Re: Issue with pinentry GUI agent

[Daniel Kahn Gillmor]

On Wed 2018-09-05 09:39:31 +0200, Kristian Fiskerstrand wrote:
> On 9/4/18 6:10 PM, Daniel Kahn Gillmor wrote:
>> or do you mean something else?
>
> without DISPLAY env var, qt version automatically falls back to curses
> variant despite the argument
>
> kristianf@ares ~ $ unset DISPLAY
> kristianf@ares ~ $ /usr/bin/pinentry-qt4 --display :0
>
> (pinentry-qt4:6370): Gtk-WARNING **: 09:31:41.576: cannot open display:
> kristianf@ares ~ $ export DISPLAY=:0
> kristianf@ares ~ $ /usr/bin/pinentry-qt4 --display :0
> OK Pleased to meet you
>
> throwing in a simple wrapper around pinentry,
> #!/bin/bash
> env > /tmp/pinentry-log.txt
> echo "$@" >> /tmp/pinentry-log.txt
> exec /usr/bin/pinentry-qt "$@"
>
> and diffing the log between keep-display, shows that the difference is
> +DISPLAY=:0
>
> btw, you say started, but this should also be updated when issuing
> UPDATESTARTUPTTY shouldn't it? In any case, it solved the issue for the
> user and I replicated it also on pinentry 1.1.0 on gnupg 2.2.10

I'm unable to replicate this.  here's a transcript of my session,
testing pinentry-qt 1.1.0-1+b1 and gnupg 2.2.10-1 on debian
testing/unstable:


0 dkg@alice:~$ DISPLAY= pinentry-qt 
OK Pleased to meet you
getpin
D monkey
OK
0 dkg@alice:~$ DISPLAY= pinentry-qt --display :0
OK Pleased to meet you
getpin
D monkey
OK
0 dkg@alice:~$ unset DISPLAY
0 dkg@alice:~$ pinentry-qt --display :0
OK Pleased to meet you
getpin 
D abc123
OK
0 dkg@alice:~$ pinentry-qt 
OK Pleased to meet you
getpin
D abc123
OK
0 dkg@alice:~$ 

The two entries with --display caused a graphical display to pop up.
the other two caused the curses fallback.

if you can sort out a clearer replication, please report it on
https://dev.gnupg.org/maniphest/task/edit/form/3/ !

Regards,

--dkg


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: AW: AW: How to fix "ERROR key_generate 3355453" / "GENKEY' failed: IPC call has been cancelled"

[Peter Lebbing]

On 05/09/18 16:29, Fiedler Roman wrote:
> Apart from that, is not the
> 
> [GNUPG:] VALIDSIG 25CE8B1D52A5B231543F8D660EE7BE094144A67F 2018-09-05 
> 1536157493 0 4 0 1 8 00 25CE8B1D52A5B231543F8D660EE7BE094144A67F
> 
> more suited for checking?

Generally: no. It just indicates the signature is cryptographically
valid, it does not indicate whether the *key* is valid. With
--trust-model always and a non-revoked key; perhaps.

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

AW: AW: How to fix "ERROR key_generate 3355453" / "GENKEY' failed: IPC call has been cancelled"

[Fiedler Roman]

> Von: Peter Lebbing [mailto:pe...@digitalbrains.com]
>
> On 05/09/18 10:45, Fiedler Roman wrote:
> > * Decrypt and verify with gpg1 on receiver side:
> >
> > /usr/bin/gpg1 --no-options --homedir Receiver --no-default-keyring --
> keyring Sender/SenderKey.pub --lock-never --trust-model always --batch --
> display-charset utf-8 --status-fd 2 --decrypt --try-all-secrets <
> Sender/OutgoingMessage.gpg
>
> If you want to know which of the public keys you have signed a
> particular message, instead of restricting your "keyring" to a single,
> desired key, you can scan the status-fd for
>
> [GNUPG:] GOODSIG

That would be the preferred way if each recipient has and is allowed
to have a list of public keys. As in my usecase the keys are stored in
a database and only the relevant key is handed out by a service, used
for the operation and then thrown away again. In a perfect world it
should never touch non-volatile storage during that process.

Not relying on a local keyring to be filled should also allow central
sanitation/quality assurance of encoded public key material, thus
avoiding security issues on status-fd protocol with key fields similar
to filename related problems in gnupg (see CVE-2018-12020)

Apart from that, is not the

[GNUPG:] VALIDSIG 25CE8B1D52A5B231543F8D660EE7BE094144A67F 2018-09-05 
1536157493 0 4 0 1 8 00 25CE8B1D52A5B231543F8D660EE7BE094144A67F

more suited for checking? The 64-bit key-IDs should be close to
bruteforcing, thus not really reliable for key identification?

> In this case, just keep your keyring as it normally is, containing all
> public keys. You might then also reach a situation where you can
> meaningfully use a trust model, instead of your --trust-model always.
>
> status-fd is documented in doc/DETAILS.

The "--status-fd" is really great for that to pin keys in a classical setup,
where I have such filter lists already in operation.

Regards,
Roman
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: AW: Both correct and surprising non-interactive gen-key

[Peter Lebbing]

On 05/09/18 15:50, Fiedler Roman wrote:
> @Peter: thanks for looking at it more closely. There might be quite some 
> sleeping
> dogs in semi/fully-automated gpg2 operation.

It's just one bug, if even, depending on my understanding of the
mechanism. One swallow does not a summer make; such negativity.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: AW: Both correct and surprising non-interactive gen-key

[Peter Lebbing]

On 05/09/18 15:50, Fiedler Roman wrote:
> The "--pinentry-mode" is here only to make gpg-agent/gpg2 happy to get rid
> of tty-related errors. The batch commands do not request any passphrase
> to be set, so it should never be read

Can you point to the documentation where it says so? Because the
passphrase is correctly set to "my_passphrase", pinentry-mode should
only ever become relevant when a pinentry is about to invoked, and in
general I just don't see why this should be the case. Additionally, it
makes no sense that there is a "%no-protection" option if this is always
the case anyway. I think that GnuPG 1.4 defaulted to no passphrase if
not supplied with a "Passphrase" option, but this is not GnuPG 1.4; the
"Passphrase" option is a no-op, included only for backwards compatibility.

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

AW: Both correct and surprising non-interactive gen-key (was: How to fix "ERROR key_generate 3355453" / "GENKEY' failed: IPC call has been cancelled")

[Fiedler Roman]

> Von: Peter Lebbing [mailto:pe...@digitalbrains.com]
> Gesendet: Mittwoch, 5. September 2018 15:21
> An: Fiedler Roman ; gnupg-users@gnupg.org
> Betreff: Both correct and surprising non-interactive gen-key (was: How to fix
> "ERROR key_generate 3355453" / "GENKEY' failed: IPC call has been
> cancelled")
>
> On 31/08/18 19:11, Fiedler Roman wrote:
> > ['/usr/bin/gpg', '--homedir', '/tmp/tmp-3abk6l8', '--with-colons', 
> > '--status-fd',
> '2', '--pinentry-mode', 'loopback', '--batch', '--gen-key', '--command-fd', 
> '0']
>
> It is unclear where the passphrase is supposed to come from... so I
> think it's correct that GnuPG CANcels. Oh, by the way, commands should
> come last for robustness.

Just for clarification:

The "--pinentry-mode" is here only to make gpg-agent/gpg2 happy to get rid
of tty-related errors. The batch commands do not request any passphrase
to be set, so it should never be read - but maybe I do understand "batch-mode"
the same way (consequence: never ask anything) compared to the gpg-meaning
of batch.

@Peter: thanks for looking at it more closely. There might be quite some 
sleeping
dogs in semi/fully-automated gpg2 operation.

> ...

Regards,
Roman
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Both correct and surprising non-interactive gen-key (was: How to fix "ERROR key_generate 3355453" / "GENKEY' failed: IPC call has been cancelled")

[Peter Lebbing]

On 31/08/18 19:11, Fiedler Roman wrote:
> ['/usr/bin/gpg', '--homedir', '/tmp/tmp-3abk6l8', '--with-colons', 
> '--status-fd', '2', '--pinentry-mode', 'loopback', '--batch', '--gen-key', 
> '--command-fd', '0']

It is unclear where the passphrase is supposed to come from... so I 
think it's correct that GnuPG CANcels. Oh, by the way, commands should 
come last for robustness.

I discovered something odd though:

--8<---cut here---start->8---
$ cat passphrase 
my_passphrase
$ cat template 
%echo Generating key
Key-Type: RSA
Key-Length: 1024
Subkey-Type: ELG-E
Subkey-Length: 1024
Name-Real: AutomationKey
Expire-Date: 0
%commit
$ exec 3<&- 38---

That works, with passphrase on fd 3 and command on fd 0. I should delete 
it though, "ultimately trusted" no thanks. But:

--8<---cut here---start->8---
$ exec 3<&- 38---

Doesn't do anything.

--8<---cut here---start->8---
$ exec 3<&- 38---

g10/keygen.c appears to be trying to read commands from fd 0 even though 
I said fd 3. There's no colon in the "command" my_passphrase, so it 
errors.

For now, I'd say go with the one that works. But I don't understand why 
the others behave as they do.

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: AW: How to fix "ERROR key_generate 3355453" / "GENKEY' failed: IPC call has been cancelled"

[Peter Lebbing]

On 05/09/18 10:45, Fiedler Roman wrote:
> * Decrypt and verify with gpg1 on receiver side:
> 
> /usr/bin/gpg1 --no-options --homedir Receiver --no-default-keyring --keyring 
> Sender/SenderKey.pub --lock-never --trust-model always --batch 
> --display-charset utf-8 --status-fd 2 --decrypt --try-all-secrets < 
> Sender/OutgoingMessage.gpg

If you want to know which of the public keys you have signed a
particular message, instead of restricting your "keyring" to a single,
desired key, you can scan the status-fd for

[GNUPG:] GOODSIG

In this case, just keep your keyring as it normally is, containing all
public keys. You might then also reach a situation where you can
meaningfully use a trust model, instead of your --trust-model always.

status-fd is documented in doc/DETAILS.

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Hiding signature identification

[Peter Lebbing]

What does an unencrypted, signed message mean to you? Because when we're
talking about the benefits or operation model of a hypothetical
"throw-keyid" option for signatures, that's what we are discussing.
Anything about encrypted messages is not relevant, since the signature
is inside the encryption as you noted. So the actual content of the data
is already deemed not to be sensitive knowledge, it just needs to be
authenticated.

Your method of correlating key ID's to out-of-band data like spying on
people's movements is something I had not considered, but the key ID is
just a bit of extra data; you could also simply correlate the production
of *an* OpenPGP signed message to the person in question and attack
them. Who cares what key they used when you can determine they are the
person who's always behind their keyboard when that interesting signed
message appears.

Furthermore, note that the design of OpenPGP assumes the data it calls
"public" is indeed public. You could try to retrofit OpenPGP into some
role where a public key is not public, but it is dangerous to use a
crypto ecosystem for something else than it was designed for. It seems
to me asking for a "throw-keyid" for signatures is exactly that, and
maybe you need to look for something else than OpenPGP if public data is
no longer public.[1]

As soon as the public key is indeed public, you've just reduced the
search space to all public keys rather than all possible public keys. I
don't particularly care if there is a meaningful user ID on the key,
that's up to the creator of the key, but it is relevant that the actual
modulus is indeed public knowledge.

HTH,

Peter.

[1] I made a typo and wrote "and pubic data is no longer public". My
pubic data would be among the least public data about me, thank you very
much :-).

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

AW: Hiding signature identification (was: How to fix "ERROR key_generate 3355453" / "GENKEY' failed: IPC call has been cancelled")

[Fiedler Roman]

> Von: Peter Lebbing [mailto:pe...@digitalbrains.com]
> 
> On 05/09/18 11:27, Fiedler Roman wrote:
> > Sorry, but you are completely off here.
> 
> If there are six people I am actually interested in, and I know all
> their public keys,

How will you know them? I will not tell you the keys, nor publish
them. You will have to steal them or wait for GPG leaking information
about them. The later risk is what I want to prevent ...

> checking if one of them signed a message with a
> hypothetical "throw-keyid" takes me at most six trial verifications,
> using their public keys in turn.

Nope, because as stated by Werner: signature verification in sign
AND encrypt schemes is not possible without decrypting the message.
And each message WILL BE encrypted, the sender and receiver key
will be stored in a HSM in the end. So I could not even give you a
copy of the private key to perform the decryption/signature
verification, even if I wanted to.

And to make it harder for you to figure out, which HSM to steal if
you want to decrypt a given message, the messages must not give
you any clue about the sender/receiver.
 
> Now when you say that you could find the signer by brute-forcing "all
> keys in the 2^2048 key space", that seems to miss a vital step. Let's
> suppose you did this massive brute force, the universe still exists, and
> you found that the RSA key with keygrip
> 8FE036329129F568D5B58A88F6F8580A064E4887 has signed the message.
> Back to your goal. Who signed the message? You don't know. You know what the 
> RSA
> modulus of the key of this person is, but you don't know their identity,
> because your brute-force search did not produce an identity, it produced
> an RSA modulus and exponent.

But now I can go through my archive of intercepted messages, where I usually
know, where I intercepted them, e.g. at the hacked switch of company X.
I will check the timestamps of the messages, try to figure out the originators
working hours, check with my surveillance cameras from the other side of
the street pointing at the company X parking lot until I am quite sure, which
car and hence which person is related to activity with a given key.

As soon as I have that information, I guess 40kUSD should be sufficient
to have child, wife, whatsoever kidnapped to make the employee turn
me over the HSM with his private key plus the HSM password or decrypt
messages for me in case of stationary HSMs - thus breaking an "unbreakable"
cryptosystem with quite little amount of money (the kidnapping and one
year of switch-cyberop plus passive surveillance operation on the parking
lot) compared to really factorizing moduli or exploiting crypto software/
hardware bugs.

Maybe some criminals or secret services know better ways to perform
that task, maybe such operation is much more complicated than I
currently envision. At least by best practice use of cryptosystems, I
do not want to make them even think about such a scheme to begin
with.

> So: to know who signed a message, you need their public key. 

... and the receiver private key for sign AND encrypt schemes ...

> So to check
> a random signature without identification, you try all the public keys
> you have at your disposal (perhaps ignoring the ones you know are
> uninteresting). So your search space is your collection of public keys.

The crypto design is done in such a way, so that there is NO easily accessible
collection of public keys. I am even trying to extend it in a way, that even
have a plaintext list of all relevant remote party public keys - they only can
locate a remote party key after receiving a message and decrypting it without
verification to do the verification in a second step (that's why my attempt
to verify an encrypted message) before crafting a response, encrypting it
with the now known public key and forgetting about the key until the next
message is received.

So without massive theft of multiple physical components plus an intercept
of a significant amount of messages, access to the private keys, there is NO
WAY to gain any information about the set of used public or private keys.

Regards,
Roman
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Issue with pinentry GUI agent

[Kristian Fiskerstrand]

On 9/5/18 9:39 AM, Kristian Fiskerstrand wrote:
> without DISPLAY env var, qt version automatically falls back to curses
> variant despite the argument

Wrote too quickly there; This is actually wrong, it never actually falls
back to curses, it just fails.

-- 

Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk

Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

Quidquid latine dictum sit, altum videtur.
Anything said in Latin sounds profound



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Hiding signature identification (was: How to fix "ERROR key_generate 3355453" / "GENKEY' failed: IPC call has been cancelled")

[Peter Lebbing]

On 05/09/18 11:27, Fiedler Roman wrote:
> Sorry, but you are completely off here.

If there are six people I am actually interested in, and I know all
their public keys, checking if one of them signed a message with a
hypothetical "throw-keyid" takes me at most six trial verifications,
using their public keys in turn.

Now when you say that you could find the signer by brute-forcing "all
keys in the 2^2048 key space", that seems to miss a vital step. Let's
suppose you did this massive brute force, the universe still exists, and
you found that the RSA key with keygrip
8FE036329129F568D5B58A88F6F8580A064E4887 has signed the message. Back to
your goal. Who signed the message? You don't know. You know what the RSA
modulus of the key of this person is, but you don't know their identity,
because your brute-force search did not produce an identity, it produced
an RSA modulus and exponent.

So: to know who signed a message, you need their public key. So to check
a random signature without identification, you try all the public keys
you have at your disposal (perhaps ignoring the ones you know are
uninteresting). So your search space is your collection of public keys.

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

AW: How to fix "ERROR key_generate 3355453" / "GENKEY' failed: IPC call has been cancelled"

[Fiedler Roman]

> Von: Werner Koch [mailto:w...@gnupg.org]
> 
> On Wed,  5 Sep 2018 10:45, roman.fied...@ait.ac.at said:
> 
> > No, this is a signed AND encrypted message. Can gpgv only be
> > used to verify signatures on signed-only but not signed AND
> > encrypted messages, maybe due to encrypt AFTER sign scheme?
> 
> Correct.  The signature is encrypted and thus it needs to be decrypted
> before the signature can be checked.  gpgv is only for checking
> signature becuase it is designed to work without private keys.

Could you please update the documentation and the error messages
from gpg1/gpg2/gpgv to be more helpful?

Now I can also reproduce with gpg1/gpg2 verify on encrypted messages,
gpg1 reports "unexpected data", which is a little more helpful than
"unexpected error" from gpg2.

Regards,
Roman

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

AW: How to fix "ERROR key_generate 3355453" / "GENKEY' failed: IPC call has been cancelled"

[Fiedler Roman]

> Von: Werner Koch [mailto:w...@gnupg.org]
> 
> On Tue,  4 Sep 2018 18:31, roman.fied...@ait.ac.at said:
> 
> > At which byte offset should I find the signer key fingerprint?
> 
> That is an encrypted message and thus can you seen the the signature.

That is good, one more issue not having to care about.
 
> >> Leaving this out would not help because it is easy to
> >> figure out the key by trial verification against all known keys.
> >
> > Well, that would be all keys in the 2^2048 key space, so the problem
> > should be as hard to solve as factorization itself. As keys are never
> > transmitted unencrypted, the attacker has no chance to know a single
> 
> Nope.  Public keys, which are required to check a signature, are, as the
> name says, public and availabale from several sources, for example the
> key servers.

Sorry, but you are completely off here. You might also publish your public
keys world wide. But they may also be known only to a closed user group
to avoid traffic analysis, user enumeration, factorization attacks if poor
generators were used, ..

If you do not believe me, just search your key servers for NSA, BND, ...
public keys. I am sure, they use public key cryptography in many domains
and have very little of their public keys published.

The real topic of this discussion might be more if gnupg is a generic public key
cryptography security solution (where hiding keys might make sense, thus
software should be able to help fulfilling that goal) or if gnupg should only
be used for desktop e-mail encryption, where all those issues are much
less pressing as security requirements are much lower.

Regards,
Roman
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: AW: AW: AW: How to fix "ERROR key_generate 3355453" / "GENKEY' failed: IPC call has been cancelled"

[Werner Koch]

On Tue,  4 Sep 2018 18:31, roman.fied...@ait.ac.at said:

> At which byte offset should I find the signer key fingerprint?

That is an encrypted message and thus can you seen the the signature. 

>> Leaving this out would not help because it is easy to
>> figure out the key by trial verification against all known keys.
>
> Well, that would be all keys in the 2^2048 key space, so the problem
> should be as hard to solve as factorization itself. As keys are never
> transmitted unencrypted, the attacker has no chance to know a single

Nope.  Public keys, which are required to check a signature, are, as the
name says, public and availabale from several sources, for example the
key servers.


Shalom-Salam,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


pgpLF3ytSPmeY.pgp
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: AW: How to fix "ERROR key_generate 3355453" / "GENKEY' failed: IPC call has been cancelled"

[Werner Koch]

On Wed,  5 Sep 2018 10:45, roman.fied...@ait.ac.at said:

> No, this is a signed AND encrypted message. Can gpgv only be
> used to verify signatures on signed-only but not signed AND
> encrypted messages, maybe due to encrypt AFTER sign scheme?

Correct.  The signature is encrypted and thus it needs to be decrypted
before the signature can be checked.  gpgv is only for checking
signature becuase it is designed to work without private keys.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


pgpu4acKSmacY.pgp
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

AW: How to fix "ERROR key_generate 3355453" / "GENKEY' failed: IPC call has been cancelled"

[Fiedler Roman]

> Von: Peter Lebbing [mailto:pe...@digitalbrains.com]
> ...
> $ gpgv --keyring ./key.gpg data.gpg
>
> > Splitting up the message gives me
> >
> > 01-001.pk_enc
> > 02-018.encrypted_mdc
>
> This is an encrypted message. gpgv can't do anything with it.

No, this is a signed AND encrypted message. Can gpgv only be
used to verify signatures on signed-only but not signed AND
encrypted messages, maybe due to encrypt AFTER sign scheme?

If so update of the manual pages and a more talkative error message
instead of "gpgv: verify signatures failed: Unexpected error" would
be really nice.


Test trail:

* Prepare:

Remove standard GPG homedir to detect any access to it by error
(should never happen).

rm -rf -- "${HOME}/.gnupg"

testDir="$(mktemp -d)"
cd -- "${testDir}"

* Generate receiver key:

mkdir --mode=0700 -- Receiver
cat < 
Receiver/ReceiverKey.pub

* Generate sender key:

mkdir --mode=0700 -- Sender
/usr/bin/gpg1 --homedir Sender --batch --command-fd 0 --status-fd 1 --gen-key 
< Sender/SenderKey.pub

* Generate message:

/usr/bin/gpg1 --no-options --homedir Sender --keyring Receiver/ReceiverKey.pub 
--lock-never --trust-model always --sign --local-user "Sender Key" --encrypt 
--throw-keyids --hidden-recipient "Receiver Key" < 
Sender/OutgoingMessage.gpg
Secret message
EOF

* Decrypt and verify with gpg1 on receiver side:

/usr/bin/gpg1 --no-options --homedir Receiver --no-default-keyring --keyring 
Sender/SenderKey.pub --lock-never --trust-model always --batch 
--display-charset utf-8 --status-fd 2 --decrypt --try-all-secrets < 
Sender/OutgoingMessage.gpg

gpg: Good signature from "Sender Key"
[GNUPG:] VALIDSIG 7C8D39EA43614F2266EBD8F52A1DF9C596868A14 2018-09-05 
1536135808 0 4 0 1 8 00 7C8D39EA43614F2266EBD8F52A1DF9C596868A14

* Verify only with gpgv (from gnupg2):

Not clear from documentation, if gpgv could verify signed AND
encrypted messages. Use absolute path for sure as relative pathnames
will be handled differently.

/usr/bin/gpgv --status-fd 2 --homedir /proc/self/fd/nonexistent --keyring 
"${testDir}/Sender/SenderKey.pub" /proc/self/fd/0 < Sender/OutgoingMessage.gpg

[GNUPG:] UNEXPECTED 0
gpgv: verify signatures failed: Unexpected error

* Final checks:

Ensure default homedir was not created due to error in testing protocol:

ls -al -- "${HOME}/.gnupg"
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

AW: How to fix "ERROR key_generate 3355453" / "GENKEY' failed: IPC call has been cancelled"

[Fiedler Roman]

> Von: Peter Lebbing [mailto:pe...@digitalbrains.com]
>
> On 04/09/18 18:31, Fiedler Roman wrote:
> > /usr/bin/gpgv --status-fd 2 --homedir /proc/self/fd/nonexistent --keyring
> sign.pub /proc/self/fd/0
>
> You missed my point. You are not including a slash in the keyring
> argument, so gpgv is looking for it in the homedir.

Sorry, this is an error copying the command to the mail. In fact, the "gpgv"
call is and was always done with a long, absolute pathname I do not want to
disclose to the list. Therefore I just forgot the fact of the special pathname
behaviour immediately after reading it.

> And this works:
>
> $ gpgv --keyring ./key.gpg data.gpg
>
> > Splitting up the message gives me
> >
> > 01-001.pk_enc
> > 02-018.encrypted_mdc
>
> This is an encrypted message. gpgv can't do anything with it.

Then why does gpg1 verify claim to see a valid signature on the
very same file if there isn't even a signature included? I will
analyze it deeper but that will take time.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Issue with pinentry GUI agent

[Kristian Fiskerstrand]

On 9/4/18 6:10 PM, Daniel Kahn Gillmor wrote:
> or do you mean something else?

without DISPLAY env var, qt version automatically falls back to curses
variant despite the argument

kristianf@ares ~ $ unset DISPLAY
kristianf@ares ~ $ /usr/bin/pinentry-qt4 --display :0

(pinentry-qt4:6370): Gtk-WARNING **: 09:31:41.576: cannot open display:
kristianf@ares ~ $ export DISPLAY=:0
kristianf@ares ~ $ /usr/bin/pinentry-qt4 --display :0
OK Pleased to meet you

throwing in a simple wrapper around pinentry,
#!/bin/bash
env > /tmp/pinentry-log.txt
echo "$@" >> /tmp/pinentry-log.txt
exec /usr/bin/pinentry-qt "$@"

and diffing the log between keep-display, shows that the difference is
+DISPLAY=:0

btw, you say started, but this should also be updated when issuing
UPDATESTARTUPTTY shouldn't it? In any case, it solved the issue for the
user and I replicated it also on pinentry 1.1.0 on gnupg 2.2.10

-- 

Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk

Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

Credo quia absurdum
I believe it because it is absurd



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users