[AppStream] Unifying the AppStream IDs

[Simon McVittie]

On 25/07/16 19:43, Matthias Klumpp wrote:
> 2016-07-25 18:26 GMT+02:00 Simon McVittie <simon.mcvittie at collabora.co.uk>:
>> copy the syntax of either interface names or well-known bus names. Both
>> of those normally look like com.example.MyProgram; the difference
>> between them is that well-known bus names may contain hyphen/minus but
>> interface names must not.
> 
> Yeah, this is pretty weird - do you know the reason for not allowing that?

This is all from before my involvement, but I think Havoc might have
intended to be able to mangle interface names into C++ namespace names,
Python package names and other things with C-identifier-like syntax
(com.example.My_App -> generated::com::example::My_App or some such)
which wouldn't work if hyphen/minus was allowed. Bus names don't have
the same constraint.

One obvious answer to that is "don't allow hyphen/minus in bus names
either, then" but it's more than a decade too late to make that change.

Another obvious answer is to point out that this isn't enough *anyway*,
because reserved words exist (and are language-specific), so you need to
be able to escape them - if nato.int wanted to generate C++ code for
int.nato.Missile, generated::int::nato::Missile is just not going to
work - and if you can do that, then you can also escape non-identifier
characters perfectly well.

The particularly weird thing about allowing hyphen/minus in well-known
bus names is that you can't follow the usual convention that the owner
of the bus name com.example.Foo-Bar1 exports its main APIs (typically an
ObjectManager) at /com/example/Foo-Bar1, because that isn't a
syntactically valid object path (you have to use /com/example/Foo_Bar1).

In my view it's silly that hyphen/minus and underscore were ever both
allowed in the same category of D-Bus names. Real DNS names can only
contain hyphen/minus and not underscore, so one is enough. Either using
the DNS name as-is or mechanically translating every hyphen/minus to
underscore would have been fine, but allowing both in well-known names
is redundant. Again, it's 10 years too late to fix this in D-Bus, but
maybe I can stop AppStream, Flatpak, etc. from making the same mistake?

> If possible I would like
> to avoid imposing the number/hyphen restrictions to AppStream IDs,
> since this will complicate the way we build IDs again and would be
> non-obvious to people ("why can't I use my real domain name?").
> Internally, we can of course treat the IDs however we like, and we
> could even have the files specifically state the D-Bus interface names
> they want to own (see <provides/> -> <dbus/>)

My concern here is that for many of the "app" solutions currently being
proposed and developed (Flatpak, Snap, etc.) sandboxing is a key
feature; and meaningful sandboxing benefits from having a really clear
story for what is and isn't allowed. For simplicity in privileged code
paths, it would be good for the rules to be as clear and obvious as
possible, even if that means forbidding some strings that would be
allowed in the wider system (like D-Bus names with hyphen/minus in).

For the specific apps I'm dealing with, I'm probably going to simplify
by requiring a stricter subset of AppStream and D-Bus, and specifically
forbid "-" even in the contexts where AppStream and D-Bus would allow
it. Of course, that doesn't impact the broader AppStream spec, because
we're using a subset of it anyway; but if you ever want to make
AppStream stricter for the same reasons, sooner is probably better than
later.

-- 
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>