summaryrefslogtreecommitdiff
path: root/libressl/libressl/README
diff options
context:
space:
mode:
authorEduardo Chappa <chappa@washington.edu>2020-01-04 20:08:32 -0700
committerEduardo Chappa <chappa@washington.edu>2020-01-04 20:08:32 -0700
commitf398f615b6df385aec2b3553310cc237b29e068a (patch)
tree5af79c6a9a180c72c58a9d9cd2d79a1d7657d152 /libressl/libressl/README
parent77191bf3e4e049603fb6a0547876259c29c71dbd (diff)
downloadalpine-f398f615b6df385aec2b3553310cc237b29e068a.tar.xz
* The feature that stopped alpine from saving passwords in the password
file prevented users from actually saving their passwords in Windows and MAC OS. Fix the code so that passwords will be saved. Also, update the documentation of this feature. * Fix a buffer overflow bug in the XOAUTH2 code (off by one error). * Update PC-Alpine to work with Libressl version 3.0.2 instead of version 2.5.5 (update build.bat and lib files from the LibreSSL build). * Erase SSLXXXXXX file. * ssl_nt.c actually directs the code to ssl_libressl.c or ssl_win.c. The file ssl_libressl.c is the file ssl_unix.c from the unix osdep directory. The file ssl_win.c is the native SSL windows code. The Unix side provides S/MIME support for Alpine and the latest encryption protocols support for Alpine when connecting to a secure server, while the windows side provide TLSv1_3 support for Alpine, but not S/MIME support. In order to provide unix code for TLSv1_3 (once LibreSSL supports it) edit the file os_nt.c and remove the comments on the #ifdef section. This would provide both TLSv1_3 and S/MIME support with unix code. On the other hand, when we provide TLSv1_3 with the Windows code we need to undefine DF_ENCRYPTION_RANGE, and this is done in the file include/config.wnt.h. The way this is done as of this moment is by commenting an #else directive that preceedes this #undefine. * Update makefile.nt and friends in the windows side to account for the addition of XOAUTH2, and the use of only ssl_nt.c when dealing with Alpine. * Define SMIME_SSLCERTS as c:\libressl\ssl\certs, so that these certificates be considered while checking a digital S/MIME signature. * Improvements to the SMARTTIME24 token to account for changes in year.
Diffstat (limited to 'libressl/libressl/README')
-rw-r--r--libressl/libressl/README48
1 files changed, 48 insertions, 0 deletions
diff --git a/libressl/libressl/README b/libressl/libressl/README
new file mode 100644
index 00000000..c8ce75b5
--- /dev/null
+++ b/libressl/libressl/README
@@ -0,0 +1,48 @@
+The windows version of Alpine can be compiled with LibreSSL. The build
+script will compile using LibreSSL if there is a libressl folder in the
+main Alpine source code directory. If you rename or remove this folder,
+Alpine will be compiled using the default SSL libraries in your computer.
+
+There are pros and cons to every decision. Here are the pros and cons to
+building using LibreSSL.
+
+Pros:
+
+ * LibreSSL can be updated at any time. This will make it possible to
+ build Alpine with the latest features of LibreSSL. If you decide to
+ not use LibreSSL, your SSL libraries will eventually not be updated.
+
+ * Certificates can be updated at any time, and so you can run your
+ favorite version of Alpine for many years, even after your Windows
+ version is not supported anymore.
+
+ * You get S/MIME support in Windows for free.
+
+Cons:
+
+ * LibreSSL will check certificates not using the certificates installed
+ in your Windows computer, but it will use those saved in
+ C:\libressl\ssl]certs. This means that it is the responsibility of the
+ user to update the certificates. No matter what choice is made, if
+ certificates are not updated, validation will always eventually fail.
+
+Default Certificates Location:
+
+ * When Alpine is compiled with LibreSSL support, certificates must be
+ placed in the C:\\libressl\ssl\certs directory. You can find a copy
+ of certificates in the git repository in the libressl/certs directory.
+ All you have to do is to copy the certificates in that directory to
+ the C:\\libressl\ssl\certs directory.
+
+ * In order to make it easy to distribute certificates, each certificate
+ is distributed twice. Once with a long name, and another with the
+ short name. The short name is called the "subject hash". A unix script
+ called "doit.sh" can be used to create the short name. You can run
+ such script, from this directory by using the command
+
+ ./doit.sh
+
+ and copy the resulting files with short names, to the
+ C:\\libressl\ssl\certs folder. You only need the files with the short
+ names, but both are distributed.
+