tosca-comment

That is all reasonable, but we’re narrowly talking about entity names (such as node templates, property names, requirement names, etc.), not the values for those entities. I agree that we can use TOSCA constraints for entity values, but we can’t do the same for entity names.

Chri

From: Tal Liron <tliron@redhat.com>
Sent: Sunday, March 8, 2020 6:39 PM
To: Chris Lauwers <lauwers@ubicity.com>
Cc: adam souzis <adam@onecommons.org>; tosca-comment@lists.oasis-open.org
Subject: Re: [tosca-comment] Feedback on TOSCA 1.3 spec

On Sun, Mar 8, 2020 at 8:18 PM Chris Lauwers <lauwers@ubicity.com<mailto:lauwers@ubicity.com>> wrote:
Problems I’ve dealt with in the past include non-legible characters being included accidentally in my YAML files by cutting and pasting. These are sometimes hard to track down.

Fair enough, but who gets to decide what is legible? The Unicode standard currently has 150 scripts, with more proposed. I doubt there is a living person that finds it all legible. And as for punctuation and non-orthographic symbols, well, they are certain legible and can sometimes have useful meanings. Even emojis can used to categorize node templates.

I think the best way to avoid mistakes is 1) to ensure strong, strict parsing at all levels, both YAML and TOSCA, and 2) create and use data types with appropriate constraints, e.g. if you only expect a >0 int then make sure to constrain, or if you're specifying a DNS hostname don't just let it be "string" but rather a pattern (regex) constraint that will protect against invalid names.

On Sun, Mar 8, 2020 at 8:45 PM Chris Lauwers <lauwers@ubicity.com> wrote:

> That is all reasonable, but we’re narrowly talking about entity names
> (such as node templates, property names, requirement names, etc.), not the
> values for those entities.
>

But these are also values that are often validated by the parser. E.g. if
you give a "bad" name to a requirement it should cause an error if it can't
be matched at the node type or node template.

I'm really confused as to where this is all going. Typos can happen
anywhere in any computer language, whether it's restricted to English's
[a-zA-Z] or all of Unicode.

I'm sorry Chris and Adam, but I think this issue is exhausted as far as I'm
concerned. I am trying to get from you some specific problem with the
current lack of restriction and have not heard anything that looks specific
to me. On the other hand, I've raised a few reasons why you would want to
keep it unrestricted -- visual IDEs, separation between design and runtime
elements, TOSCA generated from external systems, future uses that we don't
even know about, the arbitrariness of picking just any set of rules (XML?
why?) -- and have not gotten any arguments against them.

It's not about typos, it is about reducing implementation complexity and
mitigating about security flaws from malicious input. Unless you have
robust set conformance tests that tests these edge cases I guarantee you
there will be interoperability bugs with unexpected identifiers. If TOSCA
used throughout a system, e.g. persisted in a database, input data will
likely be handled by code that doesn't expect simple names to have carriage
returns and invisible characters etc. (because that is let us politely say,
unexpected and unusual) and you open yourself up to things like SQL
injection attacks.

To answer your question about XML: Does TOSCA's YAML profile need to be
compatible with its XML profile? If it does, how would you represent a
TOSCA YAML identifier in a TOSCA XML file? I guess you would write an
algorithm to escape the invalid characters? And then if you need to
translate the XML back to YAML, you'd write code to recognize the escaped
identifiers and unescape them? Just throwing an example out there to
illustrate the complexity burden you are placing on implementations for
little gain.

But I agree with you about this issue being exhausted at this point if
these arguments don't make sense make to you.



On Sun, Mar 8, 2020 at 7:06 PM Tal Liron <tliron@redhat.com> wrote:

> On Sun, Mar 8, 2020 at 8:45 PM Chris Lauwers <lauwers@ubicity.com> wrote:
>
>> That is all reasonable, but we’re narrowly talking about entity names
>> (such as node templates, property names, requirement names, etc.), not the
>> values for those entities.
>>
>
> But these are also values that are often validated by the parser. E.g. if
> you give a "bad" name to a requirement it should cause an error if it can't
> be matched at the node type or node template.
>
> I'm really confused as to where this is all going. Typos can happen
> anywhere in any computer language, whether it's restricted to English's
> [a-zA-Z] or all of Unicode.
>
> I'm sorry Chris and Adam, but I think this issue is exhausted as far as
> I'm concerned. I am trying to get from you some specific problem with the
> current lack of restriction and have not heard anything that looks specific
> to me. On the other hand, I've raised a few reasons why you would want to
> keep it unrestricted -- visual IDEs, separation between design and runtime
> elements, TOSCA generated from external systems, future uses that we don't
> even know about, the arbitrariness of picking just any set of rules (XML?
> why?) -- and have not gotten any arguments against them.
>

My remark about "typos" was specifically a response to Chris's last point
about unfortunate copy-and-paste mistakes.

I feel I've responded fully to the SQL injection issue, which I insist is
not enabled by TOSCA allowing arbitrary node template names, any more than
our allowance for arbitrary string values in properties. If you are
building SQL queries with literal values and not scrubbing them then I dare
say you have more serious security issues than node template names.

I will respond only to new issues here to avoid repetition:

On Mon, Mar 9, 2020 at 5:08 PM adam souzis <adam@onecommons.org> wrote:

> To answer your question about XML: Does TOSCA's YAML profile need to be
> compatible with its XML profile? If it does, how would you represent a
> TOSCA YAML identifier in a TOSCA XML file?
>

Here's one way that would be fully compatible with TOSCA 1.0 (in YAML) to
1.3:

<node-template>
<id> you can put any Unicode text here as long as you escape XML entities
</id>
</node-template>

I know that TOSCA 1.0 (in XML) used an attribute for the ID, but I also
don't know of anybody currently using that spec. Meanwhile, TOSCA 1.0
(YAML) to TOSCA 1.3 were published without specifying name restrictions. If
we introduce a restriction in TOSCA 2.0, which will be quite different from
the 1.X series, we could affect migration to 2.0. Are you suggesting that
someone will want to convert a TOSCA 2.0 service template to TOSCA 1.0 in
XML? I think node template names would be the least of their problems.
Actually, all versions of TOSCA until now introduced breaking changes. We
are hoping to run a tighter ship in the 2.X series, or at least make sure
to upgrade the major version number when we introduce breakage.

It's worth pointing out that TOSCA's move to YAML involved fully embracing
the type system in YAML 1.1 (with the exception of timestamps, which we've
discussed separately in this mailing list). XML does not have a type system
(no integers or floats, only CDATA) while YAML's has served us quite well
as an underlying system for TOSCA's basic data types. It's very easy to
take a YAML file and convert it to any programming language's primitives,
hashmap, and array implementations. I've come to call this kind of
data "Agnostic
Raw Data (ARD) <https://github.com/tliron/puccini/blob/master/ard/README.md>
".

We could go even further: YAML 1.2 expands on extensibility, so that
potentially we could even allow for TOSCA data types to be represented as
custom YAML types. I wouldn't recommend we go in that direction, though, as
it would also make it very hard to implement TOSCA parsers. You would have
to find a YAML 1.2 parser library that allows for easy extensibility of
types, and honestly most YAML libraries out there do not do a good job with
it, if they allow for it at all. (Data types would also have to be defined
separately from our service templates, because they would have to be parsed
and initialized as YAML types *before* being used to parse the service
template.)