W dniu 31.10.2011 14:49, Pau Garcia i Quiles pisze:
On Thu, Oct 27, 2011 at 1:28 AM, Ian Jackson
The difficulty is that if we end up with ten different versions of
vulnerability we need to somehow backport the patch to each of those
And here "we" means the security team, not the people who uploaded the
ten versions in the first place.
So this is rather unpalatable.
What's the alternative?
It seems that we only have two choices:
(what we have been doing until now, which results in some packages not
manifest only in some situations in runtime). This is essentially what
we do with C, C++, etc libraries, btw: the whole Debian is built
against the same zlib, same glibc, same libpng, etc
- Each package works with the upstream-bundled version of the
security fixes). The advantage being we are sure the application works
as expected because it has been tested by upstream.
I'm not sure what's worse: a malfunctioning application or an insecure one.
Zygmunt's proposal of adding unit testing, etc to upstream is a noble
one but highly unrealistic, IMHO.
For the record. I stated the reverse, what you described above was
proposed by someone else. I on the other hand agree that we should:
1) Ship _bundled_ libraries that upstream provides. The rationale is
that version is what upstream supports. I don't believe in our capacity
to support random applications out there better than upstreams already do.
2) Have broad multi-version support (perhaps eventually at dpkg level),
version that upstream used. The motivation for this is similar to my
previous point except that it might be, theoretically, better to support
security fixes. The more direct advantage is easier support for
incompatible, co-installable versions of a single library.
I think that security aspect is moot because failing to find a proper
package people will just revert to _not_ using dpkg for their web
deployments and the world will NOT be a single bit more secure.