Suggestion: Broaden to cover security patching any abandoned package about package-maintenance HOT 19 CLOSED

I think the focus of this group should be to adopt (popular) abandoned packages and keep them up to date.

from package-maintenance.

@mcollina I am also thinking the same that this group mainly focus on abandoned packages to be keep update.

from package-maintenance.

I think this is a loosing battle, and if the group decides to take this on as a goal it will be swamped with takeover requests. There are thousands (hundreds of thousands?) of packages in this state, and less than 100 contributors here. It is just too large of a task for this small of a group.

IMO, a better approach would be to work with npm and any maintainers who we can reach to find a way to indicate package SLA's, deprecation messaging (already supported in npm, just not widely used), who is looking for help and on what (already being worked on with with good first issue tagging), and adoption guidelines for modules. All of these are things we can reasonably take on and achieve meaningful change without taking over responsibility for code pushes.

Side note: Changing semver ranges is not a fix for unsupported packages, and we should not make a recommendation like this. Semver ranges can be an attack vector just like an unpatched package dependency. Evangelizing the pros/cons of different approaches is good, but blanket saying using a range fixes things is problematic. I have other opinions on this, but do not have the time to write them all out here, nor do I think this is the right place for such a discussion :)

from package-maintenance.

I think the focus of this group should be to adopt (popular) abandoned packages and keep them up to date.

For the reasons @ljharb wrote above "abandoned" packages are problematic. While this is a noble goal and one we could attempt eventually, I think we're setting ourselves up for disappointment if we make it a focal point right away.

Instead, we should look for quick wins at the outset. Or low-hanging fruit if you are fond of management nonsense. 😄

You'll find that in popular packages with active maintainers who want to work with us. For example: maintainers who want to provide long-term support for their packages, but just don't have the resources to do so (or even know where to begin).

from package-maintenance.

I don’t think this group has any “enforcement” in its scope at all - but certainly I’d expect educating authors to use ^ semver ranges as a best practice to be in our scope.

from package-maintenance.

That seems very different than the initial intention of the group - unless we’d get special dispensation from npm to take package ownerships, how would we be any different from what people already do in the ecosystem? (iow, people already attempt to take over abandoned packages; many of my own were obtained by asking the maintainer for help and being handed the keys since they weren’t interested in still maintaining them)

from package-maintenance.

Kudos to you @ljharb for taking over ownership on a number of occasions. But the system doesn't always work so smoothly.

As an example, there was a low-level logging utility which was/is a deeply nested dependency of karma (I can't remember the exact name). I didn't consider myself familiar enough with the detail of what it did to confidently take ownership. I suggested that the owners of the package that included it as a dependency could take ownership of it, but they were unwilling to because, like most OSS maintainers, they were volunteers and it's not their responsibility to take on other people's code.

So who's responsibility should it be? I agree that the issue is somewhat removed in it's mechanics, from what this group is about, but in spirit it's very similar I feel; improving users' confidence in the quality of npm platform by getting involved with the maintenace of its packages.

From a security perspective, I also think it'd be an improvement on the current model. You have taken over some packages ethically, but what's to stop a malicious actor finding an abandoned package, applying for ownership, and inserting some malicious code. Wouldn't it be good if, rather than being transferred to the first person who asks the disinterested owner for the keys, there was a pool of security vetted npm maintainers who could be called in? People like you, who are keen to take ownership, could still contribute by joining the pool.

from package-maintenance.

Unless npm and GitHub are willing to hand over access to someone who isn’t the original owner - both of which i doubt, even to an “official” group - this group will have no more ability to effect change of ownerships than an individual developer directly asking the owner.

from package-maintenance.

There's no need for github to get involved - the repo can be forked, and package.json's repository field changed to point to the fork
And npm already forcibly hand over access to new owners if certain criteria are met. If anything, this proposal introduces more governance to that process as the ownership is transferred to a known group rather than to a relatively unknown individual

from package-maintenance.

That would have to be a proposal to npm, tho - that’s not something node has authority over.

from package-maintenance.

I obviously don't understand the organisational structure of node/npm 😞. I still think that it's a big problem that needs solving through some collective action from the nodejs/npm community, and this group is the closest thing I've come across to setting something up that could help with solving the problem.

On the one hand, npm are the managers of packages, so yes, keeping dependencies up to date in the entire ecosystem is their domain. But it's a shame if there's no room for community initiatives to transparently span the two projects; I doubt most users view nodejs and npm as distinct projects with distinct communities

from package-maintenance.

How users view them doesn't change that they are distinct; and there's definitely cooperation.

However, typically, a thing is either a node feature that needs npm help, or an npm feature that needs node help - this would be more the latter.

from package-maintenance.

I agree we need to start small, address the low-hanging fruit and figure out some well scoped issues that we can address to get rolling. @wesleytodd suggestion to help surface information, developing guidelines and helping guide people to where they can help is a good way to get started.

from package-maintenance.

We discussed this in the initial meeting and I think we agreed that trying to take on "security fixing" is out of scope at least initially. While we might be able to adopt some small set of packages and include some patching we are not going to be able to do it for all packages. @wheresrhys would it be ok to close this issue and then once things are further along we could open new issues to explore this concept if/when we believe there is sufficient capacity?

from package-maintenance.

Thanks for following up. Yes feel free to close

from package-maintenance.

@wheresrhys thanks, closing.

from package-maintenance.

I think the major (at least minor) version of the package which owner will be changed should increase by force, and the package can never publish lower version patch.

from package-maintenance.

@LongTengDao that would both have to be implemented by npm (and is thus out of scope here) and would make the ecosystem much worse, by disallowing important fixes to be backported to earlier major or minor lines.

from package-maintenance.

@ljharb Sorry and thanks for notice, I didn't differentiate node and npm.

from package-maintenance.