From lucio at lambrate.inaf.it Tue Dec 4 02:33:25 2018 From: lucio at lambrate.inaf.it (Lucio Chiappetti) Date: Tue Dec 4 02:36:03 2018 Subject: [Alpine-info] can I turn off S/MIME ? Message-ID: I am sporadically seeing messages like this "Couldn't verify S/MIME signature: signer certificate not found" or other I cannot reproduce now asking me if I want to save something. Usually this happens while I am scanning my inbox, and in particular if the next message is a MIME digest from some mailing list. In this case the prompt to save something may appear more than once which is annoying. I see such digests contain Multipart/x-pkcs7-enclosure attachments. I usually reply NO or ctl-C. I am not receiving S/MIME mail from known regular correspondents, and currently I am not interested in it. Curiously, the message does not always present again if I enter the same folder (at least in the same session ?) even if I replied NO. Can I just go to the configuration (M S M) and tick [ ] S/MIME -- Turn off S/MIME Will this just suppress the annoying messages and have no other side effect ? -- Lucio Chiappetti - INAF/IASF - via Bassini 15 - I-20133 Milano (Italy) For more info : http://www.iasf-milano.inaf.it/~lucio/personal.html ------------------------------------------------------------------------ "All that is google does not glitter Nor all who use alpine/procmail are lost" From alpine.chappa at gmx.com Tue Dec 4 20:32:52 2018 From: alpine.chappa at gmx.com (Eduardo Chappa) Date: Tue Dec 4 20:33:21 2018 Subject: [Alpine-info] can I turn off S/MIME ? In-Reply-To: References: Message-ID: On Tue, 4 Dec 2018, Lucio Chiappetti wrote: > Can I just go to the configuration (M S M) and tick > > [ ] S/MIME -- Turn off S/MIME > > Will this just suppress the annoying messages and have no other side > effect ? Dear Lucio, thank you for asking such question. I dared to do it, and I got Alpine immediately to crash. There is an unprotected check for a value of a pointer which is NULL, and this makes Alpine crash. Let me work on this for a little bit, to fix this correctly. Thank you. -- Eduardo https://tinyurl.com/yc377wlh (Web) http://repo.or.cz/alpine.git (Git) RSS: http://repo.or.cz/alpine.git/rss (Git updates) RSS: https://tinyurl.com/ybj33j2a (Web updates) From lucio at lambrate.inaf.it Wed Dec 5 03:17:32 2018 From: lucio at lambrate.inaf.it (Lucio Chiappetti) Date: Wed Dec 5 03:18:14 2018 Subject: [Alpine-info] can I turn off S/MIME ? In-Reply-To: References: Message-ID: On Tue, 4 Dec 2018, Eduardo Chappa wrote: > On Tue, 4 Dec 2018, Lucio Chiappetti wrote: >> [ ] S/MIME -- Turn off S/MIME > thank you for asking such question. I dared to do it, and I got Alpine > immediately to crash. There is an unprotected check for a value of a > pointer which is NULL, and this makes Alpine crash. Dear Eduardo, I also dared to do it (in 2.21 all-patches) and apparently initially I got no problem. It suppressed the annoying messages and everything worked normally ... ... however ... ... after reading your message I tried M S M to go back and check if I had left it disabled ... AND ALPINE IMMEDIATELY BUMMED OUT ... apparently once the option is set, one cannot enter M S M. However one can enter M S C, and unset the option from there (if display hidden config is enabled ? for me it is). Then everything goes back working normally. I thought as last resort (if M S C hadn't worked) one could manually edit .pinerc, which is possibly true but the names of the variables/options in .pinerc are not those shown by M S C (for instance they are lower case and not only) Cheers -- Lucio Chiappetti - INAF/IASF - via Bassini 15 - I-20133 Milano (Italy) For more info : http://www.iasf-milano.inaf.it/~lucio/personal.html ------------------------------------------------------------------------ "All that is google does not glitter Nor all who use alpine/procmail are lost" From lucio at lambrate.inaf.it Wed Dec 5 09:28:00 2018 From: lucio at lambrate.inaf.it (Lucio Chiappetti) Date: Wed Dec 5 09:32:04 2018 Subject: [Alpine-info] text attachments (not necessarily an alpine question) Message-ID: I always avoided sending plain text attachments (typically short shell script or source code) in the mail body (to prevent unwanted line wrap), but send them as attachments. (also in general I do not save attachments in fcc;) I have always thought that plain text attachments (unlike other "binary" files) be sent verbatim, unencoded, as byte streams preserving the original line length. Yesterday I sent a script to a colleague next door (since he was not available at the moment, and the disk area shared among us would be cleaned overnight). Today he told me the script was not working with very odd shell errors. (even a plain "set echo" gave error) At the end they resulted to extra carriage returns being present in the script he saved. I verified that: - alpine sends the file as Content-Type: text/plain; Content-Transfer-Encoding: BASE64 **always** irrespective of file/line length or content (and it is documented) - of course alpine is fully capable of saving the attachment identical to the original file - it is the MUA of the recipient (which could be either thunderbird or firefox/gmail) which adds extra carriage returns, despite the fact my colleague's machine is a linux identical to mine ... unfortunately he recently moved from alpine to those MUAs for reasons too long to explain here So this is clearly not (only) an alpine question. I am not sure how the alpine BASE64 encoding maps newlines (as newlines or as newline-carriage return or as some other line terminator) and how the other MUAs see them (do they find the carriage returns in the attachment or do they add them ?). (Just by curiosity, if my colleague sends a text attachment, they are sent as quoted-printable not BASE64. Of course my alpine can handle that). So far I had (myself) carriage return problems only very occasionally from some non-linux correspondent sending his native text files zipped or alike, and since I use a cat -v alias I usually spot it soon and remove the cr. From mattack at apple.com Wed Dec 5 10:08:16 2018 From: mattack at apple.com (Matt Ackeret) Date: Wed Dec 5 10:08:55 2018 Subject: [Alpine-info] text attachments (not necessarily an alpine question) In-Reply-To: References: Message-ID: <4599075C-34F5-4501-9098-C5949FE824E5@apple.com> > On Dec 5, 2018, at 9:28 AM, Lucio Chiappetti wrote: > > So far I had (myself) carriage return problems only very occasionally from some non-linux correspondent sending his native text files zipped or alike, and since I use a cat -v alias I usually spot it soon and remove the cr. well, I guess this isn't going to help, but I was going to suggest gzipping them to avoid this, since they'll receive them as binary files? From alpine.chappa at gmx.com Wed Dec 5 13:36:32 2018 From: alpine.chappa at gmx.com (Eduardo Chappa) Date: Wed Dec 5 13:35:53 2018 Subject: [Alpine-info] text attachments (not necessarily an alpine question) In-Reply-To: References: Message-ID: On Wed, 5 Dec 2018, Lucio Chiappetti wrote: > At the end they resulted to extra carriage returns being present in the > script he saved. Dear Lucio, internally Alpine does the following for text/* attachments: * Every end of line "\n" is transformed to "\r\n". * The result is base64 encoded. * The result is wrapped and attached. This is done this way because the standard RFC 2045 says so in section 6.8, namely: "In particular, text line breaks must be converted into CRLF sequences prior to base64 encoding." The receiving agent should see that a text plain was attached and should transform those \r\n line breaks to whatever line terminator in the system for the user is. I hope this helps. -- Eduardo From arifsaha at yahoo.com Wed Dec 5 19:56:11 2018 From: arifsaha at yahoo.com (S P Arif Sahari Wibowo) Date: Wed Dec 5 19:58:06 2018 Subject: [Alpine-info] Crash on Bounce command Message-ID: Hi! Every time I am in mailbox screen (list of emails), choose an email and press B (bounce) alpine immediatedly crash with the message "Received abort signal(sig=11)" and "Abort trap: 6". I compiled alpine 2.21 without tcl and with all_patch on macOS 10.12. Any thought? Look like this after the crash: ? Help < FldrList P PrevMsg - PrevPage D Delete R Reply Problem detected: "Received abort signal(sig=11)".Msg Spc NextPage U Undelete F Forward Alpine Exiting. Abort trap: 6 -- ____ ____ ____ ____ (stephan paul) Arif Sahari Wibowo /___ /___/ /___/ /___ http://www.arifsaha.com/ ____/ / / / ____/ From alpine.chappa at gmx.com Wed Dec 5 20:52:13 2018 From: alpine.chappa at gmx.com (Eduardo Chappa) Date: Wed Dec 5 20:52:32 2018 Subject: [Alpine-info] Crash on Bounce command In-Reply-To: References: Message-ID: On Wed, 5 Dec 2018, S P Arif Sahari Wibowo wrote: > Every time I am in mailbox screen (list of emails), choose an email and press > B (bounce) alpine immediatedly crash with the message "Received abort > signal(sig=11)" and "Abort trap: 6". > > I compiled alpine 2.21 without tcl and with all_patch on macOS 10.12. > > Any thought? Dear Arif, This is a problem which you can find resolved in any version after 2.21. You can check out the latest version for the git repo at http://repo.or.cz/alpine.git -- Eduardo https://tinyurl.com/yc377wlh (Web) http://repo.or.cz/alpine.git (Git) RSS: http://repo.or.cz/alpine.git/rss (Git updates) RSS: https://tinyurl.com/ybj33j2a (Web updates) From lucio at lambrate.inaf.it Thu Dec 6 02:36:24 2018 From: lucio at lambrate.inaf.it (Lucio Chiappetti) Date: Thu Dec 6 02:36:41 2018 Subject: [Alpine-info] text attachments (not necessarily an alpine question) In-Reply-To: References: Message-ID: On Wed, 5 Dec 2018, Eduardo Chappa wrote: > internally Alpine does the following for text/* attachments: > > * Every end of line "\n" is transformed to "\r\n". > * The result is base64 encoded. > * The result is wrapped and attached. > > This is done this way because the standard RFC 2045 says so in section > 6.8, namely: Dear Eduardo, thanks for spelling out how alpine works, and also for giving the reference to RFC 2045 (RFC 2049 is also referred therein), And in particular for stating that alpine IS FULLY STANDARD CONFORMING. Which unfortunately cannot be said for other *major* MUAs :-( > The receiving agent should see that a text plain was attached and should > transform those \r\n line breaks to whatever line terminator in the > system for the user is. Apparently this is what thunderbird and firefox/gmail do NOT do. Before your answer I did some experimenting and what I found empirically is the following: - text attachment can de facto be encoded as base64 or quoted-printable (apparently the other quoted MUAs seem to use quoted-printable) - alpine receiving such attachments with either encoding can decode and save them as proper linux text files (newline terminated) - base64 apparently exists in two flavours. At least this page https://www.base64encode.org/ offers two ways, LF and CRLF terminated - alpine receiving base64 attachments in both flavours can decode and save them as proper linux text files (newline terminated) - alpine sends in the CRLF flavour (and my finding terminated here), which now I know is the correct standard conforming way - the other MUAs do not do the CR stripping My tests were done saving a message with attachment as only message in a folder, than using the H command to view them as they are (I could also have opened the folder with an editor) The first line of the encoded attachment is IyEvYmluL2NzaCAtZg0KIyBpbnRlcnJvZ2F0ZSB2aWEgZXhwZWN0IHRoZSBq which decoded with the linux base4 command (or the web "decode" facility) corresponds to one and half line of my script #!/bin/csh -f # interrogate via expect the j I say one and half because correctly the first line is newline terminated and the second is truncated in the middle After that I tried the web "encode" facility with the two flavours, and saw that the one-and-half line can be encoded as IyEvYmluL2NzaCAtZgojIGludGVycm9nYXRlIHZpYSBleHBlY3QgdGhlIGo= (LF) or IyEvYmluL2NzaCAtZg0KIyBpbnRlcnJvZ2F0ZSB2aWEgZXhwZWN0IHRoZSBq (CRLF) and indeed decoding them using a cat option which displays CRs (my default "type" alias) shows the carriage return when there lucio 291 > base64 -d | cat -v IyEvYmluL2NzaCAtZgojIGludGVycm9nYXRlIHZpYSBleHBlY3QgdGhlIGo= #!/bin/csh -f # interrogate via expect the jlucio 292 > lucio 292 > base64 -d | cat -v IyEvYmluL2NzaCAtZg0KIyBpbnRlcnJvZ2F0ZSB2aWEgZXhwZWN0IHRoZSBq #!/bin/csh -f^M # interrogate via expect the jlucio 292 > Finally I edited the saved folder reducing the attachment only to the first encoded row, and, replacing it with either the CRLF or LF form verified that alpine deals equally well with either. Which unfortunately canno be said of the other MUAs On Wed, 5 Dec 2018, Matt Ackeret wrote: > well, I guess this isn't going to help, but I was going to suggest > gzipping them to avoid this, since they'll receive them as binary files? I would have said "tarring" instead of (g)zipping, but I consider it a sort of overshoot for transfer next door :-) In fact I have occasionally incurred in the reverse situation, Me on the receiving end, receiving a .zip (pkzip) file, and finding that the text file(s) therein were CRLF terminated, so I stripped the CR (usually those are data files for ingestion in some database ... if they were text files for reading my "type" alias would have shown the CRs ... but most people's type command won't shown them so they will read them and ignore the CRs). The CRs are apparently annoying only when the text file is a shell script which has to be executed. And any solution like zipping, tarring, gzipping may be ok when sending to a specified recipient whose operating system and environment is known, but is not adequate for sending to e.g. a generic mailing list or distribution list. -- ------------------------------------------------------------------------ Lucio Chiappetti - INAF/IASF - via Bassini 15 - I-20133 Milano (Italy) ------------------------------------------------------------------------ The reasonable man tries to adapt himself to the world The unreasonable man tries to adapt the world to himself Therefore all progress depends on the unreasonable man (G.B.Shaw) ------------------------------------------------------------------------ For more info : http://www.iasf-milano.inaf.it/~lucio/personal.html ------------------------------------------------------------------------ From robin.listas at telefonica.net Thu Dec 6 06:04:24 2018 From: robin.listas at telefonica.net (Carlos E. R.) Date: Thu Dec 6 06:08:04 2018 Subject: [Alpine-info] text attachments (not necessarily an alpine question) In-Reply-To: References: Message-ID: On 05/12/2018 18.28, Lucio Chiappetti wrote: > I always avoided sending plain text attachments (typically short shell > script or source code) in the mail body (to prevent unwanted line wrap), > but send them as attachments. Me too, some times. > (also in general I do not save attachments in fcc;) > > I have always thought that plain text attachments (unlike other "binary" > files) be sent verbatim, unencoded, as byte streams preserving the > original line length. No. Years ago I found out when sending Linux software translations (*po/*pot) as text that the encoding was changed, and I asked here. Text can be translated from machine to machine to what that machine and MUA interprets as text. To avoid problems you have to send as binary, which is a pain, I know. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 188 bytes Desc: OpenPGP digital signature URL: From alpine.chappa at gmx.com Thu Dec 6 15:36:45 2018 From: alpine.chappa at gmx.com (Eduardo Chappa) Date: Thu Dec 6 15:36:01 2018 Subject: [Alpine-info] can I turn off S/MIME ? In-Reply-To: References: Message-ID: On Wed, 5 Dec 2018, Lucio Chiappetti wrote: > Dear Eduardo, > I also dared to do it (in 2.21 all-patches) and apparently > initially I got no problem. It suppressed the annoying messages and > everything worked normally ... > > ... however ... > > ... after reading your message I tried M S M to go back and check if I had > left it disabled ... AND ALPINE IMMEDIATELY BUMMED OUT Dear Lucio, I identified the problems: 1. The crash you suffered was from an unprotected dereferencing of a null pointer. I had seen this crash also, and luckily it was an easy fix. 2. There was another crash, due to a double freeing of memory. I had to create a new function to release the memorey allocated, and free memory that way everywhere in Alpine to avoid this issue in the future. I will push these changes to the git repository tonight. Thank you for your patience! -- Eduardo From alpine.chappa at gmx.com Tue Dec 11 07:44:27 2018 From: alpine.chappa at gmx.com (Eduardo Chappa) Date: Tue Dec 11 07:44:02 2018 Subject: [Alpine-info] Support of the SSL protocol in Alpine Message-ID: Hello everyone, I want to make a change in the code for Alpine, which I wanted to discuss with you. When a user connects to a server, and attempts to do so securely, the first interaction between Alpine and the server is insecure and it is done by OpenSSL/LibreSSL attempting to start a secure connection. Once the connection is secure, Alpine starts talking email language to the server. This message is about the first step, when Open/LibreSSL connects to the server. When negotiating a secure connection, Alpine does so when a user adds the /ssl parameter to the server path. In the past, it used to mean to use the protocol SSL version 3, but now in the world of encryption people have moved to using different versions of the TLS protocol; meaning TLS version 1.1, 1.2 or 1.3. In order to support this, there are /tlsv1_1, /tlsv1_2, etc. parameters to the server name, and this means that I need to write several "ifdef" macros in the code. On top of that, it is not clear that all versions of Alpine across different systems support all these options. Much depends on the system that is being used. For example, at work I run a version of OpenSuse that supports different methods to do secure connections than the one I run at home. Other examples, are versions of PC-Alpine, where people run different versions of Windows with different support for SSL. I will talk more about this in a different message. Finally, OpenSSL is moving away from making secure connections using specific protocols. What this means is that OpenSSL is moving towards making a secure connection to the server using the most secure method that both OpenSSL and the server support, rather than using specific versions of the encryption protocol. So, instead of filling up Alpine with switches /tlsv1_1, /tlsv1_2, etc. I think it makes more sense to interpret the /ssl parameter to mean let OpenSSL/LibreSSL negotiate the most secure connection possible. Besides this advantage, it makes it easier for users to use Alpine because they do not have to worry about learning the difference between different encryption protocols and try to make a decision based on that, when server providers do not advertise what version of the ssl protocol they support. In practice from the programmers perspective, this would simplify the code, and we would just have to use the sslv23_client_method() call to make a secure connection. Do not be deceived by the name. This is what the manual says about them for OpenSSL version 1.0.2j-fips: SSLv23_method(), SSLv23_server_method(), SSLv23_client_method() These are the general-purpose version-flexible SSL/TLS methods. The actual protocol version used will be negotiated to the highest version mutually supported by the client and the server. The supported protocols are SSLv2, SSLv3, TLSv1, TLSv1.1 and TLSv1.2. Most applications should use these method, and avoid the version specific methods described below. So I would like to know if there is any reason why we should not be using this function instead of continuing to add #ifdef to the code, which makes it hard to read and support. If there is anything that I missed here, please add to this. Thank you. -- Eduardo From paul at jakma.org Tue Dec 11 08:16:11 2018 From: paul at jakma.org (Paul Jakma) Date: Tue Dec 11 08:17:57 2018 Subject: [Alpine-info] Support of the SSL protocol in Alpine In-Reply-To: References: Message-ID: On Tue, 11 Dec 2018, Eduardo Chappa wrote: > I think it makes more sense to interpret the /ssl parameter to mean > let OpenSSL/LibreSSL negotiate the most secure connection possible. > Besides this advantage, it makes it easier for users to use Alpine > because they do not have to worry about learning the difference > between different encryption protocols and try to make a decision > based on that, when server providers do not advertise what version of > the ssl protocol they support. As an alpine user, +1 from me! regards, -- Paul Jakma | paul@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A Fortune: How do I type "for i in *.dvi do xdvi $i done" in a GUI? -- Discussion in comp.os.linux.misc on the intuitiveness of interfaces From unrtst at gmail.com Tue Dec 11 08:52:59 2018 From: unrtst at gmail.com (Joshua Miller) Date: Tue Dec 11 08:53:41 2018 Subject: [Alpine-info] Support of the SSL protocol in Alpine In-Reply-To: References: Message-ID: On Tue, Dec 11, 2018 at 10:44 AM Eduardo Chappa wrote: > Hello everyone, > Howdy! So, instead of filling up Alpine with switches /tlsv1_1, /tlsv1_2, etc. > I think it makes more sense to interpret the /ssl parameter to mean let > OpenSSL/LibreSSL negotiate the most secure connection possible. Besides > this advantage, it makes it easier for users to use Alpine because they do > not have to worry about learning the difference between different > encryption protocols and try to make a decision based on that, when > server providers do not advertise what version of the ssl protocol they > support. > > In practice from the programmers perspective, this would simplify the > code, and we would just have to use the sslv23_client_method() call to > make a secure connection. Do not be deceived by the name. This is what the > manual says about them for OpenSSL version 1.0.2j-fips: > > SSLv23_method(), SSLv23_server_method(), SSLv23_client_method() > These are the general-purpose version-flexible SSL/TLS methods. The > actual protocol version used will be negotiated to the highest > version mutually supported by the client and the server. The > supported protocols are SSLv2, SSLv3, TLSv1, TLSv1.1 and TLSv1.2. > Most applications should use these method, and avoid the version > specific methods described below. > > So I would like to know if there is any reason why we should not be using > this function instead of continuing to add #ifdef to the code, which makes > it hard to read and support. > > If there is anything that I missed here, please add to this. Sadly, what I'm about to suggest is the least friendly from the programming side... On the user side, using one flag to enable a do-your-best ssl connection seems quite good. I think that would end up working for most users, myself included, in almost all cases. However, I have had to force certain SSL and SSH parameters over the years when connecting between older and newer systems, or during times of significantly change to SSL protocols/ciphers/etc. As such, I think there should be some means of specifying the various options (ssl protocol, ciphersuites supported, etc). Perhaps there's still a way to do so via ENV flags? If not, I think it'd be helpful to have a generic ssl flag and per-protocol-version ones (or support apache style SSLProtocol string), but most people will probably be fine using a generic flag. HTH, -- Josh I. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alpine.chappa at gmx.com Tue Dec 11 09:46:20 2018 From: alpine.chappa at gmx.com (Eduardo Chappa) Date: Tue Dec 11 09:48:02 2018 Subject: [Alpine-info] SSL in PC-Alpine Message-ID: Hello everyone, Out of all different versions of Alpine, the version of PC-Alpine is different in the way it supports encryption. The code that supports this is written with specific calls to Windows libraries and linkage is done with specific Windows dlls. This is a great method, but it causes some problems, which I will describe here. The first one I described it in a separate message, where different versions of Alpine can have a meaning for parameters such as /tlsv1_1 which may not make sense in your Windows version. For example, if you are still using PC-Alpine in Windows XP (yes, there are still people using it) then you do not have support for TLS v1.1, etc. That is because your machine is too old. If a user has a valid reason to keep using an old version of Windows (e.g. it is too expensive to upgrade some software in the old machine, to a newer version of that same software in a newer version of Windows) then that user might not be able to use Alpine to read email because Alpine may not even run in that machine, or even if it does run in that machine, the certificates are too old and they will not validate a server anymore, and there is nothing the user can do to change this, as that version of Windows is not supported anymore by Microsoft. This is an Alpine problem caused by the way PC-Alpine supports SSL in Windows. In other words, other programs that support encryption do not have that issue. It is just an Alpine problem, do not point the blame to Microsoft here. All systems, regardless of who produces them, will "expire" their ssl support and will eventually fall in the "I cannot connect to your server, because your support for ssl encryption is too old and is not supported by the server anymore." This will happen in your Linux, Mac or Windows machine that is state of the art now. In order to deal with this situation in PC-Alpine, I would like to move to using LibreSSL as the internal SSL library for PC-Alpine, instead of using Windows calls. The code for this is already in the git repository (it has been there for months) and I want to make sure we all agree on this. This would make Alpine make unix-like calls instead of the Windows calls for SSL libraries. One of the problems we have by doing Windows calls only is that there was no support for S/MIME in PC-Alpine as a result of this, and now S/MIME is supported by PC-Alpine. The other difference is that making unix-like calls means that PC-Alpine will have to find server certificates in one place, which is machine independent. Certificates would have to be installed by the user (more about this later.) Using LibreSSL guarantees us that we will support modern encryption protocols. All that needs to be done is to keep updating the source code of Alpine as needed. Ok, let me summarize what we have, and how we got here: * PC-Alpine ideally supports modern encryption protocols in old machines where the user cannot update anything, nor the certificates, nor the libraries. * In order to solve that, we use LibreSSL, but that makes PC-Alpine ignore the certificates installed in the Windows machine and the user has to install their own (or the program can download them on behalf of the user from a web site during installation, and update them periodically.) * As a result of using LibreSSL we have S/MIME support in PC-Alpine. We have had that for a long time already, but we can push it more and provide all SSL support through LibreSSL. We can make the latter one a seamsless experience: Upon installation of PC-Alpine, once PC-Alpine finds an internet connection, it will download certificates, install them in a appropriate directory and update them from time to time. Failure to install certificates only causes the program to not to validate servers. * Following this model will guarantee that one can upgrade PC-Alpine in the same machine, and make it work for as many years to come, even when their operating system is not supported anymore, and an old version of Alpine will not be able to connect to a remove server anymore due to incompatible SSL encryption support in the server and the Windows machine. A problem which will be solved by only upgrading Alpine, not the Windows machine. Any thoughts? I appreciate your feedback. Thank you. -- Eduardo From jimis at gmx.net Tue Dec 11 14:47:43 2018 From: jimis at gmx.net (Dimitrios Apostolou) Date: Tue Dec 11 14:48:03 2018 Subject: [Alpine-info] Verify S/MIME emails according to system's trusted CAs Message-ID: Hello list, I can't get alpine to automatically verify signed emails. The emails are signed using a CA-issued certificate (i.e. no self-signed certificates). The CA is accepted by the system's policy, i.e. the root certificate is included in /etc/ssl/certs/ca-bundle.crt. But I don't see alpine actually checking the system CA bundle. I also tried symlinking the ca-bundle.crt to ~/.alpine-smime/ca/ but did not help, I think alpine has issues reading many certificates from one file. How can alpine automatically trust the system trusted CAs? Thanks, Dimitris From jimis at gmx.net Tue Dec 11 15:28:13 2018 From: jimis at gmx.net (Dimitrios Apostolou) Date: Tue Dec 11 15:28:50 2018 Subject: [Alpine-info] Verify S/MIME emails according to system's trusted CAs In-Reply-To: References: Message-ID: I believe I understand more now. I was trying to verify my own signed emails, but for some reason alpine was not including the "intermediate certificate" in the S/MIME signed email. In the end I figured out that manually prepending the intermediate certificate in my email@address.crt file worked, and alpine is now including a full validation chain in the signature. Now alpine sees my certificate as valid, but when I view my sent emails it asks me to save the certificate in order to trust it. Strange, my own certificate is already saved apparently since I'm signing emails with it, and it is not a self-signed one but CA-issued, so no manual saving should be needed. Dimitris On Wed, 12 Dec 2018, Dimitrios Apostolou wrote: > Hello list, > > I can't get alpine to automatically verify signed emails. The emails are > signed using a CA-issued certificate (i.e. no self-signed certificates). The > CA is accepted by the system's policy, i.e. the root certificate is included > in /etc/ssl/certs/ca-bundle.crt. > > But I don't see alpine actually checking the system CA bundle. I also tried > symlinking the ca-bundle.crt to ~/.alpine-smime/ca/ but did not help, I think > alpine has issues reading many certificates from one file. > > How can alpine automatically trust the system trusted CAs? > > > Thanks, > Dimitris > > _______________________________________________ > Alpine-info mailing list > Alpine-info@u.washington.edu > http://mailman13.u.washington.edu/mailman/listinfo/alpine-info > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2081 bytes Desc: S/MIME Cryptographic Signature URL: From jason-alpine-info at shalott.net Tue Dec 11 15:56:39 2018 From: jason-alpine-info at shalott.net (jason-alpine-info@shalott.net) Date: Tue Dec 11 15:56:45 2018 Subject: [Alpine-info] Support of the SSL protocol in Alpine In-Reply-To: References: Message-ID: >> So, instead of filling up Alpine with switches /tlsv1_1, /tlsv1_2, etc. >> I think it makes more sense to interpret the /ssl parameter to mean let >> OpenSSL/LibreSSL negotiate the most secure connection possible. > On the user side, using one flag to enable a do-your-best ssl connection > seems quite good. I think that would end up working for most users, > myself included, in almost all cases. > > However, I have had to force certain SSL and SSH parameters over the years > when connecting between older and newer systems, or during times of > significantly change to SSL protocols/ciphers/etc. As such, I think there > should be some means of specifying the various options (ssl protocol, > ciphersuites supported, etc). +1 to this. Having "/ssl" simply mean "negotiate the most secure connection possible" is probably the best option for the most users; but it may be problematic for certain users with increased security needs. In particular, I am concerned about downgrade attacks, and think that it would be very good to let users specify a minimum SSL version. Perhaps an additional parameter, something like ssl_version_min=0x0301 (meaning TLS 1.0). Thanks. -Jason From mattack at apple.com Mon Dec 17 09:11:05 2018 From: mattack at apple.com (Matt Ackeret) Date: Mon Dec 17 09:11:38 2018 Subject: [Alpine-info] Quieting "self signed certificate in certificate chain: Continue anyway ? [n]:" prompt? Message-ID: I'm using ALPINE 2.20.17, and we turned off notls support.. After flailing for a bit thinking I couldn't still connect with alpine (though I had confirmed that would still work at least for the foreseeable future), I figured out that just removing /notls from my shell alias to start alpine (to read the remote config) fixed it.. Yet I still get a: self signed certificate in certificate chain: Continue anyway ? [n]: question every time I start. How can I either fix that or at least quiet it? Since I can just say yes, and after that, everything else seems to work after fixing all refs to my server to not use notls. Also, I was able to postpone this message the first time, but I couldn't continue since my folder collection still referred to my INBOX with /notls. I really am not sure how to inform the user in these cases, but having to manually remove /notls is SLIGHTLY a pain. A message along the lines of "Can't connect with NOTLS connection. Check your connection security settings for all references to server.wherever.com." might help clue one in. Thanks... From alpine.chappa at gmx.com Mon Dec 17 16:18:31 2018 From: alpine.chappa at gmx.com (Eduardo Chappa) Date: Mon Dec 17 16:19:05 2018 Subject: [Alpine-info] Quieting "self signed certificate in certificate chain: Continue anyway ? [n]:" prompt? In-Reply-To: References: Message-ID: On Mon, 17 Dec 2018, Matt Ackeret wrote: > After flailing for a bit thinking I couldn't still connect with alpine > (though I had confirmed that would still work at least for the > foreseeable future), I figured out that just removing /notls from my > shell alias to start alpine (to read the remote config) fixed it. Dear Matt, There are two ways to start an encrypted session. One is to connect to port 143 and issue a STARTTLS command, and the second is to connect to port 993, and use the SSL protocol. The /notls parameter you are referring to, has to do with the first method. It does not affect the second method. Using the /notls parameter tells Alpine not to issue the STARTTLS command, which means your connection will always be insecure. The parameter you need is /ssl, which will start the connection in port 993. The preferred way to connect securely is to use port 993 and encrypt from the beginning. Using STARTTLS can make you a victim of cracker-in-the-middle attacks. It is unsafe. Do not use it. > Yet I still get a: > self signed certificate in certificate chain: Continue anyway ? [n]: > > question every time I start. That seems like a problem that could be taken care of (meaning, quieting it off) by adding /novalidate-cert to the server definition. I would not recommend doing that either. The problem is that again, you can be a victim of a cracker-in-the-middle attack. I hope this helps. -- Eduardo https://tinyurl.com/yc377wlh (Web) http://repo.or.cz/alpine.git (Git) RSS: http://repo.or.cz/alpine.git/rss (Git updates) RSS: https://tinyurl.com/ybj33j2a (Web updates) From mattack at apple.com Mon Dec 17 16:33:54 2018 From: mattack at apple.com (Matt Ackeret) Date: Mon Dec 17 16:34:16 2018 Subject: [Alpine-info] Quieting "self signed certificate in certificate chain: Continue anyway ? [n]:" prompt? In-Reply-To: References: Message-ID: On Mon, 17 Dec 2018, Eduardo Chappa wrote: > There are two ways to start an encrypted session. One is to connect to port > 143 and issue a STARTTLS command, and the second is to connect to port 993, and > use the SSL protocol. > > The /notls parameter you are referring to, has to do with the first method. > It does not affect the second method. Using the /notls parameter tells Alpine > not to issue the STARTTLS command, which means your connection will always be > insecure. > > The parameter you need is /ssl, which will start the connection in port 993. > > The preferred way to connect securely is to use port 993 and encrypt from the > beginning. Using STARTTLS can make you a victim of cracker-in-the-middle > attacks. It is unsafe. Do not use it. Maybe I wasn't clear. Today, I had to REMOVE the /notls.. so I think that made me MORE secure. > That seems like a problem that could be taken care of (meaning, quieting it > off) by adding /novalidate-cert to the server definition. I would not recommend > doing that either. The problem is that again, you can be a victim of a > cracker-in-the-middle attack. If there's reasonably clear info about how to fix the "real" problem that I can easily fix, I'll try doing that at some point.. But I'm already on a corporate network, behind tons of security. Security issues are things I'm admittedly not fully up on (heck, even setting up security for various internal-use-only web sites was a pain even with the key generation and such provided for us). But basically, I'm already on an internal network, connecting to an internal-only server... and it seems to me like I'm at least "less insecure" than before. But if I can fix it on my end so I don't have to say /novalidate-cert, great. Your workaround was great though. For now, I just added "/ssl/novalidate-cert" to the hostname portion of all of the mailbox settings for this server (e.g. inbox, the one in the collection, remote address book). I noticed no change from a user perspective adding the ssl part only. From alpine.chappa at gmx.com Mon Dec 17 16:56:08 2018 From: alpine.chappa at gmx.com (Eduardo Chappa) Date: Mon Dec 17 16:56:33 2018 Subject: [Alpine-info] Quieting "self signed certificate in certificate chain: Continue anyway ? [n]:" prompt? In-Reply-To: References: Message-ID: On Mon, 17 Dec 2018, Matt Ackeret wrote: >> The preferred way to connect securely is to use port 993 and encrypt >> from the beginning. Using STARTTLS can make you a victim of >> cracker-in-the-middle attacks. It is unsafe. Do not use it. > > Maybe I wasn't clear. Today, I had to REMOVE the /notls.. so I think > that made me MORE secure. Maybe I was not clear. Removing /notls is INSECURE. STARTTLS is INSECURE, it does not matter if you can validate or not the server certificate, your insecurity is due to other reasons. >> That seems like a problem that could be taken care of (meaning, >> quieting it off) by adding /novalidate-cert to the server definition. I >> would not recommend doing that either. The problem is that again, you >> can be a victim of a cracker-in-the-middle attack. > > If there's reasonably clear info about how to fix the "real" problem > that I can easily fix, I'll try doing that at some point.. But I'm > already on a corporate network, behind tons of security. Security > issues are things I'm admittedly not fully up on (heck, even setting up > security for various internal-use-only web sites was a pain even with > the key generation and such provided for us). > > But basically, I'm already on an internal network, connecting to an > internal-only server... and it seems to me like I'm at least "less > insecure" than before. > > But if I can fix it on my end so I don't have to say /novalidate-cert, > great. > > Your workaround was great though. > > For now, I just added "/ssl/novalidate-cert" to the hostname portion of > all of the mailbox settings for this server (e.g. inbox, the one in the > collection, remote address book). I noticed no change from a user > perspective adding the ssl part only. Here is the thing. Being on an internal server again gives you only some security. Here is what you should be doing instead. Download the certificate from the server, and install it in your machine, then delete the /novalidate-cert part that you added. Read the page below thoroughly. It will teach you what to do so you can do this correctly. https://www.madboa.com/geek/pine-ssl/ I hope this helps. -- Eduardo https://tinyurl.com/yc377wlh (Web) http://repo.or.cz/alpine.git (Git) RSS: http://repo.or.cz/alpine.git/rss (Git updates) RSS: https://tinyurl.com/ybj33j2a (Web updates) From mattack at apple.com Mon Dec 17 17:14:52 2018 From: mattack at apple.com (Matt Ackeret) Date: Mon Dec 17 17:14:58 2018 Subject: [Alpine-info] Quieting "self signed certificate in certificate chain: Continue anyway ? [n]:" prompt? In-Reply-To: References: Message-ID: On Mon, 17 Dec 2018, Eduardo Chappa wrote: > Maybe I was not clear. Removing /notls is INSECURE. STARTTLS is INSECURE, it My only point is that it's like locking your door with a flimsy lock. Having /notls means DON'T even use the *insecure* security, which is like leaving your door wide open and throwing your stuff on the lawn so everyone sees everything regardless. Infinisimally better than NO security. The Pig Latin of security. > https://www.madboa.com/geek/pine-ssl/ awesome. For now I think I'll leave my workaround in place, but will read that in more depth later, maybe over vacation.. (I just skimmed it now) From gatetman at gmail.com Tue Dec 18 10:19:08 2018 From: gatetman at gmail.com (Carl Edquist) Date: Tue Dec 18 10:20:04 2018 Subject: [Alpine-info] IMAP login doesn't work if username contains a backslash In-Reply-To: References: Message-ID: Hi Eduardo, I don't know if you saw my reply back on Oct 25 about this, but i came up with the following patch, which solved the "username contains a backslash" issue for me: https://github.com/edquist/alpine/commit/bcfdec9.patch In particular, previously, this switch-case made it impossible to properly escape backslashes in "astring" tokens: case '"': case '\\': /* quoted-specials (IMAP2 required this) */ Would you consider including a fix (like the above patch) in a future release? Thanks, Carl On Wed, 24 Oct 2018, Eduardo Chappa wrote: > Date: Wed, 24 Oct 2018 21:26:21 > From: Eduardo Chappa > To: Carl Edquist > Cc: alpine-info@u.washington.edu > Subject: Re: [Alpine-info] IMAP login doesn't work if username contains a > backslash > > On Wed, 24 Oct 2018, Carl Edquist wrote: > >> Is there a way to get the actual LOGIN lines as they are sent over the wire >> in the debug logs? > > No, this is not written to any debug files. > > If you notice in the link, you can see that the login command is in the > format > > TAG LOGIN "userid" "password" > > Normally, you do not need to quote userid and password, you can just type > > TAG LOGIN userid password > > Maybe the reason why PLAIN authentication fails is because there is no > quoting. Try to see if you enter these with quotes, if it will work. > > -- > Eduardo > From alpine.chappa at gmx.com Tue Dec 18 13:41:06 2018 From: alpine.chappa at gmx.com (Eduardo Chappa) Date: Tue Dec 18 13:39:57 2018 Subject: [Alpine-info] IMAP login doesn't work if username contains a backslash In-Reply-To: References: Message-ID: Dear Carl, I am sorry I did not say anything at that time. I did look at your patch, and by now I forgot what I thought about it. This semester has been very busy for me, and things are finally getting to the end. I promise you I will take a look at the patch again and think about it. Please ping me again in case I take too long to reply. Thank you. -- Eduardo On Tue, 18 Dec 2018, Carl Edquist wrote: > Hi Eduardo, > > I don't know if you saw my reply back on Oct 25 about this, but i came up > with the following patch, which solved the "username contains a backslash" > issue for me: > > https://github.com/edquist/alpine/commit/bcfdec9.patch > > > In particular, previously, this switch-case made it impossible to properly > escape backslashes in "astring" tokens: > > case '"': case '\\': /* quoted-specials (IMAP2 required this) */ > > > Would you consider including a fix (like the above patch) in a future > release? > > > Thanks, > Carl > > On Wed, 24 Oct 2018, Eduardo Chappa wrote: > >> Date: Wed, 24 Oct 2018 21:26:21 >> From: Eduardo Chappa >> To: Carl Edquist >> Cc: alpine-info@u.washington.edu >> Subject: Re: [Alpine-info] IMAP login doesn't work if username contains a >> backslash >> >> On Wed, 24 Oct 2018, Carl Edquist wrote: >> >>> Is there a way to get the actual LOGIN lines as they are sent over the >>> wire in the debug logs? >> >> No, this is not written to any debug files. >> >> If you notice in the link, you can see that the login command is in the >> format >> >> TAG LOGIN "userid" "password" >> >> Normally, you do not need to quote userid and password, you can just type >> >> TAG LOGIN userid password >> >> Maybe the reason why PLAIN authentication fails is because there is no >> quoting. Try to see if you enter these with quotes, if it will work. >> >> -- >> Eduardo >> > -- Eduardo