GPG Lockfile (concurrency) issue, keyring lost: awarding 300$ for bugfix

[Stefan Haller]

Hi all

A while ago I posted a bug report about a concurrency issue. Parallel 
import and verify GPG processes using the same keyring may result in 
loosing all public keys in the key ring.

I upgraded to 1.2.5, but the issues are still present. I looked at the 
code myself, but I think it will require a lot of time for me to fix the 
issues and it will probably result only in a poor work around. I would 
like a good solution for the issue which is acceptable to the GnuPG 
development team for use in future versions of GnuPG to increase the 
products quality. I will award up to 300$ to the developer that solves the 
problem for me. Please find details below.


I need two modifications in GnuPG:

1. The lockfile for the keyring is not handeled correctly, it seems. I 
need proper locking to prevent GPG from loosing the entire public key 
ring.
I think it happens somehow like this:
- import renames keyring and updates file
- verify does not find keyring file and creates new one
- import finds an already existing keyring and is unable to rename the 
updated file back
If the output of gpg is...
gpg: keyring `/var/tmp/keyring_lost_test/pubring.gpg' created
... you know that all keys in keyring were lost.

2. In case GPG cannot run because of a lock-file being present, I require 
a separate exit status. This will indicate to my program that it can retry 
the command afterwards as it was not a real error.


I'm willing to award 100$ for a patch based on the last stable release of 
GPG, fixing above issues.
Another 100$ are awarded to the patch author, if the patch is accepted by 
the GPG core team and incorporated in future releases.
Another 100$ are awarded if I have a working solution until end of August 
2004.


The following acceptance procedures apply:

The patch is verified using a shell script I wrote to reproduce the 
behaviour. It is attached to this email. The patch is only accepted if the 
script succeeds on my system. I reserve the right to adjust the test 
script in case I built in errors into the test procedure, so just using a 
bug in the test script to make it work is not accepted... (first 100$ for 
a working patch)

If the patch is committed to the main GnuPG development branch by GPG core 
developers (or anyone with permissions), the patch author will be rewarded 
with another 100$ as the GPG core team thinks it is a good patch.

If I get a working patch (does not need to be included in GPG development 
branch, just working for me) by end of August 2004, I reward the patch 
author by another 100$.


Above goals are cumulative, meaning that I am willing to pay up to 300$ if 
all conditions are fulfilled.


To prevent a chaos, this "contract" is awarded as follows:
- participation requires explicit confirmation by me. This is to prevent 
more than one person working on the issue. So, just mail me first if you 
would like to do this.
- first come, first served. I will confirm the first person mailing me, 
that he may start implementing. The others will be notified, that it is 
already taken care of.


I hope you find this offer interesting. Contact me if you have any 
questions on the topic.


With kind regards
 Stefan


Stefan Haller
Software Development
Transport Revenue
________________________________ 
Ascom Autelca Ltd.
Worbstrasse 201
CH-3073 Gümligen 
Phone 
Fax 
+41 31 999 65 06
+41 31 999 65 82 
stefan.haller at ascom.ch
www.ascom.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: keyring_lost_spike.sh
Type: application/octet-stream
Size: 4046 bytes
Desc: not available
Url : /pipermail/attachments/20040811/0c722ab4/keyring_lost_spike-0001.exe