Difference between revisions of "Contributions"
(Created page with "There are a number of reasons why code or documentation contributions may not be adopted by the OpenSSL maintainers. === Technical Concerns === ==== Security Issues ==== (TBD) …") |
|||
| Line 2: | Line 2: | ||
=== Technical Concerns === | === Technical Concerns === | ||
| + | |||
| + | ==== Compatibility ==== | ||
| + | Binary incompatible changes can only occur on major releases (the next is 1.1.0) and releases | ||
| + | are often years apart. | ||
| + | OpenSSL has a painful history of problems caused by references to OpenSSL internals, a | ||
| + | history that has left the survivors very paranoid about referencing or changing APIs or | ||
| + | structures (even those which seem to be clearly for internal use only). | ||
| + | |||
| + | New features cannot be added to existing stable releases as this violates the [[versioning]] | ||
| + | rule So adding new functionality to OpenSSL 0.9.8, 1.0.0 or 1.0.1 just isn't going to | ||
| + | happen ''unless'' that new functionality is needed to address a security hole or bug. | ||
==== Security Issues ==== | ==== Security Issues ==== | ||
| Line 11: | Line 22: | ||
==== Future Directions ==== | ==== Future Directions ==== | ||
(TBD) | (TBD) | ||
| + | |||
| + | ==== Maintainability ==== | ||
| + | Incorporation of new code into OpenSSL means an implicit obligation to support it | ||
| + | forever. There are many subtleties about OpenSSL which even surprise the experts at | ||
| + | times: new code may have unfortunate consequences and open up security holes. OpenSSL | ||
| + | is used on a very wide range of applications including a sizeable proportions of the | ||
| + | world's web servers and as a result the developers have to be pretty darned sure new | ||
| + | additions wont have unfortunate consequences. Comments and/or documentation can help | ||
| + | a lot here especially for addition of new features to OpenSSL itself. | ||
=== Presentation === | === Presentation === | ||
| Line 19: | Line 39: | ||
==== Coding Style ==== | ==== Coding Style ==== | ||
| − | + | Although there are some exceptions most of the OpenSSL code is indented in a rather | |
| + | quirky way. That style isn't documented but if you can't figure it out from looking | ||
| + | at existing source you haven't spend nearly enough time with OpenSSL to think about | ||
| + | changing it. If a reviewer has to reformat everything to fit with the current code | ||
| + | style that counts against it. | ||
=== Documentation === | === Documentation === | ||
| Line 25: | Line 49: | ||
==== Code Maturity ==== | ==== Code Maturity ==== | ||
| − | With documentation there is another factor. People rely on documentation as showing the preferred way of using the software, and once documented an API it effectively "cast in stone" for future versions of OpenSSL. There is a | + | With documentation there is another factor. People rely on documentation as showing the preferred way of using the software, and once documented an API it effectively "cast in stone" for future versions of OpenSSL. There is a rIs the code compatible with the OpenSSL license? New contributions will receive appropriate credit but they can't be expected to require every OpenSSL application to acknowledge the author in the documentation by adding additional attribution requirements. eluctance to document features that may not yet be in a final form. |
==== Abstraction Level ==== | ==== Abstraction Level ==== | ||
| Line 34: | Line 58: | ||
low level APIs when the corresponding preferred high level approach is not yet | low level APIs when the corresponding preferred high level approach is not yet | ||
adequately documented. | adequately documented. | ||
| + | |||
| + | === Licensing and Copyright === | ||
| + | Is the code compatible with the [[License|OpenSSL license]]? New contributions will receive | ||
| + | appropriate credit but they can't be expected to require every OpenSSL application to | ||
| + | acknowledge the author in the documentation by adding additional attribution requirements. | ||
Revision as of 12:08, 15 March 2013
There are a number of reasons why code or documentation contributions may not be adopted by the OpenSSL maintainers.
Technical Concerns
Compatibility
Binary incompatible changes can only occur on major releases (the next is 1.1.0) and releases are often years apart. OpenSSL has a painful history of problems caused by references to OpenSSL internals, a history that has left the survivors very paranoid about referencing or changing APIs or structures (even those which seem to be clearly for internal use only).
New features cannot be added to existing stable releases as this violates the versioning rule So adding new functionality to OpenSSL 0.9.8, 1.0.0 or 1.0.1 just isn't going to happen unless that new functionality is needed to address a security hole or bug.
Security Issues
(TBD)
Platform Portability
(TBD)
Future Directions
(TBD)
Maintainability
Incorporation of new code into OpenSSL means an implicit obligation to support it forever. There are many subtleties about OpenSSL which even surprise the experts at times: new code may have unfortunate consequences and open up security holes. OpenSSL is used on a very wide range of applications including a sizeable proportions of the world's web servers and as a result the developers have to be pretty darned sure new additions wont have unfortunate consequences. Comments and/or documentation can help a lot here especially for addition of new features to OpenSSL itself.
Presentation
(TBD)
Patch Format
(TBD)
Coding Style
Although there are some exceptions most of the OpenSSL code is indented in a rather quirky way. That style isn't documented but if you can't figure it out from looking at existing source you haven't spend nearly enough time with OpenSSL to think about changing it. If a reviewer has to reformat everything to fit with the current code style that counts against it.
Documentation
(TBD)
Code Maturity
With documentation there is another factor. People rely on documentation as showing the preferred way of using the software, and once documented an API it effectively "cast in stone" for future versions of OpenSSL. There is a rIs the code compatible with the OpenSSL license? New contributions will receive appropriate credit but they can't be expected to require every OpenSSL application to acknowledge the author in the documentation by adding additional attribution requirements. eluctance to document features that may not yet be in a final form.
Abstraction Level
With OpenSSL there is usually a preferred general high-level API (EVP) and then many lower level function calls that can be used to achieve similar outcomes. The higher level abstractions are usually the best solution for all common application requirements. As a result there is a reluctance to adopt and publish documentation of low level APIs when the corresponding preferred high level approach is not yet adequately documented.
Licensing and Copyright
Is the code compatible with the OpenSSL license? New contributions will receive appropriate credit but they can't be expected to require every OpenSSL application to acknowledge the author in the documentation by adding additional attribution requirements.
