Changelog?

[jdoe]

Will there ever be a changelog for the grsec patch? There are silent version bumps where the patch's date on the site is changed but no other announcement is made. It would be nice to have it a little more obvious when there's a new patch, as well as enough information to judge whether it's worth updating.

[spender]

The basic problem is that we don't know of a good tool for tracking our development process. If you've been following grsec for a while, you know that we used to use CVS, but the additional work involved with each new kernel release made it waste more time than it was designed to save. gradm is still maintained with CVS and has a changelog autogenerated for it nightly that you can view. Some time ago we decided to switch back to doing things manually for the kernel patches. You've always of course been able to interdiff two patches to see what exactly changed, though as for the descriptions/explanations of the changes, we don't have a central location for them.

For instance, the most recent update was a small 2 hunk change to fix compilation (this happened to be reported via email). The previous update was backporting of some code reorganization from a 2.6.33 patch the PaX team is developing (since the 2.6.32 tree is being maintained long-term, it's easier to deal with things that are similar if they can be made similar) and fixes for two unnecessary warnings about capability usage in the RBAC system, one which was discussed here on the forums in another thread (regarding netlink and NETLINK_ROUTE) and the other submitted via email about RLIMIT_NPROC overstepping where the vanilla kernel was checking for CAP_SYS_ADMIN and CAP_SYS_RESOURCE before checking to see if the user was root.

We basically have three kinds of changes: bugfixes, forward ports, and new features. New features we generally announce in some form, forward ports for the most part won't apply to the stable series, which leaves bugfixes like the ones mentioned above. For the stable series, you should still be updating to each new .x.y release as standard practice, as with few exceptions there's security vulnerabilities (some silent or unobvious, others more obvious) fixed in each one. If you're not having any problems (any problems that do appear tend to show up here on the forums pretty quickly) then in general you shouldn't need to upgrade more often than that.

-Brad

[bplant]

Out of interest, have you considered/tried git?

I understand that producing change logs would involve additional work, but it'd certainly be a nice addition. Especially for the 2.6.32 series since I imagine this is only going to include bug fixes etc.

Cheers,

Brad

[cormander]

I'm using git to track the patches now along with the upstream in the build system I'm using for the grsec/pax kernels. It's working greater for me. I have yet to convince spender of it being an advantage

[PaX Team]

Out of interest, have you considered/tried git?

yes, we did but unfortunately it seems ill-suited for our needs. for me the one fundamental issue is that git doesn't provide an efficient way of having several checked out trees at once (a process of checkout/rebuild in a single directory is awfully slow and hence inefficient). this is because in git a cloned repository and a checked out one are one and the same. in say cvs, the repo on the server is independent of the checkouts, you can have as many checkouts as you want, all working against the same repo. in git you can't easily do that, there're hacks that sort of allow you to share the object database among clones but such setups are not well supported, break in subtle ways if you're not careful, etc. i'm all ears if you have a solution for this problem.

[cormander]

You could place your .git directory somewhere like /pub/git/linux-2.6.x.x and create a symlink in each checkout to have the .git point to that directory.

That way, you can move from one checkout to the other and compare against the same repo you have in /pub/git (or wherever you place it).

I've used it on shared projects before with people who were used to subversion and had a hard time with the concept clones, pushing and pulling.

[PaX Team]

You could place your .git directory somewhere like /pub/git/linux-2.6.x.x and create a symlink in each checkout to have the .git point to that directory.

this may work only when you check out the exact branch into each working directory (and i'm not sure how commits from one and pulls into another will work in that case), but it will fail with different branches for sure (what's HEAD?). as i said, there're certain hacks that do something like this, look at /usr/share/git/contrib/workdir/git-new-workdir but it's still fragile.

[cormander]

For anyone interested, I have a git repo that follows the upstream git.kernel.org stable/linux-2.6.32.y and has a grsecurity branch. I have a script that pokes the grsecurity.net site for an updated grsecurity patch, and applies the difference between it and the last one and commits it. It auto merges with upstream when necessary.

For example, the difference between:

grsecurity-2.1.14-2.6.32.8-201002090925
and
grsecurity-2.1.14-2.6.32.8-201002132204

is here:

http://git.cormander.com/?p=linux-2.6.3 ... c953300e0f

I'm using this repo for my build system which polls it for changes, and rebuilds / boots / tests the kernel when there is code updates.

So every patch from here on out (or at least most of them) should get pulled into this repo.

[cormander]

this may work only when you check out the exact branch into each working directory (and i'm not sure how commits from one and pulls into another will work in that case), but it will fail with different branches for sure (what's HEAD?)

Actually, it just hit me. The "symbolic-ref" function ought to make this work with different branches. It works like this:

git symbolic-ref HEAD refs/heads/yourbranch

It makes you "switch branches" without touching the working tree at all.

Say you've cloned 2.6.33 and make 2 branches, each to be compiled in the directory of its own:

cd branch1/
..do work..
commit
cd ../branch2/

At this point you see 'git status' as the commit from branch1 in reverse. You then type:

git symbolic-ref HEAD refs/heads/branch2

It's now a clean working tree. You can do different commits and they won't affect branch1. When you commit and head back into branch1, you'll see the commits from branch2 in reverse; simply symbolic-ref the HEAD back to branch1 for a "clean" status. Then if you want to merge, you can pull in changes to the locally checked out branch like you normally would.

The symbolic-ref doesn't actually touch any of the files in the checkout, so re-running the make command after all has been built won't need to recompile anything. I know how much it sucks to have to touch a file like init/main.c and sit and wait for the whole thing to start over.

You could simply alias that symbolic-ref command to make it shorter to type too.

as i said, there're certain hacks that do something like this, look at /usr/share/git/contrib/workdir/git-new-workdir but it's still fragile.

I suppose this is a "hack" as well. But I started trying it and it works for me. Also on the plus side, no more of the messy push/pull between local checkouts to pass changes between each of them, and forgetting to update some of them on occasion, because they all point to the same repo via the .git symlink.

You could then technically track the mainline kernel, the stable kernel, and your own branches all in one git repo. You'll just have a lot of "remotes" to pull in the different lines of development into your branches