Darren J Moffat wrote:
James C. McPherson wrote:
....
We've got a unique hash which identifies "binary X". We can create
a publishable mapping (ie, on sunsolve) between that hash and the
version of the source that it is based on.
Why is it needed that you map a given random binary to source files ?
The wsdiff tool may help here though.
ignore wsdiff for the moment, and remember that not everybody
out there in Services-land cares about the source, just the
mapping of patch numbers to bugids. That is why we need it.
Sun already has the finger print database which maps the binaries going
back all the way to Solaris 2.0 and patches to MD5 hashes.
I was wondering when you'd bring that up.
As I mentioned to Rich Lowe on irc a little while ago, this has
turned into one of those "oh, we've got a nifty tool to do that
already ... just nobody used it" kinda scenarios. Time, I think,
for some evangelising on the fingerprint db.
The various automagical tools that Support Services people make
use of can definitely be re-targeted to make use of said hash(es).
My remaining concern is/was secure sites, where Sun has to send
an SSE onsite to do things. Reading a unique hash over the phone
line is going to be a pain in the rear (and yes, it will happen),
but I think the benefits of the hash will outweigh the downsides.
It isn't that hard, plus even on secure sites like that you should be
able to get the hashes off site after all they are public information
after all!
And the other already-invented-here response is "gee, that would
appear to be tailor made for including on the EIS distribution."
So to me, it looks like problem solved.
cheers,
James C. McPherson
--
Solaris kernel software engineer
Sun Microsystems
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
