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

Add automation for updating OpenSSL dependency #45605

Closed
wants to merge 2 commits into from
Closed

Add automation for updating OpenSSL dependency #45605

wants to merge 2 commits into from

Conversation

facutuesca
Copy link
Contributor

Add a Github Action that checks for new versions of the OpenSSL library, and creates a PR to update it if a newer version than the one present in the repo is found.

Refs: nodejs/security-wg#828

@nodejs-github-bot
Copy link
Collaborator

Review requested:

  • @nodejs/actions

@nodejs-github-bot nodejs-github-bot added meta Issues and PRs related to the general management of the project. tools Issues and PRs related to the tools directory. labels Nov 24, 2022
@facutuesca
Copy link
Contributor Author

facutuesca commented Nov 24, 2022

cc @RafaelGSS @mhdawson

1. Check the `CHANGES.md` file in the [repo](https://github.com/quictls/openssl)
for things that might require changes in Node.js.
2. Check the diffs to ensure the changes are right. Even if there are no changes
in the source, `buildinf.h` files will be updated because they have timestamp
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not related to this PR, but we should add a task somwhere to see if we can address this. Having it be more repeatable would be good.

exit 1
fi

command -v perl >/dev/null 2>&1 || { echo >&2 "Error: 'Perl' required but not installed."; exit 1; }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

again likely a follow on, but I wonder if we need to pin/capture what versions of perl etc was used. The same might be asked about the environment/os level in the action but. Not a blocker for this PR as we don't specify/fix those when people are running manually today.

Copy link
Member

@mhdawson mhdawson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@RafaelGSS
Copy link
Member

RafaelGSS commented Dec 2, 2022

I'm adding the labels to not backport it to versions that use openssl 1

Copy link
Member

@RafaelGSS RafaelGSS left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll review it properly tomorrow, but I believe is better to have a workflow_dispatch instead. At least I think we'll have more control on those updates. Wdyt @mhdawson?

@richardlau
Copy link
Member

This will only create one commit instead of two? I don't know if that will make the PR harder to review.

@facutuesca
Copy link
Contributor Author

This will only create one commit instead of two? I don't know if that will make the PR harder to review.

Are the changes manually reviewed? Since the update consists a copy-paste of an entire repo followed by regenerating config files programatically, the resulting PRs are pretty big. For example, the latest update in this PR #45309 has changes in 800 files, with +15,840-5,825 lines changed.

I ask because the current CI workflow for creating PRs to update dependencies assume that all dependencies will be updated using a single commit. If there's value in having two commits for OpenSSL we can do it, but it will require modifying that workflow to have a special case for OpenSSL separate from the rest of the dependencies.

Copy link
Member

@RafaelGSS RafaelGSS left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If there's value in having two commits for OpenSSL we can do it, but it will require modifying that workflow to have a special case for OpenSSL separate from the rest of the dependencies.

There's a value in two commits. The second commit is arch build and normally some errors are caught in this phase (for example, nasm build issue - mentioned in the maintaining guide) so you just need to re-do the second one.

@mhdawson
Copy link
Member

I'll review it properly tomorrow, but I believe is better to have a workflow_dispatch instead. At least I think we'll have more control on those updates. Wdyt @mhdawson?

@RafaelGSS do you mean we should have workflow_dispatch and then trigger it manually, or just have that as another option for triggering and update?

@RafaelGSS
Copy link
Member

I'll review it properly tomorrow, but I believe is better to have a workflow_dispatch instead. At least I think we'll have more control on those updates. Wdyt @mhdawson?

@RafaelGSS do you mean we should have workflow_dispatch and then trigger it manually, or just have that as another option for triggering and update?

Yes, the first option. Triggering it manually through workflow_dispatch.

@mhdawson
Copy link
Member

I think having the ability to trigger it manually would be good, but having a PR auto generated and available when there is a new release seems useful, provided it does not require manual work most of the time. I think for OpenSSL we probably want to try to keep as up to date as possible in the main branch.

Copy link
Member

@RafaelGSS RafaelGSS left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. I think we are good to go. As discussed previously in a SecurityWG meeting, adding the support for two commits will be a bit out-of-scope.

Therefore, I'm fine moving forward with it, and if needed, we include support for multiple commits.

@mhdawson
Copy link
Member

The current documentation does say to land as 2 commits so unless its hard/lots of work to do that I'm thinking we should do that now versus later. @richardlau what's your take?

@richardlau
Copy link
Member

The current documentation does say to land as 2 commits so unless its hard/lots of work to do that I'm thinking we should do that now versus later. @richardlau what's your take?

My take is that the conservative option is the status quo -- two commits. On one hand that allows people to validate the first commit -- you should be able to get the exact same files. Keeping that property may be helpful in the future in terms of potential work around supply chain/verifying our dependencies.

The second commit has timestamps and local directories written into it which makes it harder to compare/validate.

On the other hand the two commit approach has always been the exception to the

All commits should be self-contained, meaning every commit should pass all tests.

guidance in our collaborator guide.

@mhdawson
Copy link
Member

My take is that the conservative option is the status quo -- two commits. On one hand that allows people to validate the first commit -- you should be able to get the exact same files. Keeping that property may be helpful in the future in terms of potential work around supply chain/verifying our dependencies.

@facutuesca I think it would be best to try to implement the 2 commits unless its going to take a larger effort.

@RafaelGSS
Copy link
Member

It will require including that support in our current tooling (dep_updaters)

@facutuesca facutuesca requested review from mhdawson and RafaelGSS and removed request for mhdawson December 19, 2022 18:37
@facutuesca
Copy link
Contributor Author

facutuesca commented Dec 19, 2022

@mhdawson @RafaelGSS @richardlau

I changed it to create 2 commits instead of one. I re-requested reviews since the new approach is different enough that it should be reviewed as a new PR. The things to keep in mind are:

  • The GH workflow for updating OpenSSL is now separate from the one used for the other dependencies. The OpenSSL steps (having multiple commits, each after running a different command) is different enough from the other dependencies that it can't be generalised to a single workflow without adding too much complexity
  • The bash script to update OpenSSL was also updated. Now it has two sub-commands (download and regenerate), corresponding to the two commits. A full update needs both sub-commands to be run, and the README was updated to reflect that

(edit: for some reason I cannot correctly re-request reviews, maybe a permissions issue since I also don't have permissions to add reviewers)

@facutuesca facutuesca requested review from mhdawson and removed request for RafaelGSS and mhdawson December 19, 2022 19:13
@facutuesca facutuesca requested review from RafaelGSS and mhdawson and removed request for RafaelGSS December 19, 2022 19:13
persist-credentials: false
- name: Check if update branch already exists
run: |
BRANCH_EXISTS=$(git ls-remote --heads origin actions/tools-update-openssl)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this block the automatic backport. We won't be able to update v14 and v16 at same time considering the race condition of the branch creation.

So, I'll include the labels dont-land-on-vX and after landing you will need to manually backport and change the branch name to actions/tools-update-openssl-vX.

Does that make sense to you?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the same logic used for the other deps. See this line from the current dependency update action:

branch: actions/tools-update-${{ matrix.id }} # Custom branch *just* for this Action.

As far as I understand, this would be already an issue for corepack, eslint, etc right? Since the branches created for them are called tools-update-corepack and tools-update-eslint without mentioning the Node version.

Do you know how those are handled currently?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we have different versions of eslint/corepack in each release line. Could you check if the bot has ever opened PR targeting other branches instead of main?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The bot will not because the automatic scheduled runs only happen on the default branch:
https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#schedule

Scheduled workflows run on the latest commit on the default or base branch.

# Only run rest of the workflow if the update branch does not yet exist
if: ${{ env.BRANCH_EXISTS == '' }}
run: |
NEW_VERSION=$(gh api repos/quictls/openssl/releases -q '.[].tag_name|select(contains("openssl-3"))|ltrimstr("openssl-")' | head -n1)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this also blocks the automatic backport to v14.x. We use the original repo on v14.x

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does v14.x have any existing action for dependency updates? I could not find any

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Currently there is no automation via Actions for dependency updates for any version of Node.js outside of the main branch.

.github/workflows/update-openssl.yml Show resolved Hide resolved
.github/workflows/update-openssl.yml Outdated Show resolved Hide resolved
@RafaelGSS RafaelGSS added the dont-land-on-v18.x PRs that should not land on the v18.x-staging branch and should not be released in v18.x. label Dec 22, 2022
facutuesca and others added 2 commits February 24, 2023 18:58
Add a Github Action that checks for new versions of the `OpenSSL`
library, and creates a PR to update it if a newer version than the one
present in the repo is found.

Refs: nodejs/security-wg#828
@RafaelGSS
Copy link
Member

ping @mhdawson

Copy link
Member

@mhdawson mhdawson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

mhdawson pushed a commit that referenced this pull request Mar 2, 2023
Add a Github Action that checks for new versions of the `OpenSSL`
library, and creates a PR to update it if a newer version than the one
present in the repo is found.

Refs: nodejs/security-wg#828

PR-URL: #45605
Reviewed-By: Michael Dawson <[email protected]>
Reviewed-By: Rafael Gonzaga <[email protected]>
Reviewed-By: Marco Ippolito <[email protected]>
@mhdawson
Copy link
Member

mhdawson commented Mar 2, 2023

Landed in c4103c1

@mhdawson mhdawson closed this Mar 2, 2023
targos pushed a commit that referenced this pull request Mar 13, 2023
Add a Github Action that checks for new versions of the `OpenSSL`
library, and creates a PR to update it if a newer version than the one
present in the repo is found.

Refs: nodejs/security-wg#828

PR-URL: #45605
Reviewed-By: Michael Dawson <[email protected]>
Reviewed-By: Rafael Gonzaga <[email protected]>
Reviewed-By: Marco Ippolito <[email protected]>
targos pushed a commit that referenced this pull request Mar 14, 2023
Add a Github Action that checks for new versions of the `OpenSSL`
library, and creates a PR to update it if a newer version than the one
present in the repo is found.

Refs: nodejs/security-wg#828

PR-URL: #45605
Reviewed-By: Michael Dawson <[email protected]>
Reviewed-By: Rafael Gonzaga <[email protected]>
Reviewed-By: Marco Ippolito <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dont-land-on-v18.x PRs that should not land on the v18.x-staging branch and should not be released in v18.x. meta Issues and PRs related to the general management of the project. tools Issues and PRs related to the tools directory.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants