public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: "William L. Thomson Jr." <wlt-ml@o-sinc.com>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Prevent binary/non-compiled packages from binary package creation
Date: Wed, 9 Aug 2017 16:35:56 -0400	[thread overview]
Message-ID: <assp.0394db8eb2.20170809163556.337cb4a5@o-sinc.com> (raw)
In-Reply-To: <CAD6zcDwEeivFOrZNJLk-rZcoRdNkpAh5q38jK5ym4kuYNvWE7w@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2193 bytes --]

On Wed, 9 Aug 2017 22:23:41 +0200
Francesco Riosa <vivo75@gmail.com> wrote:

> 2017-08-09 17:33 GMT+02:00 William L. Thomson Jr. <wlt-ml@o-sinc.com>:
> 
> > On Wed, 9 Aug 2017 11:07:04 +1000
> > "Sam Jorna (wraeth)" <wraeth@gentoo.org> wrote:
> >
> > > > What then is the benefit? If what is installed is the same from
> > > > package manager or binpkg. Also your redistributing another's
> > > > package in binary format which may not be legally allowed.
> > >
> > > The difference is that how the package manager/ebuild installs the
> > > package may be better suited to the environment than what upstream
> > > expects (such as upstreams that install through a .run file)
> >
> > I fail to see how basically skipping src_install and maybe some
> > prepare stuff that makes it better suited to an environment.
> > Can you explain that further?
> >
> > These packages are just exploded tarballs. I fail to see the benefit
> > to repacking those into another tarball to be exploded. At best
> > skipping src_install and/or prepare, seems to be the only
> > difference.
> >
> one such benefit is that the binhost is known and managed by someone
> you trust, SRC_URI point to the wider and dangerous internet.

Interesting argument, saying upstreams cannot be trusted. Nor Gentoo
with its manifests and hashes of the files referenced in SRC_URI. Given
that most will come from Gentoo mirrors not upstream servers. Ignoring
that the binhost has to use these SRC_URI's just the same. It makes
sense in very strange way.

FYI binpkgs have no hash. If someone did something malicious within the
binhost to the binpkgs. You have no way of knowing. Yes the same can
happen with ebuilds and manifest. But easy to sync portage and see if a
manifest has changed.

Therefore relying on binhost as means of security is possible but odd,
as it leaves things open to potentially larger issues.

> So please leave this as a configurable choice.

For some things configurable would make sense. For things like fetch
restricted, it would not. Since it is not legal to mirror that stuff to
begin with. It surely is not to re-package.

-- 
William L. Thomson Jr.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

  reply	other threads:[~2017-08-09 20:36 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-08 16:37 [gentoo-dev] Prevent binary/non-compiled packages from binary package creation William L. Thomson Jr.
2017-08-08 16:53 ` Rich Freeman
2017-08-08 17:11 ` Kristian Fiskerstrand
2017-08-08 17:18   ` Rich Freeman
2017-08-08 17:32     ` Michał Górny
2017-08-08 17:33     ` William L. Thomson Jr.
2017-08-08 17:23   ` William L. Thomson Jr.
2017-08-08 17:32     ` Kristian Fiskerstrand
2017-08-08 18:20       ` William L. Thomson Jr.
2017-08-08 18:41         ` William L. Thomson Jr.
2017-08-09  0:29         ` Sam Jorna (wraeth)
2017-08-09  0:43           ` William L. Thomson Jr.
2017-08-09  1:07             ` Sam Jorna (wraeth)
2017-08-09 15:33               ` William L. Thomson Jr.
2017-08-09 20:23                 ` Francesco Riosa
2017-08-09 20:35                   ` William L. Thomson Jr. [this message]
2017-08-10  0:50                     ` Sam Jorna (wraeth)
2017-08-10  1:42                       ` William L. Thomson Jr.
2017-08-10  3:33                         ` Sam Jorna (wraeth)
2017-08-10 17:08                           ` William L. Thomson Jr.
2017-08-10 23:58                             ` Sam Jorna (wraeth)
2017-08-10  1:25             ` Sam Jorna (wraeth)
2017-08-10  1:47               ` William L. Thomson Jr.
2017-08-10  1:56                 ` Sam Jorna (wraeth)
2017-08-08 17:34     ` Ian Stakenvicius
2017-08-08 18:10       ` William L. Thomson Jr.
2017-08-08 18:15         ` Kristian Fiskerstrand
2017-08-08 18:33           ` William L. Thomson Jr.
2017-08-09 20:42 ` William L. Thomson Jr.
2017-08-10 23:30 ` [gentoo-dev] " Duncan
2017-08-11  2:06   ` William L. Thomson Jr.

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=assp.0394db8eb2.20170809163556.337cb4a5@o-sinc.com \
    --to=wlt-ml@o-sinc.com \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox