The main MoonRocks manifest and all associated files are automatically
backed up to this git repository
https://github.com/rocks-moonscript-org/moonrocks-mirror  I'm also fine
with setting up something that the mirrors can use rsync on so minimal
changes are required.

In response to the worries about malicious modules, if you have any idea
for mitigating problems like this I'd love to hear them. I think minimally
it would be good to have some community moderation features. Nothing like
that exists yet but if there are people interested in being moderators then
I can add that functionality.

As for the round robin mirrors idea, it's definitely an interesting idea
but potentially frustrating because the rocks available on any given mirror
might not be the same as the other mirrors due to delays. This would cause
unexpected confusion. Additionally you lose the ability for your module to
be available immediately upon uploading unless we can ensure mirrors update
immediately.



On Wed, May 21, 2014 at 6:05 PM, Hisham <h...@hisham.hm> wrote:

> On 21 May 2014 18:46, Rob Kendrick <r...@rjek.com> wrote:
> > On Wed, May 21, 2014 at 06:36:05PM -0300, Hisham wrote:
> >> As mentioned before in this list, we have a plan of making MoonRocks
> >> the default rocks repository, effectively moving LuaRocks to a
> >> non-curated repository model (like the vast majority of programming
> >> language repositories out there). Yes, no more sending rocks through
> >> the mailing list: just create an account at
> >> http://rocks.moonscript.org/ and upload them there. Once you upload a
> >> new rock, you're the owner for that name.
> >
> > Out of interest, what steps does MoonRocks take to stop somebody
> > uploading tantalisingly-named-module-with-root-kit or
> > variation-on-popular-module-name-with-root-kit?
>
> As far as I can tell, that's part of being "non-curated" too. And I'm
> sorry if I gave the wrong impression, but I never audited the _code_
> of the modules I uploaded into LuaRocks. I checked the rockspecs and
> at most verified that they built correctly (not always, because of
> external dependencies). So, we've always been under the risk of a
> malicious module.
>
> That's how things work on most repositories [1] (Cabal, RubyGems, npm,
> etc.) And to be honest, I don't think maintainers of most curated
> repositories do thorough code audits either.
>
> -- Hisham
> [1] http://hisham.hm/papers/muhammad_2013_luarocks.pdf (page 5)
>
------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Luarocks-developers mailing list
Luarocks-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/luarocks-developers

Reply via email to