[cosmo-dev] options to fix security hole

[Katie Capps Parlante]

Hi Randy,

My understanding from Grant is that the desktop work is something we can 
reasonably sign up for. Grant, is there any reason *not* to put it at 
the top of the desktop queue? Can we get a rough estimate of how long it 
will take? Randy, is Grant dependent on any server work in terms of 
timing his work?

I don't think we can take an approach where we don't allow items to be 
added to multiple collections until people upgrade -- people are using 
this feature rather heavily. (Or perhaps I'm misunderstanding the 
proposal for handling the interim situation). I think failing silently 
for the odd read-only item in a collection shared read-write is a 
reasonable approach for older clients.

Cheers,
Katie

Randy Letness wrote:
> Ok heres what I have working so far:
> i
> 1. Randy uses Chandler to publish collection A with item x
> 2. Randy shares collection A with Travis using read-write ticket T1
> 3. Travis subscribes to A using T1
> 4. Travis adds item x to his collection B
> 5. Travis syncs B, item x gets added to b read-only (because there is no 
> way for Chandler to include T1 in the morse code request)
> 6. Travis updates item x, syncs B (since x is read-only in B, server 
> silently ignores the update and proceeds as normal)
> 7. Travis syncs A (item x gets updated because x is editable in shared 
> collection A).
> 
> The key points here are 5,6, and 7, which allow the current desktop to 
> function as is with no security hole.  But this won't work for all 
> cases.  Consider:
> 
> 1. Randy uses Chandler to publish collection A with item x
> 2. Randy shares collection A with Travis using read-write ticket T1
> 3. Travis subscribes to A using T1
> 4. Travis adds item x to his collection B
> 5. Travis syncs B, item x gets added to B read-only (because there is no 
> way for Chandler to include T1 in the morse code request)
> 6. Travis shares B read-write to Jeffrey using read-write ticket T2
> 7. Jeffrey subscribes to B  using T2
> 8. Jeffrey attempts to update item x in shared collection B...server 
> fails silently because item is read-only and the update is essentially lost
> 
> So it seems like we really do need a way for the desktop to include 
> associated read-write tickets in a morse-code publish/update request.  
> This could be as simple as going through each item in the collection and 
> pulling out the "ticket=blah" from each collection url and including 
> these tickets in the morse code request.  Grant and Jeffrey, how much 
> work would this be?  What kind of impact would this have on existing 
> clients?  Do we not allow items to be added to multiple collections  
> until users upgrade or do we do the read-only thing as described above?
> 
> -Randy
> 
> _______________________________________________
> cosmo-dev mailing list
> cosmo-dev at lists.osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev