On Sat, 2005-01-15 at 17:08, William Allen Simpson wrote:
> Thor Lancelot Simon wrote:
> 
> >On Sat, Jan 15, 2005 at 05:52:16PM -0500, William Allen Simpson wrote:
> >  
> >
> >>I do wish NetBSD folk would take security more seriously.
> >>    
> >>
> >
> >Thank you, we take it quite seriously: seriously enough to not run around
> >changing things without a good understanding of why they ought to be
> >changed.
> >
> >  
> >
> Partly for the cryptography list that you added, and partly for the
> benefit of new readers of this list, I'll point out:
> 
> (1) This was discussed on this NetBSD list in 2003, and such issues were
> discussed for NetBSD and other BSDs all the way back to 1994 (by my own
> recollection).  Folks should be familiar with the issues by now.
> 
> (2) In my earlier message, I cited the terms you'd need to lookup, some
> papers you should read.  Instead, you erupted in flames.
> 
> (3) In October 2003, I provided your very own NetBSD moduli file.  These
> take a couple of weeks continuous computing to generate, so it was a
> fair amount of my own personal effort.
> 
> (4) In January 2004, OpenSSH distributed a replacement.  NetBSD never
> installed it, either. 
> 
> (5) Recently, NetBSD shipped a major release without updating it.
> 
> (6) We recently learned from Perry on cryptography that NetBSD hasn't
> audited its random number generator implementation.  (I was so
> concerned that I called Perry at home to see what could be done.)
> 
> (7) I do not consider the following statement anything other than the
> absolute heartfelt desire:
> 
> I do wish NetBSD folk would take security more seriously.
> 
> That wish includes fewer rants toward those of us that actually try to 
> provide improvements.  (Possibly it would be too much to hope for a bit 
> of gratitude.) 

There are lot's of users, such as myself, who appreciate any and all
work done to enhance security.  I think everyone really has the same
goals, so let's not let personalities interfere.  It's a difficult
subject, and it takes a lot of effort to fully understand it.  I'm not
going to comment in this specific instance because I don't know all the
details, nor all the logistical issues.  Let's first reach a consensus
on whether to update (which I believe should be yes, but I'm just a
bystander) and then try and calmly work out the details?

I know that it is easy to get emotionally involved when you've put in
many hours of work; what I think is happening here is that there a
couple of people are already putting in maximum effort, and feel that
effort is not appreciated.  Sometimes they are probably correct, as only
those closest to the work really know how many other things are going on
at the same time.

Let's calm down and start again?  If someone lists a paper that someone
else has already read, that is not necessarily intended as an insult. 
There are other people (such as myself) who may need to read them.

We don't need to flame out here, as was mentioned earlier by (my mind is
going for names) the prof at Columbia.  Let's just all agree that the
issues are not trivial and that there are, almost always, trade offs. 
Let's also distinguish between practical and theoretical attacks.  (I'm
_not_ saying that this is either; I don't know enough about it yet to
say; I'm just saying, that's one consideration.)  I expect the ultimate
question is not whether, but when and how to make this improvement.

While I understand why it may be upsetting that this was not considered
before a major release, everyone knows there are extreme and competing
pressures for time when a major release is occurring.  That's water
under the bridge, so (and I can say this since I didn't do any work, but
it's still the right course of action) let's see if this can be handled
as an update without significant weakening of the stability of the
system.  Or, rather, how it can be done to make sure there is no
regression.  That takes testing, and testing takes time.

If it helps, I can set up an extra machine for stability testing, as I'm
sure a few thousand other people would also do if necessary.

-- 
Seth Kurtzberg
CQL.com
480-620-1099

CQL - The smallest footprint SQL engine for embedded applications, with
full transactional semantics, serializability, and guaranteed recovery
to the last committed transaction.