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: 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]
ssl security desaster (was: Re: SSH keys: DSA vs RSA)
Steinar H. Gunderson [EMAIL PROTECTED]: On Thu, May 15, 2008 at 05:11:27AM +0200, Goswin von Brederlow wrote: Also if you have 2 messages signed with the same random number you can compute the secret key. It is more complicated then this but simplified boils down to is computing k given (k + r) * Message1 == Signature1 and (k + r) * Message2 == Signature2. For the details, since everyone doesn't read Planet Debian: http://blog.sesse.net/blog/tech/2008-05-14-17-21_some_maths /* Steinar */ 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. 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. I also wonder, what will the Debian community change in their processes to make such a security desaster less likely in the future? 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 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 (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 (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 (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 (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]
