Re: SeLinux integration
- From
- Christian Jaeger <christian@jaeger.mine.nu>
- Date
- Aug 18, 2008, 12:47 UTC
- Message-ID
- <48A96F51.6090404@jaeger.mine.nu>
- In-Reply-To
- <1219060960.13808.20.camel@desktop.local.neuhalfen.name>
Jens Neuhalfen wrote:
> The repository is my current development repository which, naturally (?), is based on the 'blessed' repository. My understanding of git was, that anyone with a copy of the blessed git repository can 'pull' from my repository and gets my branches with git transmitting just my changes over the net. Then he/she/it can switch to 'my' branch and test the policy/init-script. > > Did I get something wrong there? I thought that this is a/the normal way of using git. >
Well I'm sure you could use it this way; but check for yourself, if you start gitk on your repository, one has to first figure out where to find you work, i.e. one has to follow the right parent in your commits to see all of them; it's certainly possible but I guess not very inviting for people who just want to *look* at your work (as opposed to simply try it out). I'll readily admit that I just wanted to look, not try it out. But maybe I'm not the only one with this as his/her primary aim.
> You are right with the commits and their rather terse messages, though the code are not ready for release or an integration review. The plan was: Get some feedback on the current state, refine the code and then send the patches to the list. >
Ok, maybe how you're doing it is just fine, I'll leave it to others to judge. But still you should be aware that it's common practice with Git to first clean up private history before publishing it. The history can explain the code much better than is possible by just looking at the latest committed version, and since with Git it is possible to rework the history as long at it is private, people frequently do it, so that the readers can get most out of it. (This is more akin to patch sets, where each patch does a certain thing -- versus work steps, which documents how you created the changes. The latter documentation is really only of interest for you, for others it's the intended changes which matter. So you could "git branch my_selinux_prepublish_1" to keep the latter history in case you want to look at it again later, then do the history cleanup as I've suggested and publish that instead. And continue to work on that reworked branch, actually.)
> Christian, have you been able to test the policy? I am very curious, how it works on other machines (say, gentoo) or with other setups (strict-policy is completely untested, although I don't think that anyone really uses it).
I don't have any SELinux setup here. I'm playing with the thought of looking into it, that's why the subject of your mail has catched my attention.
Thanks, Christian.