From aheinecke at intevation.de Tue Jul 3 16:32:18 2018 From: aheinecke at intevation.de (Andre Heinecke) Date: Tue, 03 Jul 2018 16:32:18 +0200 Subject: WKD: User ID filtering In-Reply-To: References: <3fdb9a40-7c72-59ed-2130-9b622158b709@metacode.biz> <101995059.p5jZPprFHI@esus> Message-ID: <3581106.ktT89CzsYE@esus> Hi, On Thursday, June 21, 2018 1:01:49 PM CEST Wiktor Kwapisiewicz wrote: > > Btw. Last year Neal, Bernhard and me worked on a concept how we would like to > > utilize WKD and the TOFU trust model for automated encryption. It can be found > > under: > > https://wiki.gnupg.org/AutomatedEncryption > > > > Maybe you find it interesting, I would be interested in your opinion. > > That definitely is most interesting! > > I've been pondering setting up encryption for less technical people for > some time and the current approach requires a lot of hops to do that > (basically me setting up their MUA). > > Automated encryption with WKD+TOFU seems like a good approach. > > I am looking forward to your demo video! I've uploaded an animation of how it looks in the current development version of GpgOL: https://wiki.gnupg.org/EasyGpg2016/OutlookUi#Empty_Keyring_-_Verifying_a_Mail_with_key_available_in_WKD Below this you will find an animation which includes Keygen / Setup with a Web Key Service. I'm not sure if the wording is perfect. "Confirmed" is a bit strong for WKD. It's in contrast to "Certified" which is the word for PGP / S/MIME trust. Apologies for the language mix but I was running on a German Windows. Best Regards, Andre -- Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: From wiktor at metacode.biz Tue Jul 3 17:00:14 2018 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Tue, 3 Jul 2018 17:00:14 +0200 Subject: WKD: User ID filtering In-Reply-To: <3581106.ktT89CzsYE@esus> References: <3fdb9a40-7c72-59ed-2130-9b622158b709@metacode.biz> <101995059.p5jZPprFHI@esus> <3581106.ktT89CzsYE@esus> Message-ID: <4f304996-08d8-9e31-5085-303a0fbb80d5@metacode.biz> Hi Andre, > I've uploaded an animation of how it looks in the current development version > of GpgOL: > > https://wiki.gnupg.org/EasyGpg2016/OutlookUi#Empty_Keyring_-_Verifying_a_Mail_with_key_available_in_WKD > > Below this you will find an animation which includes Keygen / Setup with a Web > Key Service. Oh, yes. This definitely looks good! Especially the "Empty Keyring - Verifying a Mail with key available in WKD" animation that doesn't bug the user with popups - it just works! Very cool, I will definitely check this out with Outlook once released. Thanks! Kind regards, Wiktor -- https://metacode.biz/@wiktor -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 862 bytes Desc: OpenPGP digital signature URL: From gniibe at fsij.org Wed Jul 4 04:39:10 2018 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 04 Jul 2018 11:39:10 +0900 Subject: scd bug: specifying 'e length' for RSA key-attr unsupported In-Reply-To: <1be69e47-7571-f66e-e972-743734a264dc@yubico.com> References: <1be69e47-7571-f66e-e972-743734a264dc@yubico.com> Message-ID: <87d0w3vi5t.fsf@iwagami.gniibe.org> Trevor Bentley via Gnupg-devel wrote: > Specifically, the KEY-ATTR command does not accept 'e bit length' as an > argument. scdaemon simply re-uses whichever value the card defaults to > if you change the RSA key length... but the real bug here is that when > switching back to RSA from an EC algorithm, scdaemon hardcodes the 'e > bit length' to 32. In my opinion, the key attributes are not well defined in the spec and host software needs guessing about behavior of card implementation. This hard-coding in scdaemon was done for existing OpenPGPcard implementations; Achim's OpenPGPcard and Gnuk. > Note that this is a likely case: the OpenPGP on Smart Card spec (v3.3.1) > specifies 65537 (bit length 17) as the only value required to be > supported, and as the default to use if none is specified. The protocol > does not support specifying 'none', so GPG does have to specify > something when changing the algorithm. According to the spec, there is no information which key attribute (value and format) is supported by a specific card. Here, host software needs guessing. In the spec, IIRC, it suggests the value "32" for e's length in the key attributes, as well as the value 65537. Well, 65537 can be represented by 32-bit. IIRC, there is no place in the spec suggesting 17. I know that with the background of OpenPGP format itself, 17 makes sense. > I believe this needs to be fixed in one of two ways: > 1) add an 'e length' argument to KEY-ATTR (and possibly a matching UI) > 2) use '17' instead of '32' as the hard-coded length, since all cards > are required to support it Or, you can ask change of OpenPGP card implementation, following other OpenPGP card implementations. And make things explicit in the spec. > -- > $ gpg-connect-agent "SCD SETATTR KEY-ATTR --force 1 1 rsa2048" /bye > OK > $ gpg-connect-agent "SCD SETATTR KEY-ATTR --force 1 19 nistp256" /bye > OK > $ gpg-connect-agent "SCD SETATTR KEY-ATTR --force 1 1 rsa2048" /bye Here, it returns "OK" for Achim's OpenPGPcard (I have the test version of 3.3) and Gnuk 1.2. -- From trevor at yubico.com Wed Jul 4 10:26:17 2018 From: trevor at yubico.com (Trevor Bentley) Date: Wed, 4 Jul 2018 10:26:17 +0200 Subject: scd bug: specifying 'e length' for RSA key-attr unsupported In-Reply-To: <87d0w3vi5t.fsf@iwagami.gniibe.org> References: <1be69e47-7571-f66e-e972-743734a264dc@yubico.com> <87d0w3vi5t.fsf@iwagami.gniibe.org> Message-ID: <3d4b5822-0da8-9495-02c0-90b8098740e1@yubico.com> > In my opinion, the key attributes are not well defined in the spec and > host software needs guessing about behavior of card implementation. I mostly agree. The spec does state that all cards must support 65537, so at least there is a known value that can always be chosen. But ideally, the smartcard spec would allow sending a special value (or omitting the field) to means 'card default'. And ideally, GnuPG would still provide some method for the user to explicitly set a desired e bit len if the user does not want the default. I've added Achim to this thread, as it would be nice to get his input. > According to the spec, there is no information which key attribute > (value and format) is supported by a specific card. Here, host software > needs guessing. > > In the spec, IIRC, it suggests the value "32" for e's length in the key > attributes, as well as the value 65537. Well, 65537 can be represented > by 32-bit. IIRC, there is no place in the spec suggesting 17. I know > that with the background of OpenPGP format itself, 17 makes sense. The spec doesn't provide a way to check if a length is supported. However, it is clear about 65537 being required, and recommends it as default: SHALL accept (required): -- Some smart cards with RSA algorithm support only one coding for the Public Exponent (e.g. 65537 dec.). The card may reject an imported key, if e does not match the internal requirements. But the card shall accept 65537 dec. (010001) as value for e. -- SHOULD use (recommended): -- The card should use 65537 dec. (10001 bin.) as default value for e, but other values are accepted by the outside world. -- I only see 32 specified in an example, which is just demonstrating that it can be used: "Length of public exponent e in bit (e. g. 32 bit decimal = 0020), binary" You are obviously correct that 65537 fits in 32 bits, but cards that don't accept exponents larger than 17 bits are typically going to refuse the larger length. It may be _permitted_ to accept a 32-bit length and generate a 17-bit exponent within it, but in practice they almost certainly won't. And rightly so, since accepting a 32-bit length strongly implies that it can actually handle them. >> I believe this needs to be fixed in one of two ways: >> 1) add an 'e length' argument to KEY-ATTR (and possibly a matching UI) >> 2) use '17' instead of '32' as the hard-coded length, since all cards >> are required to support it > > Or, you can ask change of OpenPGP card implementation, following other > OpenPGP card implementations. And make things explicit in the spec. I would suggest that as an 'and' instead of an 'or'. I think it's best for GnuPG to support the existing spec as well as possible, and to encourage the spec to improve. >> -- >> $ gpg-connect-agent "SCD SETATTR KEY-ATTR --force 1 1 rsa2048" /bye >> OK >> $ gpg-connect-agent "SCD SETATTR KEY-ATTR --force 1 19 nistp256" /bye >> OK >> $ gpg-connect-agent "SCD SETATTR KEY-ATTR --force 1 1 rsa2048" /bye > > Here, it returns "OK" for Achim's OpenPGPcard (I have the test version > of 3.3) and Gnuk 1.2. They are permitted to accept it, especially if they really do support 32-bit exponents. That doesn't change the fact that other cards, which implement the spec correctly, will fail. As it stands today, GnuPG cannot switch from ECC to RSA on some smart cards that _correctly_ implement the 'OpenPGP application on ISO Smart Card Operating Systems', and I think that is worth fixing. Thanks, -Trevor From trevor at yubico.com Wed Jul 4 13:10:41 2018 From: trevor at yubico.com (Trevor Bentley) Date: Wed, 4 Jul 2018 13:10:41 +0200 Subject: scd bug: specifying 'e length' for RSA key-attr unsupported In-Reply-To: <4d993e7e-e391-0269-6639-b93d7ba167d7@pietig.com> References: <1be69e47-7571-f66e-e972-743734a264dc@yubico.com> <87d0w3vi5t.fsf@iwagami.gniibe.org> <3d4b5822-0da8-9495-02c0-90b8098740e1@yubico.com> <4d993e7e-e391-0269-6639-b93d7ba167d7@pietig.com> Message-ID: <89924b64-b850-04e6-2851-44c1b4d69d4b@yubico.com> > Some international standards (e. g. ISO 7816-15) define a fixed value for e (65537) and many card implementations follow this. So I definied for the OpenPGP card, that a value of 65537 shall be > accepted, to be compatible to existing cards if they want to add the OpenPGP card application. Other values are optional, depending on the implementation (my implementations allow any running values > for p, q, e). For this reason, I think the current implementation in GnuPG should change to send a bit length of 17. This is backed by two reasons: 1) All cards that implement the OpenPGP for Smart Cards spec must support it, and presumably Gnuk and the others will keep working. 2) GnuPG's 'gen-key' already defaults to 65537, and sends bit length 17 to KEY-ATTR when importing keys. So gpg is already defaulting to 17 everywhere except when switching the card from EC to RSA mode. > The best thing to me to solve this is a new information DO, where all supported algorithms of an implementation are listed with their min/max values. This new object will not 'disturbe' older > implementions and can be evalutated for setting new algorithm attributes and for key import. > > If you and Niibe agree, I will make a proposal and add it to the next specification. > The actual version of the specification however is 3.3.2 that I sent to Werner some time ago, but there are no new functionalities - only editorial enhancements and many examples. Yes, I agree with this. It should support either min/max length for cards that support ranges, or a list of discrete values for cards with absolute requirements. A card might support _exactly_ e=3 or e=65537, for instance, and specifying the range "2 to 17 bits" isn't quite right. It is similarly common to only support discrete n lengths, e.g. n=1024/2048/3072/4096. I strongly suggest that the response should clearly mark what the card considers 'default' for an algorithm. It should be trivial for GnuPG to ask the card what settings it wants and set it to that, without having to make any guesses or assumptions. Thanks, -Trevor From achim at pietig.com Wed Jul 4 11:54:06 2018 From: achim at pietig.com (Achim Pietig) Date: Wed, 4 Jul 2018 11:54:06 +0200 Subject: scd bug: specifying 'e length' for RSA key-attr unsupported In-Reply-To: <3d4b5822-0da8-9495-02c0-90b8098740e1@yubico.com> References: <1be69e47-7571-f66e-e972-743734a264dc@yubico.com> <87d0w3vi5t.fsf@iwagami.gniibe.org> <3d4b5822-0da8-9495-02c0-90b8098740e1@yubico.com> Message-ID: <4d993e7e-e391-0269-6639-b93d7ba167d7@pietig.com> Hi all, the problem is not the definition of the Algorithm Attributes, but the lack of an information object to see what functions the card will support. I often got questions what algorithm the card supports - the actual definitions are presenting the 'status quo' only, but not other features of the implemention. See my answers to your discussion in between the text below. Regards Achim Am 04.07.2018 um 10:26 schrieb Trevor Bentley: >> In my opinion, the key attributes are not well defined in the spec and >> host software needs guessing about behavior of card implementation. > > I mostly agree.? The spec does state that all cards must support 65537, so at least there is a known value that can always be chosen.? But ideally, the smartcard spec would allow sending a special > value (or omitting the field) to means 'card default'.? And ideally, GnuPG would still provide some method for the user to explicitly set a desired e bit len if the user does not want the default. > > I've added Achim to this thread, as it would be nice to get his input. > >> According to the spec, there is no information which key attribute >> (value and format) is supported by a specific card.? Here, host software >> needs guessing. >> >> In the spec, IIRC, it suggests the value "32" for e's length in the key >> attributes, as well as the value 65537.? Well, 65537 can be represented >> by 32-bit.? IIRC, there is no place in the spec suggesting 17.? I know >> that with the background of OpenPGP format itself, 17 makes sense. > --> The Algorithm Attributs only define the format of the key representation (e. g. for key import), but not the allowed content. In principle any running values are allowed, only the representation/format shall be in accordance with the alg-attributs - with some exceptions ;) Some international standards (e. g. ISO 7816-15) define a fixed value for e (65537) and many card implementations follow this. So I definied for the OpenPGP card, that a value of 65537 shall be accepted, to be compatible to existing cards if they want to add the OpenPGP card application. Other values are optional, depending on the implementation (my implementations allow any running values for p, q, e). The actual definition is 15 years old and many features where added without changing several data Objects (DO), with respect to existing implmentations. In most cases we add new DOs that can be used for new functionalities. I think the actual definition is OK for that purpose - for addressing your problem (what values are allowed) a new information object maybe helpful. > The spec doesn't provide a way to check if a length is supported. However, it is clear about 65537 being required, and recommends it as default: > > SHALL accept (required): > -- > Some smart cards with RSA algorithm support only one coding for the Public Exponent (e.g. 65537 dec.). The card may reject an imported key, if e does not match the internal requirements. But the card > shall accept 65537 dec. (010001) as value for e. > -- > > SHOULD use (recommended): > -- > The card should use 65537 dec. (10001 bin.) as default value for e, but other values are accepted by the outside world. > -- > > I only see 32 specified in an example, which is just demonstrating that it can be used: > "Length of public exponent e in bit (e. g. 32 bit decimal = 0020), binary" > > You are obviously correct that 65537 fits in 32 bits, but cards that don't accept exponents larger than 17 bits are typically going to refuse the larger length.? It may be _permitted_ to accept a > 32-bit length and generate a 17-bit exponent within it, but in practice they almost certainly won't.? And rightly so, since accepting a 32-bit length strongly implies that it can actually handle them. > --> The alg-attributs define the allowed format for presenting keys, actual you cannot see what values an implementiation will accept - you only know that all cards will/must accept e=65537. You are rigth, that other values must be known by the outside world by knowledge (e. g. data sheet of the card) or try and error. >>> I believe this needs to be fixed in one of two ways: >>> 1) add an 'e length' argument to KEY-ATTR (and possibly a matching UI) >>> 2) use '17' instead of '32' as the hard-coded length, since all cards >>> are required to support it >> >> Or, you can ask change of OpenPGP card implementation, following other >> OpenPGP card implementations.? And make things explicit in the spec. > --> The problem does not only appear to the value of e, but to all values that can be set in algorithm attributs (what algos do the card support? What key length for RSA or ELC?). GnuPG actual is orientated to the my implementions and GNUK for historic reasons, there where not many implementations in the past ;) The best thing to me to solve this is a new information DO, where all supported algorithms of an implementation are listed with their min/max values. This new object will not 'disturbe' older implementions and can be evalutated for setting new algorithm attributes and for key import. If you and Niibe agree, I will make a proposal and add it to the next specification. The actual version of the specification however is 3.3.2 that I sent to Werner some time ago, but there are no new functionalities - only editorial enhancements and many examples. > I would suggest that as an 'and' instead of an 'or'.? I think it's best for GnuPG to support the existing spec as well as possible, and to encourage the spec to improve. > >>> -- >>> $ gpg-connect-agent "SCD SETATTR KEY-ATTR --force 1 1 rsa2048" /bye >>> OK >>> $ gpg-connect-agent "SCD SETATTR KEY-ATTR --force 1 19 nistp256" /bye >>> OK >>> $ gpg-connect-agent "SCD SETATTR KEY-ATTR --force 1 1 rsa2048" /bye >> >> Here, it returns "OK" for Achim's OpenPGPcard (I have the test version >> of 3.3) and Gnuk 1.2. > > They are permitted to accept it, especially if they really do support 32-bit exponents.? That doesn't change the fact that other cards, which implement the spec correctly, will fail. > --> The specification allows other length codings for e, so if an implementation sets the algorithm attributs to a different length than 32 bits, it should work (should be accepted by GnuPG and other software). My implementations always use 32 bits for e-values - so it may be possible that other length expressions are not tested in the past, by lack of test cards... > As it stands today, GnuPG cannot switch from ECC to RSA on some smart cards that _correctly_ implement the 'OpenPGP application on ISO Smart Card Operating Systems', and I think that is worth fixing. > > Thanks, > > -Trevor > > From achim at pietig.com Thu Jul 5 10:40:39 2018 From: achim at pietig.com (Achim Pietig) Date: Thu, 5 Jul 2018 10:40:39 +0200 Subject: scd bug: specifying 'e length' for RSA key-attr unsupported In-Reply-To: <89924b64-b850-04e6-2851-44c1b4d69d4b@yubico.com> References: <1be69e47-7571-f66e-e972-743734a264dc@yubico.com> <87d0w3vi5t.fsf@iwagami.gniibe.org> <3d4b5822-0da8-9495-02c0-90b8098740e1@yubico.com> <4d993e7e-e391-0269-6639-b93d7ba167d7@pietig.com> <89924b64-b850-04e6-2851-44c1b4d69d4b@yubico.com> Message-ID: <47c1cd80-35c1-a9a3-28d0-c15875bd8f42@pietig.com> Hi, I think there is a missunderstanding in the meaning of the key format (lenght of e). The given length in the Algorithm Attributes is the format representation and has nothing to do with the legnth of the content. For im-/export of public and private keys an ASN.1 coding is used, this format can handle only full bytes (1 byte = 8 bits). To present a content of 65537, you need at least 3 bytes, filled up with leading zero bits. Because 3 byte is an uncommon representation we decided to use 4 bytes or 32 bits (unsigned long) for the representation of e-values. It is not possible to code 17 for the length, all length information in the Algorithm Attributs shall have a value that can be divided by 8 without remainder. This is valid for keys (p, q) also - they have to be filled up with leading zeros. If there is a need to see the supported values of the card, like algorithms and their possible length, an additional DO is needed, where all this information of the card features are stored. It can be evalutated before changing the Algorithm Attributs and/or for key im-/export. >> Yes, I agree with this. It should support either min/max length for cards that support ranges, or a list of discrete values for cards with absolute requirements. A card might support _exactly_ >> e=3 or e=65537, for instance, and specifying the range "2 to 17 bits" isn't quite right. It is similarly common to only support discrete n lengths, e.g. n=1024/2048/3072/4096. I think this DO should contain each supported algorithm (like RSA, EC-ANSI, EC-brainpool) in a list with their specific values as range or fixed entry. The representation to the outside world then is still in compliance with the definitions in Algorithm Attributes. Regards Achim Am 04.07.2018 um 13:10 schrieb Trevor Bentley: >> Some international standards (e. g. ISO 7816-15) define a fixed value for e (65537) and many card implementations follow this. So I definied for the OpenPGP card, that a value of 65537 shall be >> accepted, to be compatible to existing cards if they want to add the OpenPGP card application. Other values are optional, depending on the implementation (my implementations allow any running values >> for p, q, e). > > For this reason, I think the current implementation in GnuPG should change to send a bit length of 17.? This is backed by two reasons: > > 1) All cards that implement the OpenPGP for Smart Cards spec must support it, and presumably Gnuk and the others will keep working. > > 2) GnuPG's 'gen-key' already defaults to 65537, and sends bit length 17 to KEY-ATTR when importing keys.? So gpg is already defaulting to 17 everywhere except when switching the card from EC to RSA mode. > >> The best thing to me to solve this is a new information DO, where all supported algorithms of an implementation are listed with their min/max values. This new object will not 'disturbe' older >> implementions and can be evalutated for setting new algorithm attributes and for key import. >> >> If you and Niibe agree, I will make a proposal and add it to the next specification. >> The actual version of the specification however is 3.3.2 that I sent to Werner some time ago, but there are no new functionalities - only editorial enhancements and many examples. > > Yes, I agree with this.? It should support either min/max length for cards that support ranges, or a list of discrete values for cards with absolute requirements.? A card might support _exactly_ e=3 > or e=65537, for instance, and specifying the range "2 to 17 bits" isn't quite right. ?It is similarly common to only support discrete n lengths, e.g. n=1024/2048/3072/4096. > > I strongly suggest that the response should clearly mark what the card considers 'default' for an algorithm.? It should be trivial for GnuPG to ask the card what settings it wants and set it to that, > without having to make any guesses or assumptions. > > Thanks, > > -Trevor > > From trevor at yubico.com Thu Jul 5 14:09:02 2018 From: trevor at yubico.com (Trevor Bentley) Date: Thu, 5 Jul 2018 14:09:02 +0200 Subject: scd bug: specifying 'e length' for RSA key-attr unsupported In-Reply-To: <47c1cd80-35c1-a9a3-28d0-c15875bd8f42@pietig.com> References: <1be69e47-7571-f66e-e972-743734a264dc@yubico.com> <87d0w3vi5t.fsf@iwagami.gniibe.org> <3d4b5822-0da8-9495-02c0-90b8098740e1@yubico.com> <4d993e7e-e391-0269-6639-b93d7ba167d7@pietig.com> <89924b64-b850-04e6-2851-44c1b4d69d4b@yubico.com> <47c1cd80-35c1-a9a3-28d0-c15875bd8f42@pietig.com> Message-ID: > I think there is a missunderstanding in the meaning of the key format (lenght of e). The given length in the Algorithm Attributes is the format representation and has nothing to do with the legnth of > the content. For im-/export of public and private keys an ASN.1 coding is used, this format can handle only full bytes (1 byte = 8 bits). To present a content of 65537, you need at least 3 bytes, > filled up with leading zero bits. Because 3 byte is an uncommon representation we decided to use 4 bytes or 32 bits (unsigned long) for the representation of e-values. It is not possible to code 17 > for the length, all length information in the Algorithm Attributs shall have a value that can be divided by 8 without remainder. This is valid for keys (p, q) also - they have to be filled up with > leading zeros. Hmm, definitely a misunderstanding then. The spec should be updated to clarify that. "Length of public exponent e in bit" certainly implies that it will be the exact length of _e_ in bits, not the... number of bits in the minimum number of 32-bit ints needed to contain it? I'm still unclear on why it's 32 bits instead of 24. Is e=3 encoded as e_bit_len=8 or e_bit_len=32? What about e=0x100000001 (33 bits)? When importing a key, it is ASN.1 encoded and already specifies both the lengths and values of each parameter. Keys can be validated and rejected at time of import, without needing the algorithm attributes DO. Importing is not really a problem, but on-device key generation is. My understanding was that, when calling Generate Asymmetric Key Pair, it should generate a key with the bit lengths specified in Algorithm Attributes. But if those fields aren't actually the bit length of the parameters, but instead the bit length of some larger container, what is the generate command supposed to do? > If there is a need to see the supported values of the card, like algorithms and their possible length, an additional DO is needed, where all this information of the card features are stored. It can be > evalutated before changing the Algorithm Attributs and/or for key im-/export. I still think there is that need, but only if the data can actually be used somehow. Maybe you can walk me through what the expected commands would be in the following situation: Smart Card supports: (1) (RSA n=2048,e=3) (2) (RSA n=2048,e=65537) *default (3) (RSA n=4096,e=257) (4) (RSA n=4096,e=65537) I want to generate (on device) four keys in a row, of type (1) then (2) then (3) then (4). Is that possible, and if so, what would the algorithm attributes be set to before each generate command? If that is not supposed to be possible, then the need for a new DO is much less important. Thanks, Trevor From michael.haubenwallner at ssi-schaefer.com Thu Jul 5 12:51:54 2018 From: michael.haubenwallner at ssi-schaefer.com (Michael Haubenwallner) Date: Thu, 5 Jul 2018 12:51:54 +0200 Subject: [libgpg-error PATCH] doc: if ever, depend on yat2m$(EXEEXT) Message-ID: <35fd68b5-2923-6a7a-ee8f-0f36c2cdd365@ssi-schaefer.com> Cygwin is not a "real" w32 system, and transparently hides the still required '.exe' extension whenever possible. Unfortunately, this does not apply to Makefile targets, so we still have to use '.exe' here. Fortunately, there is the portable EXEEXT Makefile variable we can use. Furthermore, we want to use a detected yat2m utility only if we are cross compiling, but we do not need a Makefile dependency then. Otherwise, the just created yat2m utility should work fine. * doc/Makefile.am (CROSS_COMPILING, HAVE_YAT2M): Set empty YAT2M_DEP. (not CROSS_COMPILING): Ignore detected yat2m, use local one. Use EXEEXT in YAT2M_DEP rather than explicit '.exe' based on HAVE_W32_SYSTEM. -- Analysis for the problem on Cygwin when YAT2M_DEP does lack EXEEXT: * make has a default rule to create 'yat2m' from 'yat2m.c' (uses CC) * gcc transparently adds '.exe' when creating executables for Cygwin * 'yat2m.exe' created from default rule does perfectly work * automake generates the 'yat2m$(EXEEXT)' Makefile target (uses libtool) * with EXEEXT=.exe, Makefile has both targets 'yat2m' and 'yat2m.exe' * parallel make does execute commands for both targets in parallel * both targets really create 'yat2m.exe', overwriting each other... --- doc/Makefile.am | 15 +++++---------- 1 file changed, 5 insertions(+), 10 deletions(-) diff --git a/doc/Makefile.am b/doc/Makefile.am index 6f3e5a1..3fff0a6 100644 --- a/doc/Makefile.am +++ b/doc/Makefile.am @@ -37,26 +37,21 @@ myman_pages = gpg-error-config.1 man_MANS = $(myman_pages) +if CROSS_COMPILING if HAVE_YAT2M YAT2M_CMD = $(YAT2M) -YAT2M_DEP = $(YAT2M) +YAT2M_DEP = else -if CROSS_COMPILING YAT2M_CMD = ./yat2m-for-build YAT2M_DEP = yat2m-for-build CLEANFILES += yat2m-for-build yat2m-for-build: yat2m.c $(CC_FOR_BUILD) -o $@ $(srcdir)/yat2m.c -else -if HAVE_W32_SYSTEM -YAT2M_CMD = ./yat2m.exe -YAT2M_DEP = yat2m.exe -else -YAT2M_CMD = ./yat2m -YAT2M_DEP = yat2m -endif endif +else +YAT2M_CMD = ./yat2m$(EXEEXT) +YAT2M_DEP = yat2m$(EXEEXT) endif yat2m-stamp: $(myman_sources) $(srcdir)/version.texi -- 2.16.1 From wk at gnupg.org Thu Jul 5 16:26:04 2018 From: wk at gnupg.org (Werner Koch) Date: Thu, 05 Jul 2018 16:26:04 +0200 Subject: scd bug: specifying 'e length' for RSA key-attr unsupported In-Reply-To: (Trevor Bentley via Gnupg-devel's message of "Thu, 5 Jul 2018 14:09:02 +0200") References: <1be69e47-7571-f66e-e972-743734a264dc@yubico.com> <87d0w3vi5t.fsf@iwagami.gniibe.org> <3d4b5822-0da8-9495-02c0-90b8098740e1@yubico.com> <4d993e7e-e391-0269-6639-b93d7ba167d7@pietig.com> <89924b64-b850-04e6-2851-44c1b4d69d4b@yubico.com> <47c1cd80-35c1-a9a3-28d0-c15875bd8f42@pietig.com> Message-ID: <87muv5vjwj.fsf@wheatstone.g10code.de> Hi! This is not related to the question but let me give this quick remark. > (1) (RSA n=2048,e=3) Never ever use that public exponent. > (2) (RSA n=2048,e=65537) *default For a reason this is the default. For quite some time gpg used 41 but when new low exponent attacks appeared we skipped all others and started to use 65537. > (3) (RSA n=4096,e=257) e might be okay but it is safer to go with 65537 Shalom-Salam, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wiktor at metacode.biz Fri Jul 6 21:49:56 2018 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Fri, 6 Jul 2018 21:49:56 +0200 Subject: GPGME: looking for keys with respect to user settings Message-ID: <2137e9ae-6253-217c-60d2-c068c11cd1a7@metacode.biz> Hello, I'm trying to replicate `gpg --locate-keys $EMAIL` using GPGME and have one question. I'm using `gpgme_op_keylist_ext_start` for starting the search and want to search using whatever is configured in gpg.conf or defaults. `gpgme_set_keylist_mode` [0] seems to take several flags such as GPGME_KEYLIST_MODE_LOCATE but it's a combination of LOCAL and EXTERN search (in case of e-mail address that would be WKD). If I don't specify mode it looks like it's always using LOCAL even if I explicitly set "auto-key-locate local,wkd" in .gnupg/gpg.conf Is this by design that keylist_mode is not set to what is used by --locate-key? (that is GPGME is not using settings used by gpg) A little bit of context: I'm trying to add WKD search in mutt (in case someone enables explicitly encryption and doesn't have the key locally) but a valid question was raised, why isn't GPGME already using what the user has configured in their gpg.conf. Thanks in advance for help! Kind regards, Wiktor [0]: https://www.gnupg.org/documentation/manuals/gpgme/Key-Listing-Mode.html For the record I'm using this sample code for testing: #include #include int main() { gpgme_ctx_t ctx; gpgme_error_t err; gpgme_key_t key; gpgme_keylist_result_t result; setlocale (LC_ALL, ""); gpgme_set_locale (NULL, LC_CTYPE, setlocale (LC_CTYPE, NULL)); gpgme_check_version(NULL); gpgme_new (&ctx); const char* pattern[] = { "wiktor at metacode.biz", 0 }; printf("locating\n"); // uncommenting will explicitly enable WKD // commented out like that will always use LOCAL // gpgme_set_keylist_mode(ctx, GPGME_KEYLIST_MODE_LOCAL | GPGME_KEYLIST_MODE_EXTERN); gpgme_op_keylist_ext_start (ctx, pattern, 0, 0); while (!(err = gpgme_op_keylist_next (ctx, &key))) { fprintf(stdout, "Key ID: %s\n", key->subkeys->keyid); gpgme_key_unref (key); } gpgme_release(ctx); return 0; } -- https://metacode.biz/@wiktor From diveshuttamchandani at gmail.com Sun Jul 8 06:22:23 2018 From: diveshuttamchandani at gmail.com (Divesh Uttamchandani) Date: Sun, 8 Jul 2018 09:52:23 +0530 Subject: GPGME python bindings query Message-ID: Hi, I want to generate revocation certificate for a key using GPGME python bindings. I couldn't find example/docs which explain this. Can someone suggest a way to do so. I am not sure if there is a way, I tried to achieve this by the gpg.Context().interact functionality but couldn't find appropriate commands for certificate generation. Thanks and Regards Divesh Uttamchandani GitHub | Linkedin | University Profile -------------- next part -------------- An HTML attachment was scrubbed... URL: From achim at pietig.com Sun Jul 8 11:27:28 2018 From: achim at pietig.com (Achim Pietig) Date: Sun, 8 Jul 2018 11:27:28 +0200 Subject: scd bug: specifying 'e length' for RSA key-attr unsupported In-Reply-To: References: <1be69e47-7571-f66e-e972-743734a264dc@yubico.com> <87d0w3vi5t.fsf@iwagami.gniibe.org> <3d4b5822-0da8-9495-02c0-90b8098740e1@yubico.com> <4d993e7e-e391-0269-6639-b93d7ba167d7@pietig.com> <89924b64-b850-04e6-2851-44c1b4d69d4b@yubico.com> <47c1cd80-35c1-a9a3-28d0-c15875bd8f42@pietig.com> Message-ID: Hi Trevor, generation of keys is a complete internal function of a card, there is no influence to adjust parameters like e in the command data - all is depending on the development. In your implmentation you are free to set any valid defaults, e maybe fixed or within a range or is calculated by random - it's the choice of the developer. The Algorithm Attributes show how to interpret the key values during im- and export of private and public keys, but do not define internal rules for the generation. So your example with several given values for e will not run within the current definitions. For your needs then a new information DO maybe of less priority. But if an implmentation allows changing of the Algorithm Attributes, it is useful to know what parameters/algorithms are suppported by the card. This cannot be evaluated at the moment and a software that wants to change an algorithm e. g. must know the implementation (internal list etc.). Also for key import it is useful to know what values a card will accept, to avoid try and error. For that purposes I will add such an information DO in the next version, but it will not solve your requirements to set special values for e... Regards Achim Am 05.07.2018 um 14:09 schrieb Trevor Bentley: >> I think there is a missunderstanding in the meaning of the key format (lenght of e). The given length in the Algorithm Attributes is the format representation and has nothing to do with the legnth of >> the content. For im-/export of public and private keys an ASN.1 coding is used, this format can handle only full bytes (1 byte = 8 bits). To present a content of 65537, you need at least 3 bytes, >> filled up with leading zero bits. Because 3 byte is an uncommon representation we decided to use 4 bytes or 32 bits (unsigned long) for the representation of e-values. It is not possible to code 17 >> for the length, all length information in the Algorithm Attributs shall have a value that can be divided by 8 without remainder. This is valid for keys (p, q) also - they have to be filled up with >> leading zeros. > > Hmm, definitely a misunderstanding then.? The spec should be updated to clarify that.? "Length of public exponent e in bit" certainly implies that it will be the exact length of _e_ in bits, not > the... number of bits in the minimum number of 32-bit ints needed to contain it?? I'm still unclear on why it's 32 bits instead of 24.? Is e=3 encoded as e_bit_len=8 or e_bit_len=32?? What about > e=0x100000001 (33 bits)? > > When importing a key, it is ASN.1 encoded and already specifies both the lengths and values of each parameter.? Keys can be validated and rejected at time of import, without needing the algorithm > attributes DO. ?Importing is not really a problem, but on-device key generation is. > > My understanding was that, when calling Generate Asymmetric Key Pair, it should generate a key with the bit lengths specified in Algorithm Attributes.? But if those fields aren't actually the bit > length of the parameters, but instead the bit length of some larger container, what is the generate command supposed to do? > >> If there is a need to see the supported values of the card, like algorithms and their possible length, an additional DO is needed, where all this information of the card features are stored. It can be >> evalutated before changing the Algorithm Attributs and/or for key im-/export. > > I still think there is that need, but only if the data can actually be used somehow. > > Maybe you can walk me through what the expected commands would be in the following situation: > > Smart Card supports: > ?(1) (RSA n=2048,e=3) > ?(2) (RSA n=2048,e=65537) *default > ?(3) (RSA n=4096,e=257) > ?(4) (RSA n=4096,e=65537) > > I want to generate (on device) four keys in a row, of type (1) then (2) then (3) then (4).? Is that possible, and if so, what would the algorithm attributes be set to before each generate command? > > If that is not supposed to be possible, then the need for a new DO is much less important. > > Thanks, > > Trevor > > From aheinecke at intevation.de Mon Jul 9 09:42:17 2018 From: aheinecke at intevation.de (Andre Heinecke) Date: Mon, 09 Jul 2018 09:42:17 +0200 Subject: GPGME: looking for keys with respect to user settings In-Reply-To: <2137e9ae-6253-217c-60d2-c068c11cd1a7@metacode.biz> References: <2137e9ae-6253-217c-60d2-c068c11cd1a7@metacode.biz> Message-ID: <1794032.3tMCQeSNaZ@esus> Hi, On Friday, July 6, 2018 9:49:56 PM CEST Wiktor Kwapisiewicz via Gnupg-devel wrote: > I'm trying to replicate `gpg --locate-keys $EMAIL` using GPGME and have > one question. > > I'm using `gpgme_op_keylist_ext_start` for starting the search and want > to search using whatever is configured in gpg.conf or defaults. You do it right. GPGME_KEYLIST_MODE_LOCATE (or an or of local and extern) uses what is configured in auto-key-locate options. ( Be aware that since 2.1.23 WKD is used by default) > `gpgme_set_keylist_mode` [0] seems to take several flags such as > GPGME_KEYLIST_MODE_LOCATE but it's a combination of LOCAL and EXTERN > search (in case of e-mail address that would be WKD). Right. > If I don't specify mode it looks like it's always using LOCAL even if I > explicitly set "auto-key-locate local,wkd" in .gnupg/gpg.conf Yes. LOCAL is default. So if you don't specify a mode it just does a local keylist. To clarify: LOCAL means "--list-keys" EXTERN means "--search" EXTERN | LOCAL means "--locate-key" > Is this by design that keylist_mode is not set to what is used by > --locate-key? (that is GPGME is not using settings used by gpg) No, I think it's a misunderstanding. To better understand what is going on I recommend: export GPGME_DEBUG=9:/tmp/gpgme.log when testing. Then you can see exactly which calls are made to GnuPG by GPGME. > A little bit of context: I'm trying to add WKD search in mutt (in case > someone enables explicitly encryption and doesn't have the key locally) > but a valid question was raised, why isn't GPGME already using what the > user has configured in their gpg.conf. As stated above, it is. The next Version will be the first with which you can specify "auto-key-locate" options in GPGME ( https://dev.gnupg.org/D463 ) currently GPGME does not touch auto-key-locate at all. Best Regards, Andre -- Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: From ben at adversary.org Mon Jul 9 09:42:52 2018 From: ben at adversary.org (Ben McGinnes) Date: Mon, 9 Jul 2018 17:42:52 +1000 Subject: GPGME python bindings query In-Reply-To: References: Message-ID: <20180709074252.pygp7ys6gmzm3ncl@adversary.org> On Sun, Jul 08, 2018 at 09:52:23AM +0530, Divesh Uttamchandani wrote: > Hi, > > I want to generate revocation certificate for a key using GPGME > python bindings. The only way that GPGME can directly generate a revocation certificate is when one is automatically generated using GnuPG 2.1 or above (you should already be on 2.2 now anyway). This is no different from running either the "gpg --gen-key" or "gpg --full-gen-key" commands and the revocation certificate is generated at the same time as the key itself is. You can, however, revoke user IDs with GPGME and there is an example of that in the later sections of the Python Bindings HOWTO. It's in the sections using this guy for the example instead of Alice or Bob: http://web1.east1.us.adversary.org/wp/wp-content/uploads/2018/07/danger-mouse-20180709-01.jpg > I couldn't find example/docs which explain this. Can someone suggest a way > to do so. No. Some things are intended to be done manually and revoking an entire key is one of them. If it must be automated then current key generation will produce a revocation certificate by default and the solution would be to apply that to a key store and/or any relevant distribution channel (e.g. uploading it to the keyservers). > I am not sure if there is a way, I tried to achieve this by the > gpg.Context().interact functionality but couldn't find appropriate > commands for certificate generation. The gpg.Context().interact function is not intended for interacting with all keys in the same way you might use "gpg --edit-key", it's intended for interacting with cards and tokens which store secret key material. While there are some low level functions present which were necessary for GPGME, and consequently the bindings to it, to do what it does, these functions are not intended to be used directly and are not documented as a result. These are functions which are actually *lower* level than the gpgme_op_* functions. In your case since this is an exploratory project for GSoC, the best approach is that if something you're trying to do is both not immediately apparent and if it were to be performed manually on the command line would produce a whole bunch of warnings to the user to confirm that they're sure and if they really want to do whatever it is; then chances are good that not only is there no way to automate it, but we will also advise against trying to do so by circumventing those warnings. In anticipation of the inevitable question, there's also no function for deleting UIDs or subkeys in GPGME. Normally the window of opportunity for doing anything like that is very narrow and it would be expected to be performed manually and not automated. Instead one would revoke any UID which is no longer valid and there's plenty of examples of that on keys currently in use. Indeed, I've got one on mine right now (it's the fourth one). The following code will display it on any key interactively: c = gpg.Context() fpr = input("Enter key ID or fingerprint: ") key = c.get_key(fpr, secret=False) for i in range(len(key.uids)): if key.uids[i].revoked == 1: print(key.uids[i].uid) else: pass 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 wiktor at metacode.biz Mon Jul 9 10:13:26 2018 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Mon, 9 Jul 2018 10:13:26 +0200 Subject: GPGME: looking for keys with respect to user settings In-Reply-To: <1794032.3tMCQeSNaZ@esus> References: <2137e9ae-6253-217c-60d2-c068c11cd1a7@metacode.biz> <1794032.3tMCQeSNaZ@esus> Message-ID: <4b186e8b-a976-522d-b2c8-83be96f78315@metacode.biz> Hi Andre, You answer, as usual, is exactly what I needed! :) And this table is excellent: > To clarify: > LOCAL means "--list-keys" > EXTERN means "--search" > EXTERN | LOCAL means "--locate-key" I noticed that LOCATE is described as equivalent to --locate-key in the docs: https://www.gnupg.org/documentation/manuals/gpgme/Key-Listing-Mode.html but I didn't think other options work like that. Maybe because I'm thinking in gpg options this translation table really speaks to me. Would it be too much detail if the documentation of keylist_mode also included --list-keys and --search in description of LOCAL and EXTERN? (I didn't have LOCATE define on Ubuntu 18 packages but LOCAL|EXTERN work fine, just like you described). Thanks for the debugging tip and have a nice day! Kind regards, Wiktor -- https://metacode.biz/@wiktor -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 862 bytes Desc: OpenPGP digital signature URL: From aheinecke at intevation.de Mon Jul 9 11:52:41 2018 From: aheinecke at intevation.de (Andre Heinecke) Date: Mon, 09 Jul 2018 11:52:41 +0200 Subject: GPGME: looking for keys with respect to user settings In-Reply-To: <4b186e8b-a976-522d-b2c8-83be96f78315@metacode.biz> References: <2137e9ae-6253-217c-60d2-c068c11cd1a7@metacode.biz> <1794032.3tMCQeSNaZ@esus> <4b186e8b-a976-522d-b2c8-83be96f78315@metacode.biz> Message-ID: <2562350.SVgfRUlQNz@esus> Hi, On Monday, July 9, 2018 10:13:26 AM CEST Wiktor Kwapisiewicz wrote: > You answer, as usual, is exactly what I needed! :) You are welcome. I very much appreciate that you work on adding WKD to other software. ;-) > And this table is excellent: > > > To clarify: > > LOCAL means "--list-keys" > > EXTERN means "--search" > > EXTERN | LOCAL means "--locate-key" > > I noticed that LOCATE is described as equivalent to --locate-key in the > docs: > https://www.gnupg.org/documentation/manuals/gpgme/Key-Listing-Mode.html > but I didn't think other options work like that. Maybe because I'm > thinking in gpg options this translation table really speaks to me. > > Would it be too much detail if the documentation of keylist_mode also > included --list-keys and --search in description of LOCAL and EXTERN? I think it makes sense. Such things were ommited because GPGME tries to abstract such things away. e.g. you can also use that with gpgsm and there EXTERN does not mean --search and in theory. I've added it now as I agree that making it more explicit makes it easier for new users to understand it. Best Regards, Andre -- Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: From trevor at yubico.com Mon Jul 9 14:37:37 2018 From: trevor at yubico.com (Trevor Bentley) Date: Mon, 9 Jul 2018 14:37:37 +0200 Subject: scd bug: specifying 'e length' for RSA key-attr unsupported In-Reply-To: References: <1be69e47-7571-f66e-e972-743734a264dc@yubico.com> <87d0w3vi5t.fsf@iwagami.gniibe.org> <3d4b5822-0da8-9495-02c0-90b8098740e1@yubico.com> <4d993e7e-e391-0269-6639-b93d7ba167d7@pietig.com> <89924b64-b850-04e6-2851-44c1b4d69d4b@yubico.com> <47c1cd80-35c1-a9a3-28d0-c15875bd8f42@pietig.com> Message-ID: <5a389a32-0072-885e-ae07-c45388fc1084@yubico.com> Thanks, Achim. Then I retract this as a bug report, and lower it to a confusing spec report :) I do think you should clarify the language around e length when you add the new DO, though. It's definitely not clear how it is to be used. Also, there is one sentence in the spec that suggests Algorithm Attributes decides how on-device key generation is done: "This DO announces information related to the supported algorithm of the card. ... The formats are used by the key generation in the card..." It is never defined how they are used, but does say that they are. The implication is that on-device generation should match the current Algorithm Attributes. Yubikeys currently choose the RSA bit length of on-device generated keys based on the current Algorithm Attributes. Isn't that the expected behavior? Gnuk appears to do the same. So, in current implementations, both "Algorithm ID" and "Length of modulus n in bit" are used during generation, but "Length of public exponent e in bit" is not. -Trevor On 2018-07-08 11:27, Achim Pietig wrote: > Hi Trevor, > > generation of keys is a complete internal function of a card, there is no influence to adjust parameters like e in the command data - all is depending on the development. > In your implmentation you are free to set any valid defaults, e maybe fixed or within a range or is calculated by random - it's the choice of the developer. > The Algorithm Attributes show how to interpret the key values during im- and export of private and public keys, but do not define internal rules for the generation. > > So your example with several given values for e will not run within the current definitions. For your needs then a new information DO maybe of less priority. > But if an implmentation allows changing of the Algorithm Attributes, it is useful to know what parameters/algorithms are suppported by the card. This cannot be evaluated at the moment and a software > that wants to change an algorithm e. g. must know the implementation (internal list etc.). Also for key import it is useful to know what values a card will accept, to avoid try and error. > For that purposes I will add such an information DO in the next version, but it will not solve your requirements to set special values for e... > > Regards > Achim > > > Am 05.07.2018 um 14:09 schrieb Trevor Bentley: >>> I think there is a missunderstanding in the meaning of the key format (lenght of e). The given length in the Algorithm Attributes is the format representation and has nothing to do with the legnth of >>> the content. For im-/export of public and private keys an ASN.1 coding is used, this format can handle only full bytes (1 byte = 8 bits). To present a content of 65537, you need at least 3 bytes, >>> filled up with leading zero bits. Because 3 byte is an uncommon representation we decided to use 4 bytes or 32 bits (unsigned long) for the representation of e-values. It is not possible to code 17 >>> for the length, all length information in the Algorithm Attributs shall have a value that can be divided by 8 without remainder. This is valid for keys (p, q) also - they have to be filled up with >>> leading zeros. >> >> Hmm, definitely a misunderstanding then.? The spec should be updated to clarify that.? "Length of public exponent e in bit" certainly implies that it will be the exact length of _e_ in bits, not >> the... number of bits in the minimum number of 32-bit ints needed to contain it?? I'm still unclear on why it's 32 bits instead of 24.? Is e=3 encoded as e_bit_len=8 or e_bit_len=32?? What about >> e=0x100000001 (33 bits)? >> >> When importing a key, it is ASN.1 encoded and already specifies both the lengths and values of each parameter.? Keys can be validated and rejected at time of import, without needing the algorithm >> attributes DO. ?Importing is not really a problem, but on-device key generation is. >> >> My understanding was that, when calling Generate Asymmetric Key Pair, it should generate a key with the bit lengths specified in Algorithm Attributes.? But if those fields aren't actually the bit >> length of the parameters, but instead the bit length of some larger container, what is the generate command supposed to do? >> >>> If there is a need to see the supported values of the card, like algorithms and their possible length, an additional DO is needed, where all this information of the card features are stored. It can be >>> evalutated before changing the Algorithm Attributs and/or for key im-/export. >> >> I still think there is that need, but only if the data can actually be used somehow. >> >> Maybe you can walk me through what the expected commands would be in the following situation: >> >> Smart Card supports: >> ?(1) (RSA n=2048,e=3) >> ?(2) (RSA n=2048,e=65537) *default >> ?(3) (RSA n=4096,e=257) >> ?(4) (RSA n=4096,e=65537) >> >> I want to generate (on device) four keys in a row, of type (1) then (2) then (3) then (4).? Is that possible, and if so, what would the algorithm attributes be set to before each generate command? >> >> If that is not supposed to be possible, then the need for a new DO is much less important. >> >> Thanks, >> >> Trevor >> >> From dashohoxha at gmail.com Tue Jul 10 00:35:30 2018 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Tue, 10 Jul 2018 00:35:30 +0200 Subject: About using GPGME, etc. Message-ID: Hi, A couple of years ago I was suggested that using GPGME for implementing EasyGnuPG would be better than using the command `gpg` directly. And indeed I thought that it was a good idea, but I couldn't give it a try because I didn't know Python and I had no more free time left. A couple of months ago I started a GSoC project about this, and now it is almost finished. You can see the changes here: https://github.com/EasyGnuPG/pgpg/pull/84/files?utf8=%E2%9C%93&diff=unified&w=1 (green lines are the original code, and red lines are the new code which replaces the command `gpg` with Python code and GPGME, it is a reverse diff). Now that I look at it, I think that the original code is better, and it is not worth replacing `gpg` by GPGME calls. However I would like to know your opinion as well. The reasons that I think so are these: - `gpg` calls are more compact than the corresponding GPGME code. Basically we are replacing a single line of Bash code with about 20-30 lines of Python code. It can expand even further if all the edge cases are handled properly (right now they are not handled). In my opinion this increases the complexity of the code, makes it more difficult to understand and maintain, and is unnecessary. - Not everything that can be done by the command `gpg` can be achieved through GPGME. So, we still have to rely on `gpg` for some parts of the program. See: https://lists.gnupg.org/pipermail/gnupg-devel/2018-July/033829.html - Even those things that can be achieved by GPGME are not done easier than doing them from `gpg`. For example those actions that need interactivity. My hope was that there would be a better way for doing them in GPGME, but I was disappointed. Either there is no better way, or there is no way at all. - One of the advantages of using GPGME would be that the programmer has better control over the output. Since `gpg` output is meant for the humans, it is difficult to be parsed by the programs, and it is difficult to customize. With GPGME we have better control over the output. However the aim of `egpg` has never been to replace `gpg`, but to make it easier for the users. One of the design goals of `egpg` is that it tries to integrate seamlessly with `gpg`, so that the users can switch to `gpg` easily if they find that the assumptions and the simplified interface of `egpg` restricts them somehow. So, displaying the original messages from `gpg` in this case is actually a god thing, not a bad thing, since it helps the users to get familiar with the `gpg` itself, although they are using `egpg`. In general, I find GPGME an incomplete programming interface (API). For some applications it may be sufficient, but there are certainly cases that it cannot handle. I think that GPGME may become complete only when the `gpg` command itself is built on top of it. I also find odd and not quite suitable for programming the interactive interface. It could have been better if GPGME used a RESTful API for communicating with the GnuPG engine (similar to what most of the web services use nowadays). For example GPGME can send to the server (GnuPG engine in this case) an action and the parameters (the data) needed to perform this action, and then get an answer with a status of the result, the result itself, any error messages, etc. The GPGME (or at least the Python implementation) can also build and present to the applications a higher level of abstraction, for example an object-oriented representation of the data and the actions performed on them. This could make easier to build applications that are based on GPGME. However all these changes for improving GPGME maybe need another GSoC project, or a project wider than that. On the other hand, the `gpg` command itself can try to make easier the life of programmers by: 1 - Trying to offer a batch mode for any action that currently can be done only through interactivity. 2 - Trying to offer a more programmer friendly output. One of the problems with trying to call `gpg` directly on applications is that its output is meant for humans, so it is difficult to be parsed by applications. However the situation would be better if there was an option or an environment variable to tell it to output programming friendly output instead. The format of this output can be JSON, or XML, or whatever can be parsed easily by the applications. It may also be configurable. Implementing these improvements to `gpg` seems to be a big project as well, and it may also be interwoven with the project of improving GPGME. These are my thoughts about building GnuPG based applications. Any opinions would be welcome, especially from other people who have used or are trying to use GPGME on their applications. Regards, Dashamir -------------- next part -------------- An HTML attachment was scrubbed... URL: From gniibe at fsij.org Tue Jul 10 04:12:33 2018 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 10 Jul 2018 11:12:33 +0900 Subject: [libgpg-error PATCH] doc: if ever, depend on yat2m$(EXEEXT) In-Reply-To: <35fd68b5-2923-6a7a-ee8f-0f36c2cdd365@ssi-schaefer.com> References: <35fd68b5-2923-6a7a-ee8f-0f36c2cdd365@ssi-schaefer.com> Message-ID: <87efgbj0tq.fsf@iwagami.gniibe.org> Hello, Thanks for your patch. Michael Haubenwallner writes: > * doc/Makefile.am (CROSS_COMPILING, HAVE_YAT2M): Set empty YAT2M_DEP. > (not CROSS_COMPILING): Ignore detected yat2m, use local one. Use EXEEXT > in YAT2M_DEP rather than explicit '.exe' based on HAVE_W32_SYSTEM. I agree that using EXEEXT is better than HAVE_W32_SYSTEM. Also, I agree that we don't need to use detected yat2m for !CROSS_COMPILING. Furthermore, I also think that the detection of yat2m on build system is not needed for CROSS_COMPILING now, because we can build yat2m-for-build. Remaining problem is we need to have something like EXEEXT for build machine, so that we can support cross building on Windows (say, for POSIX machine). Here is my attempt. How do you think? -- -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-doc-Now-yat2m-is-a-standard-tool-provided-by-libgpg-.patch Type: text/x-diff Size: 1674 bytes Desc: patch 0001 URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-build-Use-AX_CC_FOR_BUILD-and-EXEEXT.patch Type: text/x-diff Size: 5644 bytes Desc: patch 0002 URL: From tookmund at gmail.com Tue Jul 10 19:01:10 2018 From: tookmund at gmail.com (Jacob Adams) Date: Tue, 10 Jul 2018 13:01:10 -0400 Subject: GPGME python bindings query In-Reply-To: <20180709074252.pygp7ys6gmzm3ncl@adversary.org> References: <20180709074252.pygp7ys6gmzm3ncl@adversary.org> Message-ID: On 07/09/2018 03:42 AM, Ben McGinnes wrote: > On Sun, Jul 08, 2018 at 09:52:23AM +0530, Divesh Uttamchandani wrote: >> Hi, >> >> I want to generate revocation certificate for a key using GPGME >> python bindings. > > The only way that GPGME can directly generate a revocation certificate > is when one is automatically generated using GnuPG 2.1 or above (you > should already be on 2.2 now anyway). This is no different from > running either the "gpg --gen-key" or "gpg --full-gen-key" commands > and the revocation certificate is generated at the same time as the > key itself is. > > You can, however, revoke user IDs with GPGME and there is an example > of that in the later sections of the Python Bindings HOWTO. It's in > the sections using this guy for the example instead of Alice or Bob: > > http://web1.east1.us.adversary.org/wp/wp-content/uploads/2018/07/danger-mouse-20180709-01.jpg > >> I couldn't find example/docs which explain this. Can someone suggest a way >> to do so. > > No. Some things are intended to be done manually and revoking an > entire key is one of them. If it must be automated then current key > generation will produce a revocation certificate by default and the > solution would be to apply that to a key store and/or any relevant > distribution channel (e.g. uploading it to the keyservers). I'm actually manually generating a GPG revocation certificate in my own project (by calling gpg from subprocess). I know I shouldn't be doing this, but I didn't see another way (and based on the above there isn't one). I would prefer to use the automatically generated certificate as it also comes with some useful explanation text, but the problem I'm having is that there is no way to trigger this generation from GPGME and it appears to happen whenever you generate your first subkey (or perhaps your first signing subkey, haven't dug that much into it). I'd like to inform the user every time they will be prompted for their password and a random extra password prompt for the revocation certificate that I can't control doesn't really help there. If there's some way I could manually trigger this process that would be great. > In your case since this is an exploratory project for GSoC, the best > approach is that if something you're trying to do is both not > immediately apparent and if it were to be performed manually on the > command line would produce a whole bunch of warnings to the user to > confirm that they're sure and if they really want to do whatever it > is; then chances are good that not only is there no way to automate > it, but we will also advise against trying to do so by circumventing > those warnings. I definitely need to keep this in mind. Thanks, Jacob -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Thu Jul 12 16:42:31 2018 From: wk at gnupg.org (Werner Koch) Date: Thu, 12 Jul 2018 16:42:31 +0200 Subject: [Announce] GnuPG 2.2.9 released Message-ID: <874lh4seg8.fsf@wheatstone.g10code.de> Hello! We are pleased to announce the availability of a new GnuPG release: version 2.2.9. 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.9 =================================== * dirmngr: Fix recursive resolver mode and other bugs in the libdns code. [#3374,#3803,#3610] * dirmngr: When using libgpg-error 1.32 or later a GnuPG build with NTBTLS support (e.g. the standard Windows installer) does not anymore block for dozens of seconds before returning data. If you still have problems on Windows, please consider to use one of the options disable-ipv4 or disable-ipv6. * gpg: Fix bug in --show-keys which actually imported revocation certificates. [#4017] * gpg: Ignore too long user-ID and comment packets. [#4022] * gpg: Fix crash due to bad German translation. Improved printf format compile time check. * gpg: Handle missing ISSUER sub packet gracefully in the presence of the new ISSUER_FPR. [#4046] * gpg: Allow decryption using several passphrases in most cases. [#3795,#4050] * gpg: Command --show-keys now enables the list options show-unusable-uids, show-unusable-subkeys, show-notations and show-policy-urls by default. * gpg: Command --show-keys now prints revocation certificates. [#4018] * gpg: Add revocation reason to the "rev" and "rvs" records of the option --with-colons. [#1173] * gpg: Export option export-clean does now remove certain expired subkeys; export-minimal removes all expired subkeys. [#3622] * gpg: New "usage" property for the drop-subkey filters. [#4019] Getting the Software ==================== Please follow the instructions found at or read on: GnuPG 2.2.9 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.9.tar.bz2 (6503k) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.9.tar.bz2.sig An installer for Windows without any graphical frontend except for a very minimal Pinentry tool is available here: https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.8_20180712.exe (3922k) https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.8_20180712.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.9.tar.bz2 you would use this command: gpg --verify gnupg-2.2.9.tar.bz2.sig gnupg-2.2.9.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.9.tar.bz2, you run the command like this: sha1sum gnupg-2.2.9.tar.bz2 and check that the output matches the next line: e6ef18c2e06175bbe563959c9acc682c02bcd572 gnupg-2.2.9.tar.bz2 aa6753b8443d2b81330dcf1b5d17be743bf1a36a gnupg-w32-2.2.9_20180712.tar.xz a0c234781d85d5ef530636622f3d6d80a8d46b5e gnupg-w32-2.2.9_20180712.exe Internationalization ==================== This version of GnuPG has support for 26 languages with Chinese, Czech, French, German, Japanese, Norwegian, Russian, and Ukrainian being almost completely translated. Documentation and Support ========================= If you used GnuPG in the past you should read the description of changes and new features at doc/whats-new-in-2.1.txt or online at https://gnupg.org/faq/whats-new-in-2.1.html The file gnupg.info has the complete reference manual of the system. Separate man pages are included as well but they miss some of the details availabale only in thee manual. The manual is also available online at https://gnupg.org/documentation/manuals/gnupg/ or can be downloaded as PDF at https://gnupg.org/documentation/manuals/gnupg.pdf . The chapters on gpg-agent, gpg and gpgsm include information on how to set up the whole thing. You may also want to search the GnuPG mailing list archives or ask on the gnupg-users mailing list for advise on how to solve problems. Most of the new features are around for several years and thus enough public experience is available. Please consult the archive of the gnupg-users mailing list before reporting a bug: . We suggest to send bug reports for a new release to this list in favor of filing a bug at . If you need commercial support check out . If you are a developer and you need a certain feature for your project, please do not hesitate to bring it to the gnupg-devel mailing list for discussion. Thanks ====== Maintenance and development of GnuPG is mostly financed by donations. The GnuPG project currently employs one full-time developer and two contractors. All work exclusively on GnuPG and closely related software like Libgcrypt, GPGME, and GPA. We have to thank all the people who helped the GnuPG project, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, and answering questions on the mailing lists. Many thanks to our numerous financial supporters, both corporate and individuals. Without you it would not be possible to keep GnuPG in a good shape and address all the small and larger requests made by our users. Thanks. Happy hacking, Your GnuPG hackers p.s. This is an announcement only mailing list. Please send replies only to the gnupg-users'at'gnupg.org mailing list. p.p.s List of Release Signing Keys: To guarantee that a downloaded GnuPG version has not been tampered by malicious entities we provide signature files for all tarballs and binary versions. The keys are also signed by the long term keys of their respective owners. Current releases are signed by one or more of these four keys: rsa2048 2011-01-12 [expires: 2019-12-31] Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) rsa2048 2014-10-29 [expires: 2019-12-31] Key fingerprint = 46CC 7308 65BB 5C78 EBAB ADCF 0437 6F3E E085 6959 David Shaw (GnuPG Release Signing Key) rsa2048 2014-10-29 [expires: 2020-10-30] Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 NIIBE Yutaka (GnuPG Release Key) rsa3072 2017-03-17 [expires: 2027-03-15] Key fingerprint = 5B80 C575 4298 F0CB 55D8 ED6A BCEF 7E29 4B09 2E28 Andre Heinecke (Release Signing Key) The keys are available at and in any recently released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed by a different key. =========== -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From michael.haubenwallner at ssi-schaefer.com Thu Jul 12 17:15:30 2018 From: michael.haubenwallner at ssi-schaefer.com (Michael Haubenwallner) Date: Thu, 12 Jul 2018 17:15:30 +0200 Subject: [libgpg-error PATCH] doc: if ever, depend on yat2m$(EXEEXT) In-Reply-To: <87efgbj0tq.fsf@iwagami.gniibe.org> References: <35fd68b5-2923-6a7a-ee8f-0f36c2cdd365@ssi-schaefer.com> <87efgbj0tq.fsf@iwagami.gniibe.org> Message-ID: Hello, I've thought about EXEEXT for build too and found AC_PROG_CC_FOR_BUILD to set $BUILD_EXEEXT, but because that was commented out in configure.ac I've not followed that further, as I was not aware of AX_CC_FOR_BUILD at all. So yes, your attempt looks good to me, thanks! /haubi/ On 07/10/2018 04:12 AM, NIIBE Yutaka wrote: > Hello, > > Thanks for your patch. > > Michael Haubenwallner writes: >> * doc/Makefile.am (CROSS_COMPILING, HAVE_YAT2M): Set empty YAT2M_DEP. >> (not CROSS_COMPILING): Ignore detected yat2m, use local one. Use EXEEXT >> in YAT2M_DEP rather than explicit '.exe' based on HAVE_W32_SYSTEM. > > I agree that using EXEEXT is better than HAVE_W32_SYSTEM. Also, I agree > that we don't need to use detected yat2m for !CROSS_COMPILING. > > Furthermore, I also think that the detection of yat2m on build system is > not needed for CROSS_COMPILING now, because we can build > yat2m-for-build. > > Remaining problem is we need to have something like EXEEXT for build > machine, so that we can support cross building on Windows (say, for > POSIX machine). > > Here is my attempt. How do you think? > From michael.haubenwallner at ssi-schaefer.com Thu Jul 12 17:49:04 2018 From: michael.haubenwallner at ssi-schaefer.com (Michael Haubenwallner) Date: Thu, 12 Jul 2018 17:49:04 +0200 Subject: [libgpg-error PATCH] doc: if ever, depend on yat2m$(EXEEXT) In-Reply-To: References: <35fd68b5-2923-6a7a-ee8f-0f36c2cdd365@ssi-schaefer.com> <87efgbj0tq.fsf@iwagami.gniibe.org> Message-ID: On 07/12/2018 05:15 PM, Michael Haubenwallner wrote: > Hello, > > I've thought about EXEEXT for build too and found AC_PROG_CC_FOR_BUILD to > set $BUILD_EXEEXT, but because that was commented out in configure.ac I've > not followed that further, as I was not aware of AX_CC_FOR_BUILD at all. > Ohw, shouldn't the build tools in src/ also use EXEEXT_FOR_BUILD? /haubi/ > So yes, your attempt looks good to me, thanks> > /haubi/ > > On 07/10/2018 04:12 AM, NIIBE Yutaka wrote: >> Hello, >> >> Thanks for your patch. >> >> Michael Haubenwallner writes: >>> * doc/Makefile.am (CROSS_COMPILING, HAVE_YAT2M): Set empty YAT2M_DEP. >>> (not CROSS_COMPILING): Ignore detected yat2m, use local one. Use EXEEXT >>> in YAT2M_DEP rather than explicit '.exe' based on HAVE_W32_SYSTEM. >> >> I agree that using EXEEXT is better than HAVE_W32_SYSTEM. Also, I agree >> that we don't need to use detected yat2m for !CROSS_COMPILING. >> >> Furthermore, I also think that the detection of yat2m on build system is >> not needed for CROSS_COMPILING now, because we can build >> yat2m-for-build. >> >> Remaining problem is we need to have something like EXEEXT for build >> machine, so that we can support cross building on Windows (say, for >> POSIX machine). >> >> Here is my attempt. How do you think? >> -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-build-use-EXEEXT_FOR_BUILD-everywhere.patch Type: text/x-patch Size: 3575 bytes Desc: not available URL: From ben at adversary.org Fri Jul 13 04:42:49 2018 From: ben at adversary.org (Ben McGinnes) Date: Fri, 13 Jul 2018 12:42:49 +1000 Subject: GPGME python bindings query In-Reply-To: References: <20180709074252.pygp7ys6gmzm3ncl@adversary.org> Message-ID: <20180713024249.7rqou4sxowpjpbcu@adversary.org> On Tue, Jul 10, 2018 at 01:01:10PM -0400, Jacob Adams wrote: > On 07/09/2018 03:42 AM, Ben McGinnes wrote: >> On Sun, Jul 08, 2018 at 09:52:23AM +0530, Divesh Uttamchandani wrote: >> >>> I couldn't find example/docs which explain this. Can someone >>> suggest a way to do so. >> >> No. Some things are intended to be done manually and revoking an >> entire key is one of them. If it must be automated then current key >> generation will produce a revocation certificate by default and the >> solution would be to apply that to a key store and/or any relevant >> distribution channel (e.g. uploading it to the keyservers). > > I'm actually manually generating a GPG revocation certificate in my > own project (by calling gpg from subprocess). I know I shouldn't be > doing this, It's a good thing you said that. > but I didn't see another way (and based on the above there isn't > one). Correct. > I would prefer to use the automatically generated certificate as it > also comes with some useful explanation text, but the problem I'm > having is that there is no way to trigger this generation from GPGME > and it appears to happen whenever you generate your first subkey (or > perhaps your first signing subkey, haven't dug that much into it). It's generated with the certification key and this comment indicates there may be a little misunderstanding about the revocation certificate. It's used to revoke an entire key, including subkeys and it does this by the simple expedient of revoking the certification key. Once the certification key is revoked, the certification signatures can't be validated without throwing the disabled key errors which prevent the subkeys from being used. So even if subkeys are added later, there are no additional revocation certificates generated for the subkeys. Which is why you'll find .rev files in $GNUPGHOME/openpgp-revocs.d/ directory matching the fingerprint of the primary key, but nothing for the subkeys; while the $GNUPGHOME/private-keys-v1.d/ is populated with multiple .key files matching the keygrips for all the keys and subkeys generated. > I'd like to inform the user every time they will be prompted for > their password Fair enough, it's good practice to get them used to the idea of it being necessary and reiterating the importance of it without laying it on too thickly. > and a random extra password prompt There are no random extra password prompts, they're all necessary for a secure system. > for the revocation certificate that I can't control doesn't really > help there. If there's some way I could manually trigger this > process that would be great. It should have already occurred when the key was first generated. The only time it needs to be done manually is when issuing a specific revocation certificate with a less generic revocation reason or if the key was generated with an older version of GPG that did not generate such a certificate by default. >> In your case since this is an exploratory project for GSoC, the >> best approach is that if something you're trying to do is both not >> immediately apparent and if it were to be performed manually on the >> command line would produce a whole bunch of warnings to the user to >> confirm that they're sure and if they really want to do whatever it >> is; then chances are good that not only is there no way to automate >> it, but we will also advise against trying to do so by >> circumventing those warnings. > > I definitely need to keep this in mind. Not just you, a lot of people should; the warnings are there for valid reasons and we saw recently with the EFFail situation what happens when MUAs ignore warnings and errors. 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 gniibe at fsij.org Fri Jul 13 05:14:04 2018 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 13 Jul 2018 12:14:04 +0900 Subject: [libgpg-error PATCH] doc: if ever, depend on yat2m$(EXEEXT) In-Reply-To: References: <35fd68b5-2923-6a7a-ee8f-0f36c2cdd365@ssi-schaefer.com> <87efgbj0tq.fsf@iwagami.gniibe.org> Message-ID: <87a7qvq137.fsf@iwagami.gniibe.org> Michael Haubenwallner wrote: >> I've thought about EXEEXT for build too and found AC_PROG_CC_FOR_BUILD to >> set $BUILD_EXEEXT, but because that was commented out in configure.ac I've >> not followed that further, as I was not aware of AX_CC_FOR_BUILD at all. >> > > Ohw, shouldn't the build tools in src/ also use EXEEXT_FOR_BUILD? Good catch. That's right. Please have a look at: https://gnupg.org/faq/HACKING.html#sec-1-3 and send your GnuPG DCO (Developer's Certificate of Origin). The file is available at: https://dev.gnupg.org/source/gnupg/browse/master/doc/DCO And please add "Signed-off-by" line in your commit log, so that I can apply your patch. -- From gniibe at fsij.org Fri Jul 13 07:22:15 2018 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 13 Jul 2018 14:22:15 +0900 Subject: pkg-config? Message-ID: <87a7qvogl4.fsf@iwagami.gniibe.org> Hello, I'd like to adopt pkg-config methodology to GnuPG. I mean, providing PACKAGE.pc. I know that we had discussions in the past. Since then, situation has been changed; pkg-config 0.27 and later allow --with-internal-glib option at configure time. We also have pkgconf now. I think that our concern about dependency to another software is smaller now. So, I think that we can move now. For GnuPG configure, we now have following: gpg-error-config ksba-config libassuan-config libgcrypt-config npth-config ntbtls-config Using those *-config works, but I think that using pkg-config is better. At least, using pkg-config which supports multiple libraries at once, linking can be simplified and accurate. Today, I have a specific problem. These days, libgpg-error is used by many (ksba, assuan, gcrypt, ntbtls, and GnuPG itself). Now, using each *-config, GnuPG's linking has many -lgpg-error. It is only redundant, for normal case, that's true. But for a developer, who installs development version of libgpg-error in /usr/local (and still keep using old libgpg-erro in system), he may encounter a problem, say, if he still uses old ksba package. That's because... while ksba-config --libs returns (for example) -L/usr/lib/x86_64-linux-gnu -lksba -lgpg-error new gpg-error-config --libs returns -L/usr/local/lib -lgpg-error Then, appending those to generate the executable kbxutil in gnugp/kbx, old libgpg-error is selected, unfortunately. I think that now is a good opportunity to move on. Any thoughts? -- From michael.haubenwallner at ssi-schaefer.com Fri Jul 13 09:45:18 2018 From: michael.haubenwallner at ssi-schaefer.com (Michael Haubenwallner) Date: Fri, 13 Jul 2018 09:45:18 +0200 Subject: [libgpg-error PATCH] doc: if ever, depend on yat2m$(EXEEXT) In-Reply-To: <87a7qvq137.fsf@iwagami.gniibe.org> References: <35fd68b5-2923-6a7a-ee8f-0f36c2cdd365@ssi-schaefer.com> <87efgbj0tq.fsf@iwagami.gniibe.org> <87a7qvq137.fsf@iwagami.gniibe.org> Message-ID: On 07/13/2018 05:14 AM, NIIBE Yutaka wrote: > Michael Haubenwallner wrote: >>> I've thought about EXEEXT for build too and found AC_PROG_CC_FOR_BUILD to >>> set $BUILD_EXEEXT, but because that was commented out in configure.ac I've >>> not followed that further, as I was not aware of AX_CC_FOR_BUILD at all. >>> >> >> Ohw, shouldn't the build tools in src/ also use EXEEXT_FOR_BUILD? > > Good catch. That's right. > > > Please have a look at: > > https://gnupg.org/faq/HACKING.html#sec-1-3 > > and send your GnuPG DCO (Developer's Certificate of Origin). > > The file is available at: > > https://dev.gnupg.org/source/gnupg/browse/master/doc/DCO Here we go. > > And please add "Signed-off-by" line in your commit log, so that I can > apply your patch. > Not sure how to deal with my "Signed-off-by" line exceeding the git commit message line length limit of 72 characters. Thanks! /haubi/ -------------- next part -------------- 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: Michael Haubenwallner -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-build-use-EXEEXT_FOR_BUILD-everywhere.patch Type: text/x-patch Size: 3668 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 981 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Fri Jul 13 10:19:53 2018 From: wk at gnupg.org (Werner Koch) Date: Fri, 13 Jul 2018 10:19:53 +0200 Subject: pkg-config? In-Reply-To: <87a7qvogl4.fsf@iwagami.gniibe.org> (NIIBE Yutaka's message of "Fri, 13 Jul 2018 14:22:15 +0900") References: <87a7qvogl4.fsf@iwagami.gniibe.org> Message-ID: <87r2k7r1hy.fsf@wheatstone.g10code.de> On Fri, 13 Jul 2018 07:22, gniibe at fsij.org said: > Since then, situation has been changed; pkg-config 0.27 and later allow > --with-internal-glib option at configure time. We also have pkgconf Which is still a lot of code for a simple task. > and GnuPG itself). Now, using each *-config, GnuPG's linking has > many -lgpg-error. > > It is only redundant, for normal case, that's true. Right (we could enhance the config scripts to remove the duplicates but it would only be cosmetic). > Then, appending those to generate the executable kbxutil in gnugp/kbx, > old libgpg-error is selected, unfortunately. The cumulative effect of -L and its correct ordering is both a problem and a feature. How is pgk-config supposed to solve this? Of course we could do the original test linking stuff again to detect this problem, but there ware may other build problems lingering when you have several versions installed. Shalom-Salam, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From aheinecke at intevation.de Mon Jul 16 09:59:15 2018 From: aheinecke at intevation.de (Andre Heinecke) Date: Mon, 16 Jul 2018 09:59:15 +0200 Subject: pkg-config? In-Reply-To: <87a7qvogl4.fsf@iwagami.gniibe.org> References: <87a7qvogl4.fsf@iwagami.gniibe.org> Message-ID: <2281198.WLL6BQpWJx@esus> Hi, On Friday, July 13, 2018 2:22:15 PM CEST NIIBE Yutaka wrote: > I'd like to adopt pkg-config methodology to GnuPG. I mean, > providing PACKAGE.pc. > > I know that we had discussions in the past. Yes please. I had discussions with Werner about this some time ago and he OK'ed it at least for libgpg-error, libassuan and gpgme as long as it would be additional to the current -config scripts. The rationale was that we want to make it easy for developers to find / link gpgme using standard tools. The cmake find scripts for GnuPG libraries are complicated and uncommon because they also support building natively "on Windows" against precompiled binaries (which is something we support) and there the -config scripts don't work at all. pkg-config files where the prefix variable can be changed would help with that. I just never got around to do it. > Since then, situation has been changed; pkg-config 0.27 and later allow > --with-internal-glib option at configure time. We also have pkgconf > now. I think that our concern about dependency to another software is > smaller now. > > So, I think that we can move now. We are also using pkg-config to find other packages. So in my opinion it is strange that we don't play nice with pgk-config. Best Regards, Andre -- Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: From brian at minton.name Wed Jul 18 22:42:47 2018 From: brian at minton.name (Brian Minton) Date: Wed, 18 Jul 2018 16:42:47 -0400 Subject: PhD project ideas In-Reply-To: References: Message-ID: <64474b5f-9295-b3cb-16dc-69275335091b@minton.name> On 06/09/2018 08:51 AM, Dashamir Hoxha wrote: > I don't know what is WKD, and Keybase as far as I know is centralized, > it is not distributed. > If it was distributed, it would have been a better alternative than > keyservers, in my opinion. > wkd = Web Key Discovery.? https://tools.ietf.org/html/draft-koch-openpgp-webkey-service-06 is the current draft.? Basically, you run a web server with your key on it. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 390 bytes Desc: OpenPGP digital signature URL: From wiktor at metacode.biz Thu Jul 19 14:44:07 2018 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Thu, 19 Jul 2018 14:44:07 +0200 Subject: PhD project ideas In-Reply-To: <64474b5f-9295-b3cb-16dc-69275335091b@minton.name> References: <64474b5f-9295-b3cb-16dc-69275335091b@minton.name> Message-ID: <68c98c64-7355-f307-9b99-9ccad8edd1ff@metacode.biz> >> I don't know what is WKD, and Keybase as far as I know is centralized, >> it is not distributed. >> If it was distributed, it would have been a better alternative than >> keyservers, in my opinion. >> > wkd = Web Key Discovery. > https://tools.ietf.org/html/draft-koch-openpgp-webkey-service-06 is the > current draft.? Basically, you run a web server with your key on it. Yes on own domain, and over HTTPS. Recently WKD is gaining some adoption, e.g. gentoo.org added support for retrieving its developer's keys [0] over WKD. Kind regards, Wiktor [0]: https://gentoo.org/inside-gentoo/developers/ -- https://metacode.biz/@wiktor -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 862 bytes Desc: OpenPGP digital signature URL: From gniibe at fsij.org Fri Jul 20 09:22:19 2018 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 20 Jul 2018 16:22:19 +0900 Subject: pkg-config? In-Reply-To: <87a7qvogl4.fsf@iwagami.gniibe.org> References: <87a7qvogl4.fsf@iwagami.gniibe.org> Message-ID: <87601axtg4.fsf@fsij.org> Hello, again, This week, I struggle with shell programming. (I realized that what I use was mostly bash features.) NIIBE Yutaka wrote: > I'd like to adopt pkg-config methodology to GnuPG. I mean, > providing PACKAGE.pc. I understand that adding requirement of pkg-config to the GnuPG build is not good. I think that it is good to provide *.pc file, for the users of libraries, even if the GnuPG build process doesn't use pkg-config. To be more concrete, how about using a shell script like the one at the end of this mail, with config files which is shared between the script and pkg-config users? ========================>8=>8=>8================== gpg-error.pc prefix=/usr/local exec_prefix=${prefix} includedir=${prefix}/include libdir=${prefix}/lib host=x86_64-pc-linux-gnu Name: gpg-error Description: GPG Runtime Version: 1.32-betaXXX Cflags: -I${includedir} Libs: -L${libdir} -lgpg-error URL: https://www.gnupg.org/software/libgpg-error/index.html ========================>8=>8=>8================== ========================>8=>8=>8================== gpg-error-mt.pc prefix=/usr/local exec_prefix=${prefix} includedir=${prefix}/include libdir=${prefix}/lib host=x86_64-pc-linux-gnu Name: gpg-error Description: GPG Runtime Version: 1.32-betaXXX Cflags: -I${includedir} Libs: -L${libdir} -lgpg-error -pthread URL: https://www.gnupg.org/software/libgpg-error/index.html ========================>8=>8=>8================== Here is an example for gpg-error-config replacement: ========================>8=>8=>8================== #! /bin/sh # # gpg-something-config, using a config file in pkg-config style, so # that we can share such a config file between pkg-config # # # get_var: get the variable value of NAME # # Variables are recorded in the shell variables named "VAR_" get_var () { local name=$1 eval echo \$VAR_$name } # # get_attr: get the attribute value of KEY # # Attributes are recorded in the shell variables named "ATTR_" get_attr () { local name=$1 eval echo \$ATTR_$name } # Remove ${varname} part in the beginning of a string. remove_var_expr () { local varname=$1 shift eval echo \"\${@#\\\$\\\{$varname\\\}}\" } # Given a string, substitute variables. substitute_vars () { local string="$1" local line local varname local result while [ -n "$string" ]; do case "$string" in \$\$*) result="$result\$" string="${string#\$\$}" ;; \${*}*) varname="${string#\$\{}" varname="${varname%%\}*}" result="$result$(get_var ${varname})" string=$(remove_var_expr ${varname} ${string}) ;; *) result="${result}$(printf %c "$string")" string="${string#$(printf %c "$string")}" ;; esac done echo "$result" } # Read a config file read_config_file () { local line local varname local value local key while read line; do case "$line" in *=*) varname="${line%%=*}" value="${line#*=}" VAR_list="$VAR_list VAR_$varname" read VAR_$varname <&2 ;; esac shift done # eval unset $VAR_list VAR_list # eval unset $ATTR_list ATTR_list echo $output ========================>8=>8=>8================== -- From ben at adversary.org Sat Jul 21 11:57:09 2018 From: ben at adversary.org (Ben McGinnes) Date: Sat, 21 Jul 2018 19:57:09 +1000 Subject: pkg-config? In-Reply-To: <87601axtg4.fsf@fsij.org> References: <87a7qvogl4.fsf@iwagami.gniibe.org> <87601axtg4.fsf@fsij.org> Message-ID: <20180721095709.c3vzhq5pxcw3ztbs@adversary.org> On Fri, Jul 20, 2018 at 04:22:19PM +0900, NIIBE Yutaka wrote: > > I understand that adding requirement of pkg-config to the GnuPG > build is not good. > > I think that it is good to provide *.pc file, for the users of > libraries, even if the GnuPG build process doesn't use pkg-config. Sounds reasonable to me. > To be more concrete, how about using a shell script like the one > at the end of this mail, with config files which is shared > between the script and pkg-config users? This might also help me fix a recently discovered issue with the SWIG builds similar to your own observations with multiple installations of dev versions versus system versions. Specifically that SWIG does not appear to be picking up alternative dependencies passed to configure during the compiling of GPGME if there are also versions of those dependencies in $PREFIX and/or $EPREFIX. I'm still looking into where precisely that information gets lost. 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 doron.behar at gmail.com Mon Jul 23 19:55:10 2018 From: doron.behar at gmail.com (Doron Behar) Date: Mon, 23 Jul 2018 20:55:10 +0300 Subject: Improving the command line UI of gpg Message-ID: <20180723175510.lbgq2anufpghh6fy@NUC.doronbehar.com> Hello GnuPG developers, I would like to discuss a subject that has been really bothering me and I hope I'm not the only one. I've been using `gpg` for a while. Honestly, I must say it's command-line user interface is super uncomfortable. Let me explain: The problem resides in the fact that it accepts only `options` (starting with `--` or `-`. Shell completion engines are better built for commands that accept both options and commands. This makes it easier for the user (getting help either from the shell tab completion engine or the program's manual) to distinguish between commands and the optional flags. Inspired by the (super comfortable IMO) command line user interface of `git`, I've had a vision for a new set of `gpg` subcommands and the corresponding arguments and options I think naming them so would be comfortable enough. I've attached a text file with the subcommands and the arguments and options they should accept. I hope it's format is clear. I would really like to improve the usability of `gpg` and I think this is a crucial step towards making it more user friendly. From reading the source code, I've noticed GnuPG implements it's own command line arguments parsing. Maybe it'll be better to use a standard library like `argp.h`? This obviously mean that it would make the next version of `gpg` incompatible with the older versions but I really think it's worth the effort. I'd love to hear your opinions. From doron.behar at gmail.com Mon Jul 23 20:22:18 2018 From: doron.behar at gmail.com (Doron Behar) Date: Mon, 23 Jul 2018 21:22:18 +0300 Subject: Improving the command line UI of gpg Message-ID: <20180723182218.gqiof7rr53eldec6@NUC.doronbehar.com> Hello GnuPG developers, I would like to discuss a subject that has been really bothering me and I hope I'm not the only one. I've been using `gpg` for a while. Honestly, I must say it's command-line user interface is super uncomfortable. Let me explain: The problem resides in the fact that it accepts only `options` (starting with `--` or `-`. Shell completion engines are better built for commands that accept both options and commands. This makes it easier for the user (getting help either from the shell tab completion engine or the program's manual) to distinguish between commands and the optional flags. Inspired by the (super comfortable IMO) command line user interface of `git`, I've had a vision for a new set of `gpg` subcommands and the corresponding arguments and options I think naming them so would be comfortable enough. I've attached a text file with the subcommands and the arguments and options they should accept. I hope it's format is clear. I would really like to improve the usability of `gpg` and I think this is a crucial step towards making it more user friendly. From reading the source code, I've noticed GnuPG implements it's own command line arguments parsing. Maybe it'll be better to use a standard library like `argp.h`? This obviously mean that it would make the next version of `gpg` incompatible with the older versions but I really think it's worth the effort. I'd love to hear your opinions. -------------- next part -------------- sign --clear --detached --no-sign-uid-embed --comment ... --annotate --armor # TODO: relevant? --emit-version --no-emit-version --expiration encrypt --sign --sig-annotation __ --sig-comment __ --sig-policy-url __ --sig-armor # TODO: relevant? --sig-keyserver-url __ --sig-emit-version --sig-no-emit-version --sig-no-uid-embed --sig-expiration --symmetric --files [-] --compression-level ## --auto-locate-key-mechanisms --recipient _ --s2k-cipher-algo _ --s2k-digest-algo _ --s2k-mode ## --s2k-count ## TODO: make the following 3 options have warnings for non pgp complience which could be prevented by `--batch` --compression-preferences __ --digest-preferences __ --cipher-preferences __ --hidden-recipient _ --recipient-file _ --hidden-recipient-file _ --max-size --max-input-size --text --mdc {always,auto,never} --filename _ --for-your-eyes-only === decrypt --lowmem-compression --no-sig-cache --output --output-to-embedded-filename --key __ # or all --no-verify === store # TODO === verify --no-sig-cache === key list --secret --public --signatures --format ... TODO: `--locate-keys`? edit # --all-options... be creative delete --secret-only --public-only export --armor --output --options ## --filter import --merge --source --options ## --filter refresh --server # TODO: add all dirmngr options here --options ... search --server # TODO: add all dirmngr options here options ... fetch --server --options ... generate # --all-options... be creative, include something like --revokation as well add sign --non-exportable (--lsign) --cert-level === TODO: `--list-packets`? === card edit status (default) pin # change pin === trust checkdb (default) updatedb import export === TODO: `--print-md{,s}`? === generate random prime key # just like `mpg key generate` === config ___ # ... === run ... # low priority --gpg === --keyring _ --secret-keyring _ --primary-keyring _ --home _ --config _ --trustdb _ --trusted --trust-model __ --lockdb {once,multiple, never} TODO: `--completes-needed` TODO: `--marginals-needed` TODO: `--tufo-default-policy` TODO: warnings TODO: `--no-random-seed-file` TODO: `--sender` --compliance {rfc4880,rfc4880bis,rfc2440,..} --verbose --debug --batch --log # TODO: Use arguments for these 2 options from page 83 of documentqtion of version ..., including `multiple-messages`, `special-filenames`, `preserve-permissions`, --allow --disallow # TODO: learn about session key From doron.behar at gmail.com Mon Jul 23 20:40:19 2018 From: doron.behar at gmail.com (Doron Behar) Date: Mon, 23 Jul 2018 21:40:19 +0300 Subject: Improving the command line UI of gpg Message-ID: <20180723184019.qkg7ddxytc5vcped@NUC.doronbehar.com> Hello GnuPG developers, I would like to discuss a subject that has been really bothering me and I hope I'm not the only one. I've been using `gpg` for a while. Honestly, I must say it's command-line user interface is super uncomfortable. Let me explain: The problem resides in the fact that it accepts only `options` (starting with `--` or `-`. Shell completion engines are better built for commands that accept both options and commands. This makes it easier for the user (getting help either from the shell tab completion engine or the program's manual) to distinguish between commands and the optional flags. Inspired by the (super comfortable IMO) command line user interface of `git`, I've had a vision for a new set of `gpg` subcommands and the corresponding arguments and options I think naming them so would be comfortable enough. I've attached a text file with the subcommands and the arguments and options each one should accept. I hope the format is clear, it is still a raw draft, I don't understand yet some of the options described in the documentation. I would really like to improve the usability of `gpg` and I think this is a crucial step towards making it more user friendly. From reading the source code, I've noticed GnuPG implements it's own command line arguments parsing. Maybe it'll be better to use a standard library like `argp.h`? This obviously mean that it would make the next version of `gpg` incompatible with the older versions but I really think it's worth the effort. I'd love to hear your opinions. -------------- next part -------------- sign --clear --detached --no-sign-uid-embed --comment ... --annotate --armor # TODO: relevant? --emit-version --no-emit-version --expiration encrypt --sign --sig-annotation __ --sig-comment __ --sig-policy-url __ --sig-armor # TODO: relevant? --sig-keyserver-url __ --sig-emit-version --sig-no-emit-version --sig-no-uid-embed --sig-expiration --symmetric --files [-] --compression-level ## --auto-locate-key-mechanisms --recipient _ --s2k-cipher-algo _ --s2k-digest-algo _ --s2k-mode ## --s2k-count ## TODO: make the following 3 options have warnings for non pgp complience which could be prevented by `--batch` --compression-preferences __ --digest-preferences __ --cipher-preferences __ --hidden-recipient _ --recipient-file _ --hidden-recipient-file _ --max-size --max-input-size --text --mdc {always,auto,never} --filename _ --for-your-eyes-only === decrypt --lowmem-compression --no-sig-cache --output --output-to-embedded-filename --key __ # or all --no-verify === store # TODO === verify --no-sig-cache === key list --secret --public --signatures --format ... TODO: `--locate-keys`? edit # --all-options... be creative delete --secret-only --public-only export --armor --output --options ## --filter import --merge --source --options ## --filter refresh --server # TODO: add all dirmngr options here --options ... search --server # TODO: add all dirmngr options here options ... fetch --server --options ... generate # --all-options... be creative, include something like --revokation as well add sign --non-exportable (--lsign) --cert-level === TODO: `--list-packets`? === card edit status (default) pin # change pin === trust checkdb (default) updatedb import export === TODO: `--print-md{,s}`? === generate random prime key # just like `mpg key generate` === config ___ # ... === run ... # low priority --gpg === --keyring _ --secret-keyring _ --primary-keyring _ --home _ --config _ --trustdb _ --trusted --trust-model __ --lockdb {once,multiple, never} TODO: `--completes-needed` TODO: `--marginals-needed` TODO: `--tufo-default-policy` TODO: warnings TODO: `--no-random-seed-file` TODO: `--sender` --compliance {rfc4880,rfc4880bis,rfc2440,..} --verbose --debug --batch --log # TODO: Use arguments for these 2 options from page 83 of documentqtion of version ..., including `multiple-messages`, `special-filenames`, `preserve-permissions`, --allow --disallow # TODO: learn about session key From dashohoxha at gmail.com Tue Jul 24 00:22:57 2018 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Tue, 24 Jul 2018 00:22:57 +0200 Subject: Improving the command line UI of gpg In-Reply-To: <20180723182218.gqiof7rr53eldec6@NUC.doronbehar.com> References: <20180723182218.gqiof7rr53eldec6@NUC.doronbehar.com> Message-ID: On Mon, Jul 23, 2018 at 9:34 PM Doron Behar wrote: > Hello GnuPG developers, > > I would like to discuss a subject that has been really bothering me and > I hope I'm not the only one. > I am not a genuine GnuPG developer, I am rather a user. I have noticed it as well that the commands and sub-commands of `gpg` are not clearly distinguishable from their options, and this makes it difficult to use (or to understand a command in a script). So I think that your proposal is a good idea. I also have noticed that `gpg` does more things that it needs to do. For example, why should it do compression, when there are lots of tools out there for doing compression? But maybe I am missing something, since I am not an expert on cryptographic things. > > I've been using `gpg` for a while. Honestly, I must say it's > command-line user interface is super uncomfortable. Let me explain: > > The problem resides in the fact that it accepts only `options` (starting > with `--` or `-`. Shell completion engines are better built for commands > that accept both options and commands. This makes it easier for the user > (getting help either from the shell tab completion engine or the > program's manual) to distinguish between commands and the optional > flags. > > Inspired by the (super comfortable IMO) command line user interface of > `git`, I've had a vision for a new set of `gpg` subcommands and the > corresponding arguments and options I think naming them so would be > comfortable enough. I've attached a text file with the subcommands and > the arguments and options they should accept. I hope it's format is > clear. > > I would really like to improve the usability of `gpg` and I think this > is a crucial step towards making it more user friendly. From reading the > source code, I've noticed GnuPG implements it's own command line > arguments parsing. Maybe it'll be better to use a standard library like > `argp.h`? > > This obviously mean that it would make the next version of `gpg` > incompatible with the older versions but I really think it's worth the > effort. > Maybe it can preserve the backwards compatibility, but the code will have to be a little bit more complex. > > I'd love to hear your opinions. > By the way, can you have a look at this: https://github.com/EasyGnuPG/egpg It is an attempt to make GnuPG easier for beginners, and it uses the model of sub-commands that you describe. Regards, Dashamir -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Tue Jul 24 08:51:29 2018 From: wk at gnupg.org (Werner Koch) Date: Tue, 24 Jul 2018 08:51:29 +0200 Subject: Improving the command line UI of gpg In-Reply-To: <20180723182218.gqiof7rr53eldec6@NUC.doronbehar.com> (Doron Behar's message of "Mon, 23 Jul 2018 21:22:18 +0300") References: <20180723182218.gqiof7rr53eldec6@NUC.doronbehar.com> Message-ID: <87a7qhgm8e.fsf@wheatstone.g10code.de> On Mon, 23 Jul 2018 20:22, doron.behar at gmail.com said: > The problem resides in the fact that it accepts only `options` (starting > with `--` or `-`. Shell completion engines are better built for commands Right. That is how Unix programs work. Granted some tools have a driver program which call different binaries depending on a keyword (command) however they are rare and that is not how gpg works. For example to have something like gpg -v sign --detached FILE the common thing would be for gpg to exec this gpg-sign -v --detached FILE That would require a lot of extra binaries for no good reason. It is also not clear what should count as a global option (-v in the above example) or as a command specific option (e.g. --detached). The matrix would be quiet complicated so that in the end both would not be distinguished. There is only one fact which distinguishes options from commands: Only one command is possible and gpg will complain about. However, it will also warn about certain option combinations. > that accept both options and commands. This makes it easier for the user > (getting help either from the shell tab completion engine or the > program's manual) to distinguish between commands and the optional Why? > Inspired by the (super comfortable IMO) command line user interface of > `git`, I've had a vision for a new set of `gpg` subcommands and the > corresponding arguments and options I think naming them so would be We won't change the command line API of gpg it is a stable API for 20 years and you simply can't change that. Considere what would happend if you chnage the API of tar. > source code, I've noticed GnuPG implements it's own command line > arguments parsing. Maybe it'll be better to use a standard library like > `argp.h`? Nope. argparse is much more flexible and includes a well designed help interface as well as other goodies. Actually it would even be possibe to add some kind of configuration to allow optional specification of commands without the option prefix (--) to mimic the behaviour of, say, git. > This obviously mean that it would make the next version of `gpg` > incompatible with the older versions but I really think it's worth the No way. Salam-Shalom, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From dashohoxha at gmail.com Tue Jul 24 10:20:29 2018 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Tue, 24 Jul 2018 10:20:29 +0200 Subject: Improving the command line UI of gpg In-Reply-To: References: <20180723182218.gqiof7rr53eldec6@NUC.doronbehar.com> Message-ID: On Tue, Jul 24, 2018 at 12:22 AM Dashamir Hoxha wrote: > On Mon, Jul 23, 2018 at 9:34 PM Doron Behar wrote: > >> >> This obviously mean that it would make the next version of `gpg` >> incompatible with the older versions but I really think it's worth the >> effort. >> > > Maybe it can preserve the backwards compatibility, but the code will have > to be a little bit more complex. > I have another vision. It should be possible to create a wrapper program, which accepts the commands and options in the format that is easy for the users (in this case Doron), and internally it just calls `gpg` with the commands and arguments in the current format. This would be fully backwards compatible and at the same time offering users a novel usage that is supposed to be easier (with command-line completion etc.) Actually this is such an easy task that even a good student can do it (assuming that he knows very well all the commands and options of `gpg`, their meaning, when they are used, etc.). It can even be a Bash script. For example one can start from a copy of EasyGnuPG (mentioned below) and customize it for this purpose. > > By the way, can you have a look at this: https://github.com/EasyGnuPG/egpg > It is an attempt to make GnuPG easier for beginners, and it uses the model > of sub-commands that you describe. > Dashamir -------------- next part -------------- An HTML attachment was scrubbed... URL: From rainer.perske at uni-muenster.de Tue Jul 24 10:29:09 2018 From: rainer.perske at uni-muenster.de (Rainer Perske) Date: Tue, 24 Jul 2018 10:29:09 +0200 (CEST) Subject: Improving the command line UI of gpg In-Reply-To: Message-ID: Hello My opinion regarding this request: I completely follow Werner. Don't extend the core GnuPG tool by adding a second user interface into the core without urgent need, risiking unnecessary compatibility issues and even unnecessary security vulnerabilities. If you want another interface, feel free to write a wrapper, based either on the existing command line interface or on GPGME. Kind regards -- Rainer Perske System operations dept. and director of the certification authority (WWUCA) Center for Information Processing (university computer center) Westf?lische Wilhelms-Universit?t Zentrum f?r Informationsverarbeitung Rainer Perske R?ntgenstra?e 7-13 48149 M?nster Germany phone: +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 office: room 006, R?ntgenstra?e 11 site map: http://wwwuv2.uni-muenster.de/uniplan/?action=spot&gebnr=7474 Certification Authority of the University of M?nster (WWUCA): phone: +49 251 83-31590 fax: +49 251 83-31555 e-mail: ca at uni-muenster.de WWW: https://www.uni-muenster.de/WWUCA/ Center for Information Processing: phone: +49 251 83-31600 (Mon-Fri 7:30-17:30) 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 dashohoxha at gmail.com Tue Jul 24 13:56:10 2018 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Tue, 24 Jul 2018 13:56:10 +0200 Subject: Improving the command line UI of gpg In-Reply-To: References: Message-ID: On Tue, Jul 24, 2018 at 12:34 PM Rainer Perske < rainer.perske at uni-muenster.de> wrote: > Hello > > My opinion regarding this request: I completely follow Werner. Don't > extend the core GnuPG tool by adding a second user interface into the > core without urgent need, risiking unnecessary compatibility issues > and even unnecessary security vulnerabilities. If you want another > interface, feel free to write a wrapper, based either on the existing > command line interface or on GPGME. > As far as I know, GPGME is not an option for this task, because it does not cover all the functionality of `gpg`. Even if it did, you have to implement your own logic with GPGME, which is a burden and also risky. So, the only option is to use the `gpg` command itself. Dashamir -------------- next part -------------- An HTML attachment was scrubbed... URL: From dashohoxha at gmail.com Wed Jul 25 03:04:02 2018 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Wed, 25 Jul 2018 03:04:02 +0200 Subject: Improving the command line UI of gpg In-Reply-To: <48a16cf6-2434-cdf5-e968-ea0e0e2753c0@nopicturesplease.de> References: <48a16cf6-2434-cdf5-e968-ea0e0e2753c0@nopicturesplease.de> Message-ID: On Tue, Jul 24, 2018 at 6:10 PM Holger Smolinski via [gnupg-devel] < gpg-devel at nopicturesplease.de> wrote: > [ . . . ] > If you require a better usable CLI, feel free to create your personal > wrapper script to implement one. It may turn out to be superior to the > current one and people will start using it instead of the old one. > Thanks for the encouragement, but creating my "personal" wrapper script does not seem like a compelling or a good idea to me. It can be successful only if it has the support of the core developers and it is distributed with the official release. Dashamir -------------- next part -------------- An HTML attachment was scrubbed... URL: From jiri.kerestes at trustica.cz Wed Jul 25 11:39:46 2018 From: jiri.kerestes at trustica.cz (Jiri Kerestes) Date: Wed, 25 Jul 2018 11:39:46 +0200 Subject: [PATCH] scd: Add support for Trustica Cryptoucan Message-ID: A non-text attachment was scrubbed... Name: 0001-scd-Add-support-for-Trustica-Cryptoucan.patch Type: text/x-patch Size: 2685 bytes Desc: not available URL: -------------- next part -------------- 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: Jiri Kerestes -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x24DFF780FF952CCA.asc Type: application/pgp-keys Size: 669 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From dirk.gottschalk1980 at googlemail.com Wed Jul 25 12:43:56 2018 From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk) Date: Wed, 25 Jul 2018 12:43:56 +0200 Subject: Improving the command line UI of gpg In-Reply-To: References: <48a16cf6-2434-cdf5-e968-ea0e0e2753c0@nopicturesplease.de> Message-ID: <22f3ce640d5cef16867cbbb678086ec6227f1d40.camel@googlemail.com> Hello. Am Mittwoch, den 25.07.2018, 03:04 +0200 schrieb Dashamir Hoxha: > On Tue, Jul 24, 2018 at 6:10 PM Holger Smolinski via [gnupg-devel] < > gpg-devel at nopicturesplease.de> wrote: > > > [ . . . ] > > If you require a better usable CLI, feel free to create your > > personal > > wrapper script to implement one. It may turn out to be superior to > > the > > current one and people will start using it instead of the old one. > > > Thanks for the encouragement, but creating my "personal" wrapper > script > does not seem like a compelling or a good idea to me. It can be > successful > only if it has the support of the core developers and it is > distributed > with the > official release. I see no reason for a wrapper in the GnuPG release. That's something what's up to the users usecase for gpg. most commands on the CLI which are used on a regular basis are as easy to use as possible, I think. Gpg is used in so many ways by it's users, I wouldn't wonder if even Werner didn't think about some of them, before he heard of them. Distributing wrapper scripts with gnupg is not a goof idea, they would have to be provided for any platform. That means as shell scipts for Linux/Unix, as batch file for windows and so an. Python would not be an option because it would generate a dependency on python, what, for example, means an additional installation for python on windows. For long command line commands I created aliases, where this is enough, or I wrote my own scripts, where it is neccessary. There are even many GUI-Frontends for gpg out there, seahorse and GPA for example, and much more. Blowing up GnuPG itself, or the installation routine to install more dependencies, is nut a good idea, in my opinion. Regards, Dirk -- Dirk Gottschalk Paulusstrasse 6-8 52064 Aachen Tel.: +49 1573 1152350 -------------- 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 jiri.kerestes at trustica.cz Wed Jul 25 15:38:29 2018 From: jiri.kerestes at trustica.cz (Jiri Kerestes) Date: Wed, 25 Jul 2018 15:38:29 +0200 Subject: [Gpg4win-devel] GnuPG with internal CCID driver In-Reply-To: <87d0vbehlq.fsf@wheatstone.g10code.de> References: <87d0vbehlq.fsf@wheatstone.g10code.de> Message-ID: <0ae1f6aa-0414-406d-dd4c-d5e461ef0330@trustica.cz> Hello, On 25.7.2018 12:26, Werner Koch wrote: > I cc Gniibe because he is the maintainer of scdaemon and does all card > stuff these days. Even that you write about Windows, this is not > specific for Gpg4win because Gpg4win uses the standard GnuPG build for > Windows under the hood. So gnupg-devel would be more appropriate - but > this list is also okay as long as we keep Gniibe in the loop. cc'ing gnupg-devel ML. >> I've done some hackery and I have a working w32 GnuPG build with libusb >> support. I'm not very familiar with Gpg4win development history, so >> before I dive into autotools to do this properly: is there any reason >> why Gpg4Win shouldn't be shipped with libusb and internal CCID driver? > > Can you give some more background on this libusb? I would be interested > to support it also on Windows. I just modified configure.ac to use precompiled libusb libraries from SourceForge and included libusb-1.0.dll in build-aux/speedo/w32/inst.nsi. I've included example diff below, but it needs to be done properly (e.g. without hardcoded paths). Windows system setup is described on libusb GitHub wiki [1]. If the USB reader supports WCID [2], then it should work out-of-the-box. I tested this on Windows 10 64-bit with our token. It works either with WinUSB driver installed by Zadig tool, or with automatic WCID WinUSB driver install. [1]: https://github.com/libusb/libusb/wiki/Windows#How_to_use_libusb_on_Windows [2]: https://github.com/pbatard/libwdi/wiki/WCID-Devices diff --git a/build-aux/speedo/w32/inst.nsi b/build-aux/speedo/w32/inst.nsi index fb452d513014088b12a946a76731c123dbbc3c11..ca38498b2550a14aa294b274b2840e31f429377b 100644 --- a/build-aux/speedo/w32/inst.nsi +++ b/build-aux/speedo/w32/inst.nsi @@ -628,6 +628,7 @@ Section "GnuPG" SEC_gnupg File "libexec/dirmngr_ldap.exe" File "libexec/gpg-preset-passphrase.exe" File "libexec/gpg-wks-client.exe" + File "/home/nephirus/MinGW32/dll/libusb-1.0.dll" ClearErrors SetOverwrite try diff --git a/configure.ac b/configure.ac index f77317f369ab247d64dce564197cbfbf943cf473..c89a7cbb3556c669bc5693503a49b4a1190bce9f 100644 --- a/configure.ac +++ b/configure.ac @@ -806,7 +806,7 @@ AM_PATH_KSBA("$NEED_KSBA_API:$NEED_KSBA_VERSION",have_ksba=yes,have_ksba=no) if test "$use_ccid_driver" = auto || test "$use_ccid_driver" = yes; then case "${host}" in *-mingw32*) - LIBUSB_NAME= + LIBUSB_NAME=usb-1.0.dll LIBUSB_LIBS= LIBUSB_CPPFLAGS= ;; @@ -826,6 +826,8 @@ if test "$use_ccid_driver" = auto || test "$use_ccid_driver" = yes; then esac fi if test x"$LIBUSB_NAME" != x ; then + CPPFLAGS="${CPPFLAGS} -I/home/nephirus/include/libusb-1.0" + LDFLAGS="${LDFLAGS} -L/home/nephirus/MinGW32/dll" AC_CHECK_LIB($LIBUSB_NAME, libusb_init, [ LIBUSB_LIBS="-l$LIBUSB_NAME $LIBUSB_LIBS" have_libusb=yes ]) Best regards Jiri -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From dashohoxha at gmail.com Wed Jul 25 21:19:50 2018 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Wed, 25 Jul 2018 21:19:50 +0200 Subject: Improving the command line UI of gpg In-Reply-To: <22f3ce640d5cef16867cbbb678086ec6227f1d40.camel@googlemail.com> References: <48a16cf6-2434-cdf5-e968-ea0e0e2753c0@nopicturesplease.de> <22f3ce640d5cef16867cbbb678086ec6227f1d40.camel@googlemail.com> Message-ID: On Wed, Jul 25, 2018 at 2:03 PM Dirk Gottschalk via Gnupg-devel < gnupg-devel at gnupg.org> wrote: > > I see no reason for a wrapper in the GnuPG release. That's something > what's up to the users usecase for gpg. most commands on the CLI which > are used on a regular basis are as easy to use as possible, I think. > I agree. > > Gpg is used in so many ways by it's users, I wouldn't wonder if even > Werner didn't think about some of them, before he heard of them. > > Distributing wrapper scripts with gnupg is not a goof idea, they would > have to be provided for any platform. That means as shell scipts for > Linux/Unix, as batch file for windows and so an. Python would not be an > option because it would generate a dependency on python, what, for > example, means an additional installation for python on windows. > I don't agree that bash scripts for Linux should be converted to batch files for windows. There are ways though to run bash scripts on windows. For long command line commands I created aliases, where this is enough, > or I wrote my own scripts, where it is neccessary. > In my opinion this confirms the need for making the CLI of GnuPG a bit more user-friendly (or more comfortable, as some people say), so that people don't have to write their own scripts all the time. There are even many GUI-Frontends for gpg out there, seahorse and GPA > for example, and much more. > > Blowing up GnuPG itself, or the installation routine to install more > dependencies, is nut a good idea, in my opinion. > My idea was not to blow up GnuPG (or its installation), but to have more support about this project (or mini-project, or feature, whatever it is). If there is no general consensus that implementing this wrapper would be a good thing, and it can potentially make things a bit easier for the users, and if there is no support from the core developers (at least moral support), there is no point in spending time to implement it. I have been foolish enough in the past to spend time implementing ideas that seemed good and useful to me, and the result has been that nobody has supported them, nobody has helped to implement them, instead people have called them "single-man projects", so not worth of being taken seriously or being trusted. I don't want it to happen again. I don't even see any need for implementing a "personal" wrapper script, if I have to be its only user. It can only be useful if it is meant to be used by lots of users. Regards, Dashamir -------------- next part -------------- An HTML attachment was scrubbed... URL: From dirk.gottschalk1980 at googlemail.com Wed Jul 25 22:04:13 2018 From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk) Date: Wed, 25 Jul 2018 22:04:13 +0200 Subject: Improving the command line UI of gpg In-Reply-To: References: <48a16cf6-2434-cdf5-e968-ea0e0e2753c0@nopicturesplease.de> <22f3ce640d5cef16867cbbb678086ec6227f1d40.camel@googlemail.com> Message-ID: Hi. Am Mittwoch, den 25.07.2018, 21:19 +0200 schrieb Dashamir Hoxha: > On Wed, Jul 25, 2018 at 2:03 PM Dirk Gottschalk via Gnupg-devel < > gnupg-devel at gnupg.org> wrote: > > > > > I see no reason for a wrapper in the GnuPG release. That's > > something > > what's up to the users usecase for gpg. most commands on the CLI > > which > > are used on a regular basis are as easy to use as possible, I > > think. > > > > I agree. > > > > > > Gpg is used in so many ways by it's users, I wouldn't wonder if > > even > > Werner didn't think about some of them, before he heard of them. > > > > Distributing wrapper scripts with gnupg is not a goof idea, they > > would > > have to be provided for any platform. That means as shell scipts > > for > > Linux/Unix, as batch file for windows and so an. Python would not > > be an > > option because it would generate a dependency on python, what, for > > example, means an additional installation for python on windows. > > > > I don't agree that bash scripts for Linux should be converted to > batch > files for windows. There are ways though to run bash scripts on > windows. Yes, with additional software, that's what i talked about. > > For long command line commands I created aliases, where this is > > enough, > > or I wrote my own scripts, where it is neccessary. > > > > In my opinion this confirms the need for making the CLI of GnuPG a > bit > more user-friendly (or more comfortable, as some people say), so that > people don't have to write their own scripts all the time. That's the point. Every user has different claims about the work with gpg. You can't write wrappers for all of them. Sure, the moist used tasks could be wrapped in scripts, that's not a bad idea, but i would offer them as optional add-on. For this you could start a project on GitHub or something like that and propagate it on this list. I think the GnuPG team would even add it to the list of related software on the website, where the GUIs and MTAs are listed, which support gpg. > > There are even many GUI-Frontends for gpg out there, seahorse and GPA > > for example, and much more. > > > > Blowing up GnuPG itself, or the installation routine to install > > more > > dependencies, is nut a good idea, in my opinion. > > > > My idea was not to blow up GnuPG (or its installation), but to have > more support about this project (or mini-project, or feature, > whatever it > is). > If there is no general consensus that implementing this wrapper would > be a good thing, and it can potentially make things a bit easier for > the > users, > and if there is no support from the core developers (at least moral > support), > there is no point in spending time to implement it. Support should be not a problem. Here you get as much support as possible. The development team is still there to help and open for anything. At least on this list, or the users list, help is there as much as possible. That is what I found out in the month I am now following this list. > I have been foolish enough in the past to spend time implementing > ideas that seemed good and useful to me, and the result has been > that nobody has supported them, nobody has helped to implement them, > instead people have called them "single-man projects", so not worth > of being taken seriously or being trusted. I don't want it to happen > again. As far as I know, a long time ago, even GnuPG was a one man show. Yes, many people think this way, I know exactly what you mean, but not all. > I don't even see any need for implementing a "personal" wrapper > script, if I have to be its only user. It can only be useful if it is > meant to be used by lots of users. Just a second. It ain't over, 'till the fat lady sings. Have you any ideas what could or should be implemented in those wrappers? Any suggestions? I think we should at least discuss those things. IMHO this list is the right place for this discussions, especially about things that are not good solved in GnuPG, ot what could be improved with wrappers. Regards, Dirk -- Dirk Gottschalk Paulusstrasse 6-8 52064 Aachen Tel.: +49 1573 1152350 -------------- 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 dirk.gottschalk1980 at googlemail.com Wed Jul 25 23:39:21 2018 From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk) Date: Wed, 25 Jul 2018 23:39:21 +0200 Subject: Improving the command line UI of gpg In-Reply-To: References: <48a16cf6-2434-cdf5-e968-ea0e0e2753c0@nopicturesplease.de> <22f3ce640d5cef16867cbbb678086ec6227f1d40.camel@googlemail.com> <3fcab3c3b926ec25fc8c7eefd513d5f5a380aac9.camel@googlemail.com> Message-ID: <990f3b1d7fb1d7a090a3f190fe55c07659e9aeff.camel@googlemail.com> Hello Dashamir, Am Mittwoch, den 25.07.2018, 23:01 +0200 schrieb Dashamir Hoxha: > On Wed, Jul 25, 2018 at 9:53 PM Dirk Gottschalk < > dirk.gottschalk1980 at googlemail.com> wrote: > > > > > Have you any ideas what could or should be implemented in those > > wrappers? Any suggestions? > > > > It is the idea proposed on the message that started this thread. > Namely, trying to make GnuPG CLI as comfortable as `git` (or similar > to it). > This involves: > - Commands that do not look like options. This is a goot point and could be done with scripts, at least for the long command lines. > - Command line completion of commands and options. I use ZSH with Antigen and various plug-ins and auto-completion with works well with gpg. But I didn't use bash for a long time so I don't know if itz works there, too. > - Separate man page for each command. This could be part of the wrapper scripts package and would be good as explaination for new users. > - Contextual help and instructions that give the right directions > when you don't know what you are doing. This would also be good because the documentation of GnuPG itself is, let's say, far away from complete and is hard to understand for new users. May the main developers excuse me, but that's no secret. ;-) > - As much automated tests as possible (with sharness). What kind of tests do you mean? > - etc. > > I think everyone has used `git`, so there is no need to go to much > details. Yes, as a developer I am a regular user og git. I know what are talking of. The git-... commands. To be honest, I don't use them myself, I use the "long" commands. Regards, Dirk PS: I forgot the list in my last Mail. I forwardet this to the list and added it right here again in the CC field. -- Dirk Gottschalk Paulusstrasse 6-8 52064 Aachen Tel.: +49 1573 1152350 -------------- 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 rainer.perske at uni-muenster.de Wed Jul 25 23:51:53 2018 From: rainer.perske at uni-muenster.de (Rainer Perske) Date: Wed, 25 Jul 2018 23:51:53 +0200 (CEST) Subject: Improving the command line UI of gpg In-Reply-To: Message-ID: Hello, > I have been foolish enough in the past to spend time implementing > ideas that seemed good and useful to me, and the result has been > that nobody has supported them, nobody has helped to implement them, > instead people have called them "single-man projects", so not worth > of being taken seriously or being trusted. I don't want it to happen again. @Dashamir: I do understand your frustration; I have made similar experiences earlier. Perhaps I may give you a piece of advice? :-) > [...] It can only be useful if it is meant to be used by lots of users. Exactly! Improving usability is always a good idea, you are very welcome if you want to contribute. But your current idea is thought far too short: Only IT experts still use the command line, and experts have no problem with the current interface, so they do not need the improvement you are thinking of. Hence you are getting the negative reactions you are experiencing now; you simply have no chance to address lots of users by enhancing the command line interface. So, if you want to improve usability for non-experts, it would be wasting time to enhance the command line interface. Better invest your time in one of the interfaces used by non-expert users: Apps for smartphone and tablet users, graphical interfaces for desktop and laptop users, perhaps better integration into e-mail software etc. In this wide field you can certainly find a project that brings you much more fun. (The "wrapper" I wrote in the last decade is the complete integration of OpenPGP and S/MIME into the webmailer of the university where I am working, not a simple shell script. That webmailer is used by thousands of people daily.) Best wishes -- Rainer Perske System operations dept. and director of the certification authority (WWUCA) Center for Information Processing (university computer center) Westf?lische Wilhelms-Universit?t Zentrum f?r Informationsverarbeitung Rainer Perske R?ntgenstra?e 7-13 48149 M?nster Germany phone: +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 office: room 006, R?ntgenstra?e 11 site map: http://wwwuv2.uni-muenster.de/uniplan/?action=spot&gebnr=7474 Certification Authority of the University of M?nster (WWUCA): phone: +49 251 83-31590 fax: +49 251 83-31555 e-mail: ca at uni-muenster.de WWW: https://www.uni-muenster.de/WWUCA/ Center for Information Processing: phone: +49 251 83-31600 (Mon-Fri 7:30-17:30) 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 gniibe at fsij.org Thu Jul 26 04:40:11 2018 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 26 Jul 2018 11:40:11 +0900 Subject: [Gpg4win-devel] GnuPG with internal CCID driver In-Reply-To: <0ae1f6aa-0414-406d-dd4c-d5e461ef0330@trustica.cz> References: <87d0vbehlq.fsf@wheatstone.g10code.de> <0ae1f6aa-0414-406d-dd4c-d5e461ef0330@trustica.cz> Message-ID: <87h8km67p0.fsf@fsij.org> Jiri Kerestes wrote: > I've done some hackery and I have a working w32 GnuPG build with libusb > support. Great. > I'm not very familiar with Gpg4win development history, so before I > dive into autotools to do this properly: is there any reason why > Gpg4Win shouldn't be shipped with libusb and internal CCID driver? No good technical reason, just historical, I suppose. In the past, I suggested using the internal CCID driver is better (also) for Windows and macOS, but no one has tried so far. With the internal CCID driver, multiple cardreaders/tokens are supported. So, it's good if we can do that on Windows. If the configuration is not that complicated, I will be glad if we can put the internal CCID driver as a default for GPG4Win. In my opinion, the only use case of scdaemon with PC/SC is that a person uses PC/SC for other purposes and cannot stop the service, or it requires some proprietary driver which works with PC/SC. Please note that I don't use Windows, at all. So, my opinion would be irrelevant. (All I do for Windows is cross-build of GnuPG for Windows.) -- From gniibe at fsij.org Thu Jul 26 04:46:39 2018 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 26 Jul 2018 11:46:39 +0900 Subject: [PATCH] scd: Add support for Trustica Cryptoucan In-Reply-To: References: Message-ID: <87d0va67e8.fsf@fsij.org> Jiri Kerestes wrote: > Subject: [PATCH] scd: Add support for Trustica Cryptoucan. Thanks applied and pushed to the master. -- From uri at mit.edu Thu Jul 26 05:27:44 2018 From: uri at mit.edu (Uri Blumenthal) Date: Thu, 26 Jul 2018 03:27:44 +0000 Subject: [Gpg4win-devel] GnuPG with internal CCID driver In-Reply-To: <87h8km67p0.fsf@fsij.org> References: <87d0vbehlq.fsf@wheatstone.g10code.de> <0ae1f6aa-0414-406d-dd4c-d5e461ef0330@trustica.cz>,<87h8km67p0.fsf@fsij.org> Message-ID: <415C97DF-AF8C-4F4F-8AC7-581A97CDA4FD@mit.edu> Considering that there are popular cards on the market that contain multiple applets - OpenPGP and PIV in particular - shipping GnuPG with its own (internal) CCID driver world likely result in a disaster on MacOS. MacOS requires tokend (often provided by OpenSC) for most apps, and native pivtoken for Safari and Apple Mail (and for some system apps). This is compounded by the nasty habit of GnuPG to open the token in exclusive mode (regardless of whether there are other applets on this token, or other apps that may need access - e.g., it wouldn't be unheard of to use a web browser and email client at the same time - and both need to access the token). GnuPG is an important app - but, believe or not, there are other equally important apps that GnuPG must coexist with (for example, in my works a lot of email is S/MIME, and the vast majority of the protected web sites require PIV certs). Sent from my test iPhone > On Jul 25, 2018, at 22:41, NIIBE Yutaka wrote: > > Jiri Kerestes wrote: >> I've done some hackery and I have a working w32 GnuPG build with libusb >> support. > > Great. > >> I'm not very familiar with Gpg4win development history, so before I >> dive into autotools to do this properly: is there any reason why >> Gpg4Win shouldn't be shipped with libusb and internal CCID driver? > > No good technical reason, just historical, I suppose. > > In the past, I suggested using the internal CCID driver is better (also) > for Windows and macOS, but no one has tried so far. > > With the internal CCID driver, multiple cardreaders/tokens are > supported. So, it's good if we can do that on Windows. > > If the configuration is not that complicated, I will be glad if we can > put the internal CCID driver as a default for GPG4Win. > > In my opinion, the only use case of scdaemon with PC/SC is that a person > uses PC/SC for other purposes and cannot stop the service, or it > requires some proprietary driver which works with PC/SC. > > > Please note that I don't use Windows, at all. So, my opinion would be > irrelevant. (All I do for Windows is cross-build of GnuPG for Windows.) > -- > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel From jiri.kerestes at trustica.cz Thu Jul 26 10:46:48 2018 From: jiri.kerestes at trustica.cz (Jiri Kerestes) Date: Thu, 26 Jul 2018 10:46:48 +0200 Subject: [Gpg4win-devel] GnuPG with internal CCID driver In-Reply-To: <415C97DF-AF8C-4F4F-8AC7-581A97CDA4FD@mit.edu> References: <87d0vbehlq.fsf@wheatstone.g10code.de> <0ae1f6aa-0414-406d-dd4c-d5e461ef0330@trustica.cz> <87h8km67p0.fsf@fsij.org> <415C97DF-AF8C-4F4F-8AC7-581A97CDA4FD@mit.edu> Message-ID: <15720a51-6a3d-91c2-c5b7-49fd0ce6f6f7@trustica.cz> I didn't do any thorough testing on MacOS yet, but AFAIK you can always disable internal CCID driver by adding line 'disable-ccid' to your scdaemon.conf. Moreover, this change should affect only Windows builds and devices not using standard Windows USB CCID driver. Best regards Jiri On 26.7.2018 05:27, Uri Blumenthal wrote: > Considering that there are popular cards on the market that contain multiple applets - OpenPGP and PIV in particular - shipping GnuPG with its own (internal) CCID driver world likely result in a disaster on MacOS. MacOS requires tokend (often provided by OpenSC) for most apps, and native pivtoken for Safari and Apple Mail (and for some system apps). > > This is compounded by the nasty habit of GnuPG to open the token in exclusive mode (regardless of whether there are other applets on this token, or other apps that may need access - e.g., it wouldn't be unheard of to use a web browser and email client at the same time - and both need to access the token). > > GnuPG is an important app - but, believe or not, there are other equally important apps that GnuPG must coexist with (for example, in my works a lot of email is S/MIME, and the vast majority of the protected web sites require PIV certs). > > Sent from my test iPhone > >> On Jul 25, 2018, at 22:41, NIIBE Yutaka wrote: >> >> Jiri Kerestes wrote: >>> I've done some hackery and I have a working w32 GnuPG build with libusb >>> support. >> >> Great. >> >>> I'm not very familiar with Gpg4win development history, so before I >>> dive into autotools to do this properly: is there any reason why >>> Gpg4Win shouldn't be shipped with libusb and internal CCID driver? >> >> No good technical reason, just historical, I suppose. >> >> In the past, I suggested using the internal CCID driver is better (also) >> for Windows and macOS, but no one has tried so far. >> >> With the internal CCID driver, multiple cardreaders/tokens are >> supported. So, it's good if we can do that on Windows. >> >> If the configuration is not that complicated, I will be glad if we can >> put the internal CCID driver as a default for GPG4Win. >> >> In my opinion, the only use case of scdaemon with PC/SC is that a person >> uses PC/SC for other purposes and cannot stop the service, or it >> requires some proprietary driver which works with PC/SC. >> >> >> Please note that I don't use Windows, at all. So, my opinion would be >> irrelevant. (All I do for Windows is cross-build of GnuPG for Windows.) >> -- >> >> _______________________________________________ >> Gnupg-devel mailing list >> Gnupg-devel at gnupg.org >> http://lists.gnupg.org/mailman/listinfo/gnupg-devel From uri at mit.edu Thu Jul 26 13:19:35 2018 From: uri at mit.edu (Uri Blumenthal) Date: Thu, 26 Jul 2018 11:19:35 +0000 Subject: [Gpg4win-devel] GnuPG with internal CCID driver In-Reply-To: <15720a51-6a3d-91c2-c5b7-49fd0ce6f6f7@trustica.cz> References: <87d0vbehlq.fsf@wheatstone.g10code.de> <0ae1f6aa-0414-406d-dd4c-d5e461ef0330@trustica.cz> <87h8km67p0.fsf@fsij.org> <415C97DF-AF8C-4F4F-8AC7-581A97CDA4FD@mit.edu>, <15720a51-6a3d-91c2-c5b7-49fd0ce6f6f7@trustica.cz> Message-ID: <53D5B05F-B2A1-4238-919C-288068F59E0A@mit.edu> For MacOS, if 'disable-ccid' in 'scdaemon.conf' works - it would address my concerns. I do not know the consequences of shipping CCID driver on Windows. Since in my world people must use PIV tokens on Windows as well, the new software such as GnuPG shouldn't interfere with those. If it is ensured, either by disabling CCID (like above), or by some other means - then again, all is well. I'd like to mention my other wish - that 'enable-shared' parameter is added to scdaemon.conf to allow sharing of the token between GnuPG, OpenSC, and tokend (platforms I'm concerned with here are MacOS and Linux, though I can envision similar situation on Windows if a user had, e.g., a Yubikey NEO or such, and wanted to use both PIV and OpenPGP applets). I realize the security implications, and think that the trade-off is worth it. Thanks! Sent from my test iPhone > On Jul 26, 2018, at 04:47, Jiri Kerestes wrote: > > I didn't do any thorough testing on MacOS yet, but AFAIK you can always > disable internal CCID driver by adding line 'disable-ccid' to your > scdaemon.conf. Moreover, this change should affect only Windows builds > and devices not using standard Windows USB CCID driver. > > Best regards > > Jiri > >> On 26.7.2018 05:27, Uri Blumenthal wrote: >> Considering that there are popular cards on the market that contain multiple applets - OpenPGP and PIV in particular - shipping GnuPG with its own (internal) CCID driver world likely result in a disaster on MacOS. MacOS requires tokend (often provided by OpenSC) for most apps, and native pivtoken for Safari and Apple Mail (and for some system apps). >> >> This is compounded by the nasty habit of GnuPG to open the token in exclusive mode (regardless of whether there are other applets on this token, or other apps that may need access - e.g., it wouldn't be unheard of to use a web browser and email client at the same time - and both need to access the token). >> >> GnuPG is an important app - but, believe or not, there are other equally important apps that GnuPG must coexist with (for example, in my works a lot of email is S/MIME, and the vast majority of the protected web sites require PIV certs). >> >> Sent from my test iPhone >> >>> On Jul 25, 2018, at 22:41, NIIBE Yutaka wrote: >>> >>> Jiri Kerestes wrote: >>>> I've done some hackery and I have a working w32 GnuPG build with libusb >>>> support. >>> >>> Great. >>> >>>> I'm not very familiar with Gpg4win development history, so before I >>>> dive into autotools to do this properly: is there any reason why >>>> Gpg4Win shouldn't be shipped with libusb and internal CCID driver? >>> >>> No good technical reason, just historical, I suppose. >>> >>> In the past, I suggested using the internal CCID driver is better (also) >>> for Windows and macOS, but no one has tried so far. >>> >>> With the internal CCID driver, multiple cardreaders/tokens are >>> supported. So, it's good if we can do that on Windows. >>> >>> If the configuration is not that complicated, I will be glad if we can >>> put the internal CCID driver as a default for GPG4Win. >>> >>> In my opinion, the only use case of scdaemon with PC/SC is that a person >>> uses PC/SC for other purposes and cannot stop the service, or it >>> requires some proprietary driver which works with PC/SC. >>> >>> >>> Please note that I don't use Windows, at all. So, my opinion would be >>> irrelevant. (All I do for Windows is cross-build of GnuPG for Windows.) >>> -- >>> >>> _______________________________________________ >>> Gnupg-devel mailing list >>> Gnupg-devel at gnupg.org >>> http://lists.gnupg.org/mailman/listinfo/gnupg-devel > From ben at adversary.org Fri Jul 27 01:22:24 2018 From: ben at adversary.org (Ben McGinnes) Date: Fri, 27 Jul 2018 09:22:24 +1000 Subject: Improving the command line UI of gpg In-Reply-To: References: Message-ID: <20180726232224.243px7fi7ojzjgg4@adversary.org> On Tue, Jul 24, 2018 at 10:29:09AM +0200, Rainer Perske wrote: > Hello > > My opinion regarding this request: I completely follow Werner. Don't > extend the core GnuPG tool by adding a second user interface into > the core without urgent need, risiking unnecessary compatibility > issues and even unnecessary security vulnerabilities. If you want > another interface, feel free to write a wrapper, based either on the > existing command line interface or on GPGME. Right ... except not via yet another wrapper to the existing command line binaries. Use GPGME instead. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From ben at adversary.org Fri Jul 27 03:35:29 2018 From: ben at adversary.org (Ben McGinnes) Date: Fri, 27 Jul 2018 11:35:29 +1000 Subject: Improving the command line UI of gpg In-Reply-To: <22f3ce640d5cef16867cbbb678086ec6227f1d40.camel@googlemail.com> References: <48a16cf6-2434-cdf5-e968-ea0e0e2753c0@nopicturesplease.de> <22f3ce640d5cef16867cbbb678086ec6227f1d40.camel@googlemail.com> Message-ID: <20180727013529.hrrw5opoyce7scik@adversary.org> On Wed, Jul 25, 2018 at 12:43:56PM +0200, Dirk Gottschalk via Gnupg-devel wrote: > > Distributing wrapper scripts with gnupg is not a goof idea, they would > have to be provided for any platform. Right. > That means as shell scipts for Linux/Unix, as batch file for windows > and so an. Python would not be an option because it would generate a > dependency on python, what, for example, means an additional > installation for python on windows. Actually this doesn't necessarily rule out Python in the long run, it would just take a bit more effort on the part of the developer, depending on whether you wanted an embedded Python that was shippeed with the wrapper interface or whether you used a compiler type module to generate platform specific binaries from your wrappers, as is often done with PyInstaller and similar things. Caveats: There are currently other runtime issues with the Python bindings on Windows which are still under investigation; and the bindings did not play nicely with PyInstaller at all the last time I checked, mainly because PyInstaller can only really handle pure Python, ctypes and (maybe) cffi. I haven't checked all the alternatives to PyInstaller either and generally an installation of CPython is preferable anyway. As for "problems" stemming from introducing Windows dependencies in the form of installing Python. I'd say there's a fair argument that anyone seeking an alternative command line interface for GPG on Windows probably wouldn't bat an eyelid at installing Python, would probably already have GPGShell, Kleopatra and GPA installed and be somewhat further ahead of relying merely on a collection of .bat files. Python as a dependency isn't actually the problem for Windows users, the real issue for them is whether GPGME and GPG were compiled with the same runtime as the version of Python they installed. As for what happens when those runtimes do match ... is pending confirmation. 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 wk at gnupg.org Fri Jul 27 09:35:04 2018 From: wk at gnupg.org (Werner Koch) Date: Fri, 27 Jul 2018 09:35:04 +0200 Subject: [Gpg4win-devel] GnuPG with internal CCID driver In-Reply-To: <53D5B05F-B2A1-4238-919C-288068F59E0A@mit.edu> (Uri Blumenthal's message of "Thu, 26 Jul 2018 11:19:35 +0000") References: <87d0vbehlq.fsf@wheatstone.g10code.de> <0ae1f6aa-0414-406d-dd4c-d5e461ef0330@trustica.cz> <87h8km67p0.fsf@fsij.org> <415C97DF-AF8C-4F4F-8AC7-581A97CDA4FD@mit.edu> <15720a51-6a3d-91c2-c5b7-49fd0ce6f6f7@trustica.cz> <53D5B05F-B2A1-4238-919C-288068F59E0A@mit.edu> Message-ID: <87d0v9b07r.fsf@wheatstone.g10code.de> On Thu, 26 Jul 2018 13:19, uri at mit.edu said: > For MacOS, if 'disable-ccid' in 'scdaemon.conf' works - it would address my concerns. It should definitely work because that is the usual Unix code. > I do not know the consequences of shipping CCID driver on > Windows. Since in my world people must use PIV tokens on Windows as I have seen that PIV certs can be used with ssh. This should also work with GnuPG but we could make that even easier. Do you know whether it is possible to get a specimen of such a card or at least sample certificates as they would be stored on the card? > I'd like to mention my other wish - that 'enable-shared' parameter is > added to scdaemon.conf to allow sharing of the token between GnuPG, My usual response for that is that we cache DO from the card due to the slow card I/O and thus shared access may invalidate our idea of the card's state. The real solution is to have other users scdaemon's API to exchange APDUs with the card - but well, other tools can demand the same. Given that our internal CCID driver has a greater flexibility and better control of pinpads we may now consider to use drop the use of the exclusive mode in PC/SC along with a warning in the manual that this may have have unwanted side-effects. Gniibe: What do you think? Shalom-Salam, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From georg at riseup.net Fri Jul 27 09:23:52 2018 From: georg at riseup.net (Georg Faerber) Date: Fri, 27 Jul 2018 07:23:52 +0000 Subject: Keeping (some information of) gpg --card-status private Message-ID: <20180727072352.GA7717@debian> Hi all, I querying a Nitrokey Pro via gpg --card-status, without any PIN needed, the card reveals quite some information, for example the ids of the keys stored on the card. Is there any way around this, for example to make these information available only after a valid PIN was entered? In case it's not, are there any cards out there with which this is possible? Looking forward to any input. Thanks for your work, cheers, Georg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Digital signature URL: From achim at pietig.com Fri Jul 27 13:02:42 2018 From: achim at pietig.com (Achim Pietig) Date: Fri, 27 Jul 2018 13:02:42 +0200 Subject: Keeping (some information of) gpg --card-status private In-Reply-To: <20180727072352.GA7717@debian> References: <20180727072352.GA7717@debian> Message-ID: Hi Georg, most information like key-IDs, fingerprints etc. are set to READ ALWAYS in the card specification - this information is also available in GnuPG (e. g. --list-keys) without any protection. Werner and me defined these policies 15 years ago and no one had any probs with it up to now ;) All implementions that are in compliance with the card specification have the same behaviour. Any change will result in changes for GnuPG and other software that works with the card too. Regrads Achim Am 27.07.2018 um 09:23 schrieb Georg Faerber: > Hi all, > > I querying a Nitrokey Pro via gpg --card-status, without any PIN needed, > the card reveals quite some information, for example the ids of the keys > stored on the card. > > Is there any way around this, for example to make these information > available only after a valid PIN was entered? In case it's not, are > there any cards out there with which this is possible? > > Looking forward to any input. > > Thanks for your work, > cheers, > Georg > > > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > From georg at riseup.net Fri Jul 27 19:12:42 2018 From: georg at riseup.net (Georg Faerber) Date: Fri, 27 Jul 2018 17:12:42 +0000 Subject: Keeping (some information of) gpg --card-status private In-Reply-To: References: <20180727072352.GA7717@debian> Message-ID: <20180727171242.GB7717@debian> Hi Achim, all, On 18-07-27 13:02:42, Achim Pietig wrote: > most information like key-IDs, fingerprints etc. are set to READ > ALWAYS in the card specification - this information is also available > in GnuPG (e. g. --list-keys) without any protection. Alright. Regarding your second point: Yeah, but, for example, imagine a pc using LUKS-encrypted storage: In case the device is turned off, these information are not revealed. > Werner and me defined these policies 15 years ago and no one had any > probs with it up to now ;) I see, thanks, even if this is a bit unfortunate. > All implementions that are in compliance with the card specification > have the same behaviour. Any change will result in changes for GnuPG > and other software that works with the card too. Any other people out there with an opinion regarding this? Any interest in changing the spec (to begin with)? Cheers, Georg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Digital signature URL: From uri at mit.edu Fri Jul 27 19:48:24 2018 From: uri at mit.edu (Uri Blumenthal) Date: Fri, 27 Jul 2018 17:48:24 +0000 Subject: Keeping (some information of) gpg --card-status private In-Reply-To: <20180727171242.GB7717@debian> References: <20180727072352.GA7717@debian> , <20180727171242.GB7717@debian> Message-ID: <2FB696CD-822C-47A4-87A6-94663FDB7187@mit.edu> In my opinion GnuPG should remain as is wrt. the behavior you complain about. This is the correct expected behavior, and it's mirroring what other standards (e.g., CAC and PIV) do. And I for one don't find it unfortunate - I'm happy that it works the way it does. I'm interested in keeping this part of the spec frozen. Sent from my test iPhone > On Jul 27, 2018, at 13:13, Georg Faerber wrote: > > Hi Achim, all, > >> On 18-07-27 13:02:42, Achim Pietig wrote: >> most information like key-IDs, fingerprints etc. are set to READ >> ALWAYS in the card specification - this information is also available >> in GnuPG (e. g. --list-keys) without any protection. > > Alright. > > Regarding your second point: Yeah, but, for example, imagine a pc using > LUKS-encrypted storage: In case the device is turned off, these > information are not revealed. > >> Werner and me defined these policies 15 years ago and no one had any >> probs with it up to now ;) > > I see, thanks, even if this is a bit unfortunate. > >> All implementions that are in compliance with the card specification >> have the same behaviour. Any change will result in changes for GnuPG >> and other software that works with the card too. > > Any other people out there with an opinion regarding this? Any interest > in changing the spec (to begin with)? > > Cheers, > Georg > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel From wk at gnupg.org Sat Jul 28 19:02:25 2018 From: wk at gnupg.org (Werner Koch) Date: Sat, 28 Jul 2018 19:02:25 +0200 Subject: Keeping (some information of) gpg --card-status private In-Reply-To: <20180727171242.GB7717@debian> (Georg Faerber's message of "Fri, 27 Jul 2018 17:12:42 +0000") References: <20180727072352.GA7717@debian> <20180727171242.GB7717@debian> Message-ID: <87sh439tum.fsf@wheatstone.g10code.de> Hi! It is right that OpenPGP has wildcard keyids and thus I understand that you want something similar for the smartcard. However, there are practical problems with that. The only case were this could work smoothly is that you have exactly _one smartcard_ and use it it only for _one device_: You know which smartcard to insert for the device. Now consider what happens if you have several smartcards: You device will request that you insert the smartcard - you enter the PIN and the device will either "unlock" or throw and error. Then you need to use the second card and so on. This will be quite annoying. One of the best features in GnuPG we introduced recently was the support to work with several plugged in smartcards - it makes life much easier. Of course this requires some identification of the keys on the card to make sense. We have lot of experience with the OpenPGP wildcard keyids (--throw-keyid) and it can quickly turn out to be annoying exercise to decrypt something if you have several keys or worse several smartcards: gpg needs to do a lot of trial decryptions and you need to swap smartcards like we swapped floppies back then when we installed Netware 3.0. If you want to hide which key was used to encrypt a partition you can use --throw-keyid and gpg will already ask you to start entering passphrases and swapping smartcards. I am not sure whether LUKS offers this option because I use g13 which supports this. Shalom-Salam, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From dashohoxha at gmail.com Sun Jul 29 19:12:15 2018 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Sun, 29 Jul 2018 19:12:15 +0200 Subject: Problem with connecting to gpg-agent Message-ID: Hi, I have docker container that I use for testing, which normally has a root user, and I have also created a non-root user (called developer). The tests work for the root user but fail for the non-root user. I have been able to localize the problem to this error: ``` $ gpg --list-secret-keys gpg: can't connect to the agent: IPC connect call failed ``` However when it is called with `sudo` it works: ``` $ sudo gpg --list-secret-keys gpg: WARNING: unsafe ownership on homedir '/home/developer/.gnupg' /home/developer/.gnupg/pubring.kbx ---------------------------------- sec rsa4096/18D1DA4D9E7A4FD0 2016-05-14 [SC] [expires: 2026-07-27] A9446F790F9BE7C9D108FC6718D1DA4D9E7A4FD0 uid [ultimate] Test 1 ssb rsa4096/12A2B2669B636DD4 2016-05-14 [E] [expires: 2026-07-27] ``` The version of gpg is 2.2.4 (default installation on bionic). I have run out of ideas about how to debug it further or what might be wrong. This problem does not happen on my host computer (gpg 2.1.18 on stretch). Most probably it is something related to the restrictions of the docker container for the non-root user, or something like this. But I am not able to understand the error message: "can't connect to the agent: IPC connect call failed" Can you help me to debug it further or to fix it? Thanks, Dashamir -------------- next part -------------- An HTML attachment was scrubbed... URL: From James.Bottomley at HansenPartnership.com Sun Jul 29 23:31:48 2018 From: James.Bottomley at HansenPartnership.com (James Bottomley) Date: Sun, 29 Jul 2018 14:31:48 -0700 Subject: [PATCH tpm-work 3/3] tpm2: Make libtss directly linked In-Reply-To: <1532899727.3142.12.camel@HansenPartnership.com> References: <1532899727.3142.12.camel@HansenPartnership.com> Message-ID: <1532899908.3142.16.camel@HansenPartnership.com> In the original proof of concept, the tpm2 handling library (libtss) was dynamically pulled into gpg-agent if it existed. Now that tpm2 handling has been moved out to a separate daemon, gpg-agent will do the right thing if the daemon can't be spawned, so the tss library can be directly linked to the tpm2daemon. Signed-off-by: James Bottomley --- configure.ac | 5 +- tpm2d/Makefile.am | 2 +- tpm2d/tpm2.c | 191 ++++++++++++++++++------------------------------------ 3 files changed, 67 insertions(+), 131 deletions(-) diff --git a/configure.ac b/configure.ac index 5797883b3..7ce050c15 100644 --- a/configure.ac +++ b/configure.ac @@ -1593,10 +1593,13 @@ AC_SUBST(W32SOCKLIBS) # # TPM libtss library .. don't compile TPM support if we don't have it # -AC_CHECK_LIB(tss, TSS_Create, [have_libtss=yes]) +AC_CHECK_LIB(tss, TSS_Create, + [ LIBTSS_LIBS="-ltss $LIBTSS_LIBS" + have_libtss=yes ]) if test "$have_libtss" = yes; then AC_DEFINE(HAVE_LIBTSS, 1, [Defined if we have TPM2 support library]) fi +AC_SUBST(LIBTSS_LIBS) AM_CONDITIONAL(HAVE_LIBTSS, test "$have_libtss" = yes) # diff --git a/tpm2d/Makefile.am b/tpm2d/Makefile.am index 3507ae394..85e9f4267 100644 --- a/tpm2d/Makefile.am +++ b/tpm2d/Makefile.am @@ -14,5 +14,5 @@ tpm2daemon_SOURCES = command.c \ tpm2daemon_LDADD = $(libcommonpth) \ $(LIBGCRYPT_LIBS) $(LIBASSUAN_LIBS) $(NPTH_LIBS) \ - $(GPG_ERROR_LIBS) $(LIBINTL) $(LIBICONV) + $(GPG_ERROR_LIBS) $(LIBINTL) $(LIBICONV) $(LIBTSS_LIBS) endif diff --git a/tpm2d/tpm2.c b/tpm2d/tpm2.c index 4eabcf57a..3b00f6e93 100644 --- a/tpm2d/tpm2.c +++ b/tpm2d/tpm2.c @@ -20,31 +20,6 @@ #include #include -/* List of tss2 functions we use. This is macro jiggery-pokery: - * the F argument gives us the ability to run an arbitrary macro over - * the function list as for each function do macro F */ -#define _TSS2_LIST(F) \ - F(TSS_Create); \ - F(TSS_SetProperty); \ - F(TSS_Execute); \ - F(TSS_ResponseCode_toString); \ - F(TPM2B_PUBLIC_Unmarshal); \ - F(TPM2B_PRIVATE_Unmarshal); \ - F(TSS_TPM2B_PUBLIC_Marshal); \ - F(TSS_TPMT_PUBLIC_Marshal); \ - F(TSS_TPM2B_PRIVATE_Marshal); \ - F(TSS_UINT16_Marshal); \ - F(TSS_TPMT_SENSITIVE_Marshal); \ - F(TSS_SetProperty); \ - F(TSS_GetDigestSize); \ - F(TSS_Hash_Generate); \ - F(TSS_Delete); - -/* create static declarations for the function pointers */ -#define _DL_DECLARE(func) \ - static typeof(func) *p##func -_TSS2_LIST(_DL_DECLARE); - static const char *tpm2_dir; /* The TPM builds a small database of active files representing key @@ -76,54 +51,12 @@ tpm2_set_unique_tssdir(void) return dir; } -/* now dynamically load the tss library (if it exists) and resolve the - * above symbols. This allows us simply to return 0 for tpm2_init on - * systems where there is no TPM library */ -static int -tpm2_init(void) -{ - static int inited = 0; - const char *sym; - void *dl; - - if (inited) - return 0; - - dl = dlopen(TSS2_LIB, RTLD_LAZY); - - if (!dl) - { - log_error("opening of tss2 library failed %s\n", strerror(errno)); - return GPG_ERR_CARD_NOT_PRESENT; - } - - /* load each symbol pointer and check for existence */ -# define _DL_SYM(func) \ - sym = #func; \ - p##func = dlsym(dl, #func); \ - if (p##func == NULL) \ - goto out_symfail - - _TSS2_LIST(_DL_SYM); - - tpm2_dir = tpm2_set_unique_tssdir(); - if (!tpm2_dir) - /* make this non fatal */ - log_error("Failed to set unique TPM directory\n"); - inited = 1; - return 0; - - out_symfail: - log_error("Failed to find symbol %s in tss2 library\n", sym); - return GPG_ERR_CARD_NOT_PRESENT; -} - static void tpm2_error(TPM_RC rc, char *prefix) { const char *msg, *submsg, *num; - pTSS_ResponseCode_toString(&msg, &submsg, &num, rc); + TSS_ResponseCode_toString(&msg, &submsg, &num, rc); log_error("%s gave TPM2 Error: %s%s%s", prefix, msg, submsg, num); } @@ -139,21 +72,21 @@ int tpm2_start(TSS_CONTEXT **tssc) { TPM_RC rc; - int ret; - ret = tpm2_init(); - if (ret) - return ret; + tpm2_dir = tpm2_set_unique_tssdir(); + if (!tpm2_dir) + /* make this non fatal */ + log_error("Failed to set unique TPM directory\n"); - _TSS_CHECK(pTSS_Create(tssc)); - _TSS_CHECK(pTSS_SetProperty(*tssc, TPM_DATA_DIR, tpm2_dir)); + _TSS_CHECK(TSS_Create(tssc)); + _TSS_CHECK(TSS_SetProperty(*tssc, TPM_DATA_DIR, tpm2_dir)); return 0; } void tpm2_end(TSS_CONTEXT *tssc) { - pTSS_Delete(tssc); + TSS_Delete(tssc); } void @@ -165,11 +98,11 @@ tpm2_flush_handle(TSS_CONTEXT *tssc, TPM_HANDLE h) return; in.flushHandle = h; - pTSS_Execute(tssc, NULL, - (COMMAND_PARAMETERS *)&in, - NULL, - TPM_CC_FlushContext, - TPM_RH_NULL, NULL, 0); + TSS_Execute(tssc, NULL, + (COMMAND_PARAMETERS *)&in, + NULL, + TPM_CC_FlushContext, + TPM_RH_NULL, NULL, 0); } static int @@ -195,12 +128,12 @@ tpm2_get_hmac_handle(TSS_CONTEXT *tssc, TPM_HANDLE *handle, ReadPublic_Out rout; rin.objectHandle = salt_key; - rc = pTSS_Execute (tssc, - (RESPONSE_PARAMETERS *)&rout, - (COMMAND_PARAMETERS *)&rin, - NULL, - TPM_CC_ReadPublic, - TPM_RH_NULL, NULL, 0); + rc = TSS_Execute (tssc, + (RESPONSE_PARAMETERS *)&rout, + (COMMAND_PARAMETERS *)&rin, + NULL, + TPM_CC_ReadPublic, + TPM_RH_NULL, NULL, 0); if (rc) { tpm2_error(rc, "TPM2_ReadPublic"); return GPG_ERR_CARD; @@ -211,12 +144,12 @@ tpm2_get_hmac_handle(TSS_CONTEXT *tssc, TPM_HANDLE *handle, * construct the salt */ in.tpmKey = salt_key; } - rc = pTSS_Execute(tssc, - (RESPONSE_PARAMETERS *)&out, - (COMMAND_PARAMETERS *)&in, - (EXTRA_PARAMETERS *)&extra, - TPM_CC_StartAuthSession, - TPM_RH_NULL, NULL, 0); + rc = TSS_Execute(tssc, + (RESPONSE_PARAMETERS *)&out, + (COMMAND_PARAMETERS *)&in, + (EXTRA_PARAMETERS *)&extra, + TPM_CC_StartAuthSession, + TPM_RH_NULL, NULL, 0); if (rc) { tpm2_error(rc, "TPM2_StartAuthSession"); return GPG_ERR_CARD; @@ -246,10 +179,10 @@ tpm2_exec_with_auth(ctrl_t ctrl, TSS_CONTEXT *tssc, if (rc) return rc; - rc = pTSS_Execute(tssc, out, in, NULL, - cmd, - ah, auth, 0, - TPM_RH_NULL, NULL, 0); + rc = TSS_Execute(tssc, out, in, NULL, + cmd, + ah, auth, 0, + TPM_RH_NULL, NULL, 0); gcry_free (auth); if (rc) { tpm2_error(rc, cmd_str); @@ -329,21 +262,21 @@ tpm2_load_key(TSS_CONTEXT *tssc, const unsigned char *shadow_info, buf = (BYTE *)priv; size = priv_len; - pTPM2B_PRIVATE_Unmarshal(&in.inPrivate, &buf, &size); + TPM2B_PRIVATE_Unmarshal(&in.inPrivate, &buf, &size); buf = (BYTE *)pub; size = pub_len; - pTPM2B_PUBLIC_Unmarshal(&in.inPublic, &buf, &size, FALSE); + TPM2B_PUBLIC_Unmarshal(&in.inPublic, &buf, &size, FALSE); *type = in.inPublic.publicArea.type; - rc = pTSS_Execute(tssc, - (RESPONSE_PARAMETERS *)&out, - (COMMAND_PARAMETERS *)&in, - NULL, - TPM_CC_Load, - TPM_RS_PW, NULL, 0, - TPM_RH_NULL, NULL, 0); + rc = TSS_Execute(tssc, + (RESPONSE_PARAMETERS *)&out, + (COMMAND_PARAMETERS *)&in, + NULL, + TPM_CC_Load, + TPM_RS_PW, NULL, 0, + TPM_RH_NULL, NULL, 0); if (rc != TPM_RC_SUCCESS) { tpm2_error(rc, "TPM2_Load"); return GPG_ERR_CARD; @@ -701,16 +634,16 @@ tpm2_ObjectPublic_GetName(TPM2B_NAME *name, if (rc == 0) { INT32 size = MAX_RESPONSE_SIZE; uint8_t *buffer1 = buffer; - rc = pTSS_TPMT_PUBLIC_Marshal(tpmtPublic, &written, &buffer1, &size); + rc = TSS_TPMT_PUBLIC_Marshal(tpmtPublic, &written, &buffer1, &size); } /* hash the public area */ if (rc == 0) { - sizeInBytes = pTSS_GetDigestSize(tpmtPublic->nameAlg); + sizeInBytes = TSS_GetDigestSize(tpmtPublic->nameAlg); digest.hashAlg = tpmtPublic->nameAlg; /* Name digest algorithm */ /* generate the TPMT_HA */ - rc = pTSS_Hash_Generate(&digest, - written, buffer, - 0, NULL); + rc = TSS_Hash_Generate(&digest, + written, buffer, + 0, NULL); } if (rc == 0) { TPMI_ALG_HASH nameAlgNbo; @@ -749,7 +682,7 @@ TPM_RC tpm2_SensitiveToDuplicate(TPMT_SENSITIVE *s, if (symdef->algorithm == TPM_ALG_AES && symdef->mode.aes == TPM_ALG_CFB) { TPMT_HA hash; - const int hlen = pTSS_GetDigestSize(nalg); + const int hlen = TSS_GetDigestSize(nalg); TPM2B *digest = (TPM2B *)buf; TPM2B *s2b; int32_t size; @@ -771,16 +704,16 @@ TPM_RC tpm2_SensitiveToDuplicate(TPMT_SENSITIVE *s, buf = (BYTE *)&digest->size; bsize = hlen; size = 2; - pTSS_UINT16_Marshal(&bsize, &written, &buf, &size); + TSS_UINT16_Marshal(&bsize, &written, &buf, &size); /* marshal the unencrypted sensitive in place */ size = sizeof(*s); bsize = 0; buf = s2b->buffer; - pTSS_TPMT_SENSITIVE_Marshal(s, &bsize, &buf, &size); + TSS_TPMT_SENSITIVE_Marshal(s, &bsize, &buf, &size); buf = (BYTE *)&s2b->size; size = 2; - pTSS_UINT16_Marshal(&bsize, &written, &buf, &size); + TSS_UINT16_Marshal(&bsize, &written, &buf, &size); bsize = bsize + sizeof(s2b->size); p->t.size += bsize; @@ -788,9 +721,9 @@ TPM_RC tpm2_SensitiveToDuplicate(TPMT_SENSITIVE *s, /* compute hash of unencrypted marshalled sensitive and * write to the digest buffer */ hash.hashAlg = nalg; - pTSS_Hash_Generate(&hash, bsize, s2b, - name->t.size, name->t.name, - 0, NULL); + TSS_Hash_Generate(&hash, bsize, s2b, + name->t.size, name->t.name, + 0, NULL); memcpy(digest->buffer, &hash.digest, hlen); gcry_cipher_open (&hd, GCRY_CIPHER_AES128, GCRY_CIPHER_MODE_CFB, GCRY_CIPHER_SECURE); @@ -808,10 +741,10 @@ TPM_RC tpm2_SensitiveToDuplicate(TPMT_SENSITIVE *s, buf = s2b->buffer; /* marshal the unencrypted sensitive in place */ - pTSS_TPMT_SENSITIVE_Marshal(s, &bsize, &buf, &size); + TSS_TPMT_SENSITIVE_Marshal(s, &bsize, &buf, &size); buf = (BYTE *)&s2b->size; size = 2; - pTSS_UINT16_Marshal(&bsize, &written, &buf, &size); + TSS_UINT16_Marshal(&bsize, &written, &buf, &size); p->b.size += bsize + sizeof(s2b->size); } else { @@ -894,13 +827,13 @@ tpm2_import_key(ctrl_t ctrl, TSS_CONTEXT *tssc, if (rc) return GPG_ERR_CARD; - rc = pTSS_Execute(tssc, - (RESPONSE_PARAMETERS *)&iout, - (COMMAND_PARAMETERS *)&iin, - NULL, - TPM_CC_Import, - ah, NULL, TPMA_SESSION_DECRYPT, - TPM_RH_NULL, NULL, 0); + rc = TSS_Execute(tssc, + (RESPONSE_PARAMETERS *)&iout, + (COMMAND_PARAMETERS *)&iin, + NULL, + TPM_CC_Import, + ah, NULL, TPMA_SESSION_DECRYPT, + TPM_RH_NULL, NULL, 0); if (rc) { tpm2_error(rc, "TPM2_Import"); /* failure means auth handle is not flushed */ @@ -911,15 +844,15 @@ tpm2_import_key(ctrl_t ctrl, TSS_CONTEXT *tssc, size = sizeof(TPM2B_PUBLIC); buffer = pub; len = 0; - pTSS_TPM2B_PUBLIC_Marshal(&iin.objectPublic, + TSS_TPM2B_PUBLIC_Marshal(&iin.objectPublic, &len, &buffer, &size); *pub_len = len; size = sizeof(TPM2B_PRIVATE); buffer = priv; len = 0; - pTSS_TPM2B_PRIVATE_Marshal(&iout.outPrivate, - &len, &buffer, &size); + TSS_TPM2B_PRIVATE_Marshal(&iout.outPrivate, + &len, &buffer, &size); *priv_len = len; return 0; -- 2.13.7 From James.Bottomley at HansenPartnership.com Sun Jul 29 23:30:00 2018 From: James.Bottomley at HansenPartnership.com (James Bottomley) Date: Sun, 29 Jul 2018 14:30:00 -0700 Subject: [PATCH tpm-work 1/3] agent: separate out daemon handling infrastructure for reuse In-Reply-To: <1532899727.3142.12.camel@HansenPartnership.com> References: <1532899727.3142.12.camel@HansenPartnership.com> Message-ID: <1532899800.3142.14.camel@HansenPartnership.com> The model I'm using for a TPM daemon is the current scdaemon. That includes start and stop handlers plus liveness checks and an assuan socket generator. To avoid massive code duplication (and save me a lot of effort), I've elected to strip this code out of call-scd.c into a generic framework which can then be reused as is by the TPM handling daemon. Signed-off-by: James Bottomley --- agent/Makefile.am | 1 + agent/agent.h | 35 ++-- agent/call-daemon.c | 569 ++++++++++++++++++++++++++++++++++++++++++++++++++++ agent/call-scd.c | 543 +++---------------------------------------------- agent/command-ssh.c | 10 +- agent/command.c | 4 +- agent/gpg-agent.c | 18 +- 7 files changed, 635 insertions(+), 545 deletions(-) create mode 100644 agent/call-daemon.c diff --git a/agent/Makefile.am b/agent/Makefile.am index 3abdde4fc..e2d1b7103 100644 --- a/agent/Makefile.am +++ b/agent/Makefile.am @@ -53,6 +53,7 @@ gpg_agent_SOURCES = \ divert-scd.c \ cvt-openpgp.c cvt-openpgp.h \ call-scd.c \ + call-daemon.c \ learncard.c if HAVE_LIBTSS diff --git a/agent/agent.h b/agent/agent.h index 67e82b763..32098b7a5 100644 --- a/agent/agent.h +++ b/agent/agent.h @@ -29,6 +29,7 @@ #define map_assuan_err(a) \ map_assuan_err_with_source (GPG_ERR_SOURCE_DEFAULT, (a)) #include +#include #include #include "../common/util.h" @@ -53,6 +54,12 @@ this shouldn't be a problem in practice. */ #define MAX_PASSPHRASE_LEN 255 +/* The daemons we support. When you add a new daemon, add to + both the daemon_type and the daemons_global array */ +enum daemon_type { + DAEMON_SCD, + DAEMON_MAX_TYPE, +}; /* A large struct name "opt" to keep global flags */ struct @@ -78,10 +85,10 @@ struct /* Filename of the program to start as pinentry. */ const char *pinentry_program; - /* Filename of the program to handle smartcard tasks. */ - const char *scdaemon_program; + /* Filename of the program to handle daemon tasks. */ + const char *daemon_program[DAEMON_MAX_TYPE]; - int disable_scdaemon; /* Never use the SCdaemon. */ + int disable_daemon[DAEMON_MAX_TYPE]; /* Never use the daemon. */ int no_grab; /* Don't let the pinentry grab the keyboard */ @@ -202,7 +209,7 @@ struct ssh_control_file_s; typedef struct ssh_control_file_s *ssh_control_file_t; /* Forward reference for local definitions in call-scd.c. */ -struct scd_local_s; +struct daemon_local_s; /* Collection of data per session (aka connection). */ struct server_control_s @@ -222,8 +229,8 @@ struct server_control_s /* Private data of the server (command.c). */ struct server_local_s *server_local; - /* Private data of the SCdaemon (call-scd.c). */ - struct scd_local_s *scd_local; + /* Private data of the daemon (call-XXX.c). */ + struct daemon_local_s *d_local[DAEMON_MAX_TYPE]; /* Environment settings for the connection. */ session_env_t session_env; @@ -358,7 +365,7 @@ const char *get_agent_socket_name (void); const char *get_agent_ssh_socket_name (void); int get_agent_active_connection_count (void); #ifdef HAVE_W32_SYSTEM -void *get_agent_scd_notify_event (void); +void *get_agent_daemon_notify_event (void); #endif void agent_sighup_action (void); int map_pk_openpgp_to_gcry (int openpgp_algo); @@ -587,13 +594,17 @@ int divert_generic_cmd (ctrl_t ctrl, int divert_writekey (ctrl_t ctrl, int force, const char *serialno, const char *id, const char *keydata, size_t keydatalen); +/*-- call-daemon.c --*/ +int daemon_start (enum daemon_type type, ctrl_t ctrl); +assuan_context_t daemon_type_ctx (enum daemon_type type, ctrl_t ctrl); +int daemon_unlock (enum daemon_type type, ctrl_t ctrl, int rc); +void initialize_module_daemon (void); +void agent_daemon_dump_state (void); +int agent_daemon_check_running (enum daemon_type type); +void agent_daemon_check_aliveness (void); +void agent_reset_daemon (ctrl_t ctrl); /*-- call-scd.c --*/ -void initialize_module_call_scd (void); -void agent_scd_dump_state (void); -int agent_scd_check_running (void); -void agent_scd_check_aliveness (void); -int agent_reset_scd (ctrl_t ctrl); int agent_card_learn (ctrl_t ctrl, void (*kpinfo_cb)(void*, const char *), void *kpinfo_cb_arg, diff --git a/agent/call-daemon.c b/agent/call-daemon.c new file mode 100644 index 000000000..d046c2934 --- /dev/null +++ b/agent/call-daemon.c @@ -0,0 +1,569 @@ +#include +#include +#include +#include +#include +#include +#include +#include +#ifdef HAVE_SIGNAL_H +# include +#endif +#include +#include +#ifndef HAVE_W32_SYSTEM +#include +#endif +#include + +#include "agent.h" +#include +#include "../common/strlist.h" + +/* daemon type to module mapping */ +static const int daemon_modules[DAEMON_MAX_TYPE] = { + [DAEMON_SCD] = GNUPG_MODULE_NAME_SCDAEMON, +}; + +/* Definition of module local data of the CTRL structure. */ +struct daemon_local_s +{ + /* We keep a list of all allocated context with an anchor at + DAEMON_LOCAL_LIST (see below). */ + struct daemon_local_s *next_local; + + /* We need to get back to the ctrl object actually referencing this + structure. This is really an awkward way of enumerating the local + contexts. A much cleaner way would be to keep a global list of + ctrl objects to enumerate them. */ + ctrl_t ctrl_backlink; + + /* and also to get back to the global structure */ + struct daemon_global_s *g; + + assuan_context_t ctx; /* NULL or session context for the daemon + used with this connection. */ + int locked; /* This flag is used to assert proper use of + start_daemon and unlock_daemon. */ + +}; + + +/* Primary holder of all the started daemons */ +struct daemon_global_s +{ + /* To keep track of all active daemon contexts, we keep a linked list + anchored at this variable. */ + struct daemon_local_s *local_list; + /* A malloced string with the name of the socket to be used for + additional connections. May be NULL if not provided by + daemon. */ + char *socket_name; + + /* The context of the primary connection. This is also used as a flag + to indicate whether the daemon has been started. */ + assuan_context_t primary_ctx; + + /* To allow reuse of the primary connection, the following flag is set + to true if the primary context has been reset and is not in use by + any connection. */ + int primary_ctx_reusable; +}; + +static struct daemon_global_s daemon_global[DAEMON_MAX_TYPE]; + + +/* A Mutex used inside the start_daemon function. */ +static npth_mutex_t start_daemon_lock; + +/* The unlock_daemon function shall be called after having accessed the + daemon. It is currently not very useful but gives an opportunity to + keep track of connections currently calling daemon. Note that the + "lock" operation is done by the start_daemon() function which must be + called and error checked before any daemon operation. CTRL is the + usual connection context and RC the error code to be passed trhough + the function. */ +int +daemon_unlock (enum daemon_type type, ctrl_t ctrl, int rc) +{ + if (ctrl->d_local[type]->locked != 1) + { + log_error ("unlock_daemon: invalid lock count (%d)\n", + ctrl->d_local[type]->locked); + if (!rc) + rc = gpg_error (GPG_ERR_INTERNAL); + } + ctrl->d_local[type]->locked = 0; + return rc; +} + +/* To make sure we leave no secrets in our image after forking of the + daemon, we use this callback. */ +static void +atfork_cb (void *opaque, int where) +{ + (void)opaque; + + if (!where) + gcry_control (GCRYCTL_TERM_SECMEM); +} + +/* Fork off the daemon if this has not already been done. Lock the + daemon and make sure that a proper context has been setup in CTRL. + This function might also lock the daemon, which means that the + caller must call unlock_daemon after this function has returned + success and the actual Assuan transaction been done. */ +int +daemon_start (enum daemon_type type, ctrl_t ctrl) +{ + gpg_error_t err = 0; + const char *pgmname; + assuan_context_t ctx = NULL; + const char *argv[5]; + assuan_fd_t no_close_list[3]; + int i; + int rc; + char *abs_homedir = NULL; + struct daemon_global_s *g = &daemon_global[type]; + const char *name = gnupg_module_name (daemon_modules[type]); + + assert (type < DAEMON_MAX_TYPE); + + if (opt.disable_daemon[type]) + return gpg_error (GPG_ERR_NOT_SUPPORTED); + + /* If this is the first call for this session, setup the local data + structure. */ + if (!ctrl->d_local[type]) + { + ctrl->d_local[type] = xtrycalloc (1, sizeof *ctrl->d_local[type]); + if (!ctrl->d_local[type]) + return gpg_error_from_syserror (); + ctrl->d_local[type]->ctrl_backlink = ctrl; + ctrl->d_local[type]->g = g; + ctrl->d_local[type]->next_local = g->local_list; + g->local_list = ctrl->d_local[type]; + } + + + /* Assert that the lock count is as expected. */ + if (ctrl->d_local[type]->locked) + { + log_error ("start_daemon: invalid lock count (%d)\n", + ctrl->d_local[type]->locked); + return gpg_error (GPG_ERR_INTERNAL); + } + ctrl->d_local[type]->locked++; + + if (ctrl->d_local[type]->ctx) + return 0; /* Okay, the context is fine. We used to test for an + alive context here and do an disconnect. Now that we + have a ticker function to check for it, it is easier + not to check here but to let the connection run on an + error instead. */ + + + /* We need to protect the following code. */ + rc = npth_mutex_lock (&start_daemon_lock); + if (rc) + { + log_error ("failed to acquire the start_daemon lock: %s\n", + strerror (rc)); + return gpg_error (GPG_ERR_INTERNAL); + } + + /* Check whether the pipe server has already been started and in + this case either reuse a lingering pipe connection or establish a + new socket based one. */ + if (g->primary_ctx && g->primary_ctx_reusable) + { + ctx = g->primary_ctx; + g->primary_ctx_reusable = 0; + if (opt.verbose) + log_info ("new connection to %s daemon established (reusing)\n", + name); + goto leave; + } + + rc = assuan_new (&ctx); + if (rc) + { + log_error ("can't allocate assuan context: %s\n", gpg_strerror (rc)); + err = rc; + goto leave; + } + + if (g->socket_name) + { + rc = assuan_socket_connect (ctx, g->socket_name, 0, 0); + if (rc) + { + log_error ("can't connect to socket '%s': %s\n", + g->socket_name, gpg_strerror (rc)); + err = gpg_error (GPG_ERR_NO_SCDAEMON); + goto leave; + } + + if (opt.verbose) + log_info ("new connection to %s daemon established\n", + name); + goto leave; + } + + if (g->primary_ctx) + { + log_info ("%s daemon is running but won't accept further connections\n", + name); + err = gpg_error (GPG_ERR_NO_SCDAEMON); + goto leave; + } + + /* Nope, it has not been started. Fire it up now. */ + if (opt.verbose) + log_info ("no running %s daemon - starting it\n", name); + + if (fflush (NULL)) + { +#ifndef HAVE_W32_SYSTEM + err = gpg_error_from_syserror (); +#endif + log_error ("error flushing pending output: %s\n", strerror (errno)); + /* At least Windows XP fails here with EBADF. According to docs + and Wine an fflush(NULL) is the same as _flushall. However + the Wime implementation does not flush stdin,stdout and stderr + - see above. Lets try to ignore the error. */ +#ifndef HAVE_W32_SYSTEM + goto leave; +#endif + } + + if (!opt.daemon_program[type] || !*opt.daemon_program[type]) + opt.daemon_program[type] = gnupg_module_name (GNUPG_MODULE_NAME_SCDAEMON); + if ( !(pgmname = strrchr (opt.daemon_program[type], '/'))) + pgmname = opt.daemon_program[type]; + else + pgmname++; + + argv[0] = pgmname; + argv[1] = "--multi-server"; + if (gnupg_default_homedir_p ()) + argv[2] = NULL; + else + { + abs_homedir = make_absfilename_try (gnupg_homedir (), NULL); + if (!abs_homedir) + { + log_error ("error building filename: %s\n", + gpg_strerror (gpg_error_from_syserror ())); + goto leave; + } + + argv[2] = "--homedir"; + argv[3] = abs_homedir; + argv[4] = NULL; + } + + i=0; + if (!opt.running_detached) + { + if (log_get_fd () != -1) + no_close_list[i++] = assuan_fd_from_posix_fd (log_get_fd ()); + no_close_list[i++] = assuan_fd_from_posix_fd (fileno (stderr)); + } + no_close_list[i] = ASSUAN_INVALID_FD; + + /* Connect to the daemon and perform initial handshaking. Use + detached flag so that under Windows DAEMON does not show up a + new window. */ + rc = assuan_pipe_connect (ctx, opt.daemon_program[type], argv, + no_close_list, atfork_cb, NULL, + ASSUAN_PIPE_CONNECT_DETACHED); + if (rc) + { + log_error ("can't connect to the daemon %s: %s\n", + name, gpg_strerror (rc)); + err = gpg_error (GPG_ERR_NO_SCDAEMON); + goto leave; + } + + if (opt.verbose) + log_debug ("first connection to daemon %s established\n", name); + + + /* Get the name of the additional socket opened by daemon. */ + { + membuf_t data; + unsigned char *databuf; + size_t datalen; + + xfree (g->socket_name); + g->socket_name = NULL; + init_membuf (&data, 256); + assuan_transact (ctx, "GETINFO socket_name", + put_membuf_cb, &data, NULL, NULL, NULL, NULL); + + databuf = get_membuf (&data, &datalen); + if (databuf && datalen) + { + g->socket_name = xtrymalloc (datalen + 1); + if (!g->socket_name) + log_error ("warning: can't store socket name: %s\n", + strerror (errno)); + else + { + memcpy (g->socket_name, databuf, datalen); + g->socket_name[datalen] = 0; + if (DBG_IPC) + log_debug ("additional connections at '%s'\n", g->socket_name); + } + } + xfree (databuf); + } + + /* Tell the daemon we want him to send us an event signal. We + don't support this for W32CE. */ +#ifndef HAVE_W32CE_SYSTEM + if (opt.sigusr2_enabled) + { + char buf[100]; + +#ifdef HAVE_W32_SYSTEM + snprintf (buf, sizeof buf, "OPTION event-signal=%lx", + (unsigned long)get_agent_daemon_notify_event ()); +#else + snprintf (buf, sizeof buf, "OPTION event-signal=%d", SIGUSR2); +#endif + assuan_transact (ctx, buf, NULL, NULL, NULL, NULL, NULL, NULL); + } +#endif /*HAVE_W32CE_SYSTEM*/ + + g->primary_ctx = ctx; + g->primary_ctx_reusable = 0; + + leave: + xfree (abs_homedir); + if (err) + { + daemon_unlock (type, ctrl, err); + if (ctx) + assuan_release (ctx); + } + else + { + ctrl->d_local[type]->ctx = ctx; + } + rc = npth_mutex_unlock (&start_daemon_lock); + if (rc) + log_error ("failed to release the start_daemon lock: %s\n", strerror (rc)); + return err; +} + + +/* This function must be called once to initialize this module. This + has to be done before a second thread is spawned. We can't do the + static initialization because NPth emulation code might not be able + to do a static init; in particular, it is not possible for W32. */ +void +initialize_module_daemon (void) +{ + static int initialized; + int err; + + if (!initialized) + { + err = npth_mutex_init (&start_daemon_lock, NULL); + if (err) + log_fatal ("error initializing mutex: %s\n", strerror (err)); + initialized = 1; + } +} + + +/* This function may be called to print information pertaining to the + current state of this module to the log. */ +void +agent_daemon_dump_state (void) +{ + int i; + + for (i = 0; i < DAEMON_MAX_TYPE; i++) { + struct daemon_global_s *g = &daemon_global[i]; + + log_info ("agent_daemon_dump_state: name %s primary_ctx=%p pid=%ld reusable=%d\n", + gnupg_module_name (daemon_modules[i]), + g->primary_ctx, + (long)assuan_get_pid (g->primary_ctx), + g->primary_ctx_reusable); + if (g->socket_name) + log_info ("agent_daemon_dump_state: socket='%s'\n", g->socket_name); + } +} + + +/* Check whether the daemon is active. This is a fast check without + any locking and might give a wrong result if another thread is about + to start the daemon or the daemon is about to be stopped.. */ +int +agent_daemon_check_running (enum daemon_type type) +{ + return !!daemon_global[type].primary_ctx; +} + + +/* Check whether the daemons are still alive and clean it up if not. */ +void +agent_daemon_check_aliveness (void) +{ + pid_t pid; +#ifdef HAVE_W32_SYSTEM + DWORD rc; +#else + int rc; +#endif + struct timespec abstime; + int err; + int i; + + for (i = 0; i < DAEMON_MAX_TYPE; i++) { + struct daemon_global_s *g = &daemon_global[i]; + + if (!g->primary_ctx) + continue; /* No daemon running. */ + + /* This is not a critical function so we use a short timeout while + acquiring the lock. */ + npth_clock_gettime (&abstime); + abstime.tv_sec += 1; + err = npth_mutex_timedlock (&start_daemon_lock, &abstime); + if (err) + { + if (err == ETIMEDOUT) + { + if (opt.verbose > 1) + log_info ("failed to acquire the start_daemon lock while" + " doing an aliveness check: %s\n", strerror (err)); + } + else + log_error ("failed to acquire the start_daemon lock while" + " doing an aliveness check: %s\n", strerror (err)); + return; + } + + if (g->primary_ctx) + { + pid = assuan_get_pid (g->primary_ctx); +#ifdef HAVE_W32_SYSTEM + /* If we have a PID we disconnect if either GetExitProcessCode + fails or if ir returns the exit code of the daemon. 259 is + the error code for STILL_ALIVE. */ + if (pid != (pid_t)(void*)(-1) && pid + && (!GetExitCodeProcess ((HANDLE)pid, &rc) || rc != 259)) +#else + if (pid != (pid_t)(-1) && pid + && ((rc=waitpid (pid, NULL, WNOHANG))==-1 || (rc == pid)) ) +#endif + { + /* Okay, daemon died. Disconnect the primary connection + now but take care that it won't do another wait. Also + cleanup all other connections and release their + resources. The next use will start a new daemon then. + Due to the use of the START_SCD_LOCAL we are sure that + none of these context are actually in use. */ + struct daemon_local_s *sl; + + assuan_set_flag (g->primary_ctx, ASSUAN_NO_WAITPID, 1); + assuan_release (g->primary_ctx); + + for (sl=g->local_list; sl; sl = sl->next_local) + { + if (sl->ctx) + { + if (sl->ctx != g->primary_ctx) + assuan_release (sl->ctx); + sl->ctx = NULL; + } + } + + g->primary_ctx = NULL; + g->primary_ctx_reusable = 0; + + xfree (g->socket_name); + g->socket_name = NULL; + } + } + + err = npth_mutex_unlock (&start_daemon_lock); + if (err) + log_error ("failed to release the start_daemon lock while" + " doing the aliveness check: %s\n", strerror (err)); + } +} + + + +/* Reset the daemon if it has been used. Actually it is not a reset but + a cleanup of resources used by the current connection. */ +void +agent_reset_daemon (ctrl_t ctrl) +{ + int i; + + for (i = 0; i < DAEMON_MAX_TYPE; i++) { + if (ctrl->d_local[i]) + { + struct daemon_global_s *g = ctrl->d_local[i]->g; + + if (ctrl->d_local[i]->ctx) + { + /* We can't disconnect the primary context because libassuan + does a waitpid on it and thus the system would hang. + Instead we send a reset and keep that connection for + reuse. */ + if (ctrl->d_local[i]->ctx == g->primary_ctx) + { + /* Send a RESTART to the daemon. This is required for the + primary connection as a kind of virtual EOF; we don't + have another way to tell it that the next command + should be viewed as if a new connection has been + made. For the non-primary connections this is not + needed as we simply close the socket. We don't check + for an error here because the RESTART may fail for + example if the daemon has already been terminated. + Anyway, we need to set the reusable flag to make sure + that the aliveness check can clean it up. */ + assuan_transact (g->primary_ctx, "RESTART", + NULL, NULL, NULL, NULL, NULL, NULL); + g->primary_ctx_reusable = 1; + } + else + assuan_release (ctrl->d_local[i]->ctx); + ctrl->d_local[i]->ctx = NULL; + } + + /* Remove the local context from our list and release it. */ + if (!g->local_list) + BUG (); + else if (g->local_list == ctrl->d_local[i]) + g->local_list = ctrl->d_local[i]->next_local; + else + { + struct daemon_local_s *sl; + + for (sl=g->local_list; sl->next_local; sl = sl->next_local) + if (sl->next_local == ctrl->d_local[i]) + break; + if (!sl->next_local) + BUG (); + sl->next_local = ctrl->d_local[i]->next_local; + } + xfree (ctrl->d_local[i]); + ctrl->d_local[i] = NULL; + } + } +} + +assuan_context_t +daemon_type_ctx (enum daemon_type type, ctrl_t ctrl) +{ + return ctrl->d_local[type]->ctx; +} diff --git a/agent/call-scd.c b/agent/call-scd.c index 6ce0cddfb..5aaab20a5 100644 --- a/agent/call-scd.c +++ b/agent/call-scd.c @@ -47,27 +47,6 @@ #define MAX_OPEN_FDS 20 #endif -/* Definition of module local data of the CTRL structure. */ -struct scd_local_s -{ - /* We keep a list of all allocated context with an anchor at - SCD_LOCAL_LIST (see below). */ - struct scd_local_s *next_local; - - /* We need to get back to the ctrl object actually referencing this - structure. This is really an awkward way of enumerating the local - contexts. A much cleaner way would be to keep a global list of - ctrl objects to enumerate them. */ - ctrl_t ctrl_backlink; - - assuan_context_t ctx; /* NULL or session context for the SCdaemon - used with this connection. */ - int locked; /* This flag is used to assert proper use of - start_scd and unlock_scd. */ - -}; - - /* Callback parameter for learn card */ struct learn_parm_s { @@ -96,495 +75,25 @@ struct inq_needpin_parm_s }; -/* To keep track of all active SCD contexts, we keep a linked list - anchored at this variable. */ -static struct scd_local_s *scd_local_list; - -/* A Mutex used inside the start_scd function. */ -static npth_mutex_t start_scd_lock; - -/* A malloced string with the name of the socket to be used for - additional connections. May be NULL if not provided by - SCdaemon. */ -static char *socket_name; - -/* The context of the primary connection. This is also used as a flag - to indicate whether the scdaemon has been started. */ -static assuan_context_t primary_scd_ctx; - -/* To allow reuse of the primary connection, the following flag is set - to true if the primary context has been reset and is not in use by - any connection. */ -static int primary_scd_ctx_reusable; - /* Local prototypes. */ - - - - -/* This function must be called once to initialize this module. This - has to be done before a second thread is spawned. We can't do the - static initialization because NPth emulation code might not be able - to do a static init; in particular, it is not possible for W32. */ -void -initialize_module_call_scd (void) -{ - static int initialized; - int err; - - if (!initialized) - { - err = npth_mutex_init (&start_scd_lock, NULL); - if (err) - log_fatal ("error initializing mutex: %s\n", strerror (err)); - initialized = 1; - } -} - - -/* This function may be called to print information pertaining to the - current state of this module to the log. */ -void -agent_scd_dump_state (void) -{ - log_info ("agent_scd_dump_state: primary_scd_ctx=%p pid=%ld reusable=%d\n", - primary_scd_ctx, - (long)assuan_get_pid (primary_scd_ctx), - primary_scd_ctx_reusable); - if (socket_name) - log_info ("agent_scd_dump_state: socket='%s'\n", socket_name); -} - - -/* The unlock_scd function shall be called after having accessed the - SCD. It is currently not very useful but gives an opportunity to - keep track of connections currently calling SCD. Note that the - "lock" operation is done by the start_scd() function which must be - called and error checked before any SCD operation. CTRL is the - usual connection context and RC the error code to be passed trhough - the function. */ -static int -unlock_scd (ctrl_t ctrl, int rc) -{ - if (ctrl->scd_local->locked != 1) - { - log_error ("unlock_scd: invalid lock count (%d)\n", - ctrl->scd_local->locked); - if (!rc) - rc = gpg_error (GPG_ERR_INTERNAL); - } - ctrl->scd_local->locked = 0; - return rc; -} - -/* To make sure we leave no secrets in our image after forking of the - scdaemon, we use this callback. */ -static void -atfork_cb (void *opaque, int where) -{ - (void)opaque; - - if (!where) - gcry_control (GCRYCTL_TERM_SECMEM); -} - - -/* Fork off the SCdaemon if this has not already been done. Lock the - daemon and make sure that a proper context has been setup in CTRL. - This function might also lock the daemon, which means that the - caller must call unlock_scd after this function has returned - success and the actual Assuan transaction been done. */ static int start_scd (ctrl_t ctrl) { - gpg_error_t err = 0; - const char *pgmname; - assuan_context_t ctx = NULL; - const char *argv[5]; - assuan_fd_t no_close_list[3]; - int i; - int rc; - char *abs_homedir = NULL; - - if (opt.disable_scdaemon) - return gpg_error (GPG_ERR_NOT_SUPPORTED); - - /* If this is the first call for this session, setup the local data - structure. */ - if (!ctrl->scd_local) - { - ctrl->scd_local = xtrycalloc (1, sizeof *ctrl->scd_local); - if (!ctrl->scd_local) - return gpg_error_from_syserror (); - ctrl->scd_local->ctrl_backlink = ctrl; - ctrl->scd_local->next_local = scd_local_list; - scd_local_list = ctrl->scd_local; - } - - - /* Assert that the lock count is as expected. */ - if (ctrl->scd_local->locked) - { - log_error ("start_scd: invalid lock count (%d)\n", - ctrl->scd_local->locked); - return gpg_error (GPG_ERR_INTERNAL); - } - ctrl->scd_local->locked++; - - if (ctrl->scd_local->ctx) - return 0; /* Okay, the context is fine. We used to test for an - alive context here and do an disconnect. Now that we - have a ticker function to check for it, it is easier - not to check here but to let the connection run on an - error instead. */ - - - /* We need to protect the following code. */ - rc = npth_mutex_lock (&start_scd_lock); - if (rc) - { - log_error ("failed to acquire the start_scd lock: %s\n", - strerror (rc)); - return gpg_error (GPG_ERR_INTERNAL); - } - - /* Check whether the pipe server has already been started and in - this case either reuse a lingering pipe connection or establish a - new socket based one. */ - if (primary_scd_ctx && primary_scd_ctx_reusable) - { - ctx = primary_scd_ctx; - primary_scd_ctx_reusable = 0; - if (opt.verbose) - log_info ("new connection to SCdaemon established (reusing)\n"); - goto leave; - } - - rc = assuan_new (&ctx); - if (rc) - { - log_error ("can't allocate assuan context: %s\n", gpg_strerror (rc)); - err = rc; - goto leave; - } - - if (socket_name) - { - rc = assuan_socket_connect (ctx, socket_name, 0, 0); - if (rc) - { - log_error ("can't connect to socket '%s': %s\n", - socket_name, gpg_strerror (rc)); - err = gpg_error (GPG_ERR_NO_SCDAEMON); - goto leave; - } - - if (opt.verbose) - log_info ("new connection to SCdaemon established\n"); - goto leave; - } - - if (primary_scd_ctx) - { - log_info ("SCdaemon is running but won't accept further connections\n"); - err = gpg_error (GPG_ERR_NO_SCDAEMON); - goto leave; - } - - /* Nope, it has not been started. Fire it up now. */ - if (opt.verbose) - log_info ("no running SCdaemon - starting it\n"); - - if (fflush (NULL)) - { -#ifndef HAVE_W32_SYSTEM - err = gpg_error_from_syserror (); -#endif - log_error ("error flushing pending output: %s\n", strerror (errno)); - /* At least Windows XP fails here with EBADF. According to docs - and Wine an fflush(NULL) is the same as _flushall. However - the Wime implementation does not flush stdin,stdout and stderr - - see above. Lets try to ignore the error. */ -#ifndef HAVE_W32_SYSTEM - goto leave; -#endif - } - - if (!opt.scdaemon_program || !*opt.scdaemon_program) - opt.scdaemon_program = gnupg_module_name (GNUPG_MODULE_NAME_SCDAEMON); - if ( !(pgmname = strrchr (opt.scdaemon_program, '/'))) - pgmname = opt.scdaemon_program; - else - pgmname++; - - argv[0] = pgmname; - argv[1] = "--multi-server"; - if (gnupg_default_homedir_p ()) - argv[2] = NULL; - else - { - abs_homedir = make_absfilename_try (gnupg_homedir (), NULL); - if (!abs_homedir) - { - log_error ("error building filename: %s\n", - gpg_strerror (gpg_error_from_syserror ())); - goto leave; - } - - argv[2] = "--homedir"; - argv[3] = abs_homedir; - argv[4] = NULL; - } - - i=0; - if (!opt.running_detached) - { - if (log_get_fd () != -1) - no_close_list[i++] = assuan_fd_from_posix_fd (log_get_fd ()); - no_close_list[i++] = assuan_fd_from_posix_fd (fileno (stderr)); - } - no_close_list[i] = ASSUAN_INVALID_FD; - - /* Connect to the scdaemon and perform initial handshaking. Use - detached flag so that under Windows SCDAEMON does not show up a - new window. */ - rc = assuan_pipe_connect (ctx, opt.scdaemon_program, argv, - no_close_list, atfork_cb, NULL, - ASSUAN_PIPE_CONNECT_DETACHED); - if (rc) - { - log_error ("can't connect to the SCdaemon: %s\n", - gpg_strerror (rc)); - err = gpg_error (GPG_ERR_NO_SCDAEMON); - goto leave; - } - - if (opt.verbose) - log_debug ("first connection to SCdaemon established\n"); - - - /* Get the name of the additional socket opened by scdaemon. */ - { - membuf_t data; - unsigned char *databuf; - size_t datalen; - - xfree (socket_name); - socket_name = NULL; - init_membuf (&data, 256); - assuan_transact (ctx, "GETINFO socket_name", - put_membuf_cb, &data, NULL, NULL, NULL, NULL); - - databuf = get_membuf (&data, &datalen); - if (databuf && datalen) - { - socket_name = xtrymalloc (datalen + 1); - if (!socket_name) - log_error ("warning: can't store socket name: %s\n", - strerror (errno)); - else - { - memcpy (socket_name, databuf, datalen); - socket_name[datalen] = 0; - if (DBG_IPC) - log_debug ("additional connections at '%s'\n", socket_name); - } - } - xfree (databuf); - } - - /* Tell the scdaemon we want him to send us an event signal. We - don't support this for W32CE. */ -#ifndef HAVE_W32CE_SYSTEM - if (opt.sigusr2_enabled) - { - char buf[100]; - -#ifdef HAVE_W32_SYSTEM - snprintf (buf, sizeof buf, "OPTION event-signal=%lx", - (unsigned long)get_agent_scd_notify_event ()); -#else - snprintf (buf, sizeof buf, "OPTION event-signal=%d", SIGUSR2); -#endif - assuan_transact (ctx, buf, NULL, NULL, NULL, NULL, NULL, NULL); - } -#endif /*HAVE_W32CE_SYSTEM*/ - - primary_scd_ctx = ctx; - primary_scd_ctx_reusable = 0; - - leave: - xfree (abs_homedir); - if (err) - { - unlock_scd (ctrl, err); - if (ctx) - assuan_release (ctx); - } - else - { - ctrl->scd_local->ctx = ctx; - } - rc = npth_mutex_unlock (&start_scd_lock); - if (rc) - log_error ("failed to release the start_scd lock: %s\n", strerror (rc)); - return err; -} - - -/* Check whether the SCdaemon is active. This is a fast check without - any locking and might give a wrong result if another thread is about - to start the daemon or the daemon is about to be stopped.. */ -int -agent_scd_check_running (void) -{ - return !!primary_scd_ctx; + return daemon_start (DAEMON_SCD, ctrl); } - -/* Check whether the Scdaemon is still alive and clean it up if not. */ -void -agent_scd_check_aliveness (void) +static int +unlock_scd (ctrl_t ctrl, gpg_error_t err) { - pid_t pid; -#ifdef HAVE_W32_SYSTEM - DWORD rc; -#else - int rc; -#endif - struct timespec abstime; - int err; - - if (!primary_scd_ctx) - return; /* No scdaemon running. */ - - /* This is not a critical function so we use a short timeout while - acquiring the lock. */ - npth_clock_gettime (&abstime); - abstime.tv_sec += 1; - err = npth_mutex_timedlock (&start_scd_lock, &abstime); - if (err) - { - if (err == ETIMEDOUT) - { - if (opt.verbose > 1) - log_info ("failed to acquire the start_scd lock while" - " doing an aliveness check: %s\n", strerror (err)); - } - else - log_error ("failed to acquire the start_scd lock while" - " doing an aliveness check: %s\n", strerror (err)); - return; - } - - if (primary_scd_ctx) - { - pid = assuan_get_pid (primary_scd_ctx); -#ifdef HAVE_W32_SYSTEM - /* If we have a PID we disconnect if either GetExitProcessCode - fails or if ir returns the exit code of the scdaemon. 259 is - the error code for STILL_ALIVE. */ - if (pid != (pid_t)(void*)(-1) && pid - && (!GetExitCodeProcess ((HANDLE)pid, &rc) || rc != 259)) -#else - if (pid != (pid_t)(-1) && pid - && ((rc=waitpid (pid, NULL, WNOHANG))==-1 || (rc == pid)) ) -#endif - { - /* Okay, scdaemon died. Disconnect the primary connection - now but take care that it won't do another wait. Also - cleanup all other connections and release their - resources. The next use will start a new daemon then. - Due to the use of the START_SCD_LOCAL we are sure that - none of these context are actually in use. */ - struct scd_local_s *sl; - - assuan_set_flag (primary_scd_ctx, ASSUAN_NO_WAITPID, 1); - assuan_release (primary_scd_ctx); - - for (sl=scd_local_list; sl; sl = sl->next_local) - { - if (sl->ctx) - { - if (sl->ctx != primary_scd_ctx) - assuan_release (sl->ctx); - sl->ctx = NULL; - } - } - - primary_scd_ctx = NULL; - primary_scd_ctx_reusable = 0; - - xfree (socket_name); - socket_name = NULL; - } - } - - err = npth_mutex_unlock (&start_scd_lock); - if (err) - log_error ("failed to release the start_scd lock while" - " doing the aliveness check: %s\n", strerror (err)); + return daemon_unlock (DAEMON_SCD, ctrl, err); } - - -/* Reset the SCD if it has been used. Actually it is not a reset but - a cleanup of resources used by the current connection. */ -int -agent_reset_scd (ctrl_t ctrl) +static assuan_context_t +daemon_ctx (ctrl_t ctrl) { - if (ctrl->scd_local) - { - if (ctrl->scd_local->ctx) - { - /* We can't disconnect the primary context because libassuan - does a waitpid on it and thus the system would hang. - Instead we send a reset and keep that connection for - reuse. */ - if (ctrl->scd_local->ctx == primary_scd_ctx) - { - /* Send a RESTART to the SCD. This is required for the - primary connection as a kind of virtual EOF; we don't - have another way to tell it that the next command - should be viewed as if a new connection has been - made. For the non-primary connections this is not - needed as we simply close the socket. We don't check - for an error here because the RESTART may fail for - example if the scdaemon has already been terminated. - Anyway, we need to set the reusable flag to make sure - that the aliveness check can clean it up. */ - assuan_transact (primary_scd_ctx, "RESTART", - NULL, NULL, NULL, NULL, NULL, NULL); - primary_scd_ctx_reusable = 1; - } - else - assuan_release (ctrl->scd_local->ctx); - ctrl->scd_local->ctx = NULL; - } - - /* Remove the local context from our list and release it. */ - if (!scd_local_list) - BUG (); - else if (scd_local_list == ctrl->scd_local) - scd_local_list = ctrl->scd_local->next_local; - else - { - struct scd_local_s *sl; - - for (sl=scd_local_list; sl->next_local; sl = sl->next_local) - if (sl->next_local == ctrl->scd_local) - break; - if (!sl->next_local) - BUG (); - sl->next_local = ctrl->scd_local->next_local; - } - xfree (ctrl->scd_local); - ctrl->scd_local = NULL; - } - - return 0; + return daemon_type_ctx (DAEMON_SCD, ctrl); } @@ -641,7 +150,7 @@ agent_card_learn (ctrl_t ctrl, parm.certinfo_cb_arg = certinfo_cb_arg; parm.sinfo_cb = sinfo_cb; parm.sinfo_cb_arg = sinfo_cb_arg; - rc = assuan_transact (ctrl->scd_local->ctx, "LEARN --force", + rc = assuan_transact (daemon_ctx(ctrl), "LEARN --force", NULL, NULL, NULL, NULL, learn_status_cb, &parm); if (rc) @@ -701,7 +210,7 @@ agent_card_serialno (ctrl_t ctrl, char **r_serialno, const char *demand) else snprintf (line, DIM(line), "SERIALNO --demand=%s", demand); - rc = assuan_transact (ctrl->scd_local->ctx, line, + rc = assuan_transact (daemon_ctx (ctrl), line, NULL, NULL, NULL, NULL, get_serialno_cb, &serialno); if (rc) @@ -838,13 +347,13 @@ agent_card_pksign (ctrl_t ctrl, bin2hex (indata, indatalen, stpcpy (line, "SETDATA ")); - rc = assuan_transact (ctrl->scd_local->ctx, line, + rc = assuan_transact (daemon_ctx (ctrl), line, NULL, NULL, NULL, NULL, NULL, NULL); if (rc) return unlock_scd (ctrl, rc); init_membuf (&data, 1024); - inqparm.ctx = ctrl->scd_local->ctx; + inqparm.ctx = daemon_ctx (ctrl); inqparm.getpin_cb = getpin_cb; inqparm.getpin_cb_arg = getpin_cb_arg; inqparm.getpin_cb_desc = desc_text; @@ -857,7 +366,7 @@ agent_card_pksign (ctrl_t ctrl, else snprintf (line, sizeof line, "PKSIGN %s %s", hash_algo_option (mdalgo), keyid); - rc = assuan_transact (ctrl->scd_local->ctx, line, + rc = assuan_transact (daemon_ctx (ctrl), line, put_membuf_cb, &data, inq_needpin, &inqparm, NULL, NULL); @@ -932,14 +441,14 @@ agent_card_pkdecrypt (ctrl_t ctrl, sprintf (p, "%02X", indata[len]); p += 2; } - rc = assuan_transact (ctrl->scd_local->ctx, line, + rc = assuan_transact (daemon_ctx (ctrl), line, NULL, NULL, NULL, NULL, NULL, NULL); if (rc) return unlock_scd (ctrl, rc); } init_membuf (&data, 1024); - inqparm.ctx = ctrl->scd_local->ctx; + inqparm.ctx = daemon_ctx (ctrl); inqparm.getpin_cb = getpin_cb; inqparm.getpin_cb_arg = getpin_cb_arg; inqparm.getpin_cb_desc = desc_text; @@ -947,7 +456,7 @@ agent_card_pkdecrypt (ctrl_t ctrl, inqparm.keydata = NULL; inqparm.keydatalen = 0; snprintf (line, DIM(line), "PKDECRYPT %s", keyid); - rc = assuan_transact (ctrl->scd_local->ctx, line, + rc = assuan_transact (daemon_ctx (ctrl), line, put_membuf_cb, &data, inq_needpin, &inqparm, padding_info_cb, r_padding); @@ -983,7 +492,7 @@ agent_card_readcert (ctrl_t ctrl, init_membuf (&data, 1024); snprintf (line, DIM(line), "READCERT %s", id); - rc = assuan_transact (ctrl->scd_local->ctx, line, + rc = assuan_transact (daemon_ctx (ctrl), line, put_membuf_cb, &data, NULL, NULL, NULL, NULL); @@ -1018,7 +527,7 @@ agent_card_readkey (ctrl_t ctrl, const char *id, unsigned char **r_buf) init_membuf (&data, 1024); snprintf (line, DIM(line), "READKEY %s", id); - rc = assuan_transact (ctrl->scd_local->ctx, line, + rc = assuan_transact (daemon_ctx (ctrl), line, put_membuf_cb, &data, NULL, NULL, NULL, NULL); @@ -1072,7 +581,7 @@ agent_card_writekey (ctrl_t ctrl, int force, const char *serialno, return rc; snprintf (line, DIM(line), "WRITEKEY %s%s", force ? "--force " : "", id); - parms.ctx = ctrl->scd_local->ctx; + parms.ctx = daemon_ctx (ctrl); parms.getpin_cb = getpin_cb; parms.getpin_cb_arg = getpin_cb_arg; parms.getpin_cb_desc= NULL; @@ -1080,7 +589,7 @@ agent_card_writekey (ctrl_t ctrl, int force, const char *serialno, parms.keydata = keydata; parms.keydatalen = keydatalen; - rc = assuan_transact (ctrl->scd_local->ctx, line, NULL, NULL, + rc = assuan_transact (daemon_ctx (ctrl), line, NULL, NULL, inq_writekey_parms, &parms, NULL, NULL); return unlock_scd (ctrl, rc); } @@ -1152,7 +661,7 @@ agent_card_getattr (ctrl_t ctrl, const char *name, char **result) if (err) return err; - err = assuan_transact (ctrl->scd_local->ctx, line, + err = assuan_transact (daemon_ctx (ctrl), line, NULL, NULL, NULL, NULL, card_getattr_cb, &parm); if (!err && parm.error) @@ -1225,7 +734,7 @@ agent_card_cardlist (ctrl_t ctrl, strlist_t *result) if (err) return err; - err = assuan_transact (ctrl->scd_local->ctx, line, + err = assuan_transact (daemon_ctx (ctrl), line, NULL, NULL, NULL, NULL, card_cardlist_cb, &parm); if (!err && parm.error) @@ -1301,7 +810,7 @@ agent_card_scd (ctrl_t ctrl, const char *cmdline, if (rc) return rc; - inqparm.ctx = ctrl->scd_local->ctx; + inqparm.ctx = daemon_ctx (ctrl); inqparm.getpin_cb = getpin_cb; inqparm.getpin_cb_arg = getpin_cb_arg; inqparm.getpin_cb_desc = NULL; @@ -1309,14 +818,14 @@ agent_card_scd (ctrl_t ctrl, const char *cmdline, inqparm.keydata = NULL; inqparm.keydatalen = 0; - saveflag = assuan_get_flag (ctrl->scd_local->ctx, ASSUAN_CONVEY_COMMENTS); - assuan_set_flag (ctrl->scd_local->ctx, ASSUAN_CONVEY_COMMENTS, 1); - rc = assuan_transact (ctrl->scd_local->ctx, cmdline, + saveflag = assuan_get_flag (daemon_ctx (ctrl), ASSUAN_CONVEY_COMMENTS); + assuan_set_flag (daemon_ctx (ctrl), ASSUAN_CONVEY_COMMENTS, 1); + rc = assuan_transact (daemon_ctx (ctrl), cmdline, pass_data_thru, assuan_context, inq_needpin, &inqparm, pass_status_thru, assuan_context); - assuan_set_flag (ctrl->scd_local->ctx, ASSUAN_CONVEY_COMMENTS, saveflag); + assuan_set_flag (daemon_ctx (ctrl), ASSUAN_CONVEY_COMMENTS, saveflag); if (rc) { return unlock_scd (ctrl, rc); diff --git a/agent/command-ssh.c b/agent/command-ssh.c index 715544635..a73cf2ac1 100644 --- a/agent/command-ssh.c +++ b/agent/command-ssh.c @@ -2610,7 +2610,7 @@ ssh_handler_request_identities (ctrl_t ctrl, reader - this should be allowed even without being listed in sshcontrol. */ - if (!opt.disable_scdaemon) + if (!opt.disable_daemon[DAEMON_SCD]) { char *serialno; strlist_t card_list, sl; @@ -3711,8 +3711,8 @@ start_command_handler_ssh (ctrl_t ctrl, gnupg_fd_t sock_client) es_ungetc (c, stream_sock); } - /* Reset the SCD in case it has been used. */ - agent_reset_scd (ctrl); + /* Reset the daemon in case it has been used. */ + agent_reset_daemon (ctrl); out: @@ -3859,8 +3859,8 @@ serve_mmapped_ssh_request (ctrl_t ctrl, valid_response = 1; } - /* Reset the SCD in case it has been used. */ - agent_reset_scd (ctrl); + /* Reset the daemon in case it has been used. */ + agent_reset_daemon (ctrl); return valid_response? 0 : -1; } diff --git a/agent/command.c b/agent/command.c index a46e2888e..37acee608 100644 --- a/agent/command.c +++ b/agent/command.c @@ -2988,7 +2988,7 @@ cmd_getinfo (assuan_context_t ctx, char *line) } else if (!strcmp (line, "scd_running")) { - rc = agent_scd_check_running ()? 0 : gpg_error (GPG_ERR_GENERAL); + rc = agent_daemon_check_running (DAEMON_SCD)? 0 : gpg_error (GPG_ERR_GENERAL); } else if (!strcmp (line, "std_env_names")) { @@ -3431,7 +3431,7 @@ start_command_handler (ctrl_t ctrl, gnupg_fd_t listen_fd, gnupg_fd_t fd) clear_nonce_cache (ctrl); /* Reset the SCD if needed. */ - agent_reset_scd (ctrl); + agent_reset_daemon (ctrl); /* Reset the pinentry (in case of popup messages). */ agent_reset_query (ctrl); diff --git a/agent/gpg-agent.c b/agent/gpg-agent.c index bd9a471e8..ff23e4c7c 100644 --- a/agent/gpg-agent.c +++ b/agent/gpg-agent.c @@ -812,7 +812,7 @@ parse_rereadable_options (ARGPARSE_ARGS *pargs, int reread) xfree (opt.pinentry_invisible_char); opt.pinentry_invisible_char = NULL; opt.pinentry_timeout = 0; - opt.scdaemon_program = NULL; + memset (opt.daemon_program, 0, sizeof opt.daemon_program); opt.def_cache_ttl = DEFAULT_CACHE_TTL; opt.def_cache_ttl_ssh = DEFAULT_CACHE_TTL_SSH; opt.max_cache_ttl = MAX_CACHE_TTL; @@ -829,7 +829,7 @@ parse_rereadable_options (ARGPARSE_ARGS *pargs, int reread) opt.allow_external_cache = 1; opt.allow_loopback_pinentry = 1; opt.allow_emacs_pinentry = 0; - opt.disable_scdaemon = 0; + memset (opt.disable_daemon, 0, sizeof opt.disable_daemon); disable_check_own_socket = 0; /* Note: When changing the next line, change also gpgconf_list. */ opt.ssh_fingerprint_digest = GCRY_MD_MD5; @@ -871,8 +871,8 @@ parse_rereadable_options (ARGPARSE_ARGS *pargs, int reread) opt.pinentry_invisible_char = xtrystrdup (pargs->r.ret_str); break; break; case oPinentryTimeout: opt.pinentry_timeout = pargs->r.ret_ulong; break; - case oScdaemonProgram: opt.scdaemon_program = pargs->r.ret_str; break; - case oDisableScdaemon: opt.disable_scdaemon = 1; break; + case oScdaemonProgram: opt.daemon_program[DAEMON_SCD] = pargs->r.ret_str; break; + case oDisableScdaemon: opt.disable_daemon[DAEMON_SCD] = 1; break; case oDisableCheckOwnSocket: disable_check_own_socket = 1; break; case oDefCacheTTL: opt.def_cache_ttl = pargs->r.ret_ulong; break; @@ -976,7 +976,7 @@ initialize_modules (void) assuan_set_system_hooks (ASSUAN_SYSTEM_NPTH); initialize_module_cache (); initialize_module_call_pinentry (); - initialize_module_call_scd (); + initialize_module_daemon (); initialize_module_trustlist (); } @@ -2086,7 +2086,7 @@ get_agent_active_connection_count (void) event. */ #if defined(HAVE_W32_SYSTEM) && !defined(HAVE_W32CE_SYSTEM) void * -get_agent_scd_notify_event (void) +get_agent_daemon_notify_event (void) { static HANDLE the_event = INVALID_HANDLE_VALUE; @@ -2371,7 +2371,7 @@ handle_tick (void) last_minute = time (NULL); /* Check whether the scdaemon has died and cleanup in this case. */ - agent_scd_check_aliveness (); + agent_daemon_check_aliveness (); /* If we are running as a child of another process, check whether the parent is still alive and shutdown if not. */ @@ -2460,7 +2460,7 @@ handle_signal (int signo) logging system. */ /* pth_ctrl (PTH_CTRL_DUMPSTATE, log_get_stream ()); */ agent_query_dump_state (); - agent_scd_dump_state (); + agent_daemon_dump_state (); break; case SIGUSR2: @@ -2863,7 +2863,7 @@ handle_connections (gnupg_fd_t listen_fd, sigs = 0; ev = pth_event (PTH_EVENT_SIGS, &sigs, &signo); # else - events[0] = get_agent_scd_notify_event (); + events[0] = get_agent_daemon_notify_event (); events[1] = INVALID_HANDLE_VALUE; # endif #endif -- 2.13.7 From James.Bottomley at HansenPartnership.com Sun Jul 29 23:28:47 2018 From: James.Bottomley at HansenPartnership.com (James Bottomley) Date: Sun, 29 Jul 2018 14:28:47 -0700 Subject: [PATCH tpm-work 0/3] move the tpm-work branch to an assuan based tpm handling daemon Message-ID: <1532899727.3142.12.camel@HansenPartnership.com> Sorry this has taken so long. For some reason, I found assuan really hard to get on with?and the documentation somewhat perfunctory, so I had to actually go the libassuan sources a lot to figure out what was going on. Being incredibly lazy, the first patch in the series actually abstracts out most of the scdaemon handling code so it can be re-used for the tpm2daemon. Patch 2 actually does the shift and patch 3 tidies up the linking. I'm sure I got a lot wrong, but it's a start. There's obviously a large amount of documentation that would need writing as well. James --- James Bottomley (3): agent: separate out daemon handling infrastructure for reuse tpm2: handle via a new assuan connected daemon tpm2: Make libtss directly linked Makefile.am | 7 +- agent/Makefile.am | 5 +- agent/agent.h | 46 +- agent/call-daemon.c | 570 +++++++++++++++++++ agent/call-scd.c | 543 +----------------- agent/call-tpm2d.c | 272 +++++++++ agent/command-ssh.c | 10 +- agent/command.c | 4 +- agent/divert-tpm2.c | 62 +- agent/gpg-agent.c | 22 +- common/homedir.c | 7 + common/util.h | 1 + configure.ac | 12 +- tools/gpgconf-comp.c | 2 + tpm2d/Makefile.am | 18 + tpm2d/command.c | 574 +++++++++++++++++++ {agent => tpm2d}/tpm2.c | 239 +++----- {agent => tpm2d}/tpm2.h | 15 +- tpm2d/tpm2daemon.c | 1432 +++++++++++++++++++++++++++++++++++++++++++++++ tpm2d/tpm2daemon.h | 130 +++++ 20 files changed, 3218 insertions(+), 753 deletions(-) create mode 100644 agent/call-daemon.c create mode 100644 agent/call-tpm2d.c create mode 100644 tpm2d/Makefile.am create mode 100644 tpm2d/command.c rename {agent => tpm2d}/tpm2.c (79%) rename {agent => tpm2d}/tpm2.h (64%) create mode 100644 tpm2d/tpm2daemon.c create mode 100644 tpm2d/tpm2daemon.h -- 2.13.7 From wiktor at metacode.biz Mon Jul 30 21:44:56 2018 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Mon, 30 Jul 2018 21:44:56 +0200 Subject: [PATCH tpm-work 0/3] move the tpm-work branch to an assuan based tpm handling daemon In-Reply-To: <1532899727.3142.12.camel@HansenPartnership.com> References: <1532899727.3142.12.camel@HansenPartnership.com> Message-ID: <6f7c0cfd-8902-a6db-1b3d-7305953432a2@metacode.biz> Hi James, I'm very interested in your TPM patches (as a user). Could I ask you some questions on how does it work? I would like to have keys wrapped by TPM in such a way that the change in system configuration would render the key useless. As far as I've seen it's possible to do that by utilizing Platform Configuration Registers (PCRs). Would keys created by your TPM code have this property? Thanks in advance for answer! Kind regards, Wiktor > Sorry this has taken so long. For some reason, I found assuan really > hard to get on with?and the documentation somewhat perfunctory, so I > had to actually go the libassuan sources a lot to figure out what was > going on. Being incredibly lazy, the first patch in the series > actually abstracts out most of the scdaemon handling code so it can be > re-used for the tpm2daemon. Patch 2 actually does the shift and patch > 3 tidies up the linking. I'm sure I got a lot wrong, but it's a start. > There's obviously a large amount of documentation that would need > writing as well. > > James > > --- > > James Bottomley (3): > agent: separate out daemon handling infrastructure for reuse > tpm2: handle via a new assuan connected daemon > tpm2: Make libtss directly linked > > Makefile.am | 7 +- > agent/Makefile.am | 5 +- > agent/agent.h | 46 +- > agent/call-daemon.c | 570 +++++++++++++++++++ > agent/call-scd.c | 543 +----------------- > agent/call-tpm2d.c | 272 +++++++++ > agent/command-ssh.c | 10 +- > agent/command.c | 4 +- > agent/divert-tpm2.c | 62 +- > agent/gpg-agent.c | 22 +- > common/homedir.c | 7 + > common/util.h | 1 + > configure.ac | 12 +- > tools/gpgconf-comp.c | 2 + > tpm2d/Makefile.am | 18 + > tpm2d/command.c | 574 +++++++++++++++++++ > {agent => tpm2d}/tpm2.c | 239 +++----- > {agent => tpm2d}/tpm2.h | 15 +- > tpm2d/tpm2daemon.c | 1432 +++++++++++++++++++++++++++++++++++++++++++++++ > tpm2d/tpm2daemon.h | 130 +++++ > 20 files changed, 3218 insertions(+), 753 deletions(-) > create mode 100644 agent/call-daemon.c > create mode 100644 agent/call-tpm2d.c > create mode 100644 tpm2d/Makefile.am > create mode 100644 tpm2d/command.c > rename {agent => tpm2d}/tpm2.c (79%) > rename {agent => tpm2d}/tpm2.h (64%) > create mode 100644 tpm2d/tpm2daemon.c > create mode 100644 tpm2d/tpm2daemon.h > -- https://metacode.biz/@wiktor From James.Bottomley at HansenPartnership.com Mon Jul 30 22:47:54 2018 From: James.Bottomley at HansenPartnership.com (James Bottomley) Date: Mon, 30 Jul 2018 13:47:54 -0700 Subject: [PATCH tpm-work 0/3] move the tpm-work branch to an assuan based tpm handling daemon In-Reply-To: <1532899727.3142.12.camel@HansenPartnership.com> References: <1532899727.3142.12.camel@HansenPartnership.com> Message-ID: <1532983674.14893.5.camel@HansenPartnership.com> It turns out that this code works in my test environment where I specify the tpm2daemon location but it fails on a production build for openSUSE where they try to reconfigure the default daemon locations (largely because the config code doesn't exist in my current copy). The below is the patch I needed to plumb it in properly and get the openSUSE gpg2 build working. James --- >From 41b2c2df461cd54813ba951a4fe7a97bdce29e74 Mon Sep 17 00:00:00 2001 From: James Bottomley Date: Mon, 30 Jul 2018 08:39:26 -0700 Subject: [PATCH] Fix tpm2 daemon configs and gpgconf Signed-off-by: James Bottomley --- agent/call-daemon.c | 9 ++++++++- am/cmacros.am | 3 +++ configure.ac | 10 ++++++++++ tools/gpgconf-comp.c | 17 +++++++++++++++-- 4 files changed, 36 insertions(+), 3 deletions(-) diff --git a/agent/call-daemon.c b/agent/call-daemon.c index 8b5bae955..472ab0635 100644 --- a/agent/call-daemon.c +++ b/agent/call-daemon.c @@ -239,7 +239,14 @@ daemon_start (enum daemon_type type, ctrl_t ctrl) } if (!opt.daemon_program[type] || !*opt.daemon_program[type]) - opt.daemon_program[type] = gnupg_module_name (GNUPG_MODULE_NAME_SCDAEMON); + { + int map_types[] = { + [DAEMON_SCD] = GNUPG_MODULE_NAME_SCDAEMON, + [DAEMON_TPM2D] = GNUPG_MODULE_NAME_TPM2DAEMON, + }; + + opt.daemon_program[type] = gnupg_module_name (map_types[type]); + } if ( !(pgmname = strrchr (opt.daemon_program[type], '/'))) pgmname = opt.daemon_program[type]; else diff --git a/am/cmacros.am b/am/cmacros.am index 9610e4efe..e71bc4e9d 100644 --- a/am/cmacros.am +++ b/am/cmacros.am @@ -44,6 +44,9 @@ endif if GNUPG_SCDAEMON_PGM AM_CPPFLAGS += -DGNUPG_DEFAULT_SCDAEMON="\"@GNUPG_SCDAEMON_PGM@\"" endif +if GNUPG_TPM2DAEMON_PGM +AM_CPPFLAGS += -DGNUPG_DEFAULT_TPM2DAEMON="\"@GNUPG_TPM2DAEMON_PGM@\"" +endif if GNUPG_DIRMNGR_PGM AM_CPPFLAGS += -DGNUPG_DEFAULT_DIRMNGR="\"@GNUPG_DIRMNGR_PGM@\"" endif diff --git a/configure.ac b/configure.ac index ce3145a36..1fe5ba33c 100644 --- a/configure.ac +++ b/configure.ac @@ -181,6 +181,15 @@ show_gnupg_scdaemon_pgm="(default)" test -n "$GNUPG_SCDAEMON_PGM" && show_gnupg_scdaemon_pgm="$GNUPG_SCDAEMON_PGM" +AC_ARG_WITH(tpm2daemon-pgm, + [ --with-tpm2daemon-pgm=PATH Use PATH as the default for the tpm2daemon)], + GNUPG_TPM2DAEMON_PGM="$withval", GNUPG_TPM2DAEMON_PGM="" ) +AC_SUBST(GNUPG_TPM2DAEMON_PGM) +AM_CONDITIONAL(GNUPG_TPM2DAEMON_PGM, test -n "$GNUPG_TPM2DAEMON_PGM") +show_gnupg_tpm2daemon_pgm="(default)" +test -n "$GNUPG_TPM2DAEMON_PGM" && show_gnupg_tpm2daemon_pgm="$GNUPG_TPM2DAEMON_PGM" + + AC_ARG_WITH(dirmngr-pgm, [ --with-dirmngr-pgm=PATH Use PATH as the default for the dirmngr)], GNUPG_DIRMNGR_PGM="$withval", GNUPG_DIRMNGR_PGM="" ) @@ -2071,6 +2080,7 @@ echo " Default agent: $show_gnupg_agent_pgm Default pinentry: $show_gnupg_pinentry_pgm Default scdaemon: $show_gnupg_scdaemon_pgm + Default tpm2daemon: $show_gnupg_tpm2daemon_pgm Default dirmngr: $show_gnupg_dirmngr_pgm Dirmngr auto start: $dirmngr_auto_start diff --git a/tools/gpgconf-comp.c b/tools/gpgconf-comp.c index 799154c83..d3f52dd68 100644 --- a/tools/gpgconf-comp.c +++ b/tools/gpgconf-comp.c @@ -134,6 +134,9 @@ typedef enum /* The GnuPG SCDaemon. */ GC_BACKEND_SCDAEMON, + /* The TPM2 daemon */ + GC_BACKEND_TPM2DAEMON, + /* The GnuPG directory manager. */ GC_BACKEND_DIRMNGR, @@ -188,10 +191,10 @@ static const struct NULL, GPGCONF_NAME "-" GPGSM_NAME ".conf" }, { GPG_AGENT_DISP_NAME, GPG_AGENT_NAME, GNUPG_MODULE_NAME_AGENT, gpg_agent_runtime_change, GPGCONF_NAME"-" GPG_AGENT_NAME ".conf" }, - { TPM2DAEMON_DISP_NAME, TPM2DAEMON_NAME, GNUPG_MODULE_NAME_TPM2DAEMON, - NULL, GPGCONF_NAME"-" TPM2DAEMON_NAME ".conf" }, { SCDAEMON_DISP_NAME, SCDAEMON_NAME, GNUPG_MODULE_NAME_SCDAEMON, scdaemon_runtime_change, GPGCONF_NAME"-" SCDAEMON_NAME ".conf" }, + { TPM2DAEMON_DISP_NAME, TPM2DAEMON_NAME, GNUPG_MODULE_NAME_TPM2DAEMON, + NULL, GPGCONF_NAME"-" TPM2DAEMON_NAME ".conf" }, { DIRMNGR_DISP_NAME, DIRMNGR_NAME, GNUPG_MODULE_NAME_DIRMNGR, dirmngr_runtime_change, GPGCONF_NAME "-" DIRMNGR_NAME ".conf" }, { DIRMNGR_DISP_NAME " LDAP Server List", NULL, 0, @@ -602,6 +605,15 @@ static gc_option_t gc_options_gpg_agent[] = }; #endif /*BUILD_WITH_AGENT*/ +static gc_option_t gc_options_tpm2daemon[] = + { + /* The configuration file to which we write the changes. */ + { GPGCONF_NAME"-"TPM2DAEMON_NAME".conf", + GC_OPT_FLAG_NONE, GC_LEVEL_INTERNAL, + NULL, NULL, GC_ARG_TYPE_FILENAME, GC_BACKEND_TPM2DAEMON }, + + GC_OPTION_NULL, + }; #ifndef BUILD_WITH_SCDAEMON #define gc_options_scdaemon NULL @@ -1118,6 +1130,7 @@ static const struct { "gpg", "gnupg", N_("OpenPGP"), gc_options_gpg }, { "gpg-agent","gnupg", N_("Private Keys"), gc_options_gpg_agent }, { "scdaemon", "gnupg", N_("Smartcards"), gc_options_scdaemon }, + { "tpm2daemon", "gnupg", N_("TPM2"), gc_options_tpm2daemon }, { "gpgsm", "gnupg", N_("S/MIME"), gc_options_gpgsm }, { "dirmngr", "gnupg", N_("Network"), gc_options_dirmngr }, { "pinentry", "gnupg", N_("Passphrase Entry"), gc_options_pinentry } -- 2.13.7 From James.Bottomley at HansenPartnership.com Mon Jul 30 22:54:08 2018 From: James.Bottomley at HansenPartnership.com (James Bottomley) Date: Mon, 30 Jul 2018 13:54:08 -0700 Subject: [PATCH tpm-work 0/3] move the tpm-work branch to an assuan based tpm handling daemon In-Reply-To: <6f7c0cfd-8902-a6db-1b3d-7305953432a2@metacode.biz> References: <1532899727.3142.12.camel@HansenPartnership.com> <6f7c0cfd-8902-a6db-1b3d-7305953432a2@metacode.biz> Message-ID: <1532984048.14893.7.camel@HansenPartnership.com> On Mon, 2018-07-30 at 21:44 +0200, Wiktor Kwapisiewicz via Gnupg-devel wrote: > Hi James, > > I'm very interested in your TPM patches (as a user). > > Could I ask you some questions on how does it work? > > I would like to have keys wrapped by TPM in such a way that the > change? in system configuration would render the key useless. As far > as I've? seen it's possible to do that by utilizing Platform > Configuration?Registers (PCRs). Would keys created by your TPM code > have this property? The current gpg2 code just does secure handling for the key, meaning it ties the key to being only released on a single platform, so it currently doesn't do a policy based on the PCR values. That said, there's no reason why it couldn't and if you look at the openssl_tpm2_engine code, it does precisely do this (you can specify a PCR and password policy for the key): https://git.kernel.org/pub/scm/linux/kernel/git/jejb/openssl_tpm2_engine.git/ The difficulty I have with adding PCR policy to TPM protected gpg keys is that PCR policy handling is a very esoteric function and it's difficult to see value beyond the current platform locking the TPM already does since the user would have to understand when the PCR values changed and how to update the keys with new PCR values, which would really put a kink in usability. James From wiktor at metacode.biz Tue Jul 31 09:31:42 2018 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Tue, 31 Jul 2018 09:31:42 +0200 Subject: [PATCH tpm-work 0/3] move the tpm-work branch to an assuan based tpm handling daemon In-Reply-To: <1532984048.14893.7.camel@HansenPartnership.com> References: <1532899727.3142.12.camel@HansenPartnership.com> <6f7c0cfd-8902-a6db-1b3d-7305953432a2@metacode.biz> <1532984048.14893.7.camel@HansenPartnership.com> Message-ID: <8c6ad755-9995-ea0a-28b4-2e47619436cf@metacode.biz> > The difficulty I have with adding PCR policy to TPM protected gpg keys > is that PCR policy handling is a very esoteric function and it's > difficult to see value beyond the current platform locking the TPM > already does since the user would have to understand when the PCR > values changed and how to update the keys with new PCR values, which > would really put a kink in usability. I agree this is more esoteric and probably not that useful for the majority of users. For my use case I'm thinking on full disk encryption with keys copied to TPM where I'd like it to break if the configuration changes. If I changed it I would copy the keys again, if I didn't do the configuration change I'd see it. One way or another TPM keys are already big improvement for secure storage of keys so thank you for working on it! Have a nice day. Kind regards, Wiktor -- https://metacode.biz/@wiktor From andrewg at andrewg.com Tue Jul 31 15:17:29 2018 From: andrewg at andrewg.com (Andrew Gallagher) Date: Tue, 31 Jul 2018 14:17:29 +0100 Subject: Improving the command line UI of gpg In-Reply-To: <20180726232224.243px7fi7ojzjgg4@adversary.org> References: <20180726232224.243px7fi7ojzjgg4@adversary.org> Message-ID: On 27/07/18 00:22, Ben McGinnes wrote: > On Tue, Jul 24, 2018 at 10:29:09AM +0200, Rainer Perske wrote: >> Hello >> >> My opinion regarding this request: I completely follow Werner. Don't >> extend the core GnuPG tool by adding a second user interface into >> the core without urgent need, risiking unnecessary compatibility >> issues and even unnecessary security vulnerabilities. If you want >> another interface, feel free to write a wrapper, based either on the >> existing command line interface or on GPGME. > > Right ... except not via yet another wrapper to the existing command > line binaries. Use GPGME instead. If we're going to extol GPGME as the one stop shop for all wrappers, then we had better make sure it's feature-complete - which it currently is not. I speak as someone who wrote his own wrapper and found that invoking the binaries by hand was the only solution... :-( -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 862 bytes Desc: OpenPGP digital signature URL: From peter at digitalbrains.com Tue Jul 31 16:03:14 2018 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 31 Jul 2018 16:03:14 +0200 Subject: Improving the command line UI of gpg In-Reply-To: References: <20180726232224.243px7fi7ojzjgg4@adversary.org> Message-ID: On 31/07/18 15:17, Andrew Gallagher wrote: > If we're going to extol GPGME as the one stop shop for all wrappers, > then we had better make sure it's feature-complete - which it currently > is not. In this specific context, though, the discussion is about a command-line wrapper that simplifies the command line usage for certain tasks. If something cannot be done through GPGME, you could wonder whether it would be something that needs to be functionality of this "simpler" command-line wrapper at all, or people should just use the gpg command line. 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 James.Bottomley at HansenPartnership.com Tue Jul 31 18:07:37 2018 From: James.Bottomley at HansenPartnership.com (James Bottomley) Date: Tue, 31 Jul 2018 09:07:37 -0700 Subject: [PATCH tpm-work 0/3] move the tpm-work branch to an assuan based tpm handling daemon In-Reply-To: <8c6ad755-9995-ea0a-28b4-2e47619436cf@metacode.biz> References: <1532899727.3142.12.camel@HansenPartnership.com> <6f7c0cfd-8902-a6db-1b3d-7305953432a2@metacode.biz> <1532984048.14893.7.camel@HansenPartnership.com> <8c6ad755-9995-ea0a-28b4-2e47619436cf@metacode.biz> Message-ID: <1533053257.3219.7.camel@HansenPartnership.com> On Tue, 2018-07-31 at 09:31 +0200, Wiktor Kwapisiewicz wrote: > > The difficulty I have with adding PCR policy to TPM protected gpg > > keys > > is that PCR policy handling is a very esoteric function and it's > > difficult to see value beyond the current platform locking the TPM > > already does since the user would have to understand when the PCR > > values changed and how to update the keys with new PCR values, > > which > > would really put a kink in usability. > > I agree this is more esoteric and probably not that useful for the? > majority of users. > > For my use case I'm thinking on full disk encryption with keys copied > to?TPM where I'd like it to break if the configuration changes. If I? > changed it I would copy the keys again, if I didn't do the > configuration?change I'd see it. OK, so there's a problem here: disk encryption has to be done with a symmetric key because asymmetric operations are too slow. The TPM can do symmetric key operations, but certainly not fast enough for bulk data, so the only viable mechanism for disk encryption is for something to release the symmetric key to a software encrypt/decrypt system. In the LUKS model (and the TPM trusted keys model in the kernel), the TPM does this by a data unseal operation which can be linked to PCRs. Gnupg does have a sort of equivalent in the way it encrypts and decrypts messages: it generates a temporary symmetric key and wraps that symmetric key with the recipient public keys but to preserve forward secrecy, the symmetric key is different for every message. So while one could imagine using the gnupg wrapping mechanism for key unsealing it's a bit of a stretch use case. > One way or another TPM keys are already big improvement for secure? > storage of keys so thank you for working on it! You're welcome, James From andreas at almroth.com Tue Jul 31 17:19:06 2018 From: andreas at almroth.com (Andreas Almroth) Date: Tue, 31 Jul 2018 17:19:06 +0200 Subject: Improving the command line UI of gpg In-Reply-To: References: <20180726232224.243px7fi7ojzjgg4@adversary.org> Message-ID: 2018-07-31 15:17 GMT+02:00 Andrew Gallagher : > On 27/07/18 00:22, Ben McGinnes wrote: > > On Tue, Jul 24, 2018 at 10:29:09AM +0200, Rainer Perske wrote: > >> Hello > >> > >> My opinion regarding this request: I completely follow Werner. Don't > >> extend the core GnuPG tool by adding a second user interface into > >> the core without urgent need, risiking unnecessary compatibility > >> issues and even unnecessary security vulnerabilities. If you want > >> another interface, feel free to write a wrapper, based either on the > >> existing command line interface or on GPGME. > > > > Right ... except not via yet another wrapper to the existing command > > line binaries. Use GPGME instead. > > If we're going to extol GPGME as the one stop shop for all wrappers, > then we had better make sure it's feature-complete - which it currently > is not. I speak as someone who wrote his own wrapper and found that > invoking the binaries by hand was the only solution... :-( > > Do we have a list of the missing features in gpgme (to fully support at least gpg)? Looking at the TODO file in git as well as the git site at dev.gnupg.org, I don't really find much that would indicate what needs to be covered. If the gpgme approach is the recommended interface for building wrappers, then perhaps we should at least look at what is missing to make it usable. -------------------------------------------------------------------- Best regards / Med v?nlig h?lsning / Med venlig hilsen /Cordialement *Andreas Almroth* -------------- next part -------------- An HTML attachment was scrubbed... URL: From wiktor at metacode.biz Tue Jul 31 21:15:01 2018 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Tue, 31 Jul 2018 21:15:01 +0200 Subject: [PATCH tpm-work 0/3] move the tpm-work branch to an assuan based tpm handling daemon In-Reply-To: <1533053257.3219.7.camel@HansenPartnership.com> References: <1532899727.3142.12.camel@HansenPartnership.com> <6f7c0cfd-8902-a6db-1b3d-7305953432a2@metacode.biz> <1532984048.14893.7.camel@HansenPartnership.com> <8c6ad755-9995-ea0a-28b4-2e47619436cf@metacode.biz> <1533053257.3219.7.camel@HansenPartnership.com> Message-ID: Hi James, > OK, so there's a problem here: disk encryption has to be done with a > symmetric key because asymmetric operations are too slow. The TPM can > do symmetric key operations, but certainly not fast enough for bulk > data, so the only viable mechanism for disk encryption is for something > to release the symmetric key to a software encrypt/decrypt system. In > the LUKS model (and the TPM trusted keys model in the kernel), the TPM > does this by a data unseal operation which can be linked to PCRs. > > Gnupg does have a sort of equivalent in the way it encrypts and > decrypts messages: it generates a temporary symmetric key and wraps > that symmetric key with the recipient public keys but to preserve > forward secrecy, the symmetric key is different for every message. So > while one could imagine using the gnupg wrapping mechanism for key > unsealing it's a bit of a stretch use case. Agreed, in my setup that I'm... setting up, I'll be using GnuPG to decrypt the keyfile (that's on an unencrypted disk or initramfs) using OpenPGP smartcard. All of this will happen very early in the boot process, that requires some GnuPG binaries to be available by then. The idea is not new and there are already projects that implement that: https://github.com/xdbob/mkinitcpio-gpg-encrypt#configuration-process The TPM could give me additional advantage of knowing the system state did not change and although there are projects for that too... https://github.com/electrickite/luks-tpm ...I'd be very happy if I could have the same key wrapped by TPM and on a smartcard (for recovery purposes). But that's another issue. TPM keys, as an alternative for always-connected smartcard, are very useful on their own in my opinion. Kind regards, Wiktor -- https://metacode.biz/@wiktor From wiktor at metacode.biz Tue Jul 31 21:15:01 2018 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Tue, 31 Jul 2018 21:15:01 +0200 Subject: [PATCH tpm-work 0/3] move the tpm-work branch to an assuan based tpm handling daemon In-Reply-To: <1533053257.3219.7.camel@HansenPartnership.com> References: <1532899727.3142.12.camel@HansenPartnership.com> <6f7c0cfd-8902-a6db-1b3d-7305953432a2@metacode.biz> <1532984048.14893.7.camel@HansenPartnership.com> <8c6ad755-9995-ea0a-28b4-2e47619436cf@metacode.biz> <1533053257.3219.7.camel@HansenPartnership.com> Message-ID: Hi James, > OK, so there's a problem here: disk encryption has to be done with a > symmetric key because asymmetric operations are too slow. The TPM can > do symmetric key operations, but certainly not fast enough for bulk > data, so the only viable mechanism for disk encryption is for something > to release the symmetric key to a software encrypt/decrypt system. In > the LUKS model (and the TPM trusted keys model in the kernel), the TPM > does this by a data unseal operation which can be linked to PCRs. > > Gnupg does have a sort of equivalent in the way it encrypts and > decrypts messages: it generates a temporary symmetric key and wraps > that symmetric key with the recipient public keys but to preserve > forward secrecy, the symmetric key is different for every message. So > while one could imagine using the gnupg wrapping mechanism for key > unsealing it's a bit of a stretch use case. Agreed, in my setup that I'm... setting up, I'll be using GnuPG to decrypt the keyfile (that's on an unencrypted disk or initramfs) using OpenPGP smartcard. All of this will happen very early in the boot process, that requires some GnuPG binaries to be available by then. The idea is not new and there are already projects that implement that: https://github.com/xdbob/mkinitcpio-gpg-encrypt#configuration-process The TPM could give me additional advantage of knowing the system state did not change and although there are projects for that too... https://github.com/electrickite/luks-tpm ...I'd be very happy if I could have the same key wrapped by TPM and on a smartcard (for recovery purposes). But that's another issue. TPM keys, as an alternative for always-connected smartcard, are very useful on their own in my opinion. Kind regards, Wiktor -- https://metacode.biz/@wiktor