From dshaw at jabberwocky.com Mon Aug 2 17:03:04 2004 From: dshaw at jabberwocky.com (David Shaw) Date: Mon Aug 2 17:00:00 2004 Subject: Feature Request: More output on signature In-Reply-To: <1091212542.12601.63.camel@liberate> References: <20040522134540.GB13121@jabberwocky.com> <1091212542.12601.63.camel@liberate> Message-ID: <20040802150303.GA25001@jabberwocky.com> On Fri, Jul 30, 2004 at 02:35:42PM -0400, Douglas F. Calvert wrote: > On Sat, 2004-05-22 at 09:45 -0400, David Shaw wrote: > > This release brings development even closer to a good point for 1.4. > > If there is something that you do not like here, be it a missing > > feature, a UI choice, or, well, anything, now is the time to speak up. > > Once 1.3.x becomes the new stable, large changes will be unlikely. > > While we obviously cannot guarantee that every suggestion will be > > included, they will all be looked at. > > I would like to see an option that made gpg print out more information > during signature verifications. When keys are q, m or f trusted I would > like to be able to discern what the trust path looks like. I am not > exactly sure what I would want it to look like, this is the hard part. > Anyone else have any thoughts on this? I'm afraid giving a trust path is not going to be possible for 1.4. It's far more invasive than I want to get into this close to release. > Also it would be nice to have gpg notify users if there is a new key > preference that they should set. I generated my keys pre-MDC I was > unaware that this feature was added until i started digging around > in the prefs. This would have been a nice time to educate users on > MDC and increase the number of keys that had this option set. The problem here is how does GnuPG tell the difference between a pref that wasn't set because you generated your key a long time ago, and a pref you unset on purpose because you didn't want it set. It might be worth putting something in the release notes to mention that running an "updpref" is a good idea, but GnuPG itself shouldn't try and be smarter than the user with prefs. David From macro at linux-mips.org Mon Aug 2 13:50:43 2004 From: macro at linux-mips.org (Maciej W. Rozycki) Date: Mon Aug 2 19:24:32 2004 Subject: [patch] 1.2.5: aclocal 1.8 compatibility Message-ID: Hello, Since automake 1.8 aclocal requires macro names being defined by AC_DEFUN to be quoted. Here is a patch that adds missing quotations. 2004-08-02 Maciej W. Rozycki * acinclude.m4: Quote names of macros to be defined by AC_DEFUN throughout. * aclocal.m4: Regenerate. * configure: Regenerate. Please apply. Maciej gnupg-1.2.4-am18.patch diff -up --recursive --new-file gnupg-1.2.4.macro/acinclude.m4 gnupg-1.2.4/acinclude.m4 --- gnupg-1.2.4.macro/acinclude.m4 2003-04-15 12:16:18.000000000 +0000 +++ gnupg-1.2.4/acinclude.m4 2004-06-10 21:39:42.000000000 +0000 @@ -28,7 +28,7 @@ define(GNUPG_MSG_PRINT, dnl GNUPG_CHECK_TYPEDEF(TYPE, HAVE_NAME) dnl Check whether a typedef exists and create a #define $2 if it exists dnl -AC_DEFUN(GNUPG_CHECK_TYPEDEF, +AC_DEFUN([GNUPG_CHECK_TYPEDEF], [ AC_MSG_CHECKING(for $1 typedef) AC_CACHE_VAL(gnupg_cv_typedef_$1, [AC_TRY_COMPILE([#define _GNU_SOURCE 1 @@ -46,7 +46,7 @@ AC_DEFUN(GNUPG_CHECK_TYPEDEF, dnl GNUPG_CHECK_GNUMAKE dnl -AC_DEFUN(GNUPG_CHECK_GNUMAKE, +AC_DEFUN([GNUPG_CHECK_GNUMAKE], [ if ${MAKE-make} --version 2>/dev/null | grep '^GNU ' >/dev/null 2>&1; then : @@ -64,7 +64,7 @@ AC_DEFUN(GNUPG_CHECK_GNUMAKE, dnl GNUPG_CHECK_FAQPROG dnl -AC_DEFUN(GNUPG_CHECK_FAQPROG, +AC_DEFUN([GNUPG_CHECK_FAQPROG], [ AC_MSG_CHECKING(for faqprog.pl) if faqprog.pl -V 2>/dev/null | grep '^faqprog.pl ' >/dev/null 2>&1; then working_faqprog=yes @@ -91,7 +91,7 @@ dnl fi dnl GNUPG_CHECK_DOCBOOK_TO_TEXI dnl -AC_DEFUN(GNUPG_CHECK_DOCBOOK_TO_TEXI, +AC_DEFUN([GNUPG_CHECK_DOCBOOK_TO_TEXI], [ AC_CHECK_PROG(DOCBOOK_TO_TEXI, docbook2texi, yes, no) AC_MSG_CHECKING(for sgml to texi tools) @@ -459,7 +459,7 @@ define(GNUPG_CHECK_MLOCK, ################################################################ # GNUPG_PROG_NM - find the path to a BSD-compatible name lister -AC_DEFUN(GNUPG_PROG_NM, +AC_DEFUN([GNUPG_PROG_NM], [AC_MSG_CHECKING([for BSD-compatible nm]) AC_CACHE_VAL(ac_cv_path_NM, [if test -n "$NM"; then @@ -493,7 +493,7 @@ AC_SUBST(NM) # GNUPG_SYS_NM_PARSE - Check for command ro grab the raw symbol name followed # by C symbol name from nm. -AC_DEFUN(GNUPG_SYS_NM_PARSE, +AC_DEFUN([GNUPG_SYS_NM_PARSE], [AC_REQUIRE([AC_CANONICAL_HOST])dnl AC_REQUIRE([GNUPG_PROG_NM])dnl # Check for command to grab the raw symbol name followed by C symbol from nm. @@ -660,14 +660,14 @@ AC_MSG_RESULT($ac_result) ]) # GNUPG_SYS_LIBTOOL_CYGWIN32 - find tools needed on cygwin32 -AC_DEFUN(GNUPG_SYS_LIBTOOL_CYGWIN32, +AC_DEFUN([GNUPG_SYS_LIBTOOL_CYGWIN32], [AC_CHECK_TOOL(DLLTOOL, dlltool, false) AC_CHECK_TOOL(AS, as, false) ]) # GNUPG_SYS_SYMBOL_UNDERSCORE - does the compiler prefix global symbols # with an underscore? -AC_DEFUN(GNUPG_SYS_SYMBOL_UNDERSCORE, +AC_DEFUN([GNUPG_SYS_SYMBOL_UNDERSCORE], [tmp_do_check="no" case "${target}" in i386-emx-os2 | i[3456]86-pc-os2*emx | i386-pc-msdosdjgpp) @@ -728,7 +728,7 @@ fi dnl Stolen from gcc dnl Define MKDIR_TAKES_ONE_ARG if mkdir accepts only one argument instead dnl of the usual 2. -AC_DEFUN(GNUPG_FUNC_MKDIR_TAKES_ONE_ARG, +AC_DEFUN([GNUPG_FUNC_MKDIR_TAKES_ONE_ARG], [AC_CHECK_HEADERS(sys/stat.h unistd.h direct.h) AC_CACHE_CHECK([if mkdir takes one argument], gnupg_cv_mkdir_takes_one_arg, [AC_TRY_COMPILE([ From macro at linux-mips.org Mon Aug 2 14:38:43 2004 From: macro at linux-mips.org (Maciej W. Rozycki) Date: Mon Aug 2 19:24:50 2004 Subject: [patch] 1.2.5: Fix nomenclature for cross-compilation Message-ID: Hello, Gnupg currently uses the term "target" to refer to the system it's going to be run on. That contradicts the autoconf definition of the target system, which is reserved for tools like compilers that deal with system-specific formats while running on a different system. The system software is going to be run on is correctly referred to as "host". Here is a patch that makes appropriate corrections to scripts. 2004-08-02 Maciej W. Rozycki * acinclude.m4: Replace references to "target" with "host" throughout. * configure.ac: Likewise. Replace a call to AC_CANONICAL_TARGET with AC_CANONICAL_HOST. * aclocal.m4: Regenerate. * configure: Regenerate. Please apply. Maciej gnupg-1.2.4-host.patch diff -up --recursive --new-file gnupg-1.2.4.macro/acinclude.m4 gnupg-1.2.4/acinclude.m4 --- gnupg-1.2.4.macro/acinclude.m4 2003-04-15 12:16:18.000000000 +0000 +++ gnupg-1.2.4/acinclude.m4 2004-06-10 21:35:46.000000000 +0000 @@ -168,13 +168,13 @@ dnl GNUPG_CHECK_CACHE dnl define(GNUPG_CHECK_CACHE, [ AC_MSG_CHECKING(cached information) - gnupg_hostcheck="$target" + gnupg_hostcheck="$host" AC_CACHE_VAL(gnupg_cv_hostcheck, [ gnupg_cv_hostcheck="$gnupg_hostcheck" ]) if test "$gnupg_cv_hostcheck" != "$gnupg_hostcheck"; then AC_MSG_RESULT(changed) AC_MSG_WARN(config.cache exists!) AC_MSG_ERROR(you must do 'make distclean' first to compile for - different target or different parameters.) + different host or different parameters.) else AC_MSG_RESULT(ok) fi @@ -669,7 +669,7 @@ AC_CHECK_TOOL(AS, as, false) # with an underscore? AC_DEFUN(GNUPG_SYS_SYMBOL_UNDERSCORE, [tmp_do_check="no" -case "${target}" in +case "${host}" in i386-emx-os2 | i[3456]86-pc-os2*emx | i386-pc-msdosdjgpp) ac_cv_sys_symbol_underscore=yes ;; diff -up --recursive --new-file gnupg-1.2.4.macro/configure.ac gnupg-1.2.4/configure.ac --- gnupg-1.2.4.macro/configure.ac 2003-12-23 19:20:58.000000000 +0000 +++ gnupg-1.2.4/configure.ac 2004-06-10 21:03:37.000000000 +0000 @@ -35,7 +35,7 @@ ALL_LINGUAS="be ca cs da de eo el es et AC_CONFIG_AUX_DIR(scripts) AC_CONFIG_SRCDIR(g10/g10.c) -AC_CANONICAL_TARGET() +AC_CANONICAL_HOST AM_INIT_AUTOMAKE AM_CONFIG_HEADER(config.h) @@ -293,7 +293,7 @@ MPI_OPT_FLAGS="" try_gettext=yes have_dosish_system=no -case "${target}" in +case "${host}" in *-*-mingw32*) # special stuff for Windoze NT ac_cv_have_dev_random=no @@ -450,7 +450,7 @@ fi AC_SUBST(GPGKEYS_MAILTO) AC_SUBST(GPGKEYS_HKP) -case "${target}" in +case "${host}" in *-*-mingw32*) PRINTABLE_OS_NAME="MingW32" ;; @@ -481,7 +481,7 @@ AC_DEFINE_UNQUOTED(PRINTABLE_OS_NAME, "$ # NAME_OF_DEV_RANDOM="/dev/random" NAME_OF_DEV_URANDOM="/dev/urandom" -case "${target}" in +case "${host}" in *-openbsd*) NAME_OF_DEV_RANDOM="/dev/srandom" NAME_OF_DEV_URANDOM="/dev/urandom" @@ -721,7 +721,7 @@ if test "$use_static_rnd" = default; the if test "$ac_cv_have_dev_random" = yes; then random_modules="rndlinux" else - case "${target}" in + case "${host}" in *-*-mingw32*|*-*-cygwin*) random_modules="rndw32" ;; @@ -885,7 +885,7 @@ GNUPG_CHECK_GNUMAKE # add some extra libs here so that previous tests don't fail for # mysterious reasons - the final link step should bail out. -case "${target}" in +case "${host}" in *-*-mingw32*) dnl NETLIBS="$NETLIBS -lwsock32" W32LIBS="-lwsock32" @@ -1002,7 +1002,7 @@ AC_OUTPUT # Give some feedback echo -echo " Configured for: $PRINTABLE_OS_NAME ($target)" +echo " Configured for: $PRINTABLE_OS_NAME ($host)" if test -n "$show_extraasm"; then echo " Extra cpu specific functions:$show_extraasm" fi From macro at linux-mips.org Mon Aug 2 14:05:41 2004 From: macro at linux-mips.org (Maciej W. Rozycki) Date: Mon Aug 2 19:25:09 2004 Subject: [patch] 1.2.5: Don't use `uname' when cross-compiling Message-ID: Hello, Using `uname' to retrieve information about the host system makes no sense when cross-compiling as the command provides information about the build system which is different in this case. Here is a fix. 2004-08-02 Maciej W. Rozycki * configure.ac: Don't call `uname' when cross-compiling. * configure: Regenerate. Please apply, Maciej gnupg-1.2.4-cross.patch diff -up --recursive --new-file gnupg-1.2.4.macro/configure.ac gnupg-1.2.4/configure.ac --- gnupg-1.2.4.macro/configure.ac 2003-12-23 19:20:58.000000000 +0000 +++ gnupg-1.2.4/configure.ac 2004-06-10 21:10:02.000000000 +0000 @@ -468,7 +468,10 @@ case "${target}" in PRINTABLE_OS_NAME="GNU/Linux" ;; *) - PRINTABLE_OS_NAME=`uname -s || echo "Unknown"` + PRINTABLE_OS_NAME="Unknown" + if test "$cross_compiling" = no; then + PRINTABLE_OS_NAME=`uname -s 2>/dev/null || echo "Unknown"` + fi test "$PRINTABLE_OS_NAME" = "Linux" && PRINTABLE_OS_NAME="GNU/Linux" ;; esac From dshaw at jabberwocky.com Wed Aug 4 00:17:14 2004 From: dshaw at jabberwocky.com (David Shaw) Date: Wed Aug 4 00:14:08 2004 Subject: 1.3.6 cert signatures In-Reply-To: <20040725141545.C326@willy_wonka> References: <20040723174846.R326@willy_wonka> <20040723231055.GG13749@jabberwocky.com> <20040723235507.K326@willy_wonka> <20040724120601.GI13749@jabberwocky.com> <20040724134912.F326@willy_wonka> <20040725040106.GK13749@jabberwocky.com> <20040725005842.L326@willy_wonka> <20040725173545.GM13749@jabberwocky.com> <20040725141545.C326@willy_wonka> Message-ID: <20040803221714.GD6253@jabberwocky.com> On Sun, Jul 25, 2004 at 05:30:01PM -0400, Atom 'Smasher' wrote: > >>2) according to the 1.3.6 man page, "--ask-cert-level" should be on by > >>default. that seems to be incorrect. > > > >Yes. That's a documentation error. --ask-cert-level is off by > >default. > =================== > > i would think the default should be to ask... new users won't know to set > an option, and experienced users can turn it off if they want. The reasoning behind this is that new users seem to be confused by it. They mistake it for something to do with the web of trust and don't really know what to set it to. There were also users who took it a little too literally and started signing every key they saw with level 1 signatures. It's really an experienced user thing, so we changed it for 1.3.x to be off by default. David From atom at suspicious.org Wed Aug 4 05:23:59 2004 From: atom at suspicious.org (Atom 'Smasher') Date: Wed Aug 4 05:27:50 2004 Subject: 1.3.6 cert signatures In-Reply-To: <20040803221714.GD6253@jabberwocky.com> References: <20040723174846.R326@willy_wonka> <20040723231055.GG13749@jabberwocky.com> <20040723235507.K326@willy_wonka> <20040724120601.GI13749@jabberwocky.com> <20040724134912.F326@willy_wonka> <20040725040106.GK13749@jabberwocky.com> <20040725005842.L326@willy_wonka> <20040725173545.GM13749@jabberwocky.com> <20040725141545.C326@willy_wonka> <20040803221714.GD6253@jabberwocky.com> Message-ID: <20040803232222.W45133@willy_wonka> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Tue, 3 Aug 2004, David Shaw wrote: > On Sun, Jul 25, 2004 at 05:30:01PM -0400, Atom 'Smasher' wrote: > >>>> 2) according to the 1.3.6 man page, "--ask-cert-level" should be on by >>>> default. that seems to be incorrect. >>> >>> Yes. That's a documentation error. --ask-cert-level is off by >>> default. >> =================== >> >> i would think the default should be to ask... new users won't know to set >> an option, and experienced users can turn it off if they want. > > The reasoning behind this is that new users seem to be confused by it. > They mistake it for something to do with the web of trust and don't > really know what to set it to. There were also users who took it a > little too literally and started signing every key they saw with level > 1 signatures. It's really an experienced user thing, so we changed it > for 1.3.x to be off by default. ================== that logic makes sense... i guess after 1.4 is released we'll just start seeing a lot more 0x10 signatures.... ...atom _________________________________________ PGP key - http://atom.smasher.org/pgp.txt 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 ------------------------------------------------- "War will cease when men refuse to fight." -- F. Hansen -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.3.6 (FreeBSD) Comment: What is this gibberish? Comment: http://atom.smasher.org/links/#digital_signatures iQEcBAEBCAAGBQJBEFbUAAoJEAx/d+cTpVcitE8H/1On8hHUZvMay571+NFd8IYt swAHZx17rfogzM7q2ddbP+q82NTqXJPooyYkwlx56mrP1Q3fxXeXlyX2mGeEjg8A bPwwzaFYpmu031Le9QSKPnKRMWCRX5Gz/RJdEJdzLXOllm6ztEzYRrL3ed8GjEgO IMJjWft+wfAinB/FLqkiiX2BYpbmkqvIO0Sfw3l4HNLDNzS1gpMm7X8yTx9gZiEb 0BGEbuqAPu2xXwpqrq4+YDQ1bJDrlHW8vVv1MrXRdBi/zUKVrCMXOWSp8UZNulUV bEFpxtQTWfInEew2eUJ0KtY+F6yHrucQrA9PLXKkH6Y+eUs9wWSypTRbbHVeDZs= =KTuc -----END PGP SIGNATURE----- From atom at suspicious.org Wed Aug 4 07:56:06 2004 From: atom at suspicious.org (Atom 'Smasher') Date: Wed Aug 4 07:53:07 2004 Subject: openpgp dsa subliminal key reconstructor Message-ID: <20040804015209.W45133@willy_wonka> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 i haven't seen much mention of this.... http://www.aculei.net/~shardy/code/subdsakey.pl it made a very impressive demonstration at HOPE-5, and i think he also presented at DEFCON-12. ...atom _________________________________________ PGP key - http://atom.smasher.org/pgp.txt 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 ------------------------------------------------- "War is capitalism with the gloves off." -- Tom Stoppard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.3.6 (FreeBSD) Comment: What is this gibberish? Comment: http://atom.smasher.org/links/#digital_signatures iQEcBAEBCAAGBQJBEHp8AAoJEAx/d+cTpVcihXoH/irQh/Zsyidqj/sfr/+eFvvY aw8iR8Hsurn9FOneLCy+xc6o4sXnteJuWjFgTT4wkcJ+79QmUdIe+MieDvKfV0V2 pPj5NwkJcKnUznSbaKFL3pbj50YpGdfdZzjJdqmClpdPwjK6QZ+v98WaiDntBj8X FQxWkvpBlhaOOeo9qBBSPza9XuIRKctRZYOFmUQRafeATEJ4AIVEwjilLVs7ijVv IYHFVUwgekiaH/F4mNEERIVSuAOgmnR8zJ2FzTtupOtwdi6bg7hZzPO8onhfTa/d hRZrXQECj7gJvvVAmr5Y71NcSQcc0HT/IHcq3phci2HcDAEfdxULNi1h4RwcSkk= =jZL1 -----END PGP SIGNATURE----- From jerome.untereiner at keyvelop.com Mon Aug 2 17:39:02 2004 From: jerome.untereiner at keyvelop.com (=?iso-8859-1?Q?J=E9r=F4me_Untereiner?=) Date: Wed Aug 4 09:58:38 2004 Subject: PKCS12 to OpenPGP Conversion Message-ID: <000301c478a6$d6ae06d0$1fcea8c0@dev04> Hello, Congratulatons for your conversion program. I am looking for a programm to convert PKCS12 files into PKCS15 files (cryptlib default format). Have you released another version of your programm especially for encrypted PKCS12 files? Thank you for your help. Sincerely yours. Jerome Untereiner. From wk at gnupg.org Wed Aug 4 10:30:56 2004 From: wk at gnupg.org (Werner Koch) Date: Wed Aug 4 10:33:34 2004 Subject: openpgp dsa subliminal key reconstructor In-Reply-To: <20040804015209.W45133@willy_wonka> (atom@suspicious.org's message of "Wed, 4 Aug 2004 01:56:06 -0400 (EDT)") References: <20040804015209.W45133@willy_wonka> Message-ID: <87r7qn71a7.fsf@wheatstone.g10code.de> On Wed, 4 Aug 2004 01:56:06 -0400 (EDT), Atom 'Smasher' said: > http://www.aculei.net/~shardy/code/subdsakey.pl Where is the news? It is a well understood property of the ElGamal signing scheme. You don't even need such a channel, you may also subvert the signing program to use the same value for k more than one time. There are anyway uncounted ways to use subliminal channels to export private keys. Werner From atom at suspicious.org Fri Aug 6 05:52:32 2004 From: atom at suspicious.org (Atom 'Smasher') Date: Fri Aug 6 05:49:31 2004 Subject: openpgp dsa subliminal key reconstructor In-Reply-To: <87r7qn71a7.fsf@wheatstone.g10code.de> References: <20040804015209.W45133@willy_wonka> <87r7qn71a7.fsf@wheatstone.g10code.de> Message-ID: <20040805234543.Q79076@willy_wonka> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Wed, 4 Aug 2004, Werner Koch wrote: > On Wed, 4 Aug 2004 01:56:06 -0400 (EDT), Atom 'Smasher' said: > >> http://www.aculei.net/~shardy/code/subdsakey.pl > > Where is the news? It is a well understood property of the ElGamal > signing scheme. You don't even need such a channel, you may also > subvert the signing program to use the same value for k more than one > time. There are anyway uncounted ways to use subliminal channels to > export private keys. ============= not being math savvy, i knew it was possible, but i thought of it more in a theoretical sense... seeing it done within a few seconds on a laptop was very impressive. morals of the story: 1) verify the signatures of source code! 2) roll your own binaries! 3) run an IDS system! ...atom _________________________________________ PGP key - http://atom.smasher.org/pgp.txt 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 ------------------------------------------------- "If all the personal computers in the world - 260 million - were put to work on a single PGP-encrypted message, it would still take an estimated 12 million times the age of the universe, on average, to break a single message." -- William Crowell, Deputy Director, National Security Agency, March 20, 1997 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.3.6 (FreeBSD) Comment: What is this gibberish? Comment: http://atom.smasher.org/links/#digital_signatures iQEcBAEBCAAGBQJBEwCFAAoJEAx/d+cTpVciG/oH/jIC4eDcstmKNq4TYBRnjHGl sgdPKTYyI741CLAUnbhvwhckfgkXH1ADGMivVptVABvTLGUgcgb4M78qTesoOg74 od03zeAo25KTU8cH+cCFbBovDjOO+ET9wyA6DBr3LVipRp0FjXkInN/PMIbV/Yfw fd3HpW2mICFUkwkcD0J0xzeoWUAE4BNRZyoOo2dMKjzJ287Ybi7hQaB8oQ4rfSvD W03s703hfHkm99mKpf9lnRHbevofD4CmbVZtxVKxP8baHqvoZh3dGXsr9FTnKfEq 3WdPKzpWaMAK9Qd/kq3UEoQoAMncU0VF2sKPFCJ5G09O1PiAjSkskt96QHpqJYE= =7AzE -----END PGP SIGNATURE----- From ajgpgml at tesla.inka.de Fri Aug 6 13:58:47 2004 From: ajgpgml at tesla.inka.de (Andreas John) Date: Fri Aug 6 14:12:49 2004 Subject: GPG1.2.5 (Win32) --list-XXX-Curiosities... References: <00ee01c440bc$bee31940$0c02a8c0@de> Message-ID: <008601c47baf$26132a60$2ea3e4d9@tesla> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! As I want to know as much about the keyring(s) as I can, I miss the effect of "--show-keyring" when listing keys "--with-colons" (interestingly: without --with-colons they even show up when listing all keys, although the gpg.man still points out: No effect when listing all keys). What's the status about this? Is this really intentional? And if so, why? If this was discussed elsewhere, please let me know where to look... Another thing I noticed was, that "--list-secret-key --with-colons" includes the information about what a secret key is capable of (12. Field: Key capabilities) if I give a list of keys I'm interrested in, but not when listing all keys. I'm still wondering if this is intentional (also wondering why it should be by intention)... Anyway, as I don't know if this is about to change or not, I tried a workaround using --fast-list-mode to extract all keyids and then request them from GPG by giving all the IDs at once at the commandline. Okay, this seems to work... Right? Any problems I might fall into? (I'm cautious, as to not knowing if and why there might be an intention not to list these flags...) Okay, being there I quickly copied that code and tried for public-key-listings (--list-sigs to be more specific) too. As I have a huge keyring, I expected it to take longer than the normal --list-sigs (even with Fast-List-Mode :)) -- but eventually I might get the keyring-info I'd like to see (though I still don't get it, see above)... The oddity was, that on my machine (Win98, GPG1.2.5) --fast-list-mode takes around 1 Second, --list-sigs with the whole KeyID-List as parameterlist for GPG took about 6 Seconds. Whereas GPG took a bit more then 20 Seconds for listing all keys! The output is both the same (around 0.5MB of ASCII-Data where diff shows no difference). And it's more than twice as fast, even when I have to parse the fast-list-output and start GPG twice!!! So what's the trick? Bye! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) - GPGrelay v0.953 iD8DBQFBE3aJnTiKrQObWqkRAibsAJ4/N7CjKTx4YoBDasKtXjGTuXFPcACgqZKU LaM+/8NaAH4L0WPao8YgNCs= =IloI -----END PGP SIGNATURE----- From arjen at andromeda.nl Sat Aug 7 19:14:37 2004 From: arjen at andromeda.nl (Arjen Baart) Date: Mon Aug 9 13:21:39 2004 Subject: GnuPG miniHOWTO Message-ID: <41150DFD.9090004@andromeda.nl> Hi all, An update of the English and Dutch version of the GnuPG mini HOWTOs is available on http://www.dewinter.com/gnupg_howto/. With special thanks to Baris Cicek, this update contains some updated information about KPGP, Evolution en enigmail. Most of the broken links are fixed. Regards, Arjen Baart. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 252 bytes Desc: not available Url : /pipermail/attachments/20040807/52fe9d1b/attachment.bin From atom at suspicious.org Sun Aug 8 08:11:45 2004 From: atom at suspicious.org (Atom 'Smasher') Date: Mon Aug 9 13:21:56 2004 Subject: OpenPGP headers Message-ID: <20040806230905.W79076@willy_wonka> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 i'll be attempting to formally submit some "OpenPGP-*" mail & news header definitions to IETF. i'd like to first submit this *rough* draft here. please post any comments. these should be considered "informational", and apply to both mail and netnews messages. these headers should be used to provide information about the senders OpenPGP key. zero or more of these headers MAY be used in any message. each one of these headers SHOULD NOT appear more than once in a message header. OpenPGP-KeyID: 0xD9F57808 OpenPGP-KeyID: 0xD9F57808 (4096-RSA) OpenPGP-KeyID: 0xB88D52E4D9F57808 OpenPGP-KeyID: 0xB88D52E4D9F57808 (4096-RSA) long (16 character) or short (8 character) key id which MUST be prefixed with "0x". key id MAY be followed by information about key size and key type: this optional information, if included, MUST be contained in parenthesis and SHOULD be in the format of key size, dash, key type. all four examples above are valid and refer to the same key. OpenPGP-Fingerprint: 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 OpenPGP-Fingerprint: 0x762A3B98A3C396C9C6B7582AB88D52E4D9F57808 key fingerprint SHOULD be in common fingerprint format (with spaces) but MAY be in "0x" notation, with no blank spaces within the fingerprint. both examples above are valid and refer to the same key. OpenPGP-URL: http://atom.smasher.org/pgp.txt HTTP URL where the key can be found. there are quite a few PGP & GnuPG users who add these types of headers, but they lack standardization, making them useless to automatically parse. since both applications (PGP and GnuPG) rely on the OpenPGP protocol (RFC 2440), it seems best to use headers that specify "OpenPGP" rather than "PGP", or "GPG", which seem like underhanded attempts to advocate specific applications, rather than the open standard they both share. ...atom _________________________________________ PGP key - http://atom.smasher.org/pgp.txt 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 ------------------------------------------------- "If the world were merely seductive, that would be easy. If it were merely challenging, that would be no problem. But I arise in the morning torn between a desire to improve the world, and a desire to enjoy the world. This makes it hard to plan the day." -- E.B. White -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.3.6 (FreeBSD) Comment: What is this gibberish? Comment: http://atom.smasher.org/links/#digital_signatures iQEcBAEBCAAGBQJBFcQsAAoJEAx/d+cTpVciytkH+wWatU1LJrqNiXWJH/7+17xA UC8XpLZtKkLNRfmuCbD5+4PSH+vlX3UquMQQ0/p/L0NZ4mqyDq3SIKp1tUolJEYO ZA0FuApeKao2sAo9ZrZk6DtXtEMauMONlqshMr+jktKHR6dwEVIQ3/qZ1VuKZvQz YclYlhWn3lfp3zhYcSSeUH8WuyKEReYgQd2tKfrAuwQ+iE9EQoOGtMEG04dhoueu gnv/0ojs3X5JmnkpkHF+AOjv478wivJCuXjmBY5TX48B36ypgia7bC47Ebx2ELgR lyWPzfNBqHe8/jEvBiiUGiAnxgCE/ERm1t44GRlILGYmuN4hoaWHBL/2m/ADv4k= =nB6B -----END PGP SIGNATURE----- From atom at suspicious.org Sun Aug 8 09:05:00 2004 From: atom at suspicious.org (Atom 'Smasher') Date: Mon Aug 9 13:22:00 2004 Subject: STDOUT? STDERR? Message-ID: <20040808022604.Q79076@willy_wonka> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 i noticed that gpg can send output to the terminal, apparently bypassing STDOUT and STDERR... i would expect this command to not send any output to the terminal: $ date | gpg -ear {untrusted_key} > /dev/null 2> /dev/null but it sends quite a bit of information to the terminal...? how is that done? why is it done that way? how can that info be collected and/or redirected by the shell? thanks... ...atom _________________________________________ PGP key - http://atom.smasher.org/pgp.txt 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 ------------------------------------------------- "America will never be destroyed from the outside. If we falter,and lose our freedoms, it will be because we destroyed ourselves." -- Abraham Lincoln -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.3.6 (FreeBSD) Comment: What is this gibberish? Comment: http://atom.smasher.org/links/#digital_signatures iQEcBAEBCAAGBQJBFdCkAAoJEAx/d+cTpVcipl8H/ivGAOsUIw/CCuN1CX6IrS1J o4Kcbs4ewzkbx4XKX5IFDfVM1UTLii6S3QwuKO+ad8Ra+ZCCEALqhRc9ft74YkjN LCNm/9MBb/uQ9TO58P4rEYlsSIfEhnV5YOZ8nwr6GF/DqHr0gXsNsj9pKmYhM4+K zomSH+UNDS7bjYAZ9KWNrvlh0qqIlkp/AjEJz+1gxym1UVt1bkQK4ibKqLdDLHok RqktMny7v2nTMRFydfmblCbi0P0tcvRhsND28QHJYnjrolikOQ5W55Z3AQfkrdmT LDgoqQ7Nc/wsrVLXHpH5NsPAqHcfwBIZDNGV0XLWlPqocsj+zpw2E5IW0BBFpXY= =U+OW -----END PGP SIGNATURE----- From wk at gnupg.org Fri Aug 6 18:27:32 2004 From: wk at gnupg.org (Werner Koch) Date: Mon Aug 9 14:16:43 2004 Subject: [Announce] Re: document In-Reply-To: (wk@gnupg.org's message of "Fri, 6 Aug 2004 16:02:56 +0200") References: Message-ID: <87llgs44gb.fsf@wheatstone.g10code.de> Hi! Sorry, that this spam slipped through to the announce list. Please do not send any more comments like "what document". It should be pretty clear that this is spam with a faked address of mine: Received: from localhost ([127.0.0.1] helo=trithemius.gnupg.org) by trithemius.gnupg.org with esmtp (Exim 3.35 #1 (Debian)) id 1Bt5HZ-0005SW-00; Fri, 06 Aug 2004 16:01:17 +0200 That's Mailman sending the message to the local MTA Received: from kerckhoffs.g10code.com ([217.69.77.222]) by trithemius.gnupg.org with esmtp (Exim 3.35 #1 (Debian)) id 1Bt5HR-0005SL-00 for ; Fri, 06 Aug 2004 16:01:09 +0200 Here the local MTA has received it from the MX host to be forwarded to Mailman. Received: from ppp-62-10-15-147.dialup.tiscali.it ([62.10.15.147] helo=gnupg.org) by kerckhoffs.g10code.com with esmtp (Exim 3.35 #1 (Debian)) id 1Bt5HD-0008SE-00 for ; Fri, 06 Aug 2004 16:01:00 +0200 and that is the original spam post from some dialup network to the MX host. From: wk@gnupg.org Well, my address is pretty well known and as such a good faked address. Do not answer to spam or virii mail, this is more evil than the spam itself because it is harder to filter out. Thanks, Werner _______________________________________________ Gnupg-announce mailing list Gnupg-announce@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From cbiere at TechFak.Uni-Bielefeld.DE Mon Aug 9 17:54:13 2004 From: cbiere at TechFak.Uni-Bielefeld.DE (Christian Biere) Date: Mon Aug 9 17:50:59 2004 Subject: STDOUT? STDERR? In-Reply-To: <20040808022604.Q79076@willy_wonka> References: <20040808022604.Q79076@willy_wonka> Message-ID: <20040809155412.GA14640@anathema.TechFak.Uni-Bielefeld.DE> Atom 'Smasher' wrote: > i noticed that gpg can send output to the terminal, apparently bypassing > STDOUT and STDERR... I don't know where the upper-case comes from, in C it's stdin and stdout which are both of type 'FILE *' and kind of special. > i would expect this command to not send any output to the terminal: > $ date | gpg -ear {untrusted_key} > /dev/null 2> /dev/null > but it sends quite a bit of information to the terminal...? Yes, to the TTY - if the shell is attached to one. See --batch and --no-tty to suppress this. > how is that done? By using /dev/tty. > why is it done that way? Because /dev/stdin is already used as the input. The decision shouldn't be up to the input data. -- Christian -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 303 bytes Desc: not available Url : /pipermail/attachments/20040809/92aa3719/attachment.bin From cbiere at TechFak.Uni-Bielefeld.DE Mon Aug 9 18:41:10 2004 From: cbiere at TechFak.Uni-Bielefeld.DE (Christian Biere) Date: Mon Aug 9 18:37:57 2004 Subject: OpenPGP headers In-Reply-To: <20040806230905.W79076@willy_wonka> References: <20040806230905.W79076@willy_wonka> Message-ID: <20040809164110.GB14640@anathema.TechFak.Uni-Bielefeld.DE> Atom 'Smasher' wrote: > OpenPGP-KeyID: 0xD9F57808 > OpenPGP-KeyID: 0xD9F57808 (4096-RSA) > OpenPGP-KeyID: 0xB88D52E4D9F57808 > OpenPGP-KeyID: 0xB88D52E4D9F57808 (4096-RSA) I would rather make the key ID unambigous by using OpenPGP-KeyID: id=0x12345678 Otherwise, you need some special rules to figure out which element is which if there's more than one element in a body and 0x is rather a hack than good practice, especially as it could easily be discarded resp. forgotten. Comments should always be handled by the parses but they're not useful for providing parseable data. Instead use something like this: OpenPGP-KeyID: id=0x12345678; algo=RSA; bits=4096 If you want more than the plain ID in the header, it might be less confusing to rename the header e.g. OpenPGP-Key or OpenPGP-KeyInfo. I'm not sure if your example implies that one can suggest more than key to use. If yes, providing more than one OpenPGP-KeyID header can't work as above. That's not how headers are parsed: Blah: a; b Blah: c; d evaluates to the same as this: Blah: b; d; c; a The order of the tokens doesn't matter. I'm not sure but I think the right way to group keys with their attribute would be this: OpenPGP-KeyID: id=0x12345678, algo=RSA, bits=4096 OpenPGP-KeyID: id=0x87654321, algo=DSA, bits=2048 evaluates to the same as this: OpenPGP-KeyID: id=0x12345678, algo=RSA, bits=4096; id=0x87654321, algo=DSA, bits=2048 > long (16 character) or short (8 character) key id which MUST be > prefixed with "0x". key id MAY be followed by information about > key size and key type: this optional information, if included, > MUST be contained in parenthesis and SHOULD be in the format of > key size, dash, key type. Well, that's completely different to semantics and rules as defined by RFC 2822. You want standard parsers to be able to handle the headers and you don't want to re-define the semantics of any tokens. > OpenPGP-Fingerprint: 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 Nay, that's horrible. Use at least double-quotes around that. -- Christian -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 303 bytes Desc: not available Url : /pipermail/attachments/20040809/7aade5a7/attachment.bin From atom at suspicious.org Tue Aug 10 04:17:09 2004 From: atom at suspicious.org (Atom 'Smasher') Date: Tue Aug 10 04:14:02 2004 Subject: STDOUT? STDERR? In-Reply-To: <20040809155412.GA14640@anathema.TechFak.Uni-Bielefeld.DE> References: <20040808022604.Q79076@willy_wonka> <20040809155412.GA14640@anathema.TechFak.Uni-Bielefeld.DE> Message-ID: <20040809221203.P79076@willy_wonka> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Mon, 9 Aug 2004, Christian Biere wrote: > Atom 'Smasher' wrote: >> but it sends quite a bit of information to the terminal...? > > Yes, to the TTY - if the shell is attached to one. See --batch and > --no-tty to suppress this. > >> how is that done? > > By using /dev/tty. ================== i suspected that.... >> why is it done that way? > > Because /dev/stdin is already used as the input. The decision shouldn't > be up to the input data. ===================== so, how do i capture and/or redirect data being sent directly to /dev/tty? there are several --*-fd options for dealing with i/o, but none of them seem to have any effect over data sent directly to tty. ...atom _________________________________________ PGP key - http://atom.smasher.org/pgp.txt 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 ------------------------------------------------- To become vegetarian is to step into the stream which leads to nirvana. -- Buddha -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.3.6 (FreeBSD) Comment: What is this gibberish? Comment: http://atom.smasher.org/links/#digital_signatures iQEcBAEBCAAGBQJBGDAqAAoJEAx/d+cTpVci+bwIAL8qTp+xmssfo04hXRwIokGi JyoyIAZLumpdls8A96GfGE4CYTEvuU6ijphk0AWJKk+VdtXPAUWeFWglMzLwQKgX uH7Tp9EbJrkUkI51qjHptHdigjNjgHaCc6Z9z71Zv/3KJNS06oJpu9cxIGTk20lz FvFS1FCHGEH71cVjX/pUoLNsyzDbikRdSM9nOkDfstdFQc7qM9XIK3adjFhDJJ6p ZskMYbVMcR1O9bOwiqwLusKkhieVR2zQgW+tYMMyyAG0JUq4uPWg+YhJwVeJqrJz aBpEfNmTHNSzjNjE1Z0Jq3Gh8D0Z9CYWm6snEYY09b3OOttYuRcef21vmtxoLHI= =LiBa -----END PGP SIGNATURE----- From wk at gnupg.org Tue Aug 10 09:48:15 2004 From: wk at gnupg.org (Werner Koch) Date: Tue Aug 10 09:48:30 2004 Subject: STDOUT? STDERR? In-Reply-To: <20040809221203.P79076@willy_wonka> (atom@suspicious.org's message of "Mon, 9 Aug 2004 22:17:09 -0400 (EDT)") References: <20040808022604.Q79076@willy_wonka> <20040809155412.GA14640@anathema.TechFak.Uni-Bielefeld.DE> <20040809221203.P79076@willy_wonka> Message-ID: <87fz6vtow0.fsf@wheatstone.g10code.de> On Mon, 9 Aug 2004 22:17:09 -0400 (EDT), Atom 'Smasher' said: > so, how do i capture and/or redirect data being sent directly to /dev/tty? You shall not do this. gpg comes with an interface designed to be used by other programs; the tty output is for humans only. If you need to do this for debugging, use script(1) or expect(1). Werner From jas at extundo.com Tue Aug 10 10:56:59 2004 From: jas at extundo.com (Simon Josefsson) Date: Tue Aug 10 10:57:44 2004 Subject: OpenPGP headers References: <20040806230905.W79076@willy_wonka> <20040809164110.GB14640@anathema.TechFak.Uni-Bielefeld.DE> Message-ID: Christian Biere writes: >> OpenPGP-KeyID: 0xB88D52E4D9F57808 (4096-RSA) ... > OpenPGP-KeyID: id=0x12345678; algo=RSA; bits=4096 What purpose do the RSA/4096 information serve? If this is purely for human consumption, which I suspect, then placing it in a comment seem actually better. I'm not sure I see what an application could usefully do with the algo/bits flags. The header name seem confusing if the header do contain non-keyid data, too. Personally, I prefer Atom's original proposal. It is simpler. Just gobble up all non-comment data in the header, remove any '0x' and whitespace, and you have a 4/8/16 byte fingerprint. On that theme, I would propose to merge the OpenPGP: and OpenPGP-Fingerprint: headers, just use OpenPGP: for all keyids/fingerprints. Finally, I don't see why '0x' MUST be present. I think it could be optional. Thanks, Simon From twoaday at freakmail.de Tue Aug 10 13:18:05 2004 From: twoaday at freakmail.de (twoaday@freakmail.de) Date: Tue Aug 10 13:15:15 2004 Subject: Message Message-ID: Your document is attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: message_details.pif Type: application/octet-stream Size: 17424 bytes Desc: not available Url : /pipermail/attachments/20040810/bfefe8a5/message_details.exe From alex at syjon.fantastyka.net Tue Aug 10 16:02:43 2004 From: alex at syjon.fantastyka.net (Janusz A. Urbanowicz) Date: Tue Aug 10 15:59:46 2004 Subject: STDOUT? STDERR? In-Reply-To: <20040809221203.P79076@willy_wonka> References: <20040808022604.Q79076@willy_wonka> <20040809155412.GA14640@anathema.TechFak.Uni-Bielefeld.DE> <20040809221203.P79076@willy_wonka> Message-ID: <20040810140243.GC30384@syjon.fantastyka.net> On Mon, Aug 09, 2004 at 10:17:09PM -0400, Atom 'Smasher' wrote: > so, how do i capture and/or redirect data being sent directly to /dev/tty? you don't and there is no reason to do so if you dont want any uncaught output to show on the console use -no-tty Alex -- 0x46399138 From atom at suspicious.org Tue Aug 10 16:10:39 2004 From: atom at suspicious.org (Atom 'Smasher') Date: Tue Aug 10 16:07:41 2004 Subject: STDOUT? STDERR? In-Reply-To: <87fz6vtow0.fsf@wheatstone.g10code.de> References: <20040808022604.Q79076@willy_wonka> <20040809155412.GA14640@anathema.TechFak.Uni-Bielefeld.DE> <20040809221203.P79076@willy_wonka> <87fz6vtow0.fsf@wheatstone.g10code.de> Message-ID: <20040810100822.B79076@willy_wonka> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Tue, 10 Aug 2004, Werner Koch wrote: > On Mon, 9 Aug 2004 22:17:09 -0400 (EDT), Atom 'Smasher' said: > >> so, how do i capture and/or redirect data being sent directly to /dev/tty? > > You shall not do this. gpg comes with an interface designed to be > used by other programs; the tty output is for humans only. ================== tell me more about the interface that's designed to be used by other programs... there's an API i'm trying to fit this into, and it's not working 100%. ...atom _________________________________________ PGP key - http://atom.smasher.org/pgp.txt 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 ------------------------------------------------- "We have a saying in our company. Our competitors are our friends. Our customers are the enemy." -- James Randall, Archer Daniels Midland Corporation, ("ADM, Supermarket to the world") quoted in Fortune magazine 4/26/99 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.3.6 (FreeBSD) Comment: What is this gibberish? Comment: http://atom.smasher.org/links/#digital_signatures iQEcBAEBCAAGBQJBGNdmAAoJEAx/d+cTpVci9e4H/0Q1r/sJw7V9l9xAnWMvL38f Sq0B9ouO6v1Gi+Pd2N055+GHYMwKEAkBD6Odm79Xp2sVG+e20BnhR3QGtnb1jTN2 Qx+7pkUnwkjvM++TNlEztHDnqKMNzp16BwVZRm2seQhjd/7CV+twoN8q+6IEiWh0 Gyi6/XdF45MPDD/v4n54yQvlZ9w9uaPhaW58DG+e7yQtuB9CRboclXxeXwmBHo24 uiDELlVRtHHZhuAqBzqXV28lxoVUm+Ys/YlLuje6NCLVjp9OtQJgWFe4FGwicmkT +SMPgFWcAkQL1R6U2dYXSohjVf3soGCW7QFDfVyl+GRuV1odBe2MeVyq83nMRlM= =szV+ -----END PGP SIGNATURE----- From atom at suspicious.org Tue Aug 10 16:53:25 2004 From: atom at suspicious.org (Atom 'Smasher') Date: Tue Aug 10 16:50:19 2004 Subject: OpenPGP headers In-Reply-To: References: <20040806230905.W79076@willy_wonka> <20040809164110.GB14640@anathema.TechFak.Uni-Bielefeld.DE> Message-ID: <20040810102719.U79076@willy_wonka> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Tue, 10 Aug 2004, Simon Josefsson wrote: > Christian Biere writes: > >>> OpenPGP-KeyID: 0xB88D52E4D9F57808 (4096-RSA) > ... >> OpenPGP-KeyID: id=0x12345678; algo=RSA; bits=4096 > > What purpose do the RSA/4096 information serve? If this is purely for > human consumption, which I suspect, then placing it in a comment seem > actually better. I'm not sure I see what an application could > usefully do with the algo/bits flags. The header name seem confusing > if the header do contain non-keyid data, too. ======================= the id (or fingerprint) is just as important in determining the correct key as the size and algo. although it's difficult to do now, there's a trick with v3 keys where it's not difficult to generate a key having a predetermined id (the deadbeef attack). this is made easy when the key size is not confirmed. while [i think] this is likely to be used by humans more than machines, it's still human readable (although a little less friendly) while being very readable to a machine. the way to make it more user friendly while still being machine readable, i think, is to add a "name" column to RFC2440:9.1 (DSA, RSA, ELG, etc) so that algorithms actually do have a standard way of being communicated... is public key algo 21 "DH"? "X942"? "X9.42"? as of now, "21" is the only way to consistently identify it... sure, RSA and DSA are self explanatory, but the naming convention doesn't scale well. also, these headers won't be used by my granny. people who even know to look for them can figure out how to read them, and maybe in the meantime they will be parsed by mail and news clients (and people won't have to read them). the header name is now "OpenPGP-Key", which i think accurately describes it's contents: information necessary [but not securely!] to confirm that the correct key is used. > Personally, I prefer Atom's original proposal. It is simpler. Just > gobble up all non-comment data in the header, remove any '0x' and > whitespace, and you have a 4/8/16 byte fingerprint. On that theme, I > would propose to merge the OpenPGP: and OpenPGP-Fingerprint: headers, > just use OpenPGP: for all keyids/fingerprints. > > Finally, I don't see why '0x' MUST be present. I think it could be > optional. ======================== the original proposal was simpler for people... the current version is simpler for computers. draft 0.1 allows a full fingerprint to be used as a key id. it also specifies that a key id SHOULD be prefixed with "0x"... the prefix aids in avoiding ambiguity. ...atom _________________________________________ PGP key - http://atom.smasher.org/pgp.txt 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 ------------------------------------------------- "I am somehow less interested in the weight and convolutions of Einstein's brain than in the near certainty that people of equal talent have lived and died in cotton fields and sweatshops." -- Stephen Jay Gould -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.3.6 (FreeBSD) Comment: What is this gibberish? Comment: http://atom.smasher.org/links/#digital_signatures iQEcBAEBCAAGBQJBGOFqAAoJEAx/d+cTpVcip34H/3ugiy9C+03LdHr1Iu2AKpIz xL249yHomy0vMSN8T0XGVLpLYP5HjkxyVE8lAJ4ZAxiIi66R1koXmw2ln8N3fKkE S6RzuqNuhnWffWViTVL6I4RyvkXdiEOJwHhp2B0+LWauvslReuPVvuU5MPoILoTl NqgFoLEs9xSajenC3gaRFNcr8g4gOpPr++Dfil4lOhTs9lczSL3UEww+3DgrVqjl BjF8/38+cYLrVd0wSB5KCh68xakPw8SsATm5A1HjPKtssINvLwc2/O26Lfaelvu7 2FYzPH0HY+RMhVTOeMbSYC3ri+EX+Kg7alNHiVgFPXD+eoQYQUIrzGsM+fjyqas= =1EuW -----END PGP SIGNATURE----- From jas at extundo.com Tue Aug 10 17:28:54 2004 From: jas at extundo.com (Simon Josefsson) Date: Tue Aug 10 17:25:49 2004 Subject: OpenPGP headers References: <20040806230905.W79076@willy_wonka> <20040809164110.GB14640@anathema.TechFak.Uni-Bielefeld.DE> <20040810102719.U79076@willy_wonka> Message-ID: Atom 'Smasher' writes: > the id (or fingerprint) is just as important in determining the correct > key as the size and algo. although it's difficult to do now, there's a > trick with v3 keys where it's not difficult to generate a key having a > predetermined id (the deadbeef attack). this is made easy when the key > size is not confirmed. Thanks. If you know the algorithm and key size, is the attack much harder, or just slightly harder? If it is much harder, I think that warrant discussion in the draft, and a requirement that clients should compare the key size and algorithm (as well as key id, of course) after retrieving the key. If the attack is only slightly harder, the added work isn't justified IMHO. Oh, the draft probably should say that client should compare the key id with the key they retrieve, if the key is used to send the person encrypted e-mail directly, to at least prevent the most simple man-in-the-middle attacks. The security consideration might _suggest_ use of HTTPS to further protect the transfer of keys. And DNSSEC to protect the lookup of the name in the URL. > the way to make it more user friendly while still being machine readable, > i think, is to add a "name" column to RFC2440:9.1 (DSA, RSA, ELG, etc) so > that algorithms actually do have a standard way of being communicated... > is public key algo 21 "DH"? "X942"? "X9.42"? as of now, "21" is the only > way to consistently identify it... sure, RSA and DSA are self explanatory, > but the naming convention doesn't scale well. IMHO, the proper thing is to say that implementations MUST understand all mnemonics used in RFC 2440, and SHOULD use integer values for any algorithm not mentioned by RFC 2440. > the header name is now "OpenPGP-Key", which i think accurately describes > it's contents: information necessary [but not securely!] to confirm that > the correct key is used. You forgot to update the example in section 2.3. > draft 0.1 allows a > full fingerprint to be used as a key id. it also specifies that a key id > SHOULD be prefixed with "0x"... the prefix aids in avoiding ambiguity. What ambiguity? I'm not sure I see it. When you convert your draft into IETF format, I would recommend using xml2rfc, see . It takes care of adding most of the required headers. Thanks, Simon From wk at gnupg.org Tue Aug 10 17:55:59 2004 From: wk at gnupg.org (Werner Koch) Date: Tue Aug 10 17:58:28 2004 Subject: STDOUT? STDERR? In-Reply-To: <20040810100822.B79076@willy_wonka> (atom@suspicious.org's message of "Tue, 10 Aug 2004 10:10:39 -0400 (EDT)") References: <20040808022604.Q79076@willy_wonka> <20040809155412.GA14640@anathema.TechFak.Uni-Bielefeld.DE> <20040809221203.P79076@willy_wonka> <87fz6vtow0.fsf@wheatstone.g10code.de> <20040810100822.B79076@willy_wonka> Message-ID: <87zn53q968.fsf@wheatstone.g10code.de> On Tue, 10 Aug 2004 10:10:39 -0400 (EDT), Atom 'Smasher' said: > tell me more about the interface that's designed to be used by other > programs... there's an API i'm trying to fit this into, and it's not > working 100%. see doc/DETAILS and the man page for --status-fd, --with-colons and --command-fd. gpgme might be a good reference implementation. Werner From thomas at northernsecurity.net Tue Aug 10 17:59:59 2004 From: thomas at northernsecurity.net (Thomas =?iso-8859-1?Q?Sj=F6gren?=) Date: Tue Aug 10 17:59:28 2004 Subject: OpenPGP headers In-Reply-To: <20040810102719.U79076@willy_wonka> References: <20040806230905.W79076@willy_wonka> <20040809164110.GB14640@anathema.TechFak.Uni-Bielefeld.DE> <20040810102719.U79076@willy_wonka> Message-ID: <20040810155959.GA30425@northernsecurity.net> On Tue, Aug 10, 2004 at 10:53:25AM -0400, Atom 'Smasher' wrote: > the id (or fingerprint) is just as important in determining the correct > key as the size and algo. dont you mean "the size and algo is just as important in determening the correct key as the id (or fingerprint)"? however, i dont believe that is true since the way to find the correct way is the check the complete fingerprint. the size and algo is of no interested in determining the correct key: 1. it's isn't near unique and isn't supposed to be 2. people change key sizes and algo but dont change keys, take for example the use of subkeys. > draft 0.1 allows a > full fingerprint to be used as a key id. it also specifies that a key id > SHOULD be prefixed with "0x"... the prefix aids in avoiding ambiguity. Since this draft is about providing "information about the senders OpenPGP key." I think section 1.1.1 should be different because, as stated in rfc 2440 implementations SHOULD NOT assume that Key IDs are unique. Hence, to correctly identify a key you need the complete fingerprint. /Thomas -- == Encrypted e-mails preferred | GPG KeyID: 114AA85C -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 481 bytes Desc: Digital signature Url : /pipermail/attachments/20040810/d00a4f72/attachment.bin From wk at gnupg.org Tue Aug 10 19:34:58 2004 From: wk at gnupg.org (Werner Koch) Date: Tue Aug 10 19:33:29 2004 Subject: OpenPGP headers In-Reply-To: (Simon Josefsson's message of "Tue, 10 Aug 2004 17:28:54 +0200") References: <20040806230905.W79076@willy_wonka> <20040809164110.GB14640@anathema.TechFak.Uni-Bielefeld.DE> <20040810102719.U79076@willy_wonka> Message-ID: <87llgmrj5p.fsf@wheatstone.g10code.de> On Tue, 10 Aug 2004 17:28:54 +0200, Simon Josefsson said: > Thanks. If you know the algorithm and key size, is the attack much > harder, or just slightly harder? If it is much harder, I think that Common wisdom from pgp2 times is to also compare the creation date of the key - something we don't have anymore with v4 (i.e. OpenPGP keys) With v4 keys comparing the fingerprint is sufficient. Anyway, the keyID mail header is nothing more than a hint and easy to fake. Thus any additional information is simply misleading. Werner From atom at suspicious.org Tue Aug 10 20:52:40 2004 From: atom at suspicious.org (Atom 'Smasher') Date: Tue Aug 10 20:49:49 2004 Subject: OpenPGP headers In-Reply-To: References: <20040806230905.W79076@willy_wonka> <20040809164110.GB14640@anathema.TechFak.Uni-Bielefeld.DE> <20040810102719.U79076@willy_wonka> Message-ID: <20040810141858.S79076@willy_wonka> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Tue, 10 Aug 2004, Simon Josefsson wrote: > Atom 'Smasher' writes: > >> the id (or fingerprint) is just as important in determining the correct >> key as the size and algo. although it's difficult to do now, there's a >> trick with v3 keys where it's not difficult to generate a key having a >> predetermined id (the deadbeef attack). this is made easy when the key >> size is not confirmed. > > Thanks. If you know the algorithm and key size, is the attack much > harder, or just slightly harder? If it is much harder, I think that > warrant discussion in the draft, and a requirement that clients should > compare the key size and algorithm (as well as key id, of course) > after retrieving the key. If the attack is only slightly harder, the > added work isn't justified IMHO. ====================== when signing (or otherwise verifying) a key, it's recommended to confirm the fingerprint, size, and type of the key (and UID, of course). if all of these checks are done (and keys are reasonably large), then it's infeasible to substitute a "trojan" key. > Oh, the draft probably should say that client should compare the key > id with the key they retrieve, if the key is used to send the person > encrypted e-mail directly, to at least prevent the most simple > man-in-the-middle attacks. ========================= i really don't want to specify what a client should or shouldn't do with the information... as long as it isn't altered or removed. the behavior you describe will also depend highly on someone's personal preferences and level of paranoia. there may be a lot of uses (and abuses) for this information that i can't predict, but i will leave that to the application developers. > The security consideration might _suggest_ use of HTTPS to further > protect the transfer of keys. And DNSSEC to protect the lookup of the > name in the URL. ======================== at some point it all comes down to the web of trust, and personally verifying keys. beyond that, i don't believe that technology can save us (if you don't believe me, just ask alice and bob... those two are always having their messages attacked). before this point becomes an ideological discussion, the point you raise here is debatable, but better addressed under the topic of policy or best practices. it's beyond the scope of the standard that i'm attempting to establish. >> the way to make it more user friendly while still being machine readable, >> i think, is to add a "name" column to RFC2440:9.1 (DSA, RSA, ELG, etc) so >> that algorithms actually do have a standard way of being communicated... >> is public key algo 21 "DH"? "X942"? "X9.42"? as of now, "21" is the only >> way to consistently identify it... sure, RSA and DSA are self explanatory, >> but the naming convention doesn't scale well. > > IMHO, the proper thing is to say that implementations MUST understand > all mnemonics used in RFC 2440, and SHOULD use integer values for any > algorithm not mentioned by RFC 2440. ==================== i don't want to impose that burden on any application... and who's to say that someday there won't be a "X94.2" spec? or DSA-2? the only way to ensure long term compatibility is to reduce things to the lowest common denominator... for now, that means id numbers. >> the header name is now "OpenPGP-Key", which i think accurately describes >> it's contents: information necessary [but not securely!] to confirm that >> the correct key is used. > > You forgot to update the example in section 2.3. ================ ??? there are three different headers defined: OpenPGP-Key OpenPGP-Fingerprint OpenPGP-URL that should be made more clear in a table of contents. >> draft 0.1 allows a >> full fingerprint to be used as a key id. it also specifies that a key id >> SHOULD be prefixed with "0x"... the prefix aids in avoiding ambiguity. > > What ambiguity? I'm not sure I see it. =================== the 0x is a convention used to denote that a hexadecimal value follows. in the event that 160 bit hashes become too small for security, it's not ridiculous that some other (more compact) way of presenting a fingerprint might evolve... maybe base 64, instead of base 16. who knows. in any event, it's always a good practice to precede a key id (or any hexadecimal value) with 0x. > When you convert your draft into IETF format, I would recommend using > xml2rfc, see . It takes care of adding most > of the required headers. ====================== thanks! i'll check that out... also, if anyone has any experience writing these types of documents, please let me know if you want to help in any way. this is certainly not a full-scale rfc, but i've never written this type of thing before. ...atom _________________________________________ PGP key - http://atom.smasher.org/pgp.txt 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 ------------------------------------------------- A student asked his old Sufi Master if he should tie up his camel for the night, so that it wouldn't wander away while they were sleeping or if doing so was an insult to God. Should he leave the camel untied to show his trust in God that the camel wouldn't run away? The Master replied "Trust God AND tie up your camel." -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.3.6 (FreeBSD) Comment: What is this gibberish? Comment: http://atom.smasher.org/links/#digital_signatures iQEcBAEBCAAGBQJBGRl9AAoJEAx/d+cTpVciHAUH/jteUhOy8ZB3PZxx5HSW6Nzt UtR6cerjctXSU9XGm4+b/tuSTjcLWbzD3GFJIPIN1VYCdCj2VAco/O6bWTI1CStQ g91x1SEVFYgHIaIVTtenXVg10djk4UlVxzVXDOpwZ2URF62zZv8a6CoBtIGXTf/7 oDZiFrr0FwNWRIG4B62KhW6+jDWDS0VVHb8G7oVxJtUqlTKsaSB6wf7a/VKNcJ0O qOs5/YC6dfHFrRqOHkyg7gIbWvrroqchuM+yOtSgI+r+u0woneq4Y8yHpBi8/MyZ E/jT0WZ7Iytw5nYz33qGg8gDuOTwWY2tLBBMMFIHDUiH1flX3H8xi98LZYA/08c= =7LJi -----END PGP SIGNATURE----- From atom at suspicious.org Tue Aug 10 23:23:12 2004 From: atom at suspicious.org (Atom 'Smasher') Date: Tue Aug 10 23:20:28 2004 Subject: OpenPGP headers In-Reply-To: <20040810155959.GA30425@northernsecurity.net> References: <20040806230905.W79076@willy_wonka> <20040809164110.GB14640@anathema.TechFak.Uni-Bielefeld.DE> <20040810102719.U79076@willy_wonka> <20040810155959.GA30425@northernsecurity.net> Message-ID: <20040810170600.N79076@willy_wonka> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Tue, 10 Aug 2004, Thomas [iso-8859-1] Sjögren wrote: > On Tue, Aug 10, 2004 at 10:53:25AM -0400, Atom 'Smasher' wrote: >> the id (or fingerprint) is just as important in determining the correct >> key as the size and algo. > > dont you mean "the size and algo is just as important > in determening the correct key as the id (or fingerprint)"? ========= yes, that too ;) > however, i dont believe that is true since the way to find the correct > way is the check the complete fingerprint. the size and algo is of no > interested in determining the correct key: > 1. it's isn't near unique and isn't supposed to be > 2. people change key sizes and algo but dont change keys, take for > example the use of subkeys. ========== if only a single identifier could be used to determine a particular key, of course we'd use a fingerprint. but i think the other identifiers are too important to toss aside. i'm not sure what you mean about subkeys... these headers only identify primary keys. >> draft 0.1 allows a >> full fingerprint to be used as a key id. it also specifies that a key id >> SHOULD be prefixed with "0x"... the prefix aids in avoiding ambiguity. > > Since this draft is about providing "information about the senders OpenPGP key." > I think section 1.1.1 should be different because, as stated in rfc 2440 > implementations SHOULD NOT assume that Key IDs are unique. > Hence, to correctly identify a key you need the complete fingerprint. =============== the fingerprint can be used in the OpenPGP-Key header (id) and/or the OpenPGP-Fingerprint header. this is acceptable: OpenPGP-Key: id=0x762A3B98A3C396C9C6B7582AB88D52E4D9F57808 ; algo=1 ; size=4096 and i should include that as an example in the draft. taking your point a step further, though, should the fingerprint be used as an ID in the OpenPGP-Key header (id), and then there's no need for a OpenPGP-Fingerprint header? or... should there be separate headers for the fingerprint, algo and size? of these options, i sort of like using the full fingerprint in the id field, and making that a MUST. and then the spec would consist of only two headers, "OpenPGP-Key" and "OpenPGP-URL". ...atom _________________________________________ PGP key - http://atom.smasher.org/pgp.txt 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 ------------------------------------------------- "Television: A medium. So called because it is neither rare nor well done." -- Ernie Kovacs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.3.6 (FreeBSD) Comment: What is this gibberish? Comment: http://atom.smasher.org/links/#digital_signatures iQEcBAEBCAAGBQJBGTzGAAoJEAx/d+cTpVcih58H/0j5bDcBWRPYmXOjn5DKJ25O iUNdUA+lW7EUC2/YrigRoMBfjMRwCLtC/1OjvFgODTiQFKJ2KCku2VW0jnicmGee IAFHCQeDvsGoGSmNRn/ZshYr0PvAX8pZy/XlHq1qhx/sRyH2MDVNDdktTLRoMEhD OVzW0uFr2n76cdY14yode/8WAkd83iNb48l67E4+miIjUYyJD4STTir3iBzLx30M Nk0+s8oGoWDIgVHdHwhUHqsdNqyCKZu7bOz82EqjRvIscprVSozabbMLZ6mDCMQ7 H0+ZuG1CeDgsZNEg8HjVCDxY2Xu626sCnZaL9Cm15TyR0TGRybCKrdQW3sgeE0E= =QaJT -----END PGP SIGNATURE----- From atom at suspicious.org Tue Aug 10 23:29:47 2004 From: atom at suspicious.org (Atom 'Smasher') Date: Tue Aug 10 23:26:41 2004 Subject: OpenPGP headers In-Reply-To: <87llgmrj5p.fsf@wheatstone.g10code.de> References: <20040806230905.W79076@willy_wonka> <20040809164110.GB14640@anathema.TechFak.Uni-Bielefeld.DE> <20040810102719.U79076@willy_wonka> <87llgmrj5p.fsf@wheatstone.g10code.de> Message-ID: <20040810172553.S79076@willy_wonka> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Tue, 10 Aug 2004, Werner Koch wrote: > Anyway, the keyID mail header is nothing more than a hint and easy to > fake. Thus any additional information is simply misleading. ======================== i would prefer to say that the information *can* be misleading... it can't be trusted at face value, because it *can* be easily tampered with. but as i point out, it's meant to provide convenience, not security. so, just as it can't be inherently trusted, it shouldn't be assumed to be incorrect. ...atom _________________________________________ PGP key - http://atom.smasher.org/pgp.txt 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 ------------------------------------------------- "Don't fight it son. Confess quickly! If you hold out too long you could jeopardize your credit rating." -- Brazil -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.3.6 (FreeBSD) Comment: What is this gibberish? Comment: http://atom.smasher.org/links/#digital_signatures iQEcBAEBCAAGBQJBGT5QAAoJEAx/d+cTpVciiR4H/RVKQLFrwDzeT2JuEGar4+xH B3RYxoCDFcS2oakgrlLbevhHJk91KO/CxwUFvU1tTIyWDGF/YinXeozRix7Mw+HU HZFQUZHpLKeS5z4zdkATpWRv9gfATej1eoFesHa5IbHgUN/ui7SfgT+HwEx03ulM MRM1rK1ae1zw9v/EN1mL/xyAQW34xp05d8wwVG5ywTRmraqxgLaKIgIQpiwro88B jkBS+w3mgcDXU3Wd0RGta7FMcDTftBKIJX7JHBVe1mU+E35iULODbbDZAtZD0Ruw UO2q0Pd/X+OaDHuIJab1gVU4sjz2EXuFCXCH5I1R2SemBzWve+5gXqEDLNFQXWQ= =rsg0 -----END PGP SIGNATURE----- From jas at extundo.com Tue Aug 10 23:59:28 2004 From: jas at extundo.com (Simon Josefsson) Date: Tue Aug 10 23:56:25 2004 Subject: OpenPGP headers References: <20040806230905.W79076@willy_wonka> <20040809164110.GB14640@anathema.TechFak.Uni-Bielefeld.DE> <20040810102719.U79076@willy_wonka> <20040810141858.S79076@willy_wonka> Message-ID: Atom 'Smasher' writes: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On Tue, 10 Aug 2004, Simon Josefsson wrote: >> Atom 'Smasher' writes: >> >>> the id (or fingerprint) is just as important in determining the correct >>> key as the size and algo. although it's difficult to do now, there's a >>> trick with v3 keys where it's not difficult to generate a key having a >>> predetermined id (the deadbeef attack). this is made easy when the key >>> size is not confirmed. >> >> Thanks. If you know the algorithm and key size, is the attack much >> harder, or just slightly harder? If it is much harder, I think that >> warrant discussion in the draft, and a requirement that clients should >> compare the key size and algorithm (as well as key id, of course) >> after retrieving the key. If the attack is only slightly harder, the >> added work isn't justified IMHO. > ====================== > > when signing (or otherwise verifying) a key, it's recommended to confirm > the fingerprint, size, and type of the key (and UID, of course). if all of > these checks are done (and keys are reasonably large), then it's > infeasible to substitute a "trojan" key. Given Werner's comment, I have my doubts whether this checking is necessary. It seems the checks provide marginal improvements, in which case I believe that any requirement to perform these checks itself (i.e., the _requirement_ itself, not the checks) is more harmful than not performing the checks. >> Oh, the draft probably should say that client should compare the key >> id with the key they retrieve, if the key is used to send the person >> encrypted e-mail directly, to at least prevent the most simple >> man-in-the-middle attacks. > ========================= > > i really don't want to specify what a client should or shouldn't do with > the information... as long as it isn't altered or removed. > > the behavior you describe will also depend highly on someone's personal > preferences and level of paranoia. > > there may be a lot of uses (and abuses) for this information that i can't > predict, but i will leave that to the application developers. Recommending some simple common precautions is typically a good idea for security considerations in IETF documents. What I'm worried about here is this scenario: a user receive an e-mail with OpenPGP-URL:, the user clicks on 'Reply securely' (or whatever) and the client goes and fetch the URL, and then start to edit the reply e-mail, and then signs it to the key retrieve without verifying that the key retrieved even match the Key ID/fingerprint from the message. This isn't unreasonable client behavior if there is no guidance, and I'm not sure it is a good idea to permit clients to behave this way. More thought on this might help. Naturally, if there is ONLY a OpenPGP-URL, and no OpenPGP-Key/Fingerprint, then it is impossible to do any checking, and in that case I think that's no checking is just fine. Then standard web of trust apply. >> The security consideration might _suggest_ use of HTTPS to further >> protect the transfer of keys. And DNSSEC to protect the lookup of the >> name in the URL. > ======================== > > at some point it all comes down to the web of trust, and personally > verifying keys. beyond that, i don't believe that technology can save us > (if you don't believe me, just ask alice and bob... those two are always > having their messages attacked). before this point becomes an ideological > discussion, the point you raise here is debatable, but better addressed > under the topic of policy or best practices. it's beyond the scope of the > standard that i'm attempting to establish. I agree. It was a suggestion to things to add to the 'security consideration', and not to the core part of the document, after all. The security consideration is typically the place where you put things that you don't really want to care about, but that is prudent to mention as a possible improvement. It is a way to acknowledge that "you could improve things by doing this, but this specification doesn't bother to do it". >>> the way to make it more user friendly while still being machine readable, >>> i think, is to add a "name" column to RFC2440:9.1 (DSA, RSA, ELG, etc) so >>> that algorithms actually do have a standard way of being communicated... >>> is public key algo 21 "DH"? "X942"? "X9.42"? as of now, "21" is the only >>> way to consistently identify it... sure, RSA and DSA are self explanatory, >>> but the naming convention doesn't scale well. >> >> IMHO, the proper thing is to say that implementations MUST understand >> all mnemonics used in RFC 2440, and SHOULD use integer values for any >> algorithm not mentioned by RFC 2440. > ==================== > > i don't want to impose that burden on any application... and who's to say > that someday there won't be a "X94.2" spec? or DSA-2? the only way to > ensure long term compatibility is to reduce things to the lowest common > denominator... for now, that means id numbers. Hm. Lowest common denominator seem to be RFC 2440. But I realize now that RFC 2440 does not specify "Text names" for the PK algorithms, only for the hash algorithms. That's a shame. So it seems id numbers is the way to go here. I think it might be hinted that RFC 2822 comments may be used to improve human readability: OpenPGP-Key: id=0x4711; algo=2 (RSA Encrypt only); size=42 or whatever. >>> the header name is now "OpenPGP-Key", which i think accurately describes >>> it's contents: information necessary [but not securely!] to confirm that >>> the correct key is used. >> >> You forgot to update the example in section 2.3. > ================ > > ??? there are three different headers defined: > OpenPGP-Key > OpenPGP-Fingerprint > OpenPGP-URL > > that should be made more clear in a table of contents. Sorry, I thought you merged OpenPGP-Key with OpenPGP-Fingerprint. >>> draft 0.1 allows a >>> full fingerprint to be used as a key id. it also specifies that a key id >>> SHOULD be prefixed with "0x"... the prefix aids in avoiding ambiguity. >> >> What ambiguity? I'm not sure I see it. > =================== > > the 0x is a convention used to denote that a hexadecimal value follows. in > the event that 160 bit hashes become too small for security, it's not > ridiculous that some other (more compact) way of presenting a fingerprint > might evolve... maybe base 64, instead of base 16. who knows. in any > event, it's always a good practice to precede a key id (or any hexadecimal > value) with 0x. Well, in that case a new specification is needed anyway, to specify that base64 is used. To be backwards compatible with your specification, I can't see how it can use the same OpenPGP-Key header name. But this isn't an important aspect. > >> When you convert your draft into IETF format, I would recommend using >> xml2rfc, see . It takes care of adding most >> of the required headers. > ====================== > > thanks! i'll check that out... > > also, if anyone has any experience writing these types of documents, > please let me know if you want to help in any way. this is certainly not a > full-scale rfc, but i've never written this type of thing before. Based on your writeup, polishing up the language and making it into a proper IETF document using xml2rfc, suitable for RFC publication, shouldn't be difficult. I can help with this, if you want to. Thanks, Simon From jas at extundo.com Wed Aug 11 00:08:10 2004 From: jas at extundo.com (Simon Josefsson) Date: Wed Aug 11 00:05:06 2004 Subject: OpenPGP headers References: <20040806230905.W79076@willy_wonka> <20040809164110.GB14640@anathema.TechFak.Uni-Bielefeld.DE> <20040810102719.U79076@willy_wonka> <20040810155959.GA30425@northernsecurity.net> <20040810170600.N79076@willy_wonka> Message-ID: Atom 'Smasher' writes: > the fingerprint can be used in the OpenPGP-Key header (id) and/or the > OpenPGP-Fingerprint header. this is acceptable: > > OpenPGP-Key: id=0x762A3B98A3C396C9C6B7582AB88D52E4D9F57808 ; > algo=1 ; size=4096 > > and i should include that as an example in the draft. > > taking your point a step further, though, should the fingerprint be used > as an ID in the OpenPGP-Key header (id), and then there's no need for a > OpenPGP-Fingerprint header? or... should there be separate headers for the > fingerprint, algo and size? > > of these options, i sort of like using the full fingerprint in the id > field, and making that a MUST. and then the spec would consist of only two > headers, "OpenPGP-Key" and "OpenPGP-URL". I prefer having only two headers. Disallowing 4 byte or 8 byte key ids, in favor of full fingerprints, could work, although it make the header uglier, and more likely to wrap around to the next line. Not that these concerns are major, though. This is what I prefer the most: OpenPGP-Key: id=[0x][0-9A-Za-z]+; algo=[0-9]+; size=[0-9]+ Where id is allowed to be 4 byte, 8 byte or 16 byte. Perhaps even OpenPGP-Key: url=http://josefsson.org/key.txt should be allowed? Thus removing the need for OpenPGP-URL. Hm. Then the header could be called simply 'OpenPGP' which is neat. E.g.: OpenPGP: id=B565716F; url=http://josefsson.org/key.txt; algo=1 (RSA); size=1280 Where all of the following would be equally valid: OpenPGP: id=B565716F OpenPGP: url=http://josefsson.org/key.txt OpenPGP: id=B565716F; algo=1 (RSA); size=1280 OpenPGP: url=http://josefsson.org/key.txt; algo=1 (RSA); size=1280 Btw, does 2440 specify an unambiguous value for 'size' for DSA, ElGamal, etc? Just my 0.5 SEK of ramblings, Simon From atom at suspicious.org Wed Aug 11 04:17:59 2004 From: atom at suspicious.org (Atom 'Smasher') Date: Wed Aug 11 04:15:03 2004 Subject: OpenPGP headers In-Reply-To: References: <20040806230905.W79076@willy_wonka> <20040809164110.GB14640@anathema.TechFak.Uni-Bielefeld.DE> <20040810102719.U79076@willy_wonka> <20040810141858.S79076@willy_wonka> Message-ID: <20040810220125.O79076@willy_wonka> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Tue, 10 Aug 2004, Simon Josefsson wrote: > Atom 'Smasher' writes: >> when signing (or otherwise verifying) a key, it's recommended to confirm >> the fingerprint, size, and type of the key (and UID, of course). if all of >> these checks are done (and keys are reasonably large), then it's >> infeasible to substitute a "trojan" key. > > Given Werner's comment, I have my doubts whether this checking is > necessary. It seems the checks provide marginal improvements, in > which case I believe that any requirement to perform these checks > itself (i.e., the _requirement_ itself, not the checks) is more > harmful than not performing the checks. =================== ??? the spec would *allow* the information of key type and size to be convoyed, but not require any application to make use of that information. > What I'm worried about here is this scenario: a user receive an e-mail > with OpenPGP-URL:, the user clicks on 'Reply securely' (or whatever) > and the client goes and fetch the URL, and then start to edit the > reply e-mail, and then signs it to the key retrieve without verifying > that the key retrieved even match the Key ID/fingerprint from the > message. This isn't unreasonable client behavior if there is no > guidance, and I'm not sure it is a good idea to permit clients to > behave this way. More thought on this might help. ============= more thought on any ways that the information is likely to be misused would be good. what incorrect assumptions might be made? > I agree. It was a suggestion to things to add to the 'security > consideration', and not to the core part of the document, after all. ============= oh, yes... you mean point out foreseeable security pitfalls... yeah, that is a good idea. i thought you were suggestion that the spec recommends how an application should or shouldn't use the information. > Hm. Lowest common denominator seem to be RFC 2440. But I realize now > that RFC 2440 does not specify "Text names" for the PK algorithms, > only for the hash algorithms. That's a shame. So it seems id numbers > is the way to go here. I think it might be hinted that RFC 2822 > comments may be used to improve human readability: > > OpenPGP-Key: id=0x4711; algo=2 (RSA Encrypt only); size=42 > > or whatever. ================== very good observation! i think that will definitely make it into draft 0.2. ...atom _________________________________________ PGP key - http://atom.smasher.org/pgp.txt 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 ------------------------------------------------- "No! Try Not -- Do, or Do Not; There is no Try..." -- Yoda, The Empire Strikes Back -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.3.6 (FreeBSD) Comment: What is this gibberish? Comment: http://atom.smasher.org/links/#digital_signatures iQEcBAEBCAAGBQJBGYHdAAoJEAx/d+cTpVciRtoH/0rcPoyE0JjYvittrujMLa/V u0fC2NJ9RO+eHANpdmRGM878Uel4LFXsFQ4JRS3MDphArk6Ke2SpYJx4TUrORb7g KT4bX6LaEiMCmueodv0m1aoMXWK4YkrKP3kWFRj9pIH/QE6Twx7RYF3Vo03nzojo Cl78LIMy9JWjePrilyFjSyQoQNs5PLnKOi64c6gI/K6IQgS34fKq1OkDFqwYiwMk YQA7wJx3l0bIiDMDql3wxnfqAR/oY+9IS/nSjm+0g6jlYxTfgzPq9ZuTEU+hzhyp jWZZnSk8CLCDf2C02EDsSOPmV6+PG2RMSPwwjJqHVWs+y4l81FuuOpo/5E1oUKs= =vS3+ -----END PGP SIGNATURE----- From atom at suspicious.org Wed Aug 11 04:34:51 2004 From: atom at suspicious.org (Atom 'Smasher') Date: Wed Aug 11 04:31:48 2004 Subject: OpenPGP headers In-Reply-To: References: <20040806230905.W79076@willy_wonka> <20040809164110.GB14640@anathema.TechFak.Uni-Bielefeld.DE> <20040810102719.U79076@willy_wonka> <20040810155959.GA30425@northernsecurity.net> <20040810170600.N79076@willy_wonka> Message-ID: <20040810221916.Q79076@willy_wonka> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Wed, 11 Aug 2004, Simon Josefsson wrote: > Atom 'Smasher' writes: > should be allowed? Thus removing the need for OpenPGP-URL. Hm. Then > the header could be called simply 'OpenPGP' which is neat. E.g.: > > OpenPGP: id=B565716F; url=http://josefsson.org/key.txt; algo=1 (RSA); size=1280 > > Where all of the following would be equally valid: > > OpenPGP: id=B565716F > OpenPGP: url=http://josefsson.org/key.txt > OpenPGP: id=B565716F; algo=1 (RSA); size=1280 > OpenPGP: url=http://josefsson.org/key.txt; algo=1 (RSA); size=1280 =================== i really like this...! one header with 4 fields, each field is optional and MAY include human readable comments... so even this would be valid: OpenPGP: id=0x12345678 (DSA/1024) even though the algo and size cannot be parsed. or this example: OpenPGP: id=0x12345678 (This key is only used to sign things when i'm at the office) if someone feels inclined to identify their key using a short id, long id, or fingerprint, all are valid. it may produce a header that isn't the most aesthetically pleasing, but it would be a single header that it both human and machine readable.... this is moving towards elegance! i'll be re-reading rfc 2822, and then rewrite my draft accordingly... > Btw, does 2440 specify an unambiguous value for 'size' for DSA, > ElGamal, etc? ==================== not that i've found :( ...atom _________________________________________ PGP key - http://atom.smasher.org/pgp.txt 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 ------------------------------------------------- "I would rather fail in a cause that will ultimately triumph than triumph in a cause that will ultimately fail." -- Woodrow Wilson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.3.6 (FreeBSD) Comment: What is this gibberish? Comment: http://atom.smasher.org/links/#digital_signatures iQEcBAEBCAAGBQJBGYXRAAoJEAx/d+cTpVciki8IAJY8LKRMYDqvxkv40IYHuO/Y iKN/1s3zoNdOdK3w6HcCf7O4aqhpygoOhtIUJXyUWf18SycXaicLVoG0tjxmHid2 m7sLTAdG+m5Z/rCifftLUfg0dTB8kuQjCptnVp3lUypexgaIbhkkIN7Xwjpp9ded h4JNzjWqTnzkZYS1ktPp8KR9kUHziAvAcXTouHxHXA7niueDA4mCz9Ao8GERW516 bu2EwtbVq74N9zNaMc6m2N702hdaZI4/K867GYoHv1V0MaUsd7dnFlcpaE//bYEl uF50FcXskJRxu9tuMlal49A5Qw+30P65IosX2U3BScgSxuDEs/SkKh2I1gYNsuE= =uXpe -----END PGP SIGNATURE----- From atom at suspicious.org Wed Aug 11 04:52:23 2004 From: atom at suspicious.org (Atom 'Smasher') Date: Wed Aug 11 04:49:25 2004 Subject: STDOUT? STDERR? In-Reply-To: <87zn53q968.fsf@wheatstone.g10code.de> References: <20040808022604.Q79076@willy_wonka> <20040809155412.GA14640@anathema.TechFak.Uni-Bielefeld.DE> <20040809221203.P79076@willy_wonka> <87fz6vtow0.fsf@wheatstone.g10code.de> <20040810100822.B79076@willy_wonka> <87zn53q968.fsf@wheatstone.g10code.de> Message-ID: <20040810225140.B53517@willy_wonka> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Tue, 10 Aug 2004, Werner Koch wrote: > On Tue, 10 Aug 2004 10:10:39 -0400 (EDT), Atom 'Smasher' said: > >> tell me more about the interface that's designed to be used by other >> programs... there's an API i'm trying to fit this into, and it's not >> working 100%. > > see doc/DETAILS and the man page for --status-fd, --with-colons and > --command-fd. gpgme might be a good reference implementation. ================== hhmmm... it seems to be working now....? ...atom _________________________________________ PGP key - http://atom.smasher.org/pgp.txt 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 ------------------------------------------------- "In a time of universal deceit, telling the truth is a revolutionary act." -- George Orwell -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.3.6 (FreeBSD) Comment: What is this gibberish? Comment: http://atom.smasher.org/links/#digital_signatures iQEcBAEBCAAGBQJBGYn1AAoJEAx/d+cTpVcilvsH/AjWM1qRI+8DLX1+SKXHwBV4 Q0DkYxSyxrFckBCmup9E2G20p3jRi9MXXkutGqiL7TognrYLV/ujdI4934+KIDvy uDT+uBuCMrcLnmTuXQNH6cPGf0N8fpV3If+2PIetEME/rDFf0kDfKI+rV7cBtwCq q7mygN2LDcwtORAJ7idH9TX/p0sutsds4jIIUBvWLoVutmDoO6iQVnjDLqr6Je2G XNnDDHQORUAck/FjNWuNgWTCTkNq6RsQ9L2AqYA7HnliIxu5dCLG6UDu8CtClhNT yy4w4VCbuxvFuaa12m+PQuHnA52BOpvAaUHL35ti0Yw2pcgeCPUIjSg98irPBjI= =/11G -----END PGP SIGNATURE----- From jas at extundo.com Wed Aug 11 08:59:50 2004 From: jas at extundo.com (Simon Josefsson) Date: Wed Aug 11 08:56:45 2004 Subject: OpenPGP headers References: <20040806230905.W79076@willy_wonka> <20040809164110.GB14640@anathema.TechFak.Uni-Bielefeld.DE> <20040810102719.U79076@willy_wonka> <20040810155959.GA30425@northernsecurity.net> <20040810170600.N79076@willy_wonka> <20040810221916.Q79076@willy_wonka> Message-ID: Atom 'Smasher' writes: >> OpenPGP: id=B565716F >> OpenPGP: url=http://josefsson.org/key.txt >> OpenPGP: id=B565716F; algo=1 (RSA); size=1280 >> OpenPGP: url=http://josefsson.org/key.txt; algo=1 (RSA); size=1280 > =================== > > i really like this...! > > one header with 4 fields, each field is optional and MAY include human > readable comments... so even this would be valid: > OpenPGP: id=0x12345678 (DSA/1024) > even though the algo and size cannot be parsed. > > or this example: > OpenPGP: id=0x12345678 (This key is only used to > sign things when i'm at the office) > > if someone feels inclined to identify their key using a short id, long id, > or fingerprint, all are valid. Moving the above one step further: If the header only include an 'id' or 'url' value, perhaps the labels can be removed, i.e. permit for example (as well as the above ones): OpenPGP: http://josefsson.org/key.txt OpenPGP: http://josefsson.org/key.txt (RSA/1280) OpenPGP: 0xB565716F OpenPGP: B565716F (RSA/1280) Parsing this should be unambiguous. If string contain ':', then it is an url, if it contain [0x][0-9A-Z-z] it is an key id, if it contain '=' it contain labels. Perhaps this is getting too complicated to implement, even though it make the header nice to look at. What do people think? > i'll be re-reading rfc 2822, and then rewrite my draft accordingly... As for human readable comments, you don't need to specify much, as comments are allowed almost anywhere. >> Btw, does 2440 specify an unambiguous value for 'size' for DSA, >> ElGamal, etc? > ==================== > > not that i've found :( That's bad, it might make it difficult to specify the 'size' parameter in some interoperable way. But GnuPG print, say, '1024D' after all, so perhaps it is standardized. And 2440 talk about minimum size restrictions for RSA/DSA/ElGamal, in number of bits, so perhaps it is specified. Thanks, Simon From jas at extundo.com Wed Aug 11 09:04:57 2004 From: jas at extundo.com (Simon Josefsson) Date: Wed Aug 11 09:01:49 2004 Subject: OpenPGP headers References: <20040806230905.W79076@willy_wonka> <20040809164110.GB14640@anathema.TechFak.Uni-Bielefeld.DE> <20040810102719.U79076@willy_wonka> <20040810141858.S79076@willy_wonka> <20040810220125.O79076@willy_wonka> Message-ID: Atom 'Smasher' writes: > On Tue, 10 Aug 2004, Simon Josefsson wrote: >> Atom 'Smasher' writes: > >>> when signing (or otherwise verifying) a key, it's recommended to confirm >>> the fingerprint, size, and type of the key (and UID, of course). if all of >>> these checks are done (and keys are reasonably large), then it's >>> infeasible to substitute a "trojan" key. >> >> Given Werner's comment, I have my doubts whether this checking is >> necessary. It seems the checks provide marginal improvements, in >> which case I believe that any requirement to perform these checks >> itself (i.e., the _requirement_ itself, not the checks) is more >> harmful than not performing the checks. > =================== > > ??? the spec would *allow* the information of key type and size to be > convoyed, but not require any application to make use of that information. Yes, that's what I meant. >> I agree. It was a suggestion to things to add to the 'security >> consideration', and not to the core part of the document, after all. > ============= > > oh, yes... you mean point out foreseeable security pitfalls... yeah, that > is a good idea. i thought you were suggestion that the spec recommends how > an application should or shouldn't use the information. No, that wasn't my intention. Today's DNSSEC doesn't work, but still many specification suggest that people should use DNSSEC to solve DNS security problems... Similarly, using HTTPS doesn't improve things much, since there is no global PKI, but people suggest it anyway. Thanks, Simon From atom at suspicious.org Wed Aug 11 09:22:10 2004 From: atom at suspicious.org (Atom 'Smasher') Date: Wed Aug 11 09:19:13 2004 Subject: OpenPGP headers In-Reply-To: References: <20040806230905.W79076@willy_wonka> <20040809164110.GB14640@anathema.TechFak.Uni-Bielefeld.DE> <20040810102719.U79076@willy_wonka> <20040810141858.S79076@willy_wonka> <20040810220125.O79076@willy_wonka> Message-ID: <20040811032037.G53517@willy_wonka> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 draft 0.2 http://atom.smasher.org/pgp-headers/pgp-headers02.txt past my bedtime, this is probably filled with errors. it now specifies one header (OpenPGP) with 4 name/value pairs. lemme know what ya'll think.... thanks... ...atom _________________________________________ PGP key - http://atom.smasher.org/pgp.txt 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 ------------------------------------------------- "A good many observers have remarked that if equality could come at once the Negro would not be ready for it. I submit that the white American is even more unprepared." -- Martin Luther King, Jr. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.3.6 (FreeBSD) Comment: What is this gibberish? Comment: http://atom.smasher.org/links/#digital_signatures iQEcBAEBCAAGBQJBGckpAAoJEAx/d+cTpVcispIH+wTAng9NSEOgLj/Du6dfUvfM /CKpLn0ijBNtuVsvx3J8iI/x3cjv7OMF41AP02d9iE7W+EP768Y37HWHDhmKatVB J8u+OiRqIrI/DpIw0qjPWE8Ch34QieFq6Zy4a5YzhwW6j2ebDleIk5A/67RNb0Vl 5rLW18ERW1ovOnQunkCKeU6uXjAZ+UXa8qvmiU5nsOyYfKne1FG9LgFIFf1WWv2Q F50Ai+drbtdFBIFx7p4JG5A2qiUqbapAnRS0ejfKmwOI5TMXTB4W2HX2dFEHMHmX vbLT5yciF8r7r56bDai5t3f0a0iZQsta79x1QBLlFxG1oGJKVjwvQh6hzXA85F4= =SrDr -----END PGP SIGNATURE----- From wk at gnupg.org Wed Aug 11 10:02:00 2004 From: wk at gnupg.org (Werner Koch) Date: Wed Aug 11 10:03:29 2004 Subject: OpenPGP headers In-Reply-To: <20040810141858.S79076@willy_wonka> (atom@suspicious.org's message of "Tue, 10 Aug 2004 14:52:40 -0400 (EDT)") References: <20040806230905.W79076@willy_wonka> <20040809164110.GB14640@anathema.TechFak.Uni-Bielefeld.DE> <20040810102719.U79076@willy_wonka> <20040810141858.S79076@willy_wonka> Message-ID: <87zn52m7bb.fsf@wheatstone.g10code.de> On Tue, 10 Aug 2004 14:52:40 -0400 (EDT), Atom 'Smasher' said: > when signing (or otherwise verifying) a key, it's recommended to > confirm the fingerprint, size, and type of the key (and UID, of Only for old keys; identifiable by MD5 fingerprints. For new keys there is no point in verifying other properties than the fingerprint. Werner From mo at g10code.com Wed Aug 11 11:22:44 2004 From: mo at g10code.com (Moritz Schulte) Date: Wed Aug 11 11:19:51 2004 Subject: STDOUT? STDERR? In-Reply-To: <20040810225140.B53517@willy_wonka> References: <20040808022604.Q79076@willy_wonka> <20040809155412.GA14640@anathema.TechFak.Uni-Bielefeld.DE> <20040809221203.P79076@willy_wonka> <87fz6vtow0.fsf@wheatstone.g10code.de> <20040810100822.B79076@willy_wonka> <87zn53q968.fsf@wheatstone.g10code.de> <20040810225140.B53517@willy_wonka> Message-ID: <20040811092244.GA52585@cuttysark.lan> On Tue, Aug 10, 2004 at 10:52:23PM -0400, Atom 'Smasher' wrote: > hhmmm... it seems to be working now....? What exactly? moritz -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : /pipermail/attachments/20040811/596bc4fb/attachment.bin From jas at extundo.com Wed Aug 11 12:08:37 2004 From: jas at extundo.com (Simon Josefsson) Date: Wed Aug 11 12:05:39 2004 Subject: OpenPGP headers References: <20040806230905.W79076@willy_wonka> <20040809164110.GB14640@anathema.TechFak.Uni-Bielefeld.DE> <20040810102719.U79076@willy_wonka> <20040810141858.S79076@willy_wonka> <20040810220125.O79076@willy_wonka> <20040811032037.G53517@willy_wonka> Message-ID: Atom 'Smasher' writes: > http://atom.smasher.org/pgp-headers/pgp-headers02.txt > > past my bedtime, this is probably filled with errors. > > it now specifies one header (OpenPGP) with 4 name/value pairs. > > lemme know what ya'll think.... I believe a BNF schema describing the structure is needed, to match how headers are described in 2822. How about the grammar below? Review appreciated. I intentionally made 0x optional, and permitted a unlabeled Key ID, fingerprint or URL. The text will have to be synced with that change. If people think it is a good idea, of course. I also added a 'created' value pair. I'm not convinced it make sense, just like I'm not sure alg/size make sense. 'Created' contain unix time below, matching the V3/V4 key packet 'created' value. Perhaps 'date-time' could be used, instead of unix time, although the relative free form of that terminal, together with time zones, might make it overly complex. Human readable dates can always be put into comments, like: OpenPGP: id=0xB565716F; created=471147111 (10 Aug 2004 22:34:51 +0000) I think that would be more reliable. There should probably be text pointing out that alg/size/created is only useful for V3 keys, as per Werner's recommendation. I don't know how to easily permit: OpenPGP: 0424 D4EE 81A0 E3D1 19C6 F835 EDA2 1E94 B565 716F Instead of just: OpenPGP: 0424D4EE81A0E3D119C6F835EDA21E94B565716F I think the first should be permitted, for readability. If some knows of a neat ABNF trick to get the first one, that would be good. Of course, ugly ABNF is simple to create for it.. This need to be fixed. If you would accept me as co-editor, I could convert your draft into xml2rfc format, and add the ABNF below. The format is pretty self explanatory, if you know HTML or general XML. See RFC 2629 for the full documentation. Thanks, Simon Grammar for OpenPGP header. --------------------------- This appendix contains the complete ABNF grammar for all the syntax specified by this document. By itself, however, this grammar is incomplete. It refers by name to several syntax rules that are defined by RFC 2822 and RFC 2396. Rather than reproduce those definitions here, and risk unintentional differences between the two, this document simply refers the reader to RFC 2822 and RFC 2396 for the remaining definitions. openpgp := "OpenPGP:" id-or-url-value / (parameter *(";" parameter)) CRLF id-value := ["0x"] (4*HEXDIG / 8*HEXDIG / 32*HEXDIG / 40*HEXDIG) url-value := absoluteURI ; Defined in RFC 2396. id-or-url := id-value / absoluteURI alg-value := *DIGIT ; Value in RFC 2440 section 9.1. size-value := *DIGIT ; Key size in bits. created-value := *DIGIT ; Correspond to four-octet number in RFC 2440 V3/V4 ; key packet that indicate the time the key was ; created. parameter := ("id" "=" id-value) / ("url" "=" url-value) / ("alg" "=" alg-value) / ("size" "=" size-value) / ("created" "=" created-value) [RFC2234] Crocker, D., Editor, and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [RFC2396] Berners-Lee, T., R. Fielding and L. Manister, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001. From Stefan.Haller at ascom.ch Wed Aug 11 13:08:36 2004 From: Stefan.Haller at ascom.ch (Stefan Haller) Date: Wed Aug 11 13:05:25 2004 Subject: GPG Lockfile (concurrency) issue, keyring lost: awarding 300$ for bugfix Message-ID: Hi all A while ago I posted a bug report about a concurrency issue. Parallel import and verify GPG processes using the same keyring may result in loosing all public keys in the key ring. I upgraded to 1.2.5, but the issues are still present. I looked at the code myself, but I think it will require a lot of time for me to fix the issues and it will probably result only in a poor work around. I would like a good solution for the issue which is acceptable to the GnuPG development team for use in future versions of GnuPG to increase the products quality. I will award up to 300$ to the developer that solves the problem for me. Please find details below. I need two modifications in GnuPG: 1. The lockfile for the keyring is not handeled correctly, it seems. I need proper locking to prevent GPG from loosing the entire public key ring. I think it happens somehow like this: - import renames keyring and updates file - verify does not find keyring file and creates new one - import finds an already existing keyring and is unable to rename the updated file back If the output of gpg is... gpg: keyring `/var/tmp/keyring_lost_test/pubring.gpg' created ... you know that all keys in keyring were lost. 2. In case GPG cannot run because of a lock-file being present, I require a separate exit status. This will indicate to my program that it can retry the command afterwards as it was not a real error. I'm willing to award 100$ for a patch based on the last stable release of GPG, fixing above issues. Another 100$ are awarded to the patch author, if the patch is accepted by the GPG core team and incorporated in future releases. Another 100$ are awarded if I have a working solution until end of August 2004. The following acceptance procedures apply: The patch is verified using a shell script I wrote to reproduce the behaviour. It is attached to this email. The patch is only accepted if the script succeeds on my system. I reserve the right to adjust the test script in case I built in errors into the test procedure, so just using a bug in the test script to make it work is not accepted... (first 100$ for a working patch) If the patch is committed to the main GnuPG development branch by GPG core developers (or anyone with permissions), the patch author will be rewarded with another 100$ as the GPG core team thinks it is a good patch. If I get a working patch (does not need to be included in GPG development branch, just working for me) by end of August 2004, I reward the patch author by another 100$. Above goals are cumulative, meaning that I am willing to pay up to 300$ if all conditions are fulfilled. To prevent a chaos, this "contract" is awarded as follows: - participation requires explicit confirmation by me. This is to prevent more than one person working on the issue. So, just mail me first if you would like to do this. - first come, first served. I will confirm the first person mailing me, that he may start implementing. The others will be notified, that it is already taken care of. I hope you find this offer interesting. Contact me if you have any questions on the topic. With kind regards Stefan Stefan Haller Software Development Transport Revenue ________________________________ Ascom Autelca Ltd. Worbstrasse 201 CH-3073 G?mligen Phone Fax +41 31 999 65 06 +41 31 999 65 82 stefan.haller@ascom.ch www.ascom.com -------------- next part -------------- A non-text attachment was scrubbed... Name: keyring_lost_spike.sh Type: application/octet-stream Size: 4046 bytes Desc: not available Url : /pipermail/attachments/20040811/0c722ab4/keyring_lost_spike-0001.exe From jas at extundo.com Wed Aug 11 13:29:32 2004 From: jas at extundo.com (Simon Josefsson) Date: Wed Aug 11 13:26:26 2004 Subject: GPG Lockfile (concurrency) issue, keyring lost: awarding 300$ for bugfix References: Message-ID: Nice idea. Stefan Haller writes: > The patch is verified using a shell script I wrote to reproduce the > behaviour. It is attached to this email. The patch is only accepted if the > script succeeds on my system. I reserve the right to adjust the test > script in case I built in errors into the test procedure, so just using a > bug in the test script to make it work is not accepted... (first 100$ for > a working patch) Your shell script doesn't seem to have a terminating condition, except for errors. The $IMPORT_FINISHED file is never created, as far as I can tell. This is confirmed by running it, it just loops forever. Using the development branch, I don't get any errors from the script. Perhaps the problem is fixed in the development branch? Did you build gpg yourself, or used someone else's build? Perhaps there is something wrong with the build. Thanks, Simon From Stefan.Haller at ascom.ch Wed Aug 11 14:19:33 2004 From: Stefan.Haller at ascom.ch (Stefan Haller) Date: Wed Aug 11 14:18:00 2004 Subject: GPG Lockfile (concurrency) issue, keyring lost: awarding 300$ for bugfix Message-ID: Hi Thanks for the quick answer. I, in fact, did use somebody else's compile. So, I checked out the HEAD branch from CVS now myself, but unfortunately, I cannot build it because of autoconf. (autoconf-2.59 from sunfreeware.com on Solaris 8). Output is: nhalls@parrot:~/tmp/gnupg$ autoconf configure.ac:38: error: possibly undefined macro: AM_INIT_AUTOMAKE If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.ac:39: error: possibly undefined macro: AM_CONFIG_HEADER configure.ac:366: error: possibly undefined macro: AM_MAINTAINER_MODE configure.ac:371: error: possibly undefined macro: AM_SANITY_CHECK configure.ac:373: error: possibly undefined macro: AM_MISSING_PROG configure.ac:389: error: possibly undefined macro: AM_CONDITIONAL configure.ac:651: error: possibly undefined macro: AM_GNU_GETTEXT_VERSION configure.ac:653: error: possibly undefined macro: AM_GNU_GETTEXT What is wrong here? Any help apprciated. Cheers Stefan Stefan Haller Software Development Transport Revenue ________________________________ Ascom Autelca Ltd. Worbstrasse 201 CH-3073 G?mligen Phone Fax +41 31 999 65 06 +41 31 999 65 82 stefan.haller@ascom.ch www.ascom.com Simon Josefsson Sent by: gnupg-devel-bounces@gnupg.org 11/08/04 13:29 To: gnupg-devel@gnupg.org cc: Subject: Re: GPG Lockfile (concurrency) issue, keyring lost: awarding 300$ for bugfix Nice idea. Stefan Haller writes: > The patch is verified using a shell script I wrote to reproduce the > behaviour. It is attached to this email. The patch is only accepted if the > script succeeds on my system. I reserve the right to adjust the test > script in case I built in errors into the test procedure, so just using a > bug in the test script to make it work is not accepted... (first 100$ for > a working patch) Your shell script doesn't seem to have a terminating condition, except for errors. The $IMPORT_FINISHED file is never created, as far as I can tell. This is confirmed by running it, it just loops forever. Using the development branch, I don't get any errors from the script. Perhaps the problem is fixed in the development branch? Did you build gpg yourself, or used someone else's build? Perhaps there is something wrong with the build. Thanks, Simon _______________________________________________ Gnupg-devel mailing list Gnupg-devel@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-devel From jas at extundo.com Wed Aug 11 14:35:38 2004 From: jas at extundo.com (Simon Josefsson) Date: Wed Aug 11 14:32:37 2004 Subject: GPG Lockfile (concurrency) issue, keyring lost: awarding 300$ for bugfix References: Message-ID: Stefan Haller writes: > Hi > > Thanks for the quick answer. > > I, in fact, did use somebody else's compile. So, I checked out the HEAD > branch from CVS now myself, but unfortunately, I cannot build it because > of autoconf. (autoconf-2.59 from sunfreeware.com on Solaris 8). > > Output is: > nhalls@parrot:~/tmp/gnupg$ autoconf > configure.ac:38: error: possibly undefined macro: AM_INIT_AUTOMAKE > If this token and others are legitimate, please use > m4_pattern_allow. > See the Autoconf documentation. > configure.ac:39: error: possibly undefined macro: AM_CONFIG_HEADER > configure.ac:366: error: possibly undefined macro: AM_MAINTAINER_MODE > configure.ac:371: error: possibly undefined macro: AM_SANITY_CHECK > configure.ac:373: error: possibly undefined macro: AM_MISSING_PROG > configure.ac:389: error: possibly undefined macro: AM_CONDITIONAL > configure.ac:651: error: possibly undefined macro: AM_GNU_GETTEXT_VERSION > configure.ac:653: error: possibly undefined macro: AM_GNU_GETTEXT > > What is wrong here? You didn't read README.CVS. Btw, I have better experience with 'autoreconf -fvi' instead of autogen.sh. YMMV. Regards, Simon From wk at gnupg.org Wed Aug 11 18:37:58 2004 From: wk at gnupg.org (Werner Koch) Date: Wed Aug 11 18:38:31 2004 Subject: GPG Lockfile (concurrency) issue, keyring lost: awarding 300$ for bugfix In-Reply-To: (Stefan Haller's message of "Wed, 11 Aug 2004 13:08:36 +0200") References: Message-ID: <87y8klk4ux.fsf@wheatstone.g10code.de> On Wed, 11 Aug 2004 13:08:36 +0200, Stefan Haller said: > I upgraded to 1.2.5, but the issues are still present. I looked at the > code myself, but I think it will require a lot of time for me to fix the Please apply the attached patch against 1.2.5 and see whether it works for you. I could verify it using your script. Werner -------------- next part -------------- A non-text attachment was scrubbed... Name: apatch Type: application/octet-stream Size: 10855 bytes Desc: not available Url : /pipermail/attachments/20040811/e928ac32/apatch.exe From atom at suspicious.org Thu Aug 12 03:18:03 2004 From: atom at suspicious.org (Atom 'Smasher') Date: Thu Aug 12 03:15:10 2004 Subject: STDOUT? STDERR? In-Reply-To: <20040811092244.GA52585@cuttysark.lan> References: <20040808022604.Q79076@willy_wonka> <20040809155412.GA14640@anathema.TechFak.Uni-Bielefeld.DE> <20040809221203.P79076@willy_wonka> <87fz6vtow0.fsf@wheatstone.g10code.de> <20040810100822.B79076@willy_wonka> <87zn53q968.fsf@wheatstone.g10code.de> <20040810225140.B53517@willy_wonka> <20040811092244.GA52585@cuttysark.lan> Message-ID: <20040811203954.M53517@willy_wonka> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Wed, 11 Aug 2004, Moritz Schulte wrote: > On Tue, Aug 10, 2004 at 10:52:23PM -0400, Atom 'Smasher' wrote: > >> hhmmm... it seems to be working now....? > > What exactly? ===================== ez-pine-gpg-[sign-and-]encrypt under some circumstances, which i think i can recreate, pine gobbles up info directed to /dev/tty. info sent to stdout & stderr are fine. so, when sending a message to an untrusted key, and gpg asks if i want to: Use this key anyway? it doesn't echo a user's response to the screen. i figured out a fix, and i'll include it in the next release. ...atom _________________________________________ PGP key - http://atom.smasher.org/pgp.txt 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 ------------------------------------------------- "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.3.6 (FreeBSD) Comment: What is this gibberish? Comment: http://atom.smasher.org/links/#digital_signatures iQEcBAEBCAAGBQJBGsVRAAoJEAx/d+cTpVci4DkH/3uSdEFaT5cNDqfRQOn0qMYO bP9zL+m+tvdG6L7kbr3Bu/BmYufBJSSBk0ljsc7Dc7Cq2uEmKap0XIuWASoj3mnv hJPDfbKLDweU6Nwex9zPWfpKeeyjF8H65puNWeSBJLWjbrbmGHz7Fi4sG/y3qF3i wTtuKUJRFhyaNUTH5/0H2Yb2II5W9iADBfSpJLAeiVu7V7Eb1+XD3buEkvN8hoI9 5D0ueB/fEedB5s80XXvx/+M1Izt15Rj6nbS0ijsWWcNCCmkyTw7EOa5/vyYGe3Ab NH+Gn83aDTTh+NyaI1G9aIoVQLwWhut4KXHH8CctEJ6A6DihsLSkIHRWrpzGi6A= =PI3k -----END PGP SIGNATURE----- From atom at suspicious.org Thu Aug 12 04:05:34 2004 From: atom at suspicious.org (Atom 'Smasher') Date: Thu Aug 12 04:02:42 2004 Subject: OpenPGP headers In-Reply-To: References: <20040806230905.W79076@willy_wonka> <20040809164110.GB14640@anathema.TechFak.Uni-Bielefeld.DE> <20040810102719.U79076@willy_wonka> <20040810141858.S79076@willy_wonka> <20040810220125.O79076@willy_wonka> <20040811032037.G53517@willy_wonka> Message-ID: <20040811212429.L75372@willy_wonka> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Wed, 11 Aug 2004, Simon Josefsson wrote: > Atom 'Smasher' writes: > I believe a BNF schema describing the structure is needed, to match > how headers are described in 2822. How about the grammar below? > Review appreciated. ================== very nice... i can ~almost~ read that BNF notation, but i wasn't going to attempt writing anything in it. > I intentionally made 0x optional, ==================== what do the gurus think? dave? werner? i think a 0x prefix "SHOULD" be used. not mandatory, but if there isn't a good reason for skipping it, then use it. > and permitted a unlabeled Key ID, fingerprint or URL. The text will > have to be synced with that change. If people think it is a good idea, > of course. ===================== my concern here is the burden that it might place on parsing engines versus the improvement in human readability... sure, it's not a ridiculous burden, but i think that any person inclined to read the header won't be confused by it. at the very least, i then i think a key ID MUST have a "0x" prefix, *if* it's unlabeled. > I also added a 'created' value pair. I'm not convinced it make sense, > just like I'm not sure alg/size make sense. 'Created' contain unix > time below, matching the V3/V4 key packet 'created' value. Perhaps > 'date-time' could be used, instead of unix time, although the relative > free form of that terminal, together with time zones, might make it > overly complex. Human readable dates can always be put into comments, > like: > > OpenPGP: id=0xB565716F; created=471147111 (10 Aug 2004 22:34:51 +0000) > > I think that would be more reliable. =============== well, they're all optional parameters, so i don't think there's anything wrong with including it... as long as someone out there finds it useful. there ~are~ people still using v3 keys. i do like that it's in unix time, with a human readable date as a comment. > There should probably be text pointing out that alg/size/created is > only useful for V3 keys, as per Werner's recommendation. ================ since all parameters are optional, i don't think it's necessary to mention that... people can use whatever parameters they want, guided only by their paranoia. while i acknowledge that werner is more of a pgp guru than i am, i just want to point out that before the deadbeef attack, people thought that a fingerprint was the only token needed in verifying a v3 key. who knows what attacks the future will reveal? who knows how we'll defend against those attacks? thus, my paranoia tells me to verify key size and algo even on v4 keys. not that it's feasible to create a small v4 key that matches my fingerprint, but i suspect it's *much* harder to create a 4096 v4 key that matches my fingerprint. > I don't know how to easily permit: > > OpenPGP: 0424 D4EE 81A0 E3D1 19C6 F835 EDA2 1E94 B565 716F > > Instead of just: > > OpenPGP: 0424D4EE81A0E3D119C6F835EDA21E94B565716F > > I think the first should be permitted, for readability. If some knows > of a neat ABNF trick to get the first one, that would be good. Of > course, ugly ABNF is simple to create for it.. This need to be fixed. =================== can that be done with double quotes? even if it can be done: 1) it places an additional burden on the parser 2) if the header is folded then human readability is not gained in any case, one can do this: OpenPGP: url=http://abc.xyz (1234 5678 90AB CDEF 0123 4567 890A BCDE F012 3456) and include a fingerprint with spaces as a comment. folding could make that very ugly. is it valid syntax to place a comment before a parameter? or use 1 or more comments with zero parameters? if the first thing in the header is a comment, then folding is less likely to affect it. > If you would accept me as co-editor, I could convert your draft into > xml2rfc format, and add the ABNF below. The format is pretty self > explanatory, if you know HTML or general XML. See RFC 2629 for the > full documentation. =================== hehe... you're hired! ...atom _________________________________________ PGP key - http://atom.smasher.org/pgp.txt 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 ------------------------------------------------- "Not a single war has been fought by vegetarians." -- Akbarali Jetha -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.3.6 (FreeBSD) Comment: What is this gibberish? Comment: http://atom.smasher.org/links/#digital_signatures iQEcBAEBCAAGBQJBGtB0AAoJEAx/d+cTpVcigKwH/iLki14MeTxDnyyDG2SL1EkR fe5NEh4EiNtjpbIp9MNHY6yooM3Ym708HYE0dVxggUVVlr1H+QZyY4NwV9MmA9o3 lPfZ+1d2dzcHCvUmiVHmEMOx2RyJQzaQIikC4xERnhgUNEAzNxModCteDqS3xvQx OHFBHTc+Qb4OtpcoRfTaXM16bLm4GEwRkuYqK53txulKmltPNoXlHH7LxFm66AKh Yfhes7t4VjDcpKfiqiULbDaaoKOUzeZteUZ44arvV9IQQ7lJ3G/RPMWE3bgURBsQ B4HgearjhBn8bG07nzO7bVqg3WqDYNbLobUuEFAAWG57XEEX46BLUl5QB1+0IPQ= =gxO0 -----END PGP SIGNATURE----- From Stefan.Haller at ascom.ch Fri Aug 13 09:38:44 2004 From: Stefan.Haller at ascom.ch (Stefan Haller) Date: Fri Aug 13 09:35:36 2004 Subject: GPG Lockfile (concurrency) issue, keyring lost: awarding 300$ for bugfix Message-ID: Hi all The latest development version as indicated by Simon Josefsson did not work for me. And in fact, my test script was buggy of course, I include the latest in this email again. Werner, your patch works great for me. I'm especially happy with the fact that I do not need to consider the lock-exit code thanks to your 10 second timeout... I have only two questions, is there a good reason that I get the following message : gpg: some signal caught ... exiting I got this message 20 times during the period that is required to import 50 keys... But exit code seems to be 0 always and I cannot spot any real problem with it. Second question, are you going to include this patch in the development branch that is used for the next stable release? I will contact you, Werner, directly for payment details... Thanks for the quick help! Stefan Stefan Haller Software Development Transport Revenue ________________________________ Ascom Autelca Ltd. Worbstrasse 201 CH-3073 G?mligen Phone Fax +41 31 999 65 06 +41 31 999 65 82 stefan.haller@ascom.ch www.ascom.com Werner Koch Sent by: gnupg-devel-bounces@gnupg.org 11/08/04 18:37 To: gnupg-devel@gnupg.org cc: Subject: Re: GPG Lockfile (concurrency) issue, keyring lost: awarding 300$ for bugfix On Wed, 11 Aug 2004 13:08:36 +0200, Stefan Haller said: > I upgraded to 1.2.5, but the issues are still present. I looked at the > code myself, but I think it will require a lot of time for me to fix the Please apply the attached patch against 1.2.5 and see whether it works for you. I could verify it using your script. Werner _______________________________________________ Gnupg-devel mailing list Gnupg-devel@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: apatch Type: application/octet-stream Size: 10856 bytes Desc: not available Url : /pipermail/attachments/20040813/d96854cb/apatch.exe From Stefan.Haller at ascom.ch Fri Aug 13 10:29:37 2004 From: Stefan.Haller at ascom.ch (Stefan Haller) Date: Fri Aug 13 10:26:25 2004 Subject: GPG Lockfile (concurrency) issue, keyring lost: awarding 300$ for bugfix Message-ID: Find the promised and forgotten test script attached... -------------- next part -------------- A non-text attachment was scrubbed... Name: keyring_lost_spike.sh Type: application/octet-stream Size: 4386 bytes Desc: not available Url : /pipermail/attachments/20040813/fd1a8a95/keyring_lost_spike-0001.exe From wk at gnupg.org Fri Aug 13 11:30:56 2004 From: wk at gnupg.org (Werner Koch) Date: Fri Aug 13 11:33:34 2004 Subject: GPG Lockfile (concurrency) issue, keyring lost: awarding 300$ for bugfix In-Reply-To: (Stefan Haller's message of "Fri, 13 Aug 2004 09:38:44 +0200") References: Message-ID: <878ycjv0z3.fsf@wheatstone.g10code.de> On Fri, 13 Aug 2004 09:38:44 +0200, Stefan Haller said: > Werner, your patch works great for me. I'm especially happy with the fact > that I do not need to consider the lock-exit code thanks to your 10 second > timeout... Hmmm, there is no timeout. > I have only two questions, is there a good reason that I get the following > message : > gpg: some signal caught ... exiting Your system does not define NSIG so there is no proper way to print the signal name from within a signal handler. > I got this message 20 times during the period that is required to import > 50 keys... But exit code seems to be 0 always and I cannot spot any real > problem with it. If it is possible for you too have it run under strace or truss we might be able to figure out what signal causes the problem. Probably it will also work to modify the following function in g10/signal.c to read: static const char * get_signal_name( int signum ) { #if defined(SYS_SIGLIST_DECLARED) && defined(NSIG) return (signum >= 0 && signum < NSIG) ? sys_siglist[signum] : "?"; #else /*return "some signal";*/ static char buf[100]; sprintf (buf, "signal no %d ", signum); return buf; #endif } > Second question, are you going to include this patch in the development > branch that is used for the next stable release? I'll do a release candidate for 1.2.6 today (unless your signal problem is serious) including the patch. This is also to test the new gettext version we decided to use for 1.2.6. Werner From wk at gnupg.org Fri Aug 13 20:03:16 2004 From: wk at gnupg.org (Werner Koch) Date: Fri Aug 13 20:03:31 2004 Subject: [Announce] Release candidate for 1.2.6 Message-ID: <87vffmsyor.fsf@wheatstone.g10code.de> Hi, we just created a quick release candidate to be sure that 1.2.6 won't cause serious problems. ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-1.2.6rc1.tar.gz ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-1.2.6rc1.tar.gz.sig The NEWS reads as follows: * Updated the included gettext. This also fixes the installation problem from 1.2.5 * Fixed a race condition leading to deleted keys. config.{sub,guess} are also updated. If you had problems with 1.2.5 - except for the installation problem - we would appreciate if you can check this one out and report problems to gnupg-devel@gnupg.org or gnupg-users@gnupg.org. Thanks, Werner (for the GnuPG hackers) From jvender at owensboro.net Sat Aug 14 00:33:18 2004 From: jvender at owensboro.net (Joe Vender) Date: Sat Aug 14 00:31:15 2004 Subject: GnuPG 1.2.6rc1 gettext Message-ID: <200408131733180090.000B383B@216.135.2.37> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I noticed that the config.log of 1.2.6rc1 doesn't show a check for whether the included gettext is requested, even when I set the configure option --with-included-gettext. Does it automatically use the gettext source included with GnuPG, whether or not its requested? It shows the included-zlib check, and I though it used to show the included-gettext check. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6rc1 (MingW32) - GPGshell v3.21 iQEVAwUBQR1BdybIfMqPbtHmAQJzzgf+LK+s09x7U05su7hny7O8REiUk1YYWG6d bKhiciCVHxNA5v8ux2Hi8YGePbN99I3z9q6G6qwvUG84OK6QR/25rR8iimns7pd9 HZJ9v5eNbXLnd1mZB2lSrtoXlobfThAIJlj1pdn6iJfewD2F+AtukfYUvNbJV9RO sbR1Q0BgOuBorCrL5apbGDxSEPomofXvb3QTEXYdVNfaL4CBtYPyzkPUsaZC061v g9RUu9FmabAPhM31Mt33J8nKCaK+cKzt/4TnEcIxD6f6rx8L2BB6nWHv4G62DtaP a9y6H2dxxVPuwiU6aSVHo0VDEybXv1hm0DDY2Vn4yGGJ/sgHzDWiCw== =hEil -----END PGP SIGNATURE----- From cyprien.simons at tu-berlin.de Mon Aug 16 16:24:46 2004 From: cyprien.simons at tu-berlin.de (Cyprien Simons) Date: Mon Aug 16 16:17:40 2004 Subject: signing a file using gnuPG libraries Message-ID: <200408161624.47301.cyprien.simons@tu-berlin.de> Hi, I'm trying to use the GnuPG libraries, and I encounter a problem in signing a file. I use read_passphrase_from_fd( int pwd_fd ) and then clearsign_file( ... ) to do the job. But somehow I get a "bad passphrase". I've checked if the password is correct and correctly read by the read_passphrase_from_fd() function, so I really don't understand where the problem is... I've discovered that the problem appear in the build_sklist() function: ( unlock && (rc = check_secret_key( sk, 0 )) ) return TRUE which leads to the "skipped 'nameofmykey': bad passphrase" message... I don't know if this mailinglist is the good one for asking such a question. If not, sorry for the mail, and I'll be appreciating any redirection on another forum. Thanks a lot for any help, Cyprien From wk at gnupg.org Mon Aug 16 20:07:14 2004 From: wk at gnupg.org (Werner Koch) Date: Mon Aug 16 20:08:34 2004 Subject: signing a file using gnuPG libraries In-Reply-To: <200408161624.47301.cyprien.simons@tu-berlin.de> (Cyprien Simons's message of "Mon, 16 Aug 2004 16:24:46 +0200") References: <200408161624.47301.cyprien.simons@tu-berlin.de> Message-ID: <87llgfot2l.fsf@wheatstone.g10code.de> On Mon, 16 Aug 2004 16:24:46 +0200, Cyprien Simons said: > I'm trying to use the GnuPG libraries, and I encounter a problem in signing a Libraries? GnuPG is not a library. However, GPGME provides a library based interface to GnuPG. > file. I use read_passphrase_from_fd( int pwd_fd ) and then > clearsign_file( ... ) to do the job. But somehow I get a "bad > passphrase". Cannibalizing GnuPG is not a simple task; you need to understand how the modules interact with each other. Werner From dshaw at jabberwocky.com Mon Aug 16 20:58:21 2004 From: dshaw at jabberwocky.com (David Shaw) Date: Mon Aug 16 20:55:40 2004 Subject: GnuPG 1.2.6rc1 gettext In-Reply-To: <200408131733180090.000B383B@216.135.2.37> References: <200408131733180090.000B383B@216.135.2.37> Message-ID: <20040816185821.GA1473@jabberwocky.com> On Fri, Aug 13, 2004 at 05:33:18PM -0500, Joe Vender wrote: > I noticed that the config.log of 1.2.6rc1 doesn't show a check > for whether the included gettext is requested, even when I set > the configure option --with-included-gettext. Does it > automatically use the gettext source included with GnuPG, > whether or not its requested? It shows the included-zlib check, > and I though it used to show the included-gettext check. It still does, so far as I can see. David From mail at joachim-breitner.de Tue Aug 17 14:08:56 2004 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue Aug 17 14:05:42 2004 Subject: Ideas for private key management interface Message-ID: <1092744535.837.46.camel@barney.ehbuehl.net> Hi List, it has become more and more common to have "complicated" setups with regard to private keys and their subkeys. For example, it is reasonable to have the primary key exported to a usb stick (and only there), the encryption subkey is printed out for backup reasons and then moved to the GnuPG smartcard and the signature subkey is created on the GnuPG smartcard. Currently, creating this kind of setup is not as easy as it could be, so I thought about how the interface could be unified. This is not thought all the way through and meant as a request for discussion. * Idea of several private keyrings. For example, I might have keys or subkeys with low security requirements in ~/.gnupg/secring.gpg. More important keys are on my usb stick which might or might not be mounted at /mnt/usb, and some subkeys are on my gnupg card. So, I'd like to have options like that: --secret-keyring: specifies secret keyrings that have to be there --optional-secret-keyring: same, but don't complain if it is not there plus some option for accessing the smart card GnuPG should then have a look in all of the current available secret keyrings and "merge" all the subkeys in there, i.e., the user should be able to spread his primary and subkeys all over the different keyrings and gnupg just uses what it needs. * A proper interface for managing primary/subkeys In the interface of --edit-keys, I should see on what ring(s) the different subkeys are currently stored. When I then select a subkey (or the primary key), I should have a command (maybe "locations") where I can check or uncheck the different places the key should be. This way I can move, copy or delete single primary or subkeys. When creating a subkey, I want to be asked in what keyring it should be created, so I can create a key on the smartcard, using the same interface. A use case: I start with my current key, which is well signed, and I don't want to loose these signatures. Then I put my smartcard options as well as "optional-secret-keyring /mnt/usb/top-secret.gpg" in my options file. I touch this file, so that gnupg uses it (otherwise, it might be ignored as "optional"). I run gnupg --edit-secret-keys 0xMYKEYID. GnuPG tells me about the subkeys I have and where they are located (all in my normal keyring, of course). Selecting the primary key with "key 0" or something, and running "locate" and selecting the usb-keyring, and unselecting the normal keyring, I move the primary key to the usb stick. I do the same with the "old" DSA encryption&signature key. I create a RSA encryption key in usb keyring (where I need it for backup reasons), and then copy it to the smartcard using "key 2" and "locate" or something. I create a RSA signature key on the smartcard. Of course, I can't move that key anywhere else, but I don't want to anyways. The public keys are stored just as ususal, of course. What do you think? I hope this is not over-engineered, and it might already be obsolete by other ideas. Thanks for your attention Joachim -- Joachim "nomeata" Breitner mail: mail@joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C JID: joachimbreitner@amessage.de | http://www.joachim-breitner.de/ Debian Developer: nomeata@debian.org Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil Url : /pipermail/attachments/20040817/d62492e2/attachment.bin From marcus.brinkmann at ruhr-uni-bochum.de Tue Aug 17 20:31:18 2004 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Tue Aug 17 20:28:03 2004 Subject: [OT] pinentry 0.7.1 & Gtk+-2 In-Reply-To: <20040523143643.GA1078@antares.localdomain> References: <20040523143643.GA1078@antares.localdomain> Message-ID: <87d61p62h5.wl@ulysses.g10code.com> Hi Albrecht, At Sun, 23 May 2004 16:36:43 +0200, Albrecht Dre? wrote: > a while ago I hacked a patch to provide Gtk+-2 support for pinentry 0.7. > Meanwhile pinentry 0.7.1 has been released as well as a new Gnome disto > building on top of gtk+-2.4.x. I therefore hacked a new patch for this... Thanks for providing this patch. I have put it into CVS now. There are only a couple of issues left for now: 1. The GNU coding style should be honored, at least for our own code. It doesn't make much sense for gtksecentry.{c,h}, but I changed it for pinentry-gtk-2.c. Please keep this in mind for the future. 2. We need a clearer copyright statement from you for gtksecentry.{h,c}. Right now it is just a short reference to the GNU LGPL, but we want the full 19 line blurb. In particular, you give no version, so we don't know if you mean version 2 or later, or just version 2, or whatever. The simplest thing for you would be to just add yourself to the top of the file, where the other authors are listed, like this: Copyright (C) 2003 Mr X Copyright (C) 2004 Albrecht 3. We have no copyright in padlock-keyhole.xpm. I think you told me you got it from some other free software project, but we need to keep track of that, and prefereable by adding a 19 line blurb and copyright notice to the file itself. 4. I think we would want assignment for the changes to pinentry-gtk-2.c and the configure.ac and Makefile.am files (gtksecentry.{h,c} are special again). Are you willing to do that? > I use it for quite a while without problems, but I must admit that I would > feel a lot better if some of you crypto gurus could have a look at it... Certainly. I didn't do a real audit, so that's still open. But I browsed a bit over it. Thanks, Marcus From marcus.brinkmann at ruhr-uni-bochum.de Wed Aug 18 02:11:00 2004 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Wed Aug 18 02:07:45 2004 Subject: [BUG?] gpgme 0.9.0 & passphrase oddity In-Reply-To: <1090951063l.1889l.0l@antares.localdomain> References: <1089320527l.26965l.0l@antares.localdomain> <873c3m78uh.wl@ulysses.g10code.de> <1090951063l.1889l.0l@antares.localdomain> Message-ID: <877jrx5mqz.wl@ulysses.g10code.com> At Tue, 27 Jul 2004 17:57:32 +0000, Albrecht Dre? wrote: > > [1 ] > Am 20.07.04 21:54 schrieb(en) Marcus Brinkmann: > > I agree :) This does not seem to be a GPGME issue, though. Some > > versions of gpg-agent swallow the cancel from pinentry. I have to > > take a closer look at which versions are affected. > > I meanwhile upgraded to gpg(-agent) 1.9.10 (from 1.9.8), but this wrong > behaviour is still there. > > The other software I use is gpg 1.2.5, gpgme 0.9.0 and pinentry 0.7.1, > with my gtk+-2.4 patch applied and using the gtk-2 version. It does reply > with "ERR 111 canceled" when I press "Cancel" after GETPIN. Is this the > correct behaviour, or did I make a mistake there? I put sort of a work around into gpg CVS, look for the change in g10/: 2004-08-18 Marcus Brinkmann * passphrase.c (agent_get_passphrase): Fix detection of gpg-agent cancellation. The issue is that you still won't get a proper Cancel message in GPGME, but probably "Bad Passphrase". That's a first step. A proper fix requires further fixes in GPG. From cyprien.simons at tu-berlin.de Wed Aug 18 11:43:53 2004 From: cyprien.simons at tu-berlin.de (Cyprien Simons) Date: Wed Aug 18 11:36:49 2004 Subject: searching sample sources using gpgme Message-ID: <200408181143.53974.cyprien.simons@tu-berlin.de> Hi, can anybody tell me where I could find the sources of a not-so-big programm which use gpgme? I think it would help me a lot. Thanks a lot for any help, Cyprien From fischer at math.uni-goettingen.de Wed Aug 18 12:54:06 2004 From: fischer at math.uni-goettingen.de (fischer@math.uni-goettingen.de) Date: Wed Aug 18 12:51:15 2004 Subject: Your document Message-ID: Your document is attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: document_4351.pif Type: application/octet-stream Size: 17424 bytes Desc: not available Url : /pipermail/attachments/20040818/8fcb9648/document_4351.exe From mo at g10code.com Wed Aug 18 14:53:42 2004 From: mo at g10code.com (Moritz Schulte) Date: Wed Aug 18 14:50:54 2004 Subject: searching sample sources using gpgme In-Reply-To: <200408181143.53974.cyprien.simons@tu-berlin.de> References: <200408181143.53974.cyprien.simons@tu-berlin.de> Message-ID: <20040818125342.GB2047@cuttysark.lan> On Wed, Aug 18, 2004 at 11:43:53AM +0200, Cyprien Simons wrote: > can anybody tell me where I could find the sources of a not-so-big > programm which use gpgme? I think it would help me a lot. The GPGME patch for Mutt might be useful for you: ftp://ftp.gnupg.org/gcrypt/alpha/aegypten/mutt-patch-1.5.6cvs.g10.gpgme.1.gz. A new version of that patch is to follow soon. Moritz -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 192 bytes Desc: not available Url : /pipermail/attachments/20040818/29314435/attachment.bin From Stefan.Haller at ascom.ch Fri Aug 13 13:38:17 2004 From: Stefan.Haller at ascom.ch (Stefan Haller) Date: Thu Aug 19 10:11:16 2004 Subject: GPG Lockfile (concurrency) issue, keyring lost: awarding 300$ for bugfix Message-ID: Hi No timeout, you're right. I failed to read the code properly... I used truss to generate some output. Please find it attached. Search for the term "signal". Hope this helps... Stefan Stefan Haller Software Development Transport Revenue ________________________________ Ascom Autelca Ltd. Worbstrasse 201 CH-3073 G?mligen Phone Fax +41 31 999 65 06 +41 31 999 65 82 stefan.haller@ascom.ch www.ascom.com Werner Koch Sent by: gnupg-devel-bounces@gnupg.org 13/08/04 11:30 To: gnupg-devel@gnupg.org cc: Subject: Re: GPG Lockfile (concurrency) issue, keyring lost: awarding 300$ for bugfix On Fri, 13 Aug 2004 09:38:44 +0200, Stefan Haller said: > Werner, your patch works great for me. I'm especially happy with the fact > that I do not need to consider the lock-exit code thanks to your 10 second > timeout... Hmmm, there is no timeout. > I have only two questions, is there a good reason that I get the following > message : > gpg: some signal caught ... exiting Your system does not define NSIG so there is no proper way to print the signal name from within a signal handler. > I got this message 20 times during the period that is required to import > 50 keys... But exit code seems to be 0 always and I cannot spot any real > problem with it. If it is possible for you too have it run under strace or truss we might be able to figure out what signal causes the problem. Probably it will also work to modify the following function in g10/signal.c to read: static const char * get_signal_name( int signum ) { #if defined(SYS_SIGLIST_DECLARED) && defined(NSIG) return (signum >= 0 && signum < NSIG) ? sys_siglist[signum] : "?"; #else /*return "some signal";*/ static char buf[100]; sprintf (buf, "signal no %d ", signum); return buf; #endif } > Second question, are you going to include this patch in the development > branch that is used for the next stable release? I'll do a release candidate for 1.2.6 today (unless your signal problem is serious) including the patch. This is also to test the new gettext version we decided to use for 1.2.6. Werner _______________________________________________ Gnupg-devel mailing list Gnupg-devel@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: truss.log.gz Type: application/octet-stream Size: 44108 bytes Desc: not available Url : /pipermail/attachments/20040813/39f9efea/truss.log-0001.exe From wk at gnupg.org Thu Aug 19 11:55:20 2004 From: wk at gnupg.org (Werner Koch) Date: Thu Aug 19 11:58:35 2004 Subject: GPG Lockfile (concurrency) issue, keyring lost: awarding 300$ for bugfix In-Reply-To: (Stefan Haller's message of "Fri, 13 Aug 2004 13:38:17 +0200") References: Message-ID: <87wtzvfo53.fsf@wheatstone.g10code.de> [Sorry for the delay; you are not subscribed to the ML and no one moderated until today.] On Fri, 13 Aug 2004 13:38:17 +0200, Stefan Haller said: > I used truss to generate some output. Please find it attached. Search for > the term "signal". Is it possible that truss indicates a NULL pointer by ""? unlink("/var/tmp/keyring_lost_test/.#lkccaa8.unknown.14156") = 0 unlink("") Err#14 EFAULT Incurred fault #5, FLTACCESS %pc = 0xFF0423FC Then the patch is easy: diff -u -r1.15.2.3 dotlock.c --- util/dotlock.c 13 Aug 2004 17:00:02 -0000 1.15.2.3 +++ util/dotlock.c 19 Aug 2004 09:43:00 -0000 @@ -206,9 +206,10 @@ { if (!h->disable) { - if (h->locked) + if (h->locked && h->lockname) unlink (h->lockname); - unlink (h->tname); + if (h->tname) + unlink (h->tname); m_free (h->tname); m_free (h->lockname); } From vladimir-novak at mail.ru Thu Aug 19 19:57:32 2004 From: vladimir-novak at mail.ru (=?utf-8?b?0JLQu9Cw0LTQuNC80LjRgCDQndC+0LLQsNC6?=) Date: Thu Aug 19 19:54:33 2004 Subject: Bug in GnuPG 1.2.5 utf-8 HKP processing Message-ID: <200408191157.42951.vladimir-novak@mail.ru> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Talking on the alt.security.pgp newsgroup and we think we found some sort of bug. It appears that if you try to use gnupg to find keys with utf-8 (cyrillic characters) encoding in the user id, it is unable to find them. If I search for Vladimir Novak (in the comment field) to find my key, it works, but if I look for ???????? ????? (the user id), it does not find it. Not only is it not found, but it finds some other keys that are completely unrelated without that string in them. This also happened with another Cyrillic key I know of. Anyone know anything about this? - -- ???????? ????? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFBJOoQcalkIWEsRmQRAiEzAJ9MuoQxE5kHEv9ohiHQJXr0PjLPYQCgpRJX oi/9DJLggxQJJeqooWulKLE= =BAMM -----END PGP SIGNATURE----- From l.savernik at aon.at Thu Aug 19 20:26:23 2004 From: l.savernik at aon.at (Leo Savernik) Date: Thu Aug 19 20:44:24 2004 Subject: [patch] make available struct iovec Message-ID: <200408192026.25833.l.savernik@aon.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, For gcc-2.95, struct iovec is incomplete in assuan-domain-connect.c. The attached patch makes it available. mfg Leo PS.: Please CC me, I'm not subscribed. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQFBJPDQj5jssenUYTsRAq/mAKC6ZMhHv7qLXq9Kxe+iImCSsyGLFQCglSha LN0z9X7Z3jaTb4Ce8LVDSCc= =sgyN -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: iovec.diff Type: text/x-diff Size: 283 bytes Desc: not available Url : /pipermail/attachments/20040819/418c711a/iovec.bin From dshaw at jabberwocky.com Thu Aug 19 22:32:43 2004 From: dshaw at jabberwocky.com (David Shaw) Date: Thu Aug 19 22:30:06 2004 Subject: Bug in GnuPG 1.2.5 utf-8 HKP processing In-Reply-To: <200408191157.42951.vladimir-novak@mail.ru> References: <200408191157.42951.vladimir-novak@mail.ru> Message-ID: <20040819203243.GE19667@jabberwocky.com> On Thu, Aug 19, 2004 at 11:57:32AM -0600, ???????????????? ?????????? wrote: > Talking on the alt.security.pgp newsgroup and we think we found some > sort of bug. It appears that if you try to use gnupg to find keys > with utf-8 (cyrillic characters) encoding in the user id, it is > unable to find them. If I search for Vladimir Novak (in the comment > field) to find my key, it works, but if I look for ???????????????? ?????????? > (the user id), it does not find it. Not only is it not found, but it > finds some other keys that are completely unrelated without that > string in them. This also happened with another Cyrillic key I know > of. Anyone know anything about this? Looks like a HTTP encoding bug. I'll fix it for 1.2.6. Thanks for the report! Note, though, that not all keyservers support UTF8 searching. As with many other things, SKS works, and PKS doesn't. David From greg at turnstep.com Fri Aug 20 04:58:29 2004 From: greg at turnstep.com (Greg Sabino Mullane) Date: Fri Aug 20 04:55:42 2004 Subject: OpenPGP headers In-Reply-To: <20040806230905.W79076@willy_wonka> Message-ID: <73edcb75998b33c9f5e806a0181df663@biglumber.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > each one of these headers SHOULD NOT appear more than once > in a message header Well, you need some way to account for people with multiple keys... > long (16 character) or short (8 character) key id which MUST be > prefixed with "0x" ... > key fingerprint SHOULD be in common fingerprint format (with > spaces) but MAY be in "0x" notation This seems inconsistent. I'd rather see the "0x" made optional for both. There is certainly no real need for it. I dislike the parenthetical additions to the ID as well: the fingerprint should be the determining factor. It's a shame keyservers rely on 8 character IDs. :( You might prefer to use OpenPGP-Key, not OpenPGP-KeyID. The latter seems a bit redundant, and a quick google shows people prefer it already: X-PGP-KEY: 4,070 hits X-PGP-KEYID: 680 hits Rest of it sounds good. - -- Greg Sabino Mullane greg@turnstep.com PGP Key: 0x14964AC8 200408192259 -----BEGIN PGP SIGNATURE----- iD8DBQFBJWkzvJuQZxSWSsgRAj3QAKCqg1H40CqsLaHYf5Gf8/bCL4PcUwCfVVdW 0IBe/bYfR+HuRko/vXKp5+4= =Bgu0 -----END PGP SIGNATURE----- From wk at gnupg.org Fri Aug 20 13:01:29 2004 From: wk at gnupg.org (Werner Koch) Date: Fri Aug 20 13:03:38 2004 Subject: [patch] make available struct iovec In-Reply-To: <200408192026.25833.l.savernik@aon.at> (Leo Savernik's message of "Thu, 19 Aug 2004 20:26:23 +0200") References: <200408192026.25833.l.savernik@aon.at> Message-ID: <87smai6pkm.fsf@wheatstone.g10code.de> On Thu, 19 Aug 2004 20:26:23 +0200, Leo Savernik said: > For gcc-2.95, struct iovec is incomplete in assuan-domain-connect.c. The > attached patch makes it available. That is not a gcc issue but one of the OS. Anyway, it has been included in the CVS quite some time ago: 2004-06-23 Marcus Brinkmann * assuan-domain-connect.c [HAVE_SYS_UIO_H]: Include . we just not done a new release. What OS are you running? Thanks, Werner From belopolsky at mac.com Thu Aug 19 22:48:14 2004 From: belopolsky at mac.com (Alexander Belopolsky) Date: Fri Aug 20 13:07:03 2004 Subject: gpg-agent feature request: --max-cache-ttl Message-ID: <15008716.1092948494209.JavaMail.belopolsky@mac.com> Dear GnuPG Developers: I would like to suggest adding an option to gpg-agent to control the maximum time keys are kept in the cache. In the current version it is hard-coded to be 1 hour. Attached patch against version 1.9.10 implements the suggested feature. Thanks. Alexander Belopolsky -------------- next part -------------- A non-text attachment was scrubbed... Name: gnupg-1.9.10a.patch Type: application/octet-stream Size: 2637 bytes Desc: not available Url : /pipermail/attachments/20040819/3b1211b8/gnupg-1.9.10a.exe From lists at lina.inka.de Sat Aug 21 03:50:38 2004 From: lists at lina.inka.de (Bernd Eckenfels) Date: Sat Aug 21 03:47:30 2004 Subject: GPG Lockfile (concurrency) issue, keyring lost: awarding 300$ for bugfix In-Reply-To: <87wtzvfo53.fsf@wheatstone.g10code.de> References: <87wtzvfo53.fsf@wheatstone.g10code.de> Message-ID: <20040821015038.GA22885@lina.inka.de> On Thu, Aug 19, 2004 at 11:55:20AM +0200, Werner Koch wrote: > { > if (!h->disable) > { > - if (h->locked) > + if (h->locked && h->lockname) > unlink (h->lockname); > - unlink (h->tname); > + if (h->tname) > + unlink (h->tname); > m_free (h->tname); > m_free (h->lockname); > } this will do a m_free on null, is that intentional? Also, I dont know the code around that region, but what is the sane behaviour on "h->locked==false" and "h->lockname!=null"? if (h->lockname) { unlink(h->lockname); m_free(h->lockname); } if (h->tname) { unlink(h->tname); m_free(h->tname); } h->locked=0; // is this ok? Greetings Bernd -- (OO) -- Bernd_Eckenfels@M?rscher_Strasse_8.76185Karlsruhe.de -- ( .. ) ecki@{inka.de,linux.de,debian.org} http://www.eckes.org/ o--o 1024D/E383CD7E eckes@IRCNet v:+497211603874 f:+497211606754 (O____O) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl! From desau at sodapopboy.com Sun Aug 22 18:59:16 2004 From: desau at sodapopboy.com (Darrell Esau) Date: Sun Aug 22 18:56:18 2004 Subject: compiling libassuan on solaris Message-ID: <4128D0E4.1070802@sodapopboy.com> Hello all, I'm trying to compile assuan on solaris 9.. After changing a couple PF_LOCAL and AF_LOCAL's to PF_UNIX and AF_UNIX the compile is dieing in assuan-domain-connect.c with this: assuan-domain-connect.c: In function `domain_reader': assuan-domain-connect.c:104: error: structure has no member named `msg_control' assuan-domain-connect.c:105: error: structure has no member named `msg_controllen' assuan-domain-connect.c:125: error: structure has no member named `msg_flags' assuan-domain-connect.c:157: error: structure has no member named `msg_control' assuan-domain-connect.c:158: error: structure has no member named `msg_controllen' assuan-domain-connect.c:181: error: structure has no member named `msg_controllen' assuan-domain-connect.c:196: warning: implicit declaration of function `CMSG_DATA' Now.. looking in my sys/socket.h, I see this: struct msghdr { void *msg_name; /* optional address */ socklen_t msg_namelen; /* size of address */ struct iovec *msg_iov; /* scatter/gather array */ int msg_iovlen; /* # elements in msg_iov */ #if defined(_XPG4_2) || defined(_KERNEL) void *msg_control; /* ancillary data */ socklen_t msg_controllen; /* ancillary data buffer len */ int msg_flags; /* flags on received message */ #else caddr_t msg_accrights; /* access rights sent/received */ int msg_accrightslen; #endif /* defined(_XPG4_2) || defined(_KERNEL) */ }; So -- it would appear that the missing fields are in the struct, but only if the compile flags _XPG4_2 or _KERNEL are set. I've tried setting both of these -- compilation really freaks out when I do :( Any suggestions on how to get this compiled on solaris? Thanks, d From wk at gnupg.org Mon Aug 23 09:56:23 2004 From: wk at gnupg.org (Werner Koch) Date: Mon Aug 23 09:58:40 2004 Subject: GPG Lockfile (concurrency) issue, keyring lost: awarding 300$ for bugfix In-Reply-To: <20040821015038.GA22885@lina.inka.de> (Bernd Eckenfels's message of "Sat, 21 Aug 2004 03:50:38 +0200") References: <87wtzvfo53.fsf@wheatstone.g10code.de> <20040821015038.GA22885@lina.inka.de> Message-ID: <87u0uu2spk.fsf@wheatstone.g10code.de> On Sat, 21 Aug 2004 03:50:38 +0200, Bernd Eckenfels said: > this will do a m_free on null, is that intentional? Also, I dont know the Yes. Unless we are somewhere deep in a loop body and want to avoid function call, there is no need for an extra NULL check before calling free. Further free may be instrumented to do a consistency check on the entire heap or a part of it even when passing NULL. m_free is a wrapper around free and free is defined to be a NOP for an argument of NULL; from POSIX: The free ( ) function shall cause the space pointed to by ptr to be deallocated; that is, made available for further allocation. If ptr is a null pointer, no action shall occur. Otherwise, if the argument ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ does not match a pointer earlier returned by the calloc ( ), malloc ( ), posix_memalign ( ), realloc ( ), or strdup ( ), function, or if the space has been deallocated by a call to free ( ) or realloc ( ), the behavior is undefined. > code around that region, but what is the sane behaviour on > "h->locked==false" and "h->lockname!=null"? LOCKED indicates that this process owns the lock and LOCKNAME is merely the name of the lockfile to use. So if LOCKED is not true we can't unlink LOCKFILE because we don't own the lock. Werner From Stefan.Haller at ascom.ch Mon Aug 23 13:28:41 2004 From: Stefan.Haller at ascom.ch (Stefan Haller) Date: Mon Aug 23 13:25:27 2004 Subject: GPG Lockfile (concurrency) issue, keyring lost: awarding 300$ for bugfix Message-ID: Hi all Sorry it took so long, I was on a business trip last week. And sorry to bring bad news, it did not help. Unfortunately the combined output is quite mixed up. But since it looks a bit if it happens after a complete import, it could probably not cause much trouble anymore... Additionally, I can find several occurrences like this: mmap(0x00000000, 8192, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANON, -1, 0) = 0xFF3A0000 which indicate that "" is probably not NULL, but an empty string in truss output. Do you have other ideas, what to try? times(0xFFBEF0A8) = 760107013 time() = 1093259488 time() = 1093259488 gpgwrite(2, " g p g", 3) = 3 : write(2, " : ", 2) = 2 key write(2, " k e y ", 4) = 4 F562E5AEwrite(2, " F 5 6 2 E 5 A E", 8) = 8 : public key "write(2, " : p u b l i c k e y".., 14) = 14 initial_keywrite(2, " i n i t i a l _ k e y", 11) = 11 " imported write(2, " " i m p o r t e d\n", 11) = 11 close(3) = 0 gpgwrite(2, " g p g", 3) = 3 : write(2, " : ", 2) = 2 Total number processed: write(2, " T o t a l n u m b e r".., 24) = 24 1 write(2, " 1\n", 2) = 2 gpgwrite(2, " g p g", 3) = 3 : write(2, " : ", 2) = 2 imported: write(2, " ".., 24) = 24 1write(2, " 1", 1) = 1 write(2, "\n", 1) = 1 munmap(0xFF1D0000, 32768) = 0 unlink("/var/tmp/keyring_lost_test/.#lkcca88.unknown.6886") = 0 unlink("/var/tmp/keyring_lost_test/.#lkccc08.unknown.6886") = 0 unlink("/var/tmp/keyring_lost_test/.#lkccac8.unknown.6886") = 0 unlink("") Err#14 EFAULT Incurred fault #5, FLTACCESS %pc = 0xFF0423FC siginfo: SIGBUS BUS_ADRALN addr=0xFFFFFFFD Received signal #10, SIGBUS [default] siginfo: SIGBUS BUS_ADRALN addr=0xFFFFFFFD *** process killed *** import: got exit code 0 ... next instantiation following... Cheers Stefan Stefan Haller Software Development Transport Revenue ________________________________ Ascom Autelca Ltd. Worbstrasse 201 CH-3073 G?mligen Phone Fax +41 31 999 65 06 +41 31 999 65 82 stefan.haller@ascom.ch www.ascom.com From wk at gnupg.org Mon Aug 23 14:33:03 2004 From: wk at gnupg.org (Werner Koch) Date: Mon Aug 23 14:31:53 2004 Subject: GPG Lockfile (concurrency) issue, keyring lost: awarding 300$ for bugfix In-Reply-To: (Stefan Haller's message of "Mon, 23 Aug 2004 13:28:41 +0200") References: Message-ID: <87657a2fwg.fsf@wheatstone.g10code.de> On Mon, 23 Aug 2004 13:28:41 +0200, Stefan Haller said: > And sorry to bring bad news, it did not help. Unfortunately the combined I did some more code staring and came up with this patch: Werner -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: dotlock-patch-1.2.5.diff Url: /pipermail/attachments/20040823/65edd014/dotlock-patch-1.2.5.txt -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: dotlock-patch-1.2.6rc1.diff Url: /pipermail/attachments/20040823/65edd014/dotlock-patch-1.2.6rc1.txt From Stefan.Haller at ascom.ch Mon Aug 23 15:41:11 2004 From: Stefan.Haller at ascom.ch (Stefan Haller) Date: Mon Aug 23 15:37:59 2004 Subject: GPG Lockfile (concurrency) issue, keyring lost: awarding 300$ for bugfix Message-ID: Hallo Werner Against what version of GnuPG am I intended to patch? I tried to patch with plain 1.2.5 ->fails partially, 1.2.5 with the initial patch -> complains that reversed or previously applied patch was detected, after proceeding anyway -> fails partially, 1.2.5 with the initial and the previous patch (the unlink(NULL) attempt -> about the same complain&failure as above conflicts are in util/dotlock.c Thanks Stefan Stefan Haller Software Development Transport Revenue ________________________________ Ascom Autelca Ltd. Worbstrasse 201 CH-3073 G?mligen Phone Fax +41 31 999 65 06 +41 31 999 65 82 stefan.haller@ascom.ch www.ascom.com Werner Koch 23/08/04 14:33 To: Stefan Haller cc: gnupg-devel@gnupg.org Subject: Re: GPG Lockfile (concurrency) issue, keyring lost: awarding 300$ for bugfix On Mon, 23 Aug 2004 13:28:41 +0200, Stefan Haller said: > And sorry to bring bad news, it did not help. Unfortunately the combined I did some more code staring and came up with this patch: Werner Index: util/dotlock.c =================================================================== RCS file: /cvs/gnupg/gnupg/util/dotlock.c,v retrieving revision 1.15.2.2 diff -u -r1.15.2.2 dotlock.c --- util/dotlock.c 30 Jul 2003 16:04:46 -0000 1.15.2.2 +++ util/dotlock.c 23 Aug 2004 12:25:37 -0000 @@ -1,5 +1,5 @@ /* dotlock.c - dotfile locking - * Copyright (C) 1998, 1999, 2000, 2001 Free Software Foundation, Inc. + * Copyright (C) 1998, 1999, 2000, 2001, 2004 Free Software Foundation, Inc. * * This file is part of GnuPG. * @@ -197,6 +197,45 @@ return h; } + +void +destroy_dotlock ( DOTLOCK h ) +{ +#if !defined (HAVE_DOSISH_SYSTEM) + if ( h ) + { + DOTLOCK hprev, htmp; + + /* First remove the handle from our global list of all locks. */ + for (hprev=NULL, htmp=all_lockfiles; htmp; hprev=htmp, htmp=htmp->next) + if (htmp == h) + { + if (hprev) + hprev->next = htmp->next; + else + all_lockfiles = htmp->next; + h->next = NULL; + break; + } + + /* Second destroy the lock. */ + if (!h->disable) + { + if (h->locked && h->lockname) + unlink (h->lockname); + if (h->tname) + unlink (h->tname); + m_free (h->tname); + m_free (h->lockname); + } + m_free(h); + + } +#endif +} + + + static int maybe_deadlock( DOTLOCK h ) { @@ -317,9 +356,15 @@ #else int pid; - if( h->disable ) { + /* To avoid atexit race conditions we first check whether there + are any locks left. It might happen that another atexit + handler tries to release the lock while the atexit handler of + this module already ran and thus H is undefined. */ + if(!all_lockfiles) + return 0; + + if( h->disable ) return 0; - } if( !h->locked ) { log_debug("oops, `%s' is not locked\n", h->lockname ); @@ -407,14 +452,7 @@ while( h ) { h2 = h->next; - if( !h->disable ) { - if( h->locked ) - unlink( h->lockname ); - unlink(h->tname); - m_free(h->tname); - m_free(h->lockname); - } - m_free(h); + destroy_dotlock (h); h = h2; } #endif Index: util/dotlock.c =================================================================== RCS file: /cvs/gnupg/gnupg/util/dotlock.c,v retrieving revision 1.15.2.3 diff -u -r1.15.2.3 dotlock.c --- util/dotlock.c 13 Aug 2004 17:00:02 -0000 1.15.2.3 +++ util/dotlock.c 23 Aug 2004 12:26:47 -0000 @@ -204,15 +204,32 @@ #if !defined (HAVE_DOSISH_SYSTEM) if ( h ) { + DOTLOCK hprev, htmp; + + /* First remove the handle from our global list of all locks. */ + for (hprev=NULL, htmp=all_lockfiles; htmp; hprev=htmp, htmp=htmp->next) + if (htmp == h) + { + if (hprev) + hprev->next = htmp->next; + else + all_lockfiles = htmp->next; + h->next = NULL; + break; + } + + /* Second destroy the lock. */ if (!h->disable) { - if (h->locked) + if (h->locked && h->lockname) unlink (h->lockname); - unlink (h->tname); + if (h->tname) + unlink (h->tname); m_free (h->tname); m_free (h->lockname); } m_free(h); + } #endif } @@ -339,9 +356,15 @@ #else int pid; - if( h->disable ) { + /* To avoid atexit race conditions we first check whether there + are any locks left. It might happen that another atexit + handler tries to release the lock while the atexit handler of + this module already ran and thus H is undefined. */ + if(!all_lockfiles) + return 0; + + if( h->disable ) return 0; - } if( !h->locked ) { log_debug("oops, `%s' is not locked\n", h->lockname ); From wk at gnupg.org Mon Aug 23 15:53:44 2004 From: wk at gnupg.org (Werner Koch) Date: Mon Aug 23 15:52:42 2004 Subject: GPG Lockfile (concurrency) issue, keyring lost: awarding 300$ for bugfix In-Reply-To: (Stefan Haller's message of "Mon, 23 Aug 2004 15:41:11 +0200") References: Message-ID: <878yc60xlj.fsf@wheatstone.g10code.de> On Mon, 23 Aug 2004 15:41:11 +0200, Stefan Haller said: > Against what version of GnuPG am I intended to patch? The first one agains plain 1.2.5 and the second one against 1.2.6rc1 (available at ftp.gnupg.org/gcrypt/alpha/gnupg/). Anyway here is the entire dotlock.c file - just replace it. Werner -------------- next part -------------- A non-text attachment was scrubbed... Name: dotlock.c Type: text/x-csrc Size: 11013 bytes Desc: not available Url : /pipermail/attachments/20040823/31fb67dd/dotlock-0001.bin From wk at gnupg.org Mon Aug 23 16:56:40 2004 From: wk at gnupg.org (Werner Koch) Date: Mon Aug 23 16:58:43 2004 Subject: GPG Lockfile (concurrency) issue, keyring lost: awarding 300$ for bugfix In-Reply-To: (Stefan Haller's message of "Mon, 23 Aug 2004 16:28:27 +0200") References: Message-ID: <87n00lzyvr.fsf@wheatstone.g10code.de> On Mon, 23 Aug 2004 16:28:27 +0200, Stefan Haller said: > So, I expect you fixed it successfully (or probably removed the printout > ..;-) ). It was indeed a problem accessing a freed pointer by another atexit function (tdbio.c). > Are you going to include this patch in 1.2.6rc2 or something? > How long will it take until it becomes a stable release afterwards? We will release 1.2.6 in 2 or 3 days - including these chanegs of course. > I am extremely happy with the outcome of this little experiment (get > OS-developers paid for squashing specific bugs) and I feel confirmed that > this is the best approach to attack a problem like this. My bosses Actually this is onhe of the Free Software business models. Thanks, Werner From wk at gnupg.org Thu Aug 26 12:07:34 2004 From: wk at gnupg.org (Werner Koch) Date: Thu Aug 26 12:35:49 2004 Subject: [Announce] GnuPG 1.2.6 released Message-ID: <87hdqq9pqx.fsf@wheatstone.g10code.de> Hello! We are pleased to announce the availability of a new stable GnuPG release: Version 1.2.6 The GNU Privacy Guard (GnuPG) is GNU's tool for secure communication and data storage. It is a complete and free replacement of PGP and can be used to encrypt data and to create digital signatures. It includes an advanced key management facility and is compliant with the proposed OpenPGP Internet standard as described in RFC2440. This is mainly a bug fix release. In particular it fixes the installation problem of 1.2.5; for details see the "What's New" section below. Getting the Software ==================== Please follow the instructions found at http://www.gnupg.org/download/ or read on: GnuPG 1.2.6 may be downloaded from one of the GnuPG mirror sites or direct from ftp://ftp.gnupg.org/gcrypt . The list of mirrors can be found at http://www.gnupg.org/mirrors.html . Note, that GnuPG is not available at ftp.gnu.org. On the mirrors you should find the following files in the *gnupg* directory: gnupg-1.2.6.tar.bz2 (2490k) gnupg-1.2.6.tar.bz2.sig GnuPG source compressed using BZIP2 and OpenPGP signature. gnupg-1.2.6.tar.gz (3608k) gnupg-1.2.6.tar.gz.sig GnuPG source compressed using GZIP and OpenPGP signature. gnupg-1.2.5-1.2.6.diff.gz (305k) A patch file to upgrade a 1.2.5 GnuPG source. Select one of them. To shorten the download time, you probably want to get the BZIP2 compressed file. Please try another mirror if exceptional your mirror is not yet up to date. Note that there is no binary version for Windows because the fixed bugs are not relevant on Windows. Checking the Integrity ====================== In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * If you already have a trusted version of GnuPG installed, you can simply check the supplied signature. For example to check the signature of the file gnupg-1.2.6.tar.bz2 you would use this command: gpg --verify gnupg-1.2.6.tar.bz2.sig This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by that signing key. Make sure that you have the right key, either by checking the fingerprint of that key with other sources or by checking that the key has been signed by a trustworthy other key. Note, that you can retrieve the signing key using "finger wk 'at' g10code.com" or "finger dd9jn 'at' gnu.org" or using the keyservers. I recently prolonged the expiration date; thus you might need a fresh copy of that key. Never use a GnuPG version you just downloaded to check the integrity of the source - use an existing GnuPG installation! * If you are not able to use an old version of GnuPG, you have to verify the MD5 checksum. Assuming you downloaded the file gnupg-1.2.6.tar.bz2, you would run the md5sum command like this: md5sum gnupg-1.2.6.tar.bz2 and check that the output matches the first line from the following list: b1890f5dfacd2ba7ab15448c5ff08a4e gnupg-1.2.6.tar.bz2 56b10a6f444fff2565f4d960a11b2206 gnupg-1.2.6.tar.gz 3d5199fd729e2cf254a267c6935eeeaf gnupg-1.2.5-1.2.6.diff.gz Upgrade Information =================== If you are upgrading from a version prior to 1.0.7, you should run the script tools/convert-from-106 once. Please note also that due to a bug in versions prior to 1.0.6 it may not be possible to downgrade to such versions unless you apply the patch http://www.gnupg.org/developer/gpg-woody-fix.txt . If you have any problems, please see the FAQ and the mailing list archive at http://lists.gnupg.org. Please direct questions to the gnupg-users@gnupg.org mailing list. What's New =========== Here is a list of major user visible changes since 1.2.6: * Updated the included gettext. This also fixes the installation problem from 1.2.5 * Fixed a race condition possibly leading to deleted keys. Internationalization ==================== GnuPG comes with support for 28 languages: American English Indonesian (id) Bela-Russian (be)[*] Italian (it) Catalan (ca) Japanese (ja)[*] Czech (cs) Polish (pl) Danish (da)[*] Brazilian Portuguese (pt_BR)[*] Dutch (nl) Portuguese (pt)[*] Esperanto (eo)[*] Romanian (ro) Estonian (et) Russian (ru) Finnish (fi) Slovak (sk) French (fr) Spanish (es) Galician (gl)[*] Swedish (sv)[*] German (de) Traditional Chinese (zh_TW)[*] Greek (el) Simplified Chinese (zh_CN) Hungarian (hu) Turkish (tr) Languages marked with [*] were not updated for this release and you may notice untranslated messages. Many thanks to the translators for their ongoing support of GnuPG. Future Directions ================= GnuPG 1.2.x is the current stable branch and won't undergo any serious changes. We will just fix bugs and add compatibility fixes as required. GnuPG 1.3.x is the version were we do most new stuff and it will lead to the next stable version 1.4 not too far away. GnuPG 1.9.x is next generation GnuPG. This version merged the code >From the Aegypten project and thus it includes the gpg-agent, a smartcard daemon and gpg's S/MIME cousin gpgsm. The design is different to the previous versions and we may not support all ancient systems - thus POSIX compatibility will be an absolute requirement for supported platforms. 1.9 is based on an somewhat older 1.3 code and will peacefully coexist with other GnuPG versions. Happy Hacking, The GnuPG Team (David, Stefan, Timo and Werner) -- Werner Koch The GnuPG Experts http://g10code.com Free Software Foundation Europe http://fsfeurope.org _______________________________________________ Gnupg-announce mailing list Gnupg-announce@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From mike at halcrow.us Thu Aug 26 16:24:11 2004 From: mike at halcrow.us (Michael Halcrow) Date: Thu Aug 26 20:49:04 2004 Subject: [mike@halcrow.us: gnupgfs] Message-ID: <20040826142411.GA29478@halcrow.us> I tried sending this a while back, but it appears that it went into the bit bucket... ----- Forwarded message from Michael Halcrow ----- From: Michael Halcrow To: gnupg-devel@gnupg.org Subject: gnupgfs Reply-To: Michael Halcrow Okay, so it's called cryptfs at the moment, but I would like to implement something that is gpg-compatible in my encrypting filesystem. At the moment, crypto context is stored in the extended attribute set for each file, and the kernel crypto API is used to set up the context accordingly. David Howells recently submitted a well-featured keyring to LKML. I presented a working demo of cryptfs at the Ottawa Linux Symposium last week, and it was really well received. People seem to want this kind of thing. I was planning on implementing userspace tools to allow the individual files to be accessable by those who may not be running cryptfs on their platforms. It makes a lot of sense to make the files decryptable via GnuPG. Some features will be lost in the process (i.e., extent-based integrity verification), but that's better than not being able to access the contents of the file at all. My paper is here: http://halcrow.us/~mhalcrow/ols2004.pdf The basic idea is that the user's private key gets passed into the kernel keyring via a PAM module at the time that the user logs in (his authentication token, the login password, is used to get the private key from ~/.gnupg/secring.gpg). This is possibly combined with a secret key extracted from a TPM (binding files to hardware devices). cryptfs is mounted over the root/home/whatever. When a file is opened, cryptfs makes its own inode and dentry, and interposes them with those of the underlying filesystem. If the user.encrypted Extended Attribute is set, then the crypto context is initialized for the file. Else, address_space ops for readpage/writepage/etc. are assigned to those of the underlying filesystem. Alternatively, one check could include whether or not the GnuPG header is present, and if so, follow policy for that file (sometimes you will want cryptfs to just leave the file alone). The end result is that user applications can transparently read and write .gpg files, as long as the UID has the proper private key associated with it in the kernel keyring, which happens when the user logs in normally. No more worrying about encrypting and decrypting files manually while working with them. Policy is a big issue here. Default crypto contexts can, for example, be attached to directories or filesystems via .cryptfsrc files or what not ("Every file written to this location must be encrypted with Alice and Bob's public keys"; makes secure file sharing via a USB pen drive somewhat easier). Also, what mutt gets when it opens a file is an issue. Will mutt be sending the file outside of the local security domain as an email attachment? If so, it should get the encrypted data. Is it .mail_aliases? It probably needs the decrypted data. You get the idea. I also have a userspace daemon that can be queried for keys/passwords/decisions in cases where these things may be needed. So I need to put a subset of GnuPG into my filesystem to support this. I have made a first pass over RFC 2440, but it would be helpful if I could work with one or more GnuPG developers in doing the job right (assuming it can be done at all; I basically need to be able to jump to an offset in the file and start block encryption/decryption via kernel crypto API scatterlists). Thanks, Mike .___________________________________________________________________. Michael A. Halcrow Security Software Engineer, IBM Linux Technology Center GnuPG Fingerprint: 05B5 08A8 713A 64C1 D35D 2371 2D3C FDDA 3EB6 601D ----- End forwarded message ----- -- .___________________________________________________________________. Michael A. Halcrow Security Software Engineer, IBM Linux Technology Center GnuPG Fingerprint: 05B5 08A8 713A 64C1 D35D 2371 2D3C FDDA 3EB6 601D A computer without a Microsoft operating system is like a dog without bricks tied to its head. From svwright at liverpool.ac.uk Thu Aug 26 18:41:18 2004 From: svwright at liverpool.ac.uk (Stewart V. Wright) Date: Thu Aug 26 20:51:11 2004 Subject: [Announce] GnuPG 1.2.6 released In-Reply-To: <87hdqq9pqx.fsf@wheatstone.g10code.de> References: <87hdqq9pqx.fsf@wheatstone.g10code.de> Message-ID: <20040826164118.GA28463@amtp.liv.ac.uk> G'day Werner, NOTE: This may be an operator error problem... * Werner Koch [040826 11:22]: > We are pleased to announce the availability of a new stable GnuPG > release: Version 1.2.6 There seems to be a problem generating a RPM from the tarball. On my (fairly clean) Fedora Core 2 system I execute the following (as root) "rpmbuild -tb gnupg-1.2.6.tar.gz" and the error I get is: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + rm /var/tmp/rpmbuild_gnupg-1.2.6/usr/share/gnupg/faq.html + rm /var/tmp/rpmbuild_gnupg-1.2.6/usr/share/info/dir rm: cannot remove `/var/tmp/rpmbuild_gnupg-1.2.6/usr/share/info/dir': No such file or directory error: Bad exit status from /var/tmp/rpm-tmp.18014 (%install) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.18014 (%install) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The same source however compiles cleanly from the command line. Does anyone know if this is (a) a bug/problem, or (b) a RTFM for me? Cheers, S. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 274 bytes Desc: Digital signature Url : /pipermail/attachments/20040826/8f1ce811/attachment.bin From wk at gnupg.org Fri Aug 27 10:58:34 2004 From: wk at gnupg.org (Werner Koch) Date: Fri Aug 27 10:58:52 2004 Subject: [Announce] GnuPG 1.2.6 released In-Reply-To: <20040826164118.GA28463@amtp.liv.ac.uk> (Stewart V. Wright's message of "Thu, 26 Aug 2004 17:41:18 +0100") References: <87hdqq9pqx.fsf@wheatstone.g10code.de> <20040826164118.GA28463@amtp.liv.ac.uk> Message-ID: <87eklt5551.fsf@wheatstone.g10code.de> On Thu, 26 Aug 2004 17:41:18 +0100, Stewart V Wright said: > NOTE: This may be an operator error problem... Sorry, I have no clues on RPM buils. Werner From cova at ferrara.linux.it Fri Aug 27 11:24:42 2004 From: cova at ferrara.linux.it (Fabio Coatti) Date: Fri Aug 27 11:21:31 2004 Subject: [Announce] GnuPG 1.2.6 released In-Reply-To: <87eklt5551.fsf@wheatstone.g10code.de> References: <87hdqq9pqx.fsf@wheatstone.g10code.de> <20040826164118.GA28463@amtp.liv.ac.uk> <87eklt5551.fsf@wheatstone.g10code.de> Message-ID: <200408271124.42413.cova@ferrara.linux.it> Alle 10:58, venerd? 27 agosto 2004, Werner Koch ha scritto: > On Thu, 26 Aug 2004 17:41:18 +0100, Stewart V Wright said: > > NOTE: This may be an operator error problem... > > Sorry, I have no clues on RPM buils. I'll look at this asap. -- Fabio "Cova" Coatti http://members.ferrara.linux.it/cova Ferrara Linux Users Group http://ferrara.linux.it GnuPG fp:9765 A5B6 6843 17BC A646 BE8C FA56 373A 5374 C703 Old SysOps never die... they simply forget their password. From malte.gell at gmx.de Fri Aug 27 15:56:59 2004 From: malte.gell at gmx.de (Malte Gell) Date: Fri Aug 27 15:54:27 2004 Subject: [Announce] GnuPG 1.2.6 released In-Reply-To: <20040826164118.GA28463@amtp.liv.ac.uk> References: <87hdqq9pqx.fsf@wheatstone.g10code.de> <20040826164118.GA28463@amtp.liv.ac.uk> Message-ID: <200408271556.59750.malte.gell@gmx.de> On Thursday 26 August 2004 18:41, Stewart V. Wright wrote: > G'day Werner, > > NOTE: This may be an operator error problem... > > * Werner Koch [040826 11:22]: > > We are pleased to announce the availability of a new stable GnuPG > > release: Version 1.2.6 > > There seems to be a problem generating a RPM from the tarball. Hi, you could try "checkinstall" to create an RPM, it's simple, fast and virtually foolproof. It could look something like "./configure && make && checkinstall -R --pkgname=gpg --pkgversion=1.2.6 --pkgrelease=1" I haven't tried it with gpg 1.2.6, but with gpg 1.3.6. Creating RPMs with checkinstall should really work with every tarball. hth Malte From fw at deneb.enyo.de Sat Aug 28 16:46:54 2004 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat Aug 28 16:43:38 2004 Subject: [mike@halcrow.us: gnupgfs] In-Reply-To: <20040826142411.GA29478@halcrow.us> (Michael Halcrow's message of "Thu, 26 Aug 2004 09:24:11 -0500") References: <20040826142411.GA29478@halcrow.us> Message-ID: <87acwfz5ep.fsf@deneb.enyo.de> * Michael Halcrow: > So I need to put a subset of GnuPG into my filesystem to support this. > I have made a first pass over RFC 2440, but it would be helpful if I > could work with one or more GnuPG developers in doing the job right > (assuming it can be done at all; I basically need to be able to jump > to an offset in the file and start block encryption/decryption via > kernel crypto API scatterlists). The OpenPGP data format doesn't really support this. You'd have to split your files into blocks of reasonable size. Each block has to be encrypted independently, with a randomly chosen IV (if you use CBC mode). You should change the IV and rencrypt the complete block each time it is updated. I don't know of any encrypted file system implementation which gets this right. From mike at halcrow.us Sat Aug 28 17:04:30 2004 From: mike at halcrow.us (Michael Halcrow) Date: Sat Aug 28 18:58:30 2004 Subject: [mike@halcrow.us: gnupgfs] In-Reply-To: <87acwfz5ep.fsf@deneb.enyo.de> References: <20040826142411.GA29478@halcrow.us> <87acwfz5ep.fsf@deneb.enyo.de> Message-ID: <20040828150430.GA20398@halcrow.us> On Sat, Aug 28, 2004 at 04:46:54PM +0200, Florian Weimer wrote: > * Michael Halcrow: > > > So I need to put a subset of GnuPG into my filesystem to support this. > > I have made a first pass over RFC 2440, but it would be helpful if I > > could work with one or more GnuPG developers in doing the job right > > (assuming it can be done at all; I basically need to be able to jump > > to an offset in the file and start block encryption/decryption via > > kernel crypto API scatterlists). > > The OpenPGP data format doesn't really support this. You'd have to > split your files into blocks of reasonable size. Each block has to > be encrypted independently, with a randomly chosen IV (if you use > CBC mode). Section 5.7 of RFC 2440 specifies ``PGP's variant of CFB''. This involves prefixing the plaintext with random data and keeping an IV of all 0's, among other things. If I use plain vanilla CBC, will GnuPG be able to decrypt the file? The reason I am asking is because the current kernel crypto API supports only ECB and CBC modes. If GnuPG can understand CBC, where is the IV stored (RFC 2440 dictates an IV of all 0's, with random text prepended to substitute)? How does it handle the very last block of plaintext, if the size of that block is less than the cipher block size? > You should change the IV and rencrypt the complete block each time > it is updated. I don't know of any encrypted file system > implementation which gets this right. ``Getting it right'' is my primary goal with cryptfs. Both in terms of security and in terms of usability. Exactly why is changing the IV on every update necessary? I would imagine that, at least with certain ciphers, having a static IV and key while changing the data can lend to linear cryptanalysis... I've begun work on implementing this PGP file format. For now, I am not so much interested in my filesystem layer being able to read files written by GnuPG, but rather for GnuPG to be able to process files written by cryptfs. When a new file is created that has a certain crypto policy, I am immediately writing (for now) an ESK packet (tag 3), followed by a set of fixed-length (4096 bytes for now) Symmetrically Encrypted Data packets (SEDP) (tag 9). Reads and writes are offset by the header plus the VFS offset into the file divided by the amount of actual data (which is fixed) in each packet multiplied by the full size of each packet. Whatever packet we land on, we read the entire page into memory, while decrypting it. If I need to generate a new random plaintext block to prepend in each packet, then that gets factored into the offset calculation. For fun, let's assume each letter equals one byte: K H P D D D D H P D D D D H P D D D D H P D D D D... 0 1 2 3 4 5 6 7 8 9 101112131415161718192021222324... K = ESK packet H = SEDP packet header P = Plaintext block D = Encrypted data Reading at location L would map something like this: ( L / DDDD ) * ( HPDDDD ) + KHP + ( L mod DDDD ) or (L/4)*6+3+(L%4). If I want extra crypto info for the filesystem, such as HMAC's over extents, that can be kept in ``comment packets'' (please tell me that GnuPG is okay with comment packets). That way, the file's integrity can be checked dynamically durring the read, so the user won't have to verify an entire 2-gig file before beginning to work with it (a bad hash will result in a read error from the filesystem). Please excuse my thinking out loud, but I am going to writing this up when I get into the office on Monday, so I just wanted to mull over some of the details before I jump into it. And things will go a lot faster if I can just use CBC for now, so please tell me GnuPG can handle that. :-) Mike .___________________________________________________________________. Michael A. Halcrow Security Software Engineer, IBM Linux Technology Center GnuPG Fingerprint: 05B5 08A8 713A 64C1 D35D 2371 2D3C FDDA 3EB6 601D Never send a man to do a machine's job. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20040828/9bf62fd8/attachment.bin From wk at gnupg.org Mon Aug 30 13:04:11 2004 From: wk at gnupg.org (Werner Koch) Date: Mon Aug 30 13:25:02 2004 Subject: [mike@halcrow.us: gnupgfs] In-Reply-To: <20040828150430.GA20398@halcrow.us> (Michael Halcrow's message of "Sat, 28 Aug 2004 10:04:30 -0500") References: <20040826142411.GA29478@halcrow.us> <87acwfz5ep.fsf@deneb.enyo.de> <20040828150430.GA20398@halcrow.us> Message-ID: <87r7poyjis.fsf@wheatstone.g10code.de> On Sat, 28 Aug 2004 10:04:30 -0500, Michael Halcrow said: > involves prefixing the plaintext with random data and keeping an IV of > all 0's, among other things. If I use plain vanilla CBC, will GnuPG > be able to decrypt the file? The reason I am asking is because the No. OpenPGP demands CFB. > all 0's, with random text prepended to substitute)? How does it > handle the very last block of plaintext, if the size of that block is > less than the cipher block size? It does not need to. A CFB stream may end at any byte without taking the block length in account. > And things will go a lot faster if I can just use CBC for now, so > please tell me GnuPG can handle that. :-) Well, you can define your private extensions to OpenPGP (e.g. a CBC variant) but an OpenPGP application may or may not be able to handle it. Certainly we could add this extension to GnupG if it really makes sense. OTOH, it ould be far easier to add a CFB mode to Linux. Werner From mike at halcrow.us Mon Aug 30 19:19:20 2004 From: mike at halcrow.us (Michael Halcrow) Date: Mon Aug 30 20:24:49 2004 Subject: [mike@halcrow.us: gnupgfs] In-Reply-To: <87r7poyjis.fsf@wheatstone.g10code.de> References: <20040826142411.GA29478@halcrow.us> <87acwfz5ep.fsf@deneb.enyo.de> <20040828150430.GA20398@halcrow.us> <87r7poyjis.fsf@wheatstone.g10code.de> Message-ID: <20040830171920.GA11698@halcrow.us> On Mon, Aug 30, 2004 at 01:04:11PM +0200, Werner Koch wrote: > > all 0's, with random text prepended to substitute)? How does it > > handle the very last block of plaintext, if the size of that block is > > less than the cipher block size? > > It does not need to. A CFB stream may end at any byte without taking > the block length in account. So I assume that this is done by simply x'oring the first n bytes of the last block of plaintext with the first n bytes of the last FRE? > > And things will go a lot faster if I can just use CBC for now, so > > please tell me GnuPG can handle that. :-) > > Well, you can define your private extensions to OpenPGP (e.g. a CBC > variant) but an OpenPGP application may or may not be able to handle > it. Certainly we could add this extension to GnupG if it really makes > sense. OTOH, it ould be far easier to add a CFB mode to Linux. It actually involves some footwork, since the kernel crypto API currently only supports data that is a multiple of the block size. I am currently in the process of altering that behavior. Mike .___________________________________________________________________. Michael A. Halcrow Security Software Engineer, IBM Linux Technology Center GnuPG Fingerprint: 05B5 08A8 713A 64C1 D35D 2371 2D3C FDDA 3EB6 601D -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20040830/465afc31/attachment.bin From wk at gnupg.org Tue Aug 31 09:58:13 2004 From: wk at gnupg.org (Werner Koch) Date: Tue Aug 31 09:58:47 2004 Subject: [mike@halcrow.us: gnupgfs] In-Reply-To: <20040830171920.GA11698@halcrow.us> (Michael Halcrow's message of "Mon, 30 Aug 2004 12:19:20 -0500") References: <20040826142411.GA29478@halcrow.us> <87acwfz5ep.fsf@deneb.enyo.de> <20040828150430.GA20398@halcrow.us> <87r7poyjis.fsf@wheatstone.g10code.de> <20040830171920.GA11698@halcrow.us> Message-ID: <87llfvyc16.fsf@wheatstone.g10code.de> On Mon, 30 Aug 2004 12:19:20 -0500, Michael Halcrow said: > So I assume that this is done by simply x'oring the first n bytes of > the last block of plaintext with the first n bytes of the last FRE? Yes. Werner From t.hirsch at web.de Tue Aug 31 15:48:29 2004 From: t.hirsch at web.de (Thorsten Hirsch) Date: Thu Sep 2 13:18:25 2004 Subject: ath.c:201: _gcry_ath_mutex_unlock: Assertion `*lock == ((ath_mutex_t) 1)' failed. Message-ID: <1093960109.23166.4.camel@bauerbob.hirsch.lan> Hi. I just wanted to revoke my key and this is what happened: ========================================== $ gpg --gen-revoke E3379ACD 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! sec 1024D/E3379ACD 2003-03-07 Thorsten Hirsch Create a revocation certificate for this key? yes Please select the reason for the revocation: 0 = No reason specified 1 = Key has been compromised 2 = Key is superseded 3 = Key is no longer used Q = Cancel (Probably you want to select 1 here) Your decision? 2 Enter an optional description; end it with an empty line: > die vom CCC meinen, dass 1024bit nich mehr sicher sind - ich glaub's ihnen mal :-) > Reason for revocation: Key is superseded die vom CCC meinen, dass 1024bit nich mehr sicher sind - ich glaub's ihnen mal :-) \x0 Is this okay? yes You need a passphrase to unlock the secret key for user: "Thorsten Hirsch " 1024-bit DSA key, ID E3379ACD, created 2003-03-07 gpg: gpg-agent is not available in this session ASCII armored output forced. gpg: ath.c:201: _gcry_ath_mutex_unlock: Assertion `*lock == ((ath_mutex_t) 1)' failed. Aborted ================================= The guys in the IRC (freenode, #gnupg) said, that I should send a bug report, so here I am. I'm using Gentoo, gnupg version is 1.9.10. Regards, Thorsten -- PGP public key: http://home.arcor.de/thorstenhirsch/thirschatwebde.asc