No subject

On Thu, July 17, 2008 00:51, Brian Warner wrote:
> On Sat, 12 Jul 2008 21:29:30 -0700
> Aleksandr Milewski <zandr at allmydata.com> wrote:
>
>> A pragmatic $0.02.
>>
>> We should allow a mechanism to keep caps off the commandline. We should
>> also allow them, because they're convenient and the process table leak
>> is
>> not always a concern.
>>
>> If we do allow caps on the commandline, we should rewrite argv to reduce
>> the window where the leak occurs.
>
> I agree. Being able to do 'tahoe get CAP' is awfully handy, and none of
> the
> unix boxes that I use are shared with people I don't trust. The debate
> reminds me a little bit of the argument against putting caps in URLs:
> various
> browser bugs and misfeatures make it difficult to keep URLs secret, so
> let's
> come up with weird workarounds to hide or mangle the URLs.
>
> Here's what I think we should do:
>
>  * add an --interactive option to 'tahoe add-alias', which causes it to
>    accept the cap on stdin, after asking a question

A very good , solid and 'real' solution IMHO.

> (or maybe just use
> 'tahoe
>    add-alias ALIASNAME -', as a relatively well-known convention for "get
>    this thing from stdin"). Users who share a unix box with adversaries
> can
>    use it.

Not as good as the first solution, but if you can't have 'least' authority
having 'less' authority is not all that bad.


>  * maybe have 'tahoe get', etc, rewrite their argv to reduce the window of
>    vulnerability.
>  * fix #174 (which is about rewriting argv of 'tahoe start' to at least
>    mention the directory in which the node is running)



For these two, I learned this lessen the hard way that having a race
condition means having an expoitable race condition. Don't spent precious
development time or recources and/or add complexity to your program to
'reduce the window', it is simply not woth it IMHO.


Rob J Meijer