Level / community

Discussion, support and common information for projects in the community.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Address security concerns from community

vweevers opened this issue · comments

In light of the recent event-stream incident, we (@ralphtheninja and I) want to take action to reduce the attack surface of packages maintained in Level.

Level has been and will remain an OPEN Open Source Project. While we recognize the risk of giving people owner rights, it has been vital to the open, transparent and dare I say loving nature of Level. We might add some policy, if it really benefits security. Keep in mind that too much policy can scare off contributors, put a burden on maintainers and provide a false sense of security, hiding real issues that are out of our control under a layer of bureaucracy that in addition impedes individual freedom.

Trust is essential in OSS and we want to be wary of knee-jerk reactions to incidents like event-stream.

That said, we are thinking about what we can do and open to any suggestions. After an initial brainstorm we came up with 3 actionable items and wished to move further discussion to GitHub for community input and transparency.

1. Reduce npm owners

  • Our npm packages have more owners than needed for continued maintenance. Go through the list of current owners and ask if they really want/need publish rights: #17.

2. Reduce GitHub organization owners

  • We have quite a few inactive members. We will ask them if they can be removed and list removed members as Collaborator Emeriti in a suitable place.

3. Archive unmaintained projects

Archival consists of:

  • Pinning dependencies (note: transient dependencies are out of our control)
  • Releasing a final patch version
  • Deprecating the package
  • Removing extraneous npm owners
  • Archiving the GitHub repository.

Candidates for archival:

Please edit the above list or leave a comment if you think one of these should not be archived.

1. Reduce npm owners

Our npm packages have more owners than needed for continued maintenance. Go through the list of current owners and ask if they really want/need publish rights. As a starting point, see #17 (note: that's only a partial list of owners).

I'm currently not invested in level packages so could drop owner, even if we decide at a later time it would be better to add back. I'm assuming this applies to more maintainers than me.

I would like to be part of the GitHub organization still though.

Also, +1 for archiving the unused repos, or moving them to a different organization, like level-userland or level-misc or level-community

level-graveyard? :)

I think it's fine to keep the repos here. If someone comes forward wanting to revive a project, we can then decide whether to move the repo elsewhere or stay involved.

What's a good message for npm deprecate <pkg> <message>?

  1. This project has been abandoned. There will be no further releases. If you wish to revive <pkg>, please open an issue (https://github.com/Level/community) to discuss a way forward. Thank you! (similar to the readme)
  2. This project has been abandoned. There will be no further releases.
  3. This project has been abandoned. Please see the README for more information.
  4. This project has been abandoned. Please visit GitHub for more information.

I prefer the first one. It's nice to have a link to go to for more information.

Hm, there's a downside to pinning dependencies of a package before abandoning it: when a dependency patches a vulnerability, it doesn't float in. You can't win..

Should we archive level-lazy-open as well? 0 downloads, 0 dependents, and superseded by deferred-leveldown.

Should we archive level-lazy-open as well? 0 downloads, 0 dependents, and superseded by deferred-leveldown.

🆗

The remaining task (reduce GitHub organization owners) is being handled and discussed privately.