Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 31 Jul 2013 15:24:07 +0200
From:      Michael Gmelin <freebsd@grem.de>
To:        Mark Felder <feld@FreeBSD.org>
Cc:        freebsd-ports@freebsd.org
Subject:   Re: r253680 in CURRENT breaks GH ports and maybe others
Message-ID:  <20130731152407.5d6a806e@bsd64.grem.de>
In-Reply-To: <1375276228.4960.3681111.005EA613@webmail.messagingengine.com>
References:  <831982af5f96759f17d21aba62b02eb6@mail.lifanov.com> <20130731144853.2a13617b@bsd64.grem.de> <51F90B8D.4030808@mail.lifanov.com> <1375276228.4960.3681111.005EA613@webmail.messagingengine.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 31 Jul 2013 08:10:28 -0500
Mark Felder <feld@FreeBSD.org> wrote:

> On Wed, Jul 31, 2013, at 8:05, Nikolai Lifanov wrote:
> > 
> > I fully agree. We already checksum the *distfiles*.
> > It shouldn't be important what the source is.
> > 
> > Are there any objections to adding --no-verify-peer to FETCH_ARGS
> > across the board?
> > 
> 
> Won't that break fetch for users whose fetch doesn't support
> --no-verify-peer?

True, it probably makes more sense to set SSL_NO_VERIFY_PEER in the
environment, since older versions of fetch will just ignore that.
bsd.port.mk already provides FETCH_ENV for that, so we could utilize
it for that purpose.

While you're on it you might also want to set SSL_NO_VERIFY_HOSTNAME
to disable host name verification in the cert (this is required less
often, but I could still see problems cause for incorrectly configured
master sites).

So this would mean adding something like this to bsd.port.mk around
line 2215:

FETCH_ENV?=	SSL_NO_VERIFY_PEER=1 SSL_NO_VERIFY_HOSTNAME=1

Michael


-- 
Michael Gmelin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130731152407.5d6a806e>