1 |
On Wed, 9 Aug 2017 22:23:41 +0200 |
2 |
Francesco Riosa <vivo75@×××××.com> wrote: |
3 |
|
4 |
> 2017-08-09 17:33 GMT+02:00 William L. Thomson Jr. <wlt-ml@××××××.com>: |
5 |
> |
6 |
> > On Wed, 9 Aug 2017 11:07:04 +1000 |
7 |
> > "Sam Jorna (wraeth)" <wraeth@g.o> wrote: |
8 |
> > |
9 |
> > > > What then is the benefit? If what is installed is the same from |
10 |
> > > > package manager or binpkg. Also your redistributing another's |
11 |
> > > > package in binary format which may not be legally allowed. |
12 |
> > > |
13 |
> > > The difference is that how the package manager/ebuild installs the |
14 |
> > > package may be better suited to the environment than what upstream |
15 |
> > > expects (such as upstreams that install through a .run file) |
16 |
> > |
17 |
> > I fail to see how basically skipping src_install and maybe some |
18 |
> > prepare stuff that makes it better suited to an environment. |
19 |
> > Can you explain that further? |
20 |
> > |
21 |
> > These packages are just exploded tarballs. I fail to see the benefit |
22 |
> > to repacking those into another tarball to be exploded. At best |
23 |
> > skipping src_install and/or prepare, seems to be the only |
24 |
> > difference. |
25 |
> > |
26 |
> one such benefit is that the binhost is known and managed by someone |
27 |
> you trust, SRC_URI point to the wider and dangerous internet. |
28 |
|
29 |
Interesting argument, saying upstreams cannot be trusted. Nor Gentoo |
30 |
with its manifests and hashes of the files referenced in SRC_URI. Given |
31 |
that most will come from Gentoo mirrors not upstream servers. Ignoring |
32 |
that the binhost has to use these SRC_URI's just the same. It makes |
33 |
sense in very strange way. |
34 |
|
35 |
FYI binpkgs have no hash. If someone did something malicious within the |
36 |
binhost to the binpkgs. You have no way of knowing. Yes the same can |
37 |
happen with ebuilds and manifest. But easy to sync portage and see if a |
38 |
manifest has changed. |
39 |
|
40 |
Therefore relying on binhost as means of security is possible but odd, |
41 |
as it leaves things open to potentially larger issues. |
42 |
|
43 |
> So please leave this as a configurable choice. |
44 |
|
45 |
For some things configurable would make sense. For things like fetch |
46 |
restricted, it would not. Since it is not legal to mirror that stuff to |
47 |
begin with. It surely is not to re-package. |
48 |
|
49 |
-- |
50 |
William L. Thomson Jr. |