- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Jul 21 2021
ok i found it just add "trust-model always" in gpg.conf
now its importing keys but it dosent trust them do you know how to fix this?
gpg2 --verbose --no-secmem-warning --no-greeting --auto-key-retrieve --no-tty --batch --yes --status-fd=2 --encrypt --armor -u <key-id> -r <email> -r <key-id> --output -
gpg: using subkey <sub-key> instead of primary key <primary-key>
[GNUPG:] KEY_CONSIDERED <key-id> 0
gpg: using pgp trust model
gpg: This key belongs to us
gpg: data source: <keyserver>
gpg: armor header: Comment: <key-id>
gpg: armor header: Comment: Name <email>
gpg: pub rsa4096/<key-id> <date> <name> <email>
gpg: key <key-id>: public key "<name> <email>"
imported
[GNUPG:] IMPORTED <key-id> <name> <email>
[GNUPG:] IMPORT_OK 1 <key-id>
gpg: Total number processed: 1
gpg: imported: 1
[GNUPG:] IMPORT_RES 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0
gpg: auto-key-locate found fingerprint <fingerprint>
gpg: using subkey <sub-key> instead of primary key <primary-key>
[GNUPG:] KEY_CONSIDERED <fingerprint> 0
gpg: automatically retrieved '<email>' via keyserver
gpg: <sub-key>: There is no assurance this key belongs to the named user
[GNUPG:] INV_RECP 10 <email>
[GNUPG:] FAILURE encrypt 53
gpg: [stdin]: encryption failed: Unusable public key
Hmm your log does not seem to indicate that the key is requested by GnuPG,
e.g. something like
rmngr[6077.5]: DBG: chan_5 <- KS_GET -- =bernhard@intevation.de
is missing.
OK, thanks for the explanation. But I think that the documentation should be slightly changed to say that the mapping is hardcoded. Otherwise, this may surprise users of different machines with different GnuPG versions (or in discussions between different users), who would see different behaviors when the mapping changes.
GnuPG 2.2.29 does not use keys.gnupg.net anymore. What it does is mapping keys.gnupg.net that is read from an (old) keyserver setting in the configuration files to a (hopefully) working keyserver. The documentation of gpg and dirmngr does indeed still mention keys.gnupg.net. The main problem with updating the documentation is that there isn't a good replacement for keys.gnupg.net and since keys.gnupg.net still works (via the aforementioned internal mapping) it is probably the best option for now.
For the evolution command i get:
2021-07-21 03:04:06 dirmngr[2421] listening on socket '/run/user/1000/gnupg/S.dirmngr'
2021-07-21 03:04:06 dirmngr[2422.0] permanently loaded certificates: 129
2021-07-21 03:04:06 dirmngr[2422.0] runtime cached certificates: 0
2021-07-21 03:04:06 dirmngr[2422.0] trusted certificates: 129 (128,0,0,1)
2021-07-21 03:04:06 dirmngr[2422.6] handler for fd 6 started
2021-07-21 03:04:06 dirmngr[2422.6] DBG: chan_6 -> # Home: /home/<user>/.gnupg
2021-07-21 03:04:06 dirmngr[2422.6] DBG: chan_6 -> # Config: /home/<user>/.gnupg/dirmngr.conf
2021-07-21 03:04:06 dirmngr[2422.6] DBG: chan_6 -> OK Dirmngr 2.2.27 at your service
2021-07-21 03:04:06 dirmngr[2422.6] connection from process 2419 (1000:1000)
2021-07-21 03:04:06 dirmngr[2422.6] DBG: chan_6 <- GETINFO version
2021-07-21 03:04:06 dirmngr[2422.6] DBG: chan_6 -> D 2.2.27
2021-07-21 03:04:06 dirmngr[2422.6] DBG: chan_6 -> OK
2021-07-21 03:04:06 dirmngr[2422.6] DBG: chan_6 <- KEYSERVER --clear hkp://<keyserver>:8080
2021-07-21 03:04:06 dirmngr[2422.6] DBG: chan_6 -> OK
2021-07-21 03:04:06 dirmngr[2422.6] DBG: chan_6 <- WKD_GET -- <email>
2021-07-21 03:04:37 dirmngr[2422.6] DBG: chan_6 -> S SOURCE https://<domain> #the domain dosnt has a WKD service
2021-07-21 03:04:37 dirmngr[2422.6] number of system provided CAs: 143
2021-07-21 03:04:47 dirmngr[2422.6] DBG: http.c:request:
2021-07-21 03:04:47 dirmngr[2422.6] DBG: >> GET /.well- known/openpgpkey/hu/qhff8o86zx5pf4qa1w59eh6ohtnb8w44?l=<local-part>
HTTP/1.0\r\n
2021-07-21 03:04:47 dirmngr[2422.6] DBG: >> Host: <domain>\r\n
2021-07-21 03:04:47 dirmngr[2422.6] DBG: http.c:request-header:
2021-07-21 03:04:47 dirmngr[2422.6] DBG: >> \r\n
2021-07-21 03:04:47 dirmngr[2422.6] DBG: http.c:response:
2021-07-21 03:04:47 dirmngr[2422.6] DBG: >> HTTP/1.1 302 Found\r\n
2021-07-21 03:04:47 dirmngr[2422.6] http.c:RESP: 'date: Wed, 21 Jul
2021 07:04:45 GMT'
2021-07-21 03:04:47 dirmngr[2422.6] http.c:RESP: 'server: Apache/2.4.41 (Ubuntu)'
2021-07-21 03:04:47 dirmngr[2422.6] http.c:RESP: 'location: https://www.<domain>/.well-known/openpgpkey/hu/qhff8o86zx5pf4qa1w59eh6ohtnb8w44?l=<local-part>'
2021-07-21 03:04:47 dirmngr[2422.6] http.c:RESP: 'content-length: 347'
2021-07-21 03:04:47 dirmngr[2422.6] http.c:RESP: 'content-type: text/html; charset=iso-8859-1'
2021-07-21 03:04:47 dirmngr[2422.6] http.c:RESP: 'strict-transport- security: max-age=15768000'
2021-07-21 03:04:47 dirmngr[2422.6] http.c:RESP: 'connection: close'
2021-07-21 03:04:47 dirmngr[2422.6] http.c:RESP: ''
2021-07-21 03:04:47 dirmngr[2422.6] URL 'https://www.<domain>/.well-known/openpgpkey/hu/qhff8o86zx5pf4qa1w59eh6ohtnb8w44?l=<local-part>' redirected to 'https://www.<domain>/.well-known/openpgpkey/hu/qhff8o86zx5pf4qa1w59eh6ohtnb8w44?l=<local-part>' (302)
2021-07-21 03:04:47 dirmngr[2422.6] redirection changed to 'https://www.<domain>/.well-known/openpgpkey/hu/qhff8o86zx5pf4qa1w59eh6ohtnb8w44?l=<local-part>'
2021-07-21 03:04:47 dirmngr[2422.6] DBG: chan_6 -> S WARNING http_redirect_cleanup 0 changed from 'https://<domain>/.well-known/openpgpkey/hu/qhff8o86zx5pf4qa1w59eh6ohtnb8w44?l=<local-host>' to 'https://www.<domain>/.well-known/openpgpkey/hu/qhff8o86zx5pf4qa1w59eh6ohtnb8w44?l=<local-part>'
2021-07-21 03:04:57 dirmngr[2422.6] DBG: http.c:request:
2021-07-21 03:04:57 dirmngr[2422.6] DBG: >> GET /.well- known/openpgpkey/hu/qhff8o86zx5pf4qa1w59eh6ohtnb8w44?l=<local-part>
HTTP/1.0\r\n
2021-07-21 03:04:57 dirmngr[2422.6] DBG: >> Host: [http://www.<domain>\r\n]www.<domain>\r\n
2021-07-21 03:04:57 dirmngr[2422.6] DBG: http.c:request-header:
2021-07-21 03:04:57 dirmngr[2422.6] DBG: >> \r\n
2021-07-21 03:04:57 dirmngr[2422.6] DBG: chan_6 -> S PROGRESS tick ? 0 0
2021-07-21 03:04:57 dirmngr[2422.6] DBG: http.c:response:
2021-07-21 03:04:57 dirmngr[2422.6] DBG: >> HTTP/1.1 404 Not Found\r\n
2021-07-21 03:04:57 dirmngr[2422.6] http.c:RESP: 'date: Wed, 21 Jul
2021 07:04:55 GMT'
2021-07-21 03:04:57 dirmngr[2422.6] http.c:RESP: 'server: Apache/2.4.41
Jul 20 2021
i dont have one what shoud i put in it
i dont have one what shoud i put in it
Tried it myself, getting the pubkey seems to work here.
Debian gnupg Version: 2.2.27-2~bpo10+1
Yes same result
Jul 19 2021
Did you try "--auto-key-retrieve"?
The comand that works says:
For formatting there are four modes: Formatting forced off (the default)/force on/on/off. The latter two modes allow the user to change the option.
This is a duplicate of T5522: gpgme: qt: t-various.cpp TestVarious::testSignKeyWithExpiration fails on 32 bit.
Jul 18 2021
Jul 17 2021
Jul 16 2021
Can you show the output of the command that works and the command that does not (and gets called by evolution),
please also add a "-v" to the options.
This key server also dosnt work
It could also be a problem of the keyserver (some hagrid instances are known to deliberately break RFC4880), can you try with a different keyserver, e.g. http://keys2.andreas-puls.de/.
And... as long as I read the PCT patches, it is not needed to export those API to users.
It is only needed internally for PCT tests (at most).
I am considering API enhancement, for this task.
This rwlock guarantees access with ctrl->card_ctx is always valid.
Jul 15 2021
[[ URL | foreach ($list as $item) {
work_miracles($item);
} ]]
Forgot to mention one thing: after changing my user folder directory I lost all my Outlook contacts. I was able to recover them... make sure you have a backup before attempting this!
Jul 14 2021
Jul 13 2021
I went through the patches above + what I suggested in previous comments, tested everything against both upstream and libgcrypt in Fedora in FIPS mode. There were slight differences, some cases were already fixed in master, some needed to upstream some of our changes, but the result is 10 patches working in both FIPS and non-fips mode, hopefully enough annotated. If not, please, ask for clarifications.
Jul 12 2021
I just had the same issue as hurui200320. My user name contains a "ç" and Kleopatra did not start. The Windows event logger reported a crash in libstdc++-6.dll. This was with gpg4win-3.1.16. Installing gnupg 2.3.1 did not change anything.
I went through the OpenSSL drafts. The module boundary in OpenSSL will be separate fips.so object and only non-deprecated functions of OpenSSL 3.0 will be FIPS compliant. There is a global state, that will allow only approved algorithms and modes and there will be API to query the FIPS mode status using OSSL_PARAM_get* functions, but we still have some unknowns so I hope we will know more on the next meeting.
(OpenSSL for FIPS support is a bit tricky, which is described in README-FIPS.md in their distribution. It offers OpenSSL FIPS provider as shared library fips.so.)
Jul 11 2021
Jul 10 2021
Jul 9 2021
Just FYI, NSS offers following API:
Jul 8 2021
I have couple of references from libssh:
gniibe: Can you please check what openssl does exactly. The problem is that we currently have no permanent state for Libgcrypt (i.e. something stored on disk per user or even better global)
FWIW: Unfortunately everyone is moving to GCM, even Outlook. While GnuPG was evaluated by the German BSI we had discussions about this and their evaluators were wary about GCM due to its brittleness thus our use of OCB was very welcomed. OTOH, another approved product meanwhile comes with GCM for S/MIME and thus it seems thatGCM is accepted.
rM6a79e90dedc19877ae1c520fed875b57089a5425 looks good
There is no point in questioning whether a couple of words change racism or any other human problems of these days. It will not.
I was so far testing with changes on top of our patches.
Right. The AES-GCM was not allowed in FIPS mode until recently and I think now it is acceptable only for certain protocols (TLS, SSH), which guarantee that the IV is handled "correctly". As mentioned by gniibe, the requirements is that one should not be able to set IV to any specific value. The IV should be incremented automatically inside of the library (with some mask length + some generator configuration), somehow similarly as it is done with openssl, which would probably requite a new API in libgcrypt.
With `/etc/gcrypt/fips_enabled/', make check fails by:
If I understand correctly, to conform FIPS, we need to ensure Key/IV pair uniqueness (See "Implementation Guidance for FIPS 140-3", Annex C. "C.H Key/IV Pair Uniqueness Requirements from SP 800-38D").
Use of the API to set IV by any value may be considered bad.
Update: still ./basic --fips fails (for me), because of GCM (18 errors).
Need to fix T4873: Enable AES GCM in FIPS mode.
Jul 7 2021
Thanks for the reply, this source code file and suggestions are very useful. Let gpg execute commands is a solution, but it is not optimal compared to providing a functional interface.
In addition, it is reversible to revoke the subkey by expiring it. But I will use the solutions you provide at this stage, knowing that you have time to provide better solutions. thank you!
Sorry, this is not acceptable to me. <rant>You don't change racism by avoid words which are may be connected to racism. Master is a term used for example to indicate that a person is proficient in her profession. Slave is (in theory) a historic term to describe, well slaves. That is humans who are non-free and are not allowed to control their lives - like the majority of humans these days - they are just called different and the methods of suppression are different than in the past. In fact a Roman slave (but not a medieval bondsman) had well defined and esteemed rights not something the majority of US citizen with a dark skin has in practice. Term abolished, racism abolished, works as good as freeing the US slaves in the 1856, the 1960, or still today. It did not work. Mr. Kings hope has not yet realized itself and is now maybe farther away than we all had hoped in the second half of the last century. Don't cover facts by changing words used in a very different context.</rant>
That crcalgo can be any digest algorithm and SHA256 seems best option to me.
Thank you for checking and for revised patch. I tested your patch and it works fine for the basic test up until this failure with the crcalgo:
basic: algo 316, crcalgo: 3, gcry_md_open failed: Invalid digest algorithm basic: algo 317, crcalgo: 3, gcry_md_open failed: Invalid digest algorithm
These are GCRY_MD_SHAKE128 and GCRY_MD_SHAKE256, but the md used here is actually GCRY_MD_RMD160 which is hardcoded and not allowed in FIPS.
What do you mean by "exporting revocation certificates"? Once such a certificate is imported you simply export the public key including the revocation signature. Otherwise, simply takes the revocation certificates from ${GNUPGHOME}/openpgp-revocs.d where they are written to, if you generate a key. Kleopatra uses gpg directly to generate a revocation certificate mimicking what gpgme would do: See https://dev.gnupg.org/source/kleo/browse/master/src/commands/genrevokecommand.cpp.
That reminds me that we we should replace libgcrypt's internal debug functions by those from gpgrt. We have a dependency for gpgrt anyway and thus we should avoid code duplication. Sure we will keep the existsing public functions but that is easy given that gpgrt comes with gpgrt_logv since 1.28 which we can make mandatory (currently libgcrypt requires 1.27 (from 2017, with 1.28 is from 2018)
I applied rC297d31294333: tests: Fix messages to STDERR when FIPS mode is enabled.. Please note that your intention to change check_digests is right, but your patch actually didn't; When a MD algo is not supported, gcry_md_test_algo returns != 0 (an error code), and it "continues" to next entry (before the change).