From jestedfa at microsoft.com Thu Dec 7 16:52:12 2017 From: jestedfa at microsoft.com (Jeffrey Stedfast) Date: Thu, 7 Dec 2017 15:52:12 +0000 Subject: GnuPG 2.1.x and 2.2.x keyring formats Message-ID: Hi all, I know that starting with GnuPG 2.1.x, the use of pubring.gpg and secring.gpg changed and gpg now uses private-keys-v1.d/ to store keys (or is it only private keys?). I guess I have a couple of questions: 1. What is the file format of the *.key files in the private-keys-v1.d directory? 2. How are these files named? Does the file name correspond with a fingerprint / key id? 3. Does gpg still use pubring.gpg? I'm asking these questions because I have a C# email library that uses Bouncy Castle for OpenPGP support that I'm trying to make interoperable with GnuPG as much as I can. Any information you can share with me so that I can make my library work with GnuPG 2.2 would be fantastic. Thanks! Jeff From wk at gnupg.org Thu Dec 7 19:57:48 2017 From: wk at gnupg.org (Werner Koch) Date: Thu, 07 Dec 2017 19:57:48 +0100 Subject: GnuPG 2.1.x and 2.2.x keyring formats In-Reply-To: (Jeffrey Stedfast via Gnupg-devel's message of "Thu, 7 Dec 2017 15:52:12 +0000") References: Message-ID: <87374mnz6b.fsf@wheatstone.g10code.de> Hi Jeff, On Thu, 7 Dec 2017 16:52, gnupg-devel at gnupg.org said: > 1. What is the file format of the *.key files in the private-keys-v1.d directory? See gnupg/agent/keyformat.txt (also copied below). But note that this is a private property of GnuPG and you should take care when accessing them directky. > 2. How are these files named? Does the file name correspond with a > fingerprint / key id? this is the the keygrip with the suffix ".key". To view the keygrip, use gpg --with-colons -K and grep for the "grp" records. Such records follow after "sec", "ssb", "pub", or "sub" records. To get them in a huma readable format use gpg --with-keygrip -K > 3. Does gpg still use pubring.gpg? As long as there is no pubring.kbx and existing pubring.gpg will be used. If you have a pubring.kbx from gnupg 2.0 (gpgsm always used this) but that one has no OpenPGP key and existing pubring.gpg is also used. kbxutil pubring.kbx | head shows a flag line which indicates whether an openPGP key exists. > I'm asking these questions because I have a C# email library that uses Bouncy Castle for OpenPGP support that I'm trying to make interoperable with GnuPG as much as I can. Hmmm. I can't give an offical guarantee that the format will always be the same. The keygrip is computed by a function in Libgcrypt. Shalom-Salam, Werner ========== Some notes on the format of the secret keys used with gpg-agent. * Location of keys The secret keys[1] are stored on a per file basis in a directory below the ~/.gnupg home directory. This directory is named private-keys-v1.d and should have permissions 700. The secret keys are stored in files with a name matching the hexadecimal representation of the keygrip[2] and suffixed with ".key". * Extended Private Key Format GnuPG 2.3+ will use a new format to store private keys that is both more flexible and easier to read and edit by human beings. The new format stores name,value-pairs using the common mail and http header convention. Example (here indented with two spaces): Description: Key to sign all GnuPG released tarballs. The key is actually stored on a smart card. Use-for-ssh: yes OpenSSH-cert: long base64 encoded string wrapped so that this key file can be easily edited with a standard editor. Key: (shadowed-private-key (rsa (n #00AA1AD2A55FD8C8FDE9E1941772D9CC903FA43B268CB1B5A1BAFDC900 2961D8AEA153424DC851EF13B83AC64FBE365C59DC1BD3E83017C90D4365B4 83E02859FC13DB5842A00E969480DB96CE6F7D1C03600392B8E08EF0C01FC7 19F9F9086B25AD39B4F1C2A2DF3E2BE317110CFFF21D4A11455508FE407997 601260816C8422297C0637BB291C3A079B9CB38A92CE9E551F80AA0EBF4F0E 72C3F250461E4D31F23A7087857FC8438324A013634563D34EFDDCBF2EA80D F9662C9CCD4BEF2522D8BDFED24CEF78DC6B309317407EAC576D889F88ADA0 8C4FFB480981FB68C5C6CA27503381D41018E6CDC52AAAE46B166BDC10637A E186A02BA2497FDC5D1221#) (e #00010001#) (shadowed t1-v1 (#D2760001240102000005000011730000# OPENPGP.1) ))) GnuPG 2.2 is able to read and update keys using the new format, but will not create new files using the new format. Furthermore, it only makes use of the value stored under the name 'Key:'. Keys in the extended format can be recognized by looking at the first byte of the file. If it starts with a '(' it is a naked S-expression, otherwise it is a key in extended format. ** Names A name must start with a letter and end with a colon. Valid characters are all ASCII letters, numbers and the hyphen. Comparison of names is done case insensitively. Names may be used several times to represent an array of values. The name "Key:" is special in that it may occur only once and the associated value holds the actual S-expression with the cryptographic key. The S-expression is formatted using the 'Advanced Format' (GCRYSEXP_FMT_ADVANCED) that avoids non-printable characters so that the file can be easily inspected and edited. See section 'Private Key Format' below for details. ** Values Values are UTF-8 encoded strings. Values can be wrapped at any point, and continued in the next line indicated by leading whitespace. A continuation line with one leading space does not introduce a blank so that the lines can be effectively concatenated. A blank line as part of a continuation line encodes a newline. ** Comments Lines containing only whitespace, and lines starting with whitespace followed by '#' are considered to be comments and are ignored. * Private Key Format ** Unprotected Private Key Format The content of the file is an S-Expression like the ones used with Libgcrypt. Here is an example of an unprotected file: (private-key (rsa (n #00e0ce9..[some bytes not shown]..51#) (e #010001#) (d #046129F..[some bytes not shown]..81#) (p #00e861b..[some bytes not shown]..f1#) (q #00f7a7c..[some bytes not shown]..61#) (u #304559a..[some bytes not shown]..9b#) ) (created-at timestamp) (uri http://foo.bar x-foo:whatever_you_want) (comment whatever) ) "comment", "created-at" and "uri" are optional. "comment" is currently used to keep track of ssh key comments. "created-at" is used to keep track of the creation time stamp used with OpenPGP keys; it is optional but required for some operations to calculate the fingerprint of the key. This timestamp should be a string with the number of seconds since Epoch or an ISO time string (yyyymmddThhmmss). ** Protected Private Key Format A protected key is like this: (protected-private-key (rsa (n #00e0ce9..[some bytes not shown]..51#) (e #010001#) (protected mode (parms) encrypted_octet_string) (protected-at ) ) (uri http://foo.bar x-foo:whatever_you_want) (comment whatever) ) In this scheme the encrypted_octet_string is encrypted according to the algorithm described after the keyword protected; most protection algorithms need some parameters, which are given in a list before the encrypted_octet_string. The result of the decryption process is a list of the secret key parameters. The protected-at expression is optional; the isotimestamp is 15 bytes long (e.g. "19610711T172000"). The currently defined protection modes are: *** openpgp-s2k3-sha1-aes-cbc This describes an algorithm using AES in CBC mode for encryption, SHA-1 for integrity protection and the String to Key algorithm 3 from OpenPGP (rfc4880). Example: (protected openpgp-s2k3-sha1-aes-cbc ((sha1 16byte_salt no_of_iterations) 16byte_iv) encrypted_octet_string ) The encrypted_octet string should yield this S-Exp (in canonical representation) after decryption: ( ( (d #046129F..[some bytes not shown]..81#) (p #00e861b..[some bytes not shown]..f1#) (q #00f7a7c..[some bytes not shown]..61#) (u #304559a..[some bytes not shown]..9b#) ) (hash sha1 #...[hashvalue]...#) ) For padding reasons, random bytes are appended to this list - they can easily be stripped by looking for the end of the list. The hash is calculated on the concatenation of the public key and secret key parameter lists: i.e. it is required to hash the concatenation of these 6 canonical encoded lists for RSA, including the parenthesis, the algorithm keyword and (if used) the protected-at list. (rsa (n #00e0ce9..[some bytes not shown]..51#) (e #010001#) (d #046129F..[some bytes not shown]..81#) (p #00e861b..[some bytes not shown]..f1#) (q #00f7a7c..[some bytes not shown]..61#) (u #304559a..[some bytes not shown]..9b#) (protected-at "18950523T000000") ) After decryption the hash must be recalculated and compared against the stored one - If they don't match the integrity of the key is not given. *** openpgp-s2k3-ocb-aes This describes an algorithm using AES-128 in OCB mode, a nonce of 96 bit, a taglen of 128 bit, and the String to Key algorithm 3 from OpenPGP (rfc4880). Example: (protected openpgp-s2k3-ocb-aes ((sha1 16byte_salt no_of_iterations) 12byte_nonce) encrypted_octet_string ) The encrypted_octet string should yield this S-Exp (in canonical representation) after decryption: ( ( (d #046129F..[some bytes not shown]..81#) (p #00e861b..[some bytes not shown]..f1#) (q #00f7a7c..[some bytes not shown]..61#) (u #304559a..[some bytes not shown]..9b#) ) ) For padding reasons, random bytes may be appended to this list - they can easily be stripped by looking for the end of the list. The associated data required for this protection mode is the list formiing the public key parameters. For the above example this is is this canonical encoded S-expression: (rsa (n #00e0ce9..[some bytes not shown]..51#) (e #010001#) (protected-at "18950523T000000") ) *** openpgp-native This is a wrapper around the OpenPGP Private Key Transport format which resembles the standard OpenPGP format and allows the use of an existing key without re-encrypting to the default protection format. Example: (protected openpgp-native (openpgp-private-key (version V) (algo PUBKEYALGO) (skey _ P1 _ P2 _ P3 ... e PN) (csum n) (protection PROTTYPE PROTALGO IV S2KMODE S2KHASH S2KSALT S2KCOUNT))) Note that the public key paramaters in SKEY are duplicated and should be identical to their copies in the standard parameter elements. Here is an example of an entire protected private key using this format: (protected-private-key (rsa (n #00e0ce9..[some bytes not shown]..51#) (e #010001#) (protected openpgp-native (openpgp-private-key (version 4) (algo rsa) (skey _ #00e0ce9..[some bytes not shown]..51# _ #010001# e #.........................#) (protection sha1 aes #aabbccddeeff00112233445566778899# 3 sha1 #2596f93e85f41e53# 3:190)))) (uri http://foo.bar x-foo:whatever_you_want) (comment whatever)) ** Shadowed Private Key Format To keep track of keys stored on IC cards we use a third format for private kyes which are called shadow keys as they are only a reference to keys stored on a token: (shadowed-private-key (rsa (n #00e0ce9..[some bytes not shown]..51#) (e #010001#) (shadowed protocol (info)) ) (uri http://foo.bar x-foo:whatever_you_want) (comment whatever) ) The currently used protocol is "ti-v1" (token info version 1). The second list with the information has this layout: (card_serial_number id_string_of_key fixed_pin_length) FIXED_PIN_LENGTH is optional. It can be used to store the length of the PIN; a value of 0 indicates that this information is not available. The rationale for this field is that some pinpad equipped readers don't allow passing a variable length PIN. More items may be added to the list. ** OpenPGP Private Key Transfer Format This format is used to transfer keys between gpg and gpg-agent. (openpgp-private-key (version V) (algo PUBKEYALGO) (curve CURVENAME) (skey _ P1 _ P2 _ P3 ... e PN) (csum n) (protection PROTTYPE PROTALGO IV S2KMODE S2KHASH S2KSALT S2KCOUNT)) * V is the packet version number (3 or 4). * PUBKEYALGO is a Libgcrypt algo name * CURVENAME is the name of the curve - only used with ECC. * P1 .. PN are the parameters; the public parameters are never encrypted the secrect key parameters are encrypted if the "protection" list is given. To make this more explicit each parameter is preceded by a flag "_" for cleartext or "e" for encrypted text. * CSUM is the deprecated 16 bit checksum as defined by OpenPGP. This is an optional element. * If PROTTYPE is "sha1" the new style SHA1 checksum is used if it is "sum" the old 16 bit checksum (above) is used and if it is "none" no protection at all is used. * PROTALGO is a Libgcrypt style cipher algorithm name * IV is the initialization verctor. * S2KMODE is the value from RFC-4880. * S2KHASH is a libgcrypt style hash algorithm identifier. * S2KSALT is the 8 byte salt * S2KCOUNT is the count value from RFC-4880. ** Persistent Passphrase Format Note: That this has not yet been implemented. To allow persistent storage of cached passphrases we use a scheme similar to the private-key storage format. This is a master passphrase format where each file may protect several secrets under one master passphrase. It is possible to have several of those files each protected by a dedicated master passphrase. Clear text keywords allow listing the available protected passphrases. The name of the files with these protected secrets have this form: pw-.dat. STRING may be an arbitrary string, as a default name for the passphrase storage the name "pw-default.dat" is suggested. (protected-shared-secret ((desc descriptive_text) (key [key_1] (keyword_1 keyword_2 keyword_n)) (key [key_2] (keyword_21 keyword_22 keyword_2n)) (key [key_n] (keyword_n1 keyword_n2 keyword_nn)) (protected mode (parms) encrypted_octet_string) (protected-at ) ) ) After decryption the encrypted_octet_string yields this S-expression: ( ( (value key_1 value_1) (value key_2 value_2) (value key_n value_n) ) (hash sha1 #...[hashvalue]...#) ) The "descriptive_text" is displayed with the prompt to enter the unprotection passphrase. KEY_1 to KEY_N are unique identifiers for the shared secret, for example an URI. In case this information should be kept confidential as well, they may not appear in the unprotected part; however they are mandatory in the encrypted_octet_string. The list of keywords is optional. The oder of the "key" lists and the order of the "value" lists mut match, that is the first "key"-list is associated with the first "value" list in the encrypted_octet_string. The protection mode etc. is identical to the protection mode as described for the private key format. list of the secret key parameters. The protected-at expression is optional; the isotimestamp is 15 bytes long (e.g. "19610711T172000"). The "hash" in the encrypted_octet_string is calculated on the concatenation of the key list and value lists: i.e it is required to hash the concatenation of all these lists, including the parenthesis and (if used) the protected-at list. Example: (protected-shared-secret ((desc "List of system passphrases") (key "uid-1002" ("Knuth" "Donald Ervin Knuth")) (key "uid-1001" ("Dijkstra" "Edsgar Wybe Dijkstra")) (key) (protected mode (parms) encrypted_octet_string) (protected-at "20100915T111722") ) ) with "encrypted_octet_string" decoding to: ( ( (value 4:1002 "signal flags at the lock") (value 4:1001 "taocp") (value 1:0 "premature optimization is the root of all evil") ) (hash sha1 #0102030405060708091011121314151617181920#) ) To compute the hash this S-expression (in canoncical format) was hashed: ((desc "List of system passphrases") (key "uid-1002" ("Knuth" "Donald Ervin Knuth")) (key "uid-1001" ("Dijkstra" "Edsgar Wybe Dijkstra")) (key) (value 4:1002 "signal flags at the lock") (value 4:1001 "taocp") (value 1:0 "premature optimization is the root of all evil") (protected-at "20100915T111722") ) * Notes [1] I usually use the terms private and secret key exchangeable but prefer the term secret key because it can be visually be better distinguished From the term public key. [2] The keygrip is a unique identifier for a key pair, it is independent of any protocol, so that the same key can be used with different protocols. PKCS-15 calls this a subjectKeyHash; it can be calculated using Libgcrypt's gcry_pk_get_keygrip (). [3] Even when canonical representation are required we will show the S-expression here in a more readable representation. -- 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 jestedfa at microsoft.com Thu Dec 7 21:03:54 2017 From: jestedfa at microsoft.com (Jeffrey Stedfast) Date: Thu, 7 Dec 2017 20:03:54 +0000 Subject: GnuPG 2.1.x and 2.2.x keyring formats In-Reply-To: <87374mnz6b.fsf@wheatstone.g10code.de> References: <87374mnz6b.fsf@wheatstone.g10code.de> Message-ID: <128150DE-8EB8-4222-90A0-8333928EFDE7@microsoft.com> Hi Werner, Thanks so much for taking the time to respond with such valuable information! Jeff ?On 12/7/17, 2:05 PM, "Werner Koch" wrote: Hi Jeff, On Thu, 7 Dec 2017 16:52, gnupg-devel at gnupg.org said: > 1. What is the file format of the *.key files in the private-keys-v1.d directory? See gnupg/agent/keyformat.txt (also copied below). But note that this is a private property of GnuPG and you should take care when accessing them directky. > 2. How are these files named? Does the file name correspond with a > fingerprint / key id? this is the the keygrip with the suffix ".key". To view the keygrip, use gpg --with-colons -K and grep for the "grp" records. Such records follow after "sec", "ssb", "pub", or "sub" records. To get them in a huma readable format use gpg --with-keygrip -K > 3. Does gpg still use pubring.gpg? As long as there is no pubring.kbx and existing pubring.gpg will be used. If you have a pubring.kbx from gnupg 2.0 (gpgsm always used this) but that one has no OpenPGP key and existing pubring.gpg is also used. kbxutil pubring.kbx | head shows a flag line which indicates whether an openPGP key exists. > I'm asking these questions because I have a C# email library that uses Bouncy Castle for OpenPGP support that I'm trying to make interoperable with GnuPG as much as I can. Hmmm. I can't give an offical guarantee that the format will always be the same. The keygrip is computed by a function in Libgcrypt. Shalom-Salam, Werner From peter at digitalbrains.com Thu Dec 7 21:23:35 2017 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 7 Dec 2017 21:23:35 +0100 Subject: GnuPG 2.1.x and 2.2.x keyring formats In-Reply-To: <87374mnz6b.fsf@wheatstone.g10code.de> References: <87374mnz6b.fsf@wheatstone.g10code.de> Message-ID: <4979cd00-d1bc-85c6-46b7-7eb5e53c8f10@digitalbrains.com> On 07/12/17 19:57, Werner Koch wrote: > * Extended Private Key Format > > [...] > (shadowed t1-v1 > (#D2760001240102000005000011730000# OPENPGP.1) > ))) shadowed tee one dash vee one > ** Shadowed Private Key Format > > [...] > The currently used protocol is "ti-v1" (token info version 1). The > second list with the information has this layout: tee eye dash vee one I'm afraid the former is correct, looking at my own private key files. It looks like a typo has wormed its way into both code and key storage! HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From peter at digitalbrains.com Thu Dec 7 21:29:58 2017 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 7 Dec 2017 21:29:58 +0100 Subject: OT: prof. dr. Dijkstra In-Reply-To: <87374mnz6b.fsf@wheatstone.g10code.de> References: <87374mnz6b.fsf@wheatstone.g10code.de> Message-ID: <5a7fcd5f-5ca9-dd05-0cde-3f0f2a3b4430@digitalbrains.com> On 07/12/17 19:57, Werner Koch wrote: > (key "uid-1001" ("Dijkstra" "Edsgar Wybe Dijkstra")) Mr. Dijkstra is actually called Edsger Wybe, straight-up Frisian names, so as a matter of fact most Dutch people might misspell them as well ;-). Cheers, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Thu Dec 7 21:40:41 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 07 Dec 2017 15:40:41 -0500 Subject: keygrip format [was: Re: GnuPG 2.1.x and 2.2.x keyring formats] In-Reply-To: <87374mnz6b.fsf@wheatstone.g10code.de> References: <87374mnz6b.fsf@wheatstone.g10code.de> Message-ID: <87po7q2rw6.fsf@fifthhorseman.net> On Thu 2017-12-07 19:57:48 +0100, Werner Koch wrote: > On Thu, 7 Dec 2017 16:52, gnupg-devel at gnupg.org said: >> I'm asking these questions because I have a C# email library that >> uses Bouncy Castle for OpenPGP support that I'm trying to make >> interoperable with GnuPG as much as I can. > > Hmmm. I can't give an offical guarantee that the format will always be > the same. The keygrip is computed by a function in Libgcrypt. Can you guarantee that the keygrip will remain stable? Given that gpg-agent addresses the keys by keygrip, for interoperability purposes i think we need to commit to an official guarantee about keygrip calculation, and it ought to be publicly stable. keyformat.txt says: >>> [2] The keygrip is a unique identifier for a key pair, it is >>> independent of any protocol, so that the same key can be used with >>> different protocols. PKCS-15 calls this a subjectKeyHash; it can be >>> calculated using Libgcrypt's gcry_pk_get_keygrip (). But RSA has made it much harder to find copies of the PKCS-15 standard these days, and it hasn't made it through to the IETF yet, afaict. However, it looks like there's a copy here: http://tjscott.net/pki/pkcs/pkcs15.pdf which says: >>>> subjectPublicKeyHash: >>>> >>>> An OCTET STRING which contains the SHA-1 hash of the public key >>>> associated with the private key. In the RSA case, the modulus of the >>>> public key shall be used, and the hash is to be done on the >>>> (network-order or big-endian) integer representation of it. The >>>> hash-algorithm shall be SHA-1. In the case of Elliptic Curves, it is >>>> recommended that the hash be calculated on the x-coordinate of the >>>> public key's ECPoint OCTET STRING. As an alternative, the hash can also >>>> be used as the CommonKeyAttributes.iD. >>>> >>>> NOTE >>>> >>>> This is different from the hash method used e.g. in IETF RFC 2459 >>>> ([32]), but it serves the purpose of being independent of certificate >>>> format ? alternative certificate formats not DER-encoding the public key >>>> has been proposed. Is that worth documenting explicitly? fwiw, RFC 2459 has been superceded (twice!) and RFC 5280 is now the preferred recommendation from the IETF. Its recommendations for generating key identifiers is here: https://tools.ietf.org/html/rfc5280#section-4.2.1.2 it recommends digesting the ASN.1 "BIT STRING subjectPublicKey", which is more than just the public key modulus or the ECPoint X coordinate, and has the advantage that two keys of different formats will not have colliding keygrips. Right? Using the mechanism defined in PKCS-15, what prevents an RSA key from having the same keygrip as an ECC key? --dkg From wk at gnupg.org Thu Dec 7 22:40:19 2017 From: wk at gnupg.org (Werner Koch) Date: Thu, 07 Dec 2017 22:40:19 +0100 Subject: keygrip format In-Reply-To: <87po7q2rw6.fsf@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Thu, 07 Dec 2017 15:40:41 -0500") References: <87374mnz6b.fsf@wheatstone.g10code.de> <87po7q2rw6.fsf@fifthhorseman.net> Message-ID: <87lgiemd30.fsf@wheatstone.g10code.de> On Thu, 7 Dec 2017 21:40, dkg at fifthhorseman.net said: > Can you guarantee that the keygrip will remain stable? Yes, that is part of the Libcrypt ABI and will thus not change. Sorry, I should have put this into a separate paragraph. > Right? Using the mechanism defined in PKCS-15, what prevents an RSA key > from having the same keygrip as an ECC key? The Libgcrypt keygrip is in general different from the PCKS-15 keygrip. With the exception of RSA the Libgcrypt keygrip always includes an identifier for the algorithm. I tried to keep the RSA keygrip similar to the PCKS-15 defined one but: /* Compute a keygrip. [...] PKCS-15 says that for RSA only the modulus should be hashed - however, it is not clear whether this is meant to use the raw bytes (assuming this is an unsigned integer) or whether the DER required 0 should be prefixed. We hash the raw bytes. */ For ECC we hash an s-expression with all curve parameters in a well defined order. For other algorithms we use the standard Libgcrypt s-expression using the parameters in the order given by Libgcrypt's implementation. 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 dkg at fifthhorseman.net Thu Dec 7 23:17:22 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 07 Dec 2017 17:17:22 -0500 Subject: keygrip format In-Reply-To: <87lgiemd30.fsf@wheatstone.g10code.de> References: <87374mnz6b.fsf@wheatstone.g10code.de> <87po7q2rw6.fsf@fifthhorseman.net> <87lgiemd30.fsf@wheatstone.g10code.de> Message-ID: <87609i2nf1.fsf@fifthhorseman.net> On Thu 2017-12-07 22:40:19 +0100, Werner Koch wrote: > The Libgcrypt keygrip is in general different from the PCKS-15 keygrip. > With the exception of RSA the Libgcrypt keygrip always includes an > identifier for the algorithm. What identifier? Is this documented somewhere other than the source code? From what i can see, _gcry_pk_get_keygrip() in cipher/pubkey.c doesn't inject the header directly, and just initializes the digest object and invokes the comp_keygrip member of the pk_spec. And the comp_keygrip member of the rsa pk_spec is compute_keygrip in cipher/rsa.c, which just passes the raw data to the message digest object. > I tried to keep the RSA keygrip similar to the PCKS-15 defined one > but: > > /* Compute a keygrip. [...] > > PKCS-15 says that for RSA only the modulus should be hashed - > however, it is not clear whether this is meant to use the raw bytes > (assuming this is an unsigned integer) or whether the DER required > 0 should be prefixed. We hash the raw bytes. */ OK, so i tried to replicate this for RSA and i failed :( 0 dkg at alice:~$ gpg --with-keygrip --with-key-data --list-keys D238EA65D64C67ED4C3073F28A861B1C7EFD60D9 gpg: please do a --check-trustdb tru:o:1:1511190515:1:3:1:5 pub:q:2048:1:8A861B1C7EFD60D9:1413720402:1609412423::-:::scSC::::::23::0: fpr:::::::::D238EA65D64C67ED4C3073F28A861B1C7EFD60D9: grp:::::::::E56EE6EE5A2FDC3E989DFE49DAF56743E3272833: pkd:0:2048:B493C79928398DA9D99AC0E949FE6EB62F683CB974FFFBFBC01066F5C9A89BD3DC48EAD7C65F36EA943C2B2C865C26C4884FF9EDFDA8C99C855B737D77EEF6B85DBC0CCEC0E900C1F89A6893A2A93E8B31028469B6927CEB2F08687E547C686B0A2F7E50A194FF7AB7637E03DE0912EF7F6E5F1EC37625BD1620CCC2E7A56431E168CDAFBD1D9E61AE47A69A6FA03EF22F844528A710B2392F262B95A3078CF321DC8325F92A5691EF69F34FD0DE0B22C79D29DC87723FCADE463829E8E5F7D196D73D6C9C180F6A6A0DDBF7B9D8F7FA293C36163B12199EF6A1A95CAE4051E3069C522CC6C4A7110F663A5DAD20F66C13A1674D050088208FAE4F33B3AB5103: pkd:1:17:010001: uid:q::::1413720402::D49001903ADA4875E769A87C05F25BD14DD7A7D9::Werner Koch (Release Signing Key)::::::::::0: 0 dkg at alice:~$ the grp: line has the keygrip, and the pkd:0: line is the modulus, right? So, we should be able to compute that in python, but i'm not seeing it, with the raw bytes in either order: In [1]: import hashlib, codecs In [2]: keydata = codecs.decode('B493C79928398DA9D99AC0E949FE6EB62F683CB974FFFBF ...: BC01066F5C9A89BD3DC48EAD7C65F36EA943C2B2C865C26C4884FF9EDFDA8C99C855B737 ...: D77EEF6B85DBC0CCEC0E900C1F89A6893A2A93E8B31028469B6927CEB2F08687E547C686 ...: B0A2F7E50A194FF7AB7637E03DE0912EF7F6E5F1EC37625BD1620CCC2E7A56431E168CDA ...: FBD1D9E61AE47A69A6FA03EF22F844528A710B2392F262B95A3078CF321DC8325F92A569 ...: 1EF69F34FD0DE0B22C79D29DC87723FCADE463829E8E5F7D196D73D6C9C180F6A6A0DDBF ...: 7B9D8F7FA293C36163B12199EF6A1A95CAE4051E3069C522CC6C4A7110F663A5DAD20F66 ...: C13A1674D050088208FAE4F33B3AB5103', 'hex') In [3]: hashlib.sha1(keydata).hexdigest() Out[3]: '805cfd0a15e427ef8345c01ae6657b4de888ea13' In [4]: hashlib.sha1(bytes(reversed(keydata))).hexdigest() Out[4]: '92ab5f591661031b7270edc61119e67faf47382f' neither Out[3] nor Out[4] is 'e56ee6ee5a2fdc3e989dfe49daf56743e3272833', which i'd expect from the grp: line above. What am i doing wrong in python here? > For ECC we hash an s-expression with all curve parameters in a well > defined order. For other algorithms we use the standard Libgcrypt > s-expression using the parameters in the order given by Libgcrypt's > implementation. This sounds like something that needs to be publicly documented if there's any intent to allow other implementations to talk to gpg-agent, or to do anything else which requires knowing the keygrip corresponding to a public key. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From gniibe at fsij.org Fri Dec 8 01:22:25 2017 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 08 Dec 2017 09:22:25 +0900 Subject: GnuPG 2.1.x and 2.2.x keyring formats In-Reply-To: <4979cd00-d1bc-85c6-46b7-7eb5e53c8f10@digitalbrains.com> References: <87374mnz6b.fsf@wheatstone.g10code.de> <4979cd00-d1bc-85c6-46b7-7eb5e53c8f10@digitalbrains.com> Message-ID: <87374mhxvi.fsf@iwagami.gniibe.org> Hello, Thanks for your good catch. Peter Lebbing wrote: > On 07/12/17 19:57, Werner Koch wrote: >> * Extended Private Key Format >> >> [...] >> (shadowed t1-v1 >> (#D2760001240102000005000011730000# OPENPGP.1) >> ))) > > shadowed tee one dash vee one > >> ** Shadowed Private Key Format >> >> [...] >> The currently used protocol is "ti-v1" (token info version 1). The >> second list with the information has this layout: > > tee eye dash vee one > > I'm afraid the former is correct, looking at my own private key files. It looks > like a typo has wormed its way into both code and key storage! The code has been "t1-v1" (tee one dash vee one) from the beginning (even thogh it was not intended), and our conclusion was fixing the documentation. In 2015-04-09: https://lists.gnupg.org/pipermail/gnupg-devel/2015-April/029680.html Fixed in 5c121d444, finally. -- From wk at gnupg.org Fri Dec 8 08:18:16 2017 From: wk at gnupg.org (Werner Koch) Date: Fri, 08 Dec 2017 08:18:16 +0100 Subject: keygrip format In-Reply-To: <87609i2nf1.fsf@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Thu, 07 Dec 2017 17:17:22 -0500") References: <87374mnz6b.fsf@wheatstone.g10code.de> <87po7q2rw6.fsf@fifthhorseman.net> <87lgiemd30.fsf@wheatstone.g10code.de> <87609i2nf1.fsf@fifthhorseman.net> Message-ID: <87609hn0w7.fsf@wheatstone.g10code.de> On Thu, 7 Dec 2017 23:17, dkg at fifthhorseman.net said: > In [2]: keydata = codecs.decode('B493C79928398DA9D99AC0E949FE6EB62F683CB974FFFBF use '00B493...' as per OpenPGP rules. I also added this key to libgcrypt/tests/keygrip.c. 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 dashohoxha at gmail.com Sat Dec 9 15:27:53 2017 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Sat, 9 Dec 2017 15:27:53 +0100 Subject: GSoC 2018 Message-ID: Hi, Are we going to propose any projects for the Google Summer of Code 2018? - https://developers.google.com/open-source/gsoc/timeline - https://www.gnu.org/software/soc-projects/ideas-2017.html - http://lists.gnu.org/archive/html/summer-of-code/2017-01/msg00000.html I have a couple of project ideas. For example: 1 - Rewrite EasyGnuPG (https://github.com/dashohoxha/egpg) so that it is built with Python and GPGME 2 - Implement a GUI to EasyGnuPG (maybe with Python). 3 - Extend EasyGnuPG with scripts/commands that automate other common usage scenarios (for example keeping the master key on a card). I would be ready to be a mentor for these projects, but I don't have enough experience neither with Python, nor with GPGME (and neither with advanced scenarios, like keeping the master key on a card). So, if someone would like to be a co-mentor this would be helpful. Regards, Dashamir -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Sat Dec 9 22:23:16 2017 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 9 Dec 2017 16:23:16 -0500 Subject: GSoC 2018 In-Reply-To: References: Message-ID: > Are we going to propose any projects for the Google Summer of Code 2018? I think there are a few bite-sized projects that would work well for GSoC. Porting the default Win32 passphrase dialog to Qt 5 or Gtk+3, for instance, as the current one is looking kind of ugly and clunky. > 1 - Rewrite EasyGnuPG (https://github.com/dashohoxha/egpg) > so that it is built with Python and GPGME It's pre-1.0, has a very small userbase, and the only person (you) capable of serving as a mentor on it doesn't know Python or GPGME. > 2 - Implement a GUI to EasyGnuPG (maybe with Python). I don't understand why a GUI would be placed on a shell script, especially when it just as easily could do the tasks directly by calling to GPGME. This project also seems redundant with the plethora of key managers out there: Enigmail, Kleopatra, GPA, etc. > 3 - Extend EasyGnuPG with scripts/commands that automate > other common usage scenarios (for example keeping the master key > on a card). Without a significant number of users, there are no common usage scenarios. I appreciate your desire to hack on a project and I don't want to dissuade you from spending your time hacking on whatever you choose: go, have fun, get down with your bad self, and please share your code. :) But I don't think EasyGnuPG is a suitable project for a GSoC at this time. From wk at gnupg.org Sun Dec 10 20:00:34 2017 From: wk at gnupg.org (Werner Koch) Date: Sun, 10 Dec 2017 20:00:34 +0100 Subject: GSoC 2018 In-Reply-To: (Robert J. Hansen's message of "Sat, 9 Dec 2017 16:23:16 -0500") References: Message-ID: <87d13mjtm5.fsf@wheatstone.g10code.de> On Sat, 9 Dec 2017 22:23, rjh at sixdemonbag.org said: > I think there are a few bite-sized projects that would work well for > GSoC. Porting the default Win32 passphrase dialog to Qt 5 or Gtk+3, for > instance, as the current one is looking kind of ugly and clunky. Actually there is no need to port it because gpg4win already provided them (GTK+-2, though, but that is just a minor thing). The vanilla installer from gnupg.org/ftp/gcrypt/binary does not come with Qt or GTK pinentries for the simple reason that this requires to deliver huge amounts of GUI framework stuff (binary and source) for just a single simple GUI applications (pinentry). The speedo build script once did this but I removed it because it does not make sense to add all this stuff to the GnuPG (backend) installer. I already looked into FLTK to provide a better Pinentry while keeping the size of the installer small. I think that will be possible but needs more work. Shalom-Salam, Werner p.s. I will not be available to help any Google recruitment program. -- 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 rjh at sixdemonbag.org Sun Dec 10 21:02:01 2017 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 10 Dec 2017 15:02:01 -0500 Subject: GSoC 2018 In-Reply-To: <87d13mjtm5.fsf@wheatstone.g10code.de> References: <87d13mjtm5.fsf@wheatstone.g10code.de> Message-ID: > Actually there is no need to port it because gpg4win already provided > them (GTK+-2, though, but that is just a minor thing). The vanilla Another option: .NET 3.0 + WinForms. It could be developed entirely on Mono in Linux, so you'd have a Free Software buildchain, and it would provide a good L&F without a lot of infuriating Win32 GUI calls. And .NET 3.0 is pretty widely supported, even on XP. From dr.munga at gmail.com Mon Dec 11 20:51:32 2017 From: dr.munga at gmail.com (munga) Date: Mon, 11 Dec 2017 20:51:32 +0100 Subject: csexpr parsing problem Message-ID: [ I've already sent this message a few times, but never made it trough. I hope this is the good one] Hi all, I'm new here in town. I've started playing with gpg-agent recently and I'm writing a small client to talk assuan . I've this strange problem. When asking for "genkey" I receive a string like : (10:public-key(3:rsa(1:n513: ... that is a csexpr. I've noticed that the numbers 10, 3, 1 and 513, that are supposedly the number of bytes to follow, are always the same. BUT the size of the entire csexpr is sometimes different. The server itself tells me the number of bytes sent and I get for example : 2017-12-08 16:21:36 gpg-agent[17137] DBG: returning public key 2017-12-08 16:21:36 gpg-agent[17137] DBG: chan_10 -> [ 44 20 28 31 30 3a 70 75 62 6c 69 63 2d 6b +65 79 ...(550 byte(s) skipped) ] 2017-12-08 16:21:36 gpg-agent[17137] DBG: chan_10 -> OK 2017-12-08 16:21:36 gpg-agent[17137] DBG: chan_10 <- [eof] 2017-12-08 16:10:41 gpg-agent[17137] DBG: returning public key 2017-12-08 16:10:41 gpg-agent[17137] DBG: chan_10 -> [ 44 20 28 31 30 3a 70 75 62 6c 69 63 2d 6b +65 79 ...(552 byte(s) skipped) ] 2017-12-08 16:10:41 gpg-agent[17137] DBG: chan_10 -> OK 2017-12-08 16:10:41 gpg-agent[17137] DBG: chan_10 <- [eof] notice that once it says : (550 byte(s) and the next (552 byte(s) skipped) ... Moreover when I try to read 513 bytes representing the pubkey, this number is always short of a few bytes (between 14 and 16 ...), and I truly don't understand why. Attached you can find the dump of the csexpr as I receive it from the agent and a small python parser... Any insight would be greatly appreciate. Specifically : - is the answer sent back by the server of a fixed size or not ? - are the size in the cexpr (513:...) to be interpreted as "read 513 bytes from here" ? I could use libaussan directly, but to avoid this C dependency in my OCaml code, I'd rather avoid it. A bit lost -------------- next part -------------- A non-text attachment was scrubbed... Name: gpg.dump Type: application/octet-stream Size: 580 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: parse.py Type: text/x-python Size: 309 bytes Desc: not available URL: From wk at gnupg.org Tue Dec 12 08:41:33 2017 From: wk at gnupg.org (Werner Koch) Date: Tue, 12 Dec 2017 08:41:33 +0100 Subject: csexpr parsing problem In-Reply-To: (munga's message of "Mon, 11 Dec 2017 20:51:32 +0100") References: Message-ID: <87y3m8fl5e.fsf@wheatstone.g10code.de> On Mon, 11 Dec 2017 20:51, dr.munga at gmail.com said: > (10:public-key(3:rsa(1:n513: ... that is a csexpr. > > I've noticed that the numbers 10, 3, 1 and 513, that are supposedly > the number of bytes to follow, are always the same. BUT the size of the Right. Did you read the specification os S-expressions? Just in case I will attach them. > entire csexpr is sometimes different. The server itself tells me the > number of bytes sent and I get for example : > > 2017-12-08 16:21:36 gpg-agent[17137] DBG: returning public key > 2017-12-08 16:21:36 gpg-agent[17137] DBG: chan_10 -> [ 44 20 28 31 30 > 3a 70 75 62 6c 69 63 2d 6b That is log output and not intended for further processing. > Attached you can find the dump of the csexpr as I receive it from the agent > and a small python parser... Any insight would be greatly appreciate. Your dump seems to e araw dump from Assuan. In Assuan LFs are used as record delimiters and thus percent escaping is used to protec LFs in raw data. Thus you need to unescape the received data lines. Libassuan does this for you but percent-unescaping is trivial because it can be done in-place: static size_t do_unescape_inplace (char *string, int withplus, int nulrepl) { unsigned char *p, *p0; p = p0 = string; while (*string) { if (*string == '%' && string[1] && string[2]) { string++; *p = xtoi_2 (string); if (!*p) *p = nulrepl; /* Optional replace a nul. */ string++; } else if (*string == '+' && withplus) /* Optional '+'->' ' unescaping.*/ *p = ' '; else *p = *string; p++; string++; } return (p - p0); } > - is the answer sent back by the server of a fixed size or not ? No, it is a canonical encoded s-expression. > - are the size in the cexpr (513:...) to be interpreted as "read 513 bytes from > here" ? Yes. But please use a correct s-expression parser and don't assume a fixed prefix. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: sexp.txt URL: -------------- 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 Dec 12 08:46:06 2017 From: wk at gnupg.org (Werner Koch) Date: Tue, 12 Dec 2017 08:46:06 +0100 Subject: GSoC 2018 In-Reply-To: (Robert J. Hansen's message of "Sun, 10 Dec 2017 15:02:01 -0500") References: <87d13mjtm5.fsf@wheatstone.g10code.de> Message-ID: <87lgi8fkxt.fsf@wheatstone.g10code.de> On Sun, 10 Dec 2017 21:02, rjh at sixdemonbag.org said: > Another option: .NET 3.0 + WinForms. It could be developed entirely on > Mono in Linux, so you'd have a Free Software buildchain, and it would Well, that would be an option. I have no experience with WinForms, though. 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 Dec 12 09:45:14 2017 From: wk at gnupg.org (Werner Koch) Date: Tue, 12 Dec 2017 09:45:14 +0100 Subject: Proposal with patch: Make socket directory host dependent In-Reply-To: (Rainer Perske's message of "Sun, 19 Nov 2017 14:59:27 +0100 (CET)") References: Message-ID: <87a7yofi79.fsf@wheatstone.g10code.de> Hi, I took your suggestion and gnupg 2.2.4 (o be released next week) will support a new build option: commit 17efcd2a2acdc3b7f00711272aa51e5be2476921 Author: Werner Koch Date: Tue Dec 12 09:42:43 2017 +0100 build: New configure option --enable-run-gnupg-user-socket. * configure.ac: (USE_RUN_GNUPG_USER_SOCKET): New ac_define. * common/homedir.c (_gnupg_socketdir_internal): Add extra directories. -- This allows to build GnuPG with an extra socketdir below /run. See https://lists.gnupg.org/pipermail/gnupg-devel/2017-November/033250.html for a longer explanation why this is sometimes useful. Suggested-by: Rainer Perske Signed-off-by: Werner Koch You may use gpgconf -v --dry-run --create-socketdir to check permissions etc. 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 Tue Dec 12 15:10:29 2017 From: wk at gnupg.org (Werner Koch) Date: Tue, 12 Dec 2017 15:10:29 +0100 Subject: [PATCH] default-preference-list: prefer SHA512. In-Reply-To: <87po8euxus.fsf@wheatstone.g10code.de> (Werner Koch's message of "Sun, 19 Nov 2017 15:50:03 +0100") References: <87wp50voca.fsf@fifthhorseman.net> <20170928123226.28189-1-dkg@fifthhorseman.net> <874lpv2uc7.fsf@wheatstone.g10code.de> <87wp2otph6.fsf@fifthhorseman.net> <87po8euxus.fsf@wheatstone.g10code.de> Message-ID: <87r2s0avfu.fsf@wheatstone.g10code.de> On Sun, 19 Nov 2017 15:50, wk at gnupg.org said: > On Sat, 18 Nov 2017 01:11, dkg at fifthhorseman.net said: > >> great! should i merge the patch then on master and STABLE-BRANCH-2-2, >> or will you do it? > > Please push to 2.2 Okay, I just pushed that to 2.2. Will be merged into master later. 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 Dec 12 15:26:58 2017 From: wk at gnupg.org (Werner Koch) Date: Tue, 12 Dec 2017 15:26:58 +0100 Subject: [Announce] GPGME 1.10.0 released Message-ID: <87k1xsauod.fsf@wheatstone.g10code.de> Hello! We are pleased to announce version 1.10.0 of GPGME. GnuPG Made Easy (GPGME) is a C language library that allows to add support for cryptography to a program. It is designed to make access to public key crypto engines like gpg and gpgsm easier for applications. GPGME provides a high-level crypto API for encryption, decryption, signing, signature verification, and key management. GPGME comes with language bindings for Common Lisp, C++, QT, Python 2 and 3. See https://gnupg.org/software/gpgme for more. Noteworthy changes in version 1.10.0 ==================================== * Now returns more specific error codes for decryption to distinguish between bad passphrase, user canceled, and no secret key. * Now returns key origin information if available. * Added context flag "auto-key-retrieve" to selectively enable the corresponding gpg option. * Added flag is_de_vs to decryption and verify results. * py: Use SEEK_SET as default for data.seek. * cpp: Various new APIs. * Reduced spawn overhead on Linux again. Added new configure option --disable-linux-getdents to disable this feature for very old Linux versions. * Improved the Python bindings build system. * Made the test suite less fragile. Download ======== You may download this library and its OpenPGP signature from: https://gnupg.org/ftp/gcrypt/gpgme/gpgme-1.10.0.tar.bz2 (1338k) https://gnupg.org/ftp/gcrypt/gpgme/gpgme-1.10.0.tar.bz2.sig or from ftp.gnupg.org. The SHA-1 checksum is 77d3390887da25ed70b7ac04392360efbdca501f gpgme-1.10.0.tar.bz2 but you better check the integrity using the provided signature. See for details. Thanks ====== Maintenance and development of GnuPG is mostly financed by donations. The GnuPG project currently employs one full-time developer and one contractor. Both work exclusivly on GnuPG and closely related software like Libgcrypt, GPGME, and GPA. We are planning to extend our team again. See you at FOSDEM. 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, answering questions on the mailing lists, and with financial support. Happy hacking, Your GnuPG hackers p.s. This is an announcement only mailing list. Please send replies only to the gnupg-devel 'at' gnupg.org mailing list. p.p.s List of Release Signing Keys: To guarantee that a downloaded GnuPG version has not been tampered by malicious entities we provide signature files for all tarballs and binary versions. The keys are also signed by the long term keys of their respective owners. Current releases are signed by one or more of these four keys: rsa2048 2011-01-12 [expires: 2019-12-31] Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) rsa2048 2014-10-29 [expires: 2019-12-31] Key fingerprint = 46CC 7308 65BB 5C78 EBAB ADCF 0437 6F3E E085 6959 David Shaw (GnuPG Release Signing Key) rsa2048 2014-10-29 [expires: 2020-10-30] Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 NIIBE Yutaka (GnuPG Release Key) rsa3072 2017-03-17 [expires: 2027-03-15] Key fingerprint = 5B80 C575 4298 F0CB 55D8 ED6A BCEF 7E29 4B09 2E28 Andre Heinecke (Release Signing Key) The keys are available at and in any recently released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed by a different key. -- 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 rainer.perske at uni-muenster.de Thu Dec 14 12:26:05 2017 From: rainer.perske at uni-muenster.de (Rainer Perske) Date: Thu, 14 Dec 2017 12:26:05 +0100 (CET) Subject: Proposal with patch: Make socket directory host dependent In-Reply-To: <87a7yofi79.fsf@wheatstone.g10code.de> Message-ID: Hallo, > I took your suggestion and gnupg 2.2.4 (o be released next week) will > support a new build option: [...] Gro?artig! Ganz, ganz herzlichen Dank! [Great!, many many thanks!] Beste Gr??e -- Rainer Perske Abteilung Systembetrieb und Leiter der Zertifizierungsstelle (WWUCA) Zentrum f?r Informationsverarbeitung (Universit?tsrechenzentrum) Westf?lische Wilhelms-Universit?t Zentrum f?r Informationsverarbeitung Rainer Perske R?ntgenstra?e 7-13 48149 M?nster Tel.: +49 251 83-31582 Fax.: +49 251 83-31555 E-Mail: rainer.perske at uni-muenster.de WWW: https://www.uni-muenster.de/ZIV/Mitarbeiter/RainerPerske.shtml B?ro: Raum 006, R?ntgenstra?e 11 Lageplan: http://wwwuv2.uni-muenster.de/uniplan/?action=spot&gebnr=7474 Zertifizierungsstelle der Universit?t M?nster (WWUCA): Tel.: +49 251 83-31590 Fax.: +49 251 83-31555 E-Mail: ca at uni-muenster.de WWW: https://www.uni-muenster.de/WWUCA/ Zentrum f?r Informationsverarbeitung (ZIV): Tel.: +49 251 83-31600 (Mo-Fr 7:30-17:30 Uhr) Fax.: +49 251 83-31555 E-Mail: ziv at uni-muenster.de WWW: https://www.uni-muenster.de/ZIV/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6807 bytes Desc: S/MIME cryptographic signature URL: From ben at adversary.org Sat Dec 16 01:21:02 2017 From: ben at adversary.org (Ben McGinnes) Date: Sat, 16 Dec 2017 11:21:02 +1100 Subject: DCO sign-off Message-ID: <20171216002102.l6aejk5xdp6xhtfi@adversary.org> Hi all, So since I can't find a record of having done this 2 years ago when I should have (I thought I had, but can't find it), here's a DCO to apply to all submissions (if necessary), past and future. Take tour pick of the body of the email or the clearsigned attached version. ======== 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: Ben McGinnes DB4724E6FA4286C92B4E55C4321E4E2373590E5D ======== I suspect it might have been skipped because my contributions were already available under the same licenses prior to being incorporated into the project. That doesn't necessarily cover the future, though, so a DCO now is probably wise. Regards, Ben -------------- next part -------------- -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 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: Ben McGinnes -----BEGIN PGP SIGNATURE----- iQGzBAEBCgAdFiEEt/D+dZOHQw3QxYvbf/LTcTXHVTwFAloeL4UACgkQf/LTcTXH VTwYGwwAoVqjVw3eQf/wzG657YdWK7+g988JvE3aTydM85qR45mG8asfgdsOmluE aG21VdTcazVDGzRPK4QLJ/xbTXlEmxiQcMQxuyarGiiC0WCP1sINhbUX5SCBOUDr lGaR9F0CFkwN15HjE1/Q+dE5iGN8DLkmeSwHU1r4kp2aR2otFHJ9wbUSHndjNE0j mR0Nct+zJSw5MprQ4BMuXhX/clNN7kAZ56SEQL9KoN+c+qecUjY104ZoInOW7pq4 18v+M2EK57S8cX0cep3PoyrS5QM07T+Oe8SytMSOEZzACFrrCNNTPVqpEnZc3ypT sTiI8G3C9RDuBqxt9EyprYIb5JbMQgiSvUXA6cYtUm2rGf3l9q1HZ8fMvkUpYV9/ FYy2KEqPtrLr6tJdg7YBn5ntsKej8vZZBCUqrnWb67siPEwWR31hhgXtSBUaaMJU pfcM/k2PunQLw1s6lgZGwaZRRZzT/OvJbGUi7abJuxO7wpX8l/8neMw7279mc8We T1qdtYK8 =Mqdk -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: not available URL: From rainer.perske at uni-muenster.de Wed Dec 20 12:48:50 2017 From: rainer.perske at uni-muenster.de (Rainer Perske) Date: Wed, 20 Dec 2017 12:48:50 +0100 (CET) Subject: Proposal with patch: Make socket directory host dependent In-Reply-To: Message-ID: Hello, I have just downloaded GnuPG 2.2.4 an will check the patch now. Thanks again! In my proposal, I had enlarged the character array "prefix" (now line 557 of common/homedir.c) from "13 + 1 + 20 + 6 + 1" to "6 + "13 + 1 + 20 + 6 + 1", the additional "6" is space for the characters "/gnupg" I had added to the prefix. I do not understand yet how the figures 13 + 1 + 20 are calculated. Maybe I was too careful by enlarging the space, but I'd propose to check whether the array is still large enough for all possible cases (if you did not already do so). Best regards -- Rainer Perske Abteilung Systembetrieb und Leiter der Zertifizierungsstelle (WWUCA) Zentrum f?r Informationsverarbeitung (Universit?tsrechenzentrum) Westf?lische Wilhelms-Universit?t Zentrum f?r Informationsverarbeitung Rainer Perske R?ntgenstra?e 7-13 48149 M?nster Tel.: +49 251 83-31582 Fax.: +49 251 83-31555 E-Mail: rainer.perske at uni-muenster.de WWW: https://www.uni-muenster.de/ZIV/Mitarbeiter/RainerPerske.shtml B?ro: Raum 006, R?ntgenstra?e 11 Lageplan: http://wwwuv2.uni-muenster.de/uniplan/?action=spot&gebnr=7474 Zertifizierungsstelle der Universit?t M?nster (WWUCA): Tel.: +49 251 83-31590 Fax.: +49 251 83-31555 E-Mail: ca at uni-muenster.de WWW: https://www.uni-muenster.de/WWUCA/ Zentrum f?r Informationsverarbeitung (ZIV): Tel.: +49 251 83-31600 (Mo-Fr 7:30-17:30 Uhr) Fax.: +49 251 83-31555 E-Mail: ziv at uni-muenster.de WWW: https://www.uni-muenster.de/ZIV/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6807 bytes Desc: S/MIME cryptographic signature URL: From wk at gnupg.org Wed Dec 20 15:32:17 2017 From: wk at gnupg.org (Werner Koch) Date: Wed, 20 Dec 2017 15:32:17 +0100 Subject: Proposal with patch: Make socket directory host dependent In-Reply-To: (Rainer Perske's message of "Wed, 20 Dec 2017 12:48:50 +0100 (CET)") References: Message-ID: <87wp1hxyfi.fsf@wheatstone.g10code.de> On Wed, 20 Dec 2017 12:48, rainer.perske at uni-muenster.de said: > I do not understand yet how the figures 13 + 1 + 20 are calculated. char prefix[13 + 1 + 20 + 6 + 1]; /var/run/user -> 13 / -> 1 UID -> 20 (for a 64 bit unsigned integer) /gnupg -> 6 nul -> 1 and indeed I did not add 6 extra bytes for the leading "/gnupg". However, it is not a problem: A 32 bit user id (e.g. 2147483647) does only need 10 bytes and thus there is enough space for the extra string. If the ID would really grow to a larger 64 bit value, this will not work anymore and the explict check will let it return an error. Although I tested this I obviously did not noticed that we will end up with a socket directory /run/gnupg/user/gnupg/ The second gnupg would not be needed. The question is whether to remove it or to keep it for code simplicity. I will fix the size of the prefix, though. 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 Dec 20 16:36:34 2017 From: wk at gnupg.org (Werner Koch) Date: Wed, 20 Dec 2017 16:36:34 +0100 Subject: [Announce] GnuPG 2.2.4 released Message-ID: <87fu85xvgd.fsf@wheatstone.g10code.de> Hello! 20 years after the first version we are pleased to announce the availability of a new GnuPG release: version 2.2.4. 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.4 =================================== * gpg: Change default preferences to prefer SHA512. * gpg: Print a warning when more than 150 MiB are encrypted using a cipher with 64 bit block size. * gpg: Print a warning if the MDC feature has not been used for a message. * gpg: Fix regular expression of domain addresses in trust signatures. [#2923] * agent: New option --auto-expand-secmem to help with high numbers of concurrent connections. Requires libgcrypt 1.8.2 for having an effect. [#3530] * dirmngr: Cache responses of WKD queries. * gpgconf: Add option --status-fd. * wks: Add commands --check and --remove-key to gpg-wks-server. * Increase the backlog parameter of the daemons to 64 and add option --listen-backlog. * New configure option --enable-run-gnupg-user-socket to first try a socket directory which is not removed by systemd at session end. Getting the Software ==================== Please follow the instructions found at or read on: GnuPG 2.2.4 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.4.tar.bz2 (6417k) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.4.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.4_20171220.exe (3817k) https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.5_20171220.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 3.0 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.4.tar.bz2 you would use this command: gpg --verify gnupg-2.2.4.tar.bz2.sig gnupg-2.2.4.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.4.tar.bz2, you run the command like this: sha1sum gnupg-2.2.4.tar.bz2 and check that the output matches the next line: 732266e8888c6f41c084d043c7a0058332ff3580 gnupg-2.2.4.tar.bz2 d06a1413fd901c51eba14164ddb28d99ab9f84df gnupg-w32-2.2.4_20171220.exe 60d0e804075e05c8268b75d4cda1ec4277691385 gnupg-w32-2.2.4_20171220.tar.xz Internationalization ==================== This version of GnuPG has support for 26 languages with Chinese, Czech, French, German, Japanese, Norwegian, Russian, and Ukrainian being almost completely translated. Documentation and Support ========================= If you used GnuPG in the past you should read the description of changes and new features at doc/whats-new-in-2.1.txt or online at https://gnupg.org/faq/whats-new-in-2.1.html The file gnupg.info has the complete reference manual of the system. Separate man pages are included as well but they miss some of the details availabale only in thee manual. The manual is also available online at https://gnupg.org/documentation/manuals/gnupg/ or can be downloaded as PDF at https://gnupg.org/documentation/manuals/gnupg.pdf . The chapters on gpg-agent, gpg and gpgsm include information on how to set up the whole thing. You may also want to search the GnuPG mailing list archives or ask on the gnupg-users mailing list for advise on how to solve problems. Most of the new features are around for several years and thus enough public experience is available. Please consult the archive of the gnupg-users mailing list before reporting a bug: . We suggest to send bug reports for a new release to this list in favor of filing a bug at . If you need commercial support check out . If you are a developer and you need a certain feature for your project, please do not hesitate to bring it to the gnupg-devel mailing list for discussion. Thanks ====== Maintenance and development of GnuPG is mostly financed by donations. The GnuPG project currently employs one full-time developer and one contractor. Both work exclusively on GnuPG and closely related software like Libgcrypt, GPGME, and GPA. We are planning to extend our team again and to help developers to improve integration of crypto in their applications. We have to thank all the people who helped the GnuPG project, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, and answering questions on the mailing lists. Many thanks to our numerous financial supporters, both corporate and individuals. Without you it would not be possible to keep GnuPG in a good shape and address all the small and larger requests made by our users. Thanks. Happy hacking, Your GnuPG hackers p.s. This is an announcement only mailing list. Please send replies only to the gnupg-users'at'gnupg.org mailing list. p.p.s List of Release Signing Keys: To guarantee that a downloaded GnuPG version has not been tampered by malicious entities we provide signature files for all tarballs and binary versions. The keys are also signed by the long term keys of their respective owners. Current releases are signed by one or more of these four keys: rsa2048 2011-01-12 [expires: 2019-12-31] Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) rsa2048 2014-10-29 [expires: 2019-12-31] Key fingerprint = 46CC 7308 65BB 5C78 EBAB ADCF 0437 6F3E E085 6959 David Shaw (GnuPG Release Signing Key) rsa2048 2014-10-29 [expires: 2020-10-30] Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 NIIBE Yutaka (GnuPG Release Key) rsa3072 2017-03-17 [expires: 2027-03-15] Key fingerprint = 5B80 C575 4298 F0CB 55D8 ED6A BCEF 7E29 4B09 2E28 Andre Heinecke (Release Signing Key) The keys are available at and in any recently released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed by a different key. -- 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 kristian.fiskerstrand at sumptuouscapital.com Wed Dec 20 21:25:01 2017 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Wed, 20 Dec 2017 21:25:01 +0100 Subject: [PATCH] build: Increase libassuan min version to 2.5.0 Message-ID: Subject: [PATCH] build: Increase libassuan min version to 2.5.0 -- assuan_sock_set_system_hooks is used unconditionally in gnupg since commit 9f641430dcdecbd7ee205d407cb19bb4262aa95d, and as such it requires libassuan 2.5.0 (function introduced in commit 90dc81682b13a7cf716a8a26b891051cbd4b0caf) --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- Varitatio delectat Change pleases -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-build-Increase-libassuan-min-version-to-2.5.0.patch Type: text/x-patch Size: 856 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Thu Dec 21 09:02:38 2017 From: wk at gnupg.org (Werner Koch) Date: Thu, 21 Dec 2017 09:02:38 +0100 Subject: [PATCH] build: Increase libassuan min version to 2.5.0 In-Reply-To: (Kristian Fiskerstrand's message of "Wed, 20 Dec 2017 21:25:01 +0100") References: Message-ID: <87lghwwlsx.fsf@wheatstone.g10code.de> On Wed, 20 Dec 2017 21:25, kristian.fiskerstrand at sumptuouscapital.com said: > Subject: [PATCH] build: Increase libassuan min version to 2.5.0 Ooops. No release without glitches. We had to use that new libassuan function to fix a hang on Windows. I am not 100% sure whether Unix is also affected; @gniibe: can you enlight us? Does this new requirement pose a problem for Linux distros? If so we should see whether we can do something about it. 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 kristian.fiskerstrand at sumptuouscapital.com Thu Dec 21 12:05:10 2017 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Thu, 21 Dec 2017 12:05:10 +0100 Subject: [PATCH] build: Increase libassuan min version to 2.5.0 In-Reply-To: <87lghwwlsx.fsf@wheatstone.g10code.de> References: <87lghwwlsx.fsf@wheatstone.g10code.de> Message-ID: On December 21, 2017 9:02:38 AM GMT+01:00, Werner Koch wrote: >On Wed, 20 Dec 2017 21:25, kristian.fiskerstrand at sumptuouscapital.com >said: >> Subject: [PATCH] build: Increase libassuan min version to 2.5.0 > >Ooops. No release without glitches. > >We had to use that new libassuan function to fix a hang on Windows. I >am not 100% sure whether Unix is also affected; @gniibe: can you >enlight >us? > >Does this new requirement pose a problem for Linux distros? If so we >should see whether we can do something about it. > > >Salam-Shalom, > > Werner New requirement doesn't pose a problem for Gentoo at least. -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP certificate at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 From dkg at fifthhorseman.net Thu Dec 21 22:28:36 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 21 Dec 2017 16:28:36 -0500 Subject: [PATCH] build: Increase libassuan min version to 2.5.0 In-Reply-To: <87lghwwlsx.fsf@wheatstone.g10code.de> References: <87lghwwlsx.fsf@wheatstone.g10code.de> Message-ID: <87608zlqij.fsf@fifthhorseman.net> On Thu 2017-12-21 09:02:38 +0100, Werner Koch wrote: > On Wed, 20 Dec 2017 21:25, kristian.fiskerstrand at sumptuouscapital.com > said: >> Subject: [PATCH] build: Increase libassuan min version to 2.5.0 > > Ooops. No release without glitches. > > We had to use that new libassuan function to fix a hang on Windows. I > am not 100% sure whether Unix is also affected; @gniibe: can you enlight > us? > > Does this new requirement pose a problem for Linux distros? If so we > should see whether we can do something about it. when i'm thinking about backporting GnuPG for older debian releases, i typically assume i'll need to backport a set of GnuPG-specific dependencies as well. It shouldn't be particularly painful to include assuan in that list. If i find it's painful, i'll let you know, but for the moment, please don't prioritize it for my sake. --dkg PS what i'd really *like* in terms of dependency creep is a new release of libgpg-error that includes yat2m and gpgscm, so i can make it a build-dependency of gnupg itself, and get the gnupg package out of the business of building these mainly orthogonal tools. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From gniibe at fsij.org Fri Dec 22 00:47:42 2017 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 22 Dec 2017 08:47:42 +0900 Subject: [PATCH] build: Increase libassuan min version to 2.5.0 In-Reply-To: <87lghwwlsx.fsf@wheatstone.g10code.de> References: <87lghwwlsx.fsf@wheatstone.g10code.de> Message-ID: <87zi6b8wyp.fsf@fsij.org> Werner Koch writes: > We had to use that new libassuan function to fix a hang on Windows. I > am not 100% sure whether Unix is also affected; @gniibe: can you enlight > us? The change is not needed for Unix. Let me explain. The problem is about the initialization of nPth (the thread library), the use of libassuan, and UNIX domain socket emulation on Windows. We use nPth library for cooperative threads. When a thread of an application calls a system call which may block, the thread should release the "execution right" (which is only given to a single thread at a time) and then, after the system call, it should acquire the right. This way, an application doesn't cause any hang, and execution is done by single thread, cooperatively. Libassuan uses hooks for this mechanism for its calls of usleep, read, write, recvmsg, sendmsg, waitpid, connect, and close. We want to defer the nPth initialization, to be done after fork(2) on Unix, because forking a process of multiple threads may open a can of worms (of undefined/undocumented things). gpg-agent prepares listing sockets, forks, and then, it comes nPth initialization. On the other hand, before nPth initialization (forking on Unix), gpg-agent uses libassuan to check if another gpg-agent is available or not. This use of libassuan is done by non-threaded mode (it blocks on connect/read/write). There are two access mode in use of libassuan: by assuan_sock_* functions with standard sock_fd, and by assuan context of type assuan_context_t CTX. Before the fix, use of assuan_sock_* by libassuan had the setting of non-threaded mode, because of the order of initialization (nPth initialization is done after fork). This worked well on Unix, because all the things done by assuan_sock_* are things by listening socket and checking nonce before start_command_handler. After checking nonce (which is null on Unix), it uses the assuan context. Things done by listening sockets are: poll on new connection by its own call of nPth function (npth_select), accept (by npth_accept), and create a new thread to work with the connection. No problem, even if non-threaded mode of libassuan. On Windows, UNIX domain socket emulation does checking nonce (by read and write), and it was done in non-threaded mode of libassuan. This caused a race condition, where the entire gpg-agent process might hang. The fix is that we provide an API (assuan_sock_set_system_hooks) to initialize, for the accesses by assuan_sock_* functions (along with assuan_set_system_hooks). Before the fix, the accesses by assuan_sock_* functions only inherited the setting by assuan_set_system_hooks. Now, it can be done independently. Thus, on Windows, checking nonce is now done in threaded-mode, which can avoid hang. -- From wk at gnupg.org Fri Dec 22 09:53:21 2017 From: wk at gnupg.org (Werner Koch) Date: Fri, 22 Dec 2017 09:53:21 +0100 Subject: [PATCH] build: Increase libassuan min version to 2.5.0 In-Reply-To: <87608zlqij.fsf@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Thu, 21 Dec 2017 16:28:36 -0500") References: <87lghwwlsx.fsf@wheatstone.g10code.de> <87608zlqij.fsf@fifthhorseman.net> Message-ID: <87zi6bywhq.fsf@wheatstone.g10code.de> On Thu, 21 Dec 2017 22:28, dkg at fifthhorseman.net said: > dependencies as well. It shouldn't be particularly painful to include > assuan in that list. If i find it's painful, i'll let you know, but for > the moment, please don't prioritize it for my sake. Okay. > PS what i'd really *like* in terms of dependency creep is a new release > of libgpg-error that includes yat2m and gpgscm, so i can make it a > build-dependency of gnupg itself, and get the gnupg package out of I am slowly working in it but gpgscm has a lot og gnupg dependencies; Some need to be ported to libgpg-error and other may better be re-written in scheme as part of the gnupg test suite. If it is really urgent I could soon do a release with yat2m but without gpgscm. 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 ben at adversary.org Sat Dec 23 07:00:17 2017 From: ben at adversary.org (Ben McGinnes) Date: Sat, 23 Dec 2017 17:00:17 +1100 Subject: [PATCH] Website: Grammar in first paragraph. Message-ID: <20171223060017.4n3o2pv4qq3imhz5@adversary.org> From 5d495931d0b4f6f1a4567b4c4902e5ff25b1fc0f Mon Sep 17 00:00:00 2001 From: Ben McGinnes Date: Sat, 23 Dec 2017 15:52:08 +1100 Subject: [PATCH] Grammar in first paragraph. * This paragraph tried to be English and almost made it in parts of one or two sentences ... and now does so in all of them. * No doubt there will be more to find later. * Thanks to @Error26914 on Twitter for the heads up on this bit. --- web/index.org | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/web/index.org b/web/index.org index 4fed715..db0271e 100644 --- a/web/index.org +++ b/web/index.org @@ -10,11 +10,11 @@ #+index: Gpg4win GnuPG is a complete and free implementation of the OpenPGP standard as -defined by [[https://www.ietf.org/rfc/rfc4880.txt][RFC4880]] (also known as /PGP/). GnuPG allows to encrypt and -sign your data and communication, features a versatile key management -system as well as access modules for all kinds of public key +defined by [[https://www.ietf.org/rfc/rfc4880.txt][RFC4880]] (also known as /PGP/). GnuPG allows you to encrypt and +sign your data and communications; it features a versatile key management +system, along with access modules for all kinds of public key directories. GnuPG, also known as /GPG/, is a command line tool with -features for easy integration with other applications. A wealth of +features for easy integration with other applications. A wealth of [[file:software/frontends.html][frontend applications]] and [[file:software/libraries.html][libraries]] are available. GnuPG also provides support for S/MIME and Secure Shell (ssh). -- 2.15.1 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: not available URL: From dgouttegattat at incenp.org Sat Dec 30 11:19:23 2017 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Sat, 30 Dec 2017 10:19:23 +0000 Subject: [PATCH 0/2] Use external process to check for passphrase quality Message-ID: <20171230101925.7062-1-dgouttegattat@incenp.org> Hi GnuPG folks, The following patch set provides a way to give the user a better passphrase quality estimation, as discussed in ticket #2103 [1]. The first patch adds to gpg-agent a new option --passphrase-checker, which may be set to the pathname of a program that the agent will call to perform the passphrase quality estimation. The program should read the passphrase on stdin and write a 0..100 quality value on stdout. (Such a program is pwscore, from the libpwquality project [2]). The second patch changes the behavior of the agent to request a quality bar from pinentry *only* if either --passphrase-checker or --check-passphrase-pattern is set, as proposed by Werner. [1] https://dev.gnupg.org/T2103. [2] https://github.com/libpwquality/libpwquality Damien Goutte-Gattat (2): agent: Defer passphrase quality check to external tool. agent: Disable quality bar by default. agent/agent.h | 3 +++ agent/call-pinentry.c | 34 +++++++++++++++++++++++++++++----- agent/gpg-agent.c | 6 ++++++ doc/gpg-agent.texi | 7 +++++++ 4 files changed, 45 insertions(+), 5 deletions(-) -- 2.14.1 From dgouttegattat at incenp.org Sat Dec 30 11:19:24 2017 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Sat, 30 Dec 2017 10:19:24 +0000 Subject: [PATCH 1/2] agent: Defer passphrase quality check to external tool. In-Reply-To: <20171230101925.7062-1-dgouttegattat@incenp.org> References: <20171230101925.7062-1-dgouttegattat@incenp.org> Message-ID: <20171230101925.7062-2-dgouttegattat@incenp.org> * agent/call-pinentry.c (estimate_passphrase_quality): Call external program to evaluate passphrase if requested. * agent/agent.h (struct opt): New field passphrase_quality_checker. * agent/gpg-agent.c (oPassphraseChecker): New const. (opts): New option --passphrase-checker. (parse_rereadable_options): Handle the new option. * doc/gpg-agent.texi: Document the new option. -- GnuPG-bug-id: 2103 Signed-off-by: Damien Goutte-Gattat --- agent/agent.h | 3 +++ agent/call-pinentry.c | 21 +++++++++++++++++++++ agent/gpg-agent.c | 6 ++++++ doc/gpg-agent.texi | 7 +++++++ 4 files changed, 37 insertions(+) diff --git a/agent/agent.h b/agent/agent.h index 687635dc7..b1c649e1a 100644 --- a/agent/agent.h +++ b/agent/agent.h @@ -116,6 +116,9 @@ struct /* File name with a patternfile or NULL if not enabled. */ const char *check_passphrase_pattern; + /* Path to a external passphrase checker (NULL to disable). */ + const char *passphrase_quality_checker; + /* If not 0 the user is asked to change his passphrase after these number of days. */ unsigned int max_passphrase_days; diff --git a/agent/call-pinentry.c b/agent/call-pinentry.c index af4eb06f2..1d971db6f 100644 --- a/agent/call-pinentry.c +++ b/agent/call-pinentry.c @@ -39,6 +39,7 @@ #include #include "../common/sysutils.h" #include "../common/i18n.h" +#include "../common/exectool.h" #ifdef _POSIX_OPEN_MAX #define MAX_OPEN_FDS _POSIX_OPEN_MAX @@ -785,6 +786,26 @@ estimate_passphrase_quality (const char *pw) int length; const char *s; + if (opt.passphrase_quality_checker) + { + char *output; + long percent; + + if (gnupg_exec_tool (opt.passphrase_quality_checker, NULL, + pw, &output, NULL)) + return 0; + + percent = strtol (output, NULL, 10); + if (percent < 0) + percent = 0; + if (percent > 100) + percent = 100; + + xfree (output); + + return percent; + } + if (goodlength < 1) return 0; diff --git a/agent/gpg-agent.c b/agent/gpg-agent.c index a1964ece8..7e9a03310 100644 --- a/agent/gpg-agent.c +++ b/agent/gpg-agent.c @@ -110,6 +110,7 @@ enum cmd_and_opt_values oMinPassphraseLen, oMinPassphraseNonalpha, oCheckPassphrasePattern, + oPassphraseChecker, oMaxPassphraseDays, oEnablePassphraseHistory, oEnableExtendedKeyFormat, @@ -224,6 +225,7 @@ static ARGPARSE_OPTS opts[] = { ARGPARSE_s_s (oCheckPassphrasePattern, "check-passphrase-pattern", "@"), ARGPARSE_s_u (oMaxPassphraseDays, "max-passphrase-days", "@"), ARGPARSE_s_n (oEnablePassphraseHistory, "enable-passphrase-history", "@"), + ARGPARSE_s_s (oPassphraseChecker, "passphrase-checker", "@"), ARGPARSE_s_n (oIgnoreCacheForSigning, "ignore-cache-for-signing", /* */ N_("do not use the PIN cache when signing")), @@ -821,6 +823,7 @@ parse_rereadable_options (ARGPARSE_ARGS *pargs, int reread) opt.min_passphrase_len = MIN_PASSPHRASE_LEN; opt.min_passphrase_nonalpha = MIN_PASSPHRASE_NONALPHA; opt.check_passphrase_pattern = NULL; + opt.passphrase_quality_checker = NULL; opt.max_passphrase_days = MAX_PASSPHRASE_DAYS; opt.enable_passphrase_history = 0; opt.enable_extended_key_format = 0; @@ -890,6 +893,9 @@ parse_rereadable_options (ARGPARSE_ARGS *pargs, int reread) case oCheckPassphrasePattern: opt.check_passphrase_pattern = pargs->r.ret_str; break; + case oPassphraseChecker: + opt.passphrase_quality_checker = pargs->r.ret_str; + break; case oMaxPassphraseDays: opt.max_passphrase_days = pargs->r.ret_ulong; break; diff --git a/doc/gpg-agent.texi b/doc/gpg-agent.texi index 3e8bd894d..1a72836aa 100644 --- a/doc/gpg-agent.texi +++ b/doc/gpg-agent.texi @@ -458,6 +458,13 @@ a policy. A better policy is to educate users on good security behavior and optionally to run a passphrase cracker regularly on all users passphrases to catch the very simple ones. + at item --passphrase-checker @var{filename} + at opindex passphrase-checker +Call program @var{filename} to estimate the quality of a new passphrase. +The program is expected to read the passphrase to check on its standard +input and should print the estimated quality as an integer value between +0 and 100. The default is not to call any such program. + @item --max-passphrase-days @var{n} @opindex max-passphrase-days Ask the user to change the passphrase if @var{n} days have passed since -- 2.14.1 From dgouttegattat at incenp.org Sat Dec 30 11:19:25 2017 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Sat, 30 Dec 2017 10:19:25 +0000 Subject: [PATCH 2/2] agent: Disable quality bar by default. In-Reply-To: <20171230101925.7062-1-dgouttegattat@incenp.org> References: <20171230101925.7062-1-dgouttegattat@incenp.org> Message-ID: <20171230101925.7062-3-dgouttegattat@incenp.org> * agent/call-pinentry.c (SHOW_QUALITYBAR): New symbol. (agent_askpin): Request a quality bar only if meaningful. (agent_get_passphrase): Likewise. -- We should ask Pinentry to display a quality bar only if we have a decent way (provided by the --passphrase-quality-checker option) of estimating the quality of the passphrase, or if we check the passphrase against a list of patterns (--check-passphrase-pattern). Signed-off-by: Damien Goutte-Gattat --- agent/call-pinentry.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/agent/call-pinentry.c b/agent/call-pinentry.c index 1d971db6f..7e878df12 100644 --- a/agent/call-pinentry.c +++ b/agent/call-pinentry.c @@ -54,6 +54,12 @@ time. */ #define LOCK_TIMEOUT (1*60) +/* We ask Pinentry to display a quality bar only if we have some way + to actually evaluate the quality of the passphrase. */ +#define SHOW_QUALITYBAR (opt.min_passphrase_len \ + && (opt.check_passphrase_pattern \ + || opt.passphrase_quality_checker)) + /* The assuan context of the current pinentry. */ static assuan_context_t entry_ctx; @@ -1062,10 +1068,7 @@ agent_askpin (ctrl_t ctrl, if (rc) return unlock_pinentry (ctrl, rc); - /* If a passphrase quality indicator has been requested and a - minimum passphrase length has not been disabled, send the command - to the pinentry. */ - if (pininfo->with_qualitybar && opt.min_passphrase_len ) + if (pininfo->with_qualitybar && SHOW_QUALITYBAR) { rc = setup_qualitybar (ctrl); if (rc) @@ -1272,7 +1275,7 @@ agent_get_passphrase (ctrl_t ctrl, if (rc) return unlock_pinentry (ctrl, rc); - if (with_qualitybar && opt.min_passphrase_len) + if (with_qualitybar && SHOW_QUALITYBAR) { rc = setup_qualitybar (ctrl); if (rc) -- 2.14.1 From wk at gnupg.org Sat Dec 30 13:22:50 2017 From: wk at gnupg.org (Werner Koch) Date: Sat, 30 Dec 2017 13:22:50 +0100 Subject: [PATCH 0/2] Use external process to check for passphrase quality In-Reply-To: <20171230101925.7062-1-dgouttegattat@incenp.org> (Damien Goutte-Gattat's message of "Sat, 30 Dec 2017 10:19:23 +0000") References: <20171230101925.7062-1-dgouttegattat@incenp.org> Message-ID: <87r2rcxv51.fsf@wheatstone.g10code.de> On Sat, 30 Dec 2017 11:19, dgouttegattat at incenp.org said: > The following patch set provides a way to give the user a better > passphrase quality estimation, as discussed in ticket #2103 [1]. Given that this is a long standing complaint I would be fine with adding this even to 2.2. Or should we do this only for master? 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 dgouttegattat at incenp.org Sat Dec 30 14:27:21 2017 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Sat, 30 Dec 2017 13:27:21 +0000 Subject: [PATCH 0/2] Use external process to check for passphrase quality In-Reply-To: <87r2rcxv51.fsf@wheatstone.g10code.de> References: <20171230101925.7062-1-dgouttegattat@incenp.org> <87r2rcxv51.fsf@wheatstone.g10code.de> Message-ID: On 12/30/2017 12:22 PM, Werner Koch wrote: > Given that this is a long standing complaint I would be fine with adding > this even to 2.2. Or should we do this only for master? I've written the patch against master but it applies cleanly on STABLE-BRANCH-2-2 as well. For what it's worth I would like to see it in a future 2.2 release. Damien -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: