From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Gerwitz Subject: Re: NPM and trusted binaries Date: Thu, 08 Sep 2016 20:31:54 -0400 Message-ID: <8760q5j4lh.fsf@gnu.org> References: <87shtiz8f7.fsf@gnu.org> <877farzrdl.fsf@gnu.org> <20160906165048.GC18454@thebird.nl> <87bmzzkt2d.fsf@gnu.org> <87eg4uwzi2.fsf@gnu.org> <87y432jo2b.fsf@gnu.org> <877famw4jn.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:35285) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bi9k6-0005EG-JS for guix-devel@gnu.org; Thu, 08 Sep 2016 20:32:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bi9k4-000060-8O for guix-devel@gnu.org; Thu, 08 Sep 2016 20:32:29 -0400 List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Jan Nieuwenhuizen Cc: guix-devel --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, Sep 08, 2016 at 21:54:36 +0200, Jan Nieuwenhuizen wrote: > The question I'm trying to answer is: how does `a user' who builds a > package from the repository install the needed dependencies. Sorry, I misinterpreted. `npm install ' will by default install all devDependencies; the `--production' flag suppresses that behavior. Many packages define a command to be run when `npm test` is invoked, which would in turn need the devDependencies to run the test suite. > I very much doubt that users install the essential dependencies all by > building those from the source repository. How would they do that? No, they don't. I'm not sure if it's even possible with how npm works, though I haven't done that sort of research. But that'd be Guix' responsibility---just because npm doesn't offer a way to do that doesn't mean that Guix can't, provided that there is an automated way to track down each of the packages and determine how they are built. Some might use Make, some Grunt, nothing, etc. > My working hypothesis is that it's impossible to do so for any > moderately interesting npm package. And I would very much like someone > to show me (with working code) that instead it is possible. I'm hoping such code is precisely what this project produces. :) > what the benefits are (in terms of software freedom) of spending our > energy by upholding the source/binary metaphor (even if for a majority > of packages there may not be a difference). As I mentioned, I don't see a difference between this situation and packaging other software that has no distinction between source code and "binary" distribution. It's just a hell of a lot more complex and the package manager used to manage these packages (npm) doesn't care about these issues. Corresponding source code must include everything needed to build the software, and must be the preferred form of modifying that software. This assumption cannot be made with the state of the packages in the npm repository. Some of the files might not even be in the source repository (e.g. generated). I have great faith in Guix and its mission; it would be a shame to see that tainted by something like this. Normally someone will look over a package manually before adding it; but mass-adding thousands of packages in an automated manner is even _more_ of an argument for the importance not trusting binary distributions. With all that said, I have no idea how it'll be done. Someone could just add any old file to the published npm package and never commit it to any source repository. I've done that accidentally. I don't know how you'd handle situations like that. I don't know how you'd handle a situation where a build script doesn't even work on a machine other than the author's. I don't know how you confirm that the software produced from a build will actually be the same as the software normally installed when you invoke `npm install `. If a package doesn't build from source, contain all the necessary files, etc, it's not practical to exercise your freedoms, and so including it would be bad. But if one dependency out of thousands has that problem, then what? If one of the dependencies happens to actually contain non-free code, then what? When I evaluate software offered to GNU, I have to consider each and every dependency. This usually isn't a difficult task---many libraries are standard, have already been reviewed by a project like Debian, and there's rarely more than a few dozen of them. I then build it from source. If I have the packages on my system (Trisquel at present), I know that they're free and can be built from source. Otherwise, I must compile the library myself, recursively as needed for all dependencies (which is usually not an issue). If any of those were a problem at any point, then the whole of the project is a problem. If any of those dependencies are non-free, the whole of the project is non-free unless it can be swapped out. If one obscure library requires several dark incantations and a few dead chickens, users can't practically exercise their freedoms, and that would be a problem for the package. Now how the hell is this enforced with thousands of dependencies that have not undergone any review, within a community that really couldn't care less? Even something as simple as the license: package.json has no legal force; it's _metadata_. I feel like this will have to be manually checked no matter how it is done; any automated process would just be a tool to aid in a transition and keeping a package up-to-date. I don't really see any other way. So I think that I share in your concern with how such a thing would possible be done. My point is that if it can't, it shouldn't be at all (where is where we differ). =2D-=20 Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: 2217 5B02 E626 BC98 D7C0 C2E5 F22B B815 8EE3 0EAB https://mikegerwitz.com --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCgAGBQJX0gL6AAoJEPIruBWO4w6rAMEQAJX/ky35krlZ7M3InBlpbPx8 iKrHO6TuWt/G6Q3RJhMxa3QDQ63PUSbZ1znJLECFY98oJ7LXBcCJg/WEONW5VLoE D5+3zW2O8U8EHUCu4RsHO0gCuiADkudBdkBlcpOKjt6O3Of9L0MNdDt0tboreKDU vLDveodm3WwkGYp6yu15K0Ox3m7/sp+KA8O1UY3hTFwzW9gjeYZNGLNBW0ivnNVj GyBzTOhv2JJpVkMGb3nyvGWcNDBr7SJ3GE7NDoFvGgB5CH8J37tX/CzSoys2Aqa0 h66m48bK2oWlyv9jdJsLKzHKH7RJZlK5fwS27kDk6axg8TZqU8G1SnCGmh9UB8i7 +zUNbRTSckwRQ0+n1NygWr7m9qcDEOH6gwf3nJE++3frnM/SgOZM4M9WsQtGubin wfKUWu3rruh/c3QUtGr2pORKZK43knEGr6W4eNR19Mwpb+VyGwGPHLJZFTwxJzVx vNOUEPG8RkQGTFEzu76e0ZNo/idTMcVt8TutlpnN4DvnTn1zQ6HKoe4dzYEOv+1c AV2UavGX/RXB8Fw0lvO0IyxzDfH4ROCCTyns+7Aw2Fm0tU2Uh0bpX3S8q9Vfd84G sE9Uk1GlvmKmUuKlLGK0bGXQUbr2HtLylJEdKUh+RPs1ITFOyaiK+tHt9Z9T4ErA axMCZqT1Gz1ZNaGh54Hl =+zFo -----END PGP SIGNATURE----- --=-=-=--