1*66bae5e7SchristosHOW TO CONTRIBUTE TO OpenSSL 2*66bae5e7Schristos============================ 3*66bae5e7Schristos 4*66bae5e7SchristosPlease visit our [Getting Started] page for other ideas about how to contribute. 5*66bae5e7Schristos 6*66bae5e7Schristos [Getting Started]: <https://www.openssl.org/community/getting-started.html> 7*66bae5e7Schristos 8*66bae5e7SchristosDevelopment is done on GitHub in the [openssl/openssl] repository. 9*66bae5e7Schristos 10*66bae5e7Schristos [openssl/openssl]: <https://github.com/openssl/openssl> 11*66bae5e7Schristos 12*66bae5e7SchristosTo request new features or report bugs, please open an issue on GitHub 13*66bae5e7Schristos 14*66bae5e7SchristosTo submit a patch, please open a pull request on GitHub. If you are thinking 15*66bae5e7Schristosof making a large contribution, open an issue for it before starting work, 16*66bae5e7Schristosto get comments from the community. Someone may be already working on 17*66bae5e7Schristosthe same thing or there may be reasons why that feature isn't implemented. 18*66bae5e7Schristos 19*66bae5e7SchristosTo make it easier to review and accept your pull request, please follow these 20*66bae5e7Schristosguidelines: 21*66bae5e7Schristos 22*66bae5e7Schristos 1. Anything other than a trivial contribution requires a [Contributor 23*66bae5e7Schristos License Agreement] (CLA), giving us permission to use your code. 24*66bae5e7Schristos If your contribution is too small to require a CLA (e.g. fixing a spelling 25*66bae5e7Schristos mistake), place the text "`CLA: trivial`" on a line by itself separated by 26*66bae5e7Schristos an empty line from the rest of the commit message. It is not sufficient to 27*66bae5e7Schristos only place the text in the GitHub pull request description. 28*66bae5e7Schristos 29*66bae5e7Schristos [Contributor License Agreement]: <https://www.openssl.org/policies/cla.html> 30*66bae5e7Schristos 31*66bae5e7Schristos To amend a missing "`CLA: trivial`" line after submission, do the following: 32*66bae5e7Schristos 33*66bae5e7Schristos ``` 34*66bae5e7Schristos git commit --amend 35*66bae5e7Schristos [add the line, save and quit the editor] 36*66bae5e7Schristos git push -f 37*66bae5e7Schristos ``` 38*66bae5e7Schristos 39*66bae5e7Schristos 2. All source files should start with the following text (with 40*66bae5e7Schristos appropriate comment characters at the start of each line and the 41*66bae5e7Schristos year(s) updated): 42*66bae5e7Schristos 43*66bae5e7Schristos ``` 44*66bae5e7Schristos Copyright 20xx-20yy The OpenSSL Project Authors. All Rights Reserved. 45*66bae5e7Schristos 46*66bae5e7Schristos Licensed under the Apache License 2.0 (the "License"). You may not use 47*66bae5e7Schristos this file except in compliance with the License. You can obtain a copy 48*66bae5e7Schristos in the file LICENSE in the source distribution or at 49*66bae5e7Schristos https://www.openssl.org/source/license.html 50*66bae5e7Schristos ``` 51*66bae5e7Schristos 52*66bae5e7Schristos 3. Patches should be as current as possible; expect to have to rebase 53*66bae5e7Schristos often. We do not accept merge commits, you will have to remove them 54*66bae5e7Schristos (usually by rebasing) before it will be acceptable. 55*66bae5e7Schristos 56*66bae5e7Schristos 4. Patches should follow our [coding style] and compile without warnings. 57*66bae5e7Schristos Where `gcc` or `clang` is available you should use the 58*66bae5e7Schristos `--strict-warnings` `Configure` option. OpenSSL compiles on many varied 59*66bae5e7Schristos platforms: try to ensure you only use portable features. Clean builds via 60*66bae5e7Schristos GitHub Actions and AppVeyor are required, and they are started automatically 61*66bae5e7Schristos whenever a PR is created or updated. 62*66bae5e7Schristos 63*66bae5e7Schristos [coding style]: https://www.openssl.org/policies/technical/coding-style.html 64*66bae5e7Schristos 65*66bae5e7Schristos 5. When at all possible, patches should include tests. These can 66*66bae5e7Schristos either be added to an existing test, or completely new. Please see 67*66bae5e7Schristos [test/README.md](test/README.md) for information on the test framework. 68*66bae5e7Schristos 69*66bae5e7Schristos 6. New features or changed functionality must include 70*66bae5e7Schristos documentation. Please look at the "pod" files in doc/man[1357] for 71*66bae5e7Schristos examples of our style. Run "make doc-nits" to make sure that your 72*66bae5e7Schristos documentation changes are clean. 73*66bae5e7Schristos 74*66bae5e7Schristos 7. For user visible changes (API changes, behaviour changes, ...), 75*66bae5e7Schristos consider adding a note in [CHANGES.md](CHANGES.md). 76*66bae5e7Schristos This could be a summarising description of the change, and could 77*66bae5e7Schristos explain the grander details. 78*66bae5e7Schristos Have a look through existing entries for inspiration. 79*66bae5e7Schristos Please note that this is NOT simply a copy of git-log one-liners. 80*66bae5e7Schristos Also note that security fixes get an entry in [CHANGES.md](CHANGES.md). 81*66bae5e7Schristos This file helps users get more in depth information of what comes 82*66bae5e7Schristos with a specific release without having to sift through the higher 83*66bae5e7Schristos noise ratio in git-log. 84*66bae5e7Schristos 85*66bae5e7Schristos 8. For larger or more important user visible changes, as well as 86*66bae5e7Schristos security fixes, please add a line in [NEWS.md](NEWS.md). 87*66bae5e7Schristos On exception, it might be worth adding a multi-line entry (such as 88*66bae5e7Schristos the entry that announces all the types that became opaque with 89*66bae5e7Schristos OpenSSL 1.1.0). 90*66bae5e7Schristos This file helps users get a very quick summary of what comes with a 91*66bae5e7Schristos specific release, to see if an upgrade is worth the effort. 92*66bae5e7Schristos 93*66bae5e7Schristos 9. Guidelines how to integrate error output of new crypto library modules 94*66bae5e7Schristos can be found in [crypto/err/README.md](crypto/err/README.md). 95