-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 <snip> Kees Cook wrote: > On Fri, Sep 28, 2007 at 03:56:31PM +0100, Ian Jackson wrote: >> * Yes, click-through addition of PPAs whose uploaders we bless >> and for which someone will provide security support > > It seems that some knowledge of who owns a PPA should factor into > the key management for that PPA. For example, someone who isn't > MOTU shouldn't get automatic installation of packages onto users' > systems from "main". > > > - Ubuntu repository software (QC'd via Debian & ubuntu-*dev, Safe, > Free) - PPA repository software (less QC, less Safe, contractually > Free) - 3PA repository software (lesser QC, less Safe, unknown > Freedom) - 3PA non-repository software (least QC, unsafe, non-Free) > - Malware (no QC, dangerous, non-Free) > > I don't think there is much difference between the PPA repo and 3PA > repo -- in both situations, the person providing the software is > attempting to make it available in an "easy" way for the end-user. > I think key management can be the way to make the PPAs stand out > here. > > > -Kees </snip> It sounds like regardless of the exact details, some additional features in Launchpad could be extremely useful for this. Lately there has been some discussion on the LP-users ML requesting the ability to sign PPA archives so that users could add the key and avoid the "untrusted source" warning from apt. This could be extended to give different types of warnings or lack thereof depending on the person. Conveniently, Launchpad PPAs are already tied to a LP user ID or team, each of which has its own team memberships, and therefore would make trust and access levels / permissions reasonably easy to define and maintain. Additionally, some people (Dennis Kaarsemaker for instance, aka Seveas) maintain third-party repos, but also have a Launchpad ID with their GPG key, so theoretically we could also incorporate the repos of individuals and groups that choose not to use Launchpad's PPA feature (in favor of other tools, such as Falcon in this example), but who have a Launchpad profile that would be associated with their key. There would then need to probably be some package in the default installation that would be a sync of Launchpad permission levels and members, although I don't know how practical that would be given that it's something that could change with time. However, it might be reasonably sane to have a set level of access per release, much like we have package freezes, and only change it for certain exceptional circumstances. This would make sure people weren't having to get updates to that package all the time and get annoyed, but still provide the functionality. The main reason to have it be a package is to ensure that the controls would be present at the system even if an internet connection is not present at the time a user tries to install something, or in the event of Launchpad downtime. I have no idea how we'd determine which teams would have which privileges in this system, but I imagine they'd be related to what their upload privileges are during development, plus some other cases for things like LoCo PPAs, individuals (Ubuntu Member / non-member distinction?), and things like mozillateam, that aren't normally directly part of the upload process, but may have differing levels of trust that aren't appropriate to group all together with just anyone. What the different behaviors for each trust level would of course have to be defined by someone far more knowledgeable than myself, although it sounds like you're already starting to get an idea of what some of these might be. Thoughts? - - Tony -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG/c5iKlAIzV4ebxoRAk1jAJwMtMDZ03R8hU2ge00cPQP8gLwsoACfRXjb WCdGhMLUU2vOWAMDrhX05/c= =rxXD -----END PGP SIGNATURE-----
This is the launchpad-users mailing list archive — see also the general help for Launchpad.net mailing lists.
(Formatted by MHonArc.)