From f398f615b6df385aec2b3553310cc237b29e068a Mon Sep 17 00:00:00 2001
From: Eduardo Chappa <chappa@washington.edu>
Date: Sat, 4 Jan 2020 20:08:32 -0700
Subject:    * 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.
---
 pith/pine.hlp | 18 ++++++++++++++++--
 1 file changed, 16 insertions(+), 2 deletions(-)

(limited to 'pith/pine.hlp')

diff --git a/pith/pine.hlp b/pith/pine.hlp
index aa86c17c..38d76e7a 100644
--- a/pith/pine.hlp
+++ b/pith/pine.hlp
@@ -140,7 +140,7 @@ with help text for the config screen and the composer that didn't have any
 reasonable place to be called from.
 Dummy change to get revision in pine.hlp
 ============= h_revision =================
-Alpine Commit 380 2019-12-19 08:22:29
+Alpine Commit 381 2020-01-04 20:07:10
 ============= h_news =================
 <HTML>
 <HEAD>
@@ -33910,7 +33910,15 @@ That is a separate and independent feature.
 <BODY>
 <H1>FEATURE: <!--#echo var="FEAT_disable-password-file-saving"--></H1>
 
-This feature changes the behavior of Alpine when a login name and password combination
+<P> This feature disables caching of passwords, even if your version of Alpine allows
+saving passwords. For MAC OS users saving passwords is done using the Apple Key Chain, for
+Windows users caching passwords is done using the internal Windows Credentials, and for
+other users this is done by using the password file. In this feature, the phrase
+&quot;password file&quot; is a misnomer and represents the way in which your system
+stores passwords.
+
+<P>
+Specifically, this feature changes the behavior of Alpine when a login name and password combination
 for a specific server is not found in the password file. The default behavior is that
 Alpine will ask the user if they wish to save this information in the password file for future
 use. It is assumed that if a user created a password file it is because they intend
@@ -33918,6 +33926,12 @@ to use it, but in some instances a user might want to save some passwords and no
 In this case, enabling this feature will make Alpine not add any more passwords to the
 password file and will only use the passwords that it already saved. If you wish to allow
 Alpine to save more passwords in the password file, disable this feature.
+
+<P> Regardless of which method Alpine uses to store passwords, this is done in a secure
+way when compiled with OpenSSL or LibreSSL. This is very likely to be your version, and
+you can check this by reading the encryption features
+<A HREF="X-Alpine-Config:">supported</A> by Alpine.
+
 <P>
 <UL>   
 <LI><A HREF="h_finding_help">Finding more information and requesting help</A>
-- 
cgit v1.2.3-54-g00ecf

