Allow hiding authentication data in scope binary

Mardy: if this doesn't actually improve security, why is this bug marked high importance? Is there any particular user who is calling for this feature?

Are there any online services we are talking to that require this kind of obfuscation?

The importance is a bit arbitrary. From the security point of view, there is really no benefit in having this feature.

However, there is a real case for it, because service providers might have some guidelines on where the application keys can appear and where they cannot: I recall Ken telling me that Twitter was unhappy about having the application keys visible in the Gwibber's source code, and just moving them to the debian/rules files made them happier. It's illogical, but it can happen.

There is anyway another reason why this feature is needed: in some cases, authentication parameters are known only at run time, and therefore cannot be encoded in any static file. The example (and the reason why I hurried to fix this bug) is UbuntuOne, whose "TokenName" parameter is based on the device's hostname, which is changeable.

If you're patching client IDs into a program from the debian/ directory, surely it would be just as easy to patch them into the service file as into the source code though, right?

As for Ubuntu One OAuth code, I agree that it's OAuth code is weirdly non-standard (I filed bug 978719 about it way back). However, I'm not sure how your proposed API changes would help with U1: while it isn't using a fixed consumer key and secret, those values are assigned as part of the authorisation process rather than being passed in by the application.

On 15/03/2016 04:01, James Henstridge wrote:
> If you're patching client IDs into a program from the debian/ directory,
> surely it would be just as easy to patch them into the service file as
> into the source code though, right?

Absolutely. But some people do argue (while I try hard to avoid LOL'ing)
that having the keys encoded in the scope binary is more secure than
having the in plain text in the filesystem.
Really, it's not a matter of security, it's all about perception and
politics. :-)

That said, however, there are also other valid use cases: for instance,
the list of OAuth2 permissions which a scope requests can vary at
runtime. Indeed, most apps and scopes always request the full list of
permissions that they intend to use, but one could imagine the case
where a scope presents a configuration UI to the user, and based on the
user choices uses a different set of service APIs (and therefore
requests different permissions).

> As for Ubuntu One OAuth code, I agree that it's OAuth code is weirdly
> non-standard (I filed bug 978719 about it way back). However, I'm not
> sure how your proposed API changes would help with U1: while it isn't
> using a fixed consumer key and secret, those values are assigned as part
> of the authorisation process rather than being passed in by the
> application.

You are right that the token name is not passed by the application, but
anyway it's generated in the libubuntuoneauth library *at runtime*,
based on the hostname. That's why this feature is needed.

This bug was fixed in the package unity-scopes-api - 1.0.4+16.04.20160402.4-0ubuntu1

---------------
unity-scopes-api (1.0.4+16.04.20160402.4-0ubuntu1) xenial; urgency=medium

  [ Marcus Tomlinson ]
  * Simplify debian/control munging. Look for clang-format as opposed to
    clang-format-3.x. Added missing initializations to TypedScopeFixture
    (Bug #1542906). Allow clients to specify authentication parameters
    (Bug #1554040). (LP: #1554040, #1542906)

  [ Michi Henning ]
  * Fixed incorrect generation of Replaces: and Conflicts: entries in
    debian/control for xenial. Fixed incorrect library soname for vivid.

 -- Marcus Tomlinson <email address hidden> Sat, 02 Apr 2016 03:24:17 +0000