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