RT is put out to pasture

list first.  Someone may be already working on the same thing or there

may be a good reason as to why that feature isn't implemented.

The best way to submit a patch is to make a pull request on GitHub.

(It is not necessary to send mail to rt@openssl.org to open a ticket!)

If you think the patch could use feedback from the community, please

start a thread on openssl-dev.

To submit a patch, make a pull request on GitHub.  If you think the patch

could use feedback from the community, please start a thread on openssl-dev

to discuss it.

You can also submit patches by sending it as mail to rt@openssl.org.

Please include the word "PATCH" and an explanation of what the patch

does in the subject line.  If you do this, our preferred format is "git

format-patch" output. For example to provide a patch file containing the

last commit in your local git repository use the following command:

    % git format-patch --stdout HEAD^ >mydiffs.patch

Another method of creating an acceptable patch file without using git is as

follows:

    % cd openssl-work

    ...make your changes...

    % ./Configure dist; make clean

    % cd ..

    % diff -ur openssl-orig openssl-work >mydiffs.patch

Note that pull requests are generally easier for the team, and community, to

work with.  Pull requests benefit from all of the standard GitHub features,

including code review tools, simpler integration, and CI build support.

No matter how a patch is submitted, the following items will help make

the acceptance and review process faster:

Having addressed the following items before the PR will help make the

acceptance and review process faster:

    1. Anything other than trivial contributions will require a contributor

    licensing agreement, giving us permission to use your code. See

        in the file LICENSE in the source distribution or at

        https://www.openssl.org/source/license.html

    3.  Patches should be as current as possible.  When using GitHub, please

    expect to have to rebase and update often. Note that we do not accept merge

    commits. You will be asked to remove them before a patch is considered

    acceptable.

    3.  Patches should be as current as possible; expect to have to rebase

    often. We do not accept merge commits; You will be asked to remove

    them before a patch is considered acceptable.

    4.  Patches should follow our coding style (see

    https://www.openssl.org/policies/codingstyle.html) and compile without

    warnings. Where gcc or clang is available you should use the

    --strict-warnings Configure option.  OpenSSL compiles on many varied

    platforms: try to ensure you only use portable features.

    Clean builds via Travis and AppVeyor are expected, and done whenever

    a PR is created or updated.

    5.  When at all possible, patches should include tests. These can either be

    added to an existing test, or completely new.  Please see test/README

    for information on the test framework.

    5.  When at all possible, patches should include tests. These can

    either be added to an existing test, or completely new.  Please see

    test/README for information on the test framework.

    6.  New features or changed functionality must include documentation. Please

    look at the "pod" files in doc/apps, doc/crypto and doc/ssl for examples of

    our style.

    6.  New features or changed functionality must include

    documentation. Please look at the "pod" files in doc/apps, doc/crypto

    and doc/ssl for examples of our style.

 If you have any problems with OpenSSL then please take the following steps

 first:

    - Download the current snapshot from ftp://ftp.openssl.org/snapshot/

    - Download the latest version from the repository

      to see if the problem has already been addressed

    - Remove ASM versions of libraries

    - Configure with no-asm

    - Remove compiler optimisation flags

 If you wish to report a bug then please include the following information in

 any bug report:

 If you wish to report a bug then please include the following information

 and create an issue on GitHub:

    - OpenSSL version: output of 'openssl version -a'

    - Any "Configure" options that you selected during compilation of the

    - Problem Description (steps that will reproduce the problem, if known)

    - Stack Traceback (if the application dumps core)

 Email the report to:

    rt@openssl.org

 In order to avoid spam, this is a moderated mailing list, and it might

 take a couple of days for the ticket to show up.  (We also scan posts to make

 sure that security disclosures aren't publicly posted by mistake.) Mail

 to this address is recorded in the public RT (request tracker) database

 (see https://www.openssl.org/community/index.html#bugs for details) and

 also forwarded the public openssl-dev mailing list.  Confidential mail

 may be sent to openssl-security@openssl.org (PGP key available from the

 key servers).

 Please do NOT use this for general assistance or support queries.

 Just because something doesn't work the way you expect does not mean it

 is necessarily a bug in OpenSSL. Use the openssl-users email list for this type

 of query.

 You can also make GitHub pull requests. See the CONTRIBUTING file for more

 details.

 HOW TO CONTRIBUTE TO OpenSSL

 ----------------------------

 LEGALITIES

 ----------

 A number of nations, in particular the U.S., restrict the use or export

 of cryptography. If you are potentially subject to such restrictions

 you should seek competent professional legal advice before attempting to

 develop or distribute cryptographic code.

 A number of nations, restrict the use or export of cryptography. If you

 are potentially subject to such restrictions you should seek competent

 professional legal advice before attempting to develop or distribute

 cryptographic code.