On Wed, Jul 31, 2013 at 03:24:07PM +0200, Michael Gmelin wrote:
> On Wed, 31 Jul 2013 08:10:28 -0500
> Mark Felder 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
On Wed, 31 Jul 2013 08:10:28 -0500
Mark Felder 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
>
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
On 07/31/13 08:48, Michael Gmelin wrote:
On Wed, 31 Jul 2013 08:18:51 -0400
Nikolai Lifanov wrote:
r253680 enables SSL certificate verification for "fetch" command.
Ports use "fetch" to download distfiles.
At least all USE_GITHUB fetches are broken on CURRENT, and others
might be too.
What i
On Wed, 31 Jul 2013 08:18:51 -0400
Nikolai Lifanov wrote:
> r253680 enables SSL certificate verification for "fetch" command.
> Ports use "fetch" to download distfiles.
>
> At least all USE_GITHUB fetches are broken on CURRENT, and others
> might be too.
>
> What is the correct/intended way to
r253680 enables SSL certificate verification for "fetch" command.
Ports use "fetch" to download distfiles.
At least all USE_GITHUB fetches are broken on CURRENT, and others might
be too.
What is the correct/intended way to handle master sites that use bad SSL
certificates?
Is there an intent
