include SHA1/MD5 hash/digest of setup.exe, and use HTTPS

[Ryan Johnson]

tl;dr: publishing a checksum for setup.exe is a good idea, https makes 
little or no sense in this setting, and cryptographic signatures for 
packages would be nice to have but would burden volunteers while 
providing incomplete protection.

(response follows)

On 26/09/2012 2:22 AM, Bry8 Star wrote:
> Please include SHA1/MD5 hash/digest code of "setup.exe" file, on webpage
> next to "setup.exe" download url-link.
Providing a digest for setup.exe is probably a good idea, and probably 
not too hard.

> so we know for sure, if we have a correct file or not, and someone in
> middle (MITM) has not changed it.
>
> Windows users prefer to verify files rather with sha1/md5 etc, than
> using asc, as asc verification is more complicated.
Cygwin packages already provide MD5 signatures, but those only really  
protect against accidental corruption during the download [1]. ASC would 
provide a bit more protection [2], but it's apparently too inconvenient 
for you to use. This is good, because it would be severely inconvenient 
for cygwin devs and package maintainers to provide it to you.

> please distribute the setup.exe, via using a HTTPS based URL/site.
Why do want https? There are exactly zero bytes of sensitive traffic to 
protect, and attackers would still know you're visiting the site (use a 
VPN to prevent that).

> No need for a paid/purchased SSL/TLS certificate. A self-signed or
> CAcert or other free cert (various cert providers have free cert for
> non-profit or open-source developers), is more than enough & suffice.
> Much much better than using no encryption at all.
A self-signed certificate provides a dangerous false sense of security 
when verifying site identity [3]; no certificate can protect you from a 
hacked cygwin.com (should that ever occur), nor from malicious 
developers and package maintainers (c.f. [2]). The encryption aspect of 
https is irrelevant because no sensitive information is exchanged.

> Does the "setup.exe" connect to Internet/mirror sites using https or
> SSL/TLS encrypted connections ?
It makes no sense for mirrors to provide https [4], and most probably 
couldn't even if they wanted to.

$0.02
Ryan

[1] There are good technical reasons why setup.exe will never pull 
checksums for mirrored packages from cygwin.com, so forget that idea. 
Further, several recent collision attacks have shown MD5 to be utterly 
broken when an attacker wants it to be (SHA-1 might be better, I don't 
remember).

[2] Cryptographic signatures would prevent mirrors from tampering with 
packages after release, but do nothing to establish trust in the myriad 
volunteers who write the software and compile the packages in the first 
place. I seriously doubt RedHat would open itself to liability by 
vouching for the identity or character of non-employees.

[3] An attacker willing/able to spoof your DNS will be perfectly capable 
of providing a convincing self-signed certificate as well. They might 
even provide a "proper" certificate, in light of recent attacks on 
gmail, et al.

[4] A mirror needs only to provide unmodified copies of packages; 
cryptographic signatures are both necessary and sufficient to achieve 
that goal. It doesn't matter who (or how malevolent) the mirror operator 
is as long as the signatures check out.


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