danimoth <danim...@cryptolab.net> writes: > On 20/02/13 at 10:49am, micah anderson wrote: >> >> Developers never made a mistake leading to a security problem, so >> Debian's one mistake in 2006 should be forever trotted out as an example >> of how Debian sucks, good point. >> >> Sorry, but this distinction between Developers doesn't make sense, many >> Debian *Developers* are developers themselves, often upstream to the >> packages that they are shipping. > > > They are developers, but not for the project they are maintaing in > debian (or not all).
That is not true. There are many 'upstream' developers who are the 'developers' in Debian, in otherwords they are the ones maintaining their packages in Debian. > My point is that, if there exist a program A, its developers know a > lot more than the corrisponding debian packager, and they are the only > that could patch at "least bad". And this principle is showed > perfectly for the PRNG example which I cited. That is why those Debian people who aren't upstream are expected to have a close relationshp with upstream. That doesn't always happen of course. In the PRNG example you cited, since some people can't help but continue to talk about this one security vulnerability from seven years ago (although I've got a few vulnerabilities that were much worse since then, that is if you are interested in seeing past this one: you might be shocked!)... The Debian person who made this mistake actually *did* discuss it on openssl-dev and got a (admittedly weak) go-ahead from an openssl developer (Ulf Möeller). There were lessons learned from that, mostly about about distributions and projects working together or, as in this case, failing to work together, and the openssl team making it more clear how they would like these things to be communicated. This wasn't the first, or last time that security bugs to upstream openssl/openssh were not properly responded to by upstream. micah -- -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
