Fixed in git for gnupg 1.4.13, Libgcrypt 1.5.1 and Libgcrypt 1.6.0.

The reason why I was not able to replicate this bug was that
I didn't use -std=c99 with gcc >= 4.3.

We won't do this for 1.4.

I would say this should go into 2.1.

Thank You werner for the explanations.

As a workaround I copied to C:\GNU\GnuPG\ and this helped.
Now I have other issues but this one is solved.

Thanks again and bye.
me.

Meanwhile gniibe fixed a lot more bugs and also ported them back to 2.0. Thus I
close this bug.

This problem also happens with gcc if run in -std=c99 mode. It is due to a
change in gcc 4.3. It has been fixed in for stable and master. It is thus
likely that the problem is also solved for clang.

I have implemented your suggestion for 1.4. Check out commit b1abc01 of GnuPG.

Yes, mandatory locks are a problem. LockFile works on a separate lockfile to
implement such an advisory locking. If we would lock the random_seed file
directly reads or writes will fail and we won't be able to lock the creation of
that file.

You suggestion for 1.4. makes sense.

This is not a bug. The description of --max-cache-ttl reads:

  Set the maximum time a cache entry is valid to @var{n} seconds.  After
  this time a cache entry will be expired even if it has been accessed
  recently.  The default is 2 hours (7200 seconds).

Thus even if you set the cache-ttl-ssh > max-cache-ttl, it will expire after
max-cache-ttl seconds.

Some autoconf tests may choke on spaces in file names. Of course it is
possible to avoid this problem, but for development tools, it is not really
justified. Hacker's don't have spaces in there file names - they lead to all
kind of problems. Sometimes there is even a check for this problem:

1. Reject unsafe characters in $HOME, $tsdir and cwd. We consider spaces
2. as unsafe because it is too easy to get scripts wrong in this regard.

am_lf='
'
case pwd in

*[\;\\\"\#\$\&\'\`$am_lf\ \	]*)
  echo "unsafe working directory name"; DIE=yes;;

esac

But most packages don't have these checks, yet.

You should try to install into another directory - without strange characters
like spaces or parentheses.

The behaviour matches that observed in released versions; I was debugging a
problem observed in the released versions, not reviewing code looking for issues.

Whether or not it's used in the current development branch, this has caused an
interoperability issue in the real world for the keyserver operators, causing a
functionality deployment to be rolled back and resulting in filtered results,
reducing the pool of available keyservers.

Since Issue1447 is a security impacting issue which will need a CVE and a security
release to fix anyway, it would really be nice to try to get the fix for client
behaviour into a version which is likely to be pushed out widely. Not critical,
security comes first, but if we can leverage the security release to improve
interop, that would be helpful.

In practice, we (the keyserver operators and pool operators) are stuck not able to
use SRV to point to non-default ports for at least a couple of years. This is
very unfortunate, given the efforts currently being made to make deployments more
robust, with TLS more widely deployed.

So you are saying, every distribution supporting a co-installation should patch
GPG to fix this?
The user might not even know what gpg is, that several major versions exist, or
which options are available where. He just sees email encryption not working any
longer. In most cases, he won't have decided to install both versions - he just
has software installed which, indirectly, depends on both.

Well, it might still exists, but it is not used anymore. Remember that this is
the development branch.

The one who decided to install both versions while at the same time using an
option not available for gpg1. It might be caused by a package manager.

Of course it can be fixed by changing the config files. However, the default
behaviour (if I start gpgconf as a new user) is to use the shared config file
for both versions. As I see it, programs are responsible to set up the
configuration in the user's home directory if they need one - at least, that's
common practice in my experience.
If this is not a bug in GnuPG, then whose installation problem is this?

% git remote -v
origin git://git.gnupg.org/gnupg.git (fetch)
origin git://git.gnupg.org/gnupg.git (push)
% git status

On branch master

nothing to commit (working directory clean)
%

I did the pull on the day I filed the bug, and as of the commit stated, the
directory exists. I just did a "git pull", no change. I didn't write "git current"
in this bug.

http://www.gnupg.org/download/cvs_access.en.html still points to the repo above, so
that's what I pulled. If that's no longer correct, I can pull another repo.

But still, if you check out the revision stated, you'll see the behaviour, which is
reflected in current releases of GnuPG.

Gpgconf uses the configuration file as advertised by gpg.
For example:

  $ gpg2 --gpgconf-list | grep ^gpgconf-gpg.conf:
  gpgconf-gpg.conf:16:"/home/wk/.gnupg/gpg.conf
  $ gpg --gpgconf-list | grep ^gpgconf-gpg.conf:
  gpgconf-gpg.conf:16:"/home/wk/.gnupg/gpg.conf

  $ touch ~/.gnupg/gpg.conf-1

  $ gpg2 --gpgconf-list | grep ^gpgconf-gpg.conf:
  gpgconf-gpg.conf:16:"/home/wk/.gnupg/gpg.conf
  $ gpg --gpgconf-list | grep ^gpgconf-gpg.conf:
  gpgconf-gpg.conf:16:"/home/wk/.gnupg/gpg.conf-1

Thus you only need to create a gpg.conf-1 (or conf-2) and you are
done. This is an installation problem.

What do you mean by "git current"? The current "git master" has no keyserver/
stuff.

Kristian has removed the SRV records at _pgpkey-https._tcp.hkps.sks-
keyservers.net, so the explanation in step 3 might seem to not match reality, but
that's a change, because of this Issue and Issue1446.

If you set up your own DNS pool for testing, I'm happy to send you a CSR for a new
vhost to help with debugging.

I'm not sure what you mean by "no portable advisory locking in Windows".
There's LockFile()/UnlockFile() as used in the new dotlock code. Would it be a
problem if the locks on random_seed were mandatory locks? If so, then using the
dotlock code is certainly the shortest path to a perfect solution.

Regarding gpg 1.4, however: The reason why I opened this bug is that gpg
randomly fails to encrypt what it was told to encrypt. This is as bad as if it
would be randomly crashing. I don't mind an occasional "note: random_seed file
is empty" message nor a performance penalty from needlessly re-generating the
seed file. Modifying the error handling after read() as I tried to outline in
my previous message ought to be enough to get rid of the random fatal errors.
Do you consider such a change suitable for gpg 1.4?

What is your threat model?

It is already available in the latest 2.1-beta.

That is not possible for two reasons:

1. For v3 keys the fingerprint is different from the keyID.
2. We often have only the keyID but not the fingerprint available.

Yeah sure, I meant "NOT a problem".

Yes I know what you mean. But without locking you will never be able
to get it right.

As you noted there is actually a problem with Libgcrypt under
Windows. In Libgcrypt we lock the seed file and thus the fatal error
is the right thing to do. But.....

  #ifdef __GCC__
  #warning Check whether we can lock on Windows.
  #endif
  #if LOCK_SEED_FILE

Thus we should implement locking for Windows. The problem here is
that there is no portable advisory locking in Windows. And frankly our
fcntl locking approach does not work on all Unices either and worse it
does not work if the home partition is on certain remote file systems.

The only solution I see is to employ the new dotlock code from GnuPG
here. It is slower than fcntl locking but very portable.

I don't think we will fix this in gpg 1.4.

Make sure your umask is setup properly. This is standard Unix behaviour and
nothing GPG can do about. Whether you use --output or the usual redirection
shall not make a difference.

In any case we can't change the behaviour of --output created files becuase that
would break all kind of users.

This is known but a problem from a security POV.

I suppose you mean "NOT a problem"? I think it might be a problem in
opportunistic encryption scenarios if gpg encryption failures caused by
random_seed access conflicts are ignored like failures caused by missing keys.
But usually it's just a nuisance like any other randomly failing program.

The non-locking read is on purpose - if it works: okay. Otherwise we
re-generate a seed file.

I see that the code tries to tolerate access conflicts, but there's still a race
condition if the random_seed file is truncated between fstat() and read(). The
read() error handling is incomplete. Maybe this pseudo-patch explains best what
I mean:

diff -ru gnupg-1.4.12/cipher/random.c gnupg-1.4.12/cipher/random.c

• gnupg-1.4.12/cipher/random.c 2012-01-24 09:45:41.000000000 +0100

+++ gnupg-1.4.12/cipher/random.c 2012-09-18 19:47:54.449578800 +0200
@@ -492,11 +492,17 @@

    do {
	n = read( fd, buffer, POOLSIZE );
    } while( n == -1 && errno == EINTR );

• if( n != POOLSIZE ) {

+ if( n == -1 ) {

	log_fatal(_("can't read `%s': %s\n"), seed_file_name,strerror(errno) );
	close(fd);
	return 0;
    }

+ else if ( n == 0 ) {
+ ... handle like sb.st_size == 0
+ }
+ else if ( n != POOLSIZE ) {
+ ... handle like sb.st_size != POOLSIZ
+ }

     close(fd);

Yes, we could do the file locking

Proper locking would be the ideal solution, but a better read() error handling
would already be sufficient to avoid the sporadic fatal errors on random_seed
accesses.

and iirc, we do this in libgcrypt (GnuPG-2).

I'm just checking this and ... sorry, no. The gpg2.exe from Gpg4win 2.1.0 shows
the very same error:

note: random_seed file is empty
note: random_seed file is empty
Fatal: can't read `C:/Dokumente und
Einstellungen/jechternach/Anwendungsdaten/GnuPG /random_seed': No such file or
directory

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
note: random_seed file is empty

Ok I did some more research on this topic and it appears ECC is the fix for RSA
additional key sizes. Do you have any idea when ECC will be implemented into
this gem? This draft appears to be expired though so its unknown to me if there
are plans to get this implemented into the default software without requiring a
patch.

Draft: https://tools.ietf.org/html/draft-jivsov-openpgp-ecc-11

Once again thanks for the feedback. I tried to search but I kept getting errors
so I apologize if this was previously addressed.

This is known but a problem from a security POV. The seed file is a cache. If
the seed file can't be read a new one is created. Right, there might be a
performance issue but at least on Windows this is not as severe as on certain
Linux systems.

The non-locking read is on purpose - if it works: okay. Otherwise we
re-generate a seed file. Yes, we could do the file locking and iirc, we do this
in libgcrypt (GnuPG-2).

The error on short reads is also on purpose. We want those 600 bytes at once
and nothing else. If another process is writing the seed file we may see the
short reads. But in this case there is no clear answer waht to do - thus we
assume the "no seed file" case.

No.

Please read all the long threads on gnupg-users to learn why this is not a good
idea. You may also want to read Ross Anderson's "Security Engineering".

D159: 359_gpgme_op_encrypt_sign-symmetric.patch

May I ask for the status of this bug?

Is this going to be implemented in the gnupg 2.x series?

May I ask what happen with this bug?

Just trying to keep track of these bugs in Debian Bug Tracking System.

Can you please also test with GPA?

Makese sense.

Marked as resolved in Gentoo.