Barry deFreese wrote: [...] > > Buggy patches happen all the time. The question is, how could > > something as bad as this slip through? And one important > > reason is IMHO, that splitting up the development/bug fixing/review > > by creating different software branches is bad. > > Different software branches in what respect? Just by nature of > having a distro "package" ? By having a large diff against the upstream source with changes unrelated to packaging. [...] > > Clearly, Debian adds value by its patches. If those patches would be > > integrated upstream, then the whole free software community would > > benefit. > > Which brings up at least two issues. Upstream not wanting the patches > or dead upstream. Speaking from the games team alone I would bet that > 50% or more of the packages have no upstream anymore. Should those > packages be removed? If upstream is dead or unable to do his job well, somebody should fork the project (or take ownership). But this has nothing to do with packaging software and should in my opinion not be intermixed. > Also, obviously, there are changes that make no sense to > upstream that are strictly distro specific. Requiring distro specific changes feels wrong anyway. Software should be coupled by standardized interfaces. But I might be naive here. What are the distro specific changes we are talking about? > Also, I don't think we should always wait for upstream's > new releases for adding them if we have them available. > It might depend on every case. I think there should be a policy. I propose: > > I would prefer if only security fixes and bugs which might cause > > data loss would fixed directly in Debian. Everything else should > > go upstream first. > > Sounds good but again, what about unresponsive/dead upstreams. Do you > leave your users to "suffer" ? Is Debian here to service the user > community > or not? Fork it. But not as part of the packaging work. > > > Maybe there's a problem with the fact that some of those patches > > > are just reviewed by just one person, but then again, I seriously > > > think that it would have been quite difficult to discover that > > > there was a problem with this one. The proof that it wasn't > > > evident is not only that upstream didn't see the problem either, > > > nor any other developer or derivative distribution or independent > > > reviewers in 2 years. > > > > Did you look at the code? This was not exactly a deeply hidden flaw > > in some obscure looking code. Upstream didn't see the patch. That's > > exactly the problem. And I doubt that there was any review of this > > code in all this 2 years. > > I have seen links where "upstream" was asked about/notified of the > patch so this isn't an entirely true statement. Egos play a big part > in all of this as well. Upstream answered that it is okay too remove the seeding of the PRNG with uninitialized memory, but the concrete patch which additionally and erranously removed all seeding was never posted on openssl-dev. Regards, Martin
Attachment:
signature.asc
Description: Digital signature