Hacker News Reader

Comment by selrond | Hacker News Reader

This could solve the trust issues with npm - you never know, whether the package you're installing is really from the source provided on its npm page

View on HN

This is one of the things I love about Packagist. Technically Composer doesn't care where the source is from, but the official Packagist repository actually just uses Github as the storage and CDN for downloads. You have to link a repo to publish it, and Packagist will only publish source committed to your repo (no build steps, etc). Packagist then uses the zipball downloads for each package for it's source.

Downside of this approach is that almost any PHP project requires you to configure Composer with a personal access token for Github due to the amount of API requests causing rate limiting. Folks sometimes end up wondering why Composer needs an API token to download otherwise public code. (https://getcomposer.org/doc/articles/troubleshooting.md#api-...)

Composer/packagist has done many things right: namespaced packages, and downloads straight from VCS to name a few.

I wouldn't consider the Github personal token to be an issue either. It's a one-time setup per device, and my server (which only pulls code) never needed one, because it uses the lock files to download the exact commit/tag, and this significantly reduces the number of API calls made.

If you can just point at the github registry, and run `npm publish`, does that really solve the problem?

NPM's major problem is there's no official link between the package and the repo, any code/branch can be published, and unless I'm missing something, this doesn't really solve that issue.

OTOH GitHub is already in the position to require that only accounts that have 2-factor auth enabled can publish to public repositories. You can already require on organization level that only users who have 2FA enabled can be members of the org, which is great feature for orgs that host private code on GitHub.

AFAIK most cases where npm etc. have been compromised are scenarios where maintainer of a popular package re-used a password, and the password became compromised in some unrelated hack. Other attack vectors (compromising access tokens on maintainer's computer, compromising 2FA, compromising a git repo) really are a notch harder.

Even if these hacks are not the fault of npm per se, they make them look bad, and looking bad security-wise is really really something you don't want to happen to you when your whole business model is founded on user trust (public package repo).

There can be a link, if you prefer to write your dependencies down that way in package.json. See Git URLs¹ and GitHub URLs².

There are some challenges, though. If the repository requires a build step to derive a package from it then the author has to provide the proper package.json lifecycle hooks, e.g. a prepare script. Also, there's presently no git/hub-install support for a package nested inside a monorepo.

¹ https://docs.npmjs.com/files/package.json#git-urls-as-depend...

² https://docs.npmjs.com/files/package.json#github-urls

Not big challenges though.

A simple tool like https://github.com/andreineculau/npm-publish-git does the job (it's regularly used and tested within my current company TobiiPro https://github.com/tobiipro).

We publish npm packages to git tags that get installed exactly the same as packages received from a registry, no build step necessary.

That does not change with this github registry. It's simply moving the binary storage. But as long as Github is not enforcing reproducible builds, or letting users pulling down build environments, the statue quo is still the same as today.

Unless they require code signing, how does this help trust issues?

They can create a special kind of Authentic GitHub signing that guarantees that the source you see is responsible for the binary being downloaded.

Code signing is a different sort of trust issue, in this case if the package file is coming from the same github repo page as the source code, you know it (AFAIK) had to come from someone with write access to the repository.

vs having an npm package named (for example) nodejs, are you sure the npm package is authored by and owned by the same person or people that own the nodejs git repository? How do you verify that?

There are many problems this doesn't solve of course but it does seem like it helps with the one I describe above, the connection between the source and the package.

Unsolved problems of course would include things like 'did someone get unauthorized access to the git repo and put an artifact there' and 'did someone with unauthorized access push code to the repo and then have an artifact built'. Those are tough and real problems but I don't know if that's any different between this and say, npm. Code signing Helps with that but you have the same unauthorized access problem if some bad actor gets their signing key instead of repo access.

> How do you verify that?

I think if they required a user or org-namespaced package name, you'd get that. For example, if https://exiftool-vendored.js.org was `@mceachen/exiftool-vendored`, or `@photostructure/exiftool-vendored`, it's explicit, in the package name, who you're trusting.

> ... did someone get unauthorized access ...

If they required publishing to be via 2FA-authenticated users, and (if I can dream), GPG-signed commits, I think you get most of the way there.

Github is starting greenfield here, and it's frustrating they didn't (at least afaict) require these small steps.

When I'm looking at a given package, I'd like:

1. Assurance that the package was published by the author 2. Assurance that the package contents were generated, in an externally repeatable way, from a release tag.

It seems like they could have lifted 1. by requiring 2FA and GPG.

It seems like their new Actions tab could have given us 2. It may, I can't tell from the demo.

And when I update my dependencies, I also want to see the diffs from the version I'm updating from. Github already has nice comparison views for arbitrary commit shas, so this should be doable as well.

Basically because it's all just github, the package author and publisher are intrinsically linked because the package repo is directly associated with the code repo. In NPM, there is not any way to directly ensure the publisher and package author are the same because they're different systems.

Reply on news.ycombinator.com