Good to see them catching up on GitLab in terms of features.
GitHub Package Registry
51–60 of 389 posts
Re: GitHub Package Registry
#52This 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
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).
Re: GitHub Package Registry
#53This is really outstanding. It will mean the death of Maven Central, about which I have mixed feelings. On the one hand, Sonatype deserves enormous thanks for what they have done for the open source world, as does mvnrepository.org. Their central repository has been free and maintained for a long time. Thank you, Sonatype. On the other hand, it took me three days to release a new version of one of my artifacts the ot…
Hey Microsoft, if you're listening, you should throw Sonatype or other Maven-related organizations a few bucks. They deserve it.
Re: GitHub Package Registry
#54While the technical side of the news is interesting, the organisational repercussions worry me. Microsoft (who owns GitHub) is already one of the largest tech companies, and I would not be surprised if this move was intended to weaken NPM and Docker in an attempt to acquire them.
I fear a future where everything one requires to develop "socially" depends on a single super-entity. GitHub and VSCode were the first steps in that direction, and now package management. My guess would be for CI/CD to be next on their list, with more integration of Azure somehow (potentially under the hood).
Re: GitHub Package Registry
#55Do I want to use Github for this? I kind of like the npm model where they say "don't cache it, we guarantee as much capacity as you want to re-download packages". I use a lot of go modules, and each of our container builds ends up fetching them all. Github rate limits this and you have to either vendor the modules or provide a caching go module proxy (Athens, etc.). Meanwhile, npm just uses Cloudflare which seems hap…
The blog post says something about serving via a cdn. Are they also rate limiting?
Re: GitHub Package Registry
#56So what happens when a package on npm depends on a package on Github registry or vice versa?
The same way it works today when you utilize packages from multiple repositories. Github isn't the first non-npm repository in existence.
What if they clash (eh user/package exist both on npmjs.com and GitHub)? Does it go through each of the configured repositories in sequence looking for a match?
Re: GitHub Package Registry
#57I'm disappointed it doesn't support Python. There's not a lot of options available for private Python package hosting, it would have been good to have another one.
jfrog's artifactory has nice support for python https://www.jfrog.com/confluence/display/RTF/PyPI+Repositori...
Re: GitHub Package Registry
#58This 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
Unless they require code signing, how does this help trust issues?
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.
Re: GitHub Package Registry
#59If/when they add a build service (like Bitbucket Pipelines), they have a golden opportunity to provide a strong guarantee that a package was built from a particular Git commit (i.e. the source code wasn't modified to add malicious code). That would make me feel a lot better about using pre-built packages.
Re: GitHub Package Registry
#60Earlier quoted context omitted.
Unless they require code signing, how does this help trust issues?
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?…
> 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.