Hi! Quoting Nagaev Boris (2016-10-22 19:22:52) > On Sat, Oct 22, 2016 at 6:56 PM, Adrián Pérez de Castro > <ape...@igalia.com> wrote: > > Hello all! > > > > Today I was thinking about the security implications of automatically > > downloading and intalling a LuaRocks release, and I noticed that > > releases are not signed in any way, and are served over plain ol' HTTP > > luarocks.org uses https.
The link at the wiki page with installation instructions at https://github.com/keplerproject/luarocks/wiki/Download#Downloading has the following link pointing to the releases: http://luarocks.org/releases which is a redirect to http://keplerproject.github.io/luarocks/releases/ I have just noticed that manually changing the URL to have "https://"; as the scheme works, but unfortunately the redirect is sent to plain HTTP: % curl -si https://luarocks.org/releases | grep '^Location:' Location: http://keplerproject.github.io/luarocks/releases % > > (read: no encryption). It would be interesting to be able to know > > whether a release tarball has been tampered with, to be confident that > > harmful code has not been introduced. > > > > I have an idea [1] a possible workaround when using Rockz (a Zsh plugin > > which provides a virtualenv-alike tool), but it would still be a good > > thing that releases would be provided with an accompanying PGP > > signature. This would be as easy as running: > > > > % gpg --detach-sign --armor luarocks-X.Y.Z.tar.gz > > > > and including the generated “luarocks-X.Y.Z.tar.gz.asc” file in the > > releases download page. In order to verify the signature, once the > > signature and the tarball are downloaded in the same location, this > > would be done: > > > > % gpg --verify luarocks-X.Y.Z.tar.gz.asc > > I propose another solution which is in use in Debian APT: create a > file with checksums of all rocks and sign it. This file should be > downloaded together with the list of packages (or replace it). > Checksum type should be a part of the file and a package can be hashed > with multiple hash algorithms. Mmmmhh, maybe I was not clear enough: my proposal is for the tarballs of LuaRocks itself, not for the modules hosted in luarocks.org — the latter would more complex to implement, and it would need changes in LuaRocks and in the server. Let's forget for now about the hosted modules :-) > Advantage is that number of files downloaded is n+1 not 2*n. > > See example of such a file for Debian APT: > http://pkg.mxe.cc/repos/apt/debian/dists/wheezy/main/binary-amd64/Packages > And the signature of the file: > http://pkg.mxe.cc/repos/apt/debian/dists/wheezy/InRelease > > Luarocks seems to have files called manifests. Can checksums be added to them? This could be an option if we would be talking about signing the hosted modules. That could be worth discussing as well, but better in a separate thread, I think. > > Is there any chance that upcoming releases could be signed? > > > > Cheers, and thanks for listening^W reading :-) > > > > -- > > ☛ Adrián > > > > P.S: A different topic (interesting by itself) would be having support > > for providing signed rocks/rockspecs, and that “luarocks install” > > would verify the signatures of the packages it is installing... > > > > [1] https://github.com/aperezdc/rockz/issues/2 -- ☛ Adrián
signature.asc
Description: signature
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________ Luarocks-developers mailing list Luarocks-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/luarocks-developers
