From patrick at enigmail.net Fri Jun 1 08:46:03 2018 From: patrick at enigmail.net (Patrick Brunschwig) Date: Fri, 1 Jun 2018 08:46:03 +0200 Subject: Feature suggestion: options to require MDC or trusted signature on decryption In-Reply-To: <87d0xbd5sa.fsf@wheatstone.g10code.de> References: <705db6da-0999-4cd0-f45c-23a1cfa83a29@gmail.com> <87vab8jfp2.fsf@wheatstone.g10code.de> <87po1cdpy7.fsf@wheatstone.g10code.de> <47ee925a-c8f0-bf40-9105-3b36b5f74fde@enigmail.net> <87d0xbd5sa.fsf@wheatstone.g10code.de> Message-ID: On 31.05.18 20:44, Werner Koch wrote: > On Thu, 31 May 2018 16:51, patrick at enigmail.net said: > >> May I suggest that for GnuPG 2.3 you implement some more rules? For example: >> * refuse encrypting emails if MDC is not enabled in the key prefs > > RFC-4880 can be read to allow using MDC even without the feature flag. > For RFC-4880bis non-MDC will be deprected: > > This packet is obsolete. An implementation MUST not create this > packet. An implementation MAY process such a packet but it MUST > return a clear diagnostic that a non-integrity protected packet has > been processed. The implementation SHOULD also return an error in > this case and stop processing. > >> * remove options like --ignore-mdc-error, --ignore-mdc-warning and >> --allow-multiple-messages, or at least require them to be combined >> with something like --dangerous-options > > Already done. The MDC options in 2.3 and 2.2 are now NOPs. The > allow-multiple options and the --pgpg6 options are NOPs in 2.3. For > testing --rfc2440 can be used which has always had the effect not to > create an MDC. But then you contradict yourself. You wrote that gpg prints the following messages, but ignore-mdc-error is now a NOP: gpg: WARNING: message was not integrity protected gpg: Hint: If this message was created before the year 2003 it is likely that this message is legitimate. This is because back then integrity protection was not widely used. **gpg: Use the option '--ignore-mdc-error' to decrypt anyway.** [GNUPG:] ERROR nomdc_with_legacy_cipher 152 gpg: decryption forced to fail! [GNUPG:] DECRYPTION_FAILED [GNUPG:] END_DECRYPTION -Patrick From wk at gnupg.org Fri Jun 1 10:45:13 2018 From: wk at gnupg.org (Werner Koch) Date: Fri, 01 Jun 2018 10:45:13 +0200 Subject: Feature suggestion: options to require MDC or trusted signature on decryption In-Reply-To: (Patrick Brunschwig's message of "Fri, 1 Jun 2018 08:46:03 +0200") References: <705db6da-0999-4cd0-f45c-23a1cfa83a29@gmail.com> <87vab8jfp2.fsf@wheatstone.g10code.de> <87po1cdpy7.fsf@wheatstone.g10code.de> <47ee925a-c8f0-bf40-9105-3b36b5f74fde@enigmail.net> <87d0xbd5sa.fsf@wheatstone.g10code.de> Message-ID: <874limc2ue.fsf@wheatstone.g10code.de> On Fri, 1 Jun 2018 08:46, patrick at enigmail.net said: > But then you contradict yourself. You wrote that gpg prints the > following messages, but ignore-mdc-error is now a NOP: By MDC options I meant --force-mdc et al. and spefically not --ignore-mdc-error. Sorry I misread a part of your request. --ignore-mdc-error will stay because we need to have a way to decrypt old archieved mails somehow. Shalom-Salam, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From muelli at cryptobitch.de Fri Jun 1 17:25:01 2018 From: muelli at cryptobitch.de (Tobias Mueller) Date: Fri, 01 Jun 2018 17:25:01 +0200 Subject: Feature suggestion: options to require MDC or trusted signature on decryption In-Reply-To: <874limc2ue.fsf@wheatstone.g10code.de> References: <705db6da-0999-4cd0-f45c-23a1cfa83a29@gmail.com> <87vab8jfp2.fsf@wheatstone.g10code.de> <87po1cdpy7.fsf@wheatstone.g10code.de> <47ee925a-c8f0-bf40-9105-3b36b5f74fde@enigmail.net> <87d0xbd5sa.fsf@wheatstone.g10code.de> <874limc2ue.fsf@wheatstone.g10code.de> Message-ID: <1527866701.13278.3.camel@cryptobitch.de> Hi, On Fri, 2018-06-01 at 10:45 +0200, Werner Koch wrote: > because we need to have a way to decrypt > old archieved mails somehow. How about with an old archived version of GnuPG which is vulnerable to manipulated ciphertext? Cheers, Tobi From tookmund at gmail.com Sun Jun 3 19:25:41 2018 From: tookmund at gmail.com (Jacob Adams) Date: Sun, 3 Jun 2018 13:25:41 -0400 Subject: GPGME Developer's Certificate of Origin Message-ID: GPGME Developer's Certificate of Origin. Version 1.0 ===================================================== By making a contribution to the GPGME 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: Jacob Adams -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From diveshuttamchandani at gmail.com Tue Jun 5 07:18:45 2018 From: diveshuttamchandani at gmail.com (Divesh Uttamchandani) Date: Tue, 5 Jun 2018 10:48:45 +0530 Subject: GSoC Project EasyGnuPG Improvements Message-ID: Hi all, I am working on Easy GnuPG improvements for Google Summer of Code 2018 mentored by Dashamir Hoxha and T K Sourab. Dashamir suggested that some of you might be interested in this project so I am dropping its current progress here: The Initial scope of the project was to do complete rewrite of egpg using python and GPGME. Last week we tried another approach which is to replace the gpg calls with calls to python scripts which achieve the same functionality calls to GPGME library. Major things done during few week: - learning the use of GPGME following this resource and bash scripting. - Setting up development environment (docker scripts) - writing scripts for signing and verification replacing the gpg calls. I am updating my weekly reports on this GitHub repo so if you are interested you can watch the repo. If many of you are interested, and community doesn't consider these as a noise, I can also mail my reports every week to this list. Lastly, If community has any suggestions for the project and our approach please reach us out through this thread. Regards, Divesh Uttamchandani GitHub | LinkedIn | University Profile -------------- next part -------------- An HTML attachment was scrubbed... URL: From bernhard at intevation.de Tue Jun 5 16:41:26 2018 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 5 Jun 2018 16:41:26 +0200 Subject: WKD v06 (and CORS) Message-ID: <201806051641.34344.bernhard@intevation.de> Werner, thanks for publishing WKD v06 looking at the diff [1] I see that you've added the suggestion to avoid building and index, thanks! I hope that you'll also consider loosening the phrasing of the DNS SRV record so that implementors know that they will exclude a significant number of requesting clients in the future if they rely on the DNS SRV record. Personally I believe being independent of additional DNS requests is an advantages that WKD has over VVV or some other pubkey distribution methods proposed in the past. There is another detail which could help WKD, as pointed out by Wiktor, a regular web-app would need to get a CORS header from the WKD-server in order to fully use the results, see https://github.com/mailvelope/mailvelope/issues/580#issuecomment-394690051 Hereby I suggest to add this as SHOULD to the WKD spec. Rationale: Making this a MUST would put some more requirements on the serving side, which we want to avoid, as right now just placing a few files on a web server is enough (and not all allow setting headers in the served files itself as far as I know). Web Extensions (like Mailvelope) do not need the CORS header (AFAIK). Best Regards, Bernhard ps.: Could you make it a habit to drop a short email to gnupg-devel when you publish a new WKD, I'd appreciate it. Thanks! [1] https://www.ietf.org/rfcdiff?url1=draft-koch-openpgp-webkey-service-05&url2=draft-koch-openpgp-webkey-service-06 -- www.intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Tue Jun 5 20:18:46 2018 From: wk at gnupg.org (Werner Koch) Date: Tue, 05 Jun 2018 20:18:46 +0200 Subject: [GPA][PATCH] option->description in confdialog.c In-Reply-To: <20180529065212.GH8919@gnu.org> (ineiev@gnu.org's message of "Tue, 29 May 2018 02:52:14 -0400") References: <20160326094338.GA21716@gnu.org> <20180522095426.GK8919@gnu.org> <20180529065212.GH8919@gnu.org> Message-ID: <878t7t6qrd.fsf@wheatstone.g10code.de> On Tue, 29 May 2018 08:52, ineiev at gnu.org said: > Ping. Pong. All commited. Thanks for the reminder. Salam-Shalom, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Tue Jun 5 20:20:55 2018 From: wk at gnupg.org (Werner Koch) Date: Tue, 05 Jun 2018 20:20:55 +0200 Subject: WKD v06 (and CORS) In-Reply-To: <201806051641.34344.bernhard@intevation.de> (Bernhard Reiter's message of "Tue, 5 Jun 2018 16:41:26 +0200") References: <201806051641.34344.bernhard@intevation.de> Message-ID: <874lih6qns.fsf@wheatstone.g10code.de> On Tue, 5 Jun 2018 16:41, bernhard at intevation.de said: > ps.: Could you make it a habit to drop a short email to gnupg-devel when you > publish a new WKD, I'd appreciate it. Thanks! Hey, I only published it to avoid expiration. No real changes in the last months. You may want to follow the gnupg-doc repo where the I-D is developed. Shalom-Salam, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From ben at adversary.org Wed Jun 6 23:12:48 2018 From: ben at adversary.org (Ben McGinnes) Date: Thu, 7 Jun 2018 07:12:48 +1000 Subject: GSoC Project EasyGnuPG Improvements In-Reply-To: References: Message-ID: <20180606211248.w3nhny66o4bkvwts@adversary.org> On Tue, Jun 05, 2018 at 10:48:45AM +0530, Divesh Uttamchandani wrote: > Hi all, > > I am working on Easy GnuPG improvements > for Google > Summer of Code 2018 mentored by Dashamir Hoxha and T K Sourab. > > Dashamir suggested that some of you might be interested in this project so No doubt. > Major things done during few week: > - learning the use of GPGME following this > resource and > bash scripting. Don't use that version, that's (usually) a draft version used for testing export output. Use the version of the org-mode file that was shipped with the version of GPGME you actually have installed. That will be closer what's on your system. If you want the latest documentation, that's great, but you really ought to have the latest code to go with it. In that case, clone the GPGME repository from git.gnupg.org and compile the latest branch. The document you want is in lang/python/docs/GPGMEpythonHOWTOen.org. To view a HTML version of it instead, open that file in Emacs and export it to HTML with: C-c C-e Followed by: h o That will open an XHTML file in your default browser (though it may claim you're the author down the bottom, it fibs like that and so does LaTeX). Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From diveshuttamchandani at gmail.com Fri Jun 8 11:35:23 2018 From: diveshuttamchandani at gmail.com (Divesh Uttamchandani) Date: Fri, 8 Jun 2018 15:05:23 +0530 Subject: Query regarding GPGME python Bindings Message-ID: Hi, I am developing an application using gpgme python bindings. I want to achieve the following gpg command functionality using gpgme. gpg --auto-key-locate=local,cert,keyserver,pka \ --keyserver "$KEYSERVER" $recipients \ --sign --encrypt --armor \ --output "$file.sealed" "$file For achieving this i have broken it down to two parts 1. getting the recipients' key locally/keyserver 2. using these keys to encrypt (and sign the data) I have idea to achieve the functionality of the second part. I am doubtful about the first, Though I have tried it in following way, I want to know if I am correct and if there is a better way? Way used: 1) Set the keyserver in gpg.conf (in my case gpg.conf resides in ~/.gnupg say) 2) Set up the context with correct homedir gpg.Context(home_dir="~/.gnupg") 3) For each recipient use LOCATE mode to get keylist gpg.Context().keylist(recipient, mode=gpg.constants.keylist.mode.LOCATE) 4) from the list return by #3, confirm the contact from the user and add it to a list of recipient keys I am maintaining. 5) Finally I can use these keys for encrypting as mentioned in the example provided in part 2. Particularly I would like to know is there a way to provide keyserver from gpgme itself and not in gpg.conf. I couldn't find details about these variables in the examples provided, found this mostly using dir() and help() functions in python. Though I also read the c documentation but I am not sure if it the right way. Regards, Divesh Uttamchandani GitHub | Linkedin | University Profile -------------- next part -------------- An HTML attachment was scrubbed... URL: From dashohoxha at gmail.com Fri Jun 8 14:56:38 2018 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Fri, 8 Jun 2018 14:56:38 +0200 Subject: Query regarding GPGME python Bindings In-Reply-To: References: Message-ID: On Fri, Jun 8, 2018 at 11:35 AM, Divesh Uttamchandani < diveshuttamchandani at gmail.com> wrote: > > Way used: > 1) Set the keyserver in gpg.conf (in my case gpg.conf resides in ~/.gnupg > say) > > 2) Set up the context with correct homedir > gpg.Context(home_dir="~/.gnupg") > If you can load some settings from a configuration file ('gpg.conf' in this case), there should be some way to customize or override those settings. This is how it usually works. Maybe you should check more carefully the structure of the object 'gpg'. Sorry that I can't be more specific or more helpful about this. Dashamir -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Fri Jun 8 15:40:55 2018 From: wk at gnupg.org (Werner Koch) Date: Fri, 08 Jun 2018 15:40:55 +0200 Subject: [Announce] [security fix] GnuPG 2.2.8 released (CVE-2018-12020) Message-ID: <874lidz994.fsf@wheatstone.g10code.de> Hello! We are pleased to announce the availability of a new GnuPG release: version 2.2.8. This version fixes a critical security bug and comes with some other minor changes. Impact ====== All current GnuPG versions are affected on all platforms. All mail clients and other applications which make use of GPG but are not utilizing the GPGME library might be affected. The OpenPGP protocol allows to include the file name of the original input file into a signed or encrypted message. During decryption and verification the GPG tool can display a notice with that file name. The displayed file name is not sanitized and as such may include line feeds or other control characters. This can be used inject terminal control sequences into the out and, worse, to fake the so-called status messages. These status messages are parsed by programs to get information from gpg about the validity of a signature and an other parameters. Status messages are created with the option "--status-fd N" where N is a file descriptor. Now if N is 2 the status messages and the regular diagnostic messages share the stderr output channel. By using a made up file name in the message it is possible to fake status messages. Using this technique it is for example possible to fake the verification status of a signed mail. Although GnuPG takes great care to sanitize all diagnostic and status output, the case at hand was missed but finally found and reported by Marcus Brinkmann. CVE-2018-12020 was assigned to this bug; GnuPG tracks it at . Solution ======== If your application uses GPGME your application is safe. Fortunately most modern mail readers use GPGME, including GpgOL and KMail. Mutt users should make sure to use "set crypt_use_gpgme". If you are parsing GnuPG status output and you use a dedicated file descriptor with --status-fd you are safe. A dedicated file descriptor is one that is not shared with the log output. The log output defaults to stderr (2) but may be a different if the option --logger-fd is used. If you are not using --verbose you are safe. But take care: --verbose might be specified in the config file. As a short term mitigation or if you can't immediately upgrade to the latest versions, you can add --no-verbose to the invocation of gpg. Another short term mitigation is to redirect the log output to a different file: For example "--log-file /dev/null". The suggested solution is to update to GnuPG 2.2.8 or a vendor provided update of their GnuPG version. To check whether the bug has been fixed you may use the simple test at the end of this mail [1]. About GnuPG =========== The GNU Privacy Guard (GnuPG) is a complete and free implementation of the OpenPGP standard which is commonly abbreviated as PGP. 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. 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.8 =================================== * gpg: Decryption of messages not using the MDC mode will now lead to a hard failure even if a legacy cipher algorithm was used. The option --ignore-mdc-error can be used to turn this failure into a warning. Take care: Never use that option unconditionally or without a prior warning. * gpg: The MDC encryption mode is now always used regardless of the cipher algorithm or any preferences. For testing --rfc2440 can be used to create a message without an MDC. * gpg: Sanitize the diagnostic output of the original file name in verbose mode. [#4012,CVE-2018-12020] * gpg: Detect suspicious multiple plaintext packets in a more reliable way. [#4000] * gpg: Fix the duplicate key signature detection code. [#3994] * gpg: The options --no-mdc-warn, --force-mdc, --no-force-mdc, --disable-mdc and --no-disable-mdc have no more effect. * agent: Add DBUS_SESSION_BUS_ADDRESS and a few other envvars to the list of startup environment variables. [#3947] Getting the Software ==================== Please follow the instructions found at or read on: GnuPG 2.2.8 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.8.tar.bz2 (6477k) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.8.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.8_20180608.exe (3916k) https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.8_20180608.exe.sig The source used to build the Windows installer can be found in the same directory with a ".tar.xz" suffix. A new Gpg4win installer featuring this version of GnuPG will be available soon. 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.8.tar.bz2 you would use this command: gpg --verify gnupg-2.2.8.tar.bz2.sig gnupg-2.2.8.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.8.tar.bz2, you run the command like this: sha1sum gnupg-2.2.8.tar.bz2 and check that the output matches the next line: d87553a125832ea90e8aeb3ceeecf24f88de56fb gnupg-2.2.8.tar.bz2 3126ec2b7005063cbff95792208796dfa42c2a22 gnupg-w32-2.2.8_20180608.tar.xz 231b29631647328934a35f8c6baa483e7594e26a gnupg-w32-2.2.8_20180608.exe Internationalization ==================== This version of GnuPG has support for 26 languages with Chinese, Czech, French, German, Japanese, Norwegian, 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 availabale 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 . The chapters on gpg-agent, gpg and gpgsm include information on how to set up the whole thing. 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. 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 check out . 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 ====== Maintenance and development of GnuPG is mostly financed by donations. The GnuPG project currently employs one full-time developer and one contractor. Both work exclusively on GnuPG and closely related software like Libgcrypt, GPGME, and GPA. We are planning to extend our team again and to help developers to improve integration of crypto in their applications. We have to thank all the people who helped the GnuPG project, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, and 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 shape and address all the small and larger requests made by our users. Thanks. 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: 2019-12-31] Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) rsa2048 2014-10-29 [expires: 2019-12-31] Key fingerprint = 46CC 7308 65BB 5C78 EBAB ADCF 0437 6F3E E085 6959 David Shaw (GnuPG Release Signing Key) 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) 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. =========== [1] If you want to test whether you are affected by this bug, remove the indentation from the following block -----BEGIN PGP MESSAGE----- jA0EBwMC1pW2pqoYvbXl0p4Bo5z/v7PXy7T1BY/KQxWaE9uTBRbf4no64/+5YYzX +BVNqP+82aBFYXEsD9x1vGuYwofQ4m/q/WcQDEPXhRyzU+4yiT3EOuG7sTTaQR3b 8xAn2Qtpyq5tO7k9CN6dasaXKSduXVmFUqzgU+W9WaTLOKNDFw6FYV3lnOoPtFcX rzhh2opkX9Oh/5DUkZ6YmUIX3j/A0z+59/qNO1i2hQ== =zswl -----END PGP MESSAGE----- and pass to this pipeline gpg --no-options -vd 2>&1 | grep '^\[GNUPG:] INJECTED' If you get some output you are using a non-fixed version. -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available 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 ca+gnupg-devel at esmtp.org Fri Jun 8 16:27:36 2018 From: ca+gnupg-devel at esmtp.org (Claus Assmann) Date: Fri, 8 Jun 2018 07:27:36 -0700 Subject: gpg 2.2.8: mainproc.c:686: error: 'GPGRT_LOGLVL_INFO' undeclared Message-ID: <20180608142736.GA21641@x2.esmtp.org> Hmm, did I do something wrong? mainproc.c: In function 'proc_encrypted': mainproc.c:686: error: 'GPGRT_LOGLVL_INFO' undeclared (first use in this function) That macro doesn't seem to be defined anywhere in this source code (does it rely on some include file from some other lib*?) Maybe it should be this: --- g10/mainproc.c- Fri Jun 8 07:20:01 2018 +++ g10/mainproc.c Fri Jun 8 07:20:12 2018 @@ -683,7 +683,7 @@ * are rare in practice we print a hint on how to decrypt * such messages. */ log_string - (GPGRT_LOGLVL_INFO, + (GPGRT_LOG_INFO, _("Hint: If this message was created before the year 2003 it is\n" "likely that this message is legitimate. This is because back\n" "then integrity protection was not widely used.\n")); From dgouttegattat at incenp.org Fri Jun 8 16:40:07 2018 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Fri, 8 Jun 2018 15:40:07 +0100 Subject: gpg 2.2.8: mainproc.c:686: error: 'GPGRT_LOGLVL_INFO' undeclared In-Reply-To: <20180608142736.GA21641@x2.esmtp.org> References: <20180608142736.GA21641@x2.esmtp.org> Message-ID: <89dd7cc8-280d-7e35-bbb4-effc0a25ee36@incenp.org> Hi, On 06/08/2018 03:27 PM, Claus Assmann wrote: > Hmm, did I do something wrong? > > mainproc.c: In function 'proc_encrypted': > mainproc.c:686: error: 'GPGRT_LOGLVL_INFO' undeclared (first use in this function) > > That macro doesn't seem to be defined anywhere in this source code > (does it rely on some include file from some other lib*?) It is defined in libgpg-error. You need at least libgpg-error >= 1.28. Damien -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From ben at adversary.org Fri Jun 8 17:02:36 2018 From: ben at adversary.org (Ben McGinnes) Date: Sat, 9 Jun 2018 01:02:36 +1000 Subject: Query regarding GPGME python Bindings In-Reply-To: References: Message-ID: <20180608150236.x2ubagwbjziaab3n@adversary.org> On Fri, Jun 08, 2018 at 03:05:23PM +0530, Divesh Uttamchandani wrote: > Hi, > > I am developing an application using gpgme python bindings. > I want to achieve the following gpg command functionality using gpgme. > > gpg --auto-key-locate=local,cert,keyserver,pka \ > --keyserver "$KEYSERVER" $recipients \ Direct access to keyserver (dirmngr) commands or functions is not currently included in GPGME. Since the SKS protocol is essentially sitting on HTTP and HTTPS, however, it's simple enough to replicate those features directly using existing Python methods. I *highly* recommend using the requests module for that part. The second part of this section is the implicit forwarding. That will be added to the Python bindings in a very Pythonic form very soon now. It's presently waiting on the other GSoC participant. So we'll see how his answer compares to a reference method I've got tucked away already. > --sign --encrypt --armor \ > --output "$file.sealed" "$file There are several different typed of encrypting or signing and encrypting in the HOWTO, plus there are multiple executable scripts in the lang/python/examples/howto/ directory which explicitly implement functions demonstrated in the HOWTO or which are discussed or referenced in it. This includes a script to generate Mutt and Neomutt crypthooks from the group lines in gpg.conf, as well as scripts to encrypt a file to every member of a group (which meets the criteria of the notmuch/alot users. > Way used: > 1) Set the keyserver in gpg.conf (in my case gpg.conf resides in > ~/.gnupg say) Keyserver entries in gpg.conf shouldn't be doing anything anymore, for it to do anything it should be in dirmngr.conf. Anything still in gpg.conf is simply a relic of older versions of GPG which predated the moving of that code. > 2) Set up the context with correct homedir > gpg.Context(home_dir="~/.gnupg") This is unnecessary if the homedir is the default one then leaving the homedir value as it's default (i.e. homedir=None) will result in the same thing. You should only change that when you're actually changing the homedir. > 3) For each recipient use LOCATE mode to get keylist > gpg.Context().keylist(recipient, mode=gpg.constants.keylist.mode.LOCATE) > > 4) from the list return by #3, confirm the contact from the user and add it > to a list of recipient keys I am maintaining. Oh no, it's much easier than that once you've antually got all their keys imported. Have a look at this file in the current master branch: lang/python/examples/howto/encrypt-to-group.py Plus this version which effectively implements it as "trust-model always": lang/python/examples/howto/encrypt-to-group-gullible.py Along with this version which never overrides the trust settings: lang/python/examples/howto/encrypt-to-group-trustno1.py > 5) Finally I can use these keys for encrypting as mentioned in the > example provided in part 2. > > Particularly I would like to know is there a way to provide > keyserver from gpgme itself and not in gpg.conf. As indicated above, presently it is in neither. When the other GSoC participant completes his next step it will be supplemented by both examples and documentation demonstrating precisely how to do this. Though if you've used requests to deal with any RESTful or REST-like API in the past, it should be pretty easy to work out from a quick glance at the SKS URLs and URIs. > I couldn't find details about these variables in the examples > provided, found this mostly using dir() and help() functions in > python. Though I also read the c documentation but I am not sure if > it the right way. The automatically generated GPGME documentation will only describe the underlying C functions and their corresponding lower level Python bindings. Using these directly is not ideal, it is far better to use the more Pythonic functions available in and being added to gpg.core and gpg.Context(). The reason for this is essentially two-fold: 1. The additional layer between your coding and the deeper bindings are a lot easier and more intuitive to use. They're also being explicitly documented in addition to the standard GPGME documentation, beginning earlier this year and subsequently alongside the addition of new functions. 2. It's possible that the underlying binaries may need to change in some respects for some platforms. By maintaining this more Pythonic layer above the real bindings, we can continue to deliver a standard implementation for Python developers even under those circumstances where the underlying bindings may need to veer away from the SWIG generated bindings. The latter isn't absolutely confirmed yet, but since the bindings tend not to work with Windows systems at all, it does seem rather likely that Microsoft will require, once again, special handling to reach even a fraction of what the rest of the world can as standard. I highly recommend you check out the current GPGME repository and at least track the master branch as you continue this little project. I also recommend you have a look at the work of Kenneth Reitz, if you haven't already done so. He created the requests module (and a few other things) while working at Heroku and since using these functions with things on the web is inevitable (even if we ignore keyserver access); spending some time working with requests is never a waste. With regards to the Python bindings, however, it may even be better to retrieve keys via requests than dirmngr itself, but I'm not entirely convinced of that, It may depend a little on the current state of dirmngr's DNS resolver when the data is to be retrieved via Tor. Using requests via Tor is fairly simple (in conjunction with privoxy), but using dnspython with Tor is, as far as I'm aware, untested. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From kristian.fiskerstrand at sumptuouscapital.com Fri Jun 8 16:50:35 2018 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Fri, 8 Jun 2018 16:50:35 +0200 Subject: gpg 2.2.8: mainproc.c:686: error: 'GPGRT_LOGLVL_INFO' undeclared In-Reply-To: <89dd7cc8-280d-7e35-bbb4-effc0a25ee36@incenp.org> References: <20180608142736.GA21641@x2.esmtp.org> <89dd7cc8-280d-7e35-bbb4-effc0a25ee36@incenp.org> Message-ID: <0afd51ff-426b-6bdd-8a87-4fe13119b473@sumptuouscapital.com> On 06/08/2018 04:40 PM, Damien Goutte-Gattat via Gnupg-devel wrote: > Hi, > > On 06/08/2018 03:27 PM, Claus Assmann wrote: >> Hmm, did I do something wrong? >> >> mainproc.c: In function 'proc_encrypted': >> mainproc.c:686: error: 'GPGRT_LOGLVL_INFO' undeclared (first use in this function) >> >> That macro doesn't seem to be defined anywhere in this source code >> (does it rely on some include file from some other lib*?) > > It is defined in libgpg-error. You need at least libgpg-error >= 1.28. Thank you both for the heads up, the configure.ac file needs to be updated to reflect this updated min requirement, but increased the package manager dependency now so will at least avoid downstream bug reports :) -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From dashohoxha at gmail.com Fri Jun 8 18:07:22 2018 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Fri, 8 Jun 2018 18:07:22 +0200 Subject: Query regarding GPGME python Bindings In-Reply-To: <20180608150236.x2ubagwbjziaab3n@adversary.org> References: <20180608150236.x2ubagwbjziaab3n@adversary.org> Message-ID: On Fri, Jun 8, 2018 at 5:02 PM, Ben McGinnes wrote: > On Fri, Jun 08, 2018 at 03:05:23PM +0530, Divesh Uttamchandani wrote: > > Hi, > > > > I am developing an application using gpgme python bindings. > > I want to achieve the following gpg command functionality using gpgme. > > > > gpg --auto-key-locate=local,cert,keyserver,pka \ > > --keyserver "$KEYSERVER" $recipients \ > > Direct access to keyserver (dirmngr) commands or functions is not > currently included in GPGME. Since the SKS protocol is essentially > sitting on HTTP and HTTPS, however, it's simple enough to replicate > those features directly using existing Python methods. > > I *highly* recommend using the requests module for that part. > As a workaround, or temporary solution, you can also try to use the commands: gpg --keyserver="$keyserver" --search-keys "$recipient" gpg --keyserver="$keyserver" --recv-keys ... for fetching the recipients that are not available locally. Later you can replace this with Python code. Regards, Dashamir -------------- next part -------------- An HTML attachment was scrubbed... URL: From ca+gnupg-devel at esmtp.org Fri Jun 8 19:35:38 2018 From: ca+gnupg-devel at esmtp.org (Claus Assmann) Date: Fri, 8 Jun 2018 10:35:38 -0700 Subject: gpg 2.2.8: mainproc.c:686: error: 'GPGRT_LOGLVL_INFO' undeclared In-Reply-To: <89dd7cc8-280d-7e35-bbb4-effc0a25ee36@incenp.org> References: <20180608142736.GA21641@x2.esmtp.org> <89dd7cc8-280d-7e35-bbb4-effc0a25ee36@incenp.org> Message-ID: <20180608173538.GA21395@x2.esmtp.org> On Fri, Jun 08, 2018, Damien Goutte-Gattat via Gnupg-devel wrote: > > mainproc.c:686: error: 'GPGRT_LOGLVL_INFO' undeclared (first use in this function) > It is defined in libgpg-error. You need at least libgpg-error >= 1.28. Hmm, all the other calls use GPGRT_LOG_*, not GPGRT_LOGLVL_* ./g10/keyedit.c: ? GPGRT_LOG_INFO : GPGRT_LOG_ERROR, ./g10/call-agent.c: GPGRT_LOG_INFO : GPGRT_LOG_ERROR, ./g10/tofu.c: log_string (GPGRT_LOG_INFO, msg); ./g10/tofu.c: log_string (GPGRT_LOG_INFO, text); ./sm/certchain.c: log_logv (is_error? GPGRT_LOG_ERROR: GPGRT_LOG_INFO, format, arg_ptr); ./dirmngr/dirmngr.c: log_logv_with_prefix (GPGRT_LOG_INFO, "ntbtls: ", fmt, argv); ./kbx/kbxutil.c: case GCRY_LOG_INFO: level = GPGRT_LOG_INFO; break; ./common/logging.h: GPGRT_LOG_INFO, ./common/miscellaneous.c: case GCRY_LOG_INFO: level = GPGRT_LOG_INFO; break; ./common/logging.c: case GPGRT_LOG_INFO: break; ./common/logging.c: do_logv (GPGRT_LOG_INFO, 0, NULL, NULL, fmt, arg_ptr); and log_string() is defined common/logging.c, so using a different "value" doesn't seem to make much sense... (but I don't the source well enough). From wk at gnupg.org Fri Jun 8 21:53:18 2018 From: wk at gnupg.org (Werner Koch) Date: Fri, 08 Jun 2018 21:53:18 +0200 Subject: gpg 2.2.8: mainproc.c:686: error: 'GPGRT_LOGLVL_INFO' undeclared In-Reply-To: <89dd7cc8-280d-7e35-bbb4-effc0a25ee36@incenp.org> (Damien Goutte-Gattat via Gnupg-devel's message of "Fri, 8 Jun 2018 15:40:07 +0100") References: <20180608142736.GA21641@x2.esmtp.org> <89dd7cc8-280d-7e35-bbb4-effc0a25ee36@incenp.org> Message-ID: <87sh5xxdg1.fsf@wheatstone.g10code.de> On Fri, 8 Jun 2018 16:40, gnupg-devel at gnupg.org said: > It is defined in libgpg-error. You need at least libgpg-error >= 1.28. The fun of merging. Master is prepared to work with a newer libgpg-error but 2.2 is not. I missed this when cherry picking. Urgs. Looks like a 2.2.9 tomorrow. Shalom-Salam, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From ca+gnupg-devel at esmtp.org Sat Jun 9 03:48:02 2018 From: ca+gnupg-devel at esmtp.org (Claus Assmann) Date: Fri, 8 Jun 2018 18:48:02 -0700 Subject: gpg 2.2.8: Test FAILures Message-ID: <20180609014802.GA29613@x2.esmtp.org> I don't know if these are important, but maybe it's worth sending to the list (removed the "PASS" entries to reduce the amount of data). Making check in gpgscm ... Checking decryption of supplied files > plain-1 gpg: encrypted with 1024-bit ELG key, ID ABAB28A247BE2775, created 2003-12-31 "Test one (pp=def) " gpg: uncompressing failed: Unknown compression algorithm : (() ((throw (:stderr result)) (call-popen cmd input))) 0: # 1: tests.scm:443: (apply throw error) FAIL: tests/openpgp/decrypt.scm Checking decryption of supplied files using --multifile. ("SOMEDIR/gnupg-2.2.8/g10/gpg" --no-permission-warning --always-trust --decrypt --multifile "plain-1.asc" "plain-2.asc" "plain-3.asc" "plain-large.asc") failed: gpg: encrypted with 1024-bit ELG key, ID ABAB28A247BE2775, created 2003-12-31 "Test one (pp=def) " gpg: uncompressing failed: Unknown compression algorithm gpg: encrypted with 1024-bit ELG key, ID ABAB28A247BE2775, created 2003-12-31 "Test one (pp=def) " gpg: uncompressing failed: Unknown compression algorithm gpg: encrypted with 1024-bit ELG key, ID ABAB28A247BE2775, created 2003-12-31 "Test one (pp=def) " gpg: uncompressing failed: Unknown compression algorithm gpg: encrypted with 1024-bit ELG key, ID ABAB28A247BE2775, created 2003-12-31 "Test one (pp=def) " gpg: uncompressing failed: Unknown compression algorithm 0: tests.scm:122: (throw (string-append (stringify what) " failed") (:stderr result)) 1: decrypt-multifile.scm:38: (call-check `(, at gpg --decrypt --multifile , at encrypted-files)) FAIL: tests/openpgp/decrypt-multifile.scm Checking decryption of supplied DSA encrypted file > plain-1 gpg: encrypted with 768-bit ELG key, ID 5B7A02F0CB879DE9, created 1998-03-17 "pgp5 test " gpg: uncompressing failed: Unknown compression algorithm gpg: WARNING: message was not integrity protected : (() ((throw (:stderr result)) (call-popen cmd input))) 0: # 1: tests.scm:443: (apply throw error) FAIL: tests/openpgp/decrypt-dsa.scm Checking decryption of supplied files using the session key. > plain-1 gpg: encrypted with 1024-bit ELG key, ID ABAB28A247BE2775, created 2003-12-31 "Test one (pp=def) " gpg: session key: '2:93E759AAACAE2A1A3D6C13AF185F846ACF803D684C0DB6BE' gpg: uncompressing failed: Unknown compression algorithm 0: tests.scm:129: (throw (:stderr result)) 1: decrypt-session-key.scm:25: (call-popen `(, at gpg --status-fd=1 --decrypt --show-session-key --output ,sink ,filename) "") FAIL: tests/openpgp/decrypt-session-key.scm Checking unwrapping the encryption. > encsig-2-keys-3 ("SOMEDIR/gnupg-2.2.8/g10/gpg" --no-permission-warning --always-trust --verify "/tmp/gpgscm-20180609T013249-decrypt-unwrap-verify-fblHp2/unwrapped") failed: gpg: uncompressing failed: Unknown compression algorithm gpg: verify signatures failed: Unknown compression algorithm 0: tests.scm:122: (throw (string-append (stringify what) " failed") (:stderr result)) 1: decrypt-unwrap-verify.scm:40: (call-check `(, at gpg --verify ,unwrapped)) 2: init.scm:443: (thunk) FAIL: tests/openpgp/decrypt-unwrap-verify.scm > plain-1 plain-2 plain-3 plain-large data-500 data-9000 data-32000 data-80000 < Checking bug 537: MDC problem with old style compressed packets. gpg: encrypted with 1024-bit ELG key, ID ABAB28A247BE2775, created 2003-12-31 "Test one (pp=def) " gpg: uncompressing failed: Unknown compression algorithm ... 0: tests.scm:129: (throw (:stderr result)) 1: signencrypt.scm:35: (call-popen `(, at gpg --yes --passphrase-fd "0" --output ,tmp --decrypt ,(in-srcdir "tests" "openpgp" "bug537-test.data.asc")) usrpass1) FAIL: tests/openpgp/signencrypt.scm .... Checking bogus signature > #x2d #xca < Checking that a valid signature is verified as such > msg_ols_asc msg_cols_asc (((SOMEDIR/gnupg-2.2.8/g10/gpg --no-permission-warning --always-trust --verify) 6446 2)) FAIL: tests/openpgp/verify.scm Checking verification of supplied files using --multifile. gpg: Signature made Wed Jun 22 10:00:38 2016 CEST gpg: using RSA key AA43F1DCC7FED1B7 gpg: issuer "steve.biko at example.net" gpg: Good signature from "steve.biko at example.net" [unknown] gpg: WARNING: Using untrusted key! gpg: uncompressing failed: Unknown compression algorithm 0: tests.scm:129: (throw (:stderr result)) 1: verify-multifile.scm:28: (call-popen `(, at gpg --verify --multifile --status-fd=1 ,@(map (lambda (name) (in-srcdir "tests" "openpgp" "samplemsgs" name)) files)) "") FAIL: tests/openpgp/verify-multifile.scm Checking bogus signature > #x2d #xca < Checking that a valid signature is verified as such > msg_ols_asc msg_cols_asc (((SOMEDIR/gnupg-2.2.8/g10/gpgv --keyring pubring.kbx) 6483 2)) FAIL: tests/openpgp/gpgv.scm .... Checking armored_key_8192 Importing alpha_seckey Checking for bug #1179 (((SOMEDIR/gnupg-2.2.8/g10/gpg --no-permission-warning --always-trust --output - --decrypt -) 6519 2)) FAIL: tests/openpgp/armor.scm .... Preparing for ECC test Importing ECC public keys Checking opaque ECDSA signatures > msg_opaque_signed_256 ("SOMEDIR/gnupg-2.2.8/g10/gpg" --output "/tmp/gpgscm-20180609T013352-ecc-WhAF3Q/y" --verify "/tmp/gpgscm-20180609T013352-ecc-OgUWUX/x") failed: gpg: uncompressing failed: Unknown compression algorithm gpg: verify signatures failed: Unknown compression algorithm 0: tests.scm:122: (throw (string-append (stringify what) " failed") (:stderr result)) 1: ecc.scm:79: (call-check `(,(tool 'gpg) --output ,y --verify ,x)) 2: init.scm:429: (func (let ((current-ws *active-windings*)) (lambda (x) (set-active-windings! current-ws) (continuation x)))) 3: # 4: init.scm:422: (old-c/cc (lambda (continuation) (func (let ((current-ws *active-windings*)) (lambda (x) (set-active-windings! current-ws) (continuation x)))))) 5: (call/cc (lambda (**exit**) (push-handler (lambda *error* (**exit** (begin (remove-temporary-file y) (rethrow *error*))))) (let ((gensym-44 (begin (begin (call-with-output-file x (lambda (p) (display (eval test (current-environment)) p))) (call-check `(,(tool 'gpg) --output ,y --verify ,x)) (unless (file=? y z) (fail "mismatch")))))) (pop-handler) gensym-44))) FAIL: tests/openpgp/ecc.scm .... gpgscm: error running '/etc/ssh': probably not installed (wait-process "/etc/ssh" 6898 #t): Configuration error 0: ffi.scm:39: (throw (get-output-string args') message) 1: ffi.scm:30: (ffi-fail name args (strerror (car result))) 2: :1: (ffi-apply "wait-process" _-wait-process a) 3: tests.scm:103: (wait-process (car what) (:pid h) #t) 4: ssh-import.scm:40: (call-with-io `(,ssh "-V") "") FAIL: tests/openpgp/ssh-import.scm .... =================== 60 tests run, 45 succeeded, 12 failed, 0 failed expectedly, 0 succeeded unexpectedly, 3 skipped. Failed tests: tests/openpgp/ssh-import.scm tests/openpgp/ecc.scm tests/openpgp/armor.scm tests/openpgp/gpgv.scm tests/openpgp/verify-multifile.scm tests/openpgp/verify.scm tests/openpgp/signencrypt.scm tests/openpgp/decrypt-unwrap-verify.scm tests/openpgp/decrypt-session-key.scm tests/openpgp/decrypt-dsa.scm tests/openpgp/decrypt-multifile.scm tests/openpgp/decrypt.scm Skipped tests: tests/openpgp/issue2929.scm tests/openpgp/tofu.scm tests/openpgp/4gb-packet.scm =================== From gnupg-devel at spodhuis.org Sat Jun 9 05:34:05 2018 From: gnupg-devel at spodhuis.org (Phil Pennock) Date: Fri, 8 Jun 2018 23:34:05 -0400 Subject: Query regarding GPGME python Bindings In-Reply-To: <20180608150236.x2ubagwbjziaab3n@adversary.org> References: <20180608150236.x2ubagwbjziaab3n@adversary.org> Message-ID: <20180609033404.GA48491@osmium.lan> On 2018-06-09 at 01:02 +1000, Ben McGinnes wrote: > Direct access to keyserver (dirmngr) commands or functions is not > currently included in GPGME. Since the SKS protocol is essentially > sitting on HTTP and HTTPS, however, it's simple enough to replicate > those features directly using existing Python methods. nit, with pointers to correct terms to hopefully be helpful for those trying to research and not just be nit-picking: the protocol is HKP (or HKPS), implemented by a variety of keyservers. SKS is a protocol for set reconciliation between keyservers and not implemented (nor appropriate to implement) by GnuPG; it's used by the SKS software base and one or two other products. The SKS software, like almost all non-LDAP keyservers, implements an HKP interface too. I've some more details up at: including links to the HKP specs, such as they are (a thesis paper and an expired draft). -Phil From marcelf at selfnet.de Sat Jun 9 09:13:23 2018 From: marcelf at selfnet.de (Marcel Fest) Date: Sat, 9 Jun 2018 09:13:23 +0200 Subject: Query regarding GPGME python Bindings In-Reply-To: References: <20180608150236.x2ubagwbjziaab3n@adversary.org> Message-ID: <38cd3dc6-850f-1153-7423-c797a5d7948b@selfnet.de> > As a workaround, or temporary solution, you can also try to use the > commands: > gpg --keyserver="$keyserver" --search-keys "$recipient" > gpg --keyserver="$keyserver" --recv-keys ... > for fetching the recipients that are not available locally. > Later you can replace this with Python code. > > Regards, > Dashamir If someone needs code for hkp/hkps, their is some on my own project. https://github.com/Selfnet/multivault/tree/master/multivault/hkp It was originally written for urllib2 but I ported it to the requests library. https://github.com/dgladkov/python-hkp Is the original codebase of my code, I modified it in purpose of the requests library. --------------------------------------------------------------------- Other question. Is it possible with gpgme, to create a new initialized homedir. I only find that option in the gpg cli but not in the gpgme bindings. How would I achieve that? Best Regards Marcel Fest -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From dashohoxha at gmail.com Sat Jun 9 11:07:09 2018 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Sat, 9 Jun 2018 11:07:09 +0200 Subject: PhD project ideas Message-ID: Hi, I am trying to apply for PhD studies, and usually they ask you for a project proposal, what will be the topic of your research (and development). The time of PhD studies is usually 3 years. I have a couple of ideas myself, but I would also like to ask your opinion. Are there any project ideas that can benefit or improve GnuPG? For example, from some discussions here I get that the fact that keyservers do not allow you to remove your keys may be a problem for the right to be forgotten of GDPR. Personally I think that keyservers should allow the users to remove their own keys. If this is a bad thing, let the user software take care of it, do not enforce it on the keyserver. The keyserver is just a servant and it should obey the orders of the user, even if they damage the user himself. The user's software (that runs in the computer of the user, `gpg` or something else), should warn the user about the bad consequences of making a wrong decision. But if the user wants to shoot himself on his foot, let him do it. This is in line with the Unix/Linux philosophy that the user knows what he is doing. So, would an improvement or rewrite of the keyserver software be a useful project for GnuPG (and a good PhD project proposal)? What other projects could be beneficial for GnuPG? If you had money available for sponsoring PhD students, for what projects would you spend them? Regards, Dashamir -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Sat Jun 9 10:58:11 2018 From: wk at gnupg.org (Werner Koch) Date: Sat, 09 Jun 2018 10:58:11 +0200 Subject: gpg 2.2.8: Test FAILures In-Reply-To: <20180609014802.GA29613@x2.esmtp.org> (Claus Assmann's message of "Fri, 8 Jun 2018 18:48:02 -0700") References: <20180609014802.GA29613@x2.esmtp.org> Message-ID: <87d0x0xroc.fsf@wheatstone.g10code.de> On Sat, 9 Jun 2018 03:48, ca+gnupg-devel at esmtp.org said: > gpg: uncompressing failed: Unknown compression algorithm What is the output of gpg --version? Salam-Shalom, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Sat Jun 9 11:49:11 2018 From: wk at gnupg.org (Werner Koch) Date: Sat, 09 Jun 2018 11:49:11 +0200 Subject: PhD project ideas In-Reply-To: (Dashamir Hoxha's message of "Sat, 9 Jun 2018 11:07:09 +0200") References: Message-ID: <874licxpbc.fsf@wheatstone.g10code.de> On Sat, 9 Jun 2018 11:07, dashohoxha at gmail.com said: > The keyserver is just a servant and it should obey the orders > of the user, even if they damage the user himself. The keyservers are the white pages for keys. You can't change white pages once they have been printed and delivered. Well, unless you setup a Minitrue. Salam-Shalom, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From andrewg at andrewg.com Sat Jun 9 13:34:24 2018 From: andrewg at andrewg.com (Andrew Gallagher) Date: Sat, 9 Jun 2018 12:34:24 +0100 Subject: PhD project ideas In-Reply-To: References: Message-ID: > On 9 Jun 2018, at 10:07, Dashamir Hoxha wrote: > > The keyserver is just a servant and it should obey the orders > of the user, even if they damage the user himself. The keyservers don?t obey anyone?s orders. They a fairly dumb, but efficient, cache. If you want a system that obeys orders then it might be better to use something like WKD or keybase, where keys are attached to individual user accounts. The keyservers perform three main services: finding keys, updating keys and revoking keys. There are other ways of finding and updating keys these days, even if none of them are as broadly used. For me though, the killer application for the keyservers is efficient distribution of revocations. In a GDPR apocalypse scenario the simplest fallback position for the keyservers is probably to blacklist any packets containing user IDs. This would mean keyservers would no longer be usable for finding keys by ID, but their other functions would be maintained. This has all been discussed in excruciating detail over on the sks-devel list in the last few months, including several suggestions for keyserver improvements. This thread is probably best continued there. A From dashohoxha at gmail.com Sat Jun 9 14:51:23 2018 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Sat, 9 Jun 2018 14:51:23 +0200 Subject: PhD project ideas In-Reply-To: References: Message-ID: On Sat, Jun 9, 2018 at 1:34 PM, Andrew Gallagher wrote: > > > On 9 Jun 2018, at 10:07, Dashamir Hoxha wrote: > > > > The keyserver is just a servant and it should obey the orders > > of the user, even if they damage the user himself. > > The keyservers don?t obey anyone?s orders. They a fairly dumb, but > efficient, cache. If you want a system that obeys orders then it might be > better to use something like WKD or keybase, where keys are attached to > individual user accounts. > I don't know what is WKD, and Keybase as far as I know is centralized, it is not distributed. If it was distributed, it would have been a better alternative than keyservers, in my opinion. The keyservers perform three main services: finding keys, updating keys and > revoking keys. There are other ways of finding and updating keys these > days, even if none of them are as broadly used. For me though, the killer > application for the keyservers is efficient distribution of revocations. > In a GDPR apocalypse scenario the simplest fallback position for the > keyservers is probably to blacklist any packets containing user IDs. This > would mean keyservers would no longer be usable for finding keys by ID, but > their other functions would be maintained. > The problem is that I don't care about the keys, because I communicate with people, not with keys. The keys are just a means of communication. If user information is removed from the keys, then keyservers become almost useless, as far as I am concerned. I don't think there is going to be any "GDPR apocalypse". This has also been clarified from previous discussions here. But I do think that the keys should not be published for ever and ever, up to the eternity. The owner should be able to remove them for whatever reason he deems this is right. This has all been discussed in excruciating detail over on the sks-devel > list in the last few months, including several suggestions for keyserver > improvements. This thread is probably best continued there. > Of course. But this thread was not only about the keyservers, they were just an example. Dashamir -------------- next part -------------- An HTML attachment was scrubbed... URL: From ca+gnupg-devel at esmtp.org Sat Jun 9 15:50:34 2018 From: ca+gnupg-devel at esmtp.org (Claus Assmann) Date: Sat, 9 Jun 2018 06:50:34 -0700 Subject: gpg 2.2.8: Test FAILures In-Reply-To: <87d0x0xroc.fsf@wheatstone.g10code.de> References: <20180609014802.GA29613@x2.esmtp.org> <87d0x0xroc.fsf@wheatstone.g10code.de> Message-ID: <20180609135034.GA30080@x2.esmtp.org> On Sat, Jun 09, 2018, Werner Koch wrote: > On Sat, 9 Jun 2018 03:48, ca+gnupg-devel at esmtp.org said: > > gpg: uncompressing failed: Unknown compression algorithm > What is the output of gpg --version? gpg (GnuPG) 2.2.8 libgcrypt 1.8.2 Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: $HOME/.gnupg ## modified... Supported algorithms: Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed ggp has been configured with: --disable-bzip2 --disable-zip If at least one compression method is needed, maybe configure should enforce that? Otherwise it might be a good idea to let the tests check if they can succeed at all (its requirement/preconditions are met). After enabling one compression method only tests/openpgp/ssh-import.scm fails; this message: gpgscm: error running '/etc/ssh': probably not installed is a bit confusing: /etc/ssh is a directory on the system, I "guess" the algorithm to look for the ssh binary finds the directory: (define path (string-split (getenv "PATH") *pathsep*)) (define ssh #f) (catch (skip "ssh not found") (set! ssh (path-expand "ssh" path))) because /etc is in PATH. Maybe it should check if the "item" it found is actually an executable program? S_ISREG(st_mode) && (st_mode & (S_IXUSR|S_IXGRP|S_IXOTH)) From aheinecke at intevation.de Mon Jun 11 08:20:52 2018 From: aheinecke at intevation.de (Andre Heinecke) Date: Mon, 11 Jun 2018 08:20:52 +0200 Subject: PhD project ideas In-Reply-To: References: Message-ID: <1957939.bW4m131END@esus> Hi, On Saturday, June 9, 2018 2:51:23 PM CEST Dashamir Hoxha wrote: > I don't know what is WKD, and Keybase as far as I know is centralized, it > is not distributed. WKD is the Web Key Directory [1][2] so that you can do with recent versions of GnuPG a: "gpg --locate-key aheinecke at intevation.de" Which then gets the key from intevation.de without a keyserver and without a walkable directory. As for other projects maybe some ideas: - A look at the trustmodels of OpenPGP with maybe ideas how to improve them or their usage. - Usability studies of OpenPGP MUA's and comments / improvements about this. (Why Johnny still still can't encrypt) Here with the focus on concrete suggestions what to imrpove. - Private key sync between multiple devices. - Private key backup that is understandable to users who generally only know recoverable passwords as secret. Best Regards, Andre 1: https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-service 2: https://wiki.gnupg.org/WKD -- Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Mon Jun 11 10:53:39 2018 From: wk at gnupg.org (Werner Koch) Date: Mon, 11 Jun 2018 10:53:39 +0200 Subject: PhD project ideas In-Reply-To: <1957939.bW4m131END@esus> (Andre Heinecke's message of "Mon, 11 Jun 2018 08:20:52 +0200") References: <1957939.bW4m131END@esus> Message-ID: <877en5hffw.fsf@wheatstone.g10code.de> On Mon, 11 Jun 2018 08:20, aheinecke at intevation.de said: > - Private key sync between multiple devices. I already started with that. No code yet, though. Salam-Shalom, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From andrewg at andrewg.com Mon Jun 11 11:06:27 2018 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 11 Jun 2018 10:06:27 +0100 Subject: PhD project ideas In-Reply-To: References: Message-ID: <69debf70-20bb-8970-3210-e4983dac0194@andrewg.com> On 09/06/18 13:51, Dashamir Hoxha wrote: > If user information is removed from the keys, then keyservers become > almost useless, as far as I am concerned. They become useless for the purposes of searching by user ID. But the association of a user ID to a given key is only the first step in the process. Once that is done, all sorts of other things happen in the background based on fingerprints, and which the ordinary user will rarely see because they are automated. For example, keyservers are vital for propagating revocations. If my key is stolen, and I revoke it, the best place to publish that revocation is on the keyservers. They are the most widely supported directory and it is not only possible but recommended that PGP clients refresh their keyrings from the keyservers on a schedule. Removing user IDs would not affect this process. -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 862 bytes Desc: OpenPGP digital signature URL: From look at my.amazin.horse Mon Jun 11 11:08:40 2018 From: look at my.amazin.horse (Vincent Breitmoser) Date: Mon, 11 Jun 2018 11:08:40 +0200 Subject: PhD project ideas In-Reply-To: <877en5hffw.fsf@wheatstone.g10code.de> References: <1957939.bW4m131END@esus> <877en5hffw.fsf@wheatstone.g10code.de> Message-ID: <20180611090840.6ft3nhljxgwwgdn3@calamity> > I already started with that. No code yet, though. Oh, interesting. Can you elaborate on your approach? Is there somewhere I can read about it? - V From dashohoxha at gmail.com Tue Jun 12 00:05:47 2018 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Tue, 12 Jun 2018 00:05:47 +0200 Subject: PhD project ideas In-Reply-To: <1957939.bW4m131END@esus> References: <1957939.bW4m131END@esus> Message-ID: On Mon, Jun 11, 2018 at 8:20 AM, Andre Heinecke wrote: > Hi, > > On Saturday, June 9, 2018 2:51:23 PM CEST Dashamir Hoxha wrote: > > I don't know what is WKD, and Keybase as far as I know is centralized, it > > is not distributed. > > WKD is the Web Key Directory [1][2] so that you can do with recent > versions of > GnuPG a: > > "gpg --locate-key aheinecke at intevation.de" > > Which then gets the key from intevation.de without a keyserver and > without a > walkable directory. > This seems interesting. I will look at WKD closer. Any P2P solution for sharing keys would be better than keyservers, in my opinion. > > As for other projects maybe some ideas: > - A look at the trustmodels of OpenPGP with maybe ideas how to improve > them or > their usage. > - Usability studies of OpenPGP MUA's and comments / improvements about > this. > (Why Johnny still still can't encrypt) Here with the focus on concrete > suggestions what to imrpove. > - Private key sync between multiple devices. > - Private key backup that is understandable to users who generally only > know > recoverable passwords as secret. > These ideas seem interesting too. I have been thinking myself about how to make GnuPG more easy and more accessible to people, so that it becomes a part of normal everyday life. For example nowadays even very old people and very young children have learned to use smartphones as a part of their everyday life. Who would have thought this a few years ago (myself I have started to use a smartphone almost a year ago). Can we make GnuPG part of the everyday life? A few months ago I applied for PhD to a university with a research project about this, but I was not accepted. Maybe I applied to the wrong university. I will append a copy of the project idea at the end of this message. Recently I have learned that people interested on Privacy Enhanced Technologies have a special mailing list where they post announcements about conferences, PhD positions, jobs etc. that are related to this topic. I don't know if there is any similar mailing list about the PGP/GPG topics. Regards, Dashamir --------------- project idea about making gnupg more popular --------------------- I have been interested on digital signatures, as an essential tool for enabling and supporting the digital identity and establishing a secure relationship between the people on the real world and digital documents. This is crucial for creating trust and security on the digital world and for building a digital society. Without digital signatures we cannot be sure that digital documents are original and we cannot be sure about their real author (they can be corrupted and manipulated). Without these guaranties, digital documents can never be considered official. So, despite using computers, digital systems and digital documents, we always have to rely on the hard copies of the documents and keep them around for official purposes, since we can?t fully trust the digital documents. This means that we will never be able to build totally digital systems for institutions and organizations, free from papers and hard-copy documents. I have also written an article that discusses and summarizes these issues, makes a comparison between the two authentication models, X.509 and OpenPGP, and makes a few proposals for solving existing issues: The Digital Signature and the X.509/OpenPGP Authentication Models https://www.researchgate.net/publication/317176950_The_Digital_Signature_and_the_X509OpenPGP_Authentication_Models The technology and tools for making digital signatures have been available since a long time. The legal framework for recognizing digitally signed documents as valid for official purposes does exist since many years. However we still don't see a widespread usage of digital signatures on everyday life. For example very few people use digital signatures to secure their email communications. It is even less used while exchanging digital documents between businesses, organizations, or with government institutions. There are clearly some problems that prevent the adaptation of the digital signature technology on the everyday life. Some of these problems may be: - The existing tools for making digital signatures are not enough user-friendly to be used by common people. - The existing infrastructure that supports digital identities and their verification/validation is not adequate to support the everyday life use-cases. - There is a lack of literacy about the digital signature and the available tools, and people don't really know why or how to use them. I have been interested for a long time about these issues and how to solve them. In the past years I have even developed a tool, called EasyGPG, which tries to solve the first issue mentioned above (making tools easy to use). It is a set of shell scripts that wrap GnuPG and try to make it more accessible and easy to use: https://github.com/EasyGnuPG/egpg If I get the chance to do my doctoral studies on your university, my objective would be to study and try to find adequate solutions for these problems. More specifically, I will study in more details any existing tools that help to ensure security and trust on the digital world, including asymmetric cryptography, digital signature tools and infrastructures, blockchain technologies, etc. Then I will try to design a system that applies these tools and technologies to solve a real world problem. For example, it can be a digitized notary office, which allows the notary to legalize a digital document by signing it with his digital signature. It can also help his clients to sign a digital contract with their digital signatures, which then can be stamped and legalized by the notary through his digital signature. The notary himself can also help his clients to create their digital certificates (with which they can sign their digital documents), and he can check, verify, and sign these digital certificates. Since the notary is a public, well known, and trusted person, the digital certificates verified and signed by him can also be trusted by other parties (institutions, partners, other notaries, etc.) I will also try to build a working prototype or a first version of this software. And of course I will try to make it as easy as possible, both for the notaries and for the clients, so that they find its usage intuitive and natural. In the long term, this may be the beginning of a start-up company, because the software will need to be maintained and improved, the notary offices may need training and support, the infrastructure may need maintenance, etc. It seems to me that this is an innovative project, which helps to transfer advanced technologies to the real world domain, where they can be accessible and available to everybody on their normal everyday life. If it succeeds, it may have a fundamental impact on the society and build a bridge to a fully digitized society. ----------- end of project idea ---------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Wed Jun 13 18:28:31 2018 From: wk at gnupg.org (Werner Koch) Date: Wed, 13 Jun 2018 18:28:31 +0200 Subject: [Announce] Libgcrypt 1.8.3 and 1.7.10 to fix CVE-2018-0495 Message-ID: <87efhabqhc.fsf@wheatstone.g10code.de> Hi! The GnuPG Project is pleased to announce the availability of Libgcrypt versions 1.8.3 and 1.7.10. These releases mitigate a novel side-channel attack on ECDSA signatures and also bring fixes for a few other bugs. Libgcrypt is a general purpose library of cryptographic building blocks. It is originally based on code used by GnuPG. It does not provide any implementation of OpenPGP or other protocols. Thorough understanding of applied cryptography is required to use Libgcrypt. Noteworthy changes in version 1.8.3 =================================== - Use blinding for ECDSA signing to mitigate a novel side-channel attack. [#4011,CVE-2018-0495] - Fix incorrect counter overflow handling for GCM when using an IV size other than 96 bit. [#3764] - Fix incorrect output of AES-keywrap mode for in-place encryption on some platforms. - Fix the gcry_mpi_ec_curve_point point validation function. - Fix rare assertion failure in gcry_prime_check. Release info at . We also released a new version of the older 1.7 branch with similar fixes. Comments on the attack ====================== Details on CVE-2018-0495 can be found in the paper "Return of the Hidden Number Problem" which can be downloaded from the advisory page . See for a timeline. One user of Libgcrypt is GnuPG, thus a quick comment: GnuPG does not use the vulenrable ECDSA signatures by default. Further, it is much harder to mount such an attack against an offline protocol like OpenPGP than against online protocols like TLS. Anyway, we also released a new Windows installer for GnuPG 2.2.8 featuring the fixed Libgcrypt version. That installer is linked from the usual download page and a new Gpg4win version will be released soon. Download ======== Source code is hosted at the GnuPG FTP server and its mirrors as listed at . On the primary server the source tarball and its digital signature are: https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.8.3.tar.bz2 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.8.3.tar.bz2.sig or gzip compressed: https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.8.3.tar.gz https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.8.3.tar.gz.sig The URLs for the older 1.7 branch are: https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.7.10.tar.bz2 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.7.10.tar.bz2.sig https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.7.10.tar.gz https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.7.10.tar.gz.sig In order to check that the version of Libgcrypt you downloaded is an original and unmodified file please follow the instructions found at . In short, you may use one of the following methods: - Check the supplied OpenPGP signature. For example to check the signature of the file libgcrypt-1.8.3.tar.bz2 you would use this command: gpg --verify libgcrypt-1.8.3.tar.bz2.sig libgcrypt-1.8.3.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 libgcrypt-1.8.3.tar.bz2, you run the command like this: sha1sum libgcrypt-1.8.3.tar.bz2 and check that the output matches the first line from the this list: 13bd2ce69e59ab538e959911dfae80ea309636e3 libgcrypt-1.8.3.tar.bz2 3b4d23db99ef13e6e305f536f009d9de8f5d0535 libgcrypt-1.8.3.tar.gz 66902603f7b6ad62c72db868d93b1772ac2a1afa libgcrypt-1.7.10.tar.bz2 a0aaea0c514c62de8533a955631134bc57f2e552 libgcrypt-1.7.10.tar.gz You should also verify that the checksums above are authentic by matching them with copies of this announcement. Those copies can be found at other mailing lists, web sites, and search engines. Copying ======= Libgcrypt is distributed under the terms of the GNU Lesser General Public License (LGPLv2.1+). The helper programs as well as the documentation are distributed under the terms of the GNU General Public License (GPLv2+). The file LICENSES has notices about contributions that require that these additional notices are distributed. Support ======= For help on developing with Libgcrypt you should read the included manual and optional ask on the gcrypt-devel mailing list [1]. A listing with commercial support offers for Libgcrypt and related software is available at the GnuPG web site [2]. If you are a developer and you may need a certain feature for your project, please do not hesitate to bring it to the gcrypt-devel mailing list for discussion. Thanks ====== Maintenance and development of GnuPG is mostly financed by donations. The GnuPG project currently employs one full-time developer and two contractors. They all work exclusively on GnuPG and closely related software like Libgcrypt, GPGME, and GPA. We have to thank all the people who helped the GnuPG project, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, and answering questions on the mailing lists. Special thanks to Keegan Ryan of NCC Group for his proper handling of the disclosure. Many thanks to our numerous financial supporters, both corporate and individuals. Without you it would not be possible to keep GnuPG in a good shape and address all the small and larger requests made by our users. Thanks. 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: 2019-12-31] Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) rsa2048 2014-10-29 [expires: 2019-12-31] Key fingerprint = 46CC 7308 65BB 5C78 EBAB ADCF 0437 6F3E E085 6959 David Shaw (GnuPG Release Signing Key) 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) 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: not available 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 tomas.zahradnicky at boxtrap.net Fri Jun 15 19:09:05 2018 From: tomas.zahradnicky at boxtrap.net (Tomas Zahradnicky) Date: Fri, 15 Jun 2018 19:09:05 +0200 Subject: Mac launchd socket activation Message-ID: <16d186f0-028e-63d9-9e0b-bfdf04f5816d@boxtrap.net> Hi everyone, I was trying to run gpg-agent in the supervised mode from macOS launchd. There seem to be at leasttwo problems with this approach: ? 1. launchd prohibits forking [1]; ? 2. in order to receive sockets from launchd, its launchd_activate_socket API must be used. The supervised mode does not break [1] but expects sockets to be configured from file descriptor 3 on along with LISTEN_FDNAMES and LISTEN_FDS environment variables configured. The proper way to acquire sockets from launchd should be by using its API. Here's our patch for gpg-agent using launchd_activate_socket against the master revision including a sample launchd plist file using the socket activation. All the best, Tomas References --------- 1. Apple, Inc. launchd.plist excerpt: A daemon or agent launched by launchd MUST NOT do the following in the process directly launched by launchd: ?????????? o?? Call daemon(3). ?????????? o?? Do the moral equivalent of daemon(3) by calling fork(2) and have the parent process exit(3) or _exit(2). Patch ----- diff --git a/agent/agent.h b/agent/agent.h index 9fdbc76d3..7ff2580d8 100644 --- a/agent/agent.h +++ b/agent/agent.h @@ -175,6 +175,10 @@ struct ?? /* The value of the option --s2k-count.? If this option is not given ??? * or 0 an auto-calibrated value is used.? */ ?? unsigned long s2k_count; +? /* Launchd activation. macOS only. When enabled, the sockets will +?? * be acquired from launchd by calling launch_activate_socket. +?? * Usable in the supervised mode. */ +? int launchd_activate_sockets; ?} opt; ? ? diff --git a/agent/gpg-agent.c b/agent/gpg-agent.c index 1fdc94d0f..6dfb10f35 100644 --- a/agent/gpg-agent.c +++ b/agent/gpg-agent.c @@ -30,6 +30,9 @@ ?#include ?#include ?#include +#ifdef __APPLE__ +#include +#endif ?#ifdef HAVE_W32_SYSTEM ?# ifndef WINVER ?#? define WINVER 0x0500? /* Same as in common/sysutils.c */ @@ -137,6 +140,7 @@ enum cmd_and_opt_values ?? oS2KCount, ?? oAutoExpandSecmem, ?? oListenBacklog, +? oLaunchdActivateSockets, ? ?? oWriteEnvFile ?}; @@ -263,6 +267,9 @@ static ARGPARSE_OPTS opts[] = { ?? ARGPARSE_s_n (oUseStandardSocket, "use-standard-socket", "@"), ?? ARGPARSE_s_n (oNoUseStandardSocket, "no-use-standard-socket", "@"), ? +? /* Launchd activation */ +? ARGPARSE_s_n (oLaunchdActivateSockets, "launchd-activate-sockets", N_("activate sockets from launchd")), + ?? ARGPARSE_end () /* End of list */ ?}; ? @@ -732,6 +739,30 @@ map_supervised_sockets (gnupg_fd_t *r_fd, ?????????????? if (!strcmp (fdnames[i], tbl[j].label) || j == DIM(tbl)-1) ???????????????? { ?????????????????? fd = 3 + i; +#if __APPLE__ +??????????????????? if( opt.launchd_activate_sockets ) +??????????????????? { +??????????????????????? int* fds = NULL; +??????????????????????? size_t cnt = 0; +??????????????????????? int err = launch_activate_socket( fdnames[i], &fds, &cnt ); +??????????????????????? if( err != 0 ) +??????????????????????? { +??????????????????????????? log_error("cannot activate socket %s because of error %d\n", fdnames[i], err); +??????????????????????????? break; +??????????????????????? } +??????????????????????? if( cnt > 0 ) +??????????????????????? { +??????????????????????????? fd = fds[0]; +??????????????????????????? free(fds); +??????????????????????? } +??????????????????????? else +??????????????????????? { +??????????????????????????? log_error("no socket returned for activation of socket %s\n", fdnames[i]); +??????????????????????????? continue; +??????????????????????? } +??????????????????? } +#endif + ?????????????????? if (**tbl[j].fdaddr == -1) ???????????????????? { ?????????????????????? name = gnupg_get_socket_name (fd); @@ -834,6 +865,7 @@ parse_rereadable_options (ARGPARSE_ARGS *pargs, int reread) ?????? /* Note: When changing the next line, change also gpgconf_list.? */ ?????? opt.ssh_fingerprint_digest = GCRY_MD_MD5; ?????? opt.s2k_count = 0; +????? opt.launchd_activate_sockets = 0; ?????? return 1; ???? } ? @@ -1260,6 +1292,10 @@ main (int argc, char **argv ) ?????????? /* Only used by the first stage command line parser.? */ ?????????? break; ? +??????? case oLaunchdActivateSockets: +????????? opt.launchd_activate_sockets = 1; +????????? break; + ???????? case oWriteEnvFile: ?????????? obsolete_option (configname, configlineno, "write-env-file"); ?????????? break; My ~/Library/LaunchAgents/net.boxtrap.gpg-agent.plist file ---------------------------------------------------------- ? ??? Label ??? net.boxtrap.gpg-agent ??? ProgramArguments ??? ????? /usr/local/MacGPG2/bin/gpg-agent ????? --supervised ????? --launchd-activate-sockets ????? --homedir ????? /Users/zahradt/.gnupg/ ????? --enable-ssh-support ????? --log-file ????? /Users/zahradt/Library/Logs/gpg-agent.log ??? ??? Sockets ??? ????? std ????? ??????? SockFamily ??????? Unix ??????? SockPathMode ??????? 448 ??????? SockPathName ??????? /Users/zahradt/.gnupg/S.gpg-agent ??????? SockType ??????? Stream ????? ????? browser ????? ??????? SockFamily ??????? Unix ??????? SockPathMode ??????? 448 ??????? SockPathName ??????? /Users/zahradt/.gnupg/S.gpg-browser ??????? SockType ??????? Stream ????? ????? extra ????? ??????? SockFamily ??????? Unix ??????? SockPathMode ??????? 448 ??????? SockPathName ??????? /Users/zahradt/.gnupg/S.gpg-extra ??????? SockType ??????? Stream ????? ????? ssh ????? ??????? SockFamily ??????? Unix ??????? SockPathMode ??????? 448 ??????? SockPathName ??????? /Users/zahradt/.gnupg/S.gpg-ssh ??????? SockType ??????? Stream ????? ??? ??? EnvironmentVariables ??? ????? LISTEN_FDNAMES ????? std:browser:extra:ssh ????? LISTEN_FDS ????? 4 ??? ??? StandardOutPath ??? /Users/zahradt/Library/Logs/gpg-agent.stdout.log ??? StandardErrorPath ??? /Users/zahradt/Library/Logs/gpg-agent.error.log ??? RunAtLoad ??? ? From ben at adversary.org Sun Jun 17 15:31:01 2018 From: ben at adversary.org (Ben McGinnes) Date: Sun, 17 Jun 2018 23:31:01 +1000 Subject: Query regarding GPGME python Bindings In-Reply-To: <38cd3dc6-850f-1153-7423-c797a5d7948b@selfnet.de> References: <20180608150236.x2ubagwbjziaab3n@adversary.org> <38cd3dc6-850f-1153-7423-c797a5d7948b@selfnet.de> Message-ID: <20180617133101.dyfd44unoi2lpxmr@adversary.org> On Sat, Jun 09, 2018 at 09:13:23AM +0200, Marcel Fest wrote: > > Is it possible with gpgme, to create a new initialized homedir. I > only find that option in the gpg cli but not in the gpgme bindings. > How would I achieve that? It's possible to specify an alternative homedir in GPGME and thus also in the Python bindings, just as can currently be done with the GPG binary. Creating and populating the entire hidden directory structure, however, is another matter ? which is why I scripted the part of that which GPGME doesn't do too. That script is here: lang/python/examples/howto/temp-homedir-config.py One of the many side benefitswhich grew out of needing to create keys for the Greatest Secret Agent in the World. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From marcelf at selfnet.de Sun Jun 17 16:21:14 2018 From: marcelf at selfnet.de (Marcel Fest) Date: Sun, 17 Jun 2018 16:21:14 +0200 Subject: AW: Re: Query regarding GPGME python Bindings In-Reply-To: <20180617133101.dyfd44unoi2lpxmr@adversary.org> References: <20180608150236.x2ubagwbjziaab3n@adversary.org> <38cd3dc6-850f-1153-7423-c797a5d7948b@selfnet.de> <20180617133101.dyfd44unoi2lpxmr@adversary.org> Message-ID: Thanks, so i can fully migrate to gpgme Python bindings. cu Marcel Fest ---- Ben McGinnes schrieb ---- >On Sat, Jun 09, 2018 at 09:13:23AM +0200, Marcel Fest wrote: >> >> Is it possible with gpgme, to create a new initialized homedir. I >> only find that option in the gpg cli but not in the gpgme bindings. >> How would I achieve that? > >It's possible to specify an alternative homedir in GPGME and thus also >in the Python bindings, just as can currently be done with the GPG >binary. > >Creating and populating the entire hidden directory structure, >however, is another matter ? which is why I scripted the part of that >which GPGME doesn't do too. That script is here: > >lang/python/examples/howto/temp-homedir-config.py > >One of the many side benefitswhich grew out of needing to create keys >for the Greatest Secret Agent in the World. > > >Regards, >Ben > >_______________________________________________ >Gnupg-devel mailing list >Gnupg-devel at gnupg.org >http://lists.gnupg.org/mailman/listinfo/gnupg-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From alon.barlev at gmail.com Mon Jun 18 18:45:06 2018 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Mon, 18 Jun 2018 19:45:06 +0300 Subject: [PATCH GNUPG] Remove unused check for mail program Message-ID: <20180618164506.21273-1-alon.barlev@gmail.com> * configure.ac (--with-mailprog): Remove. -- SENDMAIL substitution is never used. Signed-off-by: Alon Bar-Lev --- configure.ac | 21 --------------------- 1 file changed, 21 deletions(-) diff --git a/configure.ac b/configure.ac index 0d270a4..3d1c202 100644 --- a/configure.ac +++ b/configure.ac @@ -1200,27 +1200,6 @@ fi AM_CONDITIONAL(USE_LDAPWRAPPER, test "$use_ldapwrapper" = yes) - - -# -# Check for sendmail -# -# This isn't necessarily sendmail itself, but anything that gives a -# sendmail-ish interface to the outside world. That includes Exim, -# Postfix, etc. Basically, anything that can handle "sendmail -t". -AC_ARG_WITH(mailprog, - AC_HELP_STRING([--with-mailprog=NAME], - [use "NAME -t" for mail transport]), - ,with_mailprog=yes) -if test x"$with_mailprog" = xyes ; then - AC_PATH_PROG(SENDMAIL,sendmail,,$PATH:/usr/sbin:/usr/libexec:/usr/lib) -elif test x"$with_mailprog" != xno ; then - AC_MSG_CHECKING([for a mail transport program]) - AC_SUBST(SENDMAIL,$with_mailprog) - AC_MSG_RESULT($with_mailprog) -fi - - # # Construct a printable name of the OS # -- 2.16.4 From wk at gnupg.org Tue Jun 19 08:10:39 2018 From: wk at gnupg.org (Werner Koch) Date: Tue, 19 Jun 2018 08:10:39 +0200 Subject: [PATCH GNUPG] Remove unused check for mail program In-Reply-To: <20180618164506.21273-1-alon.barlev@gmail.com> (Alon Bar-Lev's message of "Mon, 18 Jun 2018 19:45:06 +0300") References: <20180618164506.21273-1-alon.barlev@gmail.com> Message-ID: <877emve274.fsf@wheatstone.g10code.de> On Mon, 18 Jun 2018 18:45, alon.barlev at gmail.com said: > SENDMAIL substitution is never used. But it should: In tools/wks-util.c:send_mail where sendmail is a fixed string. I fixed this. Thanks for the reminder. Salam-Shalom, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From calestyo at scientia.net Tue Jun 19 14:20:36 2018 From: calestyo at scientia.net (Christoph Anton Mitterer) Date: Tue, 19 Jun 2018 14:20:36 +0200 Subject: any way to use gpg(openpgp) with Argon2 Message-ID: <1a43612adb99968d1d6742647abde646f4afb53a.camel@scientia.net> Hey. I've had posted the email below to gnupg-users already but nobody seemed to have a clue. Is there any way to reasonably use a more secure passphrase hashing algo (e.g. Argon2) with gnupg? I'd guess it's not useful to just use argon2's output as passphrase as then the "normal" hashing (as controlled by the s2k* options) would still be the "weakest" link in the chain. Or is there any integration of argon2 planned into the standard (and this going to happen in a forseeable time)? Cheers, Chris. On Thu, 2018-06-07 at 14:50 +0200, Christoph Anton Mitterer wrote: > Hey. > > > I have the following scenario: > > > I'd like to archive private data to e.g. some cloud storage for > backup > reasons. > > Basically I'd see two ways to move on from here: > 1) Put the data in on or more disk images which are encrypted with > dm- > crypt/LUKS (e.g. using aes-xts-plain64) > > 2) Put the data in one or more tar or dar archive files, which I > think > is a bit more flexible. > With (2) I'd guess gnupg would be the tool of choice (or is there > anything else well-maintained?) and using e.g. AES256 should provide > adequate security. > > > In both cases, I'd want to put the actual key alongside the archive > (i.e. also backing it up the the remote storage, as I'd be screwed it > I > loose the key when I just store it locally). > For both (LUKS/OpenPGP), the actual symmetric key is anyway alongside > the image/archive encrypted by some passphrase (respectively the > pubkey, in case of asymmetric encryption with gpg). > > > > > Now here's the question/problem: > - LUKS/cryptsetup, at least in it's more recent version already > support > Argon2 and even for the older version there was a noticeable effect > when increasing the hashing iterations (like taking several minutes > for > cryptsetup to actually "open" the device). > For gpg there is --s2k-* especially --s2k-count, but even when > setting > this to the max value of 65011712... passphrase hashing seems super > fast. > > I'd be totally happy if a single passphrase try (for an attacker) > takes > like 10 minutes (just to be on the safe side)... but that doesn't > seem > possible with OpenPGP/gpg right now? > > > What would you guys suggest in my scenario? > > Is there a way to chain Argon2 with current gpg versions (not having > to > wait until this gets integrated in a new RFC in some future)? > > > Thanks, > Chris. From wk at gnupg.org Wed Jun 20 19:23:47 2018 From: wk at gnupg.org (Werner Koch) Date: Wed, 20 Jun 2018 19:23:47 +0200 Subject: any way to use gpg(openpgp) with Argon2 In-Reply-To: <1a43612adb99968d1d6742647abde646f4afb53a.camel@scientia.net> (Christoph Anton Mitterer's message of "Tue, 19 Jun 2018 14:20:36 +0200") References: <1a43612adb99968d1d6742647abde646f4afb53a.camel@scientia.net> Message-ID: <87o9g5cqxo.fsf@wheatstone.g10code.de> On Tue, 19 Jun 2018 14:20, calestyo at scientia.net said: > Or is there any integration of argon2 planned into the standard (and > this going to happen in a forseeable time)? I doubt that it will make it into rfc4880bis. I also see no reason for it. Passphrases must die. I fact OpenPGP is mostly about public key encryption and thus we don't use passphrases for its main tasks. Passphrases can be used to protect a private key but that is questionable because if you box is already compromised the passphrase does not help much. The other use of passphrases is symmetric-only encryption (command -c) but in most use cases the passphrase comes from another application or a database and is not entered manually. In this case I consider it better to use --s2k-mode=0 along with a full entropy passphrase instead of relying on passphrase mangling algorithms - they are designed for manual interaction and not for large scale use with thousands of messages. For disk encryption it is better to use a token than a secure passphrase most humans can't remember. Salam-Shalom, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wiktor at metacode.biz Wed Jun 20 22:06:42 2018 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Wed, 20 Jun 2018 22:06:42 +0200 Subject: WKD: User ID filtering Message-ID: <3fdb9a40-7c72-59ed-2130-9b622158b709@metacode.biz> Hello, During tests of gpg --locate-keys using WKD I noticed that the key UIDs are filtered, that is only UID that contains the e-mail passed to locate-keys is added to the keyring, no other UIDs. It seems reasonable but I couldn't find anything about this behavior in the WKD I-D. Is this by design? An implementation detail of gnupg? Should this behavior be documented/recommended in the I-D? Thank you for your time! Kind regards, Wiktor -- */metacode/* -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From muelli at cryptobitch.de Wed Jun 20 23:39:08 2018 From: muelli at cryptobitch.de (Tobias Mueller) Date: Wed, 20 Jun 2018 23:39:08 +0200 Subject: any way to use gpg(openpgp) with Argon2 In-Reply-To: <87o9g5cqxo.fsf@wheatstone.g10code.de> References: <1a43612adb99968d1d6742647abde646f4afb53a.camel@scientia.net> <87o9g5cqxo.fsf@wheatstone.g10code.de> Message-ID: <1529530748.15089.79.camel@cryptobitch.de> Hi, On Wed, 2018-06-20 at 19:23 +0200, Werner Koch wrote: > Passphrases can be used to protect > a private key but that is questionable because if you box is already > compromised the passphrase does not help much. That depends on your attacker, of course. You might still get some value out of your passphrase (and the way it's been mangled) against an attacker that is capable of getting hold of your data (and perform offline attacks) but not fully compromising your box. Cheers, Tobi From look at my.amazin.horse Thu Jun 21 02:01:23 2018 From: look at my.amazin.horse (Vincent Breitmoser) Date: Thu, 21 Jun 2018 02:01:23 +0200 Subject: any way to use gpg(openpgp) with Argon2 In-Reply-To: <87o9g5cqxo.fsf@wheatstone.g10code.de> References: <1a43612adb99968d1d6742647abde646f4afb53a.camel@scientia.net> <87o9g5cqxo.fsf@wheatstone.g10code.de> Message-ID: <20180621000123.45itfqgwnsgctn4q@calamity> > I doubt that it will make it into rfc4880bis. I also see no reason for > it. Passphrases must die. > > I fact OpenPGP is mostly about public key encryption and thus we don't > use passphrases for its main tasks. Passphrases can be used to protect > a private key but that is questionable because if you box is already > compromised the passphrase does not help much. YES. Thank you! I'm so glad to hear that. Myself and others have been evangelizing this position for a while, and my experience has been that when I ask people about their stance on passphrases, the kneejerk virtue signalling answer is "why of *course* I only use super strong passphrases! they are the weakest part of the system, after all". This is so ingrained that people actually feel bad about even the thought of a weak passphrase, let alone none at all. And it's not surprising, given that this advice is virtually ubiquitous in the numerous blog posts on how to set up gpg. The gpg man page also does its part, right at the top: "Use a *good* password for your user account and a *good* passphrase to protect your secret key. This passphrase is the weakest part of the whole system." I would very very much appreciate a blog post from you on this matter. It's a nuanced matter, but just giving a general impulse here would help a lot. - V From wk at gnupg.org Thu Jun 21 09:39:34 2018 From: wk at gnupg.org (Werner Koch) Date: Thu, 21 Jun 2018 09:39:34 +0200 Subject: WKD: User ID filtering In-Reply-To: <3fdb9a40-7c72-59ed-2130-9b622158b709@metacode.biz> (Wiktor Kwapisiewicz via Gnupg-devel's message of "Wed, 20 Jun 2018 22:06:42 +0200") References: <3fdb9a40-7c72-59ed-2130-9b622158b709@metacode.biz> Message-ID: <87r2l0si4p.fsf@wheatstone.g10code.de> On Wed, 20 Jun 2018 22:06, gnupg-devel at gnupg.org said: > Is this by design? Yes, this by design of the protocol. The protocol asserts via TLS that a user id is managed by a certain domain (i.e. mail provider). client connects to the domain of a user id and looks up the key. That key is then stored in the local public keyring along with a flag that the user id has been retrieved via WKD. > Should this behavior be documented/recommended in the I-D? I though this was obvious. I will add this to the security considerations: | The mail provider MUST make sure to filter a key in a way that only | the User ID belonging to that user is returned and that confirmation | requests are only send for such User IDs. It is further recommended | that a client filters the key for a publication requests so that only | a key with the specific User ID of the provider is send. Shalom-Salam, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Thu Jun 21 09:52:50 2018 From: wk at gnupg.org (Werner Koch) Date: Thu, 21 Jun 2018 09:52:50 +0200 Subject: any way to use gpg(openpgp) with Argon2 In-Reply-To: <1529530748.15089.79.camel@cryptobitch.de> (Tobias Mueller's message of "Wed, 20 Jun 2018 23:39:08 +0200") References: <1a43612adb99968d1d6742647abde646f4afb53a.camel@scientia.net> <87o9g5cqxo.fsf@wheatstone.g10code.de> <1529530748.15089.79.camel@cryptobitch.de> Message-ID: <87muvoshil.fsf@wheatstone.g10code.de> On Wed, 20 Jun 2018 23:39, muelli at cryptobitch.de said: > You might still get some value out of your passphrase (and the way it's > been mangled) against an attacker that is capable of getting hold of Assuming no sane person stores private keys on other people's machines, getting hold of the data means in most cases that a laptop was stolen or a disk was dumped without first destroying it. For a laptop security aware people use disk encryption which also protects the private key against the above cases. The majority of comprises are due to remote automated attacks and these are all involve the installation of malware. No passphrase for an on-disk key protects against this threat. > your data (and perform offline attacks) but not fully compromising your Ever played pinball? I never heard about a half-tilt; it is tilt and only tilt and you lost your ball or the game. Same thing for computers. Salam-Shalom, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wiktor at metacode.biz Thu Jun 21 10:16:56 2018 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Thu, 21 Jun 2018 10:16:56 +0200 Subject: WKD: User ID filtering In-Reply-To: <87r2l0si4p.fsf@wheatstone.g10code.de> References: <3fdb9a40-7c72-59ed-2130-9b622158b709@metacode.biz> <87r2l0si4p.fsf@wheatstone.g10code.de> Message-ID: <40a50982-44a8-05b6-0450-d14db6158c7e@metacode.biz> Hello, Yes, it's obvious in retrospect, but when implementing it from the spec it's far to easy to take the shortcut of "just fetch the binary key from that URL and import it to local keyring". I did it in my two implementations of WKD clients and as far as I've read the source code of EnigMail it does that too (imports the entire key without filtering). Your addition to security considerations will be greatly appreciated. I assume that if after filtering the key does not contain any UIDs the import is rejected. > That key is > then stored in the local public keyring along with a flag that the > user id has been retrieved via WKD. Is that flag used for anything or just informational? Because fetching via WKD at least "validates" the e-mail part and this information is useful. Thank you for your time! Kind regards, Wiktor W dniu 21.06.2018 o?09:39, Werner Koch pisze: > On Wed, 20 Jun 2018 22:06, gnupg-devel at gnupg.org said: > >> Is this by design? > > Yes, this by design of the protocol. The protocol asserts via TLS that > a user id is managed by a certain domain (i.e. mail provider). client > connects to the domain of a user id and looks up the key. That key is > then stored in the local public keyring along with a flag that the user > id has been retrieved via WKD. > >> Should this behavior be documented/recommended in the I-D? > > I though this was obvious. I will add this to the security > considerations: > > | The mail provider MUST make sure to filter a key in a way that only > | the User ID belonging to that user is returned and that confirmation > | requests are only send for such User IDs. It is further recommended > | that a client filters the key for a publication requests so that only > | a key with the specific User ID of the provider is send. > > > Shalom-Salam, > > Werner > -- */metacode/* -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From muelli at cryptobitch.de Thu Jun 21 10:18:41 2018 From: muelli at cryptobitch.de (Tobias Mueller) Date: Thu, 21 Jun 2018 10:18:41 +0200 Subject: any way to use gpg(openpgp) with Argon2 In-Reply-To: <87muvoshil.fsf@wheatstone.g10code.de> References: <1a43612adb99968d1d6742647abde646f4afb53a.camel@scientia.net> <87o9g5cqxo.fsf@wheatstone.g10code.de> <1529530748.15089.79.camel@cryptobitch.de> <87muvoshil.fsf@wheatstone.g10code.de> Message-ID: <1529569121.26453.5.camel@cryptobitch.de> Hi, On Thu, 2018-06-21 at 09:52 +0200, Werner Koch wrote: > getting hold of the data means in most cases that a laptop was stolen > or a disk was dumped without first destroying it. I claim that there is a way in between these either black or white paths. These days apps are isolated against each other, potentially running as different user, etc. Your malware may very well be able to exfiltrate files not belonging to the app itself (e.g. "allow access to SD-card") but not have many other capabilities. Cheers, Tobi From wk at gnupg.org Thu Jun 21 10:21:21 2018 From: wk at gnupg.org (Werner Koch) Date: Thu, 21 Jun 2018 10:21:21 +0200 Subject: WKD: User ID filtering In-Reply-To: <40a50982-44a8-05b6-0450-d14db6158c7e@metacode.biz> (Wiktor Kwapisiewicz via Gnupg-devel's message of "Thu, 21 Jun 2018 10:16:56 +0200") References: <3fdb9a40-7c72-59ed-2130-9b622158b709@metacode.biz> <87r2l0si4p.fsf@wheatstone.g10code.de> <40a50982-44a8-05b6-0450-d14db6158c7e@metacode.biz> Message-ID: <878t78sg72.fsf@wheatstone.g10code.de> On Thu, 21 Jun 2018 10:16, gnupg-devel at gnupg.org said: > I assume that if after filtering the key does not contain any UIDs the > import is rejected. Right. There is also the little twist that if a mail provider announces mailbox-only and the user id also has a real-name gpg-wks-client creates a new user-id with just the mailbox. > Is that flag used for anything or just informational? It can be read out and will eventually be used for key validation heuristics. Option --with-key-origin and in the --with-colons output fields 19 and 20 of uid and pub records. > Because fetching via WKD at least "validates" the e-mail part and this > information is useful. Right. Shalom-Salam, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Thu Jun 21 10:25:29 2018 From: wk at gnupg.org (Werner Koch) Date: Thu, 21 Jun 2018 10:25:29 +0200 Subject: any way to use gpg(openpgp) with Argon2 In-Reply-To: <20180621000123.45itfqgwnsgctn4q@calamity> (Vincent Breitmoser's message of "Thu, 21 Jun 2018 02:01:23 +0200") References: <1a43612adb99968d1d6742647abde646f4afb53a.camel@scientia.net> <87o9g5cqxo.fsf@wheatstone.g10code.de> <20180621000123.45itfqgwnsgctn4q@calamity> Message-ID: <874lhwsg06.fsf@wheatstone.g10code.de> On Thu, 21 Jun 2018 02:01, look at my.amazin.horse said: > I would very very much appreciate a blog post from you on this matter. It's > a nuanced matter, but just giving a general impulse here would help a lot. It even seems that people don't grasp the public key concept and think that the passphrase is there to protect the communication. Even admins of large companies who are responsible for securing data protection sometimes don't get it. A real simple and fast to read intro would be good. Salam-Shalom, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From aheinecke at intevation.de Thu Jun 21 10:49:48 2018 From: aheinecke at intevation.de (Andre Heinecke) Date: Thu, 21 Jun 2018 10:49:48 +0200 Subject: WKD: User ID filtering In-Reply-To: <878t78sg72.fsf@wheatstone.g10code.de> References: <3fdb9a40-7c72-59ed-2130-9b622158b709@metacode.biz> <40a50982-44a8-05b6-0450-d14db6158c7e@metacode.biz> <878t78sg72.fsf@wheatstone.g10code.de> Message-ID: <4319783.sgv91OkD0O@esus> Hi, On Thursday, June 21, 2018 10:21:21 AM CEST Werner Koch wrote: > On Thu, 21 Jun 2018 10:16, gnupg-devel at gnupg.org said: > > Is that flag used for anything or just informational? > > It can be read out and will eventually be used for key validation > heuristics. Option --with-key-origin and in the --with-colons output > fields 19 and 20 of uid and pub records. In gpgme it is also available since 1.10.0 ;-) > > Because fetching via WKD at least "validates" the e-mail part and this > > information is useful. As an example, I'm using that flag for "Automatic Encryption" in GpgOL. It will see a userid as acceptable for automatic encryption if it has either marginal validity (when TOFU is not used) or if it came from WKD. Best Regards, Andre -- Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: From wiktor at metacode.biz Thu Jun 21 11:02:28 2018 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Thu, 21 Jun 2018 11:02:28 +0200 Subject: WKD: User ID filtering In-Reply-To: <4319783.sgv91OkD0O@esus> References: <3fdb9a40-7c72-59ed-2130-9b622158b709@metacode.biz> <40a50982-44a8-05b6-0450-d14db6158c7e@metacode.biz> <878t78sg72.fsf@wheatstone.g10code.de> <4319783.sgv91OkD0O@esus> Message-ID: <85653439-6896-1123-8713-6661e0dea7bf@metacode.biz> Hello, >> It can be read out and will eventually be used for key validation >> heuristics. Option --with-key-origin and in the --with-colons output >> fields 19 and 20 of uid and pub records. > > In gpgme it is also available since 1.10.0 ;-) I will check this out, thanks for the info! :) >>> Because fetching via WKD at least "validates" the e-mail part and this >>> information is useful. > > As an example, I'm using that flag for "Automatic Encryption" in GpgOL. It will > see a userid as acceptable for automatic encryption if it has either marginal > validity (when TOFU is not used) or if it came from WKD. Yes! That's a very good idea! Actually I was thinking about the same but for EnigMail. WKD provides a good basis for initial contact encryption. Have you thought about extending it even further? For example if someone types an unknown e-mail, presses Enter, the GpgOL could see if there is a key available via WKD and if so, fetch it and enable encryption entirely automatically! Kind regards, Wiktor -- */metacode/* -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From aheinecke at intevation.de Thu Jun 21 12:35:46 2018 From: aheinecke at intevation.de (Andre Heinecke) Date: Thu, 21 Jun 2018 12:35:46 +0200 Subject: WKD: User ID filtering In-Reply-To: <85653439-6896-1123-8713-6661e0dea7bf@metacode.biz> References: <3fdb9a40-7c72-59ed-2130-9b622158b709@metacode.biz> <4319783.sgv91OkD0O@esus> <85653439-6896-1123-8713-6661e0dea7bf@metacode.biz> Message-ID: <101995059.p5jZPprFHI@esus> Hi, On Thursday, June 21, 2018 11:02:28 AM CEST Wiktor Kwapisiewicz wrote: > Yes! That's a very good idea! Actually I was thinking about the same but > for EnigMail. WKD provides a good basis for initial contact encryption. > > Have you thought about extending it even further? For example if someone > types an unknown e-mail, presses Enter, the GpgOL could see if there is > a key available via WKD and if so, fetch it and enable encryption > entirely automatically! Exactly. That is actually what I am currently working on for the next version. I can probably show a demo video next week about how it looks in GpgOL. Btw. Last year Neal, Bernhard and me worked on a concept how we would like to utilize WKD and the TOFU trust model for automated encryption. It can be found under: https://wiki.gnupg.org/AutomatedEncryption Maybe you find it interesting, I would be interested in your opinion. It's my current focus for new feature work on Gpg4win. Best Regards, Andre -- Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: From wiktor at metacode.biz Thu Jun 21 13:01:49 2018 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Thu, 21 Jun 2018 13:01:49 +0200 Subject: WKD: User ID filtering In-Reply-To: <101995059.p5jZPprFHI@esus> References: <3fdb9a40-7c72-59ed-2130-9b622158b709@metacode.biz> <4319783.sgv91OkD0O@esus> <85653439-6896-1123-8713-6661e0dea7bf@metacode.biz> <101995059.p5jZPprFHI@esus> Message-ID: Hello, > Btw. Last year Neal, Bernhard and me worked on a concept how we would like to > utilize WKD and the TOFU trust model for automated encryption. It can be found > under: > https://wiki.gnupg.org/AutomatedEncryption > > Maybe you find it interesting, I would be interested in your opinion. That definitely is most interesting! I've been pondering setting up encryption for less technical people for some time and the current approach requires a lot of hops to do that (basically me setting up their MUA). Automated encryption with WKD+TOFU seems like a good approach. I am looking forward to your demo video! Kind regards, Wiktor -- */metacode/* -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Thu Jun 21 15:28:38 2018 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 21 Jun 2018 09:28:38 -0400 Subject: any way to use gpg(openpgp) with Argon2 In-Reply-To: <874lhwsg06.fsf@wheatstone.g10code.de> References: <1a43612adb99968d1d6742647abde646f4afb53a.camel@scientia.net> <87o9g5cqxo.fsf@wheatstone.g10code.de> <20180621000123.45itfqgwnsgctn4q@calamity> <874lhwsg06.fsf@wheatstone.g10code.de> Message-ID: <8f563c3b-95c2-18a9-64d2-79314733e600@sixdemonbag.org> > It even seems that people don't grasp the public key concept and think > that the passphrase is there to protect the communication. Even admins > of large companies who are responsible for securing data protection > sometimes don't get it. A real simple and fast to read intro would be > good. Given we're tiptoeing close to FAQ territory -- how do you want it? Where would it be hosted? I'm happy to write it, but I need to know what I'm writing. From wk at gnupg.org Fri Jun 22 12:26:59 2018 From: wk at gnupg.org (Werner Koch) Date: Fri, 22 Jun 2018 12:26:59 +0200 Subject: any way to use gpg(openpgp) with Argon2 In-Reply-To: <8f563c3b-95c2-18a9-64d2-79314733e600@sixdemonbag.org> (Robert J. Hansen's message of "Thu, 21 Jun 2018 09:28:38 -0400") References: <1a43612adb99968d1d6742647abde646f4afb53a.camel@scientia.net> <87o9g5cqxo.fsf@wheatstone.g10code.de> <20180621000123.45itfqgwnsgctn4q@calamity> <874lhwsg06.fsf@wheatstone.g10code.de> <8f563c3b-95c2-18a9-64d2-79314733e600@sixdemonbag.org> Message-ID: <87o9g3p158.fsf@wheatstone.g10code.de> On Thu, 21 Jun 2018 15:28, rjh at sixdemonbag.org said: > Given we're tiptoeing close to FAQ territory -- how do you want it? > Where would it be hosted? I was thinking of a single page https://gnupg.org/faq/pubkey-primer.html or so which could even be given in error messages of gpg. There are a few pages in that diretcory, like why-not-idea.html. > I'm happy to write it, but I need to know what I'm writing. That would be nice. Salam-Shalom, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From calestyo at scientia.net Sun Jun 24 14:35:16 2018 From: calestyo at scientia.net (Christoph Anton Mitterer) Date: Sun, 24 Jun 2018 14:35:16 +0200 Subject: any way to use gpg(openpgp) with Argon2 In-Reply-To: <1a43612adb99968d1d6742647abde646f4afb53a.camel@scientia.net> References: <1a43612adb99968d1d6742647abde646f4afb53a.camel@scientia.net> Message-ID: Hey. >I doubt that it will make it into rfc4880bis. I also see no >reason for it. Well, to replace the worse algos in place? >Passphrases must die. I don't see any reason for that, or better said... no better replacement. Apart from that, they simply won't go away anytime soon in reality, so this is probably no good reason not to improve the RFC, especially when the older hashing algorithms are left in place in the standard. >I fact OpenPGP is mostly about public key encryption and thus we >don't use passphrases for its main tasks. Passphrases can be used >to protect a private key but that is questionable because if you >box is already compromised the passphrase does not help much. Truly, if the box is fully compromised an attacker may be able to eventually also get access to a well-protected private key. But there you ignore so many scenarios in which the encryption of it actually does provide a pretty solid layer, like: - Any scenario in which an attacker gets only a one time snapshot of the data of the box (theft, or e.g. getting access to backups of it, which are in so many places made automatically e.g. on universities to tape and so on). Sure you can always argue, that then other measures would have needed to be taken (encryption of the box, the backups, etc.) but often they simply are not. - Any scenario, where the private key is (encrypted) in place, but the user doesn't really unlock it on the compromised box. - Any scenario where a plain text key on a otherwise secure and not compromised system may be gotten hold on by others (e.g. some governmental organisation simply getting in your rooms and taking it). It's kinda strange to read on a place like this that password protection of they keys wouldn't be necessary and that this should be solved somehow else. Any biometric protection is quite obviously completely rubbish, as it can be quite easily "stolen" from the owner, most of the time even without his knowledge. For a passphrase, one would at least need to impose some force on the owner (which is often illegal), and at least, he would then know that his stuff is compromised. And the token's you mention... just another black box by some manufacturer that one needs to blindly trust, where one doesn't know whether it has backdoors or not... and how many cases have we already seen of just that (or of stupid design). Every token is either then again secured by some passphrase or PIN, or it's whole security is simply based on possession - which is pretty pretty weak. Sure, passphrases have their disadvantages... but when used correctly, there is no real better alternative to them. >The other use of passphrases is symmetric-only encryption (command -c) That would be basically my case... >In this case I consider it better to use --s2k-mode=0 along with a >full entropy passphrase instead of relying on passphrase mangling >algorithms - they are designed for manual interaction and not >for large scale use with thousands of messages. But that still doesn't take the provided "passphrase" directly as a key, right? It still hashes it, just without any salt and iterations. So even if I'd use e.g. some standalone argon2 binary on my passphrase and use the strongly hashed output of this with Simple S2K (mode 0) I wouldn't gain any security as the weakest link would be still the passphrase hashing in OpenPGP (now even simpler, as it has no salt or any iteration). Or do I get anything wrong here? Thanks, Chris. From wiktor at metacode.biz Mon Jun 25 13:03:45 2018 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Mon, 25 Jun 2018 13:03:45 +0200 Subject: Web Key Directory: refreshing keys Message-ID: Hello, I would like to ask about the potential ability to refresh keys using Web Key Directory protocol. As far as I know WKD can be used to locate keys (via --locate-key et al. and when verifying signatures with signer's UID embedded) but the keys retrieved via WKD are refreshed using keyservers only, never their original location. Technically that would be possible (as the key origin is preserved). The disadvantage would be that WKD server operator would see when people refresh keys within their domain. I see also some advantages: there are less bytes to download (because binary, and because keyservers allow anyone to bloat the keys [0] [1]) and that it could allow managing keys without keyservers at all [2] (for example in case of a hypothetical GDPR-apocalypse). Would refresh via WKD be a good idea? Thanks for your input! Kind regards, Wiktor [0]: https://bitbucket.org/skskeyserver/sks-keyserver/issues/57 [1]: https://bitbucket.org/skskeyserver/sks-keyserver/issues/60 [2]: Of course someone else can put the keys in keyservers anyway but I mean providing authoritative key updates on WKD host. -- */metacode/* -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From andrewg at andrewg.com Mon Jun 25 14:15:17 2018 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 25 Jun 2018 13:15:17 +0100 Subject: Web Key Directory: refreshing keys In-Reply-To: References: Message-ID: On 25/06/18 12:03, Wiktor Kwapisiewicz via Gnupg-devel wrote: > Would refresh via WKD be a good idea? It might be a good idea if used in addition to keyserver refresh. I would be worried that relying on WKD alone would prevent the propagation of revocations. At the moment, if you want to block revocation distribution you have to take down the entire keyserver network (although that's looking more plausible these days!). With WKD you only have to block or fake one DNS server. The WKD server operator would typically be the same person/organisation as the email server operator - so leaking relationship data may not necessarily lead to them learning anything more than they already can. -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 862 bytes Desc: OpenPGP digital signature URL: From aheinecke at intevation.de Mon Jun 25 16:41:39 2018 From: aheinecke at intevation.de (Andre Heinecke) Date: Mon, 25 Jun 2018 16:41:39 +0200 Subject: Web Key Directory: refreshing keys In-Reply-To: References: Message-ID: <6965529.St8GluLQHk@esus> Hi, On Monday, June 25, 2018 1:15:17 PM CEST Andrew Gallagher wrote: > On 25/06/18 12:03, Wiktor Kwapisiewicz via Gnupg-devel wrote: > > Would refresh via WKD be a good idea? Yes. Especially regarding expiry this is neccessary. We have a default expiry nowadays and that needs to be extended automatically through WKD. There is a task for that: https://dev.gnupg.org/T2917 You can "force" a WKD update through: gpg --auto-key-locate clear,nodefault,wkd --locate-key aheinecke at intevation.de > It might be a good idea if used in addition to keyserver refresh. I > would be worried that relying on WKD alone would prevent the propagation > of revocations. At the moment, if you want to block revocation > distribution you have to take down the entire keyserver network > (although that's looking more plausible these days!). With WKD you only > have to block or fake one DNS server. > > The WKD server operator would typically be the same person/organisation > as the email server operator - so leaking relationship data may not > necessarily lead to them learning anything more than they already can. Yes ideally both should be combined. I'm still in favor of having dirmngr handle refresh through WKD or Keyservers randomly in the background. But we probably need the planned keyring controller process to control that. Currently I guess it's the response of the client (MUA) to trigger refreshs. Best Regards, Andre -- Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: From ben at adversary.org Fri Jun 29 08:54:44 2018 From: ben at adversary.org (Ben McGinnes) Date: Fri, 29 Jun 2018 16:54:44 +1000 Subject: Query regarding GPGME python Bindings In-Reply-To: References: <20180608150236.x2ubagwbjziaab3n@adversary.org> <38cd3dc6-850f-1153-7423-c797a5d7948b@selfnet.de> <20180617133101.dyfd44unoi2lpxmr@adversary.org> Message-ID: <20180629065444.dc4ytkfzst2fxhru@adversary.org> On Sun, Jun 17, 2018 at 04:21:14PM +0200, Marcel Fest wrote: > Thanks, so i can fully migrate to gpgme Python bindings. Awesome. Let me know if you encounter any weirdness along the way. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From ben at gnupg.org Fri Jun 29 09:00:33 2018 From: ben at gnupg.org (Ben McGinnes) Date: Fri, 29 Jun 2018 17:00:33 +1000 Subject: GPGME Python bindings with Python 3.7.0 Message-ID: <20180629070033.7zuwqg6leyao5bla@adversary.org> Hello, As some of you may have already noticed, Python 3.7.0 has been released in the last day or so. I can now confirm that it does indeed work with the Python bindings for GPGME. For the moment the explicit configuration for 3.7 comes after 3.4, but only until 3.7.1 or 3.7.2 if there are significant problems discovered in either 3.7.0 or 3.7.2. Regards, Ben -- | Ben McGinnes | GNU Privacy Guard | ben at gnupg.org | | ---------------------------------------------------------------- | | GNU Privacy Guard Made Easy (GPGME) Python 3 API Maintainer | | GPG key: 0x321E4E2373590E5D http://www.adversary.org/ben-key.asc | | GPG key fpr: DB47 24E6 FA42 86C9 2B4E 55C4 321E 4E23 7359 0E5D | | Web: https://www.gnupg.org/ Tor: http://ic6au7wa3f6naxjq.onion/ | | ---------------------------------------------------------------- | -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From trevor at yubico.com Fri Jun 29 13:33:01 2018 From: trevor at yubico.com (Trevor Bentley) Date: Fri, 29 Jun 2018 13:33:01 +0200 Subject: scd bug: specifying 'e length' for RSA key-attr unsupported Message-ID: <1be69e47-7571-f66e-e972-743734a264dc@yubico.com> Hi everyone, I'm trying to use GPG with smartcards, and ran across what appears to be a bug in scdaemon when using both RSA and ECC keys. Specifically, the KEY-ATTR command does not accept 'e bit length' as an argument. scdaemon simply re-uses whichever value the card defaults to if you change the RSA key length... but the real bug here is that when switching back to RSA from an EC algorithm, scdaemon hardcodes the 'e bit length' to 32. This is in scd/app-openpgp.c:change_rsa_keyattr(), line 3254 (GnuPG 2.2.8). This is problematic for smartcards that don't support an 'e length' of 32. The attribute change is rejected because of the unsupported value, and the card is effectively stuck with an EC curve unless completely reset. Example output of this failing is in the snippet below my signature. Note that this is a likely case: the OpenPGP on Smart Card spec (v3.3.1) specifies 65537 (bit length 17) as the only value required to be supported, and as the default to use if none is specified. The protocol does not support specifying 'none', so GPG does have to specify something when changing the algorithm. It is also a limitation for cards that support multiple 'e' lengths, in that there is no way to change it from the default. That is more of a missing feature than a bug. There is a strange edge case of smartcards that support both lengths of 17 and 32 bits: you can change from 17 to 32 by changing the algo from RSA -> ECC -> RSA, and then you are permanently switched to a 32-bit e length. I believe this needs to be fixed in one of two ways: 1) add an 'e length' argument to KEY-ATTR (and possibly a matching UI) 2) use '17' instead of '32' as the hard-coded length, since all cards are required to support it Please let me know if this makes sense, or if I'm mistaken about something. Thanks, Trevor -- $ gpg-connect-agent "SCD SETATTR KEY-ATTR --force 1 1 rsa2048" /bye OK $ gpg-connect-agent "SCD SETATTR KEY-ATTR --force 1 19 nistp256" /bye OK $ gpg-connect-agent "SCD SETATTR KEY-ATTR --force 1 1 rsa2048" /bye ERR 100663351 Invalid value -- -- scdaemon[56643] DBG: send apdu: c=00 i=DA p1=00 p2=C1 lc=6 le=-1 em=0 scdaemon[56643] DBG: PCSC_data: 00 DA 00 C1 06 01 08 00 00 11 00 scdaemon[56643] DBG: response: sw=9000 datalen=0 scdaemon[56643] DBG: dump: scdaemon[56643] key attribute changed (key=1) ... scdaemon[56643] DBG: send apdu: c=00 i=DA p1=00 p2=C1 lc=10 le=-1 em=0 scdaemon[56643] DBG: PCSC_data: 00 DA 00 C1 0A 13 2B 24 03 03 02 08 01 01 07 scdaemon[56643] DBG: response: sw=9000 datalen=0 scdaemon[56643] DBG: dump: scdaemon[56643] key attribute changed (key=1) ... scdaemon[56643] DBG: send apdu: c=00 i=DA p1=00 p2=C1 lc=6 le=-1 em=0 scdaemon[56643] DBG: PCSC_data: 00 DA 00 C1 06 01 08 00 00 20 00 scdaemon[56643] DBG: response: sw=6A80 datalen=0 scdaemon[56643] error changing key attribute (key=1) --