Re: [PATCH] Accept more :tangle-mode specification forms

[Tim Cross <theophilusx@gmail.com>]

Timothy <tecosaur@gmail.com> writes:

> Hi All,
>
> I thought I’d checked for this, but I’ve just noticed that :tangle-mode 755
> doesn’t actually work as expected. I assumed 755 would be passed as a string but
> org-babel-parse-header-arguments actually turns it into an integer, just like
> (identity #o755). Obviously 755 != #o755 and so this causes issues.
>
> As it stands “755” works, but that isn’t great (most importantly, it’s easy to
> confuse). Since it’s easier to add than remove things like this, we could just
> get rid of this for now, but a convenient octal notation was a large chunk of
> the motivation here IIRC.
>
> We could also change the implementation to handle :tangle-mode o755, which will
> make org-babel-parse-header-arguments parse the argument as a string.
>
> I’m be keen to hear other people’s thoughts on this.
>

Thanks for your work on this. I am a little concerned we are making a
rod for our back by trying to make this overly clever in order to
provide as much convenience to the user as possible. As this setting
does have significant security implications, I would favour a simple and
easily testable option which is concise and unambiguous over
convenience. I would drop the 'rwxrw-r--' format as it isn't typical,
not allow base10 mode specifications and possibly even limit what
can be set (i.e. no sticky bit etc, just read, write and execute).

Security issues are more often than not, caused by complexity. Things
become complex when we try to satisfy too many options. In this case,
rather than being liberal in what we accept and precise in what we
send/do, I think we need to be precise in what we accept and do.

I would just accept two formats, both being strings with either "o400"
(or perhaps "#o400") and "u+rwx" symbolic form and anything else
generates an error (a hard error, not a warning i.e. stop processing,
don't tangle). 
 
Making the octal version be "#o600" rather than just "o600" would
possibly make interpretation easier as it would avoid "o600" and "o+r" -
if it starts with "#o" interpret as octal, otherwise try to parse as
symbolic names.

this would mean there will be some edge cases where you cannot set the
mode precisely to the value you want. However, these will be fringe
cases and requiring the user to take additional/special steps in this
case is IMO not too much to ask in exchange for reliability and
correctness for the majority and avoiding dangerous corner cases.