From spam.trap.mailing.lists at gmail.com  Sun Nov  1 00:45:32 2020
From: spam.trap.mailing.lists at gmail.com (Stefan Claas)
Date: Sat, 31 Oct 2020 23:45:32 +0000
Subject: ping - Governikus
In-Reply-To: <5ACDAF2A-02CE-4337-852C-DDCFA76D9793@andrewg.com>
References: <CAC6FiZ7EkFWsfXzxxtjo3qZ6tDJEkXeLFAqAzpZpAMy2+3G+Qg@mail.gmail.com>
 <5ACDAF2A-02CE-4337-852C-DDCFA76D9793@andrewg.com>
Message-ID: <CAC6FiZ7wqjmpr5zpQ8TqXYpgBk2=kKh+eaOLe0f=q77wrY2J+g@mail.gmail.com>

It is required and also automatically checked that my name 'Stefan Claas'
in the UID matches the name in my ID-card. If I would enter in my pub key
for example 'Paul Claas' or 'Stefan Class' as UID then my pub key would
not be signed. They use the email address IMHO only to submit your
certified pub key to your email account.

I am aware that there is a second 'Stefan Claas' living in Germany
but he would not have the same fingerprint as I would have. In case
of doubt people could always prove to third parties, if requested,
that one is the actual key holder, with a simple challenge/response.

Regards
Stefan

On Sat, Oct 31, 2020 at 10:31 PM Andrew Gallagher <andrewg at andrewg.com> wrote:
>
>
> > On 31 Oct 2020, at 18:46, Stefan Claas via Gnupg-users <gnupg-users at gnupg.org> wrote:
> >
> > I would like to make the following proposal that users using
> > your certification service have the ability to upload pub keys
> > for signing, which do not require an email address in the UID
> > and that such public keys can be mailed on digital media
> > to the (in a provided submission form) postal address.
>
> What is governikus certifying if there?s nothing identifiable in the user id? What use is it to a third party to see such a signature on a key?
>
> A
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users


From andrewg at andrewg.com  Mon Nov  2 13:06:15 2020
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Mon, 2 Nov 2020 12:06:15 +0000
Subject: ping - Governikus
In-Reply-To: <CAC6FiZ7wqjmpr5zpQ8TqXYpgBk2=kKh+eaOLe0f=q77wrY2J+g@mail.gmail.com>
References: <CAC6FiZ7EkFWsfXzxxtjo3qZ6tDJEkXeLFAqAzpZpAMy2+3G+Qg@mail.gmail.com>
 <5ACDAF2A-02CE-4337-852C-DDCFA76D9793@andrewg.com>
 <CAC6FiZ7wqjmpr5zpQ8TqXYpgBk2=kKh+eaOLe0f=q77wrY2J+g@mail.gmail.com>
Message-ID: <c5a35386-fcd1-41f8-e72e-b3b3d67578a4@andrewg.com>

On 31/10/2020 23:45, Stefan Claas wrote:
> I am aware that there is a second 'Stefan Claas' living in Germany
> but he would not have the same fingerprint as I would have. In case
> of doubt people could always prove to third parties, if requested,
> that one is the actual key holder, with a simple challenge/response.

This may be an acceptable edge case for one Stefan Claas, but maybe not
for Stefan M?ller or Stefan Schmidt. Or even the other Stefan Claas, who
may not appreciate you being able to more easily impersonate him. :-)

If Governikus (or anyone else for that matter) were to start certifying
ambiguous identities, it would devalue their name across the board. Why
would they do that?

-- 
Andrew Gallagher

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

From wk at gnupg.org  Mon Nov  2 13:49:36 2020
From: wk at gnupg.org (Werner Koch)
Date: Mon, 02 Nov 2020 13:49:36 +0100
Subject: Avoid recipient-compatibility SHA1
In-Reply-To: <20201030041054.GA959448@fullerene.field.pennock-tech.net> (Phil
 Pennock via Gnupg-users's message of "Fri, 30 Oct 2020 00:10:54
 -0400")
References: <20201030041054.GA959448@fullerene.field.pennock-tech.net>
Message-ID: <874km7vs7z.fsf@wheatstone.g10code.de>

On Fri, 30 Oct 2020 00:10, Phil Pennock said:

> I just sent a message to N recipients, and I think one of them probably
> has some preference algorithm in their key details, because this one
> mail was signed using SHA1, not my defaults.

Fixed:

commit 15746d60d492f5792e4a179ab0a08801b4049695 
Author: Werner Koch <wk at gnupg.org>
Date:   Mon Nov 2 13:39:58 2020 +0100

    gpg: Do not use weak digest algos if selected by recipient prefs.
    
    * g10/misc.c (is_weak_digest): New.
    (print_digest_algo_note): Use it here.
    * g10/sig-check.c (check_signature_end_simple): Use it.
    * g10/sign.c (hash_for): Do not use recipient_digest_algo if it is in
    the least of weak digest algorithm.
    --
    
    If a message is signed and encrypted to several recipients, the to be
    used digest algorithm is deduced from the preferences of the
    recipient.  This is so that all recipients are able to check the the
    signature.  However, if the sender has a declared an algorithm as
    week, that algorithm shall not be used - in this case we fallback to
    the standard way of selecting an algorithm.
    
    Note that a smarter way of selecting the algo is to check this while
    figuring out the algorithm - this needs more testing and thus we do it
    the simple way.

or in short if any of the preferences would lead to a weak algo the
feature of selecting the digest algo from the preferences is disabled.

I intend to put this also in to 2.2.24.

> recipient.  That's fine.  I'd rather create pressure for people to fix
> their systems to use modern cryptography than cater to their brokenness
> with sensitive messages.

People won't update their keys - that just does not work.  Ignoring the
preferences is a better way here.


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/20201102/733ea0c5/attachment.sig>

From gnupg-users at spodhuis.org  Mon Nov  2 14:15:32 2020
From: gnupg-users at spodhuis.org (Phil Pennock)
Date: Mon, 2 Nov 2020 08:15:32 -0500
Subject: Avoid recipient-compatibility SHA1
In-Reply-To: <874km7vs7z.fsf@wheatstone.g10code.de>
References: <20201030041054.GA959448@fullerene.field.pennock-tech.net>
 <874km7vs7z.fsf@wheatstone.g10code.de>
Message-ID: <20201102131532.GA1475874@fullerene.field.pennock-tech.net>

On 2020-11-02 at 13:49 +0100, Werner Koch via Gnupg-users wrote:
> On Fri, 30 Oct 2020 00:10, Phil Pennock said:
> > recipient.  That's fine.  I'd rather create pressure for people to fix
> > their systems to use modern cryptography than cater to their brokenness
> > with sensitive messages.
> 
> People won't update their keys - that just does not work.  Ignoring the
> preferences is a better way here.

First: thank you for the code changes!

As to the people part: for a generic call to action, you're right.  But
that's not the social dynamic in play here.

For a specific set of people who know each other, trying to communicate
securely, if someone says "hey your key is too broken to use, please fix
it, here's a command to run (which you should check for yourself),
please do so and send us your new public key" ... then that works.

In the generic case, there's a hypothetical reward requiring work now.
In the specific case, it's a case of "you're getting cut out of this
ongoing conversation which presumably matters to you, do this now to get
back in".  If the conversation really does matter to that person, then
they will fix their key.  I have gotten people to fix various problems
on exactly this basis.

For everyone I am not talking to?  Not my business, not my problem.
I can only issue advice and shrug when people ignore it.

Now I just need a sane way to figure out which key caused this.  :)

Thanks,
-Phil


From spam.trap.mailing.lists at gmail.com  Mon Nov  2 20:12:21 2020
From: spam.trap.mailing.lists at gmail.com (Stefan Claas)
Date: Mon, 2 Nov 2020 19:12:21 +0000
Subject: ping - Governikus
In-Reply-To: <c5a35386-fcd1-41f8-e72e-b3b3d67578a4@andrewg.com>
References: <CAC6FiZ7EkFWsfXzxxtjo3qZ6tDJEkXeLFAqAzpZpAMy2+3G+Qg@mail.gmail.com>
 <5ACDAF2A-02CE-4337-852C-DDCFA76D9793@andrewg.com>
 <CAC6FiZ7wqjmpr5zpQ8TqXYpgBk2=kKh+eaOLe0f=q77wrY2J+g@mail.gmail.com>
 <c5a35386-fcd1-41f8-e72e-b3b3d67578a4@andrewg.com>
Message-ID: <CAC6FiZ5sDWDozLM4YQa3e1YK87ySCjvgy81J=JzH9yJXoN-aNg@mail.gmail.com>

On Mon, Nov 2, 2020 at 12:10 PM Andrew Gallagher <andrewg at andrewg.com> wrote:
>
> On 31/10/2020 23:45, Stefan Claas wrote:
> > I am aware that there is a second 'Stefan Claas' living in Germany
> > but he would not have the same fingerprint as I would have. In case
> > of doubt people could always prove to third parties, if requested,
> > that one is the actual key holder, with a simple challenge/response.
>
> This may be an acceptable edge case for one Stefan Claas, but maybe not
> for Stefan M?ller or Stefan Schmidt. Or even the other Stefan Claas, who
> may not appreciate you being able to more easily impersonate him. :-)
>
> If Governikus (or anyone else for that matter) were to start certifying
> ambiguous identities, it would devalue their name across the board. Why
> would they do that?

You are correct, they would not do that. While I thought also about
the possibility that here in Germany are for example thousands of
M?ller or Meier etc. I could imagine that not only two of them bear
the same first name. It would be interesting to get hold of them and
then convince them to use a shared email account, while everybody
of them would then have to generate their own key pair and then
let it sign by Governikus.

I think a solution to this problem could be PBKDF2 hashed data
in the UID, but developing an OpenPGP certifying workflow could
be a bit tricky.

https://www.freecodeformat.com/pbkdf2.php

Regards
Stefan


From spam.trap.mailing.lists at gmail.com  Mon Nov  2 20:53:55 2020
From: spam.trap.mailing.lists at gmail.com (Stefan Claas)
Date: Mon, 2 Nov 2020 19:53:55 +0000
Subject: ping - Governikus
In-Reply-To: <CAC6FiZ5sDWDozLM4YQa3e1YK87ySCjvgy81J=JzH9yJXoN-aNg@mail.gmail.com>
References: <CAC6FiZ7EkFWsfXzxxtjo3qZ6tDJEkXeLFAqAzpZpAMy2+3G+Qg@mail.gmail.com>
 <5ACDAF2A-02CE-4337-852C-DDCFA76D9793@andrewg.com>
 <CAC6FiZ7wqjmpr5zpQ8TqXYpgBk2=kKh+eaOLe0f=q77wrY2J+g@mail.gmail.com>
 <c5a35386-fcd1-41f8-e72e-b3b3d67578a4@andrewg.com>
 <CAC6FiZ5sDWDozLM4YQa3e1YK87ySCjvgy81J=JzH9yJXoN-aNg@mail.gmail.com>
Message-ID: <CAC6FiZ4wAy-ojqCM9Vdcu=ncqBMP7+M2bY5PphjfroWaX=kpJg@mail.gmail.com>

On Mon, Nov 2, 2020 at 7:12 PM Stefan Claas
<spam.trap.mailing.lists at gmail.com> wrote:

> I think a solution to this problem could be PBKDF2 hashed data
> in the UID, but developing an OpenPGP certifying workflow could
> be a bit tricky.
>
> https://www.freecodeformat.com/pbkdf2.php

To be more precise, the name 'Stefan Claas' would be still readable in the
UID but the additional hashed data would be displayed as a hash, like in
the code example and it would have hashed additional data from my ID-card.

Because the other Stefan Claas would not have the same hash string in the
UID this could be a working solution.

Regards
Stefan


From andrewg at andrewg.com  Tue Nov  3 01:06:38 2020
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Tue, 3 Nov 2020 00:06:38 +0000
Subject: ping - Governikus
In-Reply-To: <CAC6FiZ4wAy-ojqCM9Vdcu=ncqBMP7+M2bY5PphjfroWaX=kpJg@mail.gmail.com>
References: <CAC6FiZ4wAy-ojqCM9Vdcu=ncqBMP7+M2bY5PphjfroWaX=kpJg@mail.gmail.com>
Message-ID: <241B6B17-A294-4DCE-8F81-CABCCF661C4C@andrewg.com>


> On 2 Nov 2020, at 19:55, Stefan Claas <spam.trap.mailing.lists at gmail.com> wrote:
> 
> ?On Mon, Nov 2, 2020 at 7:12 PM Stefan Claas
> <spam.trap.mailing.lists at gmail.com> wrote:
> 
>> I think a solution to this problem could be PBKDF2 hashed data
>> in the UID, but developing an OpenPGP certifying workflow could
>> be a bit tricky.
>> 
>> https://www.freecodeformat.com/pbkdf2.php
> 
> To be more precise, the name 'Stefan Claas' would be still readable in the
> UID but the additional hashed data would be displayed as a hash, like in
> the code example and it would have hashed additional data from my ID-card.
> 
> Because the other Stefan Claas would not have the same hash string in the
> UID this could be a working solution.

Aha, so what you?re looking for is a signature over a nonced, hashed ID but without the plaintext ID being attached - in which case do you even need the plaintext ?real name? at all? After all, if there are only two Stefan Claases in Germany you?ve already leaked far too much information for the subterfuge to be worth the effort. What?s the use case?

A



From spam.trap.mailing.lists at gmail.com  Tue Nov  3 17:44:08 2020
From: spam.trap.mailing.lists at gmail.com (Stefan Claas)
Date: Tue, 3 Nov 2020 16:44:08 +0000
Subject: ping - Governikus
In-Reply-To: <241B6B17-A294-4DCE-8F81-CABCCF661C4C@andrewg.com>
References: <CAC6FiZ4wAy-ojqCM9Vdcu=ncqBMP7+M2bY5PphjfroWaX=kpJg@mail.gmail.com>
 <241B6B17-A294-4DCE-8F81-CABCCF661C4C@andrewg.com>
Message-ID: <CAC6FiZ6MWmpKV-YXiJv=9ofR0rgUDjHCWotF9uXvCZQzuLa+1A@mail.gmail.com>

On Tue, Nov 3, 2020 at 12:10 AM Andrew Gallagher <andrewg at andrewg.com> wrote:
>
>
> > On 2 Nov 2020, at 19:55, Stefan Claas <spam.trap.mailing.lists at gmail.com> wrote:
> >
> > ?On Mon, Nov 2, 2020 at 7:12 PM Stefan Claas
> > <spam.trap.mailing.lists at gmail.com> wrote:
> >
> >> I think a solution to this problem could be PBKDF2 hashed data
> >> in the UID, but developing an OpenPGP certifying workflow could
> >> be a bit tricky.
> >>
> >> https://www.freecodeformat.com/pbkdf2.php
> >
> > To be more precise, the name 'Stefan Claas' would be still readable in the
> > UID but the additional hashed data would be displayed as a hash, like in
> > the code example and it would have hashed additional data from my ID-card.
> >
> > Because the other Stefan Claas would not have the same hash string in the
> > UID this could be a working solution.
>
> Aha, so what you?re looking for is a signature over a nonced, hashed ID but without the       plaintext ID being attached - in which case do you even need the plaintext ?real name? at all? After all, if there are only two Stefan Claases in Germany you?ve already leaked far too much information for the subterfuge to be worth the effort. What?s the use case?

As we know OpenPGP compatible public key cryptography usually requires
a UID, whether
the ones we are used to or a freeform UID. My goal is to have a CA
certified pubkey with
only one UID and without an email address, so that the key pair can be
universally been
used, besides classic email, ie. Fax, Telephone, Radio, Blog post
discussions, Bitmessage, File Transfer, Postcards, Letters, Social
Media chats, Messengers and what not which all do not require an email
address. In case of email it should be possible to use it for multiple
email accounts or if email accounts change, to not edit the key or
create a new key. Simply said, a certified multipurpose OpenPGP key
for long term usage.

Why the included Name and hash string? GnuPG users, I assume, are used
to public keys including a name in the UID, for their keyring
management and selecting keys with
their MUA/NUA plug-ins.

Since we mentioned that it can happen that many people bear the same
name I thought/think
it could be useful for certifying purposes that an additional hash
string, composed from additional  ID-card data, which can't be easily
reversed, would be useful.

Let's assume the following ... In case gnupg.com would expand their
business and would also
run a CA, I could simply send them per postal mail a CD, containing my
pub key, with my
name and the hash string and a photo of my ID-card. They simply could
then compare the
name on the key and photo plus in case of many Stefan Claases they
could also verify the
hash string by rehashing the data which I hashed from my ID-card, thus
guaranteeing to third parties with their CA sig. that this universal
public key, without an email address, belongs to
me and not the other Stefan Claas. In case this would be not enough
proof for the CA I could include on the CD an additional eIDAS signed
.pdf document, including the fingerprint of my pub  key.

I also think that maybe many people would like to have a CA certified
universal OpenPGP public key, without an email address.

Regards
Stefan


From oz.tiram at gmail.com  Tue Nov  3 22:28:28 2020
From: oz.tiram at gmail.com (Oz Tiram)
Date: Tue, 3 Nov 2020 22:28:28 +0100
Subject: GPG agent forward on Debian: setting pinentry mode 'loopback' failed:
 Forbidden
Message-ID: <CADKMUw=6=mCrLNy5ebccVwwHzM3WdZXsWPQzTmf0vzWARvJT3Q@mail.gmail.com>

Apologies, I accidentally posted the complete SO question in my previous
email.
That was not my intention. I hope I can still find some answers with the
help from subscribers of this list.

Best wishes
Oz

-- 


---

Imagine there's no countries
it isn't hard to do
Nothing to kill or die for
And no religion too
Imagine all the people
Living life in peace
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20201103/3fdb8ae5/attachment.html>

From oz.tiram at gmail.com  Tue Nov  3 21:29:23 2020
From: oz.tiram at gmail.com (Oz Tiram)
Date: Tue, 3 Nov 2020 21:29:23 +0100
Subject: GPG agent forward on Debian: setting pinentry mode 'loopback' failed:
 Forbidden
Message-ID: <CADKMUw=UNmKWUSbR+V1Lv+6A2EyZYB=2w+7ttkTGgr96ajznfA@mail.gmail.com>

Hi,

I spend quite sometime trying to set up gpg agent forwarding between two
machines (running debian).
But I can't get this work with the instructions from the gpg wiki.
My ssh config:

Host debian-remote
    Hostname 192.168.122.72
    RemoteForward /run/user/1000/gnupg/S.gpg-agent
/run/user/1000/gnupg/S.gpg-agent.extra
    ExitOnForwardFailure yes


$ ssh -v -A debian-remote
...
debug1: Remote connections from /run/user/1000/gnupg/S.gpg-agent:-2
forwarded to local address /run/user/1000/gnupg/S.gpg-agent.extra:-2
debug1: ssh_init_forwarding: expecting replies for 1 forwards
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions at openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype hostkeys-00 at openssh.com want_reply 0
debug1: Remote: /home/debian/.ssh/authorized_keys:1: key options:
agent-forwarding port-forwarding pty user-rc x11-forwarding
debug1: Remote: /home/debian/.ssh/authorized_keys:1: key options:
agent-forwarding port-forwarding pty user-rc x11-forwarding
debug1: remote forward success for: listen
/run/user/1000/gnupg/S.gpg-agent:-2, connect
/run/user/1000/gnupg/S.gpg-agent.extra:-2
debug1: forwarding_success: all expected forwarding replies received
debug1: Requesting authentication agent forwarding.
...
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Tue Nov  3 18:45:13 2020 from 192.168.122.202
$

Looks OK, so far.

*Closed.* This question does not meet Stack Overflow guidelines
<https://stackoverflow.com/help/closed-questions>. It is not currently
accepting answers.
------------------------------

We don?t allow questions about general computing hardware and software on
Stack Overflow. You can edit the question so it?s on-topic
<https://stackoverflow.com/help/on-topic> for Stack Overflow or post a new
one on Super User <https://superuser.com/help/on-topic>.

Closed 15 mins ago.

(Private feedback for you)
Background

I spent quite some time trying to solve this problem without success. I
have 2 Debian testing machine with GPG version:

~$ gpg --version
gpg (GnuPG) 2.2.20
libgcrypt 1.8.6

GPG agent should be forwarded from one machine (local) to the other
(remote). On the local machine, I have the following settings:

~$ cat .gnupg/gpg.conf
use-agent
pinentry-mode loopback
~$ cat .gnupg/gpg-agent.conf
pinentry-program /usr/bin/pinentry
no-grab
default-cache-ttl 1800
enable-ssh-support
allow-loopback-pinentry

And also:

Host debian-remote
    Hostname 192.168.122.72
    RemoteForward /run/user/1000/gnupg/S.gpg-agent
/run/user/1000/gnupg/S.gpg-agent.extra
    ExitOnForwardFailure yes

On the remote machine:

I set in /etc/ssh/sshd_config:

StreamLocalBindUnlink yes

I copied over pubring.kbx with:

scp .gnupg/pubring.kbx 192.168.122.72:/home/debian/.gnupg/

Finally, I created an encrypted file with and copied it over:

$ echo TEST | gpg --encrypt -r myUserId > out
$ scp out debian-remote:~/out

When I ssh to remote machine, I see the following:

$ ssh -v -A debian-remote
...
debug1: Remote connections from /run/user/1000/gnupg/S.gpg-agent:-2
forwarded to local address /run/user/1000/gnupg/S.gpg-agent.extra:-2
debug1: ssh_init_forwarding: expecting replies for 1 forwards
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions at openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype hostkeys-00 at openssh.com want_reply 0
debug1: Remote: /home/debian/.ssh/authorized_keys:1: key options:
agent-forwarding port-forwarding pty user-rc x11-forwarding
debug1: Remote: /home/debian/.ssh/authorized_keys:1: key options:
agent-forwarding port-forwarding pty user-rc x11-forwarding
debug1: remote forward success for: listen
/run/user/1000/gnupg/S.gpg-agent:-2, connect
/run/user/1000/gnupg/S.gpg-agent.extra:-2
debug1: forwarding_success: all expected forwarding replies received
debug1: Requesting authentication agent forwarding.
...
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Tue Nov  3 18:45:13 2020 from 192.168.122.202
$

Seems OK so far.

However, I can't decrypt secrets using this agent:

$ gpg --decrypt out
debug1: client_input_channel_open: ctype
forwarded-streamlocal at openssh.com rchan 3 win 2097152 max 32768
debug1: client_request_forwarded_streamlocal: request:
/run/user/1000/gnupg/S.gpg-agent
debug1: connect_next: host /run/user/1000/gnupg/S.gpg-agent.extra
([unix]:/run/user/1000/gnupg/S.gpg-agent.extra) in progress, fd=7
debug1: channel 1: new [forwarded-streamlocal]
debug1: confirm forwarded-streamlocal at openssh.com
debug1: channel 1: connected to /run/user/1000/gnupg/S.gpg-agent.extra port -2
gpg: encrypted with 2048-bit RSA key, ID 268570EF8062F280, created 2013-11-23
    ...
gpg: public key decryption failed: Inappropriate ioctl for device
gpg: decryption failed: No secret key


When I forward the regular socket with:

Host debian-remote
    Hostname 192.168.122.72
    RemoteForward /run/user/1000/gnupg/S.gpg-agent
/run/user/1000/gnupg/S.gpg-agent
    ExitOnForwardFailure yes


I can decrypt secrets as expected.

However, I guess I should not be doing that. Hence, I'm still struggling
what should be done to allow decrypting with GPG agents and extra socket on
the remote hosts.

Oddly, the above settings for gpg.conf and gpg-agent.conf are taken from
the first result on DDG
<https://d.sb/2016/11/gpg-inappropriate-ioctl-for-device-errors> for: gpg
Inappropriate ioctl for device, but I still get this error.
I would appreciate any help here.

Best regards,
Oz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20201103/ad651170/attachment.html>

From stakanov at disroot.org  Tue Nov  3 10:41:22 2020
From: stakanov at disroot.org (Stakanov)
Date: Tue, 03 Nov 2020 10:41:22 +0100
Subject: A question about the status of the keyserver structure
Message-ID: <8587313.y1p07l5mTE@roadrunner>

I hope this is the correct list for this question:

I tried to follow the instructions of 
https://www.mageia.org/it/downloads/get/?q=Mageia-7.1-x86_64.iso[1] 
were it says you can import the key to verify the iso.
But kleopatra stays without reaction (no matter how many pools I join) and 
entropia at roadrunner:~> gpg --keyserver pool.sks-keyservers.net --recv-keys 
EDCA7A90 


Now I remember time ago there was an issue of keyservers abused and the structure 
was halted. 

What is the current status and how can one download a signature as of today? 
Manually or with a "keyserverpage" on https or how does it work now?
Thank you in advance. 

--------
[1] https://www.mageia.org/it/downloads/get/?q=Mageia-7.1-x86_64.iso
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20201103/9d233d30/attachment.html>

From andrewg at andrewg.com  Wed Nov  4 11:32:01 2020
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Wed, 4 Nov 2020 10:32:01 +0000
Subject: GPG agent forward on Debian: setting pinentry mode 'loopback'
 failed: Forbidden
In-Reply-To: <CADKMUw=UNmKWUSbR+V1Lv+6A2EyZYB=2w+7ttkTGgr96ajznfA@mail.gmail.com>
References: <CADKMUw=UNmKWUSbR+V1Lv+6A2EyZYB=2w+7ttkTGgr96ajznfA@mail.gmail.com>
Message-ID: <3628b26a-6753-390e-9f6f-c2841951fc30@andrewg.com>

Hi, Oz.

Does /run/user/1000/gnupg/S.gpg-agent.extra exist on your local machine?
To make it exist I had to add `extra-socket` to my gpg-agent.conf (I'm
on gpg 2.2.12 from vanilla debian):

```
$ cat ~/.gnupg/gpg-agent.conf
enable-ssh-support
extra-socket /run/user/1000/gnupg/S.gpg-agent.extra
```

A.

On 03/11/2020 20:29, Oz Tiram via Gnupg-users wrote:
> ~$ cat .gnupg/gpg.conf 
> use-agent 
> pinentry-mode loopback
> ~$ cat .gnupg/gpg-agent.conf 
> pinentry-program /usr/bin/pinentry
> no-grab
> default-cache-ttl 1800
> enable-ssh-support
> allow-loopback-pinentry
>
> And also:
> 
> Host debian-remote
>     Hostname 192.168.122.72
>     RemoteForward /run/user/1000/gnupg/S.gpg-agent /run/user/1000/gnupg/S.gpg-agent.extra
>     ExitOnForwardFailure yes

-- 
Andrew Gallagher

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

From andrewg at andrewg.com  Wed Nov  4 12:38:46 2020
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Wed, 4 Nov 2020 11:38:46 +0000
Subject: ping - Governikus
In-Reply-To: <CAC6FiZ6MWmpKV-YXiJv=9ofR0rgUDjHCWotF9uXvCZQzuLa+1A@mail.gmail.com>
References: <CAC6FiZ4wAy-ojqCM9Vdcu=ncqBMP7+M2bY5PphjfroWaX=kpJg@mail.gmail.com>
 <241B6B17-A294-4DCE-8F81-CABCCF661C4C@andrewg.com>
 <CAC6FiZ6MWmpKV-YXiJv=9ofR0rgUDjHCWotF9uXvCZQzuLa+1A@mail.gmail.com>
Message-ID: <2cbc198c-f484-f05a-9eda-a8fed4f725cf@andrewg.com>

On 03/11/2020 16:44, Stefan Claas wrote:
> My goal is to have a CA
> certified pubkey with
> only one UID and without an email address, so that the key pair can be
> universally been
> used, besides classic email, ie. Fax, Telephone, Radio, Blog post
> discussions, Bitmessage, File Transfer, Postcards, Letters, Social
> Media chats, Messengers and what not which all do not require an email
> address. In case of email it should be possible to use it for multiple
> email accounts or if email accounts change, to not edit the key or
> create a new key.

OK, but what is the meaning of a certification in this context? Taking
just the email section of the above, if I want to send you an email, I
can either get the key from you by some private means, or I can look up
your key on e.g. a keyserver and check whether somebody I trust (e.g.
Governikus) has certified that your key is valid for your email address.

AIUI, you propose that Governikus certify that your key is valid for
someone called "Stefan Claas", that they know which one, but they won't
disclose that identity to me. How does that help me decide whether your
key is valid? If I have to perform a second (manual?) verification step
no matter what Governikus says, then it's a better use of my time to try
that method first, and Governikus's sig has added nothing of value.

The same argument can be repeated for the other communications methods
above. If third-party certifications are not sufficient in your security
model, then what's the point of them at all? Considering that the only
reason we use third-party sigs is to cover the cases where other,
stronger, verification schemes (physical meeting, phone calls etc.) are
inappropriate or inconvenient.

-- 
Andrew Gallagher

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

From spam.trap.mailing.lists at gmail.com  Wed Nov  4 16:33:28 2020
From: spam.trap.mailing.lists at gmail.com (Stefan Claas)
Date: Wed, 4 Nov 2020 15:33:28 +0000
Subject: ping - Governikus
In-Reply-To: <2cbc198c-f484-f05a-9eda-a8fed4f725cf@andrewg.com>
References: <CAC6FiZ4wAy-ojqCM9Vdcu=ncqBMP7+M2bY5PphjfroWaX=kpJg@mail.gmail.com>
 <241B6B17-A294-4DCE-8F81-CABCCF661C4C@andrewg.com>
 <CAC6FiZ6MWmpKV-YXiJv=9ofR0rgUDjHCWotF9uXvCZQzuLa+1A@mail.gmail.com>
 <2cbc198c-f484-f05a-9eda-a8fed4f725cf@andrewg.com>
Message-ID: <CAC6FiZ4Tdes7=rEL=LhsJLot9pifRqdp_9NYMPjRWvj0-LbbZQ@mail.gmail.com>

On Wed, Nov 4, 2020 at 11:42 AM Andrew Gallagher <andrewg at andrewg.com> wrote:
>
> On 03/11/2020 16:44, Stefan Claas wrote:
> > My goal is to have a CA
> > certified pubkey with
> > only one UID and without an email address, so that the key pair can be
> > universally been
> > used, besides classic email, ie. Fax, Telephone, Radio, Blog post
> > discussions, Bitmessage, File Transfer, Postcards, Letters, Social
> > Media chats, Messengers and what not which all do not require an email
> > address. In case of email it should be possible to use it for multiple
> > email accounts or if email accounts change, to not edit the key or
> > create a new key.
>
> OK, but what is the meaning of a certification in this context? Taking
> just the email section of the above, if I want to send you an email, I
> can either get the key from you by some private means, or I can look up
> your key on e.g. a keyserver and check whether somebody I trust (e.g.
> Governikus) has certified that your key is valid for your email address.
>
> AIUI, you propose that Governikus certify that your key is valid for
> someone called "Stefan Claas", that they know which one, but they won't
> disclose that identity to me. How does that help me decide whether your
> key is valid? If I have to perform a second (manual?) verification step
> no matter what Governikus says, then it's a better use of my time to try
> that method first, and Governikus's sig has added nothing of value.
>
> The same argument can be repeated for the other communications methods
> above. If third-party certifications are not sufficient in your security
> model, then what's the point of them at all? Considering that the only
> reason we use third-party sigs is to cover the cases where other,
> stronger, verification schemes (physical meeting, phone calls etc.) are
> inappropriate or inconvenient.

If people meet at a key signing party, or we both would meet in person, they/we
usually check the name of the key holder and compare it with ID-cards
and fingerprints
of the keys. The email address has no certification value, because in
case of a freeform
UID they/we would not refuse to sign a key, I strongly assume.

Regards
Stefan


From spam.trap.mailing.lists at gmail.com  Wed Nov  4 16:56:11 2020
From: spam.trap.mailing.lists at gmail.com (Stefan Claas)
Date: Wed, 4 Nov 2020 15:56:11 +0000
Subject: ping - Governikus
In-Reply-To: <CAC6FiZ4Tdes7=rEL=LhsJLot9pifRqdp_9NYMPjRWvj0-LbbZQ@mail.gmail.com>
References: <CAC6FiZ4wAy-ojqCM9Vdcu=ncqBMP7+M2bY5PphjfroWaX=kpJg@mail.gmail.com>
 <241B6B17-A294-4DCE-8F81-CABCCF661C4C@andrewg.com>
 <CAC6FiZ6MWmpKV-YXiJv=9ofR0rgUDjHCWotF9uXvCZQzuLa+1A@mail.gmail.com>
 <2cbc198c-f484-f05a-9eda-a8fed4f725cf@andrewg.com>
 <CAC6FiZ4Tdes7=rEL=LhsJLot9pifRqdp_9NYMPjRWvj0-LbbZQ@mail.gmail.com>
Message-ID: <CAC6FiZ5md_dd-2KM7Ow-0E+L5cKxxet7T_c=_vq3cJx2K9tm3g@mail.gmail.com>

P.S. we should also think about these things, to make it more clear
why no email address should be required.

If people use primarily 'social' media for their communications, like
facebook which has a profile option for a GnuPG pub key, why should
that pub key bear an email address, once certified?

Or take as another security example a YubiKey for 2FA. The key does
not need an email address, if I log-in to facebook, Twitter, Google etc.
with the same key(s).

Or as an extreme example, my credit card, bank card, ID-card etc.
have no email address either, when I authenticate with them globally.

Regards
Stefan


From spam.trap.mailing.lists at gmail.com  Wed Nov  4 17:21:30 2020
From: spam.trap.mailing.lists at gmail.com (Stefan Claas)
Date: Wed, 4 Nov 2020 16:21:30 +0000
Subject: A question about the status of the keyserver structure
In-Reply-To: <8587313.y1p07l5mTE@roadrunner>
References: <8587313.y1p07l5mTE@roadrunner>
Message-ID: <CAC6FiZ7KNzo4vZh2eu8rrPDBnjzGSZSYbRNEOpZVYP7hmN7ROw@mail.gmail.com>

Hi,

attached is the (hopefully proper) key.

Regards
Stefan

On Tue, Nov 3, 2020 at 10:44 PM Stakanov via Gnupg-users
<gnupg-users at gnupg.org> wrote:
>
> I hope this is the correct list for this question:
>
>
>
> I tried to follow the instructions of
>
> https://www.mageia.org/it/downloads/get/?q=Mageia-7.1-x86_64.iso
>
> were it says you can import the key to verify the iso.
>
> But kleopatra stays without reaction (no matter how many pools I join) and
>
> entropia at roadrunner:~> gpg --keyserver pool.sks-keyservers.net --recv-keys EDCA7A90
> gpg: using character set 'utf-8'
> gpg: ricezione dal keyserver fallita: Connessione rifiutata
>
> which is: reception of keyserver failed: connection refused.
>
>
>
> Now I remember time ago there was an issue of keyservers abused and the structure was halted.
>
>
>
> What is the current status and how can one download a signature as of today? Manually or with a "keyserverpage" on https or how does it work now?
>
> Thank you in advance.
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mageia.asc
Type: application/octet-stream
Size: 7727 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20201104/73b1276a/attachment-0001.obj>

From andrewg at andrewg.com  Wed Nov  4 17:29:33 2020
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Wed, 4 Nov 2020 16:29:33 +0000
Subject: ping - Governikus
In-Reply-To: <CAC6FiZ4Tdes7=rEL=LhsJLot9pifRqdp_9NYMPjRWvj0-LbbZQ@mail.gmail.com>
References: <CAC6FiZ4wAy-ojqCM9Vdcu=ncqBMP7+M2bY5PphjfroWaX=kpJg@mail.gmail.com>
 <241B6B17-A294-4DCE-8F81-CABCCF661C4C@andrewg.com>
 <CAC6FiZ6MWmpKV-YXiJv=9ofR0rgUDjHCWotF9uXvCZQzuLa+1A@mail.gmail.com>
 <2cbc198c-f484-f05a-9eda-a8fed4f725cf@andrewg.com>
 <CAC6FiZ4Tdes7=rEL=LhsJLot9pifRqdp_9NYMPjRWvj0-LbbZQ@mail.gmail.com>
Message-ID: <c7677dd7-d444-f9ed-8645-2074f54eaecf@andrewg.com>

On 04/11/2020 15:33, Stefan Claas wrote:
> The email address has no certification value, because in
> case of a freeform
> UID they/we would not refuse to sign a key, I strongly assume.

You could sign it if you want, that's not the issue. The issue is what
value a third party would place on such a signature.

> If people use primarily 'social' media for their communications, like
> facebook which has a profile option for a GnuPG pub key, why should
> that pub key bear an email address, once certified?

It does not need to bear an email address, no. But it should bear a
unique identifier of some kind. That could be a URL, or a Twitter
handle, or anything sufficiently distinctive for the purposes for which
a third party would expect to use the key.

> Or take as another security example a YubiKey for 2FA. The key does
> not need an email address, if I log-in to facebook, Twitter, Google etc.
> with the same key(s).

But Facebook, Twitter etc. verify your yubikey themselves. They are not
relying upon a strange yubikey with a certification from a third party
saying "this yubikey belongs to one Stefan Claas".

> Or as an extreme example, my credit card, bank card, ID-card etc.
> have no email address either, when I authenticate with them globally.

Again, your credit card is certified by your bank because your bank owns
your physical credit card. They *made* your credit card. When you use
chip and pin in some shop, the card machine in the shop talks
(indirectly) to your bank, which certifies its own property. This is not
comparable to a third-party signature.

The key phrase I keep repeating in all these arguments is "third party".
For secure communication between two individuals who already have an
established relationship, there is no need for third-party
certification. I still don't see an actual use case for this.

-- 
Andrew Gallagher

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

From spam.trap.mailing.lists at gmail.com  Wed Nov  4 17:54:18 2020
From: spam.trap.mailing.lists at gmail.com (Stefan Claas)
Date: Wed, 4 Nov 2020 16:54:18 +0000
Subject: ping - Governikus
In-Reply-To: <c7677dd7-d444-f9ed-8645-2074f54eaecf@andrewg.com>
References: <CAC6FiZ4wAy-ojqCM9Vdcu=ncqBMP7+M2bY5PphjfroWaX=kpJg@mail.gmail.com>
 <241B6B17-A294-4DCE-8F81-CABCCF661C4C@andrewg.com>
 <CAC6FiZ6MWmpKV-YXiJv=9ofR0rgUDjHCWotF9uXvCZQzuLa+1A@mail.gmail.com>
 <2cbc198c-f484-f05a-9eda-a8fed4f725cf@andrewg.com>
 <CAC6FiZ4Tdes7=rEL=LhsJLot9pifRqdp_9NYMPjRWvj0-LbbZQ@mail.gmail.com>
 <c7677dd7-d444-f9ed-8645-2074f54eaecf@andrewg.com>
Message-ID: <CAC6FiZ5rup+=fL-rvMQMDrCfbYh9O+jdQfU0SLtT7Dk86ZkHXQ@mail.gmail.com>

On Wed, Nov 4, 2020 at 4:32 PM Andrew Gallagher <andrewg at andrewg.com> wrote:
>
> On 04/11/2020 15:33, Stefan Claas wrote:
> > The email address has no certification value, because in
> > case of a freeform
> > UID they/we would not refuse to sign a key, I strongly assume.
>
> You could sign it if you want, that's not the issue. The issue is what
> value a third party would place on such a signature.

Well, If someone I know, or a CA, would sign such a key from you
I would know that the key belongs to you, regardless for what the
key is used for, i.e. in case you would sign here on the ML and with
the option that your email account changes in the future.

> > If people use primarily 'social' media for their communications, like
> > facebook which has a profile option for a GnuPG pub key, why should
> > that pub key bear an email address, once certified?
>
> It does not need to bear an email address, no. But it should bear a
> unique identifier of some kind. That could be a URL, or a Twitter
> handle, or anything sufficiently distinctive for the purposes for which
> a third party would expect to use the key.

For me a unique identifier would be the included hash, which I can't
reverse, but which was signed along my name from the CA.

[...]

> The key phrase I keep repeating in all these arguments is "third party".
> For secure communication between two individuals who already have an
> established relationship, there is no need for third-party
> certification. I still don't see an actual use case for this.

Not sure why you don't see this, but let's say you or I would run a popular
crypto etc. blog on a web page and people would be allowed to reply
encrypted and you only provide a postal address (P.O.box address) instead
of a spamable email address, I and probably the majority of readers would
not need an email address in your UID and they would most likely trust
your certified pub key more, like I would, compared to a pub key which
bears no CA signature. There are more examples, but I think my point
should be clear why people should have the option to get a CA certified
public key without an email address, so that they can use the pub key
as a multipurpose key, not bound to an email address, which can always
change.

Regards
Stefan


From oz.tiram at gmail.com  Wed Nov  4 22:09:43 2020
From: oz.tiram at gmail.com (Oz Tiram)
Date: Wed, 4 Nov 2020 22:09:43 +0100
Subject: GPG agent forward on Debian: setting pinentry mode 'loopback'
 failed: Forbidden
In-Reply-To: <CADKMUwmJMHoR7zG4HQ6pUkMXApZFSEnrNyHwfgpVcM_+tW40Uw@mail.gmail.com>
References: <CADKMUw=cZCMZrTXVMBLRq_u-mQWk9_F55C8diSkPvnxrL2SNYQ@mail.gmail.com>
 <60006AB0-E311-4371-B55C-6EA7C33C2EE8@andrewg.com>
 <CADKMUwmJMHoR7zG4HQ6pUkMXApZFSEnrNyHwfgpVcM_+tW40Uw@mail.gmail.com>
Message-ID: <CADKMUwkM4jeoNg9-pU1sGRL9zciwo+5Uc7O=agxOXtGErRZ1kg@mail.gmail.com>

Hi Andrew!

I solved this issue finally! What a weird UI ...

So ..., apparently, it's not enough to tell the gpg-agent which tty needs
to be used via GPG_TTY!
You also have to do:

> I guess something is wrong on the local machine.
>

export GPG_TTY=$(tty)
gpg-connect-agent updatestartuptty /bye >/dev/null

Now, when I try to decrypt a file on the remote machine, pinentry opens a
dialog on the local machine.
If the password is properly typed, the decrypted file is printed out on the
remote machine!

This took quite a while to figure out!

THANK YOU!

Oz



--


---

Imagine there's no countries
it isn't hard to do
Nothing to kill or die for
And no religion too
Imagine all the people
Living life in peace
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20201104/f0ccd9f8/attachment.html>

From spam.trap.mailing.lists at gmail.com  Wed Nov  4 23:15:17 2020
From: spam.trap.mailing.lists at gmail.com (Stefan Claas)
Date: Wed, 4 Nov 2020 22:15:17 +0000
Subject: ping - Governikus
In-Reply-To: <CAC6FiZ5rup+=fL-rvMQMDrCfbYh9O+jdQfU0SLtT7Dk86ZkHXQ@mail.gmail.com>
References: <CAC6FiZ4wAy-ojqCM9Vdcu=ncqBMP7+M2bY5PphjfroWaX=kpJg@mail.gmail.com>
 <241B6B17-A294-4DCE-8F81-CABCCF661C4C@andrewg.com>
 <CAC6FiZ6MWmpKV-YXiJv=9ofR0rgUDjHCWotF9uXvCZQzuLa+1A@mail.gmail.com>
 <2cbc198c-f484-f05a-9eda-a8fed4f725cf@andrewg.com>
 <CAC6FiZ4Tdes7=rEL=LhsJLot9pifRqdp_9NYMPjRWvj0-LbbZQ@mail.gmail.com>
 <c7677dd7-d444-f9ed-8645-2074f54eaecf@andrewg.com>
 <CAC6FiZ5rup+=fL-rvMQMDrCfbYh9O+jdQfU0SLtT7Dk86ZkHXQ@mail.gmail.com>
Message-ID: <CAC6FiZ5UJHbVVULOtVRFUFGBuutNrNGb1TdX_iTLhsqvDyyFsg@mail.gmail.com>

On Wed, Nov 4, 2020 at 4:54 PM Stefan Claas
<spam.trap.mailing.lists at gmail.com> wrote:

[...]

> Not sure why you don't see this, but let's say you or I would run a popular
> crypto etc. blog on a web page and people would be allowed to reply
> encrypted and you only provide a postal address (P.O.box address) instead
> of a spamable email address, I and probably the majority of readers would
> not need an email address in your UID and they would most likely trust
> your certified pub key more, like I would, compared to a pub key which
> bears no CA signature. There are more examples, but I think my point
> should be clear why people should have the option to get a CA certified
> public key without an email address, so that they can use the pub key
> as a multipurpose key, not bound to an email address, which can always
> change.

Ok. as PoC I created such a key and used NIST guidelines to create the
pbkdf2 hash and also saved as reference the parameters used, in case
I had to send the pub key to another CA. Since Governikus needs an
email address for returning the certified pub key, I used a 'noreply'
disposal email address which (hopefully) everybody can use too.

Additionally I can create a secp256k1 sub key so that I can also
do Bitcoin transactions with my multi purpose key. :-)

I am attaching the key to this message.

The good thing now is in case I had to sign a message here on the ML
I can use this key with this spam address and not get spam with my
new real email address. :-)

Regards
Stefan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: stefan_claas_multi_purpose_key.asc
Type: application/octet-stream
Size: 1247 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20201104/8452f3f0/attachment-0001.obj>

From bangchuishan at outlook.com  Fri Nov  6 14:51:33 2020
From: bangchuishan at outlook.com (Gao Xiaohui)
Date: Fri, 6 Nov 2020 13:51:33 +0000
Subject: How to change the protect cipher algorithm and the digest algorithm
 of the secret key?
In-Reply-To: <SG2PR04MB2588CA4C0E300003B5340E3BD5ED0@SG2PR04MB2588.apcprd04.prod.outlook.com>
References: <SG2PR04MB258808825CEA95C4E4744155D5EF0@SG2PR04MB2588.apcprd04.prod.outlook.com>,
 <SG2PR04MB2588CA4C0E300003B5340E3BD5ED0@SG2PR04MB2588.apcprd04.prod.outlook.com>
Message-ID: <SG2PR04MB2588ABE63A54DF347B1C5D80D5ED0@SG2PR04MB2588.apcprd04.prod.outlook.com>

Hello,
Excuse me,When using "gpg --list-packets [private secret key file]",it print "iter+salt S2K, algo: 7, SHA1 protection, hash: 2, salt: ****************", how to change "algo:7" and "hash:2"?
I searched on Google, it use the "gpg --gen-key" or "gpg --edit-key" command with "--s2k-cipher-algo AES256" and "--s2k-digest-algo SHA512" options could change them, but I tested,It could not change them. Tell me  the correct way please.Thank you very much.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20201106/20f3faf0/attachment.html>

From jscott at posteo.net  Sun Nov  8 02:27:57 2020
From: jscott at posteo.net (John Scott)
Date: Sat, 07 Nov 2020 20:27:57 -0500
Subject: Clarification on getting a validity reason in GPGME
Message-ID: <2919903.yKVeVyVuyW@t450>

Hi

I'm writing a tool using GPGSM and want to print signature validation 
information without reinventing the wheel with case statements, also for the 
sake of localization. These members in gpgme_signature_t [1] seem to be what 
I'm looking for:

gpgme_validity_t validity
	The validity of the signature.
gpgme_error_t validity_reason
	If a signature is not valid, this provides a reason why.

so I can get a string from the gpgme_error_t, although it appears to be 
conditional on the signature being invalid. That's not clear since 
gpgme_validity_t is an enumeration of
GPGME_VALIDITY_{UNKNOWN, UNDEFINED, NEVER, MARGINAL,FULL, ULTIMATE}

I wonder if this is the case already and it's just a documentation quirk, but 
it'd be helpful if validity_reason were set to some value for good signatures, 
although this isn't technically an error.

[1] https://www.gnupg.org/documentation/manuals/gpgme/Verify.html#Verify
-------------- 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/20201107/83e4748c/attachment.sig>

From pavel.hora at yandex.com  Sat Nov  7 18:55:58 2020
From: pavel.hora at yandex.com (pavel hora)
Date: Sat, 07 Nov 2020 18:55:58 +0100
Subject: cannot verify .sig
Message-ID: <147211604771090@mail.yandex.com>

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

From johndoe65534 at mail.com  Sun Nov  8 16:38:24 2020
From: johndoe65534 at mail.com (john doe)
Date: Sun, 8 Nov 2020 16:38:24 +0100
Subject: cannot verify .sig
In-Reply-To: <147211604771090@mail.yandex.com>
References: <147211604771090@mail.yandex.com>
Message-ID: <2d95f9c0-4079-c6e8-99ce-23e37307c841@mail.com>

On 11/7/2020 6:55 PM, pavel hora via Gnupg-users wrote:
> Hi,
> I would like to use GPG to verify installation files (True Crypt this time to be
> specific) that come with a signature .sig and PGP public key .asc.

You should use veracrypt instead.

> I have installed GPG 4 Win 3.1.13.
> I have imported the public key. I have tried to verify the .exe with .sig, but
> Kleopatra tells me the public key is not certified, so I try to certify it
> myself, but I need my own key pair for that. So I try to build it, only it ends
> with error, because "No agent running".
> Now I assume that these issues happen because I prevent Kleopatra or GPG from
> accessing the net, but then again, why should it do so for the tasks specified
> above? I have used PGP in the past, long time ago, and it was always offline.
> So my question is - can I still use GPG to check the signature of the file, pls?
> And perhaps, why does GPG so desire the net access for my tasks?

Does it work if you do:

$ gpg --verify <*.sig>

--
John Doe


From kloecker at kde.org  Sun Nov  8 16:50:33 2020
From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=)
Date: Sun, 08 Nov 2020 16:50:33 +0100
Subject: Clarification on getting a validity reason in GPGME
In-Reply-To: <2919903.yKVeVyVuyW@t450>
References: <2919903.yKVeVyVuyW@t450>
Message-ID: <3223422.C68FoQFQi0@breq>

On Sonntag, 8. November 2020 02:27:57 CET John Scott via Gnupg-users wrote:
> Hi
> 
> I'm writing a tool using GPGSM and want to print signature validation
> information without reinventing the wheel with case statements, also for the
> sake of localization. These members in gpgme_signature_t [1] seem to be
> what I'm looking for:
> 
> gpgme_validity_t validity
> 	The validity of the signature.
> gpgme_error_t validity_reason
> 	If a signature is not valid, this provides a reason why.
> 
> so I can get a string from the gpgme_error_t, although it appears to be
> conditional on the signature being invalid. That's not clear since
> gpgme_validity_t is an enumeration of
> GPGME_VALIDITY_{UNKNOWN, UNDEFINED, NEVER, MARGINAL,FULL, ULTIMATE}

In the C++ bindings the equivalent for validity_reason is, more appropriately, 
called nonValidityReason. Also, validity refers to the (local) validity of the 
certificate that was used to make the signature. As far as I can see, in case 
of gpgsm validitity can take only three of the above mentioned 6 values:
* FULL (if the signature is good; the signature cannot be good if there is a 
problem or an untrusted key in the certificate chain; in this case 
validity_reason is 0)
* NEVER (if the certificate chain is invalid; in this case validity_reason 
gives more details)
* UNDEFINED (if there was some other problem while validating the certificate 
chain).

> I wonder if this is the case already and it's just a documentation quirk,
> but it'd be helpful if validity_reason were set to some value for good
> signatures, although this isn't technically an error.

As mentioned above the variable is just named badly. It would better have been 
called non_validity_reason (as in the C++ binding).

I'm wondering what kind of reason do you expect for a good signature? I mean 
there's exactly one reason for a good signature: The signature is 
"cryptographically correct" and the certificate that was used to make the 
signature is valid. In all other cases the signature is not good and then it 
makes sense to ask for the reason why it's not good.

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/20201108/2f520043/attachment.sig>

From kloecker at kde.org  Sun Nov  8 16:57:53 2020
From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=)
Date: Sun, 08 Nov 2020 16:57:53 +0100
Subject: cannot verify .sig
In-Reply-To: <147211604771090@mail.yandex.com>
References: <147211604771090@mail.yandex.com>
Message-ID: <7855050.VAL3zy08H2@breq>

On Samstag, 7. November 2020 18:55:58 CET pavel hora via Gnupg-users wrote:
> Hi,
> I would like to use GPG to verify installation files (True Crypt this time
> to be specific) that come with a signature .sig and PGP public key .asc. I
> have installed GPG 4 Win 3.1.13.
> I have imported the public key. I have tried to verify the .exe with .sig,
> but Kleopatra tells me the public key is not certified, so I try to certify
> it myself, but I need my own key pair for that. So I try to build it, only
> it ends with error, because "No agent running". Now I assume that these
> issues happen because I prevent Kleopatra or GPG from accessing the net,
> but then again, why should it do so for the tasks specified above? I have
> used PGP in the past, long time ago, and it was always offline. So my
> question is - can I still use GPG to check the signature of the file, pls?
> And perhaps, why does GPG so desire the net access for my tasks?

GnuPG consists of several applications (e.g. gpg as frontend called by 
Kleopatra and gpg-agent as backend) that talk to each other. I'm not sure 
whether this communication requires local network connections on Windows. On 
Linux it's done via socket connections. Anyway, maybe blocking network access 
also blocks the local communication between gpg and gpg-agent. You may have to 
allow local network access for gpg.

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/20201108/41d52a13/attachment-0001.sig>

From spam.trap.mailing.lists at gmail.com  Sun Nov  8 22:08:25 2020
From: spam.trap.mailing.lists at gmail.com (Stefan Claas)
Date: Sun, 8 Nov 2020 21:08:25 +0000
Subject: GnuPG 'Lottery' - 'fun' with 256 bit keys
Message-ID: <CAC6FiZ4xc5S6ahC1GDdChx+_p27m=D4ZCjDiUvAQ58ijHyQmjg@mail.gmail.com>

Hi all,

while reading about how many possible 256bit keys can be
generated and and also reading about collisions I thought
why not check with a Bitcoin blockchain explorer when one
sees a 256 bit data string in HEX notation if it would
have some balance?

While looking at Werner's signatures, in postings here on
the ML, I could see that his signature contains such data,
when one checks his signature with a tool like this one:

https://github.com/ConradIrwin/gpg-decoder

and extracts the 'data:' string in the last row and feeds
then the string in a program like this:

https://github.com/matja/bitcoin-tool

in order to generate the keys for checking.

I already checked a couple of Werner's sigs but the balance
from his signatures was always zero. Maybe someone of you
will have luck in the future to find a proper 256 bit string.
(chances however are *very very very* minimal to almost zero)

P.S. this procedure means that if you have a publicity available
256bit string (in HEX notation) that you simply use it as a secret
key to generate the proper keys for checking ...

Regards
Stefan


From spam.trap.mailing.lists at gmail.com  Sun Nov  8 23:08:17 2020
From: spam.trap.mailing.lists at gmail.com (Stefan Claas)
Date: Sun, 8 Nov 2020 22:08:17 +0000
Subject: GnuPG 'Lottery' - 'fun' with 256 bit keys
In-Reply-To: <CAC6FiZ4xc5S6ahC1GDdChx+_p27m=D4ZCjDiUvAQ58ijHyQmjg@mail.gmail.com>
References: <CAC6FiZ4xc5S6ahC1GDdChx+_p27m=D4ZCjDiUvAQ58ijHyQmjg@mail.gmail.com>
Message-ID: <CAC6FiZ5YSJro-RqFcLgGzfHVLTwnbrNY5Vg0qA=Kv41Y_QSzZw@mail.gmail.com>

On Sun, Nov 8, 2020 at 9:08 PM Stefan Claas
<spam.trap.mailing.lists at gmail.com> wrote:

> and extracts the 'data:' string in the last row and feeds

correction, 'signature:' string.

> then the string in a program like this:
>
> https://github.com/matja/bitcoin-tool

In case people are Windows users and like to have an .exe,
I compiled one:

https://anonfiles.com/H4P7Xbncpd/bitcoin-tool_zip

Regards
Stefan


From franek.wiertara at onet.eu  Sun Nov  8 16:20:36 2020
From: franek.wiertara at onet.eu (franek.wiertara at onet.eu)
Date: Sun, 08 Nov 2020 16:20:36 +0100
Subject: cannot verify .sig
Message-ID: <111175881-b0ac1820736306e1ae0c517c17b072b7@pmq3v.m5r2.onet>

Run "Perform Self-test" in "Settings" menu and make sure everything there is OK and running. One of the tests fails on my computer, that is "scdaemon" but I don't use smart cards and I believe I don't have to worry about it. I could probably turn it off in settings. If everything is OK, then you should be able to create a new key pair and then sign the public key.


> Hi,
> I would like to use GPG to verify installation files (True Crypt this time to be specific) that come with a signature .sig and PGP public key .asc.
> I have installed GPG 4 Win 3.1.13.
> I have imported the public key. I have tried to verify the .exe with .sig, but Kleopatra tells me the public key is not certified, so I try to certify it myself, but I need my own key pair for that. So I try to build it, only it ends with error, because "No agent running".
> Now I assume that these issues happen because I prevent Kleopatra or GPG from accessing the net, but then again, why should it do so for the tasks specified above? I have used PGP in the past, long time ago, and it was always offline.
> So my question is - can I still use GPG to check the signature of the file, pls?
> And perhaps, why does GPG so desire the net access for my tasks?
> 
> 
> Many thanks in advance for your kind help!
> 
> 
> Best regards,
> PH



From stefanclaas at riseup.net  Wed Nov 11 19:59:16 2020
From: stefanclaas at riseup.net (Stefan Claas)
Date: Wed, 11 Nov 2020 10:59:16 -0800
Subject: GnuPG 'Lottery' - 'fun' with 256 bit keys
In-Reply-To: <CAC6FiZ4xc5S6ahC1GDdChx+_p27m=D4ZCjDiUvAQ58ijHyQmjg@mail.gmail.com>
References: <CAC6FiZ4xc5S6ahC1GDdChx+_p27m=D4ZCjDiUvAQ58ijHyQmjg@mail.gmail.com>
Message-ID: <79560c4b73f91b8f0d57455509a65d9a@riseup.net>

On 2020-11-08 22:08, Stefan Claas via Gnupg-users wrote:

> P.S. this procedure means that if you have a publicity available
> 256bit string (in HEX notation) that you simply use it as a secret
> key to generate the proper keys for checking ...

P.S. according to Bitcoin specs the 256bit HEX values needs to
be in a proper range.

And another idea, to expand the GnuPG 'Lottery'. How about this:

Some cool GnuPG hackers write a program which checks publicity
available SKS key server dumps for signature packets #2, the
once that are only 256bit long, then saves those values in a
text file, convert these values to Bitcoin key pairs and then
uses a balance checker program, to see if a key has a balance
(in the future)?

Well, just a thought. At least it would give publicity available
key server dumps an additional research value.

Regards
Stefan


From wangtianjiao.wang959 at gmail.com  Thu Nov 12 15:48:48 2020
From: wangtianjiao.wang959 at gmail.com (A NiceBoy)
Date: Thu, 12 Nov 2020 09:48:48 -0500
Subject: How to change the protect cipher algorithm and the digest
 algorithm of the secret key?
In-Reply-To: <SG2PR04MB2588ABE63A54DF347B1C5D80D5ED0@SG2PR04MB2588.apcprd04.prod.outlook.com>
References: <SG2PR04MB258808825CEA95C4E4744155D5EF0@SG2PR04MB2588.apcprd04.prod.outlook.com>
 <SG2PR04MB2588CA4C0E300003B5340E3BD5ED0@SG2PR04MB2588.apcprd04.prod.outlook.com>
 <SG2PR04MB2588ABE63A54DF347B1C5D80D5ED0@SG2PR04MB2588.apcprd04.prod.outlook.com>
Message-ID: <CAL57ndE2-C90SzRgDgniejBEun11Nd5tsALGXEJ=8nAf3+tM4A@mail.gmail.com>

Hello Gao,

Your question could be stated more clearly as in this bug report:
https://dev.gnupg.org/T1800


1. The solution is also in this report. Just install gpg version
2.0.x, which prior to version 2.1, then run the following command to
generate the key:

> gpg2 --s2k-cipher-algo AES256 --s2k-digest-algo SHA512 --s2k-mode 3 --s2k-count 65000000 --gen-key

Then export, using the s2k options in case they're needed here instead:

> gpg2 --s2k-cipher-algo AES256 --s2k-digest-algo SHA512 --s2k-mode 3 --s2k-count 65000000 --export-secret-keys | gpg2 --list-packets

Then you can see the algo changed to AES256 and digest changed to SHA512.


2. To modify the existing key, you still have to install gpg version
2.0.x first, which prior to version 2.1, then add the following
options into your gpg.conf:

> #-----------------------------
> # algorithm and ciphers
> #-----------------------------
> # Limits the algorithms used
> personal-cipher-preferences AES256
> personal-digest-preferences SHA512
> default-preference-list SHA512 SHA384 SHA256 RIPEMD160 AES256 TWOFISH BLOWFISH ZLIB BZIP2 ZIP Uncompressed
> cipher-algo AES256
> digest-algo SHA512
> cert-digest-algo SHA512
> compress-algo ZLIB
> disable-cipher-algo 3DES
> #weak-digest SHA1
> s2k-cipher-algo AES256
> s2k-digest-algo SHA512
> s2k-mode 3
> s2k-count 65011712

Then reset the passphrase of the private key, using the above
settings, then export the private key to file. Here is the output of
command of --list-packets :

> iter+salt S2K, algo: 9, SHA1 protection, hash: 10, salt: 12d208a128163024
> protect count: 65011712 (255)

This idea comes from the links:
https://blog.eleven-labs.com/en/openpgp-almost-perfect-key-pair-part-1
,  https://security.stackexchange.com/a/90617


3. There is a small tool along with the command of --list-packets,
called pgpdump which is available at
http://www.mew.org/~kazu/proj/pgpdump/en/ , to provide more details of
the private key file.


Best regards

On Fri, 6 Nov 2020 at 16:27, Gao Xiaohui via Gnupg-users
<gnupg-users at gnupg.org> wrote:
>
> Hello,
> Excuse me,When using "gpg --list-packets [private secret key file]",it print "iter+salt S2K, algo: 7, SHA1 protection, hash: 2, salt: ****************", how to change "algo:7" and "hash:2"?
> I searched on Google, it use the "gpg --gen-key" or "gpg --edit-key" command with "--s2k-cipher-algo AES256" and "--s2k-digest-algo SHA512" options could change them, but I tested,It could not change them. Tell me  the correct way please.Thank you very much.
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users


From wangtianjiao.wang959 at gmail.com  Thu Nov 12 15:27:26 2020
From: wangtianjiao.wang959 at gmail.com (A NiceBoy)
Date: Thu, 12 Nov 2020 09:27:26 -0500
Subject: How to change the protect cipher algorithm and the digest
 algorithm of the secret key?
In-Reply-To: <SG2PR04MB2588ABE63A54DF347B1C5D80D5ED0@SG2PR04MB2588.apcprd04.prod.outlook.com>
References: <SG2PR04MB258808825CEA95C4E4744155D5EF0@SG2PR04MB2588.apcprd04.prod.outlook.com>
 <SG2PR04MB2588CA4C0E300003B5340E3BD5ED0@SG2PR04MB2588.apcprd04.prod.outlook.com>
 <SG2PR04MB2588ABE63A54DF347B1C5D80D5ED0@SG2PR04MB2588.apcprd04.prod.outlook.com>
Message-ID: <CAL57ndEf++4yOLG1s6TaY1nniWFwjZFmwjwY_YU+NfYEn6nQ1g@mail.gmail.com>

Hello Gao,

Your question could be stated more clearly as in this bug report:
https://dev.gnupg.org/T1800


1. The solution is also in this report. Just install gpg version 2.0.x,
which prior to version 2.1, then run the following command to generate the
key:

> gpg2 --s2k-cipher-algo AES256 --s2k-digest-algo SHA512 --s2k-mode 3
--s2k-count 65000000 --gen-key

Then export, using the s2k options in case they're needed here instead:

> gpg2 --s2k-cipher-algo AES256 --s2k-digest-algo SHA512 --s2k-mode 3
--s2k-count 65000000 --export-secret-keys | gpg2 --list-packets

Then you can see the algo changed to AES256 and digest changed to SHA512.


2. To modify the existing key, you still have to install gpg version 2.0.x
first, which prior to version 2.1, then add the following options into your
gpg.conf:

> #-----------------------------
> # algorithm and ciphers
> #-----------------------------
> # Limits the algorithms used
> personal-cipher-preferences AES256
> personal-digest-preferences SHA512
> default-preference-list SHA512 SHA384 SHA256 RIPEMD160 AES256 TWOFISH
BLOWFISH ZLIB BZIP2 ZIP Uncompressed
> cipher-algo AES256
> digest-algo SHA512
> cert-digest-algo SHA512
> compress-algo ZLIB
> disable-cipher-algo 3DES
> #weak-digest SHA1
> s2k-cipher-algo AES256
> s2k-digest-algo SHA512
> s2k-mode 3
> s2k-count 65011712

Then reset the passphrase of the private key, using the above settings,
then export the private key to file. Here is the output of command of
--list-packets :

> iter+salt S2K, algo: 9, SHA1 protection, hash: 10, salt: 12d208a128163024
> protect count: 65011712 (255)

This idea comes from the links:
https://blog.eleven-labs.com/en/openpgp-almost-perfect-key-pair-part-1 ,
https://security.stackexchange.com/a/90617


3. There is a small tool along with the command of --list-packets, called
pgpdump which is available at https://www.mew.org/~kazu/proj/pgpdump/en/ ,
to provide more details of the private key file.


Best regards



On Fri, 6 Nov 2020 at 16:27, Gao Xiaohui via Gnupg-users <
gnupg-users at gnupg.org> wrote:

> Hello,
> Excuse me,When using "gpg --list-packets [private secret key file]",it
> print "iter+salt S2K, algo: 7, SHA1 protection, hash: 2, salt:
> ****************", how to change "algo:7" and "hash:2"?
> I searched on Google, it use the "gpg --gen-key" or "gpg --edit-key"
> command with "--s2k-cipher-algo AES256" and "--s2k-digest-algo SHA512"
> options could change them, but I tested,It could not change them. Tell me
>  the correct way please.Thank you very much.
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20201112/e4fdb4b0/attachment-0001.html>

From wk at gnupg.org  Fri Nov 13 09:48:40 2020
From: wk at gnupg.org (Werner Koch)
Date: Fri, 13 Nov 2020 09:48:40 +0100
Subject: How to change the protect cipher algorithm and the digest
 algorithm of the secret key?
In-Reply-To: <CAL57ndEf++4yOLG1s6TaY1nniWFwjZFmwjwY_YU+NfYEn6nQ1g@mail.gmail.com>
 (A. NiceBoy via Gnupg-users's message of "Thu, 12 Nov 2020 09:27:26
 -0500")
References: <SG2PR04MB258808825CEA95C4E4744155D5EF0@SG2PR04MB2588.apcprd04.prod.outlook.com>
 <SG2PR04MB2588CA4C0E300003B5340E3BD5ED0@SG2PR04MB2588.apcprd04.prod.outlook.com>
 <SG2PR04MB2588ABE63A54DF347B1C5D80D5ED0@SG2PR04MB2588.apcprd04.prod.outlook.com>
 <CAL57ndEf++4yOLG1s6TaY1nniWFwjZFmwjwY_YU+NfYEn6nQ1g@mail.gmail.com>
Message-ID: <87v9e9prpz.fsf@wheatstone.g10code.de>

On Thu, 12 Nov 2020 09:27, A NiceBoy said:

> 1. The solution is also in this report. Just install gpg version 2.0.x,

Don't!

2.0 reached end-of-life 3 years ago - there are no security fixes etc.
You shall not use that version anymore.

> Then you can see the algo changed to AES256 and digest changed to SHA512.

If you want to convey secret keys do not rely on the passphrase
protection of OpenPGP but use a secure transport channel.  Which may be
just a gpg encrypted file.  The problem with the passphrase is that you
need to transport a secure passphrase via another secured medium and in
this case you can also a transport the secret key with a "weaker"
passphrase.  Whether you use SHA256 or SHA512 does not matter.  The
iteration count matters more but in any case you can't create better
security from a weak passphrase - the iteration count is a failstop
thing but not a proper cryptographic replacement for a weak passphrase.


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/20201113/4e3cdd49/attachment.sig>

From sirisha.gopigiri at ericsson.com  Fri Nov 13 12:52:44 2020
From: sirisha.gopigiri at ericsson.com (Sirisha Gopigiri)
Date: Fri, 13 Nov 2020 11:52:44 +0000
Subject: GPG Encryption/Decryption Failing
Message-ID: <SN6PR1501MB1998350A2C8AFCBF23CF890FF8E60@SN6PR1501MB1998.namprd15.prod.outlook.com>

Hi,

We are trying to use SOPS+GPG to encrypt/decrypt yaml files and we have written some go wrapper using sops library to perform the required encryption/decryption. However when trying to execute this code the gpg library seems to be failing at keygeneration most of the time with the following error.


failed to encrypt new data key with master key "681E3A89EB1DAFD36EB883120A73BB48E26694D8": could not encrypt data key with PGP key: golang.org/x/crypto/openpgp error: key with fingerprint 681E3A89EB1DAFD36EB883120A73BB48E26694D8 is not available in keyring and could not be retrieved from keyserver; GPG binary error: gpg binary failed with error: exit status 2, gpg: 681E3A89EB1DAFD36EB883120A73BB48E26694D8: skipped: No public key

?Seems like it is unable to fetch the public key, we are executing the code locally, so we are using the local public and private keys only.

Though we can list the public key locally, we keep getting the above error quite frequently. However, the encryption/decryption is happening successfully the other times.

Kindly let us know if we are missing anything.

We are facing this error only with gpg 2.1.x version, gpg 1.4.x version seems to be working fine.

Thank you in advance!

Best Regards
Sirisha Gopigiri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20201113/6b6ff089/attachment.html>

From 22h39 at tutanota.com  Fri Nov 13 20:22:21 2020
From: 22h39 at tutanota.com (22h39)
Date: Fri, 13 Nov 2020 20:22:21 +0100 (CET)
Subject: Major problems with gpg and scdaemon, help highly appriciated
Message-ID: <MM22ib4--B-2@tutanota.com>


I have been for the life of me unable to get gpg working with the contactless interface in my reader.


How to reproduce:

I'm using a REINERSCT Cyberjack standard RFID dual interface class 3 reader
Simply take a Openpgp card and try to sign anything using the contactless interface.

The drivers for the reader are here:

 https://www.reiner-sct.com/support/support-anfrage/?productGroup=77304735&product=77304820&q=driver&os=Linux#choice5




This is the card's list command that works on both interfaces:


```
Reader ...........: REINER SCT cyberJack RFID standard (9934036502) 00 00Application ID ...: D276000124010304BEEF000000000007Application type .: OpenPGPVersion ..........: 3.4Manufacturer .....: unknownSerial number ....: 00000000Name of cardholder: bac  Language prefs ...: enSalutation .......: URL of public key : [not set]Login data .......: [not set]Signature PIN ....: not forcedKey attributes ...: rsa4096 rsa4096 rsa3072Max. PIN lengths .: 127 127 127PIN retry counter : 3 0 3Signature counter : 4KDF setting ......: offSignature key ....: 0353 CB0B 67EA AADE 39A5  B54F E8D6 EC89 1A92 2CE4      created ....: 2020-11-13 18:32:45Encryption key....: 03FC FCB0 49FF E397 337B  4B3F F9BE BBC9 CCB3 DEA9      created ....: 2020-11-13 18:32:45Authentication key: 526C E0A2 9AC4 F6B3 F6D1  2B67 BADC ADFD C2AC 5D9F      created ....: 2020-11-13 18:32:45General key info..: pub  rsa4096/E8D6EC891A922CE4 2020-11-13 Test keysec>  rsa4096/E8D6EC891A922CE4  created: 2020-11-13  expires: never                                     card-no: BEEF 00000000ssb>  rsa3072/BADCADFDC2AC5D9F  created: 2020-11-13  expires: never                                     card-no: BEEF 00000000ssb>  rsa4096/F9BEBBC9CCB3DEA9  created: 2020-11-13  expires: never                                     card-no: BEEF 00000000```

This is pcsc_scan's output when I take out the card and insert it into the other slot


```
0: REINER SCT cyberJack RFID standard (9934036502) 00 00 Fri Nov 13 19:43:53 2020 Reader 0: REINER SCT cyberJack RFID standard (9934036502) 00 00  Event number: 2  Card state: Card removed,    Fri Nov 13 19:43:57 2020 Reader 0: REINER SCT cyberJack RFID standard (9934036502) 00 00  Event number: 3  Card state: Card inserted,   ATR: 3B 94 95 81 01 46 54 56 01 C4ATR: 3B 94 95 81 01 46 54 56 01 C4+ TS = 3B --> Direct Convention+ T0 = 94, Y(1): 1001, K: 4 (historical bytes)  TA(1) = 95 --> Fi=512, Di=16, 32 cycles/ETU    125000 bits/s at 4 MHz, fMax for Fi = 5 MHz => 156250 bits/s  TD(1) = 81 --> Y(i+1) = 1000, Protocol T = 1 -----  TD(2) = 01 --> Y(i+1) = 0000, Protocol T = 1 -----+ Historical bytes: 46 54 56 01  Category indicator byte: 46 (proprietary format)+ TCK = C4 (correct checksum)Possibly identified card (using /usr/share/pcsc/smartcard_list.txt):3B 94 95 81 01 46 54 56 01 C4	blank J3H145 card (Other)   Fri Nov 13 19:43:59 2020 Reader 0: REINER SCT cyberJack RFID standard (9934036502) 00 00  Event number: 4  Card state: Card removed,    Fri Nov 13 19:44:02 2020 Reader 0: REINER SCT cyberJack RFID standard (9934036502) 00 00  Event number: 5  Card state: Card inserted,   ATR: 3B 80 80 01 01ATR: 3B 80 80 01 01+ TS = 3B --> Direct Convention+ T0 = 80, Y(1): 1000, K: 0 (historical bytes)  TD(1) = 80 --> Y(i+1) = 1000, Protocol T = 0 -----  TD(2) = 01 --> Y(i+1) = 0000, Protocol T = 1 -----+ Historical bytes: + TCK = 01 (correct checksum)Possibly identified card (using /usr/share/pcsc/smartcard_list.txt):3B 80 80 01 01	ISO 14443 Type B without historical bytes	Electronic Passport	Spanish passport (2012)	Canadian Passport	Venez_Prox

```

This is an attempt to sign on both of the interfaces.
 On contact it asks for the PIN using the reader's pinentry




Contact:

```
h39 at Auriel ~/Downloads > gpg -vvv -s testfilegpg: using character set 'utf-8'gpg: writing to 'testfile.gpg'gpg: pinentry launched (51412 gnome3 1.1.0 /dev/pts/0 xterm-256color :1)gpg: RSA/SHA512 signature from: "E8D6EC891A922CE4 Test key"

Contactless:

h39 at Auriel ~/Downloads> gpg -vvv -s testfilegpg: using character set 'utf-8'File 'testfile.gpg' exists. Overwrite? (y/N) ygpg: writing to 'testfile.gpg'gpg: pinentry launched (51454 gnome3 1.1.0 /dev/pts/0 xterm-256color :1)gpg: signing failed: Conditions of use not satisfiedgpg: signing failed: Conditions of use not satisfied

And finally here are pcscd's logs using --debug and first trying to sign on contacts then on contactless, the card PIN is 123456

03900506 [140366865852160] hotplug_libudev.c:655:HPEstablishUSBNotifications() USB Device add00000234 [140366865852160] hotplug_libudev.c:299:get_driver() Looking for a driver for VID: 0x0C4B, PID: 0x0500, path: /dev/bus/usb/001/01400000016 [140366865852160] hotplug_libudev.c:440:HPAddDevice() Adding USB device: REINER SCT cyberJack RFID standard00000054 [140366865852160] readerfactory.c:1074:RFInitializeReader() Attempting startup of REINER SCT cyberJack RFID standard (9934036502) 00 00 using /usr/lib/pcsc/drivers/libifd-cyberjack.bundle/Contents/Linux/libifd-cyberjack.so <http://libifd-cyberjack.bundle/Contents/Linux/libifd-cyberjack.so>CYBERJACK: Started00001790 [140366865852160] readerfactory.c:950:RFBindFunctions() Loading IFD Handler 3.002092822 [140366865852160] readerfactory.c:391:RFAddReader() Using the pcscd polling thread07477005 [140366770595584] eventhandler.c:406:EHStatusHandlerThread() powerState: POWER_STATE_POWERED00000032 [140366770595584] eventhandler.c:423:EHStatusHandlerThread() Card inserted into REINER SCT cyberJack RFID standard (9934036502) 00 0000000026 [140366770595584] Card ATR: 3B 80 80 01 01 00400366 [140366770595584] eventhandler.c:482:EHStatusHandlerThread() powerState: POWER_STATE_UNPOWERED02424729 [140366770595584] eventhandler.c:358:EHStatusHandlerThread() Card Removed From REINER SCT cyberJack RFID standard (9934036502) 00 0001587089 [140366770595584] eventhandler.c:406:EHStatusHandlerThread() powerState: POWER_STATE_POWERED00000022 [140366770595584] eventhandler.c:423:EHStatusHandlerThread() Card inserted into REINER SCT cyberJack RFID standard (9934036502) 00 0000000010 [140366770595584] Card ATR: 3B 94 95 81 01 46 54 56 01 C4 00400575 [140366770595584] eventhandler.c:482:EHStatusHandlerThread() powerState: POWER_STATE_UNPOWERED03735577 [140366874249152] winscard_msg_srv.c:256:ProcessEventsServer() Common channel packet arrival00000031 [140366874249152] winscard_msg_srv.c:267:ProcessEventsServer() ProcessCommonChannelRequest detects: 1400000012 [140366874249152] pcscdaemon.c:133:SVCServiceRunLoop() A new context thread creation is requested: 1400000176 [140366762202880] winscard_svc.c:340:ContextThread() Authorized PC/SC client00000013 [140366762202880] winscard_svc.c:343:ContextThread() Thread is started: dwClientID=14, threadContext @0x560a0ee01f2000000011 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_VERSION from client 1400000007 [140366762202880] winscard_svc.c:373:ContextThread() Client is protocol version 4:400000004 [140366762202880] winscard_svc.c:396:ContextThread() CMD_VERSION rv=0x0 for client 1400000086 [140366762202880] winscard_svc.c:361:ContextThread() Received command: ESTABLISH_CONTEXT from client 1400000114 [140366762202880] winscard.c:215:SCardEstablishContext() Establishing Context: 0xA6D81FD00000006 [140366762202880] winscard_svc.c:461:ContextThread() ESTABLISH_CONTEXT rv=0x0 for client 1400000085 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_GET_READERS_STATE from client 1400000071 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_GET_READERS_STATE from client 1400000140 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CONNECT from client 1400000023 [140366762202880] winscard_svc.c:499:ContextThread() Authorized client for 'REINER SCT cyberJack RFID standard (9934036502) 00 00'00000009 [140366762202880] winscard.c:258:SCardConnect() Attempting Connect to REINER SCT cyberJack RFID standard (9934036502) 00 00 using protocol: 300000012 [140366762202880] readerfactory.c:821:RFReaderInfo() RefReader() count was: 100044154 [140366762202880] winscard.c:332:SCardConnect() power up complete.00000026 [140366762202880] Card ATR: 3B 94 95 81 01 46 54 56 01 C4 00000008 [140366762202880] winscard.c:352:SCardConnect() powerState: POWER_STATE_IN_USE00000007 [140366762202880] prothandler.c:107:PHSetProtocol() Attempting PTS to T=100011078 [140366762202880] winscard.c:430:SCardConnect() Active Protocol: T=100000023 [140366762202880] winscard.c:456:SCardConnect() hCard Identity: 5ed3ae4700000009 [140366762202880] winscard.c:518:SCardConnect() UnrefReader() count was: 200000010 [140366762202880] winscard_svc.c:513:ContextThread() CONNECT rv=0x0 for client 1400000135 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CONTROL from client 1400000018 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000025 [140366762202880] winscard.c:1359:SCardControl() UnrefReader() count was: 200000005 [140366762202880] winscard_svc.c:735:ContextThread() CONTROL rv=0x0 for client 1400000102 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_GET_READERS_STATE from client 1400000108 [140366762202880] winscard_svc.c:361:ContextThread() Received command: STATUS from client 1400000012 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000004 [140366762202880] winscard.c:1300:SCardStatus() UnrefReader() count was: 200000004 [140366762202880] winscard_svc.c:632:ContextThread() STATUS rv=0x0 for client 1400000073 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_WAIT_READER_STATE_CHANGE from client 1400000008 [140366762202880] winscard_svc.c:834:MSGSendReaderStates() Send reader states: 1400000077 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_STOP_WAITING_READER_STATE_CHANGE from client 1400000009 [140366762202880] winscard_svc.c:442:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 1400000076 [140366762202880] winscard_svc.c:361:ContextThread() Received command: TRANSMIT from client 1400000011 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000007 [140366762202880] winscard.c:1595:SCardTransmit() Send Protocol: T=100000007 [140366762202880] APDU: 00 A4 00 0C 02 3F 00 00184823 [140366762202880] SW: 6A 86 00000020 [140366762202880] winscard.c:1640:SCardTransmit() UnrefReader() count was: 200000007 [140366762202880] winscard_svc.c:685:ContextThread() TRANSMIT rv=0x0 for client 1400000135 [140366762202880] winscard_svc.c:361:ContextThread() Received command: TRANSMIT from client 1400000021 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000006 [140366762202880] winscard.c:1595:SCardTransmit() Send Protocol: T=100000006 [140366762202880] APDU: 00 A4 04 00 06 D2 76 00 01 24 01 00015298 [140366762202880] SW: 90 00 00000020 [140366762202880] winscard.c:1640:SCardTransmit() UnrefReader() count was: 200000006 [140366762202880] winscard_svc.c:685:ContextThread() TRANSMIT rv=0x0 for client 1400000136 [140366762202880] winscard_svc.c:361:ContextThread() Received command: TRANSMIT from client 1400000021 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000006 [140366762202880] winscard.c:1595:SCardTransmit() Send Protocol: T=100000006 [140366762202880] APDU: 00 CA 00 4F 00 00016731 [140366762202880] SW: D2 76 00 01 24 01 03 04 BE EF 00 00 00 00 00 07 90 00 00000022 [140366762202880] winscard.c:1640:SCardTransmit() UnrefReader() count was: 200000013 [140366762202880] winscard_svc.c:685:ContextThread() TRANSMIT rv=0x0 for client 1400000113 [140366762202880] winscard_svc.c:361:ContextThread() Received command: TRANSMIT from client 1400000023 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000008 [140366762202880] winscard.c:1595:SCardTransmit() Send Protocol: T=100000008 [140366762202880] APDU: 00 CA 5F 52 00 00015652 [140366762202880] SW: 00 C1 C5 73 C0 01 80 05 90 00 90 00 00000019 [140366762202880] winscard.c:1640:SCardTransmit() UnrefReader() count was: 200000011 [140366762202880] winscard_svc.c:685:ContextThread() TRANSMIT rv=0x0 for client 1400000147 [140366762202880] winscard_svc.c:361:ContextThread() Received command: TRANSMIT from client 1400000025 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000010 [140366762202880] winscard.c:1595:SCardTransmit() Send Protocol: T=100000010 [140366762202880] APDU: 00 CA 00 C4 00 00017123 [140366762202880] SW: 01 7F 7F 7F 03 00 03 90 00 00000019 [140366762202880] winscard.c:1640:SCardTransmit() UnrefReader() count was: 200000007 [140366762202880] winscard_svc.c:685:ContextThread() TRANSMIT rv=0x0 for client 1400000114 [140366762202880] winscard_svc.c:361:ContextThread() Received command: TRANSMIT from client 1400000021 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000005 [140366762202880] winscard.c:1595:SCardTransmit() Send Protocol: T=100000006 [140366762202880] APDU: 00 CA 00 6E 00 00047584 [140366762202880] SW: 6E 81 D9 4F 10 D2 76 00 01 24 01 03 04 BE EF 00 00 00 00 00 07 5F 52 0A 00 C1 C5 73 C0 01 80 05 90 00 73 81 B7 C0 0A FF 03 00 20 04 80 00 FF 00 00 C1 06 01 10 00 00 11 03 C2 06 01 10 00 00 11 03 C3 06 01 0C 00 00 11 03 C4 07 01 7F 7F 7F 03 00 03 C5 3C 03 53 CB 0B 67 EA AA DE 39 A5 B5 4F E8 D6 EC 89 1A 92 2C E4 03 FC FC B0 49 FF E3 97 33 7B 4B 3F F9 BE BB C9 CC B3 DE A9 52 6C E0 A2 9A C4 F6 B3 F6 D1 2B 67 BA DC AD FD C2 AC 5D 9F C6 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CD 0C 5F AE D1 4D 5F AE D1 4D 5F AE D1 4D 90 00 00000022 [140366762202880] winscard.c:1640:SCardTransmit() UnrefReader() count was: 200000009 [140366762202880] winscard_svc.c:685:ContextThread() TRANSMIT rv=0x0 for client 1400000115 [140366762202880] winscard_svc.c:361:ContextThread() Received command: TRANSMIT from client 1400000014 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000005 [140366762202880] winscard.c:1595:SCardTransmit() Send Protocol: T=100000004 [140366762202880] APDU: 00 CA 7F 74 00 00012896 [140366762202880] SW: 6A 88 00000018 [140366762202880] winscard.c:1640:SCardTransmit() UnrefReader() count was: 200000006 [140366762202880] winscard_svc.c:685:ContextThread() TRANSMIT rv=0x0 for client 1400000097 [140366762202880] winscard_svc.c:361:ContextThread() Received command: TRANSMIT from client 1400000021 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000006 [140366762202880] winscard.c:1595:SCardTransmit() Send Protocol: T=100000005 [140366762202880] APDU: 00 CA 00 5E 00 00011747 [140366762202880] SW: 90 00 00000021 [140366762202880] winscard.c:1640:SCardTransmit() UnrefReader() count was: 200000008 [140366762202880] winscard_svc.c:685:ContextThread() TRANSMIT rv=0x0 for client 1400000086 [140366762202880] winscard_svc.c:361:ContextThread() Received command: TRANSMIT from client 1400000018 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000008 [140366762202880] winscard.c:1595:SCardTransmit() Send Protocol: T=100000008 [140366762202880] APDU: 00 CA 00 6E 00 00047658 [140366762202880] SW: 6E 81 D9 4F 10 D2 76 00 01 24 01 03 04 BE EF 00 00 00 00 00 07 5F 52 0A 00 C1 C5 73 C0 01 80 05 90 00 73 81 B7 C0 0A FF 03 00 20 04 80 00 FF 00 00 C1 06 01 10 00 00 11 03 C2 06 01 10 00 00 11 03 C3 06 01 0C 00 00 11 03 C4 07 01 7F 7F 7F 03 00 03 C5 3C 03 53 CB 0B 67 EA AA DE 39 A5 B5 4F E8 D6 EC 89 1A 92 2C E4 03 FC FC B0 49 FF E3 97 33 7B 4B 3F F9 BE BB C9 CC B3 DE A9 52 6C E0 A2 9A C4 F6 B3 F6 D1 2B 67 BA DC AD FD C2 AC 5D 9F C6 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CD 0C 5F AE D1 4D 5F AE D1 4D 5F AE D1 4D 90 00 00000039 [140366762202880] winscard.c:1640:SCardTransmit() UnrefReader() count was: 200000019 [140366762202880] winscard_svc.c:685:ContextThread() TRANSMIT rv=0x0 for client 1400000196 [140366762202880] winscard_svc.c:361:ContextThread() Received command: TRANSMIT from client 1400000037 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000013 [140366762202880] winscard.c:1595:SCardTransmit() Send Protocol: T=100000013 [140366762202880] APDU: 00 CA 00 6E 00 00047564 [140366762202880] SW: 6E 81 D9 4F 10 D2 76 00 01 24 01 03 04 BE EF 00 00 00 00 00 07 5F 52 0A 00 C1 C5 73 C0 01 80 05 90 00 73 81 B7 C0 0A FF 03 00 20 04 80 00 FF 00 00 C1 06 01 10 00 00 11 03 C2 06 01 10 00 00 11 03 C3 06 01 0C 00 00 11 03 C4 07 01 7F 7F 7F 03 00 03 C5 3C 03 53 CB 0B 67 EA AA DE 39 A5 B5 4F E8 D6 EC 89 1A 92 2C E4 03 FC FC B0 49 FF E3 97 33 7B 4B 3F F9 BE BB C9 CC B3 DE A9 52 6C E0 A2 9A C4 F6 B3 F6 D1 2B 67 BA DC AD FD C2 AC 5D 9F C6 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CD 0C 5F AE D1 4D 5F AE D1 4D 5F AE D1 4D 90 00 00000028 [140366762202880] winscard.c:1640:SCardTransmit() UnrefReader() count was: 200000008 [140366762202880] winscard_svc.c:685:ContextThread() TRANSMIT rv=0x0 for client 1400000101 [140366762202880] winscard_svc.c:361:ContextThread() Received command: TRANSMIT from client 1400000016 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000005 [140366762202880] winscard.c:1595:SCardTransmit() Send Protocol: T=100000006 [140366762202880] APDU: 00 CA 00 6E 00 00047566 [140366762202880] SW: 6E 81 D9 4F 10 D2 76 00 01 24 01 03 04 BE EF 00 00 00 00 00 07 5F 52 0A 00 C1 C5 73 C0 01 80 05 90 00 73 81 B7 C0 0A FF 03 00 20 04 80 00 FF 00 00 C1 06 01 10 00 00 11 03 C2 06 01 10 00 00 11 03 C3 06 01 0C 00 00 11 03 C4 07 01 7F 7F 7F 03 00 03 C5 3C 03 53 CB 0B 67 EA AA DE 39 A5 B5 4F E8 D6 EC 89 1A 92 2C E4 03 FC FC B0 49 FF E3 97 33 7B 4B 3F F9 BE BB C9 CC B3 DE A9 52 6C E0 A2 9A C4 F6 B3 F6 D1 2B 67 BA DC AD FD C2 AC 5D 9F C6 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CD 0C 5F AE D1 4D 5F AE D1 4D 5F AE D1 4D 90 00 00000025 [140366762202880] winscard.c:1640:SCardTransmit() UnrefReader() count was: 200000007 [140366762202880] winscard_svc.c:685:ContextThread() TRANSMIT rv=0x0 for client 1400000208 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_WAIT_READER_STATE_CHANGE from client 1400000020 [140366762202880] winscard_svc.c:834:MSGSendReaderStates() Send reader states: 1400001122 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_STOP_WAITING_READER_STATE_CHANGE from client 1400000018 [140366762202880] winscard_svc.c:442:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 1400000052 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_WAIT_READER_STATE_CHANGE from client 1400000011 [140366762202880] winscard_svc.c:834:MSGSendReaderStates() Send reader states: 1400000085 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_STOP_WAITING_READER_STATE_CHANGE from client 1400000018 [140366762202880] winscard_svc.c:442:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 1400000618 [140366762202880] winscard_svc.c:361:ContextThread() Received command: TRANSMIT from client 1400000024 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000009 [140366762202880] winscard.c:1595:SCardTransmit() Send Protocol: T=100000009 [140366762202880] APDU: 00 CA 00 6E 00 00047574 [140366762202880] SW: 6E 81 D9 4F 10 D2 76 00 01 24 01 03 04 BE EF 00 00 00 00 00 07 5F 52 0A 00 C1 C5 73 C0 01 80 05 90 00 73 81 B7 C0 0A FF 03 00 20 04 80 00 FF 00 00 C1 06 01 10 00 00 11 03 C2 06 01 10 00 00 11 03 C3 06 01 0C 00 00 11 03 C4 07 01 7F 7F 7F 03 00 03 C5 3C 03 53 CB 0B 67 EA AA DE 39 A5 B5 4F E8 D6 EC 89 1A 92 2C E4 03 FC FC B0 49 FF E3 97 33 7B 4B 3F F9 BE BB C9 CC B3 DE A9 52 6C E0 A2 9A C4 F6 B3 F6 D1 2B 67 BA DC AD FD C2 AC 5D 9F C6 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CD 0C 5F AE D1 4D 5F AE D1 4D 5F AE D1 4D 90 00 00000029 [140366762202880] winscard.c:1640:SCardTransmit() UnrefReader() count was: 200000010 [140366762202880] winscard_svc.c:685:ContextThread() TRANSMIT rv=0x0 for client 1400002711 [140366762202880] winscard_svc.c:361:ContextThread() Received command: TRANSMIT from client 1400000022 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000008 [140366762202880] winscard.c:1595:SCardTransmit() Send Protocol: T=100000008 [140366762202880] APDU: 00 CA 00 7A 00 00015633 [140366762202880] SW: 93 03 00 00 05 90 00 00000021 [140366762202880] winscard.c:1640:SCardTransmit() UnrefReader() count was: 200000007 [140366762202880] winscard_svc.c:685:ContextThread() TRANSMIT rv=0x0 for client 1400000178 [140366762202880] winscard_svc.c:361:ContextThread() Received command: TRANSMIT from client 1400000023 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000009 [140366762202880] winscard.c:1595:SCardTransmit() Send Protocol: T=100000008 [140366762202880] APDU: 00 CA 00 C4 00 00017131 [140366762202880] SW: 01 7F 7F 7F 03 00 03 90 00 00000021 [140366762202880] winscard.c:1640:SCardTransmit() UnrefReader() count was: 200000007 [140366762202880] winscard_svc.c:685:ContextThread() TRANSMIT rv=0x0 for client 1400000097 [140366762202880] winscard_svc.c:361:ContextThread() Received command: TRANSMIT from client 1400000015 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000005 [140366762202880] winscard.c:1595:SCardTransmit() Send Protocol: T=100000005 [140366762202880] APDU: 00 CA 00 65 00 00018460 [140366762202880] SW: 5B 10 74 65 73 74 3C 3C 63 61 72 64 68 6F 6C 64 65 72 5F 2D 02 65 6E 5F 35 01 30 90 00 00000021 [140366762202880] winscard.c:1640:SCardTransmit() UnrefReader() count was: 200000007 [140366762202880] winscard_svc.c:685:ContextThread() TRANSMIT rv=0x0 for client 1400054002 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CONTROL from client 1400000060 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 103264154 [140366762202880] winscard.c:1359:SCardControl() UnrefReader() count was: 200000010 [140366762202880] winscard_svc.c:735:ContextThread() CONTROL rv=0x0 for client 1400000625 [140366762202880] winscard_svc.c:361:ContextThread() Received command: TRANSMIT from client 1400000009 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000002 [140366762202880] winscard.c:1595:SCardTransmit() Send Protocol: T=100000007 [140366762202880] APDU: 00 2A 9E 9A 53 30 51 30 0D 06 09 60 86 48 01 65 03 04 02 03 05 00 04 40 D7 32 A1 3D FB 5D 89 B4 50 AD E8 59 02 54 FF D0 D6 B9 EE F6 AF 53 E7 9A A9 1E 6A CC 2B D4 A0 2E EB 7F 7A 9C EA 90 2E 0D 0D B3 8D 71 C4 A9 3B BB F0 53 4A 8F 58 D4 0E 2F 5B 12 23 8C A4 55 AF 63 00 01108360 [140366762202880] SW: 0A 09 22 41 94 1A C4 5C AC 26 D2 E7 60 83 5B A1 C4 4D 0C 5A 57 FD 3D EC E8 73 30 44 89 11 09 CE A6 0C 95 A7 6C 80 EC 7C 3A 9B 5F B6 70 C5 D1 01 F4 D6 2E D1 AB 84 58 F3 48 3D D2 9A 75 C7 F2 15 D3 B6 28 43 63 0F 7B 7F 8D 4F D6 6C 5A 83 69 80 8B 0C 98 66 8A 9D 08 BE 91 98 3A 65 BF FE 64 9B 4C 23 83 C4 26 C1 F7 8E F5 9A 46 10 FE 05 05 FD 97 C1 8C A3 80 A1 97 F5 C3 82 AA 80 CA D9 DE FB DE 4A 9F 0A 87 49 6B A7 CE E6 74 3B 53 8D 0A FC C9 64 72 FC FB 01 06 97 39 1B A3 8B CE A8 43 6C DD E6 F1 B4 C3 C8 99 FC AC 89 22 CB 2C E4 58 00 4F C4 9F 19 45 35 D9 47 98 07 F1 13 6F E9 86 1E B2 42 25 D3 EE C9 01 53 89 FC BD FE B6 96 8B 07 42 BE 1E 68 84 B4 E7 39 CA CA E2 62 AF DC 0A 2B 85 D5 99 CE 44 33 6A 93 AF D4 32 10 F2 F4 DB 57 46 C4 57 76 57 9F F2 7F D6 E4 F8 03 01 64 61 22 61 FF 00000026 [140366762202880] winscard.c:1640:SCardTransmit() UnrefReader() count was: 200000012 [140366762202880] winscard_svc.c:685:ContextThread() TRANSMIT rv=0x0 for client 1400000150 [140366762202880] winscard_svc.c:361:ContextThread() Received command: TRANSMIT from client 1400000025 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000006 [140366762202880] winscard.c:1595:SCardTransmit() Send Protocol: T=100000007 [140366762202880] APDU: 00 C0 00 00 FF 00032566 [140366762202880] SW: 31 52 FF 43 66 DF 62 16 2E D1 50 91 18 4F B9 99 36 90 67 CC 9F A1 85 54 11 D4 4E 1A E5 F0 2E 88 E0 D1 CB 4F 45 9E 77 5D 1A 2C 8B 91 65 2D BB DA 97 92 F1 C3 17 87 43 52 06 EE FE FC B1 8B AC 48 C8 79 19 C0 C5 E6 3F C5 31 94 76 33 63 1D 1E B1 F5 8F CE 81 BA 49 3E 60 54 16 20 5E 9C 19 6F 6E 37 5E 96 81 9C 69 A2 E7 EF 5D E6 09 5D 42 C1 29 FC B6 90 7A 9D EA 91 89 16 4F 8E 1A F4 CB 3F 3D CE 9F 6B 72 6B A4 9A E9 25 DE AC AB 01 F7 82 F7 69 B3 B7 37 E9 2C 82 11 A1 51 03 22 FF 2A 12 B4 2D 54 E8 41 A8 63 F6 52 A4 AE 78 C3 26 A2 7F 50 0F 99 F7 A5 36 BD 44 94 0B 36 5C 9D DE CD 04 63 85 22 6E 8F 9A CB 98 18 3D 39 29 EC C6 4C 0C 7E AD 69 25 1E 1B 32 94 20 5F CA EE 1A C8 35 A6 2D C7 5D 6B 8A 46 FA C5 24 21 69 90 D5 64 4C 74 79 F2 C0 4E 12 5C EF 16 3E 9D 1F 65 E7 2C AF E2 61 01 00000033 [140366762202880] winscard.c:1640:SCardTransmit() UnrefReader() count was: 200000020 [140366762202880] winscard_svc.c:685:ContextThread() TRANSMIT rv=0x0 for client 1400000174 [140366762202880] winscard_svc.c:361:ContextThread() Received command: TRANSMIT from client 1400000036 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000010 [140366762202880] winscard.c:1595:SCardTransmit() Send Protocol: T=100000009 [140366762202880] APDU: 00 C0 00 00 01 00010334 [140366762202880] SW: F6 90 00 00000019 [140366762202880] winscard.c:1640:SCardTransmit() UnrefReader() count was: 200000007 [140366762202880] winscard_svc.c:685:ContextThread() TRANSMIT rv=0x0 for client 1400000191 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_WAIT_READER_STATE_CHANGE from client 1400000019 [140366762202880] winscard_svc.c:834:MSGSendReaderStates() Send reader states: 1400001105 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_STOP_WAITING_READER_STATE_CHANGE from client 1400000019 [140366762202880] winscard_svc.c:442:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 1400000107 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_WAIT_READER_STATE_CHANGE from client 1400000021 [140366762202880] winscard_svc.c:834:MSGSendReaderStates() Send reader states: 1400000114 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_STOP_WAITING_READER_STATE_CHANGE from client 1400000020 [140366762202880] winscard_svc.c:442:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 1400500705 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_WAIT_READER_STATE_CHANGE from client 1400000036 [140366762202880] winscard_svc.c:834:MSGSendReaderStates() Send reader states: 1400001120 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_STOP_WAITING_READER_STATE_CHANGE from client 1400000028 [140366762202880] winscard_svc.c:442:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 1400000135 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_WAIT_READER_STATE_CHANGE from client 1400000030 [140366762202880] winscard_svc.c:834:MSGSendReaderStates() Send reader states: 1400000124 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_STOP_WAITING_READER_STATE_CHANGE from client 1400000021 [140366762202880] winscard_svc.c:442:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 1400500611 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_WAIT_READER_STATE_CHANGE from client 1400000026 [140366762202880] winscard_svc.c:834:MSGSendReaderStates() Send reader states: 1400001131 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_STOP_WAITING_READER_STATE_CHANGE from client 1400000021 [140366762202880] winscard_svc.c:442:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 1400000129 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_WAIT_READER_STATE_CHANGE from client 1400000018 [140366762202880] winscard_svc.c:834:MSGSendReaderStates() Send reader states: 1400000128 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_STOP_WAITING_READER_STATE_CHANGE from client 1400000019 [140366762202880] winscard_svc.c:442:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 1400500680 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_WAIT_READER_STATE_CHANGE from client 1400000026 [140366762202880] winscard_svc.c:834:MSGSendReaderStates() Send reader states: 1400001103 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_STOP_WAITING_READER_STATE_CHANGE from client 1400000020 [140366762202880] winscard_svc.c:442:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 1400000058 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_WAIT_READER_STATE_CHANGE from client 1400000013 [140366762202880] winscard_svc.c:834:MSGSendReaderStates() Send reader states: 1400000089 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_STOP_WAITING_READER_STATE_CHANGE from client 1400000019 [140366762202880] winscard_svc.c:442:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 1400500656 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_WAIT_READER_STATE_CHANGE from client 1400000023 [140366762202880] winscard_svc.c:834:MSGSendReaderStates() Send reader states: 1400001129 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_STOP_WAITING_READER_STATE_CHANGE from client 1400000018 [140366762202880] winscard_svc.c:442:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 1400000123 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_WAIT_READER_STATE_CHANGE from client 1400000017 [140366762202880] winscard_svc.c:834:MSGSendReaderStates() Send reader states: 1400000124 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_STOP_WAITING_READER_STATE_CHANGE from client 1400000018 [140366762202880] winscard_svc.c:442:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 1400500619 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_WAIT_READER_STATE_CHANGE from client 1400000012 [140366762202880] winscard_svc.c:834:MSGSendReaderStates() Send reader states: 1400001021 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_STOP_WAITING_READER_STATE_CHANGE from client 1400000005 [140366762202880] winscard_svc.c:442:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 1400000080 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_WAIT_READER_STATE_CHANGE from client 1400000018 [140366762202880] winscard_svc.c:834:MSGSendReaderStates() Send reader states: 1400000014 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_STOP_WAITING_READER_STATE_CHANGE from client 1400000003 [140366762202880] winscard_svc.c:442:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 1400500696 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_WAIT_READER_STATE_CHANGE from client 1400000039 [140366762202880] winscard_svc.c:834:MSGSendReaderStates() Send reader states: 1400001204 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_STOP_WAITING_READER_STATE_CHANGE from client 1400000027 [140366762202880] winscard_svc.c:442:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 1400000177 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_WAIT_READER_STATE_CHANGE from client 1400000026 [140366762202880] winscard_svc.c:834:MSGSendReaderStates() Send reader states: 1400000155 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_STOP_WAITING_READER_STATE_CHANGE from client 1400000026 [140366762202880] winscard_svc.c:442:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 1400500638 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_WAIT_READER_STATE_CHANGE from client 1400000027 [140366762202880] winscard_svc.c:834:MSGSendReaderStates() Send reader states: 1400001121 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_STOP_WAITING_READER_STATE_CHANGE from client 1400000026 [140366762202880] winscard_svc.c:442:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 1400000062 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_WAIT_READER_STATE_CHANGE from client 1400000017 [140366762202880] winscard_svc.c:834:MSGSendReaderStates() Send reader states: 1400000145 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_STOP_WAITING_READER_STATE_CHANGE from client 1400000029 [140366762202880] winscard_svc.c:442:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 1400044124 [140366770595584] eventhandler.c:358:EHStatusHandlerThread() Card Removed From REINER SCT cyberJack RFID standard (9934036502) 00 0000456534 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_WAIT_READER_STATE_CHANGE from client 1400000027 [140366762202880] winscard_svc.c:834:MSGSendReaderStates() Send reader states: 1400000106 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_STOP_WAITING_READER_STATE_CHANGE from client 1400000022 [140366762202880] winscard_svc.c:442:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 1400000328 [140366762202880] winscard_svc.c:361:ContextThread() Received command: DISCONNECT from client 1400000024 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000007 [140366762202880] winscard.c:881:SCardDisconnect() Active Contexts: -100000005 [140366762202880] winscard.c:882:SCardDisconnect() dwDisposition: 000000005 [140366762202880] winscard.c:1017:SCardDisconnect() powerState: POWER_STATE_GRACE_PERIOD00000011 [140366762202880] winscard.c:1043:SCardDisconnect() UnrefReader() count was: 200000010 [140366762202880] winscard_svc.c:550:ContextThread() DISCONNECT rv=0x0 for client 1400000064 [140366762202880] winscard_svc.c:361:ContextThread() Received command: RELEASE_CONTEXT from client 1400000012 [140366762202880] winscard.c:229:SCardReleaseContext() Releasing Context: 0xA6D81FD00000005 [140366762202880] winscard_svc.c:476:ContextThread() RELEASE_CONTEXT rv=0x0 for client 1400000036 [140366762202880] winscard_svc.c:354:ContextThread() Client die: 1400000025 [140366762202880] winscard_svc.c:1055:MSGCleanupClient() Thread is stopping: dwClientID=14, threadContext @0x560a0ee01f2000000007 [140366762202880] winscard_svc.c:1063:MSGCleanupClient() Freeing SCONTEXT @0x560a0ee01f2000343238 [140366770595584] eventhandler.c:494:EHStatusHandlerThread() powerState: POWER_STATE_POWERED00400571 [140366770595584] eventhandler.c:482:EHStatusHandlerThread() powerState: POWER_STATE_UNPOWERED00170077 [140366770595584] eventhandler.c:406:EHStatusHandlerThread() powerState: POWER_STATE_POWERED00000017 [140366770595584] eventhandler.c:423:EHStatusHandlerThread() Card inserted into REINER SCT cyberJack RFID standard (9934036502) 00 0000000008 [140366770595584] Card ATR: 3B 80 80 01 01 00400587 [140366770595584] eventhandler.c:482:EHStatusHandlerThread() powerState: POWER_STATE_UNPOWERED01123888 [140366874249152] winscard_msg_srv.c:256:ProcessEventsServer() Common channel packet arrival00000021 [140366874249152] winscard_msg_srv.c:267:ProcessEventsServer() ProcessCommonChannelRequest detects: 1400000006 [140366874249152] pcscdaemon.c:133:SVCServiceRunLoop() A new context thread creation is requested: 1400000143 [140366762202880] winscard_svc.c:340:ContextThread() Authorized PC/SC client00000015 [140366762202880] winscard_svc.c:343:ContextThread() Thread is started: dwClientID=14, threadContext @0x560a0ee01f2000000011 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_VERSION from client 1400000006 [140366762202880] winscard_svc.c:373:ContextThread() Client is protocol version 4:400000004 [140366762202880] winscard_svc.c:396:ContextThread() CMD_VERSION rv=0x0 for client 1400000038 [140366762202880] winscard_svc.c:361:ContextThread() Received command: ESTABLISH_CONTEXT from client 1400000013 [140366762202880] winscard.c:215:SCardEstablishContext() Establishing Context: 0xF640E7B00000004 [140366762202880] winscard_svc.c:461:ContextThread() ESTABLISH_CONTEXT rv=0x0 for client 1400000031 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_GET_READERS_STATE from client 1400000037 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_GET_READERS_STATE from client 1400000066 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CONNECT from client 1400000011 [140366762202880] winscard_svc.c:499:ContextThread() Authorized client for 'REINER SCT cyberJack RFID standard (9934036502) 00 00'00000004 [140366762202880] winscard.c:258:SCardConnect() Attempting Connect to REINER SCT cyberJack RFID standard (9934036502) 00 00 using protocol: 300000004 [140366762202880] readerfactory.c:821:RFReaderInfo() RefReader() count was: 100170139 [140366762202880] winscard.c:332:SCardConnect() power up complete.00000016 [140366762202880] Card ATR: 3B 80 80 01 01 00000003 [140366762202880] winscard.c:352:SCardConnect() powerState: POWER_STATE_IN_USE00000007 [140366762202880] prothandler.c:107:PHSetProtocol() Attempting PTS to T=100000010 [140366762202880] winscard.c:430:SCardConnect() Active Protocol: T=100000005 [140366762202880] winscard.c:456:SCardConnect() hCard Identity: 6cc0d62600000007 [140366762202880] winscard.c:518:SCardConnect() UnrefReader() count was: 200000008 [140366762202880] winscard_svc.c:513:ContextThread() CONNECT rv=0x0 for client 1400000044 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CONTROL from client 1400000008 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000173 [140366762202880] winscard.c:1359:SCardControl() UnrefReader() count was: 200000010 [140366762202880] winscard_svc.c:735:ContextThread() CONTROL rv=0x0 for client 1400000031 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_GET_READERS_STATE from client 1400000036 [140366762202880] winscard_svc.c:361:ContextThread() Received command: STATUS from client 1400000008 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000003 [140366762202880] winscard.c:1300:SCardStatus() UnrefReader() count was: 200000002 [140366762202880] winscard_svc.c:632:ContextThread() STATUS rv=0x0 for client 1400000021 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_WAIT_READER_STATE_CHANGE from client 1400000005 [140366762202880] winscard_svc.c:834:MSGSendReaderStates() Send reader states: 1400000019 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_STOP_WAITING_READER_STATE_CHANGE from client 1400000006 [140366762202880] winscard_svc.c:442:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 1400000024 [140366762202880] winscard_svc.c:361:ContextThread() Received command: TRANSMIT from client 1400000008 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000004 [140366762202880] winscard.c:1595:SCardTransmit() Send Protocol: T=100000006 [140366762202880] APDU: 00 A4 00 0C 02 3F 00 00024905 [140366762202880] SW: 6A 86 00000032 [140366762202880] winscard.c:1640:SCardTransmit() UnrefReader() count was: 200000018 [140366762202880] winscard_svc.c:685:ContextThread() TRANSMIT rv=0x0 for client 1400000169 [140366762202880] winscard_svc.c:361:ContextThread() Received command: TRANSMIT from client 1400000044 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000014 [140366762202880] winscard.c:1595:SCardTransmit() Send Protocol: T=100000015 [140366762202880] APDU: 00 A4 04 00 06 D2 76 00 01 24 01 00015151 [140366762202880] SW: 90 00 00000034 [140366762202880] winscard.c:1640:SCardTransmit() UnrefReader() count was: 200000015 [140366762202880] winscard_svc.c:685:ContextThread() TRANSMIT rv=0x0 for client 1400000178 [140366762202880] winscard_svc.c:361:ContextThread() Received command: TRANSMIT from client 1400000040 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000019 [140366762202880] winscard.c:1595:SCardTransmit() Send Protocol: T=100000017 [140366762202880] APDU: 00 CA 00 4F 00 00015945 [140366762202880] SW: D2 76 00 01 24 01 03 04 BE EF 00 00 00 00 00 07 90 00 00000017 [140366762202880] winscard.c:1640:SCardTransmit() UnrefReader() count was: 200000009 [140366762202880] winscard_svc.c:685:ContextThread() TRANSMIT rv=0x0 for client 1400000143 [140366762202880] winscard_svc.c:361:ContextThread() Received command: TRANSMIT from client 1400000018 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000005 [140366762202880] winscard.c:1595:SCardTransmit() Send Protocol: T=100000005 [140366762202880] APDU: 00 CA 5F 52 00 00015242 [140366762202880] SW: 00 C1 C5 73 C0 01 80 05 90 00 90 00 00000019 [140366762202880] winscard.c:1640:SCardTransmit() UnrefReader() count was: 200000011 [140366762202880] winscard_svc.c:685:ContextThread() TRANSMIT rv=0x0 for client 1400000110 [140366762202880] winscard_svc.c:361:ContextThread() Received command: TRANSMIT from client 1400000018 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000005 [140366762202880] winscard.c:1595:SCardTransmit() Send Protocol: T=100000007 [140366762202880] APDU: 00 CA 00 C4 00 00016816 [140366762202880] SW: 01 7F 7F 7F 03 00 03 90 00 00000017 [140366762202880] winscard.c:1640:SCardTransmit() UnrefReader() count was: 200000007 [140366762202880] winscard_svc.c:685:ContextThread() TRANSMIT rv=0x0 for client 1400000104 [140366762202880] winscard_svc.c:361:ContextThread() Received command: TRANSMIT from client 1400000015 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000006 [140366762202880] winscard.c:1595:SCardTransmit() Send Protocol: T=100000005 [140366762202880] APDU: 00 CA 00 6E 00 00032907 [140366762202880] SW: 6E 81 D9 4F 10 D2 76 00 01 24 01 03 04 BE EF 00 00 00 00 00 07 5F 52 0A 00 C1 C5 73 C0 01 80 05 90 00 73 81 B7 C0 0A FF 03 00 20 04 80 00 FF 00 00 C1 06 01 10 00 00 11 03 C2 06 01 10 00 00 11 03 C3 06 01 0C 00 00 11 03 C4 07 01 7F 7F 7F 03 00 03 C5 3C 03 53 CB 0B 67 EA AA DE 39 A5 B5 4F E8 D6 EC 89 1A 92 2C E4 03 FC FC B0 49 FF E3 97 33 7B 4B 3F F9 BE BB C9 CC B3 DE A9 52 6C E0 A2 9A C4 F6 B3 F6 D1 2B 67 BA DC AD FD C2 AC 5D 9F C6 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CD 0C 5F AE D1 4D 5F AE D1 4D 5F AE D1 4D 90 00 00000025 [140366762202880] winscard.c:1640:SCardTransmit() UnrefReader() count was: 200000008 [140366762202880] winscard_svc.c:685:ContextThread() TRANSMIT rv=0x0 for client 1400000098 [140366762202880] winscard_svc.c:361:ContextThread() Received command: TRANSMIT from client 1400000017 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000006 [140366762202880] winscard.c:1595:SCardTransmit() Send Protocol: T=100000006 [140366762202880] APDU: 00 CA 7F 74 00 00013046 [140366762202880] SW: 6A 88 00000015 [140366762202880] winscard.c:1640:SCardTransmit() UnrefReader() count was: 200000006 [140366762202880] winscard_svc.c:685:ContextThread() TRANSMIT rv=0x0 for client 1400000127 [140366762202880] winscard_svc.c:361:ContextThread() Received command: TRANSMIT from client 1400000019 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000005 [140366762202880] winscard.c:1595:SCardTransmit() Send Protocol: T=100000005 [140366762202880] APDU: 00 CA 00 5E 00 00011872 [140366762202880] SW: 90 00 00000015 [140366762202880] winscard.c:1640:SCardTransmit() UnrefReader() count was: 200000006 [140366762202880] winscard_svc.c:685:ContextThread() TRANSMIT rv=0x0 for client 1400000117 [140366762202880] winscard_svc.c:361:ContextThread() Received command: TRANSMIT from client 1400000018 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000005 [140366762202880] winscard.c:1595:SCardTransmit() Send Protocol: T=100000005 [140366762202880] APDU: 00 CA 00 6E 00 00032903 [140366762202880] SW: 6E 81 D9 4F 10 D2 76 00 01 24 01 03 04 BE EF 00 00 00 00 00 07 5F 52 0A 00 C1 C5 73 C0 01 80 05 90 00 73 81 B7 C0 0A FF 03 00 20 04 80 00 FF 00 00 C1 06 01 10 00 00 11 03 C2 06 01 10 00 00 11 03 C3 06 01 0C 00 00 11 03 C4 07 01 7F 7F 7F 03 00 03 C5 3C 03 53 CB 0B 67 EA AA DE 39 A5 B5 4F E8 D6 EC 89 1A 92 2C E4 03 FC FC B0 49 FF E3 97 33 7B 4B 3F F9 BE BB C9 CC B3 DE A9 52 6C E0 A2 9A C4 F6 B3 F6 D1 2B 67 BA DC AD FD C2 AC 5D 9F C6 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CD 0C 5F AE D1 4D 5F AE D1 4D 5F AE D1 4D 90 00 00000026 [140366762202880] winscard.c:1640:SCardTransmit() UnrefReader() count was: 200000008 [140366762202880] winscard_svc.c:685:ContextThread() TRANSMIT rv=0x0 for client 1400000103 [140366762202880] winscard_svc.c:361:ContextThread() Received command: TRANSMIT from client 1400000016 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000007 [140366762202880] winscard.c:1595:SCardTransmit() Send Protocol: T=100000006 [140366762202880] APDU: 00 CA 00 6E 00 00032934 [140366762202880] SW: 6E 81 D9 4F 10 D2 76 00 01 24 01 03 04 BE EF 00 00 00 00 00 07 5F 52 0A 00 C1 C5 73 C0 01 80 05 90 00 73 81 B7 C0 0A FF 03 00 20 04 80 00 FF 00 00 C1 06 01 10 00 00 11 03 C2 06 01 10 00 00 11 03 C3 06 01 0C 00 00 11 03 C4 07 01 7F 7F 7F 03 00 03 C5 3C 03 53 CB 0B 67 EA AA DE 39 A5 B5 4F E8 D6 EC 89 1A 92 2C E4 03 FC FC B0 49 FF E3 97 33 7B 4B 3F F9 BE BB C9 CC B3 DE A9 52 6C E0 A2 9A C4 F6 B3 F6 D1 2B 67 BA DC AD FD C2 AC 5D 9F C6 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CD 0C 5F AE D1 4D 5F AE D1 4D 5F AE D1 4D 90 00 00000019 [140366762202880] winscard.c:1640:SCardTransmit() UnrefReader() count was: 200000006 [140366762202880] winscard_svc.c:685:ContextThread() TRANSMIT rv=0x0 for client 1400000129 [140366762202880] winscard_svc.c:361:ContextThread() Received command: TRANSMIT from client 1400000019 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000005 [140366762202880] winscard.c:1595:SCardTransmit() Send Protocol: T=100000004 [140366762202880] APDU: 00 CA 00 6E 00 00032916 [140366762202880] SW: 6E 81 D9 4F 10 D2 76 00 01 24 01 03 04 BE EF 00 00 00 00 00 07 5F 52 0A 00 C1 C5 73 C0 01 80 05 90 00 73 81 B7 C0 0A FF 03 00 20 04 80 00 FF 00 00 C1 06 01 10 00 00 11 03 C2 06 01 10 00 00 11 03 C3 06 01 0C 00 00 11 03 C4 07 01 7F 7F 7F 03 00 03 C5 3C 03 53 CB 0B 67 EA AA DE 39 A5 B5 4F E8 D6 EC 89 1A 92 2C E4 03 FC FC B0 49 FF E3 97 33 7B 4B 3F F9 BE BB C9 CC B3 DE A9 52 6C E0 A2 9A C4 F6 B3 F6 D1 2B 67 BA DC AD FD C2 AC 5D 9F C6 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CD 0C 5F AE D1 4D 5F AE D1 4D 5F AE D1 4D 90 00 00000022 [140366762202880] winscard.c:1640:SCardTransmit() UnrefReader() count was: 200000006 [140366762202880] winscard_svc.c:685:ContextThread() TRANSMIT rv=0x0 for client 1400000104 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_WAIT_READER_STATE_CHANGE from client 1400000018 [140366762202880] winscard_svc.c:834:MSGSendReaderStates() Send reader states: 1400001089 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_STOP_WAITING_READER_STATE_CHANGE from client 1400000015 [140366762202880] winscard_svc.c:442:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 1400000040 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_WAIT_READER_STATE_CHANGE from client 1400000009 [140366762202880] winscard_svc.c:834:MSGSendReaderStates() Send reader states: 1400000109 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_STOP_WAITING_READER_STATE_CHANGE from client 1400000014 [140366762202880] winscard_svc.c:442:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 1400000567 [140366762202880] winscard_svc.c:361:ContextThread() Received command: TRANSMIT from client 1400000019 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000005 [140366762202880] winscard.c:1595:SCardTransmit() Send Protocol: T=100000005 [140366762202880] APDU: 00 CA 00 6E 00 00033060 [140366762202880] SW: 6E 81 D9 4F 10 D2 76 00 01 24 01 03 04 BE EF 00 00 00 00 00 07 5F 52 0A 00 C1 C5 73 C0 01 80 05 90 00 73 81 B7 C0 0A FF 03 00 20 04 80 00 FF 00 00 C1 06 01 10 00 00 11 03 C2 06 01 10 00 00 11 03 C3 06 01 0C 00 00 11 03 C4 07 01 7F 7F 7F 03 00 03 C5 3C 03 53 CB 0B 67 EA AA DE 39 A5 B5 4F E8 D6 EC 89 1A 92 2C E4 03 FC FC B0 49 FF E3 97 33 7B 4B 3F F9 BE BB C9 CC B3 DE A9 52 6C E0 A2 9A C4 F6 B3 F6 D1 2B 67 BA DC AD FD C2 AC 5D 9F C6 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CD 0C 5F AE D1 4D 5F AE D1 4D 5F AE D1 4D 90 00 00000024 [140366762202880] winscard.c:1640:SCardTransmit() UnrefReader() count was: 200000006 [140366762202880] winscard_svc.c:685:ContextThread() TRANSMIT rv=0x0 for client 1400466806 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_WAIT_READER_STATE_CHANGE from client 1400000032 [140366762202880] winscard_svc.c:834:MSGSendReaderStates() Send reader states: 1400001150 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_STOP_WAITING_READER_STATE_CHANGE from client 1400000028 [140366762202880] winscard_svc.c:442:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 1400000146 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_WAIT_READER_STATE_CHANGE from client 1400000027 [140366762202880] winscard_svc.c:834:MSGSendReaderStates() Send reader states: 1400000145 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_STOP_WAITING_READER_STATE_CHANGE from client 1400000027 [140366762202880] winscard_svc.c:442:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 1400400686 [140366762202880] winscard_svc.c:361:ContextThread() Received command: TRANSMIT from client 1400000045 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000018 [140366762202880] winscard.c:1595:SCardTransmit() Send Protocol: T=100000017 [140366762202880] APDU: 00 CA 00 7A 00 00015576 [140366762202880] SW: 93 03 00 00 06 90 00 00000030 [140366762202880] winscard.c:1640:SCardTransmit() UnrefReader() count was: 200000019 [140366762202880] winscard_svc.c:685:ContextThread() TRANSMIT rv=0x0 for client 1400000217 [140366762202880] winscard_svc.c:361:ContextThread() Received command: TRANSMIT from client 1400000038 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000014 [140366762202880] winscard.c:1595:SCardTransmit() Send Protocol: T=100000015 [140366762202880] APDU: 00 CA 00 C4 00 00016894 [140366762202880] SW: 01 7F 7F 7F 03 00 03 90 00 00000027 [140366762202880] winscard.c:1640:SCardTransmit() UnrefReader() count was: 200000015 [140366762202880] winscard_svc.c:685:ContextThread() TRANSMIT rv=0x0 for client 1400000141 [140366762202880] winscard_svc.c:361:ContextThread() Received command: TRANSMIT from client 1400000021 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000012 [140366762202880] winscard.c:1595:SCardTransmit() Send Protocol: T=100000014 [140366762202880] APDU: 00 CA 00 65 00 00017052 [140366762202880] SW: 5B 10 74 65 73 74 3C 3C 63 61 72 64 68 6F 6C 64 65 72 5F 2D 02 65 6E 5F 35 01 30 90 00 00000015 [140366762202880] winscard.c:1640:SCardTransmit() UnrefReader() count was: 200000005 [140366762202880] winscard_svc.c:685:ContextThread() TRANSMIT rv=0x0 for client 1400048211 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CONTROL from client 1400000016 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000849 [140366762202880] winscard.c:1359:SCardControl() UnrefReader() count was: 200000013 [140366762202880] winscard_svc.c:735:ContextThread() CONTROL rv=0x0 for client 1400000718 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_WAIT_READER_STATE_CHANGE from client 1400000016 [140366762202880] winscard_svc.c:834:MSGSendReaderStates() Send reader states: 1400001065 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_STOP_WAITING_READER_STATE_CHANGE from client 1400000012 [140366762202880] winscard_svc.c:442:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 1400000026 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_WAIT_READER_STATE_CHANGE from client 14```

Also there exists another issue, for example when my admin PIN is made up of characters I have no way of inputing it from the reader's pinentry and I know of no wha to switch to the on-screen pinentry




Thank You for your help,
 22h49
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20201113/d24e97eb/attachment-0001.html>

From juergen at bruckner.email  Sat Nov 14 11:22:22 2020
From: juergen at bruckner.email (Juergen Bruckner)
Date: Sat, 14 Nov 2020 11:22:22 +0100
Subject: Major problems with gpg and scdaemon, help highly appriciated
In-Reply-To: <MM22ib4--B-2@tutanota.com>
References: <MM22ib4--B-2@tutanota.com>
Message-ID: <31358caf-53ce-c083-4f26-9fcf9c33307a@bruckner.email>


Hello 22h49

Am 13.11.20 um 20:22 schrieb 22h39 via Gnupg-users:
> 
> I have been for the life of me unable to get gpg working with the contactless interface in my reader.
> 
> 
> How to reproduce:
> 
> I'm using a REINERSCT Cyberjack standard RFID dual interface class 3 reader
> Simply take a Openpgp card and try to sign anything using the contactless interface.
> 

As far as I know the OpenPGP function of the OpenPGP-Card cannot be used 
via NFC / RFID. You need to use the on card chip and a card reader for 
PGP operations.

regards
Juergen

-- 
/?\   No  |
\ /  HTML |    Juergen Bruckner
  X    in  |    juergen at bruckner.email
/ \  Mail |

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3894 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20201114/df04f59d/attachment.bin>

From wk at gnupg.org  Sat Nov 14 14:38:19 2020
From: wk at gnupg.org (Werner Koch)
Date: Sat, 14 Nov 2020 14:38:19 +0100
Subject: Major problems with gpg and scdaemon, help highly appriciated
In-Reply-To: <31358caf-53ce-c083-4f26-9fcf9c33307a@bruckner.email> (Juergen
 Bruckner via Gnupg-users's message of "Sat, 14 Nov 2020 11:22:22
 +0100")
References: <MM22ib4--B-2@tutanota.com>
 <31358caf-53ce-c083-4f26-9fcf9c33307a@bruckner.email>
Message-ID: <87lff4oy7o.fsf@wheatstone.g10code.de>

On Sat, 14 Nov 2020 11:22, Juergen Bruckner said:

> As far as I know the OpenPGP function of the OpenPGP-Card cannot be
> used via NFC / RFID. You need to use the on card chip and a card

In fact GnuPG does not support secure messaging and thus using the
contactless interface iwould be a security problem.


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/20201114/49103637/attachment.sig>

From 22h39 at tutanota.com  Sat Nov 14 19:45:54 2020
From: 22h39 at tutanota.com (22h39)
Date: Sat, 14 Nov 2020 19:45:54 +0100 (CET)
Subject: Major problems with gpg and scdaemon, help highly appriciated
In-Reply-To: <MM22ib4--B-2@tutanota.com>
References: <MM22ib4--B-2@tutanota.com>
Message-ID: <MM73zcN--F-2@tutanota.com>

I don't understand, then how is OpenKeychain able to use OpenPGP cards via RFID?

I can sucessfully sign using this card via my phone but It won't work with the reader connected to the computer.

Looking at the logs, the card exchanges exactly the same apdus when using the contact and contactless interface so all points to some weird bug in gpg.

Thanks for help,
22h49
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20201114/b6c740ac/attachment.html>

From juergen at bruckner.email  Sat Nov 14 19:58:51 2020
From: juergen at bruckner.email (Juergen Bruckner)
Date: Sat, 14 Nov 2020 19:58:51 +0100
Subject: Major problems with gpg and scdaemon, help highly appriciated
In-Reply-To: <MM73zcN--F-2@tutanota.com>
References: <MM22ib4--B-2@tutanota.com> <MM73zcN--F-2@tutanota.com>
Message-ID: <3acfebb5-7868-a111-b08f-b6fa2480c05d@bruckner.email>

What kind of OpenPGP card do you use?
The OpenPGP Smart Card V3.3 + MiFare DESFire [1] don't support PGP 
operations via RFID.

regards
Juergen

[1] 
https://www.floss-shop.de/en/security-privacy/smartcards/4/openpgp-smart-card-v3.3-mifare-desfire
--
/?\   No  |
\ /  HTML |    Juergen Bruckner
  X    in  |    juergen at bruckner.email
/ \  Mail |

Am 14.11.20 um 19:45 schrieb 22h39 via Gnupg-users:
> I don't understand, then how is OpenKeychain able to use OpenPGP cards via RFID?
> 
> I can sucessfully sign using this card via my phone but It won't work with the reader connected to the computer.
> 
> Looking at the logs, the card exchanges exactly the same apdus when using the contact and contactless interface so all points to some weird bug in gpg.
> 
> Thanks for help,
> 22h49
> 
> 
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3894 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20201114/f8958575/attachment.bin>

From 22h39 at tutanota.com  Sat Nov 14 20:08:27 2020
From: 22h39 at tutanota.com (22h39)
Date: Sat, 14 Nov 2020 20:08:27 +0100 (CET)
Subject: Major problems with gpg and scdaemon, help highly appriciated
In-Reply-To: <3acfebb5-7868-a111-b08f-b6fa2480c05d@bruckner.email>
References: <MM22ib4--B-2@tutanota.com> <MM73zcN--F-2@tutanota.com>
 <3acfebb5-7868-a111-b08f-b6fa2480c05d@bruckner.email>
Message-ID: <MM798zs--3-2@tutanota.com>

Sorry Jorgen for the mail I missclicked.

As can be seen in the logs I'm using a NXP J3H145 card with this applet: https://github.com/ANSSI-FR/SmartPGP which is compliant with OpenPGP spec V3.4.

I can assure that this card __works__ via RFID since I can easily sign files using it and OpenKeychain on my phone, the problem here is created by GPG in conjunction with the reader.

Thanks for help,
22h49



Nov 14, 2020, 19:58 by gnupg-users at gnupg.org:

> What kind of OpenPGP card do you use?
> The OpenPGP Smart Card V3.3 + MiFare DESFire [1] don't support PGP operations via RFID.
>
> regards
> Juergen
>
> [1] https://www.floss-shop.de/en/security-privacy/smartcards/4/openpgp-smart-card-v3.3-mifare-desfire
> --
> /?\   No  |
> \ /  HTML |    Juergen Bruckner
>  X    in  |    juergen at bruckner.email
> / \  Mail |
>
> Am 14.11.20 um 19:45 schrieb 22h39 via Gnupg-users:
>
>> I don't understand, then how is OpenKeychain able to use OpenPGP cards via RFID?
>>
>> I can sucessfully sign using this card via my phone but It won't work with the reader connected to the computer.
>>
>> Looking at the logs, the card exchanges exactly the same apdus when using the contact and contactless interface so all points to some weird bug in gpg.
>>
>> Thanks for help,
>> 22h49
>>
>>
>> _______________________________________________
>> Gnupg-users mailing list
>> Gnupg-users at gnupg.org
>> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20201114/6fb16bb3/attachment-0001.html>

From juergen at bruckner.email  Sat Nov 14 20:39:43 2020
From: juergen at bruckner.email (Juergen Bruckner)
Date: Sat, 14 Nov 2020 20:39:43 +0100
Subject: Major problems with gpg and scdaemon, help highly appriciated
In-Reply-To: <MM798zs--3-2@tutanota.com>
References: <MM22ib4--B-2@tutanota.com> <MM73zcN--F-2@tutanota.com>
 <3acfebb5-7868-a111-b08f-b6fa2480c05d@bruckner.email>
 <MM798zs--3-2@tutanota.com>
Message-ID: <c57cb647-72fe-1e07-433a-33f99b3d7755@bruckner.email>

No problem!

I see.
Well I don't have any experiences with other cards than these from 
Zeitcontrol and the tokens from Yubikey and Nitrokey.
I know that the Yubikey5 supports PGP operations via RFID as a few 
customers from me use it with their mobile devices.

But as Werner stated in his e-mail before it may be a 'problem' specific 
with GnuPG as it doesn't support wireless operation for security reasons.

And I really don't know if another OpenPGP implementation does support 
smartcards/token.
This was already a big issue with Mozilla's Thunderbird 78 and it's 
native implementation of OpenPGP instead of Enigmail.

Sorry that I can't help in a better way!

best regards and a great weekend
Juergen

-- 
/?\   No  |
\ /  HTML |    Juergen Bruckner
  X    in  |    juergen at bruckner.email
/ \  Mail |

Am 14.11.20 um 20:08 schrieb 22h39 via Gnupg-users:
> Sorry Jorgen for the mail I missclicked.
> 
> As can be seen in the logs I'm using a NXP J3H145 card with this applet: https://github.com/ANSSI-FR/SmartPGP which is compliant with OpenPGP spec V3.4.
> 
> I can assure that this card __works__ via RFID since I can easily sign files using it and OpenKeychain on my phone, the problem here is created by GPG in conjunction with the reader.
> 
> Thanks for help,
> 22h49
> 
> 
> 
> Nov 14, 2020, 19:58 by gnupg-users at gnupg.org:
> 
>> What kind of OpenPGP card do you use?
>> The OpenPGP Smart Card V3.3 + MiFare DESFire [1] don't support PGP operations via RFID.
>>
>> regards
>> Juergen
>>
>> [1] https://www.floss-shop.de/en/security-privacy/smartcards/4/openpgp-smart-card-v3.3-mifare-desfire
>> --
>> /?\   No  |
>> \ /  HTML |    Juergen Bruckner
>>   X    in  |    juergen at bruckner.email
>> / \  Mail |
>>
>> Am 14.11.20 um 19:45 schrieb 22h39 via Gnupg-users:
>>
>>> I don't understand, then how is OpenKeychain able to use OpenPGP cards via RFID?
>>>
>>> I can sucessfully sign using this card via my phone but It won't work with the reader connected to the computer.
>>>
>>> Looking at the logs, the card exchanges exactly the same apdus when using the contact and contactless interface so all points to some weird bug in gpg.
>>>
>>> Thanks for help,
>>> 22h49
>>>
>>>
>>> _______________________________________________
>>> Gnupg-users mailing list
>>> Gnupg-users at gnupg.org
>>> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>>>
> 
> 
> 
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3894 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20201114/566f394a/attachment.bin>

From 22h39 at tutanota.com  Sat Nov 14 21:28:58 2020
From: 22h39 at tutanota.com (22h39)
Date: Sat, 14 Nov 2020 21:28:58 +0100 (CET)
Subject: Major problems with gpg and scdaemon, help highly appriciated
In-Reply-To: <c57cb647-72fe-1e07-433a-33f99b3d7755@bruckner.email>
References: <MM22ib4--B-2@tutanota.com> <MM73zcN--F-2@tutanota.com>
 <3acfebb5-7868-a111-b08f-b6fa2480c05d@bruckner.email>
 <MM798zs--3-2@tutanota.com>
 <c57cb647-72fe-1e07-433a-33f99b3d7755@bruckner.email>
Message-ID: <MM7R_M3--3-2@tutanota.com>

Thanks to everyone I have been able to resolve the problem by writing:

disable-pinpad

to: ~/.gnupg/scdaemon.conf

The problem lies in Pinentry which for some reason can't hande ccid pin requests on the contactless interface, after this fix the interface works as expceted no problem with any feautures.

Thank you,
22h49


Nov 14, 2020, 20:39 by gnupg-users at gnupg.org:

> No problem!
>
> I see.
> Well I don't have any experiences with other cards than these from Zeitcontrol and the tokens from Yubikey and Nitrokey.
> I know that the Yubikey5 supports PGP operations via RFID as a few customers from me use it with their mobile devices.
>
> But as Werner stated in his e-mail before it may be a 'problem' specific with GnuPG as it doesn't support wireless operation for security reasons.
>
> And I really don't know if another OpenPGP implementation does support smartcards/token.
> This was already a big issue with Mozilla's Thunderbird 78 and it's native implementation of OpenPGP instead of Enigmail.
>
> Sorry that I can't help in a better way!
>
> best regards and a great weekend
> Juergen
>
> -- 
> /?\   No  |
> \ /  HTML |    Juergen Bruckner
>  X    in  |    juergen at bruckner.email
> / \  Mail |
>
> Am 14.11.20 um 20:08 schrieb 22h39 via Gnupg-users:
>
>> Sorry Jorgen for the mail I missclicked.
>>
>> As can be seen in the logs I'm using a NXP J3H145 card with this applet: https://github.com/ANSSI-FR/SmartPGP which is compliant with OpenPGP spec V3.4.
>>
>> I can assure that this card __works__ via RFID since I can easily sign files using it and OpenKeychain on my phone, the problem here is created by GPG in conjunction with the reader.
>>
>> Thanks for help,
>> 22h49
>>
>>
>>
>> Nov 14, 2020, 19:58 by gnupg-users at gnupg.org:
>>
>>> What kind of OpenPGP card do you use?
>>> The OpenPGP Smart Card V3.3 + MiFare DESFire [1] don't support PGP operations via RFID.
>>>
>>> regards
>>> Juergen
>>>
>>> [1] https://www.floss-shop.de/en/security-privacy/smartcards/4/openpgp-smart-card-v3.3-mifare-desfire
>>> --
>>> /?\   No  |
>>> \ /  HTML |    Juergen Bruckner
>>>  X    in  |    juergen at bruckner.email
>>> / \  Mail |
>>>
>>> Am 14.11.20 um 19:45 schrieb 22h39 via Gnupg-users:
>>>
>>>> I don't understand, then how is OpenKeychain able to use OpenPGP cards via RFID?
>>>>
>>>> I can sucessfully sign using this card via my phone but It won't work with the reader connected to the computer.
>>>>
>>>> Looking at the logs, the card exchanges exactly the same apdus when using the contact and contactless interface so all points to some weird bug in gpg.
>>>>
>>>> Thanks for help,
>>>> 22h49
>>>>
>>>>
>>>> _______________________________________________
>>>> Gnupg-users mailing list
>>>> Gnupg-users at gnupg.org
>>>> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>>>>
>>
>>
>>
>> _______________________________________________
>> Gnupg-users mailing list
>> Gnupg-users at gnupg.org
>> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20201114/d31f9675/attachment.html>

From 22h39 at tutanota.com  Sat Nov 14 21:32:59 2020
From: 22h39 at tutanota.com (22h39)
Date: Sat, 14 Nov 2020 21:32:59 +0100 (CET)
Subject: Major problems with gpg and scdaemon, help highly appriciated
In-Reply-To: <MM7Ryr6--3-2@tutanota.com>
References: <MM22ib4--B-2@tutanota.com> <MM7Ryr6--3-2@tutanota.com>
Message-ID: <MM7SVH1--3-2@tutanota.com>

Problem resolved! look at my last reply to Juergen to find the solution.

Thanks to everyone,
22h49

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20201114/49436786/attachment.html>

From wk at gnupg.org  Mon Nov 16 16:06:43 2020
From: wk at gnupg.org (Werner Koch)
Date: Mon, 16 Nov 2020 16:06:43 +0100
Subject: Major problems with gpg and scdaemon, help highly appriciated
In-Reply-To: <MM7R_M3--3-2@tutanota.com> (gnupg-users@gnupg.org's message of
 "Sat, 14 Nov 2020 21:28:58 +0100 (CET)")
References: <MM22ib4--B-2@tutanota.com> <MM73zcN--F-2@tutanota.com>
 <3acfebb5-7868-a111-b08f-b6fa2480c05d@bruckner.email>
 <MM798zs--3-2@tutanota.com>
 <c57cb647-72fe-1e07-433a-33f99b3d7755@bruckner.email>
 <MM7R_M3--3-2@tutanota.com>
Message-ID: <875z65pcho.fsf@wheatstone.g10code.de>

On Sat, 14 Nov 2020 21:28, 22h39 said:

> The problem lies in Pinentry which for some reason can't hande ccid
> pin requests on the contactless interface, after this fix the

Which reader and which ccid driver are you using?  I assume that you are
running pcscd, right?


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/20201116/ade383f3/attachment.sig>

From 22h39 at tutanota.com  Mon Nov 16 18:18:02 2020
From: 22h39 at tutanota.com (22h39)
Date: Mon, 16 Nov 2020 18:18:02 +0100 (CET)
Subject: Major problems with gpg and scdaemon, help highly appriciated
In-Reply-To: <875z65pcho.fsf@wheatstone.g10code.de>
References: <MM22ib4--B-2@tutanota.com> <MM73zcN--F-2@tutanota.com>
 <3acfebb5-7868-a111-b08f-b6fa2480c05d@bruckner.email>
 <MM798zs--3-2@tutanota.com>
 <c57cb647-72fe-1e07-433a-33f99b3d7755@bruckner.email>
 <MM7R_M3--3-2@tutanota.com> <875z65pcho.fsf@wheatstone.g10code.de>
Message-ID: <MMH32xj--3-2@tutanota.com>

The readers as I've shown is a REINERST Cyberjack RFID Standard, and the driver pcsc_lite.

Indeed I am running pcsc, in my first message I've even posted it's debug log.

Thanks,
22h49



Nov 16, 2020, 16:06 by wk at gnupg.org:

> On Sat, 14 Nov 2020 21:28, 22h39 said:
>
>> The problem lies in Pinentry which for some reason can't hande ccid
>> pin requests on the contactless interface, after this fix the
>>
>
> Which reader and which ccid driver are you using?  I assume that you are
> running pcscd, right?
>
>
> Salam-Shalom,
>
>  Werner
>
> -- 
> Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20201116/f40ac4e8/attachment-0001.html>

From wangtianjiao.wang959 at gmail.com  Tue Nov 17 02:35:57 2020
From: wangtianjiao.wang959 at gmail.com (A NiceBoy)
Date: Mon, 16 Nov 2020 20:35:57 -0500
Subject: GPG Encryption/Decryption Failing
In-Reply-To: <SN6PR1501MB1998350A2C8AFCBF23CF890FF8E60@SN6PR1501MB1998.namprd15.prod.outlook.com>
References: <SN6PR1501MB1998350A2C8AFCBF23CF890FF8E60@SN6PR1501MB1998.namprd15.prod.outlook.com>
Message-ID: <CAL57ndEA34oG6pecAc=Ji8oPT72TXNuG7pu0Lsj=+1+MqsWZew@mail.gmail.com>

Hello Sirisha,

I read from Mozilla's official documentation which states that SOPS
command-line client is preferred, the SOPS library should be used only
for decryption.

The link is here: https://godoc.org/go.mozilla.org/sops/v3

>This package should not be used directly. Instead, Sops users should install the command line client >via `go get -u go.mozilla.org/sops/v3/cmd/sops`, or use the decryption helper provided at >`go.mozilla.org/sops/v3/decrypt`.

>We do not guarantee API stability for any package other than `go.mozilla.org/sops/v3/decrypt`.

My two cents.

Best regards

On Fri, 13 Nov 2020 at 17:08, Sirisha Gopigiri via Gnupg-users
<gnupg-users at gnupg.org> wrote:
>
> Hi,
>
> We are trying to use SOPS+GPG to encrypt/decrypt yaml files and we have written some go wrapper using sops library to perform the required encryption/decryption. However when trying to execute this code the gpg library seems to be failing at keygeneration most of the time with the following error.
>
> failed to encrypt new data key with master key "681E3A89EB1DAFD36EB883120A73BB48E26694D8": could not encrypt data key with PGP key: golang.org/x/crypto/openpgp error: key with fingerprint 681E3A89EB1DAFD36EB883120A73BB48E26694D8 is not available in keyring and could not be retrieved from keyserver; GPG binary error: gpg binary failed with error: exit status 2, gpg: 681E3A89EB1DAFD36EB883120A73BB48E26694D8: skipped: No public key
>
> Seems like it is unable to fetch the public key, we are executing the code locally, so we are using the local public and private keys only.
>
> Though we can list the public key locally, we keep getting the above error quite frequently. However, the encryption/decryption is happening successfully the other times.
>
> Kindly let us know if we are missing anything.
>
> We are facing this error only with gpg 2.1.x version, gpg 1.4.x version seems to be working fine.
>
>
> Thank you in advance!
>
> Best Regards
> Sirisha Gopigiri
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users


From wk at gnupg.org  Tue Nov 17 11:17:11 2020
From: wk at gnupg.org (Werner Koch)
Date: Tue, 17 Nov 2020 11:17:11 +0100
Subject: [Announce] GnuPG 2.2.24 released
Message-ID: <87mtzgnv88.fsf@wheatstone.g10code.de>

Hello!

We are pleased to announce the availability of a new GnuPG release:
version 2.2.24.  This is maintenace release fixing some long standing
bugs.  See below for details.


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 is Free Software (meaning that it respects your freedom).  It can
be freely used, modified and distributed under the terms of the GNU
General Public License.


Noteworthy changes in version 2.2.24
====================================

  * Allow Unicode file names on Windows almost everywhere.  Note that
    it is still not possible to use Unicode strings on the command
    line.  This change also fixes a regression in 2.2.22 related to
    non-ascii file names.  [#5098]

  * Fix localized time printing on Windows.  [#5073]

  * gpg: New command --quick-revoke-sig.  [#5093]

  * gpg: Do not use weak digest algos if selected by recipient
    preference during sign+encrypt.  [4c181d51a6]

  * gpg: Switch to AES256 for symmetric encryption in de-vs mode.
    [166e779634]

  * gpg: Silence weak digest warnings with --quiet.  [#4893]

  * gpg: Print new status line CANCELED_BY_USER for a cancel during
    symmetric encryption.  [f05d1772c4]

  * gpg: Fix the encrypt+sign hash algo preference selection for
    ECDSA.  This is in particular needed for keys created from
    existing smartcard based keys.  [aeed0b93ff]

  * agent: Fix secret key import of GnuPG 2.3 generated Ed25519 keys.
    [#5114]

  * agent: Keep some permissions of private-keys-v1.d.  [#2312]

  * dirmngr: Align sks-keyservers.netCA.pem use between ntbtls and
    gnutls builds.  [e4f3b74c91]

  * dirmngr: Fix the pool keyserver case for a single host in the
    pool.  [72e04b03b1a7]

  * scd: Fix the use case of verify_chv2 by CHECKPIN.  [61aea64b3c]

  * scd: Various improvements to the ccid-driver.  [#4616,#5065]

  * scd: Minor fixes for Yubikey [25bec16d0b]

  * gpgconf: New option --show-versions.

  * w32: Install gpg-check-pattern and example profiles.  Install
    Windows subsystem variant of gpgconf (gpgconf-w32).

  * i18n: Complete overhaul and completion of the Italian translation.
    Thanks to Denis Renzi.

  * Require Libgcrypt 1.8 because 1.7 has long reached end-of-life.

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


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

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

GnuPG 2.2.24 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.24.tar.bz2 (7027k)
 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.24.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.24_20201117.exe (4322k)
 https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.24_20201117.exe.sig

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

New versions of the GnuPG VS-Desktop(tm) as well as Gpg4win for Windows
featuring this version of GnuPG will be released shortly.


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.24.tar.bz2 you would use this command:

     gpg --verify gnupg-2.2.24.tar.bz2.sig gnupg-2.2.24.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.24.tar.bz2, you run the command like this:

     sha1sum gnupg-2.2.24.tar.bz2

   and check that the output matches the next line:

2e8e29fdc06710d1e7f6f4b87098b96e058797fe  gnupg-2.2.24.tar.bz2
eeefbaaecc4d69a3b66e1ce333c4c5081501310a  gnupg-w32-2.2.24_20201117.tar.xz
ab895bd9bc4319b88b1314ede3a816cd0a1cc677  gnupg-w32-2.2.24_20201117.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
=========================

If you used GnuPG in the past you should read the description of
changes and new features at doc/whats-new-in-2.1.txt or online at

  https://gnupg.org/faq/whats-new-in-2.1.html

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/T5052 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 currently mostly financed by donations.  Two full-time employed
developers as well as two contractor exclusively work on GnuPG and
closely related software like Libgcrypt, GPGME and Gpg4win.

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, or answering questions on the mailing
lists.

Many thanks to our numerous financial supporters, both corporate and
individuals.  Without you it would not be possible to keep GnuPG in a
good and secure shape and to address all the small and larger requests
made by our users.  Thanks.


Happy hacking,

   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.

p.p.s
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 four keys:

  rsa2048 2011-01-12 [expires: 2021-12-31]
  Key fingerprint = D869 2123 C406 5DEA 5E0F  3AB5 249B 39D2 4F25 E3B6
  Werner Koch (dist sig)

  rsa2048 2014-10-29 [expires: 2020-10-30]
  Key fingerprint = 031E C253 6E58 0D8E A286  A9F2 2071 B08A 33BD 3F06
  NIIBE Yutaka (GnuPG Release Key) <gniibe 'at' fsij.org>

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

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

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/20201117/5b3b4f0a/attachment.sig>
-------------- next part --------------
_______________________________________________
Gnupg-announce mailing list
Gnupg-announce at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-announce

From bangchuishan at outlook.com  Tue Nov 17 03:28:49 2020
From: bangchuishan at outlook.com (Gao Xiaohui)
Date: Tue, 17 Nov 2020 02:28:49 +0000
Subject: How to change the protect cipher algorithm and the digest
 algorithm of the secret key?
Message-ID: <SG2PR04MB2588C30F55F49E706C4B6D6AD5E20@SG2PR04MB2588.apcprd04.prod.outlook.com>

Thank you for your reply to my question.
In "https://dev.gnupg.org/T1800", Werner responded: "It is an open question whether gpg should be allowed to change the s2k options because the keys are a property of the agent and not of gpg. For export it might hwoever make sense to be able to change that (think export for use on a slower box)."Excuse me, why not use "--s2k-digest-algo" and "--s2k-cipher-algo" and other options for gpg-agent.exe, so you can also write these options in "gpg- conf.conf". At present, the "--s2k-count" option can be used in both gpg.exe and gpg-agent.exe.Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20201117/4c1a8306/attachment.html>

From wk at gnupg.org  Tue Nov 17 16:20:29 2020
From: wk at gnupg.org (Werner Koch)
Date: Tue, 17 Nov 2020 16:20:29 +0100
Subject: How to change the protect cipher algorithm and the digest
 algorithm of the secret key?
In-Reply-To: <SG2PR04MB2588C30F55F49E706C4B6D6AD5E20@SG2PR04MB2588.apcprd04.prod.outlook.com>
 (Gao Xiaohui via Gnupg-users's message of "Tue, 17 Nov 2020 02:28:49
 +0000")
References: <SG2PR04MB2588C30F55F49E706C4B6D6AD5E20@SG2PR04MB2588.apcprd04.prod.outlook.com>
Message-ID: <87ft58nh6q.fsf@wheatstone.g10code.de>

On Tue, 17 Nov 2020 02:28, Gao Xiaohui said:

> conf.conf". At present, the "--s2k-count" option can be used in both
> gpg.exe and gpg-agent.exe.Thank you.

In gpg.conf this is used for deriving a passphrase for symmetric
encryption.

In gpg-agent.conf it is used to override the calibrated iteration code
for protecting keys in gpg-agent.  There is no need to change the
algorithms.  For interoperability and maintenance reasons we try to
limit the number of user modifiable parameters.  Eventually there will
be change to an AEAD algorithm, howver interoperability is the main
concern and not theoretical attacks.


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/20201117/fa6de38d/attachment-0001.sig>

From spam.trap.mailing.lists at gmail.com  Tue Nov 17 16:47:18 2020
From: spam.trap.mailing.lists at gmail.com (Stefan Claas)
Date: Tue, 17 Nov 2020 15:47:18 +0000
Subject: Avoid recipient-compatibility SHA1
In-Reply-To: <20201102131532.GA1475874@fullerene.field.pennock-tech.net>
References: <20201030041054.GA959448@fullerene.field.pennock-tech.net>
 <874km7vs7z.fsf@wheatstone.g10code.de>
 <20201102131532.GA1475874@fullerene.field.pennock-tech.net>
Message-ID: <CAC6FiZ5ryG_BL3k7UBjcqQZRuGtTu5gGu1FKP2cW57huuPhsyg@mail.gmail.com>

On Mon, Nov 2, 2020 at 2:25 PM Phil Pennock via Gnupg-users
<gnupg-users at gnupg.org> wrote:
>
> On 2020-11-02 at 13:49 +0100, Werner Koch via Gnupg-users wrote:
> > On Fri, 30 Oct 2020 00:10, Phil Pennock said:
> > > recipient.  That's fine.  I'd rather create pressure for people to fix
> > > their systems to use modern cryptography than cater to their brokenness
> > > with sensitive messages.
> >
> > People won't update their keys - that just does not work.  Ignoring the
> > preferences is a better way here.
>
> First: thank you for the code changes!
>
> As to the people part: for a generic call to action, you're right.  But
> that's not the social dynamic in play here.
>
> For a specific set of people who know each other, trying to communicate
> securely, if someone says "hey your key is too broken to use, please fix
> it, here's a command to run (which you should check for yourself),
> please do so and send us your new public key" ... then that works.

I do have a question for you and Werner, if you don't mind.

When one checks Wikipedia for SHA1:

https://en.wikipedia.org/wiki/SHA-1

People may ask when seeing this [Quote]:

Since 2005, SHA-1 has not been considered secure against well-funded
opponents;[4] as of 2010 many organizations have recommended its
replacement.[5][6][7] NIST formally deprecated use of SHA-1 in 2011
and disallowed its use for digital signatures in 2013.

Was this therefore ever discussed on OpenPGP Mailing Lists, between
OpenPGP experts and Mr. Zimmermann and Werner?

Second question:

What does it really mean for the OpenPGP ecosystem if there would be a
SHA1 collision found in an email or detached signed document or file?
I ask, because when one checks a GnuPG
digitally signed message or file it usually says it comes from the key
(owner) blah and this key has a fingerprint of blah if one checks.

Regards
Stefan


From giessman at informatik.hu-berlin.de  Tue Nov 17 17:37:38 2020
From: giessman at informatik.hu-berlin.de (Ernst G Giessmann)
Date: Tue, 17 Nov 2020 17:37:38 +0100
Subject: Avoid recipient-compatibility SHA1
In-Reply-To: <CAC6FiZ5ryG_BL3k7UBjcqQZRuGtTu5gGu1FKP2cW57huuPhsyg@mail.gmail.com>
References: <20201030041054.GA959448@fullerene.field.pennock-tech.net>
 <874km7vs7z.fsf@wheatstone.g10code.de>
 <20201102131532.GA1475874@fullerene.field.pennock-tech.net>
 <CAC6FiZ5ryG_BL3k7UBjcqQZRuGtTu5gGu1FKP2cW57huuPhsyg@mail.gmail.com>
Message-ID: <aabdad0c-624e-2711-a668-ffc7e71ca16f@informatik.hu-berlin.de>

The answer to the second question is:

A SHA-1 collision of two documents D1 and D2 means that the hash values
Hash(D1) and Hash(D2) are equal, which in turn means that (regardless
who signs) any signature of D1 (be it OpenPGP or SMIME) can also be used
as a signature of D2. Any signer and any key, if used with SHA-1!

So if you got a harmless document D to sign, you must be sure that there
is no evil twin of it. This is usually the case if you are the author of
D, because the construction of an evil twin remains hard. But it is easy
to construct docs with the same hash value.

/Ernst.

Am 2020-11-17 um 16:47 schrieb Stefan Claas via Gnupg-users:
> ...
> Second question:
>
> What does it really mean for the OpenPGP ecosystem if there would be a
> SHA1 collision found in an email or detached signed document or file?
> I ask, because when one checks a GnuPG
> digitally signed message or file it usually says it comes from the key
> (owner) blah and this key has a fingerprint of blah if one checks.
>
> Regards
> Stefan
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users



From gnupg-users at spodhuis.org  Wed Nov 18 00:13:59 2020
From: gnupg-users at spodhuis.org (Phil Pennock)
Date: Tue, 17 Nov 2020 18:13:59 -0500
Subject: Avoid recipient-compatibility SHA1
In-Reply-To: <CAC6FiZ5ryG_BL3k7UBjcqQZRuGtTu5gGu1FKP2cW57huuPhsyg@mail.gmail.com>
References: <20201030041054.GA959448@fullerene.field.pennock-tech.net>
 <874km7vs7z.fsf@wheatstone.g10code.de>
 <20201102131532.GA1475874@fullerene.field.pennock-tech.net>
 <CAC6FiZ5ryG_BL3k7UBjcqQZRuGtTu5gGu1FKP2cW57huuPhsyg@mail.gmail.com>
Message-ID: <X7RZNyxlD9bn/q4h@fullerene.field.pennock-tech.net>

On 2020-11-17 at 15:47 +0000, Stefan Claas wrote:
>} Since 2005, SHA-1 has not been considered secure against well-funded
>} opponents;[4] as of 2010 many organizations have recommended its
>} replacement.[5][6][7] NIST formally deprecated use of SHA-1 in 2011
>} and disallowed its use for digital signatures in 2013.
> 
> Was this therefore ever discussed on OpenPGP Mailing Lists, between
> OpenPGP experts and Mr. Zimmermann and Werner?

It's been discussed on the standardization lists, where I would
summarize the view as "What the hell, why are people still using SHA1?"

The answer is that some people are still using tools such as GnuPGv1 and
other similarly ancient software and get upset when asked to use the
current code-bases.

If you made a key using such old software but are now using modern
software, you should re-sign your UID and check for other problems.

If anyone wants to explore working with OpenPGP message formats while
writing a standalone tool, I suggest a public key reporter tool which
will report on the use of SHA1 (or MD5) digests where there's not
also a signature with a modern digest scheme, and provide guidance about
updating the keys. There's a few places such things might creep in.
Re-reading RFC 4880 while taking notes about all the places you see such
keys would help in writing a good tool.

This strikes me as a good way for a developer to become more familiar
with the ecosystem and to create an actively useful tool to help the
community move forward away from ancient systems.

Please don't demand this tool of any other developers: I offer the idea
as a suggestion only.


> Second question:
> 
> What does it really mean for the OpenPGP ecosystem if there would be a
> SHA1 collision found in an email or detached signed document or file?
> I ask, because when one checks a GnuPG
> digitally signed message or file it usually says it comes from the key
> (owner) blah and this key has a fingerprint of blah if one checks.

If someone can knowingly construct collisions against an existing
signature, without the cooperation of the key owner, then SHA1 would be
completely useless and such signatures would be nearly meaningless.

The current state of SHA1 is "dangerously exposed, you should be
hurrying for the exits, there might still be time to grab your coat on
the way out of the door."  The history is such that when the current
attacks against a digest system are where the SHA1 attacks are now, you
really don't want to be dealing with the next revelations because you
will not be happy.

At present, using "weak-digest sha1" in your GnuPG configuration files
reveals a lot of problems and in day-to-day use you will have to
periodically comment it back out again.  I know, because I've been doing
this since January.  It has helped me with pushing people I need to
exchange private mail with to update their keys.

-Phil


From azbigdogs at gmx.com  Wed Nov 18 06:18:55 2020
From: azbigdogs at gmx.com (Mark)
Date: Tue, 17 Nov 2020 22:18:55 -0700
Subject: Avoid recipient-compatibility SHA1
In-Reply-To: <X7RZNyxlD9bn/q4h@fullerene.field.pennock-tech.net>
References: <20201030041054.GA959448@fullerene.field.pennock-tech.net>
 <874km7vs7z.fsf@wheatstone.g10code.de>
 <20201102131532.GA1475874@fullerene.field.pennock-tech.net>
 <CAC6FiZ5ryG_BL3k7UBjcqQZRuGtTu5gGu1FKP2cW57huuPhsyg@mail.gmail.com>
 <X7RZNyxlD9bn/q4h@fullerene.field.pennock-tech.net>
Message-ID: <483c47e9-aa79-9f57-75fd-ace40fe7a319@gmx.com>

Not to ask a stupid question but how can you tell which algorithm your
keys are using and if using SHA1 update them to a more secure one?

Thanks,

On 11/17/2020 4:13 PM, Phil Pennock via Gnupg-users wrote:
>
> The current state of SHA1 is "dangerously exposed, you should be
> hurrying for the exits, there might still be time to grab your coat on
> the way out of the door."  The history is such that when the current
> attacks against a digest system are where the SHA1 attacks are now, you
> really don't want to be dealing with the next revelations because you
> will not be happy.
>
> At present, using "weak-digest sha1" in your GnuPG configuration files
> reveals a lot of problems and in day-to-day use you will have to
> periodically comment it back out again.  I know, because I've been doing
> this since January.  It has helped me with pushing people I need to
> exchange private mail with to update their keys.
>
> -Phil
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users

--
PGP Key Upon Request



From spam.trap.mailing.lists at gmail.com  Wed Nov 18 14:11:53 2020
From: spam.trap.mailing.lists at gmail.com (Stefan Claas)
Date: Wed, 18 Nov 2020 14:11:53 +0100
Subject: Avoid recipient-compatibility SHA1
In-Reply-To: <20201102131532.GA1475874@fullerene.field.pennock-tech.net>
References: <20201030041054.GA959448@fullerene.field.pennock-tech.net>
 <874km7vs7z.fsf@wheatstone.g10code.de>
 <20201102131532.GA1475874@fullerene.field.pennock-tech.net>
Message-ID: <CAC6FiZ7WZGrH-zS02SopyAEQ9ntPhL8zWczpPdRobeoGsSeezw@mail.gmail.com>

Thank you for your reply, much appreciated! I will however ask also
Ernst here again the same question one more time again, as an
illustrative example.

Regards
Stefan

On Mon, Nov 2, 2020 at 3:25 PM Phil Pennock via Gnupg-users
<gnupg-users at gnupg.org> wrote:
>
> On 2020-11-02 at 13:49 +0100, Werner Koch via Gnupg-users wrote:
> > On Fri, 30 Oct 2020 00:10, Phil Pennock said:
> > > recipient.  That's fine.  I'd rather create pressure for people to fix
> > > their systems to use modern cryptography than cater to their brokenness
> > > with sensitive messages.
> >
> > People won't update their keys - that just does not work.  Ignoring the
> > preferences is a better way here.
>
> First: thank you for the code changes!
>
> As to the people part: for a generic call to action, you're right.  But
> that's not the social dynamic in play here.
>
> For a specific set of people who know each other, trying to communicate
> securely, if someone says "hey your key is too broken to use, please fix
> it, here's a command to run (which you should check for yourself),
> please do so and send us your new public key" ... then that works.
>
> In the generic case, there's a hypothetical reward requiring work now.
> In the specific case, it's a case of "you're getting cut out of this
> ongoing conversation which presumably matters to you, do this now to get
> back in".  If the conversation really does matter to that person, then
> they will fix their key.  I have gotten people to fix various problems
> on exactly this basis.
>
> For everyone I am not talking to?  Not my business, not my problem.
> I can only issue advice and shrug when people ignore it.
>
> Now I just need a sane way to figure out which key caused this.  :)
>
> Thanks,
> -Phil
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users


From spam.trap.mailing.lists at gmail.com  Wed Nov 18 14:30:12 2020
From: spam.trap.mailing.lists at gmail.com (Stefan Claas)
Date: Wed, 18 Nov 2020 14:30:12 +0100
Subject: Avoid recipient-compatibility SHA1
In-Reply-To: <aabdad0c-624e-2711-a668-ffc7e71ca16f@informatik.hu-berlin.de>
References: <20201030041054.GA959448@fullerene.field.pennock-tech.net>
 <874km7vs7z.fsf@wheatstone.g10code.de>
 <20201102131532.GA1475874@fullerene.field.pennock-tech.net>
 <CAC6FiZ5ryG_BL3k7UBjcqQZRuGtTu5gGu1FKP2cW57huuPhsyg@mail.gmail.com>
 <aabdad0c-624e-2711-a668-ffc7e71ca16f@informatik.hu-berlin.de>
Message-ID: <CAC6FiZ4LQP28HV3PZ+56+=wWPsTYfOgdpgD92-1r1F9ARqo5_g@mail.gmail.com>

On Tue, Nov 17, 2020 at 11:11 PM Ernst G Giessmann via Gnupg-users
<gnupg-users at gnupg.org> wrote:
>
> The answer to the second question is:
>
> A SHA-1 collision of two documents D1 and D2 means that the hash values
> Hash(D1) and Hash(D2) are equal, which in turn means that (regardless
> who signs) any signature of D1 (be it OpenPGP or SMIME) can also be used
> as a signature of D2. Any signer and any key, if used with SHA-1!
>
> So if you got a harmless document D to sign, you must be sure that there
> is no evil twin of it. This is usually the case if you are the author of
> D, because the construction of an evil twin remains hard. But it is easy
> to construct docs with the same hash value.
>
> /Ernst.

Thanks for your reply! So if I check the SHA1 checksums
from https://gnupg.org/download/integrity_check.html
and Alice checks from another evil site the same files then we
could have a problem with tools like openssl or the shasum tool.

But, sorry to ask again.

I like to give an Example.

Mallory has managed to listen to the clear text communications from
Alice and Bob's online devices. Alice and Bob always use GnuPG
to digitally sign their messages.

Mallory is *not* in possession of the private keys from Alice and Bob.
Mallory has created a document which causes a collision and was
signed with his own key.

He sends this message to Alice. What does Alice see when she
does a gpg --verify? I mean she should see, regardless if the
message has a collision or not, that the message was digitally
signed by Mallory's private key and not by Bob's private key.

Regards
Stefan


From spam.trap.mailing.lists at gmail.com  Wed Nov 18 15:20:00 2020
From: spam.trap.mailing.lists at gmail.com (Stefan Claas)
Date: Wed, 18 Nov 2020 15:20:00 +0100
Subject: Avoid recipient-compatibility SHA1
In-Reply-To: <CAC6FiZ4LQP28HV3PZ+56+=wWPsTYfOgdpgD92-1r1F9ARqo5_g@mail.gmail.com>
References: <20201030041054.GA959448@fullerene.field.pennock-tech.net>
 <874km7vs7z.fsf@wheatstone.g10code.de>
 <20201102131532.GA1475874@fullerene.field.pennock-tech.net>
 <CAC6FiZ5ryG_BL3k7UBjcqQZRuGtTu5gGu1FKP2cW57huuPhsyg@mail.gmail.com>
 <aabdad0c-624e-2711-a668-ffc7e71ca16f@informatik.hu-berlin.de>
 <CAC6FiZ4LQP28HV3PZ+56+=wWPsTYfOgdpgD92-1r1F9ARqo5_g@mail.gmail.com>
Message-ID: <CAC6FiZ45OoGmZ2KeYGV0Kq3qFzMykz+9DMAV4KVTyfupr0-1Pg@mail.gmail.com>

On Wed, Nov 18, 2020 at 2:30 PM Stefan Claas
<spam.trap.mailing.lists at gmail.com> wrote:
>
> On Tue, Nov 17, 2020 at 11:11 PM Ernst G Giessmann via Gnupg-users
> <gnupg-users at gnupg.org> wrote:
> >
> > The answer to the second question is:
> >
> > A SHA-1 collision of two documents D1 and D2 means that the hash values
> > Hash(D1) and Hash(D2) are equal, which in turn means that (regardless
> > who signs) any signature of D1 (be it OpenPGP or SMIME) can also be used
> > as a signature of D2. Any signer and any key, if used with SHA-1!
> >
> > So if you got a harmless document D to sign, you must be sure that there
> > is no evil twin of it. This is usually the case if you are the author of
> > D, because the construction of an evil twin remains hard. But it is easy
> > to construct docs with the same hash value.
> >
> > /Ernst.
>
> Thanks for your reply! So if I check the SHA1 checksums
> from https://gnupg.org/download/integrity_check.html
> and Alice checks from another evil site the same files then we
> could have a problem with tools like openssl or the shasum tool.

evil mirror with 'same' files ...

> But, sorry to ask again.
>
> I like to give an Example.
>
> Mallory has managed to listen to the clear text communications from
> Alice and Bob's online devices. Alice and Bob always use GnuPG
> to digitally sign their messages.

prior encrypting.

> Mallory is *not* in possession of the private keys from Alice and Bob.
> Mallory has created a document which causes a collision and was
> signed with his own key.
>
> He sends this message to Alice. What does Alice see when she
> does a gpg --verify? I mean she should see, regardless if the
> message has a collision or not, that the message was digitally
> signed by Mallory's private key and not by Bob's private key.

The one thing I could currently see is if Alice would make a public
statement on her web site, for example, digitally signed by her
with SHA1 and that Mallory would upload a collided document
with a (completely) different content.

So the question for me would be if a collision could be crafted,
let's say for an important business contract etc., if the different
content of a document would make the same sense, like the one
from the original document.

Regards
Stefan


From giessman at informatik.hu-berlin.de  Wed Nov 18 15:58:18 2020
From: giessman at informatik.hu-berlin.de (Ernst G Giessmann)
Date: Wed, 18 Nov 2020 15:58:18 +0100
Subject: Avoid recipient-compatibility SHA1
In-Reply-To: <CAC6FiZ4LQP28HV3PZ+56+=wWPsTYfOgdpgD92-1r1F9ARqo5_g@mail.gmail.com>
References: <20201030041054.GA959448@fullerene.field.pennock-tech.net>
 <874km7vs7z.fsf@wheatstone.g10code.de>
 <20201102131532.GA1475874@fullerene.field.pennock-tech.net>
 <CAC6FiZ5ryG_BL3k7UBjcqQZRuGtTu5gGu1FKP2cW57huuPhsyg@mail.gmail.com>
 <aabdad0c-624e-2711-a668-ffc7e71ca16f@informatik.hu-berlin.de>
 <CAC6FiZ4LQP28HV3PZ+56+=wWPsTYfOgdpgD92-1r1F9ARqo5_g@mail.gmail.com>
Message-ID: <3533c941-54eb-e35c-7ff0-ef847cac0390@informatik.hu-berlin.de>

Am 2020-11-18 um 14:30 schrieb Stefan Claas:
> On Tue, Nov 17, 2020 at 11:11 PM Ernst G Giessmann via Gnupg-users
> <gnupg-users at gnupg.org> wrote:
>> The answer to the second question is:
>>
>> A SHA-1 collision of two documents D1 and D2 means that the hash values
>> Hash(D1) and Hash(D2) are equal, which in turn means that (regardless
>> who signs) any signature of D1 (be it OpenPGP or SMIME) can also be used
>> as a signature of D2. Any signer and any key, if used with SHA-1!
>>
>> So if you got a harmless document D to sign, you must be sure that there
>> is no evil twin of it. This is usually the case if you are the author of
>> D, because the construction of an evil twin remains hard. But it is easy
>> to construct docs with the same hash value.
>>
>> /Ernst.
> Thanks for your reply! So if I check the SHA1 checksums
> from https://gnupg.org/download/integrity_check.html
> and Alice checks from another evil site the same files then we
> could have a problem with tools like openssl or the shasum tool.
No, here you will have no problem, because we all trust gnupg.org ;-)
They will never create two different packages with a SHA-1 collision.

The problem shows up, if Mallory creates two documents D1 and D2 being a 
SHA-1 collision.
D1 says that Alice will owe Bob 10 Euros, D2 says the Bob will owe Alice 
1000 Euros.

Anybody who signs D1 will sign at the same time also D2.? Now I come 
back to your example.
> But, sorry to ask again.
>
> I like to give an Example.
>
> Mallory has managed to listen to the clear text communications from
> Alice and Bob's online devices. Alice and Bob always use GnuPG
> to digitally sign their messages.
Fine. Unfortunally Alice accepts SHA-1 signed messages and Bob creates 
signatures based on SHA-1
> Mallory is *not* in possession of the private keys from Alice and Bob.
> Mallory has created a document which causes a collision and was
> signed with his own key.
No, Mallory does not sign the document, instead he sends D1 to Bob and 
asks him for his signature.
Bob is happy because he gets 10 Euros for free from Alice and 
immediately signs the document D1.
Mallory replaces D1 by D2, leaving the signature untouched.
> He sends this message to Alice. What does Alice see when she
> does a gpg --verify? I mean she should see, regardless if the
> message has a collision or not, that the message was digitally
> signed by Mallory's private key and not by Bob's private key.
Alice will see a signed by Bob document D2 with a valid signature (due 
to the fact that SHA1(D1)=SHA1(D2)), where Bob confirms, that he owes 
Alice money.
That Bob signs another document could be proven by showing the other 
document D1, but which document, D1 or D2, was actually signed remains 
nevertheless open. In this particular case, it seems very unlikely that 
Bob had signed D2, but it would have been even better if he had not used 
SHA-1 at all. And SHA-2(D1) is certainly different from SHA-2(D2).

/Ernst.

I suspect, that Mallory and Alice were in fact the same person ;-)



From sirisha.gopigiri at ericsson.com  Wed Nov 18 12:51:51 2020
From: sirisha.gopigiri at ericsson.com (Sirisha Gopigiri)
Date: Wed, 18 Nov 2020 11:51:51 +0000
Subject: GPG Encryption/Decryption Failing
In-Reply-To: <CAL57ndEA34oG6pecAc=Ji8oPT72TXNuG7pu0Lsj=+1+MqsWZew@mail.gmail.com>
References: <SN6PR1501MB1998350A2C8AFCBF23CF890FF8E60@SN6PR1501MB1998.namprd15.prod.outlook.com>,
 <CAL57ndEA34oG6pecAc=Ji8oPT72TXNuG7pu0Lsj=+1+MqsWZew@mail.gmail.com>
Message-ID: <DM5PR1501MB1990210804638B7B053651AFF8E10@DM5PR1501MB1990.namprd15.prod.outlook.com>

Hi

Thank you for the reply and we have looked into the documentation.

But after debugging a little we found that we are running into this issue only if we use gpg 2.2.4 version. We tested the same code with gpg 1.4.20 version and it seems to work fine. I mean we ran the test cases for the code like 20 times and we haven't got this error at least once. So we were thinking if we are missing out some configuration with gpg 2.2.4. Could you please help us?

Thank you in advance!

Best Regards
Sirisha Gopigiri
________________________________
From: A NiceBoy <wangtianjiao.wang959 at gmail.com>
Sent: 17 November 2020 07:05
To: Sirisha Gopigiri <sirisha.gopigiri at ericsson.com>
Cc: gnupg-users at gnupg.org <gnupg-users at gnupg.org>; E Guhan <e.guhan at ericsson.com>; Michelle Eslinger A <michelle.a.eslinger at ericsson.com>; Deepak Kataria <deepak.kataria at ericsson.com>
Subject: Re: GPG Encryption/Decryption Failing

Hello Sirisha,

I read from Mozilla's official documentation which states that SOPS
command-line client is preferred, the SOPS library should be used only
for decryption.

The link is here: https://godoc.org/go.mozilla.org/sops/v3

>This package should not be used directly. Instead, Sops users should install the command line client >via `go get -u go.mozilla.org/sops/v3/cmd/sops`, or use the decryption helper provided at >`go.mozilla.org/sops/v3/decrypt`.

>We do not guarantee API stability for any package other than `go.mozilla.org/sops/v3/decrypt`.

My two cents.

Best regards

On Fri, 13 Nov 2020 at 17:08, Sirisha Gopigiri via Gnupg-users
<gnupg-users at gnupg.org> wrote:
>
> Hi,
>
> We are trying to use SOPS+GPG to encrypt/decrypt yaml files and we have written some go wrapper using sops library to perform the required encryption/decryption. However when trying to execute this code the gpg library seems to be failing at keygeneration most of the time with the following error.
>
> failed to encrypt new data key with master key "681E3A89EB1DAFD36EB883120A73BB48E26694D8": could not encrypt data key with PGP key: golang.org/x/crypto/openpgp error: key with fingerprint 681E3A89EB1DAFD36EB883120A73BB48E26694D8 is not available in keyring and could not be retrieved from keyserver; GPG binary error: gpg binary failed with error: exit status 2, gpg: 681E3A89EB1DAFD36EB883120A73BB48E26694D8: skipped: No public key
>
> Seems like it is unable to fetch the public key, we are executing the code locally, so we are using the local public and private keys only.
>
> Though we can list the public key locally, we keep getting the above error quite frequently. However, the encryption/decryption is happening successfully the other times.
>
> Kindly let us know if we are missing anything.
>
> We are facing this error only with gpg 2.1.x version, gpg 1.4.x version seems to be working fine.
>
>
> Thank you in advance!
>
> Best Regards
> Sirisha Gopigiri
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> https://protect2.fireeye.com/v1/url?k=146cabc1-4bf79282-146ceb5a-861fcb972bfc-84bc22f40f25e6db&q=1&e=7a9f0586-9961-40e8-9e54-93a010f749b1&u=http%3A%2F%2Flists.gnupg.org%2Fmailman%2Flistinfo%2Fgnupg-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20201118/7286d62c/attachment.html>

From gnupg-users at spodhuis.org  Wed Nov 18 23:52:14 2020
From: gnupg-users at spodhuis.org (Phil Pennock)
Date: Wed, 18 Nov 2020 17:52:14 -0500
Subject: Avoid recipient-compatibility SHA1
In-Reply-To: <483c47e9-aa79-9f57-75fd-ace40fe7a319@gmx.com>
References: <20201030041054.GA959448@fullerene.field.pennock-tech.net>
 <874km7vs7z.fsf@wheatstone.g10code.de>
 <20201102131532.GA1475874@fullerene.field.pennock-tech.net>
 <CAC6FiZ5ryG_BL3k7UBjcqQZRuGtTu5gGu1FKP2cW57huuPhsyg@mail.gmail.com>
 <X7RZNyxlD9bn/q4h@fullerene.field.pennock-tech.net>
 <483c47e9-aa79-9f57-75fd-ace40fe7a319@gmx.com>
Message-ID: <X7WlnufPQjZryI//@fullerene.field.pennock-tech.net>

On 2020-11-17 at 22:18 -0700, Mark wrote:
> Not to ask a stupid question but how can you tell which algorithm your
> keys are using and if using SHA1 update them to a more secure one?

With GnuPG, `gpg --list-packets` shows a lot of fine detail, but unless
you're familiar with the standards it can be a bit of a slog.

If I might be forgiven for mentioning another OpenPGP tool from outside
the GnuPG suite which can help here, then Sequioa has an "sq" command
with the "inspect" sub-command.  Using an old revoked key of mine to
demonstrate:

-----------------------8< inspect with sequoia >8-----------------------
$ gpg --export 0x7C34B4E14CE4F655 | sq inspect
-: OpenPGP Certificate.

    Fingerprint: 1745 1D0F BB5E 88F4 0AC0  08F6 7C34 B4E1 4CE4 F655
                 Invalid: No binding signature at time 2020-11-18T22:41:24Z
Public-key algo: DSA (Digital Signature Algorithm)
Public-key size: 1024 bits
  Creation time: 2001-08-03 17:34:53 UTC

         UserID: Phil Pennock [censored email address in this list post]
                 Invalid: Policy rejected non-revocation signature (PositiveCertification)
                 because: SHA1 is not considered secure since 2013-01-01T00:00:00Z

             Bad Signature: [ snip long error which doesn't matter here ]
-----------------------8< inspect with sequoia >8-----------------------

Here the lack of SHA1 support made the fingerprint invalid, and then
it's explicitly called out under the UserID.

The other thing to do is to use `gpg --edit-key $YOURKEY` and run
`showpref`; it's okay for SHA1 to be _listed_ on the Digest: line, but
you also want SHA256 listed.

Fine:
  Digest: SHA256, SHA512, RIPEMD160, SHA1
Not fine:
  Digest: RIPEMD160, SHA1


With GnuPG:
 * To fix the preferences, "setpref" in the edit-key menu.
 * To fix the self-binding:
     gpg --expert --cert-digest-algo SHA256 --sign-key $YOURKEY

There's also the problem of subkey binding signatures.  That's a whole
other mess, but frankly if you have a key which is worth keeping (it has
a good web-of-trust) and you have old subkeys, just go ahead and make
new ones with a current version of GnuPG, after you've fixed the
self-binding.  I _think_, but have not checked, that GnuPG will do the
right thing there.

Basically, make a subkey for encryption, and a subkey for signing, and
call it good.

-Phil


From gnupg-users at spodhuis.org  Thu Nov 19 00:09:39 2020
From: gnupg-users at spodhuis.org (Phil Pennock)
Date: Wed, 18 Nov 2020 18:09:39 -0500
Subject: Avoid recipient-compatibility SHA1
In-Reply-To: <483c47e9-aa79-9f57-75fd-ace40fe7a319@gmx.com>
References: <20201030041054.GA959448@fullerene.field.pennock-tech.net>
 <874km7vs7z.fsf@wheatstone.g10code.de>
 <20201102131532.GA1475874@fullerene.field.pennock-tech.net>
 <CAC6FiZ5ryG_BL3k7UBjcqQZRuGtTu5gGu1FKP2cW57huuPhsyg@mail.gmail.com>
 <X7RZNyxlD9bn/q4h@fullerene.field.pennock-tech.net>
 <483c47e9-aa79-9f57-75fd-ace40fe7a319@gmx.com>
Message-ID: <X7Wpsyh9zoj1ZGJ9@fullerene.field.pennock-tech.net>

On 2020-11-17 at 22:18 -0700, Mark wrote:
> Not to ask a stupid question but how can you tell which algorithm your
> keys are using and if using SHA1 update them to a more secure one?

I have a better answer than my previous one, because the very next
mailing-list I read has a post today from the Sequoia devs where they've
written a tool to report this stuff, and even to automatically generate
current bindings, if you trust your private key to their code.

  <https://gitlab.com/sequoia-pgp/keyring-linter>

Looks to do much of what I recommended; I haven't read the code and
don't know if the current version will also fix preference lists.

(I look forward to this sort of functionality being part of GnuPG
natively, as part of key lifecycle maintenance for long-lived keys.)

-Phil


From neal at walfield.org  Thu Nov 19 08:52:39 2020
From: neal at walfield.org (Neal H. Walfield)
Date: Thu, 19 Nov 2020 08:52:39 +0100
Subject: Avoid recipient-compatibility SHA1
In-Reply-To: <CAC6FiZ4LQP28HV3PZ+56+=wWPsTYfOgdpgD92-1r1F9ARqo5_g@mail.gmail.com>
References: <20201030041054.GA959448@fullerene.field.pennock-tech.net>
 <874km7vs7z.fsf@wheatstone.g10code.de>
 <20201102131532.GA1475874@fullerene.field.pennock-tech.net>
 <CAC6FiZ5ryG_BL3k7UBjcqQZRuGtTu5gGu1FKP2cW57huuPhsyg@mail.gmail.com>
 <aabdad0c-624e-2711-a668-ffc7e71ca16f@informatik.hu-berlin.de>
 <CAC6FiZ4LQP28HV3PZ+56+=wWPsTYfOgdpgD92-1r1F9ARqo5_g@mail.gmail.com>
Message-ID: <87o8jt3hrs.wl-neal@walfield.org>

Hi Stefan,

A chosen-prefix collision attack works as follows: an attacker chooses
two message prefixes, and then uses near collisions blocks (in the
SHA-1 is a Shambles paper they needed about 10 such 512-bit blocks) to
align the internal state of the two hashes.  Since SHA-1 is a
streaming function, the attacker can also append a common suffix.
That is, we want:

  Hash(prefix #1 || near collision blocks #1 || suffix)
  = Hash(prefix #2 || near collision blocks #2 || suffix)

And the attacker can choose prefix #1, prefix #2, and suffix, but
cannot control near collision blocks #1 or near collision blocks #2.

One way to exploit this is to create a pair of colliding documents
(e.g., something benign and a will), and then convince Alice to sign
the benign one.  If successful, the signature can be transferred to
the other document, and it appears that Alice has sign it too!

This attack requires the attacker to hide the near collision blocks in
the documents.  This is often straighforward: most formats have
provisions for comments, or metadata, which the user does not see.

The difficulty is to get Alice to sign the first document: if she
modifies it (e.g., adds any context), then the hash will be different.
But, if Alice is a signing service, then this may be possible even if
Alice modifies the document as long as the modifications are
predictable.

On Wed, 18 Nov 2020 14:30:12 +0100,
Stefan Claas via Gnupg-users wrote:
> Mallory has managed to listen to the clear text communications from
> Alice and Bob's online devices. Alice and Bob always use GnuPG
> to digitally sign their messages.
> 
> Mallory is *not* in possession of the private keys from Alice and Bob.
> Mallory has created a document which causes a collision and was
> signed with his own key.

This is currently not possible.  What you describe is a preimage
attack, not a collision attack.  A preimage attack is when you can
create a document with the same hash as an existing document.  Right
now, it is possible to find two documents that collide, but you can
only partially control the content of each of them (i.e., you need to
add the near collision blocks to both to actually create the
collision).

:) Neal


From spam.trap.mailing.lists at gmail.com  Thu Nov 19 22:53:29 2020
From: spam.trap.mailing.lists at gmail.com (Stefan Claas)
Date: Thu, 19 Nov 2020 21:53:29 +0000
Subject: Avoid recipient-compatibility SHA1
In-Reply-To: <87o8jt3hrs.wl-neal@walfield.org>
References: <20201030041054.GA959448@fullerene.field.pennock-tech.net>
 <874km7vs7z.fsf@wheatstone.g10code.de>
 <20201102131532.GA1475874@fullerene.field.pennock-tech.net>
 <CAC6FiZ5ryG_BL3k7UBjcqQZRuGtTu5gGu1FKP2cW57huuPhsyg@mail.gmail.com>
 <aabdad0c-624e-2711-a668-ffc7e71ca16f@informatik.hu-berlin.de>
 <CAC6FiZ4LQP28HV3PZ+56+=wWPsTYfOgdpgD92-1r1F9ARqo5_g@mail.gmail.com>
 <87o8jt3hrs.wl-neal@walfield.org>
Message-ID: <CAC6FiZ5_+35=+vztqmqssspNEOmfn2xEF_2pQnQex0kcRGJgCQ@mail.gmail.com>

Hi Neal,

thanks a lot for the detailed explanation!

Best regards
Stefan

On Thu, Nov 19, 2020 at 7:52 AM Neal H. Walfield <neal at walfield.org> wrote:
>
> Hi Stefan,
>
> A chosen-prefix collision attack works as follows: an attacker chooses
> two message prefixes, and then uses near collisions blocks (in the
> SHA-1 is a Shambles paper they needed about 10 such 512-bit blocks) to
> align the internal state of the two hashes.  Since SHA-1 is a
> streaming function, the attacker can also append a common suffix.
> That is, we want:
>
>   Hash(prefix #1 || near collision blocks #1 || suffix)
>   = Hash(prefix #2 || near collision blocks #2 || suffix)
>
> And the attacker can choose prefix #1, prefix #2, and suffix, but
> cannot control near collision blocks #1 or near collision blocks #2.
>
> One way to exploit this is to create a pair of colliding documents
> (e.g., something benign and a will), and then convince Alice to sign
> the benign one.  If successful, the signature can be transferred to
> the other document, and it appears that Alice has sign it too!
>
> This attack requires the attacker to hide the near collision blocks in
> the documents.  This is often straighforward: most formats have
> provisions for comments, or metadata, which the user does not see.
>
> The difficulty is to get Alice to sign the first document: if she
> modifies it (e.g., adds any context), then the hash will be different.
> But, if Alice is a signing service, then this may be possible even if
> Alice modifies the document as long as the modifications are
> predictable.
>
> On Wed, 18 Nov 2020 14:30:12 +0100,
> Stefan Claas via Gnupg-users wrote:
> > Mallory has managed to listen to the clear text communications from
> > Alice and Bob's online devices. Alice and Bob always use GnuPG
> > to digitally sign their messages.
> >
> > Mallory is *not* in possession of the private keys from Alice and Bob.
> > Mallory has created a document which causes a collision and was
> > signed with his own key.
>
> This is currently not possible.  What you describe is a preimage
> attack, not a collision attack.  A preimage attack is when you can
> create a document with the same hash as an existing document.  Right
> now, it is possible to find two documents that collide, but you can
> only partially control the content of each of them (i.e., you need to
> add the near collision blocks to both to actually create the
> collision).
>
> :) Neal


From gpg at alsd.eu  Thu Nov 19 22:08:25 2020
From: gpg at alsd.eu (dalz)
Date: Thu, 19 Nov 2020 22:08:25 +0100
Subject: Ask for passphrase once, but require confirmation each time a key
 is used?
Message-ID: <C77JPW8XJ9QR.3EBYKCEBR384O@lenovale>

The motivation is that I'd like to know when something wants to decrypt
a file. I could configure gpg-agent to not cache the key and ask for the
passphrase each time, but that is very annoying with a long passphrase,
so I was wondering if there was any other way to accomplish that.
What I'm thinking is a popup window that (while gpg-agent has the key)
replaces pinentry, requiring a simple click of a button to allow the
decryption. Is there any way to do this?

I'm pretty new to this, so feel free to point out that my idea is
pointless / makes no sense if that is the case!

--
dalz


From 2017-r3sgs86x8e-lists-groups at riseup.net  Fri Nov 20 01:20:24 2020
From: 2017-r3sgs86x8e-lists-groups at riseup.net (MFPA)
Date: Fri, 20 Nov 2020 00:20:24 +0000
Subject: Ask for passphrase once,
 but require confirmation each time a key is used?
In-Reply-To: <C77JPW8XJ9QR.3EBYKCEBR384O@lenovale>
References: <C77JPW8XJ9QR.3EBYKCEBR384O@lenovale>
Message-ID: <1715164171.20201120001957@mail.riseup.net>

Hi


On Thursday 19 November 2020 at 9:08:25 PM, in
<mid:C77JPW8XJ9QR.3EBYKCEBR384O at lenovale>, dalz via Gnupg-users wrote:-


> I could configure gpg-agent to not cache the
> key and ask for the
> passphrase each time, but that is very annoying with
> a long passphrase

If you use a password manager, the length of your passphrase doesn't make any difference.

-- 
Best regards

MFPA                  <mailto:2017-r3sgs86x8e-lists-groups at riseup.net>

Yellow snow is not lemon flavoured
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 1207 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20201120/173cce3e/attachment.sig>

From gpg at alsd.eu  Fri Nov 20 09:45:23 2020
From: gpg at alsd.eu (dalz)
Date: Fri, 20 Nov 2020 09:45:23 +0100
Subject: Ask for passphrase once, but require confirmation each time a
 key is used?
In-Reply-To: <1715164171.20201120001957@mail.riseup.net>
References: <C77JPW8XJ9QR.3EBYKCEBR384O@lenovale>
 <1715164171.20201120001957@mail.riseup.net>
Message-ID: <C77YJJ3EORI9.3G31V4OEKYPOD@lenovale>

I do use a password manager (https://www.passwordstore.org/), but it
stores passwords in pgp-encrypted files - I'd have to insert the
passphrase to get the passphrase :)

--
dalz


From informatik at semy.ch  Fri Nov 20 10:23:22 2020
From: informatik at semy.ch (Daniel Bossert)
Date: Fri, 20 Nov 2020 10:23:22 +0100
Subject: Thunderbird / Enigmail / Autocrypt
Message-ID: <20201120102322.56cbc8506cb075747a3de511@semy.ch>

Hello all

How secure is it to use Thundebrird with Autocrypt? I use Sylpheed at the moment, but it is not that comfortable to use as Thunderbird.
Also, when I send an email, the signature will be shown instead like with thunderbid just an info that the mail is signed

Do you have some inputs?

Regards
Daniel

-- 
PGP: 81A8 1EC7 179C BE5F 02A8 2C01 3FF1 07B6 FC68 F10A
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20201120/5db72ae6/attachment.sig>

From wk at gnupg.org  Fri Nov 20 12:39:01 2020
From: wk at gnupg.org (Werner Koch)
Date: Fri, 20 Nov 2020 12:39:01 +0100
Subject: GPG Encryption/Decryption Failing
In-Reply-To: <DM5PR1501MB1990210804638B7B053651AFF8E10@DM5PR1501MB1990.namprd15.prod.outlook.com>
 (Sirisha Gopigiri via Gnupg-users's message of "Wed, 18 Nov 2020
 11:51:51 +0000")
References: <SN6PR1501MB1998350A2C8AFCBF23CF890FF8E60@SN6PR1501MB1998.namprd15.prod.outlook.com>
 <CAL57ndEA34oG6pecAc=Ji8oPT72TXNuG7pu0Lsj=+1+MqsWZew@mail.gmail.com>
 <DM5PR1501MB1990210804638B7B053651AFF8E10@DM5PR1501MB1990.namprd15.prod.outlook.com>
Message-ID: <873614mf56.fsf@wheatstone.g10code.de>

On Wed, 18 Nov 2020 11:51, Sirisha Gopigiri said:

> But after debugging a little we found that we are running into this
> issue only if we use gpg 2.2.4 version. We tested the same code with

You are really using a 3 year old version which was followed by 20 more
releases.   You also missed 2.2.8 which fixes CVE-2018-12020.

> gpg 1.4.20 version and it seems to work fine. I mean we ran the test

Same here.  If you use 1.4 at all you need to use the latest version
(1.4.23 from 2018)!

Isn't it a general advise to first thr the latest version of a software
if you run into a bug ;-)

Anyway, ppl here can in general better help you if you explain your
problem in more detail and best show how it can be replicated.  For
example, I even don't know what this SOPS is and how it used gpg.


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/20201120/12ce551c/attachment-0001.sig>

From cqcallaw at brainvitamins.net  Fri Nov 20 20:13:22 2020
From: cqcallaw at brainvitamins.net (cqcallaw)
Date: Fri, 20 Nov 2020 19:13:22 +0000
Subject: Signing decentralized websites
Message-ID: <0Ocu7_u7IGcQBut5VB8Wie7D6kSpzarEqoEq8pGrPyrShZp4n7FMStePe81k2lFhFfvsqERJnid9-ub0N9iPO_KpbTyrJ6JolGOzMFGMGHY=@brainvitamins.net>

Hi all,

I want to sign my decentralized website, hosted on IPFS + Ethereum Name Service (ENS). PGP detached signatures for every published file seems to be the correct solution. Inline signatures would make validation of HTML documents difficult and binary files would become invalid. Signing the root IPFS CID might work, but would require substantial updates to ENS or an external Ethereum smart contract. Signing a subset of files isn't enough, because corrupted or inauthentic unsigned files could be bundled together with the signed subset and published as authentic.

Assuming folks agree with this analysis, I have two additional questions:

1) What's the best way to sign multiple files in parallel? I have 16 CPU threads and would like to take advantage of these (mostly idle) threads to speed up the signing process. GNU parallel and Python's multiprocessing module are behaving oddly, though; when they run gpg in parallel, I'm prompted for my PGP key's password multiple times. I'm running gpg-agent, so I'd expect to be prompted for my password only once. I also observe intermittent memory allocation errors. The --lock-once and --lock-multiple CLI options don't seem to change the behavior. Is there some implementation issue with running multiple gpg signing operations in parallel?

2) Are there any tools to verify detached signatures in the browser? As a user, I'd like my browser to check for a signature file and verify any discovered signatures with any available trusted keys. If a trusted key isn't found, I'd like my browser to check for a pubkey in some known location (e.g. <root cid="">/pubkey.asc) and allow me to trust the bundled pubkey if I so desire. I'd expect browser security considerations to necessitate a separate key store for keys used in the browser, but that's an acceptable solution for me if a key import workflow exists. Does anything like this exist?

Thanks!
-Caleb


From patrick at enigmail.net  Sat Nov 21 10:35:29 2020
From: patrick at enigmail.net (Patrick Brunschwig)
Date: Sat, 21 Nov 2020 10:35:29 +0100
Subject: Thunderbird / Enigmail / Autocrypt
In-Reply-To: <20201120102322.56cbc8506cb075747a3de511@semy.ch>
References: <20201120102322.56cbc8506cb075747a3de511@semy.ch>
Message-ID: <d5df5f08-cbe7-71b3-d592-c0e654849429@enigmail.net>

If you think about using the current stable version of Thunderbird
(version 78), then there is no Enigmail and no Autocrypt. OpenPGP has
been implemented directly in Thunderbird, but there is currently no
Autocrypt support in Thunderbird.

-Patrick

Daniel Bossert via Gnupg-users wrote on 20.11.2020 10:23:
> Hello all
> 
> How secure is it to use Thundebrird with Autocrypt? I use Sylpheed at the moment, but it is not that comfortable to use as Thunderbird.
> Also, when I send an email, the signature will be shown instead like with thunderbid just an info that the mail is signed
> 
> Do you have some inputs?
> 
> Regards
> Daniel
> 
> 
> 
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
> 


From alci at mecadu.org  Sat Nov 21 10:37:57 2020
From: alci at mecadu.org (Franck Routier (perso))
Date: Sat, 21 Nov 2020 10:37:57 +0100
Subject: Ask for passphrase once, but require confirmation each time a
 key is used?
In-Reply-To: <C77JPW8XJ9QR.3EBYKCEBR384O@lenovale>
References: <C77JPW8XJ9QR.3EBYKCEBR384O@lenovale>
Message-ID: <802a7d94faca7df8d78c7f8871bf225a7d54676b.camel@mecadu.org>

You could use a Yubikey: correctly configured, it will required you to
touch the yubikey capacitor button to allow the use of the gpg key
(once the passphrade is cached of course)

Franck


Le jeudi 19 novembre 2020 ? 22:08 +0100, dalz via Gnupg-users a ?crit?:
> The motivation is that I'd like to know when something wants to
> decrypt
> a file. I could configure gpg-agent to not cache the key and ask for
> the
> passphrase each time, but that is very annoying with a long
> passphrase,
> so I was wondering if there was any other way to accomplish that.
> What I'm thinking is a popup window that (while gpg-agent has the
> key)
> replaces pinentry, requiring a simple click of a button to allow the
> decryption. Is there any way to do this?
> 
> I'm pretty new to this, so feel free to point out that my idea is
> pointless / makes no sense if that is the case!
> 
> --
> dalz
> 
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users




From gpg at alsd.eu  Sat Nov 21 17:42:45 2020
From: gpg at alsd.eu (dalz)
Date: Sat, 21 Nov 2020 17:42:45 +0100
Subject: Ask for passphrase once, but require confirmation each time a
 key is used?
In-Reply-To: <802a7d94faca7df8d78c7f8871bf225a7d54676b.camel@mecadu.org>
References: <C77JPW8XJ9QR.3EBYKCEBR384O@lenovale>
 <802a7d94faca7df8d78c7f8871bf225a7d54676b.camel@mecadu.org>
Message-ID: <C793BKQF6N5X.16V05FFLF5J8H@lenovale>

Thanks, that could be an option - but not a cheap one it seems.
I'm also considering writing a pinentry program that does what I want,
however the last attempt ended in nothing but frustration...

--
dalz


From wk at gnupg.org  Sat Nov 21 18:58:49 2020
From: wk at gnupg.org (Werner Koch)
Date: Sat, 21 Nov 2020 18:58:49 +0100
Subject: Signing decentralized websites
In-Reply-To: <0Ocu7_u7IGcQBut5VB8Wie7D6kSpzarEqoEq8pGrPyrShZp4n7FMStePe81k2lFhFfvsqERJnid9-ub0N9iPO_KpbTyrJ6JolGOzMFGMGHY=@brainvitamins.net>
 (cqcallaw via Gnupg-users's message of "Fri, 20 Nov 2020 19:13:22
 +0000")
References: <0Ocu7_u7IGcQBut5VB8Wie7D6kSpzarEqoEq8pGrPyrShZp4n7FMStePe81k2lFhFfvsqERJnid9-ub0N9iPO_KpbTyrJ6JolGOzMFGMGHY=@brainvitamins.net>
Message-ID: <87wnyelhgm.fsf@wheatstone.g10code.de>

On Fri, 20 Nov 2020 19:13, cqcallaw said:

> change the behavior. Is there some implementation issue with running
> multiple gpg signing operations in parallel?

This is all serialized because the gpg-agent does the actual signing.
There is one gpg-agent per GNUPGHOME.  Thus the easiest solution for you
is to provide copies of the GNUPGHOME and either set this envvar for
each process or pass --homedir=decicated-homedir-copy.  You can't use
links to the same directory because we use lock files.  However, it
should be possible to sumlink the private-keys-v1.d sub directories.

> 2) Are there any tools to verify detached signatures in the browser?
> As a user, I'd like my browser to check for a signature file and

Mailvelope comes to mind or you write your own thing using gpgme-json as
the native messaging server.  Mailvelope can use gpgme-json.

There is also openpgp.js as a solid Javascript implementation of
OpenPGP.


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/20201121/4a8b5693/attachment.sig>

From wk at gnupg.org  Sat Nov 21 19:02:33 2020
From: wk at gnupg.org (Werner Koch)
Date: Sat, 21 Nov 2020 19:02:33 +0100
Subject: Thunderbird / Enigmail / Autocrypt
In-Reply-To: <20201120102322.56cbc8506cb075747a3de511@semy.ch> (Daniel Bossert
 via Gnupg-users's message of "Fri, 20 Nov 2020 10:23:22 +0100")
References: <20201120102322.56cbc8506cb075747a3de511@semy.ch>
Message-ID: <87sg92lhae.fsf@wheatstone.g10code.de>

On Fri, 20 Nov 2020 10:23, Daniel Bossert said:

> How secure is it to use Thundebrird with Autocrypt? I use Sylpheed at
> the moment, but it is not that comfortable to use as Thunderbird.

Checkout Claws-mail which was forked from Sylpheed many years ago.  The
OpenPGP and S/MIME integration of both was initially done by me but many
others improved it at lot.  Claws is like Thunderbird cross-platform.

The current TB OpenPGP support is pretty basic after they removed
Enigmail.


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/20201121/2fffe442/attachment.sig>

From cqcallaw at brainvitamins.net  Sun Nov 22 02:06:53 2020
From: cqcallaw at brainvitamins.net (cqcallaw)
Date: Sun, 22 Nov 2020 01:06:53 +0000
Subject: Signing decentralized websites
In-Reply-To: <87wnyelhgm.fsf@wheatstone.g10code.de>
References: <0Ocu7_u7IGcQBut5VB8Wie7D6kSpzarEqoEq8pGrPyrShZp4n7FMStePe81k2lFhFfvsqERJnid9-ub0N9iPO_KpbTyrJ6JolGOzMFGMGHY=@brainvitamins.net>
 <87wnyelhgm.fsf@wheatstone.g10code.de>
Message-ID: <u57BM8dMpZxJnWzvUo5ArwxlmtxtyXE_bQYhqyX7QBl7aq9pwmkvIJ9Vn4REtYARMk-eN8Mxto989_YEbdvQoYM-alujfaZ3RiJg1KgbiPY=@brainvitamins.net>

??????? Original Message ???????
On Saturday, November 21, 2020 9:58 AM, Werner Koch <wk at gnupg.org> wrote:

> On Fri, 20 Nov 2020 19:13, cqcallaw said:
>
> > change the behavior. Is there some implementation issue with running
> > multiple gpg signing operations in parallel?
>
> This is all serialized because the gpg-agent does the actual signing.
> There is one gpg-agent per GNUPGHOME. Thus the easiest solution for you
> is to provide copies of the GNUPGHOME and either set this envvar for
> each process or pass --homedir=decicated-homedir-copy. You can't use
> links to the same directory because we use lock files. However, it
> should be possible to sumlink the private-keys-v1.d sub directories.
>
> > 2.  Are there any tools to verify detached signatures in the browser?
> >     As a user, I'd like my browser to check for a signature file and
> >
>
> Mailvelope comes to mind or you write your own thing using gpgme-json as
> the native messaging server. Mailvelope can use gpgme-json.
>
> There is also openpgp.js as a solid Javascript implementation of
> OpenPGP.
>
> Shalom-Salam,
>
> Werner
>
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.


Many thanks. I've written a Python script (https://github.com/cqcallaw/www/blob/94f0dbb84fa3908acdd698d7b67071bf4f2a723b/sign.py) to handle the parallel signing; I'll look into the browser options shortly.

Cheers,
-Caleb


From informatik at semy.ch  Sun Nov 22 04:52:39 2020
From: informatik at semy.ch (Daniel Bossert)
Date: Sun, 22 Nov 2020 04:52:39 +0100
Subject: Thunderbird / Enigmail / Autocrypt
In-Reply-To: <87sg92lhae.fsf@wheatstone.g10code.de>
References: <20201120102322.56cbc8506cb075747a3de511@semy.ch>
 <87sg92lhae.fsf@wheatstone.g10code.de>
Message-ID: <20201122045239.21446ab23e6407fccc091a9d@semy.ch>

Hello Werner

I would like to use claws-mail, but it looked quite old-school when I last used it.
There was no auto-configure of mail setup (find mail-server by itself).

But I will install it again and check it out.

Thank you
Daniel


On Sat, 21 Nov 2020 19:02:33 +0100
Werner Koch <wk at gnupg.org> wrote:

> On Fri, 20 Nov 2020 10:23, Daniel Bossert said:
> 
> > How secure is it to use Thundebrird with Autocrypt? I use Sylpheed at
> > the moment, but it is not that comfortable to use as Thunderbird.
> 
> Checkout Claws-mail which was forked from Sylpheed many years ago.  The
> OpenPGP and S/MIME integration of both was initially done by me but many
> others improved it at lot.  Claws is like Thunderbird cross-platform.
> 
> The current TB OpenPGP support is pretty basic after they removed
> Enigmail.
> 
> 
> Salam-Shalom,
> 
>    Werner
> 
> -- 
> Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


-- 
PGP: 81A8 1EC7 179C BE5F 02A8 2C01 3FF1 07B6 FC68 F10A
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20201122/43c1d37c/attachment.sig>

From gnupgpacker at on.yourweb.de  Sun Nov 22 10:02:54 2020
From: gnupgpacker at on.yourweb.de (gnupgpacker)
Date: Sun, 22 Nov 2020 10:02:54 +0100
Subject: Thunderbird / Enigmail / Autocrypt
Message-ID: <000101d6c0ae$43a38240$caea86c0$@on.yourweb.de>

Claws Mail is an useful alternative, but please keep aware it does not
support html mail, text only!
https://www.claws-mail.org/manual/de/claws-mail-manual.html#AEN955 

Best regards, Chris


> Date: Sat, 21 Nov 2020 19:02:33 +0100
> From: Werner Koch <wk at gnupg.org>
> To: Daniel Bossert via Gnupg-users <gnupg-users at gnupg.org>
> Subject: Re: Thunderbird / Enigmail / Autocrypt
> Message-ID: <87sg92lhae.fsf at wheatstone.g10code.de>
> Content-Type: text/plain; charset="us-ascii"
> ...
> Checkout Claws-mail which was forked from Sylpheed many years ago.
> The
> OpenPGP and S/MIME integration of both was initially done by me but
> many
> others improved it at lot.  Claws is like Thunderbird cross-platform.
> The current TB OpenPGP support is pretty basic after they removed
> Enigmail.
> Salam-Shalom,
>    Werner



From juergen at bruckner.email  Sun Nov 22 12:38:52 2020
From: juergen at bruckner.email (Juergen Bruckner)
Date: Sun, 22 Nov 2020 12:38:52 +0100
Subject: Thunderbird / Enigmail / Autocrypt
In-Reply-To: <000101d6c0ae$43a38240$caea86c0$@on.yourweb.de>
References: <000101d6c0ae$43a38240$caea86c0$@on.yourweb.de>
Message-ID: <d0b3b818-3b77-d612-2f2f-38a8b79e1bc5@bruckner.email>


Hi Chris,

Am 22.11.20 um 10:02 schrieb gnupgpacker:
> Claws Mail is an useful alternative, but please keep aware it does not
> support html mail, text only!
> https://www.claws-mail.org/manual/de/claws-mail-manual.html#AEN955
> 
> Best regards, Chris
> 

I don't understand why HTML in e-Mails is so important for some people.

For example, I configured my Mailserver to sort out HTML-Mails as Spam 
as long the sender is not on a whitelist.
HTML in e-Mails is a very big security risk in my eyes.

regards
Juergen

-- 
/?\   No  |
\ /  HTML |    Juergen Bruckner
  X    in  |    juergen at bruckner.email
/ \  Mail |

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3894 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20201122/81e7e8fe/attachment.bin>

From witwall3 at disroot.org  Sun Nov 22 12:42:44 2020
From: witwall3 at disroot.org (ael)
Date: Sun, 22 Nov 2020 11:42:44 +0000
Subject: Thunderbird / Enigmail / Autocrypt
In-Reply-To: <d0b3b818-3b77-d612-2f2f-38a8b79e1bc5@bruckner.email>
References: <000101d6c0ae$43a38240$caea86c0$@on.yourweb.de>
 <d0b3b818-3b77-d612-2f2f-38a8b79e1bc5@bruckner.email>
Message-ID: <20201122114244.GA6692@shelf.conquest>

On Sun, Nov 22, 2020 at 12:38:52PM +0100, Juergen Bruckner via Gnupg-users wrote:
> 
> I don't understand why HTML in e-Mails is so important for some people.
> 
> For example, I configured my Mailserver to sort out HTML-Mails as Spam as
> long the sender is not on a whitelist.
> HTML in e-Mails is a very big security risk in my eyes.
 +1

 ael



From andrewg at andrewg.com  Sun Nov 22 17:06:41 2020
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Sun, 22 Nov 2020 16:06:41 +0000
Subject: Thunderbird / Enigmail / Autocrypt
In-Reply-To: <d0b3b818-3b77-d612-2f2f-38a8b79e1bc5@bruckner.email>
References: <d0b3b818-3b77-d612-2f2f-38a8b79e1bc5@bruckner.email>
Message-ID: <28181ACD-F9B4-4891-BAD6-6EA752B60FF7@andrewg.com>


> On 22 Nov 2020, at 11:40, Juergen Bruckner via Gnupg-users <gnupg-users at gnupg.org> wrote:
> 
> HTML in e-Mails is a very big security risk in my eyes.

Not just yours, but unfortunately for many people it is a risk that they must absorb, because e.g. their job may depend upon it. It is not always feasible to scold your correspondents about their use of HTML mail, just as it is not always feasible to complain about their use of Microsoft Word. People need tools that work in the real world; not everyone can afford the luxury of righteous evangelism. 

A

From brad at fineby.me.uk  Sun Nov 22 17:17:37 2020
From: brad at fineby.me.uk (Brad Rogers)
Date: Sun, 22 Nov 2020 16:17:37 +0000
Subject: Thunderbird / Enigmail / Autocrypt
In-Reply-To: <28181ACD-F9B4-4891-BAD6-6EA752B60FF7@andrewg.com>
References: <d0b3b818-3b77-d612-2f2f-38a8b79e1bc5@bruckner.email>
 <28181ACD-F9B4-4891-BAD6-6EA752B60FF7@andrewg.com>
Message-ID: <20201122161737.1e310c15@earth.stargate.org.uk>

On Sun, 22 Nov 2020 16:06:41 +0000
Andrew Gallagher <andrewg at andrewg.com> wrote:

Hello Andrew,

>It is not always feasible to scold your correspondents about their use
>of HTML mail, 

True, but when my bank (just one example) tells me about their 'caring
about security' and then spewing HTML left, right, and centre, whilst
simultaneously disavowing themselves of blame should a virus be
transported by their message, they can, quite frankly, go take a running
jump.

-- 
 Regards  _
         / )           "The blindingly obvious is
        / _)rad        never immediately apparent"
Tell the dinosaurs they just won't survive
The History Of The World (Part 1) - The Damned
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20201122/d65919cb/attachment.sig>

From G.Franchetti at gsi.de  Sun Nov 22 19:34:00 2020
From: G.Franchetti at gsi.de (Giuliano Franchetti)
Date: Sun, 22 Nov 2020 19:34:00 +0100
Subject: gpg does not ask for a passphrase anymore
In-Reply-To: <20201122161737.1e310c15@earth.stargate.org.uk>
References: <d0b3b818-3b77-d612-2f2f-38a8b79e1bc5@bruckner.email>
 <28181ACD-F9B4-4891-BAD6-6EA752B60FF7@andrewg.com>
 <20201122161737.1e310c15@earth.stargate.org.uk>
Message-ID: <D2E1C0D1-0E88-46AE-BBB0-AF7398FCBDBD@gsi.de>

Hello to all, 


I use gpg for many years and never got a problem. 
Usually I encrypt files and directory with public key system. 

Recently I install duplicity and afterwards I have a strange problem I do not know to solve. 

The problem is that now if I decrypt an encrypted file, gpg decrypts it without asking the passphrase. 
I do not know what happened as before it always asked the passphrase but now not anymore.

Is anybody having a suggestion on how to make gpg to ask the passphrase again? 


Many thanks 


              Giuliano





From jerry at seibercom.net  Sun Nov 22 20:04:41 2020
From: jerry at seibercom.net (Jerry)
Date: Sun, 22 Nov 2020 14:04:41 -0500
Subject: Thunderbird / Enigmail / Autocrypt
In-Reply-To: <20201122161737.1e310c15@earth.stargate.org.uk>
References: <d0b3b818-3b77-d612-2f2f-38a8b79e1bc5@bruckner.email>
 <28181ACD-F9B4-4891-BAD6-6EA752B60FF7@andrewg.com>
 <20201122161737.1e310c15@earth.stargate.org.uk>
Message-ID: <20201122140441.00003208@seibercom.net>

On Sun, 22 Nov 2020 16:17:37 +0000, Brad Rogers stated:
>True, but when my bank (just one example) tells me about their 'caring
>about security' and then spewing HTML left, right, and centre, whilst
>simultaneously disavowing themselves of blame should a virus be
>transported by their message, they can, quite frankly, go take a
>running jump.

So, off the top of your head, how many viruses, parasites and
other assorted malignancies has your bank infected you with?

-- 
Jerry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 659 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20201122/b59c6ee5/attachment.sig>

From johanw at vulcan.xs4all.nl  Mon Nov 23 03:03:54 2020
From: johanw at vulcan.xs4all.nl (Johan Wevers)
Date: Mon, 23 Nov 2020 03:03:54 +0100
Subject: Thunderbird / Enigmail / Autocrypt
In-Reply-To: <d0b3b818-3b77-d612-2f2f-38a8b79e1bc5@bruckner.email>
References: <000101d6c0ae$43a38240$caea86c0$@on.yourweb.de>
 <d0b3b818-3b77-d612-2f2f-38a8b79e1bc5@bruckner.email>
Message-ID: <fdcae5fd-6625-50a8-9acf-98f250d569a8@vulcan.xs4all.nl>

On 22-11-2020 12:38, Juergen Bruckner via Gnupg-users wrote:

> I don't understand why HTML in e-Mails is so important for some people.

I agree on a personal level, but if you use your email also to
communicate with business users (usually using Outlook) it would be nice
to get their mails in a human readable format. Which requires,
unfortunately, usually html.

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



From guru at unixarea.de  Mon Nov 23 07:08:12 2020
From: guru at unixarea.de (Matthias Apitz)
Date: Mon, 23 Nov 2020 07:08:12 +0100
Subject: Thunderbird / Enigmail / Autocrypt
In-Reply-To: <fdcae5fd-6625-50a8-9acf-98f250d569a8@vulcan.xs4all.nl>
References: <000101d6c0ae$43a38240$caea86c0$@on.yourweb.de>
 <d0b3b818-3b77-d612-2f2f-38a8b79e1bc5@bruckner.email>
 <fdcae5fd-6625-50a8-9acf-98f250d569a8@vulcan.xs4all.nl>
Message-ID: <20201123060812.GA29830@r314251-amd64>

El d?a lunes, noviembre 23, 2020 a las 03:03:54a. m. +0100, Johan Wevers escribi?:

> On 22-11-2020 12:38, Juergen Bruckner via Gnupg-users wrote:
> 
> > I don't understand why HTML in e-Mails is so important for some people.
> 
> I agree on a personal level, but if you use your email also to
> communicate with business users (usually using Outlook) it would be nice
> to get their mails in a human readable format. Which requires,
> unfortunately, usually html.

Since ages human read mails in ASCII or UTF-8 text. Why you think this
is not a "human readable format"?

HTML as e-mail (read carefully: as email, not as attachment) should be
forbidden because most MUA automatically fetch additional remote content
which violates privacy and can fetch bad content into your system.
You're warned.

	matthias

-- 
Matthias Apitz, ? guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
??? ????? ??? ??????, ??? ?????? ??? ?????????? (??a????? ????? ?????)
Without books no knowledge - without knowledge no communism (Vladimir Ilyich Lenin)
Sin libros no hay saber - sin saber no hay comunismo. (Vladimir Ilich Lenin)


From cqcallaw at brainvitamins.net  Mon Nov 23 08:22:19 2020
From: cqcallaw at brainvitamins.net (cqcallaw)
Date: Mon, 23 Nov 2020 07:22:19 +0000
Subject: Thunderbird / Enigmail / Autocrypt
In-Reply-To: <20201123060812.GA29830@r314251-amd64>
References: <000101d6c0ae$43a38240$caea86c0$@on.yourweb.de>
 <d0b3b818-3b77-d612-2f2f-38a8b79e1bc5@bruckner.email>
 <fdcae5fd-6625-50a8-9acf-98f250d569a8@vulcan.xs4all.nl>
 <20201123060812.GA29830@r314251-amd64>
Message-ID: <Ayl-RejoKz76wQ6qRB2Qj7iNn2Tk2W_BqUzu8EuyOHEU6w0wKKekkJWFiTmzsktW_UbVB1ZbGZwIUuMCTYKP1oQlNrfBBpVKVrtzNUZvH_o=@brainvitamins.net>

??????? Original Message ???????
On Sunday, November 22, 2020 10:08 PM, Matthias Apitz <guru at unixarea.de> wrote:

> El d?a lunes, noviembre 23, 2020 a las 03:03:54a. m. +0100, Johan Wevers escribi?:
>
> > On 22-11-2020 12:38, Juergen Bruckner via Gnupg-users wrote:
> >
> > > I don't understand why HTML in e-Mails is so important for some people.
> >
> > I agree on a personal level, but if you use your email also to
> > communicate with business users (usually using Outlook) it would be nice
> > to get their mails in a human readable format. Which requires,
> > unfortunately, usually html.
>
> Since ages human read mails in ASCII or UTF-8 text. Why you think this
> is not a "human readable format"?
>
> HTML as e-mail (read carefully: as email, not as attachment) should be
> forbidden because most MUA automatically fetch additional remote content
> which violates privacy and can fetch bad content into your system.
> You're warned.
>
> matthias
>

At my job, I frequently send out summary charts and graphs surrounded by text.
Attachments simply do not work; my audience cannot spend the mental energy to
context-switch between text and attachments, and my reports become unusable.

I also provide hyperlinks in my reports. Sharing hyperlinks in plaintext emails
is possible, but verbose and unfriendly to the viewer.

In such circumstances, plaintext email is not human readable; I must use HTML.

Thanks,
-Caleb



From informatik at semy.ch  Mon Nov 23 08:30:31 2020
From: informatik at semy.ch (Daniel Bossert)
Date: Mon, 23 Nov 2020 08:30:31 +0100
Subject: Thunderbird / Enigmail / Autocrypt
In-Reply-To: <28181ACD-F9B4-4891-BAD6-6EA752B60FF7@andrewg.com>
References: <d0b3b818-3b77-d612-2f2f-38a8b79e1bc5@bruckner.email>
 <28181ACD-F9B4-4891-BAD6-6EA752B60FF7@andrewg.com>
Message-ID: <20201123083031.d4be6eda68429b76594f7a98@semy.ch>

I don't know if this is the right place here, but as we are discussing about sylpheed and claws-mail as well:
I have the following issue with Sylpheed:

I searched in Sylpheed for an email of April 20, 2020 for an insurance. I could easily find it in Thunderbird, but Sylpheed couldn't find it. I didn't see the mail in the inbox list of Sylpheed. Could it be Sylpheed doesn't catch all mail? How can I force it to sync everything it finds on the server?

I know it's not pgp related, but you guys know these two MUA, so therefore I ask.

Regards
Daniel

-- 
PGP: 81A8 1EC7 179C BE5F 02A8 2C01 3FF1 07B6 FC68 F10A
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20201123/436d1b71/attachment.sig>

From informatik at semy.ch  Mon Nov 23 08:37:11 2020
From: informatik at semy.ch (Daniel Bossert)
Date: Mon, 23 Nov 2020 08:37:11 +0100
Subject: Thunderbird / Enigmail / Autocrypt
In-Reply-To: <Ayl-RejoKz76wQ6qRB2Qj7iNn2Tk2W_BqUzu8EuyOHEU6w0wKKekkJWFiTmzsktW_UbVB1ZbGZwIUuMCTYKP1oQlNrfBBpVKVrtzNUZvH_o=@brainvitamins.net>
References: <000101d6c0ae$43a38240$caea86c0$@on.yourweb.de>
 <d0b3b818-3b77-d612-2f2f-38a8b79e1bc5@bruckner.email>
 <fdcae5fd-6625-50a8-9acf-98f250d569a8@vulcan.xs4all.nl>
 <20201123060812.GA29830@r314251-amd64>
 <Ayl-RejoKz76wQ6qRB2Qj7iNn2Tk2W_BqUzu8EuyOHEU6w0wKKekkJWFiTmzsktW_UbVB1ZbGZwIUuMCTYKP1oQlNrfBBpVKVrtzNUZvH_o=@brainvitamins.net>
Message-ID: <20201123083711.8416328c68f1aa371d28b8dc@semy.ch>

On Mon, 23 Nov 2020 07:22:19 +0000
cqcallaw via Gnupg-users <gnupg-users at gnupg.org> wrote:

> ??????? Original Message ???????
> On Sunday, November 22, 2020 10:08 PM, Matthias Apitz <guru at unixarea.de> wrote:
> 
> > El d?a lunes, noviembre 23, 2020 a las 03:03:54a. m. +0100, Johan Wevers escribi?:
> >
> > > On 22-11-2020 12:38, Juergen Bruckner via Gnupg-users wrote:
> > >
> > > > I don't understand why HTML in e-Mails is so important for some people.
> > >
> > > I agree on a personal level, but if you use your email also to
> > > communicate with business users (usually using Outlook) it would be nice
> > > to get their mails in a human readable format. Which requires,
> > > unfortunately, usually html.
> >
> > Since ages human read mails in ASCII or UTF-8 text. Why you think this
> > is not a "human readable format"?
> >
> > HTML as e-mail (read carefully: as email, not as attachment) should be
> > forbidden because most MUA automatically fetch additional remote content
> > which violates privacy and can fetch bad content into your system.
> > You're warned.
> >
> > matthias
> >
> 
> At my job, I frequently send out summary charts and graphs surrounded by text.
> Attachments simply do not work; my audience cannot spend the mental energy to
> context-switch between text and attachments, and my reports become unusable.
> 
> I also provide hyperlinks in my reports. Sharing hyperlinks in plaintext emails
> is possible, but verbose and unfriendly to the viewer.
> 
> In such circumstances, plaintext email is not human readable; I must use HTML.
> 
> Thanks,
> -Caleb

Probably HTML within an organization should be allowed but not when leaving such one?

> 
> 
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users

-- 
PGP: 81A8 1EC7 179C BE5F 02A8 2C01 3FF1 07B6 FC68 F10A
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20201123/9b2e4ff3/attachment.sig>

From guru at unixarea.de  Mon Nov 23 09:01:15 2020
From: guru at unixarea.de (Matthias Apitz)
Date: Mon, 23 Nov 2020 09:01:15 +0100
Subject: Thunderbird / Enigmail / Autocrypt
In-Reply-To: <Ayl-RejoKz76wQ6qRB2Qj7iNn2Tk2W_BqUzu8EuyOHEU6w0wKKekkJWFiTmzsktW_UbVB1ZbGZwIUuMCTYKP1oQlNrfBBpVKVrtzNUZvH_o=@brainvitamins.net>
References: <000101d6c0ae$43a38240$caea86c0$@on.yourweb.de>
 <d0b3b818-3b77-d612-2f2f-38a8b79e1bc5@bruckner.email>
 <fdcae5fd-6625-50a8-9acf-98f250d569a8@vulcan.xs4all.nl>
 <20201123060812.GA29830@r314251-amd64>
 <Ayl-RejoKz76wQ6qRB2Qj7iNn2Tk2W_BqUzu8EuyOHEU6w0wKKekkJWFiTmzsktW_UbVB1ZbGZwIUuMCTYKP1oQlNrfBBpVKVrtzNUZvH_o=@brainvitamins.net>
Message-ID: <20201123080115.GA30442@r314251-amd64>

El d?a lunes, noviembre 23, 2020 a las 07:22:19a. m. +0000, cqcallaw escribi?:

> > Since ages human read mails in ASCII or UTF-8 text. Why you think this
> > is not a "human readable format"?
> >
> > HTML as e-mail (read carefully: as email, not as attachment) should be
> > forbidden because most MUA automatically fetch additional remote content
> > which violates privacy and can fetch bad content into your system.
> > You're warned.
> >
> > matthias
> >
> 
> At my job, I frequently send out summary charts and graphs surrounded by text.
> Attachments simply do not work; my audience cannot spend the mental energy to
> context-switch between text and attachments, and my reports become unusable.
> 
> I also provide hyperlinks in my reports. Sharing hyperlinks in plaintext emails
> is possible, but verbose and unfriendly to the viewer.
> 
> In such circumstances, plaintext email is not human readable; I must use HTML.

Below you find a good example of such HTML SPAM going directly to an
external web server to fetch an "IMG" which could contain malisious code.
Is this what you really want to send to your boss or colleagues?

	matthias


<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Unbenanntes Dokument</title>
</head>

<body>
<p><strong>FFP2 Maske 1,89 bzw. 1,99 Euro</strong>. Die beliebteste und
meist getragene Atemmaske der Welt.</p>
<p>&nbsp;</p>
<p>Sehr geehrte Damen und Herren,</p>
<p>Folgende Angebote sind sofort lieferbar, einzeln verschweisst:</p>
<p><img
src="https://scontent-frx5-1.xx.fbcdn.net/v/t1.0-9/126513141_2743524842569455_973641306125964327_o.jpg?_nc_cat=100&amp;ccb=2&amp;_nc_sid=730e14&amp;_nc_ohc=NfVk0yNJgskAX9WQt3q&amp;_nc_ht=scontent-frx5-1.xx&amp;oh=2064e0f7143521537359d540ebc4a7c4&amp;oe=5FDF8DE4"
width="650" height="650" /></p>
<p><u>CE-Zertifiziert</u> durch Institut der europ&auml;ischen
Union.<strong><br /> Schutzklasse FFP2!</strong> (KN95) Guter Schutz vor
SARSCoV2 - Covid19CoronaViren.</p>
<p>Lieferung an Firmen, Beh&ouml;rden, Arztpraxen, Apotheken, Kliniken
usw.:</p>
<p>Abnahmemengen: 10er weise oder 100er weise.</p>
<p><strong><em>FFP2 Atemschutzmasken: (Auch nach AT, CH, NL, LU)<br /> 10
St. 19,90 Euro zzgl. 16 Proz. MwSt.</em></strong></p>
<p><em><strong>Angebot f&uuml;r Firmen, Kliniken, Arztpraxen:<br /> 100 St.
189,- Euro zzgl. 16 Proz. MwSt.</strong></em></p>
<p>(Gr&ouml;&szlig;ere Mengen auch sofort lieferbar.)</p>
<p>Bestellen Sie ganz einfach und zeitsparend, in dem Sie uns auf dieses
Schreiben <strong><u>einfach antworten</u></strong><u>.</u><br />
(Lieferung auf Rechnung. Keine Vorkasse oder &auml;hnliches.)</p>
<p>ceschutz at gmx.de</p>
<p><strong>Versandkostenfreie Lieferung!</strong></p>
<p>6 Wochen R&uuml;ckgaberecht bei Nichtgefallen! Ihnen enstehen keine
Kosten.</p>
<p>&nbsp;</p>
<p>Mit freundlichen Gr&uuml;&szlig;en,</p>
<p>Michaela Kress<br /> CE-Schutz Vertrieb<br /> Hannover</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>Bitte antworten Sie uns direkt per Email.</p>
<p>EU-Kunden k&ouml;nnen gern die Umsatzsteuernummer (VAT) angeben.</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
</body>
</html>



From m.mansfeld at mansfeld-elektronik.de  Mon Nov 23 11:39:39 2020
From: m.mansfeld at mansfeld-elektronik.de (Mansfeld Elektronik)
Date: Mon, 23 Nov 2020 11:39:39 +0100
Subject: Ban HTML mails? Really?(was: Re: Thunderbird / Enigmail / Autocrypt)
In-Reply-To: <20201123060812.GA29830@r314251-amd64>
References: <000101d6c0ae$43a38240$caea86c0$@on.yourweb.de>
 <d0b3b818-3b77-d612-2f2f-38a8b79e1bc5@bruckner.email>
 <fdcae5fd-6625-50a8-9acf-98f250d569a8@vulcan.xs4all.nl>
 <20201123060812.GA29830@r314251-amd64>
Message-ID: <ef6b9134e0d3bb811db820af91b60c5b@mansfeld-elektronik.de>

I'm sorry, but all this stuff becomes slightly off-topic....

Am 23.11.2020 07:08, schrieb Matthias Apitz:
> El d?a lunes, noviembre 23, 2020 a las 03:03:54a. m. +0100, Johan
> Wevers escribi?:
> 
>> On 22-11-2020 12:38, Juergen Bruckner via Gnupg-users wrote:
>> 
>> > I don't understand why HTML in e-Mails is so important for some people.
>> 
>> I agree on a personal level, but if you use your email also to
>> communicate with business users (usually using Outlook) it would be 
>> nice
>> to get their mails in a human readable format. Which requires,
>> unfortunately, usually html.
> 
> Since ages human read mails in ASCII or UTF-8 text. Why you think this
> is not a "human readable format"?
> 
> HTML as e-mail (read carefully: as email, not as attachment) should be
> forbidden because most MUA automatically fetch additional remote 
> content
> which violates privacy and can fetch bad content into your system.
> You're warned.
> 
> 	matthias


should.... should... Sorry?
In a perfect world we can choose our communication partners. In a 
semi-perfect world we can at least try to missionate against HTML mails, 
but maybe with not much success. In the real world we have very often no 
choice.
This battle is lost. The only choice is to harden the MUAs. Everything 
else is IMHO a quite academic disussion.

Regards
another Matthias


From wk at gnupg.org  Mon Nov 23 13:23:39 2020
From: wk at gnupg.org (Werner Koch)
Date: Mon, 23 Nov 2020 13:23:39 +0100
Subject: Thunderbird / Enigmail / Autocrypt
In-Reply-To: <Ayl-RejoKz76wQ6qRB2Qj7iNn2Tk2W_BqUzu8EuyOHEU6w0wKKekkJWFiTmzsktW_UbVB1ZbGZwIUuMCTYKP1oQlNrfBBpVKVrtzNUZvH_o=@brainvitamins.net>
 (cqcallaw via Gnupg-users's message of "Mon, 23 Nov 2020 07:22:19
 +0000")
References: <000101d6c0ae$43a38240$caea86c0$@on.yourweb.de>
 <d0b3b818-3b77-d612-2f2f-38a8b79e1bc5@bruckner.email>
 <fdcae5fd-6625-50a8-9acf-98f250d569a8@vulcan.xs4all.nl>
 <20201123060812.GA29830@r314251-amd64>
 <Ayl-RejoKz76wQ6qRB2Qj7iNn2Tk2W_BqUzu8EuyOHEU6w0wKKekkJWFiTmzsktW_UbVB1ZbGZwIUuMCTYKP1oQlNrfBBpVKVrtzNUZvH_o=@brainvitamins.net>
Message-ID: <87a6v8l0s4.fsf@wheatstone.g10code.de>

On Mon, 23 Nov 2020 07:22, cqcallaw said:

> At my job, I frequently send out summary charts and graphs surrounded by text.
> Attachments simply do not work; my audience cannot spend the mental energy to

Proper MUAs display inline images without problems.  I recall that even
exmh did this ~25 years ago.  It is just that the marketing department
can't enforce the corporate identity on text mails - or are too lazy to
create rules which work with plain text (and maybe inline images).

And well, I like HTML mails: my main address is free of spam thanks to a
simple procmail rule ;-)


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/20201123/ed0ba316/attachment.sig>

From wk at gnupg.org  Mon Nov 23 13:29:43 2020
From: wk at gnupg.org (Werner Koch)
Date: Mon, 23 Nov 2020 13:29:43 +0100
Subject: Thunderbird / Enigmail / Autocrypt
In-Reply-To: <000101d6c0ae$43a38240$caea86c0$@on.yourweb.de> (gnupgpacker's
 message of "Sun, 22 Nov 2020 10:02:54 +0100")
References: <000101d6c0ae$43a38240$caea86c0$@on.yourweb.de>
Message-ID: <873610l0i0.fsf@wheatstone.g10code.de>

On Sun, 22 Nov 2020 10:02, gnupgpacker said:
> Claws Mail is an useful alternative, but please keep aware it does not
> support html mail, text only!
> https://www.claws-mail.org/manual/de/claws-mail-manual.html#AEN955 

Just load one of the HTML viewer plugins.  Note that most plugins are an
integral part of Claws and thus don't run into problems like Enigmail
with Thunderbird.

Right, the first-use setup is not as easy as with Thunderbird.  That is
the difference between a multi-million dollar per year project and a
voluntary thingy.


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/20201123/f68c33e6/attachment.sig>

From mwood at iupui.edu  Mon Nov 23 16:15:43 2020
From: mwood at iupui.edu (Mark H. Wood)
Date: Mon, 23 Nov 2020 10:15:43 -0500
Subject: Thunderbird / Enigmail / Autocrypt
In-Reply-To: <20201123060812.GA29830@r314251-amd64>
References: <000101d6c0ae$43a38240$caea86c0$@on.yourweb.de>
 <d0b3b818-3b77-d612-2f2f-38a8b79e1bc5@bruckner.email>
 <fdcae5fd-6625-50a8-9acf-98f250d569a8@vulcan.xs4all.nl>
 <20201123060812.GA29830@r314251-amd64>
Message-ID: <20201123151543.GC5082@IUPUI.Edu>

On Mon, Nov 23, 2020 at 07:08:12AM +0100, Matthias Apitz wrote:
> El d?a lunes, noviembre 23, 2020 a las 03:03:54a. m. +0100, Johan Wevers escribi?:
> 
> > On 22-11-2020 12:38, Juergen Bruckner via Gnupg-users wrote:
> > 
> > > I don't understand why HTML in e-Mails is so important for some people.
> > 
> > I agree on a personal level, but if you use your email also to
> > communicate with business users (usually using Outlook) it would be nice
> > to get their mails in a human readable format. Which requires,
> > unfortunately, usually html.
> 
> Since ages human read mails in ASCII or UTF-8 text. Why you think this
> is not a "human readable format"?
> 
> HTML as e-mail (read carefully: as email, not as attachment) should be
> forbidden because most MUA automatically fetch additional remote content
> which violates privacy and can fetch bad content into your system.
> You're warned.

I consider that Mutt gives me the best of both, when I configure it:

  auto_view text/html

and in .mailcap:

  text/html; \
        lynx -dump -force_html %s; \
        copiousoutput

The text is flattened.  The result is sometimes ugly, but readable.

Attachments (such as images, or things purporting to be images) are
presented separately, and I can open them if I choose.  (Or I can copy
them out and inspect them in other ways, if I'm suspicious.  Examining
the un-rendered structure and content of some malicious messages can
be briefly entertaining.)

I would be mildly surprised to learn that my co-workers, outside of my
immediate workgroup, are even aware that I don't see their emails
rendered the way they do.  And nobody has ever told me, "your message
looks funny," except an occasional comment that someone couldn't open
the "attachment" (meaning the PGP/MIME signature).  Those stopped when
I got a corporate X.509 certificate and configured Mutt to use S/MIME
for internal mail.

Other console MUAs probably can do similar things when configured to
do so.

-- 
Mark H. Wood
Lead Technology Analyst

University Library
Indiana University - Purdue University Indianapolis
755 W. Michigan Street
Indianapolis, IN 46202
317-274-0749
www.ulib.iupui.edu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20201123/49e071f6/attachment.sig>

From johanw at vulcan.xs4all.nl  Mon Nov 23 17:57:45 2020
From: johanw at vulcan.xs4all.nl (Johan Wevers)
Date: Mon, 23 Nov 2020 17:57:45 +0100
Subject: Thunderbird / Enigmail / Autocrypt
In-Reply-To: <20201123060812.GA29830@r314251-amd64>
References: <000101d6c0ae$43a38240$caea86c0$@on.yourweb.de>
 <d0b3b818-3b77-d612-2f2f-38a8b79e1bc5@bruckner.email>
 <fdcae5fd-6625-50a8-9acf-98f250d569a8@vulcan.xs4all.nl>
 <20201123060812.GA29830@r314251-amd64>
Message-ID: <b439c179-db74-a2f6-50dc-f5c1ea0517da@vulcan.xs4all.nl>

On 23-11-2020 7:08, Matthias Apitz wrote:

> Since ages human read mails in ASCII or UTF-8 text. Why you think this
> is not a "human readable format"?

Sure, hand crafted html in a text reader is human readable. But the html
that is vomited by Outlook is not (unless you are a very experienced web
developer).

> HTML as e-mail (read carefully: as email, not as attachment) should be
> forbidden because most MUA automatically fetch additional remote content
> which violates privacy and can fetch bad content into your system.

Fortunately Thunderbird does not do that by default. But you can select
trusted domains for which it does if you like.

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



From gnupgpacker at on.yourweb.de  Mon Nov 23 18:03:54 2020
From: gnupgpacker at on.yourweb.de (gnupgpacker)
Date: Mon, 23 Nov 2020 18:03:54 +0100
Subject: Thunderbird / Enigmail / Autocrypt
In-Reply-To: <873610l0i0.fsf@wheatstone.g10code.de>
References: <000101d6c0ae$43a38240$caea86c0$@on.yourweb.de>
 <873610l0i0.fsf@wheatstone.g10code.de>
Message-ID: <000001d6c1ba$a0172ec0$e0458c40$@on.yourweb.de>

Thanks Werner.

After further investigation about html mailing with Claws Mail: 
'Dillo HTML viewer' project has been updated Jun-2015, not available for
Windows.
'litehtml' is available for Windows, but latest update is Oct-2015.

In our environment ~ 70% of contacts are using M$ Outlook and its
standard html mail functions, so discussion about sense of purpose are
mindless even a change of security awareness take place around there...
But you are right, html mail is definitely an annoyance and security
risk, but wide spreaded compatibility to several communication partners
and its needs is necessary!

Best regards, Chris

> -----Original Message-----
> From: Werner Koch <wk at gnupg.org>
> Sent: Monday, November 23, 2020 1:30 PM
> ...
> Just load one of the HTML viewer plugins.  Note that most plugins are
> an integral part of Claws and thus don't run into problems like 
> Enigmail with Thunderbird.



From wk at gnupg.org  Mon Nov 23 19:00:22 2020
From: wk at gnupg.org (Werner Koch)
Date: Mon, 23 Nov 2020 19:00:22 +0100
Subject: [Announce] GnuPG 2.2.25 released
Message-ID: <87tutgj6mh.fsf@wheatstone.g10code.de>

Hello!

We are pleased to announce the availability of a new GnuPG release:
version 2.2.25.  This maintenance release fixes a minor regression
introduced last week with 2.2.24.


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 is Free Software (meaning that it respects your freedom).  It can
be freely used, modified and distributed under the terms of the GNU
General Public License.


Noteworthy changes in version 2.2.25
====================================

  * scd: Fix regression in 2.2.24 requiring gpg --card-status before
    signing or decrypting.  [#5065]

  * gpgsm: Using Libksba 1.5.0 signatures with a rarely used
    combination of attributes can now be verified.  [#5146]

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


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

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

GnuPG 2.2.25 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.25.tar.bz2 (7027k)
 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.25.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.25_20201123.exe (4321k)
 https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.25_20201123.exe.sig

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

New versions of the GnuPG VS-Desktop(tm) and Gpg4win featuring this
version of GnuPG will be released shortly.


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.25.tar.bz2 you would use this command:

     gpg --verify gnupg-2.2.25.tar.bz2.sig gnupg-2.2.25.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.25.tar.bz2, you run the command like this:

     sha1sum gnupg-2.2.25.tar.bz2

   and check that the output matches the next line:

074b21dd07419575fa31c0c5d3116596d5544cbd  gnupg-2.2.25.tar.bz2
9a36c4b487563aab82d1436d8bf4518718dcc267  gnupg-w32-2.2.25_20201123.tar.xz
d4bc499a192e607f6db5e50bbc885a649ae670fc  gnupg-w32-2.2.25_20201123.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
=========================

If you used GnuPG in the past you should read the description of
changes and new features at doc/whats-new-in-2.1.txt or online at

  https://gnupg.org/faq/whats-new-in-2.1.html

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/T5140 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 still mostly financed by donations.  Two full-time employed
developers as well as two contractors exclusively work on GnuPG and
closely related software like Libgcrypt, GPGME and Gpg4win.

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, or answering questions on the mailing
lists.

Many thanks to our numerous financial supporters, both corporate and
individuals.  Without you it would not be possible to keep GnuPG in a
good and secure shape and to address all the small and larger requests
made by our users.  Thanks.


Happy hacking,

   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.

p.p.s
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 four keys:

  rsa2048 2011-01-12 [expires: 2021-12-31]
  Key fingerprint = D869 2123 C406 5DEA 5E0F  3AB5 249B 39D2 4F25 E3B6
  Werner Koch (dist sig)

  rsa2048 2014-10-29 [expires: 2020-10-30]
  Key fingerprint = 031E C253 6E58 0D8E A286  A9F2 2071 B08A 33BD 3F06
  NIIBE Yutaka (GnuPG Release Key) <gniibe 'at' fsij.org>

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

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

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.

-- 
"If privacy is outlawed, only outlaws will have privacy."
                 - PRZ 1991 ... some still don't get it.
-------------- 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/20201123/fb7012cf/attachment-0001.sig>
-------------- next part --------------
_______________________________________________
Gnupg-announce mailing list
Gnupg-announce at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-announce

From surendersinghpawar at gmail.com  Mon Nov 23 18:18:39 2020
From: surendersinghpawar at gmail.com (surender singh pawar)
Date: Mon, 23 Nov 2020 09:18:39 -0800
Subject: caching of passphrase is not working in windows ,
 gpg agent version 2.2.23
Message-ID: <CALgv3wQx9isrmM-FkEd54=EZUHFmGW3W5NJE5USdkt++bJujbQ@mail.gmail.com>

Hi folks,



I am kind of stuck on this, hence reaching out to you guyz.


GPG is prompting for passphrase even though passphrase cached in gpg-agent
<https://stackoverflow.com/questions/64939717/gpg-is-promting-for-passphrase-even-though-passphrase-cache-is-set-in-gpg-agent>
(windows)  Following steps I did.

1.      installed gpg on windows from https://gnupg.org/download/ (version
- 2.2.23)

2.      imported the key   : - > gpg --import <key File name>

3.      in home dir set the allow-preset-passphrase in gpg-agent.conf.

4.      from powershell started agent

"$gpgPath\bin\gpg-connect-agent.exe" reloadagent /bye



5.      powershell set passphrase

"$gpgPath\bin\gpg-preset-passphrase.exe" -v -c -P "$pgpPassphrase"

6.      mvn sign and deploy

mvn gpg:sign-and-deploy-file -B

"-Dfile=E:\Publish\files-1.0.12-test.jar"

"-Durl=https://oss.sonatype.org/service/local/staging/deploy/maven2"

"-Drevision=1.0.12-test" "-DrepositoryId=ossrh"

"-Dversion=1.0.12-test" "-DgroupId=datamodel" "-DartifactId=files"

"-Dsources=E:\Publish\files-1.0.12-test-sources.jar"

"-Djavadoc=E:\Publish\files-1.0.12-test-javadoc.jar"

"-Dpackaging=jar" "-DpomFile=E:\Publish\pom.xml"





it prompted the passphrase, I already cached it at step 5.

Not sure what is going wrong here .Is it a bug ? Few questions, really
appreciate if any one can help or i

1.      I don't see any option in windows, to verify if passphrase has been
cached . Does anyone know how to do that ?

2.      Are there any steps I am missing causing the passphrase prompt?

3. Any other direction , I should investigate.



I am kind of stuck here. Any help is very much appreciated.
 Thanks
Surender
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20201123/df40933f/attachment.html>

From philihp at gmail.com  Tue Nov 24 01:16:12 2020
From: philihp at gmail.com (Philihp Busby)
Date: Tue, 24 Nov 2020 00:16:12 +0000
Subject: Ban HTML mails? Really?(was: Re: Thunderbird / Enigmail /
 Autocrypt)
In-Reply-To: <ef6b9134e0d3bb811db820af91b60c5b@mansfeld-elektronik.de>
References: <000101d6c0ae$43a38240$caea86c0$@on.yourweb.de>
 <d0b3b818-3b77-d612-2f2f-38a8b79e1bc5@bruckner.email>
 <fdcae5fd-6625-50a8-9acf-98f250d569a8@vulcan.xs4all.nl>
 <20201123060812.GA29830@r314251-amd64>
 <ef6b9134e0d3bb811db820af91b60c5b@mansfeld-elektronik.de>
Message-ID: <20201124001612.GA29694@valencia.lan>

As a personal policy, I do not respond to emails if they are only in HTML. It provides an excellent signal on when an email is actually worth the distraction. Even password-reset/verify-your-email emails will have text-only components. Mailchimp marketing emails, on the other hand, often skip over the plaintext version (text-only emails don't convert in their metrics, i imagine the images don't load and they don't know you read it).

This battle has only been lost when you give up.

On 2020-11-23T11:39:39+0100 Mansfeld Elektronik <m.mansfeld at mansfeld-elektronik.de> wrote 2.0K bytes:

> I'm sorry, but all this stuff becomes slightly off-topic....
> 
> Am 23.11.2020 07:08, schrieb Matthias Apitz:
> > El d?a lunes, noviembre 23, 2020 a las 03:03:54a. m. +0100, Johan
> > Wevers escribi?:
> > 
> > > On 22-11-2020 12:38, Juergen Bruckner via Gnupg-users wrote:
> > > 
> > > > I don't understand why HTML in e-Mails is so important for some people.
> > > 
> > > I agree on a personal level, but if you use your email also to
> > > communicate with business users (usually using Outlook) it would be
> > > nice
> > > to get their mails in a human readable format. Which requires,
> > > unfortunately, usually html.
> > 
> > Since ages human read mails in ASCII or UTF-8 text. Why you think this
> > is not a "human readable format"?
> > 
> > HTML as e-mail (read carefully: as email, not as attachment) should be
> > forbidden because most MUA automatically fetch additional remote content
> > which violates privacy and can fetch bad content into your system.
> > You're warned.
> > 
> > 	matthias
> 
> 
> should.... should... Sorry?
> In a perfect world we can choose our communication partners. In a
> semi-perfect world we can at least try to missionate against HTML mails, but
> maybe with not much success. In the real world we have very often no choice.
> This battle is lost. The only choice is to harden the MUAs. Everything else
> is IMHO a quite academic disussion.
> 
> Regards
> another Matthias
> 
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users


From gnupg at raf.org  Tue Nov 24 00:01:47 2020
From: gnupg at raf.org (raf)
Date: Tue, 24 Nov 2020 10:01:47 +1100
Subject: Thunderbird / Enigmail / Autocrypt
In-Reply-To: <87a6v8l0s4.fsf@wheatstone.g10code.de>
References: <000101d6c0ae$43a38240$caea86c0$@on.yourweb.de>
 <d0b3b818-3b77-d612-2f2f-38a8b79e1bc5@bruckner.email>
 <fdcae5fd-6625-50a8-9acf-98f250d569a8@vulcan.xs4all.nl>
 <20201123060812.GA29830@r314251-amd64>
 <Ayl-RejoKz76wQ6qRB2Qj7iNn2Tk2W_BqUzu8EuyOHEU6w0wKKekkJWFiTmzsktW_UbVB1ZbGZwIUuMCTYKP1oQlNrfBBpVKVrtzNUZvH_o=@brainvitamins.net>
 <87a6v8l0s4.fsf@wheatstone.g10code.de>
Message-ID: <20201123230147.dl4q6xg6xsdjuo5i@raf.org>

On Mon, Nov 23, 2020 at 01:23:39PM +0100, Werner Koch via Gnupg-users <gnupg-users at gnupg.org> wrote:

> On Mon, 23 Nov 2020 07:22, cqcallaw said:
> 
> > At my job, I frequently send out summary charts and graphs surrounded by text.
> > Attachments simply do not work; my audience cannot spend the mental energy to
> 
> Proper MUAs display inline images without problems.  I recall that even
> exmh did this ~25 years ago.  It is just that the marketing department
> can't enforce the corporate identity on text mails - or are too lazy to
> create rules which work with plain text (and maybe inline images).
> 
> And well, I like HTML mails: my main address is free of spam thanks to a
> simple procmail rule ;-)
> 
> Shalom-Salam,
> 
>    Werner

Apologies in advance. I know this is all off-topic for
a gnupg mailing list, but for those who really hate
html email, and are able to function without it,
there's a potentially useful mail filter I wrote that
converts everything to text that can be converted, and
deletes everything else.

  http://raf.org/textmail
  https://github.com/raforg/textmail

It makes it look like everyone is sending you plain text. :-)

For everyone else, I recommend lots of phishing training
to mitigate the biggest risks of html email.

At least until gmail/outlook/etc. implement, by default,
the equivalent of Thunderbird's brilliant Torpedo
anti-phishing addon.

cheers,
raf



From guru at unixarea.de  Tue Nov 24 06:31:46 2020
From: guru at unixarea.de (Matthias Apitz)
Date: Tue, 24 Nov 2020 06:31:46 +0100
Subject: Ban HTML mails? Really?(was: Re: Thunderbird / Enigmail /
 Autocrypt)
In-Reply-To: <20201124001612.GA29694@valencia.lan>
References: <000101d6c0ae$43a38240$caea86c0$@on.yourweb.de>
 <d0b3b818-3b77-d612-2f2f-38a8b79e1bc5@bruckner.email>
 <fdcae5fd-6625-50a8-9acf-98f250d569a8@vulcan.xs4all.nl>
 <20201123060812.GA29830@r314251-amd64>
 <ef6b9134e0d3bb811db820af91b60c5b@mansfeld-elektronik.de>
 <20201124001612.GA29694@valencia.lan>
Message-ID: <20201124053146.GA35349@r314251-amd64>

El d?a martes, noviembre 24, 2020 a las 12:16:12a. m. +0000, Philihp Busby via Gnupg-users escribi?:

> As a personal policy, I do not respond to emails if they are only in HTML. It provides an excellent signal on when an email is actually worth the distraction. Even password-reset/verify-your-email emails will have text-only components. Mailchimp marketing emails, on the other hand, often skip over the plaintext version (text-only emails don't convert in their metrics, i imagine the images don't load and they don't know you read it).
> 
> This battle has only been lost when you give up.
> 

There are some other two battles to win: Don't top post and, second,
break your text lines around coulmn 72 :-)

	matthias
-- 
Matthias Apitz, ? guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
??? ????? ??? ??????, ??? ?????? ??? ?????????? (??a????? ????? ?????)
Without books no knowledge - without knowledge no communism (Vladimir Ilyich Lenin)
Sin libros no hay saber - sin saber no hay comunismo. (Vladimir Ilich Lenin)


From wk at gnupg.org  Tue Nov 24 08:37:31 2020
From: wk at gnupg.org (Werner Koch)
Date: Tue, 24 Nov 2020 08:37:31 +0100
Subject: Thunderbird / Enigmail / Autocrypt
In-Reply-To: <000001d6c1ba$a0172ec0$e0458c40$@on.yourweb.de> (gnupgpacker's
 message of "Mon, 23 Nov 2020 18:03:54 +0100")
References: <000101d6c0ae$43a38240$caea86c0$@on.yourweb.de>
 <873610l0i0.fsf@wheatstone.g10code.de>
 <000001d6c1ba$a0172ec0$e0458c40$@on.yourweb.de>
Message-ID: <87mtz7jjd0.fsf@wheatstone.g10code.de>

On Mon, 23 Nov 2020 18:03, gnupgpacker said:

> After further investigation about html mailing with Claws Mail: 
> 'Dillo HTML viewer' project has been updated Jun-2015, not available for
> Windows.

Mature software does not always need updates.  Nevertheless the plugin
code was recently updated to get rid of conditionals to build with gtk2.
Right, it is not availabale for Windows but ...

> 'litehtml' is available for Windows, but latest update is Oct-2015.

The latest update is just 6 weeks old.  The plugin is part of the
standard claws installer for Windows.  Right, the Windows installer is
often behind the source release (right now by a year).  But again, this
is a project by volunteers.

FWIW, for years we distributed Claws as part of Gpg4win but at some
point decided that it is better to let the Claws devs do the installer
so that we can concentrate on things we are can do best.


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/20201124/1f53def4/attachment.sig>

From wk at gnupg.org  Tue Nov 24 08:53:55 2020
From: wk at gnupg.org (Werner Koch)
Date: Tue, 24 Nov 2020 08:53:55 +0100
Subject: caching of passphrase is not working in windows ,
 gpg agent version 2.2.23
In-Reply-To: <CALgv3wQx9isrmM-FkEd54=EZUHFmGW3W5NJE5USdkt++bJujbQ@mail.gmail.com>
 (surender singh pawar via Gnupg-users's message of "Mon, 23 Nov 2020
 09:18:39 -0800")
References: <CALgv3wQx9isrmM-FkEd54=EZUHFmGW3W5NJE5USdkt++bJujbQ@mail.gmail.com>
Message-ID: <87im9vjilo.fsf@wheatstone.g10code.de>

On Mon, 23 Nov 2020 09:18, surender singh pawar said:

> 4.      from powershell started agent
>
> "$gpgPath\bin\gpg-connect-agent.exe" reloadagent /bye

Why do you do this?  The import operation already started the agent.  In
any case to explicitly start the agent please use

  gpgconf --launch gpg-agent

> "$gpgPath\bin\gpg-preset-passphrase.exe" -v -c -P "$pgpPassphrase"

You need to add the keygrip to the invocation; from the man page:

  gpg-preset-passphrase [options] [command] cacheid

       cacheid is either a 40 character keygrip of hexadecimal
       characters identifying the key for which the passphrase should be
       set or cleared.  The keygrip is listed along with the key when
       running the command: gpgsm --with-keygrip --list-secret-keys.
       Alternatively an arbitrary string may be used to identify a
       passphrase; it is suggested that such a string is prefixed with
       the name of the application (e.g foo:12346).  Scripts should
       always use the option --with-colons, which provides the keygrip
       in a "grp" line (cf. ?doc/DETAILS?)/

Thus something like

  gpg-preset-passphrase -vcP "$pgpPassphrase" 00112233445566778898aabvccddeeff

You should also review your architecture and the attack tree: Why use a
passphrase at all (with its KDF induced delays) if you put it into a
script.  Better remove the passphrase from the key.


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/20201124/baa46cad/attachment.sig>

From surendersinghpawar at gmail.com  Tue Nov 24 09:30:18 2020
From: surendersinghpawar at gmail.com (surender singh pawar)
Date: Tue, 24 Nov 2020 00:30:18 -0800
Subject: caching of passphrase is not working in windows , gpg agent
 version 2.2.23
In-Reply-To: <87im9vjilo.fsf@wheatstone.g10code.de>
References: <CALgv3wQx9isrmM-FkEd54=EZUHFmGW3W5NJE5USdkt++bJujbQ@mail.gmail.com>
 <87im9vjilo.fsf@wheatstone.g10code.de>
Message-ID: <CALgv3wR83O19EEKkRKAR12iW3f_hc8L9OzydV1VrW8aBWzC6jQ@mail.gmail.com>

Thanks for quick reply i did the following command only to put
passphrase in cache  ( missed id while writing mail )  got id from gpg
--list-secret-keys
 gpg-preset-passphrase -vcP "$pgpPassphrase"
*00112233445566778898aabvccddeeff  *

How can I confirm if a passphrase set in the cache ?  is there any debug
log which I can see to confirm it.

Can you share .if possible, any steps how to build windows gpg agent using
source code.? Most docs are for linux.

details for question is here as well
gnupg - windows :GPG is prompting for passphrase even though passphrase
cache is set in gpg-agent - Super User
<https://superuser.com/questions/1604539/windows-gpg-is-prompting-for-passphrase-even-though-passphrase-cache-is-set-in>


Thanks
surender

On Mon, Nov 23, 2020 at 11:55 PM Werner Koch <wk at gnupg.org> wrote:

> On Mon, 23 Nov 2020 09:18, surender singh pawar said:
>
> > 4.      from powershell started agent
> >
> > "$gpgPath\bin\gpg-connect-agent.exe" reloadagent /bye
>
> Why do you do this?  The import operation already started the agent.  In
> any case to explicitly start the agent please use
>
>   gpgconf --launch gpg-agent
>
> > "$gpgPath\bin\gpg-preset-passphrase.exe" -v -c -P "$pgpPassphrase"
>
> You need to add the keygrip to the invocation; from the man page:
>
>   gpg-preset-passphrase [options] [command] cacheid
>
>        cacheid is either a 40 character keygrip of hexadecimal
>        characters identifying the key for which the passphrase should be
>        set or cleared.  The keygrip is listed along with the key when
>        running the command: gpgsm --with-keygrip --list-secret-keys.
>        Alternatively an arbitrary string may be used to identify a
>        passphrase; it is suggested that such a string is prefixed with
>        the name of the application (e.g foo:12346).  Scripts should
>        always use the option --with-colons, which provides the keygrip
>        in a "grp" line (cf. ?doc/DETAILS?)/
>
> Thus something like
>
>   gpg-preset-passphrase -vcP "$pgpPassphrase"
> 00112233445566778898aabvccddeeff
>
> You should also review your architecture and the attack tree: Why use a
> passphrase at all (with its KDF induced delays) if you put it into a
> script.  Better remove the passphrase from the key.
>
>
> Salam-Shalom,
>
>    Werner
>
> --
> Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20201124/4a893380/attachment.html>

From patrick at enigmail.net  Tue Nov 24 12:26:43 2020
From: patrick at enigmail.net (Patrick Brunschwig)
Date: Tue, 24 Nov 2020 12:26:43 +0100
Subject: GpgOSX for Apple Silicon
Message-ID: <421282bb-796b-ed49-4957-723aa933ac65@enigmail.net>

I have created a first version of GpgOSX 2.2.25 for the new Apple
Silicon architecture (ARM processor).

However, I don't have a machine to test my build, thus I can't verify if
it works. Therefore, if someone has access to an ARM-based Mac, then
please get in touch with me.

Thanks,
Patrick

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

From kloecker at kde.org  Wed Nov 25 10:45:28 2020
From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=)
Date: Wed, 25 Nov 2020 10:45:28 +0100
Subject: caching of passphrase is not working in windows ,
 gpg agent version 2.2.23
In-Reply-To: <CALgv3wR83O19EEKkRKAR12iW3f_hc8L9OzydV1VrW8aBWzC6jQ@mail.gmail.com>
References: <CALgv3wQx9isrmM-FkEd54=EZUHFmGW3W5NJE5USdkt++bJujbQ@mail.gmail.com>
 <87im9vjilo.fsf@wheatstone.g10code.de>
 <CALgv3wR83O19EEKkRKAR12iW3f_hc8L9OzydV1VrW8aBWzC6jQ@mail.gmail.com>
Message-ID: <5660109.lOV4Wx5bFT@collossus.localdomain>

On Dienstag, 24. November 2020 09:30:18 CET surender singh pawar via Gnupg-
users wrote:
> Thanks for quick reply i did the following command only to put
> passphrase in cache  ( missed id while writing mail )  got id from gpg
> --list-secret-keys
>  gpg-preset-passphrase -vcP "$pgpPassphrase"
> *00112233445566778898aabvccddeeff  *

Is this id really the keygrip of the key? Or is it probably the key's 
fingerprint? You need to add --with-keygrip to make --list-secret-keys show 
the keygrip.

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/20201125/f262eeb3/attachment.sig>

From dirk.gottschalk1980 at googlemail.com  Thu Nov 26 12:10:59 2020
From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk)
Date: Thu, 26 Nov 2020 12:10:59 +0100
Subject: Five volunteers needed (EU only please)
In-Reply-To: <20201005163757.0000391f@300baud.de>
References: <20201005163757.0000391f@300baud.de>
Message-ID: <39d845f714609d1ce09286e991ab1056e9dfae2a.camel@googlemail.com>

Hello Stefan.

Am Montag, den 05.10.2020, 17:37 +0200 schrieb Stefan Claas:
> Hi all,
> 
> while I did some JAB-Code experiments with MMS, to send GnuPG
> messages with a dumb
> phone, I came up now with a new idea. :-)
> 
> For that I need five people who are willing to share with me their
> postal address.
> You can send me your address GnuPG encrypted. I will not store your
> address on my
> computer and will delete your email, once I received it.
> 
> My new idea is to send encrypted postcards or letters, with an NFC
> tag attached,
> containing a GnuPG clearsigned test message. I like to see if the
> postcards will
> arrive in proper condition, so that the NFC tags are still readable.
> [...]

For this test I would suggest to not use NFC stickers or anything like
that. I would suggest using plastic cards with embedded NFC Tags.

The reason for my suggestion. I'm working at a company which creates
and sells solutions for european transportation and logistics
companies. We use NFC tags for a drivers license check. These are
stickers on the drivers license card to check if it is available.
Removing them from the card destroys them. We now had multiple times
the problem that those stickers were dead on arrival. We did a fw tests
ans saw that the problem occurs only after the tags were on the postal
way. Perhaps some strong magnetic fields in the postal systems, or
anything like that.

Now as we send and receive those tags in boxes, we didn't have Problems
anymore.

Cards never had this problem, as far as I can tell.

The Tags should have enough memory to take encrypted messages. I think
at least 12k. The more memory, the longer can the message be.

Another benefit of using plastic cards instead of sticker tags is: They
are reusable.

Kind regards,
Dirk

-- 
Dirk Gottschalk

GPG key Fingerprint: C8F4 4499 861E D5B7 66FC??18F5 8E34 AF58 6574 32C8
Keyoxide: https://keybase.io/dgottschalk
GitHub: https://github.com/Dirk1980ac

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

From johndoe65534 at mail.com  Thu Nov 26 19:12:27 2020
From: johndoe65534 at mail.com (john doe)
Date: Thu, 26 Nov 2020 19:12:27 +0100
Subject: Verifying and checksumming new release is somewhat cumbersom
Message-ID: <5fe4d4c3-8ab2-6555-792d-00b59997b9b8@mail.com>

Hello all,

I see that at (1) and (2) the public keys block and the sha1sums
respectively are listed on their corresponding page.

Is there a URL to download those sha1sums and those public keyss as  files?

That is for checksumming I could simply do:

$ wget <URL-OF-CHECKSUM-FILE>
$ sha1sum -c <CHECKSUM-FILE> --ignore-missing

and for the public key I could do something like:

$ wget <URL-OF-PUBLIC-KEYS>
$ gpg --import <PUBLIC-KEYS-FILES>
$ gpg --verify *.sig

I understand that for this last step I could also do:

$ gpg --keyserver-options auto-key-retrieve veirfy *.sig


Any feedback is appreciated.

P.S.

If I can I'll be more than happy to help tweaking the release process in
that regard.


1)  https://gnupg.org/download/integrity_check.html
2)  https://gnupg.org/signature_key.html

--
John Doe


From spam.trap.mailing.lists at gmail.com  Thu Nov 26 19:46:53 2020
From: spam.trap.mailing.lists at gmail.com (Stefan Claas)
Date: Thu, 26 Nov 2020 18:46:53 +0000
Subject: Five volunteers needed (EU only please)
In-Reply-To: <39d845f714609d1ce09286e991ab1056e9dfae2a.camel@googlemail.com>
References: <20201005163757.0000391f@300baud.de>
 <39d845f714609d1ce09286e991ab1056e9dfae2a.camel@googlemail.com>
Message-ID: <CAC6FiZ7851t2te2wX2pmhkqXfp6_vYDnH7+poYCj_MYL1cUzyQ@mail.gmail.com>

On Thu, Nov 26, 2020 at 1:13 PM Dirk Gottschalk via Gnupg-users
<gnupg-users at gnupg.org> wrote:
>
> Hello Stefan.

Hi Dirk (long time not seen you!),

[...]

> For this test I would suggest to not use NFC stickers or anything like
> that. I would suggest using plastic cards with embedded NFC Tags.
>
> The reason for my suggestion. I'm working at a company which creates
> and sells solutions for european transportation and logistics
> companies. We use NFC tags for a drivers license check. These are
> stickers on the drivers license card to check if it is available.
> Removing them from the card destroys them. We now had multiple times
> the problem that those stickers were dead on arrival. We did a fw tests
> ans saw that the problem occurs only after the tags were on the postal
> way. Perhaps some strong magnetic fields in the postal systems, or
> anything like that.
>
> Now as we send and receive those tags in boxes, we didn't have Problems
> anymore.
>
> Cards never had this problem, as far as I can tell.
>
> The Tags should have enough memory to take encrypted messages. I think
> at least 12k. The more memory, the longer can the message be.
>
> Another benefit of using plastic cards instead of sticker tags is: They
> are reusable.

Thanks, I am aware of these cards, but wanted for my tests to avoid
higher costs and I only wanted to see if the postcards and tags
arrived in proper condition.

Should I use cards in the future then I would also use security envelopes.

Best regards
Stefan


From wk at gnupg.org  Thu Nov 26 21:10:50 2020
From: wk at gnupg.org (Werner Koch)
Date: Thu, 26 Nov 2020 21:10:50 +0100
Subject: Verifying and checksumming new release is somewhat cumbersom
In-Reply-To: <5fe4d4c3-8ab2-6555-792d-00b59997b9b8@mail.com> (john doe via
 Gnupg-users's message of "Thu, 26 Nov 2020 19:12:27 +0100")
References: <5fe4d4c3-8ab2-6555-792d-00b59997b9b8@mail.com>
Message-ID: <87ft4vhoad.fsf@wheatstone.g10code.de>

Hi,

and thanks for asking.

On Thu, 26 Nov 2020 19:12, john doe said:

> Is there a URL to download those sha1sums and those public keyss as  files?

The problem with sha1sums is that a single publication would be easy to
fake.  The only known countermeasure is to widely distribute them.  We
do have them on the website as you noticed, they are send out by signed
mail to several thousand subscribers, and our and other mail archives
carry the release announcement with the checksums.

No, there is no single file with the checksums because that would be a
too easy target for an attacker.

> and for the public key I could do something like:
>
> $ wget <URL-OF-PUBLIC-KEYS>
> $ gpg --import <PUBLIC-KEYS-FILES>
> $ gpg --verify *.sig

And please check the printed fingerprint against copies of the
fingerprint distributed in the same way as the checksums.  The keys are
also quite well connected in the Web-of-Trust, which can also help to to
validate them.

The advantage of the public keys and the fingerprints is that they do
not change and thus you only need to validate them once once and sign
the keys so that you can trust them in the future.

The release signing key as well as most commit signing keys are token
based and thus it is very unlikely that this key material will be
leaked.  The worst what could happen is that the build machine is
compromised by dedicated malware which swaps the to be signed data
during the build process - so we would unnoticed sign them with the real
key.  But well, that is quite advanced and enough people are building
from source and closely watch our repositories for signs of intrusion.

> I understand that for this last step I could also do:
>
> $ gpg --keyserver-options auto-key-retrieve veirfy *.sig

Don't.  For verification always use

   gpg --verify file.sig file

and check the output well.  If you need to automate this, use gpgv and
put all the trusted signing keys into a dedicated keyring.  For
automating this with gpg, I would suggest to write a gpgme based tool.


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/20201126/68bce24c/attachment.sig>

From spam.trap.mailing.lists at gmail.com  Fri Nov 27 23:07:12 2020
From: spam.trap.mailing.lists at gmail.com (Stefan Claas)
Date: Fri, 27 Nov 2020 23:07:12 +0100
Subject: Verifying and checksumming new release is somewhat cumbersom
In-Reply-To: <87ft4vhoad.fsf@wheatstone.g10code.de>
References: <5fe4d4c3-8ab2-6555-792d-00b59997b9b8@mail.com>
 <87ft4vhoad.fsf@wheatstone.g10code.de>
Message-ID: <CAC6FiZ6UBr2U3R_xyOu5WdH-Z688AEcUu63op-qC=Zf_=gu5eg@mail.gmail.com>

On Thu, Nov 26, 2020 at 9:18 PM Werner Koch via Gnupg-users
<gnupg-users at gnupg.org> wrote:
>
> Hi,
>
> and thanks for asking.
>
> On Thu, 26 Nov 2020 19:12, john doe said:
>
> > Is there a URL to download those sha1sums and those public keyss as  files?
>
> The problem with sha1sums is that a single publication would be easy to
> fake.  The only known countermeasure is to widely distribute them.  We
> do have them on the website as you noticed, they are send out by signed
> mail to several thousand subscribers, and our and other mail archives
> carry the release announcement with the checksums.
>
> No, there is no single file with the checksums because that would be a
> too easy target for an attacker.

Maybe not common among programmers, but you could easily clearsign
the shasums text file and then use a public time stamping service additionally,
thus first time users would know that the signed shasums file would have been
actually signed at day x time y, if you would also provide the .ots file.

https://opentimestamps.org

Regards
Stefan


From cqcallaw at brainvitamins.net  Fri Nov 27 23:52:27 2020
From: cqcallaw at brainvitamins.net (cqcallaw)
Date: Fri, 27 Nov 2020 22:52:27 +0000
Subject: =?utf-8?Q?[cross_post]_Why_does_verification_of_a_detached_signature_result_in_a_=E2=80=9CMessage_digest_did_not_match=E2=80=9D_error_for_OpenPGP.js=3F?=
Message-ID: <XRV4C156jQ_OfN2VIjrIf6i3eC6mkP8wJkN7_aHG_IGhJyG-v26avwcxoXemxX--Mng5wKEHhBZPQYDDfTApKlwTx3IBQWaVQa1XOHyadgs=@brainvitamins.net>

Hi folks,

This is an OpenPGP.js question, but I've gotten no answers from Stack Overflow, so I'm widening the cast of my net in hopes a relevant expert is lurking about.
I couldn't find any community policy that such a cross post might violate, but if I missed something, please feel free to (gently) inform me of that fact.

I can sign and verify a test file through `gpg` without issue, but verifying the signature through OpenGPG.js fails with the error, "Message digest did not match." Why is this?

```
$ gpg --armor --quiet --batch --yes --detach-sig index.html
$ gpg --verify index.html.asc index.html
gpg: Signature made Wed 25 Nov 2020 08:26:34 PM PST
gpg: using RSA key C361FDC3F93B9E8F8BD7E08D5F873051B2D6C347
gpg: Good signature from <key>
$ node sandbox.js
{ signatures:
[ { keyid: [Keyid],
verified: [Promise],
signature: [Signature],
valid: false,
error:
Error: Message digest did not match
at Signature.verify (/home/caleb/src/islands/node_modules/openpgp/dist/openpgp.js:41176:11)
at process._tickCallback (internal/process/next_tick.js:68:7)
at Function.Module.runMain (internal/modules/cjs/loader.js:834:11)
at startup (internal/bootstrap/node.js:283:19)
at bootstrapNodeJSCore (internal/bootstrap/node.js:623:3) } ],
data: 'Test!\n' }
```

sandbox.js (based on [the OpenPGP.js example](https://openpgpjs.org/openpgpjs/doc/index.html#create-and-verify-detached-signatures)):

```javascript
openpgp = require('openpgp');
fs = require('fs');

async function sandbox() {
path = './'

let msg_data = fs.readFileSync(path + "index.html", 'utf8');
let sig_data = fs.readFileSync(path + "index.html.asc", 'utf8');
let pubkey_data = fs.readFileSync(path + "pubkey.asc", 'utf8');

let msg = await openpgp.cleartext.fromText(msg_data);
let sig = await openpgp.signature.readArmored(sig_data);
let pubkey = await openpgp.key.readArmored(pubkey_data);

openpgp.verify({
message: msg,
signature: sig,
publicKeys: pubkey.keys
}).then(function(verified) {
console.log(verified);
});
}

sandbox();
```

index.html:
```
Test!
```

index.html.sig:
```
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEw2H9w/k7no+L1+CNX4cwUbLWw0cFAl+/LnoACgkQX4cwUbLW
w0cfcBAAlYx+81hVyOmBKF8BVHUyZ7c7xNEDEy8fe2EvEQlz4KL+O5PdWFWdlopl
FrdHenxQktfTZPs+bjWTu52OwIGomAQP7Vu4zvkScQw2M4xdBwuJTsB9/hZNJPLX
+9lWFVUffYDFPHziNRZCK1vlYpi/fJO1KrmK3ggSJCUylkjl+QtZbSE1EAuxNF4S
3NsxzH1YcyuZP8dvuMFqfHNQVfDcny5AB67fmHdf/aMnq6B05d437qqfVgCjIAKp
11naQ4g8hNSVIwacCWO/sjsa5kSvg2oKI76GTQtBFwybLh9KJTByOUbkbNOJooWM
+kpbfWSIQ7Dtl6Q4dDF9C2QJH0Af4YgKjzgT3hWU57FEw/3i7DTseZ3r2YtDcBkv
GNaFmRG0mBkRy5pyAliKC91LPWH/FznRQLSA4S2XNce1AxNJKWZpxlbtf79ns6RQ
TagE2gRt/vq+UjdN+FL6uyEdhVroWOv2vFTY5bsdD9wy8HyBSyXr0wfSMze7Ci1e
t1s098eM9MFwtx2oNOcWbKYxHy4lnDotnGkZ1WFOQMWHTKlVichL1eFNQcx08Mhw
82hoOnS49kNHrzgVV8jP7y+0Nfjcg9vqUV1kR2KkxDO7xoxtwev0k7Ol/mDOA3xi
ckPKkU60NlzMHsQe+DzW2wCMKC751ds50huLXMo1txoQ5yo6m6o=
=7Z6F
-----END PGP SIGNATURE-----
```

pubkey.asc:
```
-----BEGIN PGP PUBLIC KEY BLOCK-----

mQINBFv5CNMBEADgrYOZdSUwQr+tvcL2l/BtXfJ/baeZQvwT376QnwwZ6dvYjuOE
gxLUXmLAXt2x+xhdBztUGk6IDM0X498N4tnoq4nyuRCpeH2zyMqGGXDeiEhZq7gJ
P1J6DruBw8zW0K+1Cu8qzJOXXHHVj040A4wlwCeqZiB/ZgxuuFGvoQRtGZhVIMKW
ZNPy7fcki3QvbkLzVkUyJJz2LiQMf9IcVGb534SH4NTts+TqEHFL9LAuKk8Yx+nY
EMiSTkDMtBCRNDKOM7+XZTfs51KfMivwQd5CxHrm1qB8K67qGApNwXODE16ckGyc
ttSbniVtRbaoFw95eusXTHOOSuJzaFvAe5zQXpNPgQfMI3Wi/iqlhy/wb5XCOE3M
H6sRKThozGCXrvnPooAetsSTDjw/5kUAPUG0Xc3aDFQf0kXj5NVqkN2MOBv8N3ZP
pBtsJwYK+bp8JNzBMuTAOiKXoj/6HyKnFu/UpeisRmjxvJ+naBMRajD5dNsweyyW
w5ZNknY9/GTkjnmBycwGd2xCm/Dbq6X+PI1MY69/FzzyoavTM0a63sG4Ipo6sNGu
9pvBHrnwMuE8Jvr2TGC99ems/61vmTujwRcFsb122wpXhRgX4FEv8POnM0EmL/l1
wdr+SRLY+kwWlNrSpfuB7FZXMpt9GqyOPA1FYzrXu9nAgjEgq5oXouroPQARAQAB
tCNDYWxlYiBDYWxsYXdheSA8Y3FjYWxsYXdAZ21haWwuY29tPokCPgQTAQIAKAUC
W/kI0wIbAwUJCWYBgAYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQnT4cLjBJ
fqtb/Q//TfWxvQmVdbOd6pBymFgfAoi+K8fKg4H38ogbeFjxeEUBz0+tfcnQ0Wj+
4v4kTha71br7MzPr5P1vCM47lgbigoEJlSay0J5CKZq3fe1xXrUh4Mat+Fq8EDbM
QWYum5MAelD0yjfr7SbGNjiVm6zVyLAC3qRFCdjvxVaYn0lpEwXPMwH3SOM2z4D/
UiUcOlJYuYMgyxAXbGjK7mpBFUtS49LiY1qZq20ZMLEGcv+7tydNA4nKtBru7EW8
Afnx9LM3+xyk6XPJa/b0AKt3N5GEFrwwx8RDmmoIa3uqxnjFvbUfLGmOqBCbawRz
d871e7xZCwUr/YqIgtomOMJlLmyVMiyXrHJOLywRDQGWPYUXVQV6/6YstWmCrY8e
m7sUzSJyWafh6sof4thbWfMTgePrskbnsN1VZULc0JrYTEXW3oNRdgk8FfxCcT9P
MszKhIR/rEhDHMY+A4rpOG1/tC2vw1B0TyDYyueCa9K8ubogFLQpKKpaOVuMqIQx
GcgE6utdtmXtJlDrPDM4DCPEeyqw9/W5Dfmuj9sQHlOE0J243GerpJWp2iGuV27E
YlUjAEcKXGIpgbNyucd5/e2Xvvb8HnyWeK4IiI9vDDminjXefYTv8Z5/736aTzEx
Gwcnh5B+c9P+RRmwUhHvdu7POclnbKYmUEVk2wW462lczVA2nDi0K0NhbGViIENh
bGxhd2F5IDxjcWNhbGxhd0BicmFpbnZpdGFtaW5zLm5ldD6JAlcEEwEKAEECGwMF
CQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AWIQRyvkAwXZiPVUzqGgSdPhwu
MEl+qwUCX6bX9wIZAQAKCRCdPhwuMEl+q7AvEACXYo7sEn1JW6lszLD6/DBxmgog
fVl4YVO1pGIc5Ub2Ua3FrDNOCWNIPpkB65rx9btK5j6mtqdqUGpKKcVGoAf6y7m7
PlL9RLTUwG/T4xTMprQlYnrK5yjQRnRzHzi5jyOEcweDtwlp6J3Jm0uBYywIBt0+
QtogNWMrdOyuBqlA0uhCDqVcUjuur31N7BmYFe6SZ80GBAU/zFVXKRWp3ZLgLOkU
AulaVZ/WwFrAIi1vM7pCx4T2gQ9fXnxj7xzvuhnAJXmODlPlF7rPnqevrTpv0Dqv
M4rxmjCCFdOfxjPkFjdwskbzFRJe9zbbhRUkDFuksvxM/ixROo+wMq9zlaRTzbiG
G29ee3WnNIn3WW8NOvy4tsxIvQOjufk1wP4nnIjXlxn8qPQrmkCcZGJqSlrmuFvx
yAj/qEGAb6w0Yu+A+6hgb6amUhxI2CIL3leLOW+pXjVqEKknJ7D52OEk5m50YTam
xfzl6SiqE/QQST1WOnBUtYvOBG/v+om/tXvkSkQRALhoEOa8lj9ZOUs76w139qm3
ZNVls+cBAaKBr8s4Z9X6MohG8/ls/frFWYlqN4ettG3ULsW88RQUzr3J9PtHSHnD
A8SZtqqSZY7kKmw/fk3R279t0BJzTqKCh3gybxTXWPIG44G30lsbP5pqK2ejt9nu
YDnNvZjCB05a9Rue07kCDQRb+QjTARAAxiIZO0TrY73yrBaeXtIknEVT3Z2+OhJd
YL6RAaZk0sf6iX6CFdEAeO7XS3W3SZEITzfl3+rkdBJ3k3HKLdQyrCCpjOUK4orW
bLsEBTQl7IDMJJ4YBO2BSc7I+akiq+Flx8t4JefAVlR2i5Vf/FxqutoxyZ13L/2k
gyqc95UAhVfykJB/vUgodV1VAbOXmIEL53MAXDC7HQWUuW3eKzWsJnw+i1LD+ZPE
bYD/mIKdKeqWQZW6E6N7jj7dXhErQn/0cFpIssSxWPNF63mcPTj4Yq61ruIqjarV
tVGKL40ekL2grAF0n/2iERYSqUo18YATlJjrMbxR1k4Td67hSEJFuarJYwQqPI93
20/izYJMPrdwAzUf/jPa0lDZqaQK7xuln2/cpusFZC4p98A7Dn6bHxkYv3ymGhVz
WiAohX6vc5kYh5Qdsh1pUloInjGm2f0QimOGt+PU7U9KFGcj5c4UGaJkrLM9Qeoa
qUGN7pwzBF6NRdmAOuyB7F/e7xhMz6xdQ8iAuwbrLcwi6i1FcworwoRMmaK93etN
+1hrYjQ+ru95ZXodvPkVTeYAm8NCoVE3CmMxi3RhNAF/W1xvxO459Cj3mRNpIg1N
uw4YvhtKNW1HQhUzZr7HUu1TyKsk8uX6XTn6SnXZvd5gO/Xi7merVwvH0XlM5k9J
f6a6Xziv+ZUAEQEAAYkCJQQYAQIADwUCW/kI0wIbDAUJCWYBgAAKCRCdPhwuMEl+
q87mEADU3k1JuulGC5It3S+bNd692tcofCY0Q75EBCl0SOi0xFEh0KyCqG9DEjCo
MSFV033G5oVZ/CGQhDw3MQ1wSVVZn3yviGlEkde0KjCWXawOcuJo5GJDtltCegne
dcnCp+DqPnwhSL3OkASYG015DACq1iIGJSN/TCEPx3+myhKrdGjpDWA/6tUm1985
AQ3q2qzJi6LskOKHw/stel72OHexTjTFWQVFq+AVi63O3HMhOQ/wdEhO/5Snvr1P
bp388hi+jbubyysbAtU0VO5fuHKE+NCVUJ+DB0ju2UqtFiVP/jj6efOC3piEKFfn
pSVYCbGwJpJdM9DNPc5RQFN3hCxe0CQovReitz5KdCGQmEra18WmFgSdn/RBVHUy
xvh/FSntsfeQ6h6QwzFGvab5s2VUCVfAzyRCsZUTZ0i/yIiQe838oYsCDo5DxUgW
r8pplwqlH14mItrmv3Tlwifgol5XCESDub4nnBMsI1g18K/Mva2wghg02ClJAjxl
7bakRe5I+G1OD6n0uv/HFJNhW29SFqfFvyJLv754C7Q/iR0p1UNyuV6gqK6/Nf1B
Y2c/1fpSqvoS1JUTtLIOxJNEOtFqDwylp1K3xITMjIQFESbxfEp5wrA5y2aLExTM
cBkEBIB/Ts/5Jekwo1/8khZ1vbjMM8GqaL4WEBlOth5heZ/Jh7kCDQRdSQxpARAA
vTaGTccLWcrknJlLfer5KH+X8T/Uqj6KSS7HIA9xo59sP4cXpMQihoUc+7zemq7R
TnBryudxQOdllQw3XUYvXC5/iiHJffSxAh1s7UjlxKbvG6cPs5FKHQ1ElZ9n6WEx
GuA/FSyLHnKtjaldHM1VaNBfShs92xvolyWFohmjcjrod5G1AEDk+UrHM7PKYHCe
65pfils9uoGnUe9+wYBRfcQtQsODtXLkEQez8nLwZvfxn/IzQ8ZJttRy6kkrzOor
ZyFKRsLEeugQ5Oih5xmzyPRYAS0GUhfHOSYZnUQmfw1ikcpo5ZIKDGARZgUY9rSj
KKqpaN/BE15VqXuigiSfUf/jEVf1Kk+8SQ+Tt5V12yJUYZQNGr+zEZOu/gQe8hNM
/Hfx0MK6NYxOqhjTdxqbsxHLOCG4cJWp7LS9OqGmCGu9V0MpK8/Dg8Zg5+LL4dM2
dsqroRVWSOao6rnqizOYZ0oniNwWOAm3+QMmwrgRg0TJv7q56Mh8k5I1QHjqWcVw
BPOlRvfog1iOXkC7er4hZgYGRcdeE4ztJsqhfUkC1wBRj9PnhtlfMeXaZ/S/oYdd
EnsiCKbntCzYi8jvF/Ax8pTNG5e5RjQVYAitK03NG3MK0dgrPya0J9cLwNrefbIm
/Oh5QdY464WJGkpJvw67jfytT3F477pUHBqY0WaZbmMAEQEAAYkEcgQYAQoAJhYh
BHK+QDBdmI9VTOoaBJ0+HC4wSX6rBQJdSQxpAhsCBQkSzAMAAkAJEJ0+HC4wSX6r
wXQgBBkBCgAdFiEEw2H9w/k7no+L1+CNX4cwUbLWw0cFAl1JDGkACgkQX4cwUbLW
w0eEIw//YFO4X9g2C5eLDU7RtgMu+RFHyOTncpQwCcmr4RpQSD/Cz5K9si3zby6f
eq/niEXzU88cYPCIMBT0JwEKArZlgQv8vbBKiT4C79QmlIkShSsp56dlSV4KqzyA
u8dMPFgXR2/PKEiWyflHhLVP6cx2hNgWEMJ0WT8kTcx33GnGtGxMdYtr7y15Wxe3
okWhOpVEgYFeWRudxwpcPPfayIlBsW7sBiI0ez2hlfa29iQQP7kSSNw27nn4ARBQ
wisythPsKwvzaugcEyEXSf1rmI5kfcvHBoNBwdLnA1S7UTgs+NF2xeMsjOas+5ag
quUkghcndM0DIM6Oe2R1QrBsEu3oyqQJWjWK3MkF8gT+Fs9NM38J+8Yij54w0lXA
ZdQOU8Nbz2B6w2HhMXJctry/Te3swZN7czKl65PZ3nxU3qP1AvWiy91MjZq94BUU
yGjp44/t7gHATEAxo6n0hCWBy/hmXlBb2vVV4QptUBi8Xh0nUcYtAEZiK4bl9KIw
XpTGeg9bxMokgo3l4FiVRRLOeCJaljnp3WagqQ0enet0s/VXMlTgBG3mH13fWVZM
GEv1GuChi01IcBJ2qSGz0BFaAP2nlfGOomhvpkT4jM6C9cZgcFk6cJ/jTtMDEEXR
+AKA33kdM286NulrMQveT3C/1mQoHksCwicq6jY0tqPBUzkRSL6ibg/+LPBPMHGD
s2XohNNNRQ34UG0W9Go5ZWfDfiRpIyix8YKENNQN8OEM6kGyyuxoHkhioSno33cV
pbnNA3sIcqmvxyxaw+352u5zgGSNJmHE4ObKbZs8s5A1UW49Tf0SyeUbxKRQzogr
B6oGlfqEjA0gZ2aVwa7ZIu0gt1bjrMtF7d9uAkoBuTkwkQyxQ9qIJ5Tin8tQE1q1
idofW0FpzXNK0N5n3jUOOIajWbret4eZ3YXUFNh0gX4UD8VJ811ZzaaqCDcCz+Ss
B4JiPcb9kOz8i+R7FhPvi6yqxd5+uRkMdCL+0WtXqzGZpd7YXZwf938fAfdGabgb
/3SaSsMKkZrheQNINAh5G1OQ88CB/kD/sTBN7dv7qakdJlB1cr0oKALVu5IXvyDb
kMyYp8xIT9pT7vLdDs7hJDu7OhTBNf9FSIa075V68e5jZ2J67k4LhXkaViAsQylY
eZ0nR4nbfRGugPsQml4KX+N9m8eIi4OGWobE9oDpDP2gGuZY56Vf80Ao6fRDQUtf
/d7rPF7aYg3ST0GaTwQO/2tSEPn6xaMjGr7I9NQmtwQxfa3rt8ESEsO0sEcpR02k
wwhdk/GvJf8V/lR747/xNY5ZNr+fujPSLCBrWqJBfK+61DUpqeKN6cHPjNELvQTo
tYSsa0zo3W8EwXhkoia5hOf/YhubcMkhqXU=
=Hgou
-----END PGP PUBLIC KEY BLOCK-----
```

`npm list` shows openpgp at 4.10.8.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20201127/6b7d9ef1/attachment-0001.html>

From karmanyaahm at gmail.com  Sat Nov 28 07:00:01 2020
From: karmanyaahm at gmail.com (Karmanyaah Malhotra)
Date: Sat, 28 Nov 2020 01:00:01 -0500
Subject: Changing compression configuration
Message-ID: <d8d65ed2-fc8c-db52-84ba-ed430d9e6dc0@gmail.com>

I'm wondering if it would be possibly to somehow use something like
(pbzip2)[https://www.archlinux.org/packages/community/x86_64/pbzip2/]
instead of just regular bzip2 when compressing files. I'm not sure if
this would work with how GnuPG is designed, but it would be nice if
compression could be multi-threaded since using one thread is the
bottleneck in my system when using GPG with large files (backups so 100s
GBs).

I have tested that encryption can be sped up by disabling compression
but that would increase storage usage. (or using another algorithm, but
ZLIB and ZIP are both CPU bottlenecked).

Thanks,
Karmanyaah Malhotra
--
Contact me at https://karmanyaah.malhotra.cc/contact/

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

From johndoe65534 at mail.com  Sat Nov 28 07:57:05 2020
From: johndoe65534 at mail.com (john doe)
Date: Sat, 28 Nov 2020 07:57:05 +0100
Subject: Verifying and checksumming new release is somewhat cumbersom
In-Reply-To: <87ft4vhoad.fsf@wheatstone.g10code.de>
References: <5fe4d4c3-8ab2-6555-792d-00b59997b9b8@mail.com>
 <87ft4vhoad.fsf@wheatstone.g10code.de>
Message-ID: <469842e0-86fa-cd41-f80f-be7efec7d754@mail.com>

On 11/26/2020 9:10 PM, Werner Koch wrote:
> Hi,
>
> and thanks for asking.
>

Thanks for this.

To be sure that I understand you correctly, I took the liberty of
rewording your answers.

> On Thu, 26 Nov 2020 19:12, john doe said:
>
>> Is there a URL to download those sha1sums and those public keyss as  files?
>
> The problem with sha1sums is that a single publication would be easy to
> fake.  The only known countermeasure is to widely distribute them.  We
> do have them on the website as you noticed, they are send out by signed
> mail to several thousand subscribers, and our and other mail archives
> carry the release announcement with the checksums.
>

If I look at Debian (1) for example, the checksum file is gpg signed.
Assuming that I understand correctly, the Debian approach is not a safe
way to make the checksums available?propagate?

> No, there is no single file with the checksums because that would be a
> too easy target for an attacker.
>

Even if the file would be gpg signed?

>> and for the public key I could do something like:
>>
>> $ wget <URL-OF-PUBLIC-KEYS>
>> $ gpg --import <PUBLIC-KEYS-FILES>
>> $ gpg --verify *.sig
>
> And please check the printed fingerprint against copies of the
> fingerprint distributed in the same way as the checksums.  The keys are
> also quite well connected in the Web-of-Trust, which can also help to to
> validate them.
>

You mean by checking if the  fingerprint of the downloaded keys match
the one listed on the web site?

> The advantage of the public keys and the fingerprints is that they do
> not change and thus you only need to validate them once once and sign
> the keys so that you can trust them in the future.
>

Okay, if the fingerprints matches I should sign the keys with mine.

>> I understand that for this last step I could also do:
>>
>> $ gpg --keyserver-options auto-key-retrieve veirfy *.sig
>
> Don't.  For verification always use
>
>     gpg --verify file.sig file
>

Okay, won't do that anymore.

> and check the output well.  If you need to automate this, use gpgv and
> put all the trusted signing keys into a dedicated keyring.  For
> automating this with gpg, I would suggest to write a gpgme based tool.
>

If I want to verify a new release,:
- Manually: take advantage of gpgv
- Unattended: use a wrapper around gpgme


Your input is much appriciated.

1)  https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/

--
John Doe


From spam.trap.mailing.lists at gmail.com  Sat Nov 28 08:59:40 2020
From: spam.trap.mailing.lists at gmail.com (Stefan Claas)
Date: Sat, 28 Nov 2020 07:59:40 +0000
Subject: Mobile mini computers for GnuPG/OpenPGP usage instead of smartphone
 usage
Message-ID: <CAC6FiZ7AgOuX-24fPtni=7U=cwfUXirpP3d6oZ=KoWwHqVtgLQ@mail.gmail.com>

Hi all,

some of you may remember the recent thread from me about OpenPGP usage
with smartphones. Since I sold my Android smartphone a while ago I thought
why not look for other mobile devices, which are smaller than regular notebooks
and which are maybe better suited (for me) than pure Linux smartphones.

This would also have the advantage that one can use his preferred MUA
instead of the once available for Android/iOS.

After googling a bit I found these IMHO super mini PCs, which looked very
attractive to me and I purchased one (should be delivered in a couple of days).

https://www.gpd.hk/gpdmicropc

and for fans of MacBook designs:

https://www.gpd.hk/gpdpocket2

Hope you find this info useful!

P.S. I purchased the GPD MicroPC with Ubuntu Mate instead of Microsoft Windows.

P.P.S. These little computers are mostly sold out when looking around, but I had
luck to find a German reseller who still has some in stock.

Regards
Stefan


From guru at unixarea.de  Sat Nov 28 09:44:32 2020
From: guru at unixarea.de (Matthias Apitz)
Date: Sat, 28 Nov 2020 09:44:32 +0100
Subject: Mobile mini computers for GnuPG/OpenPGP usage instead of
 smartphone usage
In-Reply-To: <CAC6FiZ7AgOuX-24fPtni=7U=cwfUXirpP3d6oZ=KoWwHqVtgLQ@mail.gmail.com>
References: <CAC6FiZ7AgOuX-24fPtni=7U=cwfUXirpP3d6oZ=KoWwHqVtgLQ@mail.gmail.com>
Message-ID: <20201128084432.GA2638@c720-r342378>

El d?a s?bado, noviembre 28, 2020 a las 07:59:40a. m. +0000, Stefan Claas via Gnupg-users escribi?:

> ...
> 
> After googling a bit I found these IMHO super mini PCs, which looked very
> attractive to me and I purchased one (should be delivered in a couple of days).
> 
> https://www.gpd.hk/gpdmicropc
> 
> and for fans of MacBook designs:
> 
> https://www.gpd.hk/gpdpocket2
> 
> Hope you find this info useful!
> 
> P.S. I purchased the GPD MicroPC with Ubuntu Mate instead of Microsoft Windows.
> 
> P.P.S. These little computers are mostly sold out when looking around, but I had
> luck to find a German reseller who still has some in stock.

Hi Stefan,

Could you please share with me the contact to the German reseller?
Thanks in advance.

Have you seen this alternative: https://puri.sm/posts/librem-5-visual-walkthrough/
I funded the campaign in October 2017 (USD 599) and now, after three years
they start delivery to the backers.

	matthias

-- 
Matthias Apitz, ? guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
??? ????? ??? ??????, ??? ?????? ??? ?????????? (??a????? ????? ?????)
Without books no knowledge - without knowledge no communism (Vladimir Ilyich Lenin) 
Sin libros no hay saber - sin saber no hay comunismo. (Vladimir Ilich Lenin)


From spam.trap.mailing.lists at gmail.com  Sat Nov 28 11:05:06 2020
From: spam.trap.mailing.lists at gmail.com (Stefan Claas)
Date: Sat, 28 Nov 2020 11:05:06 +0100
Subject: Mobile mini computers for GnuPG/OpenPGP usage instead of
 smartphone usage
In-Reply-To: <20201128084432.GA2638@c720-r342378>
References: <CAC6FiZ7AgOuX-24fPtni=7U=cwfUXirpP3d6oZ=KoWwHqVtgLQ@mail.gmail.com>
 <20201128084432.GA2638@c720-r342378>
Message-ID: <CAC6FiZ5nC5rBzE4AEeHsR+-9_J-O25ae+Q8XJxcmV_nB3Z3SKQ@mail.gmail.com>

On Sat, Nov 28, 2020 at 9:48 AM Matthias Apitz <guru at unixarea.de> wrote:

> Hi Stefan,
>
> Could you please share with me the contact to the German reseller?
> Thanks in advance.

Hi Matthias,

sure, I just send you an email via my ctemplar account.

Best regards
Stefan


From juergen at bruckner.email  Sat Nov 28 15:35:09 2020
From: juergen at bruckner.email (Juergen Bruckner)
Date: Sat, 28 Nov 2020 15:35:09 +0100
Subject: Mobile mini computers for GnuPG/OpenPGP usage instead of
 smartphone usage
In-Reply-To: <CAC6FiZ7AgOuX-24fPtni=7U=cwfUXirpP3d6oZ=KoWwHqVtgLQ@mail.gmail.com>
References: <CAC6FiZ7AgOuX-24fPtni=7U=cwfUXirpP3d6oZ=KoWwHqVtgLQ@mail.gmail.com>
Message-ID: <970cb566-619d-02fb-b70f-5a83381f2968@bruckner.email>

Hello Stefan,


Am 28.11.20 um 08:59 schrieb Stefan Claas via Gnupg-users:
> Hi all,
> 
> some of you may remember the recent thread from me about OpenPGP usage
> with smartphones. Since I sold my Android smartphone a while ago I thought
> why not look for other mobile devices, which are smaller than regular notebooks
> and which are maybe better suited (for me) than pure Linux smartphones.
> 
> This would also have the advantage that one can use his preferred MUA
> instead of the once available for Android/iOS.
> 
> After googling a bit I found these IMHO super mini PCs, which looked very
> attractive to me and I purchased one (should be delivered in a couple of days).
> 
> https://www.gpd.hk/gpdmicropc
> 
> and for fans of MacBook designs:
> 
> https://www.gpd.hk/gpdpocket2
> 
> Hope you find this info useful!
> 
> P.S. I purchased the GPD MicroPC with Ubuntu Mate instead of Microsoft Windows.
> 
> P.P.S. These little computers are mostly sold out when looking around, but I had
> luck to find a German reseller who still has some in stock.
> 
> Regards
> Stefan

Could you please tell me more when you get this device?

best regards
Juergen

-- 
/?\   No  |
\ /  HTML |    Juergen Bruckner
  X    in  |    juergen at bruckner.email
/ \  Mail |

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3894 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20201128/125e3d00/attachment-0001.bin>

From kloecker at kde.org  Sat Nov 28 16:38:27 2020
From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=)
Date: Sat, 28 Nov 2020 16:38:27 +0100
Subject: [cross post] Why does verification of a detached signature result
 in a =?UTF-8?B?4oCcTWVzc2FnZSBkaWdlc3QgZGlkIG5vdCBtYXRjaOKAnQ==?= error for
 OpenPGP.js?
In-Reply-To: <XRV4C156jQ_OfN2VIjrIf6i3eC6mkP8wJkN7_aHG_IGhJyG-v26avwcxoXemxX--Mng5wKEHhBZPQYDDfTApKlwTx3IBQWaVQa1XOHyadgs=@brainvitamins.net>
References: <XRV4C156jQ_OfN2VIjrIf6i3eC6mkP8wJkN7_aHG_IGhJyG-v26avwcxoXemxX--Mng5wKEHhBZPQYDDfTApKlwTx3IBQWaVQa1XOHyadgs=@brainvitamins.net>
Message-ID: <1667962.ExSmAaXVfq@breq>

On Freitag, 27. November 2020 23:52:27 CET cqcallaw via Gnupg-users wrote:
> I can sign and verify a test file through `gpg` without issue, but verifying
> the signature through OpenGPG.js fails with the error, "Message digest did
> not match." Why is this?

Could be a problem with text mode vs. non-text mode. By default, gpg uses non-
text mode when signing something. Try adding --textmode to gpg's command line.

> let msg = await openpgp.cleartext.fromText(msg_data);

This is just a wild guess, but fromText() could imply text mode in OpenPGP.js.

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/20201128/070028d7/attachment.sig>

From spam.trap.mailing.lists at gmail.com  Sat Nov 28 16:49:39 2020
From: spam.trap.mailing.lists at gmail.com (Stefan Claas)
Date: Sat, 28 Nov 2020 16:49:39 +0100
Subject: Mobile mini computers for GnuPG/OpenPGP usage instead of
 smartphone usage
In-Reply-To: <970cb566-619d-02fb-b70f-5a83381f2968@bruckner.email>
References: <CAC6FiZ7AgOuX-24fPtni=7U=cwfUXirpP3d6oZ=KoWwHqVtgLQ@mail.gmail.com>
 <970cb566-619d-02fb-b70f-5a83381f2968@bruckner.email>
Message-ID: <CAC6FiZ4FpGndHhPbnHKuOVEUhts9Mx2viB9oyULfEHy0nymwjQ@mail.gmail.com>

On Sat, Nov 28, 2020 at 3:38 PM Juergen Bruckner via Gnupg-users
<gnupg-users at gnupg.org> wrote:
>
> Hello Stefan,

[...]

> Could you please tell me more when you get this device?

Hi Juergen,

sure, I will tell you more once I have the device. It may take
a couple of days due to delivery schedules at DHL, because
of COVID-19.

Best regards
Stefan


From guru at unixarea.de  Sat Nov 28 19:08:53 2020
From: guru at unixarea.de (Matthias Apitz)
Date: Sat, 28 Nov 2020 18:08:53 +0000
Subject: Mobile mini computers for GnuPG/OpenPGP usage instead of
 smartphone usage
In-Reply-To: <970cb566-619d-02fb-b70f-5a83381f2968@bruckner.email>
References: <CAC6FiZ7AgOuX-24fPtni=7U=cwfUXirpP3d6oZ=KoWwHqVtgLQ@mail.gmail.com>
 <970cb566-619d-02fb-b70f-5a83381f2968@bruckner.email>
Message-ID: <9kqfyr.qkiqeu.2wbngi-qmf@ms-10.1blu.de>


>
> Could you please tell me more when you get this device?
>
> best regards
> Juergen

I will do too :-)

matthias


-- 
Matthias Apitz, ? guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
??? ????? ??? ??????, ??? ?????? ??? ?????????? (??a????? ????? ?????)
Without books no knowledge - without knowledge no communism (Vladimir Ilyich Lenin) 
Sin libros no hay saber - sin saber no hay comunismo. (Vladimir Ilich Lenin)


From cqcallaw at brainvitamins.net  Sat Nov 28 21:54:10 2020
From: cqcallaw at brainvitamins.net (cqcallaw)
Date: Sat, 28 Nov 2020 20:54:10 +0000
Subject: =?utf-8?Q?Re:_[cross_post]_Why_does_verification_of_a_detached_signature_result_in_a_=E2=80=9CMessage_digest_did_not_match=E2=80=9D_error_for_OpenPGP.js=3F?=
In-Reply-To: <1667962.ExSmAaXVfq@breq>
References: <XRV4C156jQ_OfN2VIjrIf6i3eC6mkP8wJkN7_aHG_IGhJyG-v26avwcxoXemxX--Mng5wKEHhBZPQYDDfTApKlwTx3IBQWaVQa1XOHyadgs=@brainvitamins.net>
 <1667962.ExSmAaXVfq@breq>
Message-ID: <WT26gmZu537Xzi-Nn6Ti_hSys9g34Tc2U44fXOrUK8s5aJ7OCNLXiwfXC34jJHUe0eF6-6vA0GE19hjurNnS4q2TkF7BRJ6XX6oXhg1MkI0=@brainvitamins.net>

??????? Original Message ???????
On Saturday, November 28, 2020 7:38 AM, Ingo Kl?cker <kloecker at kde.org> wrote:

> On Freitag, 27. November 2020 23:52:27 CET cqcallaw via Gnupg-users wrote:
> Could be a problem with text mode vs. non-text mode. By default, gpg uses non-
> text mode when signing something. Try adding --textmode to gpg's command line.
>
> > let msg = await openpgp.cleartext.fromText(msg_data);
>
> This is just a wild guess, but fromText() could imply text mode in OpenPGP.js.

Excellent, adding --textmode to gpg's command line resolved the issue.

Thanks!
-Caleb


From thomas at glanzmann.de  Sun Nov 29 08:24:11 2020
From: thomas at glanzmann.de (Thomas Glanzmann)
Date: Sun, 29 Nov 2020 08:24:11 +0100
Subject: graphical pinentry no longer working after upgrading to debian
 bullseye and pinentry and how to resolve it
Message-ID: <20201129072411.GE30751@glanzmann.de>

Hello,
I just upgraded to Debian bullseye and the graphical pinentry did not work
anymore. I got the following error message:

2020-11-28 21:37:41 gpg-agent[3535] DBG: connection to PIN entry established
2020-11-28 21:37:41 gpg-agent[3535] DBG: chan_10 -> INQUIRE PINENTRY_LAUNCHED 3633 gtk2:curses 1.1.0 - - -
2020-11-28 21:37:41 gpg-agent[3535] DBG: chan_10 <- END
2020-11-28 21:37:41 gpg-agent[3535] DBG: error calling pinentry: Inappropriate ioctl for device <Pinentry>
2020-11-28 21:37:41 gpg-agent[3535] failed to unprotect the secret key: Inappropriate ioctl for device
2020-11-28 21:37:41 gpg-agent[3535] failed to read the secret key
2020-11-28 21:37:41 gpg-agent[3535] command 'PKDECRYPT' failed: Inappropriate ioctl for device <Pinentry>
2020-11-28 21:37:41 gpg-agent[3535] DBG: chan_10 -> ERR 83918950 Inappropriate ioctl for device <Pinentry>
2020-11-28 21:37:41 gpg-agent[3535] DBG: chan_10 <- [eof]

I did the following to resolve the issue:

        - Installed pinentry-gnome3 because that for one of two systems
          dis resolve the issue for me without anything else below. I
          also installed pinentry-gnome3 because it grabs the keyboard,
          deinstalled any other pinentry (like gtk2 which does not grab
          the keyboard, if you have focus follows mouse on fvwm2)

apt install -y pinentry-gnome3 dbus-x11

	- Added the following to my .xsession. This is necessary because in
	  bullseye gpg-agent seems to be started by systemd sometimes without
	  the correct display set
gpg-connect-agent UPDATESTARTUPTTY /bye

	- gpg.conf (just to have a fully working example):
keyserver hkp://pool.sks-keyservers.net
keyserver-options no-honor-keyserver-url
cert-digest-algo SHA512
no-greeting
lock-once
default-key <key>
encrypt-to <key>
keyid-format 0xlong
use-agent
with-fingerprint
quiet
default-recipient-self
no-secmem-warning
keyserver-options auto-key-retrieve
no-auto-check-trustdb
trust-model direct
no-autostart
default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed

	- gpg-agent.conf (I tried here a lot in the old days I had keep-display
         and keep-tty and restarted gpg-agent in my .xsession. that does not work
         anylonger becuase systemd seems to start gpg-agent. What also
         worked was calling pinentry using a wrapper script which
         sets the DISPLAY variable explicitly, but this gives me more
         flexibility, not that I need it. Because I always enter my
         passphrase using X11 on system I'm sitting in front of)
enable-ssh-support
default-cache-ttl 34560000
max-cache-ttl 34560000
default-cache-ttl-ssh 34560000
max-cache-ttl-ssh 34560000
allow-mark-trusted

With the above setup the following works:

	- gpg locally
gpg -d test.gpg
	- gpg as ssh-agent
ssh remotesystem
	- gpg remotely
ssh -A -R /home/sithglan/.gnupg/S.gpg-agent:/run/user/1000/gnupg/S.gpg-agent.extra remotesystem gpg -d test.gpg
        - sshfs using gpg as ssh-agent:
# automounter sshfs
apt-get install sshfs autofs
echo '/ssh    /etc/auto.sshfs --timeout=60' >> /etc/auto.master

cat > /etc/auto.sshfs <<'EOF'
#!/bin/bash
echo -e "-fstype=fuse,rw,nodev,noatime,allow_other,ssh_command=/usr/local/sbin/ssh_sshfs / sshfs\#${1}:/"
EOF

cat > /usr/local/sbin/ssh_sshfs <<'EOF'
#!/bin/bash

if [ "${UID}" == 0 ]; then
        exec /usr/bin/sudo -H -u sithglan $0 "$@"
fi

export LOCALDOMAIN="glanzmann.de gmvl.de cs.fau.de"

source ~sithglan/.ssh/env

exec /usr/bin/ssh "$@"
EOF

chmod +x /etc/auto.sshfs /usr/local/sbin/ssh_sshfs
/etc/init.d/autofs restart

Tripwires:
        - nsswitch.conf: automount: files

        - 'echo export SSH_AUTH_SOCK=${SSH_AUTH_SOCK} > ~/.ssh/env'

Feedback, improvement and explanations welcome.

Cheers,
        Thomas


From thomas at glanzmann.de  Sun Nov 29 08:32:30 2020
From: thomas at glanzmann.de (Thomas Glanzmann)
Date: Sun, 29 Nov 2020 08:32:30 +0100
Subject: gpg prompts me thrice for my passphrase - how to resolve it
Message-ID: <20201129073230.GA9809@glanzmann.de>

Hello,
I sometimes use a yubikey, there gpg-agent only asks me once for my pin,
however if I have my key on the disk, gpg-agent asks me three times:

        - once for local gpg -d test.gpg
        - once for gpg-agent functioning as ssh-agent
        - once for remote gpg -d test.gpg

Now I wonder, if I can tell gpg-agent to prompt me only once or
prepopulate all three secrets at once during startup?

Cheers,
        Thomas


From wk at gnupg.org  Sun Nov 29 12:49:06 2020
From: wk at gnupg.org (Werner Koch)
Date: Sun, 29 Nov 2020 12:49:06 +0100
Subject: Changing compression configuration
In-Reply-To: <d8d65ed2-fc8c-db52-84ba-ed430d9e6dc0@gmail.com> (Karmanyaah
 Malhotra via Gnupg-users's message of "Sat, 28 Nov 2020 01:00:01
 -0500")
References: <d8d65ed2-fc8c-db52-84ba-ed430d9e6dc0@gmail.com>
Message-ID: <87pn3wfknh.fsf@wheatstone.g10code.de>

On Sat, 28 Nov 2020 01:00, Karmanyaah Malhotra said:

> instead of just regular bzip2 when compressing files. I'm not sure if

bzip2 is part of the OpenPGP specs and it is very unlikely that we will
ever add another compression algo.  In fact adding bzip2 was already a
bad idea.

> compression could be multi-threaded since using one thread is the

Adding this to GnuPG would be too hard.  You better use an external
program for compressing the data

  cat foo | bzip2 | gpg -z0 -e >foo.bz2.gpg

  gpg -d <foo.bz2.gpg | bunzip2 >foo

this has more flexibility and the OS (and bzip2 er al) take care of
multi-threading.


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/20201129/6b99b5a8/attachment.sig>

From wk at gnupg.org  Sun Nov 29 12:53:53 2020
From: wk at gnupg.org (Werner Koch)
Date: Sun, 29 Nov 2020 12:53:53 +0100
Subject: Verifying and checksumming new release is somewhat cumbersom
In-Reply-To: <469842e0-86fa-cd41-f80f-be7efec7d754@mail.com> (john doe via
 Gnupg-users's message of "Sat, 28 Nov 2020 07:57:05 +0100")
References: <5fe4d4c3-8ab2-6555-792d-00b59997b9b8@mail.com>
 <87ft4vhoad.fsf@wheatstone.g10code.de>
 <469842e0-86fa-cd41-f80f-be7efec7d754@mail.com>
Message-ID: <87lfekfkfi.fsf@wheatstone.g10code.de>

On Sat, 28 Nov 2020 07:57, john doe said:

> If I look at Debian (1) for example, the checksum file is gpg signed.
> Assuming that I understand correctly, the Debian approach is not a safe
> way to make the checksums available?propagate?

No, that is a safe way.

Having a separate file with checksums is sometimes better for the
signing workflow.  It also allows to sign/verify a bunch of files with
just one operation.  It also avoids the need to download and upload all
files to a dedicated signing box.  Only since GnuPG 2.2 the latter could
be handled using gpg-agent's remote feature.


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/20201129/624cdc55/attachment-0001.sig>

From rjh at sixdemonbag.org  Mon Nov 30 10:16:56 2020
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Mon, 30 Nov 2020 04:16:56 -0500
Subject: Odd error
Message-ID: <31679534-a4ff-5222-f02c-b5de32e53de1@sixdemonbag.org>

This should not be happening, but is.  From a completely clean 
installation, importation of legitimate OpenPGP keys results in strange 
general failures.  The system is an x64 Fedora 33 box running GnuPG 
2.2.24 on libgcrypt 1.8.6.

I'm happy to provide the keys.asc file to any GnuPG dev who needs it to 
look into this problem.

=====

[rjh at localhost ~]$ gpgconf --kill gpg-agent
[rjh at localhost ~]$ rm -rf .gnupg
[rjh at localhost ~]$ gpg --import Downloads/keys.asc
gpg: directory '/home/rjh/.gnupg' created
gpg: keybox '/home/rjh/.gnupg/pubring.kbx' created
gpg: /home/rjh/.gnupg/trustdb.gpg: trustdb created

[snip]

gpg: key 1DCBDC01B44427C7: public key "Robert J. Hansen 
<rjh at sixdemonbag.org>" imported
gpg: kbx: error computing keygrip
gpg: error writing keyring '/home/rjh/.gnupg/pubring.kbx': General error
gpg: error reading 'Downloads/keys.asc': General error
gpg: no valid OpenPGP data found.
gpg: import from 'Downloads/keys.asc' failed: General error
gpg: Total number processed: 5
gpg:               imported: 5
gpg: no ultimately trusted keys found

=====

Let's try again on a higher verbosity level.  (I have to say I saw 
nothing of use here.)

=====

[rjh at localhost ~]$ gpgconf --kill gpg-agent
[rjh at localhost ~]$ rm -rf .gnupg
[rjh at localhost ~]$ gpg -vvv --import Downloads/keys.asc
gpg: using character set 'utf-8'
gpg: directory '/home/rjh/.gnupg' created
gpg: keybox '/home/rjh/.gnupg/pubring.kbx' created
gpg: armor: BEGIN PGP PUBLIC KEY BLOCK
# off=0 ctb=99 tag=6 hlen=3 plen=269

[snipping successfully imported public keys]
[leaving in debugging lines from other GnuPG components]
[some data anonymized, because it's not mine]

gpg: pub  rsa2048/XXXXXXXXXXXXXXXX 2010-10-18  XXXXXXXX
gpg: writing to '/home/rjh/.gnupg/pubring.kbx'
gpg: /home/rjh/.gnupg/trustdb.gpg: trustdb created
gpg: using pgp trust model
gpg: key XXXXXXXXXXXXXXXX: public key "XXXXXXXX" imported
gpg: no running gpg-agent - starting '/usr/bin/gpg-agent'
gpg: waiting for the agent to come up ... (5s)
gpg: connection to agent established
gpg: pub  rsa2048/XXXXXXXXXXXXXXXX 2012-05-24  XXXXXXXX
gpg: writing to '/home/rjh/.gnupg/pubring.kbx'
gpg: key XXXXXXXXXXXXXXXX: public key "XXXXXXXX" imported
gpg: pub  rsa4096/XXXXXXXXXXXXXXXX 2013-09-13  XXXXXXXX
gpg: writing to '/home/rjh/.gnupg/pubring.kbx'
gpg: key XXXXXXXXXXXXXXXX: public key "XXXXXXXX" imported
gpg: pub  rsa4096/XXXXXXXXXXXXXXXX 2016-10-04  XXXXXXXX
gpg: writing to '/home/rjh/.gnupg/pubring.kbx'
# off=10553 ctb=99 tag=6 hlen=3 plen=397
:public key packet:
	version 4, algo 1, created 1437075659, expires 0
	pkey[0]: [3072 bits]
	pkey[1]: [17 bits]
	keyid: 1DCBDC01B44427C7
gpg: key XXXXXXXXXXXXXXXX: public key "XXXXXXXX" imported
# off=10953 ctb=b4 tag=13 hlen=2 plen=35
:user ID packet: "Robert J. Hansen <rob at enigmail.net>"
# off=10990 ctb=89 tag=2 hlen=3 plen=446
:signature packet: algo 1, keyid 1DCBDC01B44427C7
	version 4, created 1437078058, md5len 0, sigclass 0x13
	digest algo 8, begin of digest cf aa
	hashed subpkt 2 len 4 (sig created 2015-07-16)
	hashed subpkt 27 len 1 (key flags: 03)
	hashed subpkt 11 len 11 (pref-sym-algos: 10 13 9 12 8 11 7 4 3 1 2)
	hashed subpkt 21 len 5 (pref-hash-algos: 10 9 8 11 3)
	hashed subpkt 22 len 3 (pref-zip-algos: 3 1 2)
	hashed subpkt 30 len 1 (features: 01)
	hashed subpkt 23 len 1 (keyserver preferences: 80)
	subpkt 16 len 8 (issuer key ID 1DCBDC01B44427C7)
	data: [3070 bits]
# off=11439 ctb=89 tag=2 hlen=3 plen=540
:signature packet: algo 1, keyid DB1187B9DD5F693B
	version 4, created 1437210170, md5len 0, sigclass 0x13
	digest algo 10, begin of digest 8b 3c
	hashed subpkt 2 len 4 (sig created 2015-07-18)
	subpkt 16 len 8 (issuer key ID DB1187B9DD5F693B)
	data: [4095 bits]
# off=11982 ctb=b4 tag=13 hlen=2 plen=38
:user ID packet: "Robert J. Hansen <rjh at sixdemonbag.org>"
# off=12022 ctb=89 tag=2 hlen=3 plen=449
:signature packet: algo 1, keyid 1DCBDC01B44427C7
	version 4, created 1467479780, md5len 0, sigclass 0x13
	digest algo 8, begin of digest 34 63
	hashed subpkt 27 len 1 (key flags: 03)
	hashed subpkt 11 len 11 (pref-sym-algos: 10 13 9 12 8 11 7 4 3 1 2)
	hashed subpkt 21 len 5 (pref-hash-algos: 10 9 8 11 3)
	hashed subpkt 22 len 3 (pref-zip-algos: 3 1 2)
	hashed subpkt 30 len 1 (features: 01)
	hashed subpkt 23 len 1 (keyserver preferences: 80)
	hashed subpkt 2 len 4 (sig created 2016-07-02)
	hashed subpkt 25 len 1 (primary user ID)
	subpkt 16 len 8 (issuer key ID 1DCBDC01B44427C7)
	data: [3072 bits]
# off=12474 ctb=89 tag=2 hlen=3 plen=540
:signature packet: algo 1, keyid DB1187B9DD5F693B
	version 4, created 1437210170, md5len 0, sigclass 0x13
	digest algo 10, begin of digest a8 e5
	hashed subpkt 2 len 4 (sig created 2015-07-18)
	subpkt 16 len 8 (issuer key ID DB1187B9DD5F693B)
	data: [4096 bits]
# off=13017 ctb=b4 tag=13 hlen=2 plen=41
:user ID packet: "Robert J. Hansen <rob at hansen.engineering>"
# off=13060 ctb=89 tag=2 hlen=3 plen=446
:signature packet: algo 1, keyid 1DCBDC01B44427C7
	version 4, created 1467479729, md5len 0, sigclass 0x13
	digest algo 8, begin of digest 81 4e
	hashed subpkt 2 len 4 (sig created 2016-07-02)
	hashed subpkt 27 len 1 (key flags: 03)
	hashed subpkt 11 len 11 (pref-sym-algos: 10 13 9 12 8 11 7 4 3 1 2)
	hashed subpkt 21 len 5 (pref-hash-algos: 10 9 8 11 3)
	hashed subpkt 22 len 3 (pref-zip-algos: 3 1 2)
	hashed subpkt 30 len 1 (features: 01)
	hashed subpkt 23 len 1 (keyserver preferences: 80)
	subpkt 16 len 8 (issuer key ID 1DCBDC01B44427C7)
	data: [3071 bits]
# off=13509 ctb=b9 tag=14 hlen=3 plen=397
:public sub key packet:
	version 4, algo 1, created 1437075659, expires 0
	pkey[0]: [3072 bits]
	pkey[1]: [17 bits]
	keyid: DC0F82625FA6AADE
# off=13909 ctb=89 tag=2 hlen=3 plen=415
:signature packet: algo 1, keyid 1DCBDC01B44427C7
	version 4, created 1437075659, md5len 0, sigclass 0x18
	digest algo 8, begin of digest 60 5b
	hashed subpkt 2 len 4 (sig created 2015-07-16)
	hashed subpkt 27 len 1 (key flags: 0C)
	subpkt 16 len 8 (issuer key ID 1DCBDC01B44427C7)
	data: [3067 bits]
# off=14327 ctb=b8 tag=14 hlen=2 plen=51
:public sub key packet:
	version 4, algo 22, created 1491360583, expires 0
	pkey[0]: [80 bits] ed25519 (1.3.6.1.4.1.11591.15.1)
	pkey[1]: [263 bits]
	keyid: A83CAE94D3DC3873
# off=14380 ctb=89 tag=2 hlen=3 plen=511
:signature packet: algo 1, keyid 1DCBDC01B44427C7
	version 4, created 1491360583, md5len 0, sigclass 0x18
	digest algo 2, begin of digest 69 5a
	hashed subpkt 2 len 4 (sig created 2017-04-05)
	hashed subpkt 27 len 1 (key flags: 02)
	subpkt 16 len 8 (issuer key ID 1DCBDC01B44427C7)
	subpkt 32 len 94 (signature: v4, class 0x19, algo 22, digest algo 8)
	data: [3072 bits]
# off=14894 ctb=b8 tag=14 hlen=2 plen=56
:public sub key packet:
	version 4, algo 18, created 1491360897, expires 0
	pkey[0]: [88 bits] cv25519 (1.3.6.1.4.1.3029.1.5.1)
	pkey[1]: [263 bits]
	pkey[2]: [32 bits]
	keyid: AA24CC81B8AED08B
# off=14952 ctb=89 tag=2 hlen=3 plen=415
:signature packet: algo 1, keyid 1DCBDC01B44427C7
	version 4, created 1491360897, md5len 0, sigclass 0x18
	digest algo 2, begin of digest a1 8d
	hashed subpkt 2 len 4 (sig created 2017-04-05)
	hashed subpkt 27 len 1 (key flags: 0C)
	subpkt 16 len 8 (issuer key ID 1DCBDC01B44427C7)
	data: [3071 bits]
# off=15370 ctb=99 tag=6 hlen=3 plen=525

[resuming omission of other people's keys]

gpg: pub  rsa3072/1DCBDC01B44427C7 2015-07-16  Robert J. Hansen 
<rob at enigmail.net>
gpg: key 1DCBDC01B44427C7: 2 signatures not checked due to missing keys
gpg: writing to '/home/rjh/.gnupg/pubring.kbx'
gpg: key 1DCBDC01B44427C7: public key "Robert J. Hansen 
<rjh at sixdemonbag.org>" imported
gpg: pub  rsa4096/XXXXXXXXXXXXXXXX 2017-03-18  XXXXXXXX
gpg: writing to '/home/rjh/.gnupg/pubring.kbx'
gpg: kbx: error computing keygrip
gpg: error writing keyring '/home/rjh/.gnupg/pubring.kbx': General error
gpg: error reading 'Downloads/keys.asc': General error
gpg: no valid OpenPGP data found.
gpg: import from 'Downloads/keys.asc' failed: General error
gpg: Total number processed: 5
gpg:               imported: 5
gpg: 0 keys processed (0 validity counts cleared)
gpg: no ultimately trusted keys found


From wk at gnupg.org  Mon Nov 30 15:16:20 2020
From: wk at gnupg.org (Werner Koch)
Date: Mon, 30 Nov 2020 15:16:20 +0100
Subject: Odd error
In-Reply-To: <31679534-a4ff-5222-f02c-b5de32e53de1@sixdemonbag.org> (Robert
 J. Hansen via Gnupg-users's message of "Mon, 30 Nov 2020 04:16:56
 -0500")
References: <31679534-a4ff-5222-f02c-b5de32e53de1@sixdemonbag.org>
Message-ID: <87pn3vdj63.fsf@wheatstone.g10code.de>

Hi!

On Mon, 30 Nov 2020 04:16, Robert J. Hansen said:

> gpg: kbx: error computing keygrip
> gpg: error writing keyring '/home/rjh/.gnupg/pubring.kbx': General error

The first one is the real error.  We can't compute the keygrip for the
public key.  If you can build gpg yourself please apply this patch:

--8<---------------cut here---------------start------------->8---
diff --git a/kbx/keybox-openpgp.c b/kbx/keybox-openpgp.c
index 6d6ed77dc..345af0164 100644
--- a/kbx/keybox-openpgp.c
+++ b/kbx/keybox-openpgp.c
@@ -240,6 +240,7 @@ keygrip_from_keyparm (int algo, struct keyparm_s *kp, unsigned char *grip)
 
   if (!err && !gcry_pk_get_keygrip (s_pkey, grip))
     {
+      gcry_log_debugsxp ("pubkey:", s_pkey);
       log_info ("kbx: error computing keygrip\n");
       err = gpg_error (GPG_ERR_GENERAL);
     }
--8<---------------cut here---------------end--------------->8---

or send me your sample key.  In any case please also run our new 2.2.24
command to see how libgcrypt has been built:

  gpgconf --show-versions
  


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/20201130/21b59ba9/attachment.sig>

From rjh at sixdemonbag.org  Mon Nov 30 15:25:26 2020
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Mon, 30 Nov 2020 09:25:26 -0500
Subject: Odd error
In-Reply-To: <87pn3vdj63.fsf@wheatstone.g10code.de>
References: <31679534-a4ff-5222-f02c-b5de32e53de1@sixdemonbag.org>
 <87pn3vdj63.fsf@wheatstone.g10code.de>
Message-ID: <bfabfd65-e04b-5a09-c89c-6668009db17a@sixdemonbag.org>

> The first one is the real error.  We can't compute the keygrip for the
> public key.  If you can build gpg yourself please apply this patch:

It's a standard Fedora GnuPG, so although I'm sure a source RPM is 
available I'm not enough of an RPM surgeon to know how to modify the 
.rpmspec to apply the patch.

I'll send the keyring onto you privately.

> or send me your sample key.  In any case please also run our new 2.2.24
> command to see how libgcrypt has been built:
> 
>    gpgconf --show-versions


* GnuPG 2.2.25 (40f75823d)
GNU/Linux

* Libgcrypt 1.8.7 ()
version:1.8.7:10807:1.37-unknown:12500:
cc:100201:gcc:10.2.1 20201016 (Red Hat 10.2.1-6):
ciphers:arcfour:blowfish:cast5:des:aes:twofish:serpent:rfc2268:seed:camellia:idea:salsa20:gost28147:chacha20:
pubkeys:dsa:elgamal:rsa:ecc:
digests:crc:gostr3411-94::md4:md5:rmd160:sha1:sha256:sha512:sha3:tiger:whirlpool:stribog:blake2:
rnd-mod:linux:
cpu-arch:x86:
mpi-asm:amd64/mpih-add1.S:amd64/mpih-sub1.S:amd64/mpih-mul1.S:amd64/mpih-mul2.S:amd64/mpih-mul3.S:amd64/mpih-lshift.S:amd64/mpih-rshift.S:
hwflist:intel-cpu:intel-bmi2:intel-ssse3:intel-sse4.1:intel-pclmul:intel-aesni:intel-rdrand:intel-avx:intel-avx2:intel-fast-vpgather:intel-rdtsc:
fips-mode:n:n:
rng-type:standard:1:2010000:1:

* GpgRT 1.37-unknown (0000000)

* Libassuan 2.5.3 (4de3154)

* KSBA 1.3.5 (?)

* GNUTLS 3.6.15


From ryan at digicana.com  Mon Nov 30 15:36:16 2020
From: ryan at digicana.com (Ryan McGinnis)
Date: Mon, 30 Nov 2020 14:36:16 +0000
Subject: Mobile mini computers for GnuPG/OpenPGP usage instead of
 smartphone usage
In-Reply-To: <CAC6FiZ7AgOuX-24fPtni=7U=cwfUXirpP3d6oZ=KoWwHqVtgLQ@mail.gmail.com>
References: <CAC6FiZ7AgOuX-24fPtni=7U=cwfUXirpP3d6oZ=KoWwHqVtgLQ@mail.gmail.com>
Message-ID: <C9CtvlKv1QybxQnNtRBsa0XAcHhvd6ZlTQKnibb9aMXMUCa1ia-Co-5F3QjRsRol-XYlmmB86kvcmwumQMxIYz3zlPPWET1Rt-N3p7A4jc8=@digicana.com>

An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20201130/adb52c75/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 839 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20201130/adb52c75/attachment.sig>

From m.fernandes.business at gmail.com  Mon Nov 30 19:00:00 2020
From: m.fernandes.business at gmail.com (Mark Fernandes)
Date: Mon, 30 Nov 2020 18:00:00 +0000
Subject: Five volunteers needed (EU only please)
In-Reply-To: <mailman.3992.1606517570.9913.gnupg-users@gnupg.org>
References: <mailman.3992.1606517570.9913.gnupg-users@gnupg.org>
Message-ID: <CANJMFk9MXn8b5DPLeP4B5ok3eMfsWS1-t0Sav6SX2ye5qkiCJQ@mail.gmail.com>

> ------------------------------
>
> Message: 2
> Date: Thu, 26 Nov 2020 12:10:59 +0100
> From: Dirk Gottschalk <dirk.gottschalk1980 at googlemail.com>
> To: gnupg-users at gnupg.org
> Subject: Re: Five volunteers needed (EU only please)
> Message-ID:
>         <39d845f714609d1ce09286e991ab1056e9dfae2a.camel at googlemail.com>
> Content-Type: text/plain; charset="utf-8"
>
> ...
>
> Am Montag, den 05.10.2020, 17:37 +0200 schrieb Stefan Claas:
> > ...
> >
> > My new idea is to send encrypted postcards or letters, with an NFC
> > tag attached,
> > containing a GnuPG clearsigned test message. ...
> > [...]
>
> ...
> The Tags should have enough memory to take encrypted messages. I think
> at least 12k. The more memory, the longer can the message be.
>
> ....



It might be better only to use tags that have relatively small amounts of
memory, in order to be more secure: if your computer has been hacked, it
may try to do arbitrary code execution of data on the NFC, where someone
may have deceptively planted malware.


Kind regards,


Mark Fernandes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20201130/38fb0a44/attachment-0001.html>

From spam.trap.mailing.lists at gmail.com  Mon Nov 30 19:59:18 2020
From: spam.trap.mailing.lists at gmail.com (Stefan Claas)
Date: Mon, 30 Nov 2020 19:59:18 +0100
Subject: Mobile mini computers for GnuPG/OpenPGP usage instead of
 smartphone usage
In-Reply-To: <C9CtvlKv1QybxQnNtRBsa0XAcHhvd6ZlTQKnibb9aMXMUCa1ia-Co-5F3QjRsRol-XYlmmB86kvcmwumQMxIYz3zlPPWET1Rt-N3p7A4jc8=@digicana.com>
References: <CAC6FiZ7AgOuX-24fPtni=7U=cwfUXirpP3d6oZ=KoWwHqVtgLQ@mail.gmail.com>
 <C9CtvlKv1QybxQnNtRBsa0XAcHhvd6ZlTQKnibb9aMXMUCa1ia-Co-5F3QjRsRol-XYlmmB86kvcmwumQMxIYz3zlPPWET1Rt-N3p7A4jc8=@digicana.com>
Message-ID: <CAC6FiZ6mf-2jXxmMGAJwJpW6U1baCH_uGXFU7rQV=OYKBO1_ZA@mail.gmail.com>

On Mon, Nov 30, 2020 at 3:36 PM Ryan McGinnis <ryan at digicana.com> wrote:
>
> Hah, these look like they?re probably aimed at the pentesting market, they are indeed tiny as hell!

[...]

What I like to try out is to see how it works as offline device, i.e.
attaching the MicroPC to my dumb phone via USB (to send
GnuPG encrypted MMS) or to my PC via the serial port and then
CoolTerm usage on both.

Regards
Stefan


From wk at gnupg.org  Mon Nov 30 21:34:17 2020
From: wk at gnupg.org (Werner Koch)
Date: Mon, 30 Nov 2020 21:34:17 +0100
Subject: Odd error
In-Reply-To: <bfabfd65-e04b-5a09-c89c-6668009db17a@sixdemonbag.org> (Robert
 J. Hansen via Gnupg-users's message of "Mon, 30 Nov 2020 09:25:26
 -0500")
References: <31679534-a4ff-5222-f02c-b5de32e53de1@sixdemonbag.org>
 <87pn3vdj63.fsf@wheatstone.g10code.de>
 <bfabfd65-e04b-5a09-c89c-6668009db17a@sixdemonbag.org>
Message-ID: <87ft4qeg8m.fsf@wheatstone.g10code.de>

On Mon, 30 Nov 2020 09:25, Robert J. Hansen said:

> I'll send the keyring onto you privately.

Thanks.  Unfortunately i was not able to replicate the bug on my Devuan
box.  I tried using the same Libgcrypt version but with some libraries
different.  Should not matter, though.

> * Libgcrypt 1.8.7 ()

This is a somehow patched version, it should read

* Libgcrypt 1.8.7 (04c156a4)

which gives the commit id of the release.  As you know, patching a
version is quite common and not a problem.  However, given the error
message, this is the first place where I need to look.  I don't have any
Fedora running here but it is a good opportunity to install a VM for
testing.  But not this evening anymore.


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/20201130/642a4267/attachment.sig>

From wk at gnupg.org  Mon Nov 30 22:20:58 2020
From: wk at gnupg.org (Werner Koch)
Date: Mon, 30 Nov 2020 22:20:58 +0100
Subject: Odd error
In-Reply-To: <87ft4qeg8m.fsf@wheatstone.g10code.de> (Werner Koch via
 Gnupg-users's message of "Mon, 30 Nov 2020 21:34:17 +0100")
References: <31679534-a4ff-5222-f02c-b5de32e53de1@sixdemonbag.org>
 <87pn3vdj63.fsf@wheatstone.g10code.de>
 <bfabfd65-e04b-5a09-c89c-6668009db17a@sixdemonbag.org>
 <87ft4qeg8m.fsf@wheatstone.g10code.de>
Message-ID: <878saiee2t.fsf@wheatstone.g10code.de>

Hi!

I looked at the Fedora Libgcrypt source and noticed that they ship
libgcrypt with the nistp192 and all brainpool curves removed.  I have
not yet build this version but given that one of your keys has brainpool
curves this might be the culprit.

I can understand that they remove nistp192 for security policy reasons.
But I do not understand why the brainpool curves are removed.  The
general statement in the spec file is that curves need to be removed due
to patent rasons.  However, Brainpool curves are less prone to patent
claims for fast multiplication than the NIST curves and we actually use
the very same code for all those Weierstrass curves. 

I'll build with the Fedora patches in the next days.  If the missing
curves are really the reason, we can fix that.


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/20201130/f1566881/attachment.sig>