Don't check pointer we just freed, always set it to NULL.

[openssl.git] / README

diff --git a/README b/README
index 05198344260fe56e4c834d672d9bcb3fcc95b93e..13464f20b653aebc366b6e931b511ae6e230b009 100644 (file)
--- a/README
+++ b/README
@@ -1,7 +1,7 @@
 
  OpenSSL 1.1.0-dev
 
 
  OpenSSL 1.1.0-dev
 

- Copyright (c) 1998-2011 The OpenSSL Project
+ Copyright (c) 1998-2015 The OpenSSL Project

  Copyright (c) 1995-1998 Eric A. Young, Tim J. Hudson
  All rights reserved.
 
  Copyright (c) 1995-1998 Eric A. Young, Tim J. Hudson
  All rights reserved.
 


@@ -90,32 +90,6 @@
         SSL/TLS Client and Server Tests
         Handling of S/MIME signed or encrypted mail
 
         SSL/TLS Client and Server Tests
         Handling of S/MIME signed or encrypted mail
 

-
- PATENTS
- -------
-
- Various companies hold various patents for various algorithms in various
- locations around the world. _YOU_ are responsible for ensuring that your use
- of any algorithms is legal by checking if there are any patents in your
- country.  The file contains some of the patents that we know about or are
- rumored to exist. This is not a definitive list.
-
- RSA Security holds software patents on the RC5 algorithm.  If you
- intend to use this cipher, you must contact RSA Security for
- licensing conditions. Their web page is http://www.rsasecurity.com/.
-
- RC4 is a trademark of RSA Security, so use of this label should perhaps
- only be used with RSA Security's permission.
-
- The IDEA algorithm is patented by Ascom in Austria, France, Germany, Italy,
- Japan, the Netherlands, Spain, Sweden, Switzerland, UK and the USA.  They
- should be contacted if that algorithm is to be used; their web page is
- http://www.ascom.ch/.
-
- NTT and Mitsubishi have patents and pending patents on the Camellia
- algorithm, but allow use at no charge without requiring an explicit
- licensing agreement: http://info.isl.ntt.co.jp/crypt/eng/info/chiteki.html
-

  INSTALLATION
  ------------
 
  INSTALLATION
  ------------
 


@@ -161,19 +135,25 @@
     - Problem Description (steps that will reproduce the problem, if known)
     - Stack Traceback (if the application dumps core)
 
     - Problem Description (steps that will reproduce the problem, if known)
     - Stack Traceback (if the application dumps core)
 

- Report the bug to the OpenSSL project via the Request Tracker
- (http://www.openssl.org/support/rt.html) by mail to:
+ Email the report to:
+
+    rt@openssl.org

 
 

-    openssl-bugs@openssl.org
+ In order to avoid spam, this is a moderated mailing list, and it might
+ take a day for the ticket to show up.  (We also scan posts to make sure
+ that security disclosures aren't publically posted by mistake.) Mail to
+ this address is recorded in the public RT (request tracker) database (see
+ https://www.openssl.org/support/rt.html 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).

 
 

- Note that the request tracker should NOT be used 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.
+ 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.

 
 

- Note that mail to openssl-bugs@openssl.org is recorded in the publicly
- readable request tracker database and is forwarded to a public
- mailing list. Confidential mail may be sent to openssl-security@openssl.org
- (PGP key available from the key servers).
+ You can also make GitHub pull requests. If you do this, please also send
+ mail to rt@openssl.org with a link to the PR so that we can more easily
+ keep track of it.

 
  HOW TO CONTRIBUTE TO OpenSSL
  ----------------------------
 
  HOW TO CONTRIBUTE TO OpenSSL
  ----------------------------


@@ -190,11 +170,10 @@
  reason as to why that feature isn't implemented.
 
  Patches should be as up to date as possible, preferably relative to the
  reason as to why that feature isn't implemented.
 
  Patches should be as up to date as possible, preferably relative to the

- current CVS or the last snapshot. They should follow the coding style of
- OpenSSL and compile without warnings. Some of the core team developer targets
- can be used for testing purposes, (debug-steve64, debug-geoff etc). OpenSSL
- compiles on many varied platforms: try to ensure you only use portable
- features.
+ current Git or the last snapshot. They should follow our coding style
+ (see http://openssl.org/about/codingstyle.txt) and compile without
+ warnings using the --strict-warnings flag.  OpenSSL compiles on many
+ varied platforms: try to ensure you only use portable features.

 
  Note: For legal reasons, contributions from the US can be accepted only
  if a TSU notification and a copy of the patch are sent to crypt@bis.doc.gov
 
  Note: For legal reasons, contributions from the US can be accepted only
  if a TSU notification and a copy of the patch are sent to crypt@bis.doc.gov