Re: ssl security desaster

2008-05-29 Thread Patrik Fimml
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]



Thanks for the response on DSA-1571 OpenSSL vulnerability (was: ssl security desaster)

2008-05-28 Thread Ben Finney
Martin Langhoff [EMAIL PROTECTED] writes:

 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.
 
 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.

I've been very impressed with the response of the Debian people
involved in getting this widely understood and getting the tools in
place to help mitigate the disaster.

 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.

Yes, the vulnerability has made my time as a sysadmin very harrowing;
quite apart from the exposure and legwork involved, there is great
loss of face in some quarters for having recommended Debian in the
first place.

In such cases where embarrassing loss of face has occurred, the *only*
thing that I've been able to concretely point to as an upside has been
the excellent, professional, well-coordinated response.

Thank you, Debian project.

-- 
 \  Think for yourselves and let others enjoy the privilege to do |
  `\   so too.  -- Voltaire, _Essay On Tolerance_ |
_o__)  |
Ben Finney


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



security embargos (was: Re: ssl security desaster)

2008-05-28 Thread Klaus Ethgen
-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

2008-05-27 Thread Florian Weimer
* 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

2008-05-27 Thread Colin Watson
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)

2008-05-27 Thread Colin Watson
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)

2008-05-27 Thread Martin Langhoff
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

2008-05-18 Thread Martin Uecker

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

2008-05-17 Thread Mike Hommey
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

2008-05-17 Thread Florian Weimer
* 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

2008-05-17 Thread Martin Uecker

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

2008-05-17 Thread Tollef Fog Heen
* 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)

2008-05-16 Thread Martin Uecker

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)

2008-05-16 Thread Thibaut Paumard

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)

2008-05-16 Thread Olivier Berger
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-05-16 Thread Miriam Ruiz
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)

2008-05-16 Thread Richard Kettlewell
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)

2008-05-16 Thread Thibaut Paumard


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

2008-05-16 Thread Kevin B. McCarty
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

2008-05-16 Thread Martin Uecker

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

2008-05-16 Thread Russ Allbery
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

2008-05-16 Thread Adam Majer
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

2008-05-16 Thread Tollef Fog Heen
* 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

2008-05-16 Thread Russ Allbery
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]



ssl security desaster (was: Re: SSH keys: DSA vs RSA)

2008-05-15 Thread Martin Uecker
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)

2008-05-15 Thread 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?

 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

2008-05-15 Thread Russ Allbery
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)

2008-05-15 Thread Martin Uecker
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)

2008-05-15 Thread 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.

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)

2008-05-15 Thread Mike Bird
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)

2008-05-15 Thread Mike Bird
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)

2008-05-15 Thread Martin Uecker
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)

2008-05-15 Thread Thijs Kinkhorst
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)

2008-05-15 Thread Kevin B. McCarty
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

2008-05-15 Thread Mikhail Gusarov
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)

2008-05-15 Thread Peter Samuelson

[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

2008-05-15 Thread Russ Allbery
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)

2008-05-15 Thread Mike Bird
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)

2008-05-15 Thread Peter Samuelson

[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)

2008-05-15 Thread Thibaut Paumard

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

2008-05-15 Thread Kevin B. McCarty
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)

2008-05-15 Thread Stephen Gran
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)

2008-05-15 Thread Kevin Buhr
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]