mikesamuel at gmail.com
Mon Dec 21 08:51:05 PST 2009
2009/12/21 Mark Seaborn <mseaborn at google.com>:
> On Tue, Dec 15, 2009 at 12:04 AM, Mike Samuel <mikesamuel at gmail.com> wrote:
>> 2009/12/14 Ash Berlin <ash_js at firemirror.com>:
>> > If you haven't yet read http://www.python.org/dev/peps/pep-3101/ (Advanced String Formatting) I
>> I have not read it. Thanks for the link. It has a good summary of
>> alternate syntaxes and establishes a point partway between positional
>> and inline syntax. It does include a bunch of format specifiers that
>> I think incompatible with DSL schemes.
> Python 2.6/3.0's new format() method lets you put attribute accesses
> inline in the format string, e.g.
> This is problematic for secure subsets of Python such as CapPython
> that try to restrict attribute access . There might be similar
> problems for secure subsets of ES if something like Python 3.0's
> scheme were adopted in ES.
So python's format() method is not statically analyzable since it
turns strings into code, though in a more limited way than either
python's or ecmascript's eval.
> Apparently the Python developers weren't aware of quasi-literals -- or
> at least quasi-literals weren't proposed -- so they weren't
> It seems to me that if you really want attribute accesses inline in
> the format string, it's better to have these attribute accesses as
> real expressions -- as quasi-literals allow -- rather than inventing a
> new mini-language for them as Python 3.0 format strings did.
For the quasi proposal, since the semantics are specified in terms of
a desugaring, any kind of security by analysis that holds on the
desugared form should also hold with syntactic sugar.
So any analysis that holds for
should also hold for
and the quasi proposal does not suffer from the third-party format
string problem that python suffers from.
Do the assertions about static analysis under "security
considerations" make sense to you?
>  http://lackingrhoticity.blogspot.com/2008/09/attribute-access-in-format-strings-in.html
> es-discuss mailing list
> es-discuss at mozilla.org
More information about the es-discuss