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

[Melanie]

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
> 
>