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 Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/833053 Title: license_key_path should not (yet) support per-user location To manage notifications about this bug go to: https://bugs.launchpad.net/software-center-agent/+bug/833053/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
