AFAIK, Stephan evaluated it only for x86, let me ask him ...
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Jun 4 2020
Jun 3 2020
We already have the option --sender which does what @mgorny requests but only in the TOFU case. I need to revisit the system to see whether we can extend it to WoT and direct key signatures.
Done.
Let's wait with this until we ship a libgpgrt. I am not sure what the best way to migrate to another library name. By current idea is start with some release installing two libraries using the two names but with identical code. Some releases later we could require a configure option to install libgpg-error in addition to libgpgrt.
Thanks. I bumped it up to be in sync with GnuPG 2.2. It also does not make sense to require a Libgcrypt which has reached end-of-life; Thus we now need 1.8.
I bumped up the requirement to 1.25 because we also use error codes defined there. To be on the safe side with older distros I defined the missing error code instead of requiring 1.27.
Thanks for the report.
I now describe the shortcuts as development and 2.2 stable branch.
Jun 2 2020
The problem is with the code for T3656
Thanks for the report. I can reproduce this by replying to S/MIME enc & sign mails.
no prob
@Angel: The mail server log showed 0 bytes for the affected messages.
While triaging issues this looks to me more like a support case. And not an issue of the software itself. So I'm closing this issue.
Uh, I just noticed that this issue is from dec. 2019 I am unsure why I overlooked this and only noticed it in my regular tracker check today.
@JJworx Thanks for the suggestion / feature request.
As of now we doubt that the proposed patch helps and we even fear that it could make things worst. Thus, as long as there is we have no description of an attack we won't do anything about it.
Change of gpg-agent for ECC-SOS
I agree.
It (only) fixed a regression where a user can specify a fingerprint to select a card (rarely used feature in the scdaemon protocol).
Jun 1 2020
Are they actually zero-byte mails, or is the content mungled as an attachment? (which those replying probably overlooked, and would still be hard to interpret, as it would containe MIME parts)
May 31 2020
May 29 2020
Although this is a standard behaviour for Unix tools, you are right that it makes sense to tell the user about the problems. And well, the version info should not appear either.
FYIL This is delayed because there are some dependencies to internals of gnupg.
Merged. Thanks.
Ok. However, I don't think that the fingerprint is really important. We can compute it anyway as long as we have the creation date. The keygrip is meanwhile more important but that is also easy to compute.
Perhaps, no change would be required.
My major concern is that: the data object for fingerprints C5 and C6 were defined as fixed-size 60-byte objects (and actually _is_ defined still in the current specification of 3.4), but it's 80-byte (newer Yubikey), which might cause problem(s).
May 28 2020
Is there a blogpost or similar where the use of several smartcards following this improvement is explained to n00bs like me? :) For now all I find is this thread and some SE answers saying it does not work yet (https://security.stackexchange.com/questions/154702/gpg-encryption-subkey-on-multiple-smart-cards-issue) . If somebody could post a new answer on SE / write a small blog post or similar that would be great. Useful would be to have 1) from which versions and over is that available 2) how this works / how to use.
Why do you think that we need to care about the attestation key? Where possible I take in new code in account that we will have more OpenPGP keys, but right now I don't think that is makes sense to replace our data structures for that the 3 element arrays we currently use are okay for the 3 standard keys. We can latter see how to replace them. At one place I already introduced something new:
Here is a dump of my token (Yubikey 5.2.6). I used the new apdu command of gpg-card along with "undump | dumpasn1 -", which saves quite some time:
Hand parsing the data object content:
fa 82 01 e2 c1 06 010800001100 c1 06 010c00001100 c1 06 011000001100 c1 09 132a8648ce3d030107 c1 06 132b81040022 c1 06 132b81040023 c1 06 132b8104000a c1 0a 132b2403030208010107 c1 0a 132b240303020801010b c1 0a 132b240303020801010d c1 0a 162b06010401da470f01 c1 0b 162b060104019755010501 c2 06 010800001100 c2 06 010c00001100 c2 06 011000001100 c2 09 122a8648ce3d030107 c2 06 122b81040022 c2 06 122b81040023 c2 06 122b8104000a c2 0a 122b2403030208010107 c2 0a 122b240303020801010b c2 0a 122b240303020801010d c2 0a 162b06010401da470f01 c2 0b 162b060104019755010501 c3 06 010800001100 c3 06 010c00001100 c3 06 011000001100 c3 09 132a8648ce3d030107 c3 06 132b81040022 c3 06 132b81040023 c3 06 132b8104000a c3 0a 132b2403030208010107 c3 0a 132b240303020801010b c3 0a 132b240303020801010d c3 0a 162b06010401da470f01 c3 0b 162b060104019755010501 da 06 010800001100 da 06 010c00001100 da 06 011000001100 da 09 132a8648ce3d030107 da 06 132b81040022 da 06 132b81040023 da 06 132b8104000a da 0a 132b2403030208010107 da 0a 132b240303020801010b da 0a 132b240303020801010d da 0a 162b06010401da470f01 da 0b 162b060104019755010501
And here is (raw) dump of the data object FA:
Here is the dump of "Application Related Data" (6E):
6e 82 01 47 4f 10 d2760001240103040006106160490000 5f 52 08 00730000e0059000 7f 74 03 810120 73 82 01 20 c0 0a 7d000bfe080000ff0000 c1 0b 162b06010401da470f0100 c2 0c 122b06010401975501050100 c3 0b 162b06010401da470f0100 da 06 <-------------------------------------- This is algorithm attributes for Attestation key (Yubikey specific) 010800001100 c4 07 ff7f7f7f030003 c5 50 eeeed1b50b1b1d9c669033fe019e94a27992b44c d00b630fdcb5c4397d5ffbd69aa68a3ff9f8ed10 1b2a3d46f4f0c5afd0115e7eb858d476daf64cdb 0000000000000000000000000000000000000000 <--- This appears to be fingerprint of Attestation key c6 50 0000000000000000000000000000000000000000 0000000000000000000000000000000000000000 0000000000000000000000000000000000000000 0000000000000000000000000000000000000000 <--- This appears to be fingerprint of some key related to Attestation key??? cd 10 5e58b1e65e58b1c55e58b1f900000000 de 08 0102020203028102 7f 66 08 02020bfe02020bfe d6 02 0020 d7 02 0020 d8 02 0020 d9 02 0020