At this moment, we agreed on keeping the current behavior and not allowing the SHA1 for verification either. But we might need to revisit that in the future if this will cause issues. Or we might go the way of switching the service to non-fips if needed, rather than creating some more middle ground.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Oct 20 2021
Thanks! I was able to compile the current source code of npth (1.7) (with gcc 7.1. and ldd (GNU libc) 2.3.2 ). The error error: unknown type name ‘pthread_rwlock_t’ didn't occour.
Okay. So the product prefix has been added intentionally to the version.
The below change makes the function report a general error if gpgconf didn't write any output on stdout:
diff --git a/src/engine-gpgconf.c b/src/engine-gpgconf.c index 28f91158..21211366 100644 --- a/src/engine-gpgconf.c +++ b/src/engine-gpgconf.c @@ -1245,6 +1245,13 @@ gpgconf_query_swdb (void *engine, } }
This commit changed the behaviour:
https://invent.kde.org/pim/libkleo/-/commit/bf7af017d84747d83ec16e0f8ab03b656899bfcd#c50ded182b9e04dd8e8c34c84c3bfd32ec2c5b46_149_214
When changing the filel contents of C:\Program Files (x86)\Gpg4win\VERSION from
Gpg4win-3.1.15
to
3.1.15
the update check works again.
rW4dcba538b74e2ad2d64adb4273176a4e4f85e599 changes the contents of the VERSION file as part of T5056 both on 2020-09-20.
Well spotted @ikloecker !
Lets downgrade the priority and keep it open in case we get reports from customers. The other option would be to replicate this here using our AD demo network. But that is a bit time consuming.
Yes, but it is more complicated to do because you need to download a binary version of the keys and check that they are authentic. Most users don't known it. Anyway, I meanwhile created a Brainpool release sign key and new VSD releases are signed with that. The override option does not really harm, but we can close this bug due to the new release key.
Perhaps, as a library (considering the benefit of users), it would be better to allow signature verification with SHA-1, to defer the decision to application.
Well, the debug output
org.kde.pim.kleopatra: No update for: "Gpg4win-3.1.15"
and, even more clearly,
GPGME 20211019T134123 07DC _gpgme_io_spawn: check: path=0x031deff0 argv[ 0] = C:\Program Files (x86)\GnuPG\bin\gpgconf.exe GPGME 20211019T134123 07DC _gpgme_io_spawn: check: path=0x031deff0 argv[ 1] = --query-swdb GPGME 20211019T134123 07DC _gpgme_io_spawn: check: path=0x031deff0 argv[ 2] = gpg4win GPGME 20211019T134123 07DC _gpgme_io_spawn: check: path=0x031deff0 argv[ 3] = Gpg4win-3.1.15
reveals that Kleopatra via gpgme ran the command
gpgconf --query-swdb gpg4win Gpg4win-3.1.15
i.e. that current is "Gpg4win-3.1.15".
I tried to reproduce this. Experimentally, I added P15CardWidget::searchPGPFpr() to OpenPGPKeyCardWidget, commented out the code that checks for an LDAP keyserver and called the function with a fixed fingerprint.
@ikloecker Note you can easily setup a test instance using one of Microsoft'S test VMs, see https://lists.wald.intevation.org/pipermail/gpg4win-devel/2021-October/001769.html
Thank you for having a look into that. The change looks fine, but I need to get some clarification about what "Legacy use" means for "Digital signature verification" in the Table 8 of https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf
We should disable the menu button until it is fixed. I think it should be on the roadmap of 4.0 to have this working.
I have a little concern for glibc 2.34 (which has dummy libpthread and all is actually in libc).
Okay, any thing else missing in nPth?
(3-1) is implemented: rCa23cf78102f3: cipher: Reject SHA-1 for hash+sign/verify when FIPS enabled.
For a programmer like me, it is easier if the behavior will be:
The problem is that the SHA-1 as a digest algorithm itself is allowed in FIPS mode (for non-cryptographic digests), but using it as part of approved signature scheme is not allowed
The current code is inconsistent about its behavior: how non-approved digest algos are supported or not when FIPS enabled.
If .fips will mean FIPS 140-3, why not the following patch?
diff --git a/cipher/sha1.c b/cipher/sha1.c index 3bb24c7e..cb50ef66 100644 --- a/cipher/sha1.c +++ b/cipher/sha1.c @@ -759,7 +759,7 @@ static gcry_md_oid_spec_t oid_spec_sha1[] =