Re: Two utilities: gpg-tofu and gpg-graph

[Teemu Likonen]

Teemu Likonen [2019-02-17 08:23:38+02] wrote:

> I have made two utilities to help my usage of gpg. [...]

> gpg-tofu

> gpg-graph


I moved these utilities to a new combined repository:

https://github.com/tlikonen/gpg-utilities

There is also a new tool gpg-cert-path which find the shortest
certification distance between two keys.


-- 
/// Teemu Likonen   - .-..    //
// PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 ///


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

Re: gpg vs gpgv and trustedkeys

[Daniel Kahn Gillmor]

On Sat 2019-03-02 11:31:44 +0100, Olliver Schinagl wrote:
> Well the actualy firmware image validation will be done via a script
> there, so no worries on that regard. But if an engineer is tasked with
> modifying any of these scripts, they may struggle to know what's going
> on when invoking the tools themselves.

right.  If you have the capacity to make a thoughtful design of the
internal image validation script (both its API and its internal
codebase), then the validation script itself can serve as useful
tooling and explanatory guideposts for your engineers.

> gpgv should really remove this feature all together. E.g.  always
> point to a keyring.

This is an interesting suggestion, and i wonder whether GnuPG upstream
would be willing to consider it for some API-breaking new revision of
gpgv (or some alternate signature-verifying tool).

I've proposed a new process-level OpenPGP signature-verifying API over
here:

https://bugs.debian.org/872271

and you're right, it doesn't assume a default keyring, but rather
requires an explicit designation of which keys are acceptable.

I agree with you that the documentation should be improved, and i think
that upstream would welcome patches to that effect.

I've just submitted one improvement (to documentation about gpgv's
keyring selection) here:  https://dev.gnupg.org/T4386

One path toward actually deprecating the default keyring would be to
warn if the default keyring is used, probably in main() in
g10/gpgv.c.

> The trustedkeys file is just confusing (and the internet is only
> filled with confusion surounding this filename).  Many suggest to even
> just symlink the trustedkeys file to the pubkey files.

yikes.  I can imagine some unusual circumstances where that would be
reasonable, but it sounds particularly dangerous in contexts where you
care about who the signature comes from.


> Having said that, I'll didn't check/try; but what IS the best way to get
> a key into a system. I can do gpg --import and move + package the file
> of course; but is there a cleaner solution to get the file, into say
> /etc/keys for example? (Without using the --keyring paramater of gpg, as
> that paramater has come and gone in certain versions, so not sure how
> reliable that one is). Or is it really the only and recommended way.


The best way to create a set of keys that can validate is to explictly
and deliberately *export* (not import!) the keys that you know you care
about into a file.

so, verify that you get *only* the keys you want:

gpg --list-keys $FINGERPRINT

and then if it looks good:

gpg --output curated.pgp --export $FINGERPRINT

then you can pass curated.pgp to gpgv's --keyring argument.

Note that gpgv has weird non-standard semantics for its --keyring
argument, though -- if the filename has no "/" in it, it's assumed to be
found in the homedir (typically, ~/.gnupg/), rather than in the current
working directory, so i always specify keyrings with an absolute path.
in the shell, you can often launder it through realpath(1), so this
should be safe, regardless of how $KEYRING gets set:


KEYRING=curated.pgp
[…]
gpgv --keyring "$(realpath "$KEYRING")" "$signature" "$object"

Note also that the semantics of gpgv's return value may not match what
you want.  In particular, they make it difficult to ship additional
signatures during a time of key transition, because gpgv will return
non-zero if *any* discovered signatures are "bad" [0]. Additionally, gpgv
has some odd semantics around key creation time, expiry, revocation,
etc:

https://dev.gnupg.org/T1537

So you really do want to use --status-fd and parse its output to
determine what happened, and not just rely on its return code.

  --dkg

[0] explanation of the lifecycle of a signed series of updates:

 * at time T, clients fetch update U_T with signature bundle S_T.  the
   clients all verify that S_T is signed by one of the keys they know
   about.

 * initially, all clients know only about signing key K_0.

 * So, at early time A, a client fetches update U_A and signature S_A
   and verifies that S_A is made by K_0.

 * at some future time B, the authors introduce a new signing key K_1,
   but not all clients know about it yet.  S_B contains signatures from
   both K_0 and K_1.  Unupdated clients verify S_B over U_B based on
   K_0, while updated clients verify S_B over U_B based on K_1.

 * later, at time C, once all clients are known to be updated (or are
   explictly unsupported), the authors drop or revoke or destroy K_0,
   and sign new updates only with K_1.

between times B and C, any verification mechanism that depends on gpgv's
return code will break for clients that don't know about *both* K_0 and
K_1.  This requires software vendors to ship their preferred signing
keys well before they start actually distributing signatures with them,
which is a surprising workflow.


signature.asc
Description: PGP signature
___
Gnupg-us

Re: Howto override "encrypt-to KEYHERE" in gpg.conf?

[MFPA]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi


On Thursday 28 February 2019 at 1:40:56 PM, in
, g...@trodman.com
wrote:-


> My goal is to run gpg commands that entirely ignore
> my default-key and encrypt-to key
> in ~/.gnupg/gpg.conf.

- --no-options

- --
Best regards

MFPA  

Everyone makes mistakes. It is what you do afterwards that counts.
-BEGIN PGP SIGNATURE-

iNUEARYKAH0WIQSWDIYo1ZL/jN6LsL/g4t7h1sju+gUCXHyEu18UgAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTYw
Qzg2MjhENTkyRkY4Q0RFOEJCMEJGRTBFMkRFRTFENkM4RUVGQQAKCRDg4t7h1sju
+hqSAQDoHYdmxfXXS/iL59lKi7iEQSeKqsViNXNa98raL2W3ugEAmkQ3/2n4vmQv
EtuFZZFM+cRPe0MXBdwkwtgY8nFN9w+JApMEAQEKAH0WIQRSX6konxd5jbM7JygT
DfUWES/A/wUCXHyEu18UgAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0NTI1RkE5Mjg5RjE3Nzk4REIzM0IyNzI4MTMw
REY1MTYxMTJGQzBGRgAKCRATDfUWES/A/2uzD/9X4iaG7qzIGXwbHIrK46YR+iMM
uYVW957P3FtNqOIhf7asAXB5wTpKhB7ZnaHIXbmfi9uVCveu8yT4J/DXSrAeyraN
w3cc1DWBcYOcizT0pCo1fH/HWiO59NNcudKirJMZLkNn1p0M+FQuDVzFtMUAgqsg
VJCQV1xsEBPC4jBs9s54QswW0I9iFKMVi3erpSJ00vcIIyVANu0POvLfjh9m6Ixp
E+RoyLP44klw5JjSEF5pdkkDtmBOg1Igza9baLzZjUxXHzWCw27CIysD084jjUqN
tZ+bFOavquKLjjulQvTDHify5USUhRDG2qrDZ8rLpxNckvrd9VkQ3umPEY7J+2Jn
rqgD39oahxtxlwqLgm8/EHoATIGJvzOtx5JS4i5o3cZXWXHI5olxsXCRVrgMpTZv
Iq1TxB9lljY/FaIfR9X2ebM5BBg7I3VXg3uD0m2sTbt/RxOkRoitWG/YaGjW8si3
bvzsZp10HrLHawPzG3kH0/PCxQF74KYTOdfzEaFxcIeiQaRe6VSxyUFe9Fy934E6
zzuXAf4Esvm7p4XVhJUY+SzPtMBVQjKfSVIn5xEU0wLLgDjd1feDXKFomxNvx1SO
DgQ2wkdxgKHl2q6x3EjOWF5Q+jmyPY1uyTBWV3eeJql4aOYd5hwj6WxBGZtvHrEu
IYktMs3vyNfoUg1cxA==
=BWOr
-END PGP SIGNATURE-


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

Invalid IPC Response requiring gpg-agent restart

[Farhan Khan via Gnupg-users]

Hi all,

I am ssh'ing into a FreeBSD box with my PGP key. I noticed that when I try to
decrypt or sign something, I get this error:

---
$ echo test | gpg -a --sign
gpg: signing failed: Invalid IPC response
-BEGIN PGP MESSAGE-

gpg: signing failed: Invalid IPC response
---

When I check the running processes, I see this:
gpg-agent --homedir /usr/home/user/.gnupg --use-standard-socket --daemon

My ~/.gpg-agent.conf is:
enable-ssh-support
default-cache-ttl 300
max-cache-ttl 1200

If I kill this process and restart using "gpg-agent --daemon', everything works
fine. Is there a long-term solution to fix whatever settings is broken?

Thanks!
---
Farhan Khan
PGP Fingerprint: 1312 89CE 663E 1EB2 179C  1C83 C41D 2281 F8DA C0DE


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