Ubuntu needs a new development model
dmitrij.ledkov at ubuntu.com
Thu May 6 20:42:40 UTC 2010
On 6 May 2010 21:23, John Moser <john.r.moser at gmail.com> wrote:
> On Thu, May 6, 2010 at 4:07 PM, Dmitrijs Ledkovs
> <dmitrij.ledkov at ubuntu.com> wrote:
>> The thing that all packages in debian rely on to prove that they are authentic?
> He said easier to trust PEOPLE. Look at the PGP web of trust, people
> with dozens or hundreds of signatures on their PGP public keys. When
> I was using GPG for a year to sign my e-mails, I re-downloaded my
> public key from the key server and had found that some 15 or so people
> that I'd never heard of had signed my key.
Debian is not using public gpg servers. Instead they maintain their
own keyring shipped in the debian-keyring package. You cannot add
signatures to that from non-dd's. And DD's are only keeping real
signatures on their keys from key signing parties.
> Your first response to this is going to point out that Ubuntu could
> trust only keys signed with keys that themselves are signed with an
> Ubuntu Master Key or some such; so maybe Martin's key is signed by
My response is to not use public gpg keyservers as authorative source
of keys & signatures....
> Canonical, Inc and Martin signs your key, so you're valid. You sign
> another key, that is still called "untrusted." Thus, we don't have
> the crazy uncontrolled mess described above.
That's more inline with SSL keys with CA keys and so-on. Debian does
self-signed onces, then sign it by gpg key =) cause CA keys are imho a
bit of mess and I can't really trust them for distributed nature.
> Which brings us back to trusting people.
> Out of the hundreds, thousands of people that you want to incorporate
> into your trust hierarchy, how do you determine which can be trusted?
> Who is talking their way through you, showing good work, uploading
> hundreds of excellent packages with stopgap patches or well-requested
> features and things that won't go into Main or will go in later; but
> in secret, really waiting for a good time to slip malware into a
I don't recall that this ever happened with ubuntu or debian to the
point that it got distributed to users. Plus there is hiearchy of
human review of all packages which go into the archive. Such things
will be noticed very quickly.
> It doesn't have to be patches they wrote; could be a -ck kernel or a
> kernel with a piece from -mm, or a patch onto Gimp that's gained
> popularity but nobody felt fit to pay attention to, or any other
> 3-seconds-of-work patching process. More than 3 seconds? Oh, this
> one I hit a bump with, I think I'll just discard it; I've got plenty
> of other "work" to show.
you lost me here.
> The smoke and mirrors is a bit complex; but we're talking about a
> threat that essentially amounts to "someone wrote, compiled, packaged,
> tested, and uploaded a piece of malware to a repository they needed
> special permission to join." This is not a fat businessman pushing
> the "SPAM THE WORLD" button.
I maybe be wrong but there are about 200 people with upload rights to
ubuntu archive. It's not so hard to know 200 people. Most of these
people are putting their reputation and work prospects when they sign
a package for upload. One such incedent can invalidate years of hard
work in open-source. I don't think there are people motivate enough to
cause such a thing.
> Every time someone suggests finding a way to trust people more (or in
> this case, trust more people), God laughs at them. A lot. The only
> way to fully trust an individual is to hang a camera and a turret
> above his head constantly, and even then you can't be sure; the only
How does that help to read someone's mind? I don't follow.....
> way to improve how much you can safely trust someone is to devote
> resources to learning about them on a personal and technical (i.e.
> background check) level. When you add hundreds of developers or just
> random people to a project, with direct access, you WILL have
> problems, and you WILL hand access to people who desperately don't
All people are already filtered like that. The suggestion here is that
you can extend this model to unofficial repositories and allow users
to connect to those easier.
You might want to look at openSUSE buildservice which allows 1-click
install of packages from any random user's published repositories.
They even kind of hide the fact that it is a team or person they just
display a catalogue with package names and versions.....
> need it. This is why the Linux Kernel has 30,000 developers and all
> of 1 or 2 people with commit access (Linus and who else? Drepper and
> Andrew maybe).
Everyone has commit access to linux tree. Go clone it and commit.
Every linux based distribution are maintaining forks with custom set
of patches applied & different compile settings. If you think about it
this way there are 100 of activly maintained forks which are
distributed to users without explicitly going through Linus, Drepper
nor Andrew. But in order to get into the mainline and cross over your
patches to other forks you need to go through pear review.
This is a similar model we can use here. If there are 10 Ubuntu
Developers that recommend a ppa and sign a key ubuntu-software centre
can forexample verify that and show to a user "what's hot?" ppa if
packages in that ppa match user's installed software stack.
More information about the Ubuntu-devel-discuss