[Fedora] Re: Semi OT: Subversion

John Summerfield debian at herakles.homelinux.org
Thu Nov 8 05:08:11 UTC 2007

Les Mikesell wrote:
> John Summerfield wrote:
>>>> Nobody should have the ability to update code owned by the next stage.
>>> That's not possible with most version control systems.  Everyone has 
>> It's essential. You don't want everyone to be able to mess with 
>> production code.
> I meant that no one ever changes anything that has ever been committed. 
>  Everyone makes changes in their own workspace and a commit becomes a 
> new revision.  Anyone can check out any revision that has ever been 
> committed.  So, each stage checks out their own appropriate revision or 
> tagged copy based on the workflow regardless of what else is happening 
> in the repository.  It doesn't matter that someone can check in garbage, 
> what matters is that the garbage revision not the one that QA 
> tests/approves/tags to go to production.

How do you propose minimising the possibility of someone of ill intent 
making unauthorised changes?

Think what DoD, any big bank, Qantas, Westfield or any other significant 
business would expect?

Lesser organisations may need to take lesser decisions - a business of 
four people could hardly do that - but the tradeoff is greater risk.

>> Nobody can certify code they don't control. If I can apply a little 
>> vim or emacs to your repo, you're sunk. Just let the auditors ask, 
>> "Who can change this source code?" and "We will try."
> You've got unix filesystem permissions and SELinux at your disposal to 
> control direct repository access.  And the repository doesn't have to be 
> on the same machine as any of the users.

Unix is weak. selinux is cumbersome.

>> Essentially, we cloned the libraries of source code, and each stage 
>> (to the best of my recollection) built their own executables.
>> If every source file's digitally signed, that's probably good enough, 
>> but old fogies (say, my generation) would probably say not.
> If you don't trust your file access control, these don't matter much.

Nobody should trust anything they're not forced to: that's what 
Microsoft means when it talks of "trusted computing."

Do I trust my eye surgeon to operate on my eye properly and skillfully? 
Yes, I do, because I must have that operation (I might make enquiries to 
ensure he's trustworthy, but that's another matter).

Do I trust Laurie with keys to my house? Yes I do, because I'm hiring 
him to paint it, to do up the bathroom (Not Lavatory, its the room where 
one cleans oneself) etc.

Do I trust my bank with my money? Yes, I do, because I have to have 
someone to keep my surplus cash safe.

Do I trust any of the above with any of the other above? No, I don't. I 
don't think my banker could renovate the house or operate on my eye with 
the skill I expect.

In the context of the Linux kernel, Linus and his lieutenants constitute 
the development manager. They manage all those who would hack on the 
Linux code and make changes. Perhaps he also does the testing.

Think of RH, Novel etc as the QA folk. They take the code, clone it, do 
their own testing and packaging. If the RHEL kernel's broken, RH carries 
the responsibility of fixing it.

And then sensible enterprise users take their chosen vendors' offering, 
and since they don't _have_ to trust the vendor, they don't. They do 
their own QA, before putting into production in their own enterprise. 
they may well take a copy of the source code too, and some (eg CentOS do 
exactly that).

Now, we know it's more complicated than that, but that's the basics of it.



-- spambait
1aaaaaaa at coco.merseine.nu  Z1aaaaaaa at coco.merseine.nu
-- Advice

Please do not reply off-list

More information about the fedora-list mailing list