It is unlikely that the tofu stuff will get into widespread use in the 2.2 version - if at all.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jul 29 2022
As 2.3.7 was released on the 11th of July, see https://lists.gnupg.org/pipermail/gnupg-announce/2022q3/000474.html
I guess that this issue should be closed and some issues moved to one with 2.3.8.
Jul 28 2022
Probably, PIPE_REJECT_REMOTE_CLIENTS mode and lpSecurityAttributes=NULL is OK.
Here is the parser output:
$ python3 sd.py --type=pipe "D:P(A;;GA;;;SY)(A;;GA;;;BA)(A;;0x12019b;;;AU)" D:P(A;;GA;;;SY)(A;;GA;;;BA)(A;;0x12019b;;;AU) Discretionary ACL: P(A;;GA;;;SY)(A;;GA;;;BA)(A;;0x12019b;;;AU) Flags: P: SE_DACL_PROTECTED (Blocks inheritance of parent's ACEs)
I think that the last argument of CreateNamedPipeA can limit the access to the named pipe.
Here is a patch to implement the functionality with --enable-win32-openssh-support.
Jul 27 2022
Backported for for 2.2.37
I just confirmed that firmware 5.4.3 works fine with the changes (to be 2.2.37 and 2.3.8).
Jul 26 2022
Jul 18 2022
as of 2.3.7 (which I just updated to) this works. ticket can be closed
Please give us more information.
- Do you change SSH program?
- If so, please check if adding configuration https://dev.gnupg.org/T5935#157674 for ssh works.
- Do you mean, reinstalling gpg 2.3.4 fixes your issue?
- Are you using with smartcard/token? Which one (Yubikey/Zeitcontrol/Gnuk), if it's the case?
Jul 15 2022
Does Yubico furnish you with devices for test...
Jul 14 2022
Thanks @gniibe. Does Yubico furnish you with devices for test, or did you have to order that at your own/the project's expense?
Jul 12 2022
I'm going to backport this to 2.2, as it found useful.
It's in 2.3.7.
Changed the tags and the title.
Fixed in 2.3.7.
Fixed in 2.3.7.
Jul 10 2022
Due to vacation the review may take some time.
Jul 8 2022
Any chance someone is able to review the posted patch?
Jul 5 2022
Let me know how best to submit it
I tried to submit the below patch to gnupg-devel@lists.gnupg.org, but get an Unrouteable address error. Let me know how best to submit it
Jul 4 2022
Jun 29 2022
The first ideas sounds best to me. Patches please to the mailing list.
Jun 28 2022
FIPS 140-3 (https://csrc.nist.gov/Projects/cryptographic-module-validation-program/fips-140-3-standards) points to SP 800-140Dr1 (https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-140Dr1.pdf) to list acceptable "Security Parameter Generation and Establishment Methods". From this document, RFC 5869 (i.e., HKDF with the counter at the end) can be reached via two paths:
Jun 24 2022
In T6040#159431, @Valodim wrote:I suppose you're right, we might have crossed that bridge a while ago. Simple availability of certificate- or even signature-specific keyserver URIs just make the risks of honor-keyserver-url more obvious than before.
I suppose you're right, we might have crossed that bridge a while ago. Simple availability of certificate- or even signature-specific keyserver URIs just make the risks of honor-keyserver-url more obvious than before.
In T6040#159428, @Valodim wrote:This is a reasonable feature, however it should be noted that this implies a fairly large metadata leak: You are essentially adding a URI to signatures that will be pinged on signature verification.
This is a reasonable feature, however it should be noted that this implies a fairly large metadata leak: You are essentially adding a URI to signatures that will be pinged on signature verification.
I don't see why this is a child task of T6020: the features are similar, but they don't actually impact each other in any way.
Jun 23 2022
Jun 22 2022
Jun 16 2022
I pushed the change needed for GnuPG to t5964 branch.
See: https://dev.gnupg.org/rGc281bd94349e4f7997a89927aaa2c2f45004b902
Added HKDF implementation to master.
Jun 14 2022
Here is a test signature with long notation data. During verification gpg faults when emitting the NOTATION_DATA lines.
Thank you. Applied.
Jun 13 2022
Jun 9 2022
gpg tries to find the "best" key using get_best_pubkey_byname (https://dev.gnupg.org/source/gnupg/browse/master/g10/getkey.c$1507), but the applied rules are not clearly documented in one place.
Because it's the library which refuses null passphrase as input, only possible options are either:
Jun 7 2022
I can only find this one: https://github.com/patrickfav/singlestep-kdf/wiki/NIST-SP-800-56C-Rev1:-Non-Official-Test-Vectors
Jun 2 2022
nice, that's great news! I'll have to try it out when I get a chance.
Funnily I created a file dirmngr/rfc3161.c last Sunday. I can't tell how long it will take but I am definitely interested in using GnuPG to create qualified signatures. Timestamp support is at least good for testing.
Jun 1 2022
@werner There's renewed interest with protecting supply chains. GnuPG is used by a lot of open source systems. Is it possible to bump the priority on this?
May 31 2022
I learned that it's now called "OneStep KDF" in SP 800-56Cr2.
It's "SSKDF" in OpenSSL (Single Step KDF, perhaps).
May 29 2022
Related problem exists with the modern ESIGN application. I think I fixed that but the whole Telesec eIDAS QES case needs more work.
May 27 2022
The changes have been applied with Werner's suggested improvement with revision rG35b17550706c: gpg: Look up user ID to revoke by UID hash
May 23 2022
Any progress on how the solution for this have been considered? Thanks.
May 19 2022
At first, we need to add/enhance new API for KDF in libgcrypt. Currently, the term "KDF" in libgcrypt is used with narrower focus, that is, only for password->key KDF.
May 17 2022
Lets implement it for 2.3
May 10 2022
Thank you, @gniibe. That's what I was missing: installing libsqlite3-dev made the difference.
Pushed the fix.
You need to install a package like sqlite-devel or libsqlite3-dev, so that you can have development header files and library (sqlite3*.h and libsqite3.so) and pkgconfig file (pkgconfig/sqlite3.pc).
Yes, I saw that in the logs and installed those packages. Now I have sqlite and sqlite3 in /usr/bin, but that doesn't seem to have changed anything.
the link's target doesn't exist
May 9 2022
Yes, of course I did that. The error output I included followed the sequence
Please do make at first before invoking make check. It creates symbolic links for executables.
May 6 2022
May 5 2022
When we implemented this first, Libgcrypt had no appropriate KDF support. I recall that I considered to change this but it turned out the for 2.2 the changes are too large. For 2.3 we will consider such a change.
May 3 2022
Fixed in GnuPG 2.3.5.
Nitrokey Start uses Gnuk as its firmware. You need to upgrade its firmware to version 1.2.16 or newer.
Please note that when upgrading the firmware, your keys will be removed.
May 2 2022
Its a nitrokey start. I gave it another spin just to make sure, and again when updating to openssh 9.0 and "gpg (GnuPG) 2.3.6-unknown", it fails (again with careful gpgconf --kill gpg-agent etc. Double checked the downloaded source code by arch's makepkg, appears to have that patch applied. Also tried adding -o KexAlgorithms=-sntrup761x25519-sha512@openssh.com to the ssh command, which didn't help.
KexAlgorithms -sntrup761x25519-sha512@openssh.com
Please describe what token is used. For my use cases with rGe8fb8e2b3e66: scd: Don't inhibit SSH authentication for larger data if it can., both of Gnuk (>= 1.2.16) and Yubikey (>= 5) work well.
Apr 29 2022
this looks similar to https://dev.gnupg.org/T5935 and https://bugs.debian.org/1008573
I'm seeing something just like this when attempting to install gnupg-2.3.6 on Ubuntu 22.04 LTS (running under WSL 2, if it matters).
Apr 28 2022
FYI, I built 2.3.6 using a modified archlinux PKGBUILD (& disabling patches to avoid conflicts), then did:
gpgconf --kill gpg-agent
gpgconf --launch gpg-agent
but ssh still fails as before