libEST Contributions Policy

#General libEST is an open-source project (that implements the Enrollment over Secure Transport EST) protocol) hosted by Cisco in GitHub. In the spirit of open-source collaboration Cisco encourages users to clone, use and contribute to this project. Our goal is for the EST protocol to become widely accepted in the industry because it offers a lot of advantages compered to its alternatives. We hope that the community will help build a more robust and useful implementation which will enable for faster adoption of the EST protocol. Users are welcome to contribute to the project with features and bug fixes. In order to ensure the quality of the code and faster integration in the future releases, below we present our code contribution policy. These guidelines should be followed by project contributors to enable their changes to make it faster into libEST.

#Guidelines Below we try to outline all our contribution guidelines for libEST:

• Presentation and code quality Even though it is not documented officially, most of the libEST code is written in a specific way. Contributions should follow the same coding style and quality as the existing libEST code. Contributions that are written in a different style would require more vetting and work from our team and could delay adoption. Examples of the openssl coding style that is similar to libEST’s are here.
• Documentation Contributions should be properly documented.
• New feature

• Size New feature contributions should be submitted as individual features, not a collective of features. Bundling multiple new features in one submission would require significant review and create confusion in the vetting process. New features should be submitted individually to allow for proper processing.
• Maintainability New features will be evaluated for maintainability. libEST is aimed for multiple applications and vendors. Adding a feature that should not impact potential adopters and should not be too usecase specific to be maintained in the library in the long-run.
• Platform Portability Changes or new features in libEST should not affect other platforms using the library.
• Unit Tests New feature code contributions should include unit test coverage through the CUnit framework.

• Specificity A contribution should be specific enough to be implemented or adopted. Using generic language about the end-goal can be counter intuitive and time consuming.
• Security Contributions should not introduce security holes or vulnerabilities to the library.
• RFC compliance Contributions should not violate or deviate from the EST standard (RFC7030) or any of its future updates.
• Licensing and Copyright Contributions should comply with the libEST license.

Contributions are very welcome by libEST. We encourage contributors to take the following into consideration:

• The time to review can depend on the available resources. During busy periods or if there are multiple submission, processing could take more time.
• New feature adoption will usually take more time to evaluate than simple bug fixes. New features will be added in our backlog. We will evaluate them, think about them against our roadmap and vision and take them on if we chose to. Although code implementing a feature is welcome, it could require some code rewrite, should we choose to adopt it in libEST.
• Contributors are welcome to fork libEST to start a new project for specific uses. This model has worked for many versions of openssl and is acceptable by libEST. Contributors should note that forking a new branch would require maintenance efforts to keep the branch up to date with its master libEST when there are libEST updates. Although it is uncommon, failure to follow the above guidelines could lead to push requests being rejected and their adoption in libEST to be slowed down.