From gpgdev.5.signal11 at spamgourmet.com Thu Jun 1 16:33:03 2006 From: gpgdev.5.signal11 at spamgourmet.com (gpgdev.5.signal11@spamgourmet.com) Date: Fri Jun 2 14:46:30 2006 Subject: GnuPG does not detect injection of unsigned data Message-ID: <20060601163303.7f5cd241.gpgdev.5.signal11@spamgourmet.com> Hello, From dshaw at jabberwocky.com Fri Jun 2 14:56:32 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Fri Jun 2 14:55:31 2006 Subject: GnuPG does not detect injection of unsigned data In-Reply-To: <20060601163303.7f5cd241.gpgdev.5.signal11@spamgourmet.com> References: <20060601163303.7f5cd241.gpgdev.5.signal11@spamgourmet.com> Message-ID: <20060602125632.GA31383@jabberwocky.com> On Thu, Jun 01, 2006 at 04:33:03PM +0200, gpgdev.5.signal11@spamgourmet.com wrote: > Hello, > > From the background information in the announcement, it seems that this > problem does not affect cleartext signatures. > > Am I correct, or is this a misinterpretation? The announcement sounds > like gpg would still correctly verify (only) data covered by the signature, but then > output data which is not covered by the signature. So it would still be safe to > assume that anything between -----BEGIN PGP SIGNED MESSAGE----- and the > following -----BEGIN PGP SIGNATURE----- is correctly validated(?). The problem does not affect cleartext signatures. Just for reference, the problem also does not affect signed software tarballs (i.e. detached signatures), or PGP/MIME signed emails (they're actually detached signatures). The problem *might* affect PGP/MIME signed+encrypted emails, signed+encrypted files in general, or unencrypted but binary (not cleartext) signed messages. David From qed at tiscali.it Sat Jun 3 22:33:10 2006 From: qed at tiscali.it (Qed) Date: Sat Jun 3 22:35:16 2006 Subject: DSA2 and recipient preferences Message-ID: <4481F206.3060201@tiscali.it> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Playing with DSA2 keys(gnupg 1.4.4-svn4149) I've noticed a potentially problematic behaviour when mixing old and new keys. Suppose you have three keys: # is your key and is a 3072DSA(q=256) # is a key that has the following digest prefs: SHA1, SHA256, RIPEMD160 # is a key with the following(rather common) digest prefs: SHA1, RIPEMD160 and you have personal-digest-preferences "H10 H9 H8 H3 H2" in your gpg.conf. with "gpg -u -s -e --encrypt-to -r " we obtain a DSA/SHA256 signature, correct. with "gpg -u -s -e --encrypt-to -r " we obtain a DSA/SHA512(truncated to 256bits) signature without ANY warning. with "gpg -u -s -e --encrypt-to -r - -r " again we obtain a DSA/SHA512 sig without warnings, thus violating the preferences of both recipients. This latter behaviour is obviously a bug, RFC2440 says about symmetric ciphers: > An implementation MUST NOT use a symmetric algorithm that is not in > the recipient's preference list. When encrypting to more than one > recipient, the implementation finds a suitable algorithm by taking > the intersection of the preferences of the recipients. but future DSA keys with q>160 would inevitably break this rule when the recipient is a key with digest prefs set to "H2 H3". Decrypting the message with such a key and veryfing doesn't generate any warning, again RFC2440: > If an implementation can decrypt a message that a keyholder doesn't > have in their preferences, the implementation SHOULD decrypt the > message anyway, but MUST warn the keyholder that the protocol has > been violated. Obviously my statements are based assuming that the same considerations for symmetric algorithms apply to digest algorithms, section 12.2 says: > Other algorithm preferences work similarly to the symmetric > algorithm preference, in that they specify which algorithms the > keyholder accepts. Must be said that section 12.2.2(Hash algorithm preferences) doesn't specify explicitly what MUST be done, so if my assumptions are wrong, please ignore me. - -- Q.E.D. ICQ UIN: 301825501 OpenPGP key ID: 0x58D14EB3 Key fingerprint: 00B9 3E17 630F F2A7 FF96 DA6B AEE0 EC27 58D1 4EB3 Check fingerprints before trusting a key! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEgfIGH+Dh0Dl5XacRAwQYAJ0T2dUHW4h3KTkDInOtz09R2mjXygCfSsbh cJXPC2Qy+wirA45qwey32To= =D8uH -----END PGP SIGNATURE----- From dshaw at jabberwocky.com Sun Jun 4 00:00:23 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Sat Jun 3 23:59:18 2006 Subject: DSA2 and recipient preferences In-Reply-To: <4481F206.3060201@tiscali.it> References: <4481F206.3060201@tiscali.it> Message-ID: <20060603220023.GA32267@jabberwocky.com> On Sat, Jun 03, 2006 at 10:33:10PM +0200, Qed wrote: > Playing with DSA2 keys(gnupg 1.4.4-svn4149) I've noticed a potentially > problematic behaviour when mixing old and new keys. > > Suppose you have three keys: > # is your key and is a 3072DSA(q=256) > # is a key that has the following digest prefs: SHA1, > SHA256, RIPEMD160 > # is a key with the following(rather common) digest prefs: > SHA1, RIPEMD160 > and you have personal-digest-preferences "H10 H9 H8 H3 H2" in your > gpg.conf. > > with "gpg -u -s -e --encrypt-to -r " > we obtain a DSA/SHA256 signature, correct. > > with "gpg -u -s -e --encrypt-to -r " > we obtain a DSA/SHA512(truncated to 256bits) signature without ANY warning. > > with "gpg -u -s -e --encrypt-to -r > -r " > again we obtain a DSA/SHA512 sig without warnings, thus violating the > preferences of both recipients. Not a bug, just a no-way-out situation. You told GPG to sign using a q=256 key, so the hash has to be 256 bits or larger. At the same time, you told GPG that it had to use either SHA1 or RIPEMD160, both of which are 160 bits. In the case where GPG simply cannot come up with a hash that pleases everyone, it goes with what the signing key is capable of (i.e. 256 or larger) joined with your personal-digest-prefs. Thus it chose SHA512: larger than 256 bits so the signing key was happy, and 512 because you listed it first. I sympathize about the desire for a warning message here, but remember that this would mean a warning message for almost every signature made with a DSA2 key. Any time you have a DSA2 key signing and encrypting to an older key without SHA256 (which are a significant majority of keys at this point) you would get a warning. In such a situation, warnings become meaningless. > This latter behaviour is obviously a bug, RFC2440 says about symmetric > ciphers: > > An implementation MUST NOT use a symmetric algorithm that is not in > > the recipient's preference list. When encrypting to more than one > > recipient, the implementation finds a suitable algorithm by taking > > the intersection of the preferences of the recipients. > but future DSA keys with q>160 would inevitably break this rule when the > recipient is a key with digest prefs set to "H2 H3". > Decrypting the message with such a key and veryfing doesn't generate any > warning, again RFC2440: > > If an implementation can decrypt a message that a keyholder doesn't > > have in their preferences, the implementation SHOULD decrypt the > > message anyway, but MUST warn the keyholder that the protocol has > > been violated. > > Obviously my statements are based assuming that the same considerations > for symmetric algorithms apply to digest algorithms, section 12.2 says: > > Other algorithm preferences work similarly to the symmetric > > algorithm preference, in that they specify which algorithms the > > keyholder accepts. > > Must be said that section 12.2.2(Hash algorithm preferences) doesn't > specify explicitly what MUST be done, so if my assumptions are wrong, > please ignore me. They're "similar," but not identical. Cipher preferences are agreed upon between the sender and recipient. Digest preferences are merely suggested by the recipient. Ultimately, the signer has to choose as it is the one issuing the signature. In the past, there was always SHA1 - the must have digest - that could be used as a fallback, so this problem never really happened in practice. Now with DSA2, it's a possibility. With DSA2, the recipient may not have *any* of the digests needed by the sender. The choice then becomes to let the sender pick a digest the recipient can't handle, or... don't sign at all. Thanks for testing DSA2. This was an interesting interaction between the new and old keys and it is good to get discussion of it before DSA2 is released in GPG 1.4.4 and the floodgates open ;) David From alphasigmax at gmail.com Sun Jun 4 02:58:17 2006 From: alphasigmax at gmail.com (Alphax) Date: Sun Jun 4 02:59:28 2006 Subject: DSA2 and recipient preferences In-Reply-To: <20060603220023.GA32267@jabberwocky.com> References: <4481F206.3060201@tiscali.it> <20060603220023.GA32267@jabberwocky.com> Message-ID: <44823029.7070607@gmail.com> David Shaw wrote: > On Sat, Jun 03, 2006 at 10:33:10PM +0200, Qed wrote: >> Playing with DSA2 keys(gnupg 1.4.4-svn4149) I've noticed a potentially >> problematic behaviour when mixing old and new keys. >> >> Suppose you have three keys: >> # is your key and is a 3072DSA(q=256) >> # is a key that has the following digest prefs: SHA1, >> SHA256, RIPEMD160 >> # is a key with the following(rather common) digest prefs: >> SHA1, RIPEMD160 >> and you have personal-digest-preferences "H10 H9 H8 H3 H2" in your >> gpg.conf. >> >> with "gpg -u -s -e --encrypt-to -r " >> we obtain a DSA/SHA256 signature, correct. >> >> with "gpg -u -s -e --encrypt-to -r " >> we obtain a DSA/SHA512(truncated to 256bits) signature without ANY warning. >> >> with "gpg -u -s -e --encrypt-to -r >> -r " >> again we obtain a DSA/SHA512 sig without warnings, thus violating the >> preferences of both recipients. > > Not a bug, just a no-way-out situation. You told GPG to sign using a > q=256 key, so the hash has to be 256 bits or larger. At the same > time, you told GPG that it had to use either SHA1 or RIPEMD160, both > of which are 160 bits. In the case where GPG simply cannot come up > with a hash that pleases everyone, it goes with what the signing key > is capable of (i.e. 256 or larger) joined with your > personal-digest-prefs. Thus it chose SHA512: larger than 256 bits so > the signing key was happy, and 512 because you listed it first. > > I sympathize about the desire for a warning message here, but remember > that this would mean a warning message for almost every signature made > with a DSA2 key. Any time you have a DSA2 key signing and encrypting > to an older key without SHA256 (which are a significant majority of > keys at this point) you would get a warning. In such a situation, > warnings become meaningless. How many people genuinely can't handle SHA256? Only pre-PGP 8 users? -- Alphax Death to all fanatics! Down with categorical imperative! OpenPGP key: http://tinyurl.com/lvq4g -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 569 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20060604/7ccca805/signature.pgp From dshaw at jabberwocky.com Sun Jun 4 03:25:03 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Sun Jun 4 03:24:06 2006 Subject: DSA2 and recipient preferences In-Reply-To: <44823029.7070607@gmail.com> References: <4481F206.3060201@tiscali.it> <20060603220023.GA32267@jabberwocky.com> <44823029.7070607@gmail.com> Message-ID: <20060604012503.GC32267@jabberwocky.com> On Sun, Jun 04, 2006 at 10:28:17AM +0930, Alphax wrote: > David Shaw wrote: > > On Sat, Jun 03, 2006 at 10:33:10PM +0200, Qed wrote: > >> Playing with DSA2 keys(gnupg 1.4.4-svn4149) I've noticed a potentially > >> problematic behaviour when mixing old and new keys. > >> > >> Suppose you have three keys: > >> # is your key and is a 3072DSA(q=256) > >> # is a key that has the following digest prefs: SHA1, > >> SHA256, RIPEMD160 > >> # is a key with the following(rather common) digest prefs: > >> SHA1, RIPEMD160 > >> and you have personal-digest-preferences "H10 H9 H8 H3 H2" in your > >> gpg.conf. > >> > >> with "gpg -u -s -e --encrypt-to -r " > >> we obtain a DSA/SHA256 signature, correct. > >> > >> with "gpg -u -s -e --encrypt-to -r " > >> we obtain a DSA/SHA512(truncated to 256bits) signature without ANY warning. > >> > >> with "gpg -u -s -e --encrypt-to -r > >> -r " > >> again we obtain a DSA/SHA512 sig without warnings, thus violating the > >> preferences of both recipients. > > > > Not a bug, just a no-way-out situation. You told GPG to sign using a > > q=256 key, so the hash has to be 256 bits or larger. At the same > > time, you told GPG that it had to use either SHA1 or RIPEMD160, both > > of which are 160 bits. In the case where GPG simply cannot come up > > with a hash that pleases everyone, it goes with what the signing key > > is capable of (i.e. 256 or larger) joined with your > > personal-digest-prefs. Thus it chose SHA512: larger than 256 bits so > > the signing key was happy, and 512 because you listed it first. > > > > I sympathize about the desire for a warning message here, but remember > > that this would mean a warning message for almost every signature made > > with a DSA2 key. Any time you have a DSA2 key signing and encrypting > > to an older key without SHA256 (which are a significant majority of > > keys at this point) you would get a warning. In such a situation, > > warnings become meaningless. > > > How many people genuinely can't handle SHA256? Only pre-PGP 8 users? Yes, and pre-GnuPG 1.4 users as well. However, the problem in this particular case is not so much that they can't handle SHA256, it's that their key may not have a preference for SHA256. It's also more than just SHA256 support - if the recipient can't handle DSA2 signatures, then it doesn't matter if they have SHA256 or not. At the moment, the only implementation that is confirmed to work with DSA2 signatures is GPG 1.4.3. David From lists at lina.inka.de Tue Jun 6 02:20:30 2006 From: lists at lina.inka.de (Bernd Eckenfels) Date: Tue Jun 6 03:56:00 2006 Subject: DSA2 and recipient preferences In-Reply-To: <20060603220023.GA32267@jabberwocky.com> References: <4481F206.3060201@tiscali.it> <20060603220023.GA32267@jabberwocky.com> Message-ID: <20060606002030.GA11425@lina.inka.de> On Sat, Jun 03, 2006 at 06:00:23PM -0400, David Shaw wrote: > With DSA2, the recipient may not have *any* of the digests needed by > the sender. The choice then becomes to let the sender pick a digest > the recipient can't handle, or... don't sign at all. Maybe a "bahaviour_on_digestdowngrade = _accept_ | warn | abort" option? Or make people add the sha1 fallback to the allowed algos if they dont want the warning... Gruss Bernd From mb at g10code.com Sat Jun 3 00:52:22 2006 From: mb at g10code.com (Marcus Brinkmann) Date: Thu Jun 8 10:42:42 2006 Subject: [Announce] Gpg4win 1.0.2 released Message-ID: <87odxbf9w9.wl%marcus.brinkmann@ruhr-uni-bochum.de> Hi! We are pleased to announce the availibility of Gpg4win, version 1.0.2. The gpg4win project aims at updating the gpg4win Windows installation package with GnuPG encryption tool, associated applications and documentation on a regular basis. Especially the documentation (handbooks "Einsteiger" and "Durchblicker") are directly maintained as part of the gpg4win project. It is an international project. Due to the origin of the project the German language is fully supported. As of now the the handbooks are only available in German. People helping with translations are very welcome! The main difference compared to all other similar approaches (mainly GnuPP, GnuPT, Windows Privacy Tools and GnuPG-Basics) is that the first thing developed was the *gpg4win-Builder*. This builder allows to easily create new gpg4win.exe installers with updated components. The builder runs on any decent Unix system, preferable Debian GNU/Linux. Almost all products are automatically cross-compiled for integration into the installer. With this concept it is hoped to *prevent quick aging of the* *installer package*. This is due to easier updating and less dependancy on single developers. Noteworthy changes in version 1.0.2 (2006-05-30) ------------------------------------------------ * Fixed a bug in GPA which led to a non-working backup on some Windows systems. * Updated Sylpheed-Claws to the latest stable version. * Included components are: GnuPG: 1.4.3 WinPT: 0.12.1 [*] GPA: 0.7.3 GPGol: 0.9.10 GPGee: 1.3.1 Sylpheed-Claws: 2.2.0 [*] Einsteiger: 2.0.2 [*] Durchblicker: 2.0.2 [*] (Marked packages are updated since the last release) For installation instuctions, please visit http://www.gpg4win.org or read on. Developers who want to *build an installer* need to get the following files from http://wald.intevation.org/projects/gpg4win/ : gpg4win-1.0.2.tar.bz2 (3.9M) gpg4win-1.0.2.tar.bz2.sig The second file is a digital signature of the the first file. Either check that this signature is fine or compare with the checksums given below. (see also http://www.gnupg.org/download/integrity_check.html) The *ready to use installer* is available at: http://ftp.gpg4win.org/gpg4win-1.0.2.exe (6.2M) http://ftp.gpg4win.org/gpg4win-1.0.2.exe.sig Or using the ftp protocol at: ftp://ftp.gpg4win.org/gpg4win/gpg4win-1.0.2.exe (6.2M) ftp://ftp.gpg4win.org/gpg4win/gpg4win-1.0.2.exe.sig SHA1 and MD5 checksums for these files are given below. If you don't need the German PDF manuals, you might alternatively download the "light" version of the installer: http://ftp.gpg4win.org/gpg4win-light-1.0.2.exe (4.6M) http://ftp.gpg4win.org/gpg4win-light- 1.0.2.exe.sig or using the ftp protocol at: ftp://ftp.gpg4win.org/gpg4win/gpg4win-1.0.2.exe (4.6M) ftp://ftp.gpg4win.org/gpg4win/gpg4win-1.0.2.exe.sig A separate installer with the the sources used to build the above installer is available at: ftp://ftp.gpg4win.org/gpg4win/gpg4win-src-1.0.2.exe (41M) ftp://ftp.gpg4win.org/gpg4win/gpg4win-src-1.0.2.exe.sig Most people don't need this source installer; it is merely stored on that server to satisfy the conditions of the GPL. In general it is better to get the gpg4win builder tarball (see above) and follow the instructions in the README to build new installers; building the installer is not possible on Windows machines and works best on current Debian GNU/Linux systems (we use the mingw32 package from Sid). SHA1 checksums are: 8d4aa1799096da33c8e961f44e5b5ceff0fc6647 gpg4win-1.0.2.exe ed93fc55e3cb221f2b0e0b96c660fb7d87f490bb gpg4win-light-1.0.2.exe 1d82a8f54819d487f6078aab4343fefa24504aa4 gpg4win-src-1.0.2.exe caa3c502645ece898281ca2f47cff4ce81657d0c gpg4win-1.0.2.tar.bz2 MD5 checksums are: ce25314e788c0434ead74cfe0662f6c5 gpg4win-1.0.2.exe 9886cbb42200393be5f3e0d019ee31ba gpg4win-light-1.0.2.exe c216828825d606dcdfe9e1b70cb3fcc7 gpg4win-src-1.0.2.exe 20f0588c5777cbe7834d751175fe98e2 gpg4win-1.0.2.tar.bz2 We like to thank the authors of the included packages, the NSIS authors, all other contributors and first of all, those folks who stayed with us and tested the early releases of gpg4win. Happy hacking, Jan, Marcus, Timo and Werner -- Marcus Brinkmann The GnuPG Experts http://g10code.com Join the Fellowship and protect your Freedom! http://www.fsfe.org _______________________________________________ Gnupg-announce mailing list Gnupg-announce@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From niki.waibel at wipro.com Wed Jun 7 19:32:15 2006 From: niki.waibel at wipro.com (Niki W Waibel) Date: Thu Jun 8 10:42:50 2006 Subject: libassuan-0.6.10 -- does not compile on solaris (yet) Message-ID: <20060607193215.eda29f6e.niki.waibel@wipro.com> hi, not subscribed to any gnupg list, so i am not sure if this email makes it through ... compiling libassuan on solaris produces the following: === if gcc -DHAVE_CONFIG_H -I. -I/tmp/libassuan-0.6.10/src -I.. -I.. -I/tmp/libassuan-0.6.10/include -I/misc/sparc-sun-solaris2.10/include -Wall -O3 -I/misc/sparc-sun-solaris2.10/include -Wall -Wcast-align -Wshadow -Wstrict-prototypes -MT assuan-logging.o -MD -MP -MF ".deps/assuan-logging.Tpo" -c -o assuan-logging.o assuan-logging.c; \ then mv -f ".deps/assuan-logging.Tpo" ".deps/assuan-logging.Po"; else rm -f ".deps/assuan-logging.Tpo"; exit 1; fi assuan-domain-connect.c: In function 'domain_reader': assuan-domain-connect.c:118: error: 'struct msghdr' has no member named 'msg_control' assuan-domain-connect.c:119: error: 'struct msghdr' has no member named 'msg_controllen' assuan-domain-connect.c:139: error: 'struct msghdr' has no member named 'msg_flags' assuan-domain-connect.c:171: error: 'struct msghdr' has no member named 'msg_control' assuan-domain-connect.c:172: error: 'struct msghdr' has no member named 'msg_controllen' assuan-domain-connect.c:195: error: 'struct msghdr' has no member named 'msg_controllen' assuan-domain-connect.c:210: warning: implicit declaration of function 'CMSG_DATA' assuan-domain-connect.c: In function 'domain_writer': assuan-domain-connect.c:257: error: 'struct msghdr' has no member named 'msg_control' assuan-domain-connect.c:258: error: 'struct msghdr' has no member named 'msg_controllen' assuan-domain-connect.c: In function 'domain_sendfd': assuan-domain-connect.c:299: error: 'struct msghdr' has no member named 'msg_control' assuan-domain-connect.c:300: error: 'struct msghdr' has no member named 'msg_controllen' make[3]: *** [assuan-domain-connect.o] Error 1 make[3]: *** Waiting for unfinished jobs.... make[3]: Leaving directory `/tmp/libassuan-0.6.10/src' make[2]: *** [all] Error 2 make[2]: Leaving directory `/tmp/libassuan-0.6.10/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/tmp/libassuan-0.6.10' make: *** [all] Error 2 === the same problem was found some days ;-) ago in wine: http://www.winehq.org/pipermail/wine-patches/2002-May/002436.html unfort i am in a hurry and i cannot write a patch (yet). rds, niki The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com From dirk.traulsen at lypso.de Thu Jun 8 11:20:34 2006 From: dirk.traulsen at lypso.de (Dirk Traulsen) Date: Thu Jun 8 12:55:59 2006 Subject: bug report: problems with import of secret keys with old prefs Message-ID: <44880802.31741.1A5D7C78@dirk.traulsen.lypso.de> Hi, I've found a bug during the import of secret keys. Scenario: gpg 1.4.3 on WinXP File 'export-sec.asc' contains 4 secret keys: 2EDFB41E Dirk Traulsen (dtg-1) B853D346 Dirk Traulsen CDDB9911 Dirk Traulsen (dtl-2) 5CCF925A Dirk Traulsen (dtl-1) Key number 2 is an old key with very old preferences (S3 S2 S1). Upon import of 'export-sec.asc' gpg tries to update the preferences and comes into trouble! As I tested, this is independant of 1. the presence of the files secring.gpg and pubring.gpg, 2. the presence of other keys in the keyring, 3. the presence of the corresponding public keys, 4. the armoring or not armoring of the file to import or 5. the locale. (This time I checked this with Lang=de and en.) After importing the first key, gpg finds the unpleasing preferences on the second key and asks for remedy. When I refuse to update the prefs, gpg prints "Key not changed so no update needed." and I get asked the same question again. (Bug#1 or peeving feature?) For the rest it doesn't matter whether I change the prefs or not. gpg doesn't succed in making secring.tmp the new secring.gpg (bug#2). secring.tmp stays in the directory and gpg breaks off the import, but not after generating and importing the public key of key number 3. Now I have the keys number 1+2 in both keyrings, key number 3 only in pubring.gpg and an additional file secring.tmp. When I start the import again, everything goes fine and secring.tmp gets deleted. Hope this helps, Dirk ===== Screencopy ========================================== C:\Dokumente und Einstellungen\Dirk>gpg --import export-sec.asc gpg: key 2EDFB41E: secret key imported gpg: key 2EDFB41E: public key "Dirk Traulsen (dtg-1) " imported gpg: key B853D346: secret key imported gpg: key B853D346: public key "Dirk Traulsen " imported gpg: WARNING: key B853D346 contains preferences for unavailable algorithms on these user IDs: gpg: "Dirk Traulsen ": preference for cipher algorithm 1 gpg: it is strongly suggested that you update your preferences and gpg: re-distribute this key to avoid potential algorithm mismatch problems Set preference list to: Cipher: AES256, AES192, AES, CAST5, 3DES Digest: SHA1, SHA256, RIPEMD160 Compression: ZLIB, BZIP2, ZIP, Uncompressed Features: MDC, Keyserver no-modify Really update the preferences? (y/N) n Key not changed so no update needed. gpg: WARNING: key B853D346 contains preferences for unavailable algorithms on these user IDs: gpg: "Dirk Traulsen ": preference for cipher algorithm 1 gpg: it is strongly suggested that you update your preferences and gpg: re-distribute this key to avoid potential algorithm mismatch problems Set preference list to: Cipher: AES256, AES192, AES, CAST5, 3DES Digest: SHA1, SHA256, RIPEMD160 Compression: ZLIB, BZIP2, ZIP, Uncompressed Features: MDC, Keyserver no-modify Really update the preferences? (y/N) n Key not changed so no update needed. gpg: renaming `C:/Dokumente und Einstellungen/Dirk /Anwendungsdaten/gnupg\secring.tmp' to `C:/Dokumente und Einstellungen/Dirk/Anwendungsdaten/gnupg\secring.gpg' failed: File exists gpg: WARNING: 2 files with confidential information exists. gpg: C:/Dokumente und Einstellungen/Dirk /Anwendungsdaten/gnupg\secring.gpg is the unchanged one gpg: C:/Dokumente und Einstellungen/Dirk /Anwendungsdaten/gnupg\secring.tmp is the new one gpg: Please fix this possible security flaw gpg: error writing keyring `C:/Dokumente und Einstellungen/Dirk/Anwendungsdaten/ gnupg\secring.gpg': file rename error gpg: key CDDB9911: secret key imported gpg: key CDDB9911: public key "Dirk Traulsen (dtl-2) " imported gpg: error reading `export-sec.asc': file rename error gpg: import from `export-sec.asc' failed: file rename error gpg: Total number processed: 2 gpg: imported: 3 gpg: secret keys read: 3 gpg: secret keys imported: 3 C:\Dokumente und Einstellungen\Dirk>gpg -K C:/Dokumente und Einstellungen/Dirk/Anwendungsdaten/gnupg\secring.gpg --------------------------------------------------------------------- sec 1024D/2EDFB41E 1998-11-04 uid Dirk Traulsen (dtg-1) ssb 4096g/0B9DCED2 1998-11-04 ssb 1024D/0A77A149 2005-10-21 sec 1024D/B853D346 1998-04-10 uid Dirk Traulsen ssb 4096g/9C1C598E 1998-04-10 C:\Dokumente und Einstellungen\Dirk>gpg -k C:/Dokumente und Einstellungen/Dirk/Anwendungsdaten/gnupg\pubring.gpg --------------------------------------------------------------------- pub 1024D/2EDFB41E 1998-11-04 uid Dirk Traulsen (dtg-1) sub 4096g/0B9DCED2 1998-11-04 sub 1024D/0A77A149 2005-10-21 pub 1024D/B853D346 1998-04-10 uid Dirk Traulsen sub 4096g/9C1C598E 1998-04-10 pub 1024D/CDDB9911 2005-10-18 uid Dirk Traulsen (dtl-2) uid Dirk Traulsen sub 4096g/E192093D 2005-10-21 sub 1024D/770BEF07 2005-10-21 C:\Dokumente und Einstellungen\Dirk>gpg --import export-sec.asc gpg: key 2EDFB41E: already in secret keyring gpg: key B853D346: already in secret keyring gpg: key CDDB9911: secret key imported gpg: key CDDB9911: "Dirk Traulsen (dtl-2) " not changed gpg: key 5CCF925A: secret key imported gpg: key 5CCF925A: public key "Dirk Traulsen (dtl-1) " imported gpg: Total number processed: 4 gpg: imported: 1 gpg: unchanged: 1 gpg: secret keys read: 4 gpg: secret keys imported: 2 gpg: secret keys unchanged: 2 C:\Dokumente und Einstellungen\Dirk>gpg -K C:/Dokumente und Einstellungen/Dirk/Anwendungsdaten/gnupg\secring.gpg --------------------------------------------------------------------- sec 1024D/2EDFB41E 1998-11-04 uid Dirk Traulsen (dtg-1) ssb 4096g/0B9DCED2 1998-11-04 ssb 1024D/0A77A149 2005-10-21 sec 1024D/B853D346 1998-04-10 uid Dirk Traulsen ssb 4096g/9C1C598E 1998-04-10 sec 1024D/CDDB9911 2005-10-18 uid Dirk Traulsen (dtl-2) uid Dirk Traulsen ssb 4096g/E192093D 2005-10-21 ssb 1024D/770BEF07 2005-10-21 sec 1024D/5CCF925A 2004-12-14 uid Dirk Traulsen (dtl-1) ssb 4096g/743DD3E2 2004-12-14 C:\Dokumente und Einstellungen\Dirk>gpg -k C:/Dokumente und Einstellungen/Dirk/Anwendungsdaten/gnupg\pubring.gpg --------------------------------------------------------------------- pub 1024D/2EDFB41E 1998-11-04 uid Dirk Traulsen (dtg-1) sub 4096g/0B9DCED2 1998-11-04 sub 1024D/0A77A149 2005-10-21 pub 1024D/B853D346 1998-04-10 uid Dirk Traulsen sub 4096g/9C1C598E 1998-04-10 pub 1024D/CDDB9911 2005-10-18 uid Dirk Traulsen (dtl-2) uid Dirk Traulsen sub 4096g/E192093D 2005-10-21 sub 1024D/770BEF07 2005-10-21 pub 1024D/5CCF925A 2004-12-14 uid Dirk Traulsen (dtl-1) sub 4096g/743DD3E2 2004-12-14 From niki.waibel at wipro.com Fri Jun 9 17:04:25 2006 From: niki.waibel at wipro.com (Niki W Waibel) Date: Fri Jun 9 17:04:12 2006 Subject: libassuan-0.6.10 -- does not compile on solaris (yet) In-Reply-To: <20060607193215.eda29f6e.niki.waibel@wipro.com> References: <20060607193215.eda29f6e.niki.waibel@wipro.com> Message-ID: <20060609170425.67fe0fcc.niki.waibel@wipro.com> ok, i've found some time. attached there are two patches that fix the solaris compile issue (possably also for other platforms). libassuan-0.6.10.nww-wo-autoconf.patch.gz patches only configure.ac and src/assuan-domain-connect.c you have to run autoheader, aclocal and autoconf afterwards libassuan-0.6.10.nww.patch.gz patches the files aclocal.m4 config.h.in configure configure.ac src/assuan-domain-connect.c so there is no more need for the auto*-tools. (i've used autoconf-2.59b, automake-1.9.6) by the way, 0.6.9 compiled fine, although it was using those members as well... this is what solaris (8/9/10) defines (in sys/socket.h): === struct msghdr { void *msg_name; /* optional address */ socklen_t msg_namelen; /* size of address */ struct iovec *msg_iov; /* scatter/gather array */ int msg_iovlen; /* # elements in msg_iov */ #if defined(_XPG4_2) || defined(_KERNEL) void *msg_control; /* ancillary data */ socklen_t msg_controllen; /* ancillary data buffer len */ int msg_flags; /* flags on received message */ #else caddr_t msg_accrights; /* access rights sent/received */ int msg_accrightslen; #endif /* defined(_XPG4_2) || defined(_KERNEL) */ }; === so i guess when compiling 0.6.9, _XPG4_2 is defined for some reason. anyway, the check for the member in the struct is a good thing imho. maybe i can find out what's going on with _XPG4_2. if so, i'll keep you posted. rds, niki On Wed, 7 Jun 2006 19:32:15 +0200 Niki W Waibel wrote: > hi, not subscribed to any gnupg list, so i am not > sure if this email makes it through ... > > compiling libassuan on solaris produces the following: > === > if gcc -DHAVE_CONFIG_H -I. -I/tmp/libassuan-0.6.10/src -I.. -I.. -I/tmp/libassuan-0.6.10/include -I/misc/sparc-sun-solaris2.10/include -Wall -O3 -I/misc/sparc-sun-solaris2.10/include -Wall -Wcast-align -Wshadow -Wstrict-prototypes -MT assuan-logging.o -MD -MP -MF ".deps/assuan-logging.Tpo" -c -o assuan-logging.o assuan-logging.c; \ > then mv -f ".deps/assuan-logging.Tpo" ".deps/assuan-logging.Po"; else rm -f ".deps/assuan-logging.Tpo"; exit 1; fi > assuan-domain-connect.c: In function 'domain_reader': > assuan-domain-connect.c:118: error: 'struct msghdr' has no member named 'msg_control' > assuan-domain-connect.c:119: error: 'struct msghdr' has no member named 'msg_controllen' > assuan-domain-connect.c:139: error: 'struct msghdr' has no member named 'msg_flags' > assuan-domain-connect.c:171: error: 'struct msghdr' has no member named 'msg_control' > assuan-domain-connect.c:172: error: 'struct msghdr' has no member named 'msg_controllen' > assuan-domain-connect.c:195: error: 'struct msghdr' has no member named 'msg_controllen' > assuan-domain-connect.c:210: warning: implicit declaration of function 'CMSG_DATA' > assuan-domain-connect.c: In function 'domain_writer': > assuan-domain-connect.c:257: error: 'struct msghdr' has no member named 'msg_control' > assuan-domain-connect.c:258: error: 'struct msghdr' has no member named 'msg_controllen' > assuan-domain-connect.c: In function 'domain_sendfd': > assuan-domain-connect.c:299: error: 'struct msghdr' has no member named 'msg_control' > assuan-domain-connect.c:300: error: 'struct msghdr' has no member named 'msg_controllen' > make[3]: *** [assuan-domain-connect.o] Error 1 > make[3]: *** Waiting for unfinished jobs.... > make[3]: Leaving directory `/tmp/libassuan-0.6.10/src' > make[2]: *** [all] Error 2 > make[2]: Leaving directory `/tmp/libassuan-0.6.10/src' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/tmp/libassuan-0.6.10' > make: *** [all] Error 2 > === > > the same problem was found some days ;-) ago in wine: > http://www.winehq.org/pipermail/wine-patches/2002-May/002436.html > > unfort i am in a hurry and i cannot write a patch (yet). > > rds, niki -- Niki W. Waibel System Administrator NewLogic - A Wipro Company The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com -------------- next part -------------- A non-text attachment was scrubbed... Name: libassuan-0.6.10.nww.patch.gz Type: application/octet-stream Size: 17200 bytes Desc: not available Url : /pipermail/attachments/20060609/1ada8587/libassuan-0.6.10.nww.patch-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: libassuan-0.6.10.nww-wo-autoconf.patch.gz Type: application/octet-stream Size: 1585 bytes Desc: not available Url : /pipermail/attachments/20060609/1ada8587/libassuan-0.6.10.nww-wo-autoconf.patch-0001.obj From marcus.brinkmann at ruhr-uni-bochum.de Sun Jun 11 12:36:03 2006 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Sun Jun 11 12:38:22 2006 Subject: libassuan-0.6.10 -- does not compile on solaris (yet) In-Reply-To: <20060609170425.67fe0fcc.niki.waibel@wipro.com> References: <20060607193215.eda29f6e.niki.waibel@wipro.com> <20060609170425.67fe0fcc.niki.waibel@wipro.com> Message-ID: <878xo4f08c.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Fri, 9 Jun 2006 17:04:25 +0200, Niki W Waibel wrote: > ok, i've found some time. In the meantime, we also had another reporter who worked through this with us, plus, we found out that I already fixed this in the repository in last october and forgot about it! Can you try the latest repository version of libassuan? It worked for somebody else on Solaris. I will make a new release very soon. Thanks, Marcus From dshaw at jabberwocky.com Sun Jun 11 14:55:04 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Sun Jun 11 14:54:05 2006 Subject: DSA2 and recipient preferences In-Reply-To: <20060606002030.GA11425@lina.inka.de> References: <4481F206.3060201@tiscali.it> <20060603220023.GA32267@jabberwocky.com> <20060606002030.GA11425@lina.inka.de> Message-ID: <20060611125504.GD15370@jabberwocky.com> On Tue, Jun 06, 2006 at 02:20:30AM +0200, Bernd Eckenfels wrote: > On Sat, Jun 03, 2006 at 06:00:23PM -0400, David Shaw wrote: > > With DSA2, the recipient may not have *any* of the digests needed by > > the sender. The choice then becomes to let the sender pick a digest > > the recipient can't handle, or... don't sign at all. > > Maybe a "bahaviour_on_digestdowngrade = _accept_ | warn | abort" option? Or > make people add the sha1 fallback to the allowed algos if they dont want the > warning... It's not a question about having people allow SHA1. The algorithm itself cannot function with SHA1. SHA1 is unusable in DSA2. David From alex at bofh.net.pl Wed Jun 14 12:29:03 2006 From: alex at bofh.net.pl (Janusz A. Urbanowicz) Date: Wed Jun 14 12:27:52 2006 Subject: multiple copies of the self-signature on the key Message-ID: <20060614102902.GT22113@hell.pl> Hi, I am under an impression I reported that some time (~2 years) ago: I have a setup where I send (and update) my pubkey to remote amchines by downloading it from the keyserver network. Over time, preferences are updated, subkeys are crosscertified. And new and new self-signatures deposite on the key with old not being flushed. What can I do with that? This is my key after several updates on one machine: pub 4096R/46399138 2002-08-16 uid Janusz A. Urbanowicz sig F9289982 2002-10-16 [User ID not found] sig DD9683CE 2002-12-15 [User ID not found] sig 1D25E357 2005-04-16 [User ID not found] sig 2 5B38FF7C 2003-03-14 [User ID not found] sig 2 44ABAF32 2003-03-14 [User ID not found] sig 2 68FD549F 2004-12-02 [User ID not found] sig 3 21939169 2002-09-17 [User ID not found] sig 3 FC494FC4 2002-10-20 [User ID not found] sig 3 DEB0EC31 2002-10-22 [User ID not found] sig 3 A3F8F7F1 2002-12-15 [User ID not found] sig 3 337844C9 2003-03-13 [User ID not found] sig 3 B06901F1 2003-03-13 [User ID not found] sig 3 7C52AC99 2003-03-14 [User ID not found] sig 3 CF82F829 2003-08-01 [User ID not found] sig 3 46399138 2002-08-24 Janusz A. Urbanowicz sig 3 46399138 2002-08-24 Janusz A. Urbanowicz sig 3 46399138 2002-08-24 Janusz A. Urbanowicz sig 3 46399138 2002-08-24 Janusz A. Urbanowicz sig 3 46399138 2005-02-05 Janusz A. Urbanowicz sig 3 46390910 2005-02-05 [User ID not found] sig 3 46399138 2005-02-05 Janusz A. Urbanowicz uid Janusz A. Urbanowicz sig F9289982 2002-10-16 [User ID not found] sig DD9683CE 2002-12-15 [User ID not found] sig 1D25E357 2005-04-16 [User ID not found] sig 2 5B38FF7C 2003-03-14 [User ID not found] sig 2 44ABAF32 2003-03-14 [User ID not found] sig 2 68FD549F 2004-12-02 [User ID not found] sig 3 21939169 2002-09-17 [User ID not found] sig 3 FC494FC4 2002-10-20 [User ID not found] sig 3 DEB0EC31 2002-10-22 [User ID not found] sig 3 A3F8F7F1 2002-12-15 [User ID not found] sig 3 337844C9 2003-03-13 [User ID not found] sig 3 B06901F1 2003-03-13 [User ID not found] sig 3 7C52AC99 2003-03-14 [User ID not found] sig 3 CF82F829 2003-08-01 [User ID not found] sig 3 46399138 2002-08-16 Janusz A. Urbanowicz sig 3 46399138 2002-08-16 Janusz A. Urbanowicz sig 3 46399138 2002-08-16 Janusz A. Urbanowicz sig 3 46399138 2002-08-16 Janusz A. Urbanowicz sig 3 46399138 2002-08-16 Janusz A. Urbanowicz sig 3 46399138 2002-08-16 Janusz A. Urbanowicz sig 3 46399138 2005-02-05 Janusz A. Urbanowicz sig 3 46390910 2005-02-05 [User ID not found] sig 3 46399138 2005-02-05 Janusz A. Urbanowicz sig 3 46399138 2005-02-05 Janusz A. Urbanowicz uid Janusz A. Urbanowicz sig F9289982 2002-10-16 [User ID not found] sig DD9683CE 2002-12-15 [User ID not found] sig 1D25E357 2005-04-16 [User ID not found] sig 2 5B38FF7C 2003-03-14 [User ID not found] sig 2 44ABAF32 2003-03-14 [User ID not found] sig 2 68FD549F 2004-12-02 [User ID not found] sig 3 21939169 2002-09-17 [User ID not found] sig 3 FC494FC4 2002-10-20 [User ID not found] sig 3 DEB0EC31 2002-10-22 [User ID not found] sig 3 A3F8F7F1 2002-12-15 [User ID not found] sig 3 337844C9 2003-03-13 [User ID not found] sig 3 B06901F1 2003-03-13 [User ID not found] sig 3 7C52AC99 2003-03-14 [User ID not found] sig 3 CF82F829 2003-08-01 [User ID not found] sig 3 46399138 2002-08-17 Janusz A. Urbanowicz sig 3 46399138 2002-08-17 Janusz A. Urbanowicz sig 3 46399138 2002-08-17 Janusz A. Urbanowicz sig 3 46399138 2002-08-17 Janusz A. Urbanowicz sig 3 46399138 2005-02-05 Janusz A. Urbanowicz sig 3 46390910 2005-02-05 [User ID not found] sig 3 46399138 2005-02-05 Janusz A. Urbanowicz sub 1024D/DFDE4DCE 2002-08-16 sig 46399138 2002-08-16 Janusz A. Urbanowicz sig 46399138 2006-06-12 Janusz A. Urbanowicz sub 2048g/E43F90B3 2002-08-16 sig 46399138 2002-08-16 Janusz A. Urbanowicz From dshaw at jabberwocky.com Wed Jun 14 14:05:22 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Wed Jun 14 14:04:15 2006 Subject: multiple copies of the self-signature on the key In-Reply-To: <20060614102902.GT22113@hell.pl> References: <20060614102902.GT22113@hell.pl> Message-ID: <20060614120522.GA26165@jabberwocky.com> On Wed, Jun 14, 2006 at 12:29:03PM +0200, Janusz A. Urbanowicz wrote: > Hi, I am under an impression I reported that some time (~2 years) ago: > > I have a setup where I send (and update) my pubkey to remote amchines > by downloading it from the keyserver network. Over time, preferences > are updated, subkeys are crosscertified. And new and new > self-signatures deposite on the key with old not being flushed. What > can I do with that? You can't stop the keyservers from storing all copies of your selfsig. They have no crypto support so have no way to tell which (if any) is the "right" one to keep. In GPG, if you set: import-options import-clean keyserver-options import-clean You'll automatically strip out the unusable selfsigs (as well as unusable other stuff like multiple expired signatures) upon import. You can do the same on a key by key basis with --edit-key and the "clean" command. David From alex at bofh.net.pl Wed Jun 14 14:20:20 2006 From: alex at bofh.net.pl (Janusz A. Urbanowicz) Date: Wed Jun 14 14:19:13 2006 Subject: multiple copies of the self-signature on the key In-Reply-To: <20060614120522.GA26165@jabberwocky.com> References: <20060614102902.GT22113@hell.pl> <20060614120522.GA26165@jabberwocky.com> Message-ID: <20060614122019.GU22113@hell.pl> On Wed, Jun 14, 2006 at 08:05:22AM -0400, David Shaw wrote: > On Wed, Jun 14, 2006 at 12:29:03PM +0200, Janusz A. Urbanowicz wrote: > > Hi, I am under an impression I reported that some time (~2 years) ago: > > > > I have a setup where I send (and update) my pubkey to remote amchines > > by downloading it from the keyserver network. Over time, preferences > > are updated, subkeys are crosscertified. And new and new > > self-signatures deposite on the key with old not being flushed. What > > can I do with that? > > You can't stop the keyservers from storing all copies of your > selfsig. They have no crypto support so have no way to tell which (if > any) is the "right" one to keep. the latest one by timestamp? just a thought a From dshaw at jabberwocky.com Wed Jun 14 14:24:17 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Wed Jun 14 14:23:08 2006 Subject: multiple copies of the self-signature on the key In-Reply-To: <20060614122019.GU22113@hell.pl> References: <20060614102902.GT22113@hell.pl> <20060614120522.GA26165@jabberwocky.com> <20060614122019.GU22113@hell.pl> Message-ID: <20060614122417.GF25902@jabberwocky.com> On Wed, Jun 14, 2006 at 02:20:20PM +0200, Janusz A. Urbanowicz wrote: > On Wed, Jun 14, 2006 at 08:05:22AM -0400, David Shaw wrote: > > On Wed, Jun 14, 2006 at 12:29:03PM +0200, Janusz A. Urbanowicz wrote: > > > Hi, I am under an impression I reported that some time (~2 years) ago: > > > > > > I have a setup where I send (and update) my pubkey to remote amchines > > > by downloading it from the keyserver network. Over time, preferences > > > are updated, subkeys are crosscertified. And new and new > > > self-signatures deposite on the key with old not being flushed. What > > > can I do with that? > > > > You can't stop the keyservers from storing all copies of your > > selfsig. They have no crypto support so have no way to tell which (if > > any) is the "right" one to keep. > > the latest one by timestamp? > > just a thought Without crypto support, how is the keyserver to know that the nice new signature with a later timestamp is in fact a real signature and not garbage? It would be a perfect denial-of-service attack to upload bogus selfsignatures and then sit back and watch the keyserver erase parts of the key. GPG can do this because it can actually verify the signatures and check. Keyservers are just storage and cannot verify. David From jvender at owensboro.net Thu Jun 15 22:35:11 2006 From: jvender at owensboro.net (Joe Vender) Date: Thu Jun 15 23:56:00 2006 Subject: key generation question Message-ID: <44917E2F.20408.8FC6A@jvender.owensboro.net> Question: Is it possible - and if so, how - to generate an RSA key in which the size of the key is a prime number? For example, a key size of 4013, 4051, etc. ? Every time I try to use a prime number for the key size, PGP rounds the size up to a non-prime number. Why will it not generate a key of ANY size between 1024-4096? From alex at bofh.net.pl Fri Jun 16 11:30:54 2006 From: alex at bofh.net.pl (Janusz A. Urbanowicz) Date: Fri Jun 16 11:30:08 2006 Subject: key generation question In-Reply-To: <44917E2F.20408.8FC6A@jvender.owensboro.net> References: <44917E2F.20408.8FC6A@jvender.owensboro.net> Message-ID: <20060616093054.GA30344@hell.pl> On Thu, Jun 15, 2006 at 03:35:11PM -0500, Joe Vender wrote: > Question: > Is it possible - and if so, how - to generate an RSA key in which the > size of the key is a prime number? For example, a key size of 4013, > 4051, etc. ? Every time I try to use a prime number for the key size, > PGP rounds the size up to a non-prime number. Why will it not > generate a key of ANY size between 1024-4096? have you tried --expert mode? From ametzler at debian.org Thu Jun 15 16:06:54 2006 From: ametzler at debian.org (Andreas Metzler) Date: Fri Jun 16 11:54:14 2006 Subject: [libksba] Please update copyright statements. Message-ID: <20060615140654.GA22701@downhill.aus.cc> Hej, I do hope this is the correct contact point for libkspa, it seemed to be a likely one. ;-) The copyright statements in libkspa (even in svn) currently look like this: ------------- * Copyright (C) 2001, 2002, 2003, 2004, 2005 g10 Code GmbH * * This file is part of KSBA. * * KSBA is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by [...] * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA */ ------------- However the FSF has a new address nowadays, the respective stanza should say * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA */ (See ./configure.) thanks, cu andreas -- The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal vision of the emperor's, and its inclusion in this work does not constitute tacit approval by the author or the publisher for any such projects, howsoever undertaken. (c) Jasper Ffforde -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : /pipermail/attachments/20060615/f4f42a70/attachment.pgp From alex at bofh.net.pl Fri Jun 16 12:09:08 2006 From: alex at bofh.net.pl (Janusz A. Urbanowicz) Date: Fri Jun 16 12:07:53 2006 Subject: multiple copies of the self-signature on the key In-Reply-To: <20060614122417.GF25902@jabberwocky.com> References: <20060614102902.GT22113@hell.pl> <20060614120522.GA26165@jabberwocky.com> <20060614122019.GU22113@hell.pl> <20060614122417.GF25902@jabberwocky.com> Message-ID: <20060616100908.GB30344@hell.pl> On Wed, Jun 14, 2006 at 08:24:17AM -0400, David Shaw wrote: > On Wed, Jun 14, 2006 at 02:20:20PM +0200, Janusz A. Urbanowicz wrote: > > On Wed, Jun 14, 2006 at 08:05:22AM -0400, David Shaw wrote: > > > On Wed, Jun 14, 2006 at 12:29:03PM +0200, Janusz A. Urbanowicz wrote: > > > > Hi, I am under an impression I reported that some time (~2 years) ago: > > > > > > > > I have a setup where I send (and update) my pubkey to remote amchines > > > > by downloading it from the keyserver network. Over time, preferences > > > > are updated, subkeys are crosscertified. And new and new > > > > self-signatures deposite on the key with old not being flushed. What > > > > can I do with that? > > > > > > You can't stop the keyservers from storing all copies of your > > > selfsig. They have no crypto support so have no way to tell which (if > > > any) is the "right" one to keep. > > > > the latest one by timestamp? > > > > just a thought > > Without crypto support, how is the keyserver to know that the nice new > signature with a later timestamp is in fact a real signature and not > garbage? It would be a perfect denial-of-service attack to upload > bogus selfsignatures and then sit back and watch the keyserver erase > parts of the key. > > GPG can do this because it can actually verify the signatures and > check. Keyservers are just storage and cannot verify. So, why GPG doesn't do this on import? AFAIR PGP 2 did this automatically. Alex From dshaw at jabberwocky.com Fri Jun 16 14:11:18 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Fri Jun 16 14:10:20 2006 Subject: multiple copies of the self-signature on the key In-Reply-To: <20060616100908.GB30344@hell.pl> References: <20060614102902.GT22113@hell.pl> <20060614120522.GA26165@jabberwocky.com> <20060614122019.GU22113@hell.pl> <20060614122417.GF25902@jabberwocky.com> <20060616100908.GB30344@hell.pl> Message-ID: <20060616121118.GA31242@jabberwocky.com> On Fri, Jun 16, 2006 at 12:09:08PM +0200, Janusz A. Urbanowicz wrote: > On Wed, Jun 14, 2006 at 08:24:17AM -0400, David Shaw wrote: > > On Wed, Jun 14, 2006 at 02:20:20PM +0200, Janusz A. Urbanowicz wrote: > > > On Wed, Jun 14, 2006 at 08:05:22AM -0400, David Shaw wrote: > > > > On Wed, Jun 14, 2006 at 12:29:03PM +0200, Janusz A. Urbanowicz wrote: > > > > > Hi, I am under an impression I reported that some time (~2 years) ago: > > > > > > > > > > I have a setup where I send (and update) my pubkey to remote amchines > > > > > by downloading it from the keyserver network. Over time, preferences > > > > > are updated, subkeys are crosscertified. And new and new > > > > > self-signatures deposite on the key with old not being flushed. What > > > > > can I do with that? > > > > > > > > You can't stop the keyservers from storing all copies of your > > > > selfsig. They have no crypto support so have no way to tell which (if > > > > any) is the "right" one to keep. > > > > > > the latest one by timestamp? > > > > > > just a thought > > > > Without crypto support, how is the keyserver to know that the nice new > > signature with a later timestamp is in fact a real signature and not > > garbage? It would be a perfect denial-of-service attack to upload > > bogus selfsignatures and then sit back and watch the keyserver erase > > parts of the key. > > > > GPG can do this because it can actually verify the signatures and > > check. Keyservers are just storage and cannot verify. > > So, why GPG doesn't do this on import? AFAIR PGP 2 did this automatically. PGP 2 didn't store anything useful in the self-signature, so there were never more than one unless someone intentionally forced one to be there. In any event, GPG can do this on import, but it is optional. If you want it: keyserver-options import-clean David From alex at bofh.net.pl Fri Jun 16 15:01:20 2006 From: alex at bofh.net.pl (Janusz A. Urbanowicz) Date: Fri Jun 16 15:00:17 2006 Subject: multiple copies of the self-signature on the key In-Reply-To: <20060616121118.GA31242@jabberwocky.com> References: <20060614102902.GT22113@hell.pl> <20060614120522.GA26165@jabberwocky.com> <20060614122019.GU22113@hell.pl> <20060614122417.GF25902@jabberwocky.com> <20060616100908.GB30344@hell.pl> <20060616121118.GA31242@jabberwocky.com> Message-ID: <20060616130120.GA4061@hell.pl> On Fri, Jun 16, 2006 at 08:11:18AM -0400, David Shaw wrote: > > > Without crypto support, how is the keyserver to know that the nice new > > > signature with a later timestamp is in fact a real signature and not > > > garbage? It would be a perfect denial-of-service attack to upload > > > bogus selfsignatures and then sit back and watch the keyserver erase > > > parts of the key. > > > > > > GPG can do this because it can actually verify the signatures and > > > check. Keyservers are just storage and cannot verify. > > > > So, why GPG doesn't do this on import? AFAIR PGP 2 did this automatically. > > PGP 2 didn't store anything useful in the self-signature, so there > were never more than one unless someone intentionally forced one to be > there. > > In any event, GPG can do this on import, but it is optional. If you > want it: > > keyserver-options import-clean but this will clear all "unneeded stuff" from the keys imported and not only from my key? a From dshaw at jabberwocky.com Fri Jun 16 15:59:43 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Fri Jun 16 15:58:35 2006 Subject: multiple copies of the self-signature on the key In-Reply-To: <20060616130120.GA4061@hell.pl> References: <20060614102902.GT22113@hell.pl> <20060614120522.GA26165@jabberwocky.com> <20060614122019.GU22113@hell.pl> <20060614122417.GF25902@jabberwocky.com> <20060616100908.GB30344@hell.pl> <20060616121118.GA31242@jabberwocky.com> <20060616130120.GA4061@hell.pl> Message-ID: <20060616135943.GA12610@jabberwocky.com> On Fri, Jun 16, 2006 at 03:01:20PM +0200, Janusz A. Urbanowicz wrote: > On Fri, Jun 16, 2006 at 08:11:18AM -0400, David Shaw wrote: > > > > Without crypto support, how is the keyserver to know that the nice new > > > > signature with a later timestamp is in fact a real signature and not > > > > garbage? It would be a perfect denial-of-service attack to upload > > > > bogus selfsignatures and then sit back and watch the keyserver erase > > > > parts of the key. > > > > > > > > GPG can do this because it can actually verify the signatures and > > > > check. Keyservers are just storage and cannot verify. > > > > > > So, why GPG doesn't do this on import? AFAIR PGP 2 did this automatically. > > > > PGP 2 didn't store anything useful in the self-signature, so there > > were never more than one unless someone intentionally forced one to be > > there. > > > > In any event, GPG can do this on import, but it is optional. If you > > want it: > > > > keyserver-options import-clean > > but this will clear all "unneeded stuff" from the keys imported and not only > from my key? Yes. I have to confess I'm not sure what you are getting at here. What are you trying to do? David From JPClizbe at comcast.net Fri Jun 16 19:19:40 2006 From: JPClizbe at comcast.net (John Clizbe) Date: Fri Jun 16 19:24:57 2006 Subject: key generation question In-Reply-To: <44917E2F.20408.8FC6A@jvender.owensboro.net> References: <44917E2F.20408.8FC6A@jvender.owensboro.net> Message-ID: <4492E82C.3080604@comcast.net> Joe Vender wrote: > Question: > Is it possible - and if so, how - to generate an RSA key in which the > size of the key is a prime number? For example, a key size of 4013, > 4051, etc. ? Every time I try to use a prime number for the key size, > PGP rounds the size up to a non-prime number. Why will it not > generate a key of ANY size between 1024-4096? IIRC, the standards require keys to be multiples of 32 bits in length. Any value you specify will be rounded up to the next multiple of 32. If you specify a key length of 1025, you'll get 1056. -- John P. Clizbe Inet: JPClizbe(a)comcast DOT nyet Golden Bear Networks PGP/GPG KeyID: 0x608D2A10 "Be who you are and say what you feel because those who mind don't matter and those who matter don't mind." - Dr Seuss, "Oh the Places You'll Go" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 668 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20060616/102e6a5d/signature.pgp From alex at bofh.net.pl Sun Jun 18 17:30:38 2006 From: alex at bofh.net.pl (Janusz A. Urbanowicz) Date: Sun Jun 18 17:29:27 2006 Subject: multiple copies of the self-signature on the key In-Reply-To: <20060616135943.GA12610@jabberwocky.com> References: <20060614102902.GT22113@hell.pl> <20060614120522.GA26165@jabberwocky.com> <20060614122019.GU22113@hell.pl> <20060614122417.GF25902@jabberwocky.com> <20060616100908.GB30344@hell.pl> <20060616121118.GA31242@jabberwocky.com> <20060616130120.GA4061@hell.pl> <20060616135943.GA12610@jabberwocky.com> Message-ID: <20060618153038.GD4061@hell.pl> > Yes. I have to confess I'm not sure what you are getting at here. > What are you trying to do? I need to have unified copies/images of my pubkey key in various remote locations where: * contents of pubrings differ (so not all keys that signed my key are avaliable everywhere) * the copies of my key won't have a gazillion of self-signatures * unreferenced signatures on my key remain untouched * imported keys aren't stripped of anything that may be of use later Honestly, I thought that this is pretty obvious setup. I want to weed out unnecessary self-signatured and only unnecessary selfsignatures. Alex From dshaw at jabberwocky.com Sun Jun 18 21:27:43 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Sun Jun 18 21:26:33 2006 Subject: multiple copies of the self-signature on the key In-Reply-To: <20060618153038.GD4061@hell.pl> References: <20060614102902.GT22113@hell.pl> <20060614120522.GA26165@jabberwocky.com> <20060614122019.GU22113@hell.pl> <20060614122417.GF25902@jabberwocky.com> <20060616100908.GB30344@hell.pl> <20060616121118.GA31242@jabberwocky.com> <20060616130120.GA4061@hell.pl> <20060616135943.GA12610@jabberwocky.com> <20060618153038.GD4061@hell.pl> Message-ID: <20060618192743.GD13280@jabberwocky.com> On Sun, Jun 18, 2006 at 05:30:38PM +0200, Janusz A. Urbanowicz wrote: > > Yes. I have to confess I'm not sure what you are getting at here. > > What are you trying to do? > > I need to have unified copies/images of my pubkey key in various remote locations > where: > > * contents of pubrings differ (so not all keys that signed my key are > avaliable everywhere) > > * the copies of my key won't have a gazillion of self-signatures > > * unreferenced signatures on my key remain untouched > > * imported keys aren't stripped of anything that may be of use later > > Honestly, I thought that this is pretty obvious setup. I want to weed > out unnecessary self-signatured and only unnecessary selfsignatures. Sorry, what you want doesn't exist. There was much discussion around whether to strip out unreferenced signatures or not back when the 'clean' feature was being added, and it ultimately was decided to strip them out. You can delete the selfsigs by hand if they bother you that much. David From fredgk at gmail.com Mon Jun 19 19:38:42 2006 From: fredgk at gmail.com (fredg) Date: Mon Jun 19 21:25:49 2006 Subject: gpa-0.7.3 segfault when openig a file Message-ID: <20060619193842.7110e779.fredgk@gmail.com> Hi, Just built it under Zenwalk linux, against gpgme-1.1.2. I got a segfault when trying to open a file. Here is a gdb backtrace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1217018176 (LWP 23885)] 0xb7e0fb66 in gtk_scrolled_window_add_with_viewport () from /usr/lib/libgtk-x11-2.0.so.0 (gdb) bt #0 0xb7e0fb66 in gtk_scrolled_window_add_with_viewport () from /usr/lib/libgtk-x11-2.0.so.0 #1 0xb7e0fbdb in gtk_scrolled_window_add_with_viewport () from /usr/lib/libgtk-x11-2.0.so.0 #2 0xb7dd1345 in gtk_list_store_new () from /usr/lib/libgtk-x11-2.0.so.0 #3 0xb7e6eafa in gtk_tree_model_iter_next () from /usr/lib/libgtk-x11-2.0.so.0 #4 0x080535eb in ?? () #5 0x081b6c80 in ?? () #6 0xbfc91750 in ?? () #7 0x082145f8 in ?? () #8 0x08050e70 in ?? () #9 0x0821c028 in ?? () #10 0x00000000 in ?? () (gdb) Fred. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20060619/f3c2aef4/attachment.pgp From wk at gnupg.org Tue Jun 20 08:20:26 2006 From: wk at gnupg.org (Werner Koch) Date: Tue Jun 20 08:25:57 2006 Subject: [libksba] Please update copyright statements. In-Reply-To: <20060615140654.GA22701@downhill.aus.cc> (Andreas Metzler's message of "Thu, 15 Jun 2006 16:06:54 +0200") References: <20060615140654.GA22701@downhill.aus.cc> Message-ID: <87fyi0xs9h.fsf@wheatstone.g10code.de> On Thu, 15 Jun 2006 16:06, Andreas Metzler said: > However the FSF has a new address nowadays, the respective stanza > should say I know. It is just that there are so many files in need of a change that it takes some time whenever the FSF changes the address. I am pretty sure that there are still files with the MIT address out there. Fortunately I am about to do a new release and thus I can do this right now for libksba. Shalom-Salam, Werner From info at webinfo.de Tue Jun 20 10:18:35 2006 From: info at webinfo.de (=?iso-8859-15?Q?Bj=F6rn_Mayer?=) Date: Tue Jun 20 14:51:07 2006 Subject: gpgme: two separated contexts Message-ID: Hi folks, I just can't find out how I can create two separated contexts out of one GPG engine with the help of gpgme, so that I can import keys and delete keys in one context without affecting the other one!? Is this actually possible or is there always only one context for one GPG engine? If it is possible, how can I reaccess those contexts after having them closed? I'm really thankfull about every single hint!! Best regards, Bjorn From ametzler at downhill.at.eu.org Tue Jun 20 20:20:08 2006 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Tue Jun 20 21:58:13 2006 Subject: [libksba] Please update copyright statements. In-Reply-To: <87fyi0xs9h.fsf@wheatstone.g10code.de> References: <20060615140654.GA22701@downhill.aus.cc> <87fyi0xs9h.fsf@wheatstone.g10code.de> Message-ID: <20060620182008.GA3579@downhill.aus.cc> On 2006-06-20 Werner Koch wrote: > On Thu, 15 Jun 2006 16:06, Andreas Metzler said: [ne FSF address] > Fortunately I am about to do a new release and thus I can do this > right now for libksba. Splendid, thank you. cu andreas From marcus.brinkmann at ruhr-uni-bochum.de Tue Jun 20 23:58:31 2006 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Tue Jun 20 23:58:10 2006 Subject: gpgme: two separated contexts In-Reply-To: References: Message-ID: <87y7vr1oc8.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Tue, 20 Jun 2006 10:18:35 +0200, Bj?rn Mayer wrote: > Hi folks, > > I just can't find out how I can create two separated contexts out of one > GPG engine with the help of gpgme, so that I can import keys and delete > keys in one context without affecting the other one!? Is this actually > possible or is there always only one context for one GPG engine? If it is > possible, how can I reaccess those contexts after having them closed? > > I'm really thankfull about every single hint!! Contexts don't separate backend engines, they only capture the internal GPGME state of a crypto operation. If one crypto operation modifies the backend engine state, that can be observed by another context using the same backend engine state. Remember that GPGME is only a layer around the backend, it does not capture any state of the backend itself. If you actually want separate backend states, you need to create a new home directory for gnupg, and populate it with the state you want it to have somehow (manually). Then you can use the "set engine info" operation to configure the context to actually make use of that second home dir. Thanks, Marcus From jan-oliver.wagner at intevation.de Thu Jun 22 11:09:59 2006 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Thu Jun 22 11:08:55 2006 Subject: Compile error for GnuPG 1.9.21 Message-ID: <200606221109.59727.jan-oliver.wagner@intevation.de> Hi, during a pbuilder build of the new GnuPG 1.9.21 on Sarge I faced this problem: make[3]: Entering directory `/tmp/buildd/gnupg2-1.9.21/g10' if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../gl -I../common -I../include -I../intl -DLOCALEDIR=\"/usr/share/locale\" -DGNUPG_BINDIR="\"/usr/bin\"" -DGNUPG_LIBEXECDIR="\"/usr/lib/\"" -DGNUPG_LIBDIR="\"/usr/lib/gnupg\"" -DGNUPG_DATADIR="\"/usr/share/gnupg\"" -DGNUPG_SYSCONFDIR="\"/usr/etc/gnupg\"" -I/usr/include -Wno-pointer-sign -Wall -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -Wno-format-y2k -Wformat-security -MT gpg.o -MD -MP -MF ".deps/gpg.Tpo" -c -o gpg.o gpg.c; \ then mv -f ".deps/gpg.Tpo" ".deps/gpg.Po"; else rm -f ".deps/gpg.Tpo"; exit 1; fi cc1: error: unrecognized option `-Wno-pointer-sign' make[3]: *** [gpg.o] Error 1 make[3]: Leaving directory `/tmp/buildd/gnupg2-1.9.21/g10' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/tmp/buildd/gnupg2-1.9.21' make[1]: *** [all] Error 2 make[1]: Leaving directory `/tmp/buildd/gnupg2-1.9.21' make: *** [build-stamp] Error 2 pbuilder: Failed autobuilding of package This only occurs for the "g10" part, ie. OpenPGP. I removed this gcc option for my Debian package. Does this call for trouble? Best Jan -- Jan-Oliver Wagner: www.intevation.de/~jan | GISpatcher: www.gispatcher.de Kolab Konsortium : www.kolab-konsortium.de | Thuban : thuban.intevation.org Intevation GmbH : www.intevation.de | Kolab : www.kolab.org FreeGIS : www.freegis.org | GAV : www.grass-verein.de From wk at gnupg.org Thu Jun 22 13:08:03 2006 From: wk at gnupg.org (Werner Koch) Date: Thu Jun 22 13:11:28 2006 Subject: Compile error for GnuPG 1.9.21 In-Reply-To: <200606221109.59727.jan-oliver.wagner@intevation.de> (Jan-Oliver Wagner's message of "Thu, 22 Jun 2006 11:09:59 +0200") References: <200606221109.59727.jan-oliver.wagner@intevation.de> Message-ID: <87fyhxtpm4.fsf@wheatstone.g10code.de> On Thu, 22 Jun 2006 11:09, Jan-Oliver Wagner said: > This only occurs for the "g10" part, ie. OpenPGP. You shall not build the gpg part. There is a reason why it is not enabled by default and developers need to supply --enable-gpg to configure. Anyway even if you build it using a modern gcc, you will only see: $ g10/gpg2 gpg: NOTE: THIS IS A DEVELOPMENT VERSION! gpg: It is only intended for test purposes and should NOT be gpg: used in a production environment or with production keys! gpg: Fatal: This version of gpg is not ready for use, use gpg 1.4.x :-) Salam-Shalom, Werner From dvgevers at xs4all.nl Sat Jun 24 05:33:29 2006 From: dvgevers at xs4all.nl (Dick Gevers) Date: Sat Jun 24 05:32:17 2006 Subject: [ RFE ] short options Message-ID: <20060624033329.0bf1b578.dvgevers@xs4all.nl> Two of the most commonly used options, viz. --import and --export do not have short versions. Would you consider -m and -x please ? Thanks, =Dick Gevers= From alphasigmax at gmail.com Sat Jun 24 05:43:20 2006 From: alphasigmax at gmail.com (Alphax) Date: Sat Jun 24 05:44:08 2006 Subject: [ RFE ] short options In-Reply-To: <20060624033329.0bf1b578.dvgevers@xs4all.nl> References: <20060624033329.0bf1b578.dvgevers@xs4all.nl> Message-ID: <449CB4D8.9030109@gmail.com> Dick Gevers wrote: > Two of the most commonly used options, viz. --import and --export do not > have short versions. > > Would you consider -m and -x please ? > Aren't the only "short options" those which correspond to PGP2? -- Alphax Death to all fanatics! Down with categorical imperative! OpenPGP key: http://tinyurl.com/lvq4g -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 569 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20060624/90b8985a/signature.pgp From alphasigmax at gmail.com Sun Jun 25 05:36:43 2006 From: alphasigmax at gmail.com (Alphax) Date: Sun Jun 25 05:40:06 2006 Subject: gnupgjava web cvs location Message-ID: <449E04CB.4050904@gmail.com> I've seen activity on gnupgjava on the gnupg-commits list, but the only references I've found outside of that are some old archives on various ftp mirrors. Is there a web interface to the CVS repository for this? Are there any plans to migrate it to Subversion? -- Alphax Death to all fanatics! Down with categorical imperative! OpenPGP key: http://tinyurl.com/lvq4g -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 564 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20060625/31c5ca36/signature.pgp From wk at gnupg.org Sun Jun 25 11:25:56 2006 From: wk at gnupg.org (Werner Koch) Date: Sun Jun 25 11:31:01 2006 Subject: [ RFE ] short options In-Reply-To: <449CB4D8.9030109@gmail.com> (alphasigmax@gmail.com's message of "Sat, 24 Jun 2006 13:13:20 +0930") References: <20060624033329.0bf1b578.dvgevers@xs4all.nl> <449CB4D8.9030109@gmail.com> Message-ID: <877j35k2mz.fsf@wheatstone.g10code.de> On Sat, 24 Jun 2006 05:43, Alphax said: > Aren't the only "short options" those which correspond to PGP2? Mostly. Except for the standard ones like -v and such. I don't like the idea of adding short options for commands not very often used. In fact there is even vo short option for the most commonly used command --verify. Salam-Shalom, Werner From wk at gnupg.org Sun Jun 25 12:55:00 2006 From: wk at gnupg.org (Werner Koch) Date: Sun Jun 25 12:56:18 2006 Subject: gnupgjava web cvs location In-Reply-To: <449E04CB.4050904@gmail.com> (alphasigmax@gmail.com's message of "Sun, 25 Jun 2006 13:06:43 +0930") References: <449E04CB.4050904@gmail.com> Message-ID: <873bdtjyij.fsf@wheatstone.g10code.de> On Sun, 25 Jun 2006 05:36, Alphax said: > I've seen activity on gnupgjava on the gnupg-commits list, but the only > references I've found outside of that are some old archives on various > ftp mirrors. Is there a web interface to the CVS repository for this? > Are there any plans to migrate it to Subversion? I just added it to cvs.gnupg.org. You may use http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/gnupgjava/?root=Java+for+GnuPG to get directly to there. Shalom-Salam, Werner From wk at gnupg.org Sun Jun 25 15:43:25 2006 From: wk at gnupg.org (Werner Koch) Date: Sun Jun 25 16:41:00 2006 Subject: [Announce] GnuPG 1.4.4 released (security bug fix) Message-ID: <87psgxic5e.fsf@wheatstone.g10code.de> Skipped content of type multipart/signed-------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From jvender at owensboro.net Mon Jun 26 13:05:55 2006 From: jvender at owensboro.net (Joe Vender) Date: Mon Jun 26 13:05:53 2006 Subject: GnuPG 1.4.4 build error on mingw/msys when using mingw-runtime-3.10 Message-ID: <449FBF93.60608@owensboro.net> After upgrading mingw-runtime on my mingw/msys build environment to mingw-runtime-3.10 from 3.9, I experience a build error when trying to compile the GnuPG 1.4.4 source code. I receive the error in random.c at: #ifdef HAVE_GETTIMEOFDAY #include <------- #endif complaining that it can't find , resulting in other errors and an abort. Reading from the changelog for mingw-runtime-3.10 at http://sourceforge.net/forum/forum.php?forum_id=585368 "* include/sys/time.h: Add header guard. Add extern "C" bracketing for __cplusplus. (gettimeofday): Add prototype. * mingwex/gettimeofday.c: New file. * mingwex/makefile.in: Add gettimeofday source and object." Apparently, the "gettimeofday" prototype was introduced in mingw-runtime-3.10, but it's located in , not in . Indeed, I have no This causes the compilation attempt to abort. Since gettimeofday wasn't being #defined for me prior to this version of mingw-runtime, I didn't see this error prior to now. Is this simply a typo, or is there an inconsistency, between platforms, in naming conventions for the header files regarding where the prototypes are defined? Simply changing to resulted in a successful compile and passing of all 27 "make check" tests. Joe Vender From wk at gnupg.org Mon Jun 26 16:00:09 2006 From: wk at gnupg.org (Werner Koch) Date: Mon Jun 26 16:16:43 2006 Subject: [Announce] Gpg4win 1.0.3 released (security fix) Message-ID: <873bdsf252.fsf@wheatstone.g10code.de> Hi! We are pleased to announce the availibility of Gpg4win, version 1.0.3. * This version contains security fixes for the GnuPG and Sylpheed-Claws components. *Updating to this version is strongly recommended*. * Please also make sure to subscribe to the new gpg4win announcement mailing list. We might stop in the future to cross post announcements to the general GnuPG annoucement list. See: http://lists.wald.intevation.org/mailman/listinfo/gpg4win-announce About Gpg4win ------------- The Gpg4win project aims at updating the Gpg4win Windows installation package with GnuPG encryption tool, associated applications and documentation on a regular basis. Especially the documentation (handbooks "Einsteiger" and "Durchblicker") are directly maintained as part of the gpg4win project. It is an international project. Due to the origin of the project the German language is fully supported. As of now the the handbooks are only available in German. People helping with translations are very welcome! The main difference compared to all other similar approaches (mainly GnuPP, GnuPT, Windows Privacy Tools and GnuPG-Basics) is that the first thing developed was the *gpg4win-Builder*. This builder allows to easily create new gpg4win.exe installers with updated components. The builder runs on any decent Unix system, preferable Debian GNU/Linux. Almost all products are automatically cross-compiled for integration into the installer. With this concept it is hoped to *prevent quick aging of the* *installer package*. This is due to easier updating and less dependancy on single developers. Noteworthy changes in version 1.0.3 (2006-06-26) ------------------------------------------------ * Fixed a security related bug in GnuPG (CVE-2006-3082). * Updated Sylpheed-Claws due to security problems. * Included components are: GnuPG: 1.4.4 [*] WinPT: 0.12.3 [*] GPA: 0.7.3 GPGol: 0.9.10 GPGee: 1.3.1 Sylpheed-Claws: 2.3.1 [*] Einsteiger: 2.0.2 Durchblicker: 2.0.2 (Marked packages are updated since the last release) Installation ------------ For installation instructions, please visit http://www.gpg4win.org or read on. Developers who want to *build an installer* need to get the following files from http://wald.intevation.org/projects/gpg4win/ : gpg4win-1.0.3.tar.bz2 (3.9M) gpg4win-1.0.3.tar.bz2.sig The second file is a digital signature of the the first file. Either check that this signature is fine or compare with the checksums given below. (see also http://www.gnupg.org/download/integrity_check.html) The *ready to use installer* is available at: http://ftp.gpg4win.org/gpg4win-1.0.3.exe (6.2M) http://ftp.gpg4win.org/gpg4win-1.0.3.exe.sig Or using the ftp protocol at: ftp://ftp.gpg4win.org/gpg4win/gpg4win-1.0.3.exe (6.2M) ftp://ftp.gpg4win.org/gpg4win/gpg4win-1.0.3.exe.sig SHA1 and MD5 checksums for these files are given below. If you don't need the German PDF manuals, you might alternatively download the "light" version of the installer: http://ftp.gpg4win.org/gpg4win-light-1.0.3.exe (4.6M) http://ftp.gpg4win.org/gpg4win-light-1.0.3.exe.sig or using the ftp protocol at: ftp://ftp.gpg4win.org/gpg4win/gpg4win-1.0.3.exe (4.6M) ftp://ftp.gpg4win.org/gpg4win/gpg4win-1.0.3.exe.sig A separate installer with the the sources used to build the above installer is available at: ftp://ftp.gpg4win.org/gpg4win/gpg4win-src-1.0.3.exe (41M) ftp://ftp.gpg4win.org/gpg4win/gpg4win-src-1.0.3.exe.sig Most people don't need this source installer; it is merely stored on that server to satisfy the conditions of the GPL. In general it is better to get the gpg4win builder tarball (see above) and follow the instructions in the README to build new installers; building the installer is not possible on Windows machines and works best on current Debian GNU/Linux systems (we use the mingw32 package from Sid). SHA1 checksums are: fb010c9d4ee9e4d51b2b43034562f39eb6b88cbf gpg4win-1.0.3.exe bdb1065aaa8f72fcd13158712f2b479586d3d677 gpg4win-light-1.0.3.exe fa5e30e95227edda40f53dfc424239de06f0980a gpg4win-src-1.0.3.exe 7f0877dbde8e20e0b50288fefe4f77f1574bc50b gpg4win-1.0.3.tar.bz2 MD5 checksums are: 543343e59df88354627e018e0d3052ce gpg4win-1.0.3.exe c5ea9009beb27e16f955cc83ca5573ef gpg4win-light-1.0.3.exe 0d247c343c5623cb459b5debdadd30f7 gpg4win-src-1.0.3.exe 6ed1496b1edacfc7d7416e4155e3fe9e gpg4win-1.0.3.tar.bz2 We like to thank the authors of the included packages, the NSIS authors, all other contributors and first of all, those folks who stayed with us and tested the early releases of gpg4win. Happy hacking, Jan, Marcus, Timo and Werner -- Werner Koch The GnuPG Experts http://g10code.com Join the Fellowship and protect your Freedom! http://www.fsfe.org _______________________________________________ Gnupg-announce mailing list Gnupg-announce@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From alphasigmax at gmail.com Mon Jun 26 16:18:59 2006 From: alphasigmax at gmail.com (Alphax) Date: Mon Jun 26 16:19:53 2006 Subject: GnuPG 1.4.4 build error on mingw/msys when using mingw-runtime-3.10 In-Reply-To: <449FBF93.60608@owensboro.net> References: <449FBF93.60608@owensboro.net> Message-ID: <449FECD3.3020807@gmail.com> Joe Vender wrote: > After upgrading mingw-runtime on my mingw/msys build environment to > mingw-runtime-3.10 from 3.9, I experience a build error when trying to > compile the GnuPG 1.4.4 source code. I receive the error in random.c at: > > #ifdef HAVE_GETTIMEOFDAY > #include <------- > #endif > > complaining that it can't find , resulting in other errors > and an abort. > > Reading from the changelog for mingw-runtime-3.10 at > http://sourceforge.net/forum/forum.php?forum_id=585368 > > "* include/sys/time.h: Add header guard. Add extern "C" bracketing > for __cplusplus. > (gettimeofday): Add prototype. > * mingwex/gettimeofday.c: New file. > * mingwex/makefile.in: Add gettimeofday source and object." > > Apparently, the "gettimeofday" prototype was introduced in > mingw-runtime-3.10, but it's located in , > not in . Indeed, I have no > > This causes the compilation attempt to abort. > > Since gettimeofday wasn't being #defined for me prior to this version of > mingw-runtime, I didn't see this error prior to now. Is this simply a > typo, or is there an inconsistency, between platforms, in naming > conventions for the header files regarding where the prototypes are > defined? Simply changing to resulted in a > successful compile and passing of all 27 "make check" tests. > What I find interesting is the following (in cipher/random.c): #ifndef _WIN32 #include <--- there's the file you have #endif #ifdef HAVE_GETHRTIME #include #endif #ifdef HAVE_GETTIMEOFDAY #include #endif #ifdef HAVE_TIMES #include #endif In cipher/ChangeLog: 2003-08-28 David Shaw * idea-stub.c, random.c; s/__MINGW32__/_WIN32/ to help building on native Windows compilers. Requested by Brian Gladman. From Werner on stable branch. So, why has _WIN32 changed? Or has it? -- Alphax Death to all fanatics! Down with categorical imperative! OpenPGP key: http://tinyurl.com/lvq4g -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 564 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20060626/f729f744/signature.pgp From wk at gnupg.org Mon Jun 26 20:20:22 2006 From: wk at gnupg.org (Werner Koch) Date: Mon Jun 26 20:26:16 2006 Subject: GnuPG 1.4.4 build error on mingw/msys when using mingw-runtime-3.10 In-Reply-To: <449FECD3.3020807@gmail.com> (alphasigmax@gmail.com's message of "Mon, 26 Jun 2006 23:48:59 +0930") References: <449FBF93.60608@owensboro.net> <449FECD3.3020807@gmail.com> Message-ID: <87wtb3eq3d.fsf@wheatstone.g10code.de> On Mon, 26 Jun 2006 16:18, Alphax said: > * idea-stub.c, random.c; s/__MINGW32__/_WIN32/ to help building on > native Windows compilers. Requested by Brian Gladman. From > Werner on stable branch. > > > So, why has _WIN32 changed? Or has it? This change has no effect at all. All Windows compilers define _WIN32 (although I prefer the config.h defined HAVE_W32_SYSTEM). It is just that sys/time.h is not always available in Windows tool kits. Salam-Shalom, Werner From bjorn.mayer at staufen.net Mon Jun 26 20:45:33 2006 From: bjorn.mayer at staufen.net (=?iso-8859-15?Q?Bj=F6rn_Mayer?=) Date: Mon Jun 26 20:44:09 2006 Subject: keyserver access from within c++ or java Message-ID: Hi folks, I just wanted to ask, if anyone already implemented a java or c++ wrapper to access gpg keyservers!? As far as I know is the unfortunately still no possibility within the GPGME library... Does anyone actually know how far the developement of gpgme currently is concerning keyservers? Best regards, Bjorn From robbat2 at gentoo.org Mon Jun 26 23:59:04 2006 From: robbat2 at gentoo.org (Robin H. Johnson) Date: Mon Jun 26 23:57:58 2006 Subject: [BUG 1.4 series]: incorrect subkey used for signing Message-ID: <20060626215904.GA29100@curie-int.vc.shawcable.net> Tested & Affected: GnuPG 1.4.3, 1.4.4 Summary: gpg/g10 ignores the parameters to select a specific subkey using either the local-user parameter or the default-key parameter. Both the command line and config file versions are ignored. Pay attention to key 3233C22C. Some emphasis added to the below log. Log: $ gpg --with-colons --list-keys 0x34884E85 tru::0:1151309885:1152151040:3:1:5 pub:u:1024:17:B27B944E34884E85:2002-08-27:2008-03-09::u:Robin Hugh Johnson ::scESCA: uid:r::::::7F90208ADC2095DC95838B3F185835A4F19888B9::Robin Hugh Johnson : uid:u::::2005-03-10::73D52E9999BF413B6262A5E075A7F56B63A208FB::Robin Hugh Johnson : uid:u::::2006-06-23::E5E16CADC6D71856034B8B0B7324C6698829DFCB::Robin Hugh Johnson : uid:r::::::D936479E0731BFFFDB888E32B4D00E9665D16C2D::Robin Hugh Johnson : uid:r::::::610A8F7CE7490D0B3D2CB9F59DFF4271F025B6B9::Robin Hugh Johnson : uid:r::::::F26E4F3C6A3193048F6496AF6B32D256DB58A3BC::Robin Hugh Johnson : uid:r::::::3E1D6342532650216CAF62C2D869EBC6D0266BDD::Robin Hugh Johnson : uid:r::::::A3C07032FF409222B9DC368560256423860DF813::Robin Hugh Johnson : uid:u::::2006-06-23::65344CD246D49E07ECDC4E7C1CF138DF203C7950::Robin Hugh Johnson : sub:u:2048:16:92C71245CA05A397:2002-08-27:2008-03-09:::::e: sub:u:2048:16:A5A2BA5867592A1F:2003-04-12:2008-03-09:::::e: sub:r:1024:17:216C1775FB33B3A4:2002-08-27:2006-02-18:::::sa: sub:r:2048:16:49A3B54ACC772FC3:2002-08-27:2006-02-18:::::e: sub:u:1024:17:3E922C223233C22C:2004-08-29:2008-03-09:::::s: <--- this key should be used sub:u:1024:17:7D71DFE0A8E87991:2006-06-23:2008-06-22:::::a: sub:u:1024:17:3E0625AE9CA1EFD7:2006-06-23:2008-06-22:::::s: sub:u:2048:1:06F5B44166D8F49B:2006-06-23:2008-06-22:::::esa: $ gpg --verbose -u 0x3233C22C --output test.sign --armor --textmode --clearsign test.c gpg: no secret subkey for public subkey FB33B3A4 - ignoring gpg: no secret subkey for public subkey CC772FC3 - ignoring gpg: using subkey 66D8F49B instead of primary key 34884E85 You need a passphrase to unlock the secret key for user: "Robin Hugh Johnson " gpg: using subkey 66D8F49B instead of primary key 34884E85 2048-bit RSA key, ID 66D8F49B, created 2006-06-23 (main key ID 34884E85) gpg: gpg-agent is not available in this session gpg: writing to `test.sign' gpg: RSA/SHA1 signature from: "66D8F49B Robin Hugh Johnson " $ gpg --verbose --verify test.sign gpg: armor header: Hash: SHA1 gpg: armor header: Version: GnuPG v1.4.4 (GNU/Linux) gpg: armor header: Comment: Robbat2 @ Orbis-Terrarum Networks gpg: original file name='' gpg: Signature made Mon Jun 26 14:42:46 2006 PDT using RSA key ID 66D8F49B gpg: using subkey 66D8F49B instead of primary key 34884E85 gpg: using classic trust model gpg: Good signature from "Robin Hugh Johnson " gpg: aka "Robin Hugh Johnson " gpg: aka "Robin Hugh Johnson " gpg: aka "Robin Hugh Johnson " gpg: textmode signature, digest algorithm SHA1 -- Robin Hugh Johnson E-Mail : robbat2@orbis-terrarum.net Home Page : http://www.orbis-terrarum.net/?l=people.robbat2 ICQ# : 30269588 or 41961639 GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 524 bytes Desc: not available Url : /pipermail/attachments/20060626/d81e2877/attachment.pgp From dshaw at jabberwocky.com Tue Jun 27 00:19:57 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Tue Jun 27 00:18:48 2006 Subject: [BUG 1.4 series]: incorrect subkey used for signing In-Reply-To: <20060626215904.GA29100@curie-int.vc.shawcable.net> References: <20060626215904.GA29100@curie-int.vc.shawcable.net> Message-ID: <20060626221957.GB12940@jabberwocky.com> On Mon, Jun 26, 2006 at 02:59:04PM -0700, Robin H. Johnson wrote: > Tested & Affected: GnuPG 1.4.3, 1.4.4 > Summary: > gpg/g10 ignores the parameters to select a specific subkey using either the > local-user parameter or the default-key parameter. Both the command line and > config file versions are ignored. Not a bug, but a feature. If you want to force the use of a specific subkey, overriding the subkey-choosing logic in GPG, you must append a "!" to the key ID. From alphasigmax at gmail.com Tue Jun 27 04:46:34 2006 From: alphasigmax at gmail.com (Alphax) Date: Tue Jun 27 04:47:34 2006 Subject: GnuPG 1.4.4 build error on mingw/msys when using mingw-runtime-3.10 In-Reply-To: <87wtb3eq3d.fsf@wheatstone.g10code.de> References: <449FBF93.60608@owensboro.net> <449FECD3.3020807@gmail.com> <87wtb3eq3d.fsf@wheatstone.g10code.de> Message-ID: <44A09C0A.8020606@gmail.com> Werner Koch wrote: > On Mon, 26 Jun 2006 16:18, Alphax said: > >> * idea-stub.c, random.c; s/__MINGW32__/_WIN32/ to help building on >> native Windows compilers. Requested by Brian Gladman. From >> Werner on stable branch. >> >> >> So, why has _WIN32 changed? Or has it? > > This change has no effect at all. All Windows compilers define _WIN32 > (although I prefer the config.h defined HAVE_W32_SYSTEM). Sorry, I should have been more specific. The random.c change occured in 2003; something in mingw-runtime-3.10 is breaking _WIN32. > It is just that sys/time.h is not always available in Windows tool > kits. > sys/time.h is in at least mingw-runtime-3.9, and according to the OP has changed in mingw-runtime-3.10 - could you post the new version here? -- Alphax Death to all fanatics! Down with categorical imperative! OpenPGP key: http://tinyurl.com/lvq4g -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 564 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20060627/12957bf8/signature.pgp From jvender at owensboro.net Tue Jun 27 05:27:24 2006 From: jvender at owensboro.net (Joe Vender) Date: Tue Jun 27 05:27:03 2006 Subject: GnuPG 1.4.4 build error on mingw/msys when using mingw-runtime-3.10 In-Reply-To: <44A09C0A.8020606@gmail.com> References: <449FBF93.60608@owensboro.net> <449FECD3.3020807@gmail.com> <87wtb3eq3d.fsf@wheatstone.g10code.de> <44A09C0A.8020606@gmail.com> Message-ID: <44A0A59C.9010901@owensboro.net> Alphax wrote: > Sorry, I should have been more specific. The random.c change occured in > 2003; something in mingw-runtime-3.10 is breaking _WIN32. > Apparently, the reason that the compilation of GnuPG started failing on windows mingw/msys when migrating to mingw-runtime-3.10 from mingw-runtime-3.9 is that the "gettimeofday" prototype wasn't available prior to mingw-runtime-3.10. Since it wasn't available before that, HAVE_GETTIMEOFDAY wasn't being defined prior to mingw-runtime-3.10 and #ifdef HAVE_GETTIMEOFDAY #include #endif caused #include to be passed over, so the problem didn't show up. The include wasn't being attempted, so it wasn't finding that didn't exist on the system. >> It is just that sys/time.h is not always available in Windows tool >> kits. >> > > sys/time.h is in at least mingw-runtime-3.9, and according to the OP has > changed in mingw-runtime-3.10 - could you post the new version here? Yes, changed by addition of "gettimeofday" prototype, among other things. The addition of the new prototype in mingw-runtime-3.10 causes the code in GnuPG to break on mingw/msys because it is trying to include a file that doesn't exist on the system (times.h). For the mingw/msys build environment on windows, HAVE_GETTIMEOFDAY will only be defined if using mingw-runtime-3.10 or later, the #include should point to not From beebe at math.utah.edu Tue Jun 27 19:16:06 2006 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Tue Jun 27 21:55:50 2006 Subject: New book on PGP and GPG Message-ID: This new book on PGP and GPG has just appeared. A review can be found in last URL in the BibTeX entry: @String{pub-NO-STARCH = "No Starch Press"} @String{pub-NO-STARCH:adr = "San Francisco, CA, USA"} @Book{Lucas:2006:PGE, author = "Michael Lucas", title = "{PGP} and {GPG}: email for the practical paranoid", publisher = pub-NO-STARCH, address = pub-NO-STARCH:adr, pages = "216 (est.)", year = "2006", ISBN = "1-59327-071-2", ISBN-13 = "978-1-59327-071-1", LCCN = "TK5102.85 .L83 2006", bibdate = "Tue Jun 27 11:09:36 MDT 2006", bibsource = "z3950.loc.gov:7090/Voyager", URL = "http://www.loc.gov/catdir/toc/ecip061/2005028824.html; http://www.nostarch.com/pgp.htm", acknowledgement = ack-nhfb, tableofcontents = "Cryptography for kindergarteners \\ Understanding OpenPGP \\ Installing PGP \\ Installing GnuPG \\ The web of trust \\ PGP key management \\ Managing GnuPG keys \\ OpenPGP and email \\ PGP and email \\ GnuPG and email \\ Other OpenPGP considerations \\ The GnuPG command line \\ The PGP command line", review = "http://books.slashdot.org/books/06/06/26/1336200.shtml", subject = "Electronic mail systems; Security measures; PGP (Computer file)", } ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe@math.utah.edu - - 155 S 1400 E RM 233 beebe@acm.org beebe@computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- From npcole at yahoo.co.uk Wed Jun 28 10:41:10 2006 From: npcole at yahoo.co.uk (Nicholas Cole) Date: Wed Jun 28 10:40:22 2006 Subject: Security bug in mail plugins Message-ID: <20060628084110.10612.qmail@web26707.mail.ukl.yahoo.com> I've discovered (I'm sure I'm not the first) a bug in the gpgmail plugin, which integrates gpg with mail.app on OS X. If part of a message is a signed gpg/mime message, the user is shown a display which gives an impression that there is a valid signature for all of the message and no warning that part of the message is not signed. Mutt in similar circumstances appears to show only the signed part, although the non-signed part can be seen using "view attachments" (at least on my setup. Enigmail/Thunderbird, in the test I did, which was simply to attach an entire signed message (using mutt) to a new message, did not attempt to verify the signature at all. How do other mail clients deal with this issue? And what is the correct approach? Is there anything that can be done at the gpgme level to deal with this kind of problem, or is it (as I assume) all down to the plugin implementation to test for such cases? Best wishes, N. ___________________________________________________________ All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine http://uk.docs.yahoo.com/nowyoucan.html From wk at gnupg.org Wed Jun 28 12:26:28 2006 From: wk at gnupg.org (Werner Koch) Date: Wed Jun 28 12:31:14 2006 Subject: Security bug in mail plugins In-Reply-To: <20060628084110.10612.qmail@web26707.mail.ukl.yahoo.com> (Nicholas Cole's message of "Wed, 28 Jun 2006 09:41:10 +0100 (BST)") References: <20060628084110.10612.qmail@web26707.mail.ukl.yahoo.com> Message-ID: <87k67160ff.fsf@wheatstone.g10code.de> On Wed, 28 Jun 2006 10:41, Nicholas Cole said: > on OS X. If part of a message is a signed gpg/mime > message, the user is shown a display which gives an > impression that there is a valid signature for all of > the message and no warning that part of the message is > not signed. Well known problem with older MUAs. > How do other mail clients deal with this issue? And Gnus shows special markers to indicate what is signed and what no. Kmail puts colored frames around the signed and verified parts of the mail. > what is the correct approach? Is there anything that > can be done at the gpgme level to deal with this kind GPGME does now nown about MIME or mail protocols in general. It needs to be implemented in the MUA. Shalom-Salam, Werner From jvender at owensboro.net Thu Jun 29 01:23:28 2006 From: jvender at owensboro.net (Joe Vender) Date: Thu Jun 29 01:23:15 2006 Subject: signature question Message-ID: <44A30F70.8070204@owensboro.net> Using GnuPG 1.4.4 Is this normal GnuPG behavior or a bug? When I create a key pair and then list the signatures, I get: *** pub 4096R/6E9F8409 6/28/2006 [expires: 6/27/2010] Key fingerprint = 6942 5BE1 FCDD C366 821C A1A1 3664 1DBF 6E9F 8409 ------------- uid Joe Vender sig 3 6E9F8409 6/28/2006 Joe Vender ************* sub 4096R/90072DEF 6/28/2006 [expires: 6/27/2010] sig 6E9F8409 6/28/2006 Joe Vender *** If I then export the keypair, delete the original keypair from the ring, and reimport the exported keypair and list signatures, I get: *** pub 4096R/6E9F8409 6/28/2006 [expires: 6/27/2010] Key fingerprint = 6942 5BE1 FCDD C366 821C A1A1 3664 1DBF 6E9F 8409 ------------- uid Joe Vender sig 3 6E9F8409 6/28/2006 Joe Vender ************* sub 4096R/90072DEF 6/28/2006 [expires: 6/27/2010] sig 6E9F8409 6/28/2006 Joe Vender sig 6E9F8409 6/28/2006 Joe Vender *** It always picks up an extra signature on the subkey. If I then export the keypair again and import, there is still just two sigs on the subkey. It doesn't pick up additional sigs on the subkey after subsequent exports/imports of the keypair. Looking at the PGP packets on the subkey: *** Old: Public Subkey Packet(tag 14)(523 bytes) Ver 4 - new Public key creation time - Wed Jun 28 16:07:25 DST 2006 Pub alg - RSA Encrypt or Sign(pub 1) RSA n(4096 bits) - ... RSA e(6 bits) - ... Old: Signature Packet(tag 2)(549 bytes) Ver 4 - new Sig type - Subkey Binding Signature(0x18). Pub alg - RSA Encrypt or Sign(pub 1) Hash alg - SHA1(hash 2) Hashed Sub: signature creation time(sub 2)(4 bytes) Time - Wed Jun 28 16:07:25 DST 2006 Hashed Sub: key flags(sub 27)(1 bytes) Flag - This key may be used to encrypt communications Flag - This key may be used to encrypt storage Hashed Sub: key expiration time(sub 9)(4 bytes) Time - Sun Jun 27 16:07:25 DST 2010 Sub: issuer key ID(sub 16)(8 bytes) Key ID - 0x36641DBF6E9F8409 Hash left 2 bytes - 1c 11 RSA m^d mod n(4095 bits) - ... -> PKCS-1 Old: Signature Packet(tag 2)(549 bytes) Ver 4 - new Sig type - Subkey Binding Signature(0x18). Pub alg - RSA Encrypt or Sign(pub 1) Hash alg - SHA1(hash 2) Hashed Sub: signature creation time(sub 2)(4 bytes) Time - Wed Jun 28 16:07:27 DST 2006 Hashed Sub: key flags(sub 27)(1 bytes) Flag - This key may be used to encrypt communications Flag - This key may be used to encrypt storage Hashed Sub: key expiration time(sub 9)(4 bytes) Time - Sun Jun 27 16:07:25 DST 2010 Sub: issuer key ID(sub 16)(8 bytes) Key ID - 0x36641DBF6E9F8409 Hash left 2 bytes - 25 0c RSA m^d mod n(4095 bits) - ... -> PKCS-1 *** From wk at gnupg.org Thu Jun 29 08:45:59 2006 From: wk at gnupg.org (Werner Koch) Date: Thu Jun 29 08:51:25 2006 Subject: gpgsm OCSP question (key usage checking for response verification) In-Reply-To: <6cc244bb-d6f1-4763-b2dc-662f98efcbdc@well-done.deisui.org> (Daiki Ueno's message of "Thu, 18 May 2006 16:55:54 +0900") References: <98f51b73-f4d0-43c7-bbd0-0145271ffde0@well-done.deisui.org> <87iro3dbqa.fsf@wheatstone.g10code.de> <6cc244bb-d6f1-4763-b2dc-662f98efcbdc@well-done.deisui.org> Message-ID: <87ac7wlas8.fsf@wheatstone.g10code.de> On Thu, 18 May 2006 09:55, Daiki Ueno said: > I think that use == 0xfffffff is valid condition, so I would like to > know why use != ~0 is necessary here. The reason I implemented it this way is due RFC2560: 2.6 OCSP Signature Authority Delegation The key that signs a certificate's status information need not be the same key that signed the certificate. A certificate's issuer explicitly delegates OCSP signing authority by issuing a certificate containing a unique value for extendedKeyUsage in the OCSP signer's certificate. This certificate MUST be issued directly to the responder by the cognizant CA. What I missed is that this requirement for an extendedKeyUsage is only for delegated OCSP signers. 4.2.2.2 describes the requirements in more details. Notice also this comment in certlist.c: /* This is a hack to cope with OCSP. Note that we do not yet fully comply with the requirements and that the entire CRL/OCSP checking thing should undergo a thorough review and probably redesign. */ if ( !strcmp (p, oid_kp_ocspSigning)) have_ocsp_signing = 1; The whole callback thing for OCSP signing is a hack anyway to help dirmngr. It is the wrong approach. nstead dirmngr should be self-contained and validate the OCSP response on his own. I once tried to avoid this but it later turned out that we need to have validation code anyway in dirmngr and thus the plan is to remove this OCSP stuff from gpgsm and implement it only in dirmngr. Yes, this is shifting problems :-). Meanwhile the vaildation code for CRLs in dirmngr is pretty stable and thenext task will be to finalize Dirmngr's OCSP checking. There is also one other thing to do in libksba: Checking the nonce of the response needs to be implemented. After this has been implemented I will do an dirmngr 1.0. A lot of work is still waiting to be able to release gnupg 2.0 as well as a final dirmngr this summer. Shalom-Salam, Werner From g.esp at free.fr Thu Jun 29 07:29:41 2006 From: g.esp at free.fr (Gilles Espinasse) Date: Thu Jun 29 09:25:47 2006 Subject: uClibc : Failure to build with version>1.4.2 Message-ID: <03a701c69b3d$05b8b820$f9b5a8c0@pii350> With glibc-2.3.3 or glibc-2.3.6, it work with those options and 1.4.2/1.4.3/1.4.4 gnupg versions ./configure --prefix=/usr --disable-nls --disable-mailto --disable-photo-vie wers --disable-ldap With uClibc-0.9.28, it work with 1.4.2 but fail with 1.4.3/1.4.4 configure result is ... checking for library containing res_query... no checking for library containing __res_query... none required checking for library containing dn_expand... no checking for library containing __dn_expand... none required checking for library containing dn_skipname... no checking for library containing __dn_skipname... no checking whether the resolver is usable... yes ... Compilation error message is ../util/libutil.a(pka.o): In function `get_pka_info': pka.c:(.text+0x143): undefined reference to `__dn_skipname' pka.c:(.text+0x192): undefined reference to `__dn_skipname' ../util/libutil.a(cert.o): In function `get_cert': cert.c:(.text+0xcc): undefined reference to `__dn_skipname' cert.c:(.text+0xf4): undefined reference to `__dn_skipname' collect2: ld returned 1 exit status It only work with 1.4.3/1.4.4 by adding to configure --disable-dns-pka --disable-dns-cert --disable-dns-srv Gilles From mk at fsfe.org Thu Jun 29 09:34:00 2006 From: mk at fsfe.org (Matthias Kirschner) Date: Thu Jun 29 10:25:50 2006 Subject: Udev script not working Message-ID: <20060629073400.GA3541@mbwg.de> Hi all, I tested the smartcard howto on Debian testing with udev. Until now I used Debian stable with hotplug and everything worked fine. I did everything like described in http://www.gnupg.org/(en)/howtos/card-howto/en/ch02s03.html (under 2.3.1 with udev) user@machine:~$ gpg -v --card-status gpg: selecting openpgp failed: ec=6.108 gpg: OpenPGP Karte ist nicht vorhanden: Allgemeiner Fehler (English: OpenPGP card not available: general error) The output of udevmonitor (when I unplug and plug in the card): UEVENT[1151564470.555428] remove@/devices/pci0000:00/0000:00:1d.0/usb2/2-2/2-2:1.0 UEVENT[1151564470.555504] remove@/class/usb_device/usbdev2.3 UEVENT[1151564470.555518] remove@/devices/pci0000:00/0000:00:1d.0/usb2/2-2 UDEV [1151564470.557124] remove@/devices/pci0000:00/0000:00:1d.0/usb2/2-2/2-2:1.0 UDEV [1151564470.559383] remove@/class/usb_device/usbdev2.3 UDEV [1151564470.561257] remove@/devices/pci0000:00/0000:00:1d.0/usb2/2-2 UEVENT[1151564475.146210] add@/devices/pci0000:00/0000:00:1d.0/usb2/2-2 UEVENT[1151564475.153441] add@/devices/pci0000:00/0000:00:1d.0/usb2/2-2/2-2:1.0 UEVENT[1151564475.153504] add@/class/usb_device/usbdev2.4 UDEV [1151564475.154020] add@/devices/pci0000:00/0000:00:1d.0/usb2/2-2 UDEV [1151564475.176210] add@/devices/pci0000:00/0000:00:1d.0/usb2/2-2/2-2:1.0 UDEV [1151564475.226117] add@/class/usb_device/usbdev2.4 When I do machine:/dev/bus/usb/002# chown root:scard 004 everything is working for the user. Is someone familar with udev and has a clue what's wrong with the script? Thank you very much, Matze -- Join the Fellowship and protect your freedom! (http://www.fsfe.org) From alex at bofh.net.pl Thu Jun 29 11:21:20 2006 From: alex at bofh.net.pl (Janusz A. Urbanowicz) Date: Thu Jun 29 11:20:23 2006 Subject: Udev script not working In-Reply-To: <20060629073400.GA3541@mbwg.de> References: <20060629073400.GA3541@mbwg.de> Message-ID: <20060629092119.GF31579@hell.pl> On Thu, Jun 29, 2006 at 09:34:00AM +0200, Matthias Kirschner wrote: > When I do > > machine:/dev/bus/usb/002# chown root:scard 004 > > everything is working for the user. > > > Is someone familar with udev and has a clue what's wrong with the > script? I've found that udev/hotplug on sarge has serious problems with USB hotplug when running longer, like more than a few days. Try if the same happens if the machine is freshly booted. Alex From broonie at sirena.org.uk Thu Jun 29 13:20:15 2006 From: broonie at sirena.org.uk (Mark Brown) Date: Thu Jun 29 14:55:52 2006 Subject: Udev script not working In-Reply-To: <20060629073400.GA3541@mbwg.de> References: <20060629073400.GA3541@mbwg.de> Message-ID: <20060629112014.GA22679@sirena.org.uk> On Thu, Jun 29, 2006 at 09:34:00AM +0200, Matthias Kirschner wrote: > I did everything like described in > http://www.gnupg.org/(en)/howtos/card-howto/en/ch02s03.html (under 2.3.1 > with udev) The approach there is a bit racy, I believe. As far as I know it's not possible to do this in a udev approved manner without upgrading to more current versions of udev and the kernel. I put a few blog postings at and links back from there: http://www.sirena.org.uk/log/?p=23 (but note that I've only ever looked at this on Debian unstable.) -- "You grabbed my hand and we fell into it, like a daydream - or a fever." From mk at fsfe.org Thu Jun 29 13:34:26 2006 From: mk at fsfe.org (Matthias Kirschner) Date: Thu Jun 29 15:12:49 2006 Subject: Udev script not working In-Reply-To: <20060629092119.GF31579@hell.pl> References: <20060629073400.GA3541@mbwg.de> <20060629092119.GF31579@hell.pl> Message-ID: <20060629113425.GA4865@mbwg.de> * Janusz A. Urbanowicz [2006-06-29 11:21:20 +0200]: > > Is someone familar with udev and has a clue what's wrong with the > > script? > > I've found that udev/hotplug on sarge has serious problems with USB hotplug when > running longer, like more than a few days. On sarge, with hotplug, I did not have any problems. It is just now on etch with udev. > Try if the same happens if the machine is freshly booted. Yes I tried it right after rebooting, the rights are not set correctly. With best wishes, Matze -- Join the Fellowship and protect your freedom! (http://www.fsfe.org) From broonie at sirena.org.uk Thu Jun 29 15:56:19 2006 From: broonie at sirena.org.uk (Mark Brown) Date: Thu Jun 29 16:02:11 2006 Subject: Udev script not working In-Reply-To: <20060629113425.GA4865@mbwg.de> References: <20060629073400.GA3541@mbwg.de> <20060629092119.GF31579@hell.pl> <20060629113425.GA4865@mbwg.de> Message-ID: <20060629135618.GA20908@sirena.org.uk> On Thu, Jun 29, 2006 at 01:34:26PM +0200, Matthias Kirschner wrote: > On sarge, with hotplug, I did not have any problems. It is just now on > etch with udev. Ah, if this is etch then you definately need the newer style configuration using udev directly that I posted previously. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." From mk at fsfe.org Thu Jun 29 16:24:35 2006 From: mk at fsfe.org (Matthias Kirschner) Date: Thu Jun 29 16:23:43 2006 Subject: Udev script not working In-Reply-To: <20060629135618.GA20908@sirena.org.uk> References: <20060629073400.GA3541@mbwg.de> <20060629092119.GF31579@hell.pl> <20060629113425.GA4865@mbwg.de> <20060629135618.GA20908@sirena.org.uk> Message-ID: <20060629142435.GC3365@mbwg.de> * Mark Brown [2006-06-29 14:56:19 +0100]: > On Thu, Jun 29, 2006 at 01:34:26PM +0200, Matthias Kirschner wrote: > > > On sarge, with hotplug, I did not have any problems. It is just now on > > etch with udev. > > Ah, if this is etch then you definately need the newer style > configuration using udev directly that I posted previously. So you mean I should use: SUBSYSTEM==?usb_device?, SYSFS{idVendor}==?04e6?, SYSFS{idProduct}==?e003?, GROUP=?scard?, MODE=?0664? SUBSYSTEM==?usb_device?, SYSFS{bDeviceClass}==?0?0B?, GROUP=?scard?, MODE=?0664? SUBSYSTEM==?usb_device?, SYSFS{idVendor}==?04e6?, SYSFS{idProduct}==?5115?, GROUP=?scard?, MODE=?0664? Should I add the above to /etc/udev/udev.rules and remove this three rules? # usbfs-like devices SUBSYSTEM=="usb_device", PROGRAM="/bin/sh -c 'K=%k; K=$${K#usbdev}; printf bus/usb/%%03i/%%03i $${K%%%%.*} $${K#*.}'", \ NAME="%c" Thanks, Matze -- Join the Fellowship and protect your freedom! (http://www.fsfe.org) From jvender at owensboro.net Fri Jun 30 08:23:59 2006 From: jvender at owensboro.net (Joe Vender) Date: Fri Jun 30 08:23:47 2006 Subject: signature question In-Reply-To: <44A30F70.8070204@owensboro.net> References: <44A30F70.8070204@owensboro.net> Message-ID: <44A4C37F.4040907@owensboro.net> Is the behavior described normal behavior of GnuPG or a bug? From md+g10 at linux.it Fri Jun 30 09:54:02 2006 From: md+g10 at linux.it (Marco d'Itri) Date: Fri Jun 30 11:25:42 2006 Subject: Udev script not working In-Reply-To: <20060629112014.GA22679@sirena.org.uk> References: <20060629073400.GA3541@mbwg.de> <20060629112014.GA22679@sirena.org.uk> Message-ID: <20060630075402.GA3631@wonderland.linux.it> On Jun 29, Mark Brown wrote: > The approach there is a bit racy, I believe. As far as I know it's not > possible to do this in a udev approved manner without upgrading to more > current versions of udev and the kernel. I put a few blog postings at > and links back from there: > > http://www.sirena.org.uk/log/?p=23 Indeed this is the correct solution. -- ciao, Marco From broonie at sirena.org.uk Fri Jun 30 12:43:38 2006 From: broonie at sirena.org.uk (Mark Brown) Date: Fri Jun 30 12:58:05 2006 Subject: Udev script not working In-Reply-To: <20060629142435.GC3365@mbwg.de> References: <20060629142435.GC3365@mbwg.de> Message-ID: <20060630104336.GA21035@sirena.org.uk> On Thu, Jun 29, 2006 at 04:24:35PM +0200, Matthias Kirschner wrote: > So you mean I should use: > SUBSYSTEM==???usb_device???, SYSFS{idVendor}==???04e6???, > SYSFS{idProduct}==???e003???, GROUP=???scard???, MODE=???0664??? > SUBSYSTEM==???usb_device???, SYSFS{bDeviceClass}==???0??0B???, GROUP=???scard???, > MODE=???0664??? > SUBSYSTEM==???usb_device???, SYSFS{idVendor}==???04e6???, > SYSFS{idProduct}==???5115???, GROUP=???scard???, MODE=???0664??? Yes, that should be all you need (modulo the quotes which seem to have got messed up, probably at the point where I posted the rules on the web). > Should I add the above to /etc/udev/udev.rules and remove this three > rules? You shouldn't need anything except the above rules to get the permissions set on the nodes for the card reader so anything else you added for it could be removed. -- "You grabbed my hand and we fell into it, like a daydream - or a fever."