1HOW TO CONTRIBUTE TO OpenSSL 2============================ 3 4Please visit our [Getting Started] page for other ideas about how to contribute. 5 6 [Getting Started]: <https://openssl-library.org/community/getting-started> 7 8Development is done on GitHub in the [openssl/openssl] repository. 9 10 [openssl/openssl]: <https://github.com/openssl/openssl> 11 12To request a new feature, ask a question, or report a bug, 13please open an [issue on GitHub](https://github.com/openssl/openssl/issues). 14 15To submit a patch or implement a new feature, please open a 16[pull request on GitHub](https://github.com/openssl/openssl/pulls). 17If you are thinking of making a large contribution, 18open an issue for it before starting work, to get comments from the community. 19Someone may be already working on the same thing, 20or there may be special reasons why a feature is not implemented. 21 22Similarly, if you plan to submit many pull requests, please start with 23a representative sample (no more than 3 or 4) and open an issue 24explaining your process. The OpenSSL project has limited resources, 25especially when it comes to reviewers, so we appreciate advanced 26communication before submitting many pull requests. In addition, 27contributors should personally evaluate potential patches generated by 28automated tools. 29 30To make it easier to review and accept your pull request, please follow these 31guidelines: 32 33 1. Anything other than a trivial contribution requires a [Contributor 34 License Agreement] (CLA), giving us permission to use your code. 35 If your contribution is too small to require a CLA (e.g., fixing a spelling 36 mistake), then place the text "`CLA: trivial`" on a line by itself below 37 the rest of your commit message separated by an empty line, like this: 38 39 ``` 40 One-line summary of trivial change 41 42 Optional main body of commit message. It might contain a sentence 43 or two explaining the trivial change. 44 45 CLA: trivial 46 ``` 47 48 It is not sufficient to only place the text "`CLA: trivial`" in the GitHub 49 pull request description. 50 51 [Contributor License Agreement]: <https://www.openssl.org/policies/cla.html> 52 53 To amend a missing "`CLA: trivial`" line after submission, do the following: 54 55 ``` 56 git commit --amend 57 # add the line, save and quit the editor 58 git push -f [<repository> [<branch>]] 59 ``` 60 61 2. All source files should start with the following text (with 62 appropriate comment characters at the start of each line and the 63 year(s) updated): 64 65 ``` 66 Copyright 20xx-20yy The OpenSSL Project Authors. All Rights Reserved. 67 68 Licensed under the Apache License 2.0 (the "License"). You may not use 69 this file except in compliance with the License. You can obtain a copy 70 in the file LICENSE in the source distribution or at 71 https://www.openssl.org/source/license.html 72 ``` 73 74 3. Patches should be as current as possible; expect to have to rebase 75 often. We do not accept merge commits, you will have to remove them 76 (usually by rebasing) before it will be acceptable. 77 78 4. Code provided should follow our [coding style] and [documentation policy] 79 and compile without warnings. 80 There is a [Perl tool](util/check-format.pl) that helps 81 finding code formatting mistakes and other coding style nits. 82 Where `gcc` or `clang` is available, you should use the 83 `--strict-warnings` `Configure` option. OpenSSL compiles on many varied 84 platforms: try to ensure you only use portable features. 85 Clean builds via GitHub Actions are required. They are started automatically 86 whenever a PR is created or updated by committers. 87 88 [coding style]: https://openssl-library.org/policies/technical/coding-style/ 89 [documentation policy]: https://openssl-library.org/policies/technical/documentation-policy/ 90 91 5. When at all possible, code contributions should include tests. These can 92 either be added to an existing test, or completely new. Please see 93 [test/README.md](test/README.md) for information on the test framework. 94 95 6. New features or changed functionality must include 96 documentation. Please look at the `.pod` files in `doc/man[1357]` for 97 examples of our style. Run `make doc-nits` to make sure that your 98 documentation changes are clean. 99 100 7. For user visible changes (API changes, behaviour changes, ...), 101 consider adding a note in [CHANGES.md](CHANGES.md). 102 This could be a summarising description of the change, and could 103 explain the grander details. 104 Have a look through existing entries for inspiration. 105 Please note that this is NOT simply a copy of git-log one-liners. 106 Also note that security fixes get an entry in [CHANGES.md](CHANGES.md). 107 This file helps users get more in-depth information of what comes 108 with a specific release without having to sift through the higher 109 noise ratio in git-log. 110 111 8. Guidelines on how to integrate error output of new crypto library modules 112 can be found in [crypto/err/README.md](crypto/err/README.md). 113