license_key_path should not (yet) support per-user location

[Michael Nelson]

Currently USC won't allow a second user on a single system to purchase an app that is already installed, so we need to ensure that the devportal doesn't (yet) allow license_key_path using the home directory.

That said, while I was JDIing that, the current implementation allows a license file directly in /opt which seems sub-optimal (ie. potential conflicts with other files). After chatting with Anthony, we thought that for a system-wide license_key_path, it should be a relative pathname - relative to the executable location (ie. within /opt/[package_name]/).

[Michael Vogt (mvo)]

Thanks for looking into this one. I like the idea of restricting to /opt/pkgname *very* much as this makes the implementation in aptdaemon a lot simpler as well.

[Sebastian Heinlein (glatzor)]

We need a trusted way to get the path to license key. It should not be possible to drop a custom file by just specifying the path in a possible AddLicenseKey call of aptdaemon. This could be misused to drop malicious plugins or configuration snippets (/opt/pkgname/conf.d). Since we already have got a trust relation to the package repository it would be nice to store the key in the package control fields.

Open question would be if we specify only the directory or the whole license key path and name in the package records? If we want to support multiple license keys per package we could only store the path in the records and s-c would need to choose a name.

[Michael Nelson (michael.nelson)]

Hi Sebastian. I believe achuni and mvo agreed about copying the license_key_path value into the package, but I'm not sure when that will happen (and haven't yet seen a separate bug for it).

Regarding the validation we should include in the UI (it's just helping devs identify early values that they won't be able to use for license_key_path), you mention /opt/pkgname/conf.d - can you list all items we should not allow through validation? (and wouldn't the license key be written as a file without executable perms?)

And yes, currently we're catering only for one license key per install (but eventually per user also - I assume).

Thanks!

[Sebastian Heinlein (glatzor)]

Hello Michael and Michael,

So it makes sense to specify the complete absolute path to the global key file in the package record.

The main problem is that you don't know how secure the soon to be deployed software in /opt will be. Aptdaemon checks already if the license key is an executable or starts with a shebang line. Or if there are any symlinks in the license key path. Furthermore aptdaemon doesn't overwrite any existing file.

I cannot imagine any locations that should be restricted by the web ui generally, since it is completely up to the application developer e.g. if the conf.d directory is used to store configuration snippets or just keys.

Can we gurantee that all software installed in /opt will follow the /opt/pkgname schema? Or will there be some exceptions, e.g. /opt/AdobeAcroread?

[Sebastian Heinlein (glatzor)]

Do you already have got any proprietary software that enforces a license key path? Why not use a global location e.g. /var/licenses/pkgname ?

Could you automatically sign license keys by launchpad?

[Michael Nelson (michael.nelson)]

Hi Sebastian, there's work happening to automatically package the tarballs, and in that case, we'll be ensuring the /opt/pkgname schema, but not (necessarily) for tarballs that have valid debian package data already. Although I don't think I understand why it would matter - if the UI only allows a path relative to the binary executable then the auto-packaging can work out the absolute path for the control field, and we know it'll be contained within the directory where the binary is (ie. /opt/pkgname or /opt/AdobeAcroread), ah - or is this to help Aptdaemon's security (wouldn't within the directory containing the binary work? hrm, not if it wasn't in its own directory...)

AFAIK, there is no reason why we couldn't switched to some global location - achuni is the best person to discuss that with.

Would launchpad signing the keys just be for Aptdaemon to verify the authenticity of the keys before installing them? (Sorry, I don't know all the moving parts here).

Also, I added a configuration option to blacklist certain paths (such as conf.d) before I saw your following comment 4. The current branch addresses the original concern of this bug (validation includes per-user license keys depending on the config option, and license key paths can't conflict - relative to binary), but I think we should clarify the remaining points that you've brought up with achuni, perhaps as a separate bug. Let me know what you think.

[Sebastian Heinlein (glatzor)]

I opened a new bug:

https://bugs.launchpad.net/ubuntu/+source/aptdaemon/+bug/833945