Subject: Re: Microsoft: Closed source is more secure
From: Lynn Winebarger <>
Date: Sun, 6 May 2001 04:56:50 -0500

   I don't know if this is going off-topic or not.  Let's also keep in mind
I'm trying to answer the original question of "why isn't this used".  Giving
me all the reasons I'm wrong (while they may be valid and instructive to me)
is probably not so interesting to people on this list as looking at the question
of (a) "are these typical views", and (b) "if I design the most secure known
<x> application, how can I avoid being marginalized in the marketplace"
or similar.

On Thursday 03 May 2001 23:08, Stephen J. Turnbull wrote:
>     Lynn> I should be familiar with every line of source code for
>     Lynn> every package I run on the systems I maintain.  I should put
>     Lynn> security absolutely above features.
> Straw man. 
     Actually, I believe I've seen this view expressed before, but I may be
imagining remembering it. ["this view" being the double quoted one].  In my
more delusional moments, I may feel it's the right requirement.  It may have
been something in Vixie's cron build docs that said something along the
lines of "If saying 'su to root and type make' was enough to get you to
su to root and type make, you've got a security problem.  You should
look into it", where I saw the first sentence as an implication.

> If you really are interested in maintaining a secure
> effective mail operation, investing the time or money to become or
> hire a professional is the ante.  Otherwise I, for one, simply do not
> believe you are serious.

     Changing the financial situation is not directly within my power.
As for the time, it's a limited resource, and mail is far from the only
service I have to oversee.  I imagine we're not the only ones in this

> "They" _are_ out to get us.  I've been "got", so have many of my
> friends, including people running what they thought were "secure"
> operations.

    There are different gradations of "they".  "Secure" depends on the
analysis of the risks involved in a particular operation, and is not limited
to merely the source of a particular application.  I don't expect I'll ever run
machines with the security requirements of the military, NSA, or a major financial
institution.  My desire is simply to provide a reasonable level of confidentiality
while providing _necessary_ features, along with enough monitoring and 
record-keeping to pursue (legal) remedies if security is breached.  That's my
view on what security means.

> Your real complaint, however, seems to be that you can't get qmail
> levels of security plus the features you want cheaply by piggybacking
> on DJB's code.  As we get extremely high quality, plus features,
> through other (free) software.
> _But that has nothing to do with the license._  You couldn't get that
> anyway, even if it were a free license.  Security does not work that
> way; mix and match inherently implies much lower levels of reliability
> in the security domain than it does in others.  The "other side" is
> actively seeking exploits, so unity of design and implementation is
> much more important.
    No, you don't seem to understand.  Qmail's level of security is irrelevant
if it does not provide necessary features for the needs of the organization looking

at it.  Essentially, _it_ is a straw man of a sort.  If I have to choose between 2 
calculator programs, one of which provides only + and - but absolutely, positively
no exploits - and the other of which provides multiplication and division as well
- but likely some unknown exploits; I'd have to choose the latter and try to set
up external barriers or otherwise minimize the effects of the potential exploits.  Note
I left out the option of writing my own calculator program deliberately (writing a calculator
is significantly easier than writing a complete RFC-conformant mail system).
   Obviously qmail provides sufficient functionality to satisfy many purposes, so
this may seem an unfair comparison - I'm just trying to illustrate the point, though.
     And while I am cheap (attempt to provide cost-effective solutions is the nicer
way of putting it), if we had the money to hire outside parties to modify source code,
I would not choose qmail as the starting point unless we truly had boatloads of money
to throw at the problem.   And the license is the reason.  I'd instead start with a
piece of
free software, add the feature set  we need  (or some subset thereof) and redistribute
so others with similar needs could make adaptations and contribute them back (if they

wanted to).  It's a way for small organizations like the one I work for to informally

pool our resources.  And the license for qmail (in concert with the other factors I

mentioned originally) makes this a difficult thing to do.  As well as the infrequent
updates that would probably neither include these features (with contributed code)
or try to address them in other ways.  [given a piece of software with all the required
features but serious compromises, I'd consider contracting or doing some security
auditing, but it's an iffy thing since, as you mentioned, there may be inherent security
flaws in the design of the software].  And yes, this is still seeking free beer, but
it's not
_only_ seeking free beer.

> up to _any_ security-related criticisms.  Call it egotism if you like;
> it's his software (assuming you don't go down rms's `no such thing as
> IP' road) and he is welcome to put what restrictions on it he likes.

   I agree it's his software and he can do with it as he likes; I'm just not
inclined to invest or advise investing resources into it.  While qmail is no toy
program, the apparent interest in political goals gives me the same feeling
about it.  [The water is murky here because part of the political goal involves
providing a "reasonably" featureful mail program, which is the same way
academic toy programs get designed and written - specify a limited problem
domain and address it].  Without an effective way of getting a secondary 
(trusted, but not necessarily as much) source and a snowball effect, that 
makes me very wary.

PS - I'm not mailing from my work email address, if you're wondering.