chore(deps): update dependency semantic-release to v19 [security] #22238
Conversation
![renovate[bot]](https://avatars.githubusercontent.com/in/2740?s=60&v=4){kind=small}
renovate
bot
requested review from
jennifer-shehane
and removed request for
a team
|
See the guidelines for reviewing dependency updates for info on how to review dependency update PRs. |
|
Test summary
Run details
View run in Cypress Dashboard ➡️ Flakiness
This comment has been generated by cypress-bot as a result of this project's GitHub integration settings. You can manage this integration in this project's settings in the Cypress Dashboard |
||||||||||||||||||||||||||||||||||||||||||||||
|
Hmm seems this update is not compatible, maybe we should go to semantic-version 18 before 19. |
Autoclosing SkippedThis PR has been flagged for autoclosing, however it is being skipped due to the branch being already modified. Please close/delete it manually or report a bug if you think this is in error. |
jennifer-shehane
requested review from
a team and
AtofStryker
and removed request for
jennifer-shehane and
a team
|
Seems v18 is also not working out of the box (need some code changes, I guess). |
|
@lmiller1990 I took a quick look into this and looks like the only breaking change with v18 was requiring minimum node 14 support, and v19 dropping node 15 all together. Since we install node 16 in CI it shouldn't be an issue, and judging by the CI failure it looks like we just need to bump |
…/npm-semantic-release-vulnerability
|
@emilyrohrbough @lmiller1990 I had to update the cli_spec to include handling obscured internal error codes for version > node 16 / npm 8. The script still fails as expected, so the behavior is correct, but find it a bit weird that the child process node version changed in the lock just from this PR. Looks like this has been a problem in the past based on initial commit and the test should now have enough flexibility to pass. I also verified that exit code 10 does happen in node 14 / npm 6, and does actually become exit code 1 in Node 16 / npm 8. |
|
What do you mean by
I looked at the lockfile, but I'm not sure what I'm looking for. If you run yarn locally, does the same lockfile get produced? Sometimes these bots seems to manually edit the lockfile, which is weird - we should let yarn generate the lockfile. Strange on the exit code changing... I love keeping deps up to date, but seems this particular one introduces a bug 🤔. I wonder if this is even the latest version, or has this been seen elsewhere? |
When I run Seems more of a presentation thing, but I can't find it documented anywhere. Based on the code, it looks like this was the case in npm 4 and below (return 1 instead of 10), but was different in 5,6, and 7. And it 8, its back to returning 1. If I run the following with Node 16, / npm 8, it exits with code 1:
But in Node 14 / npm 6, it exits with code 10: Both provide the behavior we would expect though, which would be for the code to critically fail. I cannot seem to find any decision around this as to why this change happened, but I think we should be safe on our end. |
There was a problem hiding this comment.
@AtofStryker thanks for clarifying - seems semantic release have some under the hood changes. I agree that as long as we error out, we don't care too much about the specific code. Let's ship!
|
Green except one windows CI that is flaking all over the place. I will look at it right now, but I do not think this could possibly have caused it, so I'm going to merge. |
…esser/CLOUD-577-spec-list-display-latest-runs-batching * muaz/CLOUD-577-spec-list-display-latest-runs: test: Addressing launchpad test flake in Windows (#22536) address comments from @marktnoonan Address code review comments followup on other comments re: @lmiller1990 PR comments chore(deps): update dependency semantic-release to v19 [security] (#22238) chore: Address skipped specs in server package (#22356) Address code review findings Address code review findings Empty-Commit to generate new percy nonce fix: handle case of implicit plugins/index.js files during migration (#22501)
This PR contains the following updates:
17.2.3->19.0.317.4.2->19.0.3GitHub Vulnerability Alerts
CVE-2022-31051
Impact
What kind of vulnerability is it? Who is impacted?
Secrets that would normally be masked by semantic-release can be accidentally disclosed if they contain characters that are excluded from uri encoding by encodeURI. Occurrence is further limited to execution contexts where push access to the related repository is not available without modifying the repository url to inject credentials.
Patches
Has the problem been patched? What versions should users upgrade to?
Fixed in 19.0.3
Workarounds
Is there a way for users to fix or remediate the vulnerability without upgrading?
Secrets that do not contain characters that are excluded from encoding with
encodeURIwhen included in a URL are already masked properly.References
Are there any links users can visit to find out more?
For more information
If you have any questions or comments about this advisory:
Configuration
📅 Schedule: Branch creation - "" in timezone America/New_York, Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Renovate will not automatically rebase this PR, because other commits have been found.
🔕 Ignore: Close this PR and you won't be reminded about these updates again.
This PR has been generated by Mend Renovate. View repository job log here.