Adding upstream version 2.8.9rel.1.upstream/2.8.9rel.1upstream

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

2 files changed, 334 insertions, 0 deletions

diff --git a/docs/README.ssl b/docs/README.ssl
new file mode 100644
index 0000000..c9d1c79
--- /dev/null
+++ b/docs/README.ssl
@@ -0,0 +1,69 @@
+SSL support for Lynx 2.8.5pre.1
+-- adapted from http://www.mentovai.com/lynx/
+
+Lynx, in its unmodified form, will not allow you to make secure socket layer
+(SSL) connections.  SSL is used for the secure transfer of information over the
+Internet.  Many sites are now requiring SSL to ensure security for themselves
+and their users.  With a version of Lynx modified to support SSL, Lynx users
+can now visit these sites with ease as well.
+
+The SSL configure option (--with-ssl) for Lynx provides the ability to make use
+of SSL over HTTP for secure access to web sites (HTTPS) and over NNTP for
+secure access to news servers (SNEWS).  SSL is handled transparently, allowing
+users to continue accessing web sites and news services from within Lynx
+through the same interface for both secure and standard transfers.
+
+This is based on, and requires, the OpenSSL library.  OpenSSL's distribution
+and use may be restricted by licenses and laws.  For information on obtaining
+OpenSSL, as well as information on its distribution, see
+
+	http://www.openssl.org/
+
+The main distribution site is at
+
+	ftp://ftp.openssl.org/source/
+
+Lynx also has experimental support for GnuTLS (configure option --with-gnutls).
+For information on GnuTLS, see
+
+	http://www.gnu.org/software/gnutls/
+
+To test your version of Lynx for SSL support, try it out with an SSL site.
+Below are secure (https) pages which will load if your browser contains SSL
+support and you accept their certificates; they give you some information about
+the connection.
+
+	https://www.gnutls.org:5555/
+	https://www2.ggn.net/cgi-bin/ssl
+
+Lynx will complain about the certificate, since the certificate presented is
+untrusted.  You may accept this certificate to test your configuration, since
+it is a test, but it is a bad idea to blindly accept certificates from unknown
+websites if you are transmitting form data or files.
+
+You should review the document README.sslcerts for a detailed discussion of
+correct certificate handling possibilities and procedures in lynx.
+
+Users are reminded to check the laws and regulations about encryption software
+in their own countries.
+
+Here is the URL for US notification rules:
+
+	http://www.bxa.doc.gov/Encryption/PubAvailEncSourceCodeNofify.html
+
+Note that that isn't a typo; it really is "Nofify". The site contains
+links to the full EAR regulations.
+
+Lynx is GPL'd, for our own use it falls under the regulations in EAR section
+740.13(e)(1):
+
+    (1) Encryption source code controlled under 5D002, which would be
+        considered publicly available under section 734.3(b)(3) and
+        which is not subject an express agreement for the payment a
+        licensing fee or royalty for commercial production or sale of
+        any product developed with the source code, is released from
+        EI controls and may be exported or reexported without review
+        under License Exception TSU, provided you have submitted
+        written notification to BXA of the Internet location (e.g.,
+        URL or Internet address) or a copy of source code by the time
+        of export.
diff --git a/docs/README.sslcerts b/docs/README.sslcerts
new file mode 100644
index 0000000..39c3dcd
--- /dev/null
+++ b/docs/README.sslcerts
@@ -0,0 +1,265 @@
+        Lynx SSL support for certificates - README.sslcerts file
+
+BACKGROUND:
+
+The original README.ssl document for lynx stated:
+
+        Note that the server... may not have a valid certificate. Lynx will not
+        complain, as it does not yet support certificates...
+
+Such lack of support is no longer the case.  Lynx now features excellent
+certificate management through the openssl project.  There is almost no
+online documentation available regarding how to use openssl's certificate
+management with other programs, so this will accompany lynx and hopefully
+encourage good practical security for unix clients.
+
+Lynx relies on openssl to not only encrypt connections over https, but also to
+determine whether it should even accept a certificate and establish a secure
+connection with a remote host. Because of this reliance upon openssl by lynx,
+most of this tutorial deals with how to use openssl to "install" both
+vendor-provided CA cert bundles as well as self-signed certs from trusted sources
+and, most importantly, how to get them recognized by lynx.
+
+While lynx on many systems will transparently accept valid certificates, not
+all systems enjoy such functionality. Further, as noted above, older versions
+of lynx do not perform any validity checks on a certificate.
+
+There is also the common case of wanting to trust, use and install a
+self-signed certificate from a known server source and have it be trusted by
+client programs.
+
+Briefly, the procedure will involve confirming the default system location for
+certificates, setting values for SSL_CERT_DIR and SSL_CERT_FILE in
+the environment, and converting and hashing the certificates using openssl
+utilities to enable recognition.
+
+THE CURRENT SITUATION:
+
+Prior to lynx2.8.5dev9, lynx did not check at all for certificate validity.
+
+Since lynx2.8.5.dev9, lynx has reported this openssl error:
+
+SSL error:unable to get local issuer certificate-Continue? (y)
+
+whenever an https connection was initiated and the certificate could not be
+found, for whatever reason, by openssl, and therefore lynx.
+
+This checking for a certificate is an enhancement to security, but rather
+tediously generates errors at each https browser request.
+
+The ability to turn off reporting of this error to the user was added to
+lynx2.8.5dev16 as the FORCE_SSL_PROMPT setting in lynx.cfg as noted in the
+CHANGELOG:
+
+        This lets the user decide whether to ignore prompting for questionable
+        aspects of an SSL connection.
+
+While this is a convenient setting to employ when using lynx to script
+https -dumps, it by definition ignores the issue of certificate validity
+altogether. Those concerned with proper certificate management and
+the maintenance of a store of updated CA certificates will be uncomfortable
+with this relaxed security setting.
+
+The ability to accept a 'wildcard' certificate, where the first character
+is a '*' was added to lynx2.8.6dev18.
+
+PRELIMINARY PROCEDURES:
+
+It is assumed that openssl has been installed correctly, that the default
+cert directory is /usr/local/ssl/certs, (it's often /etc/ssl/certs, but we
+need a point of departure for the discussion) and that lynx has been compiled
+--with-ssl.
+
+The default location for certs on your system may be different, or there may not
+be one. You will have to substitute that location for /usr/local/ssl/certs in
+the following instructions, and/or set environment variables.
+
+To determine the default location for certs on your system you may run the
+following command:
+
+strings libcrypto.a  | grep -in cert | less
+
+Look in this output for SSL_CERT_DIR and SSL_CERT_FILE, and the lines just
+above them. This is your default location, respectively, for certificates,
+and the CA cert bundle, cert.pem. You will need to know where libcrypto.a is
+found of course.
+
+Example output:
+
+<snip>
+7490:/etc/ssl/certs
+7491:/etc/ssl/cert.pem
+7492:SSL_CERT_DIR
+7493:SSL_CERT_FILE
+<snip>
+
+Other possible example output:
+
+<snip>
+31555:/usr/local/ssl/certs
+31556:/usr/local/ssl/cert.pem
+31557:SSL_CERT_DIR
+31558:SSL_CERT_FILE
+<snip>
+
+Note that when OpenSSL is installed, the c_rehash utility is installed in a
+bin directory (default /usr/local/ssl/bin).  You will need to know where it
+is on your system. The command:
+
+whereis c_rehash
+
+will probably give useful results.
+
+Note also that there is no CA cert bundle distributed with OpenSSL. The
+OpenSSL team specifically decided NOT to do that. Getting a set of trusted
+certificates is left up to the installer.
+
+It is no longer a fairly trivial procedure to pull the bundle of trusted root certs out
+of a recent version of Internet Explorer. Multiple certificates are no longer 
+exportable as a DER formatted file; extraction of a single certificate is the only
+export for DER, and DER is what converts to PEM.
+
+Users with access to Apple OS X can export all certificates from Keychain Access System Roots as
+a .pem file. Place this in SSL_CERT_DIR and hash it and you're done.
+
+The MirOS BSD project also provides them. The procedure to convert and install them 
+is detailed later in this document, and if you simply need to have commercially provided 
+certificates trusted by lynx, you can skip down a few lines to the INSTALLING OR UPDATING
+THE CA BUNDLE section.
+
+Extracted Mozilla cert bundles are available for download from the curl project,
+http://curl.haxx.se/docs/caextract.html along with a script to extract from Mozilla
+source.
+
+
+INSTALLING A SELF-SIGNED CERTIFICATE:
+
+When you would like to trust a self-signed (non-commercial) certificate you will
+need to get hold of the actual file. If it's a cert local to your network you
+can ask the sysadmin to make it available for download as a link on a webpage.
+
+If such file is not human-readable it's probably DER formatted and will need to
+be converted to PEM format to allow openssl to use it.
+
+To convert DER formatted certificates into something openssl can deal with:
+
+Save the cert as site_name.crt in a directory. In that directory, type:
+
+openssl x509 -inform DER -in site_name.crt -outform PEM -out site_name.pem
+
+You can now copy this individual cert into the directory for that, usually
+/usr/local/ssl/certs.  The alternative is to concatenate the individual certs
+to the cert.pem bundle in /usr/local/ssl. (Please see INSTALLING OR UPDATING
+THE CA BUNDLE below).
+
+The cert file will now be in an acceptable format to openssl, PEM encoded.
+However, openssl, and by extension lynx, will not know about it until that
+cert is symbolically linked to a file named after the hash value of that cert,
+in the default directory /usr/local/ssl/certs.
+
+So the next thing to do is to hash the cert using c_rehash.
+
+INSTALLING OR UPDATING THE CA BUNDLE:
+
+Now would be a good time to check to see if you have the bundle of CA certs
+/usr/local/ssl/cert.pem, or to update them.
+
+CA bundles are available in various places, such as the MirOS BSD distribution,
+for those who want to take that route, or you can extract the current bundle
+from a current version of Internet Explorer (export them all from IE and
+transfer it onto your system).
+
+From MirOS, a cert bundle is available at
+
+http://caunter.ca/ssl.certs.shar
+
+It includes the cacert.org certificate. Download the latest revision; read the
+file to see how to get the certs out.
+
+No hashing is necessary with this set of certs; it is already done; ignore
+the c_rehash usage below for this bundle. Simply run `sh ssl.certs.shar` 
+in SSL_CERT_DIR.
+
+From IE 5.x certs extract as a PKCS7 file and need to be converted with something
+like:
+
+openssl pkcs7 -inform DER -in bundle.crt -outform PEM -out cert.pem \
+-print_certs -text
+
+The resulting cert.pem file should be copied to the default directory for
+bundles (usually /usr/local/ssl) and renamed to "cert.pem", assuming that is
+the SSL_CERT_FILE.
+
+Individual certs can also process if added and hashed in /usr/local/ssl/certs.
+
+We now have all of the individual certs we wish to trust in our certs
+directory, and the most recent bundle of CA certs as well.
+
+Confirm that you have the script c_rehash (See PRELIMINARY PROCEDURES; if it is
+not found, a copy is usually located in the tools directory of the openssl
+source tree. If you use this copy, it needs the execute bit set or it will not
+run).
+
+Run:
+
+./c_rehash
+
+The c_rehash utility is a perl script that runs openssl commands which creates
+the files named after the hash values of the certs in the default directory
+for certs.
+
+Its output looks like this:
+
+Doing /usr/local/ssl/certs
+vsignss.pem => f73e89fd.0
+vsign3.pem => 7651b327.0
+...more output
+<snip>
+
+All pem encoded certs in /usr/local/ssl/certs will now be recognized.
+
+SETTING AND EXPORTING ENVIRONMENT VARIABLES:
+
+If lynx is still not recognizing certs, environment variables need
+to be set; if on a sh type shell, the variables also need to be exported.
+
+The environment variables SSL_CERT_DIR and SSL_CERT_FILE need to be set
+if a non-default location is used for certificates, or if certs just can't be
+found by lynx. They may be set as follows in /etc/profile, or a shell
+initialization .profile or .*shrc, if we run a non csh type shell, according
+to the results of the search for the default location for certs procedure
+(See PRELIMINARY PROCEDURES):
+
+SSL_CERT_DIR="/usr/local/ssl/certs"
+SSL_CERT_FILE="/usr/local/ssl/cert.pem"
+export SSL_CERT_DIR SSL_CERT_FILE
+
+On csh type shells, you can use:
+setenv SSL_CERT_DIR "/usr/local/ssl/certs"
+setenv SSL_CERT_FILE "/usr/local/ssl/cert.pem"
+
+Note that the environment variable SSL_CERT_FILE applies to the cert-bundle
+if used outside of the default location (/usr/local/ssl/cert.pem) compiled
+into OpenSSL. There are issues with SSL_CERT_FILE in 0.9.6x versions of openssl.
+
+The configuration file lynx.cfg allows a system SSL_CERT_FILE variable to be set
+which can simplify matters. 
+
+SSL_CERT_FILE:/etc/ssl/certs/ca-certificates.crt
+
+Make sure you have FORCE_SSL_PROMPT set to PROMPT in lynx.cfg like so:
+
+FORCE_SSL_PROMPT:PROMPT
+
+You will now connect without error to https servers with trusted certs, but
+will still get this error for untrusted certs:
+
+SSL error:self signed certificate-Continue? (y)
+
+A quick check confirms that these procedures have the same effect with ssl
+errors in the pine program.
+
+2003 updated 2009
+Stefan Caunter <stefan.caunter@mohawkcollege.ca>
+Mohawk College Department of Computer Science
+Hamilton Ontario Canada