org.filezillaproject.Filezilla -> org.filezilla-project.Filezilla

[Pointedstick]

The domain name is filezilla-project.org (not filezillaproject.org) so let's respect that in the AppStream ID.

I have also submitted an upstream patch to use this ID: https://trac.filezilla-project.org/ticket/11478T

[TingPing]

That isn't a valid id for flatpak.

[Pointedstick]

No dashes allowed?

[TingPing]

Dashes are only allowed in the last segment.

[Pointedstick]

OK, thanks.

[TingPing]

The convention is to replace - with _ btw. Sadly this one didn't seem to follow that and we don't have tooling to rename apps on flathub atm.

[nedrichards]

Yeah, happy to fix that when we have tooling to move apps (which I know we're working on at work, so all isn't lost). @TingPing we should put something on the submission notes about conventions here in future.

…

On Sun, 24 Dec 2017, 17:52 TingPing, ***@***.***> wrote: The convention is to replace - with _ btw. Sadly this one didn't seem to follow that and we don't have tooling to rename app's on flathub atm. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AASeVTh5ynNX4HhM7TBCBOP7syY1KEdxks5tDo9dgaJpZM4RL-sX> .

[Pointedstick]

@TingPing @nedrichards @alexlarsson

So I got the FileZilla people to change their upstream AppStream ID to rDNS style: org.filezilla-project.FileZilla. But they refuse to further change that to remove the dash because they say it's a perfectly acceptable reverse-DNS name, and that not supporting dashes anywhere is a bug in Flatpak: https://trac.filezilla-project.org/ticket/11478#comment:3

How shall we resolve this impasse?

[TingPing]

Well sadly they just have a broken app-id now. The DBus (and thus Gtk) spec will enforce the Flatpak requirements soon and the Desktop spec will recommend the Flatpak requirements soon. So we just will continue renaming it.

[TingPing]

Sidenote just for @nedrichards @alexlarsson: We should perhaps make our own spec or something for app-id's because calling it rdns only ends poorly because we explicitly do not support rdns we just want an app-id in rdns-like style.

[Pointedstick]

Any chance you could reach out to the FileZilla folks on this matter? I'm playing go-between but since I'm not a Flatpak, Flathub, or AppStream developer, I don't think my words carry much weight.

[TingPing]

@Pointedstick Well what they said isn't wrong and they clearly don't care about Flatpak so I don't think there is any further action to take upstream. Getting consistent guidelines in all of the specs is still in progress as mentioned so maybe after that point they can revisit it.

[Pointedstick]

I think most software developers aren't going to care about Flatpak or Appstream per se; it's going to be up to us to make adoption as straightforward and painless as possible.

[TingPing]

it's going to be up to us to make adoption as straightforward and painless as possible.

Indeed, but strict naming conventions are part of the security model so that can't be avoided. All we can do is document it.

[Pointedstick]

Documentation is good, as is encouraging upstream software to take the lead here so we don't run into the situation where Flathub defined an AppStream ID for them that they don't want to or can't use once they get around to defining one themselves. And can you expand on the security implications of allowing more dashes in the AppStream ID?

[TingPing]

@Pointedstick As I understand it (anybody feel free to correct me):

Flatpak supports 6 types of exports currently: icons, mimetypes, search providers, desktop files, appstream data, dbus services.

In order for the concept of exports to be unique they must all have a matching ID so what Flatpak can allow is the least common denominator of all of these. So lets break these down:

• Desktop file spec: Seems mostly undefined except / forbidden and should be replaced by -.
• Mime info spec: Seems undefined
• Appstream spec: It must contain only ASCII characters, dots, hyphens and numbers. Spaces are not allowed. The ID must follow a reverse-DNS scheme, consisting of {tld}.{vendor}.{product}.
• Icon theme spec: Actually seems undefined other than file extension?
  GNOME extends this spec by including -symbolic variants of icons which is related to the restriction of - AFAIK.
• DBus spec (0.32 not yet released):
  • Valid UTF-8
  • Composed of 1 or more elements separated by a period ('.') character. All elements must contain at least one character.
  • Each element must only contain the ASCII characters [A-Z][a-z][0-9]_-, with "-" discouraged in new bus names. Only elements that are part of a unique connection name may begin with a digit, elements in other bus names must not begin with a digit.
  • Bus names must contain at least one '.' (period) character (and thus at least two elements).
  • Bus names must not begin with a '.' (period) character.
  • Bus names must not exceed the maximum name length.
  • Note that the hyphen ('-') character is allowed in bus names but not in interface names. To avoid situations that require special-case handling, it is recommended that new D-Bus names consistently replace hyphens with underscores.
• Search providers: Just follow DBus.

So at the end of the day one thing to absolutely be sure of; A Flatpak application-id does not necessarily match what DNS supports because that isn't the goal.

[Pointedstick]

OK, thank you. Given the confusion that's bound to result from AppStream and DBus having slightly different formats, I wonder if we might make the AppStream ID spec more strict to match the DBus one: ximion/appstream#162

[smcv]

The DBus (and thus Gtk) spec will enforce the Flatpak requirements soon

The D-Bus spec only discourages hyphen/minus. I have no plans to change "discouraged" to "forbidden" - that would be a backwards-compat break. I could make the dbus-daemon log warnings eventually, but given how hard it is to rename an app gracefully, it probably isn't worth it - apps that have the wrong name will probably have it for a long time.

A special case where a Flatpak app is sometimes allowed to publish the "wrong" name, but needs to be specially flagged as doing so, with each change triggering Flathub review, might be a pragmatic escape route.

A Flatpak application-id does not necessarily match what DNS supports because that isn't the goal.

There are already plenty of valid DNS names that are not syntactically valid D-Bus bus names, so if you want Flatpak app IDs to match D-Bus bus names and encompass all valid DNS names, you've already lost. The example I like to use is that 7-zip.org exists and publishes open source, but neither org.7-zip nor org.7_zip is a syntactically valid well-known bus name (because a leading digit isn't allowed). I believe the original motivation was to let Java and C++ libraries generate classes like com.example.MyAPI and com::example::MyAPI for their D-Bus bindings (although I didn't write that part of the spec, and it's really anyone's guess unless someone is still in touch with Havoc).

[TingPing]

I have no plans to change "discouraged" to "forbidden" - that would be a backwards-compat break.

Yea sorry I corrected that in my later post.

The example I like to use is that 7-zip.org exists and publishes open source, but neither org.7-zip nor org.7_zip is a syntactically valid well-known bus name (because a leading digit isn't allowed).

We've been using org._7_zip

Yea as I said we should just stop referring to them as rdns because upstreams expect their dns name to "just work" after that.

[smcv]

We've been using org._7_zip

Yes, that's my recommendation for dealing with that name.