From avemilia at protonmail.com Thu Sep 3 14:49:06 2020 From: avemilia at protonmail.com (Ave Milia) Date: Thu, 03 Sep 2020 12:49:06 +0000 Subject: Cross-compiling gpg4win: can not find the runtime library libgcc_s_sjlj-1.dll Message-ID: Cannot cross-compile gpg4win-3.1.12-23-gfa3dff39 on Arch Linux. I have installed all necessary packages, but get: ? ./autogen.sh --build-w32 Using /home/ave/w32root as standard install directory checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes /home/ave/.local/soft/gpg4win/missing: Unknown `--is-lightweight' option Try `/home/ave/.local/soft/gpg4win/missing --help' for more information configure: WARNING: 'missing' script is too old or missing checking for i686-w64-mingw32-strip... i686-w64-mingw32-strip checking for a thread-safe mkdir -p... /usr/bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether make supports nested variables... yes checking whether UID '1000' is supported by ustar format... yes checking whether GID '1000' is supported by ustar format... yes checking how to create a ustar tar archive... gnutar checking whether to enable maintainer-specific portions of Makefiles... yes checking build system type... x86_64-unknown-linux-gnu checking host system type... i686-w64-mingw32 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 i686-w64-mingw32-gcc... i686-w64-mingw32-gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.exe checking for suffix of executables... .exe 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 i686-w64-mingw32-gcc accepts -g... yes checking for i686-w64-mingw32-gcc option to accept ISO C89... none needed checking whether i686-w64-mingw32-gcc understands -c and -o together... yes checking whether make supports the include directive... yes (GNU style) checking dependency style of i686-w64-mingw32-gcc... gcc3 checking how to run the C preprocessor... i686-w64-mingw32-gcc -E checking for i686-w64-mingw32-ranlib... i686-w64-mingw32-ranlib checking for i686-w64-mingw32-ar... i686-w64-mingw32-ar checking for i686-w64-mingw32-strip... (cached) i686-w64-mingw32-strip checking for i686-w64-mingw32-dlltool... i686-w64-mingw32-dlltool checking for make... make checking for unzip... unzip checking for tar... tar checking for mkdir... mkdir checking for cp... cp checking for rm... rm checking for stow... stow checking for makensis... makensis checking for zcat... zcat checking for texi2dvi... texi2dvi checking for dvipdf... dvipdf checking for convert... convert checking for sha1sum... sha1sum checking for msgfmt... /usr/bin/msgfmt checking for gitlog-to-changelog... no checking for gcc... gcc checking for i686-w64-mingw32-x86_64-w64-mingw32-strip... no checking for x86_64-w64-mingw32-strip... x86_64-w64-mingw32-strip configure: WARNING: using cross tools not prefixed with host triplet configure: Using autodetected 12 make jobs. You can override this by setting GPG4WIN_PARALLEL. configure: error: can not find the runtime library libgcc_s_sjlj-1.dll in the default locations. Use the --with-libgcc_s_sjlj-1 option to set the path directly. Internet says this is a problem with dynamic linking [0]. Any advice? [0] https://stackoverflow.com/questions/12921911/mingw-libgcc-s-sjlj-1-dll-is-missing From wk at gnupg.org Thu Sep 3 18:44:35 2020 From: wk at gnupg.org (Werner Koch) Date: Thu, 03 Sep 2020 18:44:35 +0200 Subject: [Announce] [security fix] GnuPG 2.2.23 released Message-ID: <87h7seyfm4.fsf@wheatstone.g10code.de> Hello! We are pleased to announce the availability of a new GnuPG release: version 2.2.23. This version fixes a *critical security bug* in versions 2.2.21 and 2.2.22. Impact ====== These versions are affected: - GnuPG 2.2.21 (released 2020-07-09) - GnuPG 2.2.22 (released 2020-08-27) - Gpg4win 3.1.12 (released 2020-07-24) All other versions are not affected. Importing an OpenPGP key having a preference list for AEAD algorithms will lead to an array overflow and thus often to a crash or other undefined behaviour. Importing an arbitrary key can often easily be triggered by an attacker and thus triggering this bug. Exploiting the bug aside from crashes is not trivial but likely possible for a dedicated attacker. The major hurdle for an attacker is that only every second byte is under their control with every first byte having a fixed value of 0x04. Software distribution verification should not be affected by this bug because such a system uses a curated list of keys. A CVE-id has not yet been assigned. We track this bug at https://dev.gnupg.org/T5050 Solution ======== If GnuPG version 2.2.21 or 2.2.22 is in use please update ASAP to version 2.2.23. If you are using an older version or a beta of version 2.3 no immediate action is required. If you are using Gpg4win 3.1.12 or GnuPG VS-Desktop 3.1.12 you may either wait for a fixed release which we will provide very soon or install GnuPG version 2.2.23 on top. If installation of a new version is not possible, applying the patch https://dev.gnupg.org/rGaeb8272ca8aad403a4baac33b8d5673719cfd8f0 is also sufficient. About GnuPG =========== The GNU Privacy Guard (GnuPG, GPG) is a complete and free implementation of the OpenPGP and S/MIME standards. GnuPG allows to encrypt and sign data and communication, features a versatile key management system as well as access modules for public key directories. GnuPG itself is a command line tool with features for easy integration with other applications. The separate library GPGME provides a uniform API to use the GnuPG engine by software written in common programming languages. A wealth of frontend applications and libraries making use of GnuPG are available. As an universal crypto engine GnuPG provides support for S/MIME and Secure Shell in addition to OpenPGP. GnuPG is Free Software (meaning that it respects your freedom). It can be freely used, modified and distributed under the terms of the GNU General Public License. Noteworthy changes in version 2.2.23 ==================================== * gpg: Fix AEAD preference list overflow. [#5050] * gpg: Fix a possible segv in the key cleaning code. * gpgsm: Fix a minor RFC2253 parser bug. [#5037] * scdaemon: Fix a PIN verify failure on certain OpenPGP card implementations. Regression in 2.2.22. [#5039] * po: Fix bug in the Hungarian translation. Updates for the Czech, Polish, and Ukrainian translations. Release-info: https://dev.gnupg.org/T5045 Getting the Software ==================== Please follow the instructions found at or read on: GnuPG 2.2.23 may be downloaded from one of the GnuPG mirror sites or direct from its primary FTP server. The list of mirrors can be found at . Note that GnuPG is not available at ftp.gnu.org. The GnuPG source code compressed using BZIP2 and its OpenPGP signature are available here: https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.23.tar.bz2 (6933k) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.23.tar.bz2.sig An installer for Windows without any graphical frontend except for a very minimal Pinentry tool is available here: https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.23_20200903.exe (4187k) https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.23_20200903.exe.sig The source used to build the Windows installer can be found in the same directory with a ".tar.xz" suffix. A new version of the GnuPG Desktop for Windows (aka Gpg4win) featuring this version of GnuPG will be released shortly. 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 version of GnuPG installed, you can simply verify the supplied signature. For example to verify the signature of the file gnupg-2.2.23.tar.bz2 you would use this command: gpg --verify gnupg-2.2.23.tar.bz2.sig gnupg-2.2.23.tar.bz2 This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by one or more of the release signing keys. Make sure that this is a valid key, either by matching the shown fingerprint against a trustworthy list of valid release signing keys or by checking that the key has been signed by trustworthy other keys. See the end of this mail for information on the signing keys. * If you are not able to use an existing version of GnuPG, you have to verify the SHA-1 checksum. On Unix systems the command to do this is either "sha1sum" or "shasum". Assuming you downloaded the file gnupg-2.2.23.tar.bz2, you run the command like this: sha1sum gnupg-2.2.23.tar.bz2 and check that the output matches the next line: bd949b4af7426e4afc13667d678503063c6aa4b5 gnupg-2.2.23.tar.bz2 c4435707bef33a612d54114f53837b19fcea38f5 gnupg-w32-2.2.23_20200903.tar.xz 489bc6de0a078248086f3214ca298dd6145ec497 gnupg-w32-2.2.23_20200903.exe Internationalization ==================== This version of GnuPG has support for 26 languages with Chinese (traditional and simplified), Czech, French, German, Japanese, Norwegian, Polish, Russian, and Ukrainian being almost completely translated. Documentation and Support ========================= If you used GnuPG in the past you should read the description of changes and new features at doc/whats-new-in-2.1.txt or online at https://gnupg.org/faq/whats-new-in-2.1.html The file gnupg.info has the complete reference manual of the system. Separate man pages are included as well but they miss some of the details available only in thee manual. The manual is also available online at https://gnupg.org/documentation/manuals/gnupg/ or can be downloaded as PDF at https://gnupg.org/documentation/manuals/gnupg.pdf . You may also want to search the GnuPG mailing list archives or ask on the gnupg-users mailing list for advise on how to solve problems. Most of the new features are around for several years and thus enough public experience is available. https://wiki.gnupg.org has user contributed information around GnuPG and relate software. In case of build problems specific to this release please first check https://dev.gnupg.org/T5045 for updated information. 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 . If you need commercial support go to or . If you are a developer and you need a certain feature for your project, please do not hesitate to bring it to the gnupg-devel mailing list for discussion. Thanks ====== Since 2001 maintenance and development of GnuPG is done by g10 Code GmbH and currently mostly financed by donations. Two full-time employed developers as well as two contractor exclusively work on GnuPG and closely related software like Libgcrypt, GPGME and Gpg4win. We like to thank all the nice people who are helping the GnuPG project, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, or answering questions on the mailing lists. Many thanks to our numerous financial supporters, both corporate and individuals. Without you it would not be possible to keep GnuPG in a good and secure shape and to address all the small and larger requests made by our users. Thanks. Special thanks to Andreas Stieger for reporting a bug and providing detailed information for us to track this down. Happy hacking, Your GnuPG hackers p.s. This is an announcement only mailing list. Please send replies only to the gnupg-users'at'gnupg.org mailing list. p.p.s List of Release Signing Keys: To guarantee that a downloaded GnuPG version has not been tampered by malicious entities we provide signature files for all tarballs and binary versions. The keys are also signed by the long term keys of their respective owners. Current releases are signed by one or more of these four keys: rsa2048 2011-01-12 [expires: 2021-12-31] Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) rsa2048 2014-10-29 [expires: 2020-10-30] Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 NIIBE Yutaka (GnuPG Release Key) rsa3072 2017-03-17 [expires: 2027-03-15] Key fingerprint = 5B80 C575 4298 F0CB 55D8 ED6A BCEF 7E29 4B09 2E28 Andre Heinecke (Release Signing Key) ed25519 2020-08-24 [expires: 2030-06-30] Key fingerprint = 6DAA 6E64 A76D 2840 571B 4902 5288 97B8 2640 3ADA Werner Koch (dist signing 2020) The keys are available at and in any recently released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed by a different key. -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 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 aheinecke at gnupg.org Wed Sep 16 12:38:01 2020 From: aheinecke at gnupg.org (Andre Heinecke) Date: Wed, 16 Sep 2020 12:38:01 +0200 Subject: Cross-compiling gpg4win: can not find the runtime library libgcc_s_sjlj-1.dll In-Reply-To: References: Message-ID: <4574819.1pL5PQfZYy@esus> Hi, On Thursday 3 September 2020 14:49:06 CEST Ave Milia via Gnupg-devel wrote: > configure: error: can not find the runtime library libgcc_s_sjlj-1.dll in the default locations. > > Use the --with-libgcc_s_sjlj-1 option to set the path directly. This file is needed to to be installed by Gpg4win, so when configuring our package we look for that as a dll binary. To be put into the installer package so that it is available at runtime. On debian they come from: gcc-mingw-w64-i686: /usr/lib/gcc/i686-w64-mingw32/8.3-posix/libgcc_s_sjlj-1.dll /usr/lib/gcc/i686-w64-mingw32/8.3-win32/libgcc_s_sjlj-1.dll For arch linux I do not know where they come from or that you have to pass as --with-libgcc_s_sjlj-1 configure argument. There will be two other runtime librarys also: libgstdc++-6.dll and libwinpthread-1.dll Regards, Andre -- GnuPG.com - a brand of g10 Code, the GnuPG experts. g10 Code GmbH, Erkrath/Germany, AG Wuppertal HRB14459 GF Werner Koch, USt-Id DE215605608, www.g10code.com. GnuPG e.V., Rochusstr. 44, D-40479 D?sseldorf. VR 11482 D?sseldorf Vorstand: W.Koch, B.Reiter, A.Heinecke Mail: board at gnupg.org Finanzamt D-Altstadt, St-Nr: 103/5923/1779. Tel: +49-211-28010702 From avemilia at protonmail.com Wed Sep 16 13:40:12 2020 From: avemilia at protonmail.com (Ave Milia) Date: Wed, 16 Sep 2020 11:40:12 +0000 Subject: Cross-compiling gpg4win: can not find the runtime library libgcc_s_sjlj-1.dll In-Reply-To: <4574819.1pL5PQfZYy@esus> References: <4574819.1pL5PQfZYy@esus> Message-ID: > Hi, > > On Thursday 3 September 2020 14:49:06 CEST Ave Milia via Gnupg-devel wrote: > > > configure: error: can not find the runtime library libgcc_s_sjlj-1.dll in the > > default locations. > > > > Use the --with-libgcc_s_sjlj-1 > > > > option to set the path directly. > > This file is needed to to be installed by Gpg4win, so when configuring our > package we look for that as a dll binary. To be put into the installer package > so that it is available at runtime. > > On debian they come from: > gcc-mingw-w64-i686: > /usr/lib/gcc/i686-w64-mingw32/8.3-posix/libgcc_s_sjlj-1.dll > /usr/lib/gcc/i686-w64-mingw32/8.3-win32/libgcc_s_sjlj-1.dll > > For arch linux I do not know where they come from or that you have to pass as > --with-libgcc_s_sjlj-1 configure argument. Thanks for the response. This is what I have: ? sudo pacman -S mingw-w64-toolchain mingw-w64 --needed warning: mingw-w64-binutils-2.35-1 is up to date -- skipping warning: mingw-w64-crt-7.0.0-1 is up to date -- skipping warning: mingw-w64-gcc-10.2.0-1 is up to date -- skipping warning: mingw-w64-headers-7.0.0-1 is up to date -- skipping warning: mingw-w64-winpthreads-7.0.0-1 is up to date -- skipping warning: mingw-w64-binutils-2.35-1 is up to date -- skipping warning: mingw-w64-crt-7.0.0-1 is up to date -- skipping warning: mingw-w64-gcc-10.2.0-1 is up to date -- skipping warning: mingw-w64-headers-7.0.0-1 is up to date -- skipping warning: mingw-w64-winpthreads-7.0.0-1 is up to date -- skipping there is nothing to do ? pacman -Ql mingw-w64-gcc | grep gcc_s mingw-w64-gcc /usr/i686-w64-mingw32/bin/libgcc_s_dw2-1.dll mingw-w64-gcc /usr/i686-w64-mingw32/lib/libgcc_s.a mingw-w64-gcc /usr/x86_64-w64-mingw32/bin/libgcc_s_seh-1.dll mingw-w64-gcc /usr/x86_64-w64-mingw32/lib/libgcc_s.a ? pacman -Qi mingw-w64-gcc | grep -i version Version : 10.2.0-1 Perhaps something changed between gcc 8 and gcc 10? Or it's in a different form (sjlj is part of e.g. dw2)? I just don't see any reason why part of a bundle (if sjlj is really a standard part of the bundle) wouldn't be installed. There are no additional potential packages to install, even in AUR: ? yay -Ss mingw-w64 | grep -i gcc An efficient Gthread implementation for GCC (mingw-w64) aur/mingw-w64-gcc-base 10.1.0-1 (+18 0.89) Cross GCC for the MinGW-w64 cross-compiler (bootstrap) community/mingw-w64-gcc 10.2.0-1 (143.3 MiB 884.7 MiB) [mingw-w64-toolchain mingw-w64] (Installed) Cross GCC for the MinGW-w64 cross-compiler mingw-w64-gcc-base is "compile-it-yourself" version of mingw-w64-gcc in repos, I believe. From avemilia at protonmail.com Thu Sep 17 12:32:44 2020 From: avemilia at protonmail.com (Ave Milia) Date: Thu, 17 Sep 2020 10:32:44 +0000 Subject: Cross-compiling gpg4win: can not find the runtime library libgcc_s_sjlj-1.dll In-Reply-To: <87k0wsk9op.fsf@jumper.gniibe.org> References: <4574819.1pL5PQfZYy@esus> <87k0wsk9op.fsf@jumper.gniibe.org> Message-ID: On Thursday, September 17, 2020 11:57 AM, Niibe Yutaka wrote: > > IIUC, I think --disable-sjlj-exceptions matters. > Good catch, thanks! It didn't come to me to look at the sources [0]. Consider resolved. [0]: From gniibe at fsij.org Thu Sep 17 11:57:10 2020 From: gniibe at fsij.org (Niibe Yutaka) Date: Thu, 17 Sep 2020 18:57:10 +0900 Subject: Cross-compiling gpg4win: can not find the runtime library libgcc_s_sjlj-1.dll In-Reply-To: References: <4574819.1pL5PQfZYy@esus> Message-ID: <87k0wsk9op.fsf@jumper.gniibe.org> Hello, Ave Milia via Gnupg-devel wrote: > Perhaps something changed between gcc 8 and gcc 10? Or it's in a > different form (sjlj is part of e.g. dw2)? I have a look at: https://aur.archlinux.org/cgit/aur.git/commit/PKGBUILD?h=mingw-w64-gcc-base It has this change: ========================== - --enable-lto --disable-dw2-exceptions \ + --enable-lto \ --disable-nls --enable-version-specific-runtime-libs \ - --disable-multilib --enable-checking=release + --disable-multilib --enable-checking=release \ + --disable-sjlj-exceptions --with-dwarf2 ========================== IIUC, I think --disable-sjlj-exceptions matters. -- From procmem at riseup.net Sun Sep 20 01:10:44 2020 From: procmem at riseup.net (procmem at riseup.net) Date: Sat, 19 Sep 2020 23:10:44 +0000 Subject: GPG Wipe Keys from RAM on Suspend Message-ID: Hi. I came across a new cryptsetup feature that is supposed to protect user data while the PC is in standby. It wipes the key from RAM when sleep events are triggered. While it protects LUKS, other data and keys loaded in RAM at the time are still vulnerable to forensic recovery. Can you please consider adding a sleep key cache wipe feature to GPG? [1] https://blog.freesources.org//posts/2020/08/cryptsetup-suspend/ From wk at gnupg.org Tue Sep 22 09:01:38 2020 From: wk at gnupg.org (Werner Koch) Date: Tue, 22 Sep 2020 09:01:38 +0200 Subject: GPG Wipe Keys from RAM on Suspend In-Reply-To: (procmem's message of "Sat, 19 Sep 2020 23:10:44 +0000") References: Message-ID: <871riujnvx.fsf@wheatstone.g10code.de> On Sat, 19 Sep 2020 23:10, procmem--- said: > Hi. I came across a new cryptsetup feature that is supposed to protect > user data while the PC is in standby. It wipes the key from RAM when > sleep events are triggered. While it protects LUKS, other data and keys > loaded in RAM at the time are still vulnerable to forensic recovery. Can > you please consider adding a sleep key cache wipe feature to GPG? That exists for ages: gpgconf --reload gpg-agent is all what you need. However, the platforms all differ a lot on how to run scripts on power events and thus the distros need to implement this. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: