GPG Lockfile (concurrency) issue,
keyring lost: awarding 300$ for bugfix
Stefan.Haller at ascom.ch
Wed Aug 11 13:08:36 CEST 2004
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
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
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
Ascom Autelca Ltd.
+41 31 999 65 06
+41 31 999 65 82
stefan.haller at ascom.ch
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4046 bytes
Desc: not available
Url : /pipermail/attachments/20040811/0c722ab4/keyring_lost_spike-0001.exe
More information about the Gnupg-devel