Code Repositories was( RE: Proposal: add vector arithmetic to array module)

[Mike C. Fletcher]

The problem with such a centralised system is that you need people who care
enough to do such audits at the core of the project.  I, for instance, have
0 interest in doing code audits for free, and little real incentive to care
whether one has been done on any given package (the work of vetting, for
instance, wxPython would be huge, and basically I trust that the various
people on the project keep each other honest and watch their checkins).

The idea behind a non-centralised web of trust approach where you define
your trust set is that people who do care can establish themselves as
vetters of other people's code, with their vetting (maybe only their
vetting) being trusted by those who trust them (reducing the number of
people you need to trust).  As a note: if someone doesn't trust the
particular people at the top of a hierarchy of trust, then the entire
hierarchy is meaningless to them.

Trust isn't something that comes easy, but it often comes easier than
reading multiple MB of source code :o) .  Establishing that there are enough
people needing this assurance would be the first step in establishing a
project to provide the assurance IMO.  Otherwise I'd say that the vetting
mechanism should want to be a layer above the base repository.

Anyway, my arguing about such details is just hot air :) until there's a
concrete proposal and people willing to step up an build the thing, run the
thing, host the thing, etceteras.  Maybe some day I'll get bored and build
one, but for now I have plenty of other projects to get done and too little
time to finish them.

Peace,
Mike

-----Original Message-----
From: python-list-admin at python.org
[mailto:python-list-admin at python.org]On Behalf Of Paul Rubin
Sent: September 25, 2001 17:05
To: python-list at python.org
Subject: Re: Code Repositories was( RE: Proposal: add vector arithmetic
to array module)


I think multi-level certification as described in your post is very
hard to design securely and even if designed securely, doesn't work
very well in practice.  The PGP Web of Trust is an example--hardly
anyone cares about it.  If someone wants to email me something with
PGP, they usually ask for my key directly.

It's enough to just have signed distributions/libraries with one level
of signatures.  If you want real-world identity checking behind the
signatures, the existing PKI CA system is good enough for that.

Basically I want the number of entities that I have to trust to get
smaller, not larger.  That's not a matter of technical authentication
mechanisms, but rather of having a few people vetting source code and
signing it before distribution.  It would be great if there was a
Python distribution checked that way.  The vetting process wouldn't
have to be as paranoid as OpenBSD's, but any contributed source code
in such a distribution should be inspected by someone before
inclusion, and any object code in the distribution should be compiled
directly from the source code by the distribution team.

As for the authentication mechanism, something along the lines of
signed JAR files or Micro$oft Authenticode signatures should work just
fine.  It would be nice if it used normal X509 certificates, but that's
not vital.

--
http://mail.python.org/mailman/listinfo/python-list