From owner-freebsd-ports@FreeBSD.ORG Wed Jul 31 13:24:10 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 55273C31 for ; Wed, 31 Jul 2013 13:24:10 +0000 (UTC) (envelope-from freebsd@grem.de) Received: from mail.grem.de (outcast.grem.de [213.239.217.27]) by mx1.freebsd.org (Postfix) with SMTP id 977E521BB for ; Wed, 31 Jul 2013 13:24:09 +0000 (UTC) Received: (qmail 91424 invoked by uid 89); 31 Jul 2013 13:24:08 -0000 Received: from unknown (HELO bsd64.grem.de) (mg@grem.de@194.97.158.66) by mail.grem.de with ESMTPA; 31 Jul 2013 13:24:08 -0000 Date: Wed, 31 Jul 2013 15:24:07 +0200 From: Michael Gmelin To: Mark Felder 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> X-Mailer: Claws Mail 3.9.1 (GTK+ 2.24.18; amd64-portbld-freebsd9.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 13:24:10 -0000 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 > > 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