Re: [gentoo-dev] repoman commit unexpectedly drops FEATURES=sign on error
Dnia 2013-06-22, o godz. 17:02:56 Paweł Hajdan, Jr. phajdan...@gentoo.org napisał(a): On 6/20/13 2:16 AM, Michał Górny wrote: Doing test signatures won't cover all failures. Do you know an example? The only one I'm aware of is when a test signature is made very close to the expiration date, and then the real signature would be done after it. Well, Michael explained one in the other branch of this thread quite thoroughly. Other than that, there can be random runtime errors and race conditions. I'd say it's as good as using stat() to check whether a file exists before opening it. But thinking of it, I've got another idea... How about opening 'gpg -s' in a subprocess before first commit and feeding the Manifest afterwards? As far as I can see, gpg asks for the password instantly, so likely most of the bases will be covered already, and we're be doing a single signature only. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] repoman commit unexpectedly drops FEATURES=sign on error
On 06/23/2013 01:19 AM, Michał Górny wrote: Dnia 2013-06-22, o godz. 17:02:56 Paweł Hajdan, Jr. phajdan...@gentoo.org napisał(a): On 6/20/13 2:16 AM, Michał Górny wrote: Doing test signatures won't cover all failures. Do you know an example? The only one I'm aware of is when a test signature is made very close to the expiration date, and then the real signature would be done after it. Well, Michael explained one in the other branch of this thread quite thoroughly. Other than that, there can be random runtime errors and race conditions. I'd say it's as good as using stat() to check whether a file exists before opening it. But thinking of it, I've got another idea... How about opening 'gpg -s' in a subprocess before first commit and feeding the Manifest afterwards? As far as I can see, gpg asks for the password instantly, so likely most of the bases will be covered already, and we're be doing a single signature only. The only problem I see is that repoman will have no way of knowing when you have finished typing the pass phrase (if not using gpg-agent). So, there may be some mixing of repoman and gpg/pinentry output in the terminal. -- Thanks, Zac
Re: [gentoo-dev] repoman commit unexpectedly drops FEATURES=sign on error
On 6/20/13 2:16 AM, Michał Górny wrote: Doing test signatures won't cover all failures. Do you know an example? The only one I'm aware of is when a test signature is made very close to the expiration date, and then the real signature would be done after it. IMHO the best thing to do would be to drop CVS keywords and let repoman do normal commits instead of this two-step thing. But some of the devs really prefer to keep them, at least until we migrate to git and have better ways of e.g. checking the file version. Right, I found that it's used at least for prefix. I'm fine with waiting until git migration - looks like that would solve it naturally. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] repoman commit unexpectedly drops FEATURES=sign on error
On 06/20/2013 05:27 AM, Zac Medico wrote: On 06/19/2013 08:25 PM, Zac Medico wrote: On 06/19/2013 07:59 PM, Paweł Hajdan, Jr. wrote: I was surprised by repoman just dropping FEATURES=sign . I'm aware that at that time it has to commit an updated Manifest to prevent breakages, so if gpg fails it proceeds, but is there something it could do to check gpg sanity before committing anything? Failing at the password prompt (two chances on regular pinentry) also results in this behaviour. It seems the simplest way to go would be to do a test signature before commit, as suggested here: https://bugs.gentoo.org/show_bug.cgi?id=298605 Is it okay to assume that everyone uses gpg-agent, so they won't have to enter the passphrase more than once? I have a remote (ssh) test-box to work on the tree, I don't want to cache my decrypted key there. Having the crypted version there is bad enough, but GPG_AGENT protocol only exchanges passwords (unlike SSH_AGENT). GPG_AGENT forwarding over SSH can be done with a general unix domain socket forwading hack [1]. Or, we could skip the test signature if the GPG_AGENT_INFO variable is not set? It's a clue, but the key-cache can be expired and a bad password entry can still result in failure. [1] http://25thandclement.com/~william/projects/streamlocal.html -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber x...@gentoo.org
Re: [gentoo-dev] repoman commit unexpectedly drops FEATURES=sign on error
Dnia 2013-06-19, o godz. 19:59:08 Paweł Hajdan, Jr. phajdan...@gentoo.org napisał(a): I was surprised by repoman just dropping FEATURES=sign . I'm aware that at that time it has to commit an updated Manifest to prevent breakages, so if gpg fails it proceeds, but is there something it could do to check gpg sanity before committing anything? I'm pretty sure this was discussed already, either here or on bugzie. Doing test signatures won't cover all failures. IMHO the best thing to do would be to drop CVS keywords and let repoman do normal commits instead of this two-step thing. But some of the devs really prefer to keep them, at least until we migrate to git and have better ways of e.g. checking the file version. -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] repoman commit unexpectedly drops FEATURES=sign on error
Today an interesting thing happened to my repoman, as I was committing a change: Creating Manifest for /home/ph/gentoo-x86/dev-lang/v8 gpg: no default secret key: Unusable secret key gpg: /home/ph/gentoo-x86/dev-lang/v8/Manifest: clearsign failed: Unusable secret key !!! !!! gpg exited with '2' status !!! Disabled FEATURES='sign' /var/cvsroot/gentoo-x86/dev-lang/v8/Manifest,v -- Manifest new revision: 1.321; previous revision: 1.320 Indeed my private key on that machine was expired: pub 1024D/30427902 2009-08-05 [expired: 2013-06-10] But after refreshing it (I have extended the expiration date) it is fine: pub 1024D/30427902 2009-08-05 [expires: 2014-02-10] I was surprised by repoman just dropping FEATURES=sign . I'm aware that at that time it has to commit an updated Manifest to prevent breakages, so if gpg fails it proceeds, but is there something it could do to check gpg sanity before committing anything? Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] repoman commit unexpectedly drops FEATURES=sign on error
On 06/19/2013 07:59 PM, Paweł Hajdan, Jr. wrote: I was surprised by repoman just dropping FEATURES=sign . I'm aware that at that time it has to commit an updated Manifest to prevent breakages, so if gpg fails it proceeds, but is there something it could do to check gpg sanity before committing anything? It seems the simplest way to go would be to do a test signature before commit, as suggested here: https://bugs.gentoo.org/show_bug.cgi?id=298605 Is it okay to assume that everyone uses gpg-agent, so they won't have to enter the passphrase more than once? -- Thanks, Zac
Re: [gentoo-dev] repoman commit unexpectedly drops FEATURES=sign on error
On 06/19/2013 08:25 PM, Zac Medico wrote: On 06/19/2013 07:59 PM, Paweł Hajdan, Jr. wrote: I was surprised by repoman just dropping FEATURES=sign . I'm aware that at that time it has to commit an updated Manifest to prevent breakages, so if gpg fails it proceeds, but is there something it could do to check gpg sanity before committing anything? It seems the simplest way to go would be to do a test signature before commit, as suggested here: https://bugs.gentoo.org/show_bug.cgi?id=298605 Is it okay to assume that everyone uses gpg-agent, so they won't have to enter the passphrase more than once? Or, we could skip the test signature if the GPG_AGENT_INFO variable is not set? -- Thanks, Zac
