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-boun...@lists.berlios.de [mailto:opensim-dev- >> boun...@lists.berlios.de] On Behalf Of Melanie >> Sent: Monday, 16 February 2009 4:45 AM >> To: opensim-dev@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.laukka...@gmail.com >> > To: mma...@gmail.com >> > CC: opensim-dev@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 <mma...@gmail.com> wrote: >> > >> > Hi, >> > >> > On Sat, Feb 14, 2009 at 4:05 PM, Tommi Laukkanen >> > >> > <tommi.s.e.laukka...@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@lists.berlios.de >> > https://lists.berlios.de/mailman/listinfo/opensim-dev >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev@lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev > _______________________________________________ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > > _______________________________________________ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev