this is an attempt to summarise the feedback received from security
reviews by Love Hörnquist Åstrand, Sam Hartman and Jeffrey Hutzelman,
and with input from Alexey Melnikov.
the main (only) issue was the behaviour of length limits.
how does modifiers to SET interact with length limits? current
modifiers can't increase length.
variables which exceed implementation limits are silently
truncated when stored. there is no way for a script to discover
implementation limits and take appropriate action. among the
reviewers, there was consensus that at a minimum the security
aspects of this behaviour needs to be documented.
Well, the obvious security issue here is that a script that pulls data out of a
header and then tests it may be able to be bypassed by putting a bunch of
leading material in the header so truncation occurs and the test fails. This is
something of a stretch, however, given that most such tests can be bypassed
simply by omitting the data being tested for entirely.
I'm curious what other supposed security issues there are with truncation. I'm
also skeptical that this is as big a mountain as they seem to think - sure
seems more like a molehill to me.
an
alternative suggestion was to establish a namespace where such
implementation values can be looked up.
Alternative to what? In order for such information to be useful a script has to
be able to employ it meaningfully. So I find that there's an implementation
limit of foo. What do I do now? Code around it? If the limit can be coded
around without too much trouble why not code it that way for better portability
in the first place? Finding another implementation with a larger limit is
rarely an option... this really doesn't seem to accomplish much.
The only case I can imagine where this might be useful is when I know in
advance the length of the data I'm dealing with and want to check and see if it
can be processed. But the minimum maximums seem sufficient to cover this case,
so I'm left with this "alternative" in fact being no solution to any useful
problem.
It seems to me the useful alternative would be to have a way of testing to see
if truncation has occured. This way you could code tests to see if the
dataa being processed is abnormally large and respond accordingly.
But even this is of extremely marginal utility, for two reasons. First, string
sizes can already be checked, and it probably makes more sense to see if
something is abnormally long rather than checking to see if it has bumped up
against a truncation limit. Second, the availability of such a mechanism does
not mean it will actually be used, and my guess is that any such feature (and
this includes the namespace stuff) will see little if any actual use. And
rarely used features are security risks in and of themselves.
there were worries that other extensions would want some other
failure mode than "silent truncation" when such limits are
reached. I'd like to comment that the limit only concerns
storing a value, ie. is restricted to the action SET and the
implicit storage of match variables from tests. Sieve currently
has no specified limit to the static length of string or
multi-line, and it's unclear to me whether a conformant
implementation is allowed to impose such limits.
non-security objections:
Love Åstrand thinks restricting variable names to the English
alphabet is a real problem.
Funny, it doesn't seem to have exactly been a showstopper in a truly vast
number of programming languages. Absent specifics as to why this is a real
problem, IMO this should simply be ignored.
Jeffrey Hutzelman thinks a mechanism for quoting characters with
special meaning in regex should be available. this could be a
modifier for SET, e.g. :quoteregex.
This, OTOH, is IMO a good idea, although we need :quotematches more than we
need :quoteregex. I support adding this to the variables extension.
Implementation is only a few lines of code, and it can and will be used.
Jeffrey Hutzelman thinks the text regarding interaction with
regex should be in whichever of variables or regex is published
last, so that what is a normative reference isn't mislabeled as
informative.
I guess I have no problem with this, but then again I personally find a lot of
the tension and angst over reference classification to be overdone.
Ned