> Am 29.03.2017 um 07:44 schrieb Doug Barton <[email protected]>: > > > That's not how you use haveged. It is supposed to start when the system > boots, and run in the background, collecting entropy to seed the PRNG.
This system is based on a LiveCD starting a Docker container. Therefore there is no init.d, only pcscd and haveged. In my understanding wait time to collect entropy should not be the problem when having a blocking RNG - the process just waits. > > That said, if you are using a card for signing that's way more likely to be > involved in the problems you're seeing. Try creating a key on the file > system, and test using that first. If that works, then you've narrowed down > your problems. I did this before, and it worked. As not using havegd did work for me I have no need to fix this problem. I just would recommend to add a note to gpg that users are warned about the issue, as gpg will not yield a meaningful error message, even with -vvv. Thanks, Rainer > > Doug > > > On 03/22/2017 11:33 PM, Rainer Hoerbe wrote: >> Just for the record: Adding entropy using haveged does not work in my setup >> - it will cause the signature to fail without useful error message. >> >> My setup is: >> Linux keymgmt 4.9.14-200.fc25.x86_64 #1 SMP Mon Mar 13 19:26:40 UTC 2017 >> x86_64 x86_64 x86_64 GNU/Linux >> gpg (GnuPG) 2.0.22 >> libgcrypt 1.5.3 >> >> The procedure that repeatedly fails when including haveged: >> sudo /usr/sbin/pcscd >> sudo /usr/sbin/haveged >> gpg2 --import my_pub.gpg >> gpg2 --card-status >> echo -e "trust\n5\ny" > /tmp/gpg_editkey.cmd >> gpg2 --command-file /tmp/gpg_editkey.cmd --edit-key >> gpg2 --sign mydoc.txt >> >> Regards, >> Rainer Hörbe >> Identinetics GmbH >> _______________________________________________ >> Gnupg-users mailing list >> [email protected] >> http://lists.gnupg.org/mailman/listinfo/gnupg-users >> _______________________________________________ Gnupg-users mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnupg-users
