[Fedora] Re: Semi OT: Subversion

[John Summerfield]

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?
> 
> With revision control systems, you always have access to all versions 
> and the ability to see the differences between them and who made the 
> changes (most useful with text/source).  If something is important, I'd 
> expect someone to review the changes as well as performing functional 
> tests on any generated programs.

If I, a developer, can modify the repo outside the vcs system (which is 
what I said earlier), how then do you, in Production Control, guarantee 
its content?



> 
>> Think what DoD, any big bank, Qantas, Westfield or any other 
>> significant business would expect?
> 
> Don't they outsource everything these days?

Hardly relevant. I don't think we do.

> 
>>> 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.
> 
> Compared to?  How could you tell if something else is better?

Compared with tools I used in the 80s on another platform:

I used ACF/2 before it was CA-ACF2, and I can't find docs to refresh my 
mind.

Here's how to create two TSO users on z/OS:

ADDUSER (PAJ5 ESH25)

A TSO user has equivalent access to z/OS as a shell user has in Linux.
There's much more that one can specify, see 
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ICHZA441/5.3?DT=20040416130942

To create a group:
ADDGROUP PROJECTA
See 
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ICHZA441/5.1?DT=20040416130942

To connect a user to a group:
connect ESH25 group(projecta)
Note case is not significant.
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ICHZA441/5.7?SHELF=&DT=20040416130942&CASE=

Give projecta members update access to a file, WJE10.DEPT2.DATA
PERMIT 'WJE10.DEPT2.DATA' ID(RESEARCH) ACCESS(UPDATE) 

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ICHZA441/5.17?SHELF=&DT=20040416130942&CASE=

There are many things that _can_ be specified.

Any number of people could be given access to resources.

SQL has some fairly simple, effective primitives for controlling access 
to tables.

If I want to give an individual access to a file I am authorised to 
grant access to, then all I need to know is the name of my file, and the 
userid of the user. And the command.





> 
>>> 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."
> 
> Why trust the people supplying something they happen to call "trusted"?
> 
As I explained, at some point you must. Even then, you take every care. 
z/OS users trust IBM because IBM has a good reputation, and because they 
must. Even though the IBM software's imperfect.





-- 

Cheers
John

-- spambait
1aaaaaaa at coco.merseine.nu  Z1aaaaaaa at coco.merseine.nu
-- 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