From gniibe at fsij.org Mon Apr 1 04:26:26 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 01 Apr 2013 11:26:26 +0900 Subject: [GnuPG] DCO for Werner Koch In-Reply-To: <20130329133405.GW9945@odin.tremily.us> References: <87620ahchj.fsf@vigenere.g10code.de> <20130329110032.GM9945@odin.tremily.us> <87li96fjyg.fsf@vigenere.g10code.de> <20130329133405.GW9945@odin.tremily.us> Message-ID: <1364783186.3344.2.camel@cfw2.gniibe.org> On 2013-03-29 at 09:34 -0400, W. Trevor King wrote: > Can you point me towards a > license that qualifies as ?open source? but not as ?free software? (or > vice versa)? I think that when we say "open source license", there would be two meanings: (1) OSI-approved Licenses (2) Licenses that comply with the Open Source Definition The set of #1 is smaller than one of #2. Speaking for major licenses, I think that Original BSD license or Ruby license are in #2, but not in #1. Those are free software licenses, too. There are only minor licenses in #1 which are not free software licenses. I found two: NASA Open Source Agreement 1.3 and Sybase Open Watcom Public License version 1.0. Other than licenses, you can see [0] for the differences. [0] Section "Practical Differences between Free Software and Open Source" in "Why Open Source misses the point of Free Software". http://www.gnu.org/philosophy/open-source-misses-the-point.en.html -- From ueno at gnu.org Mon Apr 1 06:04:14 2013 From: ueno at gnu.org (Daiki Ueno) Date: Mon, 01 Apr 2013 13:04:14 +0900 Subject: Pinentry-mode In-Reply-To: <8738x73mqv.fsf@vigenere.g10code.de> (Werner Koch's message of "Thu, 07 Feb 2013 21:14:16 +0100") References: <8738x73mqv.fsf@vigenere.g10code.de> Message-ID: Hi, Werner Koch writes: > I hope that this feature will make it easier to use GnuPG 2.1 on > non-desktop machines. I have only tested decryption and signing and > thus other parts may not yet work. Thanks for implementing this. It looks useful for epg.el. However, gpg2 seems to write nothing to --status-fd if it is connected to a pipe: $ gpg2 --command-fd 0 --status-fd 1 --pinentry-mode loopback \ --symmetric /dev/null | cat 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! (no further output) while it does without "cat": $ gpg2 --command-fd 0 --status-fd 1 --pinentry-mode loopback \ --symmetric /dev/null 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! [GNUPG:] NEED_PASSPHRASE_SYM 3 3 2 [GNUPG:] GET_HIDDEN passphrase.enter Do you have any idea on this? Since epg.el waits for "GET_HIDDEN" sent over a pipe, currently it stalls if "--pinentry-mode loopback" is supplied. FWIW, I'm attaching a patch to epg.el to support pinentry-mode. Here is a test case: (setq epg-debug t) (setq epg-gpg-program "gpg2") (setq context (epg-make-context 'OpenPGP)) (epg-context-set-pinentry-mode context 'loopback) (epg-encrypt-file context "README" nil nil) Regards, -- Daiki Ueno -------------- next part -------------- A non-text attachment was scrubbed... Name: epg-pinentry-loopback.patch Type: text/x-patch Size: 1976 bytes Desc: not available URL: From rjh at sixdemonbag.org Mon Apr 1 15:44:11 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 01 Apr 2013 09:44:11 -0400 Subject: [GnuPG] DCO for Werner Koch In-Reply-To: <1364783186.3344.2.camel@cfw2.gniibe.org> References: <87620ahchj.fsf@vigenere.g10code.de> <20130329110032.GM9945@odin.tremily.us> <87li96fjyg.fsf@vigenere.g10code.de> <20130329133405.GW9945@odin.tremily.us> <1364783186.3344.2.camel@cfw2.gniibe.org> Message-ID: <51598F2B.8030202@sixdemonbag.org> On 03/31/2013 10:26 PM, NIIBE Yutaka wrote: > On 2013-03-29 at 09:34 -0400, W. Trevor King wrote: >> Can you point me towards a >> license that qualifies as ?open source? but not as ?free software? (or >> vice versa)? (Meant for Trevor more than Yutaka) The Apple Public Source License 1.0 was an OSI-approved open source license that the Free Software Foundation felt was non-free. APSL 2.0, as I understand things, rectified this. From fcojavmc at todo-redes.com Mon Apr 1 21:58:58 2013 From: fcojavmc at todo-redes.com (Fco. Javier M. C.) Date: Mon, 01 Apr 2013 21:58:58 +0200 Subject: Bug in 'libgpg-error' version 1.11 Message-ID: <5159E702.8010801@todo-redes.com> Hello from Spain. Sorry for my English, it's not very good. I think I found a bug in 'libgpg-error' version 1.11 The problem happens when try to compile using 'mxe' (http://mxe.cc/). It's a cross compiler system. When I use it to compile from GNU/Linux to Windows (with --enable-shared) I found that 'configure' inserts twice the tag 'EXPORTS' in generated file 'libgpg-error-1.11/src/.libs/libgpg-error-0.dll.def' and fails to compile with this message: libtool: link: if test "x`/usr/bin/sed 1q .libs/libgpg-error.def`" = xEXPORTS; then cp .libs/libgpg-error.def .libs/libgpg-error-0.dll.def; else echo EXPORTS > .libs/libgpg-error-0.dll.def; cat .libs/libgpg-error.def >> .libs/libgpg-error-0.dll.def; fi libtool: link: i686-pc-mingw32-gcc -shared .libs/libgpg-error-0.dll.def .libs/libgpg_error_la-w32-gettext.o .libs/libgpg_error_la-init.o .libs/libgpg_error_la-version.o .libs/libgpg_error_la-strsource.o .libs/libgpg_error_la-strerror.o .libs/libgpg_error_la-code-to-errno.o .libs/libgpg_error_la-code-from-errno.o .libs/versioninfo.o -O2 -o .libs/libgpg-error-0.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker .libs/libgpg-error.dll.a /mxe/usr/lib/gcc/i686-pc-mingw32/4.8.0/../../../../i686-pc-mingw32/bin/ld: .libs/libgpg-error-0.dll.def:8: syntax error /mxe/usr/lib/gcc/i686-pc-mingw32/4.8.0/../../../../i686-pc-mingw32/bin/ld:.libs/libgpg-error-0.dll.def: file format not recognized; treating as linker script /mxe/usr/lib/gcc/i686-pc-mingw32/4.8.0/../../../../i686-pc-mingw32/bin/ld:.libs/libgpg-error-0.dll.def:7: syntax error It's because this tag it's not found in the first line. The file begins with some blanks lines: libgpg-error-0.dll.def content: ***************************************** EXPORTS EXPORTS gpg_strerror @1 gpg_strerror_r @2 gpg_strsource @3 gpg_err_code_from_errno @4 gpg_err_code_to_errno @5 gpg_err_init @6 gpg_err_code_from_syserror @7 gpg_err_set_errno @8 _gpg_w32_bindtextdomain @11 _gpg_w32_textdomain @12 _gpg_w32_gettext @13 _gpg_w32_dgettext @14 _gpg_w32_dngettext @15 _gpg_w32_gettext_localename @16 _gpg_w32_gettext_use_utf8 @17 gpg_err_deinit @18 gpg_error_check_version @19 ***************************************** I make a patch (attached) to remove this blank lines before check and now it compiles without error. Thank you. Best regards. -- Fco. Javier M. C. ************************* http://todo-redes.com http://bulmagesplus.com ************************* -------------- next part -------------- A non-text attachment was scrubbed... Name: libgpg-error-1.11.patch Type: text/x-patch Size: 4125 bytes Desc: not available URL: From ueno at gnu.org Tue Apr 2 09:08:11 2013 From: ueno at gnu.org (Daiki Ueno) Date: Tue, 02 Apr 2013 16:08:11 +0900 Subject: Pinentry-mode In-Reply-To: (Daiki Ueno's message of "Mon, 01 Apr 2013 13:04:14 +0900") References: <8738x73mqv.fsf@vigenere.g10code.de> Message-ID: Daiki Ueno writes: > However, gpg2 seems to write nothing to --status-fd if it is connected > to a pipe: It seems that this is because of missing fflush in libestream (patch attached). By the way, is there any reason to rely on stdio, given that libestream has its own buffering functions? Perhaps _es_get_std_stream could always use do_fdopen instead of do_fpopen. Regards, -- Daiki Ueno -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Make-sure-to-call-fflush-if-estream_t-is-backed-with.patch Type: text/x-patch Size: 772 bytes Desc: not available URL: From bernhard at intevation.de Thu Apr 4 09:29:43 2013 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 4 Apr 2013 09:29:43 +0200 Subject: Kleo/Kgpg most complete in Linuxmagazin review, gpa and pinentry problems Message-ID: <201304040929.49387.bernhard@intevation.de> Hi GnuPG-Devs, Linuxmagazin 05/2013, pp50-54 has a GnuPG Frontend test in German. The duo Kgpg/Kleopatra provides the most complete set of functions. Seahorse is recommended for unexperienced end users. Also reviewed were GPA and Pyrite. There are a number of shortcoming listed that should be considered for instance the password quality in pinentry-qt that supposetly reports "123456789" as high quality password. Is this really the case, can we fix this? GPA did not offer 2048 bits and writes an empty file when exorting several certificates. There also was a reproducable crash on OpenSuse 12.3. If we want GnuPG to succeed, we should improve our frontends. What they did not test was, how the frontend connected to the backend. To my knowledge GPA and Kleo use the recommened way with gpgme. Kgpg does not, which often poses problems when used with gpg2 and gpg. What about Seahorse and Pyrite? My hope is that Kleo gets improved to fully replace Kgpg some day. Best Regards, Bernhard -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) 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: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Thu Apr 4 16:28:13 2013 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 04 Apr 2013 16:28:13 +0200 Subject: [GnuPG] DCO for Werner Koch In-Reply-To: <20130329133405.GW9945@odin.tremily.us> References: <87620ahchj.fsf@vigenere.g10code.de> <87li96fjyg.fsf@vigenere.g10code.de> <20130329133405.GW9945@odin.tremily.us> Message-ID: <7114680.BLQfaUnJWs@kymo.gruen> I agree that "Free Software" and "Open Source" basically mean the same state of software. They are equivalent terms and but when used they can convey a slightly different style and attitude of the user. I also prefer the term "Free Software" over "Open Source" or "Libre Software". Mostly out of the scientific tradition to use the original term. Am Freitag, 29. M?rz 2013, 09:34:05 schrieb W. Trevor King: > Can you point me towards a > license that qualifies as ?open source? but not as ?free software? (or > vice versa)? I think this debate should be migrated to a different list, e.g. https://lists.fsfe.org/mailman/listinfo/discussion Best Regards, Bernhard -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) 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: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From theblackcase at gmail.com Fri Apr 5 12:12:03 2013 From: theblackcase at gmail.com (Francesco Frontali) Date: Fri, 5 Apr 2013 12:12:03 +0200 Subject: bftest.c bug? Message-ID: When I run an encryption (or decryption) algorithm with bftest.c using the same input but different keys the output is always the same. Why this happens? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dilfridge at gentoo.org Sun Apr 7 12:53:32 2013 From: dilfridge at gentoo.org (Andreas K. Huettel) Date: Sun, 7 Apr 2013 12:53:32 +0200 Subject: card decryption rsa >3072bit Message-ID: <201304071253.40793.dilfridge@gentoo.org> Hi, small question- do you consider this commit safe for backporting onto 2.0.19? (It seems to apply cleanly apart from one whitespace issue.) From ab4ea45f54006eba55db11263431c4c0c4f557dc Mon Sep 17 00:00:00 2001 From: Werner Koch Date: Tue, 6 Nov 2012 14:39:22 +0100 Subject: [PATCH] Allow decryption with card keys > 3072 bit http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=ab4ea45f54006eba55db11263431c4c0c4f557dc (Alternatively, is there a 2.0.20 on the horizon somewhere? :) TIA, best, Andreas -- Andreas K. Huettel Gentoo Linux developer dilfridge at gentoo.org http://www.akhuettel.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 966 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Mon Apr 8 09:17:20 2013 From: wk at gnupg.org (Werner Koch) Date: Mon, 08 Apr 2013 09:17:20 +0200 Subject: card decryption rsa >3072bit In-Reply-To: <201304071253.40793.dilfridge@gentoo.org> (Andreas K. Huettel's message of "Sun, 7 Apr 2013 12:53:32 +0200") References: <201304071253.40793.dilfridge@gentoo.org> Message-ID: <8738v1a3un.fsf@vigenere.g10code.de> On Sun, 7 Apr 2013 12:53, dilfridge at gentoo.org said: > small question- do you consider this commit safe for backporting onto 2.0.19? > (It seems to apply cleanly apart from one whitespace issue.) Yes. However, I have not checked whether this is the only pacthes for that problem. > (Alternatively, is there a 2.0.20 on the horizon somewhere? :) It is long overdue, I know. We did quite some fixes for the smartcard stuff and thus I hope that we can do a release this month. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From bernhard at intevation.de Mon Apr 8 15:45:17 2013 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 8 Apr 2013 15:45:17 +0200 Subject: GPGME_DEBUG on Android, which makes env vars hard In-Reply-To: <507DD6DC.9000402@guardianproject.info> References: <504118FF.3080308@guardianproject.info> <87fw668a2r.fsf@vigenere.g10code.de> <507DD6DC.9000402@guardianproject.info> Message-ID: <201304081545.23045.bernhard@intevation.de> Am Dienstag, 16. Oktober 2012 23:51:24 schrieb Hans-Christoph Steiner: > -- with the string > > > ? ? ?"debug" for NAME and VALUE identical to the value used with the > > ? ? ?environment variable `GPGME_DEBUG'. Still GPGME_DEBUG is not documented in gpgme.texi and it should be. Even when it may be changed in the future. -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) 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: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From dilfridge at gentoo.org Mon Apr 8 17:34:54 2013 From: dilfridge at gentoo.org (Andreas K. Huettel) Date: Mon, 08 Apr 2013 17:34:54 +0200 Subject: card decryption rsa >3072bit In-Reply-To: <8738v1a3un.fsf@vigenere.g10code.de> References: <201304071253.40793.dilfridge@gentoo.org> <8738v1a3un.fsf@vigenere.g10code.de> Message-ID: <3023384.t7lG1Txih0@grenadine> > > small question- do you consider this commit safe for backporting onto > > 2.0.19? (It seems to apply cleanly apart from one whitespace issue.) > > Yes. However, I have not checked whether this is the only pacthes for > that problem. > Well, I can confirm that it works fine here- I have some ZeitControl OpenPGP 2.0 cards, and with that patch added I'm right now using one just fine with three 4096R keys (SC, E, A). Tested signing and decryption so far. Thanks a lot & best, Andreas -- Andreas K. Huettel Gentoo Linux developer kde, sci, arm, tex, printing -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 966 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Mon Apr 8 20:28:13 2013 From: wk at gnupg.org (Werner Koch) Date: Mon, 08 Apr 2013 20:28:13 +0200 Subject: GPGME_DEBUG on Android, which makes env vars hard In-Reply-To: <201304081545.23045.bernhard@intevation.de> (Bernhard Reiter's message of "Mon, 8 Apr 2013 15:45:17 +0200") References: <504118FF.3080308@guardianproject.info> <87fw668a2r.fsf@vigenere.g10code.de> <507DD6DC.9000402@guardianproject.info> <201304081545.23045.bernhard@intevation.de> Message-ID: <87sj307u82.fsf@vigenere.g10code.de> On Mon, 8 Apr 2013 15:45, bernhard at intevation.de said: > Still GPGME_DEBUG is not documented in gpgme.texi and it should be. > Even when it may be changed in the future. Well, it is mentioned. GPGME_DEBUG does not make sense unless you have the source code at your hands. And there you find what you need. GPGME_DEBUG is on purpose not a part of the API but a feature to help maintaining gpgme. There are a few other features which are not documented for the very same reason. As soon as we start to document internal stuff, folks will use that in their applications; something they REALLY SHOULD NOT do but always do (cf. RFC-6919). Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From abbotti at mev.co.uk Wed Apr 10 13:40:36 2013 From: abbotti at mev.co.uk (Ian Abbott) Date: Wed, 10 Apr 2013 12:40:36 +0100 Subject: [PATCH] doc/gpgsm.texi: fix broken @pxref{option --options} Message-ID: <1365594036-22060-1-git-send-email-abbotti@mev.co.uk> The line break and extra whitespace resulted in an error when building the documentation. Even with this fix, the cross reference goes to the wrong place in gnupg.info as the anchor is in gpg-agent.texi. Also if "gpgone" is set, there is a duplicate anchor in gpg.texi which is likely to cause problems. --- doc/gpgsm.texi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/gpgsm.texi b/doc/gpgsm.texi index bdb0378..cfcffba 100644 --- a/doc/gpgsm.texi +++ b/doc/gpgsm.texi @@ -760,8 +760,8 @@ current home directory (@pxref{option --homedir}). This is the standard configuration file read by @command{gpgsm} on startup. It may contain any valid long option; the leading two dashes may not be entered and the option may not be abbreviated. This default -name may be changed on the command line (@pxref{option - --options}). You should backup this file. +name may be changed on the command line (@pxref{option --options}). +You should backup this file. @item policies.txt -- 1.8.1.5 From abbotti at mev.co.uk Wed Apr 10 13:02:45 2013 From: abbotti at mev.co.uk (Ian Abbott) Date: Wed, 10 Apr 2013 12:02:45 +0100 Subject: [PATCH] doc/gpl.texi: fix placement of "@end enumerate" Message-ID: <1365591765-19304-1-git-send-email-abbotti@mev.co.uk> The "@enumerate 0" for the "TERMS AND CONDITIONS" section should finish before the "END OF TERMS AND CONDITIONS" heading. The "@end enumerate" line is currently in the wrong place, so move it. --- doc/gpl.texi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/gpl.texi b/doc/gpl.texi index 7f9a48a..6f5df7c 100644 --- a/doc/gpl.texi +++ b/doc/gpl.texi @@ -659,6 +659,8 @@ an absolute waiver of all civil liability in connection with the Program, unless a warranty or assumption of liability accompanies a copy of the Program in return for a fee. + at end enumerate + @iftex @heading END OF TERMS AND CONDITIONS @end iftex @@ -721,5 +723,3 @@ library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Lesser General Public License instead of this License. But first, please read @url{http://www.gnu.org/philosophy/why-not-lgpl.html}. - - at end enumerate -- 1.8.1.5 From gnupg-devel at spodhuis.org Tue Apr 16 23:05:42 2013 From: gnupg-devel at spodhuis.org (Phil Pennock) Date: Tue, 16 Apr 2013 17:05:42 -0400 Subject: Building master - feedback/notes Message-ID: <20130416210541.GA3064@redoubt.spodhuis.org> Just built master to be able to play with an ECC key, so I can help out with some keyserver issues. Some small notes: * build fails because of no rule to generate doc/DCO which is not in git; I suspect it was missed in a git add but exists on a developer's box? * building libcommon fails with unresolved symbols for libiconv_close and friends; shoving -liconv into LDFLAGS at ./configure time works around this * fig2dev could do with being called out as a build dependency; that in turn requires a bunch of X11 framework, so I bailed, copied the .fig file to a machine with fig2dev installable, generated the targets, copied back, and proceeded The fig.jpg rule invokes "fig2dev -L jpg" but fig2dev barfs on that, because the graphics language is called "jpeg" not "jpg"; "fig2dev Version 3.2 Patchlevel 5d", and I suspect that it doesn't matter because the .jpg just isn't used and it's a stale Makefile rule. Other than the fact that I also need a "cp" which takes the "-a" option, which I could hack around autogen.sh for, everything else went smoothly. Thanks, -Phil From gnupg-devel at spodhuis.org Wed Apr 17 01:44:15 2013 From: gnupg-devel at spodhuis.org (Phil Pennock) Date: Tue, 16 Apr 2013 19:44:15 -0400 Subject: [PATCH] Use $DIRMNGR_INFO to find dirmngr. Message-ID: <20130416234415.GA6083@redoubt.spodhuis.org> From: Phil Pennock Since dirmngr can take --socket-name to point the socket location to somewhere acceptable for the user, the path from $DIRMNGR_INFO is the safest way to find how to communicate. --- common/homedir.c | 21 ++++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-) diff --git a/common/homedir.c b/common/homedir.c index 28e5c9a..526cc16 100644 --- a/common/homedir.c +++ b/common/homedir.c @@ -469,7 +469,26 @@ dirmngr_socket_name (void) } return name; #else /*!HAVE_W32_SYSTEM*/ - return GNUPG_LOCALSTATEDIR "/run/" PACKAGE_NAME "/S.dirmngr"; + const char *default_dirmngr = GNUPG_LOCALSTATEDIR "/run/" PACKAGE_NAME "/S.dirmngr"; + static char *existing; + char *found, *p; + + if (existing != NULL) { + return existing; + } + found = getenv("DIRMNGR_INFO"); + if (found == NULL) { + return default_dirmngr; + } + found = xstrdup(found); + p = strchr(found, ':'); + if (p == NULL) { + free(found); + return default_dirmngr; + } + *p = '\0'; + existing = found; + return existing; #endif /*!HAVE_W32_SYSTEM*/ } -- 1.8.0.1 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 163 bytes Desc: not available URL: From wk at gnupg.org Wed Apr 17 11:39:01 2013 From: wk at gnupg.org (Werner Koch) Date: Wed, 17 Apr 2013 11:39:01 +0200 Subject: Building master - feedback/notes In-Reply-To: <20130416210541.GA3064@redoubt.spodhuis.org> (Phil Pennock's message of "Tue, 16 Apr 2013 17:05:42 -0400") References: <20130416210541.GA3064@redoubt.spodhuis.org> Message-ID: <87wqs1wl6y.fsf@vigenere.g10code.de> On Tue, 16 Apr 2013 23:05, gnupg-devel at spodhuis.org said: > * build fails because of no rule to generate doc/DCO which is not in > git; I suspect it was missed in a git add but exists on a developer's > box? I realized this too when I was on the train yesterday. Pushed. > * building libcommon fails with unresolved symbols for libiconv_close > and friends; shoving -liconv into LDFLAGS at ./configure time works > around this What is special with your environment? Do you use --disable-nls? > * fig2dev could do with being called out as a build dependency; that in > turn requires a bunch of X11 framework, so I bailed, copied the .fig Right, building from git requires the use of some maintainer tools. Not an urgen problem. > The fig.jpg rule invokes "fig2dev -L jpg" but fig2dev barfs on that, > because the graphics language is called "jpeg" not "jpg"; > "fig2dev Version 3.2 Patchlevel 5d", and I suspect that it doesn't > matter because the .jpg just isn't used and it's a stale Makefile > rule. Fixed it anyway. > Other than the fact that I also need a "cp" which takes the "-a" option, > which I could hack around autogen.sh for, everything else went smoothly. I can't remember why I used -a. It is not needed here. Both, -a and -v are not POSIX and should thus be avoided. I guess this is a relic from a bashism. Given that we need to use chmod anyway, shall I change it to cat? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Apr 17 11:53:45 2013 From: wk at gnupg.org (Werner Koch) Date: Wed, 17 Apr 2013 11:53:45 +0200 Subject: [PATCH] Use $DIRMNGR_INFO to find dirmngr. In-Reply-To: <20130416234415.GA6083@redoubt.spodhuis.org> (Phil Pennock's message of "Tue, 16 Apr 2013 19:44:15 -0400") References: <20130416234415.GA6083@redoubt.spodhuis.org> Message-ID: <87sj2pwkie.fsf@vigenere.g10code.de> On Wed, 17 Apr 2013 01:44, gnupg-devel at spodhuis.org said: > Since dirmngr can take --socket-name to point the socket location > to somewhere acceptable for the user, the path from $DIRMNGR_INFO > is the safest way to find how to communicate. Dirmngr was designed as a system service, thus the hardwired socket name. The whole thing will be changed anyway to be started on demand, much like gpg-agent. Thus this patch does not make sense. Some comments anyway: The ChangeLog Entries are mssing; see doc/HACKING. > + if (existing != NULL) { Please do me a favour and avoid comparsions to NULL. if (existsing) { } is much easier to read and less error prone. Yes, I know there are different schools, but in GnuPG this should be used if you remember it. Please also use GNU indentation style; for master most of the code has been converted to that style and thus new code should generally be written in this style. Well, for a small change of existing old-style indented code, you would keep the old style. > + found = xstrdup(found); > + p = strchr(found, ':'); > + if (p == NULL) { > + free(found); Please always use xfree instead of free. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From abbotti at mev.co.uk Wed Apr 17 16:31:44 2013 From: abbotti at mev.co.uk (Ian Abbott) Date: Wed, 17 Apr 2013 15:31:44 +0100 Subject: Building master - feedback/notes In-Reply-To: <87wqs1wl6y.fsf@vigenere.g10code.de> References: <20130416210541.GA3064@redoubt.spodhuis.org> <87wqs1wl6y.fsf@vigenere.g10code.de> Message-ID: <516EB250.4030606@mev.co.uk> On 2013/04/17 10:39 AM, Werner Koch wrote: > On Tue, 16 Apr 2013 23:05, gnupg-devel at spodhuis.org said: > >> * build fails because of no rule to generate doc/DCO which is not in >> git; I suspect it was missed in a git add but exists on a developer's >> box? > > I realized this too when I was on the train yesterday. Pushed. Also, there are errors when building the docs with the latest Texinfo. (5.0 onwards seem less tolerant of mistakes than earlier versions.) I posted a couple of patches last week to correct the build errors, although there are still problems with links going to the wrong anchors at various places in the .info file, e.g. for @pxref{options --options} for various programs linking to the documentation a different program. >> Other than the fact that I also need a "cp" which takes the "-a" option, >> which I could hack around autogen.sh for, everything else went smoothly. > > I can't remember why I used -a. It is not needed here. Both, -a and -v > are not POSIX and should thus be avoided. I guess this is a relic from > a bashism. Given that we need to use chmod anyway, shall I change it to > cat? Wouldn't a plain old cp do? -- -=( Ian Abbott @ MEV Ltd. E-mail: )=- -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=- From gnupg-devel at spodhuis.org Wed Apr 17 20:25:27 2013 From: gnupg-devel at spodhuis.org (Phil Pennock) Date: Wed, 17 Apr 2013 14:25:27 -0400 Subject: Building master - feedback/notes In-Reply-To: <87wqs1wl6y.fsf@vigenere.g10code.de> References: <20130416210541.GA3064@redoubt.spodhuis.org> <87wqs1wl6y.fsf@vigenere.g10code.de> Message-ID: <20130417182526.GA57727@redoubt.spodhuis.org> On 2013-04-17 at 11:39 +0200, Werner Koch wrote: > On Tue, 16 Apr 2013 23:05, gnupg-devel at spodhuis.org said: > > * building libcommon fails with unresolved symbols for libiconv_close > > and friends; shoving -liconv into LDFLAGS at ./configure time works > > around this > > What is special with your environment? Do you use --disable-nls? Yes. Shouldn't affect ability to translate character sets, surely? > > Other than the fact that I also need a "cp" which takes the "-a" option, > > which I could hack around autogen.sh for, everything else went smoothly. > > I can't remember why I used -a. It is not needed here. Both, -a and -v > are not POSIX and should thus be avoided. I guess this is a relic from > a bashism. Given that we need to use chmod anyway, shall I change it to > cat? "-a" is equivalent to "-RpP" and all three of those options are present in the SUSv4 cp(1) specification. -Phil From lbeith at rwu.edu Wed Apr 17 23:06:37 2013 From: lbeith at rwu.edu (Beith, Linda) Date: Wed, 17 Apr 2013 17:06:37 -0400 Subject: decryption question Message-ID: Hi folks, Please excuse cross-posting but I wasn't sure which list was the best option for my dilemma. I am new to the list and am hoping someone can provide some suggestions for a situation we have at my University. We have had a rather catastrophic loss of all data from one of our Fall 2012 courses on our Sakai open source learning management server. To compound matters, we have a military student who had an incomplete in that course and is on deadline to finish his work and submit his grades or face being dropped from his academic program. Since our Sakai instance is hosted by a third-party vendor we don't have direct access to the application at the server level, so each month the vendor makes a backup copy of our full database and encrypts/zips it using GNU PG so we can download it. We then decrypt it using the passcode they provide and we can run stats against the resulting SQL file. I had a backup file from early December 2012 that I had downloaded but never opened. I sent the file back to our vendor in hopes of being able to retrieve the course data however when they tried to unzip/decrypt it, they were not prompted for the passcode and just got an error: Gpg: can't open 'rwu.dbdump_Nov2012.sql.gz.gpg' Gpg: decrypt_message filed: file open error We can't have them redo the backup because it is too late - the files are no longer on their server. So the only source of the work is locked in this zipped file. The zipped file is quite large - over 1 GB so we know there is data there - we just can't get to it. The assumption is that something went wrong in the original encryption of the file. Do you have idea if it is possible to extract data in this situation? I appreciate any help or suggestions you can provide, Linda Linda L. Beith, Ph.D. Roger Williams University Director, Instructional Design One Old Ferry Road, Bristol RI 401-254-3134 Website: id.rwu.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From pgut001 at cs.auckland.ac.nz Wed Apr 17 23:56:16 2013 From: pgut001 at cs.auckland.ac.nz (Peter Gutmann) Date: Thu, 18 Apr 2013 09:56:16 +1200 Subject: decryption question In-Reply-To: Message-ID: "Beith, Linda" writes: >The assumption is that something went wrong in the original encryption of >the file. Do you have idea if it is possible to extract data in this >situation? A first step would be to run pgpdump ( http://www.mew.org/~kazu/proj/pgpdump/en/ or http://packages.debian.org/unstable/utils/pgpdump) on it to see what it is, i.e whether it's a valid PGP file or not, and what the format is. Peter. From dshaw at jabberwocky.com Thu Apr 18 05:31:42 2013 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 17 Apr 2013 23:31:42 -0400 Subject: decryption question In-Reply-To: References: Message-ID: On Apr 17, 2013, at 5:06 PM, "Beith, Linda" wrote: > Hi folks, > Please excuse cross-posting but I wasn?t sure which list was the best option for my dilemma. > > I am new to the list and am hoping someone can provide some suggestions for a situation we have at my University. We have had a rather catastrophic loss of all data from one of our Fall 2012 courses on our Sakai open source learning management server. To compound matters, we have a military student who had an incomplete in that course and is on deadline to finish his work and submit his grades or face being dropped from his academic program. > > Since our Sakai instance is hosted by a third-party vendor we don?t have direct access to the application at the server level, so each month the vendor makes a backup copy of our full database and encrypts/zips it using GNU PG so we can download it. We then decrypt it using the passcode they provide and we can run stats against the resulting SQL file. > > I had a backup file from early December 2012 that I had downloaded but never opened. I sent the file back to our vendor in hopes of being able to retrieve the course data however when they tried to unzip/decrypt it, they were not prompted for the passcode and just got an error: > > Gpg: can?t open ?rwu.dbdump_Nov2012.sql.gz.gpg? > Gpg: decrypt_message filed: file open error > > We can?t have them redo the backup because it is too late ? the files are no longer on their server. So the only source of the work is locked in this zipped file. The zipped file is quite large ? over 1 GB so we know there is data there ? we just can?t get to it. > > The assumption is that something went wrong in the original encryption of the file. Do you have idea if it is possible to extract data in this situation? > > I appreciate any help or suggestions you can provide, A few questions: If it doesn't work to decrypt it at the vendor, does it work if you decrypt it locally like you normally do when you run stats against the SQL? What version of GPG is your vendor using (run "gpg --version" to check) ? What platform is your vendor running GPG on (Linux / Other Unix-like / Windows / etc.) ? How do you download the file from your vendor once they create it (i.e. ftp, http, scp ... ?) How did you send it back to them for decryption? That specific error message indicates that the decryption hadn't even started yet. For example, it's the error you would get if you ran "gpg --decrypt this-file-does-not-exist.gpg". David From wk at gnupg.org Thu Apr 18 09:37:15 2013 From: wk at gnupg.org (Werner Koch) Date: Thu, 18 Apr 2013 09:37:15 +0200 Subject: Building master - feedback/notes In-Reply-To: <20130417182526.GA57727@redoubt.spodhuis.org> (Phil Pennock's message of "Wed, 17 Apr 2013 14:25:27 -0400") References: <20130416210541.GA3064@redoubt.spodhuis.org> <87wqs1wl6y.fsf@vigenere.g10code.de> <20130417182526.GA57727@redoubt.spodhuis.org> Message-ID: <87txn4uw5w.fsf@vigenere.g10code.de> On Wed, 17 Apr 2013 20:25, gnupg-devel at spodhuis.org said: > Yes. Shouldn't affect ability to translate character sets, surely? Right. Do you have the same problem with the 2.0 branch? > in the SUSv4 cp(1) specification. My woodware manuals are still SUSv3 ;-) Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From lbeith at rwu.edu Thu Apr 18 16:04:22 2013 From: lbeith at rwu.edu (Beith, Linda) Date: Thu, 18 Apr 2013 10:04:22 -0400 Subject: decryption question In-Reply-To: References: Message-ID: Thanks Peter. I'll try this. Linda -----Original Message----- From: Peter Gutmann [mailto:pgut001 at cs.auckland.ac.nz] Sent: Wednesday, April 17, 2013 5:56 PM To: gnupg-devel at gnupg.org; Beith, Linda Subject: Re: decryption question "Beith, Linda" writes: >The assumption is that something went wrong in the original encryption >of the file. Do you have idea if it is possible to extract data in this >situation? A first step would be to run pgpdump ( http://www.mew.org/~kazu/proj/pgpdump/en/ or http://packages.debian.org/unstable/utils/pgpdump) on it to see what it is, i.e whether it's a valid PGP file or not, and what the format is. Peter. From wk at gnupg.org Thu Apr 18 17:38:56 2013 From: wk at gnupg.org (Werner Koch) Date: Thu, 18 Apr 2013 17:38:56 +0200 Subject: [Announce] Libgcrypt 1.5.2 released Message-ID: <87y5cfu9v3.fsf@vigenere.g10code.de> Hello! The GNU project is pleased to announce the availability of Libgcrypt version 1.5.2. This is a maintenance release for the stable branch. Libgcrypt is a general purpose library of cryptographic building blocks. It is originally based on code used by GnuPG. It does not provide any implementation of OpenPGP or other protocols. Thorough understanding of applied cryptography is required to use Libgcrypt. Noteworthy changes in version 1.5.2: * Added support for IDEA. * Made the Padlock code work again (regression since 1.5.0). * Fixed alignment problems for Serpent. * Fixed two bugs in ECC computations. Source code is hosted at the GnuPG FTP server and its mirrors as listed at http://www.gnupg.org/download/mirrors.html . On the primary server the source file and its digital signatures is: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.5.2.tar.bz2 (1.5M) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.5.2.tar.bz2.sig This file is bzip2 compressed. A gzip compressed version is also available: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.5.2.tar.gz (1.8M) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.5.2.tar.gz.sig Alternativley you may upgrade version 1.5.1 using this patch file: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.5.1-1.5.2.diff.bz2 (12k) The SHA-1 checksums are: c9998383532ba3e8bcaf690f2f0d65e814b48d2f libgcrypt-1.5.2.tar.bz2 fb54bfea3e276a366009c5a6296eb83cf5e7c14b libgcrypt-1.5.2.tar.gz 086ac76cf91987f66666872cc7d5d5d33c68967e libgcrypt-1.5.1-1.5.2.diff.bz2 For help on developing with Libgcrypt you should read the included manual and optional ask on the gcrypt-devel mailing list [1]. A listing with commercial support offers for Libgcrypt and related software is available at the GnuPG web site [2]. The driving force behind the development of Libgcrypt is my company g10 Code. Maintenance and improvement of Libgcrypt and related software takes up most of our resources. To allow us to continue our work on free software, we ask to either purchase a support contract, engage us for custom enhancements, or to donate money: http://g10code.com/gnupg-donation.html Many thanks to all who contributed to Libgcrypt development, be it bug fixes, code, documentation, testing or helping users. Happy hacking, Werner [1] See http://www.gnupg.org/documentation/mailing-lists.html . [2] See http://www.gnupg.org/service.html -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 204 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From gnupg-devel at spodhuis.org Fri Apr 19 01:03:15 2013 From: gnupg-devel at spodhuis.org (Phil Pennock) Date: Thu, 18 Apr 2013 19:03:15 -0400 Subject: Building master - feedback/notes In-Reply-To: <87txn4uw5w.fsf@vigenere.g10code.de> References: <20130416210541.GA3064@redoubt.spodhuis.org> <87wqs1wl6y.fsf@vigenere.g10code.de> <20130417182526.GA57727@redoubt.spodhuis.org> <87txn4uw5w.fsf@vigenere.g10code.de> Message-ID: <20130418230315.GA11564@redoubt.spodhuis.org> On 2013-04-18 at 09:37 +0200, Werner Koch wrote: > On Wed, 17 Apr 2013 20:25, gnupg-devel at spodhuis.org said: > > > Yes. Shouldn't affect ability to translate character sets, surely? > > Right. Do you have the same problem with the 2.0 branch? Yes. > > in the SUSv4 cp(1) specification. > > My woodware manuals are still SUSv3 ;-) That's okay, the same flags exist in SUSv3 too. You have to go back to SUSv2 to lose the -P option. -Phil From wk at gnupg.org Fri Apr 19 10:44:05 2013 From: wk at gnupg.org (Werner Koch) Date: Fri, 19 Apr 2013 10:44:05 +0200 Subject: Bug in 'libgpg-error' version 1.11 In-Reply-To: <5159E702.8010801@todo-redes.com> (Fco. Javier M. C.'s message of "Mon, 01 Apr 2013 21:58:58 +0200") References: <5159E702.8010801@todo-redes.com> Message-ID: <87zjwusyei.fsf@vigenere.g10code.de> On Mon, 1 Apr 2013 21:58, fcojavmc at todo-redes.com said: > The problem happens when try to compile using 'mxe' (http://mxe.cc/). > It's a cross compiler system. When I use it to compile from GNU/Linux to > Windows (with --enable-shared) I found that 'configure' inserts twice Only the toolchains listed in autogen.sh are supported. Due to the reluctance of some toolchain maintainers in keeping solid backward compatibility it may unfortunately happen that newer releases of a tool chain stop working. > the tag 'EXPORTS' in generated file > 'libgpg-error-1.11/src/.libs/libgpg-error-0.dll.def' and fails to This is already known and will be addressed as soon we switch to a non-working toolchain version. This will likely happen in the next months, because we will work on gpg4win again. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Apr 19 12:08:59 2013 From: wk at gnupg.org (Werner Koch) Date: Fri, 19 Apr 2013 12:08:59 +0200 Subject: Pinentry-mode In-Reply-To: (Daiki Ueno's message of "Tue, 02 Apr 2013 16:08:11 +0900") References: <8738x73mqv.fsf@vigenere.g10code.de> Message-ID: <87fvymsuh0.fsf@vigenere.g10code.de> On Tue, 2 Apr 2013 09:08, ueno at gnu.org said: > It seems that this is because of missing fflush in libestream (patch The usual problem. > attached). By the way, is there any reason to rely on stdio, given that > libestream has its own buffering functions? Perhaps _es_get_std_stream No, it has not yet been converted. Will do now. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Apr 19 12:06:13 2013 From: wk at gnupg.org (Werner Koch) Date: Fri, 19 Apr 2013 12:06:13 +0200 Subject: Building master - feedback/notes In-Reply-To: <516EB250.4030606@mev.co.uk> (Ian Abbott's message of "Wed, 17 Apr 2013 15:31:44 +0100") References: <20130416210541.GA3064@redoubt.spodhuis.org> <87wqs1wl6y.fsf@vigenere.g10code.de> <516EB250.4030606@mev.co.uk> Message-ID: <87k3nysulm.fsf@vigenere.g10code.de> On Wed, 17 Apr 2013 16:31, abbotti at mev.co.uk said: > Also, there are errors when building the docs with the latest Texinfo. > (5.0 onwards seem less tolerant of mistakes than earlier versions.) I I have not yet updated to it. If only org-mode would have better index support and something akin deftypefun I'd switch away from good old texinfo. > posted a couple of patches last week to correct the build errors, > although there are still problems with links going to the wrong anchors > at various places in the .info file, e.g. for @pxref{options --options} I just fixed those you reported. > Wouldn't a plain old cp do? Yes. But cat is the simpler tool. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Apr 19 12:24:04 2013 From: wk at gnupg.org (Werner Koch) Date: Fri, 19 Apr 2013 12:24:04 +0200 Subject: Pinentry-mode In-Reply-To: <87fvymsuh0.fsf@vigenere.g10code.de> (Werner Koch's message of "Fri, 19 Apr 2013 12:08:59 +0200") References: <8738x73mqv.fsf@vigenere.g10code.de> <87fvymsuh0.fsf@vigenere.g10code.de> Message-ID: <87bo9astrv.fsf@vigenere.g10code.de> On Fri, 19 Apr 2013 12:08, wk at gnupg.org said: >> attached). By the way, is there any reason to rely on stdio, given that >> libestream has its own buffering functions? Perhaps _es_get_std_stream > > No, it has not yet been converted. Will do now. Please disregard my comment. The reason why we need to use stdio is that for one this is the only portable way on Unix and that I did not found another way to make our pipe emulation code work under WindowsCE. Better don't touch it. Calling fflush is easier. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gniibe at fsij.org Tue Apr 23 04:56:44 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 23 Apr 2013 11:56:44 +0900 Subject: [PATCH] Add pinpad support for REINER SCT cyberJack go Message-ID: <1366685804.2837.5.camel@cfw2.gniibe.org> Hello, This patch is for STABLE-BRANCH-2-0. I think that it should be included to forthcoming 2.0.20. I'd like to apply this if there's no problem. It builds successfully. This is based on Alina Friedrichsen's work of March 11 2013. After that, I modify the ccid-driver a bit, thus, I revise it so that it could be included to forthcoming 2.0.20. I don't know if Alina will submit a patch for master, but I expect so. It adds vendor ID and product ID for Reiner cyberJack go, and modify ccid_transceive_secure to handle the case of VENDOR_REINER. In the patch enumeration constants for vendor ID are sorted by their values. In ccid_transceive_secure, I don't put checking for product ID, like the case of Vasco, expecting newer products from those vendors will also support the feature. * scd/ccid-driver.c (VENDOR_REINER, CYBERJACK_GO): New (ccid_transceive_secure): Handle the case for VENDOR_REINER. -- Original work by Alina Friedrichsen. diff --git a/scd/ccid-driver.c b/scd/ccid-driver.c index c3a66fa..42a219f 100644 --- a/scd/ccid-driver.c +++ b/scd/ccid-driver.c @@ -212,9 +212,10 @@ enum { VENDOR_OMNIKEY= 0x076b, VENDOR_GEMPC = 0x08e6, VENDOR_VEGA = 0x0982, + VENDOR_REINER = 0x0c4b, VENDOR_KAAN = 0x0d46, + VENDOR_VASCO = 0x1a44, VENDOR_FSIJ = 0x234b, - VENDOR_VASCO = 0x1a44 }; /* Some product ids. */ @@ -227,6 +228,7 @@ enum { #define VASCO_920 0x0920 #define GEMPC_PINPAD 0x3478 #define VEGA_ALPHA 0x0008 +#define CYBERJACK_GO 0x0504 /* A list and a table with special transport descriptions. */ enum { @@ -3376,6 +3378,7 @@ ccid_transceive_secure (ccid_driver_t handle, pininfo->maxlen = 25; enable_varlen = 1; break; + case VENDOR_REINER: /* Tested with cyberJack go */ case VENDOR_VASCO: /* Tested with DIGIPASS 920 */ enable_varlen = 1; break; -- From wk at gnupg.org Tue Apr 23 14:59:33 2013 From: wk at gnupg.org (Werner Koch) Date: Tue, 23 Apr 2013 14:59:33 +0200 Subject: [PATCH] Add pinpad support for REINER SCT cyberJack go In-Reply-To: <1366685804.2837.5.camel@cfw2.gniibe.org> (NIIBE Yutaka's message of "Tue, 23 Apr 2013 11:56:44 +0900") References: <1366685804.2837.5.camel@cfw2.gniibe.org> Message-ID: <87bo95mmh6.fsf@vigenere.g10code.de> On Tue, 23 Apr 2013 04:56, gniibe at fsij.org said: > This patch is for STABLE-BRANCH-2-0. I think that it should be > included to forthcoming 2.0.20. I'd like to apply this if there's no Please go ahead. I'd like to do a 2.0.20 release later this week. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Apr 24 12:33:52 2013 From: wk at gnupg.org (Werner Koch) Date: Wed, 24 Apr 2013 12:33:52 +0200 Subject: gnupg-2.0.19 test failures on GNU/Linux Red Hat 5.8 IA-64 (Itanium) In-Reply-To: (Nelson H. F. Beebe's message of "Thu, 5 Apr 2012 09:46:39 -0600 (MDT)") References: Message-ID: <87obd4w73j.fsf@vigenere.g10code.de> Hi, On Thu, 5 Apr 2012 17:46, beebe at math.utah.edu said: > I've just made a series of experiments with builds of gnupg-2.0.19 on > Red Hat 5.8 IA-64 (Itanium) with multiple compilers: > Only the build with icc passed all of the tests, so I have > installed that one. I just did a test with the current 2.0 code on an IA64 under Debian. I had to install in my home directory and needed to build my own libpth (2.0.7 plus ia64 patch). The first test failed at decrypt.tyst and several others. Manual testing again worked then. I remove the gnupg tree and build it again and all tests succeeded. The only difference is that during the first build I had not set LD_LIBRARY_PATH and thus the "make" in tests failed. I set LD_LIBRARY_PATH, ran "make" and "make check" again and it failed as described. I also did a "make distclean" and build again, with full success. dmesg showed several hardware errors and lost page write errors on that machine thus this might have been the problem. gcc 4.4.5 > gpg: WARNING: unsafe permissions on homedir `.' > gpg: problem with the agent: Broken pipe > > Here are the home directory permissions: > > % ls -lFd ~/. > drwxr-xr-x 309 XXXXXX wheel 1434 Apr 5 08:29 /XXXXXX > > They look okay to me, and in any event, the tests pass with icc, so > the same test with gcc compilation should not fail either. The permissions are just a warning. The GnuPG home directory should not be world readable - but for a test this doesn't matter. > Also, in the output > > 3DES CAST5 BLOWFISH AES AES192 AES256 TWOFISH CAMELLIA128 CAMELLIA192 CAMELLIA256 | PASS: conventional.test > 3DES FAIL: conventional-mdc.test I have changed that to PASS: decrypt.test PASS: decrypt-dsa.test > MD5 SHA1 RIPEMD160 SHA256 SHA384 SHA512 SHA224 < PASS: sigs.test Hope this helps. Thanks for all your tests. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Apr 24 21:40:51 2013 From: wk at gnupg.org (Werner Koch) Date: Wed, 24 Apr 2013 21:40:51 +0200 Subject: 2.0.20 beta available Message-ID: <87bo93wwcc.fsf@vigenere.g10code.de> Hi, it is now more than a year since we released 2.0.19. Thus it is really time to get 2.0.20 out of the door. If you want to quickly try a beta you may use: ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-2.0.20-beta118.tar.bz2 Please send bug reports only to the mailing list. Noteworthy changes in version 2.0.20 (unreleased) ------------------------------------------------- * The hash algorithm is now printed for sig records in key listings. * Decryption using smartcards keys > 3072 bit does not work. * New meta option ignore-invalid-option to allow using the same option file by other GnuPG versions. * [gpg] Skip invalid keyblock packets during import to avoid a DoS. * [gpg] Correctly handle ports from DNS SRV records. * [gpg-agent] Avoid tty corruption when killing pinentry. * [scdaemon] Rename option --disable-keypad to --disable-pinpad. * [scdaemon] Better support for CCID readers. Now, the internal CCID driver supports readers without the auto configuration feature. * [scdaemon] Add pinpad input for PC/SC, if your reader has pinpad and it supports variable length PIN input, and you specify --enable-pinpad-varlen option. * [scdaemon] New option --enable-pinpad-varlen. * [scdaemon] Install into libexecdir to avoid accidental execution from the command line. The code also builds for Windows and we plan to do a Gpg4win release soon after 2.0.20. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gniibe at fsij.org Thu Apr 25 01:57:45 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 25 Apr 2013 08:57:45 +0900 Subject: 2.0.20 beta available In-Reply-To: <87bo93wwcc.fsf@vigenere.g10code.de> References: <87bo93wwcc.fsf@vigenere.g10code.de> Message-ID: <1366847865.3503.2.camel@cfw2.gniibe.org> I found a simple error in the release note. On 2013-04-24 at 21:40 +0200, Werner Koch wrote: > * Decryption using smartcards keys > 3072 bit does not work. It _does_ work now by the commit: ab4ea45f54006eba55db11263431c4c0c4f557dc Werner Koch Tue, 6 Nov 2012 13:39:22 +0000 (14:39 +0100) Allow decryption with card keys > 3072 bit Reviewing the diff again, I found an indentation mistake in agent_scd_pkdecrypt. The 'if' statement inside the 'for' has wrong indentation. -- From wk at gnupg.org Thu Apr 25 09:30:07 2013 From: wk at gnupg.org (Werner Koch) Date: Thu, 25 Apr 2013 09:30:07 +0200 Subject: 2.0.20 beta available In-Reply-To: <1366847865.3503.2.camel@cfw2.gniibe.org> (NIIBE Yutaka's message of "Thu, 25 Apr 2013 08:57:45 +0900") References: <87bo93wwcc.fsf@vigenere.g10code.de> <1366847865.3503.2.camel@cfw2.gniibe.org> Message-ID: <87txmvukxs.fsf@vigenere.g10code.de> On Thu, 25 Apr 2013 01:57, gniibe at fsij.org said: >> * Decryption using smartcards keys > 3072 bit does not work. > > It _does_ work now by the commit: ab4ea45f54006eba55db11263431c4c0c4f557dc Ooops, what a single letter makes a difference: s/not/now/ > Reviewing the diff again, I found an indentation mistake in > agent_scd_pkdecrypt. The 'if' statement inside the 'for' has wrong > indentation. I'll fix that in my working copy. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Apr 25 09:34:38 2013 From: wk at gnupg.org (Werner Koch) Date: Thu, 25 Apr 2013 09:34:38 +0200 Subject: 2.0.20 beta available In-Reply-To: (David Tomaschik's message of "Wed, 24 Apr 2013 14:04:50 -0700") References: <87bo93wwcc.fsf@vigenere.g10code.de> Message-ID: <87ppxjukq9.fsf@vigenere.g10code.de> On Wed, 24 Apr 2013 23:04, david at systemoverlord.com said: > * Decryption using smartcards keys > 3072 bit does not work. s/not/now/ Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From abbotti at mev.co.uk Thu Apr 25 13:00:11 2013 From: abbotti at mev.co.uk (Ian Abbott) Date: Thu, 25 Apr 2013 12:00:11 +0100 Subject: [PATCH 0/5] doc: fix some Texinfo warnings Message-ID: <1366887616-18318-1-git-send-email-abbotti@mev.co.uk> These five patches fix some warnings from Texinfo 5 by adding some missing nodes and changing some sections to subsections, and moving an '@end ifset' to the start of a line. I also noticed the 'Deprecated options' subsection didn't appear in the GPG options menu, so I added it. (Texinfo never warned about it because it was after the last node in the menu.) 1) doc/gpg.texi: move '@end ifset' to start of line 2) doc/gpg.texi: Add missing node for 'Compliance options' section. 3) doc/gpg.texi: add node for 'Deprecated options' subsection. 4) doc/gpg.texi: make 'Unattended key generation' a subsection 5) doc/gpgsm.texi: fix subsectioning for Unattended Usage doc/gpg.texi | 12 ++++++++---- doc/gpgsm.texi | 8 ++++---- 2 files changed, 12 insertions(+), 8 deletions(-) From abbotti at mev.co.uk Thu Apr 25 13:00:12 2013 From: abbotti at mev.co.uk (Ian Abbott) Date: Thu, 25 Apr 2013 12:00:12 +0100 Subject: [PATCH 1/5] doc/gpg.texi: move '@end ifset' to start of line In-Reply-To: <1366887616-18318-1-git-send-email-abbotti@mev.co.uk> References: <1366887616-18318-1-git-send-email-abbotti@mev.co.uk> Message-ID: <1366887616-18318-2-git-send-email-abbotti@mev.co.uk> Fix Texinfo warning: @end ifset should only appear at a line beginning. --- doc/gpg.texi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/gpg.texi b/doc/gpg.texi index cec4581..3b34185 100644 --- a/doc/gpg.texi +++ b/doc/gpg.texi @@ -2990,9 +2990,9 @@ Operation is further controlled by a few environment variables: @item GPG_AGENT_INFO Used to locate the gpg-agent. - @ifset gpgone + at ifset gpgone This is only honored when @option{--use-agent} is set. - @end ifset + at end ifset The value consists of 3 colon delimited fields: The first is the path to the Unix Domain Socket, the second the PID of the gpg-agent and the protocol version which should be set to 1. When starting the gpg-agent -- 1.8.1.5 From abbotti at mev.co.uk Thu Apr 25 13:00:13 2013 From: abbotti at mev.co.uk (Ian Abbott) Date: Thu, 25 Apr 2013 12:00:13 +0100 Subject: [PATCH 2/5] doc/gpg.texi: Add missing node for 'Compliance options' section. In-Reply-To: <1366887616-18318-1-git-send-email-abbotti@mev.co.uk> References: <1366887616-18318-1-git-send-email-abbotti@mev.co.uk> Message-ID: <1366887616-18318-3-git-send-email-abbotti@mev.co.uk> Fixes a couple of Texinfo warnings for gpg.texi: warning: node `GPG Esotetic Options' is next for `OpenPGP Options' in menu but not in sectioning warning: node `OpenPGP Options' is prev for `GPG Esoteric Options' in menu but not in sectioning --- doc/gpg.texi | 2 ++ 1 file changed, 2 insertions(+) diff --git a/doc/gpg.texi b/doc/gpg.texi index 3b34185..ebc7fa0 100644 --- a/doc/gpg.texi +++ b/doc/gpg.texi @@ -926,6 +926,7 @@ behaviour and to change the default configuration. * GPG Key related Options:: Key related options. * GPG Input and Output:: Input and Output. * OpenPGP Options:: OpenPGP protocol specific options. +* Compliance Options:: Compliance options. * GPG Esoteric Options:: Doing things one usually don't want to do. @end menu @@ -2183,6 +2184,7 @@ meaningful if @option{--s2k-mode} is 3. @c *************************** @c ******* Compliance ******** @c *************************** + at node Compliance Options @subsection Compliance options These options control what GnuPG is compliant to. Only one of these -- 1.8.1.5 From abbotti at mev.co.uk Thu Apr 25 13:00:14 2013 From: abbotti at mev.co.uk (Ian Abbott) Date: Thu, 25 Apr 2013 12:00:14 +0100 Subject: [PATCH 3/5] doc/gpg.texi: add node for 'Deprecated options' subsection. In-Reply-To: <1366887616-18318-1-git-send-email-abbotti@mev.co.uk> References: <1366887616-18318-1-git-send-email-abbotti@mev.co.uk> Message-ID: <1366887616-18318-4-git-send-email-abbotti@mev.co.uk> It's missing from the GPG options menu. --- doc/gpg.texi | 2 ++ 1 file changed, 2 insertions(+) diff --git a/doc/gpg.texi b/doc/gpg.texi index ebc7fa0..4e75970 100644 --- a/doc/gpg.texi +++ b/doc/gpg.texi @@ -928,6 +928,7 @@ behaviour and to change the default configuration. * OpenPGP Options:: OpenPGP protocol specific options. * Compliance Options:: Compliance options. * GPG Esoteric Options:: Doing things one usually don't want to do. +* Deprecated Options:: Deprecated options. @end menu Long options can be put in an options file (default @@ -2847,6 +2848,7 @@ on the configuration file. @c ******************************* @c ******* Deprecated ************ @c ******************************* + at node Deprecated Options @subsection Deprecated options @table @gnupgtabopt -- 1.8.1.5 From abbotti at mev.co.uk Thu Apr 25 13:00:16 2013 From: abbotti at mev.co.uk (Ian Abbott) Date: Thu, 25 Apr 2013 12:00:16 +0100 Subject: [PATCH 5/5] doc/gpgsm.texi: fix subsectioning for Unattended Usage menu. In-Reply-To: <1366887616-18318-1-git-send-email-abbotti@mev.co.uk> References: <1366887616-18318-1-git-send-email-abbotti@mev.co.uk> Message-ID: <1366887616-18318-6-git-send-email-abbotti@mev.co.uk> Change the 'Automated signature checking' and 'CSR and certificate creation' sections to subsections of the 'Unattended Usage' section. This corrects some Texinfo warnings. warning: node next `Unattended Usage' in menu `GPGSM Protocol' and in sectioning `Automated signature checking' differ warning: node prev `GPGSM Protocol' in menu `Unattended Usage' and in sectioning `CSR and certificate creation' differ --- doc/gpgsm.texi | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/doc/gpgsm.texi b/doc/gpgsm.texi index 6a84391..f7cedaf 100644 --- a/doc/gpgsm.texi +++ b/doc/gpgsm.texi @@ -916,8 +916,8 @@ but may also be used in the standard operation mode by using the * CSR and certificate creation:: CSR and certificate creation. @end menu - at node Automated signature checking,,,Unattended Usage - at section Automated signature checking + at node Automated signature checking + at subsection Automated signature checking It is very important to understand the semantics used with signature verification. Checking a signature is not as simple as it may sound and @@ -960,8 +960,8 @@ this is a missing certificate. @end table - at node CSR and certificate creation,,,Unattended Usage - at section CSR and certificate creation + at node CSR and certificate creation + at subsection CSR and certificate creation @ifclear gpgtwoone @strong{Please notice}: The immediate creation of certificates is only -- 1.8.1.5 From abbotti at mev.co.uk Thu Apr 25 13:00:15 2013 From: abbotti at mev.co.uk (Ian Abbott) Date: Thu, 25 Apr 2013 12:00:15 +0100 Subject: [PATCH 4/5] doc/gpg.texi: make 'Unattended key generation' a subsection. In-Reply-To: <1366887616-18318-1-git-send-email-abbotti@mev.co.uk> References: <1366887616-18318-1-git-send-email-abbotti@mev.co.uk> Message-ID: <1366887616-18318-5-git-send-email-abbotti@mev.co.uk> Make 'Unattended key generation' a subsection of the 'Unattended Usage' section. This fixes a Texinfo warning. warning: node `Unattended GPG key generation' is next for `Unattended Usage of GPG' in sectioning but not in menu --- doc/gpg.texi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/gpg.texi b/doc/gpg.texi index 4e75970..a88ddca 100644 --- a/doc/gpg.texi +++ b/doc/gpg.texi @@ -3171,8 +3171,8 @@ are almost always required for this. @end menu - at node Unattended GPG key generation,,,Unattended Usage of GPG - at section Unattended key generation + at node Unattended GPG key generation + at subsection Unattended key generation The command @option{--gen-key} may be used along with the option @option{--batch} for unattended key generation. The parameters are -- 1.8.1.5 From philcerf at googlemail.com Mon Apr 29 02:34:07 2013 From: philcerf at googlemail.com (Philippe Cerfon) Date: Mon, 29 Apr 2013 02:34:07 +0200 Subject: SHA3 IANA registration - method? In-Reply-To: <50D0AB16.5020505@brainhub.org> References: <20121212104620.GA35659@redoubt.spodhuis.org> <4599875.rlaQdxBocv@inno> <50CF972C.5080403@brainhub.org> <1534234.5QBUm8ahIh@inno> <50CFA8E4.2060502@brainhub.org> <50CFAE63.2020106@fifthhorseman.net> <50CFB283.7090108@brainhub.org> <50CFC07E.60909@fifthhorseman.net> <50D0AB16.5020505@brainhub.org> Message-ID: A bit late perhaps and also somewhat OT (especially as this is gnupg-devel not openpgp)... but anyway most active OpenPGP folks seem to read here as well. If there was a redesign of the OpenPGP formats along with e.g. SHA3, it would make sense to generalise all a bit, e.g.: 1) much more property fields that describe the key holder E.g. place/date of birth, colour of eyes, size, etc. also current properties like the name should be made better (an probably decoupled from the mail), like family name, surname(s), titles and styles and properties for names of non-western cultures... etc. pp. perhaps also one (or more) "common name" which is the most common representation of a key holders name (e.g. )... further things like email addresses, chat accounts, etc. Same for the image, what does it show? The key holder? His fingerprint? And eye scan? His heraldic emblem? Perhaps also fields that are suited for key usage where the owner is no a person (but e.g. a webserver). 2) The UID should no longer be the name but rather a string which semi-uniqly identifies the key in the realm where it will be used, with probably a recommendation, that on global scope this should be an email adress (although then without the name). 3) IMHO, everything should be tightened up a bit, e.g. things like the critical-flag should become the default and rather a non-critical flag should be introduced. Unknown sig subpackets should be generally considered to be critical. etc. pp. Cheers, Phil. From mailinglisten at hauke-laging.de Mon Apr 29 04:37:32 2013 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Mon, 29 Apr 2013 04:37:32 +0200 Subject: OpenPGPv5 wish list In-Reply-To: References: <20121212104620.GA35659@redoubt.spodhuis.org> <50D0AB16.5020505@brainhub.org> Message-ID: <2584059.Q9cNNqxsta@inno> Am Mo 29.04.2013, 02:34:07 schrieb Philippe Cerfon: > If there was a redesign of the OpenPGP formats along with e.g. SHA3, Wishlist opened? :-D > 1) much more property fields that describe the key holder That's easy as it can be done with notations; no need to change the protocol. Other things we IMHO really need notation standards for: 1) How secure is the key? 2) What is the key used for? 3) How was the identity checked when certifying, how the email address and how the comment? 4) What statement does this signature make? > 2) The UID should no longer You should not be forced to sign a UID as a whole. If I am sure about the name and email but not about the comment why do I have to decide for all or nothing? But this could be done with notations as mentioned above. Things I want in the protocol: 1) For compatibility with the signature laws: We really need the option to extend certifications from UIDs to subkeys. That way you could have a "normal" key and a CA could be sure that a certain subkey is on a smartcard only. 2) Officially supported offline main keys. Currently just a GnuPG extension. IMHO the most important feature with respect to security (for everyday usage keys). 3) Double-digest signatures and double-cipher encryption in case one gets broken. 4) Signature weight: Limit the signing power of a key (to 1/n) so that signatures of n different keys are enforced for paranoid applications. 5) Seperate header files for encryption. We have detached signatures. Today you have to rewrite a huge encrypted file if you want to add (or remove) recipients. 6) A kind of detached timestamp signature for public key export files. For a secure revocation system you need to be able to prove when a key was (not yet) revoked. See the signature laws. Thus we need a way to show that a certain state of the key is the current one. And this should be done without polluting the key with daily certifications which you never get rid of. Furthermore this would offer a guarantee that the key is complete (which we do not have at all today). This would also reduce the traffic for key servers caused by formal (reading) updates: The client sends a hash over the key it has and if that is the same for the key on the key server then the key server just returns the latest timestamp signature. These signatures could be distributed independently of the key servers to further reduce the load on the key servers and get some privacy (hide which keys you are interested in). Changes to GnuPG: 1) I would like a setting that a certain key makes local signatures only (unless --expert --i-really-know-what-i... is given). This would make life easier for beginners (and the people who train them). 2) Besides ownertrust (which I prefer calling certification trust as this may vary for different keys with the same owner) we should be able to assign a security value to a key (not for the public, just like ownertrust) and this should be shown to the applications on top of GnuPG. It seems crazy to me that the only relevant characteristic of another one's key is its validity. I am afraid that this behaviour rather obstructs the users' awareness for the relevant aspects of a crypto system. 3) I would like to have a more flexible trust system. Why only "complete" and "marginal" trust? Why is it important to work with such groups? Why can this value not be set for each key, 1.0 for one, 0.7 for the next, 0.1 for the other? 4) I miss an explicit per key trust calculation. Today we just see the result (valid, marginally valid or invalid). But if you want to limit possible damage by allowing only your keys to make others valid then you are lost because you cannot make GnuPG show you a list of the trust values of signatures. Hauke -- ? PGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 (seit 2012-11-04) http://www.openpgp-schulungen.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 572 bytes Desc: This is a digitally signed message part. URL: From rjh at sixdemonbag.org Mon Apr 29 07:17:04 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 29 Apr 2013 01:17:04 -0400 Subject: OpenPGPv5 wish list In-Reply-To: <2584059.Q9cNNqxsta@inno> References: <20121212104620.GA35659@redoubt.spodhuis.org> <50D0AB16.5020505@brainhub.org> <2584059.Q9cNNqxsta@inno> Message-ID: <517E0250.1040708@sixdemonbag.org> On 4/28/2013 10:37 PM, Hauke Laging wrote: > Other things we IMHO really need notation standards for: This really isn't the place for it, guys. GnuPG-devel is for discussion of how to make GnuPG track the standard better; the OpenPGP list is for discussion of how to make the standard itself better. > Things I want in the protocol: I'll make my own wish list simple: I don't want *anything* new included in the standard unless there exists at least one user who says, "the absence of this feature is a showstopper for me and is blocking my adoption of GnuPG." This user needs to be able to show a real-world use case and be willing to volunteer to run trials in a real-world environment. No real-world user? No feature. That's my own wish list, and I desperately hope it comes to pass. :) From pete at petertodd.org Mon Apr 29 06:18:09 2013 From: pete at petertodd.org (Peter Todd) Date: Mon, 29 Apr 2013 00:18:09 -0400 Subject: OpenPGPv5 wish list In-Reply-To: <2584059.Q9cNNqxsta@inno> References: <20121212104620.GA35659@redoubt.spodhuis.org> <50D0AB16.5020505@brainhub.org> <2584059.Q9cNNqxsta@inno> Message-ID: <20130429041809.GA4119@savin> On Mon, Apr 29, 2013 at 04:37:32AM +0200, Hauke Laging wrote: > 6) A kind of detached timestamp signature for public key export files. For a > secure revocation system you need to be able to prove when a key was (not yet) > revoked. See the signature laws. Thus we need a way to show that a certain FWIW I've got timestamping PGP keys on my todo list. I'm the author of the OpenTimestamps software (https://github.com/opentimestamps) and while the project isn't at all ready for prime-time one thing I would like to see possible with it is to attach a timestamp to a PGP key. I'll admit I didn't think of attaching timestamps to signatures; I'm sure you guys understand the details of what's required better than I do. After looking at RFC4880 my thinking was to do an initial implementation as a user attribute packet using the 100-110 range reserved for experimental use - the timestamp would just be for the PGP SHA1 fingerprint, possibly with a SHA256 fingerprint in parallel. OpenTimestamps is designed around hash chain timestamping, typically as a merkle-tree of timestamps with some hash at the top being signed by some authority. The way it's actually been used is with the Bitcoin network as that authority, but there is no reason why other authorities are not possible, or even multiple ones. For instance RFC3161 timestamping support is on my todo list. Bitcoin is neat because it's decentralized and verifying a timestamp is correct can be done by just downloading the Bitcoin block headers, ~20MB of data. On the other hand the viability of the timestamps depends on Bitcoin itself; who knows if Bitcoin will survive in the long run. The resolution is also not that good, roughly two hours. Another neat thing Bitcoin can do is act as a source of unpredictable but publicly known nonces, allowing you to prove that a signature was created *after* a particular date in addition to *before* a particular date. Interestingly someone did recently timestamp the fingerprints of every key in the PGP strong set with Bitcoin: https://bitcointalk.org/index.php?topic=186264.msg1967993#msg1967993 although the particular way they did it is kinda abusive towards Bitcoin itself. -- 'peter'[:-1]@petertodd.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: Digital signature URL: From wk at gnupg.org Mon Apr 29 13:52:29 2013 From: wk at gnupg.org (Werner Koch) Date: Mon, 29 Apr 2013 13:52:29 +0200 Subject: SHA3 IANA registration - method? In-Reply-To: (Philippe Cerfon's message of "Mon, 29 Apr 2013 02:34:07 +0200") References: <20121212104620.GA35659@redoubt.spodhuis.org> <4599875.rlaQdxBocv@inno> <50CF972C.5080403@brainhub.org> <1534234.5QBUm8ahIh@inno> <50CFA8E4.2060502@brainhub.org> <50CFAE63.2020106@fifthhorseman.net> <50CFB283.7090108@brainhub.org> <50CFC07E.60909@fifthhorseman.net> <50D0AB16.5020505@brainhub.org> Message-ID: <87ehdttuyq.fsf@vigenere.g10code.de> On Mon, 29 Apr 2013 02:34, philcerf at googlemail.com said: > 1) much more property fields that describe the key holder I don't want the whole X.509 mess introduced in a protocol we tried to keep clean for real use. > 2) The UID should no longer be the name but rather a string which > semi-uniqly identifies the key in the realm where it will be used, Please read 5.11: A User ID packet consists of UTF-8 text that is intended to represent the name and email address of the key holder. By convention, it includes an RFC 2822 [RFC2822] mail name-addr, but there are no restrictions on its content. The packet length in the header specifies the length of the User ID. There is nothing which enforces how you represet the name, you may put arbitrary data into the UID. However, it is common to use a mail address and thus GnuPG (by default) checks for that. > 3) IMHO, everything should be tightened up a bit, e.g. things like the > critical-flag should become the default and rather a non-critical flag > should be introduced. Unknown sig subpackets should be generally Why should we change somthing which has not shown problems in the past. If you want X.509, use X.509 for example with gpgsm. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Apr 29 13:56:12 2013 From: wk at gnupg.org (Werner Koch) Date: Mon, 29 Apr 2013 13:56:12 +0200 Subject: OpenPGPv5 wish list In-Reply-To: <2584059.Q9cNNqxsta@inno> (Hauke Laging's message of "Mon, 29 Apr 2013 04:37:32 +0200") References: <20121212104620.GA35659@redoubt.spodhuis.org> <50D0AB16.5020505@brainhub.org> <2584059.Q9cNNqxsta@inno> Message-ID: <87a9ohtusj.fsf@vigenere.g10code.de> On Mon, 29 Apr 2013 04:37, mailinglisten at hauke-laging.de said: > 1) I would like a setting that a certain key makes local signatures only > (unless --expert --i-really-know-what-i... is given). This would make life > easier for beginners (and the people who train them). I can see why you want that but I would leave this decision to the authors of a GUI frontends. > 2) Besides ownertrust (which I prefer calling certification trust as this may > vary for different keys with the same owner) we should be able to assign a > security value to a key (not for the public, just like ownertrust) and this > should be shown to the applications on top of GnuPG. It seems crazy to me that > the only relevant characteristic of another one's key is its validity. I am You may add your own trust model on top of GnuPG. The current default one is already way to complex and you still want to make it even more complex. Crypto featurism was in the 90ies - we learned that this was a dangerous habit. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Apr 29 13:59:21 2013 From: wk at gnupg.org (Werner Koch) Date: Mon, 29 Apr 2013 13:59:21 +0200 Subject: OpenPGPv5 wish list In-Reply-To: <20130429041809.GA4119@savin> (Peter Todd's message of "Mon, 29 Apr 2013 00:18:09 -0400") References: <20121212104620.GA35659@redoubt.spodhuis.org> <50D0AB16.5020505@brainhub.org> <2584059.Q9cNNqxsta@inno> <20130429041809.GA4119@savin> Message-ID: <8761z5tuna.fsf@vigenere.g10code.de> On Mon, 29 Apr 2013 06:18, pete at petertodd.org said: > FWIW I've got timestamping PGP keys on my todo list. I'm the author of I can see that this makes sense. > After looking at RFC4880 my thinking was to do an initial implementation > as a user attribute packet using the 100-110 range reserved for The answer you will likely receive from the OpenPGP WG list is to use notification data. We can talk about implementation details in GnuPG here. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From cryptostick at privacyfoundation.de Mon Apr 29 14:12:05 2013 From: cryptostick at privacyfoundation.de (Crypto Stick) Date: Mon, 29 Apr 2013 20:12:05 +0800 Subject: Crypto Stick accepted for Google Summer of Code Message-ID: <517E6395.7080305@privacyfoundation.de> Crypto Stick (you may know that it contains an OpenPGP Card) has been accepted as a mentor organization for Google Summer of Code (GSOC) 2013. If you are a student interested in working on cool crypto stuff related to OpenPGP and smart cards - this is for you. You can apply for a project with us and if accepted our mentors will work with you over the summer and Google will sponsor you USD 5000 during that time. Please check out our ideas page at https://www.assembla.com/spaces/cryptostick/wiki/Ideas or suggest your own idea. And, join our mailinglist to discuss it: https://lists.crypto-stick.org/mailman/listinfo/dev Your applications should be submitted through Google Melange (https://google-melange.com) until 3rd May! You can continue to submit additional information and comments into the system after your initial application submission. In order to participate in the program, you must be a student in an accredited institution or university. Links: * Crypto Stick project: http://crypto-stick.org * Ideas Page: https://www.assembla.com/spaces/cryptostick/wiki/Ideas * GSOC Progam F&Q: https://google-melange.appspot.com/gsoc/document/show/gsoc_program/google/gsoc2013/help_page * Crypto Stick Mailing List: https://lists.crypto-stick.org/mailman/listinfo/dev Regards, Jan From pete at petertodd.org Mon Apr 29 18:08:24 2013 From: pete at petertodd.org (Peter Todd) Date: Mon, 29 Apr 2013 12:08:24 -0400 Subject: OpenPGPv5 wish list In-Reply-To: <8761z5tuna.fsf@vigenere.g10code.de> References: <20121212104620.GA35659@redoubt.spodhuis.org> <50D0AB16.5020505@brainhub.org> <2584059.Q9cNNqxsta@inno> <20130429041809.GA4119@savin> <8761z5tuna.fsf@vigenere.g10code.de> Message-ID: <20130429160812.GA31682@petertodd.org> On Mon, Apr 29, 2013 at 01:59:21PM +0200, Werner Koch wrote: > > After looking at RFC4880 my thinking was to do an initial implementation > > as a user attribute packet using the 100-110 range reserved for > > The answer you will likely receive from the OpenPGP WG list is to use > notification data. Could anyone tell me what exactly is notification data? The term doesn't seem to be in the RFC4880 or the gnupg source. Also, the last email in the WG list archives is from a year ago, dead? > We can talk about implementation details in GnuPG here. Sure -- 'peter'[:-1]@petertodd.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From mailinglisten at hauke-laging.de Mon Apr 29 18:15:24 2013 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Mon, 29 Apr 2013 18:15:24 +0200 Subject: OpenPGPv5 wish list In-Reply-To: <20130429160812.GA31682@petertodd.org> References: <20121212104620.GA35659@redoubt.spodhuis.org> <8761z5tuna.fsf@vigenere.g10code.de> <20130429160812.GA31682@petertodd.org> Message-ID: <12433995.kyRy8OcWhK@inno> Am Mo 29.04.2013, 12:08:24 schrieb Peter Todd: > On Mon, Apr 29, 2013 at 01:59:21PM +0200, Werner Koch wrote: > > The answer you will likely receive from the OpenPGP WG list is to use > > notification data. > > Could anyone tell me what exactly is notification data? The term doesn't > seem to be in the RFC4880 or the gnupg source. He probably meant this: 10.2.2.1. Signature Notation Data Subpackets Hauke -- ? PGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 (seit 2012-11-04) http://www.openpgp-schulungen.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 572 bytes Desc: This is a digitally signed message part. URL: From John at enigmail.net Mon Apr 29 20:03:20 2013 From: John at enigmail.net (John Clizbe) Date: Mon, 29 Apr 2013 13:03:20 -0500 Subject: OpenPGPv5 wish list In-Reply-To: <20130429160812.GA31682@petertodd.org> References: <20121212104620.GA35659@redoubt.spodhuis.org> <50D0AB16.5020505@brainhub.org> <2584059.Q9cNNqxsta@inno> <20130429041809.GA4119@savin> <8761z5tuna.fsf@vigenere.g10code.de> <20130429160812.GA31682@petertodd.org> Message-ID: <517EB5E8.5060809@enigmail.net> Peter Todd wrote: > On Mon, Apr 29, 2013 at 01:59:21PM +0200, Werner Koch wrote: >> > After looking at RFC4880 my thinking was to do an initial implementation >> > as a user attribute packet using the 100-110 range reserved for >> >> The answer you will likely receive from the OpenPGP WG list is to use >> notification data. > > Could anyone tell me what exactly is notification data? The term doesn't > seem to be in the RFC4880 or the gnupg source. Signature Notation Data most likely > Also, the last email in the WG list archives is from a year ago, dead? Hardly. It's low volume while no work is being done on the standard, but there was a flurry of messages in early March of this year. The list was changed after Steve Bellovin's message of last April 5th. https://www.ietf.org/mailman/listinfo/openpgp >> We can talk about implementation details in GnuPG here. > > Sure -- John P. Clizbe Inet: John (a) Gingerbear DAWT net SKS/Enigmail/PGP-EKP or: John ( @ ) Enigmail DAWT net FSF Assoc #995 / FSFE Fellow #1797 hkp://keyserver.gingerbear.net or mailto:pgp-public-keys at gingerbear.net?subject=HELP Q:"Just how do the residents of Haiku, Hawai'i hold conversations?" A:"An odd melody / island voices on the winds / surplus of vowels" From wk at gnupg.org Mon Apr 29 20:46:01 2013 From: wk at gnupg.org (Werner Koch) Date: Mon, 29 Apr 2013 20:46:01 +0200 Subject: OpenPGPv5 wish list In-Reply-To: <12433995.kyRy8OcWhK@inno> (Hauke Laging's message of "Mon, 29 Apr 2013 18:15:24 +0200") References: <20121212104620.GA35659@redoubt.spodhuis.org> <8761z5tuna.fsf@vigenere.g10code.de> <20130429160812.GA31682@petertodd.org> <12433995.kyRy8OcWhK@inno> Message-ID: <87obcxrx92.fsf@vigenere.g10code.de> On Mon, 29 Apr 2013 18:15, mailinglisten at hauke-laging.de said: > 10.2.2.1. Signature Notation Data Subpackets Yeah sure, I switched from a different context to GnuPG. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From jeanjacquesbrucker at gmail.com Mon Apr 29 12:17:03 2013 From: jeanjacquesbrucker at gmail.com (Jean-Jacques) Date: Mon, 29 Apr 2013 10:17:03 -0000 Subject: OpenPGPv5 wish list In-Reply-To: <517E0250.1040708@sixdemonbag.org> References: <20121212104620.GA35659@redoubt.spodhuis.org> <50D0AB16.5020505@brainhub.org> <2584059.Q9cNNqxsta@inno> <517E0250.1040708@sixdemonbag.org> Message-ID: <20130429111532.7e53c7f6@gmail.com> Le Mon, 29 Apr 2013 01:17:04 -0400, "Robert J. Hansen" a ?crit : > On 4/28/2013 10:37 PM, Hauke Laging wrote: > > Other things we IMHO really need notation standards for: > > This really isn't the place for it, guys. GnuPG-devel is for > discussion of how to make GnuPG track the standard better; the > OpenPGP list is for discussion of how to make the standard itself > better. Yep, so I switched the thread to the other mailing list. > > > Things I want in the protocol: > > I'll make my own wish list simple: > > I don't want *anything* new included in the standard unless there > exists at least one user who says, "the absence of this feature is a > showstopper for me and is blocking my adoption of GnuPG." This user > needs to be able to show a real-world use case and be willing to > volunteer to run trials in a real-world environment. > > No real-world user? No feature. So I answered because I really "need" such feature in OpenPGP for real-world : 2) What is the key used for? And I see at least 4 purposes : - To authenticate itself through TLS [RFC6091] - Maybe To sign other certificates (subkeys on smartcard issues) - To authenticate through HTTP (gpgauth or https://github.com/Open-UDC/open-udc/blob/master/docs/HTTP_OpenPGP_Authentication.draft.txt) - To sign an OpenUDC transaction. I work especially on the 2 last purposes. And having the possibility for the owner to set descriptions, or more flags on its (sub)keys inside its OpenPGP certificate, would be a more elegant solution than some workaround we have to manage. > > That's my own wish list, and I desperately hope it comes to pass. :) > We have to better organize A wish list, or it will be a mess to identify their elements. :-) --- jbar. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: not available URL: