[Bug 833053] Re: license_key_path should not (yet) support per-user location

[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.

-- 
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/833053

Title:
  license_key_path should not (yet) support per-user location

Status in Online service used by software center:
  Fix Committed
Status in “aptdaemon” package in Ubuntu:
  Fix Committed

Bug description:
  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]/).

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