Timothy <tecos...@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.