 | Start a set with this search |
 | Include this search in one of my sets |
 | Exclude this search from one of my sets |
 | Permalink to these results Paste this link in email or IM: |
 | Atom feed for tracking future search results Paste this URL into your reader: |
22 messages in ru.sysoev.nginxRe: Access key module| From | Sent On | Attachments |
|---|---|---|
| Evan Miller | Dec 29, 2007 7:19 pm | |
| Cliff Wells | Dec 30, 2007 12:53 am | |
| Manlio Perillo | Dec 30, 2007 7:41 am | |
| Cliff Wells | Dec 30, 2007 3:47 pm | |
| Grzegorz Nosek | Dec 31, 2007 12:32 am | |
| Manlio Perillo | Dec 31, 2007 3:43 am | |
| Manlio Perillo | Dec 31, 2007 3:55 am | |
| Grzegorz Nosek | Dec 31, 2007 5:31 am | |
| Manlio Perillo | Dec 31, 2007 6:46 am | |
| Evan Miller | Dec 31, 2007 8:00 am | |
| Grzegorz Nosek | Dec 31, 2007 8:07 am | |
| Manlio Perillo | Dec 31, 2007 8:32 am | |
| Manlio Perillo | Dec 31, 2007 8:49 am | |
| Grzegorz Nosek | Dec 31, 2007 9:06 am | |
| Adrian Perez | Dec 31, 2007 9:52 am | |
| Evan Miller | Dec 31, 2007 12:12 pm | |
| Evan Miller | Dec 31, 2007 12:41 pm | |
| Grzegorz Nosek | Dec 31, 2007 1:06 pm | |
| Cliff Wells | Dec 31, 2007 3:34 pm | |
| Manlio Perillo | Jan 1, 2008 9:03 am | |
| Manlio Perillo | Jan 1, 2008 9:07 am | |
| Adrian Perez | Jan 4, 2008 8:13 am |
| Permalink for this message Paste this link in email or IM: |
| Permalink for this thread Paste this link in email or IM: |
| Atom feed for this thread Paste this URL into your reader: |
| Subject: | Re: Access key module | Actions... |
|---|---|---|
| From: | Cliff Wells (clif...@public.gmane.org) | |
| Date: | Dec 30, 2007 3:47:49 pm | |
| List: | ru.sysoev.nginx | |
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