From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id C3D58198005 for ; Fri, 15 Mar 2013 03:33:50 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 77238E06B3; Fri, 15 Mar 2013 03:33:42 +0000 (UTC) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 9F85EE065A for ; Fri, 15 Mar 2013 03:33:41 +0000 (UTC) Received: by mail-qa0-f42.google.com with SMTP id cr7so72015qab.15 for ; Thu, 14 Mar 2013 20:33:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; bh=n+XvezUiL8MFMZyIBs3YmTJ30KjndFlFkL6Ey7QKl6w=; b=ryhtnfHLlqUONpffCfphC+8oJCIeNVls4CkmKJ3bo76YwRU199QptkB8LD8Y3Jzgjr /YT3OJdKDQv76jgkOUZacgkcrohEKj7+NQ4JhqRoBxz81w2sfAQSDevBZy9WhyRjQOzY sLW2p5WiG/UoeqU6R3mPcigvGveG/5BVywyOgIQvVJBqGl6tAXupbuCKzOjgWQLaOhUB fYVn/CCYtTX23fLSY9F+rWrVBSVyX/kQ8i3EatVIu/4cyFPbbOyu6dV3jw6NlC/vyNTz fwIyKMGYVEegFmu1jz6rHsN2t9cPVPB5LAy8eS1TdtTQoyHEZPn280iILN/0SHNosLEF GGWQ== X-Received: by 10.224.180.15 with SMTP id bs15mr4220054qab.24.1363318420786; Thu, 14 Mar 2013 20:33:40 -0700 (PDT) Received: from ?IPv6:2001:5c0:1000:a::ff5? ([2001:5c0:1000:a::ff5]) by mx.google.com with ESMTPS id t7sm1364388qey.2.2013.03.14.20.33.39 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Mar 2013 20:33:40 -0700 (PDT) Message-ID: <51429690.6060802@gmail.com> Date: Thu, 14 Mar 2013 23:33:36 -0400 From: Michael Mol User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130222 Thunderbird/17.0.2 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] RFC: Gentoo GPG key policies References: <20130227161214.4bfde7e9@mygoo.lnet> <20130314091252.GF27080@orbis-terrarum.net> <5141EC0C.6090108@gentoo.org> <20130314171415.525323a2@pomiocik.lan> <5142883E.6080006@gmail.com> In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2IWKKQGGGWVTJFIJUVVEH" X-Archives-Salt: 93ee857c-4b2d-459d-bdfe-a65275c4e05c X-Archives-Hash: 5b10a1ee8eacaddc6bbe36dcf81dbe25 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2IWKKQGGGWVTJFIJUVVEH Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 03/14/2013 11:18 PM, Robin H. Johnson wrote: > On Thu, Mar 14, 2013 at 10:32:30PM -0400, Michael Mol wrote: >>> As to how to accomplish this, it's either a throwaway sig, or poking = the >>> agent protocol directly. >> The only trouble with that is if the agent is configured to only unloc= k >> keys for limited periods of time, then your initial check might catch >> the agent when the key is still unlocked, but your subsequent call to >> GPG comes after the timeout. I ran into this while trying to set up >> automated signing of debian packages I was building. > So Debian has a test-gpg function already? Do you know where in their > codebase it is? No idea; a build system I'd cobbled together at the time prodded gpg-agent to get an interactive auth. The build-and-package step took too long, leading to the timeout. And I apologize; I don't remember exactly what I was doing to prod gpg-agent, and since it was for a prior job, I did not retain any copies of any of the materials. >=20 >> All it really means, in a practical procedural sense, is that you need= >> to allow yourself a way to roll back anything you've been doing if tha= t >> later check fails. > I think we'd do: > - All repoman checks > - initial file editing > if two-phase commit: > - test gpg > - commit1 > - gpg sign > - commit2 > if one-phase commit: > - gpg test > - gpg sign > - commit1 >=20 > Unless commit1 took a really long time, the interval between the gpg > calls should be very small. >=20 Murphy's going to call in a long I/O hang somewhere. Race conditions are hell manifest in systems. Since I haven't been paying close attention to this thread, I'm missing some context, but if you're commit1 and commit2 apply to a DVCS, you're probably fine so long as you don't do a push between commit1 and commit2, don't do a push if any earlier step failed, and do all this in a temporary branch that never (as a branch) gets pushed upstream. If you're not applying to a DVCS, then you risk interleaving commit1 and commit2 with others' work anyway. ------enig2IWKKQGGGWVTJFIJUVVEH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRQpaSAAoJED5TcEBdxYwQopQH/jpwR2Zm0/IVI9iY87AgtSjc aEhNDPLp/iw8H/o4YDP9f8WFEvxtbrX3ndPKr5yRCJdbo566whU9P8j7MpsQ9iOX PckVJbLBKSpRK/ogQyHGtUx9BHLbbY259xerS6kwS+SWt+7tk000K3NBdq6L/Y/p ZW1bVrHbY/Z9Z2Cr1nnad7dv6jY8QqSJvOoy8ZgcbYOjZdL6E4ySilTWzpsI2luM 5tqS91uKqhZw/bYcscpNeSOUaq+TiY0XSW6J/96Fioc6Nk0qa/LUe87ggLKZe8ws BXklUEGFyJu/XDwH1dBC1n5SlVb7xc6nFkSA0YbfcxvZTJtCMYEvpdkdW7BdW5I= =m/St -----END PGP SIGNATURE----- ------enig2IWKKQGGGWVTJFIJUVVEH--