Shawn Walker writes:
> On Jun 16, 2009, at 2:01 PM, James Carlson wrote:
> > Chris Quenelle writes:
> >> 1. list of headers without version info (generated by compiler, put
> >> into .o)
> >>
> >> 2. complete URL pointing at web-based tree of headers including
> >> hash code
> >> The hash code would be retrieved from the system at compile time.
> >
> > If the hash were based on contents (such as MD5), rather than embedded
> > #pragmas, then you'd have a fairly good guarantee that nobody did
> > "sudo vi /usr/include/stdio.h" and then lied about it. That alone
> > might be pretty useful.
>
>
> pkg(5) stores a hash of each file delivered by a package and pkg
> verify can be used to ensure that files haven't been changed. I don't
> know what SVR4 does...
I think you're missing the point that I was making.
By having the compiler store hashes into the object, you could
independently verify that a given object was indeed produced from an
unaltered set of sources without actually needing or having access to
those sources. The fact that pkg(5) can verify the files on a given
system is irrelevant; the user who has that object file alone doesn't
necessarily have access to the system where it was built.
Previously, the compiler team was depending on the #pragma messages
inserted into the object files to work their way back to the source
files that were used to produce the object. My point is that we can
do much better here. Not only were the old #pragmas fragile[1], but
the hash approach is much more flexible, integrated, and predictable.
It allows *anyone* to map directly to the exact packages used and do
so for *any* consolidation, rather than indirectly via a trip through
SCCS 'prs' land.
(For what it's worth, the old SVR4 packaging code could verify based
on sum(1) values. Not nearly as good, and certainly not usable for
the sort of file-identifying hash purpose I'm suggesting.)
1. The SCCS ID numbering space is independent for each file in each
update release, so if someone copied an S10 file to S8, you
wouldn't know that it happened. It would just look like an S8
file, unless you happened to know that the ID was reused. Plus
the fact that we sometimes flubbed them by checking in expanded
keywords, and that not *all* of the consolidations in Solaris even
used them.
--
James Carlson, Solaris Networking <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
