[Opensim-dev] Please do not revert fixes without careful comtemplation

Mon Feb 16 13:21:09 UTC 2009

Hence the 'full binary compare'.

Best regards,
Stefan Andersson
Tribal Media AB

> Date: Mon, 16 Feb 2009 13:25:31 +0000
> From: melanie at t-data.com
> To: opensim-dev at lists.berlios.de
> Subject: Re: [Opensim-dev] Please do not revert fixes without careful comtemplation
> 
> I see the potential of targeted MD5 collisions as a way to obtain 
> script sources.
> A saves a script.
> B creates a targeted collision, which will result in creation of an 
> inventory item refering to A. The data B saves is ignored because of 
> hash equality
> B then reopens the object and receives A's script source.
> 
> Melanie
> 
> 
> Frisby, Adam wrote:
> > You do realise you could just not update the asset. If the hash is the same, then you can just completely ignore the save/update request.
> > 
> > That being said, even a targeted collision on MD5 is a 2^58 chance, on SHA256 it's well over 2^128 which makes it pretty much impossible. Frankly it's not something worth concerning oneself over.
> > 
> > Adam
> > 
> >> -----Original Message-----
> >> From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-
> >> bounces at lists.berlios.de] On Behalf Of Melanie
> >> Sent: Monday, 16 February 2009 4:45 AM
> >> To: opensim-dev at lists.berlios.de
> >> Subject: Re: [Opensim-dev] Please do not revert fixes without careful
> >> comtemplation
> >>
> >> Again, I'd like to stress that I believe this is too dangerous to do
> >> for anything other than textures.
> >> It is also not really needed for things other than textures, since
> >> the other assets are comparatively small, textural data.
> >>
> >> I would not want to risk even the smallest chance of a hash
> >> collision on script source.
> >>
> >> Melanie
> >>
> >> Stefan Andersson wrote:
> >> > Coming in a bit from the side here,
> >> >
> >> >
> >> >
> >> > we have, for some time, discussed to separate out the binary blog out
> >> of the metadata for an entirely different reason, namely to be able to
> >> weed out binary duplicates.
> >> >
> >> >
> >> > If there was a way for us to separate out the binary parts, into
> >> something like 'binaryassetId, hashData[256], binarydata' and then just
> >> have the asset table referencing that row, I think it would help a lot.
> >> >
> >> >
> >> > I realize it's a separate discussion, just chipping in my two cents.
> >> >
> >> >
> >> > Best regards,
> >> > Stefan Andersson
> >> > Tribal Media AB
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > Date: Sat, 14 Feb 2009 17:49:22 +0200
> >> > From: tommi.s.e.laukkanen at gmail.com
> >> > To: mmazur at gmail.com
> >> > CC: opensim-dev at lists.berlios.de
> >> > Subject: Re: [Opensim-dev] Please do not revert fixes without careful
> >> comtemplation
> >> >
> >> >
> >> > Hello,
> >> >
> >> > On second though we could keep the current structure and expose all
> >> fields also through AssetBase properties. Then we could save / load the
> >> AssetBase with nhibernate as a single object and leave out the Metadata
> >> property from NHibernate mapping. Does this sound good?
> >> >
> >> > regards,
> >> > Tommi
> >> >
> >> >
> >> > On Sat, Feb 14, 2009 at 5:06 PM, Mike Mazur <mmazur at gmail.com> wrote:
> >> >
> >> > Hi,
> >> >
> >> > On Sat, Feb 14, 2009 at 4:05 PM, Tommi Laukkanen
> >> >
> >> > <tommi.s.e.laukkanen at gmail.com> wrote:
> >> >
> >> >> I was talking with mikkopa and he suggested we should create two
> >> tables to
> >> >> cover AssetBase to solve this issue properly. Namely AssetMetadata
> >> for
> >> >> metadata information and AssetData for blobs to avoid situation
> >> where we end
> >> >> up accessing also the blob data just to read metadata.
> >> >
> >> > I was hoping not to have to do that.
> >> >
> >> > It should be straightforward to support the current
> >> > AssetBase/AssetMetadata composition in the existing OpenSim data
> >> > layers, but as sdague warned me earlier, by mapping multiple classes
> >> > to one table I was entering a world of pain. Seems that's exactly
> >> > what's happening with NHibernate.
> >> >
> >> > The reason I introduced the AssetMetadata class is to supply metadata
> >> > information only for some requests that Cable Beach, the new asset
> >> > server, supports. Now I realize that this was probably a premature
> >> > optimization.
> >> >
> >> > Instead of modifying the DB schema, we could have AssetBase inherit
> >> > from AssetMetadata, as I outlined before[1]. Alternatively, we could
> >> > get rid of AssetMetadata altogether and store everything in AssetBase
> >> > as before, splitting out the metadata sometime in the future when a
> >> > use case warrants it.
> >> >
> >> > What do you think?
> >> >
> >> > Thanks,
> >> > Mike
> >> >
> >> >
> >> > [1] https://lists.berlios.de/pipermail/opensim-dev/2009-
> >> February/004918.html
> >> >
> >> >
> >> >
> >> >
> >> > ---------------------------------------------------------------------
> >> ---
> >> >
> >> > _______________________________________________
> >> > 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
> > _______________________________________________
> > 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/20090216/1d03696c/attachment-0001.html>