Please note that this document has now been over taken by the Security Policy section 7 |
The contents of this page should be integrated into Security Manual section 7 |
Background
Draft started by a bunch of non native English speakers (Australian, Austrian, French, etc.).
- "Dev Process Policy" is like a security work flow/framework for CAcert Dev with multiple developers
- Also improving the motivation of developers to help at CAcert Project serving the whole CAcert community.
Why creating such a policy? Assuring the security and independence of CAcert community in an hostile environment.
Contents
- Background
- Full Casting
-
Normal Processing work flow
- management of bug or feature reports
- assignment of tasks
- reporting of patches to accredited people for code reviewing & testing
- patch proposal for production reviewed by the Director of Security
- Responsibility management work flow
- Environment management work flow
- Report Management work flow
- all in one
- Sensitive & Emergency Processing work flow
- Background of the Background
- Assumptions :
- All the actors of the following processes should comply with CAcert NDA (excepted simple reporters).
Read the license of CAcert code source and do not complain about it. http://www.cacert.org/src-lic.php
In the following "bugs.c" refers to "http://bugs.cacert.org"
license change policy
In order to open CAcert development, the current license might be crossed with a lesser GPL compatible license
to do:
- to define what should be kept under current license (probably)
- may require an analyzis and code rewriting between "sensitive" parts (private bugs report only) and "open" parts
- requesting advice from fsfe contacts to choose the proper license.
- pro : CAcert will not be able to scale under current development processes.
- con : requires Czar approval and strong EMC (see emc.xxxx.net)
Full Casting
Director of Security
basic profile & tasks
- The Director of Security approves and has the final word on the patches proposed in bugs.c, according to code reviews and tests reports made from the proposed patches
- He/she ensures the application of the changes from test system to production systems
- Nominated by CAcert board
- The President of CAcert association is The Director of Security when the position is vacant
- he/she ensures the compliancy of CAcert license in the way it has to be as open and secure as necessary and he/she reports about it to the CAcert board.
required skills & abilities
skilled developer & system admin
- Full Access to CAcert Datacenter
Development Manager
basic profile & tasks
- Assigns tasks to developers, code reviewers, code testers
- Manages developer, code reviewer, code tester team
- Manages bugs reports and feature requests and reports to the Director of security
- Nominated by the Director of Security
- his/her deputy is nominated by CAcert board upon Dev. Manager proposal
- his/her deputy reports to the Director of Security (and also to CAcert board in case of emergency) about Dev. Manager activities
required skills & abilities
- HR management
involved & has a complete knowledge of CAcert features
- good general background in IT
- full access to bugs.c
- admin of CAcert-devel list
2nd Level Contact
basic profile & tasks
- Member of CAcert 2nd Level Support
- Chosen by the Dev. Manager among CAcert 2nd Level Support Team
- assure the link between production feed-back and developers
- Can assign lower priority tasks to developers
required skills & abilities
involved & has a complete knowledge of CAcert features
- full access to bugs.c
- (restricted) admin access to CAcert Datacenter
- access the CAcert test environment to help code reviewer/testers
Developer
basic profile & tasks
- proposed by Dev Manager
- analyzes CAcert source code and proposes patches related to bugs and/or new features he/her has been assigned to and he/her has accepted the workload.
- delivers patches through bugs.c
- can only access his local test environment to test the feature he/she has accepted to code
required skills & abilities
- skilled developer
- can request help from 2nd Level Support, Dev Manager, and other listed CAcert developers if allowed by Dev Manager
- read access to CAcert test code source repository
- Dev access to bugs.c
Code reviewer
basic profile & tasks
- proposed by Dev Manager and confirmed by the Director of Security
- analyzes source code patches related to the bugs and/or the new features he/her has been assigned to and he/her has accepted the workload.
- depending on the critical level of the issue, he/her codes tests and add them to the proposed patches
- access the CAcert test environment to test the feature he/she has accepted for code review
- delivers additional test patches through bugs.c
can never review patches that he/her was assigned as developer (unless fully allowed by both Dev Manager and Director of Security)
required skills & abilities
skilled developer & system admin.
- can request help from 2nd Level Support, Dev Manager, and other listed CAcert developers if allowed by Dev Manager
- read/write access to CAcert test code source repository
- tester access to bugs.c
Code tester
basic profile & tasks
- proposed by Dev Manager
- access the test environment to fully test the feature he/she has accepted to test
- writes a report about the results of the tests
- cannot review patches that he/her was assigned as developer or code reviewer unless allowed by Dev Manager
required skills & abilities
- can request help from any member involved in the processing of the issue if allowed by Dev Manager
- read access to CAcert test code source repository
- reporter access to bugs.c
Bug/New feature reporter
basic profile & tasks
- reporting bugs or requesting news features
required skills & abilities
- knowledge in IT and CAcert user.
Normal Processing work flow
management of bug or feature reports
- should follow the tasks assignment in the previous part
assignment of tasks
- should follow the tasks assignment in the previous part
reporting of patches to accredited people for code reviewing & testing
- should follow the tasks assignment in the previous part
patch proposal for production reviewed by the Director of Security
- should follow the tasks assignment in the previous part
Responsibility management work flow
pdf see
Environment management work flow
pdf see
Report Management work flow
pdf see
all in one
CAcert signed OO doc see
Sensitive & Emergency Processing work flow
This is the sensitive & emergency process for critical issues and especialy "sensitive" parts (private bugs report only).
management of bug or feature reports
All related bugs have to be declared as private in bugs.c OR moved to private status in bugs.c ASAP
- If necessary, the Director of Security launches the safeguarding CAcert Datacenter procedure.
assignment of tasks
- The Director of Security assigns privately one or more developers to code and involves himself/herself in the coding/patching process
reporting of patches to accredited people for code reviewing & testing
- The Director of Security patches the test systems
- The Director of Security ensures himself of the code reviewing, then propose the Dev. Manager and its deputy to test it on the test system.
patch proposal for production reviewed by the Director of Security
- Once validated by Dev. Manager and its deputy, supported by 2nd Level Support, the Director of Security ensure the application of the patches to correct the major issue on the production system.
- In the case of a safeguarding CAcert Datacenter procedure, the Dev. Manager proposes to end the procedure.
Background of the Background
Once upon a time...
- (22:09:27) H: in order to allow others people, programmer not to flee
- (22:09:30) H: too fast
- (22:09:54) Z: Well, the way I envisioned it is the following:
- (22:10:19) Z: Developers work on smaller, separated projects.
- (22:10:26) Z: They communicate and work together on the devel mailinglist.
- (22:10:50) Z: When they have something ready, it is installed on a test-system to be presented to everyone.
- (22:10:57) Z: So that everyone can test it, ...
- (22:11:35) Z: Then the patches go to the Security Czar for approval and implementation.
- (22:11:41) Z: Yes, the patch can be attached to bugs.cacert.org
- (22:15:36) H: Ok let's hope people will not flee... with the Czar less directly involved
- (22:18:16) Z: My vision was that we succeed to completely separate the development from the approval.
- (22:18:24) Z: So that the approval people cannot develop themself.
- (22:18:40) Z: To enforce quality assurance of the code.
- (22:18:56) Z: Or that they cannot approve their own code, and have to ask someone else.
- (22:18:57) H: I do agree
- (22:19:19) H: At least the Czar as a guard of security
- (22:19:27) Z: The big problem I see is that this procedure does not work for time-critical stuff.
- (22:19:37) Z: When there is a problem that has to be fixed immediately
- (22:21:01) Z: Another thing that I saw which is necessary is mentors for the developers.
- (22:21:07) H: So need a paragraph for processing critical cases
- (22:21:29) Z: New developers sometimes do now know how to work in a group, don´t know how to correctly produce patches, ...
- (22:21:41) H: The Czar is the mentor ? no I'm kidding
- (22:21:45) Z: Developers are often one-man-shows.
- (22:22:04) Z: So you need people who care for new developers, until they know everything necessary
- (22:22:37) H: 2nd level support is here to support the becoming 3rd level support
(22:23:24) H: you need people who care for new developers => 2nd level support
- (22:23:57) H: the men in the middle
- (22:24:31) Z: No, it´s a special kind of developer support.
- (22:25:11) Z: It´s things like patch-management, version-management, ...
- (22:25:38) H: who is best at Dev support ?
- (22:25:51) Z: I think I can do that.
- (22:26:16) H: my guess : the men in the middle (you are part of it)
- (22:26:27) Z: Another important thing is motivation for developers.
- (22:26:33) Z: You need people who motivate them.
- (22:27:18) Z: Who thank them for their work, who cares for them, who tests their results, ...
- (22:27:22) H: (ya, if the system is running it is self motivating
- (22:30:24) H: Head of Dev support
- (22:30:36) H: Policy maker
- (22:31:02) H: Sending cookies to motivate people
- (22:31:18) H: home made cookies sent worldwide
(22:36:18) H: We'll write a paragraph about "Sending home made cookies worldwide to motivate Dev"
- (22:37:16) H: Sir Z, DRM (Dev Resource Management)
- (22:54:40) H: When motivation is on my way I'll try to make a draft of a draft of a policy... signed Z, the dad of all policies