Module maintenance

[Zertz]

@dodo

With over 60k downloads per month and nearly 550 stars, I think the community has shown we love the work you've done! :heart:

That said, if you would like help with this module's maintenance, I'd be willing to triage issues and pull requests.

---

I have created a fork with support for Node 6 and various other changes.

[Trott]

@Zertz Do you still have an interest in assisting with the maintenance of this package?

[Zertz]

Hey 👋

Sure thing, your module still gets a sizeable amount of downloads and we could probably merge our efforts. The fork I made is still heavily based on your work with a few fixes and minor breaking changes :)

[Trott]

Sure thing, your module still gets a sizeable amount of downloads and we could probably merge our efforts. The fork I made is still heavily based on your work with a few fixes and minor breaking changes

Hi! It's not my module (except in a narrow technical and hopefully temporary sense--read on) and certainly not my work! But I now "own" it on npm. Here's how this all happened:

For unimportant reasons, it came to my attention that:

• The module had a publicly-disclosed ReDos vulnerability in it.
• The module received over 100K downloads a week from npm.
• The module had not been updated in something like 4 years.
• PRs and issues about the vulnerability (and anything else) did not seem to get attention from the maintainer.

I reached out to the maintainer (@dodo) to see if I might get publish access on npm. At the same time, I reached out to npm support to explain the situation. After a couple weeks and a few attempts to get in touch with the maintainer (using two different email addresses), neither npm support or I received a response. So npm support granted me publish access to the module. (I do not fully understand their internal process on this, but it is surely not in the ecosystem's best interest to have unmaintained vulnerable modules unpatched forever, so I hope this is, at least from a macro-view, seen as the good thing I believe it to be.)

I released the patched version but don't really have plans or interest in maintaining the module beyond that.

I, of course, have no idea why the maintainer is unreachable and I wouldn't read much into that. Maybe they are no longer on the internet. Maybe all the email went to their spam folder and they never saw it. Maybe they have some important life event they are attending to and managing slug just isn't a priority. Maybe they're on vacation. If @dodo comes back at some point and says "WTF, I want my module back", I fully intend to hand it back.

However, that said... if you're already maintaining a fork in a reasonable and responsible way, it may be a Good Idea to give you publishing access on npm. You can release 1.0.0 (I'd prefer nothing else happen in the 0.x line except security fixes) and go from there.

One thing I don't have is publishing access to this GitHub repo. So currently, the repo I'm using is my fork (https://github.com/Trott/node-slug). I'm trying to find out if GitHub has a process like npm that allows others to take over stale/unmaintained repos. I'm not sure if they do, and if so, I'm not sure what kind of vetting process they have for it. Until that's sorted out, we could keep using my fork, or maybe move to your fork if it hasn't diverged too much. (My fork's master branch only has two commits not in this repo: The bug fix and the version bump.)

Thoughts?

[Zertz]

Thanks a lot for going through the whole process of fixing the security issue and taking ownership 😃

I'm not exactly sure either how, or even if, GitHub handles transferring ownership. Perhaps publishing rights on npm is sufficient and we can keep the fork under your username or even give ownership to a JavaScript organization of some sort.

As for the technical side of things, I maintained a fairly detailed changelog for mollusc and there's nothing major that would stop users from upgrading. The breaking changes are arguably fixes for some odd behaviors.