From mboxrd@z Thu Jan 1 00:00:00 1970 From: ng0 Subject: Re: `guix pull` over HTTPS Date: Fri, 10 Feb 2017 22:52:49 +0000 Message-ID: <20170210225249.ez2hrt4njfbntun6@wasp> References: <20170209155512.GA11291@jasmine> <20170210003054.GA12412@jasmine> <87fujmcb6w.fsf@gnu.org> <87lgte10eu.fsf@kirby.i-did-not-set--mail-host-address--so-tickle-me> <87inoh660r.fsf@gnu.org> <874m011xb2.fsf@kirby.i-did-not-set--mail-host-address--so-tickle-me> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:58190) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ccK24-0006Jf-M3 for guix-devel@gnu.org; Fri, 10 Feb 2017 17:51:13 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ccK21-00013X-0y for guix-devel@gnu.org; Fri, 10 Feb 2017 17:51:12 -0500 Content-Disposition: inline In-Reply-To: <874m011xb2.fsf@kirby.i-did-not-set--mail-host-address--so-tickle-me> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Marius Bakke Cc: guix-devel@gnu.org On 17-02-10 23:43:45, Marius Bakke wrote: > Ludovic Court=C3=A8s writes: >=20 > > Marius Bakke skribis: > > > >> Ludovic Court=C3=A8s writes: > >> > >>> Leo Famulari skribis: > >>> > > > > [...] > > > >>> Initially, I didn=E2=80=99t want to have =E2=80=98nss-certs=E2=80=99= in =E2=80=98%base-packages=E2=80=99 or > >>> anything like that, on the grounds that the whole X.509 CA story is > >>> completely broken IMO. I wonder if we should revisit that, on the > >>> grounds that =E2=80=9Cit=E2=80=99s better than nothing.=E2=80=9D > >>> > >>> The next question is what to do with foreign distros, and whether w= e > >>> should bundle =E2=80=98nss-certs=E2=80=99 in the binary tarball, wh= ich is not exciting. > >>> > >>> Alternately we could have a package that provides only the Let=E2=80= =99s Encrypt > >>> certificate chain, if that=E2=80=99s what Savannah uses. > >>> > >>> Thoughts? > >> > >> If the private key used on https://git.savannah.gnu.org/ is static, = one > >> option would be to "pin" the corresponding public key. However, some= LE > >> clients also rotate the private key when renewing, so we'd need to a= sk > >> SV admins. And also receive notices in advance if the key ever chang= es. > >> > >> Pinning the intermediate CAs might work, but what to do when the > >> certificate is signed by a new intermediate (which may happen[0])? H= ow > >> to deliver updates to users with old certs? > >> > >> See: https://www.owasp.org/index.php/Pinning_Cheat_Sheet and > >> https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning > >> > >> ..for quick and long introductions, respectively. > >> > >> [0] https://community.letsencrypt.org/t/hpkp-best-practices-if-you-c= hoose-to-implement/4625?source_topic_id=3D2450 > > > > All good points. Well, I guess there=E2=80=99s not much we can do? >=20 > I think pinning the public key could work, if the Savannah > administrators are aware of it. But we'd need a reliable fallback > mechanism in case the private key needs to be updated. >=20 > I think having a separate 'le-certs' package that can verify the Lets > Encrypt chain sounds like the easiest option. Presumably new > intermediates etc will be known well in advance. I am relatively sure that LE would let its now very large user base know in advance when a change like a new intermediate CA is being introduced, but if we are really in doubt we could ask LE themselves. --=20 ng0 -- https://www.inventati.org/patternsinthechaos/