FW: Image Unique Identifier

David T. Lewis lewis at mail.msen.com
Thu Aug 24 02:34:25 UTC 2006


On Thu, Aug 24, 2006 at 12:56:26AM +0200, Lex Spoon wrote:
> Okay, enough bashing of UUID's.  For your problem, here are two
> possible avenues for (non-universally unique) ID's to use.
> 
> 1. An IP plus a process ID (which might be an IP port number) plus an
> image-wide unique number.  Such an ID is unique relative to a
> particular IP network, but of course can be duplicated--just think
> about all the computers in the world with address 192.168.1.1.

By no means guaranteed to be unique, but recent versions of the VM
provide a sessionIdentifier for this purpose, which as you suggest
could be combined with an IP address and/or process ID. The session
identifier is currently used in the FilePlugin to help identify stale
file handles, but the intent is to provide an identifier that more or
less represents the current invocation of the VM along with the image
that is was loaded from the image file.

The value is obtained from Interpreter>>getThisSessionID.  Have
a look at the file plugin, or if you have OSProcess loaded, do
"OSProcess accessor getSessionIdentifier" to find its current value.
Using the Squeak sessionIdentifier combined with a process ID is
probably a good combination, although for any practical implementation
that is likely to occur in the next 20 years or so, the sessionIdentifier
is probably sufficient.

Better yet would be to just treat the Squeak session identifier as
a hopefully-unique ByteArray of unknown length. Currently it will
just happen to be an array of 4 bytes on a 32 bit machine, or 8
bytes on a 64 byte machine, but in some future Universe (sic) it
might be be 128 bytes of impossibly obfuscated data.

With respect to the original security question, the sessionIdentifier
is visible in the image, hence inherently insecure. As others have
pointed out, if you want an identifier that will not be visible
to some other invocation of the image file, you simply cannot
make it visible in the image at all.

Dave

p.s. "secure squeak" sounds like an oxymoron to me.




More information about the Squeak-dev mailing list