Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Maintenance of this library #36

Open
natevw opened this issue Jan 19, 2021 · 12 comments
Open

Maintenance of this library #36

natevw opened this issue Jan 19, 2021 · 12 comments

Comments

@natevw
Copy link
Collaborator

natevw commented Jan 19, 2021

A bit of recent activity here (posed as a feature request but after reading more carefully I think just needed some help using existing functionality, or consider the older #33 idea for example, but regardless…) has me thinking about the maintenance of this library.

Context: I seem to have ± inherited it from TJ years ago, at least I am able to push to this repository (though not change settings on it) as well as publish releases on npm, and I seem to be the only one proactively responding to discussions here. So afaik I am in practice the only current maintainer.

This isn't a huge problem, since my vision for this particular library is that it remain a simple, stable, secure piece of reusable code. The easiest way to do that has been to simply not mess with it unless/until another security issue ever comes to light. So I answer the occasional question or address a maintenance issue every now and then but that's it. So I'm happy to keep doing that, but it's not an ideal situation for the users of this library.

  • As an open source project it should be more responsive to the hopes and dreams of its users. Even if this library is already in an "actively finished" state it doesn't seem right for me to make that declaration unilaterally.
  • as critical infrastructure it should have more formal review/release process, vulnerability disclosure point-of-contact, etc. etc.

I think it'd be good for this library to find a more "sustainable" home this yearone of these years!

IIUC, the https://github.com/senchalabs/connect project (and therefore also the https://github.com/expressjs/express project?) still rely on this library as a critical piece of their session-handling infrastructure. Assuming TJ would be on board, I wonder if this repository could be moved to one of those accounts and be maintained under the umbrella of one of those communities?

@natevw
Copy link
Collaborator Author

natevw commented Jan 19, 2021

I'm not sure if I can tag @dougwilson from this project, but it looks like he is listed as the lead maintainer for both Express and Connect (and has been previously involved in some maintainance "growing pains" on this library already).

Otherwise the next step might be to get input from https://github.com/nodejs/security-wg and/or https://openjsf.org/ to see if they could recommend a path forward.

@dougwilson
Copy link

Hey, you are able to tag me no problem :) Yes, Express/Connect do still actively use this module, mainly as part of the TJ legacy, and also in part due to just the desire to use various small libs, especially when they have a discrete purpose (like this one).

If it's needed, I am happy to lend a hand how you see fit, even if it is just subscribing to the repo and trying to help out responding to issues and PRs.

The Express project (and it's three orgs expressjs, pillarjs, jshttp) are under the OpenJS foundation if that is more what you are looking to do.

But if a module that we are currently is looking for help, I am happy to lend a helping hand, however you see that carrying out :)

@natevw
Copy link
Collaborator Author

natevw commented Jan 19, 2021

Ah, great, thanks for chiming in so quickly Doug! I guess my main question is whether there's a more formal "foundation" and/or process that could adopt this library assuming TJ is willing, or if we should simply ask him to give you the same collaborator and npm access as I currently have (e.g. in case something comes up while I'm on vacation)?

@dougwilson
Copy link

So I can't (and wouldn't want to) speak for TJ regarding what he wants to do, but as far as just different possibilities around "reownershipping" the module:

  1. I have seen the nodejs org (which is part of OpenJS Foundation) bring in a few modules somewhat recently.
  2. It could possibly live under the Express.js project somewhere; it's a little bit outside what that project does at it's core (signing / unsigning is more crypto- than web-oriented), but I can help there if you really want it.
  3. There are a few generic orgs we have put things into as a general collab location as well; the crypto-utils org would probably make the sense for this module. The down side here is it is not part of any kind of organized foundation or anything.
  4. If just adding like myself as a collab to the repo to help is desired, I can certainly do that too (npm access can technically be granted by anyone else who has npm access using npm owner add).

I do see this is in the tj account vs the visionmedia account, so any administrative actions on the repo would need to be handled by TJ.

@natevw
Copy link
Collaborator Author

natevw commented Feb 17, 2022

@dougwilson I'm still interested in finding a proper home for this library, but in the meantime as a practical matter could you help me get a second set of eyes on #41 — whether that be your own review, or tagging someone else in the Express circle who could take a look before I merge and publish?

[I'm also looking for confirmation on #33 that allowing Buffer instead of only string for the secret key would not be considered a breaking change semver-wise, but that's lower priority.]

@dougwilson
Copy link

Hi @natevw I'll take a look at both tonight (in the next general 4-5 hours) 👍 .

@natevw
Copy link
Collaborator Author

natevw commented Feb 17, 2022

Thanks @dougwilson! I've just published 1.2.0 with the bugfix and secret key improvements.

Administratively, I also configured a missing 2FA requirement on the npm package, and added you as a maintainer there too just in case.

(I do not have any access to any of this repository's settings here — so other housekeeping like default branch name or even reviewing/adding who can merge/push are still in limbo. I'm assuming we could ping TJ if need be, but my own thinking is that we'd have a specific proposal for transferring the repo to e.g. @expressjs or some official new maintainer first.)

@wesleytodd
Copy link

wesleytodd commented Jul 27, 2024

Hey @natevw! We have recently undergone a bit of a changing of the guard in Express. @dougwilson has been a phenomenal steward these years, but this is not a job for one and he has handed most of the operations to a (partly) new TC group (who will welcome him back any time he wants). Specifically one of the goals we have is to distribute the work so that we don't burn out our awesome maintainers. So if you are interested, we would love to move this package into the org and you along with it. No added responsibility or expectation unless you want it, but the group is pushing for a v5 release of Express soon, which updates a lot of these dependencies. If you are interested in participating let me know and we can figure out the details to make it happen.

@natevw
Copy link
Collaborator Author

natevw commented Aug 12, 2024

Thanks @wesleytodd, that sounds great. I'd personally love to get this closer to the main Express project so that community can drive its development (and/or stability) in a bit more accountable fashion than just me watching this repo! 👍

I should note that I do not have any admin access to this repo itself, I can merge PRs and maybe do a bit of issue moderation but I can't add others or transfer ownership or anything. For that we'd have to either contact @tj or just manually "redirect" people to a fork via the README.

@wesleytodd
Copy link

Hey! Yeah I understand the constraints, I too have "taken over" projects like this in the past. Do you have npm publish rights? I think if you have that we can do the manual migration, if not we need TJ (or someone with admin) anyway and so it would be best to do it all the "right" way.

@natevw
Copy link
Collaborator Author

natevw commented Aug 15, 2024

Do you have npm publish rights?

Yes: TJ, Doug, and I are all "maintainers" on the npmjs side of this package 👍

@wesleytodd
Copy link

Awesome, well then @tj would you be able to innitiate a repo transfer to pillarjs? If we don't hear back by next week we can just push the code over and add you @natevw as a contributor and then move the npm package into our npm org (again adding you as a publisher).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants