Re: cygwin Digest 16 Mar 2010 19:15:45 -0000 Issue 6926

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: cygwin Digest 16 Mar 2010 19:15:45 -0000 Issue 6926

G.W. Haywood
Hi there,

On Tue, 16 Mar 2010 [hidden email] wrote:

> > Perhaps the MD5 and/or SHA1 checksums for the current setup.exe should
> > be published (and updated every time there's a new release) next to
> > the download link (like Apache does, for example)
>
> It is however a very highly-desirable goal.  I'll try and find some round
> tuits to see if we can't get some traction.

That would be a very acceptable alternative to my original suggestion
of renaming setup.exe each time it's (re)released, even if it's a bit
more work for you. :(  Thanks.

--

73,
Ged.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

Re: incomplete/corrupted setup.exe

Christopher Faylor-8
On Wed, Mar 17, 2010 at 10:45:47AM +0000, G.W. Haywood wrote:

>On Tue, 16 Mar 2010 Csaba Raduly wrote:
>>>Perhaps the MD5 and/or SHA1 checksums for the current setup.exe should
>>>be published (and updated every time there's a new release) next to the
>>>download link (like Apache does, for example)
>>
>>It is however a very highly-desirable goal.  I'll try and find some
>>round tuits to see if we can't get some traction.
>
>That would be a very acceptable alternative to my original suggestion
>of renaming setup.exe each time it's (re)released, even if it's a bit
>more work for you.  :( Thanks.

To be clear, while Dave does seem to be implying that he has the ability
to make this happen, this really is basically my decision and the
decision of the other people who maintain the site, i.e., not Dave.  Any
actual work involved would likely be done by me.

I've floated the idea about getting a certificate to allow https access
to my fellow overseers and was largely met with yawns.  All of them are
involved with other significant projects hosted on sourceware.org and
have not noticed a need for this.

Since I haven't seen any guarantees that adding https would fix this
problem I'm not convinced that this justifies the amount of work
involved.  So, until the mailing list is flooded with people who can't
download setup.exe because we don't have https access, I am satisfied
with not doing anything.

cgf

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

Re: incomplete/corrupted setup.exe

G.W. Haywood
Hi there,

On Wed, 17 Mar 2010 cgf wrote:

> On Wed, Mar 17, 2010 at 10:45:47AM +0000, G.W. Haywood wrote:
> >On Tue, 16 Mar 2010 Csaba Raduly wrote:
> >>>Perhaps the MD5 and/or SHA1 checksums for the current setup.exe should
> >>>be published (and updated every time there's a new release) next to the
> >>>download link (like Apache does, for example)
> >
> >That would be a very acceptable alternative to my original suggestion
> >of renaming setup.exe each time it's (re)released, even if it's a bit
> >more work for you.  :( Thanks.
>
> To be clear ... until the mailing list is flooded with people who
> can't download setup.exe because we don't have https access, I am
> satisfied with not doing anything.

In the interests of further clarity, all I've really been asking for
is a way for people to know exactly what they're downloading when they
click the download link.  The fact that some caching proxies might be
fooled into doing something less unhelpful than normal would just be
an incidental bonus.  I agree that the idea of using https would seem
to be overkill, and in any case it doesn't address other issues which
are covered if you publish the md5sums of each release.  When there's
a way to verify the file contents, files can if necessary be sent by
email to people who have trouble downloading.

--

73,
Ged.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

Re: incomplete/corrupted setup.exe

Steven Monai-5
In reply to this post by Christopher Faylor-8
On 2010/03/17 8:06 AM, Christopher Faylor wrote:
> Since I haven't seen any guarantees that adding https would fix this
> problem I'm not convinced that this justifies the amount of work
> involved.  So, until the mailing list is flooded with people who can't
> download setup.exe because we don't have https access, I am satisfied
> with not doing anything.

That's too bad. Using SSL would nearly eliminate the risk of a MITM
delivering a bogus setup.exe in place of the real thing to some
unsuspecting user.

As an alternative to setting up SSL on cygwin.com, what about the idea
of crypto-signing (e.g. with gnupg) every release of setup.exe, and then
posting the signature alongside the binary? I know I would breathe a
little easier if I were able to positively verify the authenticity of a
given setup.exe binary.

The public key would need to be distributed via channels other than just
cygwin.com, to make it more difficult to spoof. Fortunately, there are a
number of public PGP/GPG key servers to fill that purpose.

-SM
--

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

Re: incomplete/corrupted setup.exe

Christopher Faylor-8
On Wed, Mar 17, 2010 at 05:58:07PM -0700, Steven Monai wrote:

>On 2010/03/17 8:06 AM, Christopher Faylor wrote:
>> Since I haven't seen any guarantees that adding https would fix this
>> problem I'm not convinced that this justifies the amount of work
>> involved.  So, until the mailing list is flooded with people who can't
>> download setup.exe because we don't have https access, I am satisfied
>> with not doing anything.
>
>That's too bad. Using SSL would nearly eliminate the risk of a MITM
>delivering a bogus setup.exe in place of the real thing to some
>unsuspecting user.
>
>As an alternative to setting up SSL on cygwin.com, what about the idea
>of crypto-signing (e.g. with gnupg) every release of setup.exe, and then
>posting the signature alongside the binary? I know I would breathe a
>little easier if I were able to positively verify the authenticity of a
>given setup.exe binary.
>
>The public key would need to be distributed via channels other than just
>cygwin.com, to make it more difficult to spoof. Fortunately, there are a
>number of public PGP/GPG key servers to fill that purpose.

Oh.  Are we still talking about this?  I drifted off.

Somebody please wake me when all of this tempest in a bikeshed is over.

cgf

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

Re: incomplete/corrupted setup.exe

Steven Monai-5
On 2010/03/17 6:54 PM, Christopher Faylor wrote:
> Oh.  Are we still talking about this?  I drifted off.
>
> Somebody please wake me when all of this tempest in a bikeshed is over.

I don't understand the reason for the dismissive attitude.

Pretty much every other distro posts cryptographic hashes and/or
signatures with their binary downloads, so users can verify the
correctness and authenticity of downloaded files. Why doesn't Cygwin do
this?

-SM
--

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

Re: incomplete/corrupted setup.exe

Dave Korn-6
In reply to this post by Steven Monai-5
On 18/03/2010 00:58, Steven Monai wrote:

> As an alternative to setting up SSL on cygwin.com, what about the idea
> of crypto-signing (e.g. with gnupg) every release of setup.exe, and then
> posting the signature alongside the binary? I know I would breathe a
> little easier if I were able to positively verify the authenticity of a
> given setup.exe binary.

  That much is already done, and documented on the front page of cygwin.com:
read the first sentence under "Installing and Updating Cygwin and its
Packages" heading just beneath the mid-bar, or go straight to
http://cygwin.com/setup.exe.sig

> The public key would need to be distributed via channels other than just
> cygwin.com, to make it more difficult to spoof. Fortunately, there are a
> number of public PGP/GPG key servers to fill that purpose.

  And we have already uploaded it to them; DSA key ID 676041BA:

http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0xA9A262FF676041BA

    cheers,
      DaveK


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

Re: incomplete/corrupted setup.exe

Gregg Levine
On Thu, Mar 18, 2010 at 1:28 AM, Dave Korn <*****************> wrote:

> On 18/03/2010 00:58, Steven Monai wrote:
>
>> As an alternative to setting up SSL on cygwin.com, what about the idea
>> of crypto-signing (e.g. with gnupg) every release of setup.exe, and then
>> posting the signature alongside the binary? I know I would breathe a
>> little easier if I were able to positively verify the authenticity of a
>> given setup.exe binary.
>
>  That much is already done, and documented on the front page of cygwin.com:
> read the first sentence under "Installing and Updating Cygwin and its
> Packages" heading just beneath the mid-bar, or go straight to
> http://cygwin.com/setup.exe.sig
>
>> The public key would need to be distributed via channels other than just
>> cygwin.com, to make it more difficult to spoof. Fortunately, there are a
>> number of public PGP/GPG key servers to fill that purpose.
>
>  And we have already uploaded it to them; DSA key ID 676041BA:
>
> http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0xA9A262FF676041BA
>
>    cheers,
>      DaveK
>
> --

Hello!
George, I am certainly not the individual behind the list, I am just
another user of this most excellent system as you are. That being
said, (Oh and thank you Dave for stating that.) would that be enough
for your school to stop blacklisting the setup program for Cygwin?

I firmly believe that something did happen in the past to frustrate
and confuse the people behind you in the school you are working from.
That's why they did that, and I agree it makes less sense to me as
well.

So given that excellent decision on someone's part, can we consider
this subject closed, before CGF gets really annoyed?
-----
Gregg C Levine [hidden email]
"This signature fought the Time Wars, time and again."

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

Re: incomplete/corrupted setup.exe

Dave Korn-6
In reply to this post by Christopher Faylor-8
On 17/03/2010 15:06, Christopher Faylor wrote:

> To be clear, while Dave does seem to be implying that he has the ability
> to make this happen, this really is basically my decision and the
> decision of the other people who maintain the site, i.e., not Dave.  Any
> actual work involved would likely be done by me.

  Ah, well, I was going to ask Dan B. if he was still willing to do the basic
legwork, as he did once offer to set it up for gcc.gnu.org and they are after
all the same machine.(*)  He was talking in the context of providing
svn-over-https, but I inferred that would mean enabling SSL on the http daemon
as part of the setup, and we could have piggy-backed secure downloads of
setup.exe off of that.

    cheers,
      DaveK
--
(*) - http://sourceware.org/ml/overseers/2007-q3/msg00140.html

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

Re: incomplete/corrupted setup.exe

Christopher Faylor-8
On Thu, Mar 18, 2010 at 05:35:17AM +0000, Dave Korn wrote:

>On 17/03/2010 15:06, Christopher Faylor wrote:
>>To be clear, while Dave does seem to be implying that he has the
>>ability to make this happen, this really is basically my decision and
>>the decision of the other people who maintain the site, i.e., not Dave.
>>Any actual work involved would likely be done by me.
>
>Ah, well, I was going to ask Dan B.  if he was still willing to do the
>basic legwork, as he did once offer to set it up for gcc.gnu.org and
>they are after all the same machine.(*) He was talking in the context
>of providing svn-over-https, but I inferred that would mean enabling
>SSL on the http daemon as part of the setup, and we could have
>piggy-backed secure downloads of setup.exe off of that.

Dan isn't really associated with sourceware that much anymore.  He's
basically moved on to other things.

cgf

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

Re: incomplete/corrupted setup.exe

Warren Young
In reply to this post by Steven Monai-5
On 3/17/2010 9:05 PM, Steven Monai wrote:
> On 2010/03/17 6:54 PM, Christopher Faylor wrote:
>> Oh.  Are we still talking about this?  I drifted off.
>>
>> Somebody please wake me when all of this tempest in a bikeshed is over.
>
> I don't understand the reason for the dismissive attitude.

Your proposed solutions don't really work.  They're crutches which may
help in some cases, but they don't absolutely and finally fix the
problem.  Therefore you're proposing that someone else do work on a
"maybe".  Why are you surprised when he says "no"?

Re the idea that SSL will defeat brain-dead and broken proxies: only the
most brain-dead among them.  Corporate filtering proxies are often set
up to unwrap SSL at the proxy then re-sign the outbound request; they
see the plaintext request.  Such things aren't common at the low end
because it requires adding the proxy as a trusted CA to every SSL using
program on the system, but it's common enough.

Re MITM mitigation: If that's what you're trying to guard against, how
does putting hashes on a non-HTTPS web page help?  A MITM could modify
the hashes in transit just as well as he could modify setup.exe.

Re the MITM risk to begin with: is this actually happening, or are we
just speculating here?  I pay some attention to security issues, and
haven't seen any reports of random in-flight exes over HTTP being
replaced by a MITM with malware.  Could it be done?  Of course.  But
*is* it, and with what frequency?

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

Re: cygwin Digest 16 Mar 2010 19:15:45 -0000 Issue 6926

George Barrick
In reply to this post by G.W. Haywood

                       2010.03.18.16:13:51 UT

Hi Gregg and CygWin folks,

      I found the PGP/GPG key, and confirmed
the validity of the setup.exe.

      As for the blocking, my college hires
Cymphonix to do this for them, and then the
college Information Svces. guys stay com-
pletely away from any issues that arise.
Frustrated or confused?  I'm not entirely
convinced that their security-besotted brains
contain enough neurons for that kind of
processing.  They would say that they neither
block nor un-block anything.  It is up to
Cymphonix.

The IS guys gave me the address for the Cymphonix
group, and I had to e-mail those people for a
couple of days before they decided to un-block
the http://cygwin.com/setup.exe link.

Cymphonix apparently does not wish to deal with
actual customers.  They never replied to my
e-mails; just un-blocked the link.

I am now better informed about what awaits me
on the wild, wild frontier of the internet.
The issue (and these threads) is well and
thoroughly closed.

George                    [hidden email]



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

Re: incomplete/corrupted setup.exe

George Barrick
In reply to this post by Christopher Faylor-8

                       2010.03.18.16:13:51 UT

Hi Gregg and CygWin folks,

      I found the PGP/GPG key, and confirmed the validity of the setup.exe.

      As for the blocking, my college hires Cymphonix to do this for them, and then the college Information Svces. guys stay com- pletely away from any issues that arise.
Frustrated or confused?  I'm not entirely convinced that their security-besotted brains contain enough neurons for that kind of processing.  They would say that they neither block nor un-block anything.  It is up to Cymphonix.

The IS guys gave me the address for the Cymphonix group, and I had to e-mail those people for a couple of days before they decided to un-block the http://cygwin.com/setup.exe link.

Cymphonix apparently does not wish to deal with actual customers.  They never replied to my e-mails; just un-blocked the link.

I am now better informed about what awaits me on the wild, wild frontier of the internet.
The issue (and these threads) is well and thoroughly closed.

George                    [hidden email]



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

Re: incomplete/corrupted setup.exe

Steven Monai-5
In reply to this post by Dave Korn-6
On 2010/03/17 10:28 PM, Dave Korn wrote:

> On 18/03/2010 00:58, Steven Monai wrote:
>
>> As an alternative to setting up SSL on cygwin.com, what about the idea
>> of crypto-signing (e.g. with gnupg) every release of setup.exe, and then
>> posting the signature alongside the binary? I know I would breathe a
>> little easier if I were able to positively verify the authenticity of a
>> given setup.exe binary.
>
>   That much is already done, and documented on the front page of cygwin.com:
> read the first sentence under "Installing and Updating Cygwin and its
> Packages" heading just beneath the mid-bar, or go straight to
> http://cygwin.com/setup.exe.sig

Ah, there it is. I don't know how I managed to miss that.

>> The public key would need to be distributed via channels other than just
>> cygwin.com, to make it more difficult to spoof. Fortunately, there are a
>> number of public PGP/GPG key servers to fill that purpose.
>
>   And we have already uploaded it to them; DSA key ID 676041BA:
>
> http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0xA9A262FF676041BA

Fantastic! Thanks.

-SM
--

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

Re: incomplete/corrupted setup.exe

Steven Monai-5
In reply to this post by Warren Young
On 2010/03/18 8:38 AM, Warren Young wrote:
> Your proposed solutions don't really work.

I disagree. Granted, they are not 100% effective, but since when is
perfection the standard by which all solutions are judged?

> They're crutches which may
> help in some cases, but they don't absolutely and finally fix the
> problem.

So? Mitigating a problem means that fewer people will experience that
problem. Provided that a significant proportion of the cases experience
some mitigation, it can be worth implementing even an "imperfect" solution.

> Therefore you're proposing that someone else do work on a
> "maybe".

Jeez. A guy can't throw ideas out here without people assuming they're
demands for action. I was looking for a discussion of the relative
merits of a few ideas.

> Why are you surprised when he says "no"?

I wasn't surprised.

> Re the idea that SSL will defeat brain-dead and broken proxies: only the
> most brain-dead among them.  Corporate filtering proxies are often set
> up to unwrap SSL at the proxy then re-sign the outbound request; they
> see the plaintext request.  Such things aren't common at the low end
> because it requires adding the proxy as a trusted CA to every SSL using
> program on the system, but it's common enough.

Are most proxies proxying HTTPS? What proportion of them do? If a
significant proportion do not, then using HTTPS can still benefit a
great number of users, and it may be worth implementing (especially
since HTTPS has other nice properties).

> Re MITM mitigation: If that's what you're trying to guard against, how
> does putting hashes on a non-HTTPS web page help?  A MITM could modify
> the hashes in transit just as well as he could modify setup.exe.

I don't believe I proposed hashes on their own as a defense against
MITM. I proposed signatures and/or authenticated transports (HTTPS) for
that. Hashes can still be useful for verifying that a downloaded file is
corrupt. The OP of this thread could have used a hash to verify that his
file was bad, for example.

> Re the MITM risk to begin with: is this actually happening, or are we
> just speculating here?  I pay some attention to security issues, and
> haven't seen any reports of random in-flight exes over HTTP being
> replaced by a MITM with malware.  Could it be done?  Of course.  But
> *is* it, and with what frequency?

Good questions. I don't think there are any credible statistics on this,
since it is very difficult to define and measure. The fact that MITM is
feasible in several common scenarios is enough to warrant looking at
simple mitigation techniques. If (some combination of) the techniques
aren't too expensive when weighed against the potential risks, then they
ought to be implemented.

The intended use-case of setup.exe---namely, to download and run it from
cygwin.com every time you want to use it---is especially vulnerable to a
targeted MITM attack, since it affords the attacker any number of
opportunities to deliver you an evil setup.exe. If an attacker knows
you're a Cygwin user, and he's in a position to act as a MITM between
you and cygwin.com at least some of the time, then you'd better
carefully check every setup.exe you download before you run it.

Cygwin has already implemented signatures for setup.exe (yes, I
completely missed that before; Dave K. set me straight), and that is a
very good thing.

Detecting a MITM isn't the only problem to deal with when downloading
files. Knowing when your file is truncated or otherwise corrupted---for
any reason, not just malice---is also a good thing.

Thinking about it some more, bypassing a web filter (regardless of
whether it is well- or ill-configured) is probably not a goal to strive
for. It is better to give the user some way of verifying whether the
file he got is actually the file that Cygwin intended to deliver.
Signatures fully cover that need, and hashes are a less expensive
partial measure. HTTPS would make it simpler for more users to trust the
files they do get, since verifying signatures requires additional
knowledge and software that relatively few people actually have.
Obviously, I'm not going to hold my breath waiting for HTTPS to appear
on cygwin.com, but there is no disputing that it would improve the
security of downloads.

Best regards,
-SM
--

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

Re: incomplete/corrupted setup.exe

Christopher Faylor-8
Can we please shut this discussion down?  The person who had the initial
problem is satisfied and I've made it clear that no one at
sourceware.org/cygwin.com is interested in pursuing additional web site
measures.  While that could change at some point in the past, it is not
going to do so because the internet voices tell us to do it here in this
list.

Also, this is starting to drift off-topic anyway since this is not the
place to discuss theories of internet security.  I'm 100% certain that
there are better forums for that than this mailing list.

cgf

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

Re: incomplete/corrupted setup.exe

Christopher Faylor-8
Sigh.
On Fri, Mar 19, 2010 at 02:07:33AM -0400, Christopher Faylor wrote:
>Can we please shut this discussion down?  The person who had the initial
>problem is satisfied and I've made it clear that no one at
>sourceware.org/cygwin.com is interested in pursuing additional web site
>measures.  While that could change at some point in the past, it is not
                                                         future

cgf

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

Re: incomplete/corrupted setup.exe

G.W. Haywood
In reply to this post by Christopher Faylor-8
Hi there,

On Thu, 18 Mar 2010 Steven Monai wrote:
>
> On 2010/03/17 6:54 PM, Christopher Faylor wrote:
>
> > Oh.  Are we still talking about this?  I drifted off.
> > Somebody please wake me when all of this tempest in a bikeshed is over.
>
> I don't understand the reason for the dismissive attitude.

You either have to get used to dealing with the attitude, or, in this
case I'm afraid, find a different list.  If you find one, let me know. :)

For the record, the point about this bikeshed discussion is which
particular bike we choose to take out of it.

The point it not whether somebody fiddled with the brakes before we
got our hands on it, and not whether the handlebars will go through
the door.  Those issues are either already dealt with, or secondary.

--

73,
Ged.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple