[Bug 833945] Re: Allow to install system wide license keys

[Anthony Lenton]

Copy+pasting from the thread where packaged keys was dicussed:

(...)
The main option on this thread seems to be to serve the key from a
 package vs. pulling it in some other way that involves an API.

Packaged keys have several downsides.  If we serve them from a per-user
 PPA, it would involve a buildtime for each key package, even though
 the package itself is trivial, so there would be a considerable delay
 between purchasing the app and being able to download the key for it.

If on the other hand we serve the key packages from sca it would
 involve setting up a basic repository layout on our server and
 generating (binary) debs on the fly.  Generating and taking care of
 the server certificates, getting them trusted would also be an issue,
 as well as restricting access to the deb file during installation so
 that only the rightful owner can access it.

Lastly, USC would need to enable more than one source per purchase, and
 download more than one package, so it would still need changes on the
 client.

The alternative would be to provide an authenticated api call that
 provides the key.  There was a downside with this too: if the key is
 pulled in as part of a post-install hook, it would be running within a
 different environment that would have root privileges but possibly not
 the right network setup or user credentials to get at the key.

There is a way around this, and that is to have USC get the key as part
 of the purchase process (together with the private deb line, or in a
 separate api call).  It has all the right network setup and
 credentials at that point, and it can put it into a standard location
 for the application to check.

Which location to use for the key was another question.  Ideally it
 would be somewhere within the user's home directory, but the downside
 of that is that users might tamper with their own key file and delete
 it or break it unintentionally.  A free advantage of USC setting up
 the keys is that there could be a menu option like the current
 "Reinstall previous purchases..." that would refetch license keys for
 you.  And it could do this without needing to redownload and
 install the app (another advantage over post-install hooks).  Looking
 at xdg mvo has recommended  ~/.config/software-center/license-keys/ as
 the standard location for storing the keys.  Within that directory we
 could place one file per application.

(...)

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to aptdaemon in Ubuntu.
https://bugs.launchpad.net/bugs/833945

Title:
  Allow to install system wide license keys

Status in Online service used by software center:
  New
Status in “aptdaemon” package in Ubuntu:
  In Progress

Bug description:
  There is the need to allow sharing software license key by all users
  on the system. So they need to be dropped to an accessible location on
  the system. This bug tracks the discussion and progress of this
  effort.

  From a security point of view we allow a desktop user to "randomly"
  drop files on the system. So we should try to define the dropping area
  and the content of the file as tight as possible.

  Open issues:
  * Can we assume that we can patch or force the shipped software in /opt to use a common place defined by our policy (problem with proprietary software)?
  * If the above question is yes: Can we store the licenses in a central repository e.g. /var/licenses/pkgname.key? Or should we store them in the corresponding /opt/pkgname dir?
  * If the first question is no: Can we still assume that the key has to be stored in the /opt/pkgname dir? E.g. Does a "special" customer insist on uppercase naming which is not allowed as a package name /opt/AcrobatReader?
  * Can we sign the key by Launchpad to make sure to only drop a file which can be sure of to be license key? The signature check needs to be done by aptdaemon
  * We need a trusted way to transfer the location of the key to aptdaemon - current solution would be to store the key path in a package control field (XB-LicenseKeyPath). But we could also append this information to a signed license key, see question above.

To manage notifications about this bug go to:
https://bugs.launchpad.net/software-center-agent/+bug/833945/+subscriptions