Access key module

[Cliff Wells]

On Sun, 2007-12-30 at 16:41 +0100, Manlio Perillo wrote:
> Cliff Wells ha scritto:
> > 1) A secure, centralized place (RCS system or even just tarballs) to
> > download from (wiki is too open: even links to outside source code make
> > me nervous since they could be altered by a malicious editor to lead to
> > poisoned source code).
> > 
> 
> Each developer should sign his module source distribution with PGP.

But if this is linked to from the wiki, then it does little good.  All a
malicious person needs to do is sign their poisoned source with PGP as
well, either on the wiki or on a fake module page they substitute for
the real one. 

> Moreover, each developer should have his key signed by a "master key" 
> (Igor?) so that nginx core can verify the external module during 
> configuration.

This would be better, but seems more complicated than need be (at least
initially).  All we really need for the moment is a place where not just
any anonymous user who creates a wiki account can change where source
code is available from.

> But none of the open source projects I know with support to external 
> modules do such a thing... (signing and verification is done at 
> "Distribution" level, like Debian).

Sure, but a lot of people are using source rather than distro tools to
install Nginx, so I don't think counting on this is safe.  Plus, a lot
of OSS projects do exactly this: usually it's a "contrib" directory in
the source distribution or RCS tree.  With Nginx we don't have the main
source tree hosted in RCS, so it's a bit different, but the concept is
similar.

This actually brings up another thought: perhaps we should start an RCS
tree for Nginx.  We don't actually need Igor to use it (I'm sure he has
his own tools and methods and I don't want to interrupt that): diffs can
be generated automatically from the tarball Igor provides.  Of course,
we lose revision comments (assuming there are any), but we would at
least have a public history and a place to provide downstream patches
against (i.e. adding the ability to automatically pull 3rd party modules
into the build process).

> Adding a RCS system can be too hard to handle, altough a distribuited 
> revision system can help (and some of them permits to sign each revision).

Not sure why this would be hard.  Have current module developers vote on
a preferred RCS and use it.  And I agree that a distributed system (such
as git) would be a good choice.

> > 2) Issue tracking.  Might be handy for module authors to not have to
> > maintain their own Trac (or whatever) instance.
> > 
> 
> Yes, this can be very helpful.
> But it is always possible to use Google Code or some other projects hosting.

Sure, but it doesn't solve the problem of creating a trusted code
repository.  Remember, the problem isn't how people are storing their
code: it's how others *get* to that code.  If they follow a link from a
wiki, then there's the potential that they are not going to a legitimate
site.  

> > 3) Perhaps adding some feature to the Nginx build process that allowed
> > 3rd party modules to be easily downloaded and installed (from site
> > listed in item 1) via configure/make flags (or is this just wishful
> > thinking?).
> > 
> 
> I don't think this is a priority.

Well, nothing is a priority until it's a problem =)  We've gone from
having zero 3rd party modules to nearly a dozen in just a few months.
It would be nice to get something in place while it's still a manageable
task.

Regards,
Cliff