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 compared to its alternatives. We hope that the community will help build a more robust and useful implementation which will enable 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 future releases, below we present our code contribution policy. These guidelines must be followed by project contributors to enable their changes to make it faster into libEST.

#Guidelines Below we 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. Some common examples of coding style that need to be followed are:

  • Indentation Usage
  • C token name definition
  • Use of C and not C++ comments

• Documentation
  Contributions should be properly documented.

• New features

• Size
  New feature contributions must 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 must be submitted individually to allow for proper evaluation.
• Maintainability
  New features will be evaluated for maintainability. libEST is aimed for multiple applications and vendors. New features should not impact potential adopters and should not be too use case specific to be maintained in the library in the long-run.
• Platform Portability
  Changes or new features in libEST must 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 must not introduce security holes or vulnerabilities to the library.
• RFC compliance
  Contributions must not violate or deviate from the EST standard (RFC7030) or any of its future updates.
• Licensing and Copyright
  Contributions must 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.