Re: Lack of Mature Tools (was: Lockheed Martin, Green Hills, etc.)

["Robert I. Eachus" <rieachus@earthlink.net>]

Chris Morgan wrote:
 
> Are you really suggesting that if I see an announcement of a new
> public release of gnat on comp.lang.ada and I then download a file
> with that version number from cs.nyu.edu in /pub/gnat that it may
> somehow be corrupted? The wrong file? Altered by random strangers?

    I believe that the right answers are: several times, happened at
least once, and has not happened yet--at least on cs.nyu.edu.  There are
many different  versions of each new gnat release that can be found on
cs.nyu.edu.  There have been uploading problems on several occasions
resulting in corrupted files, and at least once the wrong version of a
binary was uploaded.  Note also that not all of the versions available
from cs.nyu.edu are created by ACT and so ACT as such has no way to
guarentee conformance for such versions.

    Having said all that--and RBKD or someone else can provide the gory
details--GNAT is probably at least as reliable and robust as Netscape or
other products you can download over the net.  But if you see the
announcement of a new "p" release and download it immediately, there
will be times when you will have to go back for the correct version.  So
yes, Robert is implying that those things can happen and that ACT cannot
be responsible--among other things, it is not their server.

> This seems like a surprising claim to me. I'll bet you (i.e. ACT) can
> be pretty sure that those bits correspond exactly to the ACT build of
> that public version just with a sum(1). If you published checksums on
> www.gnat.com everybody else could be fairly sure as well, no matter
> where they actually downloaded the file from. Better checks are also
> easily provided (e.g. MD5) as seen on many other open source or free
> software projects.
> 
> Not doing that is perfectly fine, but claiming the resultant lack of
> verifiability leads to authenticity problems seems very weaselly to
> me.

      I don't think any weaseling was intended.  MD5 checksums would
probably be a good idea, but the archive formats do include checksums
that detect truncated or corrupted files.  When I am concerned about
someone maliciously modifying software, however, I much prefer CD as a
delivery media.   After installing, you should checksum not just the
compiler, but the entire directory hierarchy.  There are tools to do
this.  Such tools in fact are included in the DII COE, and in GCCS their
use is mandatory.