| 1 |
On 06/23/2013 01:19 AM, Michał Górny wrote: |
| 2 |
> Dnia 2013-06-22, o godz. 17:02:56 |
| 3 |
> ""Paweł Hajdan, Jr."" <phajdan.jr@g.o> napisał(a): |
| 4 |
> |
| 5 |
>> On 6/20/13 2:16 AM, Michał Górny wrote: |
| 6 |
>>> Doing test signatures won't cover all failures. |
| 7 |
>> |
| 8 |
>> Do you know an example? The only one I'm aware of is when a test |
| 9 |
>> signature is made very close to the expiration date, and then the real |
| 10 |
>> signature would be done after it. |
| 11 |
> |
| 12 |
> Well, Michael explained one in the other branch of this thread quite |
| 13 |
> thoroughly. Other than that, there can be random runtime errors |
| 14 |
> and race conditions. |
| 15 |
> |
| 16 |
> I'd say it's as good as using stat() to check whether a file exists |
| 17 |
> before opening it. But thinking of it, I've got another idea... |
| 18 |
> |
| 19 |
> How about opening 'gpg -s' in a subprocess before first commit |
| 20 |
> and feeding the Manifest afterwards? As far as I can see, gpg asks for |
| 21 |
> the password instantly, so likely most of the bases will be covered |
| 22 |
> already, and we're be doing a single signature only. |
| 23 |
|
| 24 |
The only problem I see is that repoman will have no way of knowing when |
| 25 |
you have finished typing the pass phrase (if not using gpg-agent). So, |
| 26 |
there may be some mixing of repoman and gpg/pinentry output in the terminal. |
| 27 |
-- |
| 28 |
Thanks, |
| 29 |
Zac |
Archives