Verify RDNN's outside of GitHub [$30]

[stuartlangridge]

Apps have to have a reverse-domain ID, as per the fd.o spec. However, AppCenter requires that that reverse ID is com.github.myusername.appname. Quite apart from how this makes not a lot of sense if/when AppCenter starts supporting other non-github stores (gitlab, etc), it means that I can't ever move my app off github even if AppCenter does support other stores. And, more importantly, my app's ID is my domain, not github. Github just happens to be a place where it's currently pushed to so that AppCenter can get hold of it. There shouldn't be any technical problem here; the app ID doesn't need to agree with the repository URL, it just needs to be unique and mine and "a valid D-Bus well-known bus name". Indeed, if anything, that name should probably agree with that which is passed to Gtk.Application.new() in the app itself, which for almost everyone isn't com.github.anything.

---

There is a $30 open bounty on this issue. Add to the bounty at Bountysource.

[cassidyjames]

Developers building apps for elementary OS, following the elementary OS developer guide, are indeed using com.github.* for their app ID. 😉

I talked to @danrabbit about this earlier, and he pointed something out as well: if we're to trust that the app ID is globally unique, we have to be able to verify that a developer owns that domain, which means a lot of special casing for that when we can just rely on information we already know (where the code is hosted) instead. Not to say that code won't be written, but it's not a priority at the moment. If we don't verify domains, there's nothing stopping someone from using a domain that is not their own, making the use of RDNN useless in the first place.

[danirabbit]

At the moment we rely on the repository URL to ensure uniqueness and ownership. In a future where we offered GitLab integration, we'd still be relying on that repository URL. So I think for the foreseeable future RDNNs will have to match the repository URL.

I'm not sure how realistic it is to have/verify RDNNs that are different from where the code is actually hosted.

[stuartlangridge]

But where the code is hosted isn't relevant to the app's identity. At some point you will start supporting, say, gitlab, or a passed git url of my choice. At that point, I start supplying my app's gitlab or bitbucket URL, and I have to change the ID, which breaks upgrades! Making my app's globally unique ID depend on which of its five git URLs I happened to give you is like making my app's ID depend on which day I started writing it on. If I change my github username: I break upgrades for all my elementary apps. If I rename the repository: I break upgrades for that app. If I host it somewhere else: I break upgrades for that app. Perhaps you think that's a reasonable thing to do: that I should choose right now where this app will be hosted for its whole entire life. But you've already decided to move half the elementary project from launchpad to github and for god reasons; don't we want to give developers that same choice? Not lock them to this URL forever just because it's all you support right now?

[danirabbit]

Definitely notice that this report hasn't been closed. It's just not something that's feasible at the current time

[smcv]

I'd recommend transforming dashes to underscores when deriving app IDs from reversed domain names (and Github usernames are syntactically hostnames, so those too). That works much better with DBusActivatable, D-Bus in general (dashes aren't allowed in D-Bus interface names or object paths, only in bus names - historical accident but it's 10 years too late to change that now), and Flatpak. I'm going to see if I can get that recommendation into the Desktop Entry Specification. If Elementary OS accepted either - or _ for compatibility with existing apps (as Flatpak partially does), that would be fine too, of course.

Conveniently, Internet hostnames (and Github usernames, which have the same syntactic restrictions) don't allow underscores, only dashes, so there is no chance of a collision from doing that transformation.

The meme I'm trying to spread is that app IDs, D-Bus names and object paths, etc. should be derived from DNS names like this:

• replace - with _
• if a component starts with a digit, prepend _ to it
• example: 7-zip.org (which happens to hit both the problem cases) might publish org._7_zip.Archiver

This cannot result in a collision with other valid DNS domain names, because DNS domain name components aren't allowed to contain _ or start with -, so there is no ambiguity.

[phw]

Transforming dashes to underscores makes sense here independent whether hostnames outside of Github or not, probably that should be a separate issue.

@danrabbit Given the issues caused by dashes in app IDs, would it be possible to enforce this rule in your validation? And is it possible to change the ID of an already published application?

[btkostner]

Yes, it is possible to change the validation now, but its a big change and it would require making transition packages for all of the current apps. Changing this to match the desktop requirements more seem like a great idea, but I think it best to make sure we have the rules settled on first so we only have to do it once.

@smcv Thank you for your comment about how dbus and the domain schema work. I didn't take into account some of those edge cases.

[smcv]

Transforming dashes to underscores makes sense here independent whether hostnames outside of Github or not, probably that should be a separate issue.

I've opened #566 for that.

Changing this to match the desktop requirements more seem like a great idea, but I think it best to make sure we have the rules settled on first so we only have to do it once.

My patches on https://bugs.freedesktop.org/show_bug.cgi?id=103216 should hopefully be applied soon.

[btkostner]

Just to keep you guys informed: The soon to be released v2 worker fully supports customized names. This will let you use houston ci for testing apps on travis. Once v2 version of the web interface is setup you will be able to change the name in houston and release apps with custom domains and names.

[bilelmoussaoui]

@btkostner any new on this? We need to publish FeedReader here https://github.com/jangernert/FeedReader/issues/494

[aral]

Just want to chime in here both in the context of this discussion on trademark violation regarding the use of com.github in app names but also more in general based on the points raised by @stuartlangridge several years ago.

In addition to agreeing with Stuart’s points and the trademark issue, there’s another big problem with tying all third-party apps to a single corporation: you lose control over what you can allow on your platform.

Currently, there are two entities who decide who can develop for elementary OS and what apps can go on elementary OS:

1. Microsoft. Any developer not approved by Microsoft for a GitHub account for any reason cannot develop an app for elementary OS. Similarly, any app not approved by Microsoft for hosting on GitHub cannot be allowed on elementary OS.

2. The elementary OS app review team.

I feel it would be in the best long-term interests of elementary OS as an independent organisation to not give Microsoft veto rights over what apps are allowed on its platform.

[btkostner]

While the documentation says to use the GitHub RDNN the new review process has no tie to GitHub or the GitHub based RDNN. The repository in appcenter-reviews can be any valid public git repository, as can the RDNN. At this time I don't believe anyone has published something outside of the default values, but it is possible. It was designed this was to avoid GitHub restrictions and so we can eventually add dashboard support for gitlab.

One thing that can possibly be confusing is that the dashboard will use the GitHub RDNN by default. The developer will need to contact us or comment on the review PR and then we can update the RDNN.