From dkg at fifthhorseman.net Tue Jul 1 17:18:19 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 01 Jul 2014 11:18:19 -0400 Subject: Fwd: Bug#753047: src:libgpg-error: FTCBFS for any architecture but mingw32 and android In-Reply-To: <20140628180327.GA1384@alf.mars> References: <20140628180327.GA1384@alf.mars> Message-ID: <53B2D13B.9020206@fifthhorseman.net> Hi Werner and other GnuPG folks-- I'm forwarding along https://bugs.debian.org/753047, which raises concerns about cross-building libgpg-error (the FTCBFS in the Subject: means "Fails to Cross-Build from Source"). This is important for debian because libgpg-error is in the critical build-path for bootstrapping a new architecture, thanks to this dependency chain: openldap ? gnutls26 ? gcrypt ? libgpg-error In the future, we're hoping to move openldap to gnutls28 instead of gnutls26, which will remove the gcrypt dependency and take libgpg-error out of the critical path. But in the future, we may also want to consider moving to gpg2 , which itself will depend on libgpg-error, so being able to cross-build libgpg-error in a straightforward way would still be useful. I'm afraid i don't know enough about cross-building to have a concrete suggestion for the bug reporter, or for gpg. It seems to me like the remit of libgpg-error is narrow enough that we ought to be able to make it cross-buildable. Any pointers or suggestions for what we might do to make that work? Regards, --dkg -------------- next part -------------- An embedded message was scrubbed... From: Helmut Grohne Subject: Bug#753047: src:libgpg-error: FTCBFS for any architecture but mingw32 and android Date: Sat, 28 Jun 2014 20:03:28 +0200 Size: 6208 URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1010 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Thu Jul 3 08:46:00 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 03 Jul 2014 08:46:00 +0200 Subject: Fwd: Bug#753047: src:libgpg-error: FTCBFS for any architecture but mingw32 and android In-Reply-To: <53B2D13B.9020206@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Tue, 01 Jul 2014 11:18:19 -0400") References: <20140628180327.GA1384@alf.mars> <53B2D13B.9020206@fifthhorseman.net> Message-ID: <87ionf0wk7.fsf@vigenere.g10code.de> Hi, > From: Helmut Grohne > name. The native way to create lock-obj-pub.native.h is to execute the > gen-posix-lock-obj tool built from gen-posix-lock-obj.c. Unfortunately, > this tool uses various platform-specific aspects (e.g. sizeof) and > therefore using CC_FOR_BUILD to build gen-posix-lock-obj would be wrong. Right. This is why the instructions in README build="$(build-aux/config.guess)" ./configure --prefix=TARGETDIR --host=TARGET --build=$build cd src make gen-posix-lock-obj scp gen-posix-lock-obj TARGET: ssh TARGET ./gen-posix-lock-obj >tmp.h mv tmp.h "syscfg/$(awk 'NR==1 {print $2}' tmp.h)" say to build and execute gen-posix-lock-obj for the targeted host. This needs to be done just once and then we can include the required info into the release. For Debian the fastest way forward is to follow the instructions and include a patch for each platform. > Fundamentally the issue lies in gen-posix-lock-obj which both must use > the host compiler in order to access attributes of the host and it must By means of configure's AC_CHECK_SIZEOF - pretty standard for cross-compiling. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Jul 3 12:05:07 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 03 Jul 2014 12:05:07 +0200 Subject: [Announce] The fifth Beta for GnuPG 2.1 is now available for testing Message-ID: <87simizrjg.fsf@vigenere.g10code.de> Hello! I just released the fifth *beta version* of GnuPG 2.1. It has been released to give you the opportunity to check out new features and to fix the bugs in the last beta. If you need a stable and fully maintained version of GnuPG, you should use version 2.0.25 or 1.4.18. This versions is marked as BETA and as such it should in general not be used for real work. However, the core functionality is solid enough for a long time and I am using this code base for a couple of years now. What's new in 2.1.0-beta751 since beta442 ========================================= * gpg: Make export of secret keys work again. * gpg: Create revocation certificates during key generation. * gpg: Create exported secret keys and revocation certifciates with mode 0700 * gpg: The output of --list-packets does now print the offset of the packet and information about the packet header. * gpg: Avoid DoS due to garbled compressed data packets. [CVE-2014-4617] * gpg: Screen keyserver responses to avoid importing unwanted keys from rogue servers. * gpg: The validity of user ids is now shown by default. To revert this add "list-options no-show-uid-validity" to gpg.conf. * gpg: Print more specific reason codes with the INV_RECP status. * gpg: Cap RSA and Elgamal keysize at 4096 bit also for unattended key generation. * scdaemon: Support reader Gemalto IDBridge CT30 and pinpad of SCT cyberJack go. * The speedo build system has been improved. It is now also possible to build a partly working installer for Windows. Getting the Software ==================== GnuPG 2.1.0-beta751 is available at ftp://ftp.gnupg.org/gcrypt/gnupg/unstable/gnupg-2.1.0-beta751.tar.bz2 ftp://ftp.gnupg.org/gcrypt/gnupg/unstable/gnupg-2.1.0-beta751.tar.bz2.sig and soon on all mirrors . A patch against the last beta is also available. Please read the README file ! Checking the Integrity ====================== In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * If you already have a trusted version of GnuPG installed, you can simply check the supplied signature. For example to check the signature of the file gnupg-2.1.0-beta751.tar.bz2 you would use this command: gpg --verify gnupg-2.1.0-beta751.tar.bz2.sig This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by that signing key. Make sure that you have the right key, either by checking the fingerprint of that key with other sources or by checking that the key has been signed by a trustworthy other key. Note, that you can retrieve the signing key using the command finger wk ,at' g10code.com or using a keyserver like gpg --keyserver keys.gnupg.net --recv-key 4F25E3B6 The distribution key 4F25E3B6 is signed by the well known key 1E42B367. NEVER USE A GNUPG VERSION YOU JUST DOWNLOADED TO CHECK THE INTEGRITY OF THE SOURCE - USE AN EXISTING GNUPG INSTALLATION! * If you are not able to use an old version of GnuPG, you have to verify the SHA-1 checksum. Assuming you downloaded the file gnupg-2.1.0-beta751.tar.bz2, you would run the sha1sum command like this: sha1sum gnupg-2.1.0-beta751.tar.bz2 and check that the output matches this: 3d6dd8a377775780626428d98dba80dbbc5c27ac gnupg-2.1.0-beta751.tar.bz2 Documentation ============= The file gnupg.info has the complete user manual of the system. Separate man pages are included as well; however they have not all the details available in the manual. It is also possible to read the complete manual online in HTML format at https://www.gnupg.org/documentation/manuals/gnupg-devel/ The chapters on gpg-agent, gpg and gpgsm include information on how to set up the whole thing. You may also want search the GnuPG mailing list archives or ask on the gnupg-users mailing lists for advise on how to solve problems. Many of the new features are around for several years and thus enough public knowledge is already available. Almost all mail clients support GnuPG-2. Mutt users may want to use the configure option "--enable-gpgme" during build time and put a "set use_crypt_gpgme" in ~/.muttrc to enable S/MIME support along with the reworked OpenPGP support. Support ======= Please consult the archive of the gnupg-users mailing list before reporting a bug . We suggest to send bug reports for a new release to this list in favor of filing a bug at . We also have a dedicated service directory at: https://www.gnupg.org/service.html Maintaining and improving GnuPG is costly. For more than a decade, g10 Code GmbH, a German company owned and headed by GnuPG's principal author Werner Koch, is bearing the majority of these costs. To help them carry on this work, they need your support. See https://gnupg.org/donate/ Thanks ====== We have to thank all the people who helped with this release, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, and answering questions on the mailing lists. Happy Hacking, The GnuPG Team -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 180 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From wk at gnupg.org Thu Jul 3 20:07:17 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 03 Jul 2014 20:07:17 +0200 Subject: Fwd: Re: Fwd: Bug#753047: src:libgpg-error: FTCBFS for any architecture but mingw32 and android In-Reply-To: <20140703155945.GA12161@alf.mars> (Helmut Grohne's message of "Thu, 3 Jul 2014 17:59:45 +0200") References: <87ionf0wk7.fsf@vigenere.g10code.de> <53B56682.7040201@fifthhorseman.net> <20140703155945.GA12161@alf.mars> Message-ID: <87d2dmxqne.fsf@vigenere.g10code.de> On Thu, 3 Jul 2014 17:59, helmut at subdivi.de said: > maintain. These headers may need changes with updated versions of glibc > (or with a different libc) and for new ports the header will always be No. The objects are part of the ABI and thus there is no way to change them without changing the pthread ABI. > * The list of Debian architectures I am trying to crossbuild for is: > alpha, arm, arm64, armel, armhf, hppa, i386, ia64, m68k, mips, > mips64el, mipsel, or1k, powerpc, powerpcspe, ppc64, ppc64el, s390, > s390x, sh4, sparc, sparc64, x32. You have to test them anywa. Retrieving the needed information is simple. If you can give me access to those machines, I will be glad to do that. > I'd much prefer a solution based on AC_CHECK_SIZEOF (which works without > executing binaries for the host), but I am not an autofoo expert. It That is what we are doing. Running the check program is just a convenient way of creating the header _and_ to check that everything works. > Can someone explain to me why gpgrt_lock_t cannot be redefined to be > a typedef to _gpgrt_lock_t and GPGRT_LOCK_INITIALIZER cannot be changed > from For the simple reason of encapsulation. This will safe you a lot of trouble later in terms of build dependencies. > Please keep CCing me. The (missing) MFT header takes care of this ;-) Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Jul 3 20:17:51 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 03 Jul 2014 20:17:51 +0200 Subject: Fwd: Re: Fwd: Bug#753047: src:libgpg-error: FTCBFS for any architecture but mingw32 and android In-Reply-To: <87d2dmxqne.fsf@vigenere.g10code.de> (Werner Koch's message of "Thu, 03 Jul 2014 20:07:17 +0200") References: <87ionf0wk7.fsf@vigenere.g10code.de> <53B56682.7040201@fifthhorseman.net> <20140703155945.GA12161@alf.mars> <87d2dmxqne.fsf@vigenere.g10code.de> Message-ID: <878uoaxq5s.fsf@vigenere.g10code.de> On Thu, 3 Jul 2014 20:07, wk at gnupg.org said: > That is what we are doing. Running the check program is just a > convenient way of creating the header _and_ to check that everything Oops, my fault: We need to run it on the host platform to scan the value of the static intializer. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Fri Jul 4 04:48:58 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 03 Jul 2014 22:48:58 -0400 Subject: Fwd: Bug#753047: src:libgpg-error: FTCBFS for any architecture but mingw32 and android In-Reply-To: <87ionf0wk7.fsf@vigenere.g10code.de> References: <20140628180327.GA1384@alf.mars> <53B2D13B.9020206@fifthhorseman.net> <87ionf0wk7.fsf@vigenere.g10code.de> Message-ID: <87k37tx2hx.fsf@alice.fifthhorseman.net> On Thu 2014-07-03 02:46:00 -0400, Werner Koch wrote: > Right. This is why the instructions in README > > build="$(build-aux/config.guess)" > ./configure --prefix=TARGETDIR --host=TARGET --build=$build > cd src > make gen-posix-lock-obj > scp gen-posix-lock-obj TARGET: > ssh TARGET ./gen-posix-lock-obj >tmp.h > mv tmp.h "syscfg/$(awk 'NR==1 {print $2}' tmp.h)" > > say to build and execute gen-posix-lock-obj for the targeted host. Please bear with me, the cross-building process is new to me. I just tried to do this for powerpc (from x86-64) and didn't manage to create a powerpc executable for gen-posix-lock-obj. I'm not sure what i'm doing wrong, but below is a transcript of the full attempt, including a demonstration that the final executable is x86-64, not powerpc. I suspect that the problem is related to: configure: WARNING: using cross tools not prefixed with host triplet but i'm not sure how to resolve it. I'm running debian testing/unstable, using the standard toolchain. Pointers to the proper way to set up cross-compiling (if that's what i'm missing) would be welcome. --dkg 0 dkg at alice:/tmp/cdtemp.52gBUW$ wget -q ftp://ftp.gnupg.org/gcrypt/libgpg-error/libgpg-error-1.13.tar.bz2{.sig,} 0 dkg at alice:/tmp/cdtemp.52gBUW$ gpg --verify libgpg-error-1.13.tar.bz2{.sig,} gpg: Signature made Tue 15 Apr 2014 08:28:49 AM EDT gpg: using RSA key 0x249B39D24F25E3B6 gpg: please do a --check-trustdb gpg: Good signature from "Werner Koch (dist sig)" [unknown] gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 0 dkg at alice:/tmp/cdtemp.52gBUW$ tar xjf libgpg-error-1.13.tar.bz2 0 dkg at alice:/tmp/cdtemp.52gBUW$ cd libgpg-error-1.13 0 dkg at alice:/tmp/cdtemp.52gBUW/libgpg-error-1.13$ build="$(build-aux/config.guess)" 0 dkg at alice:/tmp/cdtemp.52gBUW/libgpg-error-1.13$ ./configure --prefix=/tmp/cdtemp.52gBUW/powerpc --host=powerpc-linux-gnu --build=$build checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for powerpc-linux-gnu-strip... no checking for strip... strip configure: WARNING: using cross tools not prefixed with host triplet checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... no checking whether make supports nested variables... yes checking build system type... x86_64-unknown-linux-gnu checking host system type... powerpc-unknown-linux-gnu configure: autobuild project... libgpg-error configure: autobuild revision... 1.13 configure: autobuild hostname... alice configure: autobuild timestamp... 20140703-214711 checking for powerpc-linux-gnu-gcc... no checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... yes checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking whether gcc and cc understand -c and -o together... yes checking how to run the C preprocessor... gcc -E checking for gawk... (cached) gawk checking for powerpc-linux-gnu-ar... no checking for ar... ar checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking minix/config.h usability... no checking minix/config.h presence... no checking for minix/config.h... no checking whether it is safe to define __EXTENSIONS__... yes checking how to print strings... printf checking for a sed that does not truncate output... /bin/sed checking for fgrep... /bin/grep -F checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for BSD- or MS-compatible name lister (nm)... no checking for powerpc-linux-gnu-dumpbin... no checking for powerpc-linux-gnu-link... no checking for dumpbin... no checking for link... link -dump checking the name lister (nm) interface... BSD nm checking whether ln -s works... yes checking the maximum length of command line arguments... 1635000 checking whether the shell understands some XSI constructs... yes checking whether the shell understands "+="... yes checking how to convert x86_64-unknown-linux-gnu file names to powerpc-unknown-linux-gnu format... func_convert_file_noop checking how to convert x86_64-unknown-linux-gnu file names to toolchain format... func_convert_file_noop checking for /usr/bin/ld option to reload object files... -r checking for powerpc-linux-gnu-objdump... no checking for objdump... objdump checking how to recognize dependent libraries... pass_all checking for powerpc-linux-gnu-dlltool... no checking for dlltool... no checking how to associate runtime and link libraries... printf %s\n checking for powerpc-linux-gnu-ar... ar checking for archiver @FILE support... @ checking for powerpc-linux-gnu-strip... strip checking for powerpc-linux-gnu-ranlib... no checking for ranlib... ranlib checking command to parse nm output from gcc object... ok checking for sysroot... no checking for powerpc-linux-gnu-mt... no checking for mt... mt checking if mt is a manifest tool... no checking for dlfcn.h... yes checking for objdir... .libs checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fPIC -DPIC checking if gcc PIC flag -fPIC -DPIC works... yes checking if gcc static flag -static works... yes checking if gcc supports -c -o file.o... yes checking if gcc supports -c -o file.o... (cached) yes checking whether the gcc linker (/usr/bin/ld -m elf64ppc) supports shared libraries... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... unsupported checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... no checking whether to build shared libraries... no checking whether to build static libraries... yes checking for powerpc-linux-gnu-windres... no checking for windres... no checking for cc for build... cc checking whether NLS is requested... yes checking for msgfmt... /usr/bin/msgfmt checking for gmsgfmt... /usr/bin/msgfmt checking for xgettext... /usr/bin/xgettext checking for msgmerge... /usr/bin/msgmerge checking for ld used by GCC... /usr/bin/ld -m elf64ppc checking if the linker (/usr/bin/ld -m elf64ppc) is GNU ld... no checking for shared library run path origin... done checking for CFPreferencesCopyAppValue... no checking for CFLocaleCopyCurrent... no checking for GNU gettext in libc... yes checking whether to use NLS... yes checking where the gettext function comes from... libc checking for ANSI C header files... (cached) yes checking for stdlib.h... (cached) yes checking locale.h usability... yes checking locale.h presence... yes checking for locale.h... yes checking whether strerror_r is declared... yes checking for strerror_r... yes checking whether strerror_r returns char *... yes checking for strerror_r... (cached) yes checking for flockfile... yes checking for an ANSI C-conforming const... yes checking whether imported symbols can be declared weak... guessing yes checking pthread.h usability... yes checking pthread.h presence... yes checking for pthread.h... yes checking for pthread_kill in -lpthread... yes checking for multithread API to use... posix checking for pthread_rwlock_t... yes checking size of pthread_mutex_t... 40 configure: creating ./config.status config.status: creating Makefile config.status: creating po/Makefile.in config.status: creating m4/Makefile config.status: creating src/Makefile config.status: creating tests/Makefile config.status: creating lang/Makefile config.status: creating lang/cl/Makefile config.status: creating lang/cl/gpg-error.asd config.status: creating src/versioninfo.rc config.status: creating src/gpg-error-config config.status: creating config.h config.status: executing depfiles commands config.status: executing libtool commands config.status: executing po-directories commands config.status: creating po/POTFILES config.status: creating po/Makefile libgpg-error-1.13 prepared for make Revision: 1900266 (6400) Platform: powerpc-unknown-linux-gnu 0 dkg at alice:/tmp/cdtemp.52gBUW/libgpg-error-1.13$ cd src 0 dkg at alice:/tmp/cdtemp.52gBUW/libgpg-error-1.13/src$ make gen-posix-lock-obj gcc -DHAVE_CONFIG_H -I. -I.. -g -O2 -MT gen-posix-lock-obj.o -MD -MP -MF .deps/gen-posix-lock-obj.Tpo -c -o gen-posix-lock-obj.o gen-posix-lock-obj.c mv -f .deps/gen-posix-lock-obj.Tpo .deps/gen-posix-lock-obj.Po /bin/bash ../libtool --tag=CC --mode=link gcc -g -O2 -o gen-posix-lock-obj gen-posix-lock-obj.o libtool: link: gcc -g -O2 -o gen-posix-lock-obj gen-posix-lock-obj.o 0 dkg at alice:/tmp/cdtemp.52gBUW/libgpg-error-1.13/src$ file gen-posix-lock-obj gen-posix-lock-obj: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=7bbe1ba730c4341e8f070f41c342b1c4584e984a, not stripped 0 dkg at alice:/tmp/cdtemp.52gBUW/libgpg-error-1.13/src$ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From gniibe at fsij.org Fri Jul 4 08:21:36 2014 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 04 Jul 2014 15:21:36 +0900 Subject: Fwd: Bug#753047: src:libgpg-error: FTCBFS for any architecture but mingw32 and android In-Reply-To: <87k37tx2hx.fsf@alice.fifthhorseman.net> References: <20140628180327.GA1384@alf.mars> <53B2D13B.9020206@fifthhorseman.net> <87ionf0wk7.fsf@vigenere.g10code.de> <87k37tx2hx.fsf@alice.fifthhorseman.net> Message-ID: <1404454896.3374.0.camel@latx1.gniibe.org> Hello, On 2014-07-03 at 22:48 -0400, Daniel Kahn Gillmor wrote: > I just tried to do this for powerpc (from x86-64) and didn't manage to > create a powerpc executable for gen-posix-lock-obj. I'm not sure what > i'm doing wrong, but below is a transcript of the full attempt, > including a demonstration that the final executable is x86-64, not > powerpc. You need to install cross toolchain. In the log: > checking build system type... x86_64-unknown-linux-gnu > checking host system type... powerpc-unknown-linux-gnu [...] > checking for powerpc-linux-gnu-gcc... no [...] > checking for powerpc-linux-gnu-ar... no I think that your system doesn't have cross toolchain. I don't know why configure didn't fail in this situation. Perhaps, it assumed that standard 'gcc' should have capability to compile for the host powerpc-unknown-linux-gnu. > Pointers to the proper way to set up cross-compiling (if that's what > i'm missing) would be welcome. I don't have enough knowledge of current cross toolchain for Debian, but it seems that there are packages by Ubuntu: https://launchpad.net/ubuntu/+source/powerpc-cross-toolchain-base https://launchpad.net/ubuntu/+source/gcc-defaults-powerpc-cross https://launchpad.net/ubuntu/+source/gcc-4.9-powerpc-cross https://launchpad.net/ubuntu/+source/binutils-powerpc-cross I haven't tried those packages, though. Just FYI. -- From gniibe at fsij.org Fri Jul 4 09:36:08 2014 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 04 Jul 2014 16:36:08 +0900 Subject: libgpg-error: po/ja.po update Message-ID: <1404459368.3374.4.camel@latx1.gniibe.org> Hello, I had opportunity to clone libgpg-error today, and I realized its po/ja.po is outdated, also found some errors (it didn't recognize "pinentry" as a program name, it misunderstood MAC as Media Access Control, instead of Message Authentication Code, etc.). I have updated it. Since I don't think it's maintained by translation-team-ja at lists.sourceforge.net, I modified: "Language-Team: none\n". I'll maintain this translation. OK to commit? -- From bernhard at intevation.de Mon Jul 7 15:42:30 2014 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 7 Jul 2014 15:42:30 +0200 Subject: gpgsm, certgen example and de.po fix Message-ID: <201407071542.36913.bernhard@intevation.de> Werner, I've noticed a translation slip and I suggest to add an example for the DN value for gpgsm --gen-keys. Thanks, Bernhard -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998 Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: de-fix-20140707.diff Type: text/x-diff Size: 376 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: certgen-dn-example-20140707.diff Type: text/x-diff Size: 529 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3955 bytes Desc: not available URL: From e1ven at e1ven.com Tue Jul 8 06:44:40 2014 From: e1ven at e1ven.com (Colin Davis) Date: Tue, 8 Jul 2014 00:44:40 -0400 Subject: Makefile change to fix my location compilation issue In-Reply-To: <87oaxrsv7h.fsf@vigenere.g10code.de> References: <87oaxrsv7h.fsf@vigenere.g10code.de> Message-ID: <9AA9A865-2E41-48FF-9EC7-45D076400211@e1ven.com> Thank you for taking a look at this. I apologize for the delay in replying - I had since changed my OS, and needed to swap back to get you the logs. I had been using the git master branch - Both for GnuPG as well as the libraries. When running this now, I'm using the currently git master. I?m using automake 1.11.6 - I installed this version since the new version does not work without workarounds. I?m using autoconf 2.69 The full build log, including GPG as well as the supporting libraries is at https://gist.githubusercontent.com/e1ven/5b2351b72175668dc434/raw/d7dd984309e94f3a9c27856acf27b145f5cab7ef/FullGPGinstalllog I executed the script with ?set -x?, so it would echo each command (and all their flags) The config.log is at https://gist.githubusercontent.com/e1ven/0ef747651a1935283dee/raw/b653430d867fecdfde692828976d21117d6f243a/config.log The build log after applying the patch is https://gist.githubusercontent.com/e1ven/5b42c299fc2b33bf726f/raw/4019fc4431233a6b5323db3fa5937b8dc99c44f8/gistfile1.txt I'm sure I'm doing something foolish, but I'd appreciate any thoughts. -CPD On Jun 17, 2014, at 6:10 AM, Werner Koch wrote: > Hi! > > On Mon, 26 May 2014 09:28, e1ven at e1ven.com said: >> >> -t_common_ldadd = libcommon.a ../gl/libgnu.a \ >> +t_common_ldadd = libcommon.a libcommon_a-init.o ../gl/libgnu.a \ > > That smells like a missing ranlib call. However, automake generated > makefiles call ranlib. > > What version of GnupG are you using. Do you use the GIT versions? > Which automake, autoconf in that case? > > Can you please send the respective part of the compile log and > config.log ? My apologies in advance if you already sent it and I lost > track of it. > > > Salam-Shalom, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > From lechten at wi.uni-muenster.de Tue Jul 8 19:41:09 2014 From: lechten at wi.uni-muenster.de (Jens Lechtenboerger) Date: Tue, 08 Jul 2014 19:41:09 +0200 Subject: Problems with gpgsm/dirmngr in gnupg-2.1.0-beta751 Message-ID: <87zjgjpx3e.fsf@pcwi7557.uni-muenster.de> Hi there, I'm failing to use gpgsm in gnupg-2.1.0-beta751. (I'm able to use gpgsm-2.0.14 as part of my distribution.) To make sure that my configuration is OK I renamed ~/.gnupg and killed gpg-agent (which uses a socket under ~/.gnupg). Importing certificates failed then: gpgsm: Die "Keybox" `/home/lechten/.gnupg/pubring.kbx' konnte nicht erstellt werden: Datei oder Verzeichnis nicht gefunden That message could be more helpful by stating that the directory is missing; maybe the directory could even be created automatically. Anyways, I created ~/.gnupg (/etc/gnupg is empty as well). Import of my certificate chain succeeded then. However, encryption to my certificate fails: $ gpgsm -vv --encrypt --recipient F7:A5:12:A2:56:F0:12:AA:59:E9:96:62:A2:B4:51:CF:3A:4E:47:E7 test.txt > test.gpgsm gpgsm: NOTE: THIS IS A DEVELOPMENT VERSION! gpgsm: It is only intended for test purposes and should NOT be gpgsm: used in a production environment or with production keys! gpgsm: certificate's policy list: 1.3.6.1.4.1.22177.300.1.1.4.3.1:N: 1.3.6.1.4.1.22177.300.2.1.4.3.1:N: gpgsm: Datei `/home/lechten/.gnupg/policies.txt' kann nicht ge?ffnet werden: Datei oder Verzeichnis nicht gefunden gpgsm: Notiz: Die unkritische Zertifikatsrichtlinie ist nicht erlaubt gpgsm: asking dirmngr about F7:A5:12:A2:56:F0:12:AA:59:E9:96:62:A2:B4:51:CF:3A:4E:47:E7 gpgsm: response of dirmngr: Dateiende gpgsm: certificate #16EC9481CC8496/1.2.840.113549.1.9.1=#636140756E692D6D75656E737465722E6465,CN=Zertifizierungsstelle Universitaet Muenster - G02,O=Universitaet Muenster,C=DE gpgsm: Die CRL konnte nicht gepr?ft werden: Dateiende gpgsm: Benutztes G?ltigkeitsmodell: Schale gpgsm: can't encrypt to 'F7:A5:12:A2:56:F0:12:AA:59:E9:96:62:A2:B4:51:CF:3A:4E:47:E7': Dateiende I retried the previous command with ~/.gnupg/dirmngr.conf as follows: log-file /tmp/dirmngr.log debug-all debug-level guru The resulting logfile contains: 2014-07-08 18:15:12 dirmngr[7432.0] Es wird auf Socket `/home/lechten/.gnupg/S.dirmngr' geh?rt 2014-07-08 18:15:12 dirmngr[7433.0] Fehler beim Zugriff auf das Verzeichnis `/home/lechten/.gnupg/trusted-certs': Datei oder Verzeichnis nicht gefunden 2014-07-08 18:15:12 dirmngr[7433.0] Fehler beim Zugriff auf das Verzeichnis `/home/lechten/.gnupg/extra-certs': Datei oder Verzeichnis nicht gefunden 2014-07-08 18:15:12 dirmngr[7433.0] dauerhaft geladene Zertifikate: 0 2014-07-08 18:15:12 dirmngr[7433.0] zur Laufzeit zwischengespeicherte Zertifikate: 0 2014-07-08 18:15:13 dirmngr[7433.0] Handhabungsroutine f?r fd 0 gestartet 2014-07-08 18:15:13 dirmngr[7433.0] DBG: chan_0 -> # Home: /home/lechten/.gnupg 2014-07-08 18:15:13 dirmngr[7433.0] DBG: chan_0 -> # Config: /home/lechten/.gnupg/dirmngr.conf 2014-07-08 18:15:13 dirmngr[7433.0] DBG: chan_0 -> OK Dirmngr 2.1.0-beta751 at your service 2014-07-08 18:15:13 dirmngr[7433.0] connection from process 7430 (1000:1000) 2014-07-08 18:15:13 dirmngr[7433.0] DBG: chan_0 <- OPTION audit-events=1 2014-07-08 18:15:13 dirmngr[7433.0] DBG: chan_0 -> OK 2014-07-08 18:15:13 dirmngr[7433.0] DBG: chan_0 <- ISVALID A52EFAEFBC86EF98C5E9AA92B3ECEC4101080F0A.16EC9481CC8496 2014-07-08 18:15:13 dirmngr[7433.0] Es ist keine CRL f?r den Issuer mit der ID A52EFAEFBC86EF98C5E9AA92B3ECEC4101080F0A vorhanden 2014-07-08 18:15:13 dirmngr[7433.0] DBG: chan_0 -> INQUIRE SENDCERT 2014-07-08 18:15:13 dirmngr[7433.0] DBG: chan_0 <- [ 44 20 30 82 05 e6 30 82 04 ce a0 03 02 01 02 02 ...(982 byte(s) skipped) ] 2014-07-08 18:15:13 dirmngr[7433.0] DBG: chan_0 <- [ 44 20 55 1d 1f 04 74 30 72 30 37 a0 35 a0 33 86 ...(544 byte(s) skipped) ] 2014-07-08 18:15:13 dirmngr[7433.0] DBG: chan_0 <- END 2014-07-08 18:15:13 dirmngr[7433.0] checking distribution points 2014-07-08 18:15:13 dirmngr[7433.0] fetching CRL from 'http://cdp1.pca.dfn.de/wwu-ca/pub/crl/g_cacrl.crl' I don't see any network traffic on my machine, which I find surprising in view of the final log line. So I downloaded that CRL and tried to import it: $ dirmngr-client --load-crl g_cacrl.crl dirmngr-client: Verbindung zum Dirmngr nicht m?glich: IPC "connect" Aufruf fehlgeschlagen strace shows ECONNREFUSED (Connection refused) on ~/.gnupg/S.dirmngr, which appears to be a leftover from one of the previous commands. Removing that socket and invoking dirmngr-client again then leads to ENOENT (No such file or directory) on ~/.gnupg/S.dirmngr. (The man page of dirmngr-client suggests that dirmngr should be started automatically if it is not running. This does not seem to be the case; at least no messages appear in /tmp/dirmngr.log.) Now I'm stuck. Any hints? Best wishes Jens From alfred-ganz+gpg at agci.com Wed Jul 9 01:16:25 2014 From: alfred-ganz+gpg at agci.com (Alfred Ganz) Date: Tue, 8 Jul 2014 19:16:25 -0400 Subject: gpgsm issueing two concurrent passphrase requests fails Message-ID: <20140708231625.GA30473@server.agci.com> Ladies and Gentlemen, I have encountered a problem with gpgsm/gpg-agent in the case where gpgsm needs to open two connections with gpg-agent because it needs both the passphrase for an imported certificate and a passphrase for access to gpg. From the gpg-agent debug output it looks to me like the first connection is properly prepared but then the first passphrase request for the certificate is issued on the second connection which has not been properly set up and pinetry hangs. I have done a fair amount of googleing, but have not found any resolution for the problem, although I found at least one very similar report. Yes, GPG_TTY is properly set, and a gpg -s after proper cleanup of the hung pinentry worked as expected. I have reset gpg-agent.conf and gpgsm.conf and replaced /usr/bin/pinentry with a softlink to pinentry-curses and repeated my tests wth the same results. My system: Centos 6, 2.6.32-431.11.2.el6.i686 gpgsm: gpgsm (GnuPG) 2.0.14 libgcrypt 1.4.5 libksba 1.0.7 gpg-agent: gpg-agent (GnuPG) 2.0.14 libgcrypt 1.4.5 gpg: gpg (GnuPG) 2.0.14 libgcrypt 1.4.5 I have gone back and successfully done the above under an older system with gnupg-1.4.5-14.el5_5.1 and gnupg2-2.0.10-3.el5_5.1. I assume that I am not the first one to encounter this problem, and that it has been fixed in the meantime. Could you please tell me what I need to upgrade in order to have this fixed. I am adding an attachment with the commands used and the debug output from gpg-agent. If I can help with anything else please let me know. Thanks for your work on these packages and your help, AG -- ---------------------------------------------------------------------- Alfred Ganz alfred-ganz:at:agci.com AG Consulting (203) 624-9667 440 Prospect Street # 11 New Haven, CT 06511 ---------------------------------------------------------------------- -------------- next part -------------- Preparing the certificate: openssl req -new -x509 -key -out ssh-cert.pem openssl pkcs12 -export -in ssh-cert.pem -inkey -out ssh-key.p12 Starting gpg-agent (note gpg-agent.conf is empty and pinentry is a soft link to pinentry-curses and GPG_TTY is set): gpg-agent --csh --no-detach --debug-level basic --daemon > ~/.gpg-agent-info source ~/.gpg-agent-info After cleaning up the hung pinentry this worked just fine (see at the end): gpg -s gpg-agent[24825]: DBG: connection to PIN entry established gpg-agent[24825]: handler 0x87feb58 for fd 6 started gpg-agent[24825.6] DBG: -> OK Pleased to meet you gpg-agent[24825.6] DBG: <- RESET gpg-agent[24825.6] DBG: -> OK gpg-agent[24825.6] DBG: <- OPTION ttyname=/dev/pts/6 gpg-agent[24825.6] DBG: -> OK gpg-agent[24825.6] DBG: <- OPTION ttytype=xterm gpg-agent[24825.6] DBG: -> OK gpg-agent[24825.6] DBG: <- OPTION display=:0.0 gpg-agent[24825.6] DBG: -> OK gpg-agent[24825.6] DBG: <- OPTION xauthority=/home/ganz/.Xauthority gpg-agent[24825.6] DBG: -> OK gpg-agent[24825.6] DBG: <- OPTION lc-ctype=en_US.ISO-8859-1 gpg-agent[24825.6] DBG: -> OK gpg-agent[24825.6] DBG: <- OPTION lc-messages=en_US.ISO-8859-1 gpg-agent[24825.6] DBG: -> OK gpg-agent[24825.6] DBG: <- OPTION allow-pinentry-notify gpg-agent[24825.6] DBG: -> OK gpg-agent[24825.6] DBG: <- NOP gpg-agent[24825.6] DBG: -> OK gpg-agent[24825]: handler 0x8800310 for fd 7 started gpg-agent[24825.7] DBG: -> OK Pleased to meet you gpg-agent[24825.7] DBG: <- RESET gpg-agent[24825.7] DBG: -> OK gpg-agent[24825.7] DBG: <- OPTION allow-pinentry-notify gpg-agent[24825.7] DBG: -> OK gpg-agent[24825.7] DBG: <- GETINFO cmd_has_option GET_PASSPHRASE repeat gpg-agent[24825.7] DBG: -> OK gpg-agent[24825.7] DBG: <- GET_PASSPHRASE --data --repeat=0 -- X X Passphrase: Please+enter+the+passphrase+to+unprotect+the+PKCS#12+object. gpg-agent[24825]: starting a new PIN Entry gpg-agent[24825]: DBG: connection to PIN entry established gpg-agent[24825.7] DBG: -> INQUIRE PINENTRY_LAUNCHED 24949 gpg-agent[24825.7] DBG: <- END pinentry-curses: no LC_CTYPE known - assuming UTF-8 pinentry-curses: no LC_CTYPE known - assuming UTF-8 pinentry-curses: no LC_CTYPE known - assuming UTF-8 pinentry-curses: no LC_CTYPE known - assuming UTF-8 gpg-agent[24825.6] DBG: <- [EOF] gpg-agent[24825]: handler 0x87feb58 for fd 6 terminated gpg-agent[24825]: command get_passphrase failed: Incomplete line passed to IPC gpg-agent[24825.7] DBG: -> ERR 67109126 Incomplete line passed to IPC gpg-agent[24825]: Assuan processing failed: IPC write error gpg-agent[24825]: handler 0x8800310 for fd 7 terminated gpg-agent[24825]: handler 0x8801a48 for fd 6 started gpg-agent[24825.6] DBG: -> OK Pleased to meet you gpg-agent[24825.6] DBG: <- RESET gpg-agent[24825.6] DBG: -> OK gpg-agent[24825.6] DBG: <- OPTION ttyname=/dev/pts/6 gpg-agent[24825.6] DBG: -> OK gpg-agent[24825.6] DBG: <- OPTION ttytype=xterm gpg-agent[24825.6] DBG: -> OK gpg-agent[24825.6] DBG: <- OPTION display=:0.0 gpg-agent[24825.6] DBG: -> OK gpg-agent[24825.6] DBG: <- OPTION xauthority=/home/ganz/.Xauthority gpg-agent[24825.6] DBG: -> OK gpg-agent[24825.6] DBG: <- OPTION lc-ctype=en_US.ISO-8859-1 gpg-agent[24825.6] DBG: -> OK gpg-agent[24825.6] DBG: <- OPTION lc-messages=en_US.ISO-8859-1 gpg-agent[24825.6] DBG: -> OK gpg-agent[24825.6] DBG: <- OPTION allow-pinentry-notify gpg-agent[24825.6] DBG: -> OK gpg-agent[24825.6] DBG: <- GETINFO cmd_has_option GET_PASSPHRASE repeat gpg-agent[24825.6] DBG: -> OK gpg-agent[24825.6] DBG: <- GET_PASSPHRASE --data --repeat=0 -- 8033F52E5FDA06CF43C12663C5272A68A69E4A86 X X Please+enter+the+passphrase+to+unlock+the+secret+key+for+the+OpenPGP+certificate:%0A%22Alfred+Ganz+(My+Primary+Key+Pair)+%22%0A1024-bit+DSA+key,+ID+A69E4A86,%0Acreated+2004-04-14.%0A gpg-agent[24825]: starting a new PIN Entry gpg-agent[24825]: DBG: connection to PIN entry established gpg-agent[24825.6] DBG: -> INQUIRE PINENTRY_LAUNCHED 24981 gpg-agent[24825.6] DBG: <- END gpg-agent[24825.6] DBG: -> [Confidential data not shown] gpg-agent[24825.6] DBG: -> [Confidential data not shown] gpg-agent[24825.6] DBG: <- [EOF] gpg-agent[24825]: handler 0x8801a48 for fd 6 terminated From alfred-ganz+gpg at agci.com Thu Jul 10 21:28:41 2014 From: alfred-ganz+gpg at agci.com (Alfred Ganz) Date: Thu, 10 Jul 2014 15:28:41 -0400 Subject: gpgsm issueing two concurrent passphrase requests fails Message-ID: <20140710192841.GA18740@server.agci.com> Ladies and Gentlemen, I just noticed that I had not included the gpgsm command in my previous message. The commands which I executed in a separate window are: source ~/.gpg-agent-info gpgsm --import ssh-key.p12 and it is after this command there exists a hanging pinentry. If I kill the pinentry from yet another window, gpgsm ends with: gpgsm: gpg-protect-tool: error while asking for the passphrase: Incomplete line passed to IPC gpgsm: error running `/usr/libexec/gpg-protect-tool': exit status 2 gpgsm: total number processed: 0 Sorry for not including the above in my original message, AG -- ---------------------------------------------------------------------- Alfred Ganz alfred-ganz:at:agci.com AG Consulting (203) 624-9667 440 Prospect Street # 11 New Haven, CT 06511 ---------------------------------------------------------------------- From dbaryshkov at gmail.com Sat Jul 12 13:11:17 2014 From: dbaryshkov at gmail.com (Dmitry Eremin-Solenikov) Date: Sat, 12 Jul 2014 15:11:17 +0400 Subject: [PATCH libksba 5/7] Fix memory leak in crl parsing code. In-Reply-To: <1405163479-10925-1-git-send-email-dbaryshkov@gmail.com> References: <1405163479-10925-1-git-send-email-dbaryshkov@gmail.com> Message-ID: <1405163479-10925-6-git-send-email-dbaryshkov@gmail.com> * src/crl.c (store_one_entry_extension): Free memory at oid variable - otherwise libksba leaks memory on crl parsing. Signed-off-by: Dmitry Eremin-Solenikov --- src/crl.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/crl.c b/src/crl.c index a4b1776..3ed862e 100644 --- a/src/crl.c +++ b/src/crl.c @@ -1150,6 +1150,8 @@ store_one_entry_extension (ksba_crl_t crl, else if (critical) err = gpg_error (GPG_ERR_UNKNOWN_CRIT_EXTN); + xfree(oid); + return err; } -- 2.0.0 From dbaryshkov at gmail.com Sat Jul 12 13:11:14 2014 From: dbaryshkov at gmail.com (Dmitry Eremin-Solenikov) Date: Sat, 12 Jul 2014 15:11:14 +0400 Subject: [PATCH libksba 2/7] tests: fix print_sexp and print_sexp_hex functions In-Reply-To: <1405163479-10925-1-git-send-email-dbaryshkov@gmail.com> References: <1405163479-10925-1-git-send-email-dbaryshkov@gmail.com> Message-ID: <1405163479-10925-3-git-send-email-dbaryshkov@gmail.com> * tests/t-common.h (print_sexp, print_sexp_hex): advance pointer on closing brace. Signed-off-by: Dmitry Eremin-Solenikov --- tests/t-common.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tests/t-common.h b/tests/t-common.h index 71512a9..cf82f3e 100644 --- a/tests/t-common.h +++ b/tests/t-common.h @@ -110,6 +110,7 @@ print_sexp (ksba_const_sexp_t p) else if (*p == ')') { putchar (*p); + p++; if (--level <= 0 ) return; } @@ -176,6 +177,7 @@ print_sexp_hex (ksba_const_sexp_t p) else if (*p == ')') { putchar (*p); + p++; if (--level <= 0 ) return; } -- 2.0.0 From dbaryshkov at gmail.com Sat Jul 12 13:11:19 2014 From: dbaryshkov at gmail.com (Dmitry Eremin-Solenikov) Date: Sat, 12 Jul 2014 15:11:19 +0400 Subject: [PATCH libksba 7/7] Fix two memory leaks in cert-basic test In-Reply-To: <1405163479-10925-1-git-send-email-dbaryshkov@gmail.com> References: <1405163479-10925-1-git-send-email-dbaryshkov@gmail.com> Message-ID: <1405163479-10925-8-git-send-email-dbaryshkov@gmail.com> * tests/cert-basic.c (one_file): always free public key and der2. Signed-off-by: Dmitry Eremin-Solenikov --- tests/cert-basic.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/tests/cert-basic.c b/tests/cert-basic.c index 1a89cd9..91b394e 100644 --- a/tests/cert-basic.c +++ b/tests/cert-basic.c @@ -520,11 +520,15 @@ one_file (const char *fname) __FILE__, __LINE__); errorcount++; xfree (der2); + } else { + /* Don't leak memory if everything is ok. */ + xfree (der2); } xfree (tmp); } xfree (der); } + ksba_free (public); } } #endif -- 2.0.0 From dbaryshkov at gmail.com Sat Jul 12 13:11:15 2014 From: dbaryshkov at gmail.com (Dmitry Eremin-Solenikov) Date: Sat, 12 Jul 2014 15:11:15 +0400 Subject: [PATCH libksba 3/7] Reuse common test functions in cert-basic test In-Reply-To: <1405163479-10925-1-git-send-email-dbaryshkov@gmail.com> References: <1405163479-10925-1-git-send-email-dbaryshkov@gmail.com> Message-ID: <1405163479-10925-4-git-send-email-dbaryshkov@gmail.com> * tests/cert-basic.c (xmalloc, print_hex, print_sexp, print_time, print_dn): Drop. Signed-off-by: Dmitry Eremin-Solenikov --- tests/cert-basic.c | 122 +---------------------------------------------------- 1 file changed, 1 insertion(+), 121 deletions(-) diff --git a/tests/cert-basic.c b/tests/cert-basic.c index a70867f..1a89cd9 100644 --- a/tests/cert-basic.c +++ b/tests/cert-basic.c @@ -28,6 +28,7 @@ #include "../src/keyinfo.h" #include "oidtranstbl.h" +#include "t-common.h" #ifdef __MINGW32CE__ #define getenv(a) (NULL) @@ -54,127 +55,6 @@ static int verbose; static int errorcount = 0; -static void * -xmalloc (size_t n) -{ - char *p = ksba_malloc (n); - if (!p) - { - fprintf (stderr, "out of core\n"); - exit (1); - } - return p; -} - - -void -print_hex (const unsigned char *p, size_t n) -{ - if (!p) - fputs ("none", stdout); - else - { - for (; n; n--, p++) - printf ("%02X", *p); - } -} - - - -static void -print_sexp (ksba_const_sexp_t p) -{ - int level = 0; - - if (!p) - fputs ("[none]", stdout); - else - { - for (;;) - { - if (*p == '(') - { - putchar (*p); - p++; - level++; - } - else if (*p == ')') - { - putchar (*p); - p++; - if (--level <= 0 ) - return; - } - else if (!digitp (p)) - { - fputs ("[invalid s-exp]", stdout); - return; - } - else - { - char *endp; - unsigned long n, i; - int need_hex; - - n = strtoul (p, &endp, 10); - p = endp; - if (*p != ':') - { - fputs ("[invalid s-exp]", stdout); - return; - } - p++; - for (i=0; i < n; i++) - if ( !((p[i] >='A' && p[i] <= 'Z') - || (p[i] >='a' && p[i] <='z') - || (p[i] >='0' && p[i] <='9') - || p[i] == '-' - || p[i] == '.')) - break; - need_hex = (i='A' && *p <= 'Z') || (*p >='a' && *p <='z')))) - printf ("%lu:", n); - - if (need_hex) - { - putchar('#'); - for (; n; n--, p++) - printf ("%02X", *p); - putchar('#'); - } - else - { - for (; n; n--, p++) - putchar (*p); - } - putchar(' '); - } - } - } -} - -static void -print_time (ksba_isotime_t t) -{ - if (!t || !*t) - fputs ("none", stdout); - else - printf ("%.4s-%.2s-%.2s %.2s:%.2s:%s", t, t+4, t+6, t+9, t+11, t+13); -} - -static void -print_dn (char *p) -{ - - if (!p) - fputs ("error", stdout); - else - printf ("`%s'", p); -} - - static void print_names (int indent, ksba_name_t name) { -- 2.0.0 From dbaryshkov at gmail.com Sat Jul 12 13:11:12 2014 From: dbaryshkov at gmail.com (Dmitry Eremin-Solenikov) Date: Sat, 12 Jul 2014 15:11:12 +0400 Subject: [PATCH libksba 0/7] Several bugfixes Message-ID: <1405163479-10925-1-git-send-email-dbaryshkov@gmail.com> Hello, I would like to propose several bugfix patches to libksba. If I need to sign a DCO, please point me to it - I could not find any information in libksba sources. -- With best wishes Dmitry From dbaryshkov at gmail.com Sat Jul 12 13:11:13 2014 From: dbaryshkov at gmail.com (Dmitry Eremin-Solenikov) Date: Sat, 12 Jul 2014 15:11:13 +0400 Subject: [PATCH libksba 1/7] tests: Pass -no-install to libtool In-Reply-To: <1405163479-10925-1-git-send-email-dbaryshkov@gmail.com> References: <1405163479-10925-1-git-send-email-dbaryshkov@gmail.com> Message-ID: <1405163479-10925-2-git-send-email-dbaryshkov@gmail.com> * tests/Makefile.am: add AM_LDFLAGS = -no-install Signed-off-by: Dmitry Eremin-Solenikov --- tests/Makefile.am | 1 + 1 file changed, 1 insertion(+) diff --git a/tests/Makefile.am b/tests/Makefile.am index 3680049..013fb84 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -42,6 +42,7 @@ CLEANFILES = oidtranstbl.h TESTS = cert-basic t-crl-parser t-dnparser AM_CFLAGS = $(GPG_ERROR_CFLAGS) +AM_LDFLAGS = -no-install noinst_HEADERS = t-common.h noinst_PROGRAMS = $(TESTS) t-cms-parser t-crl-parser t-dnparser t-ocsp t-oid -- 2.0.0 From dbaryshkov at gmail.com Sat Jul 12 13:11:18 2014 From: dbaryshkov at gmail.com (Dmitry Eremin-Solenikov) Date: Sat, 12 Jul 2014 15:11:18 +0400 Subject: [PATCH libksba 6/7] Enable optional valgrind for testsuite In-Reply-To: <1405163479-10925-1-git-send-email-dbaryshkov@gmail.com> References: <1405163479-10925-1-git-send-email-dbaryshkov@gmail.com> Message-ID: <1405163479-10925-7-git-send-email-dbaryshkov@gmail.com> * configure.ac: Enable gnulib valgrind module. * gl/m4/gnulib.m4: Enable valgrind module. * tests/Makefile.am: Enable valgrind as LOG_COMPILER. * gl/m4/valgrind-tests.m4: New Signed-off-by: Dmitry Eremin-Solenikov --- configure.ac | 2 +- gl/Makefile.am | 2 +- gl/m4/gnulib.m4 | 1 + gl/m4/valgrind-tests.m4 | 37 +++++++++++++++++++++++++++++++++++++ tests/Makefile.am | 2 ++ 5 files changed, 42 insertions(+), 2 deletions(-) create mode 100644 gl/m4/valgrind-tests.m4 diff --git a/configure.ac b/configure.ac index cc24bbf..372c20c 100644 --- a/configure.ac +++ b/configure.ac @@ -362,7 +362,7 @@ AC_CHECK_FUNCS([memmove strchr strtol strtoul stpcpy gmtime_r getenv]) # GNUlib checks gl_SOURCE_BASE(gl) gl_M4_BASE(gl/m4) -gl_MODULES(alloca) +gl_MODULES(alloca valgrind-tests) gl_INIT # To be used in ksba-config diff --git a/gl/Makefile.am b/gl/Makefile.am index 3e407d1..f3b46e0 100644 --- a/gl/Makefile.am +++ b/gl/Makefile.am @@ -9,7 +9,7 @@ # # Generated by gnulib-tool. # Invoked as: gnulib-tool --import -# Reproduce by: gnulib-tool --import --dir=. --lib=libgnu --source-base=gl --m4-base=gl/m4 --aux-dir=. --libtool alloca alloca-opt +# Reproduce by: gnulib-tool --import --dir=. --lib=libgnu --source-base=gl --m4-base=gl/m4 --aux-dir=. --libtool alloca alloca-opt valgrind-tests AUTOMAKE_OPTIONS = 1.5 gnits no-dependencies diff --git a/gl/m4/gnulib.m4 b/gl/m4/gnulib.m4 index 074e76e..7a975be 100644 --- a/gl/m4/gnulib.m4 +++ b/gl/m4/gnulib.m4 @@ -21,6 +21,7 @@ LTALLOCA=`echo "$ALLOCA" | sed 's/\.[^.]* /.lo /g;s/\.[^.]*$/.lo/'` changequote([, ])dnl AC_SUBST(LTALLOCA) gl_FUNC_ALLOCA + gl_VALGRIND_TESTS ]) dnl Usage: gl_MODULES(module1 module2 ...) diff --git a/gl/m4/valgrind-tests.m4 b/gl/m4/valgrind-tests.m4 new file mode 100644 index 0000000..66f81fb --- /dev/null +++ b/gl/m4/valgrind-tests.m4 @@ -0,0 +1,37 @@ +# valgrind-tests.m4 serial 3 +dnl Copyright (C) 2008-2013 Free Software Foundation, Inc. +dnl This file is free software; the Free Software Foundation +dnl gives unlimited permission to copy and/or distribute it, +dnl with or without modifications, as long as this notice is preserved. + +dnl From Simon Josefsson + +# gl_VALGRIND_TESTS() +# ------------------- +# Check if valgrind is available, and set VALGRIND to it if available. +AC_DEFUN([gl_VALGRIND_TESTS], +[ + AC_ARG_ENABLE(valgrind-tests, + AS_HELP_STRING([--enable-valgrind-tests], + [run self tests under valgrind]), + [opt_valgrind_tests=$enableval], [opt_valgrind_tests=yes]) + + # Run self-tests under valgrind? + if test "$opt_valgrind_tests" = "yes" && test "$cross_compiling" = no; then + AC_CHECK_PROGS(VALGRIND, valgrind) + fi + + OPTS="-q --error-exitcode=1 --leak-check=full" + + if test -n "$VALGRIND" \ + && $VALGRIND $OPTS $SHELL -c 'exit 0' > /dev/null 2>&1; then + opt_valgrind_tests=yes + VALGRIND="$VALGRIND $OPTS" + else + opt_valgrind_tests=no + VALGRIND= + fi + + AC_MSG_CHECKING([whether self tests are run under valgrind]) + AC_MSG_RESULT($opt_valgrind_tests) +]) diff --git a/tests/Makefile.am b/tests/Makefile.am index 013fb84..ae2ad4e 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -60,3 +60,5 @@ oidtranstbl.h: Makefile mkoidtbl.awk /usr/share ; do \ if test -f $$i/dumpasn1.cfg; then f=$$i/dumpasn1.cfg; break; fi; \ done; $(AWK) -f $(srcdir)/mkoidtbl.awk $$f >$@ + +LOG_COMPILER = $(VALGRIND) -- 2.0.0 From dbaryshkov at gmail.com Sat Jul 12 13:11:16 2014 From: dbaryshkov at gmail.com (Dmitry Eremin-Solenikov) Date: Sat, 12 Jul 2014 15:11:16 +0400 Subject: [PATCH libksba 4/7] Adapt mkoidtbl script to newer dumpasn1 database format In-Reply-To: <1405163479-10925-1-git-send-email-dbaryshkov@gmail.com> References: <1405163479-10925-1-git-send-email-dbaryshkov@gmail.com> Message-ID: <1405163479-10925-5-git-send-email-dbaryshkov@gmail.com> * tests/mkoidtbl.awk: optionally parse oid at OID line. -- Debian jessie currently has dumpasn1 version 20130608-1. It uses dumpasn1.cfg with slightly different format: OID = 0 2 262 1 10 Comment = Deutsche Telekom Description = Telesec Adapted mkoidtbl to work on both types of files. Signed-off-by: Dmitry Eremin-Solenikov --- tests/mkoidtbl.awk | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/tests/mkoidtbl.awk b/tests/mkoidtbl.awk index 70aae33..f6f827f 100644 --- a/tests/mkoidtbl.awk +++ b/tests/mkoidtbl.awk @@ -28,11 +28,15 @@ BEGIN { } /^[ \t]*#/ { next } -/^OID/ { flush() } +/^OID/ { flush() + oid = substr($0, index($0, "=") + 2) + gsub (/[ \t]+/, ".", oid) +} /^Comment/ { comment = substr($0, index($0, "=") + 2 ) gsub(/\r/, "", comment) gsub (/\\/, "\\\\", comment) gsub (/"/, "\\\"", comment) + gsub (/\(\?\?\?\)/, "(?)", comment) } /^Description/ { desc = substr($0, index($0, "=") + 2) @@ -40,11 +44,11 @@ BEGIN { if (match (desc, /\([0-9 \t]+\)/) > 2) { oid = substr(desc, RSTART+1, RLENGTH-2 ) desc = substr(desc, 1, RSTART-1); - gsub (/[ \t]+/, ".", oid) - gsub (/\\/, "\\\\", desc) - gsub (/"/, "\\\"", desc) - sub (/[ \t]*$/, "", desc) } + gsub (/[ \t]+/, ".", oid) + gsub (/\\/, "\\\\", desc) + gsub (/"/, "\\\"", desc) + sub (/[ \t]*$/, "", desc) } END { flush(); print " { NULL, NULL, NULL }\n};" } -- 2.0.0 From dbaryshkov at gmail.com Sat Jul 12 23:36:11 2014 From: dbaryshkov at gmail.com (Dmitry Eremin-Solenikov) Date: Sun, 13 Jul 2014 01:36:11 +0400 Subject: [ksba] selecting between oids in cryptval_from_sexp Message-ID: Hello, I'm playing with GOST 34.10/34.11 support in libksba. Most of the things are in place. However I have the following issue. Public key representation of GOST keys use different OIDs to identify the key depending on the 'version' and 'variant' of standards it is used with. These variants can be distinguished using 'digest' OID/string parameter in the public-key sexp. However I don't see an easy way to find the value of that parameter when selecting a corresponding entry in pk_algo_table. Werner, would you recommend any sane approach? Or I should look through passed sexp till I find the 'digest' string and then to look up for passed digest? -- With best wishes Dmitry From simon at josefsson.org Wed Jul 16 21:53:20 2014 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 16 Jul 2014 21:53:20 +0200 Subject: [PATCH] Add OpenPGP card manufacturer Yubico (6). Message-ID: <87vbqxcc7j.fsf@latte.josefsson.org> Hi. Would you consider adding this patch on STABLE-BRANCH-2-0? Yubico is now shipping NEOs with an OpenPGP applet initialized with proper serial numbers, and while a similar patch has been applied to the master branch, nobody uses that, so I would appreciated if this could be practically backported by applying this patch. It looks a bit less confusing for users. Thanks, /Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-OpenPGP-card-manufacturer-Yubico-6.patch Type: text/x-diff Size: 658 bytes Desc: not available URL: From andreas.schwier.ml at cardcontact.de Mon Jul 21 10:15:24 2014 From: andreas.schwier.ml at cardcontact.de (Andreas Schwier) Date: Mon, 21 Jul 2014 10:15:24 +0200 Subject: Fwd: APDU buffer in pcsc-wrapper too short In-Reply-To: <53C94BFA.7020903@cardcontact.de> References: <53C94BFA.7020903@cardcontact.de> Message-ID: <53CCCC1C.5090009@cardcontact.de> Sorry, picked the wrong list initially. -------- Original Message -------- Subject: APDU buffer in pcsc-wrapper too short Date: Fri, 18 Jul 2014 18:31:54 +0200 From: Andreas Schwier To: gnupg-users at gnupg.org While scd/apdu.c assumes a maximum length of 4096 byte for an extended length APDU, scd/pcsc-wrapper allocates only 1024 byte for the response. As most certificates are larger than 1024, reading them with extended length fails. The attached patch fixes the buffer size. Andreas -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-pcsc-Enlarged-APDU-buffer-to-4096-as-most-certificat.patch Type: text/x-diff Size: 770 bytes Desc: not available URL: From andreas.schwier.ml at cardcontact.de Mon Jul 21 10:13:58 2014 From: andreas.schwier.ml at cardcontact.de (Andreas Schwier) Date: Mon, 21 Jul 2014 10:13:58 +0200 Subject: Fwd: scdaemon support for SmartCard-HSM In-Reply-To: <53C932DA.9030903@cardcontact.de> References: <53C932DA.9030903@cardcontact.de> Message-ID: <53CCCBC6.9080906@cardcontact.de> Sorry, posted this to the wrong list. The third issue we've already resolved. Apparently kleopatra works with any card supported by scdaemon. It just supports some additional PIN functions for TCOS cards, not available for others. Andreas -------- Original Message -------- Subject: scdaemon support for SmartCard-HSM Date: Fri, 18 Jul 2014 16:44:42 +0200 From: Andreas Schwier To: gnupg-users at gnupg.org Hi list, we've added support for the SmartCard-HSM to scdaemon. Please find the patch that applies to master at [1]. The driver allows read/only operations with keys and certificates on a SmartCard-HSM. To generate keys and certificates please use OpenSC, XCA or the tools in OpenSCDP. There are three issues left that we couldn't resolve 1. Signing with ECDSA: Apparently gpgsm puts the wrongs (RSAEncryption) algorithm identifier in SignerInfo when using ECDSA. As a result verification of the CMS fails with "conflicting use". 2. At least on Kubuntu the PIN callback to prompt the user to enter the PIN at the reader PIN PAD does not work. gpgsm is reporting an invalid IPC call. Working directly with scdaemon does not have the problem. 3. Apparently kleopatra only support TCOS card. It's unclear to my why this restriction is in place. Andreas [1] http://www.cardcontact.de/download/0001-sc-hsm-Add-support-for-SmartCard-HSM.patch _______________________________________________ Gnupg-users mailing list Gnupg-users at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users From wk at gnupg.org Mon Jul 21 16:05:58 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 21 Jul 2014 16:05:58 +0200 Subject: [PATCH] Add OpenPGP card manufacturer Yubico (6). In-Reply-To: <87vbqxcc7j.fsf@latte.josefsson.org> (Simon Josefsson's message of "Wed, 16 Jul 2014 21:53:20 +0200") References: <87vbqxcc7j.fsf@latte.josefsson.org> Message-ID: <87oawi4xix.fsf@vigenere.g10code.de> On Wed, 16 Jul 2014 21:53, simon at josefsson.org said: > Would you consider adding this patch on STABLE-BRANCH-2-0? Yubico is Done. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Jul 21 16:11:19 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 21 Jul 2014 16:11:19 +0200 Subject: gpgsm, certgen example and de.po fix In-Reply-To: <201407071542.36913.bernhard@intevation.de> (Bernhard Reiter's message of "Mon, 7 Jul 2014 15:42:30 +0200") References: <201407071542.36913.bernhard@intevation.de> Message-ID: <87k3764xa0.fsf@vigenere.g10code.de> On Mon, 7 Jul 2014 15:42, bernhard at intevation.de said: > I've noticed a translation slip and I suggest to add an example Thanks. > for the DN value for gpgsm --gen-keys. There is no real standard for X.509 names thus an examples does not make much sense. Those who want to use X.509 should need to get a template for the name anyway from their organization. gpgsm has a syntax checker and marks obvious errors in the name. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Jul 21 16:40:13 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 21 Jul 2014 16:40:13 +0200 Subject: [PATCH libksba 0/7] Several bugfixes In-Reply-To: <1405163479-10925-1-git-send-email-dbaryshkov@gmail.com> (Dmitry Eremin-Solenikov's message of "Sat, 12 Jul 2014 15:11:12 +0400") References: <1405163479-10925-1-git-send-email-dbaryshkov@gmail.com> Message-ID: <87fvhu4vxu.fsf@vigenere.g10code.de> On Sat, 12 Jul 2014 13:11, dbaryshkov at gmail.com said: > I would like to propose several bugfix patches to libksba. If I need to sign > a DCO, please point me to it - I could not find any information in libksba > sources. Not needed - I never cared about this. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From kristian.fiskerstrand at sumptuouscapital.com Mon Jul 21 17:54:06 2014 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Mon, 21 Jul 2014 17:54:06 +0200 Subject: libksba build issue for gpl.texi Message-ID: <53CD379E.4060102@sumptuouscapital.com> Hi, Trying to build libkasba git master on my system results in the following error on my system: ./gpl.texi:668: @unnumberedsec seen before @end enumerate ./gpl.texi:725: unmatched `@end enumerate' make[2]: *** [ksba.info] Error 1 Patching it to use the same gpl.texi file as found in gnupg git master fixes the issue. -- ---------------------------- Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- "Statistics are like a bikini. What they reveal is suggestive, but what they conceal is vital." (Aaron Levenstein) -------------- next part -------------- A non-text attachment was scrubbed... Name: 001_fix_gpl-texi.patch Type: text/x-patch Size: 2318 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Tue Jul 22 09:28:04 2014 From: wk at gnupg.org (Werner Koch) Date: Tue, 22 Jul 2014 09:28:04 +0200 Subject: [PATCH libksba 0/7] Several bugfixes In-Reply-To: <1405163479-10925-1-git-send-email-dbaryshkov@gmail.com> (Dmitry Eremin-Solenikov's message of "Sat, 12 Jul 2014 15:11:12 +0400") References: <1405163479-10925-1-git-send-email-dbaryshkov@gmail.com> Message-ID: <87tx69zwcb.fsf@vigenere.g10code.de> On Sat, 12 Jul 2014 13:11, dbaryshkov at gmail.com said: > I would like to propose several bugfix patches to libksba. If I need to sign All pushed. Thanks. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From bernhard at intevation.de Tue Jul 22 10:28:43 2014 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 22 Jul 2014 10:28:43 +0200 Subject: gpgsm, certgen example and de.po fix In-Reply-To: <87k3764xa0.fsf@vigenere.g10code.de> References: <201407071542.36913.bernhard@intevation.de> <87k3764xa0.fsf@vigenere.g10code.de> Message-ID: <201407221028.52775.bernhard@intevation.de> On Monday 21 July 2014 at 16:11:19, Werner Koch wrote: > On Mon, 7 Jul 2014 15:42, bernhard at intevation.de said: > There is no real standard for X.509 names thus an examples does not make > much sense. Those who want to use X.509 should need to get a template > for the name anyway from their organization. gpgsm has a syntax checker > and marks obvious errors in the name. In my experience there are two commonly used patterns a) using the organisational hierarchy b) using the domain name hierarchy You'll find them in standard LDAP schemas. I'm suggesting the change, because while trying this myself, I was unsure at this point, about what to enter. I consider this an indication that more help for the user is useful. And giving an example would be similiar to how it is done in OpenPGP. Maybe the message can be made even more instructive like (_("Enter the X.509 subject name (the DN as required from your CA)\n" "(for example \"cn=Heinrich Heine,o=example,c=org\"):")); Bernhard -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998 Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3955 bytes Desc: not available URL: From bernhard at intevation.de Tue Jul 22 10:52:59 2014 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 22 Jul 2014 10:52:59 +0200 Subject: FAQ: Re: key length In-Reply-To: <53AB4031.4060300@sixdemonbag.org> References: <53AB4031.4060300@sixdemonbag.org> Message-ID: <201407221053.04687.bernhard@intevation.de> Robert, On Wednesday 25 June 2014 at 23:33:37, Robert J. Hansen wrote: > > we (GPGTools) had a brief meetup with Nico (he?s contributing to > > Enigmail) today. He suggested raising the key length default to 4096bit. > > The idea came via a suggestion from R?diger Wei? on the 30C3 congress > > (https://www.youtube.com/watch?v=1dhCDJ_LVuY). > > As Werner himself posted to GnuPG-Users just yesterday, 4096-bit is > wildly unnecessary for the vast majority of users. In fact, there's a > FAQ on it: > > https://www.gnupg.org/faq/gnupg-faq.html#no_default_of_rsa4096 Because this really is requently asked, I think this answer can be improved by a) putting date on the answer itself b) providing more references that support the design decision. > Please don't override the GnuPG defaults unless you have a clear and > compelling reason for why RSA-2048 (the GnuPG default) is inappropriate > for your users. Note that ENISA recommends at least 3072 bit RSA for new systems (as reported by heise). http://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/algorithms-key-sizes-and-parameters-report Also the German BSI in TR-02102-2-1 (Jan 2014) has 2000 bit RSA keys until 2020 and remarks that it can be useful to use >3000 bit to have an evenly distributed security level. Given that 3072 is recommended by ENISA and by the BSI under some circumstances today, users need good insights to understand the 2048 default of GnuPG. Best, Bernhard -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998 Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Tue Jul 22 13:28:46 2014 From: wk at gnupg.org (Werner Koch) Date: Tue, 22 Jul 2014 13:28:46 +0200 Subject: FAQ: Re: key length In-Reply-To: <201407221053.04687.bernhard@intevation.de> (Bernhard Reiter's message of "Tue, 22 Jul 2014 10:52:59 +0200") References: <53AB4031.4060300@sixdemonbag.org> <201407221053.04687.bernhard@intevation.de> Message-ID: <8738dtzl75.fsf@vigenere.g10code.de> On Tue, 22 Jul 2014 10:52, bernhard at intevation.de said: > Note that ENISA recommends at least 3072 bit RSA for new systems > (as reported by heise). It might be worth to question whether an organization with strong ties to the British, French and German [1] executives has reasons to lure citizens in false security by marketing very strong key sizes but not demanding the use of fully verifiable systems to store and use such keys. Salam-Shalom, Werner [1] Although known as a member of the Fourteen Eyes, I would not be surprised if Germany or the BND is more a hidden Six Eye. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Jul 22 14:10:14 2014 From: wk at gnupg.org (Werner Koch) Date: Tue, 22 Jul 2014 14:10:14 +0200 Subject: gpgsm, certgen example and de.po fix In-Reply-To: <201407221028.52775.bernhard@intevation.de> (Bernhard Reiter's message of "Tue, 22 Jul 2014 10:28:43 +0200") References: <201407071542.36913.bernhard@intevation.de> <87k3764xa0.fsf@vigenere.g10code.de> <201407221028.52775.bernhard@intevation.de> Message-ID: <87tx69y4pl.fsf@vigenere.g10code.de> On Tue, 22 Jul 2014 10:28, bernhard at intevation.de said: > In my experience there are two commonly used patterns > a) using the organisational hierarchy > b) using the domain name hierarchy I am pretty sure that the mostly used pattern is CN=host.example.org which is what you need for a CSR to setup a TLS server. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From andreas.schwier.ml at cardcontact.de Tue Jul 22 23:04:24 2014 From: andreas.schwier.ml at cardcontact.de (Andreas Schwier) Date: Tue, 22 Jul 2014 23:04:24 +0200 Subject: Revised patch to support the SmartCard-HSM in scdaemon Message-ID: <53CED1D8.1010306@cardcontact.de> Dear list, please find attached [1] the revised patch to GnuPG master, adding support for the SmartCard-HSM to scdaemon. The patch differs from the previous patch only in editorial changes (line length, copyright notice, spelling in comments, compiler warning) GnuPG Developer's Certificate of Origin. Version 1.0 ===================================================== By making a contribution to the GnuPG project, I certify that: (a) The contribution was created in whole or in part by me and I have the right to submit it under the free software license indicated in the file; or (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate free software license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same free software license (unless I am permitted to submit under a different license), as indicated in the file; or (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the free software license(s) involved. Signed-off-by: Andreas Schwier [1] http://www.cardcontact.de/download/0001-scd-Support-for-SmartCard-HSM.patch From rjh at sixdemonbag.org Thu Jul 24 04:25:09 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 23 Jul 2014 22:25:09 -0400 Subject: FAQ: Re: key length In-Reply-To: <201407221053.04687.bernhard@intevation.de> References: <53AB4031.4060300@sixdemonbag.org> <201407221053.04687.bernhard@intevation.de> Message-ID: <53D06E85.7080903@sixdemonbag.org> > Robert, I think your proposal is quite sensible. I'm busy as can be this week (job interviews, a wedding, a flight cross-country, and then a 1000km road trip), but I'll try to get something written up and I'll present it for community comment. From rjh at sixdemonbag.org Thu Jul 24 12:02:46 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 24 Jul 2014 06:02:46 -0400 Subject: FAQ: Re: key length In-Reply-To: <53D06E85.7080903@sixdemonbag.org> References: <53AB4031.4060300@sixdemonbag.org> <201407221053.04687.bernhard@intevation.de> <53D06E85.7080903@sixdemonbag.org> Message-ID: <53D0D9C6.1080807@sixdemonbag.org> This is just a proposal, *not* a final draft. If this gives people heartburn, let me know precisely what gives heartburn and I'll try to mitigate it as best as I can. Q: Why does GnuPG default to 2048-bit RSA? A: Because it offers reasonable security for the next several years while still being compatible with the widest variety of OpenPGP installations. Q: What are NIST's recommendations for key sizes? A: According to NIST Special Publication 800-57, "Recommendation for Key Management," published in July 2012, a 2048-bit RSA or DSA key is comparable in strength to 3DES. Further, they state that 2048-bit keys are acceptable for use through the year 2030. Q: What are ENISA's recommendations for key sizes? A: Slightly different, but not so much so as to be surprising. ENISA is slightly more pessimistic about the long-term prospects of 2048-bit keys, although they are careful to note 2048-bit keys are still daunting for an adversary. Q: Is there a general recommendation that 3072-bit keys be used for new applications? A: No, although some respected people and groups within the cryptographic community have made such recommendations. Q: Why does GnuPG disregard these recommendations for 3072-bit keys? A: We don't. That recommendation is for *new applications*. GnuPG is not a new application. When a user generates a GnuPG certificate, that user becomes part of an ecosystem of existing certificates and a userbase that spans the globe. In short, GnuPG is not a new application. Q: Are there any plans to move to stronger keys by default? A: Imminently. When a version of GnuPG is released which supports elliptical-curve cryptography, then will be an ideal time for us to pause, take a deep breath, and make the transition to larger effective key sizes. Q: I think I need larger key sizes. A: By all means, feel free to generate certificates with larger keys. GnuPG supports up to 4096-bit keys. Q: If GnuPG will be moving to stronger default key sizes in the near future via support for elliptical curves, why is there such controversy about what GnuPG's defaults are right now? A: It's human nature to want things "more, better, and right now." But just like in the rest of life, good things come to those who wait. It won't be long, we promise. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3744 bytes Desc: S/MIME Cryptographic Signature URL: From wk at gnupg.org Fri Jul 25 11:14:04 2014 From: wk at gnupg.org (Werner Koch) Date: Fri, 25 Jul 2014 11:14:04 +0200 Subject: Revised patch to support the SmartCard-HSM in scdaemon In-Reply-To: <53CED1D8.1010306@cardcontact.de> (Andreas Schwier's message of "Tue, 22 Jul 2014 23:04:24 +0200") References: <53CED1D8.1010306@cardcontact.de> Message-ID: <87ppgtu7fn.fsf@vigenere.g10code.de> On Tue, 22 Jul 2014 23:04, andreas.schwier.ml at cardcontact.de said: > please find attached [1] the revised patch to GnuPG master, adding > support for the SmartCard-HSM to scdaemon. Thanks. I applied the patch and did some minor editorial changes. I have not yet found the time to look at all parts. Unchecked code is marked with a warning pragma. Many thanks for sample cards. I have not yet opened the token; is that a custom version of the SCR3512 with a non replaceable ID-000 card or has the smartcard chip been soldered directly to the PCB? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Sat Jul 26 01:00:42 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 25 Jul 2014 19:00:42 -0400 Subject: [PATCH] add new lock-obj-pub.*.h from debian buildds In-Reply-To: <20140721053203.GA6719@alf.mars> References: <20140721053203.GA6719@alf.mars> Message-ID: <1406329242-3323-1-git-send-email-dkg@fifthhorseman.net> To generate these: pull all the logs stored under the "install" links from: https://buildd.debian.org/status/package.php?p=libgpg-error&suite=unstable https://buildd.debian-ports.org/status/package.php?p=libgpg-error&suite=unstable and then extract the headers via: for x in fetch*; do awk '/^## lock-obj-pub\..*\.h$/{ X=2 } { if (X > 0) { print $0 } } /^##$/{ X = X-1 } ' < "$x" >tmp mv -f tmp $( head -n1 < tmp | cut -f2 -d\ ) done --- .../lock-obj-pub.aarch64-unknown-linux-gnu.h | 26 ++++++++++++++++++++++ src/syscfg/lock-obj-pub.alpha-unknown-linux-gnu.h | 25 +++++++++++++++++++++ .../lock-obj-pub.arm-unknown-linux-gnueabi.h | 23 +++++++++++++++++++ .../lock-obj-pub.arm-unknown-linux-gnueabihf.h | 23 +++++++++++++++++++ src/syscfg/lock-obj-pub.hppa-unknown-linux-gnu.h | 26 ++++++++++++++++++++++ src/syscfg/lock-obj-pub.i486-pc-gnu.h | 24 ++++++++++++++++++++ src/syscfg/lock-obj-pub.i486-pc-kfreebsd-gnu.h | 23 +++++++++++++++++++ src/syscfg/lock-obj-pub.i486-pc-linux-gnu.h | 23 +++++++++++++++++++ src/syscfg/lock-obj-pub.m68k-unknown-linux-gnu.h | 23 +++++++++++++++++++ src/syscfg/lock-obj-pub.mips-unknown-linux-gnu.h | 23 +++++++++++++++++++ src/syscfg/lock-obj-pub.mipsel-unknown-linux-gnu.h | 23 +++++++++++++++++++ .../lock-obj-pub.powerpc-unknown-linux-gnu.h | 23 +++++++++++++++++++ .../lock-obj-pub.powerpc64-unknown-linux-gnu.h | 25 +++++++++++++++++++++ src/syscfg/lock-obj-pub.s390x-ibm-linux-gnu.h | 25 +++++++++++++++++++++ src/syscfg/lock-obj-pub.sh4-unknown-linux-gnu.h | 23 +++++++++++++++++++ src/syscfg/lock-obj-pub.sparc-unknown-linux-gnu.h | 23 +++++++++++++++++++ src/syscfg/lock-obj-pub.x86_64-pc-kfreebsd-gnu.h | 25 +++++++++++++++++++++ src/syscfg/lock-obj-pub.x86_64-pc-linux-gnu.h | 25 +++++++++++++++++++++ src/syscfg/lock-obj-pub.x86_64-pc-linux-gnux32.h | 24 ++++++++++++++++++++ 19 files changed, 455 insertions(+) create mode 100644 src/syscfg/lock-obj-pub.aarch64-unknown-linux-gnu.h create mode 100644 src/syscfg/lock-obj-pub.alpha-unknown-linux-gnu.h create mode 100644 src/syscfg/lock-obj-pub.arm-unknown-linux-gnueabi.h create mode 100644 src/syscfg/lock-obj-pub.arm-unknown-linux-gnueabihf.h create mode 100644 src/syscfg/lock-obj-pub.hppa-unknown-linux-gnu.h create mode 100644 src/syscfg/lock-obj-pub.i486-pc-gnu.h create mode 100644 src/syscfg/lock-obj-pub.i486-pc-kfreebsd-gnu.h create mode 100644 src/syscfg/lock-obj-pub.i486-pc-linux-gnu.h create mode 100644 src/syscfg/lock-obj-pub.m68k-unknown-linux-gnu.h create mode 100644 src/syscfg/lock-obj-pub.mips-unknown-linux-gnu.h create mode 100644 src/syscfg/lock-obj-pub.mipsel-unknown-linux-gnu.h create mode 100644 src/syscfg/lock-obj-pub.powerpc-unknown-linux-gnu.h create mode 100644 src/syscfg/lock-obj-pub.powerpc64-unknown-linux-gnu.h create mode 100644 src/syscfg/lock-obj-pub.s390x-ibm-linux-gnu.h create mode 100644 src/syscfg/lock-obj-pub.sh4-unknown-linux-gnu.h create mode 100644 src/syscfg/lock-obj-pub.sparc-unknown-linux-gnu.h create mode 100644 src/syscfg/lock-obj-pub.x86_64-pc-kfreebsd-gnu.h create mode 100644 src/syscfg/lock-obj-pub.x86_64-pc-linux-gnu.h create mode 100644 src/syscfg/lock-obj-pub.x86_64-pc-linux-gnux32.h diff --git a/src/syscfg/lock-obj-pub.aarch64-unknown-linux-gnu.h b/src/syscfg/lock-obj-pub.aarch64-unknown-linux-gnu.h new file mode 100644 index 0000000..adf10fc --- /dev/null +++ b/src/syscfg/lock-obj-pub.aarch64-unknown-linux-gnu.h @@ -0,0 +1,26 @@ +## lock-obj-pub.aarch64-unknown-linux-gnu.h +## File created by gen-posix-lock-obj - DO NOT EDIT +## To be included by mkheader into gpg-error.h + +typedef struct +{ + long _vers; + union { + volatile char _priv[48]; + long _x_align; + long *_xp_align; + } u; +} gpgrt_lock_t; + +#define GPGRT_LOCK_INITIALIZER {1,{{0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0}}} +## +## Local Variables: +## mode: c +## buffer-read-only: t +## End: +## diff --git a/src/syscfg/lock-obj-pub.alpha-unknown-linux-gnu.h b/src/syscfg/lock-obj-pub.alpha-unknown-linux-gnu.h new file mode 100644 index 0000000..80ddf01 --- /dev/null +++ b/src/syscfg/lock-obj-pub.alpha-unknown-linux-gnu.h @@ -0,0 +1,25 @@ +## lock-obj-pub.alpha-unknown-linux-gnu.h +## File created by gen-posix-lock-obj - DO NOT EDIT +## To be included by mkheader into gpg-error.h + +typedef struct +{ + long _vers; + union { + volatile char _priv[40]; + long _x_align; + long *_xp_align; + } u; +} gpgrt_lock_t; + +#define GPGRT_LOCK_INITIALIZER {1,{{0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0}}} +## +## Local Variables: +## mode: c +## buffer-read-only: t +## End: +## diff --git a/src/syscfg/lock-obj-pub.arm-unknown-linux-gnueabi.h b/src/syscfg/lock-obj-pub.arm-unknown-linux-gnueabi.h new file mode 100644 index 0000000..7a92276 --- /dev/null +++ b/src/syscfg/lock-obj-pub.arm-unknown-linux-gnueabi.h @@ -0,0 +1,23 @@ +## lock-obj-pub.arm-unknown-linux-gnueabi.h +## File created by gen-posix-lock-obj - DO NOT EDIT +## To be included by mkheader into gpg-error.h + +typedef struct +{ + long _vers; + union { + volatile char _priv[24]; + long _x_align; + long *_xp_align; + } u; +} gpgrt_lock_t; + +#define GPGRT_LOCK_INITIALIZER {1,{{0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0}}} +## +## Local Variables: +## mode: c +## buffer-read-only: t +## End: +## diff --git a/src/syscfg/lock-obj-pub.arm-unknown-linux-gnueabihf.h b/src/syscfg/lock-obj-pub.arm-unknown-linux-gnueabihf.h new file mode 100644 index 0000000..6636400 --- /dev/null +++ b/src/syscfg/lock-obj-pub.arm-unknown-linux-gnueabihf.h @@ -0,0 +1,23 @@ +## lock-obj-pub.arm-unknown-linux-gnueabihf.h +## File created by gen-posix-lock-obj - DO NOT EDIT +## To be included by mkheader into gpg-error.h + +typedef struct +{ + long _vers; + union { + volatile char _priv[24]; + long _x_align; + long *_xp_align; + } u; +} gpgrt_lock_t; + +#define GPGRT_LOCK_INITIALIZER {1,{{0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0}}} +## +## Local Variables: +## mode: c +## buffer-read-only: t +## End: +## diff --git a/src/syscfg/lock-obj-pub.hppa-unknown-linux-gnu.h b/src/syscfg/lock-obj-pub.hppa-unknown-linux-gnu.h new file mode 100644 index 0000000..fd47664 --- /dev/null +++ b/src/syscfg/lock-obj-pub.hppa-unknown-linux-gnu.h @@ -0,0 +1,26 @@ +## lock-obj-pub.hppa-unknown-linux-gnu.h +## File created by gen-posix-lock-obj - DO NOT EDIT +## To be included by mkheader into gpg-error.h + +typedef struct +{ + long _vers; + union { + volatile char _priv[48]; + long _x_align; + long *_xp_align; + } u; +} gpgrt_lock_t; + +#define GPGRT_LOCK_INITIALIZER {1,{{0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0}}} +## +## Local Variables: +## mode: c +## buffer-read-only: t +## End: +## diff --git a/src/syscfg/lock-obj-pub.i486-pc-gnu.h b/src/syscfg/lock-obj-pub.i486-pc-gnu.h new file mode 100644 index 0000000..59b61e1 --- /dev/null +++ b/src/syscfg/lock-obj-pub.i486-pc-gnu.h @@ -0,0 +1,24 @@ +## lock-obj-pub.i486-pc-gnu.h +## File created by gen-posix-lock-obj - DO NOT EDIT +## To be included by mkheader into gpg-error.h + +typedef struct +{ + long _vers; + union { + volatile char _priv[32]; + long _x_align; + long *_xp_align; + } u; +} gpgrt_lock_t; + +#define GPGRT_LOCK_INITIALIZER {1,{{0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0}}} +## +## Local Variables: +## mode: c +## buffer-read-only: t +## End: +## diff --git a/src/syscfg/lock-obj-pub.i486-pc-kfreebsd-gnu.h b/src/syscfg/lock-obj-pub.i486-pc-kfreebsd-gnu.h new file mode 100644 index 0000000..8a680d1 --- /dev/null +++ b/src/syscfg/lock-obj-pub.i486-pc-kfreebsd-gnu.h @@ -0,0 +1,23 @@ +## lock-obj-pub.i486-pc-kfreebsd-gnu.h +## File created by gen-posix-lock-obj - DO NOT EDIT +## To be included by mkheader into gpg-error.h + +typedef struct +{ + long _vers; + union { + volatile char _priv[24]; + long _x_align; + long *_xp_align; + } u; +} gpgrt_lock_t; + +#define GPGRT_LOCK_INITIALIZER {1,{{0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0}}} +## +## Local Variables: +## mode: c +## buffer-read-only: t +## End: +## diff --git a/src/syscfg/lock-obj-pub.i486-pc-linux-gnu.h b/src/syscfg/lock-obj-pub.i486-pc-linux-gnu.h new file mode 100644 index 0000000..f1849c4 --- /dev/null +++ b/src/syscfg/lock-obj-pub.i486-pc-linux-gnu.h @@ -0,0 +1,23 @@ +## lock-obj-pub.i486-pc-linux-gnu.h +## File created by gen-posix-lock-obj - DO NOT EDIT +## To be included by mkheader into gpg-error.h + +typedef struct +{ + long _vers; + union { + volatile char _priv[24]; + long _x_align; + long *_xp_align; + } u; +} gpgrt_lock_t; + +#define GPGRT_LOCK_INITIALIZER {1,{{0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0}}} +## +## Local Variables: +## mode: c +## buffer-read-only: t +## End: +## diff --git a/src/syscfg/lock-obj-pub.m68k-unknown-linux-gnu.h b/src/syscfg/lock-obj-pub.m68k-unknown-linux-gnu.h new file mode 100644 index 0000000..3788797 --- /dev/null +++ b/src/syscfg/lock-obj-pub.m68k-unknown-linux-gnu.h @@ -0,0 +1,23 @@ +## lock-obj-pub.m68k-unknown-linux-gnu.h +## File created by gen-posix-lock-obj - DO NOT EDIT +## To be included by mkheader into gpg-error.h + +typedef struct +{ + long _vers; + union { + volatile char _priv[24]; + long _x_align; + long *_xp_align; + } u; +} gpgrt_lock_t; + +#define GPGRT_LOCK_INITIALIZER {1,{{0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0}}} +## +## Local Variables: +## mode: c +## buffer-read-only: t +## End: +## diff --git a/src/syscfg/lock-obj-pub.mips-unknown-linux-gnu.h b/src/syscfg/lock-obj-pub.mips-unknown-linux-gnu.h new file mode 100644 index 0000000..b31206e --- /dev/null +++ b/src/syscfg/lock-obj-pub.mips-unknown-linux-gnu.h @@ -0,0 +1,23 @@ +## lock-obj-pub.mips-unknown-linux-gnu.h +## File created by gen-posix-lock-obj - DO NOT EDIT +## To be included by mkheader into gpg-error.h + +typedef struct +{ + long _vers; + union { + volatile char _priv[24]; + long _x_align; + long *_xp_align; + } u; +} gpgrt_lock_t; + +#define GPGRT_LOCK_INITIALIZER {1,{{0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0}}} +## +## Local Variables: +## mode: c +## buffer-read-only: t +## End: +## diff --git a/src/syscfg/lock-obj-pub.mipsel-unknown-linux-gnu.h b/src/syscfg/lock-obj-pub.mipsel-unknown-linux-gnu.h new file mode 100644 index 0000000..3a24571 --- /dev/null +++ b/src/syscfg/lock-obj-pub.mipsel-unknown-linux-gnu.h @@ -0,0 +1,23 @@ +## lock-obj-pub.mipsel-unknown-linux-gnu.h +## File created by gen-posix-lock-obj - DO NOT EDIT +## To be included by mkheader into gpg-error.h + +typedef struct +{ + long _vers; + union { + volatile char _priv[24]; + long _x_align; + long *_xp_align; + } u; +} gpgrt_lock_t; + +#define GPGRT_LOCK_INITIALIZER {1,{{0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0}}} +## +## Local Variables: +## mode: c +## buffer-read-only: t +## End: +## diff --git a/src/syscfg/lock-obj-pub.powerpc-unknown-linux-gnu.h b/src/syscfg/lock-obj-pub.powerpc-unknown-linux-gnu.h new file mode 100644 index 0000000..6601bc9 --- /dev/null +++ b/src/syscfg/lock-obj-pub.powerpc-unknown-linux-gnu.h @@ -0,0 +1,23 @@ +## lock-obj-pub.powerpc-unknown-linux-gnu.h +## File created by gen-posix-lock-obj - DO NOT EDIT +## To be included by mkheader into gpg-error.h + +typedef struct +{ + long _vers; + union { + volatile char _priv[24]; + long _x_align; + long *_xp_align; + } u; +} gpgrt_lock_t; + +#define GPGRT_LOCK_INITIALIZER {1,{{0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0}}} +## +## Local Variables: +## mode: c +## buffer-read-only: t +## End: +## diff --git a/src/syscfg/lock-obj-pub.powerpc64-unknown-linux-gnu.h b/src/syscfg/lock-obj-pub.powerpc64-unknown-linux-gnu.h new file mode 100644 index 0000000..635e6eb --- /dev/null +++ b/src/syscfg/lock-obj-pub.powerpc64-unknown-linux-gnu.h @@ -0,0 +1,25 @@ +## lock-obj-pub.powerpc64-unknown-linux-gnu.h +## File created by gen-posix-lock-obj - DO NOT EDIT +## To be included by mkheader into gpg-error.h + +typedef struct +{ + long _vers; + union { + volatile char _priv[40]; + long _x_align; + long *_xp_align; + } u; +} gpgrt_lock_t; + +#define GPGRT_LOCK_INITIALIZER {1,{{0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0}}} +## +## Local Variables: +## mode: c +## buffer-read-only: t +## End: +## diff --git a/src/syscfg/lock-obj-pub.s390x-ibm-linux-gnu.h b/src/syscfg/lock-obj-pub.s390x-ibm-linux-gnu.h new file mode 100644 index 0000000..70f6e33 --- /dev/null +++ b/src/syscfg/lock-obj-pub.s390x-ibm-linux-gnu.h @@ -0,0 +1,25 @@ +## lock-obj-pub.s390x-ibm-linux-gnu.h +## File created by gen-posix-lock-obj - DO NOT EDIT +## To be included by mkheader into gpg-error.h + +typedef struct +{ + long _vers; + union { + volatile char _priv[40]; + long _x_align; + long *_xp_align; + } u; +} gpgrt_lock_t; + +#define GPGRT_LOCK_INITIALIZER {1,{{0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0}}} +## +## Local Variables: +## mode: c +## buffer-read-only: t +## End: +## diff --git a/src/syscfg/lock-obj-pub.sh4-unknown-linux-gnu.h b/src/syscfg/lock-obj-pub.sh4-unknown-linux-gnu.h new file mode 100644 index 0000000..eb62ba3 --- /dev/null +++ b/src/syscfg/lock-obj-pub.sh4-unknown-linux-gnu.h @@ -0,0 +1,23 @@ +## lock-obj-pub.sh4-unknown-linux-gnu.h +## File created by gen-posix-lock-obj - DO NOT EDIT +## To be included by mkheader into gpg-error.h + +typedef struct +{ + long _vers; + union { + volatile char _priv[24]; + long _x_align; + long *_xp_align; + } u; +} gpgrt_lock_t; + +#define GPGRT_LOCK_INITIALIZER {1,{{0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0}}} +## +## Local Variables: +## mode: c +## buffer-read-only: t +## End: +## diff --git a/src/syscfg/lock-obj-pub.sparc-unknown-linux-gnu.h b/src/syscfg/lock-obj-pub.sparc-unknown-linux-gnu.h new file mode 100644 index 0000000..2748b26 --- /dev/null +++ b/src/syscfg/lock-obj-pub.sparc-unknown-linux-gnu.h @@ -0,0 +1,23 @@ +## lock-obj-pub.sparc-unknown-linux-gnu.h +## File created by gen-posix-lock-obj - DO NOT EDIT +## To be included by mkheader into gpg-error.h + +typedef struct +{ + long _vers; + union { + volatile char _priv[24]; + long _x_align; + long *_xp_align; + } u; +} gpgrt_lock_t; + +#define GPGRT_LOCK_INITIALIZER {1,{{0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0}}} +## +## Local Variables: +## mode: c +## buffer-read-only: t +## End: +## diff --git a/src/syscfg/lock-obj-pub.x86_64-pc-kfreebsd-gnu.h b/src/syscfg/lock-obj-pub.x86_64-pc-kfreebsd-gnu.h new file mode 100644 index 0000000..7fb596c --- /dev/null +++ b/src/syscfg/lock-obj-pub.x86_64-pc-kfreebsd-gnu.h @@ -0,0 +1,25 @@ +## lock-obj-pub.x86_64-pc-kfreebsd-gnu.h +## File created by gen-posix-lock-obj - DO NOT EDIT +## To be included by mkheader into gpg-error.h + +typedef struct +{ + long _vers; + union { + volatile char _priv[40]; + long _x_align; + long *_xp_align; + } u; +} gpgrt_lock_t; + +#define GPGRT_LOCK_INITIALIZER {1,{{0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0}}} +## +## Local Variables: +## mode: c +## buffer-read-only: t +## End: +## diff --git a/src/syscfg/lock-obj-pub.x86_64-pc-linux-gnu.h b/src/syscfg/lock-obj-pub.x86_64-pc-linux-gnu.h new file mode 100644 index 0000000..0dd6431 --- /dev/null +++ b/src/syscfg/lock-obj-pub.x86_64-pc-linux-gnu.h @@ -0,0 +1,25 @@ +## lock-obj-pub.x86_64-pc-linux-gnu.h +## File created by gen-posix-lock-obj - DO NOT EDIT +## To be included by mkheader into gpg-error.h + +typedef struct +{ + long _vers; + union { + volatile char _priv[40]; + long _x_align; + long *_xp_align; + } u; +} gpgrt_lock_t; + +#define GPGRT_LOCK_INITIALIZER {1,{{0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0}}} +## +## Local Variables: +## mode: c +## buffer-read-only: t +## End: +## diff --git a/src/syscfg/lock-obj-pub.x86_64-pc-linux-gnux32.h b/src/syscfg/lock-obj-pub.x86_64-pc-linux-gnux32.h new file mode 100644 index 0000000..e85bd30 --- /dev/null +++ b/src/syscfg/lock-obj-pub.x86_64-pc-linux-gnux32.h @@ -0,0 +1,24 @@ +## lock-obj-pub.x86_64-pc-linux-gnux32.h +## File created by gen-posix-lock-obj - DO NOT EDIT +## To be included by mkheader into gpg-error.h + +typedef struct +{ + long _vers; + union { + volatile char _priv[32]; + long _x_align; + long *_xp_align; + } u; +} gpgrt_lock_t; + +#define GPGRT_LOCK_INITIALIZER {1,{{0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0}}} +## +## Local Variables: +## mode: c +## buffer-read-only: t +## End: +## -- 2.0.1 From wk at gnupg.org Sun Jul 27 13:47:46 2014 From: wk at gnupg.org (Werner Koch) Date: Sun, 27 Jul 2014 13:47:46 +0200 Subject: [PATCH] add new lock-obj-pub.*.h from debian buildds In-Reply-To: <1406329242-3323-1-git-send-email-dkg@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 25 Jul 2014 19:00:42 -0400") References: <20140721053203.GA6719@alf.mars> <1406329242-3323-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <87r417rpjx.fsf@vigenere.g10code.de> Thanks, files added to Makefile.am and pushed. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From kristian.fiskerstrand at sumptuouscapital.com Tue Jul 29 20:11:52 2014 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Tue, 29 Jul 2014 20:11:52 +0200 Subject: Keyserver rejection filter and signing subkeys Message-ID: <53D7E3E8.10803@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, Since the introduction of the keyserver rejection filter, receiving a key by using a subkey ID/fpr rather than the primary key ID/fpr fails as shown below. I noticed this due to using a signing subkey, and a correspondent asked why he couldn't download the key. Naturally - --search still works, as the following request is then done by primary key fpr. Is this something that should be considered a regression, or do we simply mark it as per design and that the primary key ID should always be used. If so, should a reference to the primary key fpr be printed along with the subkey ID when doing --verify? $ gpg2 --verify test.tar.bz2.asc gpg: Signature made Sat 12 Jul 2014 03:16:04 PM CEST gpg: using RSA key 0xFC3B17DE05E136A0 $ gpg2 --recv-key 0xFC3B17DE05E136A0 gpg: requesting key 0xFC3B17DE05E136A0 from hkp server 192.168.0.33 gpg: key 0x0B7F8B60E3EDFAE3: rejected by import filter gpg: Total number processed: 1 - -- - ---------------------------- Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- Nunc aut numquam Now or never -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJT1+PoAAoJEPw7F94F4TagKJYP/jNveZf2GQZGhy44e6vCe8li HSjT/mlZ+NwVHhC5OYaH/S0kMfjFLLXth4X9ICncgNJbBhOZJIH0g0lNaV6Tbbce +Vd72SOkFRBL0W7FXgJhfW2PWbD1EisRis9jP5nZkWj4tEKQszxLLu9LjjZBmYy8 dtMObB9exGZOkZqhUmZmXqXy/Zib1jPrnVdIFdCqiru5SKLVn0rEzwseBKWqadEm hx8Hl59daHhA3zwNVb5K7GzqceKgDVMHvVvdRLYke68rk4OJu4mtBxIhpWd+iKNI UpOtE+j7lp5S3HtfJciXPoXz0N+V5UP3MFFfbGMROYwuVTh6cCvKSu8dcF8xWIaK phaDyhsAbebsfnYN4KRQTJeMw8YOljO63ElUH3BufiVK8pwZdvXffWPEkRur0ncY 0vbqVrXArCLNTuuuakAuVwU53WqneB1qIA8ms6I7Fv8Qj5I/RKH9OkjxNsFly/D9 R35vIwwO4yje84B/3MWVB4SLPi6hefnDs0ZpnvhR/CaXKktOdVasYCuvCYs4+A7M yi25mtnThqcNsbO6MzaN0LHZykBS2R9fSAwb8M2B2fq1AkRsYEqV9NEKNG4ev2Hc MDmt4pvYtDAPcguh38BrazDNlkGa8bKg5zpbTXjjhEDymW/uyQ+Y/yBvOB1/1AoF faJ7mG9oEm6AkoJgbFTT =1MVH -----END PGP SIGNATURE----- From wk at gnupg.org Wed Jul 30 10:22:34 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 30 Jul 2014 10:22:34 +0200 Subject: Keyserver rejection filter and signing subkeys In-Reply-To: <53D7E3E8.10803@sumptuouscapital.com> (Kristian Fiskerstrand's message of "Tue, 29 Jul 2014 20:11:52 +0200") References: <53D7E3E8.10803@sumptuouscapital.com> Message-ID: <87wqavjlx1.fsf@vigenere.g10code.de> On Tue, 29 Jul 2014 20:11, kristian.fiskerstrand at sumptuouscapital.com said: > Is this something that should be considered a regression, or do we > simply mark it as per design and that the primary key ID should always Yes, that is a regression. It would also render the --auto-key-retrieve option useless if a signing subkey has been used. To fix that we need to pass the keyblock and not just the key to the filter function. However this partly defeats the purpose of the filter if a a faked subkey has been attached to a key and uploaded to the keyserver. As long as the keyserver does not verify the key binding you would import a foreign key while verifying a signature done with the faked subkey. > be used. If so, should a reference to the primary key fpr be printed > along with the subkey ID when doing --verify? That is a different question but it already works: $ gpg --verify --with-fingerprint foo gpg: Signature made Wed Jul 30 10:08:40 2014 CEST using DSA key ID 77F95F95 gpg: Good signature from "Werner Koch " gpg: aka "Werner Koch " gpg: aka "Werner Koch " Primary key fingerprint: 8061 5870 F5BA D690 3336 86D0 F2AD 85AC 1E42 B367 Subkey fingerprint: E4B8 68C8 F90C 8964 B5AF 9DBC 4F05 40D5 77F9 5F95 Technically the printing of the fingerprint is not done by the signature verification part. If we want to make that the default we I would suggest to have something like this: gpg: Signature made Wed Jul 30 10:08:40 2014 CEST using DSA key ID 77F95F95 gpg: Primary key fingerprint: 8061 5870 F5BA D690 3336 86D0 F2AD 85AC 1E42 B367 gpg: Subkey fingerprint: E4B8 68C8 F90C 8964 B5AF 9DBC 4F05 40D5 77F9 5F95 gpg: Good signature from "Werner Koch " gpg: aka "Werner Koch " gpg: aka "Werner Koch " the line will be too long, though. Reformatting that for 2.1 ? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From kristian.fiskerstrand at sumptuouscapital.com Wed Jul 30 11:00:08 2014 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Wed, 30 Jul 2014 11:00:08 +0200 Subject: Keyserver rejection filter and signing subkeys In-Reply-To: <87wqavjlx1.fsf@vigenere.g10code.de> References: <53D7E3E8.10803@sumptuouscapital.com> <87wqavjlx1.fsf@vigenere.g10code.de> Message-ID: <53D8B418.40608@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 07/30/2014 10:22 AM, Werner Koch wrote: > On Tue, 29 Jul 2014 20:11, > kristian.fiskerstrand at sumptuouscapital.com said: > >> Is this something that should be considered a regression, or do >> we simply mark it as per design and that the primary key ID >> should always > > Yes, that is a regression. It would also render the > --auto-key-retrieve option useless if a signing subkey has been > used. > > To fix that we need to pass the keyblock and not just the key to > the filter function. However this partly defeats the purpose of > the filter if a a faked subkey has been attached to a key and > uploaded to the keyserver. As long as the keyserver does not > verify the key binding you would import a foreign key while > verifying a signature done with the faked subkey. Indeed, and the purpose of the filter is partly to protect against mallicious keyservers, so even if the "good" keyservers implements this[1] it can't be trusted. ... > > Technically the printing of the fingerprint is not done by the > signature verification part. If we want to make that the default > we I would suggest to have something like this: That looks good indeed > > gpg: Signature made Wed Jul 30 10:08:40 2014 CEST using DSA key ID > 77F95F95 gpg: Primary key fingerprint: 8061 5870 F5BA D690 3336 > 86D0 F2AD 85AC 1E42 B367 gpg: Subkey fingerprint: E4B8 68C8 > F90C 8964 B5AF 9DBC 4F05 40D5 77F9 5F95 > the line will be too long, though. Reformatting that for 2.1 ? How about breaking the fprs over two lines? as long as they are stacked up properly it'd look good still. Endnotes: [1] not likely for SKS at least as it currently does no signature verification and the performance hit could be quite large - -- - ---------------------------- Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- Ad astra per aspera To the stars through thorns -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJT2LQUAAoJEPw7F94F4TagW1MQAJmsR7UiwT85pCVQErZg58qU fUUm3MD327/4oD2bE0Z5ki9TmfGy+iKZMagQ7A3QGbXELVaJzSM6AI4RaCUmHp8g sFWVmLS2z+kDeuaTOMzzybMRqZFXg+rlbA/H2DoMItXjqoSUA1Lzi7xypzB4WB6H mAX5qZWZ/SKoPzGtzEFZdgyDUSKgl765BK+3GqwlX90lKGHDuwK38bQLof/N3zeb qhA+ORuhcR6K/7SAOm7fQwIAUwmUflP+CiVs+CAeToMNQQFhZJHTnKsr5+aSjnK0 ol8OKHJWE/Vlfi2ANOskCkuA+Eq+axX5U0ZE3UWyaseXB0ia7pdHkIkgffDGq7g1 3O7ykZYe8pekcyiKkA7NPkYDaBqbp17yU5tzyZFZVniAUAq6eoSm1IoRoN0JI+Q9 tPd39j78RYwwz+HnCgh378hehuFNoibm4T2LQ6Y3t9kmDwX/r0v1UcHD0WWBqvTq sdPj7BaYw52OU4AVi3Pmae45v2b3ZhGGhWQVjqFCSFGhVDg6ztSl6D0PlmOzVrK+ 5/hRQ/Ay36XCYkN9SaMQg+QSheHqNIVkKHuKbjZz+4fWPpBxBaackuuQ/2np/gvi O+0kUFqtDVMyHO6xMoU/rIQoDXOjMsALkEPuHDK5EhChHkLDGYpj07dtowGOVDGu iJrqSj/9ipUJtHimIhd2 =+Tms -----END PGP SIGNATURE----- From wk at gnupg.org Wed Jul 30 14:43:22 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 30 Jul 2014 14:43:22 +0200 Subject: Keyserver rejection filter and signing subkeys In-Reply-To: <53D8B418.40608@sumptuouscapital.com> (Kristian Fiskerstrand's message of "Wed, 30 Jul 2014 11:00:08 +0200") References: <53D7E3E8.10803@sumptuouscapital.com> <87wqavjlx1.fsf@vigenere.g10code.de> <53D8B418.40608@sumptuouscapital.com> Message-ID: <87egx3j9ud.fsf@vigenere.g10code.de> On Wed, 30 Jul 2014 11:00, kristian.fiskerstrand at sumptuouscapital.com said: >> verify the key binding you would import a foreign key while >> verifying a signature done with the faked subkey. > > Indeed, and the purpose of the filter is partly to protect against > mallicious keyservers, so even if the "good" keyservers implements > this[1] it can't be trusted. Actually this is not a problem because gpg won't import that subkey due to the missing key binding. >> gpg: Signature made Wed Jul 30 10:08:40 2014 CEST using DSA key ID >> 77F95F95 gpg: Primary key fingerprint: 8061 5870 F5BA D690 3336 >> 86D0 F2AD 85AC 1E42 B367 gpg: Subkey fingerprint: E4B8 68C8 >> F90C 8964 B5AF 9DBC 4F05 40D5 77F9 5F95 > >> the line will be too long, though. Reformatting that for 2.1 ? > > How about breaking the fprs over two lines? as long as they are > stacked up properly it'd look good still. Not good because c+p won't work. Note that since some time gpg accepts a standard formatted fingerprint thus tehre is no need to remove the spaces. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From kristian.fiskerstrand at sumptuouscapital.com Wed Jul 30 14:52:35 2014 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Wed, 30 Jul 2014 14:52:35 +0200 Subject: Keyserver rejection filter and signing subkeys In-Reply-To: <87egx3j9ud.fsf@vigenere.g10code.de> References: <53D7E3E8.10803@sumptuouscapital.com> <87wqavjlx1.fsf@vigenere.g10code.de> <53D8B418.40608@sumptuouscapital.com> <87egx3j9ud.fsf@vigenere.g10code.de> Message-ID: <53D8EA93.6000501@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 07/30/2014 02:43 PM, Werner Koch wrote: > On Wed, 30 Jul 2014 11:00, > kristian.fiskerstrand at sumptuouscapital.com said: > >>> verify the key binding you would import a foreign key while >>> verifying a signature done with the faked subkey. >> >> Indeed, and the purpose of the filter is partly to protect >> against mallicious keyservers, so even if the "good" keyservers >> implements this[1] it can't be trusted. > > Actually this is not a problem because gpg won't import that subkey > due to the missing key binding. > >>> gpg: Signature made Wed Jul 30 10:08:40 2014 CEST using DSA key >>> ID 77F95F95 gpg: Primary key fingerprint: 8061 5870 F5BA D690 >>> 3336 86D0 F2AD 85AC 1E42 B367 gpg: Subkey fingerprint: >>> E4B8 68C8 F90C 8964 B5AF 9DBC 4F05 40D5 77F9 5F95 >> >>> the line will be too long, though. Reformatting that for 2.1 >>> ? >> >> How about breaking the fprs over two lines? as long as they are >> stacked up properly it'd look good still. > > Not good because c+p won't work. Note that since some time gpg > accepts a standard formatted fingerprint thus tehre is no need to > remove the spaces. I was thinking more along the lines of $ gpg --verify --with-fingerprint foo gpg: Signature made Wed Jul 30 10:08:40 2014 CEST using DSA key ID 77F95F95 gpg: Primary key fingerprint: gpg: 8061 5870 F5BA D690 3336 86D0 F2AD 85AC 1E42 B367 gpg: Subkey fingerprint: gpg: E4B8 68C8 F90C 8964 B5AF 9DBC 4F05 40D5 77F9 5F95 gpg: Good signature from "Werner Koch " gpg: aka "Werner Koch " gpg: aka "Werner Koch " - -- - ---------------------------- Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- Ad astra per aspera To the stars through thorns -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJT2OqTAAoJEPw7F94F4TagDjsQAJv1NZEPeKMQrznRoRYYvgjM 1jO3tA/8iqFvOjNvMFIo0/DLt+oiuCsmx8X4B0vPuEsrQF8P5l4oTOMjAm+Ig0Tv KD4SBaBXcPw8bllTsA5YDW41kgTjOIvuJ6/p/eUFeB/H2Xv91EdMq/tGSTdn2Zrn EmuZrVZ1BDdf0f3h1TwwItB0y21Pc8NXeOAbEFXTR/xmHzgSuuOTwbpCL9jezULu d/71NMiiz4KTQcGLn8dpPNBoMq+PECKgL2VAsRyrfBjTy7oczbXsB1NabEWbdrtP gD6mWDPevzVND+jVi2JQEwPBoWL90pO6a/T+KxFgQY7YzGiPfgrUJN4mZjIdgY3H oHR3Xak4I7N+hKbDIta7GIWiJT5G5HkYYVhWr1h2GRqMbCnWK0BuK7jl1NmxNaKS 2me32sTdbcAXDqFuTicy0nlvDaSOvM+SEyfp6HL0HoajxRCG1ba0j+f0T+IGffjf tpd+uF9O9zN/VpZp8vccCyGQjmf6AsZl1hl4rTxex18L2KRDCmUXJeuv3L7Uf8VV C8JLtRJMpx6w2+xJDZ5Cyz72VE92pBh325rO4J8ycAtO1GSAJLToWRbWk2J9TGDP mPW2gr7J4qHmG3OyVzU6VrrvetcZCciBva4lhmOnYU30NAgKlYoabY2Qlw+v8OdQ +muHcAFCG5xxf7+SRKBU =LQAk -----END PGP SIGNATURE----- From wk at gnupg.org Wed Jul 30 17:35:08 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 30 Jul 2014 17:35:08 +0200 Subject: verify output (was: Keyserver rejection filter and signing subkeys) In-Reply-To: <53D8EA93.6000501@sumptuouscapital.com> (Kristian Fiskerstrand's message of "Wed, 30 Jul 2014 14:52:35 +0200") References: <53D7E3E8.10803@sumptuouscapital.com> <87wqavjlx1.fsf@vigenere.g10code.de> <53D8B418.40608@sumptuouscapital.com> <87egx3j9ud.fsf@vigenere.g10code.de> <53D8EA93.6000501@sumptuouscapital.com> Message-ID: <87k36uj1w3.fsf_-_@vigenere.g10code.de> On Wed, 30 Jul 2014 14:52, kristian.fiskerstrand at sumptuouscapital.com said: > I was thinking more along the lines of > $ gpg --verify --with-fingerprint foo > gpg: Signature made Wed Jul 30 10:08:40 2014 CEST using DSA key ID > 77F95F95 > gpg: Primary key fingerprint: > gpg: 8061 5870 F5BA D690 3336 86D0 F2AD 85AC 1E42 B367 > gpg: Subkey fingerprint: > gpg: E4B8 68C8 F90C 8964 B5AF 9DBC 4F05 40D5 77F9 5F95 > gpg: Good signature from "Werner Koch " Ah yes. However, is the subkey fingerprint really useful? It may lead to more confusion. We usually try to hide the fact that there are subkeys and present only the primary fingerprint. What about this? --8<---------------cut here---------------start------------->8--- gpg: Signature made Wed Jul 30 10:08:40 2014 CEST using DSA key ID 77F95F95 gpg: Key fingerprint = 8061 5870 F5BA D690 3336 86D0 F2AD 85AC 1E42 B367 gpg: Good signature from "Werner Koch " gpg: aka "Werner Koch " gpg: aka "Werner Koch " --8<---------------cut here---------------end--------------->8--- or with the new algorithm info format: --8<---------------cut here---------------start------------->8--- gpg: Signature made Wed Jul 30 10:08:40 2014 CEST using dsa2048/77F95F95 gpg: key fingerprint 8061 5870 F5BA D690 3336 86D0 F2AD 85AC 1E42 B367 gpg: Good signature from "Werner Koch " gpg: aka "Werner Koch " gpg: aka "Werner Koch " --8<---------------cut here---------------end--------------->8--- or the one which looks best to me: --8<---------------cut here---------------start------------->8--- gpg: Signature made Wed Jul 30 10:08:40 2014 CEST using dsa2048/77F95F95 gpg: Good signature from "Werner Koch " gpg: aka "Werner Koch " gpg: aka "Werner Koch " gpg: key fingerprint 8061 5870 F5BA D690 3336 86D0 F2AD 85AC 1E42 B367 --8<---------------cut here---------------end--------------->8--- All of them will lead to the question why the keyid does not match the fingerprint. However, this can easiliy be explained in the FAQ. Should we print the fingerprint if for a /BAD signature/, too? Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From kristian.fiskerstrand at sumptuouscapital.com Wed Jul 30 17:44:01 2014 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Wed, 30 Jul 2014 17:44:01 +0200 Subject: verify output In-Reply-To: <87k36uj1w3.fsf_-_@vigenere.g10code.de> References: <53D7E3E8.10803@sumptuouscapital.com> <87wqavjlx1.fsf@vigenere.g10code.de> <53D8B418.40608@sumptuouscapital.com> <87egx3j9ud.fsf@vigenere.g10code.de> <53D8EA93.6000501@sumptuouscapital.com> <87k36uj1w3.fsf_-_@vigenere.g10code.de> Message-ID: <53D912C1.6060301@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 07/30/2014 05:35 PM, Werner Koch wrote: > On Wed, 30 Jul 2014 14:52, > kristian.fiskerstrand at sumptuouscapital.com said: >> I was thinking more along the lines of > ... > > Ah yes. However, is the subkey fingerprint really useful? It may > lead to more confusion. We usually try to hide the fact that there > are subkeys and present only the primary fingerprint. What about > this? > Not except for the point you're making below re keyid mismatch. > or with the new algorithm info format: > > --8<---------------cut here---------------start------------->8--- > gpg: Signature made Wed Jul 30 10:08:40 2014 CEST using > dsa2048/77F95F95 gpg: key fingerprint 8061 5870 F5BA D690 3336 > 86D0 F2AD 85AC 1E42 B367 gpg: Good signature from "Werner Koch > " gpg: aka "Werner Koch > " gpg: aka "Werner Koch eifzilla>" --8<---------------cut > here---------------end--------------->8--- I prefer this one myself > > All of them will lead to the question why the keyid does not match > the fingerprint. However, this can easiliy be explained in the > FAQ. > Indeed. > Should we print the fingerprint if for a /BAD signature/, too? It is most important for when a key is not available to verify at least. - -- - ---------------------------- Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- Veni vidi velcro I came, I saw, I got stuck -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJT2RK+AAoJEPw7F94F4TagmfoP/RmfuZXcqVVpXs4DLSG5xUMw F0XnEdFd0bWJyYmIevk1oQ5hScgesFfC3YtHboKyALRHQtzVYQQrWSjKwEv6YtpI 5/7HPaIHcBzyGs3LX97gG/wIBQXv699iJGe9760c6v2JBAiZZSb69DU6/A/6w/wj imZ7TD1qNESMDwmAHmhgkBRRDiFMyDkbI/xSlHV2Zl51TIVGVW3gSppNbk/b4rKI zT811iODJ9Z8g5mK2mZcylIPG/FHEtr+ZFWKoUIk23+pzK8u7JMcBGGkiMOSghec KVGd85qaHPb7oHOjvXlevakqDiIb/ITfWDUju3mJ0S7YMgSVRNaE4VZE/IGDeOoa vohi4nBBBph8x4048cT4s9Qo2T3jP6G/tQ7yufGhwKS0dVeDqzO9d24xovHCh8+m wnuO7qSHUE14p27lkMF4eFZaSAF0P7MfGlqfpizIdDkqwznJpcxCiKG0mD9jueF2 0vbOASWmRLJ8ZlmdUwjH7OBtrZiYqPsK9DFyi3f8imLIWb+Y9mZF9fVbKDgc5AaH AH1iHEG5Qmls8ZxXFDtxiH3ROYkFctu+cSW1lYT5UT7+++SRqJ4MKn6voWnX3vVG r6w/tvBQ8MNj02rwm5UVTUSBptI2RzNkhOKkHAry2PA6GqZcA7djeQR3o7LvJaFS 9KSHWOqbZCnYkJ2DbD96 =kL3f -----END PGP SIGNATURE----- From kristian.fiskerstrand at sumptuouscapital.com Wed Jul 30 18:12:47 2014 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Wed, 30 Jul 2014 18:12:47 +0200 Subject: verify output In-Reply-To: <53D912C1.6060301@sumptuouscapital.com> References: <53D7E3E8.10803@sumptuouscapital.com> <87wqavjlx1.fsf@vigenere.g10code.de> <53D8B418.40608@sumptuouscapital.com> <87egx3j9ud.fsf@vigenere.g10code.de> <53D8EA93.6000501@sumptuouscapital.com> <87k36uj1w3.fsf_-_@vigenere.g10code.de> <53D912C1.6060301@sumptuouscapital.com> Message-ID: <53D9197F.5070605@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 07/30/2014 05:44 PM, Kristian Fiskerstrand wrote: > On 07/30/2014 05:35 PM, Werner Koch wrote: >> On Wed, 30 Jul 2014 14:52, >> kristian.fiskerstrand at sumptuouscapital.com said: >>> I was thinking more along the lines of ... > >> Should we print the fingerprint if for a /BAD signature/, too? > > It is most important for when a key is not available to verify at > least. > This didn't really make too much sense as we can't calculate the key fingerprint in that case and only have access to the subkey as issuer unless a notation field is used with the fingerprint of the primary key. So for now we're back to the issue with downloading a key based on the subkey ID.... - -- - ---------------------------- Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- "History doesn't repeat itself, but it does rhyme." (Mark Twain) -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJT2Rl+AAoJEPw7F94F4Tag100P/ibdVReLuaoCTMO/xnsnK1YO 8rBN5ksjlNHfkkrkWHarcxHpXci3mPTbbvZTQHsGDXnKcxKMVrX0X1SPs3n7N8eR /wjwTIyCMVCXDqdvdZ7rI6fPiy29ebxzjA83C/F1nT645rhicE22udKrH9oO6zU7 /xVx3e3qv8K1PdI7GSWTGKRg3IWZLHnrRex1TSsPaIwYbitnJajCYsqdfJKn74b1 PwMNf4/Vu0ey8GuOxqtoPa80a/aW7/XeVU9Xekis2EheRZTuXFu6PIeqCzK/rquP rdfASsUxoFwymhSTptH1Js5u0IOk145PE1+BoFU5gVd4UAuetwZKoHjOxhQixjZS l0VO3oH7uapHF8pXUn80jMW9hMZ8Q5aLZAYP/AcY/bawA1k5HmTbmYVEARdsoEZE wCOibJ4RAMwIDuD12nL02iWf+cAPN0YRSVMNoY7S4sUrrUDHRcewhI2euyWBQCu1 AsSo2qkKzzYW2T1Rj8RRZaZDdChAIaF38jVakvfzLZ2jYZSV+wvvQBl2s5Kg0C4J gDZTiZafl8aaqIpVpJ3q65UiE9/yGbcWHh723Gm/Dv7086uLxyVPP3hZVv2/BHsS 5t0bOXeTfy4IGmoSZPKVw+C5dYFl5jrN+5xKsQvG0SxJggSo3mNoEw3j6F4vEBgO x9mF5UrKKeiAgDjYEJyv =ydSw -----END PGP SIGNATURE----- From wk at gnupg.org Wed Jul 30 18:32:27 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 30 Jul 2014 18:32:27 +0200 Subject: verify output In-Reply-To: <53D9197F.5070605@sumptuouscapital.com> (Kristian Fiskerstrand's message of "Wed, 30 Jul 2014 18:12:47 +0200") References: <53D7E3E8.10803@sumptuouscapital.com> <87wqavjlx1.fsf@vigenere.g10code.de> <53D8B418.40608@sumptuouscapital.com> <87egx3j9ud.fsf@vigenere.g10code.de> <53D8EA93.6000501@sumptuouscapital.com> <87k36uj1w3.fsf_-_@vigenere.g10code.de> <53D912C1.6060301@sumptuouscapital.com> <53D9197F.5070605@sumptuouscapital.com> Message-ID: <87bns6iz8k.fsf@vigenere.g10code.de> On Wed, 30 Jul 2014 18:12, kristian.fiskerstrand at sumptuouscapital.com said: > This didn't really make too much sense as we can't calculate the key Well, for a BAD signature we have the key. > fingerprint in that case and only have access to the subkey as issuer > unless a notation field is used with the fingerprint of the primary > key. So for now we're back to the issue with downloading a key based > on the subkey ID.... I'll change it for master. Takes some days; we have public summer holidays and with that come some family obligations. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From hans at guardianproject.info Wed Jul 30 17:46:28 2014 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Wed, 30 Jul 2014 11:46:28 -0400 Subject: add gnupg-for-java fork to git.gnupg.org Message-ID: <53D91354.8020105@guardianproject.info> On http://git.gnupg.org/ it lists the old, unmaintained gnupg-for-java. Could this page instead point to the maintained version that works with gnupg 2.x? https://github.com/guardianproject/gnupg-for-java .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 904 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Wed Jul 30 20:56:38 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 30 Jul 2014 14:56:38 -0400 Subject: add gnupg-for-java fork to git.gnupg.org In-Reply-To: <53D91354.8020105@guardianproject.info> References: <53D91354.8020105@guardianproject.info> Message-ID: <53D93FE6.4060401@sixdemonbag.org> > On http://git.gnupg.org/ it lists the old, unmaintained > gnupg-for-java. Could this page instead point to the maintained > version that works with gnupg 2.x? I would like to see it compile out of the box first. From a checkout made just a few minutes ago on a fully updated Fedora 20 box with all the necessary development libraries and the latest Java 1.8 JDK: ===== [rjh at flynn gnupg-for-java]$ ant Buildfile: /home/rjh/Projects/gnupg-for-java/build.xml prepare: compile-java: [mkdir] Created dir: /home/rjh/Projects/gnupg-for-java/build/classes [javac] /home/rjh/Projects/gnupg-for-java/build.xml:21: warning: 'includeantruntime' was not set, defaulting to build.sysclasspath=last; set to false for repeatable builds [javac] Compiling 8 source files to /home/rjh/Projects/gnupg-for-java/build/classes gen-jni-headers: prepare: compile-java: [javac] /home/rjh/Projects/gnupg-for-java/build.xml:21: warning: 'includeantruntime' was not set, defaulting to build.sysclasspath=last; set to false for repeatable builds generate-jni-headers: [exec] /usr/java/jdk1.8.0_11/bin/javah -classpath /home/rjh/Projects/gnupg-for-java/build/classes -jni com.freiheit.gnupg.GnuPGContext com.freiheit.gnupg.GnuPGData com.freiheit.gnupg.GnuPGGenkeyResult com.freiheit.gnupg.GnuPGKey com.freiheit.gnupg.GnuPGSignature gen-jni-library: recompile-c-code: [exec] gcc -g -Werror -Wall -Wno-deprecated-declarations -fPIC -D_REENTRANT -D_THREAD_SAFE -D_FILE_OFFSET_BITS=64 -DLARGEFILE_SOURCE=1 -I"/usr/java/jdk1.8.0_11/include" -I"/usr/java/jdk1.8.0_11/include/linux" -c GnuPGContext.c [exec] GnuPGContext.c: In function ?Java_com_freiheit_gnupg_GnuPGContext_gpgmeGetSignersLength?: [exec] GnuPGContext.c:487:5: error: implicit declaration of function ?gpgme_signers_count? [-Werror=implicit-function-declaration] [exec] return (gpgme_signers_count(CONTEXT(context))); [exec] ^ [exec] cc1: all warnings being treated as errors [exec] make: *** [GnuPGContext.o] Error 1 BUILD FAILED /home/rjh/Projects/gnupg-for-java/build.xml:81: The following error occurred while executing this line: /home/rjh/Projects/gnupg-for-java/build.xml:74: exec returned: 2 Total time: 4 seconds From hans at guardianproject.info Wed Jul 30 22:55:16 2014 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Wed, 30 Jul 2014 16:55:16 -0400 Subject: add gnupg-for-java fork to git.gnupg.org In-Reply-To: <53D93FE6.4060401@sixdemonbag.org> References: <53D91354.8020105@guardianproject.info> <53D93FE6.4060401@sixdemonbag.org> Message-ID: <53D95BB4.3050400@guardianproject.info> On 07/30/2014 02:56 PM, Robert J. Hansen wrote: >> On http://git.gnupg.org/ it lists the old, unmaintained >> gnupg-for-java. Could this page instead point to the maintained >> version that works with gnupg 2.x? > > I would like to see it compile out of the box first. From a checkout > made just a few minutes ago on a fully updated Fedora 20 box with all > the necessary development libraries and the latest Java 1.8 JDK: > > ===== > > > [rjh at flynn gnupg-for-java]$ ant > Buildfile: /home/rjh/Projects/gnupg-for-java/build.xml > > prepare: > > compile-java: > [mkdir] Created dir: /home/rjh/Projects/gnupg-for-java/build/classes > [javac] /home/rjh/Projects/gnupg-for-java/build.xml:21: warning: > 'includeantruntime' was not set, defaulting to build.sysclasspath=last; > set to false for repeatable builds > [javac] Compiling 8 source files to > /home/rjh/Projects/gnupg-for-java/build/classes > > gen-jni-headers: > > prepare: > > compile-java: > [javac] /home/rjh/Projects/gnupg-for-java/build.xml:21: warning: > 'includeantruntime' was not set, defaulting to build.sysclasspath=last; > set to false for repeatable builds > > generate-jni-headers: > [exec] /usr/java/jdk1.8.0_11/bin/javah -classpath > /home/rjh/Projects/gnupg-for-java/build/classes -jni > com.freiheit.gnupg.GnuPGContext com.freiheit.gnupg.GnuPGData > com.freiheit.gnupg.GnuPGGenkeyResult com.freiheit.gnupg.GnuPGKey > com.freiheit.gnupg.GnuPGSignature > > gen-jni-library: > > recompile-c-code: > [exec] gcc -g -Werror -Wall -Wno-deprecated-declarations -fPIC > -D_REENTRANT -D_THREAD_SAFE -D_FILE_OFFSET_BITS=64 -DLARGEFILE_SOURCE=1 > -I"/usr/java/jdk1.8.0_11/include" > -I"/usr/java/jdk1.8.0_11/include/linux" -c GnuPGContext.c > [exec] GnuPGContext.c: In function > ?Java_com_freiheit_gnupg_GnuPGContext_gpgmeGetSignersLength?: > [exec] GnuPGContext.c:487:5: error: implicit declaration of > function ?gpgme_signers_count? [-Werror=implicit-function-declaration] > [exec] return (gpgme_signers_count(CONTEXT(context))); > [exec] ^ > [exec] cc1: all warnings being treated as errors > [exec] make: *** [GnuPGContext.o] Error 1 > > BUILD FAILED > /home/rjh/Projects/gnupg-for-java/build.xml:81: The following error > occurred while executing this line: > /home/rjh/Projects/gnupg-for-java/build.xml:74: exec returned: 2 > > Total time: 4 seconds I should have said works with GnuPG >=2.1 and gpgme >= 1.5.x, since it was developed using the latest versions of the GnuPG suite. gpgme_signers_count() is a function that was added in gpgme 1.5.0. It should be easy to do a basic port to GnuPG 2.0 and gpgme 1.4.3 if there is demand. Does the old gnupg-for-java still compile on your setup? As far as I remember, it does not work with GnuPG 2.x at all. And it is quite bare bones, we've added a lot of functionality and some tests to gnupg-for-java. I pushed a commit that declares 1.5.0 as the minimum gpgme version. .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 904 bytes Desc: OpenPGP digital signature URL: From bernhard at intevation.de Thu Jul 31 10:21:04 2014 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 31 Jul 2014 10:21:04 +0200 Subject: FAQ: Re: key length In-Reply-To: <53D0D9C6.1080807@sixdemonbag.org> References: <53D06E85.7080903@sixdemonbag.org> <53D0D9C6.1080807@sixdemonbag.org> Message-ID: <201407311021.13108.bernhard@intevation.de> On Thursday 24 July 2014 at 12:02:46, Robert J. Hansen wrote: > This is just a proposal, *not* a final draft. If this gives people > heartburn, let me know precisely what gives heartburn and I'll try to > mitigate it as best as I can. Thanks for the proposal. Together with a data, I think it is a big improvement! (If you wanted to, you could put it up at wiki.gnupg.org, I believe that we should get even more people to participate in collecting and improving the documentation.) > Q: Why does GnuPG default to 2048-bit RSA? > A: Because it offers reasonable security for the next several years > while still being compatible with the widest variety of OpenPGP > installations. This makes me curious: Is there an example for an OpenPGP implementation that only support <= 2048-bit RSA keys? Still in usage? > Q: What are NIST's recommendations for key sizes? > A: According to NIST Special Publication 800-57, "Recommendation for > Key Management," published in July 2012, a 2048-bit RSA or DSA > key is comparable in strength to 3DES. Further, they state that > 2048-bit keys are acceptable for use through the year 2030. > > Q: What are ENISA's recommendations for key sizes? > A: Slightly different, but not so much so as to be surprising. ENISA > is slightly more pessimistic about the long-term prospects of > 2048-bit keys, although they are careful to note 2048-bit keys are > still daunting for an adversary. I haven't read the ENISA recommendation in full length. If they allow 2048 bit for old applications or up to a specific point, it would be an improvement to say so. It may make sense to directly link to their recommendation paper. > Q: Is there a general recommendation that 3072-bit keys be used for > new applications? > A: No, although some respected people and groups within the > cryptographic community have made such recommendations. > > Q: Why does GnuPG disregard these recommendations for 3072-bit keys? > A: We don't. That recommendation is for *new applications*. GnuPG > is not a new application. When a user generates a GnuPG certificate, > that user becomes part of an ecosystem of existing certificates and > a userbase that spans the globe. In short, GnuPG is not a new > application. > > Q: Are there any plans to move to stronger keys by default? > A: Imminently. You may consider using a different word here. As someone who speaks English as a foreign language, I had to look "imminently" up to be sure about its meaning. > When a version of GnuPG is released which supports > elliptical-curve cryptography, then will be an ideal time for us > to pause, take a deep breath, and make the transition to larger > effective key sizes. > > Q: I think I need larger key sizes. > A: By all means, feel free to generate certificates with larger keys. > GnuPG supports up to 4096-bit keys. Wasn't there something about the current OpenPGP smartcards only being able to deal with 3072-bit keys? May be another argument. If you wanted to move your secret key on a smartcard some day. I recommend to leave out the next question and answer, it does not add much significant information. From the above it is clear that currently the compatibility with other/elder OpenPGP implementations is prefered as default. > Q: If GnuPG will be moving to stronger default key sizes in the near > future via support for elliptical curves, why is there such > controversy about what GnuPG's defaults are right now? > A: It's human nature to want things "more, better, and right now." But > just like in the rest of life, good things come to those who wait. > It won't be long, we promise. Best Regards, Bernhard -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998 Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Thu Jul 31 10:22:02 2014 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 31 Jul 2014 10:22:02 +0200 Subject: gpgsm, certgen example and de.po fix In-Reply-To: <87tx69y4pl.fsf@vigenere.g10code.de> References: <201407071542.36913.bernhard@intevation.de> <201407221028.52775.bernhard@intevation.de> <87tx69y4pl.fsf@vigenere.g10code.de> Message-ID: <201407311022.04464.bernhard@intevation.de> On Tuesday 22 July 2014 at 14:10:14, Werner Koch wrote: > On Tue, 22 Jul 2014 10:28, bernhard at intevation.de said: > > In my experience there are two commonly used patterns > > a) using the organisational hierarchy > > b) using the domain name hierarchy > > I am pretty sure that the mostly used pattern is > > ? CN=host.example.org > > which is what you need for a CSR to setup a TLS server. I was talking about email certficates. But anyway, I think that an example would be an improvement. -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998 Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Thu Jul 31 10:26:46 2014 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 31 Jul 2014 10:26:46 +0200 Subject: Problems with gpgsm/dirmngr in gnupg-2.1.0-beta751 In-Reply-To: <87zjgjpx3e.fsf@pcwi7557.uni-muenster.de> References: <87zjgjpx3e.fsf@pcwi7557.uni-muenster.de> Message-ID: <201407311026.47586.bernhard@intevation.de> On Tuesday 08 July 2014 at 19:41:09, Jens Lechtenboerger wrote: > Any hints? In our setups we prefer to run dirmnger as a system service, you could try this variant and see if you get further. You could also try to turn on more debugging like -vvv --debug-all -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998 Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Thu Jul 31 10:40:51 2014 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 31 Jul 2014 10:40:51 +0200 Subject: gpgme 1.4.4 and 1.5.1 released Message-ID: <201407311040.52021.bernhard@intevation.de> Gpgme 1.4.4 and 1.5.1 can be found on the servers, released by Werner, and it is not on the website yet. He probably gets to doing a real announcement soon. -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998 Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From kristian.fiskerstrand at sumptuouscapital.com Thu Jul 31 10:56:14 2014 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Thu, 31 Jul 2014 10:56:14 +0200 Subject: gpgme 1.4.4 and 1.5.1 released In-Reply-To: <201407311040.52021.bernhard@intevation.de> References: <201407311040.52021.bernhard@intevation.de> Message-ID: <53DA04AE.3070108@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 07/31/2014 10:40 AM, Bernhard Reiter wrote: > Gpgme 1.4.4 and 1.5.1 can be found on the servers, released by > Werner, and it is not on the website yet. He probably gets to doing > a real announcement soon. > In the mean time, please see CVE-2014-3564 gpgme: heap-based buffer overflow in gpgsm status handler[0] References: [0] http://seclists.org/oss-sec/2014/q3/266 - -- - ---------------------------- Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- Pr?venire melius est quam pr?veniri It is better to precede than to be preceded -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJT2gSrAAoJEPw7F94F4TagTSAP/jpgpaBaqTU3ZkUDC/KheVZV eqNE6tixY0KMS6L+zH4e1ULEyL81KaSdVklGApv4fO4AWRghsXhUETr8R38c2mle zSI0hC86YZucXq6PBcHUcTCvKa7oWVgOn0KPQeko8iWxrwMVZhWg/cdiAemFYEOc OIMutDQf27nAzDnN4UG7IHlP/Y7/TPgJ/ui2TbDGML9r9tGB2gDwAA4ieMvI2C1S 1e8VJgNRMcJIvVpN4eZmHiiByvEHnQMtYIMcI6QLWR4fmwVKrwwCydu+IA3IXUpz N0oIbzLJpObmOkt3CY2Mcv6mwzqyF/9ueTG2VH+kZnXoaoFF+CbqAuRa9bJfZE9B 2mA9dE9/dhN4W6rG3Qkf2xbvFdU6sEb6FHAn0TaBGF7n8/7tbaA5HiqEc9ZeKLjO owtvw48RopGLjthk++IyqQBJPQdjg/JGSU5nSm0BBq9WdJ1Psmrizs2wf3Pg6ebe 7bjHEQFT0MNsHG6l35HyPwlwaVxAmCIlR+tXkrCt2cbrYrvoUDthCZMdlYtFoYMm djHHQ2UqhqnYWrw1Ueh5qOMEjPTiCGUUchxKWUuDW7QVmrcvsV1jWI+NNqv6NINx +9cd9YhWDWQtgF5WPQypkRRML6RjAK0SzZBtQMBU+4w9DK6Lcgchv5I9CqtZQrb2 4o9IcUSGJf8GUs8AQT+4 =TB/o -----END PGP SIGNATURE----- From bernhard at intevation.de Thu Jul 31 17:51:28 2014 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 31 Jul 2014 17:51:28 +0200 Subject: add gnupg-for-java fork to git.gnupg.org In-Reply-To: <53D91354.8020105@guardianproject.info> References: <53D91354.8020105@guardianproject.info> Message-ID: <201407311751.29537.bernhard@intevation.de> On Wednesday 30 July 2014 at 17:46:28, Hans-Christoph Steiner wrote: > On http://git.gnupg.org/ it lists the old, unmaintained gnupg-for-java. > Could this page instead point to the maintained version that works with > gnupg 2.x? > > https://github.com/guardianproject/gnupg-for-java A good place to add this is yourself is the wiki: http://wiki.gnupg.org/APIs As a community I think it is easer to just do the changes ourself in the wiki instead of going through Werner or other core maintainers. Bernhard -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998 Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From dkg at fifthhorseman.net Thu Jul 31 18:20:33 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 31 Jul 2014 12:20:33 -0400 Subject: Keyserver rejection filter and signing subkeys In-Reply-To: <87egx3j9ud.fsf@vigenere.g10code.de> References: <53D7E3E8.10803@sumptuouscapital.com> <87wqavjlx1.fsf@vigenere.g10code.de> <53D8B418.40608@sumptuouscapital.com> <87egx3j9ud.fsf@vigenere.g10code.de> Message-ID: <53DA6CD1.5090802@fifthhorseman.net> On 07/30/2014 08:43 AM, Werner Koch wrote: > On Wed, 30 Jul 2014 11:00, kristian.fiskerstrand at sumptuouscapital.com > said: > >>> verify the key binding you would import a foreign key while >>> verifying a signature done with the faked subkey. >> >> Indeed, and the purpose of the filter is partly to protect against >> mallicious keyservers, so even if the "good" keyservers implements >> this[1] it can't be trusted. > > Actually this is not a problem because gpg won't import that subkey due > to the missing key binding. hm, maybe i'm not understanding the scenario here, but if i request key 0xdeadbeef, and that is only available as a subkey, and that subkey is bound to multiple primary keys on the keyservers, won't gpg import them all? let's set aside the concern about treating that subkey as a signing- or certification-capable subkey, which should require cross-certification in normal configurations. That constraint can be avoided by attaching the key with other usage flags, right? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 949 bytes Desc: OpenPGP digital signature URL: From hans at guardianproject.info Thu Jul 31 21:05:36 2014 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Thu, 31 Jul 2014 15:05:36 -0400 Subject: add gnupg-for-java fork to git.gnupg.org In-Reply-To: <201407311751.29537.bernhard@intevation.de> References: <53D91354.8020105@guardianproject.info> <201407311751.29537.bernhard@intevation.de> Message-ID: <53DA9380.20902@guardianproject.info> On 07/31/2014 11:51 AM, Bernhard Reiter wrote: > On Wednesday 30 July 2014 at 17:46:28, Hans-Christoph Steiner wrote: >> On http://git.gnupg.org/ it lists the old, unmaintained gnupg-for-java. >> Could this page instead point to the maintained version that works with >> gnupg 2.x? >> >> https://github.com/guardianproject/gnupg-for-java > > A good place to add this is yourself is the wiki: > http://wiki.gnupg.org/APIs > As a community I think it is easer to just do the changes ourself > in the wiki instead of going through Werner or other core maintainers. > > Bernhard Good idea, I added some things to that page: https://wiki.gnupg.org/APIs And now I change my original request: Please remove the link to https://github.com/smartrevolution/gnupg-for-java on http://git.gnupg.org/ and instead point to this wiki page: https://wiki.gnupg.org/APIs .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81