From bernhard at intevation.de Mon Feb 1 10:43:31 2010 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 1 Feb 2010 10:43:31 +0100 Subject: Debian Packaging Message-ID: <201002011043.35593.bernhard@intevation.de> I have filed a few issues with the Debian: #567536 better have a gnupg2-common for gpgconf and other tool common to gpgsm and gpg2 #567537 gnupg2: applygnupgdefaults is not packaged and one about the passphrase issue Werner reported last week Our kk packager will probably make new packages when we get around to it, addressing all this. This is just to let you all now. I would apprecate comments on the idea of having a gnupg2-common package to get gpgconf and the dependencies right. Or would it be okay to just always have gpgsm depend on gnupg2? Best Regards, (and thanks to Eric for maintaining the Debian packages), Bernhard -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Mon Feb 1 14:53:43 2010 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 1 Feb 2010 14:53:43 +0100 Subject: Passphrase problem in gpgsm 2.0.14 In-Reply-To: <201001291718.38928.bernhard@intevation.de> References: <874om9vsq1.fsf@vigenere.g10code.de> <201001291718.38928.bernhard@intevation.de> Message-ID: <201002011453.47254.bernhard@intevation.de> Am Freitag, 29. Januar 2010 17:18:33 schrieb Bernhard Reiter: > Am Dienstag, 26. Januar 2010 15:36:06 schrieb Werner Koch: > > A patch against 2.0.14 is attached. > > The signature on the email was broken for me (and for Marcus), > this is for the email received via the email list. To verify the signature of Werner's original email, you can reverse the whitespace change that broke the signature. (Save the email in raw format. Join the following two lines to be one. Then recheck the signature on the changed email.) 76,77c76 < Content-Type: multipart/mixed; < boundary="=Rule-Psix-Soviet-number-key-weapons-of-mass-destruction-freedom-Nort" --- > Content-Type: multipart/mixed; boundary="=Rule-Psix-Soviet-number-key-weapons-of-mass-destruction-freedom-Nort" There is a long standing issue with Mailman breaking signature. (I've developed a patch for a part of the problem, which after a few years got accepted into mailman 2.1.13, see https://bugs.launchpad.net/mailman/+bug/265967 https://launchpad.net/mailman/2.1/2.1.13 - Mailman no longer folds long sub-part headers in multipart messages. In addition, Mailman no longer escapes From_ lines in the body of messages sent to regular list members, although MTA's may do it anyway. This is to avoid breaking signatures per Bug #265967. Debian used to carry the patch for a long time. Bernhard -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From rich at anomos.info Tue Feb 2 05:05:31 2010 From: rich at anomos.info (Rich Jones) Date: Mon, 1 Feb 2010 23:05:31 -0500 Subject: Miscalculated Key ID and fingerprints when compiled for ARM Message-ID: Hello! I have complied a version of GPG for an ARM-based processor (this is actually running a T-Mobile G1). I have found an interesting and unfortunately fatal bug. All imported keys are invalid as there is a miscalculated key ID and fingerprint. For example, on my real machine, --list-keys gives: pub 1024D/A1D39D09 2008-04-23 uid John M. Schanck uid John M. Schanck sub 2048g/2B4C51FB 2008-04-23 but on the ARM version, the same command on the same imported key gives: pub 1024D/5267F8D8 2008-04-23 uid John M. Schanck uid John M. Schanck The binary was compiled with the command: ./configure CC=gnupg-agcc --host=arm-eabi --prefix=/data/data/org.gnupg.android.gnupg/ --disable-idea --disable-finger --disable-largefile --with-zlib=$DROID/src/external/zlib --with-bzip2=$DROID/external/bzip2 --with-included-regex --disable-photo-viewers Has anybody tried compiling GPG for ARM-EABI before? Does anybody have any idea what could be causing this? Is this related to endianness? Thanks ever so much and thanks for all your great work on this project, Rich From dshaw at jabberwocky.com Tue Feb 2 06:17:32 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 2 Feb 2010 00:17:32 -0500 Subject: Miscalculated Key ID and fingerprints when compiled for ARM In-Reply-To: References: Message-ID: On Feb 1, 2010, at 11:05 PM, Rich Jones wrote: > Hello! > > I have complied a version of GPG for an ARM-based processor (this is > actually running a T-Mobile G1). I have found an interesting and > unfortunately fatal bug. > > All imported keys are invalid as there is a miscalculated key ID and > fingerprint. > > For example, on my real machine, --list-keys gives: > > pub 1024D/A1D39D09 2008-04-23 > uid John M. Schanck > uid John M. Schanck > sub 2048g/2B4C51FB 2008-04-23 > > but on the ARM version, the same command on the same imported key gives: > > pub 1024D/5267F8D8 2008-04-23 > uid John M. Schanck > uid John M. Schanck > > The binary was compiled with the command: ./configure CC=gnupg-agcc > --host=arm-eabi --prefix=/data/data/org.gnupg.android.gnupg/ > --disable-idea --disable-finger --disable-largefile > --with-zlib=$DROID/src/external/zlib > --with-bzip2=$DROID/external/bzip2 --with-included-regex > --disable-photo-viewers Hmm. A few things to try: What sort of machine is your "real machine"? Try adding --disable-endian-check to your configure line. Also, what happens if you do: echo test | gpg --print-md sha1 On both your real machine and on the ARM machine? David From rich at anomos.info Tue Feb 2 08:22:05 2010 From: rich at anomos.info (Rich Jones) Date: Tue, 2 Feb 2010 02:22:05 -0500 Subject: Miscalculated Key ID and fingerprints when compiled for ARM In-Reply-To: References: Message-ID: Thank you for your swift response! I will try with --disable-endian-check tomorrow. For that command, on the x86 machine (my thinkpad): 4E12 43BD 22C6 6E76 C2BA 9EDD C1F9 1394 E57F 9F83 on the device: FD0C FBCC EB2E 860F 866C 09F9 0FB8 3DE9 32C7 0400 ! R On Tue, Feb 2, 2010 at 12:17 AM, David Shaw wrote: > On Feb 1, 2010, at 11:05 PM, Rich Jones wrote: > >> Hello! >> >> I have complied a version of GPG for an ARM-based processor (this is >> actually running a T-Mobile G1). I have found an interesting and >> unfortunately fatal bug. >> >> All imported keys are invalid as there is a miscalculated key ID and >> fingerprint. >> >> For example, on my real machine, --list-keys gives: >> >> pub ? 1024D/A1D39D09 2008-04-23 >> uid ? ? ? ? ? ? ? ? ?John M. Schanck >> uid ? ? ? ? ? ? ? ? ?John M. Schanck >> sub ? 2048g/2B4C51FB 2008-04-23 >> >> but on the ARM version, the same command on the same imported key gives: >> >> pub ? 1024D/5267F8D8 2008-04-23 >> uid ? ? ? ? ? ? ? ? ?John M. Schanck >> uid ? ? ? ? ? ? ? ? ?John M. Schanck >> >> The binary was compiled with the command: ./configure CC=gnupg-agcc >> --host=arm-eabi --prefix=/data/data/org.gnupg.android.gnupg/ >> --disable-idea --disable-finger --disable-largefile >> --with-zlib=$DROID/src/external/zlib >> --with-bzip2=$DROID/external/bzip2 --with-included-regex >> --disable-photo-viewers > > Hmm. ?A few things to try: > > What sort of machine is your "real machine"? > > Try adding --disable-endian-check to your configure line. > > Also, what happens if you do: > > ?echo test | gpg --print-md sha1 > > On both your real machine and on the ARM machine? > > David > > From jacques.le.malade at gmail.com Tue Feb 2 16:01:18 2010 From: jacques.le.malade at gmail.com (Jacques Le Malade) Date: Tue, 2 Feb 2010 16:01:18 +0100 Subject: Selection decryption Message-ID: <16c025801002020701w46a2a631md8b1b467a4e49d26@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello everybody, I would like to start my little new projet that is, to add an option to the right-click menu under GNOME to decrypt a selection made with the mouse. The typical use case is, I am using my webmail (or viewing an encrypted text) with any browser / text application. I select the text containing ----BEGIN PGP [...] ------ and it decryptes it for me. [Sorry for my bad english, as I'm french]. Is there an API to GnuPG we can easily use ? Thank you by advance. Jacques le Malade -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) iQIcBAEBAgAGBQJLaD3gAAoJEJ35l6s6b4oFu3IP/iZn6B+kdTy1YdJdaw1NxgOm zkFaTKwumHDUdpV8vsBaSV3ozUWs+68cCbuvM863Mq0xiUgQvmreSfgrrUm7pZob kMVb9wtrLj2LN/g9HiD3cNHBi6BQn/Hx6+gwdjtU1mlNZwi6jbOS6bDwzvEcVE1s VsTyvM8Zb6GJZMQZCKeSgaU5KXDFvMJKTjmmBZPhmThe3gTc1C8chC6IpnwsBR/y bjjJQLy1dlXWCyDjOt+KSFikIhTpDdysKAw0RiuW+R0wrkvddTlzvuA6Kd43XOfa ycA+6Cc1DsWdiFtVuK8Dfp2qaiaqmRM275dU+0C65mVUQEVpiztgxRtIw9qoB1M1 HZLavxkH9x0Uk2i5et/IvNbQ7LFLqMS83KxjmwSkdwfi1yTRj6wU9xN5WtY5Z+un 5fTazeG7w2NsJIkHKWpx9V9t6hseBe/iHj/r8vMw41FC4SiICmdped1E2U9vqE6E /cLY9sVLa05NhiTOPyl7f1YPKyMXo3ppqOsvoz0H3YIe3+tkrV7UQcRJORFRZzsB AhG35giDA9nBvfg7ygpIxB21f3NEpq7qj/dIFqCp83nIAeNtFEKgOaYGUWOU8JLr Sx463w1704CSNZ9cDp1yozM4IuCojFJrGm0KnYSwywNIQ8heQlRKQAi2K/FmdYvO /QNeSW6VT2BBKcHTSQlm =WKUE -----END PGP SIGNATURE----- From wk at gnupg.org Tue Feb 2 17:55:22 2010 From: wk at gnupg.org (Werner Koch) Date: Tue, 02 Feb 2010 17:55:22 +0100 Subject: Selection decryption In-Reply-To: <16c025801002020701w46a2a631md8b1b467a4e49d26@mail.gmail.com> (Jacques Le Malade's message of "Tue, 2 Feb 2010 16:01:18 +0100") References: <16c025801002020701w46a2a631md8b1b467a4e49d26@mail.gmail.com> Message-ID: <87fx5jo9vp.fsf@vigenere.g10code.de> On Tue, 2 Feb 2010 16:01, jacques.le.malade at gmail.com said: > Is there an API to GnuPG we can easily use ? There is something in the works. It needs the very latest version of some parts and not yet very weel tested. However, it is portable and pretty easy to do. I gave a talk about it at FSCONS2009 but unfortunately my example code (for beginners) is still not published. The idea is simple: You access a UI server and ask it to do the action. That UI-Server is responsible for key selection and such. We have two implementations right now: Kleopatra from KDE and GPA. My testbed is mousepad, a simple editor from xfce. I can post the my patches but first I need to locate the laptop and fire it up. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Feb 2 18:15:46 2010 From: wk at gnupg.org (Werner Koch) Date: Tue, 02 Feb 2010 18:15:46 +0100 Subject: Selection decryption In-Reply-To: <16c025801002020701w46a2a631md8b1b467a4e49d26@mail.gmail.com> (Jacques Le Malade's message of "Tue, 2 Feb 2010 16:01:18 +0100") References: <16c025801002020701w46a2a631md8b1b467a4e49d26@mail.gmail.com> Message-ID: <87bpg7o8xp.fsf@vigenere.g10code.de> Hi, here is some code to see how the UI-server works. /* * file.c * This file is part of Mousepad [...] #include You need gpgme of course. Here is the code to write out teh encrypted data: /* Encrypt or sign the string PLAINTEXT and write it to FP. MODE * controls whether encrypt, signing or both are used. The function * employs an external UI server and requires that gpgme has been * initialized at startup. Returns 0 on success. */ static int crypt_write (const char *plaintext, CryptMode mode, FILE *fp) { gpg_error_t err; gpgme_ctx_t ctx; gpgme_data_t in, out; err = gpgme_new (&ctx); if (err) { g_debug ("error creating gpgme context: %s", gpg_strerror (err)); return -1; } /* Tell GPGME to use the "UI-Server protocol". */ err = gpgme_set_protocol (ctx, GPGME_PROTOCOL_UISERVER); if (err) { g_debug ("gpgme does not support the UI protocol: %s", gpg_strerror (err)); gpgme_release (ctx); return -1; } /* We want the UI server to use the best encryption protocol around. */ err = gpgme_set_sub_protocol (ctx, GPGME_PROTOCOL_OpenPGP); if (err) { g_debug ("error asking the UI server to use the %s protocol: %s", "OpenPGP", gpg_strerror (err)); gpgme_release (ctx); return -1; } /* Wrap the data into an GPGME object. */ err = gpgme_data_new_from_mem (&in, plaintext, strlen (plaintext), 0); if (err) { g_debug ("error creating gpgme data object: %s", gpg_strerror (err)); gpgme_release (ctx); return -1; } There are several other methods how to create a gpgme data objects, but this one will probably also fit your requirements. /* Wrap the output stream into an GPGME object. */ err = gpgme_data_new_from_stream (&out, fp); if (err) { g_debug ("error creating gpgme stream data object: %s", gpg_strerror (err)); gpgme_data_release (in); gpgme_release (ctx); return -1; } MODE below comes from a selector in the file dialog. /* Do whatever has been requested. */ if (mode == CRYPT_ENCRYPT) { err = gpgme_op_encrypt (ctx, NULL, 0, in, out); if (err) g_debug ("error encrypting file: %s <%s>", gpg_strerror (err), gpg_strsource (err)); } else if (mode == CRYPT_SIGN) { err = gpgme_op_sign (ctx, in, out, GPGME_SIG_MODE_NORMAL); if (err) g_debug ("error signing file: %s <%s>", gpg_strerror (err), gpg_strsource (err)); } else if (mode == CRYPT_SIGNENCRYPT) { err = gpgme_op_encrypt_sign (ctx, NULL, 0, in, out); if (err) g_debug ("error signing and encrypting file: %s <%s>", gpg_strerror (err), gpg_strsource (err)); } else err = gpg_error (GPG_ERR_BUG); /* Cleanup. */ gpgme_data_release (out); gpgme_data_release (in); gpgme_release (ctx); return err? -1:0; } The rest of the code in file.c erely adds the mentioned selector widget and hooks into the saving procedure. I leave that out. Now, to test this you need to start gpa as a server: gpa --server and it should just work; i.e. you get a selection dialog etc. As I said in my last mail you need the latest gpa version, the latest gpgme version and thus also the latest libassuan version. Old GnuPG versions should do fine. Note that you can also S/MIME encrypt if you like (cf. gpgme_set_sub_protocol). Decryption is similar, but I don't think I tested it. The reason why we have this UI-server thing is that we use it in the Windows version to do all key selection and actual encryption stuff in our Outlook and Explorer plugins within a usable GUI framework (GTK+ or Qt). Thus there is no reason not to use it in other software as well. I'd really love to see that feature in real use. Thus if there are any problems, I is likely that I can help you. if something needs to be added to GPA, this can be done pretty quicker - or do it yourself (we don't need copyright assignments for GPA). Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From jacques.le.malade at gmail.com Tue Feb 2 18:48:44 2010 From: jacques.le.malade at gmail.com (Jacques Le Malade) Date: Tue, 2 Feb 2010 18:48:44 +0100 Subject: Selection decryption In-Reply-To: <87bpg7o8xp.fsf@vigenere.g10code.de> References: <16c025801002020701w46a2a631md8b1b467a4e49d26@mail.gmail.com> <87bpg7o8xp.fsf@vigenere.g10code.de> Message-ID: <16c025801002020948l3a1b6e49k620cec9dc4d34407@mail.gmail.com> Hello, I am going to look at this. That's most interesting ! > Going to download gpgme and gpa :-) Merci beaucoup ! Jacques le Fou 2010/2/2, Werner Koch : > Hi, > > here is some code to see how the UI-server works. > > /* > * file.c > * This file is part of Mousepad > [...] > > #include > > You need gpgme of course. Here is the code to write out teh encrypted > data: > > /* Encrypt or sign the string PLAINTEXT and write it to FP. MODE > * controls whether encrypt, signing or both are used. The function > * employs an external UI server and requires that gpgme has been > * initialized at startup. Returns 0 on success. */ > static int crypt_write (const char *plaintext, CryptMode mode, FILE *fp) > { > gpg_error_t err; > gpgme_ctx_t ctx; > gpgme_data_t in, out; > > err = gpgme_new (&ctx); > if (err) { > g_debug ("error creating gpgme context: %s", gpg_strerror > (err)); > return -1; > } > > /* Tell GPGME to use the "UI-Server protocol". */ > err = gpgme_set_protocol (ctx, GPGME_PROTOCOL_UISERVER); > if (err) { > g_debug ("gpgme does not support the UI protocol: %s", > gpg_strerror (err)); > gpgme_release (ctx); > return -1; > } > > /* We want the UI server to use the best encryption protocol around. > */ > err = gpgme_set_sub_protocol (ctx, GPGME_PROTOCOL_OpenPGP); > if (err) { > g_debug ("error asking the UI server to use the %s protocol: > %s", > "OpenPGP", gpg_strerror (err)); > gpgme_release (ctx); > return -1; > } > > /* Wrap the data into an GPGME object. */ > err = gpgme_data_new_from_mem (&in, plaintext, strlen (plaintext), > 0); > if (err) { > g_debug ("error creating gpgme data object: %s", > gpg_strerror (err)); > gpgme_release (ctx); > return -1; > } > > There are several other methods how to create a gpgme data objects, but > this one will probably also fit your requirements. > > /* Wrap the output stream into an GPGME object. */ > err = gpgme_data_new_from_stream (&out, fp); > if (err) { > g_debug ("error creating gpgme stream data object: %s", > gpg_strerror (err)); > gpgme_data_release (in); > gpgme_release (ctx); > return -1; > } > > MODE below comes from a selector in the file dialog. > > /* Do whatever has been requested. */ > if (mode == CRYPT_ENCRYPT) { > err = gpgme_op_encrypt (ctx, NULL, 0, in, out); > if (err) > g_debug ("error encrypting file: %s <%s>", > gpg_strerror (err), gpg_strsource (err)); > } > else if (mode == CRYPT_SIGN) { > err = gpgme_op_sign (ctx, in, out, GPGME_SIG_MODE_NORMAL); > if (err) > g_debug ("error signing file: %s <%s>", > gpg_strerror (err), gpg_strsource (err)); > } > else if (mode == CRYPT_SIGNENCRYPT) { > err = gpgme_op_encrypt_sign (ctx, NULL, 0, in, out); > if (err) > g_debug ("error signing and encrypting file: %s <%s>", > gpg_strerror (err), gpg_strsource (err)); > } > else > err = gpg_error (GPG_ERR_BUG); > > /* Cleanup. */ > gpgme_data_release (out); > gpgme_data_release (in); > gpgme_release (ctx); > > return err? -1:0; > } > > The rest of the code in file.c erely adds the mentioned selector widget > and hooks into the saving procedure. I leave that out. > > Now, to test this you need to start gpa as a server: > > gpa --server > > and it should just work; i.e. you get a selection dialog etc. As I said > in my last mail you need the latest gpa version, the latest gpgme > version and thus also the latest libassuan version. Old GnuPG versions > should do fine. Note that you can also S/MIME encrypt if you like > (cf. gpgme_set_sub_protocol). > > Decryption is similar, but I don't think I tested it. The reason why we > have this UI-server thing is that we use it in the Windows version to do > all key selection and actual encryption stuff in our Outlook and > Explorer plugins within a usable GUI framework (GTK+ or Qt). Thus there > is no reason not to use it in other software as well. > > I'd really love to see that feature in real use. Thus if there are any > problems, I is likely that I can help you. if something needs to be > added to GPA, this can be done pretty quicker - or do it yourself (we > don't need copyright assignments for GPA). > > > Salam-Shalom, > > Werner > > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > From wk at gnupg.org Tue Feb 16 11:33:30 2010 From: wk at gnupg.org (Werner Koch) Date: Tue, 16 Feb 2010 11:33:30 +0100 Subject: [admin] Please do not respond Message-ID: <87hbphh3lx.fsf@vigenere.g10code.de> Sorry, for this test message. Please do not respond. From cyril.soler at imag.fr Tue Feb 16 14:50:00 2010 From: cyril.soler at imag.fr (Cyril Soler) Date: Tue, 16 Feb 2010 14:50:00 +0100 Subject: missing export options in gpgme Message-ID: <4B7AA288.3010901@imag.fr> Hi, I'm a developer in the RetroShare project (http://retroshare.sourceforge.net). We use gpgme for interfacing with gpg. I could not find in gpgme a way of exporting public keys without signatures using gpgme_op_export. With gpg, I would do: gpg --export [key_id] --export-options export-minimal -a As gpgme is calling gpg with command-line options, is there a way to include additional command line parameters ? Thankx Cyril From wk at gnupg.org Tue Feb 16 18:44:51 2010 From: wk at gnupg.org (Werner Koch) Date: Tue, 16 Feb 2010 18:44:51 +0100 Subject: missing export options in gpgme In-Reply-To: <4B7AA288.3010901@imag.fr> (Cyril Soler's message of "Tue, 16 Feb 2010 14:50:00 +0100") References: <4B7AA288.3010901@imag.fr> Message-ID: <873a11dqi4.fsf@vigenere.g10code.de> On Tue, 16 Feb 2010 14:50, cyril.soler at imag.fr said: > As gpgme is calling gpg with command-line options, is there a way to > include additional command line parameters ? No, this is an abstract API and thus we can't allow specific options. I can see a reason for this flag, thus let me see whether we can quikcly add it. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Feb 16 19:41:51 2010 From: wk at gnupg.org (Werner Koch) Date: Tue, 16 Feb 2010 19:41:51 +0100 Subject: missing export options in gpgme In-Reply-To: <4B7AA288.3010901@imag.fr> (Cyril Soler's message of "Tue, 16 Feb 2010 14:50:00 +0100") References: <4B7AA288.3010901@imag.fr> Message-ID: <87y6itc9ao.fsf@vigenere.g10code.de> Hi! I implemented the requested minimal option. If you want to use it with older versions (< 1.3), you may use try to use the attached patch. `GPGME_EXPORT_MODE_MINIMAL' If this bit is set, the smallest possible key is exported. For OpenPGP keys it removes all signatures except for the latest self-signatures. For X.509 keys it has no effect. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: gpgme-1.3-export-minimal.diff URL: From wk at gnupg.org Thu Feb 18 10:41:49 2010 From: wk at gnupg.org (Werner Koch) Date: Thu, 18 Feb 2010 10:41:49 +0100 Subject: Release candidate for 2.0.15 Message-ID: <873a0yc23m.fsf@vigenere.g10code.de> Hi! I just prepared a release candidate for GnuPG 2.0.15. The goal of this release is to find out whether there are any severe build or runtime bugs. There are actually not may changes: * New command --passwd for GPG. * Fixes a regression in 2.0.14 which prevented unprotection of new or changed gpg-agent passphrases. * Make use of Libassuan 2.0 which is available as a DSO. as well as a couple of minor bug fixes and some changes to the German translation. The major point is the move to Libassuan 2.0. This is the first version of Libassuan which may be used as a shared library. We took this change to cleanup the API a bit with the drawback that some changes to the caller are required. To make development with Libassuan easier we need to get rid of Libassuan 1 which developer's package can't be installed side by side with Libassuan 2. Thus it is not easy to maintain software written with version 1 and 2 at the same time. With the 2.0.15 release we will have finished the migration of the GnuPG related tools to Libassuan 2. Please let us know if there are any problems building this release: ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-2.0.15rc1.tar.bz2 ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-2.0.15rc1.tar.bz2.sig Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 200 bytes Desc: not available URL: From Uldis.Ansmits at tieto.com Fri Feb 19 10:57:53 2010 From: Uldis.Ansmits at tieto.com (Uldis.Ansmits at tieto.com) Date: Fri, 19 Feb 2010 11:57:53 +0200 Subject: Gpgme_op_sign(...,GPGME_SIG_MODE_CLEAR) output limited to ~20757 with callback data buffers. Message-ID: <3633BF471A167D4DA60DBD4BA4DDFD0905490DB5E0@EXMB01.eu.tieto.com> Gpgme-1.2.0 I noticed an unexpected signing behaviour for large files when using plain and crypto callback buffers. This happens only in GPGME_SIG_MODE_CLEAR mode. All other operations work fine. The same problem also with gpgme_op_sign_start/wait. It looks like write callback is called after all reading is done. But only part of clearsign data is written. Depending on OS I got 2 - 7 write callbacks (different PIPE_BUF sizes) with total 20751 - 20757 written. Tested on x86_64, IA64, powerpc, sparc. GCC42 was used everywhere. To reproduce: * plain and crypto callback data buffers must be used * only signing opration in GPGME_SIG_MODE_CLEAR mode * plain data more than 20757 bytes Regards, Uldis From marcus.brinkmann at ruhr-uni-bochum.de Sun Feb 21 01:03:41 2010 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: 21 Feb 2010 01:03:41 +0100 Subject: Gpgme_op_sign(..., GPGME_SIG_MODE_CLEAR) output limited to ~20757 with callback data buffers. In-Reply-To: <3633BF471A167D4DA60DBD4BA4DDFD0905490DB5E0@EXMB01.eu.tieto.com> References: <3633BF471A167D4DA60DBD4BA4DDFD0905490DB5E0@EXMB01.eu.tieto.com> Message-ID: <4B80785D.8080102@ruhr-uni-bochum.de> Uldis.Ansmits at tieto.com wrote: > Gpgme-1.2.0 > > I noticed an unexpected signing behaviour for large files when using plain and crypto callback buffers. > This happens only in GPGME_SIG_MODE_CLEAR mode. All other operations work fine. > The same problem also with gpgme_op_sign_start/wait. > > It looks like write callback is called after all reading is done. But only part of clearsign data is written. Depending on OS I got 2 - 7 write callbacks (different PIPE_BUF sizes) with total 20751 - 20757 written. > Tested on x86_64, IA64, powerpc, sparc. GCC42 was used everywhere. > > To reproduce: > * plain and crypto callback data buffers must be used > * only signing opration in GPGME_SIG_MODE_CLEAR mode > * plain data more than 20757 bytes Hi, thanks for the report. It would help me a lot if you could send me an isolated test case, that means a small C program and a data set that, for which you can see the bug. Then I can very quickly see if I can reproduce it and if yes, I should be able to figure out the problem quickly. Also, independent of that, sending a GPGME_DEBUG=9 output file that shows the bug could be helpful. Thanks, Marcus From Uldis.Ansmits at tieto.com Mon Feb 22 09:15:48 2010 From: Uldis.Ansmits at tieto.com (Uldis.Ansmits at tieto.com) Date: Mon, 22 Feb 2010 10:15:48 +0200 Subject: Gpgme_op_sign(...,GPGME_SIG_MODE_CLEAR) output limited to ~20757 with callback data buffers. In-Reply-To: <4B80785D.8080102@ruhr-uni-bochum.de> Message-ID: <3633BF471A167D4DA60DBD4BA4DDFD0905490DB5E4@EXMB01.eu.tieto.com> > Uldis.Ansmits at tieto.com wrote: > > Gpgme-1.2.0 > > > > I noticed an unexpected signing behaviour for large files > when using plain and crypto callback buffers. > > This happens only in GPGME_SIG_MODE_CLEAR mode. All other > operations work fine. > > The same problem also with gpgme_op_sign_start/wait. > > > > It looks like write callback is called after all reading is > done. But only part of clearsign data is written. Depending > on OS I got 2 - 7 write callbacks (different PIPE_BUF sizes) > with total 20751 - 20757 written. > > Tested on x86_64, IA64, powerpc, sparc. GCC42 was used everywhere. > > > > To reproduce: > > * plain and crypto callback data buffers must be used > > * only signing opration in GPGME_SIG_MODE_CLEAR mode > > * plain data more than 20757 bytes > > Hi, > > thanks for the report. It would help me a lot if you could send me an > isolated test case, that means a small C program and a data > set that, for > which you can see the bug. Then I can very quickly see if I > can reproduce it > and if yes, I should be able to figure out the problem quickly. > > Also, independent of that, sending a GPGME_DEBUG=9 output > file that shows the > bug could be helpful. > > Thanks, > Marcus > I modified an existing gpgme test. See patch file. Is look like it is important to sign highly compressible data. Uldis -------------- next part -------------- A non-text attachment was scrubbed... Name: gpgme_debug.log.gz Type: application/x-gzip Size: 9763 bytes Desc: gpgme_debug.log.gz URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: gpgme_op_sign_test.patch Type: application/octet-stream Size: 1424 bytes Desc: gpgme_op_sign_test.patch URL: From Uldis.Ansmits at tieto.com Mon Feb 22 09:18:10 2010 From: Uldis.Ansmits at tieto.com (Uldis.Ansmits at tieto.com) Date: Mon, 22 Feb 2010 10:18:10 +0200 Subject: Gpgme_op_sign(...,GPGME_SIG_MODE_CLEAR) output limited to ~20757 with callback data buffers. In-Reply-To: <3633BF471A167D4DA60DBD4BA4DDFD0905490DB5E4@EXMB01.eu.tieto.com> Message-ID: <3633BF471A167D4DA60DBD4BA4DDFD0905490DB5E5@EXMB01.eu.tieto.com> > I modified an existing gpgme test. See patch file. --- tests/gpg/t-encrypt-large.c.ORIG 2010-02-22 10:00:42.000000000 +0200 +++ tests/gpg/t-encrypt-large.c 2010-02-22 10:02:33.000000000 +0200 @@ -50,6 +50,8 @@ for (; size && parms->bytes_to_send; size--, parms->bytes_to_send--) *p++ = rand (); +/* This seems to be important! Must be highly conmpressable content */ + memset(buffer,'A',p - (char*)buffer); return (p - (char*)buffer); } @@ -103,6 +105,7 @@ err = gpgme_new (&ctx); fail_if_err (err); + gpgme_set_passphrase_cb (ctx, passphrase_cb, NULL); gpgme_set_armor (ctx, 0); /* Install a progress handler to enforce a bit of more work to the @@ -122,15 +125,8 @@ &key[1], 0); fail_if_err (err); - err = gpgme_op_encrypt (ctx, key, GPGME_ENCRYPT_ALWAYS_TRUST, in, out); + err = gpgme_op_sign(ctx, in, out, GPGME_SIG_MODE_CLEAR); fail_if_err (err); - result = gpgme_op_encrypt_result (ctx); - if (result->invalid_recipients) - { - fprintf (stderr, "Invalid recipient encountered: %s\n", - result->invalid_recipients->fpr); - exit (1); - } printf ("plaintext=%u bytes, ciphertext=%u bytes\n", (unsigned int)nbytes, (unsigned int)parms.bytes_received); @@ -139,5 +135,8 @@ gpgme_data_release (in); gpgme_data_release (out); gpgme_release (ctx); + + /* expect the same plain data with signature */ + if(parms.bytes_received Hello, I was not able to build libgpg-error on cygwin and mingw+msys. I had to fix the linking of the resource file because versioninfo.o is generated by libtool into .libs directory and not into the root of the build tree. I hope that this little attached patch could be helpful. I tried to work with your bugzilla first, but I received an HTTP erron every time I tried to access to it. Sincerely, Carlo Bramini. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: libgpg-error.txt URL: From Uldis.Ansmits at tieto.com Tue Feb 23 16:01:36 2010 From: Uldis.Ansmits at tieto.com (Uldis.Ansmits at tieto.com) Date: Tue, 23 Feb 2010 17:01:36 +0200 Subject: gpgme-1.3.0 porting issues on no-GNU platforms Message-ID: <3633BF471A167D4DA60DBD4BA4DDFD0905490DB5EB@EXMB01.eu.tieto.com> gpgme-1.3.0 has been compiled and tested on following non-GNU systems: hppa2.0w-hp-hpux11.00 ia64-hp-hpux11.31 sparc-sun-solaris2.7 sparc-sun-solaris2.10 powerpc-ibm-aix5.2.0.0 Compiler: gcc-4.2 Other libraries: libgpg-error-1.7 libassuan-2.0.0 There were few porting issues. I would like to clarify if they are valid. Runtime issues -------------------------------------------- Patches for gpgme-1.3.0 Critical on AIX. getrlimit return INFINITY for rlim_max. Probably it would better to write "fds = min(rl.rlim_max,rl.rlim_cur)" because it is waste of resources to close more handles than user limit. Without this patch time to spawning new process on AIX takes forever. Similar problem affects gpg-agent form gnupg2. --- src/posix-io.c.ORIG 2009-11-11 13:38:20.000000000 +0200 +++ src/posix-io.c 2009-11-11 14:13:10.000000000 +0200 @@ -225,7 +225,7 @@ if (rc == 0) { source = "RLIMIT_NOFILE"; - fds = rl.rlim_max; + fds = rl.rlim_cur; } } #endif @@ -237,7 +237,7 @@ if (rc == 0) { source = "RLIMIT_OFILE"; - fds = rl.rlim_max; + fds = rl.rlim_cur; } } #endif Critical on Solaris. "rc = ttyname_r (1, dft_ttyname, sizeof (dft_ttyname));" will fail with ERANGE if size of dft_ttyname is 64 bytes. src/engine-assuan.c, src/engine-gpg.c and src/engine-gpgsm.c must be modified for bigger array. --- src/engine-assuan.c.ORIG 2009-11-11 17:38:50.000000000 +0200 +++ src/engine-assuan.c 2009-11-11 17:38:50.000000000 +0200 @@ -28,6 +28,7 @@ #include #endif +#include #include #include #include @@ -245,7 +246,11 @@ if (llass->opt.gpg_agent && isatty (1)) { int rc; +#ifdef _POSIX_PATH_MAX + char dft_ttyname[_POSIX_PATH_MAX]; +#else char dft_ttyname[64]; +#endif char *dft_ttytype = NULL; rc = ttyname_r (1, dft_ttyname, sizeof (dft_ttyname)); This is non-critical because is not typical real-world case. When using several contexts simultaneously, callback functions are called with invalid parameter arguments and data get lost. This can be reproduced with callback based data buffers and when gpgme_wait(,,0) is called for different contexts. Perhaps this is topic for different thread. After this modification "simultenious" callback operations works fine. There are more wait operations though. --- src/wait-global.c.ORIG 2010-01-12 12:55:22.000000000 +0200 +++ src/wait-global.c 2010-01-12 12:55:44.000000000 +0200 @@ -304,6 +304,15 @@ ictx = item->ctx; assert (ictx); + /* Run on specified context only */ + if(ctx) + { + if(ictx != ctx) + { + continue; + } + } + LOCK (ctx->lock); if (ctx->canceled) err = gpg_error (GPG_ERR_CANCELED); This is also non-critical. _gpgme_debug_buffer from src/debug.c is very CPU expensive compared to the rest of gpgme operations. Makes sense to disable debugging for the weak sparch processors. Would be nice to have a configure option. --- src/debug.h.ORIG 2010-01-14 13:19:42.000000000 +0200 +++ src/debug.h 2010-01-14 13:19:54.000000000 +0200 @@ -75,7 +75,7 @@ /* Trace support. */ /* FIXME: For now. */ -#define _gpgme_debug_trace() 1 +#define _gpgme_debug_trace() 0 #define _TRACE(lvl, name, tag) \ int _gpgme_trace_level = lvl; \ Building issues -------------------------------------------- Patch for libgpg-error-1.7 Build time programs require system specific linking options. For example on AIX link option "-Wl,-brtl" will enable runtime linking or on Solaris set of system libraries is required. --- src/Makefile.in.ORIG 2009-12-10 16:34:56.000000000 +0200 +++ src/Makefile.in 2009-12-10 16:38:21.000000000 +0200 @@ -846,7 +846,7 @@ # It is correct to use $(CC_FOR_BUILD) here. We want to run the # program at build time. mkerrcodes: mkerrcodes.c mkerrcodes.h Makefile - $(CC_FOR_BUILD) -I. -I$(srcdir) -o $@ $(srcdir)/mkerrcodes.c + $(CC_FOR_BUILD) -I. -I$(srcdir) -o $@ $(srcdir)/mkerrcodes.c $(CFLAGS) $(LDFLAGS) code-from-errno.h: mkerrcodes Makefile ./mkerrcodes | $(AWK) -f $(srcdir)/mkerrcodes2.awk >$@ Patches for gpgme-1.3.0 Compile time program gpgme_tool needs libassuan --- src/Makefile.in.ORIG 2010-02-23 13:07:06.000000000 +0200 +++ src/Makefile.in 2010-02-23 13:07:06.000000000 +0200 @@ -709,7 +709,7 @@ rm -f $$list gpgme-tool$(EXEEXT): $(gpgme_tool_OBJECTS) $(gpgme_tool_DEPENDENCIES) @rm -f gpgme-tool$(EXEEXT) - $(LINK) $(gpgme_tool_OBJECTS) $(gpgme_tool_LDADD) $(LIBS) + $(LINK) $(gpgme_tool_OBJECTS) $(gpgme_tool_LDADD) $(LIBS) $(LIBASSUAN_LIBS) gpgme-w32spawn$(EXEEXT): $(gpgme_w32spawn_OBJECTS) $(gpgme_w32spawn_DEPENDENCIES) @rm -f gpgme-w32spawn$(EXEEXT) $(LINK) $(gpgme_w32spawn_OBJECTS) $(gpgme_w32spawn_LDADD) $(LIBS) getopt.h is missing on non-GNU system. --- src/gpgme-tool.c.ORIG 2010-02-23 13:51:06.000000000 +0200 +++ src/gpgme-tool.c 2010-02-23 13:51:06.000000000 +0200 @@ -25,7 +25,8 @@ #include #include #include -#include +/* Avoid using getopt.h. Missing on non-GNU platform */ +/* #include */ #include #include #include Regards, Uldis