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

[Friedrich W. H. Kossebau]

Am Donnerstag, 19. August 2021, 15:40:44 CEST schrieb 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.

Thanks for pre-forwarding then :)

Hm, with little experienced with PGP (even if my first key signing party was 
almost 2 decades (sic) ago) I wonder though what use-case that is optimized 
for. Are people by default not interested in usable keys only? And even the 
expired ones might be interesting, if you have some old encrypted/signed data 
for which the expired key was used, no?

That should be then rather --list-unexpired-keys-even-if-unusable ;)

</newbie thoughts>

> 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.

Taken home, hopefully not buried soon on desk :)

> > 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.

Would agree here, just stayed away from proposing as it would involve also 
reganerating some of the testdata if I am not mistaken, which would be a 
bigger investment for me PGP layman. Okay if I just add that as TODO comment 
then?

Also happy to test instead a MR from a non-layman with respective changes :)

Cheers
Friedrich