Carrying security branches in the main git repository

[Tim Gardner]

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

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
-- 
Tim Gardner tim.gardner at canonical.com