mingw-cross-env-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Mingw-cross-env-list] Preparation of Release 2.21


From: Volker Grabsch
Subject: Re: [Mingw-cross-env-list] Preparation of Release 2.21
Date: Wed, 25 May 2011 14:48:51 +0200
User-agent: Mutt/1.5.20 (2009-06-14)

Tony Theodore schrieb:
> One other issue I noticed is that the freetds download from bitbucket
> redirects to a https download.

You are right. I just fixed it:

http://hg.savannah.gnu.org/hgweb/mingw-cross-env/rev/59eaac60953a

> On some systems (FreeBSD, OSX), wget
> fails to validate the certificate and needs a --no-check-certificate
> option or needs to be configured to look for the system certificate
> store.
> 
> Should we move this to a http only location,

No, that doesn't make much sense. Also note that we already do
perform downloads from HTTPS locations for version recognition
("make update") of packages freetds, gcc-mpc and gcc-mpfr.

Package freetds is the first one where the source download
itself it HTTPS, though.

> prepend the "--no-check-certificate" to the url,

I think this is the way to go. I just fixed our download mechanism
accordingly:

http://hg.savannah.gnu.org/hgweb/mingw-cross-env/rev/1433d27437ff

> or add notes to the docs about configuring wget?

This would be the "cleaner" solution, but I don't see why we
should make our users go through that trouble. I could do that
if all distros would configure wget correctly to recognize the
official SSL root certificates. But as long as the distros don't
do that, I don't see why we should demand this from our users.

It is also quite funny that the bitbucket HTTPS URL redirects
to an HTTP URL in the end, but we shouldn't use the latter
because it points directly into the CDN.

Also, we already do check download integrity via SHA1 checksums,
so I see it more as _our_ task to verify package integrity when
updating package versions and thus their checksums.

Finally, if we _really_ want to ensure package integrity, we
should do this end-to-end from the developer to us, i.e. check
GPG signatures rather than SSL certificates.


Greets,
Volker

-- 
Volker Grabsch
---<<(())>>---



reply via email to

[Prev in Thread] Current Thread [Next in Thread]