That’s exactly how individual artifacts are (and were) on PyPI. This change isn’t to artifact immutability, it’s to releases (collections of artifacts)
Yeah, I think that's the difference. In Maven, the entire set of files which compose a release is immutable. You can't add to or remove from the set of files once you've published. You have to release a new version if you want to add anything.
Interesting. I’ve only used Maven-format repos once or twice and always via somebody’s preexisting CI tooling. Is there essentially a “draft” release that you can edit repeatedly before hitting “publish”? Is that draft release visible externally as a pre-release, or only to the author?
There is indeed a "draft" release (I think they call it a "deployment"), but AFAIK your choice is then to either publish it or delete it. If you review it and it looks good, you publish it and can't change it thereafter (no changes to files, no adding new files, no removing existing files). If, however, you need to change something in the deployment before publishing it, you have to delete the deployment and create + upload a new "draft" release / deployment (can be same version number, since the previous "draft" wasn't published). AFAIK these "draft" releases are visible only to the author.
Depending on how you count, something like 96%, 94%, 65% or 87% of mainstream media employees lean left. Of course this matters less and less as customers tune out and their influence wanes.
Yes, educated people tend to lean left, since the right is so anti-intellectual. But virtually all media in this country (both social and legacy) belongs to the far right pedophile oligarchs currently running this country to the ground to fatten their pockets.
Days since last malicious packages in NPM: 0 (evergreen)
Days since last malicious packages in PyPI: 30
Days since last malicious packages in Maven: 120
I'm sure this isn't 100% accurate, and there are probably better metrics (average number of malicious packages per year, average number of developers affected per year, etc) but they aren't as easy as a quick Google News search.
Thanks for the link. However, a 7x size differential does not fully explain a 100x security incident differential -- although I'm sure it's part of it. Some of the root causes are very hard to address (e.g. a very limited standard library which encourages dependency explosions), some are just hard (e.g. established cultural norms around version pinning and upgrades, well-established reliance on install scripts) and some are easier (e.g. small tool improvements like min-release-age). I'm personally not going to touch npm with a ten foot pole in the next year or two, but I'd love to see significant improvement, so that I have that option again in 2 or 3 years. Stay safe!
The npm cli has bad defaults which you can turn off but they are there I presume for legacy reasons. The secure option is pnpm. The registry is fine.
Also on our comment about size differential ... it absolutely can.
If I jump from 2 meters hight it will be mildly uncomfortable. Jumping from 12 meters will result in severe injurious and possibly death. None of these things go linearly in real world conditions.
New PR: revert GitHub software and infrastructure to version of June 1st, 2018.
New PR: disable new user signups for 6 months
HR initiative: all future KPIs automatically require three-nines availability; all bonuses are forfeited, regardless of accomplishments, if annual availability falls below target
> Wake me up when the daily npm security breach headlines are typosquatting stories, not RCE-on-build or RCE-on-upgrade.
RCE-on-build/upgrade can be done in Maven if you manage to compromise one of the major Maven plugins, they run at build time. The thing keeping maven safe for now is that most people pin the plugin and dependency versions, with the obvious side effect that it's truly annoying to get all your dependencies updated.
> The thing keeping maven safe for now is that most people pin [...] versions
Yes, and also the signing of JARs that are uploaded to the repository, and the fact that most release processes are not fully automated, and the batteries-included standard library which reduces the total number of dependencies, and the fact that a run-of-the-mill third-party library can't execute code at build time, and the very small number of people with credentials to publish new versions of major Maven plugins, etc.
There are npm supply chain exploits in the news every other day. I'm honestly surprised that something as decentralized as Go Modules is more reliable, but here we are. The fact that we're not seeing these stories about e.g. Maven is not at all surprising, given the limited need for third party libraries and the culture of careful upgrades in the Java ecosystem. If npm proponents want the ecosystem to survive, they need to demand / create better and stop making excuses.
reply