Skip to content
New issue

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

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

Already on GitHub? # to your account

Address security concerns from community #43

Closed
7 of 8 tasks
vweevers opened this issue Dec 8, 2018 · 9 comments
Closed
7 of 8 tasks

Address security concerns from community #43

vweevers opened this issue Dec 8, 2018 · 9 comments
Labels
discussion Discussion security Vulnerabilities and other security-related matters

Comments

@vweevers
Copy link
Member

vweevers commented Dec 8, 2018

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: Add and remove npm owners #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.

@juliangruber
Copy link
Member

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

@ralphtheninja
Copy link
Member

level-graveyard? :)

@vweevers
Copy link
Member Author

vweevers commented Dec 9, 2018

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.

@vweevers
Copy link
Member Author

vweevers commented Dec 9, 2018

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.

@ralphtheninja
Copy link
Member

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

@vweevers
Copy link
Member Author

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..

@vweevers vweevers added the security Vulnerabilities and other security-related matters label Jan 1, 2019
@vweevers
Copy link
Member Author

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

@ralphtheninja
Copy link
Member

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

🆗

@vweevers
Copy link
Member Author

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

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
discussion Discussion security Vulnerabilities and other security-related matters
Projects
None yet
Development

No branches or pull requests

3 participants