Discuss: remove support for Leo's path expressions

[Edward K. Ream]

#3260 suggests removing support for Leo's path expressions by removing all calls to c.expand_path_expression in Leo's core and plugins. My reasons:

1. Path expressions are a serious security concern.

2. Path expressions are not necessary. There are easy workarounds.

3. vs-code will never allow such expressions. leoJS can not possibly ever support them.

Note: c.expand_path_expression  will still exist should someone need it.

Your comments, please.

Edward

[Thomas Passin]

I'm a little conflicted about this suggestion.  I haven't used path expressions much, but I did experiment with using them to work on both Linux and Windows, where the difference was more than just the meaning of "~".  By "work", I mean that the same outline could be moved between Linux and Windows and the external files could be found.  That's helpful for me because I use so many Linux VMs, and I can't make many of the external files work between Linux and Windows.  One obstacle to my using them more is that they are not very readable.

There's no need to use {{sep}}-style steps because Leo wants to see forward slashes in headlines and converts them as needed when running on Windows.

With regard to #2, I'd like to know an easy workaround for @file c:\Tom\devel\leo\some-file.py  on Windows but, say, @file ~/Leo/outlines/some-file.py.  I don't want to hear how I should be using some other directory structure on Windows.  My drive organization has some 30 years of history behind it, going back to Windows 95,  and I don't plan to change it all now.  If I had the experience then that I have now I would probably have done it differently.  Not that I have many external files with adaptable file paths, but at least it can be done.

One time this became a practical matter was a period of about 10 days when I had to do without my Windows laptop.  It seemed to be having memory problems.  I went to my backup machine - it ran Linux - moved my Thunderbird email files over and some key Leo outlines.  The email worked great, but I had to be careful about handling external files I cared about and wanted to work on.  Of course I had backed up the laptop.

[Félix]

I just checked the path expressions in Leo's docs. Pretty cool feature i didn't even know existed.

That being said, I don't see why vscode would not allow me to evaluate parts of those strings as expected by this feature, as I already have support of scripting , including offereing g, c, p etc. available in the scope of the running scripts.

So personally, I'd leave that good stuff in! :) 

Félix

On Friday, April 7, 2023 at 5:55:26 PM UTC-4 Edward K. Ream wrote:

[Thomas Passin]

I was thinking the same.  After all, leointeg or leojs could parse headlines and do something with the results.   What might  make sense - both for security and for both Leo and leojs - would be to write a small number of methods that would be the only ones that could be used in path expressions.  This would be safer than letting path expressions execute arbitrary code.

[jkn]

I haven't looked at c.expand_path_expression, at least recently - it may be too capable for its own good. But I would definitely want a way to navigate to a given file under different environments, similar to Tom's example.

I could live with the headline having to be changed to accommodate a new syntax. As he mentions I would expect '/' to be workable everywhere, for example.

Regards, J^n

[Edward K. Ream]

On Fri, Apr 7, 2023 at 8:28 PM Thomas Passin <tbp1...@gmail.com> wrote:

I'd like to know an easy workaround for @file c:\Tom\devel\leo\some-file.py  on Windows but, say, @file ~/Leo/outlines/some-file.py. 

Create an @button node that adjusts your @file nodes.

Edward

[Edward K. Ream]

On Fri, Apr 7, 2023 at 8:29 PM Félix <felix...@gmail.com> wrote:

I don't see why vscode would not allow me to evaluate parts of those strings as expected by this feature, as I already have support of scripting , including offereing g, c, p etc. available in the scope of the running scripts.

Many years ago Paul Patternson convinced me (and all of Leo's other devs) that we must not allow Leo to execute arbitrary scripts when loading a .leo file. So:

1. leoSettings.leo contains: @bool scripting-at-script-nodes = False

2. Leo allows setting this setting to True only in myLeoSettings.leo.

I called this policy the "Lock on the H-Bomb".

Without this policy, opening any .leo file from someone else exposes the user to malicious code in @script nodes.

Even with this policy, one should be wary of pushing any @button button in an outline created by someone you don't trust. Ditto for executing any command created by @command.

In short, .leo files are potential viruses that virus scanners will never find.

Imo, the security implications of @script, @button and @command are Leo's biggest unresolvable problem.

Path expressions bypass the lock on the H-Bomb. It's no good requiring a new lock, as a few minutes thought should convince you.

Edward

[Edward K. Ream]

On Fri, Apr 7, 2023 at 9:10 PM Thomas Passin <tbp1...@gmail.com> wrote:

I was thinking the same.  After all, leointeg or leojs could parse headlines and do something with the results.   What might  make sense - both for security and for both Leo and leojs - would be to write a small number of methods that would be the only ones that could be used in path expressions.  This would be safer than letting path expressions execute arbitrary code.

Thanks, Thomas. This is an excellent idea.

Edward

[Edward K. Ream]

On Sat, Apr 8, 2023 at 5:33 AM jkn <jkn...@nicorp.f9.co.uk> wrote:

I haven't looked at c.expand_path_expression, at least recently - it may be too capable for its own good. But I would definitely want a way to navigate to a given file under different environments, similar to Tom's example.

I could live with the headline having to be changed to accommodate a new syntax. As he mentions I would expect '/' to be workable everywhere, for example.

Thanks for your comment. I'm convinced that safe path expressions should continue to exist.

Edward