|
|
### BIND development workflow
|
|
|
|
|
|
Notes from the group meeting during IETF 101:
|
|
|
|
|
|
#### 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.
|
|
|
|
|
|
##### Maintaining supported preview branches
|
|
|
|
|
|
(to be completed)
|
|
|
|
|
|
#### Review procedures
|
|
|
|
|
|
##### Creating a merge request
|
|
|
|
|
|
(to be completed)
|
|
|
|
|
|
##### Tags
|
|
|
|
|
|
(to be completed) |
|
|
\ No newline at end of file |