Sorry, it's my misunderstanding.
_gcry_fips_run_selftest can be run by GCRYCTL_SELFTEST.
I was confused by the function name. Perhaps, it is good to change the name of function to _gcry_run_selftest.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Jan 19 2022
@werner Those removed tests are selftests which are only invoked by FIPS mode for its requirement of selftests.
AFAICS, the last commit removes some tests. We should never remove a test just because FIPS does not allow it. The old tests need to be run in non-fips mode.
Pushed the change in rC76aad97dd312: fips: Reject shorter key for HMAC in FIPS mode..
thanks, looks good!
Jan 18 2022
that's great news to my eyes. thanks werner!
$ gpg --debug 0 --gpgconf-test gpg: reading options from '/etc/gnupg/gpg.conf' gpg: reading options from '/home/foo/.gnupg/gpg.conf' gpg: reading options from '[cmdline]' gpg: reading options from '/etc/gnupg/common.conf' gpg: reading options from '/home/foo/.gnupg/common.conf'
Excuse me you are right of course. man gpgconf | grep quot says it all.
man gpg | grep quote nor man gpgconf | grep quote does not tell anything about it. I recognized the single opening quote of "string at post processing the output of gpgconf --list-options to generate a gpgconf.conf template. I just expected a closing quote for "string".
From which version on there will be global config files? The only info I found was about /etc/gnupg/gpgconf.conf and /etc/skel/.gnupg/* to manage presets.
vitusb: We had this discussion on cryptography@ years ago. No need to start it again - or well, try it over there. This is a bug tracker and not a discussion forum.
@werner Hmm, okay. So I have tested the wrong thing. To me /etc/gnupg/gpgconf.conf looked very much like a global config file I was supposed to test. I have looked at /etc/gnupg, found the example gpgconf.conf and played around with it. It had some effects (see above), so I assumed that it should work. Since it's obvious from my tests, that it doesn't really work as documented anymore, all corresponding code should be removed entirely (or fixed if it should be kept for backward compatibility).
ikloecker: gpgconf.conf ist not anymore used since we have the global config files.
Thank you.
With /etc/gnupg/gpgconf.conf
[empty lines and comment lines] * gpgsm verbose [no-change] gpgsm quiet [no-change] gpgsm debug-level [no-change] gpgsm log-file [no-change] gpgsm include-certs [no-change] gpgsm compliance [no-change] gpgsm default-key [no-change] gpgsm encrypt-to [no-change] gpgsm keyserver [no-change] gpgsm disable-dirmngr [no-change] gpgsm auto-issuer-key-retrieve [no-change] gpgsm p12-charset [no-change] gpgsm disable-crl-checks [no-change] gpgsm enable-crl-checks [no-change] gpgsm disable-trusted-cert-crl-check [no-change] gpgsm enable-ocsp [no-change] gpgsm disable-policy-checks [no-change] gpgsm cipher-algo [no-change]
all options are correctly flagged as "no change" in the output of gpgconf
More weirdness. With gpgconf (GnuPG) 2.2.34-beta23 I get:
These curves are not the default in the compliance mode "gnupg" only if you explicitly switch to the BSI defined "VS-NfD" mode they become default.
This is related to the fix for T5100. We had to to remove the version number from the AID and gpg --card-status takes the version number from the AID. gpg-card was fixed for this but gpg --card-status not.
--apply-defaults is an obsolete option because we now have global config files. I would also like to get rid of --debug-level but that won't be easy. Using --debug LIST_OF_DEBUG_FLAGS is a more versatile way of specifying debug options.
Nope. The double quote indicates a string. See the man page.
And we need to fix selftest for shorter keys.
@pmgdeb : IIUC, what we need is:
diff --git a/cipher/md.c b/cipher/md.c index 34336b5c..4f4fc9bf 100644 --- a/cipher/md.c +++ b/cipher/md.c @@ -903,6 +903,9 @@ prepare_macpads (gcry_md_hd_t a, const unsigned char *key, size_t keylen) { GcryDigestEntry *r;
Thank you, applied.
Jan 17 2022
Potential fix posted here: https://invent.kde.org/pim/kleopatra/-/merge_requests/11
Thanks for looking into this, @gniibe! over on https://bugs.debian.org/1003313 Helmut is asking for a re-consideration because he wanted to match arm-linux-musleabihf. Would you be ok with a change like my proposal rE371d1c952297f781277b979a4662859ec80fe836 (on branch dkg/expand-musl), that expands *-*-linux-musl to *-*-linux-musl* ?
In T5512#153650, @Jakuje wrote:This is my draft for the FIPS indicator KDF. I think we do not need to keep the original GCRYCTL_FIPS_SERVICE_INDICATOR if we replace it also in the tests. This will also need some tests and documentation update.
libgcrypt-fips-indicator-kdf.patch3 KBDownload
In T5783#153879, @werner wrote:Sending a private key with just the local protection is not a good idea.
In T5784#153872, @werner wrote:Please no holy wars on the type of curves. NIST as its opinon, Europe has its opinion, DJB has of course a different opinion. Please use the the cryptography ML for such political/technical discussions.
After commenting out the options that gpgconf 2.3 complains about I get:
$ gpgconf --version gpgconf (GnuPG) 2.3.5-beta17 Copyright (C) 2021 Free Software Foundation, Inc. License GNU GPL-3.0-or-later <https://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law.
I tried to see what gpgconf from master says, but I only get
$gpgconf --list-options gpg gpgconf: unknown option 'try-secret-key' at '/etc/gnupg/gpgconf.conf', line 95 gpgconf: unknown option 'reader-port' at '/etc/gnupg/gpgconf.conf', line 96
This also doesn't look right:
The following looks very much like a bug.
Example:
/etc/gnupg/gpg.conf:
default-key B81CE112B26A8EA8BE7B95D2E375339BF4C51840
With rG8c878ae4c9dfa9fe26aa15f4f9db3e86833575e9 some rules for allow-mark-trusted were removed from doc/examples/gpgconf.conf, but the comments below which are supposed to explain the example rules still talk about allow-mark-trusted.
I'm not completely sure but it might be convenient to mark HMAC keys with lengths less that 112 as non-approved in FIPS mode for both generation and verification. It could be easily implemented by adding a check using cipher/mac-hmac.c:hmac_get_keylen() or at the algo level. What do you think?
Sending a private key with just the local protection is not a good idea. It is better to export the key and then send it in an encrypted mail - for example in symmetric mode with a strong password.
Btw. had to revert your unique ptr change ;-) I didn't want to raise the c++ level just for that.
ikloecker I have just added the ki18n main code to pinentry-qt as qti18n.cpp this fixes it for me. I have commented out everything but the base catalog.
Please no holy wars on the type of curves. NIST as its opinon, Europe has its opinion, DJB has of course a different opinion. Please use the the cryptography ML for such political/technical discussions.
OTOH, inst-qttranslations.nsi copies all .qm files needed by the qt_<language>.qm files.
For the appimage I have added a patch (backported from ki18n) that makes sure that the Qt translations for qtbase are loaded even if the (unneeded) translations for qtscript, qtmultimedia, and qtxmlpatterns are missing. See 0001-Load-Qt-translations-even-if-some-catalogs-are-missi.patch.
Saw this again and the commit was not in the Stable 2.2 branch. I have cherry picked it. This should resolve this issue.
sorry, I'm a bit confused now and probably everything I wrote above is incorrect.
thanks for approving account.
build error happens in automatic configuration (when --enable-ppc-crypto-support is omitted from ./configure) and -mcpu=powerpc64le, -mcpu=power8 or power9 or -mpower8-vector flags are not passed to compiler.
Thank you, applied.
Also, add another change.
Backported to 2.2, too.
On behalf of @gyakovlev (pending approval for his account):
[03:05:23] <@gyakovlev> AC_DEFINE(HAVE_COMPATIBLE_CC_PPC_ALTIVEC,1, [03:05:23] <@gyakovlev> [Defined if underlying compiler supports PowerPC AltiVec/VSX/crypto intrinsics]) [03:05:34] <@gyakovlev> they should definitely check for __POWER8_VECTOR__ 1 [03:05:44] <@gyakovlev> it's not plain altivec [03:06:52] <@gyakovlev> that power check should check for __POWER8_VECTOR__ [03:06:52] <@gyakovlev> not only for what they check already. [03:08:59] <@gyakovlev> it probably should be checked after __powerpc64__ or instead of it.
Looks like it's triggered if e.g. -mcpu=power9 isn't in CFLAGS.
Build log here: