[SEEMS SOLVED Re: Help needed to fix FilterActionEncryptTest::shouldEncrypt(PGP*) unit tests

[Ingo Klöcker]

On Donnerstag, 19. August 2021 15:17:08 CEST Friedrich W. H. Kossebau wrote:
> Small blame still on the bit surprising inconssitent behaviour of gnupg
> then, that it with --list-keys simply omits outdated keys (I can see why),
> while listing future-timestamped-impeded keys without further hint, besides
> some not really making clear this is considered a hard issue note like
> --- 8< ---
> gpg: key yxz was created 1663 days in the future (time warp or clock
> problem) --- 8< ---
> 
> Someone (tm) should ask the gnupg developers to make it more obvious that
> this means "unusable", as I remember to have seen related confusion in
> other people questions for help on the webs. Just could not make the needed
> connections before.

Well, if you want to get information about the validity of keys you have to 
use the --with-colons option. This is the first thing the GnuPG developers 
will tell you to do.

Example:
$ gpg --list-keys --with-colons Anna
tru::1:1626098443:1659530579:3:1:5
pub:u:
255:22:2C0444CB59852D29:1608542943:1671922798::u:::scESC:::::ed25519:::0:
fpr:::::::::3A8536D46F57779C49F0CF542C0444CB59852D29:
uid:u::::1624894136::365F2D4D1E398E9FE11647DE9A81949FFCB6C0B8::Anna Remark 
<anna at example.net>::::::::::0:
sub:u:255:18:547ECA3FEAB73FC2:1608542943:1671663598:::::e:::::cv25519::
fpr:::::::::4DE4678D1CB12ECD4E9D8B6E547ECA3FEAB73FC2:

The validity is in the second field of the (primary) pub(lic key), the uid and 
the sub(key). In this case the validity is "ultimate".

Now the same with faked system time before key creation:
$ gpg --list-keys --with-colons --faked-system-time 20070924T154812 Anna
gpg: WARNING: running with faked system time: 2007-09-24 15:48:12
gpg: key 2C0444CB59852D29 was created 4836 days in the future (time warp or 
clock problem)
gpg: key 2C0444CB59852D29 was created 4836 days in the future (time warp or 
clock problem)
gpg: key 2C0444CB59852D29 was created 4836 days in the future (time warp or 
clock problem)
gpg: key 2C0444CB59852D29 was created 4836 days in the future (time warp or 
clock problem)
tru::1:1626098443:1659530579:3:1:5
pub:i:255:22:2C0444CB59852D29:1608542943:::u:::sca:::::ed25519:::0:
fpr:::::::::3A8536D46F57779C49F0CF542C0444CB59852D29:
uid:u::::::365F2D4D1E398E9FE11647DE9A81949FFCB6C0B8::Anna Remark 
<anna at example.net>::::::::::0:
sub:i:255:18:547ECA3FEAB73FC2:1608542943:::::::::::cv25519::
fpr:::::::::4DE4678D1CB12ECD4E9D8B6E547ECA3FEAB73FC2:

As you can see pub and sub are now flagged as i(nvalid).

Take home message: Whenever you want to know detailed information about 
OpenPGP keys (or even S/MIME keys imported with gpgsm) use the --with-colons 
option.

"The details of this [output] format [of the --with-colons option] are 
documented in the file ‘doc/DETAILS’, which is included in the GnuPG source
distribution." It should also be included in the gpg package of your 
distribution (or maybe in a separate gpg-doc package).

> > Finally you got me to test this by myself.
> 
> Thanks for digging in and uncovering the issue :)
> 
> Yes, adding a gog.conf with a timestamp in the time span of the test's key
> validness fixed the test for me, as well as all manual testing.
> 
> And with that and a version of MR 12 applied I now get
> "0 tests failed out of 73"
> for the unit tests of mailcommon locally :)
> 
> Should turn the faked-system-time config solution into another MR tonight
> then.

In my opinion, a better fix would be to replace the test keys by keys which do 
not expire. Expiring test keys only make sense for tests where expiration is 
required for the test, e.g. if the test checks that expired keys are excluded 
from some operation.

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: <http://mail.kde.org/pipermail/kde-pim/attachments/20210819/18da14c1/attachment.sig>