Re: Clarifications regarding GNOME Online Accounts

2019-02-16 Thread mcatanzaro
On Sat, Feb 16, 2019 at 2:57 PM, Nathan Graule via desktop-devel-list 
 wrote:

A solution would be for distribution package maintainers to use the
binary tarball as a base instead of sources - this way the build can 
be

done with secrets (ie. using GitLab CI and environment variable
secrets) and sent to distributions for packaging. This certainly puts
GNOME in a unique position in the landscape, though it allows for 
GNOME

to control the build process in such a way that build secrets become
possible.

Though if this is the way it goes, be sure to be prepared for all the
"GNOME forbids people to build their software stack" headlines,
followed by a "actually the reason is that they needed to handle
secrets in their builds in order to support client keys for the 
various

integrations in the software" in the third paragraph.


Well yeah... but distros will never allow that.

Michael

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list


Re: Clarifications regarding GNOME Online Accounts

2019-02-16 Thread Nathan Graule via desktop-devel-list
A solution would be for distribution package maintainers to use the
binary tarball as a base instead of sources - this way the build can be
done with secrets (ie. using GitLab CI and environment variable
secrets) and sent to distributions for packaging. This certainly puts
GNOME in a unique position in the landscape, though it allows for GNOME
to control the build process in such a way that build secrets become
possible.

Though if this is the way it goes, be sure to be prepared for all the
"GNOME forbids people to build their software stack" headlines,
followed by a "actually the reason is that they needed to handle
secrets in their builds in order to support client keys for the various
integrations in the software" in the third paragraph.

Le samedi 16 février 2019 à 13:06 -0600, mcatanz...@gnome.org a écrit :
> On Sat, Feb 16, 2019 at 12:57 PM, mcatanz...@gnome.org wrote:
> > It's not clear to me how g-o-a can continue to exist, then. Also, 
> > Epiphany's Safe Browsing support. (How do Firefox and Chromium
> > make 
> > this work?)
> 
> Turns out it's a new restriction that took effect on January 16,
> 2019. 
> So probably we've only been in violation for one month now. (You can 
> see the previous version of the terms of use are from 2011 and do
> not 
> include that requirement.)
> 
> Anyway, we can't have secrets in the build, so we don't have a lot
> of 
> options. Maybe not any options. At least, I don't see any.
> 
> Michael
> 
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Clarifications regarding GNOME Online Accounts

2019-02-16 Thread mcatanzaro

On Sat, Feb 16, 2019 at 12:57 PM, mcatanz...@gnome.org wrote:
It's not clear to me how g-o-a can continue to exist, then. Also, 
Epiphany's Safe Browsing support. (How do Firefox and Chromium make 
this work?)


Turns out it's a new restriction that took effect on January 16, 2019. 
So probably we've only been in violation for one month now. (You can 
see the previous version of the terms of use are from 2011 and do not 
include that requirement.)


Anyway, we can't have secrets in the build, so we don't have a lot of 
options. Maybe not any options. At least, I don't see any.


Michael

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list


Re: Clarifications regarding GNOME Online Accounts

2019-02-16 Thread mcatanzaro
On Sat, Feb 16, 2019 at 11:58 AM, Michael Terry  
wrote:
“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.”


It's not clear to me how g-o-a can continue to exist, then. Also, 
Epiphany's Safe Browsing support. (How do Firefox and Chromium make 
this work?)


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list


Re: Clarifications regarding GNOME Online Accounts

2019-02-16 Thread Michael Terry
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