From ngschroth at yahoo.com Tue Mar 2 22:19:12 2010 From: ngschroth at yahoo.com (nschroth) Date: Tue, 2 Mar 2010 13:19:12 -0800 (PST) Subject: Supressing Passphrase messages In-Reply-To: <26632859.post@talk.nabble.com> References: <26632859.post@talk.nabble.com> Message-ID: <27761317.post@talk.nabble.com> Off and on over the months since I posted this, I have tried numerous ways to supress the messages (without any luck). I have asked others with stong UNIX background, and no one can tell me how/why GPG somehow overrides the redirection of both std in and std error into /dev/null. I must assume since no one responded to my December post that none of you have a clue what is going on. I am still stumped and really could use some suggestions. nschroth wrote: > > On AIX, I am using the following command for decrypting: > /usr/local/bin/gpg --passphrase-file ./.gnupg/passphrase.txt -o > ${OUTFILE} -d ${INFILE} > > The decryption works fine, but the end-user always sees the following > verbage that messes up the screen: > > Reading passphrase from file descriptor 3 > > You need a passphrase to unlock the secret key for > user: "`XXXX (comment) " > 1024-bit ELG-E key, ID YYYYY, created 2009-10-19 (main key ID ZZZZZ) > > HOW CAN I KEEP THIS FROM DISPLAYING? > I also added > /dev/null 2>&1 to send the text to the bitbucket, but it > still displays!!! > > > -- View this message in context: http://old.nabble.com/Supressing-Passphrase-messages-tp26632859p27761317.html Sent from the GnuPG - Dev mailing list archive at Nabble.com. From dshaw at jabberwocky.com Tue Mar 2 22:59:57 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 2 Mar 2010 16:59:57 -0500 Subject: Supressing Passphrase messages In-Reply-To: <27761317.post@talk.nabble.com> References: <26632859.post@talk.nabble.com> <27761317.post@talk.nabble.com> Message-ID: <7E33499E-9CFD-4F0D-86D6-D66DB2729D84@jabberwocky.com> > nschroth wrote: >> >> On AIX, I am using the following command for decrypting: >> /usr/local/bin/gpg --passphrase-file ./.gnupg/passphrase.txt -o >> ${OUTFILE} -d ${INFILE} >> >> The decryption works fine, but the end-user always sees the following >> verbage that messes up the screen: >> >> Reading passphrase from file descriptor 3 >> >> You need a passphrase to unlock the secret key for >> user: "`XXXX (comment) " >> 1024-bit ELG-E key, ID YYYYY, created 2009-10-19 (main key ID ZZZZZ) >> >> HOW CAN I KEEP THIS FROM DISPLAYING? >> I also added > /dev/null 2>&1 to send the text to the bitbucket, but it >> still displays!!! On Mar 2, 2010, at 4:19 PM, nschroth wrote: > > Off and on over the months since I posted this, I have tried numerous ways to > supress the messages (without any luck). I have asked others with stong > UNIX background, and no one can tell me how/why GPG somehow overrides the > redirection of both std in and std error into /dev/null. > > I must assume since no one responded to my December post that none of you > have a clue what is going on. I am still stumped and really could use some > suggestions. You are looking for the "--batch" and "--quiet" options. David From lists at lina.inka.de Thu Mar 4 00:42:30 2010 From: lists at lina.inka.de (Bernd Eckenfels) Date: Thu, 4 Mar 2010 00:42:30 +0100 Subject: Supressing Passphrase messages In-Reply-To: <27761317.post@talk.nabble.com> References: <26632859.post@talk.nabble.com> <27761317.post@talk.nabble.com> Message-ID: <20100303234230.GA24190@lina.inka.de> On Tue, Mar 02, 2010 at 01:19:12PM -0800, nschroth wrote: > Off and on over the months since I posted this, I have tried numerous ways to > supress the messages (without any luck). I have asked others with stong > UNIX background, and no one can tell me how/why GPG somehow overrides the > redirection of both std in and std error into /dev/null. Its writing to the controlling tty, AFAIK. You can just use --batch and use a key with no passphrase. Gruss aBernd From dkg at fifthhorseman.net Fri Mar 5 00:47:05 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 04 Mar 2010 18:47:05 -0500 Subject: segfault in gpg --list-options show-photos --list-secret-keys Message-ID: <4B904679.6020209@fifthhorseman.net> hi folks-- it looks like if there is a User Attribute (UAT, i.e. an attached photo) in the secret keyring, then the following command raises a segmentation fault: gpg --list-options show-photos --list-secret-keys Here is a backtrace: > #0 keyid_from_pk (pk=0x0, keyid=0xbffff658) at ../../g10/keyid.c:320 > #1 0x080b0ca7 in get_validity (pk=0x0, uid=0x812c760) at ../../g10/trustdb.c:1085 > #2 0x080b0f88 in get_validity_info (pk=0x0, uid=0x812c760) at ../../g10/trustdb.c:1185 > #3 0x080c14aa in show_photos (attrs=0x812c750, count=1, pk=0x0, sk=0x812c238, uid=0x812c760) at ../../g10/photoid.c:307 > #4 0x0807598f in list_keyblock_print (keyblock=0x812c510, secret=, fpr=, opaque=0x0) at ../../g10/keylist.c:857 > #5 0x08075f76 in list_keyblock (keyblock=0x812c510, secret=1, fpr=0, opaque=0x0) at ../../g10/keylist.c:1457 > #6 0x08077648 in list_all (secret=) at ../../g10/keylist.c:445 > #7 0x08052c8d in main (argc=0, argv=0xbffffc94) at ../../g10/gpg.c:3593 the attached tarball provides a simple gpg home directory with such a setup. To replicate the crash, do: tar xzf test-keyring-20100304.tgz export GNUPGHOME=test-keyring-20100304 gpg --list-options show-photos --list-secret-keys i looked at doing a simple workaround (e.g. making keyid_from_pk() return 0xffffffff when pk is NULL), but more attempts to dereference pk happen after keyid_from_pk anyway, so i don't think that was the right track. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: test-keyring-20100304.tgz Type: application/x-compressed-tar Size: 3236 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 891 bytes Desc: OpenPGP digital signature URL: From dshaw at jabberwocky.com Fri Mar 5 01:28:54 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 4 Mar 2010 19:28:54 -0500 Subject: segfault in gpg --list-options show-photos --list-secret-keys In-Reply-To: <4B904679.6020209@fifthhorseman.net> References: <4B904679.6020209@fifthhorseman.net> Message-ID: <4B92C734-E8B2-437A-82C6-7CCE6EF09829@jabberwocky.com> On Mar 4, 2010, at 6:47 PM, Daniel Kahn Gillmor wrote: > hi folks-- > > it looks like if there is a User Attribute (UAT, i.e. an attached photo) > in the secret keyring, then the following command raises a segmentation > fault: > > gpg --list-options show-photos --list-secret-keys This is a known bug (it was #1138). It's fixed and will be part of the next release. David From dkg at fifthhorseman.net Fri Mar 5 05:33:27 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 04 Mar 2010 23:33:27 -0500 Subject: segfault in gpg --list-options show-photos --list-secret-keys In-Reply-To: <4B92C734-E8B2-437A-82C6-7CCE6EF09829@jabberwocky.com> References: <4B904679.6020209@fifthhorseman.net> <4B92C734-E8B2-437A-82C6-7CCE6EF09829@jabberwocky.com> Message-ID: <4B908997.8030904@fifthhorseman.net> On 03/04/2010 07:28 PM, David Shaw wrote: > On Mar 4, 2010, at 6:47 PM, Daniel Kahn Gillmor wrote: > >> hi folks-- >> >> it looks like if there is a User Attribute (UAT, i.e. an attached photo) >> in the secret keyring, then the following command raises a segmentation >> fault: >> >> gpg --list-options show-photos --list-secret-keys > > This is a known bug (it was #1138). It's fixed and will be part of the next release. Thanks for pointing that out, David. That does look like the same bug. The patch i see in the tracker [0] looks like a reasonable workaround, though it appears that show-uid-validity simply won't work as a list-option for --list-secret-keys. Maybe the man page could mention this limitation? That is, something like a change from show-uid-validity Display the calculated validity of user IDs during key listings. Defaults to no. to show-uid-validity Display the calculated validity of user IDs during listings of public keys. Defaults to no. Regards, --dkg [0] https://bugs.g10code.com/gnupg/issue1138 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 891 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Fri Mar 5 11:20:06 2010 From: wk at gnupg.org (Werner Koch) Date: Fri, 05 Mar 2010 11:20:06 +0100 Subject: segfault in gpg --list-options show-photos --list-secret-keys In-Reply-To: <4B908997.8030904@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Thu, 04 Mar 2010 23:33:27 -0500") References: <4B904679.6020209@fifthhorseman.net> <4B92C734-E8B2-437A-82C6-7CCE6EF09829@jabberwocky.com> <4B908997.8030904@fifthhorseman.net> Message-ID: <87mxynoysp.fsf@vigenere.g10code.de> On Fri, 5 Mar 2010 05:33, dkg at fifthhorseman.net said: > Thanks for pointing that out, David. That does look like the same bug. > The patch i see in the tracker [0] looks like a reasonable workaround, > though it appears that show-uid-validity simply won't work as a > list-option for --list-secret-keys. Maybe the man page could mention True. That will change with GnuPG 2.1. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Mar 5 11:22:45 2010 From: wk at gnupg.org (Werner Koch) Date: Fri, 05 Mar 2010 11:22:45 +0100 Subject: segfault in gpg --list-options show-photos --list-secret-keys In-Reply-To: <4B908997.8030904@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Thu, 04 Mar 2010 23:33:27 -0500") References: <4B904679.6020209@fifthhorseman.net> <4B92C734-E8B2-437A-82C6-7CCE6EF09829@jabberwocky.com> <4B908997.8030904@fifthhorseman.net> Message-ID: <87fx4foyoa.fsf@vigenere.g10code.de> On Fri, 5 Mar 2010 05:33, dkg at fifthhorseman.net said: > show-uid-validity > Display the calculated validity of user IDs during > listings of public keys. Defaults to no. Done. Thanks, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Mar 9 11:38:31 2010 From: wk at gnupg.org (Werner Koch) Date: Tue, 09 Mar 2010 11:38:31 +0100 Subject: [Announce] GnuPG 2.0.15 released Message-ID: <87bpexok48.fsf@vigenere.g10code.de> Hello! We are pleased to announce the availability of a new stable GnuPG-2 release: Version 2.0.15. The GNU Privacy Guard (GnuPG) is GNU's tool for secure communication and data storage. It can be used to encrypt data, create digital signatures, help authenticating using Secure Shell and to provide a framework for public key cryptography. It includes an advanced key management facility and is compliant with the OpenPGP and S/MIME standards. GnuPG-2 has a different architecture than GnuPG-1 (e.g. 1.4.10) in that it splits up functionality into several modules. However, both versions may be installed alongside without any conflict. In fact, the gpg version from GnuPG-1 is able to make use of the gpg-agent as included in GnuPG-2 and allows for seamless passphrase caching. The advantage of GnuPG-1 is its smaller size and the lack of dependency on other modules at run and build time. We will keep maintaining GnuPG-1 versions because they are very useful for small systems and for server based applications requiring only OpenPGP support. GnuPG is distributed under the terms of the GNU General Public License (GPL version 3). GnuPG-2 works best on GNU/Linux or *BSD systems. What's New =========== * New command --passwd for GPG. * Fixes a regression in 2.0.14 which prevented unprotection of new or changed gpg-agent passphrases. * Uses libassuan 2.0 which is available as a DSO. Getting the Software ==================== Please follow the instructions found at http://www.gnupg.org/download/ or read on: GnuPG 2.0.15 may be downloaded from one of the GnuPG mirror sites or direct from ftp://ftp.gnupg.org/gcrypt/gnupg/ . The list of mirrors can be found at http://www.gnupg.org/mirrors.html . Note, that GnuPG is not available at ftp.gnu.org. On the FTP server and its mirrors you should find the following files in the gnupg/ directory: gnupg-2.0.15.tar.bz2 (3884k) gnupg-2.0.15.tar.bz2.sig GnuPG source compressed using BZIP2 and OpenPGP signature. gnupg-2.0.14-2.0.15.diff.bz2 (40k) A patch file to upgrade a 2.0.14 GnuPG source tree. This patch does not include updates of the language files. Note, that we don't distribute gzip compressed tarballs for GnuPG-2. Checking the Integrity ====================== In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * If you already have a trusted version of GnuPG installed, you can simply check the supplied signature. For example to check the signature of the file gnupg-2.0.15.tar.bz2 you would use this command: gpg --verify gnupg-2.0.15.tar.bz2.sig This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by that signing key. Make sure that you have the right key, either by checking the fingerprint of that key with other sources or by checking that the key has been signed by a trustworthy other key. Note, that you can retrieve the signing key using the command finger wk ,at' g10code.com or using a keyserver like gpg --recv-key 1CE0C630 The distribution key 1CE0C630 is signed by the well known key 5B0358A2. If you get an key expired message, you should retrieve a fresh copy as the expiration date might have been prolonged. NEVER USE A GNUPG VERSION YOU JUST DOWNLOADED TO CHECK THE INTEGRITY OF THE SOURCE - USE AN EXISTING GNUPG INSTALLATION! * If you are not able to use an old version of GnuPG, you have to verify the SHA-1 checksum. Assuming you downloaded the file gnupg-2.0.14.tar.bz2, you would run the sha1sum command like this: sha1sum gnupg-2.0.15.tar.bz2 and check that the output matches the first line from the following list: 3596668fb9cc8ec0714463a5009f990fc23434b0 gnupg-2.0.15.tar.bz2 ed35765ae081706c8856fd491201f4f9576135fd gnupg-2.0.14-2.0.15.diff.bz2 Internationalization ==================== GnuPG comes with support for 27 languages. Due to a lot of new and changed strings many translations are not entirely complete. Jedi, Maxim Britov, Jaime Su?rez and Nilg?n Belma Bug?ner have been kind enough to go over their translations and thus the Chinese, German, Russian, Spanish, and Turkish translations are pretty much complete. Documentation ============= We are currently working on an installation guide to explain in more detail how to configure the new features. As of now the chapters on gpg-agent and gpgsm include brief information on how to set up the whole thing. Please watch the GnuPG website for updates of the documentation. In the meantime you may search the GnuPG mailing list archives or ask on the gnupg-users mailing lists for advise on how to solve problems. Many of the new features are around for several years and thus enough public knowledge is already available. KDE's KMail is the most prominent user of GnuPG-2. In fact it has been developed along with the KMail folks. Mutt users might want to use the configure option "--enable-gpgme" and "set use_crypt_gpgme" in ~/.muttrc to make use of GnuPG-2 to enable S/MIME in addition to a reworked OpenPGP support. The manual is also available online in HTML format at http://www.gnupg.org/documentation/manuals/gnupg/ and in Portable Document Format at http://www.gnupg.org/documentation/manuals/gnupg.pdf . Support ======= Improving GnuPG is costly, but you can help! We are looking for organizations that find GnuPG useful and wish to contribute back. You can contribute by reporting bugs, improve the software, order extensions or support or more general by donating money to the Free Software movement (e.g. http://www.fsfeurope.org/help/donate.en.html). Commercial support contracts for GnuPG are available, and they help finance continued maintenance. g10 Code GmbH, a Duesseldorf based company owned and headed by GnuPG's principal author, is currently funding GnuPG development. We are always looking for interesting development projects. The GnuPG service directory is available at: http://www.gnupg.org/service.html Thanks ====== We have to thank all the people who helped with this release, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word or answering questions on the mailing lists. Happy Hacking, The GnuPG Team -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 200 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From aleph at mandriva.org Tue Mar 9 11:57:24 2010 From: aleph at mandriva.org (Lonyai Gergely) Date: Tue, 9 Mar 2010 11:57:24 +0100 Subject: Some build is broken with libassuan-2.0.0 In-Reply-To: <20100309103958.547af9f2@mandrivalinux.hu> References: <20100309103958.547af9f2@mandrivalinux.hu> Message-ID: <20100309115724.75ada86e@mandrivalinux.hu> Tue, 9 Mar 2010 10:39:58 +0100 -n Lonyai Gergely ?rta: > Hi, > > The dirmngr and gnupg2 doesn't build with new libassuan-2.0.0. When > resolve this problem? > > Aleph Hi, Thank you your perfect answer. Aleph :-) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From aleph at mandriva.org Tue Mar 9 10:39:58 2010 From: aleph at mandriva.org (Lonyai Gergely) Date: Tue, 9 Mar 2010 10:39:58 +0100 Subject: Some build is broken with libassuan-2.0.0 Message-ID: <20100309103958.547af9f2@mandrivalinux.hu> Hi, The dirmngr and gnupg2 doesn't build with new libassuan-2.0.0. When resolve this problem? Aleph -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From wk at gnupg.org Tue Mar 9 12:09:33 2010 From: wk at gnupg.org (Werner Koch) Date: Tue, 09 Mar 2010 12:09:33 +0100 Subject: Some build is broken with libassuan-2.0.0 In-Reply-To: <20100309103958.547af9f2@mandrivalinux.hu> (Lonyai Gergely's message of "Tue, 9 Mar 2010 10:39:58 +0100") References: <20100309103958.547af9f2@mandrivalinux.hu> Message-ID: <876355oioi.fsf@vigenere.g10code.de> On Tue, 9 Mar 2010 10:39, aleph at mandriva.org said: > The dirmngr and gnupg2 doesn't build with new libassuan-2.0.0. When > resolve this problem? You may either install libassuan-1 or libassuan-2 development files. I have just released gnupg 2.0.15 which uses libassuan 2 and thus the problem of switching libassuan development files should be modtly fixed now. A new Dirmngr will be released this week. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From aleph at mandriva.org Tue Mar 9 12:50:10 2010 From: aleph at mandriva.org (Lonyai Gergely) Date: Tue, 9 Mar 2010 12:50:10 +0100 Subject: Some build is broken with libassuan-2.0.0 In-Reply-To: <876355oioi.fsf@vigenere.g10code.de> References: <20100309103958.547af9f2@mandrivalinux.hu> <876355oioi.fsf@vigenere.g10code.de> Message-ID: <20100309125010.16a0c175@mandrivalinux.hu> Tue, 09 Mar 2010 12:09:33 +0100 -n Werner Koch ?rta: > On Tue, 9 Mar 2010 10:39, aleph at mandriva.org said: > > > The dirmngr and gnupg2 doesn't build with new libassuan-2.0.0. When > > resolve this problem? > > You may either install libassuan-1 or libassuan-2 development files. > > I have just released gnupg 2.0.15 which uses libassuan 2 and thus the > problem of switching libassuan development files should be modtly fixed > now. > > A new Dirmngr will be released this week. > > > Salam-Shalom, > > Werner > Hi, My gnupg-2.0.15 test/check was fail on 64 bit. Please, test somebody it (make check). Aleph :-( -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From wk at gnupg.org Tue Mar 9 13:32:00 2010 From: wk at gnupg.org (Werner Koch) Date: Tue, 09 Mar 2010 13:32:00 +0100 Subject: Release candidate for Dirmngr 1.1.0 Message-ID: <871vftoev3.fsf@vigenere.g10code.de> Hi! To move forward with the migration to libassuan 2.0, I did a release candidate for Dirmngr: ftp://ftp.gnupg.org/gcrypt/alpha/dirmngr/dirmngr-1.1.0rc1.tar.bz2 (544k) ftp://ftp.gnupg.org/gcrypt/alpha/dirmngr/dirmngr-1.1.0rc1.tar.bz2.sig Changes are: * Fixed a resource problem with LDAP CRLs. * Fixed a bad EOF detection with HTTP CRLs. * Made "dirmngr-client --url --load-crl URL" work. * New option --ignore-cert-extension. And well, it requires libassuan-2. Please let us know if you notice any new problems. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Mar 9 14:06:01 2010 From: wk at gnupg.org (Werner Koch) Date: Tue, 09 Mar 2010 14:06:01 +0100 Subject: Some build is broken with libassuan-2.0.0 In-Reply-To: <20100309125010.16a0c175@mandrivalinux.hu> (Lonyai Gergely's message of "Tue, 9 Mar 2010 12:50:10 +0100") References: <20100309103958.547af9f2@mandrivalinux.hu> <876355oioi.fsf@vigenere.g10code.de> <20100309125010.16a0c175@mandrivalinux.hu> Message-ID: <87wrxlmypy.fsf@vigenere.g10code.de> On Tue, 9 Mar 2010 12:50, aleph at mandriva.org said: > My gnupg-2.0.15 test/check was fail on 64 bit. Please, test somebody it (make check). I just built it on a 8 CPU ppc64 (GNU/Linux, Gentoo) without any problems. In general it is useful if you show us a bit more of your problem, for example the exact error message. If the test of gnupg fails the content of the log file (e.g tests/openpgp/foo.test.log) is also very useful. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From aleph at mandriva.org Tue Mar 9 15:56:22 2010 From: aleph at mandriva.org (Lonyai Gergely) Date: Tue, 9 Mar 2010 15:56:22 +0100 Subject: Some build is broken with libassuan-2.0.0 In-Reply-To: <87wrxlmypy.fsf@vigenere.g10code.de> References: <20100309103958.547af9f2@mandrivalinux.hu> <876355oioi.fsf@vigenere.g10code.de> <20100309125010.16a0c175@mandrivalinux.hu> <87wrxlmypy.fsf@vigenere.g10code.de> Message-ID: <20100309155622.5f594dd7@mandrivalinux.hu> Tue, 09 Mar 2010 14:06:01 +0100 -n Werner Koch ?rta: > On Tue, 9 Mar 2010 12:50, aleph at mandriva.org said: > > > My gnupg-2.0.15 test/check was fail on 64 bit. Please, test somebody it (make check). > > I just built it on a 8 CPU ppc64 (GNU/Linux, Gentoo) without any > problems. > > In general it is useful if you show us a bit more of your problem, for > example the exact error message. If the test of gnupg fails the content > of the log file (e.g tests/openpgp/foo.test.log) is also very useful. > > > Salam-Shalom, > > Werner > Hi, http://kenobi.mandriva.com/queue/failure/cooker/main/release/20100309105939.aleph.kenobi.9022/log/gnupg2-2.0.15-1mdv2010.1/build.0.20100309110224.log The tests/openpgp/*.log isn't contain useful information. Example the genkey1024.test failed: # cat gnupg2/BUILD/gnupg-2.0.15/tests/openpgp/genkey1024.test.log gpg: WARNING: unsafe permissions on homedir `.' gpg: can't connect to the agent - trying fall back gpg: key C8DC404B marked as ultimately trusted gpg: WARNING: unsafe permissions on homedir `.' gpg: WARNING: unsafe permissions on homedir `.' gpg: can't connect to the agent - trying fall back gpg: key E08AE1C5 marked as ultimately trusted -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From wk at gnupg.org Tue Mar 9 21:38:51 2010 From: wk at gnupg.org (Werner Koch) Date: Tue, 09 Mar 2010 21:38:51 +0100 Subject: Some build is broken with libassuan-2.0.0 In-Reply-To: <20100309155622.5f594dd7@mandrivalinux.hu> (Lonyai Gergely's message of "Tue, 9 Mar 2010 15:56:22 +0100") References: <20100309103958.547af9f2@mandrivalinux.hu> <876355oioi.fsf@vigenere.g10code.de> <20100309125010.16a0c175@mandrivalinux.hu> <87wrxlmypy.fsf@vigenere.g10code.de> <20100309155622.5f594dd7@mandrivalinux.hu> Message-ID: <87hbopmdr8.fsf@vigenere.g10code.de> On Tue, 9 Mar 2010 15:56, aleph at mandriva.org said: > The tests/openpgp/*.log isn't contain useful information. > Example the genkey1024.test failed: What is the content of conventional.test.log ? -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From umq.461 at gmail.com Thu Mar 11 18:35:08 2010 From: umq.461 at gmail.com (Hirohisa Yamaguchi) Date: Fri, 12 Mar 2010 02:35:08 +0900 Subject: Release candidate for Dirmngr 1.1.0 In-Reply-To: <871vftoev3.fsf@vigenere.g10code.de> References: <871vftoev3.fsf@vigenere.g10code.de> Message-ID: <738528cb1003110935g7dfd7e61q8e4c51fee34ae4a8@mail.gmail.com> Hi, On Tue, Mar 9, 2010 at 9:32 PM, Werner Koch wrote: > To move forward with the migration to libassuan 2.0, I did a release > candidate for Dirmngr: > Please let us know if you notice any new problems. I got some warnings under FreeBSD/amd64: -- utf8conv.c: In function 'jnlib_iconv': utf8conv.c:729: warning: passing argument 2 of 'libiconv' from incompatible pointer type logging.c: In function 'set_file_fd': logging.c:287: warning: passing argument 3 of 'funopen' from incompatible pointer type dirmngr.c: In function 'pid_suffix_callback': dirmngr.c:579: warning: cast from pointer to integer of different size dirmngr.c: In function 'start_connection_thread': dirmngr.c:1707: warning: cast from pointer to integer of different size dirmngr.c:1713: warning: cast to pointer from integer of different size dirmngr.c: In function 'handle_connections': dirmngr.c:1830: warning: cast to pointer from integer of different size certcache.c: In function 'hexsn_to_sexp': certcache.c:186: warning: format '%u' expects type 'unsigned int', but argument 4 has type 'size_t' certcache.c:186: warning: format '%u' expects type 'unsigned int', but argument 4 has type 'size_t' -- hope those are not serious problem. Regards, -- Hirohisa Yamaguchi From wk at gnupg.org Fri Mar 12 13:13:41 2010 From: wk at gnupg.org (Werner Koch) Date: Fri, 12 Mar 2010 13:13:41 +0100 Subject: Release candidate for Dirmngr 1.1.0 In-Reply-To: <738528cb1003110935g7dfd7e61q8e4c51fee34ae4a8@mail.gmail.com> (Hirohisa Yamaguchi's message of "Fri, 12 Mar 2010 02:35:08 +0900") References: <871vftoev3.fsf@vigenere.g10code.de> <738528cb1003110935g7dfd7e61q8e4c51fee34ae4a8@mail.gmail.com> Message-ID: <87ljdxkaa2.fsf@vigenere.g10code.de> On Thu, 11 Mar 2010 18:35, umq.461 at gmail.com said: > utf8conv.c: In function 'jnlib_iconv': > utf8conv.c:729: warning: passing argument 2 of 'libiconv' from > incompatible pointer type No problem will be fixed with one of the next releases (that part of the code is shared with gnupg and fixed over there.) > logging.c: In function 'set_file_fd': > logging.c:287: warning: passing argument 3 of 'funopen' from > incompatible pointer type No problem either. Again code from GnuPG. My current work there is to get rid of funopen/fopencookie to make the socket logging code work on platforms other thanh GNU and BSD. I'll fix the otehr warnings for the release. > hope those are not serious problem. Should not arm. We are casting int and pointer back and forth and in total that is no problem. Thanks. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From jari.aalto at cante.net Tue Mar 23 18:16:43 2010 From: jari.aalto at cante.net (Jari Aalto) Date: Tue, 23 Mar 2010 19:16:43 +0200 Subject: [PATCH] SVN 5298: doc/gpg.texi -- improve description of option -u Message-ID: <87vdcnhsas.fsf@jondo.cante.net> Inspired by blog: [tech] How to get GPG to sign with multiple keys I spent way too much time trying to figure out how to get GnuPG to sign a file with multiple keys. It's not at all obvious from the man page, but you can use the -u option multiple times, with each key ID that you want to use. http://blog.andrew.net.au/2010/03/18#sign_with_multiple_keys 2010-03-23 Jari Aalto * gpg.texi (GPG Key related Options): improve description of option -u to mention that it can be used multiple times. (GPG Examples): In 'make a detached signature' example, mention that option -u can be used multiple times. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-doc-gpg.texi-Mention-that-u-can-be-used-multiple-tim.patch Type: text/x-diff Size: 1946 bytes Desc: not available URL: From philcerf at googlemail.com Sat Mar 27 00:55:43 2010 From: philcerf at googlemail.com (Philippe Cerfon) Date: Sat, 27 Mar 2010 00:55:43 +0100 Subject: ecc in gpg Message-ID: <6e7da8721003261655g2d181f9eu38402613a83c7c28@mail.gmail.com> Hi. I just wondered, whether any work has been done already in gpg to support http://tools.ietf.org/html/draft-jivsov-openpgp-ecc-04 ? Any idea how near a finalised standard RFC is? And when (about) could one expect a production-use-ready implementation in gpg? Cheers, Philippe. From sergi at calcurco.cat Mon Mar 29 09:25:55 2010 From: sergi at calcurco.cat (=?ISO-8859-1?Q?Sergi_Blanch_i_Torn=E9?=) Date: Mon, 29 Mar 2010 09:25:55 +0200 Subject: ecc in gpg In-Reply-To: <6e7da8721003261655g2d181f9eu38402613a83c7c28@mail.gmail.com> References: <6e7da8721003261655g2d181f9eu38402613a83c7c28@mail.gmail.com> Message-ID: <80e2a3c41003290025i757c8099ga5e5959e9b3b930d@mail.gmail.com> Yes, I only sent email to this list with the sentence "still working". The ecc code is being extended to support the encryption algorithm to the already given about the ecdsa. About the moment when this internet draft will become rfc, I have no idea. Somebody else know something? /Sergi. On Sat, Mar 27, 2010 at 1:55 AM, Philippe Cerfon wrote: > Hi. > > I just wondered, whether any work has been done already in gpg to > support http://tools.ietf.org/html/draft-jivsov-openpgp-ecc-04 ? > > Any idea how near a finalised standard RFC is? And when (about) could > one expect a production-use-ready implementation in gpg? > > Cheers, > Philippe. > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel >