Re: gpg generate key is not finishing
Am Freitag 05 Juni 2020 15:16:13 schrieb Williams, Chad L via Gnupg-users: > Is there a site to write the bug report or response to this email? If the report is complete enough https://dev.gnupg.org/ may take it, but often this ml or the devel ml is better. The important part is the diagnosis logs, you enable them with the -v and --debug command line flags. And you may need shell redirection to see it. E.g. GNUPGHOME=~/dot-gnupg-test2/ gpg -vvv --debug-all --quick-generate-key t...@example.com 2>debug-log.txt Regards, Bernhard -- www.intevation.de/~bernhard +49 541 33 508 3-3 Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998 Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: root certificate for smime missing gpgconf --launch dirmngr
Hi Uwe, Am Sonntag 07 Juni 2020 17:14:10 schrieb Uwe Brauer via Gnupg-users: > However the root certificate is still not found. Thunderbird provides > this certificate so I could install it manually. > However I would prefer an automated solution. from my point of view, installing a root CA in the hiearchical trust model means that you fully trust it, thus it cannot be done automatically, unless you have a trusted sources of root certificates. If you trust a set of root certificates, like the ones shipped with your operating system or a different application, you could just import them all and mark them trusted. Of course you would need to sync this, if the set changes on updates. Some hints about using CMS and S/MIME are here https://wiki.gnupg.org/X.509 but this misses instructions how to deal with root certificates in modern GnuPG versions currently. Regards, Bernhard -- www.intevation.de/~bernhard +49 541 33 508 3-3 Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998 Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner smime.p7s Description: S/MIME cryptographic signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Certified OpenPGP-encryption after release of Thunderbird 78
Am 31.05.2020 um 12:35 schrieb Patrick Brunschwig: > Andreas Boehlk Computer-Service wrote on 31.05.2020 11:09: >> Hello Patrick, >> >> >> Am 31.05.2020 um 10:01 schrieb Patrick Brunschwig: >>> Mark wrote on 31.05.2020 01:28: Doesn't TB also need your secret keys to decrypt messages? >>> >>> With smartcard support via GnuPG, all secret key operations are handled >>> by GnuPG, and all public key operations are handled by TB (Note: the >>> standard case, without smartcard support, will be that all keys are in >>> Thunderbird). >>> >>> The use-cases are clearly distinct: >>> - encryption: you only need public keys >>> - decryption: you only need secret keys >>> - signing: you only need secret keys >>> - verification: you only need public keys >>> >> The standard user will not be able to work with that "solution". >> Compared to the "enigmail-solution" this is the hell and bound to fail. > > Let's first define Standard users. The majority of users who use > smartcards that *I* know are expert or power users. They can handle this. > > The "Standard users" I have in mind don't use GnuPG for anything else > than encrypting mails, and they don't use smartcards either. They won't > have this issue in any way. > Also what if you need your public keys outside of TB such as encrypting a file? >>> >>> That's not supported by Thunderbird. The idea of OpenPGP in Thunderbird >>> is that you use it for email. >>> >> That is correct, but nevertheless it is mandatory to have and use a >> single key-store. > > For which use-case precisely? If you only use OpenPGP for emails (and > given the users I know who had support cases in the past, this is true > for the majority of the Enigmail users), then this is irrelevant. > The use cases are clear and I myself and some of my clients use them. And when I speak from my point of view it is enough work to take care of one key store and I personally do not want to have a second one; and this second one has to be synchronized on every single endpoint as well. That is twice the work. > To be quite clear: Thunderbird will not support GnuPG for scenarios > other than handling secret keys. And that's only because the OpenPGP > library they use can't handle smartcards yet. Once the library will > support smartcards, I expect that GnuPG support will be removed entirely. > From then on PGP and the second key store will be mandatory for the purpose of signing and decrypting. > Note: I'm not a Thunderbird developer and I don't drive Thunderbird > decisions -- this is simply my expectation of what will happen. > Yes, I got that of course. It is just my lack of understanding TB's decision to not trying to adapt a running system in a proper way. > -Patrick > Andreas signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
On using --debug flags (was: gpg generate key is not finishing)
On Tue, 9 Jun 2020 09:47, Bernhard Reiter said: > GNUPGHOME=~/dot-gnupg-test2/ gpg -vvv --debug-all --quick-generate-key Pretty please do not use --debug-all. It is better to use dedicated debug flags to get useful logs and avoid leaking secrets. All GnuPG components support symbolic debug constants; use for example gpg --debug help to view them. In many cases --debug ipc is helpful and won't reveal any long term secrets. The very first thing after a problem is to use --verbose which often is enough to see what's wrong. Only then try the debug constants. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
