Problem with faked-system-time option

[Amano Corunga]

On Tue, 07 Jun 2011 10:18:40 +0200, Werner Koch wrote:

>On Sun,  5 Jun 2011 21:15, amanoc at dizum.nl said:
>
>> To begin with, I wonder whether I have to drag along all those 25 MB
>
>The light installer is 15MB.

I subsumed all the files I found in the GnuPG folder of a fresh
Gpg4Win installation, which may approximate those 15 MB packed.

>> iconv.dll).  Is there a chance to slim it down in case I only need to
>> create / delete keys and encrypt / sign / verify messages?
>
>Yes, in theory but it is a lot of work to distribute and maintain 3
>installers.  Even convincing my co-hackers to keep the light installer
>was not easy.
>
>You may build your own installer of course.  The installer is a meta
>package and using a decent Debian OS a new installer is easy to build.
>
>> without altering the host system.  I have GPG1 with all its data
>> stored on a removable device and use it on several computers, no local
>> installation required.  That's a perfect portable application, which
>> shouldn't be dismissed without an adequate replacement at hand.
>
>The installer can't do that out of the box.  

But is it technically possible to use GPG2 like GPG1 as a portable
application which leaves no traces on the host system?

And, though I don't require an installer, without further information
I'm not capable of locating the files that aren't required for basic
tasks?

>> Last but not least, do I have to start the gpg-agent background task
>> for each command line gpg call if I don't want to risk data corruption
>> when inadvertently removing that USB device?
>
>If the gpg-agent fails it gfails and it won't corrupt any data.

I'm relieved to hear that.

>> GPG1, if it only had that faked-system-time option.  Is there room for
>> hope to get it enhanced that way?
>
>The faked-system-time option is a debug option we need to run the
>regression tests.  If you merely want to create your keys with an other
>creation date you may use a parameter file:
>
>  @item  Ceation-Date: @var{iso-date}
>  Set the creation date of the key as stored in the key information and
>  which is also part of the fingerprint calculation.  Either a date like
>  "1986-04-26" or a full timestamp like "19860426T042640" may be used.
>  The time is considered to be UTC.  If it is not given the current time
>  is used.
>
>The batch key generation and that parameter is supported by all
>versions.

I gladly confirm it really works - Great!  GPG1 key creation problem
solved.

But is there an equivalent for determining signature timestamps?

It's fair to say that GnuPG is one of the most important privacy tools
out there.  It protects data from unauthorized access, with
'throw-keyids' the recipient's identity is hidden, but why in the
world do I involuntarily have to allow others to gain sensitive
information about my time management with each mail I sign?  I don't
quite understand why that's of minor importance to others.  If OTOH
you're aiming at a signature with a trusted timestamp in no way
whatsoever the local computer's system clock can replace a validated
time stamp service.  So why not allow everybody to specify signatures'
timestamps directly instead of making that option accessible only to
those who are permitted to change their Windows computer's system time
(thanks Daniel for your Linux advice) and tolerant against all the
adverse side effects arising from that manipulation?

Thanks

Amano