[Opensim-dev] Proposal to eliminate the name, description and invType fields from the assets db

Sun Jun 22 18:07:21 UTC 2008

Ohh. Very good and valid point. Hadn't thought about that.

Then again, on the whole, the OpenSim structure as it stands right now is just a big fat vulnerability. It's a bit weird that we're using guids as just that, guids. All ids should be region-and-client contextual, and hence not guids at all.
Of course, any entity can retain (gu)ids internally, within its own trust sphere, and entities can share references based on exposed id's, but the moment you start overwriting resource  id's, you're in deep water.

We have already seen a couple of bugs illustrating this (mostly concerning load/save xml and Guid.Empty) - just hink what could be done maliciously...

Ok, being criminally short and vague here, but feel free to start debate. ;-)
Best regards,Stefan AnderssonTribal Media AB Join the 3d web revolution : http://tribalnet.se/ 

> Date: Sat, 21 Jun 2008 21:41:33 -0400> From: adam at deepthink.com.au> To: opensim-dev at lists.berlios.de> Subject: Re: [Opensim-dev] Proposal to eliminate the name, description and invType fields from the assets db table> > Snip:> ---> ...Moreover, if we adopt generation of UUIDs using a hashing algorithm> (e.g. SHA1) at some stage, we wouldn't even need to embed the UUID in> the name...> ---> Unsnip:> > A warning here if I may.> > *DO NOT DO THIS*. Hashing to produce a UUID for the asset, while> tempting in a space-saving kind of way, actually is not secure. Allow me> to explain further:> > There are many known attacks on MD5 (and SHA1) which allow a duplicate> hash to be produced by tacking on additional data at the end of your> intended data, so - say someone wants to replace the default avatar with> a flying phallus, it would be possible to do, by creating a specifically> targeted asset with some dummy data on the very end to produce a> duplicate hash. When uploaded, it would override the original UUID of> that asset and hence could be bad.> > If you *really* want to produce hashes in this way, use additional> length hashes which have yet to be easily collided with. If using SHA, I> recommend using at least 256 bit, ideally 512. This however does> increase the size of the key and hence slow down searches. It is also> recommended that it be easily possible to substitute the hashing> algorithm with a improved one later on - since these kinds of attacks> are ever evolving.> > Regards,> > Adam> > > > -----Original Message-----> From: opensim-dev-bounces at lists.berlios.de> [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Justin> Clark-Casey> Sent: Saturday, 21 June 2008 6:35 PM> To: opensim-dev at lists.berlios.de> Subject: [Opensim-dev] Proposal to eliminate the name, description and> invType fields from the assets db table> > This is mainly a question for core developers, though other viewpoints > are welcomed.> > In the OpenSim assets database table currently there are eight fields> > +-------------+-------------+------+-----+---------+-------+> | Field | Type | Null | Key | Default | Extra |> +-------------+-------------+------+-----+---------+-------+> | name | varchar(64) | NO | | | |> | description | varchar(64) | NO | | | |> | assetType | tinyint(4) | NO | | | |> | invType | tinyint(4) | NO | | | |> | local | tinyint(1) | NO | | | |> | temporary | tinyint(1) | NO | | | |> | data | longblob | NO | | | |> | id | varchar(36) | NO | PRI | | |> +-------------+-------------+------+-----+---------+-------+> > Of these, name, description and invType are not really used by OpenSim > (there are a couple of places in the code that use invType, but these > could easily use other data sources). Name and description are a little> > pointless for assets - the real names and descriptions are actually > always kept in the inventory items which reference these assets. > InvType is also information which is always duplicated in items.> > Eliminating these fields would have the following advantages> > 1. Make it easier to save and load and integrate assets with locations > outside OpenSim. If you don't need to maintain name, description or > invType, it should be possible to save assets with the uuid embedded in > the filename and an extension which shows the asset type (e.g. .jp2 for > JPEG2000 textures). The assets wouldn't require persistence of the > local and temporary attributes.> > Two immediate use cases are that elimination of these asset fields would> > make the creation and manipulation of archives and inventory libraries> > much simpler. There may also be integration benefits. For instance, > asset data files could be served directly by a stock webserver without > having to wrap them in XML to provide the extra metadata). Moreover, if> > we adopt generation of UUIDs using a hashing algorithm (e.g. SHA1) at > some stage, we wouldn't even need to embed the UUID in the name.> > 2. Eliminate the code which maintains these fields, simplifying the > codebase and making it easier to read. This is a minor point, since the> > amount of code isn't large.> > 3. Reduce data storage requirements. This is also a minor point, since> > these fields will always be dwarfed by the blobs (although this might > come into play much further down the line if blobs are moved out of the> db).> > The one disadvantage I can think of is> > 1. It becomes a little hard to get a sense of what's in your asset > database by just browsing the assets table. For instance, you get a > rough sense of how many objects are in prim or avatar inventories by > counting the number of times that 'Primitive' appears as a name... > However, statistical information could still be derived (if desired) by > analysing the type field.> > In summary, I would like to see if the name, description and invType > asset table fields can be removed at some point in the near future. > Does anybody have a good or necessary reason to retain them?> > -- > justincc> Justin Clark-Casey> http://justincc.wordpress.com> _______________________________________________> Opensim-dev mailing list> Opensim-dev at lists.berlios.de> https://lists.berlios.de/mailman/listinfo/opensim-dev> _______________________________________________> Opensim-dev mailing list> Opensim-dev at lists.berlios.de> https://lists.berlios.de/mailman/listinfo/opensim-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20080622/b01cf8fb/attachment-0001.html>