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.
--
Cheers
John
-- spambait
1aaaaaaa@xxxxxxxxxxxxxxxx Z1aaaaaaa@xxxxxxxxxxxxxxxx
-- Advice
http://webfoot.com/advice/email.top.php
http://www.catb.org/~esr/faqs/smart-questions.html
http://support.microsoft.com/kb/555375
Please do not reply off-list
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
