Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 1.6.0b3

Bug #21152 Ignore time conflicts
Submitted: 2016-12-03 07:22 UTC
From: alec Assigned: alec
Status: Closed Package: Crypt_GPG (version 1.6.0b2)
PHP Version: Irrelevant OS:
Roadmaps: 1.6.0b3    
Subscription  


 [2016-12-03 07:22 UTC] alec (Aleksander Machniak)
Description: ------------ A scenario here is that user generates a key-pair in a web browser using openpgp.js then uploads it to the server where gpg is used to import it to a user keyring. Problem is the time on server is a few seconds behind the time on the client. So, GnuPG 2.0.22 does this: gpg: key A65FB1D8: secret key imported gpg: key A65FB1D8 was created 6 seconds in the future (time warp or clock problem) gpg: key A65FB1D8 was created 6 seconds in the future (time warp or clock problem) gpg: key A65FB1D8 was created 6 seconds in the future (time warp or clock problem) gpg: key A65FB1D8 was created 6 seconds in the future (time warp or clock problem) gpg: key A65FB1D8: no valid user IDs gpg: this may be caused by a missing self-signature gpg: Total number processed: 1 gpg: w/o user IDs: 1 gpg: secret keys read: 1 gpg: secret keys imported: 1 IMPORT_OK 17 85CE61FECEFC0C46D505D6F20C507F31A65FB1D8 IMPORT_RES 1 1 0 0 0 0 0 0 0 1 1 0 0 0 I found it a little bit confusing. First, the hint about missing self-signature and no valid user IDs is not very useful and misleading. Second, it had actually imported something, I'd expect to not import anything at all. Third, the "clock problem" error is displayed (actually logged in this case) four times. Looks like there is a solution. It is --ignore-time-conflict (and maybe --ignore-valid-from).

Comments

 [2016-12-04 11:52 UTC] alec (Aleksander Machniak)
-Status: Open +Status: Closed -Assigned To: +Assigned To: alec -Roadmap Versions: +Roadmap Versions: 1.6.0b3
This bug has been fixed in SVN. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better.