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

[Friedrich W. H. Kossebau]

Am Donnerstag, 19. August 2021, 12:35:38 CEST schrieb Sandro Knauß:
> You can set the GnupgHome via EncryptJob::setGnupgHome, but in general it
> need to follow the environment variable, as the tests hopefully worked at
> some point in the past, that worked.

Yep, as it shows, that had not made a difference/was not needed,

> > (Good to see I am not the only one confused by all the distributed code,
> > already had lots of times where I rebuild and installed to test something,
> > only to find the file I had edited was from another repo :) )
> 
> Just didn't knew that EncryptJob is used.
> 
> > --- 8< ---
> > $ LANG=C GNUPGHOME=/tmp/filteractionencrypttest-FkXyit/gpghome gpg
> > --version gpg: WARNING: unsafe permissions on homedir
> > '/tmp/filteractionencrypttest- FkXyit/gpghome'
> > [...]
> > --- 8< ---
> 
> This was not the test I wanted you to archive. I wanted that you run gpg --
> version by calling the GpgHelper, to just make sure, that it does the
> correct thing.

Okay, misunderstood then, as I was too focussed on the place where the unit 
test failed with an error :)

> > GNUPGHOME = <path> gpg -e -r kmail at test.kde -o encrypt.asc
> > 
> > Perhaps this one already sheds more light/shadows indicating something for
> > you, as it gives us the very error message?
> > 
> > --- 8< ---
> > $ LANG=C GNUPGHOME=/tmp/filteractionencrypttest-FkXyit/gpghome gpg -e -r
> > kmail at test.kde -o encrypt.asc testfile.txt
> > gpg: key 358732559B8659B2 was created 1663 days in the future (time warp
> > or
> 
> clock problem)
> 
> > gpg: error retrieving 'kmail at test.kde' via Local: Unusable public key
> > gpg: kmail at test.kde: skipped: No data
> > gpg: testfile.txt: encryption failed: No data
> > --- 8< ---
> 
> I learned that the fake system time must be in the valid timeframe to make
> the key usable. (well it makes totally sense, as we want to test gpg how it
> act at an other time).

I see. I failed here then when copying over the line from messagelib's config
--- 8< ---
faked-system-time 20130110T154812
--- 8< ---
without thinking further if the actual timestamp needs some sanity adaption 
for the use within the mailcommon test, as I was focussed on the key itself. 
And then --list-keys  already changing behaviour turned my focus away. #)

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.

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

Cheers
Friedrich