1 |
On Wed, Jan 21, 2015 at 3:11 PM, hasufell <hasufell@g.o> wrote: |
2 |
> Rich Freeman: |
3 |
>> On Wed, Jan 21, 2015 at 11:36 AM, Julian <hasufell@××××××××.de> wrote: |
4 |
>>> |
5 |
>>> We would need much better tools and PM support for overlays. I've talked |
6 |
>>> about this too and there are examples of at least two distros that are |
7 |
>>> running a more decentralized model: |
8 |
>>> 1. NixOS, also see my thread on nix-dev about how they want to ensure |
9 |
>>> focus [0] |
10 |
>> |
11 |
>> I still don't get how NixOS avoids some fundamental issues. As I |
12 |
>> understand it they assign a unique ID to every build of everything, |
13 |
>> and the dependencies are expressed in the same way. So, my build 123 |
14 |
>> of appfoo v1.1 depends on build 456 of libz v2. Your package might |
15 |
>> depend on build 457 of libz v2, and that is fine since both versions |
16 |
>> will be installed side-by-side. Then we get to have two copies of |
17 |
>> libz in RAM and maybe build 456 has a security vulnerability. It is |
18 |
>> better than static linking, but not by far. |
19 |
>> |
20 |
> |
21 |
> All copies are known to the PM. That's nothing like bundles libs or |
22 |
> static linkage. It's probably a triviality to develop a tool that checks |
23 |
> for vulnerable libraries (not sure if there already is one). |
24 |
|
25 |
I'm not saying that anything bundles libs. My understanding is that |
26 |
packages are basically all content-hashed and all dependencies |
27 |
including linking is against one of these. So, if you want you can |
28 |
have 14 versions of the same library with the same SONAME and |
29 |
completely different ABI/APIs and it will all work, because each |
30 |
package is linked against the EXACT library it was built against. Two |
31 |
packages can still share the same library (in disk and in RAM), but |
32 |
they could also use two different libraries which on most other |
33 |
distros would collide (identical version, SONAME, etc). |
34 |
|
35 |
So, when you use a package you're using the exact same code the |
36 |
maintainer uses, including all the libraries. |
37 |
|
38 |
I'm sure this breaks down at some point - you can't have 47 different |
39 |
versions of dbus all running at the same time if you want processes to |
40 |
actually talk to each other. You obviously can only run one kernel at |
41 |
a time, and there is only one port 80/25/etc on the system unless you |
42 |
run every process in its own namespace. |
43 |
|
44 |
I don't see how you'd check for vulnerable libraries other than using |
45 |
heuristics (ie actually run the exploit against the library). If |
46 |
ANYBODY can create a repository, and a repository can contain any |
47 |
number of builds of any number of versions of zlib, then how could you |
48 |
possibly tell whether any particular build is patched for any |
49 |
particular vulnerability otherwise? Certainly you could offer a tool |
50 |
that checks for known-vulnerable versions from a selection of |
51 |
supported repositories. |
52 |
|
53 |
Such a model also only promotes choice to a degree. You can choose to |
54 |
use Fred's version of libfoo, and Tony's version of java, but you |
55 |
can't use them together unless tony also chooses to support this |
56 |
configuration. Tony's java could very well link to Sam's libfoo and |
57 |
you don't like that version of it, but java isn't all that popular |
58 |
these days so beggars can't be choosers. |
59 |
|
60 |
With Gentoo you can mix/match dependencies but the same thing that |
61 |
allows that to work will also cause the system to break horribly when |
62 |
somebody changes an ABI without changing an SONAME and so on. |
63 |
|
64 |
> |
65 |
> My point was: it's not enough talking about "what should we focus on?". |
66 |
> How do you implement that focus? |
67 |
|
68 |
I do agree with this, which is one of my concerns with the original |
69 |
post. We can certainly talk about what we should focus on, but the |
70 |
only thing as a Council we really have the power to do is to forbid |
71 |
people from working on other things, or to expel hot air. The latter |
72 |
can accomplish some good, but not much. |
73 |
|
74 |
> |
75 |
> What's your idea there, except of keeping status quo which clearly does |
76 |
> not work since even gentoo oldtimers seem to realize something is going |
77 |
> wrong? |
78 |
> |
79 |
|
80 |
If I had solutions I'd be posting them. Apologies if it seems like |
81 |
I'm nitpicking. The thing is that while the status quo has some clear |
82 |
deficiencies, in some ways it is also the best Gentoo has really ever |
83 |
been. |
84 |
|
85 |
Or put another way, where else are we going to go? Maybe that is why |
86 |
so many of us that seem to have so much conflict with each other all |
87 |
stick around. |
88 |
|
89 |
-- |
90 |
Rich |