Carrying security branches in the main git repository

[Stefan Bader]

Tim Gardner wrote:
> Tim Gardner wrote:
>> Andy (aka git wizard),
>>
>> I've been struggling with rebasing the security branch back into master
>> and am finding that it doesn't really work all that well. Of course, the
>> code patches rebase just fine, but where I'm having some real conflicts
>> is with some of the generated administrative files such as those in
>> debian/abi (and to some extent debian/changelog).
>>
>> What I'm considering is to just name the security branch with its
>> release version (such as security-2.6.27-9.18), cherry-pick the security
>> branch code commits back into master, and push the whole mess up to
>> zinc. The one thing I want is the ability to reliably reproduce the
>> security kernel. This method seems to satisfy that criteria, as well has
>> making sure master contains all of the security kernel code patches.
>>
>> Another advantage is that with this method I don't have to arbitrarily
>> fix the changelog. The content of changelog for the kernel in a
>> particular pocket accurately reflects the changes that went into that
>> kernel. Whereas, in the past I was hacking security changelog sections
>> into an arbitrary location in the master changelog, the results of which
>> Stefan and I have not always agreed.
>>
>> Thoughts?
>>
>> rtg
> 
> This is what I've done with Intrepid with regard to security branches.
> 
> I create a security branch in my local Intrepid repository that includes
> the ABI of the security branch, e.g.,
> 
> cd ubuntu-intrepid
> git branch security-9
> git checkout security-9
> 
> Don't ask me how I knew it was going to be -9 because there is some
> archive versioning magic involved.
> 
> Depending on the state of the master branch, I normally have to reset
> back to some known point. Remember that security uploads _must_ be a
> perfect superset of the kernel in -updates. In this case, that -updates
> kernel version was 2.6.27-7.16. So,
> 
> git reset --hard Ubuntu-2.6.27-7.16
> 

Mostly doing all the same. Just leaving one step. You can branch to a known 
version with

git branch security-9 Ubuntu-2.6.27-7.16

Saves one reset, 'cos every cycle counts ;-)

> Some packaging and version grunt work:
> 
> debian/rules startnewrelease
> vi debian/changelog (in this case change the version to 9.19)
> other package magic
> cherry-pick CVEs
> debian/rules insertchanges
> commit stuff, make a tag
> 
> By this point you should have a packageable repo. The key thing that is
> left to be done is to cherry-pick all of the code commits from the
> security branch back into master. Note that I'm specifically _not_
> including any commits into the debian directory.
> 
> The only thing left to be done is to push the branch:
> 
> git push origin security-9
> git push --tags origin
> 
> At some point these security branches are no longer relevant and can be
> deleted. But thats an exercise left for later.
> 
> Finally, depending on what version contortions we had to go through, you
> might need to update the ABI and/or version in the master branch
> changelog so as to avoid version collisions with other pockets
> (-security and -updates).
> 
> Clear as mud?
> 
> rtg


-- 

When all other means of communication fail, try words!