I don't think so at all. People go on vacation all the time. This should be 30 days not 3.

> Sorry, if you are unwilling to take 10 minutes to learn how to sign your code, you have no business maintaining software releases millions of people depend on. Full stop.

The crux of the problem is right here.

Who chose to depend on "foreach"? Millions of ill-advised people did. The author did not choose that.

In my opinion, things like scanners should not need to exist if npm's parent company, GitHub, were to take responsibility for what was published to npm. If Walmart sells you an item that ends up being a handgrenade there would be hell to pay. In this example, Walmart cannot simply say that Walmart is not in charge of what goes into the item and therefore "buyer beware." Yet, this is precisely what GitHub does with every npm package.

One reasonable approach is to increase the scrutiny for new releases based on how many active downloads of the package there are. So for new packages, maybe there will be not a ton of scrutiny, but for things that are downloaded by millions of users, like Axios, there would be significantly more scrutiny per release.

The epidemic of "not my job" and "[we] don't get paid to do that" is a large contributor to why the world is so messed up. I don't know what to call this phenomenon. In the Hawaiian language there is a word Kuleana which means "sacred responsibility" or "sacred task." If more people took on their Kuleana joyfully we would be inviting the ideal [realm] more rapidly.

I agree that benefits come from fine-grained permissions; however, for the fine permissions of user authentication (and API authentication), I think it would help to use X.509 certificate chains. The certificate can include a extension for specifying the permissions that it grants (a permission will only be granted if all certificates in the chain grant that permission). This avoids needing to login or use 2FA in order to set up new API keys or access tokens, and prevents problems with misauthentication with the wrong server (personal access tokens don't help much compared with passwords, but X.509 does help). Merely using X.509 won't cause it to have fine-grained permissions, but they can be combined in the way that I described. (This use of X.509 can also be used to allow someone else to operate on your behalf with limited permissions; in this case, a client would issue a certificate to a server, and that server would then also be a client to GitHub.)

If there is a broken design of GitHub Actions, that is another issue, and neither TLS nor X.509 is the issue with that. (Also, GitHub Actions could hopefully be made to allow finer permissions if the existing permissions are not fine enough; that is not related to X.509 at all.)

Avoiding too many dependencies, is another thing to do.

And, signed releases is another thing to do, and is helpful for additional reasons (unrelated to authentication with GitHub, but useful for knowing that you published it rather than someone else (without having to trust GitHub with it)). The key used to sign the release might or might not match that in the X.509 certificate used to authenticate with TLS; there are some benefits if it does (such as if you have published your certificates that someone else can check, or your mention of Yubikey), but it doesn't have to (e.g. because you have multiple certificates, because multiple people are publishing releases, because you have some other reason to not use the same certificate for the other purpose, etc).

> "npm is by far the worst thing about NodeJS"

I'll come and add: "after JavaScript".

Which is why automated signatures in release pipelines are usually meaningless. Authors must sign their code on their own hardware before it is published so we can tell when the signing key changes and pay extra special attention to that, and maybe a longer delay.

[flagged]