Thank you for the clarification! As someone that had been confused about the
intent and ended up relying on GOA in my third party app, it’s nice to see the
intention spelled out so clearly.
I just wanted to mention an interesting challenge in having open source apps
handle this themselves. Let’s take Google as an example. According to their
developer terms of service [1]:
“Developer credentials (such as passwords, keys, and client IDs) are intended
to be used by you and identify your API Client. You will keep your credentials
confidential and make reasonable efforts to prevent and discourage other API
Clients from using your credentials. Developer credentials may not be embedded
in open source projects.”
So in order for an open source project to access Google APIs, it would want
build secrets. An interesting argument for flatpaks and snaps, where you could
have those (as long as you don’t use a public builder).
Unfortunately, distros do not typically support build secrets. I’m not sure
what to do in those cases. (And if a distro did support them, would they use
their own API keys or act as a trusted handler for maintainers’ keys?)
GOA currently just embeds the API secret anyway, presumably because the
realistic alternative is just not supporting Google. For my part, I’m not sure
what to do. Short term, I’ll probably just keep coasting on GOA’s loose
approach.
[1] https://developers.google.com/terms/
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
