Allow all CLI commands to take arguments from stdin or a file, to avoid caps being visible to other local users

[davidsarah]

From code:docs/known_issues.txt :

command-line arguments are leaked to other local users

Remember that command-line arguments are visible to other users (through the ps command, or the windows Process Explorer tool), so if you are using a Tahoe-LAFS node on a shared host, other users on that host will be able to see (and copy) any caps that you pass as command-line arguments. This includes directory caps that you set up with the "tahoe add-alias" command. Use "tahoe create-alias" for that purpose instead.

how to manage it

Bypass add-alias and edit the NODEDIR/private/aliases file directly, [...] By entering the dircap through the editor, the command-line arguments are bypassed, and other users will not be able to see them. [...]

Starting in Tahoe-LAFS v1.3.0, there is a "tahoe create-alias" command that does this for you.

This workaround using aliases is ugly -- adding a persistent alias for an argument that might only be used once has poor usability, leaving around aliases may constitute a privacy issue, and firing up an editor is quite a heavyweight solution.

Proposed feature: if a CLI command sees an argument of the form "@filename", then it substitutes the contents of that file into the command arguments in place of "@filename" (taking newlines as argument separators). "@" on its own does the same thing for standard input. If the file cannot be read then the command fails with no effect.

(In other words, @filename works similarly to the Unix shell syntax `cat filename`, except that the latter wouldn't solve the problem because it passes the file contents via the command line.)

The syntax @filename is chosen because it seems to be a semi-convention, at least in developer tools (e.g. MSVC++, javac, javadoc use it), and because @ does not need to be quoted on either Unix or Windows.

[davidsarah]

This is an enhancement to Tahoe; the defect is in the OS :-)

[davidsarah]

Incidentally, another reason to support this is so that you don't have to remember the ridiculously complicated (and just plain ridiculous, in many ways) shell quoting and glob-expansion rules:

• ​http://www.mpi-inf.mpg.de/~uwe/lehre/unixffb/quoting-guide.html
• ​http://www.dwheeler.com/essays/fixing-unix-linux-filenames.html

[azazel]

I do not find the alias usage ugly as you just have to create an alias for the root of the tree that you want to use. After that, you can use standard slashes "addressing". By the way, it would be useful to have the arguments and options for a command to be read from a file, but i would rather use a more "normal" way of specifying it like a -c or -f option followed by a file path, and where the specified file contains options and arguments in INI or dict like syntax. I would prefer for the stdin to be used for data, rather than options or arguments:-). In any case a "-" seems a more standardized way of specifying it in unix world.

[azazel]

Replying to azazel:

where the specified file contains options and arguments in INI or dict like syntax.

of course there is no need of using another syntax, a file containing just a line filled with command line options and arguments can be good enough, even if not so comfortable when there are many long arguments

[davidsarah]

We're going to have to agree to differ about it being ugly to have to use aliases as a workaround for leakage of caps on command lines. To me, aliases are similar to variables in a programming language -- it's fine to create an alias/variable for something that will be referred to several times, or even twice, but you don't typically create a variable for every subexpression that is only used once. (Yes, I know there can be exceptions to that.) If a language or UI requires that, then it's imposing unnecessary mental overhead in forcing a programmer or user to choose temporary names.

When caps become short enough to fit on a single line, so that they are more easily cut-and-pasteable, and are real URIs (#432 and other tickets listed there), this is likely to become more important in practice. For example, say that I receive a Tahoe directory URI in an encrypted email, and want to copy the contents to a local tree. I should be able to just do tahoe cp -r @ dest and then paste in the URI, without having to set up an alias that I may never refer to again. (If I did want to refer to it again, I'd go back to the email.)

The @ syntax is preferable precisely because it isn't an option argument -- it's metasyntax that gets substituted before any arguments have been parsed -- and therefore it shouldn't look like an option argument. For instance, I think the syntax tahoe cp -r @ dest}} in the example above is less weird and easier to remember than {{{tahoe cp -r -f - dest, which looks as though -f has the same status as other options like -r, rather than -f - being a substitution.

@ is also something that you could imagine becoming a more widely-used convention, whereas any option-like syntax would inevitably clash with other options and so could never become a convention.

Replying to azazel:

of course there is no need of using another syntax, a file containing just a line filled with command line options and arguments can be good enough, even if not so comfortable when there are many long arguments

Given that arguments could be on separate lines (LF or CRLF would be equivalent to an argument separator), I don't think long arguments are a particular problem.

[daira]

"@" has unfortunately been used up for a different purpose by [3798d9946e1f62cc7b9b83c641f6f0eb21864a2c/trunk].

I suggest "!" instead, because it is not a shell metacharacter for either Windows cmd.exe or most Unix shells (outside []).