Re: ssl security desaster
On Wed, May 28, 2008 at 12:00:47AM +0100, Colin Watson wrote: On Tue, May 27, 2008 at 05:49:59PM +0200, Patrik Fimml wrote: No, actually, /all/ keys I generated were allegedly weak -- this means, after executing ssh-keygen and dowkd.pl five times, I stuck to the key. This rings all my alarm bells. In similar cases I've had reported to me, it always turned out that e.g. somebody had upgraded openssl but not libssl0.9.8, or something similar. Eek, that may indeed have been possible. :-( (ssh-vulnkey thinks it is fine though.) While I'm very confident in ssh-vulnkey's accuracy, note that ssh-vulnkey has two different states you might interpret as fine: Not blacklisted (i.e. definitely fine) and Unknown (no blacklist information) (i.e. no blacklist file installed for this key type and size). In the most recent upload to unstable, I clarified the second state to Unknown (blacklist file not installed) and added more detailed documentation in the manual page. No, my current key is really fine. It seems that I really only upgraded openssl when trying dowkd.pl, and then upgraded everything before trying again. :-/ Sorry for the confusion. Patrik PS: second eek - originally not sent to list accidentally. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
security embargos (was: Re: ssl security desaster)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sorry, I did not answer to the list: Am Mi den 28. Mai 2008 um 1:13 schrieb Colin Watson: It is never ever a good idea to make security issues secret or protracting it. And in this special case it was easy to fix the problem very fast when the advisory cames out. Let's say you'd been asleep at the time, and the advisory had laid out everything necessary to make it trivial to produce an exploit (it could easily have been much more explicit than it was, and even with limited information it only took a day and a half to produce an exploit; a couple of hours would not at all have been out of the question). Would you still feel the same way if your accounts had been compromised? Well, real men have directly connection of the CVE advisories to his brain. :-) But seriously, yes, otherwise I am not sure that my system might be compromised by someone who has more knowledge (from what source however) than me. The last one do fear me! If we had released any sooner, the OpenSSH blacklisting support would not have been available, and every system administrator would have had to figure out what was going on by hand rather than have the upgrade automatically deny attempts to exploit this vulnerability. If we had released later, a number of flaws in the blacklisting support could have been fixed, alleviating a great deal of confusion among system administrators (I spent considerable time that week supporting people confused by the new tools), and I doubt it would have made much if any difference to exploit production. I spend also some time with week administrators who did not understand the consequence of this bug or are not able to read perl code or using patch. But I do not wining about. Better to have the bug published without a blacklist so the systems can be secured as early as possible than an open system where some bad people might have this information nevertheless and use it. We used the embargo period to develop tools to help system administrators defend themselves, not to sit in a smoke-filled room gloating that we knew a secret and you didn't. I believe that. But it fears me to know that there is information out there which could be known by bad people to attack (my) systems cause other need a embargo time to develop tools to help me seeing what exactly is vulnerable. The bad people might have ways to get to the informations about zero day vulnerabilities. Regards Klaus Ethgen - -- Klaus Ethgenhttp://www.ethgen.de/ pub 2048R/D1A4EDE5 2000-02-26 Klaus Ethgen [EMAIL PROTECTED] Fingerprint: D7 67 71 C4 99 A6 D4 FE EA 40 30 57 3C 88 26 2B -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iQEVAwUBSD17S5+OKpjRpO3lAQKRGgf+IKowtWi9KHHY9IomXH5+gndLCMKpv8cN QM2V5fPai4F8NENsgyMYBmnkByeClXzej6kmbfMkDii5Jjp5NNIWNhmX+NTBqhbn MSZJAgP23CC+dV9a+qzyd3uQVxxcZIjnQeKHNQSklv6Ll1XmJImhMMSfV0GaDjCI DI5eD1NgBSBZ97z75+RFmzAkksasqSyewUnKZjASmHD3YhUmTqDMvLx2gbxmN95B TTP2aStHeZNRe+d7oJ1VxVVqnHARRofh1GqvkuqdrLmgUMarQD2kCPiKdck6qIb4 qU/g+Poo14VnuyzYggoljbQ9mjM10qYDfkThiKVfSVg+Ka/7EeEZlQ== =gITD -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ssl security desaster
* Florian Weimer: Well, you can send me the key in private if you want. Let's see if I can factor it. 8-) I got the key from Patrik, but it's not contained in my blacklist. We couldn't find a dowkd version that flagged the key as weak, nor could we definitely confirm that the very same key was actually tested at the time the alleged false positive occurred. *sigh* -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ssl security desaster
On Tue, May 27, 2008 at 05:49:59PM +0200, Patrik Fimml wrote: On Tue, May 27, 2008 at 04:51:36PM +0200, Florian Weimer wrote: Well, I actually had false positives (on amd64) -- even freshly generated keys with the new libopenssl package were reported as bad, which irritated me a bit. And you've already deleted those keys, right? How convenient. 8-/ No, actually, /all/ keys I generated were allegedly weak -- this means, after executing ssh-keygen and dowkd.pl five times, I stuck to the key. This rings all my alarm bells. In similar cases I've had reported to me, it always turned out that e.g. somebody had upgraded openssl but not libssl0.9.8, or something similar. (ssh-vulnkey thinks it is fine though.) While I'm very confident in ssh-vulnkey's accuracy, note that ssh-vulnkey has two different states you might interpret as fine: Not blacklisted (i.e. definitely fine) and Unknown (no blacklist information) (i.e. no blacklist file installed for this key type and size). In the most recent upload to unstable, I clarified the second state to Unknown (blacklist file not installed) and added more detailed documentation in the manual page. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ssl security desaster (was: Re: SSH keys: DSA vs RSA)
On Tue, May 27, 2008 at 01:45:25AM +0200, Klaus Ethgen wrote: Am Di den 27. Mai 2008 um 1:09 schrieb Colin Watson: On Thu, May 15, 2008 at 09:15:57AM -0700, Mike Bird wrote: The rollout of information and updates was appalling - even adding in the material from Ubuntu the information was piecemeal and inadequate to properly secure systems within the limited time before crackers might be expected to have exploits. I think part of the problem here was that the coordinated release date for the advisory was simply too soon after the relevant parties were notified. Ehem, is it your idea of security to make it secret (like Microsoft do often)? Well done; a straw man combined with an implication of an ad hominem. That always really impresses me. It is never ever a good idea to make security issues secret or protracting it. And in this special case it was easy to fix the problem very fast when the advisory cames out. Let's say you'd been asleep at the time, and the advisory had laid out everything necessary to make it trivial to produce an exploit (it could easily have been much more explicit than it was, and even with limited information it only took a day and a half to produce an exploit; a couple of hours would not at all have been out of the question). Would you still feel the same way if your accounts had been compromised? If we had released any sooner, the OpenSSH blacklisting support would not have been available, and every system administrator would have had to figure out what was going on by hand rather than have the upgrade automatically deny attempts to exploit this vulnerability. If we had released later, a number of flaws in the blacklisting support could have been fixed, alleviating a great deal of confusion among system administrators (I spent considerable time that week supporting people confused by the new tools), and I doubt it would have made much if any difference to exploit production. but I think an extra day or two on the embargo period would very likely have produced a better result. It is never a good idea to set a embargo period for a security issue. This is more valid for the scope of this big security problem! If it had been released without an embargo, many more systems would have been compromised, and (given the severity) it's entirely possible that somebody would have managed to write a worm that took advantage of this to seriously damage Internet infrastructure. It's as simple as that. We used the embargo period to develop tools to help system administrators defend themselves, not to sit in a smoke-filled room gloating that we knew a secret and you didn't. I believe wholeheartedly in full disclosure of all security problems. Nothing else ultimately makes sense, particularly in the free software world. That doesn't mean I think we have to actively help the black hats; a few days of advance notice is just about all the advantage we have, and we desperately need to make good use of it. All together I must say it was very professional and fast how the debian security team and other had done the treatment of the problem. Don't lower them by arguing with snakeoil about that the reaction was to fast! It can never be fast enough. Note that I was myself heavily involved in producing some of the fixes that went out in Debian security advisories. If the people directly involved are not entitled to make comments on the process, who exactly do you think is? I think everyone involved did a wonderful job, especially given the appalling constraints they were under. There is a difference, though, between acknowledging the excellent work that was done and burying one's head in the sand claiming that nothing could possibly have been improved. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ssl security desaster (was: Re: SSH keys: DSA vs RSA)
On Wed, May 28, 2008 at 11:13 AM, Colin Watson [EMAIL PROTECTED] wrote: I think everyone involved did a wonderful job, especially given the appalling constraints they were under. There is a difference, though, between acknowledging the excellent work that was done and burying one's head in the sand claiming that nothing could possibly have been improved. A wonderful job indeed. *Thanks* from this corner of the world to the Debian + Ubuntu team involved. The efforts in getting it all done while balancing the maturity of the SSH blacklist patches scripts vs risk have been excellent. It was a hard day for everyone else too, but it is clear that it would have been much worse without such careful handling of the situation. cheers, m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ssl security desaster
Tollef Fog Heen wrote: * Martin Uecker [...] | There was a thread building packages with exact binary matches | about it. Unfortunately, most people seem to think that this is not | worth it. I don't think that's unfortunate; I think it's a waste of resources better spent elsewhere. If somebody hacks into a DD's machine, the obvious thing for an attacker to do is to trojan a Debian package. I wonder how long it would take to find out... Maybe it did already happen, who knows? | I believe that postinsts need the flexibility shell (or perl or | python or whatever) gives them. If you want to restrict postinsts | to only be able to do a limited set of operations, the quality of | packages will detoriate quite a bit as they are no longer flexible | enough to cater for all packages's needs. In fact, I think the opposite would be the case: The quality of Debian would rise, because there would be the need to establish standard interfaces for all reasonable cases where packages have to mess with the system during installation. Compare this with running windows applications without system privileges. You could argue as above, that the quality of those programs will detoriate, because applications are no longer flexible to cater for all applications's need. So where is the difference? Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ssl security desaster
On Fri, May 16, 2008 at 03:27:42PM -0500, Adam Majer wrote: Russ Allbery wrote: Martin Uecker [EMAIL PROTECTED] writes: In this case, the security advisory should clearly be updated. And all advise about searching for weak keys should be removed as well, because it leads to false sense of security. In fact, *all* keys used on Debian machines should be considered compromised. All *DSA* keys. RSA keys do not have the same problem, as I understand it. Err, how so?? RSA keys generated with broken OpenSSL need replacing. This means SSL certificates, CA, etc But RSA keys (for SSL, as an example), generated on good OpenSSL but used on Etch servers are ok? Yes. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ssl security desaster
* Thibaut Paumard: Actually, I seem to remember that the issue of critical packages being maintained by only one person have been pointed out here several times already this year (although I don't remember the particular threads). Certainly, such packages needs a better QA than the rest. It's not clear that more eyeballs would have caught this. So far, only one person has claimed that he'd spotted the mistake during review. I think such a claim is a bit bold. And let's be realistic -- it's difficult to enforce strict levels ov review in an all-volunteer project. If we want to make changes, it's probably more prudent to consider changes to make key rollovers easier. This could deal with advances in cryptanalysis and legacy bugs, not just newly-added bugs. Key rollovers are never going to be easy, but if there no embedded timestamps or IDs of key-generating software, they are particularly difficult. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ssl security desaster
Tollef Fog Heen wrote: * Martin Uecker | Another problem I have argued about before, not directly related to this | incident, but IMHO another desaster waiting to happen: There is no | way to independetly validate that a debian binary package was | created from the corresponding source. How would you go about doing that? If you just mean «all packages should be built on the buildds», that's fairly easy to do, but if you are talking about actual verification of source = binary which can be done post-mortem, that's much harder. Actually, it's not that hard. If you build a package in a controlled environment, you get something which is in most cases already very reproducable. For many packages there are only a few time stamps which somehow end up in the built that make it non-reproducable. Since these time stamps are not really usefull anyway they could simply be removed. There was a thread building packages with exact binary matches about it. Unfortunately, most people seem to think that this is not worth it. | What bothers me too is the fact that the installer scripts of all | packages have root permissions during installation. While this might | be hard to do, in principle I see no good reason why installer | scripts could not be limited to certain tasks. I believe that postinsts need the flexibility shell (or perl or python or whatever) gives them. If you want to restrict postinsts to only be able to do a limited set of operations, the quality of packages will detoriate quite a bit as they are no longer flexible enough to cater for all packages's needs. A lot of packages have very simple scripts often only updating some kind of index after installation which could be done with triggers. In these cases, the scripts could possibly removed completely. Checking that the package does not overwrite files from other packages and installs files only to certain directories would then limit the security risks from installing the package to the users of a system which actually do use the software. In other cases, it might be possible to lock the scripts down with selinux, as Manoj pointed out in the thread mentioned above. Regards, Martin signature.asc Description: Digital signature
Re: ssl security desaster
* Martin Uecker | Tollef Fog Heen wrote: | | How would you go about doing that? If you just mean «all packages | should be built on the buildds», that's fairly easy to do, but if you | are talking about actual verification of source = binary which can be | done post-mortem, that's much harder. | | Actually, it's not that hard. If you build a package in a controlled | environment, you get something which is in most cases already very | reproducable. Except that in practice, your build environment is no longer available. Unstable is a moving target, so you'd need to know exactly which versions were used to build a particular package. | For many packages there are only a few time stamps which somehow end | up in the built that make it non-reproducable. Since these time | stamps are not really usefull anyway they could simply be removed. If you are looking at this as a security system, the interesting bit is not how it works, but rather how it fails. «For many packages» is therefore less interesting than the most complex packages which might embed something from the build environment, leading to not-completely-reproducible builds. | There was a thread building packages with exact binary matches | about it. Unfortunately, most people seem to think that this is not | worth it. I don't think that's unfortunate; I think it's a waste of resources better spent elsewhere. | I believe that postinsts need the flexibility shell (or perl or | python or whatever) gives them. If you want to restrict postinsts | to only be able to do a limited set of operations, the quality of | packages will detoriate quite a bit as they are no longer flexible | enough to cater for all packages's needs. | | A lot of packages have very simple scripts often only updating some | kind of index after installation which could be done with triggers. Sure, but again, if this is a security system, the interesting bit is how it fails. What happens with all those complex packages which don't just have five triggers to be pulled? | In these cases, the scripts could possibly removed completely. | Checking that the package does not overwrite files from other | packages and installs files only to certain directories would then | limit the security risks from installing the package to the users | of a system which actually do use the software. Am I understanding you correct in that you think just supporting installation of a subset of packages would be acceptable? I don't think it's acceptable or interesting, but you are of course free to work in that direction. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: ssl security desaster (was: Re: SSH keys: DSA vs RSA)
Kevin B. McCarty [EMAIL PROTECTED] wrote: If you see packages for which a Debian-specific patch seems unnecessary, please by all means file a bug (severity wishlist) requesting that the patch be either reverted or submitted upstream. Most time the patch is already submitted upstream, but not yet applied or released. If you look into the Debian changelogs you find a lot of drop XXX patch, applied upstream. This is done to bring the fix faster to the user. The question is, is this worth it? Maybe it is, but only for certain patches? Is there a policy? Speaking only for myself, let me comment on some extensive patching. I guess that some of my physics-related packages (cernlib, paw) are among the more heavily patched in Debian. Unfortunately upstream is dead, so there is *no way* to see the patches incorporated there. As other have already pointed out: In this case, it should be considered a fork. And even before they gave up the ghost, they were very conservative, refusing to consider most patches more complicated than trivial changes to fix complete breakage. Open source development does work well only if splitting up the development in different branches or even forks is strongly avoided and done only if it is strictly necessary. IMHO the Debian way of doing things makes it far too easy for package maintainers to diverge from the upstream source. I can't really comment on the examples you have provided, but in general, I feel that Debian has not found the right balance here. Regards, Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ssl security desaster (was: Re: SSH keys: DSA vs RSA)
Hi, Le 16 mai 08 à 13:48, Martin Uecker a écrit : Kevin B. McCarty [EMAIL PROTECTED] wrote: If you see packages for which a Debian-specific patch seems unnecessary, please by all means file a bug (severity wishlist) requesting that the patch be either reverted or submitted upstream. Most time the patch is already submitted upstream, but not yet applied or released. If you look into the Debian changelogs you find a lot of drop XXX patch, applied upstream. This is done to bring the fix faster to the user. The question is, is this worth it? Maybe it is, but only for certain patches? Is there a policy? I personally often discuss the patches with my upstream (but then, they're really responsive). Most of the time they apply it to their CVS, and I backport their patch (generally improved over my approach). If a patch fixes a real bug and looks simple enough that's its unlikely to break anything, I think it's useful. Other patches are not supposed to go to upstream, because they are just meant to implement the Debian policy (also I generally tell upstream anyway, to have their opinion). Of course you need to define simple enough, and unlikely (for openssl, you want it to be _very_ unlikely). I agree with you that patching should be kept to a minimum : back-porting bug fixes and implementing Debian policy (even there, I would try to not overdo it, but a must in policy is a must). By the way, Debian policy is not completely silly, so even those patches can often go to upstream and be shared with the other distributions, of be configurable at build time. For instance, my main package, yorick, traditionally expects user files to be in ~/ Yorick/. Those files can be considered configuration or data, that really depends on the user. I've triggered a discussion on the matter that configuration files in a user's home directory should be stored in hidden files or directories (that's from the FHS). Yorick now looks at both ~/.yorick/ and ~/Yorick/, so the user can choose. I was motivated by abiding by Debian policy, but the change was made upstream, to avoid a fork. If upstream had rejected the idea, I'm not sure what I would have chosen. I tend to believe the right thing to do here was to avoid a fork at all cost, but others may disagree. Let's hope this discussion will, in the end, bring good ideas and trigger actual work to improve Debian, and perhaps the free software community at large. Best regards, Thibaut. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
changing subjects when discussion becomes slightly off-topic - Was: Re: ssl security desaster (was: Re: SSH keys: DSA vs RSA)
Le vendredi 16 mai 2008 à 14:48 +0200, Thibaut Paumard a écrit : Let's hope this discussion will, in the end, bring good ideas and trigger actual work to improve Debian, and perhaps the free software community at large. Best regards, Thibaut. That'd be great. But please, may I suggest that only matters applying to keys, SSH, SSL be kep in the same Subject in the thread for future archives digging ? Thanks in advance. Best regards, -- Olivier BERGER [EMAIL PROTECTED] (*NEW ADDRESS*) http://www-inf.it-sudparis.eu/~olberger/ - OpenPGP-Id: 1024D/6B829EEC Ingénieur Recherche - Dept INF Institut TELECOM / TELECOM Management SudParis (http://www.it-sudparis.eu/), Evry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: changing subjects when discussion becomes slightly off-topic - Was: Re: ssl security desaster (was: Re: SSH keys: DSA vs RSA)
2008/5/16 Thibaut Paumard [EMAIL PROTECTED]: the topic has already been changed to ssl security desaster, and in my opinion this is precisely what my post is about: what can we learn from this disaster. (More precisely, I'm giving my 2c on what level of patching is acceptable in a Debian package. Since the disaster allegedly originates in abusive patching, this is relevant). I disagree. The cause of the disaster was not that Debian does its own patching, but the fact that that patch was buggy. On the whole I think that Debian benefits a lot from custom patches, and in fact many packages would be severely buggy and/or wouldn't integrate properly with the rest of the system without them. It's not a secret that many projects benefit from Debian patches, so there might be something good with them. 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. 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. I think that defending the position of using pristine upstream source code are just a conservative position to guarantee that we can blame upstream or someone else if something like this happens again, not that bugs won't happen. Only those who don't do anything don't make mistakes. The point is to try to avoid mistakes, not to be able to blame upstream. Of course, the development and checking of the patches should be done as cooperatively with upstream as possible, as upstream might see something we're not seeing, but the way to the solution, in my opinion, is not to avoid patching but to develop a way to check them as extensively as possible. Maybe there should also be a clasification of packages according to how bad would a bug be in them for the whole system, so that patches in those could be more carefully reviewed. Greetings, Miry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: changing subjects when discussion becomes slightly off-topic - Was: Re: ssl security desaster (was: Re: SSH keys: DSA vs RSA)
Miriam Ruiz [EMAIL PROTECTED] writes: Maybe there should also be a clasification of packages according to how bad would a bug be in them for the whole system, so that patches in those could be more carefully reviewed. Perhaps uploads could come with the diff against the last version (or a link to it)? -- http://www.greenend.org.uk/rjk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ssl security desaster (was: Re: changing subjects when discussion becomes slightly off-topic - Was:Re: SSH keys: DSA vs RSA)
Le 16 mai 08 à 15:41, Miriam Ruiz a écrit : 2008/5/16 Thibaut Paumard [EMAIL PROTECTED]: [...] Maybe there should also be a clasification of packages according to how bad would a bug be in them for the whole system, so that patches in those could be more carefully reviewed. Actually, I seem to remember that the issue of critical packages being maintained by only one person have been pointed out here several times already this year (although I don't remember the particular threads). Certainly, such packages needs a better QA than the rest. By the way, I was under the impression that Ubuntu was claiming a tighter QA for their core system... (tighter than the rest of Ubuntu, perhaps not than Debian). I can see two approaches to deal with critical packages: - enforcing team maintaining, although I'm not sure that would solve the problem: how can we be certain that each members would cross-check each other's work? Perhaps a double signature could be required, so that we are certain that the source actually reached several maintainer's computers before being uploaded? - having a special queue where every upload (to those critical packages) needs to be reviewed by a special task force, but that would delay upgrades and there needs to be provisions for urgent security fixes... Perhaps those critical packages can indeed go directly into the pool, but be automatically marked with an RC bug: needs security review? That may be silly to mark every critical package as RC buggy each time it is uploaded to the archive... But doesn't it make some sense? Of course both approaches require skilled manpower... I can see that the first approach distributes the workload on potentially more people, while the second one may ensure the better reviews... There comes then the question of what packages are critical. At first I was thinking the entire set of required packages should be considered critical, but that may not be necessary. (And certainly, many packages which are _not_ required are critical as well). Hope I'm not talking too much non-sense. Best regards, Thibaut. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ssl security desaster
Hi Martin, Martin Uecker wrote: Kevin B. McCarty [EMAIL PROTECTED] wrote: If you see packages for which a Debian-specific patch seems unnecessary, please by all means file a bug (severity wishlist) requesting that the patch be either reverted or submitted upstream. Most time the patch is already submitted upstream, but not yet applied or released. If you look into the Debian changelogs you find a lot of drop XXX patch, applied upstream. This is done to bring the fix faster to the user. The question is, is this worth it? Maybe it is, but only for certain patches? Is there a policy? Well, *assuming* the patch is good, a subset of users of the software (i.e. Debian users and users of downstream distributions) benefit from it between the time it's applied in Debian and the time it's applied upstream, and there are no major negatives that I can think of. But that assumption is what you really want to discuss, I guess. As far as I know, Debian policy is silent about when to apply a patch or how to decide if it's good. If upstream is responsive, it might make sense to wait until someone from there reviews the patch and gives a thumbs-up or -down. That supposes it is clear how to get in touch with upstream, which I gather was one of the big mis-communications leading to the current state of affairs [1]. [1] http://advogato.org/person/branden/diary/5.html Speaking only for myself, let me comment on some extensive patching. I guess that some of my physics-related packages (cernlib, paw) are among the more heavily patched in Debian. Unfortunately upstream is dead, so there is *no way* to see the patches incorporated there. As other have already pointed out: In this case, it should be considered a fork. It's really just an argument over semantics. I personally think of a real fork as one where someone purports to have taken over the role of upstream. You're welcome to have a different opinion (clearly you do). The XFree86 4.3.0 that Debian shipped with Sarge was also extremely heavily patched from the upstream version, but I don't believe most people thought of it as a real fork (unlike X.org). And even before they gave up the ghost, they were very conservative, refusing to consider most patches more complicated than trivial changes to fix complete breakage. Open source development does work well only if splitting up the development in different branches or even forks is strongly avoided and done only if it is strictly necessary. IMHO the Debian way of doing things makes it far too easy for package maintainers to diverge from the upstream source. I can't really comment on the examples you have provided, but in general, I feel that Debian has not found the right balance here. At least for the example of my packages that I brought up, if I could not make an extensive set of patches, it is unlikely that the software could have met the policy and quality standards to be accepted into Debian. Whether it's better for Debian to ship heavily-patched software (that is still quite popular in the physics community) from a dead upstream, or not to ship it at all (forcing users to download it on their own from upstream's web site, then find and apply some set of patches grabbed from elsewhere on the web [2,3], then going through a baroque and obsolete build procedure [4]) is of course open for debate. You can guess that I hold the former of these opinions. [2] http://www.public.asu.edu/~comfort/cernlib.html [3] http://www-zeuthen.desy.de/linear_collider/cernlib/new/cernlib_2005.html [4] http://cernlib.web.cern.ch/cernlib/install/install.html One could certainly envision a distribution that used a Debian-like packaging infrastructure, but had a goal of trying to deviate from upstream's source code as little as possible. I think that such a distribution would either have serious QA problems (think for instance of embedded code copies, a security nightmare) or would be restricted to packaging a much smaller set of software than Debian does. YMMV. best regards, -- Kevin B. McCarty [EMAIL PROTECTED] WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 signature.asc Description: OpenPGP digital signature
Re: ssl security desaster
Hi Kevin! Kevin B. McCarty [EMAIL PROTECTED] wrote: Martin Uecker wrote: [...] Well, *assuming* the patch is good, a subset of users of the software (i.e. Debian users and users of downstream distributions) benefit from it between the time it's applied in Debian and the time it's applied upstream, and there are no major negatives that I can think of. But that assumption is what you really want to discuss, I guess. I think it is problematic even if the patch is good, because having different software branches fragments all kind of bug fixing/development and reviewing work, which could otherwise be shared upstream. As far as I know, Debian policy is silent about when to apply a patch or how to decide if it's good. If upstream is responsive, it might make sense to wait until someone from there reviews the patch and gives a thumbs-up or -down. That supposes it is clear how to get in touch with upstream, which I gather was one of the big mis-communications leading to the current state of affairs [1]. [1] http://advogato.org/person/branden/diary/5.html This might be part of the problem, but there was discussion with other upstream developers on openssl-dev. So the problem was not that there was no communication, but that the actual patch was not forwarded to the upstream developers. [..] As other have already pointed out: In this case, it should be considered a fork. It's really just an argument over semantics. I personally think of a real fork as one where someone purports to have taken over the role of upstream. You're welcome to have a different opinion (clearly you do). The XFree86 4.3.0 that Debian shipped with Sarge was also extremely heavily patched from the upstream version, but I don't believe most people thought of it as a real fork (unlike X.org). I guess you are right, it's not a fork, more like a branch. I could imagine that there are good reasons for having a Debian branch for something like X, but I don't think this is true for many packages. [...] At least for the example of my packages that I brought up, if I could not make an extensive set of patches, it is unlikely that the software could have met the policy and quality standards to be accepted into Debian. Whether it's better for Debian to ship heavily-patched software (that is still quite popular in the physics community) from a dead upstream, or not to ship it at all (forcing users to download it on their own from upstream's web site, then find and apply some set of patches grabbed from elsewhere on the web [2,3], then going through a baroque and obsolete build procedure [4]) is of course open for debate. You can guess that I hold the former of these opinions. Surely, this is very valuable work and I am not implying at all that you should stop it. But if upstream is dead, then their is no reason not to step in and simply take ownership of the package. Traditionally, if upstream was dead, somebody formally declared ownership of the software and took over development. I think this is the right thing to do, because then there is a new upstream where all other work can be shared. If upstream is incompetent, that somebody can step in and fork the software. Again, with a clear announcement. Then this step can be discussed openly and other users might switch over to the fork. Just integration all changes which are not accepted upstream as part of the packaging work just makes it too easy to diverge from upstream without good reason, without discussion and without an easy way for other users/distributions to see whats going on and to eventually switch over. One could certainly envision a distribution that used a Debian-like packaging infrastructure, but had a goal of trying to deviate from upstream's source code as little as possible. I think that such a distribution would either have serious QA problems (think for instance of embedded code copies, a security nightmare) or would be restricted to packaging a much smaller set of software than Debian does. YMMV. I don't now. I see no reason why all this good work which now ends up in Debian patches can't be seperated from the actual packaging work. Regards, Martin signature.asc Description: Digital signature
Re: ssl security desaster
Martin Uecker [EMAIL PROTECTED] writes: I don't now. I see no reason why all this good work which now ends up in Debian patches can't be seperated from the actual packaging work. It's probably worth mentioning somewhere in this discussion that one of the most common, perhaps the most common apart from FHS tweaks and other Debian-specific modifications that upstream does not want, to patch upstream source is to cherry-pick fixes from upstream before upstream has done a new release. That's most of the upstream patches to my packages, for example. A lot of those frequently indicates a close and very fruitful interaction with upstream. Waiting for upstream releases to fix problems when the fix is known is not a great idea, IMO, particularly when the problems are serious, and pulling an untested upstream VCS snapshot with lots of other changes isn't a good idea. I know that isn't the patch case that you were getting at, but it's important, when discussing scenarios around patches, to allow for that one as well. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ssl security desaster
Russ Allbery wrote: Martin Uecker [EMAIL PROTECTED] writes: In this case, the security advisory should clearly be updated. And all advise about searching for weak keys should be removed as well, because it leads to false sense of security. In fact, *all* keys used on Debian machines should be considered compromised. All *DSA* keys. RSA keys do not have the same problem, as I understand it. Err, how so?? RSA keys generated with broken OpenSSL need replacing. This means SSL certificates, CA, etc But RSA keys (for SSL, as an example), generated on good OpenSSL but used on Etch servers are ok? - Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ssl security desaster
* Martin Uecker | Another problem I have argued about before, not directly related to this | incident, but IMHO another desaster waiting to happen: There is no | way to independetly validate that a debian binary package was | created from the corresponding source. How would you go about doing that? If you just mean «all packages should be built on the buildds», that's fairly easy to do, but if you are talking about actual verification of source = binary which can be done post-mortem, that's much harder. | What bothers me too is the fact that the installer scripts of all | packages have root permissions during installation. While this might | be hard to do, in principle I see no good reason why installer | scripts could not be limited to certain tasks. I believe that postinsts need the flexibility shell (or perl or python or whatever) gives them. If you want to restrict postinsts to only be able to do a limited set of operations, the quality of packages will detoriate quite a bit as they are no longer flexible enough to cater for all packages's needs. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ssl security desaster
Tollef Fog Heen [EMAIL PROTECTED] writes: * Martin Uecker | What bothers me too is the fact that the installer scripts of all | packages have root permissions during installation. While this might | be hard to do, in principle I see no good reason why installer | scripts could not be limited to certain tasks. I believe that postinsts need the flexibility shell (or perl or python or whatever) gives them. If you want to restrict postinsts to only be able to do a limited set of operations, the quality of packages will detoriate quite a bit as they are no longer flexible enough to cater for all packages's needs. I've thought for a while that the best solution to this would be to write an interpreter with a *very simple* language that understands the semantics of Debian maintainer scripts and understands how to do the 50 or 100 most common things that people have to do in maintainer scripts. I think that writing a mini-language with very simple semantics, designed to be very easy to parse and analyze with automated tools, that supports 80% of what people do in maintainer scripts would be fairly straightforward (easily within a Google Summer of Code project). Packages could then have the option. Packagers could depend on that interpreter and use the mini-language, or they could fall back to shell or Perl the way that they do now for the complex cases. You'd probably want to skip config, preinst, and postrm support for the first pass until it's proven to be a good idea and one has built justification for making the package essential, but the long-term goal would be to have that interpreter become essential and have it be the default way of handling maintainer scripts. You can then still bail on packages that do things that are just way too hard and maintain that escape to stronger languages, while still gaining all the benefits of a highly restricted and simple language for the vast majority of packages. I of course have absolutely no time to work on this. :) But it's not something that anyone would need permission or approval to start doing. Anyone could do this right now, propose the language design for peer review here on debian-devel, and upload a package that implements it, and people who want to start experimenting with it could have their packages depend on it. (debhelper support would of course be useful at a fairly early stage, since a fairly substantial percentage of our maintainer scripts are generated at least in part by debhelper.) -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ssl security desaster (was: Re: SSH keys: DSA vs RSA)
On Thursday 15 May 2008 14:04, Martin Uecker wrote: If I understand this correctly, this means that not only should keys generated with the broken ssl lib be considered compromised, but all keys which were potentially used to create DSA signatures by those broken libs. In this case, the security advisory should clearly be updated. The original advisory has this text: Furthermore, all DSA keys ever used on affected Debian systems for signing or authentication purposes should be considered compromised; the Digital Signature Algorithm relies on a secret random value used during signature generation. I read there exactly the thing you describe above. What is your suggestion? And all advise about searching for weak keys should be removed as well, because it leads to false sense of security. In fact, *all* keys used on Debian machines should be considered compromised. The reasoning above does not go for the more common RSA keys, so this advice would not be appropriate I think. I also wonder, what will the Debian community change in their processes to make such a security desaster less likely in the future? You mean less likely than once in 15 years? We're open to your suggestions. Thijs pgpyhLOdSozzB.pgp Description: PGP signature
Re: ssl security desaster
Martin Uecker [EMAIL PROTECTED] writes: In this case, the security advisory should clearly be updated. And all advise about searching for weak keys should be removed as well, because it leads to false sense of security. In fact, *all* keys used on Debian machines should be considered compromised. All *DSA* keys. RSA keys do not have the same problem, as I understand it. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ssl security desaster (was: Re: SSH keys: DSA vs RSA)
Am Donnerstag, den 15.05.2008, 15:20 +0200 schrieb Thijs Kinkhorst: On Thursday 15 May 2008 14:04, Martin Uecker wrote: If I understand this correctly, this means that not only should keys generated with the broken ssl lib be considered compromised, but all keys which were potentially used to create DSA signatures by those broken libs. In this case, the security advisory should clearly be updated. The original advisory has this text: Furthermore, all DSA keys ever used on affected Debian systems for signing or authentication purposes should be considered compromised; the Digital Signature Algorithm relies on a secret random value used during signature generation. I read there exactly the thing you describe above. What is your suggestion? I missed this, sorry. The advisory for ssh does not include this information. Is this not relevant for ssh for some reason? To be clear, I have been quite impressed by the professional reaction to this (and other) security problems. But it still would like to see some more information here. (Which might already be in the works.) And all advise about searching for weak keys should be removed as well, because it leads to false sense of security. In fact, *all* keys used on Debian machines should be considered compromised. The reasoning above does not go for the more common RSA keys, so this advice would not be appropriate I think. Ok. I also wonder, what will the Debian community change in their processes to make such a security desaster less likely in the future? You mean less likely than once in 15 years? We're open to your suggestions. Something as bad as this might be rare, still, if something can be improved, it should. Upstream complained about the extensive Debian patching. I think this is a valid criticism. For security sensitive packages, requiring changes to be signed-off by a second person might be a good idea too. Another problem I have argued about before, not directly related to this incident, but IMHO another desaster waiting to happen: There is no way to independetly validate that a debian binary package was created from the corresponding source. What bothers me too is the fact that the installer scripts of all packages have root permissions during installation. While this might be hard to do, in principle I see no good reason why installer scripts could not be limited to certain tasks. Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ssl security desaster (was: Re: SSH keys: DSA vs RSA)
On Thursday 15 May 2008 16:47, Martin Uecker wrote: You mean less likely than once in 15 years? We're open to your suggestions. Something as bad as this might be rare, still, if something can be improved, it should. Upstream complained about the extensive Debian patching. I think this is a valid criticism. Of course things can be improved, probably always. I don't think that just one incident means that nothing must be changed, but I also contest that this incident in and of itself requires changes to be made. One incident just doesn't tell us much about the quality of Debian patches in general, either way. That's also what I dislike in Ben Laurie's blog post: he bases his conclusion on just this thing that indeed went horribly wrong, but is far from examplary for all patching that Debian, or distributions in general, do. I don't think he realises that far from all upstreams are as ideal as he seems to think. I welcome change and review of our processes, but taking one extreme incident as the base on which to draw conclusions seems not the wise thing to do. If you're interested in for example changing the level to which software is patched in Debian, I suggest to start with a representative review of what gets patched and why it's done. That would give more base to see whether the extensive patching is indeed excessive. cheers, Thijs pgpDorSiUyayM.pgp Description: PGP signature
Re: ssl security desaster (was: Re: SSH keys: DSA vs RSA)
On Thu May 15 2008 06:20:10 Thijs Kinkhorst wrote: You mean less likely than once in 15 years? We're open to your suggestions. Leaving millions of systems open to crackers for 2 years out of 15 is not a joke. I don't blame the DD - we have all made mistakes and most of us are lucky they weren't this serious - but we should blame the process. And fix it. The notification process, with the fix in the archive long before users were notified, failed to live up to Debian's usually high standards. The delay in getting some of the fixes into Testing may also be an issue. The rollout of information and updates was appalling - even adding in the material from Ubuntu the information was piecemeal and inadequate to properly secure systems within the limited time before crackers might be expected to have exploits. The vulnerability scanner didn't handle keys in many forms (e.g. Apache keys) and gave false negatives because it doesn't use ~/.ssh/config to check the correct port in the common case where ssh is running on a port other than 22. In the wonderful light of hindsight, it would probably have been better to devote less effort to the scanner and more effort to documenting all the kinds of key replacements that are needed, and to simply assume that all keys are potentially compromised. Serious efforts are needed on two fronts. Second, we must ensure that nothing like this ever happens again. This calls for a thorough investigation and carefully updated policies and procedures. It will take a while to do properly. It must be apparent to both the Debian community and the world that the effort is authoritative, sincere, and open. But first we must carefully avoid any communication, however intended, which might be construed as a flippant attitude to this disaster. --Mike Bird -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ssl security desaster (was: Re: SSH keys: DSA vs RSA)
On Thu May 15 2008 08:33:54 Thijs Kinkhorst wrote: I welcome change and review of our processes, but taking one extreme incident as the base on which to draw conclusions seems not the wise thing to do. If you're interested in for example changing the level to which software is patched in Debian, I suggest to start with a representative review of what gets patched and why it's done. That would give more base to see whether the extensive patching is indeed excessive. This is not the time to be making statements which will be regretted later. It only takes one incident as bad as this to compromise millions of systems and to seriously harm Debian's reputation. You can't average out over all packages and say Debian is 99% secure. 99% secure is 100% insecure. This incident needs to be reviewed carefully but the time is not yet. Information is not as accessible to Debian users as it should be and some packages don't seem to have reached Testing. Focus at this time must still be on disaster response and recovery. Next come the most important phases - learning from this disaster, ensuring that a repetition is impossible (or several orders of magnitude less likely), and preparing Debian's response for the next disaster. --Mike Bird -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ssl security desaster (was: Re: SSH keys: DSA vs RSA)
Am Donnerstag, den 15.05.2008, 17:33 +0200 schrieb Thijs Kinkhorst: On Thursday 15 May 2008 16:47, Martin Uecker wrote: You mean less likely than once in 15 years? We're open to your suggestions. Something as bad as this might be rare, still, if something can be improved, it should. Upstream complained about the extensive Debian patching. I think this is a valid criticism. Of course things can be improved, probably always. I don't think that just one incident means that nothing must be changed, but I also contest that this incident in and of itself requires changes to be made. One incident just doesn't tell us much about the quality of Debian patches in general, either way. I don't question the quality of Debian patches in general. But I still think that something can be learned from this single incident. The security advantage of open source software is said to be: Many Eyes Make All Bugs Shallow! This of course can not work if every distribution basically creates its own branch. That's also what I dislike in Ben Laurie's blog post: he bases his conclusion on just this thing that indeed went horribly wrong, but is far from examplary for all patching that Debian, or distributions in general, do. I don't think he realises that far from all upstreams are as ideal as he seems to think. I am missing some self-criticism too. The use of uninitialized memory should have been fixed upstream long ago. (And this is *not* a rare case where the use of uninitialized memory is ok.) I welcome change and review of our processes, but taking one extreme incident as the base on which to draw conclusions seems not the wise thing to do. Why not? A plane crash is a very rare incident. Still every single crash is investigated to make recommendations for their future avoidance. If you're interested in for example changing the level to which software is patched in Debian, I suggest to start with a representative review of what gets patched and why it's done. That would give more base to see whether the extensive patching is indeed excessive. I do not have time to do statistics, but from looking at a lot of packages over the years I know that their a many changes in Debian packages which are not related to packaging. Besides security fixes or other really important fixes which have to go in very fast, I do not see no reason for all this Debian specific changes. Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ssl security desaster (was: Re: SSH keys: DSA vs RSA)
On Thursday 15 May 2008 18:26, Martin Uecker wrote: Why not? A plane crash is a very rare incident. Still every single crash is investigated to make recommendations for their future avoidance. Maybe that wasn't clear from my first mail, but I don't think that nothing can be learned from this incident (and already has been learned!). I just think that the conclusion that Debian patches too much is at all justified when looking solely at this bug. If you're interested in for example changing the level to which software is patched in Debian, I suggest to start with a representative review of what gets patched and why it's done. That would give more base to see whether the extensive patching is indeed excessive. I do not have time to do statistics, but from looking at a lot of packages over the years I know that their a many changes in Debian packages which are not related to packaging. Besides security fixes or other really important fixes which have to go in very fast, I do not see no reason for all this Debian specific changes. I can understand that this doesn't seem necessary from the outside. However, I've been working on Debian for a few years now, and I've come to see that large numbers of patches are very justified. For example, because upstream isn't quite as cooperative, or even responds at all. Or because upstream is not interested in problems that affect Debian users specifically. There are many more examples, and probably also quite some counterexamples. There's a net win there, however. Let me state it again, surely things can be learned from this incident, but the general conclusion that Debian patches too much is in my opinion far from justified. And I think it would be a good idea to get more overview of the reasons that these patches are applied before drawing the conclusion that it's a bad idea. cheers, Thijs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ssl security desaster (was: Re: SSH keys: DSA vs RSA)
Martin Uecker wrote: Am Donnerstag, den 15.05.2008, 17:33 +0200 schrieb Thijs Kinkhorst: If you're interested in for example changing the level to which software is patched in Debian, I suggest to start with a representative review of what gets patched and why it's done. That would give more base to see whether the extensive patching is indeed excessive. I do not have time to do statistics, but from looking at a lot of packages over the years I know that their a many changes in Debian packages which are not related to packaging. Besides security fixes or other really important fixes which have to go in very fast, I do not see no reason for all this Debian specific changes. If you see packages for which a Debian-specific patch seems unnecessary, please by all means file a bug (severity wishlist) requesting that the patch be either reverted or submitted upstream. The worst that can happen is that the bug will be ignored or closed with no reason given by the maintainer. More likely (at least I hope so), you'll either get an explanation of why the patch is needed, or have your request to remove the patch actually implemented. Speaking only for myself, let me comment on some extensive patching. I guess that some of my physics-related packages (cernlib, paw) are among the more heavily patched in Debian. Unfortunately upstream is dead, so there is *no way* to see the patches incorporated there. And even before they gave up the ghost, they were very conservative, refusing to consider most patches more complicated than trivial changes to fix complete breakage. The Debian-specific patches (which have also been incorporated into Fedora's packages) incorporate things that upstream was unwilling to include, such as: - building shared libraries instead of only static ones - support for architectures other than x86 and powerpc on Linux - minimal 64-bit support - support for newer compilers (gfortran instead of g77) - fixes for bugs when programs were built against lesstif instead of the non-free OpenMotif (upstream did not see any reason to support lesstif) - removal of non-free code, and fixing the build system to work around this removal Believe me, there are lots of upstreams for which extensive patching really is necessary. (I have no idea whether OpenSSL is one of those, as I have no familiarity with its code nor the Debian packaging of it.) best regards, -- Kevin B. McCarty [EMAIL PROTECTED] WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 signature.asc Description: OpenPGP digital signature
Re: ssl security desaster
Twas brillig at 10:30:44 15.05.2008 UTC-07 when Kevin B. McCarty did gyre and gimble: KBM Believe me, there are lots of upstreams for which extensive KBM patching really is necessary. (I have no idea whether OpenSSL is KBM one of those, as I have no familiarity with its code nor the KBM Debian packaging of it.) Probably the work then should be clearly labeled as fork (especially given the other distro maintainers also share some patches)? It will reduce the confusion, like oh, erm, our foo is not quite upstream foo, we rewrote it from scratch, and left the name and this cute logo. -- pgpFaI1HR5xJr.pgp Description: PGP signature
Re: ssl security desaster (was: Re: SSH keys: DSA vs RSA)
[Mike Bird] but we should blame the process. And fix it. it would probably have been better to devote less effort to the scanner and more effort to documenting all the kinds of key replacements Serious efforts are needed Second, we must ensure This calls for a thorough investigation we must carefully avoid Who is this we? Whose serious efforts? Who is investigating? Most importantly, should we assume that, as in the past, you, Mike Bird, intend to do nothing but talk? -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ssl security desaster
Mikhail Gusarov [EMAIL PROTECTED] writes: Probably the work then should be clearly labeled as fork (especially given the other distro maintainers also share some patches)? It will reduce the confusion, like oh, erm, our foo is not quite upstream foo, we rewrote it from scratch, and left the name and this cute logo. I try to document any such modifications in README.Debian, particularly in cases where upstream disagrees with a patch. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ssl security desaster (was: Re: SSH keys: DSA vs RSA)
On Thu May 15 2008 10:34:01 Peter Samuelson wrote: Who is this we? Whose serious efforts? Who is investigating? Most importantly, should we assume that, as in the past, you, Mike Bird, intend to do nothing but talk? Debian is still one of the world's best distros and I hope it continues as such. I use Debian on more systems than any other distro. Yet Debian makes it hard for people to help. Like most software engineers I simply don't have the time to waste on Debian's NM process. Debian's processes are indisputably Debian's decision alone, but Debian has to live with the consequences ... falling mindshare, orphaned packages, and slow releases. Nevertheless, non-DD's can and do help by filing bug reports and patches (upstream is best), helping people on d-u, and offering constructive advice to DDs. And one should not forget that most of the software in Debian is developed and maintained by non-DD's. --Mike Bird -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ssl security desaster (was: Re: SSH keys: DSA vs RSA)
[Mike Bird] Nevertheless, non-DD's can and do help by filing bug reports and patches (upstream is best), helping people on d-u, and offering constructive advice to DDs. Very well. I propose that anyone who wishes to give constructive advice to developers, but who doesn't actually do any of our development work, should use the pronoun you rather than we. This might make your posts sound like you're trying to boss us around ... but that's exactly what you're doing, so it's basically more honest. I prefer honest bossiness to implicit bossiness. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ssl security desaster (was: Re: SSH keys: DSA vs RSA)
Hi, Le 15 mai 08 à 20:17, Mike Bird a écrit : Nevertheless, non-DD's can and do help by filing bug reports and patches (upstream is best), helping people on d-u, and offering constructive advice to DDs. And maintaining packages! It can be long to find a sponsor for your first package (especially if it's a very specialized software no DD uses), but you don't need to go through NM to become a (co-) maintainer. If you feel the itch, please step forward of adopt an orphaned package, as you noted there's a large pool to choose from. If you look a package with a request for help, you're sponsor is found already: your prospective comaintainer. Besides, many packages are orphaned because they are obsolete. If nobody adopts them and they get too buggy, they'll be terminated eventually. The only alternative would be to remove them right away when the maintainer feels he doesn't care anymore, but this would be worse (unless the package was so obsolete that only the maintainer still used it). Cheers, Thibaut (DM, not DD). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ssl security desaster
Hi Mikhail, Mikhail Gusarov wrote: Twas brillig at 10:30:44 15.05.2008 UTC-07 when Kevin B. McCarty did gyre and gimble: KBM Believe me, there are lots of upstreams for which extensive KBM patching really is necessary. (I have no idea whether OpenSSL is KBM one of those, as I have no familiarity with its code nor the KBM Debian packaging of it.) Probably the work then should be clearly labeled as fork (especially given the other distro maintainers also share some patches)? It will reduce the confusion, like oh, erm, our foo is not quite upstream foo, we rewrote it from scratch, and left the name and this cute logo. I'm not sure if you are addressing me specifically, or just maintainers in general who have a large patch set. I don't view my maintainership of cernlib, paw, etc. as a fork in the same sense that, say, X.org is from XFree86 or Xemacs from Emacs. (In the most technical sense, *all* Debian packages are forks of upstream, though in some happy cases the only difference is a little added packaging infrastructure, and Debian users are generally aware of this.) My patches, if somewhat extensive, are still at most a few percent of the total size of upstream's code, so there is no rewriting from scratch going on. I've also tried to make it very clear through README.Debian files, FAQ web pages, etc. how the software in Debian behaves differently from upstream's original version in the cases where the difference is visible to the end user. I have zero desire to be considered as cernlib upstream myself -- that would imply that the software was supported at a level that I am not able to guarantee. If my upstream were to reanimate (or someone else took over upstream), I'd happily continue to package new releases from them, keeping any of my patch set that continued to be necessary that they wouldn't themselves accept. Mainly, I see my packaging of this software as a caretaker effort that makes it possible for people to install it with a minimum of trouble, while being able to expect that it follows Debian policy and has some chance of getting fixes for reported bugs. If some future change to the operating system occurred that broke cernlib in a hard-to-fix way, I would be much more likely to orphan the package and request its removal from Debian than to try to make big changes to the architecture of the software. Doing the latter, IMO, *would* deserve to be called a real fork. -- Kevin B. McCarty [EMAIL PROTECTED] WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 signature.asc Description: OpenPGP digital signature
Re: ssl security desaster (was: Re: SSH keys: DSA vs RSA)
This one time, at band camp, Mike Bird said: Yet Debian makes it hard for people to help. Like most software engineers I simply don't have the time to waste on Debian's NM process. Debian's processes are indisputably Debian's decision alone, but Debian has to live with the consequences ... falling mindshare, orphaned packages, and slow releases. Nevertheless, non-DD's can and do help by filing bug reports and patches (upstream is best), helping people on d-u, and offering constructive advice to DDs. And one should not forget that most of the software in Debian is developed and maintained by non-DD's. While we all thank you for the great amount of work you put into Debian [1] [2], I personally prefer to be told what to do and think in a slightly less agressive tone, and by someone who knows slightly more about the subject at hand. I understand that those 6 bug reports probably took quite a lot of your valuable time, and I don't mean to denigrate that. If you feel that the NM process may be too rigorous for you, there are plenty of other ways to contribute to Debian. Perhaps you could tell us what obstacles we have put in your way (I'm assuming that all these efforts like DM, alioth packaging teams, QA efforts and so on don't present a low enough barrier to entry for you, so we won't sully this conversation by mentioning them). Again, really, thank you. 1.http://qa.debian.org/developer.php?login=mgb-debian%40yosemite.netcomaint=yes 2.http://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=both;submitter=mgb-debian%40yosemite.net -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: ssl security desaster (was: Re: SSH keys: DSA vs RSA)
Peter Samuelson [EMAIL PROTECTED] writes: Who is this we? Whose serious efforts? Who is investigating? Most importantly, should we assume that, as in the past, you, Mike Bird, intend to do nothing but talk? I think this is a common stylistic choice. I consider myself part of the Debian community, though I don't contribute very much directly. When I post to Debian lists, I frequently use we as both a means of building on an existing community feeling and occasionally to soften criticism. I don't use it to claim credit. I assume Mike uses it the same way. In the future, I'll keep in mind not to lump myself with Debian developers, to avoid this sort of misunderstanding. In that spirit, maybe YOU should all be more careful about YOUR pronouns, too. After all, one of YOU, namely Thijs Kinkhorst, followed up to Martin Uecker (one of US) with: You mean less likely than once in 15 years? We're open to your suggestions. Some of US (not YOU, just US) may have interpreted this not as pointless sarcasm but as a genuine call for constructive criticism from US. If YOU had meant to solicit just Martin's suggestions and not to hear any suggestions from any of the rest of US, then YOU could have been more clear in YOUR wording. Thank YOU for YOUR continued work on Debian. Despite the occasional misstep, WE appreciate YOUR efforts. If YOU ever *do* want to hear any of OUR suggestions, WE'd be happy to share them, but please be explicit when YOU ask, so WE don't embarrass OURselves again. -- Kevin Buhr [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]