... | ... | @@ -2,36 +2,37 @@ |
|
|
|
|
|
Notes from the group meeting during IETF 101:
|
|
|
|
|
|
#### Use of public and private gitlab repositories
|
|
|
#### Use of public and private Gitlab repositories
|
|
|
|
|
|
##### Handling security incidents
|
|
|
|
|
|
1. Mark security related issues as "confidential" in gitlab.
|
|
|
1. In your local repository, create a development branch and a testcase branch. Branches whose names contain the string "security" anywhere in the name, or end with the string "-testcase", are *always* protected and cannot be pushed to the isc-public repository. After creating these branches, optionally set the upstream to the isc-private repository.
|
|
|
1. While the CVE is in progress, add protection for *_patch* branches and *_P* tags. This can be removed after public disclosure of the CVE, and ensures we will not accidentally release code prior to the planned disclosure date.
|
|
|
1. Once the testcase and code are complete, push them to isc-private for review.
|
|
|
1. Update the master branch with a placeholder CHANGES note.
|
|
|
1. When the fix has been reviewed, merge it using `--no-ff` to a new temporary branch, security-master. Replay this merge to each of the maintenance release _patch branches, and to temporary branches security-v9_12, security-v9_11, etc. These can only be pushed to isc-private.
|
|
|
1. As the public master and v9_X branches are updated, continually rebase the private security-master and security-v9_X branches.
|
|
|
1. After disclosure, remove the protection on _patch branches and _P tags. Merge security-master to master and security-v9_X to v9_X branches. Push the _patch branches and _P tags to isc-public. Delete the security-master and security-v9_X branches from isc-private.
|
|
|
1. Mark security related issues as "confidential" in Gitlab.
|
|
|
1. In your local repository, create a development branch and a test case branch. Branches whose names contain the string "security" anywhere in the name, or end with the string "-testcase", are *always* protected and cannot be pushed to the *isc-projects/bind9* repository. After creating these branches, optionally set the upstream to the *isc-private/bind9* repository.
|
|
|
1. While the CVE is in progress, add protection for *\*_patch\** branches and *\*_P\** tags. This can be removed after public disclosure of the CVE, and ensures we will not accidentally release code prior to the planned disclosure date.
|
|
|
1. Once the branches containing the fix(es) and the test case are complete, push them to *isc-private/bind9* for review.
|
|
|
1. Create two merge requests, one for each branch pushed in the previous step, so that they can be discussed. **Make sure that the destination branch for both of these merge requests is set to *master* in *isc-private/bind9*, not *isc-projects/bind9*.**
|
|
|
1. Update the *master* branch in *isc-projects/bind9* with a placeholder `CHANGES` note.
|
|
|
1. When the fix has been reviewed, cherry-pick it into a separate branch for each fixed maintenance branch (*\*-security-\*-v9_12*, *\*-security-\*-v9_11*, etc.) These can only be pushed to *isc-private/bind9*.
|
|
|
1. As the public *master* and *v9_X* branches are updated, continually rebase the private *\*-security-\** branches.
|
|
|
1. After disclosure, remove the protection on *\*_patch\** branches and *\*_P\** tags. Merge *\*-security-\** branches to the relevant branches in *isc-projects/bind9*. Push the *\*_patch\** branches and *\*_P\** tags to *isc-projects/bind9*. Delete the *\*-security-\** branches from *isc-private/bind9*.
|
|
|
|
|
|
##### Maintaining supported preview branches
|
|
|
|
|
|
Supported preview branches are maintained in the isc-private repository, and are protected so they cannot be pushed to isc-public. The branchsync script keeps them up to date by automatically cherry-picking changes from the associated v9_X branches.
|
|
|
Supported preview branches are maintained in the *isc-private/bind9* repository, and are protected so they cannot be pushed to *isc-projects/bind9*. The branchsync script keeps them up to date by automatically cherry-picking changes from the associated v9_X branches.
|
|
|
|
|
|
##### Creating a merge request
|
|
|
|
|
|
Generally, issues are used for discussion of problems and merge requests are used for discussion of the specific code used to fix the problems.
|
|
|
|
|
|
While it is possible to create a merge request and a git branch from the issue page, this isn't recommended. It clutters the MR list with merge requests that have no work in them yet, and also triggers an unnecessary pipeline run. Instead, when working on a gitlab issue, create a development branch in your local working repository. If you give the branch a name beginning with the issue number followed by a hyphen, then the branch will automatically be associated when that issue when pushed. When ready, push the branch to isc-public, then create a merge request to go with the branch. One way to do this is to go to the pipelines page, click on the branch name, and then click "Create merge request". Edit the commit message as necessary, and check "Remove source branch when merged".
|
|
|
While it is possible to create a merge request and a git branch from the issue page, this isn't recommended. It clutters the MR list with merge requests that have no work in them yet, and also triggers an unnecessary pipeline run. Instead, when working on a Gitlab issue, create a development branch in your local working repository. If you give the branch a name beginning with the issue number followed by a hyphen, then the branch will automatically be associated with that issue when pushed. When ready, push the branch to *isc-projects/bind9*, then create a merge request to go with the branch. One way to do this is to go to the pipelines page, click on the branch name, and then click *"Create merge request"*. Edit the commit message as necessary, and check *"Remove source branch when merged"*.
|
|
|
|
|
|
For minor changes, it isn't always necessary to create an issue in gitlab; just create and push a branch, then create a merge request without linking to an issue.
|
|
|
For minor changes, it isn't always necessary to create an issue in Gitlab; just create and push a branch, then create a merge request without linking to an issue.
|
|
|
|
|
|
##### Review labels
|
|
|
|
|
|
Several review-related labels have been added to gitlab merge requests:
|
|
|
Several review-related labels have been added to Gitlab merge requests:
|
|
|
|
|
|
1. Review: Set by the author when the branch is ready to be reviewed.
|
|
|
1. Merge OK: Set by the reviewer when the code is okay.
|
|
|
1. Needs cleanup: Can be set by either the author or the reviewer; this indicates that regardless of the current state of the code, the branch still needs to be cleaned up -- for example, by squashing commits in `git rebase -i`.
|
|
|
1. Author merge: The author wishes to merge this branch personally and requests that no one else click the merge button, regardless of whether it's deemed ready. |
|
|
\ No newline at end of file |
|
|
1. Author merge: The author wishes to merge this branch personally and requests that no one else click the merge button, regardless of whether it's deemed ready. |