From bts at square-r00t.net Mon Nov 5 06:20:55 2018 From: bts at square-r00t.net (brent s.) Date: Mon, 5 Nov 2018 00:20:55 -0500 Subject: python GPGME bindings and key signatures Message-ID: i frequently do work with the GPGME bindings for python (is this still referred to as "pyME" after the merge into mainline?), and i really must start by saying thank you to whomever maintains it! i do have a quick question as i'm not sure it's something expected or not. it seems the signatures interface is obsolete[0]. it seems that the non-obsolete way of accessing this is in gpgme_user_id_t's `signatures` member[1] (or .uids[].signatures per the bindings). however, this is empty in python's bindings: _________________________________________________________________ >>> import os >>> os.environ['GNUPGHOME'] '/var/tmp/python_testing/gpg/homedir' >>> import gpg >>> ctx = gpg.Context() >>> k = ctx.get_key('C548200C7F6AA9541F6EDFF65A6D013706B6BE26') >>> k.uids[0].signatures [] >>> _________________________________________________________________ whereas signatures most definitely do exist: _________________________________________________________________ [bts at cylon gpg]$ echo $GNUPGHOME /var/tmp/python_testing/gpg/homedir [bts at cylon gpg]$ gpg --list-keys --with-sig-check C548200C7F6AA9541F6EDFF65A6D013706B6BE26 pub rsa4096 2012-10-30 [SC] C548200C7F6AA9541F6EDFF65A6D013706B6BE26 uid [ full ] A Test Key for Expiring, delete when done (1351649839.474725) sig!3 5A6D013706B6BE26 2012-10-30 A Test Key for Expiring, delete when done (1351649839.474725) sig! 33F7494F9AF6E3D1 2018-11-04 A Test Key (a comment) sig! 2 33F7494F9AF6E3D1 2018-11-05 A Test Key (a comment) sub rsa4096 2012-10-30 [S] sig! 5A6D013706B6BE26 2012-10-30 A Test Key for Expiring, delete when done (1351649839.474725) gpg: 4 good signatures _________________________________________________________________ is this intentional/known behaviour? did i do a goof? if the former, is there an expected ETA on support for this? if the latter, is there a certain constant that needs to be set for the context first or something; how can i implement key signature listing? thanks! [0] https://gnupg.org/documentation/manuals/gpgme/Key-Signatures.html [1] https://www.gnupg.org/documentation/manuals/gpgme/Key-objects.html#index-gpgme_005fuser_005fid_005ft -- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 899 bytes Desc: OpenPGP digital signature URL: From muelli at cryptobitch.de Mon Nov 5 12:14:45 2018 From: muelli at cryptobitch.de (Tobias Mueller) Date: Mon, 05 Nov 2018 12:14:45 +0100 Subject: python GPGME bindings and key signatures In-Reply-To: References: Message-ID: Hi, On Mon, 2018-11-05 at 00:20 -0500, brent s. wrote: > > however, this is empty in python's bindings: > > _________________________________________________________________ > > > > import os > > > > os.environ['GNUPGHOME'] > > '/var/tmp/python_testing/gpg/homedir' > > > > import gpg > > > > ctx = gpg.Context() > > > > k = ctx.get_key('C548200C7F6AA9541F6EDFF65A6D013706B6BE26') > > > > k.uids[0].signatures > > [] > > > > > > _________________________________________________________________ > > yeah, this is one of the peculiarities of the gpgme interface. You have to request the key list with signatures. I'd link to the documentation, but as there is still no full HTML version I cannot easily press Ctrl+F and search. I have the following in my code: # *sigh* gpgme is killing me. With gpgme 1.8 we have to # set_keylist_mode before we can call keylist. With gpgme 1.9 # keylist takes a mode argument and overrides whatever has been # set before. In order to come with something compatible with both # 1.8 and 1.9 we have to set_keylist_mode and NOT call ctx.keylist # but rather the bare op_keylist_all. In 1.8 that requires two # arguments. mode = gpg.constants.keylist.mode.LOCAL | gpg.constants.keylist.mode.SIGS secret = False ctx.set_keylist_mode(mode) keys = list(ctx.op_keylist_all(key.fpr, secret)) # With gpgme 1.9 we can simply do: # keys = list(ctx.keylist(key.fpr), mode=mode) HTH, Tobi From bts at square-r00t.net Mon Nov 5 19:08:34 2018 From: bts at square-r00t.net (brent s.) Date: Mon, 5 Nov 2018 13:08:34 -0500 Subject: python GPGME bindings and key signatures In-Reply-To: References: Message-ID: <1230b4eb-2ab2-9e7e-458e-81f2083b8421@square-r00t.net> On 11/5/18 6:14 AM, Tobias Mueller wrote: > yeah, this is one of the peculiarities of the gpgme interface. > You have to request the key list with signatures. > I'd link to the documentation, but as there is still no full HTML > version I cannot easily press Ctrl+F and search. > > I have the following in my code: > > # *sigh* gpgme is killing me. With gpgme 1.8 we have to > # set_keylist_mode before we can call keylist. With gpgme 1.9 > # keylist takes a mode argument and overrides whatever has been > # set before. In order to come with something compatible with both > # 1.8 and 1.9 we have to set_keylist_mode and NOT call ctx.keylist > # but rather the bare op_keylist_all. In 1.8 that requires two > # arguments. > mode = gpg.constants.keylist.mode.LOCAL | gpg.constants.keylist.mode.SIGS > secret = False > ctx.set_keylist_mode(mode) > keys = list(ctx.op_keylist_all(key.fpr, secret)) > # With gpgme 1.9 we can simply do: > # keys = list(ctx.keylist(key.fpr), mode=mode) > > > HTH, > Tobi > Tobi - This helps a TON. Thank you so much! Something else I just ran into last night is it seems gpg.constants.import is unusable due to the : >>> import gpg >>> gpg.constants.import.NEW File "", line 1 gpg.constants.import.NEW ^ SyntaxError: invalid syntax >>> sys.version '3.7.1 (default, Oct 22 2018, 10:41:28) \n[GCC 8.2.1 20180831]' I presume that's something I'll need a bug report for. Thanks again, Tobi! -- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 899 bytes Desc: OpenPGP digital signature URL: From joeypabalinas at gmail.com Tue Nov 6 04:11:49 2018 From: joeypabalinas at gmail.com (Joey Pabalinas) Date: Mon, 5 Nov 2018 17:11:49 -1000 Subject: [PATCH] g10: fix segfault when using both --card-edit and --with-keygrip flags Message-ID: <7bd077a0052b13d013ce388a9e86f9704e5c7d17.1541473387.git.joeypabalinas@gmail.com> * g10/card-util.c (print_keygrip): Add NULL check. Signed-off-by: Joey Pabalinas --- g10/card-util.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/g10/card-util.c b/g10/card-util.c index 5205798b6a9ac486ff..1f2919fc2bb0091549 100644 --- a/g10/card-util.c +++ b/g10/card-util.c @@ -270,10 +270,12 @@ print_shax_fpr_colon (estream_t fp, static void print_keygrip (estream_t fp, const unsigned char *grp) { int i; + if (!fp) + return; if (opt.with_keygrip) { tty_fprintf (fp, " keygrip ....: "); for (i=0; i < 20 ; i++, grp++) es_fprintf (fp, "%02X", *grp); -- Cheers, Joey Pabalinas From gniibe at fsij.org Tue Nov 6 07:39:10 2018 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 06 Nov 2018 15:39:10 +0900 Subject: [PATCH] g10: fix segfault when using both --card-edit and --with-keygrip flags In-Reply-To: <7bd077a0052b13d013ce388a9e86f9704e5c7d17.1541473387.git.joeypabalinas@gmail.com> References: <7bd077a0052b13d013ce388a9e86f9704e5c7d17.1541473387.git.joeypabalinas@gmail.com> Message-ID: <87ftwe1zht.fsf@fsij.org> Hello, Joey Pabalinas wrote: > * g10/card-util.c (print_keygrip): Add NULL check. Thanks for your report. Actually, we can print out the keygrip information by using tty_fprint. I pushed that change to both of master and 2.2 branch. -- From joeypabalinas at gmail.com Tue Nov 6 07:48:34 2018 From: joeypabalinas at gmail.com (Joey Pabalinas) Date: Mon, 5 Nov 2018 20:48:34 -1000 Subject: [PATCH] g10: fix segfault when using both --card-edit and --with-keygrip flags In-Reply-To: <87ftwe1zht.fsf@fsij.org> References: <7bd077a0052b13d013ce388a9e86f9704e5c7d17.1541473387.git.joeypabalinas@gmail.com> <87ftwe1zht.fsf@fsij.org> Message-ID: <20181106064834.cznzeh3ixmvyaabg@gmail.com> On Tue, Nov 06, 2018 at 03:39:10PM +0900, NIIBE Yutaka wrote: > Thanks for your report. Actually, we can print out the keygrip > information by using tty_fprint. > > I pushed that change to both of master and 2.2 branch. Yes, this fixes it on my end as well, thanks. -- Cheers, Joey Pabalinas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From wk at gnupg.org Tue Nov 6 12:34:40 2018 From: wk at gnupg.org (Werner Koch) Date: Tue, 06 Nov 2018 12:34:40 +0100 Subject: [Announce] GnuPG 2.2.11 released Message-ID: <87va5a5tin.fsf@wheatstone.g10code.de> Hello! We are pleased to announce the availability of a new GnuPG release: version 2.2.11. This is a maintenance release; see below for a list of fixed bugs. 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.11 ==================================== * gpgsm: Fix CRL loading when intermediate certicates are not yet trusted. * gpgsm: Fix an error message about the digest algo. [#4219] * gpg: Fix a wrong warning due to new sign usage check introduced with 2.2.9. [#4014] * gpg: Print the "data source" even for an unsuccessful keyserver query. * gpg: Do not store the TOFU trust model in the trustdb. This allows to enable or disable a TOFO model without triggering a trustdb rebuild. [#4134] * scd: Fix cases of "Bad PIN" after using "forcesig". [#4177] * agent: Fix possible hang in the ssh handler. [#4221] * dirmngr: Tack the unmodified mail address to a WKD request. See commit a2bd4a64e5b057f291a60a9499f881dd47745e2f for details. * dirmngr: Tweak diagnostic about missing LDAP server file. * dirmngr: In verbose mode print the OCSP responder id. * dirmngr: Fix parsing of the LDAP port. [#4230] * wks: Add option --directory/-C to the server. Always build the server on Unix systems. * wks: Add option --with-colons to the client. Support sites which use the policy file instead of the submission-address file. * Fix EBADF when gpg et al. are called by broken CGI scripts. * Fix some minor memory leaks and bugs. Release-info: https://dev.gnupg.org/T4233 Getting the Software ==================== Please follow the instructions found at or read on: GnuPG 2.2.11 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.11.tar.bz2 (6496k) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.11.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.11_20181106.exe (3928k) https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.11_20181106.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.11.tar.bz2 you would use this command: gpg --verify gnupg-2.2.11.tar.bz2.sig gnupg-2.2.11.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.11.tar.bz2, you run the command like this: sha1sum gnupg-2.2.11.tar.bz2 and check that the output matches the next line: c762d300c6c5616c14abff1cfaa099baa5fcbd2c gnupg-2.2.11.tar.bz2 e6c64cae60ced795046fd381e39ed207e94b53d2 gnupg-w32-2.2.11_20181106.tar.xz d1b1ba1bcf433cd1accf22772600f8a5186e156c gnupg-w32-2.2.11_20181106.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. In case of build problems specific to this release please first check https://dev.gnupg.org/T4233 for updated information. Please consult the archive of the gnupg-users mailing list before reporting a bug: . We suggest to send bug reports for a new release to this list in favor of filing a bug at . If you need commercial support 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 two contractors. All work exclusively on GnuPG and closely related software like Libgcrypt and GPGME. 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: --8<---------------cut here---------------start------------->8--- 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. --8<---------------cut here---------------end--------------->8--- -- 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 andrewg at andrewg.com Tue Nov 6 19:34:49 2018 From: andrewg at andrewg.com (Andrew Gallagher) Date: Tue, 6 Nov 2018 18:34:49 +0000 Subject: [Sks-devel] [openpgp-email] Keyservers and GDPR In-Reply-To: <20181106165742.qul5hoxrr3fhm7ut@pep-project.org> References: <20180522194409.tmrteipcsoorisns@calamity> <8f9b3617-5e52-e880-8a62-c2a2bcede122@enigmail.net> <20181106165742.qul5hoxrr3fhm7ut@pep-project.org> Message-ID: > On 6 Nov 2018, at 16:57, Volker Birk wrote: > > I'm not of the opinion that key servers are a good idea at all. It's > a pity that people still follow this wrong idea. There are other methods for discovery that don?t suffer from the same weaknesses, but there is no equally resilient method of distributing revocations. A From nick.papadonis.ml at gmail.com Wed Nov 7 07:53:56 2018 From: nick.papadonis.ml at gmail.com (Nicholas Papadonis) Date: Wed, 7 Nov 2018 01:53:56 -0500 Subject: Support for RSA keys > 4096 bits In-Reply-To: References: Message-ID: For those interested, link to the NIST document: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf On Wed, Nov 7, 2018 at 1:50 AM Nicholas Papadonis < nick.papadonis.ml at gmail.com> wrote: > I read in NIST 800-57 Part 1 Rev. 4 pg 53 that RSA keys length of 15360 > bits is equivalent to a 256 bit AES symmetric key. I also read in other > documentation that NIST recommends such key lengths to protect data beyond > 2030. As email may be retained for many years it would seem appropriate to > secure such communications with a larger key. > > Does this data agree with security experts? Is there a reason why GnuPG > limits RSA key length to 4096 bits? > > Thank you, > Nicholas > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick.papadonis.ml at gmail.com Wed Nov 7 07:50:03 2018 From: nick.papadonis.ml at gmail.com (Nicholas Papadonis) Date: Wed, 7 Nov 2018 01:50:03 -0500 Subject: Support for RSA keys > 4096 bits Message-ID: I read in NIST 800-57 Part 1 Rev. 4 pg 53 that RSA keys length of 15360 bits is equivalent to a 256 bit AES symmetric key. I also read in other documentation that NIST recommends such key lengths to protect data beyond 2030. As email may be retained for many years it would seem appropriate to secure such communications with a larger key. Does this data agree with security experts? Is there a reason why GnuPG limits RSA key length to 4096 bits? Thank you, Nicholas -------------- next part -------------- An HTML attachment was scrubbed... URL: From wiktor at metacode.biz Wed Nov 7 08:14:14 2018 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Wed, 7 Nov 2018 08:14:14 +0100 Subject: Support for RSA keys > 4096 bits In-Reply-To: References: Message-ID: <83d2deb1-ac77-4ba9-6eae-bcdc974d18d2@metacode.biz> Hi Nicolas, There is also this site that may be of interest: https://www.keylength.com/ As for your question, actually that was answered in GnuPG FAQ: https://www.gnupg.org/faq/gnupg-faq.html#default_rsa2048 Kind regards, Wiktor On 07.11.2018 07:53, Nicholas Papadonis wrote: > For those interested, link to the NIST document: > > https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf > > On Wed, Nov 7, 2018 at 1:50 AM Nicholas Papadonis > > wrote: > > I read in NIST?800-57 Part 1 Rev. 4 pg 53 that RSA keys length of > 15360 bits is equivalent to a 256 bit AES symmetric key.? I also > read in other documentation that NIST recommends such key lengths to > protect data beyond 2030.? As email may be retained for many years > it would seem appropriate to secure such communications with a > larger key. > > Does this data agree with security experts?? Is there a reason why > GnuPG limits RSA key length to 4096 bits? > > Thank you, > Nicholas > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -- https://metacode.biz/@wiktor From wk at gnupg.org Wed Nov 7 10:08:19 2018 From: wk at gnupg.org (Werner Koch) Date: Wed, 07 Nov 2018 10:08:19 +0100 Subject: [openpgp-email] Keyservers and GDPR In-Reply-To: <20181106165742.qul5hoxrr3fhm7ut@pep-project.org> (Volker Birk's message of "Tue, 6 Nov 2018 17:57:42 +0100") References: <20180522194409.tmrteipcsoorisns@calamity> <8f9b3617-5e52-e880-8a62-c2a2bcede122@enigmail.net> <20181106165742.qul5hoxrr3fhm7ut@pep-project.org> Message-ID: <87in1945mk.fsf@wheatstone.g10code.de> On Tue, 6 Nov 2018 17:57, vb at pep-project.org said: > I'm not of the opinion that key servers are a good idea at all. It's > a pity that people still follow this wrong idea. Keyservers are used for several purposes: 1. Search for keys based on the fingerprint ("gpg --recv-key FPR") 2. Search for key recovations ("gpg --refresh-key") 3. Search for keys based on the user id. (e.g. "gpg --search-key") 4. As a distribution medium for key signatures. 5. As a distributed and searchable storage. The first two purposes are quite useful because they allow to verify signatures made by yet unknown keys. Retrieving the keys is no data privacy problem because by signing and sending a mail the sender has already provided all these information. There is nothing which can replace these purposes because a key does not necessary need to have a mail address and even if so, any mail address based lookup can fail after the mail address is not longer in use, the account has been disabled, etc. Fingerprints are are globally unique and need not be associated with a mail address. Purpose 3 is what we call key discovery and indeed keyservers are the wrong way to do this. In most cases we want to map a mail address to a key and have some kind of reliable mapping. Keyservers which are just a pile of keys don't allow for this. Back then when encryption was young and the internet was a friendly place search for keys worked in most cases. But the times have changed and the bona fide search is useless. Purpose 4, distribution of key signatures, worked as long as people didn't used the key listings of the server or tools for more or less funny messages. Uploading key signature should be possible only by the holder of the key. However, to enforce this the keyservers need to employ real crypto and won't be a lean service anymore. I think the distribution of keyservers, for those who still want to use the WoT, can be replaced by sending the signed keys only back to owner. In fact tools like caff suggest this use case. Purpose 5 is not relevant for OpenPGP key distribution and actually the reason why the keyserver network has more or less broken down. My suggestion is limit the keyservers to the purposes 1 and 2. This can in practice easily be done by removing the search by user-id interface form the keyservers and, on the client site, by discovering keys using other methods (e.g. Web Key Directory). Having no searchable interface to the keyservers make them less attractive for abuse (as in purpose 5) and avoid some privacy issues (white pages without user consent). It is likely that gpg will eventually change its --search-key command to do the equivalent of --locate-key but without checking the local keyring. Salam-Shalom, Werner -- 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 Wed Nov 7 10:13:06 2018 From: wk at gnupg.org (Werner Koch) Date: Wed, 07 Nov 2018 10:13:06 +0100 Subject: [openpgp-email] Keyservers and GDPR In-Reply-To: (Andy Mueller-Maguhn's message of "Tue, 6 Nov 2018 17:27:14 +0100") References: <20180522194409.tmrteipcsoorisns@calamity> <8f9b3617-5e52-e880-8a62-c2a2bcede122@enigmail.net> Message-ID: <87efbx45el.fsf@wheatstone.g10code.de> On Tue, 6 Nov 2018 17:27, amm at datenreisen.de said: > I do roughly recal that such a verification process has been discussed for > the SKS keyservers at one of the pgp-summit before, but i wonder what > happened to the idea. However, if it that is ?good enough? to be compliant This requires that there are no rogue keyservers in the network and that in turn means that they are under the control of a single entity. Or in short, let Google take care of it. Such verification will be a single point of failure and it would be trivial for governments or corporations to take down a key. Shalom-Salam, Werner -- 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 Wed Nov 7 11:50:07 2018 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 7 Nov 2018 10:50:07 +0000 Subject: [Sks-devel] [openpgp-email] Keyservers and GDPR In-Reply-To: References: <87in1945mk.fsf@wheatstone.g10code.de> Message-ID: > On 7 Nov 2018, at 10:16, Yegor Timoshenko wrote: > > World-writable storage is problematic even if there is no search. > Proof of work and some operator-controllable data removal > mechanism (like opt-in key blacklists) can help limit this attack > vector. > > Storing immutable data, distributed recon, proof of work, that > sounds like something a blockchain should do to me. More evidence that blockchain is a solution in search of a problem! :-) Proof of work verification provides little benefit over cryptographic verification. If you have already generated a valid signature, that is in itself a proof of work. The only reason you would also use hashcash is if you wanted to increase the difficulty of the work beyond what the cryptography itself provides. But hashcash only works if it is possible to find a difficulty level that impedes abuse while not significantly affecting legitimate use. It may stop people uploading warez but it can?t prevent cheap vandalism. A From wiktor at metacode.biz Wed Nov 7 12:33:00 2018 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Wed, 7 Nov 2018 12:33:00 +0100 Subject: [Sks-devel] [openpgp-email] Keyservers and GDPR In-Reply-To: References: <87in1945mk.fsf@wheatstone.g10code.de> Message-ID: On 07.11.2018 11:50, Andrew Gallagher wrote: > >> On 7 Nov 2018, at 10:16, Yegor Timoshenko wrote: >> >> World-writable storage is problematic even if there is no search. >> Proof of work and some operator-controllable data removal >> mechanism (like opt-in key blacklists) can help limit this attack >> vector. >> >> Storing immutable data, distributed recon, proof of work, that >> sounds like something a blockchain should do to me. > > More evidence that blockchain is a solution in search of a problem! :-) > > Proof of work verification provides little benefit over cryptographic verification. If you have already generated a valid signature, that is in itself a proof of work. The only reason you would also use hashcash is if you wanted to increase the difficulty of the work beyond what the cryptography itself provides. But hashcash only works if it is possible to find a difficulty level that impedes abuse while not significantly affecting legitimate use. It may stop people uploading warez but it can?t prevent cheap vandalism. Blockchain can be used to timestamp data in a way that is evident to a broad audience. If cryptographic verification was enough for X.509 there wouldn't be Certificate Transparency (that uses similar primitives) and CT is required for all issued "SSL certificates" today [0]. For OpenPGP that would mean keeping the keyservers accountable: not letting them return different responses for different people, or omitting some data (e.g. revocations). There are already projects that tackle this very problem: - https://coniks.cs.princeton.edu/about.html - https://security.googleblog.com/2017/01/security-through-transparency.html - https://blog.okturtles.org/2017/02/coniks-vs-key-transparency-vs-certificate-transparency-vs-blockchains/ (For the record I'm not advocating for using blockchain, but even a buzzword tech should be evaluated purely on its merits) Kind regards, Wiktor [0]: https://www.thesslstore.com/blog/certificate-transparency-april-30-2018/ -- https://metacode.biz/@wiktor From wk at gnupg.org Wed Nov 7 17:34:44 2018 From: wk at gnupg.org (Werner Koch) Date: Wed, 07 Nov 2018 17:34:44 +0100 Subject: [Sks-devel] [openpgp-email] Keyservers and GDPR In-Reply-To: (Andrew Gallagher's message of "Wed, 7 Nov 2018 10:50:07 +0000") References: <87in1945mk.fsf@wheatstone.g10code.de> Message-ID: <87h8gs26e3.fsf@wheatstone.g10code.de> On Wed, 7 Nov 2018 11:50, andrewg at andrewg.com said: > significantly affecting legitimate use. It may stop people uploading > warez but it can?t prevent cheap vandalism. Free storage to upload arbitrary data is easily available (e.g. p2p, free mail accounts). Having a searchable index to that data is more challenging. Thus removing the search capability from the keyservers will render its free-as-in-beer storage feature mostly useless. Salam-Shalom, Werner -- 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 Wed Nov 7 17:51:23 2018 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 7 Nov 2018 16:51:23 +0000 Subject: [Sks-devel] [openpgp-email] Keyservers and GDPR In-Reply-To: References: <87h8gs26e3.fsf@wheatstone.g10code.de> Message-ID: > On 7 Nov 2018, at 16:43, Yegor Timoshenko wrote: > > It's not just storage, it's also immutable and distributed. In the keyservers, removing immutable content is a Very Hard Problem, but it is theoretically possible. With blockchain, it is impossible by design. A From muelli at cryptobitch.de Wed Nov 7 18:07:07 2018 From: muelli at cryptobitch.de (Tobias Mueller) Date: Wed, 07 Nov 2018 18:07:07 +0100 Subject: [Autocrypt] [Sks-devel] [openpgp-email] Keyservers and GDPR In-Reply-To: <87h8gs26e3.fsf@wheatstone.g10code.de> References: <87in1945mk.fsf@wheatstone.g10code.de> <87h8gs26e3.fsf@wheatstone.g10code.de> Message-ID: On Wed, 2018-11-07 at 17:34 +0100, Werner Koch wrote: > Thus removing the search capability from the keyservers > will render its free-as-in-beer storage feature mostly useless. Only if you assume that nobody creates such an index. Cheers, Tobi From muelli at cryptobitch.de Wed Nov 7 18:07:48 2018 From: muelli at cryptobitch.de (Tobias Mueller) Date: Wed, 07 Nov 2018 18:07:48 +0100 Subject: [Autocrypt] [openpgp-email] Keyservers and GDPR In-Reply-To: <87efbx45el.fsf@wheatstone.g10code.de> References: <20180522194409.tmrteipcsoorisns@calamity> <8f9b3617-5e52-e880-8a62-c2a2bcede122@enigmail.net> <87efbx45el.fsf@wheatstone.g10code.de> Message-ID: Hi, On Wed, 2018-11-07 at 10:13 +0100, Werner Koch wrote: > This requires that there are no rogue keyservers in the network and > that > in turn means that they are under the control of a single entity. It depends on your use case, but you might be happy enough if you have a proof of who introduced the malicious data. That said, you might as well establish a network adhering to certain rules run by people who are trusted enough by its users. That may not necessarily be Google, but the EFF, the CCC, or the DPAs of the EU member states. Cheers, Tobi From muelli at cryptobitch.de Wed Nov 7 18:17:25 2018 From: muelli at cryptobitch.de (Tobias Mueller) Date: Wed, 07 Nov 2018 18:17:25 +0100 Subject: [Autocrypt] [Sks-devel] [openpgp-email] Keyservers and GDPR In-Reply-To: References: <87in1945mk.fsf@wheatstone.g10code.de> Message-ID: <690a23b50bc357b584dd9e585cba1c46bc3550c3.camel@cryptobitch.de> Hi, On Wed, 2018-11-07 at 12:33 +0100, Wiktor Kwapisiewicz via Autocrypt wrote: > If cryptographic verification was enough for X.509 there > wouldn't be Certificate Transparency CT solves a slightly different set of problems related to the centralised trust model that we don't necessarily have. That said, I think we can store revocations in the CT logs s.t. we can at least have integrity protection and non-equivocation for those. Both properties which we currently do not have when fetching them from the key server. Cheers, Tobi From wiktor at metacode.biz Wed Nov 7 18:30:33 2018 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Wed, 7 Nov 2018 18:30:33 +0100 Subject: [Autocrypt] [Sks-devel] [openpgp-email] Keyservers and GDPR In-Reply-To: <690a23b50bc357b584dd9e585cba1c46bc3550c3.camel@cryptobitch.de> References: <87in1945mk.fsf@wheatstone.g10code.de> <690a23b50bc357b584dd9e585cba1c46bc3550c3.camel@cryptobitch.de> Message-ID: <84d3b677-668f-fc47-3db2-3393a5785bce@metacode.biz> Hello, On 07.11.2018 18:17, Tobias Mueller wrote: > That said, I think we can store revocations in the CT logs s.t. we can > at least have integrity protection and non-equivocation for those. Both > properties which we currently do not have when fetching them from the > key server. Mozilla experimented with storing release hashes of Firefox in CT logs: https://wiki.mozilla.org/Security/Binary_Transparency They used Merkle tree so the amount of data stored is small (just the tree head) compared to the OpenPGP revocation. Kind regards, Wiktor -- https://metacode.biz/@wiktor From jussi.kivilinna at iki.fi Wed Nov 7 18:38:44 2018 From: jussi.kivilinna at iki.fi (Jussi Kivilinna) Date: Wed, 7 Nov 2018 19:38:44 +0200 Subject: [PATCH 1/8] g10/decrypt-data: use fill_buffer in more places In-Reply-To: <87efc8j27s.fsf@wheatstone.g10code.de> References: <154067434467.18498.15345072060569568612.stgit@localhost.localdomain> <87efc8j27s.fsf@wheatstone.g10code.de> Message-ID: <54830753-1826-03d9-6e16-6e42bb822e5c@iki.fi> Hello, On 29.10.2018 15.45, Werner Koch wrote: > Hi! > > All patches look fine to me. After applying we should however run > extensive tests against another implementation to see whether we have > any breakage. With the current code this has been with the help of > the www.rnpgp.com folks. Should I push this patch set to new branch in gnupg repo? I've also looked at disabling extra hash contexts when decrypting non-signed files. Could those contexts be disabled when any AEAD or MDC encrypted packet is seen? Such patch would look something this: diff --git a/g10/mainproc.c b/g10/mainproc.c index 5b7bc9555..4309b52ac 100644 --- a/g10/mainproc.c +++ b/g10/mainproc.c @@ -91,6 +91,8 @@ struct mainproc_context has been seen. */ unsigned int data:1; /* Any data packet seen */ unsigned int uncompress_failed:1; + unsigned int seen_encrypted_mdc:1; /* Any PKT_ENCRYPTED_MDC packet seen */ + unsigned int seen_encrypted_aead:1; /* Any PKT_ENCRYPTED_AEAD packet seen */ } any; }; @@ -536,6 +538,9 @@ proc_encrypted (CTX c, PACKET *pkt) int result = 0; int early_plaintext = literals_seen; + c->any.seen_encrypted_mdc |= (pkt->pkttype == PKT_ENCRYPTED_MDC); + c->any.seen_encrypted_aead |= (pkt->pkttype == PKT_ENCRYPTED_AEAD); + if (early_plaintext) { log_info (_("WARNING: multiple plaintexts seen\n")); @@ -874,7 +878,8 @@ proc_plaintext( CTX c, PACKET *pkt ) } } - if (!any && !opt.skip_verify) + if (!any && !opt.skip_verify && !c->any.seen_encrypted_mdc && + !c->any.seen_encrypted_aead) { /* This is for the old GPG LITERAL+SIG case. It's not legal according to 2440, so hopefully it won't come up that often. -Jussi From wk at gnupg.org Wed Nov 7 20:49:29 2018 From: wk at gnupg.org (Werner Koch) Date: Wed, 07 Nov 2018 20:49:29 +0100 Subject: [PATCH 1/8] g10/decrypt-data: use fill_buffer in more places In-Reply-To: <54830753-1826-03d9-6e16-6e42bb822e5c@iki.fi> (Jussi Kivilinna's message of "Wed, 7 Nov 2018 19:38:44 +0200") References: <154067434467.18498.15345072060569568612.stgit@localhost.localdomain> <87efc8j27s.fsf@wheatstone.g10code.de> <54830753-1826-03d9-6e16-6e42bb822e5c@iki.fi> Message-ID: <87k1lozn06.fsf@wheatstone.g10code.de> On Wed, 7 Nov 2018 18:38, jussi.kivilinna at iki.fi said: > Should I push this patch set to new branch in gnupg repo? Just go ahead and push it directly to master. > I've also looked at disabling extra hash contexts when decrypting > non-signed files. Could those contexts be disabled when any AEAD or > MDC encrypted packet is seen? Such patch would look something this: While looking at your patches I was reminded to check whether we have some useless hash context running. > + unsigned int seen_encrypted_mdc:1; /* Any PKT_ENCRYPTED_MDC packet seen */ > + unsigned int seen_encrypted_aead:1; /* Any PKT_ENCRYPTED_AEAD packet seen */ There is either one MDC packet or one AEAD packet. > - if (!any && !opt.skip_verify) > + if (!any && !opt.skip_verify && !c->any.seen_encrypted_mdc && > + !c->any.seen_encrypted_aead) > { > /* This is for the old GPG LITERAL+SIG case. It's not legal > according to 2440, so hopefully it won't come up that often. For sure this is not possible with AEAD. With MDC it is unlikely but I think we should not touch that case given that the goal is to fade out the use of MDC. Shalom-Salam, Werner -- 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 Wed Nov 7 20:52:35 2018 From: wk at gnupg.org (Werner Koch) Date: Wed, 07 Nov 2018 20:52:35 +0100 Subject: [Autocrypt] [Sks-devel] [openpgp-email] Keyservers and GDPR In-Reply-To: (Tobias Mueller's message of "Wed, 07 Nov 2018 18:07:07 +0100") References: <87in1945mk.fsf@wheatstone.g10code.de> <87h8gs26e3.fsf@wheatstone.g10code.de> Message-ID: <87ftwczmv0.fsf@wheatstone.g10code.de> On Wed, 7 Nov 2018 18:07, muelli at cryptobitch.de said: > Only if you assume that nobody creates such an index. But then it is not a problem for keyserver operators (except for load issues). Salam-Shalom, Werner -- 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 ingvar at redpill-linpro.com Thu Nov 8 09:44:09 2018 From: ingvar at redpill-linpro.com (Ingvar Hagelund) Date: Thu, 8 Nov 2018 09:44:09 +0100 Subject: [PATCH] Fix for simple typo in the Norwegian translation Message-ID: Here's a fix for a simple typo in the Norwegian translation. br, Ingvar Hagelund GnuPG Developer's Certificate of Origin. Version 1.0 ===================================================== By making a contribution to the GnuPG project, I certify that: (a) The contribution was created in whole or in part by me and I have the right to submit it under the free software license indicated in the file; or (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate free software license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same free software license (unless I am permitted to submit under a different license), as indicated in the file; or (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the free software license(s) involved. Signed-off-by: Ingvar Hagelund commit bc77d3b173507bc7b43429ce62bcae849e62caa4 (HEAD -> fix_nb) Author: Ingvar Hagelund Date: Thu Nov 8 09:33:46 2018 +0100 Correcting a simple typo in the Norwegian translation diff --git a/po/nb.po b/po/nb.po index c6694e7e5..c040c44e8 100644 --- a/po/nb.po +++ b/po/nb.po @@ -3180,7 +3180,7 @@ msgid "Really sign all text user IDs? (y/N) " msgstr "Er du sikker p? at du vil signerere alle bruker-id-er? (j/N) " msgid "Really sign all user IDs? (y/N) " -msgstr "Er du sikekr p? at du vil signerere alle bruker-id-er? (j/N) " +msgstr "Er du sikker p? at du vil signerere alle bruker-id-er? (j/N) " msgid "Hint: Select the user IDs to sign\n" msgstr "Tips: Velg bruker-id-en(e) du vil signere\n" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From jussi.kivilinna at iki.fi Thu Nov 8 19:38:47 2018 From: jussi.kivilinna at iki.fi (Jussi Kivilinna) Date: Thu, 8 Nov 2018 20:38:47 +0200 Subject: [PATCH 1/8] g10/decrypt-data: use fill_buffer in more places In-Reply-To: <87k1lozn06.fsf@wheatstone.g10code.de> References: <154067434467.18498.15345072060569568612.stgit@localhost.localdomain> <87efc8j27s.fsf@wheatstone.g10code.de> <54830753-1826-03d9-6e16-6e42bb822e5c@iki.fi> <87k1lozn06.fsf@wheatstone.g10code.de> Message-ID: On 7.11.2018 21.49, Werner Koch wrote: > On Wed, 7 Nov 2018 18:38, jussi.kivilinna at iki.fi said: > >> Should I push this patch set to new branch in gnupg repo? > > Just go ahead and push it directly to master. > >> I've also looked at disabling extra hash contexts when decrypting >> non-signed files. Could those contexts be disabled when any AEAD or >> MDC encrypted packet is seen? Such patch would look something this: > > While looking at your patches I was reminded to check whether we have > some useless hash context running. > >> + unsigned int seen_encrypted_mdc:1; /* Any PKT_ENCRYPTED_MDC packet seen */ >> + unsigned int seen_encrypted_aead:1; /* Any PKT_ENCRYPTED_AEAD packet seen */ > > There is either one MDC packet or one AEAD packet. > >> - if (!any && !opt.skip_verify) >> + if (!any && !opt.skip_verify && !c->any.seen_encrypted_mdc && >> + !c->any.seen_encrypted_aead) >> { >> /* This is for the old GPG LITERAL+SIG case. It's not legal >> according to 2440, so hopefully it won't come up that often. > > For sure this is not possible with AEAD. With MDC it is unlikely but I > think we should not touch that case given that the goal is to fade out > the use of MDC. > Ok, I'll make patch AEAD only. For CFB/MDC, user can of course use --skip-verify if they know that input does not have signature and want to get highest performance. Here's results that I've seen with patch/--skip-verify for different types of input on my machine (2GiB input file from ramfs): decrypting MDC encrypted, signed (AES128+SHA1(mdc)+SHA512(sign)): user 5.2s, 364 MB/s decrypting MDC encrypted, not signed (AES128+2xSHA1(mdc+extra)+RMD160(extra)): user 9.6s, 206 MB/s decrypting MDC encrypted, not signed --skip-verify (AES128+SHA1(mdc)): user 3.0s, 575 MB/s decrypting MDC symmetric encrypted, not signed (AES128+SHA1(mdc+extra)+RMD160(extra)): user 9.7s, 205 MB/s decrypting MDC symmetric encrypted, not signed --skip-verify (AES128+SHA1(mdc)): user 3.1s, 556 MB/s decrypting AEAD encrypted, signed (AES128_OCB+SHA512(sign)): user 4.7s, 387 MB/s decrypting AEAD encrypted, not signed (AES128_OCB+SHA1(extra)+RMD160(extra)): user 7.6s, 258 MB/s decrypting AEAD encrypted, not signed --skip-verify or patched (AES128_OCB): user 0.95s, 1.2 GB/s decrypting AEAD symmetric encrypted, not signed (AES128_OCB+SHA1(extra)+RMD160(extra)): user 7.6s, 256 MB/s decrypting AEAD symmetric encrypted, not signed --skip-verify or patched (AES128_OCB): user 1.1s, 1.1 GB/s I also noticed that --skip-verify does not affect decryption speed of signed input. Selected digest algorithm gets enabled regardless of --skip-verify in proc_plaintext(). Should this be fixed? -Jussi -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 671 bytes Desc: OpenPGP digital signature URL: From jussi.kivilinna at iki.fi Thu Nov 8 21:19:15 2018 From: jussi.kivilinna at iki.fi (Jussi Kivilinna) Date: Thu, 8 Nov 2018 22:19:15 +0200 Subject: [PATCH] g10/mainproc: avoid extra hash contexts when decrypting AEAD input Message-ID: <154170835500.7973.17202438053527160722.stgit@localhost.localdomain> * g10/mainproc.c (mainproc_context): New member 'seen_pkt_encrypted_aead'. (release_list): Clear 'seen_pkt_encrypted_aead'. (proc_encrypted): Set 'seen_pkt_encrypted_aead'. (have_seen_pkt_encrypted_aead): New. (proc_plaintext): Do not enable extra hash contexts when decryption AEAD input. -- Signed-off-by: Jussi Kivilinna --- 0 files changed diff --git a/g10/mainproc.c b/g10/mainproc.c index 5b7bc9555..7eceb7e0b 100644 --- a/g10/mainproc.c +++ b/g10/mainproc.c @@ -86,6 +86,7 @@ struct mainproc_context int trustletter; /* Temporary usage in list_node. */ ulong symkeys; /* Number of symmetrically encrypted session keys. */ struct pubkey_enc_list *pkenc_list; /* List of encryption packets. */ + int seen_pkt_encrypted_aead; /* PKT_ENCRYPTED_AEAD packet seen. */ struct { unsigned int sig_seen:1; /* Set to true if a signature packet has been seen. */ @@ -137,6 +138,7 @@ release_list( CTX c ) c->any.data = 0; c->any.uncompress_failed = 0; c->last_was_session_key = 0; + c->seen_pkt_encrypted_aead = 0; xfree (c->dek); c->dek = NULL; } @@ -536,6 +538,9 @@ proc_encrypted (CTX c, PACKET *pkt) int result = 0; int early_plaintext = literals_seen; + if (pkt->pkttype == PKT_ENCRYPTED_AEAD) + c->seen_pkt_encrypted_aead = 1; + if (early_plaintext) { log_info (_("WARNING: multiple plaintexts seen\n")); @@ -704,7 +709,6 @@ proc_encrypted (CTX c, PACKET *pkt) } - if (!result) result = decrypt_data (c->ctrl, c, pkt->pkt.encrypted, c->dek ); @@ -804,6 +808,21 @@ proc_encrypted (CTX c, PACKET *pkt) } +static int +have_seen_pkt_encrypted_aead( CTX c ) +{ + CTX cc; + + for (cc = c; cc; cc = cc->anchor) + { + if (cc->seen_pkt_encrypted_aead) + return 1; + } + + return 0; +} + + static void proc_plaintext( CTX c, PACKET *pkt ) { @@ -874,7 +893,7 @@ proc_plaintext( CTX c, PACKET *pkt ) } } - if (!any && !opt.skip_verify) + if (!any && !opt.skip_verify && !have_seen_pkt_encrypted_aead(c)) { /* This is for the old GPG LITERAL+SIG case. It's not legal according to 2440, so hopefully it won't come up that often. From wk at gnupg.org Fri Nov 9 14:46:18 2018 From: wk at gnupg.org (Werner Koch) Date: Fri, 09 Nov 2018 14:46:18 +0100 Subject: [PATCH] g10/mainproc: avoid extra hash contexts when decrypting AEAD input In-Reply-To: <154170835500.7973.17202438053527160722.stgit@localhost.localdomain> (Jussi Kivilinna's message of "Thu, 8 Nov 2018 22:19:15 +0200") References: <154170835500.7973.17202438053527160722.stgit@localhost.localdomain> Message-ID: <87zhuitlcl.fsf@wheatstone.g10code.de> Hi! Looks good to me. Shalom-Salam, Werner -- 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 jussi.kivilinna at iki.fi Fri Nov 9 17:48:07 2018 From: jussi.kivilinna at iki.fi (Jussi Kivilinna) Date: Fri, 9 Nov 2018 18:48:07 +0200 Subject: [PATCH 1/2] common/mischelp: use memset for wipememory Message-ID: <154178208738.8762.5265325772335861348.stgit@localhost.localdomain> * common/mischelp.h (wipememory2): Replace macro with function prototype. * common/mischelp.c (wipememory2): New. -- In new wipememory2 function, memset is called through volatile function pointer to so that compiler won't optimize away the call. Signed-off-by: Jussi Kivilinna --- common/mischelp.c | 10 ++++++++++ common/mischelp.h | 12 ++++-------- 2 files changed, 14 insertions(+), 8 deletions(-) diff --git a/common/mischelp.c b/common/mischelp.c index 75ba60714..008aaab55 100644 --- a/common/mischelp.c +++ b/common/mischelp.c @@ -49,6 +49,16 @@ #include "mischelp.h" +void +wipememory2 (void *ptr, int set, size_t len) +{ + /* Prevent compiler from optimizing away the call to memset by accessing + memset through volatile pointer. */ + static void *(*volatile memset_ptr)(void *, int, size_t) = (void *)memset; + memset_ptr (ptr, set, len); +} + + /* Check whether the files NAME1 and NAME2 are identical. This is for example achieved by comparing the inode numbers of the files. */ int diff --git a/common/mischelp.h b/common/mischelp.h index 18ec96edf..2554c2160 100644 --- a/common/mischelp.h +++ b/common/mischelp.h @@ -47,14 +47,10 @@ time_t timegm (struct tm *tm); #define DIM(v) (sizeof(v)/sizeof((v)[0])) #define DIMof(type,member) DIM(((type *)0)->member) -/* To avoid that a compiler optimizes certain memset calls away, these - macros may be used instead. */ -#define wipememory2(_ptr,_set,_len) do { \ - volatile char *_vptr=(volatile char *)(_ptr); \ - size_t _vlen=(_len); \ - while(_vlen) { *_vptr=(_set); _vptr++; _vlen--; } \ - } while(0) -#define wipememory(_ptr,_len) wipememory2(_ptr,0,_len) +/* To avoid that a compiler optimizes certain memset calls away, + wipememory function and macro may be used instead. */ +void wipememory2(void *ptr, int set, size_t len); +#define wipememory(_ptr,_len) wipememory2((_ptr),0,(_len)) /* Include hacks which are mainly required for Slowaris. */ From jussi.kivilinna at iki.fi Fri Nov 9 17:48:12 2018 From: jussi.kivilinna at iki.fi (Jussi Kivilinna) Date: Fri, 9 Nov 2018 18:48:12 +0200 Subject: [PATCH 2/2] common/iobuf: fix memory wiping in iobuf_copy In-Reply-To: <154178208738.8762.5265325772335861348.stgit@localhost.localdomain> References: <154178208738.8762.5265325772335861348.stgit@localhost.localdomain> Message-ID: <154178209257.8762.530409850587515562.stgit@localhost.localdomain> * common/iobuf.c (iobuf_copy): Wipe used area of buffer instead of first sizeof(char*) bytes. -- Signed-off-by: Jussi Kivilinna --- common/iobuf.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/common/iobuf.c b/common/iobuf.c index 5eeba8fe6..05944255f 100644 --- a/common/iobuf.c +++ b/common/iobuf.c @@ -2262,6 +2262,7 @@ iobuf_copy (iobuf_t dest, iobuf_t source) size_t nread; size_t nwrote = 0; + size_t max_read = 0; int err; assert (source->use == IOBUF_INPUT || source->use == IOBUF_INPUT_TEMP); @@ -2278,6 +2279,9 @@ iobuf_copy (iobuf_t dest, iobuf_t source) /* EOF. */ break; + if (nread > max_read) + max_read = nread; + err = iobuf_write (dest, temp, nread); if (err) break; @@ -2285,7 +2289,8 @@ iobuf_copy (iobuf_t dest, iobuf_t source) } /* Burn the buffer. */ - wipememory (temp, sizeof (temp)); + if (max_read) + wipememory (temp, max_read); xfree (temp); return nwrote; From albrecht.dress at arcor.de Fri Nov 9 19:23:43 2018 From: albrecht.dress at arcor.de (Albrecht =?iso-8859-1?b?RHJl3w==?=) Date: Fri, 09 Nov 2018 19:23:43 +0100 Subject: Minimum GPG version for export options? Message-ID: Hi all, does a documentation exist which ?--export-options? and ?--export-filter? attributes are supported by which gpg version? In particular, I am interested in the minimum gpg version for a minimal, Autocrypt-compliant export of existing keys, using the following options: * --export-options export-minimal,no-export-attributes * --export-filter keep-uid=? * --export-filter drop-subkey=? Thanks in advance, Albrecht. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From dkg at fifthhorseman.net Mon Nov 12 08:20:13 2018 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 12 Nov 2018 02:20:13 -0500 Subject: Minimum GPG version for export options? In-Reply-To: References: Message-ID: <87efbqbw42.fsf@fifthhorseman.net> On Fri 2018-11-09 19:23:43 +0100, Albrecht Dre? wrote: > Hi all, > > does a documentation exist which ?--export-options? and ?--export-filter? attributes are supported by which gpg version? > > In particular, I am interested in the minimum gpg version for a minimal, Autocrypt-compliant export of existing keys, using the following options: > * --export-options export-minimal,no-export-attributes > * --export-filter keep-uid=? > * --export-filter drop-subkey=? According to then NEWS file, --export-filter (and --import-filter) was added in 2.1.14. Note that the possible matches used for drop-subkey= have grown over time. most recently, 2.2.9 added a "usage" property as a matcher for drop-subkey. export-minimal and export-attributes have been in GnuPG for ages (they're in the 1.4 branch), but i note that the implementation of export-minimal has gotten tighter in version 2.2.9 (see https://dev.gnupg.org/T3622). Note that in the Debian operating system, I've backported several of these changes to the version supported in debian stable (aka "debian stretch" or "debian 9"). So while its version says "2.1.18", it does include some fixed behavior, mainly to support modern versions of Enigmail (see https://bugs.debian.org/909000 for more discussion). Regareds, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From albrecht.dress at arcor.de Mon Nov 12 19:31:05 2018 From: albrecht.dress at arcor.de (Albrecht =?iso-8859-1?b?RHJl3w==?=) Date: Mon, 12 Nov 2018 19:31:05 +0100 Subject: Minimum GPG version for export options? In-Reply-To: <87efbqbw42.fsf@fifthhorseman.net> (from dkg@fifthhorseman.net on Mon Nov 12 08:20:13 2018) Message-ID: Thanks a lot for your help! Am 12.11.18 08:20 schrieb(en) Daniel Kahn Gillmor: > According to then NEWS file, --export-filter (and --import-filter) was added in 2.1.14. > > Note that the possible matches used for drop-subkey= have grown over time. most recently, 2.2.9 added a "usage" property as a matcher for drop-subkey. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From wk at gnupg.org Tue Nov 13 15:40:38 2018 From: wk at gnupg.org (Werner Koch) Date: Tue, 13 Nov 2018 15:40:38 +0100 Subject: FYI: [openpgp] Web Key Directory I-D -07 Message-ID: <87pnv9niqh.fsf@wheatstone.g10code.de> [Copy of mail to the OpenPGP WG. ] -------------- next part -------------- An embedded message was scrubbed... From: Werner Koch Subject: [openpgp] Web Key Directory I-D -07 Date: Tue, 13 Nov 2018 15:02:04 +0100 Size: 9416 URL: -------------- next part -------------- -- 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 alon.barlev at gmail.com Tue Nov 13 16:06:55 2018 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Tue, 13 Nov 2018 17:06:55 +0200 Subject: [PATCH Libgpg-error] gpg-error.m4: support pkg-config In-Reply-To: <87d0rqod6v.fsf@fsij.org> References: <20181011182720.11991-1-alon.barlev@gmail.com> <871s8vptg1.fsf@wheatstone.g10code.de> <87efcokjn6.fsf@wheatstone.g10code.de> <8736snt3kn.fsf@fsij.org> <87d0rqod6v.fsf@fsij.org> Message-ID: Hello Werner, Please don't let this thread die. I will appreciate if we can come up with some solution that will be acceptable. Thanks! Alon On Wed, Oct 31, 2018 at 8:14 AM NIIBE Yutaka wrote: > > Alon Bar-Lev wrote: > > This thread is about modifying the build so that it will have an > > option to use pkg-config instead of config scripts if downstream > > maintainer chooses to. > > I know. > > I don't argue this point. > > I pointed out that the important technical things (no use of > --with-*-prefix/SYSROOT with *-config scripts, to build GnuPG and its > related libraries) can be already achieved with no new dependency to > pkg-config. (I mean, gnupg in master. It's not yet applied > to stable branch.) > > My point is, people don't need to use libraries' *-config scripts any > more, but only a single gpgrt-config script now. > > In the past, there are *-config script from libraries, and for some > build environment, there are even prefixed versions for supported hosts, > like i686-linux-gnu-gpg-error-config and sh4-linux-gnu-libassuan-config. > Now, we only have a gpgrt-config. > > Still *-config script in each library is not removed, so that it can > still support existing software, but it's no need any more when we build > gnupg master. > -- From wk at gnupg.org Tue Nov 13 16:20:20 2018 From: wk at gnupg.org (Werner Koch) Date: Tue, 13 Nov 2018 16:20:20 +0100 Subject: [PATCH 1/2] common/mischelp: use memset for wipememory In-Reply-To: <154178208738.8762.5265325772335861348.stgit@localhost.localdomain> (Jussi Kivilinna's message of "Fri, 9 Nov 2018 18:48:07 +0200") References: <154178208738.8762.5265325772335861348.stgit@localhost.localdomain> Message-ID: <8736s5ngwb.fsf@wheatstone.g10code.de> On Fri, 9 Nov 2018 17:48, jussi.kivilinna at iki.fi said: > In new wipememory2 function, memset is called through volatile > function pointer to so that compiler won't optimize away the call. Are you sure that none of those braindead compilers removes that call for example when inlined? They may find yet another interpreation why it is allowed. But anyway, the old code would or is already target to such new dis-optimization. Salam-Shalom, Werner -- 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 Nov 13 16:33:42 2018 From: wk at gnupg.org (Werner Koch) Date: Tue, 13 Nov 2018 16:33:42 +0100 Subject: [PATCH 1/8] g10/decrypt-data: use fill_buffer in more places In-Reply-To: (Jussi Kivilinna's message of "Thu, 8 Nov 2018 20:38:47 +0200") References: <154067434467.18498.15345072060569568612.stgit@localhost.localdomain> <87efc8j27s.fsf@wheatstone.g10code.de> <54830753-1826-03d9-6e16-6e42bb822e5c@iki.fi> <87k1lozn06.fsf@wheatstone.g10code.de> Message-ID: <87y39xm1pl.fsf@wheatstone.g10code.de> On Thu, 8 Nov 2018 19:38, jussi.kivilinna at iki.fi said: > Ok, I'll make patch AEAD only. For CFB/MDC, user can of course use > --skip-verify if they know that input does not have signature and want > to get highest performance. We should add this to the FAQ under a new section how to speed up operations. > decrypting MDC encrypted, not signed (AES128+2xSHA1(mdc+extra)+RMD160(extra)): > user 9.6s, 206 MB/s > decrypting MDC encrypted, not signed --skip-verify (AES128+SHA1(mdc)): > user 3.0s, 575 MB/s The RMD160 is really really slow. > decrypting AEAD encrypted, not signed (AES128_OCB+SHA1(extra)+RMD160(extra)): > user 7.6s, 258 MB/s > decrypting AEAD encrypted, not signed --skip-verify or patched (AES128_OCB): > user 0.95s, 1.2 GB/s Yeah, that is a speedup. > I also noticed that --skip-verify does not affect decryption speed of > signed input. Selected digest algorithm gets enabled regardless of > --skip-verify in proc_plaintext(). Should this be fixed? Yes, please. Performance was not an issue back in April 98 when I implemented --skip-verify. Shalom-Salam, Werner -- 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 jussi.kivilinna at iki.fi Tue Nov 13 18:24:13 2018 From: jussi.kivilinna at iki.fi (Jussi Kivilinna) Date: Tue, 13 Nov 2018 19:24:13 +0200 Subject: [PATCH 1/2] common/mischelp: use memset for wipememory In-Reply-To: <8736s5ngwb.fsf@wheatstone.g10code.de> References: <154178208738.8762.5265325772335861348.stgit@localhost.localdomain> <8736s5ngwb.fsf@wheatstone.g10code.de> Message-ID: <5d6d128a-e618-3e4d-7bca-80ba686dff5a@iki.fi> On 13.11.2018 17.20, Werner Koch wrote: > On Fri, 9 Nov 2018 17:48, jussi.kivilinna at iki.fi said: > >> In new wipememory2 function, memset is called through volatile >> function pointer to so that compiler won't optimize away the call. > > Are you sure that none of those braindead compilers removes that call > for example when inlined? They may find yet another interpreation why > it is allowed. But anyway, the old code would or is already target to > such new dis-optimization. Well, sufficiently braindead compiler might check if value read from volatile function pointer is for 'memset' and do dead store elimination. In practice, this does not happen. Access to memset through volatile pointer is discussed here: http://www.daemonology.net/blog/2014-09-04-how-to-zero-a-buffer.html http://www.daemonology.net/blog/2014-09-05-erratum.html Best way to perform memory wipe would be through platform provided functions, such as explicit_bzero, or memset_s. I'll add support those and leave volatile function pointer approach as backup. -Jussi -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 671 bytes Desc: OpenPGP digital signature URL: From jussi.kivilinna at iki.fi Tue Nov 13 21:25:00 2018 From: jussi.kivilinna at iki.fi (Jussi Kivilinna) Date: Tue, 13 Nov 2018 22:25:00 +0200 Subject: [PATCH] g10/mainproc: disable hash contexts when --skip-verify is used Message-ID: <154214070028.21401.1033176360857425189.stgit@localhost.localdomain> * g10/mainproc.c (proc_plaintext): Do not enable hash contexts when opt.skip_verify is set. -- Signed-off-by: Jussi Kivilinna --- 0 files changed diff --git a/g10/mainproc.c b/g10/mainproc.c index 7eceb7e0b..dce3f3799 100644 --- a/g10/mainproc.c +++ b/g10/mainproc.c @@ -862,7 +862,10 @@ proc_plaintext( CTX c, PACKET *pkt ) /* The onepass signature case. */ if (n->pkt->pkt.onepass_sig->digest_algo) { - gcry_md_enable (c->mfx.md, n->pkt->pkt.onepass_sig->digest_algo); + if (!opt.skip_verify) + gcry_md_enable (c->mfx.md, + n->pkt->pkt.onepass_sig->digest_algo); + any = 1; } } @@ -880,7 +883,8 @@ proc_plaintext( CTX c, PACKET *pkt ) * documents. */ clearsig = (*data == 0x01); for (data++, datalen--; datalen; datalen--, data++) - gcry_md_enable (c->mfx.md, *data); + if (!opt.skip_verify) + gcry_md_enable (c->mfx.md, *data); any = 1; break; /* Stop here as one-pass signature packets are not expected. */ @@ -888,7 +892,8 @@ proc_plaintext( CTX c, PACKET *pkt ) else if (n->pkt->pkttype == PKT_SIGNATURE) { /* The SIG+LITERAL case that PGP used to use. */ - gcry_md_enable ( c->mfx.md, n->pkt->pkt.signature->digest_algo ); + if (!opt.skip_verify) + gcry_md_enable (c->mfx.md, n->pkt->pkt.signature->digest_algo); any = 1; } } From jussi.kivilinna at iki.fi Tue Nov 13 21:31:28 2018 From: jussi.kivilinna at iki.fi (Jussi Kivilinna) Date: Tue, 13 Nov 2018 22:31:28 +0200 Subject: [PATCH] common/mischelp: use platform memory zeroing function for wipememory In-Reply-To: <5d6d128a-e618-3e4d-7bca-80ba686dff5a@iki.fi> References: <5d6d128a-e618-3e4d-7bca-80ba686dff5a@iki.fi> Message-ID: <154214108786.28716.2991800022134310580.stgit@localhost.localdomain> * common/mischelp.h (wipememory): Replace macro with function prototype. (wipememory2): Remove. * common/mischelp.c (wipememory): New. * configure.ac (AC_CHECK_FUNCS): Check for 'explicit_bzero'. -- In new wipememory function, memory is cleared through platform provided secure memory zeroing function, SecureZeroMemory or explicit_bzero. If none of these is available, memset is called through volatile function pointer to so that compiler won't optimize away the call. Signed-off-by: Jussi Kivilinna --- 0 files changed diff --git a/common/mischelp.c b/common/mischelp.c index 75ba60714..81dd501f8 100644 --- a/common/mischelp.c +++ b/common/mischelp.c @@ -49,6 +49,22 @@ #include "mischelp.h" +void +wipememory (void *ptr, size_t len) +{ +#if defined(HAVE_W32_SYSTEM) && defined(SecureZeroMemory) + SecureZeroMemory (ptr, len); +#elif defined(HAVE_EXPLICIT_BZERO) + explicit_bzero (ptr, len); +#else + /* Prevent compiler from optimizing away the call to memset by accessing + memset through volatile pointer. */ + static void *(*volatile memset_ptr)(void *, int, size_t) = (void *)memset; + memset_ptr (ptr, 0, len); +#endif +} + + /* Check whether the files NAME1 and NAME2 are identical. This is for example achieved by comparing the inode numbers of the files. */ int diff --git a/common/mischelp.h b/common/mischelp.h index 18ec96edf..bdee5a443 100644 --- a/common/mischelp.h +++ b/common/mischelp.h @@ -47,15 +47,9 @@ time_t timegm (struct tm *tm); #define DIM(v) (sizeof(v)/sizeof((v)[0])) #define DIMof(type,member) DIM(((type *)0)->member) -/* To avoid that a compiler optimizes certain memset calls away, these - macros may be used instead. */ -#define wipememory2(_ptr,_set,_len) do { \ - volatile char *_vptr=(volatile char *)(_ptr); \ - size_t _vlen=(_len); \ - while(_vlen) { *_vptr=(_set); _vptr++; _vlen--; } \ - } while(0) -#define wipememory(_ptr,_len) wipememory2(_ptr,0,_len) - +/* To avoid that a compiler optimizes certain memset calls away, + wipememory function may be used instead. */ +void wipememory(void *ptr, size_t len); /* Include hacks which are mainly required for Slowaris. */ #ifdef GNUPG_COMMON_NEED_AFLOCAL diff --git a/configure.ac b/configure.ac index 795daa400..f961adbde 100644 --- a/configure.ac +++ b/configure.ac @@ -1400,16 +1400,16 @@ AC_FUNC_FSEEKO AC_FUNC_VPRINTF AC_FUNC_FORK AC_CHECK_FUNCS([atexit canonicalize_file_name clock_gettime ctermid \ - fcntl flockfile fsync ftello ftruncate funlockfile \ - getaddrinfo getenv getpagesize getpwnam getpwuid \ - getrlimit getrusage gettimeofday gmtime_r \ - inet_ntop inet_pton isascii lstat \ - memicmp memmove memrchr mmap nl_langinfo pipe \ - raise rand setenv setlocale setrlimit sigaction \ - sigprocmask stat stpcpy strcasecmp strerror strftime \ - stricmp strlwr strncasecmp strpbrk strsep \ - strtol strtoul strtoull tcgetattr timegm times \ - ttyname unsetenv wait4 waitpid ]) + explicit_bzero fcntl flockfile fsync ftello \ + ftruncate funlockfile getaddrinfo getenv getpagesize \ + getpwnam getpwuid getrlimit getrusage gettimeofday \ + gmtime_r inet_ntop inet_pton isascii lstat memicmp \ + memmove memrchr mmap nl_langinfo pipe raise rand \ + setenv setlocale setrlimit sigaction sigprocmask \ + stat stpcpy strcasecmp strerror strftime stricmp \ + strlwr strncasecmp strpbrk strsep strtol strtoul \ + strtoull tcgetattr timegm times ttyname unsetenv \ + wait4 waitpid ]) # On some systems (e.g. Solaris) nanosleep requires linking to librl. # Given that we use nanosleep only as an optimization over a select From bela at becker.rocks Wed Nov 14 02:44:34 2018 From: bela at becker.rocks (=?UTF-8?q?B=C3=A9la=20Becker?=) Date: Wed, 14 Nov 2018 02:44:34 +0100 Subject: [PATCH] poldi: fail immediately when PIN input is too short Message-ID: <20181114014434.22676-1-bela@becker.rocks> When poldi detects a PIN that is too short, it repeatedly asked for a new one. This might work in a CLI, but entering a short (or empty) PIN using the KDE greeter will lock it up permanently. By failing immediately, the login program can determine the proper course of action. --- src/pam/auth-support/getpin-cb.c | 38 ++++++++++++-------------------- 1 file changed, 14 insertions(+), 24 deletions(-) diff --git a/src/pam/auth-support/getpin-cb.c b/src/pam/auth-support/getpin-cb.c index d06c50f..773f1b6 100644 --- a/src/pam/auth-support/getpin-cb.c +++ b/src/pam/auth-support/getpin-cb.c @@ -45,7 +45,6 @@ #include "getpin-cb.h" - /* Query the user through PAM for his PIN. Display INFO to the user. Store the retrieved pin in PIN, which is of size PIN_SIZE. If it does not fit, return error. */ @@ -56,41 +55,32 @@ query_user (poldi_ctx_t ctx, const char *info, char *pin, size_t pin_size) int rc; buffer = NULL; - rc = 0; - while (1) /* Loop until well-formed PIN retrieved. */ - { - /* Retrieve PIN through PAM. */ - rc = conv_ask (ctx->conv, 1, &buffer, info); - if (rc) - goto out; + /* Retrieve PIN through PAM. */ + rc = conv_ask (ctx->conv, 1, &buffer, info); + if (rc) + return rc; - /* Do some basic checks on the entered PIN. FIXME: hard-coded - values! Is this really the correct place for these checks? - Shouldn't they be done in scdaemon itself? -mo */ + /* Do some basic checks on the entered PIN. FIXME: hard-coded + values! Is this really the correct place for these checks? + Shouldn't they be done in scdaemon itself? -mo */ - if (strlen (buffer) < 6) /* FIXME? is it really minimum of 6 bytes? */ - { - log_msg_error (ctx->loghandle, "PIN too short"); - conv_tell (ctx->conv, "%s", _("PIN too short")); - } - else - break; + if (strlen (buffer) < 6) /* FIXME? is it really minimum of 6 bytes? */ + { + log_msg_error (ctx->loghandle, "PIN too short"); + conv_tell (ctx->conv, "%s", _("PIN too short")); + return gpg_error (GPG_ERR_INV_DATA); } if (strlen (buffer) >= pin_size) { log_msg_error (ctx->loghandle, "PIN too long for buffer!"); - rc = gpg_error (GPG_ERR_INV_DATA); /* ? */ - goto out; + return gpg_error (GPG_ERR_INV_DATA); } strncpy (pin, buffer, pin_size - 1); pin[pin_size-1] = 0; - - out: - - return rc; + return 0; } /* Pop up a message window similar to the confirm one but keep it open -- 2.19.1 From dgouttegattat at incenp.org Fri Nov 16 02:27:38 2018 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Fri, 16 Nov 2018 01:27:38 +0000 Subject: [PATCH libksba 2/2] Support multi-valued signatures in CSRs. In-Reply-To: <20181116012738.23296-1-dgouttegattat@incenp.org> References: <20181116012738.23296-1-dgouttegattat@incenp.org> Message-ID: <20181116012738.23296-3-dgouttegattat@incenp.org> * src/certreq.c (ksba_certreq_set_sig_val): Support signatures made of several values. -- The current implementation of ksba_certreq_set_sig_val takes only the first MPI value in the provided S-expression to build the CSR signature. This is enough for RSA, but not for ECDSA since a ECDSA signature is made of two values. This patch makes sure all values are taken into account. It also partially replaces some of the ad-hoc parsing code by the helper functions defined in sexp-parse.h. GnuPG-bug-id: 4092 Signed-off-by: Damien Goutte-Gattat --- src/certreq.c | 148 +++++++++++++++++++++++++++++++++++++++------------------- 1 file changed, 100 insertions(+), 48 deletions(-) diff --git a/src/certreq.c b/src/certreq.c index 46fca44..5c730a7 100644 --- a/src/certreq.c +++ b/src/certreq.c @@ -42,6 +42,7 @@ #include "keyinfo.h" #include "der-encoder.h" #include "ber-help.h" +#include "sexp-parse.h" #include "certreq.h" static const char oidstr_subjectAltName[] = "2.5.29.17"; @@ -406,8 +407,10 @@ ksba_certreq_add_extension (ksba_certreq_t cr, gpg_error_t ksba_certreq_set_sig_val (ksba_certreq_t cr, ksba_const_sexp_t sigval) { - const char *s, *endp; - unsigned long n; + const unsigned char *s, *saved; + char *buf = NULL; + unsigned long n, len; + int pass, nparam; if (!cr) return gpg_error (GPG_ERR_INV_VALUE); @@ -417,24 +420,17 @@ ksba_certreq_set_sig_val (ksba_certreq_t cr, ksba_const_sexp_t sigval) return gpg_error (GPG_ERR_INV_SEXP); s++; - n = strtoul (s, (char**)&endp, 10); - s = endp; - if (!n || *s!=':') - return gpg_error (GPG_ERR_INV_SEXP); /* we don't allow empty lengths */ - s++; - if (n != 7 || memcmp (s, "sig-val", 7)) + if (!(n = snext (&s))) + return gpg_error (GPG_ERR_INV_SEXP); + if (!smatch (&s, 7, "sig-val")) return gpg_error (GPG_ERR_UNKNOWN_SEXP); - s += 7; if (*s != '(') return gpg_error (digitp (s)? GPG_ERR_UNKNOWN_SEXP : GPG_ERR_INV_SEXP); s++; /* break out the algorithm ID */ - n = strtoul (s, (char**)&endp, 10); - s = endp; - if (!n || *s != ':') - return gpg_error (GPG_ERR_INV_SEXP); /* we don't allow empty lengths */ - s++; + if (!(n = snext (&s))) + return gpg_error (GPG_ERR_INV_SEXP); xfree (cr->sig_val.algo); if (n==3 && s[0] == 'r' && s[1] == 's' && s[2] == 'a') { /* kludge to allow "rsa" to be passed as algorithm name */ @@ -452,42 +448,98 @@ ksba_certreq_set_sig_val (ksba_certreq_t cr, ksba_const_sexp_t sigval) } s += n; - /* And now the values - FIXME: For now we only support one */ - /* fixme: start loop */ - if (*s != '(') - return gpg_error (digitp (s)? GPG_ERR_UNKNOWN_SEXP : GPG_ERR_INV_SEXP); - s++; - n = strtoul (s, (char**)&endp, 10); - s = endp; - if (!n || *s != ':') - return gpg_error (GPG_ERR_INV_SEXP); - s++; - s += n; /* ignore the name of the parameter */ + /* And now the values. + * + * If there is only one value, the signature is simply + * that value. Otherwise, the signature is a DER-encoded + * SEQUENCE of INTEGERs representing the different values. + * + * We need three passes over the values: + * - first pass is to get the number of values (nparam); + * - second pass is to compute the total length (len); + * - third pass is to build the final signature. */ + for (pass = 1, nparam = len = 0, saved = s; pass < 4; pass++) + { + s = saved; - if (!digitp(s)) - return gpg_error (GPG_ERR_UNKNOWN_SEXP); /* but may also be an invalid one */ - n = strtoul (s, (char**)&endp, 10); - s = endp; - if (!n || *s != ':') - return gpg_error (GPG_ERR_INV_SEXP); - s++; - if (n > 1 && !*s) - { /* We might have a leading zero due to the way we encode - MPIs - this zero should not go into the BIT STRING. */ - s++; - n--; + if (pass == 3) + { + size_t needed = len; + if (nparam > 1) + needed += _ksba_ber_count_tl (TYPE_SEQUENCE, CLASS_UNIVERSAL, 1, len); + + xfree (cr->sig_val.value); + cr->sig_val.value = xtrymalloc (needed); + if (!cr->sig_val.value) + return gpg_error (GPG_ERR_ENOMEM); + cr->sig_val.valuelen = needed; + buf = cr->sig_val.value; + + if (nparam > 1) + buf += _ksba_ber_encode_tl (buf, TYPE_SEQUENCE, + CLASS_UNIVERSAL, 1, len); + } + + while (*s != ')') + { + if (*s != '(') + return gpg_error (digitp (s)? GPG_ERR_UNKNOWN_SEXP : GPG_ERR_INV_SEXP); + s++; + if (!(n = snext (&s))) + return gpg_error (GPG_ERR_INV_SEXP); + s += n; /* Ignore the name of the parameter. */ + + if (!digitp (s)) + return gpg_error (GPG_ERR_UNKNOWN_SEXP); + if (!(n = snext (&s))) + return gpg_error (GPG_ERR_INV_SEXP); + + if (pass == 1) + nparam++; + else if (pass == 2) + { + if (nparam > 1) + len += _ksba_ber_count_tl (TYPE_INTEGER, CLASS_UNIVERSAL, 0, + *s >= 0x80? n + 1 : n) + + (*s >= 0x80? n + 1 : n); + else + len += (n > 1 && !*s)? n - 1 : n; + } + else if (pass == 3) + { + if (nparam > 1) + { + if (*s >= 0x80) + { /* Add leading zero byte. */ + buf += _ksba_ber_encode_tl (buf, TYPE_INTEGER, + CLASS_UNIVERSAL, 0, n + 1); + *buf++ = 0; + } + else + buf += _ksba_ber_encode_tl (buf, TYPE_INTEGER, + CLASS_UNIVERSAL, 0, n); + memcpy (buf, s, n); + buf += n; + } + else + { + if (n > 1 && !*s) + { /* Remove leading zero byte, which must not be + included in the bitstring. */ + s++; + n--; + } + memcpy (buf, s, n); + buf += n; + } + } + + s += n; + if (*s != ')') + return gpg_error (GPG_ERR_UNKNOWN_SEXP); + s++; + } } - xfree (cr->sig_val.value); - cr->sig_val.value = xtrymalloc (n); - if (!cr->sig_val.value) - return gpg_error (GPG_ERR_ENOMEM); - memcpy (cr->sig_val.value, s, n); - cr->sig_val.valuelen = n; - s += n; - if ( *s != ')') - return gpg_error (GPG_ERR_UNKNOWN_SEXP); /* but may also be an invalid one */ - s++; - /* fixme: end loop over parameters */ /* we need 2 closing parenthesis */ if ( *s != ')' || s[1] != ')') -- 2.14.5 From dgouttegattat at incenp.org Fri Nov 16 02:27:37 2018 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Fri, 16 Nov 2018 01:27:37 +0000 Subject: [PATCH gnupg 1/2] sm: Support generation of card-based ECDSA CSR. In-Reply-To: <20181116012738.23296-1-dgouttegattat@incenp.org> References: <20181116012738.23296-1-dgouttegattat@incenp.org> Message-ID: <20181116012738.23296-2-dgouttegattat@incenp.org> * sm/call-agent.c (gpgsm_scd_pksign): Identify type of signing key and format resulting S-expression accordingly. * sm/misc.c (transform_sigval): Support ECDSA signatures. -- Current GpgSM implementation assumes card-based keys are RSA keys. This patch introduces support for ECDSA keys. By itself this patch is not sufficient, we also need support from libksba. GnuPG-bug-id: 4092 Signed-off-by: Damien Goutte-Gattat --- sm/call-agent.c | 57 +++++++++++++++++++++++++++++++------------ sm/misc.c | 75 +++++++++++++++++++++++++++++++++++++++++++-------------- 2 files changed, 98 insertions(+), 34 deletions(-) diff --git a/sm/call-agent.c b/sm/call-agent.c index 20d879fa4..6ac715fab 100644 --- a/sm/call-agent.c +++ b/sm/call-agent.c @@ -334,7 +334,7 @@ gpgsm_scd_pksign (ctrl_t ctrl, const char *keyid, const char *desc, unsigned char *digest, size_t digestlen, int digestalgo, unsigned char **r_buf, size_t *r_buflen ) { - int rc, i; + int rc, i, pkalgo; char *p, line[ASSUAN_LINELENGTH]; membuf_t data; size_t len; @@ -342,6 +342,7 @@ gpgsm_scd_pksign (ctrl_t ctrl, const char *keyid, const char *desc, unsigned char *sigbuf; size_t sigbuflen; struct default_inq_parm_s inq_parm; + gcry_sexp_t sig; (void)desc; @@ -366,6 +367,23 @@ gpgsm_scd_pksign (ctrl_t ctrl, const char *keyid, const char *desc, if (digestlen*2 + 50 > DIM(line)) return gpg_error (GPG_ERR_GENERAL); + /* Get the key type from the scdaemon. */ + snprintf (line, DIM(line), "SCD READKEY %s", keyid); + init_membuf (&data, 1024); + rc = assuan_transact (agent_ctx, line, + put_membuf_cb, &data, NULL, NULL, NULL, NULL); + if (rc) + { + xfree (get_membuf (&data, &len)); + return rc; + } + + p = get_membuf (&data, &len); + pkalgo = get_pk_algo_from_canon_sexp (p, len); + xfree (p); + if (!pkalgo) + return gpg_error (GPG_ERR_WRONG_PUBKEY_ALGO); + p = stpcpy (line, "SCD SETDATA " ); for (i=0; i < digestlen ; i++, p += 2 ) sprintf (p, "%02X", digest[i]); @@ -386,24 +404,31 @@ gpgsm_scd_pksign (ctrl_t ctrl, const char *keyid, const char *desc, } sigbuf = get_membuf (&data, &sigbuflen); - /* Create an S-expression from it which is formatted like this: - "(7:sig-val(3:rsa(1:sSIGBUFLEN:SIGBUF)))" Fixme: If a card ever - creates non-RSA keys we need to change things. */ - *r_buflen = 21 + 11 + sigbuflen + 4; - p = xtrymalloc (*r_buflen); - *r_buf = (unsigned char*)p; - if (!p) + switch(pkalgo) { - xfree (sigbuf); - return 0; + case GCRY_PK_RSA: + rc = gcry_sexp_build (&sig, NULL, "(sig-val(rsa(s%b)))", + sigbuflen, sigbuf); + break; + + case GCRY_PK_ECC: + rc = gcry_sexp_build (&sig, NULL, "(sig-val(ecdsa(r%b)(s%b)))", + sigbuflen/2, sigbuf, + sigbuflen/2, sigbuf + sigbuflen/2); + break; + + default: + rc = gpg_error (GPG_ERR_WRONG_PUBKEY_ALGO); + break; } - p = stpcpy (p, "(7:sig-val(3:rsa(1:s" ); - sprintf (p, "%u:", (unsigned int)sigbuflen); - p += strlen (p); - memcpy (p, sigbuf, sigbuflen); - p += sigbuflen; - strcpy (p, ")))"); xfree (sigbuf); + if (rc) + return rc; + + rc = make_canon_sexp (sig, r_buf, r_buflen); + gcry_sexp_release (sig); + if (rc) + return rc; assert (gcry_sexp_canon_len (*r_buf, *r_buflen, NULL, NULL)); return 0; diff --git a/sm/misc.c b/sm/misc.c index 6d047763b..9bf528513 100644 --- a/sm/misc.c +++ b/sm/misc.c @@ -109,13 +109,16 @@ transform_sigval (const unsigned char *sigval, size_t sigvallen, int mdalgo, gpg_error_t err; const unsigned char *buf, *tok; size_t buflen, toklen; - int depth, last_depth1, last_depth2; + int depth, last_depth1, last_depth2, pkalgo; int is_pubkey = 0; - const unsigned char *rsa_s = NULL; - size_t rsa_s_len = 0; + const unsigned char *rsa_s, *ecc_r, *ecc_s; + size_t rsa_s_len, ecc_r_len, ecc_s_len; const char *oid; gcry_sexp_t sexp; + rsa_s = ecc_r = ecc_s = NULL; + rsa_s_len = ecc_r_len = ecc_s_len = 0; + *r_newsigval = NULL; if (r_newsigvallen) *r_newsigvallen = 0; @@ -137,7 +140,13 @@ transform_sigval (const unsigned char *sigval, size_t sigvallen, int mdalgo, return err; if ((err = parse_sexp (&buf, &buflen, &depth, &tok, &toklen))) return err; - if (!tok || toklen != 3 || memcmp ("rsa", tok, toklen)) + if (!tok) + return gpg_error (GPG_ERR_WRONG_PUBKEY_ALGO); + if (toklen == 3 && !memcmp ("rsa", tok, 3)) + pkalgo = GCRY_PK_RSA; + else if (toklen == 5 && !memcmp ("ecdsa", tok, 5)) + pkalgo = GCRY_PK_ECC; + else return gpg_error (GPG_ERR_WRONG_PUBKEY_ALGO); last_depth1 = depth; @@ -150,16 +159,27 @@ transform_sigval (const unsigned char *sigval, size_t sigvallen, int mdalgo, return err; if (tok && toklen == 1) { - const unsigned char **mpi; - size_t *mpi_len; + const unsigned char **mpi = NULL; + size_t *mpi_len = NULL; switch (*tok) { - case 's': mpi = &rsa_s; mpi_len = &rsa_s_len; break; + case 's': + if (pkalgo == GCRY_PK_RSA) + { + mpi = &rsa_s; + mpi_len = &rsa_s_len; + } + else if (pkalgo == GCRY_PK_ECC) + { + mpi = &ecc_s; + mpi_len = &ecc_s_len; + } + break; + + case 'r': mpi = &ecc_r; mpi_len = &ecc_r_len; break; default: mpi = NULL; mpi_len = NULL; break; } - if (mpi && *mpi) - return gpg_error (GPG_ERR_DUP_VALUE); if ((err = parse_sexp (&buf, &buflen, &depth, &tok, &toklen))) return err; @@ -182,33 +202,52 @@ transform_sigval (const unsigned char *sigval, size_t sigvallen, int mdalgo, return err; /* Map the hash algorithm to an OID. */ - switch (mdalgo) + switch (mdalgo | (pkalgo << 8)) { - case GCRY_MD_SHA1: + case GCRY_MD_SHA1 | (GCRY_PK_RSA << 8): oid = "1.2.840.113549.1.1.5"; /* sha1WithRSAEncryption */ break; - case GCRY_MD_SHA256: + case GCRY_MD_SHA256 | (GCRY_PK_RSA << 8): oid = "1.2.840.113549.1.1.11"; /* sha256WithRSAEncryption */ break; - case GCRY_MD_SHA384: + case GCRY_MD_SHA384 | (GCRY_PK_RSA << 8): oid = "1.2.840.113549.1.1.12"; /* sha384WithRSAEncryption */ break; - case GCRY_MD_SHA512: + case GCRY_MD_SHA512 | (GCRY_PK_RSA << 8): oid = "1.2.840.113549.1.1.13"; /* sha512WithRSAEncryption */ break; + case GCRY_MD_SHA224 | (GCRY_PK_ECC << 8): + oid = "1.2.840.10045.4.3.1"; /* ecdsa-with-sha224 */ + break; + + case GCRY_MD_SHA256 | (GCRY_PK_ECC << 8): + oid = "1.2.840.10045.4.3.2"; /* ecdsa-with-sha256 */ + break; + + case GCRY_MD_SHA384 | (GCRY_PK_ECC << 8): + oid = "1.2.840.10045.4.3.3"; /* ecdsa-with-sha384 */ + break; + + case GCRY_MD_SHA512 | (GCRY_PK_ECC << 8): + oid = "1.2.840.10045.4.3.4"; /* ecdsa-with-sha512 */ + break; + default: return gpg_error (GPG_ERR_DIGEST_ALGO); } - if (rsa_s && !is_pubkey) - err = gcry_sexp_build (&sexp, NULL, "(sig-val(%s(s%b)))", - oid, (int)rsa_s_len, rsa_s); - else + if (is_pubkey) err = gcry_sexp_build (&sexp, NULL, "(sig-val(%s))", oid); + else if (pkalgo == GCRY_PK_RSA) + err = gcry_sexp_build (&sexp, NULL, "(sig-val(%s(s%b)))", oid, + (int)rsa_s_len, rsa_s); + else if (pkalgo == GCRY_PK_ECC) + err = gcry_sexp_build (&sexp, NULL, "(sig-val(%s(r%b)(s%b)))", oid, + (int)ecc_r_len, ecc_r, (int)ecc_s_len, ecc_s); if (err) return err; err = make_canon_sexp (sexp, r_newsigval, r_newsigvallen); -- 2.14.5 From dgouttegattat at incenp.org Fri Nov 16 02:27:36 2018 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Fri, 16 Nov 2018 01:27:36 +0000 Subject: [PATCH gnupg+libksba 0/2] Fix CSR generation from card-based ECDSA keys. Message-ID: <20181116012738.23296-1-dgouttegattat@incenp.org> Hi GnuPG folks, The following patchset intends to fix the generation of CSR from a card-based ECDSA key (e.g., a key stored on a Gnuk token, or any other device compliant with version 3+ of the OpenPGP Card specification). Currently, when generating a CSR GpgSM assumes a card-based key can only be a RSA key, and the resulting CSR therefore has an improper signature value [1]. The first patch (against gnupg) makes GpgSM build a 'sig-val' S-expression corresponding to the actual type of the signature. The second patch (against libksba) ensures that libksba can generate a CSR whose signature comprises several values (as is the case for ECDSA signatures). (Ultimately the goal would be to make Scute support EdDSA certificates for client authentication; this is currently not possible [2] but supporting ECDSA in GpgSM is a first step.) Comments welcome. Cheers, Damien [1] https://dev.gnupg.org/T4092 [2] https://dev.gnupg.org/T4013 From dctucker at github.com Sat Nov 17 01:28:42 2018 From: dctucker at github.com (Casey Tucker) Date: Fri, 16 Nov 2018 16:28:42 -0800 Subject: DCO for dctucker Message-ID: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: message.sig Type: application/octet-stream Size: 1004 bytes Desc: not available URL: From dctucker at github.com Sat Nov 17 01:57:13 2018 From: dctucker at github.com (Casey Tucker) Date: Fri, 16 Nov 2018 16:57:13 -0800 Subject: patch: minimize calls to close() in spawn by calling poll() Message-ID: Hello, Posting this patch to the mailing list per jeroen's instructions. # Problem Statement When running GPGME within Docker, the maximum number of FDs may be set higher than a sane and reasonable values for its specific use-case, causing many close calls to be issued, introducing a major slowdown in performance of any calls to the `gpg` binary. # Proposed Solution This PR attempts to mitigate the problem by calling `poll` on the entire range of file descriptors before issuing `close` calls to each file descriptor. This limits the number of close calls made to the number of active file descriptors in the current process. It also includes a minor FIXME. ## Performance before and after This graph shows the performance of an application signing and then decrypting a few kilobytes of data. https://user-images.githubusercontent.com/772810/48650469-0ce7d700-e9ab-11e8-84fd-5e3f6b619220.png # The patch https://patch-diff.githubusercontent.com/raw/gpg/gpgme/pull/1.patch -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Sun Nov 18 12:42:38 2018 From: wk at gnupg.org (Werner Koch) Date: Sun, 18 Nov 2018 12:42:38 +0100 Subject: patch: minimize calls to close() in spawn by calling poll() In-Reply-To: (Casey Tucker's message of "Fri, 16 Nov 2018 16:57:13 -0800") References: Message-ID: <87a7m6ehn5.fsf@wheatstone.g10code.de> On Sat, 17 Nov 2018 01:57, dctucker at github.com said: > When running GPGME within Docker, the maximum number of FDs may be set > higher than a sane and reasonable values for its specific use-case, causing > many close calls to be issued, introducing a major slowdown in performance Have you investigated why get_max_fd does not work for you. On Linux that function is is used to detect the highest used file descriptor by reading /proc/self/fd/. Or is your application really using that many fds? Is is guaranteed that poll(3) does not allocate memory or other things which may take a lock? Minor nitpicks: The code assumes that poll is available. It should also not used TRACE because that may allocate memory and thus can lead to a deadlock. Shalom-Salam, Werner -- 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 jwilk at jwilk.net Sun Nov 18 13:51:35 2018 From: jwilk at jwilk.net (Jakub Wilk) Date: Sun, 18 Nov 2018 13:51:35 +0100 Subject: patch: minimize calls to close() in spawn by calling poll() In-Reply-To: <87a7m6ehn5.fsf@wheatstone.g10code.de> References: <87a7m6ehn5.fsf@wheatstone.g10code.de> Message-ID: <20181118125135.xzhtwduvhnzal6sf@jwilk.net> * Werner Koch , 2018-11-18, 12:42: >On Sat, 17 Nov 2018 01:57, dctucker at github.com said: >>When running GPGME within Docker, the maximum number of FDs may be set >>higher than a sane and reasonable values for its specific use-case, >>causing many close calls to be issued, introducing a major slowdown in >>performance > >Have you investigated why get_max_fd does not work for you. On Linux >that function is is used to detect the highest used file descriptor by >reading /proc/self/fd/. Or is your application really using that many >fds? FWIW, the parent of Casey's commit is fff2049c1bc7 (from 2014...), which didn't have this /proc/self/fd thing. Huh? >Is is guaranteed that poll(3) does not allocate memory or other things >which may take a lock? Yes, poll() is async-singal-safe. -- Jakub Wilk From dctucker at github.com Sun Nov 18 20:49:01 2018 From: dctucker at github.com (Casey Tucker) Date: Sun, 18 Nov 2018 11:49:01 -0800 Subject: patch: minimize calls to close() in spawn by calling poll() In-Reply-To: <20181118125135.xzhtwduvhnzal6sf@jwilk.net> References: <87a7m6ehn5.fsf@wheatstone.g10code.de> <20181118125135.xzhtwduvhnzal6sf@jwilk.net> Message-ID: > FWIW, the parent of Casey's commit is fff2049c1bc7 (from 2014...), which > didn't have this /proc/self/fd thing. Huh? Thank you for pointing this out. Since the default branch on the github mirror is set to `bjk/master`, I erroneously assumed it was the latest and greatest. I'll target `master` in the next patch. > Have you investigated why get_max_fd does not work for you. On Linux > that function is is used to detect the highest used file descriptor by > reading /proc/self/fd/. Or is your application really using that many > fds? In our application, we are using an older version of GPGME, version 1.9 by way of ueno/ruby-gpgme. I will attempt to backport the newer `get_max_fds` code to improve performance. We did verify that the application is not generating a high number of file descriptors by running perf against GPGME tests, ruby-gpgme tests, and our applicaton's tests, and seeing a similarly high number of close calls running. > Minor nitpicks: The code assumes that poll is available. It should also > not used TRACE because that may allocate memory and thus can lead to a > deadlock. poll() is available since Linux 2.1.23; what is the preferred macro to determine whether to use poll(); should we include linux/version.h if available and check `LINUX_VERSION_CODE >= KERNEL_VERSION(2,1,23)`? I can remove the TRACE. From wk at gnupg.org Mon Nov 19 08:56:50 2018 From: wk at gnupg.org (Werner Koch) Date: Mon, 19 Nov 2018 08:56:50 +0100 Subject: patch: minimize calls to close() in spawn by calling poll() In-Reply-To: (Casey Tucker's message of "Sun, 18 Nov 2018 11:49:01 -0800") References: <87a7m6ehn5.fsf@wheatstone.g10code.de> <20181118125135.xzhtwduvhnzal6sf@jwilk.net> Message-ID: <87in0tcxfh.fsf@wheatstone.g10code.de> On Sun, 18 Nov 2018 20:49, dctucker at github.com said: > Thank you for pointing this out. Since the default branch on the > github mirror is set to `bjk/master`, I erroneously assumed it was the > latest and greatest. I'll target `master` in the next patch. Please do no use an arbitrary mirror but use git.gnupg.org or our own mirror at dev.gnupg.org. > poll() is available since Linux 2.1.23; what is the preferred macro to GPGME is not Linux specific but needs to be build on all POSIX platforms as well as Windows Vista and newer. Shalom-Salam, Werner -- 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 bela at becker.rocks Thu Nov 22 17:09:58 2018 From: bela at becker.rocks (Becker =?ISO-8859-1?Q?B=E9la?=) Date: Thu, 22 Nov 2018 17:09:58 +0100 Subject: [PATCH] poldi: fail immediately when PIN input is too short In-Reply-To: <20181114014434.22676-1-bela@becker.rocks> References: <20181114014434.22676-1-bela@becker.rocks> Message-ID: <1760501.LXJhRv8uoP@longitude> Is this interesting to anyone? I've been using poldi with this patch for the past weeks with only minor unrelated annoyances, but without this patch the computer can easily become unusable. Would someone using poldi with a display manager that is not sddm give this patch a try? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From ben at adversary.org Thu Nov 22 20:12:09 2018 From: ben at adversary.org (Ben McGinnes) Date: Fri, 23 Nov 2018 06:12:09 +1100 Subject: python GPGME bindings and key signatures In-Reply-To: References: Message-ID: <20181122191209.wror2fokmqdfgz45@adversary.org> On Mon, Nov 05, 2018 at 12:14:45PM +0100, Tobias Mueller wrote: > Hi, > > # With gpgme 1.9 we can simply do: > # keys = list(ctx.keylist(key.fpr), mode=mode) A minor correction of a typo here, that last line should be: keys = list(ctx.keylist(key.fpr, mode=mode)) Then the signature data will be in accessible via things like this: for key in keys: for uid in key.uids: for sig in uid.signatures: print(sig.keyid, sig.uid, sig.timestamp) And so on. Also, this needs more documentation, soI'll add it to the HOWTO, thanks for the reminder. 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 albrecht.dress at arcor.de Sun Nov 25 19:36:07 2018 From: albrecht.dress at arcor.de (Albrecht =?iso-8859-1?b?RHJl3w==?=) Date: Sun, 25 Nov 2018 19:36:07 +0100 Subject: git.gnupg.org certificate expired Message-ID: ?just to let you know? ---8<-------------------------------------------------------- git.gnupg.org verwendet ein ung?ltiges Sicherheitszertifikat. Das Zertifikat ist am 24. November 2018, 07:14:09 GMT+1 abgelaufen. Die aktuelle Zeit ist 25. November 2018, 19:31. Fehlercode: SEC_ERROR_EXPIRED_CERTIFICATE ---8<-------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From alon.barlev at gmail.com Sun Nov 25 19:45:36 2018 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Sun, 25 Nov 2018 20:45:36 +0200 Subject: [PATCH Libgpg-error] gpg-error.m4: support pkg-config In-Reply-To: References: <20181011182720.11991-1-alon.barlev@gmail.com> <871s8vptg1.fsf@wheatstone.g10code.de> <87efcokjn6.fsf@wheatstone.g10code.de> <8736snt3kn.fsf@fsij.org> <87d0rqod6v.fsf@fsij.org> Message-ID: I am declaring this thread as MIA [Missing in action]. I am very sad that we cannot even properly discuss this. On Tue, Nov 13, 2018 at 5:06 PM Alon Bar-Lev wrote: > > Hello Werner, > Please don't let this thread die. > I will appreciate if we can come up with some solution that will be acceptable. > Thanks! > Alon > > On Wed, Oct 31, 2018 at 8:14 AM NIIBE Yutaka wrote: > > > > Alon Bar-Lev wrote: > > > This thread is about modifying the build so that it will have an > > > option to use pkg-config instead of config scripts if downstream > > > maintainer chooses to. > > > > I know. > > > > I don't argue this point. > > > > I pointed out that the important technical things (no use of > > --with-*-prefix/SYSROOT with *-config scripts, to build GnuPG and its > > related libraries) can be already achieved with no new dependency to > > pkg-config. (I mean, gnupg in master. It's not yet applied > > to stable branch.) > > > > My point is, people don't need to use libraries' *-config scripts any > > more, but only a single gpgrt-config script now. > > > > In the past, there are *-config script from libraries, and for some > > build environment, there are even prefixed versions for supported hosts, > > like i686-linux-gnu-gpg-error-config and sh4-linux-gnu-libassuan-config. > > Now, we only have a gpgrt-config. > > > > Still *-config script in each library is not removed, so that it can > > still support existing software, but it's no need any more when we build > > gnupg master. > > -- From gniibe at fsij.org Tue Nov 27 05:01:41 2018 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 27 Nov 2018 13:01:41 +0900 Subject: [PATCH] poldi: fail immediately when PIN input is too short In-Reply-To: <1760501.LXJhRv8uoP@longitude> References: <20181114014434.22676-1-bela@becker.rocks> <1760501.LXJhRv8uoP@longitude> Message-ID: <87a7lvp3ru.fsf@iwagami.gniibe.org> Becker B?la wrote: > without this patch the computer can easily become unusable. In my opinion, it is SDDM which should be fixed. It seems that SDDM doesn't support pam_conv(3), that is considered simply wrong (for Poldi, at least). > poldi with a display manager that is not sddm give this patch a try? I don't use Poldi usually, but I tried your patch. I'm using lightdm. With your patch, it doesn't display "PIN too short" message (since it returns an error). This is severe regression, I suppose. -- From dkg at fifthhorseman.net Wed Nov 28 07:25:25 2018 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 28 Nov 2018 01:25:25 -0500 Subject: [GPGME PATCH] python: simplify Context.decrypt() Message-ID: <20181128062525.5649-1-dkg@fifthhorseman.net> In the course of trying to address https://dev.gnupg.org/T4271, i discovered that gpg.Context.decrypt() has a bit of superfluous code. This changeset is intended to simplify the code without making any functional changes. Signed-off-by: Daniel Kahn Gillmor --- lang/python/src/core.py | 29 ++--------------------------- 1 file changed, 2 insertions(+), 27 deletions(-) diff --git a/lang/python/src/core.py b/lang/python/src/core.py index 6e925925..f7e843f1 100644 --- a/lang/python/src/core.py +++ b/lang/python/src/core.py @@ -386,13 +386,9 @@ class Context(GpgmeWrapper): if verify is False: verify = True sink_result = True - else: - pass elif isinstance(verify, list) is True: if len(verify) > 0: verify_sigs = True - else: - pass else: verify = True self.op_decrypt_verify(ciphertext, plaintext) @@ -447,29 +443,8 @@ class Context(GpgmeWrapper): if not ok: missing.append(key) if missing: - try: - raise errors.MissingSignatures(verify_result, missing, - results=results) - except errors.MissingSignatures as e: - raise e - # mse = e - # mserr = "gpg.errors.MissingSignatures:" - # print(mserr, miss_e, "\n") - # # The full details can then be found in mse.results, - # # mse.result, mse.missing if necessary. - # mse_list = [] - # msp = "Missing signatures from: \n".format() - # print(msp) - # for key in mse.missing: - # mse_list.append(key.fpr) - # msl = [] - # msl.append(key.fpr) - # for user in key.uids: - # msl.append(user.name) - # msl.append(user.email) - # # msl.append(user.uid) - # print(" ".join(msl)) - # raise mse + raise errors.MissingSignatures(verify_result, missing, + results=results) return results -- 2.19.2