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

Block publishing of Semaphore TS/JS packages if their deps contain security alerts #922

Open
jacque006 opened this issue Dec 12, 2024 · 1 comment
Labels
devops 🔧 Operations management and dev tools

Comments

@jacque006
Copy link
Contributor

Describe the improvement you're thinking about

Modify https://github.com/semaphore-protocol/semaphore/blob/main/scripts/publish.ts or add prepublish script(s) to fail if npm audit (yarn npm audit) returns security vulnerabilities that are >= High..

Many of these issues are likely not relevant (only apply to servers, only specific components, etc.), but it would:

  • Increase confidence of package consumers during installs/updates
  • Prevent adding/updating of deps with known vulnerabilities

It would NOT:

  • Prevent Semaphore packages with discovered dep vulnerabilities post-publish. npm-deprecate could be useful here, as well as Dependabot (below).

Describe alternatives you've considered

  • Leave as is, accept the risk.
  • Rely on depandabot

Questions

  • If one package has alerts but others do not, should all the publishes fail (atomic) or only those with alerts?
  • Should there be the ability to override the alert blocking publishing, say if a critical fix needs to go out? Is there a need to suppress specific alerts?
    • Can always comment out this check in the publish script/package JSON.

Additional context

#920 (comment)

@cedoor cedoor moved this to ♻️ Grooming in Semaphore Board Dec 13, 2024
@cedoor cedoor added the devops 🔧 Operations management and dev tools label Dec 13, 2024
@0x471
Copy link

0x471 commented Dec 28, 2024

  • I suggest implementing atomic failure for simplicity and security integrity. This approach can be revisited later if it turns out to be too restrictive.
  • Introducing an override flag (for example --force) for critical fixes seems practical, better to be logged for transparency

Would be happy to work on this issue @cedoor. Please let me know if there's any additional context or guidelines I should follow.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
devops 🔧 Operations management and dev tools
Projects
Status: ♻️ Grooming
Development

No branches or pull requests

3 participants