From johanw at vulcan.xs4all.nl  Tue Feb  1 16:18:30 2022
From: johanw at vulcan.xs4all.nl (Johan Wevers)
Date: Tue, 1 Feb 2022 16:18:30 +0100
Subject: Preventing public key upload to key-servers
In-Reply-To: <2908b6ef-ef9c-ec1c-1a31-908dfa32522f@andrewg.com>
References: <3a51df73-8e2e-40d3-61ad-7842a5aa0190@yandex.com>
 <a3079cfd-0649-c772-525d-c666efbbead4@andrewg.com>
 <6e1e6933-4761-5981-b0b9-eb48a9007a78@yandex.com>
 <d70ab3c7-9ddb-15c9-bd48-5aa255c35ccf@vulcan.xs4all.nl>
 <2908b6ef-ef9c-ec1c-1a31-908dfa32522f@andrewg.com>
Message-ID: <f8112b1c-0f3f-1ed6-996c-f47360ad15e6@vulcan.xs4all.nl>

On 31-01-2022 18:11, Andrew Gallagher via Gnupg-users wrote:

> This is incorrect. All three of the commonly-used HKP servers can remove
> keys; this has been done for years to remove poison (i.e. oversized)
> keys that cause DoS. However doing so comes with costs.

Yes, that was the issue that I know about. I seem to have mistaken HKP
for SKS.

-- 
ir. J.C.A. Wevers
PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html


From klaus+gnupg at ethgen.ch  Tue Feb  1 17:57:42 2022
From: klaus+gnupg at ethgen.ch (Klaus Ethgen)
Date: Tue, 1 Feb 2022 17:57:42 +0100
Subject: Preventing public key upload to key-servers
In-Reply-To: <4d179670-3fd6-fd38-dba9-4ff2eecbe04c@yandex.com>
References: <3a51df73-8e2e-40d3-61ad-7842a5aa0190@yandex.com>
 <a3079cfd-0649-c772-525d-c666efbbead4@andrewg.com>
 <6e1e6933-4761-5981-b0b9-eb48a9007a78@yandex.com>
 <dc2624a6-273c-8ca3-1f3b-6b845b7468f7@andrewg.com>
 <4d179670-3fd6-fd38-dba9-4ff2eecbe04c@yandex.com>
Message-ID: <YflmhsCU3w3SY6Cg@ikki.ethgen.ch>

Am Mo den 31. Jan 2022 um 22:39 schrieb jonkomer via Gnupg-users:
> But the reason for my original post was not to find
> better ways of communication mechanics while the
> relationship exists, it was specific and quite narrow:
> how can both sides do all they reasonably can in order
> to avoid making it public knowledge that the
> relationship existed *after it has been dissolved*.
> 
> There is significant difference between a one-time
> "third-party" correspondent misusing his knowledge of
> the relationship after it has been dissolved, from
> that same knowledge being published in perpetuity via
> a simple, automated Internet query. Specifically,
> the question was if there is any mitigation against
> the action of an uninformed (or, perhaps by a stretch,
> malicious?) correspondent adding signatures and
> uploading the key to the network of synchronizing
> pubkey servers. Well, there is none.

Well, there is no technology that can ever prevent that human
error/fault.

What you want is simply not possible. Even if there is technology to
prevent the upload to a key server, someone could just publish your key
via twitter, or put it into bitcoin keychain or via any other way you
might imagine.

And even if he is not in possession of the original key, he can create a
own key (setting date to somewhen in the past) with you mail address and
publish it. Or what does prevent others to create a facebook account in
your name? You would have pretty much trouble to get that facebook
account removed again.

The problem, you described, is a human problem, not a technical one.
GDPR cannot prevent leaks. And when it is leaked, there is no law that
could remove the data again. You can remove it from one platform but the
ghost is out of the bottle. GDPR is, as I already told, just a nearly
lame duck that just ignores how technology and internet works. 

Regards
   Klaus
-- 
Klaus Ethgen                                       http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16            Klaus Ethgen <Klaus at Ethgen.ch>
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 688 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20220201/90651f6c/attachment-0001.sig>

From foss at morgwai.pl  Tue Feb  1 18:22:00 2022
From: foss at morgwai.pl (Piotr Morgwai Kotarbinski)
Date: Wed, 2 Feb 2022 00:22:00 +0700
Subject: photo-ID omitted when retrieving keys from WKD
In-Reply-To: <2324704.NDSbao0uJy@breq>
References: <e92f75ff-f15a-9339-2f70-5230a8cf0359@morgwai.pl>
 <2324704.NDSbao0uJy@breq>
Message-ID: <fbf677fd-65d4-74c2-810c-db9a2462bbec@morgwai.pl>

hmm: I don't seem to follow:
if a user decided to trust (to certain extent) some domain's WKS admins regarding key fingerprints (for example the user trusts that the WKS admins verify key fingerprints with members of their organization by some means of their internal procedures), it seems quite arbitrary to assume that the user should definitely NOT trust the same admins regarding photo-IDs verification (for example the admins may be comparing photo-IDs with photos from their HR DB before publishing to the WKD). It seems to me, that a decision whether to trust some WKD regarding photo-IDs should be made by individual users based on their knowledge/feeling about security practices in the given organization. Users can "store" such feelings in their keyring by either (l)signing the given photo-ID, leaving it as is, or deleting it themselves.

Furthermore, it may happen that some photo-ID stored in a WKD is signed by a 3rd party that is already trusted by the user. Stripping such photo-ID may unnecessarily conceal information that may be useful/important to the user.

Am I missing maybe some part of the story that invalidates my reasoning?

Thanks!



PS: Happy new lunar year to everyone! :) 



On 01/02/2022 00:53, Ingo Kl?cker wrote:
> On Montag, 31. Januar 2022 15:58:22 CET Piotr Morgwai Kotarbinski via Gnupg-
> users wrote:
>> I have a public key with a photo-ID uploaded to WKD at my domain and when I 
> download it manually and import to gpg, everything works as expected:
> [...]
>> However if I try to locate the same key automatically using WKD mechanism, 
> then the attached photo-ID is not imported into my keyring:
> [...]
>> Is this intended or is it a bug?
> 
> Yes, this is intended. Keys retrieved via WKD are always imported with the 
> equivalent of the import filter {keep-uid=<email address used for WKD 
> retrieval>}.
> 
> The reasoning is that only user ids matching the email address used to 
> retrieve the key via WKD can be somewhat trusted (if you trust the people 
> running the WKS). Any other user id including photo ids on the key could be 
> fake, i.e. you could easily add the photo of another person as photo id to 
> your key.
> 
> Regards,
> Ingo
> 
> 
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> https://lists.gnupg.org/mailman/listinfo/gnupg-users
> 


From kloecker at kde.org  Tue Feb  1 20:03:38 2022
From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=)
Date: Tue, 01 Feb 2022 20:03:38 +0100
Subject: photo-ID omitted when retrieving keys from WKD
In-Reply-To: <fbf677fd-65d4-74c2-810c-db9a2462bbec@morgwai.pl>
References: <e92f75ff-f15a-9339-2f70-5230a8cf0359@morgwai.pl>
 <2324704.NDSbao0uJy@breq> <fbf677fd-65d4-74c2-810c-db9a2462bbec@morgwai.pl>
Message-ID: <26096983.PxPFN1Xpyo@breq>

On Dienstag, 1. Februar 2022 18:22:00 CET Piotr Morgwai Kotarbinski via Gnupg-
users wrote:
> hmm: I don't seem to follow:
> if a user decided to trust (to certain extent) some domain's WKS admins
> regarding key fingerprints

That's not what I meant by "trust the WKS admins". What I meant is whether you 
trust the WKS admins to make sure that only those people who control a certain 
email address can upload an OpenPGP key for this email address to the WKS.

> (for example the user trusts that the WKS admins
> verify key fingerprints with members of their organization by some means of
> their internal procedures), it seems quite arbitrary to assume that the
> user should definitely NOT trust the same admins regarding photo-IDs
> verification (for example the admins may be comparing photo-IDs with photos
> from their HR DB before publishing to the WKD).

Verification of user ids and photo-IDs should be documented by signing those 
entities. If you trust the WKS admins (or some other entity), that they 
properly verify user ids and photo-IDs then you sign their key (probably with 
a non-exportable signature) and set the owner trust of their key. This has 
nothing to do with WKS and that's not the problem that WKS is trying to solve. 
It's plain old web-of-trust.

> Furthermore, it may happen that some photo-ID stored in a WKD is signed by a
> 3rd party that is already trusted by the user. Stripping such photo-ID may
> unnecessarily conceal information that may be useful/important to the user.
> 
> Am I missing maybe some part of the story that invalidates my reasoning?

Distribution of OpenPGP keys with loads of user ids including photo-IDs is not 
what WKD is about. It's about providing a well defined location for looking 
for the OpenPGP key for a single email address. GnuPG decided that it strips 
any user ids not matching the email address from the downloaded key during the 
import. Note that GnuPG internally marks keys/user ids downloaded via WKD as 
such. In the future this may allow users of GnuPG to tell gpg that it should 
automatically treat keys retrieved via WKD (probably for certain domains) as 
partially or fully valid.

If you want to get everything someone uploaded to some WKS, then simply 
download the public key block from the well defined URL and then import it 
with gpg. Using the --key-origin option you can even tell gpg, that it should 
treat this public key block as if it was downloaded via WKD. (I have not 
really verified whether gpg really treats such an import identical to a WKD 
retrieval.)

Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20220201/2b1e0055/attachment.sig>

From B1773rm4n+gnupg-users at asuka-shikinami.club  Wed Feb  2 08:30:56 2022
From: B1773rm4n+gnupg-users at asuka-shikinami.club (B1773rm4n)
Date: Wed, 2 Feb 2022 14:30:56 +0700
Subject: Current state and contact (various questions)
Message-ID: <3ca7ea7f-9099-4e6c-884e-c8b2ba3275fc@asuka-shikinami.club>

Hello,

this is my first post here. I'm an experienced Dev and FOSS contributor 
which worked quite some with gpg recently.

I got some questions:

1. Who takes care for tasks like updating the website?
For example https://gnupg.org/documentation/manpage.html would be easy 
to update. Someone could easily do it. Who is responsible? How can I do 
it myself?

2. Difference of public key between gpg and Thunderbird. What do I have 
to do to yield the same public key file?
I create a key pair in gpg and then import it to thunderbird. When using 
the "attach pub key to mail" option another pub key is used than I have 
saved in my gpg exported file

2.1 The export of gpg --armor --export $KEY yields a different public 
key than Thunderbird is creating. I'm using this script:
https://gist.github.com/B1773rm4n/97c347ab77ac2ae3b8595f0c89b99bb4#file-creategpg-sh-L86

2.2 One clue which I got via --list-packets is that gpg is using new-ctb 
- Thunderbird is using the old ctb. Maybe this yields different results? 
I haven't been able to find any documentation about that new-ctb. Where 
can I find it?

3. I'm already asking the Ubuntu community but want to ask here too: gpg 
on Ubuntu jammy is 12 months old running 2.2.27. How is the current 
process / communication handled? Is there anything I can do to 
support/speed up this process?

4. Is there any IRC channel or other way of chat communication available 
for gpg?

Greets B1773rm4n


From kloecker at kde.org  Wed Feb  2 09:59:01 2022
From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=)
Date: Wed, 02 Feb 2022 09:59:01 +0100
Subject: Current state and contact (various questions)
In-Reply-To: <3ca7ea7f-9099-4e6c-884e-c8b2ba3275fc@asuka-shikinami.club>
References: <3ca7ea7f-9099-4e6c-884e-c8b2ba3275fc@asuka-shikinami.club>
Message-ID: <2975670.R2Zv99QZtj@daneel>

On Mittwoch, 2. Februar 2022 08:30:56 CET B1773rm4n via Gnupg-users wrote:
> Hello,
> 
> this is my first post here. I'm an experienced Dev and FOSS contributor
> which worked quite some with gpg recently.
> 
> I got some questions:
> 
> 1. Who takes care for tasks like updating the website?
> For example https://gnupg.org/documentation/manpage.html would be easy
> to update. Someone could easily do it. Who is responsible? How can I do
> it myself?

The source code of the website is at
https://dev.gnupg.org/source/gnupg-doc/browse/master/web/

You can submit patches via dev.gnupg.org or per email to the gnupg-devel 
mailing list.

> 2. Difference of public key between gpg and Thunderbird. What do I have
> to do to yield the same public key file?
> I create a key pair in gpg and then import it to thunderbird. When using
> the "attach pub key to mail" option another pub key is used than I have
> saved in my gpg exported file

Don't bit-wise compare the result of key exports of different applications. 
There is more than one representation of the same public key. As long as all 
exports carry the same information, there is nothing to worry about.

Differences between armored public key blocks created via different ways was 
recently discussed on this mailing list. Check the archive.

> 3. I'm already asking the Ubuntu community but want to ask here too: gpg
> on Ubuntu jammy is 12 months old running 2.2.27. How is the current
> process / communication handled? Is there anything I can do to
> support/speed up this process?

That's entirely up to Ubuntu. Talk to the maintainer of the gpg package for 
Ubuntu.

> 4. Is there any IRC channel or other way of chat communication available
> for gpg?

See at bottom of https://gnupg.org/documentation/mailing-lists.html although 
the information about the channel at freenode.org is probably outdated. I 
haven't check, but I assume that the channel has moved off of freenode.org 
like many other FOSS channels.

Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20220202/6362e3f6/attachment.sig>

From foss at morgwai.pl  Wed Feb  2 10:24:36 2022
From: foss at morgwai.pl (Piotr Morgwai Kotarbinski)
Date: Wed, 2 Feb 2022 16:24:36 +0700
Subject: Thunderbird's hints and history for OpenPGP/MIME (new wiki page)
In-Reply-To: <874k5jenci.fsf@wheatstone.g10code.de>
References: <202112020957.12700.bernhard@intevation.de>
 <db98efd69a29d33eb97d254f11af14984b2fbcd0.camel@uos.de>
 <202112031204.31216.bernhard@intevation.de>
 <c2d04023-6ec4-f5d0-e74d-3cca0e23c00e@binarus.de>
 <9f0da7e439c7d79630c6b597187730d8554206cd.camel@16bits.net>
 <874k5jenci.fsf@wheatstone.g10code.de>
Message-ID: <9184fdea-c798-6712-2eda-7c9e45f968f6@morgwai.pl>

Regarding "History" section of the page:
I always thought, that the main reason was the fact that not all features of GnuPG were fully supported on 64bit Windows at the time when Thunderbird's old add-ons mechanism was being deprecated (GPGME specifically). See for example https://admin.hostpoint.ch/pipermail/enigmail-users_enigmail.net/2020-August/005724.html and following reply from Werner stating that "Andre will include a 64 bit version of gpgme.dll into the next gpg4win release".
This is somewhat confirmed by https://blog.thunderbird.net/2020/09/openpgp-in-thunderbird-78/ which states "This change was necessary to provide a seamless and integrated experience to users on all platforms".
It seems to me that porting GPGME to 64bit Windows was much simpler task than developing whole PGP support from scratch, but in spite of this, that's what TB team seemed to use as 1 of their reasons...

BTW: the page https://gnupg.org/download/supported_systems.html still states "64 bit versions of Windows are NOT supported", which probably should be updated to instead link to gpg4win.org.

Cheers!


From a.yousar at informatik.hu-berlin.de  Wed Feb  2 10:07:45 2022
From: a.yousar at informatik.hu-berlin.de (Annie Yousar)
Date: Wed, 2 Feb 2022 10:07:45 +0100
Subject: Current state and contact (various questions)
In-Reply-To: <3ca7ea7f-9099-4e6c-884e-c8b2ba3275fc@asuka-shikinami.club>
References: <3ca7ea7f-9099-4e6c-884e-c8b2ba3275fc@asuka-shikinami.club>
Message-ID: <7b4e071a-94cf-4ffa-c595-df0b42766c5f@informatik.hu-berlin.de>

Hi B1773rm4n,

you said that export of gpg --armor --export $KEY yields a different 
public key than Thunderbird is creating. In fact, this is not true. It 
is the same key, only their formats are different (new and old format). 
You wouldn't say as well that the ASCII armor and the binary keys are 
different.

If you use the command gpg -v --list-packets (verbose listing) for the 
"different" keys you should see, that they contain the same same key 
material ;-)

Kind regards,
/Ann.


Am 2022-02-02 um 08:30 schrieb B1773rm4n via Gnupg-users:
> Hello,
>
> this is my first post here. I'm an experienced Dev and FOSS 
> contributor which worked quite some with gpg recently.
>
> I got some questions:
>
> 1. Who takes care for tasks like updating the website?
> For example https://gnupg.org/documentation/manpage.html would be easy 
> to update. Someone could easily do it. Who is responsible? How can I 
> do it myself?
>
> 2. Difference of public key between gpg and Thunderbird. What do I 
> have to do to yield the same public key file?
> I create a key pair in gpg and then import it to thunderbird. When 
> using the "attach pub key to mail" option another pub key is used than 
> I have saved in my gpg exported file
>
> 2.1 The export of gpg --armor --export $KEY yields a different public 
> key than Thunderbird is creating. I'm using this script:
> https://gist.github.com/B1773rm4n/97c347ab77ac2ae3b8595f0c89b99bb4#file-creategpg-sh-L86 
>
>
> 2.2 One clue which I got via --list-packets is that gpg is using 
> new-ctb - Thunderbird is using the old ctb. Maybe this yields 
> different results? I haven't been able to find any documentation about 
> that new-ctb. Where can I find it?
>
> 3. I'm already asking the Ubuntu community but want to ask here too: 
> gpg on Ubuntu jammy is 12 months old running 2.2.27. How is the 
> current process / communication handled? Is there anything I can do to 
> support/speed up this process?
>
> 4. Is there any IRC channel or other way of chat communication 
> available for gpg?
>
> Greets B1773rm4n
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> https://lists.gnupg.org/mailman/listinfo/gnupg-users


From andrewg at andrewg.com  Wed Feb  2 11:52:23 2022
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Wed, 2 Feb 2022 10:52:23 +0000
Subject: "Are You Now or Have You Ever Been..."
In-Reply-To: <30327f6c-a302-cf00-72ec-dc9254a1ae8e@yandex.com>
References: <4d179670-3fd6-fd38-dba9-4ff2eecbe04c@yandex.com>
 <023D2A5F-70CE-4430-B825-F09C5CA7A29C@andrewg.com>
 <30327f6c-a302-cf00-72ec-dc9254a1ae8e@yandex.com>
Message-ID: <cec99fee-a442-bc0b-4285-db7499620ca4@andrewg.com>

On 31/01/2022 22:29, jonkomer wrote:
> Confirming it, possibly many years after it has been dissolved.
> Future is the key-word here.
> 
> In that context, then-current response of a key-server query on
> "<john.doe at example.org>" could be much more deleterious to John
> than the evidence given to the tribunal by Jane Doe that she
> exchanged e-mails with john.doe at example.org way back in 2022.

If this is your concern, then email probably isn't the appropriate tool 
for your use case. The mere existence of a particular email address is 
not a secret; by design email does not (cannot!) protect envelope 
information.

If the members of example.com need to keep their membership secret, then 
at the very minimum example.com should give them random usernames. But 
you should also consider whether a plausible-deniability system like OTR 
is a better fit for your opsec, and even then plausible deniability is 
only really useful against adversaries who believe in due process...

-- 
Andrew Gallagher

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20220202/b43dc0f5/attachment.sig>

From rjh at sixdemonbag.org  Wed Feb  2 12:21:13 2022
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Wed, 02 Feb 2022 06:21:13 -0500
Subject: Current state and contact (various questions)
In-Reply-To: <2975670.R2Zv99QZtj@daneel>
Message-ID: <9ae7a4b2-8ce6-46f4-834a-67631c91851b@email.android.com>

An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20220202/aaa4e5e1/attachment.html>

From rjh at sixdemonbag.org  Wed Feb  2 15:16:46 2022
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Wed, 2 Feb 2022 09:16:46 -0500
Subject: Current state and contact (various questions)
In-Reply-To: <3ca7ea7f-9099-4e6c-884e-c8b2ba3275fc@asuka-shikinami.club>
References: <3ca7ea7f-9099-4e6c-884e-c8b2ba3275fc@asuka-shikinami.club>
Message-ID: <3d9d3574-1184-881c-ec11-44a0361d3466@sixdemonbag.org>

> this is my first post here. I'm an experienced Dev and FOSS contributor 
> which worked quite some with gpg recently.

<Die Hard>

     Welcome to the party, pal!

</Die Hard>

:)

> 1. Who takes care for tasks like updating the website?

Ingo already addressed this fully and correctly, so I'll skip.

> 2. Difference of public key between gpg and Thunderbird. What do I have 
> to do to yield the same public key file?

In my last email I included a link to what I said the last time this 
came up on-list.  If you still have questions after reading that I'm 
happy to answer them.

> 3. I'm already asking the Ubuntu community but want to ask here too: gpg 
> on Ubuntu jammy is 12 months old running 2.2.27. How is the current 
> process / communication handled? Is there anything I can do to 
> support/speed up this process?

JFYI, the 2.2 series is a long-term support release.  That's probably 
why Ubuntu and derivatives are still using it.  (Pop!_OS, an Ubuntu 
derivative, is still shipping with 2.2.20.  Just think, it could be 
worse...)  Ubuntu is pretty good about backporting security fixes to 
older versions of GnuPG, so we don't believe there's any reason to 
despair over the version they're shipping.

The 2.3 series is actually an experimental release.  As Werner said in 
April of 2021, "We are pleased to announce the availability of a new 
GnuPG release: version 2.3.0.  This release marks the start of public 
testing releases eventually leading to a new stable version 2.4."

The entire 2.3 branch is a public beta of what will ultimately become 
version 2.4.  I'm not going to tell you that you shouldn't encourage 
Ubuntu to adopt version 2.3 -- you do you, guy -- but I strongly 
recommend that before you do, you have a good answer to this question:

"Why should Ubuntu drop a long-term support release of GnuPG in favor of 
an experimental branch?"

The better your answer to that question, the better your chances of 
convincing Ubuntu.

Good luck!



From subinsebastien at gmail.com  Wed Feb  2 19:39:10 2022
From: subinsebastien at gmail.com (Subin Sebastian)
Date: Thu, 3 Feb 2022 00:09:10 +0530
Subject: Verifying Signatures using Libgcrypt
Message-ID: <CAF+OuFKAgxyk_dvFAp+0RF7hKW_=MRLro+Pco5S+7JTrZ15XOQ@mail.gmail.com>

With the help of the gcrypt manual, I'm able to build programs that can
verify detached signatures. Specifically using the "gcry_pk_verify" API.
However, how to verify and extract the content from a compressed+wrapped
signature created by the gpg utility's "--sign" command?

Subin Sebastian
http://xtel.in
+91-944-6475-826
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20220203/c4a3dbaf/attachment.html>

From jonkomer at yandex.com  Sat Feb  5 17:52:52 2022
From: jonkomer at yandex.com (jonkomer)
Date: Sat, 5 Feb 2022 09:52:52 -0700
Subject: key creation time
Message-ID: <bf5d9561-91ee-6e1f-6aa6-fd5417a38551@yandex.com>

In gpg 2.2, option "--faked-system-time 0" can be used to avoid
inserting the "wall clock" time/date in the generated key.

gpg 1.4 does not recognize the option. Is there any other method
(short of changing the OS time) to achieve the same effect in 1.4?

<https://www.gnupg.org/documentation/manuals/gnupg/> is, I assume,
the definitive user-documentation source for the current (2.3) gpg.
I was unable to find the equivalent for either 2.2 (which is what
my distro ships with), or gpg 1.4 (that my distro also includes,
as "gpg1").

Any suggestion Where to look for those?

tia, Jon K.


From borden_c at tutanota.com  Sun Feb  6 08:07:21 2022
From: borden_c at tutanota.com (Borden)
Date: Sun, 6 Feb 2022 08:07:21 +0100 (CET)
Subject: Does gpgsm support ECDSA-with-sha256 signature?
Message-ID: <MvCqwbX--3-2@tutanota.com>

Good morning,

According to dev.gnupg.org <https://dev.gnupg.org/T4092>, EC support has been in gpgsm for a while now. However, I cannot import an EC certificate/key pair (generated by CPanel via COMODO) into gpgsm . This is a bummer because Kleopatra is basically a gpgsm frontend.

The output I get is:

gpgsm: 1240 bytes of RC2 encrypted text 
gpgsm: processing certBag 
gpgsm: unknown digest algorithm '1.2.840.10045.4.3.2' used certificate 
gpgsm: certificate has a BAD signature: General error 
gpgsm: basic certificate checks failed - not imported 
gpgsm: 192 bytes of 3DES encrypted text 
gpgsm: data error at "decrypted-text", offset 1071903942 
gpgsm: error at "bag-sequence", offset 1364 
gpgsm: error parsing or decrypting the PKCS#12 file 
gpgsm: total number processed: 1 
gpgsm: ??????????not imported: 1
 
... when I import the CA bundle into gpgsm first. However, if I import the certificate/key pair first, the import works with warnings:

gpgsm: 1240 bytes of RC2 encrypted text 
gpgsm: processing certBag 
gpgsm: dirmngr cache-only key lookup failed: Not found 
gpgsm: external URL lookup failed: Connection refused 
gpgsm: issuer certificate {FE198899934848D2C2A56715955F3501318E738B} not found using authorityKeyIdentifier 
gpgsm: dirmngr cache-only key lookup failed: Not found 
gpgsm: external URL lookup failed: Connection refused 
gpgsm: issuer certificate (#/CN=cPanel\, Inc. ECC Certification Authority,O=cPanel\, Inc.,L=Houston,ST=TX,C=US) not found 
gpgsm: dirmngr cache-only key lookup failed: Not found 
gpgsm: external URL lookup failed: Connection refused 
gpgsm: issuer certificate {FE198899934848D2C2A56715955F3501318E738B} not found using authorityKeyIdentifier 
gpgsm: dirmngr cache-only key lookup failed: Not found 
gpgsm: external URL lookup failed: Connection refused 
gpgsm: 192 bytes of 3DES encrypted text 
gpgsm: data error at "decrypted-text", offset 3705267398 
gpgsm: error at "bag-sequence", offset 1364 
gpgsm: error parsing or decrypting the PKCS#12 file 
gpgsm: total number processed: 1 
gpgsm: ??????????????imported: 1
 
However, when I subsequently import the CA bundle, gpgsm does not mark my certfiicate as certified, implying that there's some breakage in the trust chain.

If  anybody wants to play with this, I've uploaded the CA bundle to https://paste.debian.net/1229750/ and my certificate to https://paste.debian.net/1229751/ . Both links will expire on 9 February 2022.

With thanks,


From kloecker at kde.org  Sun Feb  6 16:04:25 2022
From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=)
Date: Sun, 06 Feb 2022 16:04:25 +0100
Subject: Does gpgsm support ECDSA-with-sha256 signature?
In-Reply-To: <MvCqwbX--3-2@tutanota.com>
References: <MvCqwbX--3-2@tutanota.com>
Message-ID: <2539696.VsQZ01vhax@breq>

On Sonntag, 6. Februar 2022 08:07:21 CET Borden via Gnupg-users wrote:
> According to dev.gnupg.org <https://dev.gnupg.org/T4092>, EC support has
> been in gpgsm for a while now. However, I cannot import an EC
> certificate/key pair (generated by CPanel via COMODO) into gpgsm . This is
> a bummer because Kleopatra is basically a gpgsm frontend.
[snip]
> However, when I subsequently import the CA bundle, gpgsm does not mark my
> certfiicate as certified, implying that there's some breakage in the trust
> chain.
[snip]
> If  anybody wants to play with this, I've uploaded the CA bundle to
> https://paste.debian.net/1229750/ and my certificate to
> https://paste.debian.net/1229751/ . Both links will expire on 9 February
> 2022.

gpgsm 2.3.4 imports those two files without any warnings.

After marking the "COMODO ECC Certification Authority" root certificate as 
trusted with Kleopatra, the "cse.emmarhodes.ca" is listed as certified (after 
pressing F5 to reload the certificates -> seems to be an update problem).

The necessary changes may not have been backported to GnuPG 2.2.x.

Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20220206/61153ad6/attachment-0001.sig>

From swarnak87 at gmail.com  Mon Feb  7 11:02:39 2022
From: swarnak87 at gmail.com (swarna kembayee)
Date: Mon, 7 Feb 2022 11:02:39 +0100
Subject: GPG 1.4.9 compressing option
Message-ID: <CAGhgHpqzbhyo6RHMUaCuHzEeuOYu0LaQTuU+jHycuScb4a7XXQ@mail.gmail.com>

Dear Team,

Thank you very much, in advance for your time and support.
I have 3 questions which I would appreciate help on....

My environment has GPG 1.4.9 on Solaris 10 OS.

Question 1 - I am using gpg to encrypt a gzip file. Is it wrong to do this
( file/block corruption or ) ?

for example my command order is

1. gzip sourcefile.txt -- output is sourcefile.txt.gz

2. gpg --encrypt --recipient fddf at w.com sourcefile.txt.gz -- output is
sourcefile.txt.gz.gpg -- I am able to decrypt and uncompress and read the
file

I am not sure if gpg also compresses by default. I used the --verbose
option along with --compress-algo , however the compression state is
omitted from the verbose detail.

I also find --compress-algo <1,2,3> work , higher numbers 4 and above throw
an error - 'gpg: selected compression algorithm is invalid'

Question 2 - How to know if GPG is indeed compressing and what's the
default compression value ?

[image: image.png]
Question 3 - How to find the default settings of my gpg like character set
, compression value etc.  I have not configured anything in in the gpg.conf
file

Best Regards,
Swarna Kembayee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20220207/816ec931/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 27269 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20220207/816ec931/attachment-0001.png>

From wk at gnupg.org  Mon Feb  7 22:17:27 2022
From: wk at gnupg.org (Werner Koch)
Date: Mon, 07 Feb 2022 22:17:27 +0100
Subject: [Announce] GnuPG 2.2.34 (LTS) released
Message-ID: <87fsou8jh4.fsf@wheatstone.g10code.de>

Hello!

We are pleased to announce the availability of a new GnuPG LTS release:
version 2.2.34.  This release fixes a few minor problems and brings a
few new options to ease user support and large scale installations.

The LTS (long term support) series of GnuPG is guaranteed to be
maintained at least until the end of 2024.  See
https://gnupg.org/download/index.html#end-of-life


What is GnuPG
=============

The GNU Privacy Guard (GnuPG, GPG) is a complete and free implementation
of the OpenPGP and S/MIME standards.

GnuPG allows to encrypt and sign data and communication, features a
versatile key management system as well as access modules for public key
directories.  GnuPG itself is a command line tool with features for easy
integration with other applications.  The separate library GPGME provides
a uniform API to use the GnuPG engine by software written in common
programming languages.  A wealth of frontend applications and libraries
making use of GnuPG are available.  As an universal crypto engine GnuPG
provides support for S/MIME and Secure Shell in addition to OpenPGP.

GnuPG can be freely used, modified and distributed under the terms of
the GNU General Public License.


Noteworthy changes in version 2.2.34
====================================

  * gpgconf: Backport the improved option reading and writing code
    from 2.3.  [rG7a3a1ef370,T4788]

  * gpgconf: Do not list ignored options and mark forced options as
    read-only.  [T5732]

  * gpgconf: Correctly show registry entries with --show-configs.
    [T5724]

  * gpgconf: Add command aliases -L, -K, and -R.  [rGf16c535eee]

  * gpgconf: Tweak the use of the ldapserver option.  [T5801]

  * gpgconf: Make "--launch gpg-agent" work again.  [rG5a7ed6dd8f]

  * gpg: Accept Ed25519 private keys in modernized encoding.  [T5120]

  * gpg: Fix adding the list of ultimate trusted keys.  [T5742]

  * gpgsm: New option --ignore-cert-with-oid.  [rGbcf446b70c]

  * dirmngr: Avoid initial delay on the first keyserver access in
    presence of --no-use-tor.  [rGdde88897e2]

  * scdaemon: Also prefer Yubikeys if no reader port is given.
    [rG38c666ec3f]

  * agent: Make missing strings translatable and update German and
    Japanese translations.  [T4777]

  * ssh: Fix adding an ed25519 key with a zero length comment.  [T5794]

  * gpgtar: Create and handle extended headers to support long file
    names.  [T5754]

  * Fix the creation of socket directories under Windows for non-ascii
    account names.  [rG7d1215cb9c]

  * Improve the registry HKCU->HKLM fallback.  [rG96db487a4d]

  * Prettify the --help output of most commands.

  Release-info: https://dev.gnupg.org/T5703


Getting the Software
====================

Please follow the instructions found at <https://gnupg.org/download/> or
read on:

GnuPG 2.2.34 may be downloaded from one of the GnuPG mirror sites or
direct from its primary FTP server.  The list of mirrors can be found at
<https://gnupg.org/download/mirrors.html>.  Note that GnuPG is not
available at ftp.gnu.org.

The GnuPG source code compressed using BZIP2 and its OpenPGP signature
are available here:

 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.34.tar.bz2 (7082k)
 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.34.tar.bz2.sig

An installer for Windows without any graphical frontend except for a
very minimal Pinentry tool is available here:

 https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.34_20220207.exe (4425k)
 https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.34_20220207.exe.sig

The source used to build the Windows installer can be found in the same
directory with a ".tar.xz" suffix.

Please note that a new version of Gpg4win 3 will not be published.
Gpg4win users should instead update to Gpg4win 4.0 which comes with the
current stable branch of GnuPG.


Checking the Integrity
======================

In order to check that the version of GnuPG which you are going to
install is an original and unmodified one, you can do it in one of
the following ways:

 * If you already have a version of GnuPG installed, you can simply
   verify the supplied signature.  For example to verify the signature
   of the file gnupg-2.2.34.tar.bz2 you would use this command:

     gpg --verify gnupg-2.2.34.tar.bz2.sig gnupg-2.2.34.tar.bz2

   This checks whether the signature file matches the source file.
   You should see a message indicating that the signature is good and
   made by one or more of the release signing keys.  Make sure that
   this is a valid key, either by matching the shown fingerprint
   against a trustworthy list of valid release signing keys or by
   checking that the key has been signed by trustworthy other keys.
   See the end of this mail for information on the signing keys.

 * If you are not able to use an existing version of GnuPG, you have
   to verify the SHA-1 checksum.  On Unix systems the command to do
   this is either "sha1sum" or "shasum".  Assuming you downloaded the
   file gnupg-2.2.34.tar.bz2, you run the command like this:

     sha1sum gnupg-2.2.34.tar.bz2

   and check that the output matches the next line:

b931cc1aa287ad67b0efacb91e7b358bf4852278  gnupg-2.2.34.tar.bz2
1ba27aaa476c75b4be0a7d8958de722ccebc52da  gnupg-w32-2.2.34_20220207.tar.xz
a43d38390323022ea4af17336978855c9d553cee  gnupg-w32-2.2.34_20220207.exe


Internationalization
====================

This version of GnuPG has support for 26 languages with Chinese
(traditional and simplified), Czech, French, German, Italian,
Japanese, Norwegian, Polish, Russian, and Ukrainian being almost
completely translated.


Documentation and Support
=========================

The file gnupg.info has the complete reference manual of the system.
Separate man pages are included as well but they miss some of the
details available only in thee manual.  The manual is also available
online at

  https://gnupg.org/documentation/manuals/gnupg/

or can be downloaded as PDF at

  https://gnupg.org/documentation/manuals/gnupg.pdf .

You may also want to search the GnuPG mailing list archives or ask on
the gnupg-users mailing list for advise on how to solve problems.  Most
of the new features are around for several years and thus enough public
experience is available.  https://wiki.gnupg.org has user contributed
information around GnuPG and relate software.

In case of build problems specific to this release please first check
https://dev.gnupg.org/T5703 for updated information.

Please consult the archive of the gnupg-users mailing list before
reporting a bug: https://gnupg.org/documentation/mailing-lists.html.
We suggest to send bug reports for a new release to this list in favor
of filing a bug at https://bugs.gnupg.org.  If you need commercial
support go to https://gnupg.com or https://gnupg.org/service.html.

If you are a developer and you need a certain feature for your project,
please do not hesitate to bring it to the gnupg-devel mailing list for
discussion.


Thanks
======

Since 2001 maintenance and development of GnuPG is done by g10 Code GmbH
and has mostly been financed by donations.  Three full-time employed
developers as well as two contractors exclusively work on GnuPG and
closely related software like Libgcrypt, GPGME and Gpg4win.

Fortunately, and this is still not common with free software, we have
now established a way of financing the development while keeping all our
software free and freely available for everyone.  Our model is similar
to the way RedHat manages RHEL and Fedora: Except for the actual binary
of the MSI installer for Windows and client specific configuration
files, all the software is available under the GNU GPL and other Open
Source licenses.  Thus customers may even build and distribute their own
version of the software as long as they do not use our trademark
GnuPG VS-Desktop?.

We like to thank all the nice people who are helping the GnuPG project,
be it testing, coding, translating, suggesting, auditing, administering
the servers, spreading the word, answering questions on the mailing
lists, or helping with donations.


*Thank you all*

   Your GnuPG hackers



p.s.
This is an announcement only mailing list.  Please send replies only to
the gnupg-users'at'gnupg.org mailing list.

List of Release Signing Keys:
To guarantee that a downloaded GnuPG version has not been tampered by
malicious entities we provide signature files for all tarballs and
binary versions.  The keys are also signed by the long term keys of
their respective owners.  Current releases are signed by one or more
of these keys:

  rsa3072 2017-03-17 [expires: 2027-03-15]
  5B80 C575 4298 F0CB 55D8  ED6A BCEF 7E29 4B09 2E28
  Andre Heinecke (Release Signing Key)

  ed25519 2020-08-24 [expires: 2030-06-30]
  6DAA 6E64 A76D 2840 571B  4902 5288 97B8 2640 3ADA
  Werner Koch (dist signing 2020)

  ed25519 2021-05-19 [expires: 2027-04-04]
  AC8E 115B F73E 2D8D 47FA  9908 E98E 9B2D 19C6 C8BD
  Niibe Yutaka (GnuPG Release Key)

  brainpoolP256r1 2021-10-15 [expires: 2029-12-31]
  02F3 8DFF 731F F97C B039  A1DA 549E 695E 905B A208
  GnuPG.com (Release Signing Key 2021)

The keys are available at https://gnupg.org/signature_key.html and
in any recently released GnuPG tarball in the file g10/distsigkey.gpg .
Note that this mail has been signed by a different key.

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20220207/3bb74246/attachment.sig>
-------------- next part --------------
_______________________________________________
Gnupg-announce mailing list
Gnupg-announce at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-announce

From angel at pgp.16bits.net  Tue Feb  8 00:30:21 2022
From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=)
Date: Tue, 08 Feb 2022 00:30:21 +0100
Subject: GPG 1.4.9 compressing option
In-Reply-To: <CAGhgHpqzbhyo6RHMUaCuHzEeuOYu0LaQTuU+jHycuScb4a7XXQ@mail.gmail.com>
References: <CAGhgHpqzbhyo6RHMUaCuHzEeuOYu0LaQTuU+jHycuScb4a7XXQ@mail.gmail.com>
Message-ID: <5b2ade592bf55402b42b87c83b84d7d01df59abd.camel@16bits.net>

On 2022-02-07 at 11:02 +0100, swarna kembayee wrote:
> Dear Team,
> 
> Thank you very much, in advance for your time and support. 
> I have 3 questions which I would appreciate help on....
> 
> My environment has GPG 1.4.9 on Solaris 10 OS.

That version is 13 years old, not even the latest version of the 1.4.x
branch, which is itself not considered secure nowadays. Please, please,
update to a modern GPG version (2.2.x or 2.3.x)

(I will assume in the following points that you are already using a
modern version)


Also note that compressing leaks _some_ information on the entropy of
the underlying file. Hopefully not something significantly, but it's
something to take into account.


> Question 1 - I am using gpg to encrypt a gzip file. Is it wrong to do
> this ( file/block corruption or ) ?

No, it's not wrong. You are free to encrypt any kind of file, even if
it's compressed. As long as the cipher is secure, that shouldn't
matter.


> for example my command order is
> 
> 1. gzip sourcefile.txt -- output is sourcefile.txt.gz
> 
> 2. gpg --encrypt --recipient fddf at w.com sourcefile.txt.gz -- output
> is sourcefile.txt.gz.gpg -- I am able to decrypt and uncompress and
> read the file
> 
> I am not sure if gpg also compresses by default. I used the --verbose 
> option along with --compress-algo , however the compression state is
> omitted from the verbose detail.

First of all, it would depend on the preferences of the recipient key.
If you are to someone whose key doesn't support compression, it won't
be compressed (unless you forced that).


> I also find --compress-algo <1,2,3> work , higher numbers 4 and above
> throw an error - 'gpg: selected compression algorithm is invalid'

These are compression *algorithms*:

9.3.  Compression Algorithms
       ID           Algorithm
       --           ---------
       0          - Uncompressed
       1          - ZIP [RFC1951]
       2          - ZLIB [RFC1950]
       3          - BZip2 [BZ2]
       100 to 110 - Private/Experimental algorithm

see https://datatracker.ietf.org/doc/html/rfc4880#section-9

so an algorithm of 4 is not specified and gpg rightly complains.

You probably wanted --compress-level / --bzip2-compress-level to change
the level of compression.


> Question 2 - How to know if GPG is indeed compressing and what's the
> default compression value ? 

A simple test would be:

$ truncate -s 50M testfile
$ gpg -r <yourkey> --encrypt-file testfile

I find a testfile of 50M but a testfile.gpg of 50K. So it is clearly
compressing :-)

If you use --verbose twice on decryption, e.g.
gpg --verbose --verbose -d <  testfile.gpg  > /dev/null

on a gpg file using compression there will be a line such as:
:compressed packet: algo=2


> Question 3 - How to find the default settings of my gpg like
> character set , compression value etc.  I have not configured
> anything in in the gpg.conf file

The docs for your version should state the default values. Take into
account that, as stated earlier, the ones selected will depend on who
you are corresponding with.


> Best Regards,
> Swarna Kembayee

Best regards




From angel at pgp.16bits.net  Tue Feb  8 00:40:51 2022
From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=)
Date: Tue, 08 Feb 2022 00:40:51 +0100
Subject: key creation time
In-Reply-To: <bf5d9561-91ee-6e1f-6aa6-fd5417a38551@yandex.com>
References: <bf5d9561-91ee-6e1f-6aa6-fd5417a38551@yandex.com>
Message-ID: <7d225c28f86d53f83655619871630750a41d1f87.camel@16bits.net>

On 2022-02-05 at 09:52 -0700, jonkomer wrote:
> In gpg 2.2, option "--faked-system-time 0" can be used to avoid
> inserting the "wall clock" time/date in the generated key.
> 
> gpg 1.4 does not recognize the option. Is there any other method
> (short of changing the OS time) to achieve the same effect in 1.4?
> 
> <https://www.gnupg.org/documentation/manuals/gnupg/> is, I assume,
> the definitive user-documentation source for the current (2.3) gpg.
> I was unable to find the equivalent for either 2.2 (which is what
> my distro ships with), or gpg 1.4 (that my distro also includes,
> as "gpg1").
> 
> Any suggestion Where to look for those?
> 
> tia, Jon K.

You could simply use faketime(1) to make gpg believe it is living at a
fixed time.

But you should avoid using gpg1?

Regards




From jonkomer at yandex.com  Tue Feb  8 20:00:58 2022
From: jonkomer at yandex.com (jonkomer)
Date: Tue, 8 Feb 2022 12:00:58 -0700
Subject: key creation time
In-Reply-To: <7d225c28f86d53f83655619871630750a41d1f87.camel@16bits.net>
References: <bf5d9561-91ee-6e1f-6aa6-fd5417a38551@yandex.com>
 <7d225c28f86d53f83655619871630750a41d1f87.camel@16bits.net>
Message-ID: <26f6c7f9-48f8-e3f3-cef3-86b43cbfd99f@yandex.com>

> use faketime(1)...
Thank you, that does what I was after.

Jon K.


From raja at rsdisk.com  Thu Feb 10 14:23:31 2022
From: raja at rsdisk.com (Raja Saha)
Date: Thu, 10 Feb 2022 18:53:31 +0530
Subject: lost id on keyserver
In-Reply-To: <26f6c7f9-48f8-e3f3-cef3-86b43cbfd99f@yandex.com>
References: <bf5d9561-91ee-6e1f-6aa6-fd5417a38551@yandex.com>
 <7d225c28f86d53f83655619871630750a41d1f87.camel@16bits.net>
 <26f6c7f9-48f8-e3f3-cef3-86b43cbfd99f@yandex.com>
Message-ID: <b657d82d3e18743f652d80ca97f6210862d0826f.camel@rsdisk.com>

Hi,

I was following Debian Subkey guide to create and maintain keys/subkeys
https://wiki.debian.org/Subkeys

I had a functional key on the gpg (default) key server for this email
(raja at rsdisk.com). 

I renamed ~/.gnupg to ~/.gnupg_hot and created a blank ~/.gnupg. At
this point I didn't use the export command to set the dir, but instead
toggled the names of the ~/.gnupg dir to shift between the two dirs in
gpg.

I created the subkey, output it to a file and imported it to gpg on
working dir. Then I sent the key to the keyserver, gpg --send-keys
*****. After that when I searched the keyserver by my email it, there
was no key. When I searched by my key
F01D54EDAEB1700EBEDE6FC6C0A9DE3BFEFD07E2 (now revoked) it was there.
When I imported it, it didn't have a mail id.

I'm not sure where I made the mistake. I have now made a new
key/subkey, published it.

I would like to know where I went wrong so I know, for in future.

Thanks!
	



From andrewg at andrewg.com  Thu Feb 10 15:50:36 2022
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Thu, 10 Feb 2022 14:50:36 +0000
Subject: lost id on keyserver
In-Reply-To: <b657d82d3e18743f652d80ca97f6210862d0826f.camel@rsdisk.com>
References: <bf5d9561-91ee-6e1f-6aa6-fd5417a38551@yandex.com>
 <7d225c28f86d53f83655619871630750a41d1f87.camel@16bits.net>
 <26f6c7f9-48f8-e3f3-cef3-86b43cbfd99f@yandex.com>
 <b657d82d3e18743f652d80ca97f6210862d0826f.camel@rsdisk.com>
Message-ID: <bf0e0694-cd28-f5ef-e427-874d15a7c016@andrewg.com>

On 10/02/2022 13:23, Raja Saha wrote:
> 
> I created the subkey, output it to a file and imported it to gpg on
> working dir. Then I sent the key to the keyserver, gpg --send-keys
> *****. After that when I searched the keyserver by my email it, there
> was no key. When I searched by my key
> F01D54EDAEB1700EBEDE6FC6C0A9DE3BFEFD07E2 (now revoked) it was there.
> When I imported it, it didn't have a mail id.

What OS are you using? The default keyserver depends on your linux 
distro, and the default in Debian-based distros (keys.openpgp.org) 
doesn't serve userIDs by default. If you published your key there and 
then imported it into a different keyring, it wouldn't have come with 
the userID unless you went through their email verification procedure first.

-- 
Andrew Gallagher

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20220210/dc9294a6/attachment-0001.sig>

From raja at rsdisk.com  Fri Feb 11 13:01:00 2022
From: raja at rsdisk.com (Raja Saha)
Date: Fri, 11 Feb 2022 17:31:00 +0530
Subject: lost id on keyserver
In-Reply-To: <bf0e0694-cd28-f5ef-e427-874d15a7c016@andrewg.com>
References: <bf5d9561-91ee-6e1f-6aa6-fd5417a38551@yandex.com>
 <7d225c28f86d53f83655619871630750a41d1f87.camel@16bits.net>
 <26f6c7f9-48f8-e3f3-cef3-86b43cbfd99f@yandex.com>
 <b657d82d3e18743f652d80ca97f6210862d0826f.camel@rsdisk.com>
 <bf0e0694-cd28-f5ef-e427-874d15a7c016@andrewg.com>
Message-ID: <ffbc0f72372a4e0732d2cfc7c2010c33b6b64689.camel@rsdisk.com>

Hi,

I am using Debian 10. My key was verified... I think you are right. At
that time (~3yrs back) I more worried about spam from publishing it on
the keyserver.

I'm pretty sure that is what it is. I didn't verify my email. Since I
was using the same machine to know more about gpg, it wasn't a problem,
it was reading my keyring.

Thank you! I would have never figured it out.

Cheers!



On Thu, 2022-02-10 at 14:50 +0000, Andrew Gallagher via Gnupg-users
wrote:
> On 10/02/2022 13:23, Raja Saha wrote:
> > I created the subkey, output it to a file and imported it to gpg on
> > working dir. Then I sent the key to the keyserver, gpg --send-keys
> > *****. After that when I searched the keyserver by my email it,
> > there
> > was no key. When I searched by my key
> > F01D54EDAEB1700EBEDE6FC6C0A9DE3BFEFD07E2 (now revoked) it was
> > there.
> > When I imported it, it didn't have a mail id.
> 
> What OS are you using? The default keyserver depends on your linux 
> distro, and the default in Debian-based distros (keys.openpgp.org) 
> doesn't serve userIDs by default. If you published your key there
> and 
> then imported it into a different keyring, it wouldn't have come
> with 
> the userID unless you went through their email verification procedure
> first.
> 
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> https://lists.gnupg.org/mailman/listinfo/gnupg-users



From 2458099 at gmail.com  Thu Feb 10 23:30:10 2022
From: 2458099 at gmail.com (Gilberto F da Silva)
Date: Thu, 10 Feb 2022 19:30:10 -0300
Subject: Emacs no longer opens encrypted files.
Message-ID: <YgWR8tLBx2sdVkDZ@darkstar.example.net>

             Using Mageia 8 or Slackware64 15 with Emacs 27.2 I cannot
             open encrypted files. Emacs has built-in functions to
             handle GnuPG but it's only working for encryption.
             
-- 

Stela dato:2.459.621,401  Loka tempo:2022-02-10 18:37:10 ?a?do    
-==-
A Babel come?ou com todo mundo falando l?nguas diferentes. Quando 
Deus quis que os homens se desentendessem fez todos falarem a mesma 
l?ngua.
                -- Mill?r Fernandes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 358 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20220210/69e96bc7/attachment.sig>

From hello at danielcolquitt.com  Mon Feb 14 10:36:25 2022
From: hello at danielcolquitt.com (Daniel Colquitt)
Date: Mon, 14 Feb 2022 10:36:25 +0100 (CET)
Subject: Changing the encryption algorithm used for PGP/GPG private key
Message-ID: <1916288833.157.1644831385028@upanova.co-bxl>

I've read various tutorials and posts regarding changing the algorithm used to encrypt my private PGP keys. However, nothing I have tried seems to work. I am using gpg4win:

> gpg (GnuPG) 2.3.4
> libgcrypt 1.9.4
> Copyright (C) 2021 g10 Code GmbH
> 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.

> Home: C:\Users\[REDACTED]\AppData\Roaming\gnupg
> Supported algorithms:
> Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
> Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
>         CAMELLIA128, CAMELLIA192, CAMELLIA256
> AEAD: EAX, OCB
> Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
> Compression: Uncompressed, ZIP, ZLIB, BZIP2

My gpg.conf file located at C:\Users\[REDACTED]\AppData\Roaming\gnupg\gpg.conf is

> personal-digest-preferences SHA512
> cert-digest-algo SHA512
> default-preference-list SHA512 SHA384 SHA256 SHA224 SHA1 AES256 AES192 AES ZLIB BZIP2 ZIP Uncompressed OCB EAX ks-modify
> personal-cipher-preferences AES256 AES192 AES
> s2k-mode 3
> s2k-cipher-algo AES256
> s2k-digest-algo SHA512
> s2k-count 65011712
> cipher-algo AES256

I then change the password via

> gpg -vv --expert --edit-key A7AA75FD6A11F453DE501E38D3E3B91787699C75
> passwd

Export the key

> gpg -vv --cipher-algo AES256 --export-secret-keys A7AA75FD6A11F453DE501E38D3E3B91787699C75 -a > key.txt

and then inspect it

> gpg --list-packets key.txt

which then outputs

> :secret key packet:
>     ...
>     iter+salt S2K, algo: 7, SHA1 protection, hash: 2,
>     ...

This would seem to suggest that the key is still encrypted using AES128 (algo 7) and a SHA1 hash. Further, inspecting the contents of $GNUPGHOME/private-keys-v1.d/ shows files with the following lines

> ...
> (protected openpgp-s2k3-ocb-aes ((sha1 ...
> ...

What am I missing? Any help or advice would be very much appreciated.

Yours,
Dan


From davidkacerek at gmail.com  Mon Feb 14 21:24:29 2022
From: davidkacerek at gmail.com (=?utf-8?q?David=20Ka=c4=8derek?=)
Date: Mon, 14 Feb 2022 20:24:29 +0000
Subject: Gpg4win LetsEncrypt issue
In-Reply-To: <87sftur1db.fsf@wheatstone.g10code.de>
References: <CACqKRLe7GPQ1Sd_nQc-TfScYxfmcgnXdn-jhM35Vo20-p_-82w@mail.gmail.com>
 <B4474686-EC30-4349-98C5-5B43D86C6242@andrewg.com>
 <CACqKRLd6xv_N6b1THNjYuE0hXhKB6PLT7Zz1gLkxmiCJ8O9vFA@mail.gmail.com>
 <a96da1860b5918873bd432be728aa8e13f75edb4.camel@andrewg.com>
 <CACqKRLeoxPShgc6yDzCZB4tomtZKaPHo4DSu_ChOnojO8awf0g@mail.gmail.com>
 <871r1lxo3x.fsf@wheatstone.g10code.de>
 <CAM+zwjTCr8NkbC63kW=xZrc8be8FmV97Y5kFpOFt25RJjB_Cvw@mail.gmail.com>
 <87wnjdued5.fsf@wheatstone.g10code.de>
 <CAM+zwjT83S7+Hage_XoF_u0mnhd-De5X_dgSwm93kJ5JdQHcrg@mail.gmail.com>
 <87sftur1db.fsf@wheatstone.g10code.de>
Message-ID: <em4b0b096c-3829-49b7-8e5f-aa08c427f4e0@nuc-atronach>

------ Original Message ------
From: "Werner Koch via Gnupg-users" <gnupg-users at gnupg.org>
To:
Sent: 11.01.2022 11:52:00
Subject: Gpg4win LetsEncrypt issue

>For details please see https://dev.gnupg.org/T5639 which was fixed with
>GnuPG 2.2.32 and 2.3.4.
Hello,
I'd say the problem is not fixed in neither GnuPG 2.2.32 nor 2.3.4. At 
least not on Windows 10. Along with Alex Nadtoka & Anze Jesterle, I'm 
another person suffering from the same issue.
If I try to search for some keys on some keyserver not using the Let's 
Encrypt certificate, like hkp(s)://keyserver-01.2ndquadrant.com, there's 
no problem.

If I try to search on hkp://keyserver.ubuntu.com, there's no problem as 
well.

But If I try to search on hkps://keyserver.ubuntu.com or 
hkp(s)://keys.openpgp.org, I'm getting:
C:\Users\David>gpg --keyserver hkps://keyserver.ubuntu.com --search-keys 
opensuse
gpg: error searching keyserver: Certificate expired
gpg: keyserver search failed: Certificate expired
Both keyserver.ubuntu.com and keys.openpgp.org key servers use the LE 
certificate. On a side note, I wonder why hkp://keys.openpgp.org doesn't 
work either since hkp:// protokol works on top of HTTP and not HTTPS, 
but that's another issue.

If I remove the invalid intermediate certificate R3, issued by DST Root 
CA X3, expired on 09/29/2021 from certmgr.msc and then reload dirmngr, 
"certificate expired" error no longer shows in any case.

I've checked I have the new valid intermediate certificate R3, issued by 
ISRG Root X1, expiring on 09/15/2025 present in certmgt.msc and yet in 
such a case dirmngr shows in its log that it still tries the old 
verification path when the invalid R3 cert is installed. I would attach 
the whole log but it's partly in Czech and I don't know how to switch 
the output fully to English since it doesn't work despite setting the 
LC_MESSAGES=C variable.

So to me, it seems that both GnuPG 2.2.32 and 2.3.4 (installed via 
GnuPG4Win 4.0) on Win10 still suffer from the issue. So can we re-open 
the bug report https://dev.gnupg.org/T5639 or 
https://dev.gnupg.org/T5744 or should I create another one?

Thanks,
David K.



From bangchuishan at outlook.com  Tue Feb 15 12:32:24 2022
From: bangchuishan at outlook.com (Gao Xiaohui)
Date: Tue, 15 Feb 2022 11:32:24 +0000
Subject: How to solve this garbled code?
Message-ID: <TYCP286MB1314A0EB3A6489D1943C4128D5349@TYCP286MB1314.JPNP286.PROD.OUTLOOK.COM>

Hello, why do such garbled characters appear on the display page of gnupg(inside the red box),The Chinese characters will be displayed abnormally too, similar to this garbled character. what should I do and how to avoid it?
Thank you very much.
[cid:7df9d72b-2565-456a-873e-c5eefd26b716]

OS Name:Microsoft Windows 7 Home Basic 64-bits
gpg (GnuPG) 2.3.4
libgcrypt 1.9.4


Gao X.H.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20220215/9a047a03/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2022-02-15_190245.png
Type: image/png
Size: 3216 bytes
Desc: 2022-02-15_190245.png
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20220215/9a047a03/attachment-0001.png>

From danm at prime.gushi.org  Tue Feb 15 21:32:50 2022
From: danm at prime.gushi.org (Dan Mahoney (Gushi))
Date: Tue, 15 Feb 2022 12:32:50 -0800 (PST)
Subject: Questions re auto-key-locate
Message-ID: <bb23967a-8db7-b739-8a6a-456469ec4236@prime.gushi.org>

Hey all,

A long time ago I wrote a doc on a blog about putting PGP keys in the DNS, 
which has been linked to quite a bit.  I also recoded make-dns-cert as a 
shell script so that people who want to do this but don't have access to 
the make-dns-cert tool (which is not built by default on some OS packages) 
had an option to do this.

At the day job, we have a script that we use to push gpg-signed releases 
to our FTP server, and as part of that job, it verifies the signatures on 
the tarball, and will try to auto-key-locate those keys if it can't find 
them.

Since the debacle a few years ago with the SKS keyserver denial-of-service 
attack, the keyservers are kind of a non-starter.  And because GPG 
searches for keys on a tarball by keyid, not by user at domain, a keyserver 
is the only real retrieval method available to look up a key by keyid, 
which is now a non-starter.

Worse still, if you know a key exists via something like DANE (dayjob 
makes DNS software, we like the idea of it being available via DANE), 
there's no way to do gpg --search via DANE, only via a keyserver.

Thus, using that as a prefetch method to grab the current version of our 
codesign@ key into our keyring is not helpful either, unless we "faked it" 
by attempting to encrypt a message to that address, then discarded it.

Is there another way forward?  The normal things for auto-key-locate don't 
seem to help here.  I'm open to ideas.

-Dan

(PS: on gnupg.org, the documentation for auto-key-locate dane says "Locate 
a key using DANE, as specified in draft-ietf-dane-openpgpkey-05.txt."  It 
should probably say RFC7929 rather than referring to an I-D.)

-- 

--------Dan Mahoney--------
Techie,  Sysadmin,  WebGeek
Gushi on efnet/undernet IRC
FB:  fb.com/DanielMahoneyIV
LI:   linkedin.com/in/gushi
Site:  http://www.gushi.org
---------------------------



From kloecker at kde.org  Tue Feb 15 22:43:43 2022
From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=)
Date: Tue, 15 Feb 2022 22:43:43 +0100
Subject: Questions re auto-key-locate
In-Reply-To: <bb23967a-8db7-b739-8a6a-456469ec4236@prime.gushi.org>
References: <bb23967a-8db7-b739-8a6a-456469ec4236@prime.gushi.org>
Message-ID: <2344031.o4oXhT01cA@daneel>

On Dienstag, 15. Februar 2022 21:32:50 CET Dan Mahoney (Gushi) via Gnupg-users 
wrote:
> Worse still, if you know a key exists via something like DANE (dayjob
> makes DNS software, we like the idea of it being available via DANE),
> there's no way to do gpg --search via DANE, only via a keyserver.
> 
> Thus, using that as a prefetch method to grab the current version of our
> codesign@ key into our keyring is not helpful either, unless we "faked it"
> by attempting to encrypt a message to that address, then discarded it.
> 
> Is there another way forward?  The normal things for auto-key-locate don't
> seem to help here.  I'm open to ideas.

I'm not sure I understand your question, but you can use --locate-keys instead 
of a "faked" --encrypt to look up keys by email address.

Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20220215/b2c3a2d7/attachment.sig>

From andrewg at andrewg.com  Tue Feb 15 23:45:42 2022
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Tue, 15 Feb 2022 22:45:42 +0000
Subject: Questions re auto-key-locate
Message-ID: <7ACC6273-8479-4CBF-B844-2F99BA29A1EB@andrewg.com>

?
> On 15 Feb 2022, at 21:46, Dan Mahoney (Gushi) via Gnupg-users <gnupg-users at gnupg.org> wrote:
> 
> Since the debacle a few years ago with the SKS keyserver denial-of-service attack, the keyservers are kind of a non-starter.

Why so? Keyservers are still around, and the ones that survived the apocalypse are generally the ones that are better maintained. The only glitch from a user POV is that you have to publish to both a synchronising server and keys.openpgp.org to make sure everyone sees your updates?

A

From konstantin at linuxfoundation.org  Tue Feb 15 23:01:29 2022
From: konstantin at linuxfoundation.org (Konstantin Ryabitsev)
Date: Tue, 15 Feb 2022 17:01:29 -0500
Subject: Questions re auto-key-locate
In-Reply-To: <bb23967a-8db7-b739-8a6a-456469ec4236@prime.gushi.org>
References: <bb23967a-8db7-b739-8a6a-456469ec4236@prime.gushi.org>
Message-ID: <20220215220129.74i5irftmfrhzqag@nitro.local>

On Tue, Feb 15, 2022 at 12:32:50PM -0800, Dan Mahoney (Gushi) via Gnupg-users wrote:
> Thus, using that as a prefetch method to grab the current version of our
> codesign@ key into our keyring is not helpful either, unless we "faked it"
> by attempting to encrypt a message to that address, then discarded it.
> 
> Is there another way forward?  The normal things for auto-key-locate don't
> seem to help here.  I'm open to ideas.

Hi, Dan:

Any reason you want to stick with auto-locating keys instead of just
maintaining a keyring for verification purposes?

If you do want to keep using DANE, you can "gpg --auto-key-locate dane
--locate-keys codesign at whatnot" to build your pubring, e.g. (using wkd):

$ export GNUPGHOME=$(mktemp -d)
$ gpg --auto-key-locate wkd --locate-keys torvalds at kernel.org gregkh at kernel.org

We now have a $GNUPGHOME/pubring.kbx containing the keys we can use for
verification. At some point in the past I wrote the following script that
makes use of this exact approach:

https://git.kernel.org/pub/scm/linux/kernel/git/mricon/korg-helpers.git/tree/get-verified-tarball

-K


From andrewg at andrewg.com  Tue Feb 15 23:59:56 2022
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Tue, 15 Feb 2022 22:59:56 +0000
Subject: How to solve this garbled code?
In-Reply-To: <TYCP286MB1314A0EB3A6489D1943C4128D5349@TYCP286MB1314.JPNP286.PROD.OUTLOOK.COM>
References: <TYCP286MB1314A0EB3A6489D1943C4128D5349@TYCP286MB1314.JPNP286.PROD.OUTLOOK.COM>
Message-ID: <921e1134-7fa8-2748-32c8-8565c32a0337@andrewg.com>

On 15/02/2022 11:32, Gao Xiaohui via Gnupg-users wrote:
> Hello, why do such garbled characters appear on the display page of 
> gnupg(inside the red box),The Chinese characters will be displayed 
> abnormally too, similar to this garbled character. what should I do and 
> how to avoid it?
> Thank you very much.

I suspect this is because you're using a non-Unicode codepage in the 
windows command terminal. What happens if you type:

chcp 65001

and try again?

-- 
Andrew Gallagher

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20220215/0863e9a5/attachment.sig>

From dgouttegattat at incenp.org  Tue Feb 15 22:57:11 2022
From: dgouttegattat at incenp.org (Damien Goutte-Gattat)
Date: Tue, 15 Feb 2022 21:57:11 +0000
Subject: Questions re auto-key-locate
In-Reply-To: <bb23967a-8db7-b739-8a6a-456469ec4236@prime.gushi.org>
References: <bb23967a-8db7-b739-8a6a-456469ec4236@prime.gushi.org>
Message-ID: <6746290.9J7NaK4W3v@borealin.local.incenp.org>

On Tuesday, 15 February 2022 20:32:50 GMT Dan Mahoney (Gushi) via Gnupg-users 
wrote:
> Worse still, if you know a key exists via something like DANE (dayjob
> makes DNS software, we like the idea of it being available via DANE),
> there's no way to do gpg --search via DANE, only via a keyserver.
> 
> Thus, using that as a prefetch method to grab the current version of our
> codesign@ key into our keyring is not helpful either, unless we "faked it"
> by attempting to encrypt a message to that address, then discarded it.
> 
> Is there another way forward?  The normal things for auto-key-locate don't
> seem to help here.  I'm open to ideas.

Unless I misunderstood what you?re trying to achieve, I think the `--locate-
external-keys` command should be what you?re looking for?

This is basically the equivalent of `--search-keys`, except that the search is 
not limited to keyservers but instead use the mechanisms configured via the 
`--auto-key-locate` option (which can include DNS lookups, either using the 
?historical? method of RFC-4398, or the modern method of RFC-7929).

- Damien
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20220215/82ac7676/attachment.sig>

From danm at prime.gushi.org  Wed Feb 16 00:37:58 2022
From: danm at prime.gushi.org (Dan Mahoney)
Date: Tue, 15 Feb 2022 15:37:58 -0800
Subject: Questions re auto-key-locate
In-Reply-To: <7ACC6273-8479-4CBF-B844-2F99BA29A1EB@andrewg.com>
References: <7ACC6273-8479-4CBF-B844-2F99BA29A1EB@andrewg.com>
Message-ID: <FD525CD6-5746-4EC9-A009-07765A4E3E54@prime.gushi.org>



> On Feb 15, 2022, at 2:45 PM, Andrew Gallagher <andrewg at andrewg.com> wrote:
> 
> 
>> On 15 Feb 2022, at 21:46, Dan Mahoney (Gushi) via Gnupg-users <gnupg-users at gnupg.org> wrote:
>> 
>> Since the debacle a few years ago with the SKS keyserver denial-of-service attack, the keyservers are kind of a non-starter.
> 
> Why so? Keyservers are still around, and the ones that survived the apocalypse are generally the ones that are better maintained. The only glitch from a user POV is that you have to publish to both a synchronising server and keys.openpgp.org to make sure everyone sees your updates?

That's a decision I leave up to the people who *make* the key (and the software that it's signing).  If they've decided not to push the key out there (and it's no longer the case that you can publish just anyone's key) I need to respect that.

Right now, the decision is that our key (signed with our prior-year key) is on our website and FTP (also via https) site, and we do not assert that it's available on the keyservers.

-Dan

From gnupg at raf.org  Wed Feb 16 08:03:20 2022
From: gnupg at raf.org (raf)
Date: Wed, 16 Feb 2022 18:03:20 +1100
Subject: Questions re auto-key-locate
In-Reply-To: <bb23967a-8db7-b739-8a6a-456469ec4236@prime.gushi.org>
References: <bb23967a-8db7-b739-8a6a-456469ec4236@prime.gushi.org>
Message-ID: <YgyhuP8Yfgs9tYIe@raf.org>

On Tue, Feb 15, 2022 at 12:32:50PM -0800, "Dan Mahoney (Gushi) via Gnupg-users" <gnupg-users at gnupg.org> wrote:

> Hey all,
> 
> A long time ago I wrote a doc on a blog about putting PGP keys in the DNS,
> which has been linked to quite a bit.  I also recoded make-dns-cert as a
> shell script so that people who want to do this but don't have access to the
> make-dns-cert tool (which is not built by default on some OS packages) had
> an option to do this.
> 
> At the day job, we have a script that we use to push gpg-signed releases to
> our FTP server, and as part of that job, it verifies the signatures on the
> tarball, and will try to auto-key-locate those keys if it can't find them.
> 
> Since the debacle a few years ago with the SKS keyserver denial-of-service
> attack, the keyservers are kind of a non-starter.  And because GPG searches
> for keys on a tarball by keyid, not by user at domain, a keyserver is the only
> real retrieval method available to look up a key by keyid, which is now a
> non-starter.
> 
> Worse still, if you know a key exists via something like DANE (dayjob makes
> DNS software, we like the idea of it being available via DANE), there's no
> way to do gpg --search via DANE, only via a keyserver.
> 
> Thus, using that as a prefetch method to grab the current version of our
> codesign@ key into our keyring is not helpful either, unless we "faked it"
> by attempting to encrypt a message to that address, then discarded it.
> 
> Is there another way forward?  The normal things for auto-key-locate don't
> seem to help here.  I'm open to ideas.
> 
> -Dan
> 
> (PS: on gnupg.org, the documentation for auto-key-locate dane says "Locate a
> key using DANE, as specified in draft-ietf-dane-openpgpkey-05.txt."  It
> should probably say RFC7929 rather than referring to an I-D.)
> 
> -- 
> 
> --------Dan Mahoney--------
> Techie,  Sysadmin,  WebGeek
> Gushi on efnet/undernet IRC
> FB:  fb.com/DanielMahoneyIV
> LI:   linkedin.com/in/gushi
> Site:  http://www.gushi.org
> ---------------------------

Hi,

Recently, I asked for dane to be added to --auto-key-retrieve
when dane was in the auto-key-locate list (https://dev.gnupg.org/T5586),
but the outcome was: "Wontfix: DANE has been an experimental thing
and is imho dead".

I think that experiment might have taken place at a time when DNSSEC
was too much effort to implement. That's not longer the case, so maybe
the experiment should be allowed to continue.

But maybe it is dead. I don't really need it. My only interest was that
I'd written software that manages dane records (including openpgpkey),
but I don't know if anyone else is using that feature. Probably not.

cheers,
raf



From andrewg at andrewg.com  Wed Feb 16 10:32:26 2022
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Wed, 16 Feb 2022 09:32:26 +0000
Subject: Questions re auto-key-locate
In-Reply-To: <FD525CD6-5746-4EC9-A009-07765A4E3E54@prime.gushi.org>
References: <7ACC6273-8479-4CBF-B844-2F99BA29A1EB@andrewg.com>
 <FD525CD6-5746-4EC9-A009-07765A4E3E54@prime.gushi.org>
Message-ID: <806df034-8a45-04e1-e4d9-2d3fe78c5f6a@andrewg.com>

On 15/02/2022 23:37, Dan Mahoney wrote:
> That's a decision I leave up to the people who *make*  the key (and the software that it's signing).

Sorry, from your previous message it sounded like you were publishing 
your own software.

> (and it's no longer the case that you can publish just anyone's key)

This is not true, you can still publish any key you want. In the 
specific case that you publish to keys.openpgp.org it will not be 
searchable by userid until the key owner verifies it, but your use case 
only requires lookup by fingerprint, so that doesn't arise.

> Right now, the decision is that our key (signed with our prior-year key) is on our website and FTP (also via https) site, and we do not assert that it's available on the keyservers.

OK, but again I'm curious about the reasoning...

-- 
Andrew Gallagher

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20220216/47e1db9c/attachment.sig>

From mycraigsl at ymail.com  Thu Feb 17 16:09:14 2022
From: mycraigsl at ymail.com (MyCraigs List)
Date: Thu, 17 Feb 2022 15:09:14 +0000 (UTC)
Subject: Can't synchronize keys using Seahorse
References: <556199605.3244964.1645110554664.ref@mail.yahoo.com>
Message-ID: <556199605.3244964.1645110554664@mail.yahoo.com>

I can't synchronize my keys using Seahorse.
The error message reads;
Couldn't communicate with keyserver.pgp.com: Server is unwilling to perform.
How can I fix this?
Thanks,
Craig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20220217/ed6fb20a/attachment.html>

From rjh at sixdemonbag.org  Thu Feb 17 17:35:53 2022
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Thu, 17 Feb 2022 11:35:53 -0500
Subject: TB weirdness
Message-ID: <22041840-a9a7-e045-fc55-50e0ef9304ba@sixdemonbag.org>

Yes, I know, Thunderbird doesn't use GnuPG.  However, for those who do: 
apparently, Thunderbird is a big fan of attaching public certificates 
(and/or revocation certificates, for revoked keys) to outgoing emails 
for *every private certificate on your keyring*, regardless of whether 
that private key is actually associated with the account in question.

This has the potential to leak personal information, especially if 
you're in a use case where you have two or more keys presenting 
different pseudonymous identities.  Without knowing it, you might 
accidentally reveal you're the common actor behind both.

I apologize for bringing the non-GnuPG content to the list, but please 
make sure your correspondents are aware of the possible risk in how 
Thunderbird likes to attach public certificates.  That's all.  Thank you!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20220217/db258608/attachment.sig>

From wk at gnupg.org  Thu Feb 17 20:21:02 2022
From: wk at gnupg.org (Werner Koch)
Date: Thu, 17 Feb 2022 20:21:02 +0100
Subject: Questions re auto-key-locate
In-Reply-To: <YgyhuP8Yfgs9tYIe@raf.org> (raf via Gnupg-users's message of
 "Wed, 16 Feb 2022 18:03:20 +1100")
References: <bb23967a-8db7-b739-8a6a-456469ec4236@prime.gushi.org>
 <YgyhuP8Yfgs9tYIe@raf.org>
Message-ID: <875ypd47vl.fsf@wheatstone.g10code.de>

On Wed, 16 Feb 2022 18:03, raf said:

> But maybe it is dead. I don't really need it. My only interest was that

Yes, it is dead.  Except for a minority of users, it is impossible to
easily add new resource records.  However, putting new files on a
webserver is easy.

FWIW, you can build your keys for WKD distribution on your local machine
and then rsync (or whatever you use to upload files) them to the
webserver. 

  gpg-wks-client -C . --install-key [FILE|FINGERPRINT USER-ID] 

  The command --install-key manually installs a key into a local
  directory (see option -C) reflecting the structure of a WKD.  The
  arguments are a file with the keyblock and the user-id to install.
  If the first argument resembles a fingerprint the key is taken from
  the current keyring; to force the use of a file, prefix the first
  argument with "./".  If no arguments are given the parameters are
  read from stdin; the expected format are lines with the fingerprint
  and the mailbox separated by a space.  The command --remove-key
  removes a key from that directory, its only argument is a user-id



Salam-Shalom,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20220217/2a0fc286/attachment.sig>

From rjh at sixdemonbag.org  Thu Feb 17 17:18:58 2022
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Thu, 17 Feb 2022 11:18:58 -0500
Subject: Can't synchronize keys using Seahorse
In-Reply-To: <556199605.3244964.1645110554664@mail.yahoo.com>
References: <556199605.3244964.1645110554664.ref@mail.yahoo.com>
 <556199605.3244964.1645110554664@mail.yahoo.com>
Message-ID: <09d2252a-24e6-c200-f0bb-3ed2fa3eb875@sixdemonbag.org>

> How can I fix this?

Specify a different keyserver.

keyserver.pgp.com was a commercial keyserver run by PGP Corporation, or 
whichever corporate entity owned the PGP intellectual property at the 
time.  Network Associates gave way to PGP Security gave way to Symantec 
gave way to...

The PGP intellectual property is for all intents and purposes dead at 
this point.  Symantec has even stopped using the PGP trademarks: they 
may still sell the software, but they've stopped issuing new releases 
and they've rebranded it to something as bland as cottage cheese.

keyserver.pgp.com is still operational today, but nobody knows for how 
long.  It would be wise to assume that it will go away at some point, 
and start migrating to another keyserver.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x1E7A94D4E87F91D5_and_old_rev.asc
Type: application/pgp-keys
Size: 60806 bytes
Desc: OpenPGP public key
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20220217/8c0c8e18/attachment-0001.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20220217/8c0c8e18/attachment-0001.sig>

From hello at danielcolquitt.com  Fri Feb 18 09:09:28 2022
From: hello at danielcolquitt.com (Daniel Colquitt)
Date: Fri, 18 Feb 2022 09:09:28 +0100 (CET)
Subject: Changing the encryption algorithm used for PGP/GPG private key
In-Reply-To: <1916288833.157.1644831385028@upanova.co-bxl>
References: <1916288833.157.1644831385028@upanova.co-bxl>
Message-ID: <454531270.3362.1645171767978@upanova.co-bxl>

Just to follow up that this isn't a gpgwin problem. I have a Debian installation and generated a test key using GnuPG and the same gpg.conf file. Here is the output

> gpg --list-packets test.key
> # off=0 ctb=95 tag=5 hlen=3 plen=1862
> :secret key packet:
>        version 4, algo 1, created 1645171018, expires 0
>        pkey[0]: [4096 bits]
>        pkey[1]: [17 bits]
>        iter+salt S2K, algo: 7, SHA1 protection, hash: 2, salt: 618B50CF0281AD75
>        protect count: 23068672 (230)
>        protect IV:  74 02 5e e0 92 12 8a 5e 53 aa 17 4a 40 e0 7e 8d
>        skey[2]: [v4 protected]
>        keyid: 45A023416F46CE6E

I have verified that gpg reads the gpg.conf file and understands it.

Any help would be very much appreciated.

Yours,
Dan




From kloecker at kde.org  Fri Feb 18 09:55:39 2022
From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=)
Date: Fri, 18 Feb 2022 09:55:39 +0100
Subject: Changing the encryption algorithm used for PGP/GPG private key
In-Reply-To: <1916288833.157.1644831385028@upanova.co-bxl>
References: <1916288833.157.1644831385028@upanova.co-bxl>
Message-ID: <1916935.GDIAP8zadm@daneel>

On Montag, 14. Februar 2022 10:36:25 CET Daniel Colquitt via Gnupg-users 
wrote:
> I've read various tutorials and posts regarding changing the algorithm used 
to encrypt my private PGP keys. However, nothing I have tried seems to work. I 
am using gpg4win:
[...]
> My gpg.conf file located at
> C:\Users\[REDACTED]\AppData\Roaming\gnupg\gpg.conf is
> > personal-digest-preferences SHA512
> > cert-digest-algo SHA512
> > default-preference-list SHA512 SHA384 SHA256 SHA224 SHA1 AES256 AES192 AES
> > ZLIB BZIP2 ZIP Uncompressed OCB EAX ks-modify personal-cipher-preferences
> > AES256 AES192 AES
> > s2k-mode 3
> > s2k-cipher-algo AES256
> > s2k-digest-algo SHA512
> > s2k-count 65011712
> > cipher-algo AES256

As far as I can tell `man gpg` does not claim that any of these settings 
influence the encryption of secret keys.

> > :secret key packet:
> >     ...
> >     iter+salt S2K, algo: 7, SHA1 protection, hash: 2,
> >     ...
> 
> This would seem to suggest that the key is still encrypted using AES128
> (algo 7) and a SHA1 hash.

Not sure about the encryption algo, but the usage of SHA-1 seems to be 
mandatory (unless one wants to use a completely insecure two-octet checksum):
https://datatracker.ietf.org/doc/html/rfc4880#section-5.5.3

Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20220218/8164b356/attachment.sig>

From hello at danielcolquitt.com  Fri Feb 18 13:08:39 2022
From: hello at danielcolquitt.com (Daniel Colquitt)
Date: Fri, 18 Feb 2022 13:08:39 +0100 (CET)
Subject: Changing the encryption algorithm used for PGP/GPG private key
In-Reply-To: <1916935.GDIAP8zadm@daneel>
References: <1916288833.157.1644831385028@upanova.co-bxl>
 <1916935.GDIAP8zadm@daneel>
Message-ID: <2014567257.3495.1645186119470@upanova.co-bxl>

Thanks for responding, Ingo.

> As far as I can tell `man gpg` does not claim that any of these settings
> influence the encryption of secret keys.

According to the
manual<https://gnupg.org/documentation/manuals/gnupg/OpenPGP-Options.html#in
dex-s2k_002dcipher_002dalgo>, the --s2k-* flags control the algorithm used
for symmetric encryption  if the --personal-cipher-preferences flag isn't
set.

Is the suggestion the gpg does not respect these flags when applying
symmetric encryption to keys?

Dan


From vedaal at nym.hush.com  Fri Feb 18 22:12:07 2022
From: vedaal at nym.hush.com (vedaal at nym.hush.com)
Date: Fri, 18 Feb 2022 16:12:07 -0500
Subject: Changing the encryption algorithm used for PGP/GPG private key
In-Reply-To: <454531270.3362.1645171767978@upanova.co-bxl>
References: <1916288833.157.1644831385028@upanova.co-bxl>
 <454531270.3362.1645171767978@upanova.co-bxl> 
Message-ID: <20220218211207.7141280E2C5@smtp.hushmail.com>



On 2/18/2022 at 3:12 AM, "Daniel Colquitt via Gnupg-users"  wrote:Just
to follow up that this isn't a gpgwin problem. I have a Debian
installation and generated a test key using GnuPG and the same
gpg.conf file

=====

Try this:
In gpg.conf file add the option of
--expert
and in personal preferences, list only AES 256,
Not the other strengths. 
Keep all of the s2k options you listed, and try generating a new key
again
Vedaal 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20220218/8511ace7/attachment.html>

From hello at danielcolquitt.com  Sat Feb 19 10:41:12 2022
From: hello at danielcolquitt.com (Daniel Colquitt)
Date: Sat, 19 Feb 2022 10:41:12 +0100 (CET)
Subject: Changing the encryption algorithm used for PGP/GPG private key
In-Reply-To: <20220218211207.7141280E2C5@smtp.hushmail.com>
References: <20220218211207.7141280E2C5@smtp.hushmail.com>
Message-ID: <642255619.4021.1645263672470@upanova.co-bxl>

Hi Vedaal,

> Try this:
> In gpg.conf file add the option of
> --expert
> and in personal preferences, list only AES 256,
> Not the other strengths. 
> Keep all of the s2k options you listed, and try generating a new key again
> Vedaal 

Many thanks for the suggestion, but I?m afraid that this still does not work for me.

It seems the gnupg ignores all s2k and cipher preference flags when encrypting private keys. If this is indeed the intended behaviour (although I have no idea why it should be), perhaps it would a good idea to add a warning to the man pages?

Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20220219/73a3f621/attachment.html>

From wk at gnupg.org  Sat Feb 19 15:50:19 2022
From: wk at gnupg.org (Werner Koch)
Date: Sat, 19 Feb 2022 15:50:19 +0100
Subject: Who protects the private key (was: Changing the encryption algorithm
 used for PGP/GPG private key)
In-Reply-To: <2014567257.3495.1645186119470@upanova.co-bxl> (Daniel Colquitt
 via Gnupg-users's message of "Fri, 18 Feb 2022 13:08:39 +0100 (CET)")
References: <1916288833.157.1644831385028@upanova.co-bxl>
 <1916935.GDIAP8zadm@daneel>
 <2014567257.3495.1645186119470@upanova.co-bxl>
Message-ID: <875ypa29n8.fsf_-_@wheatstone.g10code.de>

On Fri, 18 Feb 2022 13:08, Daniel Colquitt said:

> Is the suggestion the gpg does not respect these flags when applying
> symmetric encryption to keys?

gpg does not encrypt private keys.  This is done by gpg-agent.  The
method how the keys are protected internally are out of scope for
OpenPGP.  See gnupg/agent/keyformat.txt for the specification of the
internal format.

However, for allowing gpg to export a private key in the OpenPGP
specified format, gpg-agent applies the encryption.  For this S2K mode 3
with AES128 and SHA1 is used.  The iteration count is the standard count
as figured out by gpg-agent - unless the gpg-agent option s2k-count is
used.  See these gpg-agent options:

   --s2k-calibration milliseconds
   
    Change the default calibration time to milliseconds.  The given
    value is capped at 60 seconds; a value of 0 resets to the
    compiled-in default.  This option is re-read on a SIGHUP (or gpgconf
    --reload gpg-agent) and the S2K count is then re-calibrated.

   --s2k-count n
   
    Specify the iteration count used to protect the passphrase.  This
    option can be used to override the auto-calibration done by default.
    The auto-calibration computes a count which requires by default
    100ms to mangle a given passphrase.  See also --s2k-calibration.

    To view the actually used iteration count and the milliseconds
    required for an S2K operation use:

     gpg-connect-agent 'GETINFO s2k_count' /bye
     gpg-connect-agent 'GETINFO s2k_time' /bye

   To view the auto-calibrated count use:

     gpg-connect-agent 'GETINFO s2k_count_cal' /bye


Remember that the OpenPGP specified protection format has some minor
flaws and it is suggested not to rely on this this protection alone.
Use the standard OpenPGP symmetric encryption layer on top.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20220219/7f960025/attachment.sig>

From hello at danielcolquitt.com  Sat Feb 19 17:02:14 2022
From: hello at danielcolquitt.com (Daniel Colquitt)
Date: Sat, 19 Feb 2022 17:02:14 +0100 (CET)
Subject: Who protects the private key (was: Changing the encryption
 algorithm used for PGP/GPG private key)
In-Reply-To: <875ypa29n8.fsf_-_@wheatstone.g10code.de>
References: <875ypa29n8.fsf_-_@wheatstone.g10code.de>
Message-ID: <1061216198.4149.1645286534539@upanova.co-bxl>


> On 19 Feb 2022, at 14:52, Werner Koch <wk at gnupg.org> wrote:
> 
> gpg does not encrypt private keys.  This is done by gpg-agent.  The
> method how the keys are protected internally are out of scope for
> OpenPGP.  See gnupg/agent/keyformat.txt for the specification of the
> internal format.

Apologies for conflating gpg and gpg-agent. I also appreciate that the protection of keys is not part of the OpenPGP specification. 

> However, for allowing gpg to export a private key in the OpenPGP
> specified format, gpg-agent applies the encryption.  For this S2K mode 3
> with AES128 and SHA1 is used. 

Whilst AES128 is probably okay for now, SHA1 has been broken for well over 15 years. Hence, my question about specifying alternative algorithms for the internal storage and exporting of private keys.

I now understand that it is not possible for the user to alter the encryption algorithm used by gpg-agent to secure private keys. Perhaps it would be a good idea to say this explicitly in a documentation? I appreciate that the manual does not say explicitly that this is possible, it certainly gives that impression.

Anyway, thank you for your help.

Dan

From jcb62281 at gmail.com  Sun Feb 20 03:07:48 2022
From: jcb62281 at gmail.com (Jacob Bachmeyer)
Date: Sat, 19 Feb 2022 20:07:48 -0600
Subject: Who protects the private key (was: Changing the encryption
 algorithm used for PGP/GPG private key)
In-Reply-To: <1061216198.4149.1645286534539@upanova.co-bxl>
References: <875ypa29n8.fsf_-_@wheatstone.g10code.de>
 <1061216198.4149.1645286534539@upanova.co-bxl>
Message-ID: <6211A274.8000004@gmail.com>

Daniel Colquitt via Gnupg-users wrote:
> Whilst AES128 is probably okay for now, SHA1 has been broken for well over 15 years.

Has it really been that long? ... No, it has not been:  a free-start 
collision was found on the SHA-1 compression function in 2015, less than 
7 years ago.

As far as I know, a single collision pair ("SHAttered") has been 
produced, using about 9 months on a very large cluster, against the full 
SHA-1.  There is no comparison here to MD5, for example.  Further, only 
collisions have been demonstrated so far, and if Mallory producing a 
colliding private key is a concern for you, you have bigger problems, 
like Mallory having provided your private key in the first place!

It is also worth noting that SHA-1 is (as far as I know) only used as a 
fancy checksum here to guard against data corruption.  If Mallory even 
has access to potentially replace your private key, you have bigger 
problems than potential weaknesses of the checksum on that key.


-- Jacob



From hello at danielcolquitt.com  Sun Feb 20 09:30:36 2022
From: hello at danielcolquitt.com (Daniel Colquitt)
Date: Sun, 20 Feb 2022 09:30:36 +0100 (CET)
Subject: Who protects the private key (was: Changing the encryption
 algorithm used for PGP/GPG private key)
In-Reply-To: <6211A274.8000004@gmail.com>
References: <875ypa29n8.fsf_-_@wheatstone.g10code.de>
 <1061216198.4149.1645286534539@upanova.co-bxl> <6211A274.8000004@gmail.com>
Message-ID: <887108780.4446.1645345836360@upanova.co-bxl>

> Has it really been that long? ... No, it has not been:  a free-start
collision was
> found on the SHA-1 compression function in 2015, less than
> 7 years ago.
>
> As far as I know, a single collision pair ("SHAttered") has been produced,
> using about 9 months on a very large cluster, against the full SHA-1.
There is
> no comparison here to MD5, for example.  

I used "broken" in the formal cryptographic sense - finding collisions
faster than brute force. Although SHAttered was the first public collision,
attacks capable of finding collisions far quicker than brute force have been
known since 2005<https://eprint.iacr.org/2007/474>

> Further, only collisions have been
> demonstrated so far, and if Mallory producing a colliding private key is a
> concern for you, you have bigger problems, like Mallory having provided
> your private key in the first place!
> 
> It is also worth noting that SHA-1 is (as far as I know) only used as a
fancy
> checksum here to guard against data corruption.  If Mallory even has
access
> to potentially replace your private key, you have bigger problems than
> potential weaknesses of the checksum on that key.

I agree with you, and Robert Hansen above, insofar as there is no practical
weakness in using SHA-1 as part of a key derivation algorithm. However, I
would argue that there is a serious problem with using SHA-1 to verify
digital signatures - but that is a matter for OpenPGP rather than GnuPG.

Nevertheless it does seem imprudent to use a formally broken hash function
by default, whilst silently ignoring options that users would reasonably
expect to change the algorithms used.

Dan


From rjh at sixdemonbag.org  Sat Feb 19 21:52:27 2022
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Sat, 19 Feb 2022 15:52:27 -0500
Subject: Who protects the private key (was: Changing the encryption
 algorithm used for PGP/GPG private key)
In-Reply-To: <1061216198.4149.1645286534539@upanova.co-bxl>
Message-ID: <c67ad27f-f5af-486b-bc44-93ea5775bd1c@email.android.com>

An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20220219/6d60ec2a/attachment.html>

From bangchuishan at outlook.com  Fri Feb 18 12:34:14 2022
From: bangchuishan at outlook.com (Gao Xiaohui)
Date: Fri, 18 Feb 2022 11:34:14 +0000
Subject: How to solve this garbled code?
Message-ID: <TYCP286MB1314880A20C10797CD17D287D5379@TYCP286MB1314.JPNP286.PROD.OUTLOOK.COM>

Hi developers, thanks for your reply. But I tried the method you gave: use "chcp 65001", and still display abnormal characters. Is there any other solution to solve it? If it is a bug, please fix it. Grateful.
[cid:c4658c5a-1a50-4e76-b1fd-f41a5cd06d2e]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20220218/1c05b4ed/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2022-02-18_191450.png
Type: image/png
Size: 9512 bytes
Desc: 2022-02-18_191450.png
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20220218/1c05b4ed/attachment-0001.png>

From alireza0101sadeghpour at gmail.com  Sun Feb 20 16:25:31 2022
From: alireza0101sadeghpour at gmail.com (Alireza Sadeghpour)
Date: Sun, 20 Feb 2022 18:55:31 +0330
Subject: Signing message problem with GPG loopback pin-entry option
Message-ID: <CAA=oK3PupJJapa4ey2-=idtPh+94WyezHKU+NmVpGt=aYD7WHA@mail.gmail.com>

I am trying to encrypt and sign a file with gpg and loopback pinentry
option, with the below command:

gpg --pinentry-mode=loopback --passphrase ="mypws" \
--ignore-time-conflict --ignore-valid-from \
--cipher-algo AES256 --symmetric --ignore-time-conflict \
--passphrase-file ~/.gnupg/PG/p-enckey --trust-model always -q --batch
--yes --local-user "UserID" \
--sign --force-mdc \
--output /var/psigner/2 \
/var/psigner/1

however i got the below error message:

gpg: signing failed: Too much data for IPC layer
gpg: /var/psigner/1: sign+symmetric failed: Too much data for IPC layer

but with the below command, which a dialog pops up to ask for the key
passphrase, everything works fine.

gpg \
--ignore-time-conflict --ignore-valid-from \
--cipher-algo AES256 --symmetric --ignore-time-conflict \
--passphrase-file ~/.gnupg/PG/patch-enckey --trust-model always -q
--batch --yes --local-user "UserID" \
--sign --force-mdc \
--output /var/psigner/2 \
/var/psigner/1

Can anyone give me advice to solve the problem?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20220220/9c18b1bd/attachment.html>

From kloecker at kde.org  Sun Feb 20 17:06:07 2022
From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=)
Date: Sun, 20 Feb 2022 17:06:07 +0100
Subject: Signing message problem with GPG loopback pin-entry option
In-Reply-To: <CAA=oK3PupJJapa4ey2-=idtPh+94WyezHKU+NmVpGt=aYD7WHA@mail.gmail.com>
References: <CAA=oK3PupJJapa4ey2-=idtPh+94WyezHKU+NmVpGt=aYD7WHA@mail.gmail.com>
Message-ID: <5082347.0mk2O1vgTK@daneel>

On Sonntag, 20. Februar 2022 16:25:31 CET Alireza Sadeghpour via Gnupg-users 
wrote:
> I am trying to encrypt and sign a file with gpg and loopback pinentry
> option, with the below command:
> 
> gpg --pinentry-mode=loopback --passphrase ="mypws" \
> --ignore-time-conflict --ignore-valid-from \
> --cipher-algo AES256 --symmetric --ignore-time-conflict \
> --passphrase-file ~/.gnupg/PG/p-enckey --trust-model always -q --batch
> --yes --local-user "UserID" \
> --sign --force-mdc \
> --output /var/psigner/2 \
> /var/psigner/1

Using the options --passphrase *and* --passphrase-file makes no sense.

> however i got the below error message:
> 
> gpg: signing failed: Too much data for IPC layer
> gpg: /var/psigner/1: sign+symmetric failed: Too much data for IPC layer

Could it be that the file ~/.gnupg/PG/p-enckey contains more data than gpg 
allows/supports for a passphrase?

> Can anyone give me advice to solve the problem?

Removing `--passphrase-file ~/.gnupg/PG/p-enckey` from the command line could 
solve your problem.

Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20220220/e0aa8f6d/attachment.sig>

From alireza0101sadeghpour at gmail.com  Sun Feb 20 17:37:51 2022
From: alireza0101sadeghpour at gmail.com (Alireza Sadeghpour)
Date: Sun, 20 Feb 2022 20:07:51 +0330
Subject: Signing message problem with GPG loopback pin-entry option
In-Reply-To: <5082347.0mk2O1vgTK@daneel>
References: <CAA=oK3PupJJapa4ey2-=idtPh+94WyezHKU+NmVpGt=aYD7WHA@mail.gmail.com>
 <5082347.0mk2O1vgTK@daneel>
Message-ID: <CAA=oK3MuqxOjHiCXAt4+1FoP54ZXifHwjTfifTht+C7F-PQXoQ@mail.gmail.com>

Thanks for your response,

Actually i need to use two keys, one  for aes encryption and another one is
used for rsa signing, which both of them are protected with a passphrase.

I tried to indicate rsa key passphrase with --passphrase option and aes key
with --passphrase-file option.

If that is wrong, how can i indicate passphrase for two separate keys in
same command?

Sencerly

On Sun, 20 Feb 2022, 7:37 PM Ingo Kl?cker, <kloecker at kde.org> wrote:

> On Sonntag, 20. Februar 2022 16:25:31 CET Alireza Sadeghpour via
> Gnupg-users
> wrote:
> > I am trying to encrypt and sign a file with gpg and loopback pinentry
> > option, with the below command:
> >
> > gpg --pinentry-mode=loopback --passphrase ="mypws" \
> > --ignore-time-conflict --ignore-valid-from \
> > --cipher-algo AES256 --symmetric --ignore-time-conflict \
> > --passphrase-file ~/.gnupg/PG/p-enckey --trust-model always -q --batch
> > --yes --local-user "UserID" \
> > --sign --force-mdc \
> > --output /var/psigner/2 \
> > /var/psigner/1
>
> Using the options --passphrase *and* --passphrase-file makes no sense.
>
> > however i got the below error message:
> >
> > gpg: signing failed: Too much data for IPC layer
> > gpg: /var/psigner/1: sign+symmetric failed: Too much data for IPC layer
>
> Could it be that the file ~/.gnupg/PG/p-enckey contains more data than gpg
> allows/supports for a passphrase?
>
> > Can anyone give me advice to solve the problem?
>
> Removing `--passphrase-file ~/.gnupg/PG/p-enckey` from the command line
> could
> solve your problem.
>
> Regards,
> Ingo
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> https://lists.gnupg.org/mailman/listinfo/gnupg-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20220220/abf822ba/attachment.html>

From kloecker at kde.org  Sun Feb 20 18:00:36 2022
From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=)
Date: Sun, 20 Feb 2022 18:00:36 +0100
Subject: Signing message problem with GPG loopback pin-entry option
In-Reply-To: <CAA=oK3MuqxOjHiCXAt4+1FoP54ZXifHwjTfifTht+C7F-PQXoQ@mail.gmail.com>
References: <CAA=oK3PupJJapa4ey2-=idtPh+94WyezHKU+NmVpGt=aYD7WHA@mail.gmail.com>
 <5082347.0mk2O1vgTK@daneel>
 <CAA=oK3MuqxOjHiCXAt4+1FoP54ZXifHwjTfifTht+C7F-PQXoQ@mail.gmail.com>
Message-ID: <1928450.mqKO6lpeso@daneel>

On Sonntag, 20. Februar 2022 17:37:51 CET Alireza Sadeghpour wrote:
> On Sun, 20 Feb 2022, 7:37 PM Ingo Kl?cker, <kloecker at kde.org> wrote:
> > On Sonntag, 20. Februar 2022 16:25:31 CET Alireza Sadeghpour wrote:
> > > I am trying to encrypt and sign a file with gpg and loopback pinentry
> > > option, with the below command:
> > > 
> > > gpg --pinentry-mode=loopback --passphrase ="mypws" \
> > > --ignore-time-conflict --ignore-valid-from \
> > > --cipher-algo AES256 --symmetric --ignore-time-conflict \
> > > --passphrase-file ~/.gnupg/PG/p-enckey --trust-model always -q --batch
> > > --yes --local-user "UserID" \
> > > --sign --force-mdc \
> > > --output /var/psigner/2 \
> > > /var/psigner/1
> > 
> > Using the options --passphrase *and* --passphrase-file makes no sense.
>
> Actually i need to use two keys, one  for aes encryption and another one is
> used for rsa signing, which both of them are protected with a passphrase.
> 
> I tried to indicate rsa key passphrase with --passphrase option and aes key
> with --passphrase-file option.
> 
> If that is wrong, how can i indicate passphrase for two separate keys in
> same command?

Our usual reply to people trying to do provide a passphrase for doing 
automatic signing (or decryption) is: Use a passphrase-less key.

If you put the passphrase needed for the signing key next to the signing key, 
then you do not gain any security by protecting the signing key with a non-
empty passphrase. That's like putting a super secure lock into the front door 
of your house and then hanging the key next to the door on a nail.

Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20220220/7b13fe0d/attachment.sig>

From mailinglisten at posteo.de  Sun Feb 20 20:38:48 2022
From: mailinglisten at posteo.de (mailinglisten at posteo.de)
Date: Sun, 20 Feb 2022 19:38:48 +0000
Subject: gpg --verify fails, no key?
Message-ID: <e1ab29ed-e779-136b-2418-d007ecebc587@posteo.de>

Hi there,

when trying this:

gpg --verify gnupg-2.3.4.tar.bz2.sig gnupg-2.3.4.tar.bz2

I get that:

gpg: Signature made Mo 20 Dez 2021 22:52:45 CET
gpg:                using EDDSA key 6DAA6E64A76D2840571B4902528897B826403ADA
gpg: Good signature from "Werner Koch (dist signing 2020)" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the
owner.
Primary key fingerprint: 6DAA 6E64 A76D 2840 571B  4902 5288 97B8 2640 3ADA
gpg: Signature made Di 21 Dez 2021 07:20:39 CET
gpg:                using EDDSA key AC8E115BF73E2D8D47FA9908E98E9B2D19C6C8BD
gpg: Can't check signature: No public key


First gpg says, good signature, then it says "no public key"?
Has the tarball been signed with two keys?
Verification was tried using gpg 2.3.1

Thanks!


From ralph at ml.seichter.de  Sun Feb 20 22:16:31 2022
From: ralph at ml.seichter.de (Ralph Seichter)
Date: Sun, 20 Feb 2022 22:16:31 +0100
Subject: gpg --verify fails, no key?
In-Reply-To: <e1ab29ed-e779-136b-2418-d007ecebc587@posteo.de>
References: <e1ab29ed-e779-136b-2418-d007ecebc587@posteo.de>
Message-ID: <87zgmls0gg.fsf@ra.horus-it.com>

* mailinglisten:

> Has the tarball been signed with two keys?

According to the output you posted there are two signatures from two
separate keys, made on two different days.

-Ralph


From ostroffjh at users.sourceforge.net  Sun Feb 20 21:05:01 2022
From: ostroffjh at users.sourceforge.net (Jack)
Date: Sun, 20 Feb 2022 15:05:01 -0500
Subject: How to solve this garbled code?
In-Reply-To: <TYCP286MB1314880A20C10797CD17D287D5379@TYCP286MB1314.JPNP286.PROD.OUTLOOK.COM>
References: <TYCP286MB1314880A20C10797CD17D287D5379@TYCP286MB1314.JPNP286.PROD.OUTLOOK.COM>
Message-ID: <59ed2ab8-0801-577e-5c3f-bc1ad9a929f8@users.sourceforge.net>

Not gpg specific, but I would capture that output in a file, and then 
use other tools to figure out what that text is.? On linux, I would 
start with some variant of "od -c" or perhaps open it in a text editor 
or word processor.


On 2/18/22 06:34, Gao Xiaohui via Gnupg-users wrote:
> Hi developers, thanks for your reply. But I tried the method you gave: 
> use "chcp 65001", and still display abnormal characters. Is there any 
> other solution to solve it? If it is a bug, please fix it. Grateful.
>
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> https://lists.gnupg.org/mailman/listinfo/gnupg-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20220220/4f318e89/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2022-02-18_191450.png
Type: image/png
Size: 9512 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20220220/4f318e89/attachment.png>

From kloecker at kde.org  Mon Feb 21 08:44:59 2022
From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=)
Date: Mon, 21 Feb 2022 08:44:59 +0100
Subject: gpg --verify fails, no key?
In-Reply-To: <87zgmls0gg.fsf@ra.horus-it.com>
References: <e1ab29ed-e779-136b-2418-d007ecebc587@posteo.de>
 <87zgmls0gg.fsf@ra.horus-it.com>
Message-ID: <4316489.HM6YA3GJAs@daneel>

On Sonntag, 20. Februar 2022 22:16:31 CET Ralph Seichter via Gnupg-users 
wrote:
> > Has the tarball been signed with two keys?
> 
> According to the output you posted there are two signatures from two
> separate keys, made on two different days.

Looking at
https://gnupg.org/download/integrity_check.html
this seems to be common practice.

Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20220221/4c8b6476/attachment.sig>

From wk at gnupg.org  Mon Feb 21 19:17:37 2022
From: wk at gnupg.org (Werner Koch)
Date: Mon, 21 Feb 2022 19:17:37 +0100
Subject: Who protects the private key
In-Reply-To: <c67ad27f-f5af-486b-bc44-93ea5775bd1c@email.android.com> (Robert
 J. Hansen via Gnupg-users's message of "Sat, 19 Feb 2022 15:52:27
 -0500")
References: <c67ad27f-f5af-486b-bc44-93ea5775bd1c@email.android.com>
Message-ID: <87tucsw0ce.fsf@wheatstone.g10code.de>

On Sat, 19 Feb 2022 15:52, Robert J. Hansen said:

> As part of an iterated key derivation function, SHA-1 is still believed safe. 
> There's no reason to shy away from it, or AES128.

FWIW: SHA-1 is also used has part of the OpenPGP MDC construction.  This
is something alike a MAC and there are not signs anyware that this
construction is broken.  In fact, it was part of the first widely
deployed AE algorithm (in 2001).


Shalom-Salam,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20220221/ec545197/attachment.sig>

From wk at gnupg.org  Mon Feb 21 19:18:25 2022
From: wk at gnupg.org (Werner Koch)
Date: Mon, 21 Feb 2022 19:18:25 +0100
Subject: How to solve this garbled code?
In-Reply-To: <TYCP286MB1314880A20C10797CD17D287D5379@TYCP286MB1314.JPNP286.PROD.OUTLOOK.COM>
 (Gao Xiaohui via Gnupg-users's message of "Fri, 18 Feb 2022 11:34:14
 +0000")
References: <TYCP286MB1314880A20C10797CD17D287D5379@TYCP286MB1314.JPNP286.PROD.OUTLOOK.COM>
Message-ID: <87pmngw0b2.fsf@wheatstone.g10code.de>

On Fri, 18 Feb 2022 11:34, Gao Xiaohui said:
> Hi developers, thanks for your reply. But I tried the method you gave:
> use "chcp 65001", and still display abnormal characters. Is there any
> other solution to solve it? If it is a bug, please fix it. Grateful.

You need to install/configure a proper font for your terminal.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20220221/1e1c6c32/attachment-0001.sig>

From 400thecat at gmx.ch  Tue Feb 22 17:28:00 2022
From: 400thecat at gmx.ch (Fourhundred Thecat)
Date: Tue, 22 Feb 2022 17:28:00 +0100
Subject: use text pinentry in the console
Message-ID: <c92532ff-d666-3f42-40fe-15ef2cf7d146@gmx.ch>

Hello,

when I type a gpg command in the terminal, such as:

   gpg -c foo

the GUI pinentry dialog pops up to ask for password (I guess its
pinentry-gtk-2)

How can I confugure so that the ncurses (text based) dialog is used
instead ?

I am using gpg 2.2.12 on Debian 10

thank you


From johndoe65534 at mail.com  Tue Feb 22 18:57:39 2022
From: johndoe65534 at mail.com (john doe)
Date: Tue, 22 Feb 2022 18:57:39 +0100
Subject: use text pinentry in the console
In-Reply-To: <c92532ff-d666-3f42-40fe-15ef2cf7d146@gmx.ch>
References: <c92532ff-d666-3f42-40fe-15ef2cf7d146@gmx.ch>
Message-ID: <6d8a36e1-0702-80ba-4deb-c3b94c6723f0@mail.com>

On 2/22/2022 5:28 PM, Fourhundred Thecat via Gnupg-users wrote:
> Hello,
>
> when I type a gpg command in the terminal, such as:
>
>  ? gpg -c foo
>
> the GUI pinentry dialog pops up to ask for password (I guess its
> pinentry-gtk-2)
>
> How can I confugure so that the ncurses (text based) dialog is used
> instead ?
>
> I am using gpg 2.2.12 on Debian 10
>

On Debian you need to use:

$ update-alternatives --config pinentry

--
John Doe


From keine-eile at e-mail.de  Tue Feb 22 18:45:06 2022
From: keine-eile at e-mail.de (Keine Eile)
Date: Tue, 22 Feb 2022 18:45:06 +0100
Subject: use text pinentry in the console
In-Reply-To: <c92532ff-d666-3f42-40fe-15ef2cf7d146@gmx.ch>
References: <c92532ff-d666-3f42-40fe-15ef2cf7d146@gmx.ch>
Message-ID: <2c743932-1ee2-3cea-5441-7a7989871f35@e-mail.de>

It's not ncurses, but you can use 'gpg --pinentry-mode loopback' to get the text mode.


From guru at unixarea.de  Tue Feb 22 18:18:14 2022
From: guru at unixarea.de (Matthias Apitz)
Date: Tue, 22 Feb 2022 18:18:14 +0100
Subject: use text pinentry in the console
In-Reply-To: <c92532ff-d666-3f42-40fe-15ef2cf7d146@gmx.ch>
References: <c92532ff-d666-3f42-40fe-15ef2cf7d146@gmx.ch>
Message-ID: <YhUa1u/oqyhDkkSk@c720-r368166>

El d?a martes, febrero 22, 2022 a las 05:28:00p. m. +0100, Fourhundred Thecat via Gnupg-users escribi?:

> Hello,
> 
> when I type a gpg command in the terminal, such as:
> 
>   gpg -c foo
> 
> the GUI pinentry dialog pops up to ask for password (I guess its
> pinentry-gtk-2)
> 
> How can I confugure so that the ncurses (text based) dialog is used
> instead ?
> 
> I am using gpg 2.2.12 on Debian 10

Run

# ls -l /usr/bin/pinent*

and set the sym-link to your needs.

	matthias

-- 
Matthias Apitz, ? guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub

Peace instead of NATO!  ??? ?????? ????!  Frieden statt NATO! ?Paz en vez de OTAN!


From 400thecat at gmx.ch  Wed Feb 23 07:05:51 2022
From: 400thecat at gmx.ch (Fourhundred Thecat)
Date: Wed, 23 Feb 2022 07:05:51 +0100
Subject: use text pinentry in the console
In-Reply-To: <6d8a36e1-0702-80ba-4deb-c3b94c6723f0@mail.com>
References: <c92532ff-d666-3f42-40fe-15ef2cf7d146@gmx.ch>
 <6d8a36e1-0702-80ba-4deb-c3b94c6723f0@mail.com>
Message-ID: <af520f7c-77de-8c92-28ab-cfed5b83e343@gmx.ch>

 > On 2022-02-22 18:57, john doe via Gnupg-users wrote:
> On 2/22/2022 5:28 PM, Fourhundred Thecat via Gnupg-users wrote:
>>
>> How can I confugure so that the ncurses (text based) dialog is used
>> instead ?
>>
>> I am using gpg 2.2.12 on Debian 10
>
> On Debian you need to use:
>
> $ update-alternatives --config pinentry

thank you, but changing this globally unfortunately causes problem with
thunderbird/enigmail. I get this error when trying to open encrypted mail:

Your GnuPG installation is configured to use the console for pinentry.
However, when using Enigmail you need a graphical version of pinentry.

This is a system setup or configuration error that prevents Enigmail
from working properly and cannot be fixed automatically.

What I would like to achieve is, that only when I call gog from the
commandline, (gpg -c foo.txt) is the text-based pinentry called

thank you




From 400thecat at gmx.ch  Wed Feb 23 08:09:56 2022
From: 400thecat at gmx.ch (Fourhundred Thecat)
Date: Wed, 23 Feb 2022 08:09:56 +0100
Subject: use text pinentry in the console
In-Reply-To: <af520f7c-77de-8c92-28ab-cfed5b83e343@gmx.ch>
References: <c92532ff-d666-3f42-40fe-15ef2cf7d146@gmx.ch>
 <6d8a36e1-0702-80ba-4deb-c3b94c6723f0@mail.com>
 <af520f7c-77de-8c92-28ab-cfed5b83e343@gmx.ch>
Message-ID: <d33ece84-ea97-928e-4e6d-5982ca30564c@gmx.ch>

 > On 2022-02-23 07:05, Fourhundred Thecat via Gnupg-users wrote:
>  > On 2022-02-22 18:57, john doe via Gnupg-users wrote:
>> On 2/22/2022 5:28 PM, Fourhundred Thecat via Gnupg-users wrote:
>>
>> $ update-alternatives --config pinentry
>
> What I would like to achieve is, that only when I call gog from the
> commandline, (gpg -c foo.txt) is the text-based pinentry called

also, I tried adding an alias:

  gpg='gpg --pinentry-mode loopback'

but then, I have another problem. When I use

   gpg -c foo.txt

it only asks for password once, not twice. I would like to be asked
twice, to make sure the password is correct



From 400thecat at gmx.ch  Wed Feb 23 11:22:38 2022
From: 400thecat at gmx.ch (Fourhundred Thecat)
Date: Wed, 23 Feb 2022 11:22:38 +0100
Subject: use text pinentry in the console
In-Reply-To: <87ee3uvwrk.fsf@city17.xyz>
References: <c92532ff-d666-3f42-40fe-15ef2cf7d146@gmx.ch>
 <6d8a36e1-0702-80ba-4deb-c3b94c6723f0@mail.com>
 <af520f7c-77de-8c92-28ab-cfed5b83e343@gmx.ch> <87ee3uvwrk.fsf@city17.xyz>
Message-ID: <e521ee2a-68f2-3fb6-e777-e5ce39b97dfa@gmx.ch>

 > On 2022-02-23 08:40, jman wrote:
>
> I think you can set that with an env var in your ~/.bashrc:
> export PINENTRY_USER_DATA=ncurses
>
> and the pinentry chooser will be `/usr/bin/pinentry-ncurses`.
>
> As a further option, I use the basic `tty` pinentry chooser and I set
> this in my ~/.bashrc:
> export PINENTRY_USER_DATA=tty

thank you, but exporting PINENTRY_USER_DATA=ncurses or
PINENTRY_USER_DATA=tty has no effect

I still get the popup gtk pinenetry dialog..


From klaus+gnupg at ethgen.ch  Wed Feb 23 11:40:37 2022
From: klaus+gnupg at ethgen.ch (Klaus Ethgen)
Date: Wed, 23 Feb 2022 11:40:37 +0100
Subject: use text pinentry in the console
In-Reply-To: <c92532ff-d666-3f42-40fe-15ef2cf7d146@gmx.ch>
References: <c92532ff-d666-3f42-40fe-15ef2cf7d146@gmx.ch>
Message-ID: <YhYPJYcd+UrCVi9L@ikki.ethgen.ch>

Am Di den 22. Feb 2022 um 17:28 schrieb Fourhundred Thecat via Gnupg-users:
> the GUI pinentry dialog pops up to ask for password (I guess its
> pinentry-gtk-2)
> 
> How can I confugure so that the ncurses (text based) dialog is used
> instead ?

You should be able to call it this way:
   env -u DISPLAY gpg -c foo

Regards
   Klaus
-- 
Klaus Ethgen                                       http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16            Klaus Ethgen <Klaus at Ethgen.ch>
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 688 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20220223/fabac0d0/attachment-0001.sig>

From 400thecat at gmx.ch  Wed Feb 23 11:51:15 2022
From: 400thecat at gmx.ch (Fourhundred Thecat)
Date: Wed, 23 Feb 2022 11:51:15 +0100
Subject: use text pinentry in the console
In-Reply-To: <YhYPJYcd+UrCVi9L@ikki.ethgen.ch>
References: <c92532ff-d666-3f42-40fe-15ef2cf7d146@gmx.ch>
 <YhYPJYcd+UrCVi9L@ikki.ethgen.ch>
Message-ID: <5c881140-f950-73f3-1632-75b3421a41a3@gmx.ch>

 > On 2022-02-23 11:40, Klaus Ethgen wrote:
> Am Di den 22. Feb 2022 um 17:28 schrieb Fourhundred Thecat via Gnupg-users:
>>
>> How can I confugure so that the ncurses (text based) dialog is used
>> instead ?
>
> You should be able to call it this way:
>     env -u DISPLAY gpg -c foo

that works!

thank you



From bernhard at intevation.de  Thu Feb 24 10:36:35 2022
From: bernhard at intevation.de (Bernhard Reiter)
Date: Thu, 24 Feb 2022 10:36:35 +0100
Subject: TB weirdness
In-Reply-To: <22041840-a9a7-e045-fc55-50e0ef9304ba@sixdemonbag.org>
References: <22041840-a9a7-e045-fc55-50e0ef9304ba@sixdemonbag.org>
Message-ID: <202202241036.35854.bernhard@intevation.de>

Am Donnerstag 17 Februar 2022 17:35:53 schrieb Robert J. Hansen via 
Gnupg-users:
> Thunderbird doesn't use GnuPG. 

For some operations it still can (be configured to do so).
Anyway, we do have a wiki page for hints
  
https://wiki.gnupg.org/EMailClients/Thunderbird

> However, for those who do: 
> apparently, Thunderbird is a big fan of attaching public certificates
> (and/or revocation certificates, for revoked keys) to outgoing emails
> for *every private certificate on your keyring*, regardless of whether
> that private key is actually associated with the account in question.
>
> This has the potential to leak personal information, especially if
> you're in a use case where you have two or more keys presenting
> different pseudonymous identities.  Without knowing it, you might
> accidentally reveal you're the common actor behind both.

Sounds like a defect to me, do you have a problem report ticket with 
Thunderbird or a forum entry which described the problem in more detail
(like which version is affected).

Overall I believe that attaching pubkeys (like autocrypt proposes) is not a 
good idea (the arguments put forward elsewhere).

Thanks for your warning, what about if we put it on our wiki page?

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20220224/97d73f55/attachment.sig>

From bernhard at intevation.de  Thu Feb 24 10:42:14 2022
From: bernhard at intevation.de (Bernhard Reiter)
Date: Thu, 24 Feb 2022 10:42:14 +0100
Subject: PGP is a proprietary Broadcom product (Was: Can't synchronize keys
 using Seahorse)
In-Reply-To: <09d2252a-24e6-c200-f0bb-3ed2fa3eb875@sixdemonbag.org>
References: <556199605.3244964.1645110554664.ref@mail.yahoo.com>
 <556199605.3244964.1645110554664@mail.yahoo.com>
 <09d2252a-24e6-c200-f0bb-3ed2fa3eb875@sixdemonbag.org>
Message-ID: <202202241042.15421.bernhard@intevation.de>

Am Donnerstag 17 Februar 2022 17:18:58 schrieb Robert J. Hansen via 
Gnupg-users:

> or whichever corporate entity owned the PGP intellectual property at the
> time.  Network Associates gave way to PGP Security gave way to Symantec
> gave way to...

As far as I know, it is Broadcom since a few years
https://techdocs.broadcom.com/us/en/symantec-security-software/information-security/pgp-solutions/1-0.html

A reminder again to use "OpenPGP" when refering to the open crypto standard.

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20220224/46a3e027/attachment.sig>

From bernhard at intevation.de  Thu Feb 24 10:56:33 2022
From: bernhard at intevation.de (Bernhard Reiter)
Date: Thu, 24 Feb 2022 10:56:33 +0100
Subject: Who protects the private key (was: Changing the encryption
 algorithm used for PGP/GPG private key)
In-Reply-To: <887108780.4446.1645345836360@upanova.co-bxl>
References: <875ypa29n8.fsf_-_@wheatstone.g10code.de>
 <6211A274.8000004@gmail.com> <887108780.4446.1645345836360@upanova.co-bxl>
Message-ID: <202202241056.42031.bernhard@intevation.de>

Am Sonntag 20 Februar 2022 09:30:36 schrieb Daniel Colquitt via Gnupg-users:
> I agree with you, and Robert Hansen above, insofar as there is no practical
> weakness in using SHA-1 as part of a key derivation algorithm. 

(for protecting exported private keys)

> Nevertheless it does seem imprudent to use a formally broken hash function
> by default, whilst silently ignoring options that users would reasonably
> expect to change the algorithms used.

The point, as I understand it, is compatibility.
Exporting and importing a private OpenPGP key is expected to work for many 
implementations and over several software revisions and years. So adhereing 
to a standard (OpenPGP in this case) seems a good choice.

You can use additional protection layers, as Werner suggested.
This seems also reasonable from a usability point of view as exporting,
transfering and importing of private OpenPGP keys is a rare process.

Best 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20220224/7be0d5a4/attachment.sig>

From look at my.amazin.horse  Thu Feb 24 13:27:08 2022
From: look at my.amazin.horse (Vincent Breitmoser)
Date: Thu, 24 Feb 2022 13:27:08 +0100
Subject: TB weirdness
In-Reply-To: <202202241036.35854.bernhard@intevation.de>
References: <202202241036.35854.bernhard@intevation.de>
 <22041840-a9a7-e045-fc55-50e0ef9304ba@sixdemonbag.org>
Message-ID: <22ZYAIW3LHGL1.2WGOF4TSRXP65@my.amazin.horse>


> Overall I believe that attaching pubkeys (like autocrypt proposes) is not a 
> good idea (the arguments put forward elsewhere).

For the record, Autocrypt does not attach public keys, it includes them in
headers. I concur that attaching public keys is a bad idea.

> apparently, Thunderbird is a big fan of attaching public certificates
> (and/or revocation certificates, for revoked keys) to outgoing emails
> for *every private certificate on your keyring*, regardless of whether
> that private key is actually associated with the account in question.

I haven't tested this myself but from a quick check with someone who uses
Thunderbird they couldn't verify this claim. Maybe this just happens on some
versions? Either way I wouldn't assume it's intended behavior.

 - V


From bernhard at intevation.de  Thu Feb 24 17:08:49 2022
From: bernhard at intevation.de (Bernhard Reiter)
Date: Thu, 24 Feb 2022 17:08:49 +0100
Subject: TB weirdness
In-Reply-To: <22ZYAIW3LHGL1.2WGOF4TSRXP65@my.amazin.horse>
References: <202202241036.35854.bernhard@intevation.de>
 <22041840-a9a7-e045-fc55-50e0ef9304ba@sixdemonbag.org>
 <22ZYAIW3LHGL1.2WGOF4TSRXP65@my.amazin.horse>
Message-ID: <202202241708.56771.bernhard@intevation.de>

Hi Vincent,

Am Donnerstag 24 Februar 2022 13:27:08 schrieb Vincent Breitmoser via 
Gnupg-users:
> > Overall I believe that attaching pubkeys (like autocrypt proposes) is not
> > a good idea (the arguments put forward elsewhere).
>
> For the record, Autocrypt does not attach public keys, it includes them in
> headers. 

Thanks for the correction.

> I concur that attaching public keys is a bad idea. 

I've meant that conveying the pubkey with each email is suboptimal,
may it be in the header, as attachment or elsewhere. This is what autocrypt
does if I remember correctly.

> I haven't tested this myself but from a quick check with someone who uses
> Thunderbird they couldn't verify this claim. Maybe this just happens on
> some versions? Either way I wouldn't assume it's intended behavior.

This is helpful information, I agree that we should have more specific
information because we can "warn" about the behaviour.
Do you know which version was tested by chance?

Best 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20220224/3d8a1ae6/attachment-0001.sig>

From rjh at sixdemonbag.org  Thu Feb 24 17:59:31 2022
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Thu, 24 Feb 2022 11:59:31 -0500
Subject: TB weirdness
In-Reply-To: <202202241036.35854.bernhard@intevation.de>
References: <22041840-a9a7-e045-fc55-50e0ef9304ba@sixdemonbag.org>
 <202202241036.35854.bernhard@intevation.de>
Message-ID: <6688bb25-1d80-9a14-e47b-47041ccc8518@sixdemonbag.org>

> Sounds like a defect to me, do you have a problem report ticket with
> Thunderbird or a forum entry which described the problem in more detail
> (like which version is affected).

It turns out the actual behavior is a little different than I originally 
described.  If you have a valid certificate with a given email address, 
and a revoked certificate (or certificates) with that same email 
address, it will silently add the revoked certificates, as well as the 
valid one, to your email.  This is still a bad idea.

On the other hand, Thunderbird now says it's a deliberate choice on 
their part, so...


From andrewg at andrewg.com  Thu Feb 24 18:27:22 2022
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Thu, 24 Feb 2022 17:27:22 +0000
Subject: TB weirdness
In-Reply-To: <6688bb25-1d80-9a14-e47b-47041ccc8518@sixdemonbag.org>
References: <22041840-a9a7-e045-fc55-50e0ef9304ba@sixdemonbag.org>
 <202202241036.35854.bernhard@intevation.de>
 <6688bb25-1d80-9a14-e47b-47041ccc8518@sixdemonbag.org>
Message-ID: <010e1288-ff61-671b-4564-4de0d5443b16@andrewg.com>

On 24/02/2022 16:59, Robert J. Hansen via Gnupg-users wrote:
>> Sounds like a defect to me, do you have a problem report ticket with
>> Thunderbird or a forum entry which described the problem in more detail
>> (like which version is affected).
> 
> It turns out the actual behavior is a little different than I originally 
> described.? If you have a valid certificate with a given email address, 
> and a revoked certificate (or certificates) with that same email 
> address, it will silently add the revoked certificates, as well as the 
> valid one, to your email.? This is still a bad idea.

I can confirm this happened to me when I specifically ticked "Attach my 
public key" in TB's composer - it also attached the revocation cert for 
an ancient key that I still have in my keyring but never used for anything.

-- 
Andrew Gallagher

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20220224/9db5169e/attachment.sig>

From m.mansfeld at mansfeld-elektronik.de  Thu Feb 24 19:14:50 2022
From: m.mansfeld at mansfeld-elektronik.de (Mansfeld Elektronik)
Date: Thu, 24 Feb 2022 19:14:50 +0100
Subject: TB weirdness
In-Reply-To: <6688bb25-1d80-9a14-e47b-47041ccc8518@sixdemonbag.org>
References: <22041840-a9a7-e045-fc55-50e0ef9304ba@sixdemonbag.org>
 <202202241036.35854.bernhard@intevation.de>
 <6688bb25-1d80-9a14-e47b-47041ccc8518@sixdemonbag.org>
Message-ID: <b45480bc55d6dd12911fa154199ae7c0@mansfeld-elektronik.de>

Am 24.02.2022 17:59, schrieb Robert J. Hansen via Gnupg-users:
>> Sounds like a defect to me, do you have a problem report ticket with
>> Thunderbird or a forum entry which described the problem in more 
>> detail
>> (like which version is affected).
> 
> It turns out the actual behavior is a little different than I
> originally described.  If you have a valid certificate with a given
> email address, and a revoked certificate (or certificates) with that
> same email address, it will silently add the revoked certificates, as
> well as the valid one, to your email.  This is still a bad idea.
> 
> On the other hand, Thunderbird now says it's a deliberate choice on
> their part, so...

In one word: broken by design..... :-(



From petroh at safe-mail.net  Thu Feb 24 17:15:24 2022
From: petroh at safe-mail.net (PetRoh)
Date: Thu, 24 Feb 2022 09:15:24 -0700
Subject: Suggestions to Thunderbird users
In-Reply-To: <22ZYAIW3LHGL1.2WGOF4TSRXP65@my.amazin.horse>
References: <202202241036.35854.bernhard@intevation.de>
 <22041840-a9a7-e045-fc55-50e0ef9304ba@sixdemonbag.org>
 <22ZYAIW3LHGL1.2WGOF4TSRXP65@my.amazin.horse>
Message-ID: <3aed9007-d11d-dd01-4be8-dd14b4c9b215@safe-mail.net>

> I haven't tested this myself but from a quick check with someone who uses
> Thunderbird they couldn't verify this claim. Maybe this just happens on some
> versions? Either way I wouldn't assume it's intended behavior.

Other than an annoying inability to turn off "by default"
attachment of public key and signing each encrypted message,
I did not notice this behaviour.

Thunderbird is by far the best openPGP cross-platform
mail-client application around. However, my suggestion to
Thunderbird mail encryption users is to avoid any
"gnupg integration". In particular:

- If you really need to import some gnupg generated keys into
   Thunderbird, clean them of any WOT crud first and treat that
   as a one-way, one-time copy/transfer. Much better approach
   is to consider the public/private key pair as an e-mail
   address/application specific item, generated directly in,
   and used only by Thunderbird.

- Devise you own method of getting public keys into the hands of
   your correspondents and of their authentication and termination.

- Even if you use a mail attachment to initially send public key
   to a correspondent, remember to turn off default "attach key"
   for all subsequent messages. Likewise, do not sign messages by
   default, but only when there is a good reason to do so.

- If at all possible, do not depend on Thunderbird to protect
   your private key; instead, place your complete mail profile
   directory hierarchy in an encrypted container.

With the above, and due to its popularity, Thunderbird has a
reasonable chance to increase that minuscule fraction of
encrypted e-mails.





From naicamine at sl4mm3r5.com  Fri Feb 25 01:04:20 2022
From: naicamine at sl4mm3r5.com (naicam|ne)
Date: Fri, 25 Feb 2022 00:04:20 +0000
Subject: TB weirdness
In-Reply-To: <22041840-a9a7-e045-fc55-50e0ef9304ba@sixdemonbag.org>
References: <22041840-a9a7-e045-fc55-50e0ef9304ba@sixdemonbag.org>
Message-ID: <3fbda2a4-4448-8688-0e02-ba20a905e791@sl4mm3r5.com>

When I want to sign or encrypt a message, I am still a fan of writing it 
out and performing these actions from within gpa, and then cutting and 
pasting the encrypted text into my messages.

Any other method leaves you to trust third parties to handle your keys 
responsibly which has been proven time and again unreliable, as is being 
pointed out here.

No, it doesn't encrypt MIME data or attachments, and I feel like that is 
desirable. I don't personally want my MIME data or signature to be 
encrypted. They are predictable anyway and that is a major liability. 
You can encrypt your attachments independently.

Unfortunately, Thunderbird has for a while now flagged "inline 
encryption" as of questionable integrity, partly since the MIME data 
isn't verifiable.

-- 
__ _ ____ _ ____ ____ _  _ _ __ _ ____
| \| |--| | |___ |--| |\/| | | \| |===