
<html>

<head>

<style>

.hmmessage P

{

margin:0px;

padding:0px

}

body.hmmessage

{

font-size: 10pt;

font-family:Verdana

}

</style>

</head>

<body class='hmmessage'>

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

</html>