From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1VWvMo-0000s8-FI for mharc-grub-devel@gnu.org; Thu, 17 Oct 2013 17:44:26 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41390) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VWvMh-0000rf-CD for grub-devel@gnu.org; Thu, 17 Oct 2013 17:44:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VWvMc-0004Tt-0M for grub-devel@gnu.org; Thu, 17 Oct 2013 17:44:19 -0400 Received: from mail-ee0-x22b.google.com ([2a00:1450:4013:c00::22b]:54626) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VWvMb-0004Tm-P6 for grub-devel@gnu.org; Thu, 17 Oct 2013 17:44:13 -0400 Received: by mail-ee0-f43.google.com with SMTP id e52so1465522eek.30 for ; Thu, 17 Oct 2013 14:44:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=IMY2TwpxlvyIWv7YhIkBsSyVkb2+4CH8lfmguJEjrpA=; b=YkbkMYM2vpj2Y57Scxx6n9gqqcEQIAKnA30qXXHt5zz1LnZYmqesixwpfoLoPQeX0A TswtxW20aMInRgKK0yS4K09QnGybEZYoHu4iQh5W1mTFfAFXC4KMwZ9cRe2b8WEe6stT cknqbXiUX17K3KBhpbnXwud05O8tOitCXkmFd0xpr/W7OSGHZVott1E43k8IhO5L2U7+ TnmTCene3NeU86exZgo2QUlnHsAqKoBiruq/W/QQms33xO56PhbaLaInCrKYoy7+jy3e 9QhFn/cF7x8RN/ZYqjxNv/EMSJT1jik5ToN1FjiQcOxt1vFeil6IkXj8Vfv3Lo+sDQj0 cy/Q== X-Received: by 10.15.35.196 with SMTP id g44mr15821917eev.18.1382046252853; Thu, 17 Oct 2013 14:44:12 -0700 (PDT) Received: from [192.168.42.243] (236-224.197-178.cust.bluewin.ch. [178.197.224.236]) by mx.google.com with ESMTPSA id bn13sm198121137eeb.11.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Oct 2013 14:44:12 -0700 (PDT) Message-ID: <52605A25.5040300@gmail.com> Date: Thu, 17 Oct 2013 23:44:05 +0200 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131005 Icedove/17.0.9 MIME-Version: 1.0 To: grub-devel@gnu.org Subject: Re: RFC: should the 'trust' and 'verify_detached' commands respect 'check_signatures=enforce'? References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="----enig2GJPLGPEMEKILPBOBIEMT" X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4013:c00::22b X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 21:44:24 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2GJPLGPEMEKILPBOBIEMT Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 17.10.2013 20:28, Jonathan McCune wrote: > Presently the 'trust' and 'verify_detached' commands disable all filter= s > (e.g., verify.c:grub_cmd_trust() calls grub_file_filter_disable_all()) > when opening a file containing a public key (note the distinction from > verify_detached implicitly using an already-loaded key). This is the intended behaviour. Usecase to manually add keys when needed. Your proposal is for other usecases which would probably require special arguments or separate functions. > This makes it > cumbersome to construct a public key hierarchy at boot time, by loading= > other signed public keys. To do this securely, the author of grub.cfg > would need to explicitly invoke 'verify_detached' (using an implicit > public key that was embedded in core.img using "grub-mkimage --pubkey")= > and check the return value before invoking 'trust'. >=20 > Arguments in favor of trust respecting 'check_signatures=3Denforce' (i.= e., > making a change): > * Consistency with behavior in nearly all other file-opening scenarios > when check_signatures=3Denforce > * Results in cleaner grub.cfg files >=20 > Arguments against (i.e., leaving things as-is): > * Desired functionality can already be obtained with appropriate script= > code in grub.cfg > * Makes it impossible (unless I'm missing something) to experiment with= > check_signatures=3Denforce without first providing a public key using t= he > --pubkey option to grub-mkimage (and presumably soon grub-install). > * Most users will never look at the C code but will see grub.cfg, and i= t > may be useful to put the public key validation logic right in front of > their eyes >=20 > As I mistakenly assumed that 'trust' *did* respect > 'check_signatures=3Denforce' upon first encountering this code, I tend = to > favor the position that this is the preferred functionality. I think > the right way to proceed is probably: (1) fix grub-install to support > --pubkey, (2) alter the behavior of 'trust' and 'verify_detached' to > respect 'check_signatures=3Denforce', and then (3) update the > documentation to make this clear. >=20 > As mentioned, the desired functionality can be obtained either way, so > as I currently understand things this is more a matter of aesthetics > than functionality. Note that grub.cfg files that manually validate > public keys before loading them would continue to behave correctly in > the face of these changes (though their validation efforts would be > redundant). >=20 > Best, > -Jon >=20 >=20 > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel >=20 ------enig2GJPLGPEMEKILPBOBIEMT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iF4EAREKAAYFAlJgWiUACgkQNak7dOguQglt0gEAr7x+ZkNu03pNLIuBaq4OsrfA YVxrk6YhDcw0o11zynIA/0mZR97aB5Yj7+ZJIeweIHqHYaCiEaaean+0lbMVYxdU =gBUg -----END PGP SIGNATURE----- ------enig2GJPLGPEMEKILPBOBIEMT--