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