Untrusted software and security click-through warnings

Anthony Yarusso tonyyarusso at comcast.net
Sat Sep 29 05:02:42 BST 2007

Hash: SHA1

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

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.


- - Tony
Version: GnuPG v1.4.6 (GNU/Linux)


More information about the ubuntu-devel mailing list