Time Stamping Again.

Time Stamping Again.

[Austin Obyrne]

GNAT 3.11p  (981118) Copyright 1992-1998 Free Software Foundation, Inc.

Compiling: c:\docume~1\admini~1\mydocu~1\skewli~3\skewline_batch_encryption_mark_0.adb (source file time stamp: 2012-09-14 08:16:36)



This is a copy of the time stamp in my computer.  I’m using this older compiler and I’m working in Windows XP.

Maybe this time stamp attribute is peculiar to AdaCore Technologies compilers only?

Seems a useful function to me that should be considered for all versions of the compiler – maybe it does? – Anybody.

The drill is this,

I go to "RUN" 0n the editor tool bar  => Compile to listing on the drop-down menu that appears.

One can revert to normal compiling straight away after – no permanent change to anything.

It should be taken that in a real world situation only free-standing computers would be used for development work in cryptography (I would say)so as to obviate hacking by adversaries.

Thanks - adacrypt

Re: Time Stamping Again.

[Simon Wright]

Austin Obyrne <austin.obyrne@hotmail.com> writes:

> GNAT 3.11p  (981118) Copyright 1992-1998 Free Software Foundation, Inc.
>
> Compiling:
> c:\docume~1\admini~1\mydocu~1\skewli~3\skewline_batch_encryption_mark_0.adb
> (source file time stamp: 2012-09-14 08:16:36)
>
>
>
> This is a copy of the time stamp in my computer.  I’m using this older
> compiler and I’m working in Windows XP.
>
> Maybe this time stamp attribute is peculiar to AdaCore Technologies
> compilers only?
>
> Seems a useful function to me that should be considered for all
> versions of the compiler – maybe it does? – Anybody.
>
> The drill is this,
>
> I go to "RUN" 0n the editor tool bar => Compile to listing on the
> drop-down menu that appears.

This is ertainly present in GCC 4.7.0 & GNAT GPL 2012, I think it always
has been.

The command-line compiler flag is -gnatl.

Re: Time Stamping Again.

[Austin Obyrne]

On Friday, September 14, 2012 7:58:04 PM UTC+1, Simon Wright wrote:
> Austin Obyrne <austin.obyrne@hotmail.com> writes: > GNAT 3.11p (981118) Copyright 1992-1998 Free Software Foundation, Inc. > > Compiling: > c:\docume~1\admini~1\mydocu~1\skewli~3\skewline_batch_encryption_mark_0.adb > (source file time stamp: 2012-09-14 08:16:36) > > > > This is a copy of the time stamp in my computer. I’m using this older > compiler and I’m working in Windows XP. > > Maybe this time stamp attribute is peculiar to AdaCore Technologies > compilers only? > > Seems a useful function to me that should be considered for all > versions of the compiler – maybe it does? – Anybody. > > The drill is this, > > I go to "RUN" 0n the editor tool bar => Compile to listing on the > drop-down menu that appears. This is ertainly present in GCC 4.7.0 & GNAT GPL 2012, I think it always has been. The command-line compiler flag is -gnatl.

Many thanks - to me that's pretty conclusive.

Being accurate to one second this is a usefull time stamp.

Cheers - adacrypt

Re: Time Stamping Again.

[björn lundin]

Den fredagen den 14:e september 2012 kl. 22:11:22 UTC+2 skrev Austin Obyrne:
> On Friday, September 14, 2012 7:58:04 PM UTC+1, Simon Wright wrote:
> 
> 
> Many thanks - to me that's pretty conclusive.
> Being accurate to one second this is a usefull time stamp.

Yes, hm, how about setting the computer clock to 1995-04-1 and
change that source file. Then compile it again.
Very useful time stamp ?
Evidence of when it was changed?
No, perhaps an indicator on what that particular computer's clock was set
to at the time of editing - nothing more ...

/Björn

Re: Time Stamping Again.

[Austin Obyrne]

On Friday, September 14, 2012 10:10:17 PM UTC+1, björn lundin wrote:
> Den fredagen den 14:e september 2012 kl. 22:11:22 UTC+2 skrev Austin Obyrne: > On Friday, September 14, 2012 7:58:04 PM UTC+1, Simon Wright wrote: > > > Many thanks - to me that's pretty conclusive. > Being accurate to one second this is a usefull time stamp. Yes, hm, how about setting the computer clock to 1995-04-1 and change that source file. Then compile it again. Very useful time stamp ? Evidence of when it was changed? No, perhaps an indicator on what that particular computer's clock was set to at the time of editing - nothing more ... /Björn

I guess there's nothing that can't be perverted in some way.

This time stamp to my mind is a mutual datum that has potential use in E_commerce (perhaps) as a tool in cases of non-repudiation of contracts made by e_mail.


I don't want to open another can of worms here but anything that lends itself to non-repudiation of e-commerece can only be good.  This requires a whole "scheme" of methods that can quickly collate hard evidence for use in a prosecution in law in the event of subsequent attempts at fraud.  It requires more than just one stumbling block to fraud obviously, an entire arsenal of traps against such fraud is needed. 

Using numbered compilers (copies to trusted third parties like say conventional solicitors) that are predated in a synchronised way is a starting point at least.  The entities would have to explain how the time stamp doesn't coincide if they later try to change the numbered and timed agreement and purport it to be the original one.

There's much more to this but time stamping of compilers to my mind is a useful start as a basic tool at least.

Cheers - adacrypt

Re: Time Stamping Again.

[Dirk Heinrichs]

Austin Obyrne wrote:

> I guess there's nothing that can't be perverted in some way.

Well, you can't do the same sort of tampering with checksums (or even GPG 
signatures).

Bye...

	Dirk
-- 
Dirk Heinrichs <dirk.heinrichs@altum.de>
Tel: +49 (0)2471 209385 | Mobil: +49 (0)176 34473913
GPG Public Key C2E467BB | Jabber: dirk.heinrichs@altum.de

Re: Time Stamping Again.

[Austin Obyrne]

On Saturday, September 15, 2012 5:15:56 PM UTC+1, Dirk Heinrichs wrote:
> Austin Obyrne wrote: > I guess there's nothing that can't be perverted in some way. Well, you can't do the same sort of tampering with checksums (or even GPG signatures). Bye... Dirk -- Dirk Heinrichs <dirk.heinrichs@altum.de> Tel: +49 (0)2471 209385 | Mobil: +49 (0)176 34473913 GPG Public Key C2E467BB | Jabber: dirk.heinrichs@altum.de

Like a lot of other things in computer science this whole topic bears a lot of discussion that is apppication-specific on a particular day maybe but not generally the case on all other days.

Frankly, 

Quote:

 "Well, you can't do the same sort of tampering with checksums (or even GPG signatures)." 

This is highly subjective and I think I can demonstrate that in a real situation that the 'tampering' he says is feasible is not in fact possible to implement undetected but arguments are possible all the time.

Thanks for your input - adacrypt 

- show quoted text -

Re: Time Stamping Again.

[Austin Obyrne]

On Friday, September 14, 2012 7:58:04 PM UTC+1, Simon Wright wrote:
> Austin Obyrne <austin.obyrne@hotmail.com> writes: > GNAT 3.11p (981118) Copyright 1992-1998 Free Software Foundation, Inc. > > Compiling: > c:\docume~1\admini~1\mydocu~1\skewli~3\skewline_batch_encryption_mark_0.adb > (source file time stamp: 2012-09-14 08:16:36) > > > > This is a copy of the time stamp in my computer. I’m using this older > compiler and I’m working in Windows XP. > > Maybe this time stamp attribute is peculiar to AdaCore Technologies > compilers only? > > Seems a useful function to me that should be considered for all > versions of the compiler – maybe it does? – Anybody. > > The drill is this, > > I go to "RUN" 0n the editor tool bar => Compile to listing on the > drop-down menu that appears. This is ertainly present in GCC 4.7.0 & GNAT GPL 2012, I think it always has been. The command-line compiler flag is -gnatl.

Just in case it is of any interest to readers,

How this works.

The time stamp records the time that the source code was *last modified.

One can compile a program as often as you like without overwriting the time stamp i.e. by 'ordinary' compile or by 'compile to listing' and the recorded time stays put  - even if its years later. (in that case just clicking on 'Build' or 'Link' alone should do in the interim - not necessary to re-complie in other words).

But if new sourcecode is added and compiled the new time is recorded as at the new updated time stamp.


If you want to keep the old time on record just build the program amd run it at any time.  It doesn't do any harm to the recorded time however to re-compile before running a program but it just isn't necessary to do that.  

There is a "compile once only" school of thought in this respect by at at least one expert that I know - build is enough after the initial compile unless new sorcecode is added.

Many thanks all - adacrypt

Re: Time Stamping Again.

[Pascal Obry]

I've not followed all the discussion and I don't have time to track all
this tread, sorry.

It just looks like time-stamp is not what you want to me. If you want to
ensure that the source code used to compile such or such .o has not been
changed and is properly identified why not use a proper signature (MD5
or even better SHA-1)? Will this fulfill your needs?

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|    http://www.obry.net  -  http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Time Stamping Again.

[Austin Obyrne]

On Saturday, September 15, 2012 11:15:44 AM UTC+1, Pascal Obry wrote:
> I've not followed all the discussion and I don't have time to track all this tread, sorry. It just looks like time-stamp is not what you want to me. If you want to ensure that the source code used to compile such or such .o has not been changed and is properly identified why not use a proper signature (MD5 or even better SHA-1)? Will this fulfill your needs? Pascal. -- --|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://www.obry.net - http://v2p.fr.eu.org --| "The best way to travel is by means of imagination" --| --| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

This is not so much solving a problem per se as using a handy resource that is going begging in every compiler - a solution waiting for a problem.

There are lots more conditions in a non-repudiation scheme that do what you say  adequately when met.

To me this is more a passing curio that seems to be going unnoticed by many users of language compilers. 

It has been put there for a purpose no doubt and I speculate on at least one good use to which it may be put !

Cheers - adacrypt

Re: Time Stamping Again.

[Dirk Heinrichs]

Austin Obyrne wrote:

> To me this is more a passing curio that seems to be going unnoticed by
> many users of language compilers.
> 
> It has been put there for a purpose no doubt and I speculate on at least
> one good use to which it may be put !

It's not really going unnoticed. It is a standard feature of any C/C++ 
compiler provided via the __TIME__ and __DATE__ macros. But in most cases, 
it is considered harmful. Let's think about software development in larger 
teams. Let's also assume that it is vital for fixing bugs to be able to 
exactly and verifiably reproduce past builds.

So you do a release build and create checksums of your .o files. When you 
need to reproduce that builds a year or two later, you can again create 
checksums and check them against the original ones to make sure you've built 
exactly what the customer has.

Now, when above macros have been used to record compilation time and date in 
your .o files, you'll always have a checksum mismatch and you can never be 
sure that you've built again what has been built before.

So checksums are, as others have already pointed out, the far better 
alternative, because a checksum always stays the same for the same 
compilation, but a timestamp does not.

Bye...

	Dirk
-- 
Dirk Heinrichs <dirk.heinrichs@altum.de>
Tel: +49 (0)2471 209385 | Mobil: +49 (0)176 34473913
GPG Public Key C2E467BB | Jabber: dirk.heinrichs@altum.de