|
OpenCA Labs
OPENSOURCE SECURITY AND IDENTITY MANAGEMENT SOLUTIONS
Developers @ OpenCA LAbs
To get your code checked into openca.org code repository you'll need to understand our code development cycle, coding practices, and checkin requirements. You probably also want to have a reasonable understanding about the project's organization. At the moment there are no written rules about conding techniques and requirements, we will provide those as soon as possible to help developers to contribute to each projects. However single projects can decide different coding rules as required by the project nature. Getting Involved
Getting involved in a project on openca.org is as easy as subscribing the support mailing list(s). Starting from there you will be part of the community and you can submit your ideas and code there. Remember, however, that patches and enhancements should be discussed among all the people participating to the project, therefore describe your ideas before writing many lines of code that might be rejected by the core team of the project. YUM REPOS
Projects
DOWNLOADS
Coding Rules
by madwolf
After the first years of experience and since some projects are now requiring special care in development, we think that security-related and/or network-related code requires more than skilled programmers to be developed. At first it is extremely important that the code is harmonized, hence all developers should apply the project's defined coding rules. If you want to contribute to a project and you are not sure about the coding rules, please ask the project coordinator or send an email to the developers mailing list (after checking the available documentation from that project!). Notice
Please ask to the specific project's manager or other developers about
the adopted rules.
Development Tools
by madwolf
In many of the current projects on OpenCA.org the used language is C/C++. Therefore specific tools should be used in order to prevent programming derived errors, such as buffer overflows, to be present in the code. From an analysis we recently conducted, the most suitable option is the usage of the C/C++ language, together with the adoption of static analysis tools. In particular, it is advisable to use tools such as ITS4, RATS or Flawfinder to conduct a focused code review after every function or logical piece of code has been completed. This strategy can be employed by each developer to check for bugs in the code she is producing. We are currently in the process of switching to CLANG. While programmers may use static analysis tools without modifying the level of reported warnings, it is highly recommended to regularly perform a full audit of the code base. This auditing phase can be carried out by using SPLINT with the options configured to have the highest number of warnings reported during the analysis. If the checks are performed frequently enough, the tool will not report too many false positives, thus allowing for prompt verification of the interactions between different project components. After each function is checked for specific errors, it is also advisable to annotate it right way in order to facilitate the next auditing phase. Testing Policies
by madwolf
In all the OpenCA projects, we promote a test policy that is focused on providing simple testing tools (e.g., by the use of standard targets - where this make sense - for testing the functionalities via a 'make tests') or test scripts that can be used for generating client-server test messages. On top of the standard testing tools, we also advocate for continuous integration and testing to make sure that new improvements do not introduce new issues, bugs, or security vulnerabilities. If you discover a new issue or vulnerabilty, please report it via the issue tracker for the project, by sending an e-mail to the specific e-mail address, or by simply sending an e-mail to the developers' mailing list for the project. All contributions are welcome and encouraged! Code of Conduct
by madwolf
Work In Progress by madwolf
Work In Progress |