[cosmo-dev] options to fix security hole

Grant Baillie grant at osafoundation.org
Tue Feb 12 17:07:11 PST 2008


On 12 Feb, 2008, at 07:23, Randy Letness wrote:

> Katie Capps Parlante wrote:
>> 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 can't think of a reason not to ... I'll clear out some of my other  
work today, and will start on this tomorrow. Getting the code written  
and tested should take at most a couple of days; in total, as a much  
as a week of my time might go down the tubes if weird things start  
happening with people's shares ;).

> The client work boils down to including some extra data (tickets) as  
> a header in the request.  We just need to agree on the format and we  
> should be set.

Would just specifying multiple Ticket: headers 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.
>
> Just to be clear, if we still allow older clients to add items to  
> multiple collections, those items will be read-only in all  
> collections that aren't owned by the user.  Failing silently for the  
> desktop should be ok, but we still need a story for what happens to  
> updates of these items through the webui.  Failing silently doesn't  
> work as well since the webui updates a single collection.  These  
> items will essentially be read-only in the webui when updated  
> through the second collection, but the webui has no way of knowing  
> this.  Should we add in some error handling code to detect this and  
> give the user a somewhat nice message?

That seems like a reasonable thing to do.

--Grant




More information about the cosmo-dev mailing list