From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marius Bakke Subject: Re: `guix pull` over HTTPS Date: Fri, 10 Feb 2017 23:43:45 +0100 Message-ID: <874m011xb2.fsf@kirby.i-did-not-set--mail-host-address--so-tickle-me> 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> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:56424) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ccJuy-0002vA-GC for guix-devel@gnu.org; Fri, 10 Feb 2017 17:43:53 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ccJuv-0006Lw-CG for guix-devel@gnu.org; Fri, 10 Feb 2017 17:43:52 -0500 In-Reply-To: <87inoh660r.fsf@gnu.org> 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: Ludovic =?utf-8?Q?Court=C3=A8s?= Cc: guix-devel@gnu.org --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ludovic Court=C3=A8s writes: > 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 we >>> should bundle =E2=80=98nss-certs=E2=80=99 in the binary tarball, which = is not exciting. >>> >>> Alternately we could have a package that provides only the Let=E2=80=99= s 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 ask >> SV admins. And also receive notices in advance if the key ever changes. >> >> Pinning the intermediate CAs might work, but what to do when the >> certificate is signed by a new intermediate (which may happen[0])? How >> 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-choos= e-to-implement/4625?source_topic_id=3D2450 > > All good points. Well, I guess there=E2=80=99s not much we can do? 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. 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. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEu7At3yzq9qgNHeZDoqBt8qM6VPoFAlieQiEACgkQoqBt8qM6 VPoJ/wgApKBcBZprDPcNgEIeALI+IfoK9qHvr2ywSuGGsFRIsa82OvJWonJso9Ec 9thVA0rKiShoshn2cU4VnEM8IrWHaL1ExvEgNnKvDCyGh2xUBx0SfX4y+CASpfZO CoBqXn4/nFi/iAylQ9KOxgQeEmsd2yUCVO/sief5YzNg9vMQarhH+OeYGbH1F6R7 cjM+FjBv2GzwAWHrSbvFIv1ahCIuwXnDNs88KKa6qLkHFLjkgAsPhgTnE5oBUdxi ZDwmBlz52Yb0/j24+aEgyATsDWuy66ghdtRDfLijVtxoKA9ejiHZbw/1hth0TmRm ah+C2Jnz7nty2+BBHhmGq1pP516dDA== =c3DG -----END PGP SIGNATURE----- --=-=-=--