There is likely a way to make the __NEXT_PLACEHOLDER functionality safe and
accessible without have scripting abbreviations enabled. Terry would know
the best plan forward.
On Saturday, November 14, 2015 at 8:48:52 AM UTC-5, Kent Tenney wrote:
>
> with
> @bool scripting-abbreviations = False
> and
> ,,={|{x='__NEXT_PLACEHOLDER'}|}
>
> in @data abbreviations
>
> my abbrev prints
> width="width" height="<|height|>"
>
> width is selected. I enter 200 for width, then double comma and get
>
> width="200{|{x='__NEXT_PLACEHOLDER'}|}" height="height"
>
> So it seems to me that next placeholder depends on
> scripting-abbreviations=True
>
> declaring
> @string next-placeholder-abbrev = ,,
>
> with scripting turned off didn't work for me
>
> Since scripting-abbreviations is the security risk, I was wondering if the
> next-field capability could be implemented without scripting-abbreviations
> being active.
>
> That would provide rich abbreviations without having to cross the
> line to full scripting.
>
> Hope that makes sense.
>
>
>
> On Fri, Nov 13, 2015 at 1:06 PM, Edward K. Ream <[email protected]
> <javascript:>> wrote:
> > On Fri, Nov 13, 2015 at 12:33 PM, Kent Tenney <[email protected]
> <javascript:>> wrote:
> >>
> >> Terry's suggestion of substitution only, no code sounds doable.
> >> Would it be possible to provide next-field by some means
> >> other than via code-running?
> >
> >
> > I'm not sure I understand this question :-)
> >
> > Leo's (static) abbreviation code is in: leoPy.leo#Code-->
> > Command classes-->@file ../commands/abbrevCommands.py-->
> > abbrev.expandAbbrev & helpers (entry point)
> >
> > This is complicated code, but the code that does next-field is not
> likely to
> > be a security concern. Afaik, the only security concern are:
> >
> > 1. scripting abbreviations such as:
> >
> > date;;={|{import time ; x=time.asctime()}|}
> >
> > 2. The code in @data abbreviations-subst-env nodes.
> >
> > As has been said, a case can be made for default locks on scripting,
> > although Leo's scripting capabilities are powerful enough that people
> must
> > take care when using .leo files that are not their own. You had better
> look
> > twice at the code for an @button node that says "push me".
> >
> > Imo, the only real "security" is knowing who it is that has given you a
> .leo
> > file. In many cases, the github id is enough to identify the person
> > responsible for code. But you are asking for big big trouble if you use
> an
> > "untrusted" .leo file.
> >
> > BTW, Leo already has a lock that prevents a .leo file from enabling
> @script
> > nodes. unitTest.leo prints the following on entry:
> >
> > Security warning! Ignoring...
> > @bool scripting-at-script-nodes = True
> >
> > Imo, this is the minimum required. I suspect that abbreviation settings
> are
> > honored in regular .leo files, so there could be a concern if, say, ",,"
> > were replaced by a regular character. But once again, @button nodes
> would
> > be a very easy way to cause execution of malicious code.
> >
> > EKR
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups
> > "leo-editor" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an
> > email to [email protected] <javascript:>.
> > To post to this group, send email to [email protected]
> <javascript:>.
> > Visit this group at http://groups.google.com/group/leo-editor.
> > For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
