Access key module
cliff at develix.com
Mon Dec 31 02:48:12 MSK 2007
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
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
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
> > 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
More information about the nginx