Hi everyone,
I am currently experiencing a problem with future-created keys and was
wondering if there was a work around.
Any help would be most appreciated.
-----------------------------------------------------------------------
The Problem:
-----------------------------------------------------------------------
e.g.
Step 1. Comp A has a future time (110 seconds in this example) - it
generates a key and sends it to the Keyserver.
Step 2. Comp B imports Comp A's key from the keyserver:
$> gpg --ignore-time-conflict --homedir gpg --keyserver XXX.XX.XXX.XX
--always-trust --recv-keys ABA2D44E
$> gpg: requesting key ABA2D44E from HKP keyserver XXX.XX.XXX.XX
$> gpg: key has been created 110 seconds in future (time warp or clock
problem)
$> gpg: key has been created 110 seconds in future (time warp or clock
problem)
$> gpg: key ABA2D44E: not changed
$> gpg: Total number processed: 1
$> gpg: unchanged: 1
Step 3. Comp B then tries to use Comp A's key to encode something
$> /usr/bin/gpg --ignore-time-conflict --homedir gpg -e -r
ABA2D44E
$> gpg: ABA2D44E: skipped: unusable public key
$> gpg: [stdin]: encryption failed: unusable public key
-------------------------------------------------------------------------
Is this correct behaviour? Shouldn't the '--ignore-time-conflict' flag
in step three allow it to encode anyway?
In the above example, the key was 110 seconds in the future (see step
2), after 110 seconds, step three is successful.
What is the point of the "--ignore-time-conflict" in this situation? It
doesn't seem to do anything.. :(
Is there a way to get around this, so Step 3 works even though the key
is in the future?
Thanks in advance,
Kind Regards,
Jonathan
I am currently experiencing a problem with future-created keys and was
wondering if there was a work around.
Any help would be most appreciated.
-----------------------------------------------------------------------
The Problem:
-----------------------------------------------------------------------
e.g.
Step 1. Comp A has a future time (110 seconds in this example) - it
generates a key and sends it to the Keyserver.
Step 2. Comp B imports Comp A's key from the keyserver:
$> gpg --ignore-time-conflict --homedir gpg --keyserver XXX.XX.XXX.XX
--always-trust --recv-keys ABA2D44E
$> gpg: requesting key ABA2D44E from HKP keyserver XXX.XX.XXX.XX
$> gpg: key has been created 110 seconds in future (time warp or clock
problem)
$> gpg: key has been created 110 seconds in future (time warp or clock
problem)
$> gpg: key ABA2D44E: not changed
$> gpg: Total number processed: 1
$> gpg: unchanged: 1
Step 3. Comp B then tries to use Comp A's key to encode something
$> /usr/bin/gpg --ignore-time-conflict --homedir gpg -e -r
ABA2D44E
$> gpg: ABA2D44E: skipped: unusable public key
$> gpg: [stdin]: encryption failed: unusable public key
-------------------------------------------------------------------------
Is this correct behaviour? Shouldn't the '--ignore-time-conflict' flag
in step three allow it to encode anyway?
In the above example, the key was 110 seconds in the future (see step
2), after 110 seconds, step three is successful.
What is the point of the "--ignore-time-conflict" in this situation? It
doesn't seem to do anything.. :(
Is there a way to get around this, so Step 3 works even though the key
is in the future?
Thanks in advance,
Kind Regards,
Jonathan