[tahoe-dev] [tahoe-lafs] #958: LAFS 301 Moved Permanently

[tahoe-lafs]

#958: LAFS 301 Moved Permanently
------------------------------+---------------------------------------------
     Reporter:  zooko         |       Owner:                                                                                                                            
         Type:  enhancement   |      Status:  new                                                                                                                       
     Priority:  major         |   Milestone:  soon                                                                                                                      
    Component:  code-mutable  |     Version:  1.6.0                                                                                                                     
   Resolution:                |    Keywords:  forward-compatibility backward-compatibility integrity newcaps newurls http sftp ftpd smb availability security revocation
Launchpad Bug:                |  
------------------------------+---------------------------------------------

Comment (by davidsarah):

 Replying to [comment:15 zooko]:
 > Hm, would it be okay to allow people to set an HTTP 301 to a different
 cap of a different ''type'', such as a read-write cap instead of a read-
 only cap or a read-only cap instead of a read-write cap?

 Allowing redirection of a read-write cap to a read-only cap seems harmless
 and useful.

 (More precisely: as long as we have API slots that can accept either a
 read-write cap or a read-only cap, we should accept rw-redirecting-to-ro
 in those slots. There's an argument for having more strictly typed APIs,
 for which read operations reject write caps, in order to catch inadvertent
 grants of excess authority; but that's orthogonal to redirection.)

 > Our tradition of transitive attenuation of authority suggests that we
 should forbid this, which means that a client which is ''following'' an
 HTTP 301 redirect should remember whatever the attenuation of the original
 cap was (i.e. if it was read-only or ''???'' if it was a verify-only cap)
 and refuse to use the new cap with authority outside of that.

 +1 (for forbidding redirection of read-only caps to read-write caps).

 This should also apply to verify-only caps in the contexts in which they
 can be used, e.g.  {{{?t=info}}}, checker APIs, etc.

-- 
Ticket URL: <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/958#comment:16>
tahoe-lafs <http://tahoe-lafs.org>
secure decentralized storage