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

[Timothy <tecosaur@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 6101 bytes --]

Hi  Tim,

Thanks for the way in which you’ve responded to my comments. I appreciate the
effort you’ve gone to to explain your views as opposed to simply saying you
disagree with some of my current thoughts :)

Tim Cross <theophilusx@gmail.com> writes:

> My suggestion is simply to look at the value and if it is not a string, reject
> it outright. […] This is not a change in org-babel-parse-arguments,
> but rather a change in how we interpret those arguments.

Ah I see, I did not think you were suggesting this. I’m quite wary of this as it
would break all current `:tangle-mode (identity #oXYZ)' headers, which as I
understand it are /the/ way tangle-mode has been previously set.

Perhaps this is a good argument for deprecation? I think we’d need to give a
decently long transition period though (a few years).

> Allowing base 10 mode specifications is just a bad idea. The fact it has been
> permitted in the past is likely just an oversight rather than intentional
> behaviour.

I think we are of the same mind regarding base10 permissions specifications
being bad, but are niggling over what to do about this.

> Given the potential security issues involved
> here, I think we can legitimately obsolete such features (using
> acceptable change management approaches with suitable notification for
> users etc).

I’m certainly open to deprecation, though I’d like to hear from some of the
other “main Org people” (e.g. Bastien, Nicolas) before doing anything along
these lines. Perhaps this would be worth making a second thread for?

> I understand your motivation. I dispute your claim it is an established
> and common convention.

Ok, cool. Since we should have a while till the next Org release, nothing is set
in stone yet and hopefully this will give us time to see if the ls -l format is
fit for purpose or not. I think it will be, but correctness is of course more
important than niceness.

>> [sticky bits and the ls -l format]
>
> This is very difficult Timothy. I really do appreciate all the work you
> have done here and your patience, which makes what I’m going to say all
> the more difficult. My big concern here is that you don’t understand
> this area with sufficient depth of understanding to really appreciate
> some of the subtleties involved here. This makes me concerned that any
> implementation of a new way to specify mode settings may have some
> unexpected side effects or hidden issues which could be exploited in
> unexpected ways (worse case) or simply have unexpected bugs which result
> in mode settings which are not what the user intended. As someone who
> has used Unix since 1980 and Linux since 1995, I’ve experienced my share
> of issues relating to file modes and their interaction with different
> filesystems, NFS, different platforms, character sets, locales etc.
> Implementing a new approach as you are proposing is something I would be
> extremely wary about.
>
> If you do plan to go forward with this approach, please ensure you are
> very confident in your understanding of the sticky bit, setuid/setgid
> and associated interaction with execute etc.

Thanks for explaining your position thoroughly here. I don’t need any convincing
that a solid understanding is necessary for a good implementation. I had a quick
peek and estimated the time I’d need to properly come to terms with sticky bits —
hence my estimate of a few days before I look at implementing this.

> I suspect you do have the skills to implement correctly given sufficient
> time, testing and motivation. However, I am concerned your initial stab
> at this may be somewhat naive and requires more consideration. My main
> concern is that once you take all the subtleties into consideration, the
> complexity of your ls -l approach will exceed its utility and
> maintainability. I could also be completely wrong.

I’ll let you (/the ML) know when I’ve taken a look at stiky bits, and whether I
think I’m able to create something that works. My intuition is that if ls -l can
properly represent sticky bits (and my rudimentary understanding is that it can)
it should be fine for specifying them too. We’ll see.

> Choice is good. However, as I mentioned in a previous post, the problem
> with choice is complexity and the biggest source of security problems is
> complexity. Keep in mind that what you do now is something which will
> need to be maintained by others in the future. It needs to be clear,
> concise and as simple as possible (but of course, no simpler!).

I like to think that the current implementation is fairly short and clean. If I
can’t add sticky bits “nicely”, I’ll reconsider things.

> Consider this simple scenario. The tangled output is being written to a
> directory which requires specific permissions for security reasons -
> perhaps it is some type of ftp server where permissions will determine
> what can be seen by whom. The data might contain sensitive information.
> The user specifies what they thing is the correct mode specification,
> but the7y get it wrong. Org comes along and looks at what they specified
> and decides it cannot interpret what the user has specified, so applies
> a default (and potentially completely wrong) mode, exposing sensitive
> data to others who should not have had access.
>
> Use a default if the user does not specify a mode, but if they specify a
> mode and org cannot interpret what they specified, then do nothing -
> don’t generate the tangled output at all. This is the only safe
> approach.

Thanks for the example. This sounds reasonable to me, and has prompted me to
test what’s actually happening at the moment.

Seems like the user-error I raise actually causes the tangling for that file
/and all subsequent files/ to fail, i.e. no content is written. It looks like we
actually want to loosen the current behaviour :P

Alright, that’s it for now. You can expect an update in a few days on sticky
bits.

All the best,
Timothy