Good evening ! First of all, huge kudos for your detailled answer. I really appreciate it, especially because it's not so common.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Tuesday, 14 April 2020 18:50, Steffen Nurpmeso <[email protected]> wrote: > Hello and a good day. > > Noctambule wrote in > <VoDeZrZpg0_t9tDNC1tLAY4K_KTfHPwu7YQHxi9O0d587pGBHzKDb8e-EBRaymOd19nWETn\ > [email protected]>: > |I feel a bit embarrassed to send you this email directly, but even > |if I sent it to S-mailx-request five days ago, I can't see it in > |archives. Therefore, I do not really know if you received it. If > > No, it seems that was directly discarded: > > Apr 09 15:50:35 .. No command, message discarded... protonmail.com > > Sorry for this! > s-mailx@ would have been right unless you wanted to subscribe: Ahh, my bad, was probably lost in my own thoughts. > #?0|kent:src$ s-nail -#Y 'echo $contact-mail; x' > [email protected] > > So it is ok to forward to the list then, i blindly presume? > Feel free to respond/post in the future. > > |you already saw it, please accept my apologies. > > Absolutely not needed, but: sure thing. > > |That was the message : > | > |At work, I extensively use S/MIME and due to the recent event, I > |had to use s-nail to read my emails. S/MIME decryption works quite > |nicely but I still have a problem. When I attempt to read an > > It needs a rework for those messages which get mangled (aka > enwrapped in new envelope) by mailing-lists, for example. Yes. > > |encrypted mail, the PAGER is launched before I see the "PEM pass phrase:" > |prompt. So we can't see that prompt If I blindly type my password, > |the mail is finally decrypted but the PAGER get messed up. > > Yes i know, that is a real pity. It needs a complete rewrite of > the MIME (and input/output) layer to get it right, what is the > plan for v15 (for many years). Because this MUA can per > definition work on many or all messages of a mailbox at once, and > we parse the messages as we go, but may start $PAGER beforehand.. > > Since i had the same problem i added a "credential helper" which > could possibly solve your problem, too. It is documented under > smime-sign-cert-USER@HOST, including bad english at [1]: > > For signing and decryption purposes it is possible to use encrypted > keys, and the pseudo-host(s) ‘[email protected]’ for the > private key (and ‘[email protected]’ for the certificate > stored in the same file) will be used for performing any necessary > password lookup, therefore the lookup can be automated via the > mechanisms described in "On URL syntax and credential lookup". > For example, the hypothetical address ‘[email protected]’ could be > driven with a private key / certificate pair path defined in > [email protected], and needed passwords would then be > looked up via the pseudo hosts ‘[email protected]’ (and > ‘[email protected]’). To include intermediate certifi‐ > cates, use smime-sign-include-certs. > > [1] https://www.sdaoden.eu/code-nail.html#560 > > I had the necessary passwords in my ~/.netrc, but which is > encrypted via gpg. So i have > > set netrc-lookup netrc-pipe='gpg -qd ~/.netrc.gpg' > > and in there one found > > machine HOST.smime-cert-key login steffen password .... > > and so i did not have to type in something, the password would be > fetched automatically. You could use all other password sources > too, as documented in [2]. > > [2] https://www.sdaoden.eu/code-nail.html#12 Yep, I saw your lines in the man pages and I will apply them ASAP. > Having said that, our s_mime test does not yet (!) test this > password query, and i have not used it for long. I think i will > add a first simple case when i come back to the mailer, hopefully > not later but next week. But should work, nothing has changed. > > |The keys assigned to commands are not applied. For example, if a type > |"Up", "Down" and "Backspace", it shows the following results : > | > |:^[OA^[OB^? > > When does that happen? When you are asked for the password?? > > |The only way to go down is to type on "Return", but the output will > |be also messed up. Every line will have glitches like this : > | > |: > |All servers will be using Debian buster > |: > > This looks like less(1), actually. Hmmm... This makes me wonder. > Which version of s-nail do you actually use? There has been > a complete rewrite of the child process and termios handling in > v14.9.14 (released 2019-07-27), and such a problem should not > happen. You must be using an elder version? It happens after I bindly typed my password. Indeed, my pager is less(1). You are right, I was still using v14.8.16. I assumed the package was correctly updated on Void Linux, but it is orphaned. I finally built v14.9.17 and the results are indeed very much different. I can see now "smime-cert-key requires a password:" prompt before less(1) is called. And it works perfectly. Nice ! > (The problem with the prompt is still there, however, since we > print it as the parser discovers the S/MIME part, which is not > necessarily in sync with what you see in $PAGER, and if you > use multiple S/MIME certificates you have to guess. That i will > also change, a little hint at least is possible. The real > solution will come in v15, were we first iterate over all > messages to be shown / copied / xy, ask for all passwords as > necessary, and then perform the desired action.) > > |At this point, the only way to go back is to CTRL + C. I hope you > |understand my description. :) > > Yes. Yes, i think you must be using an elder version, the Debian > policy is pretty unfriendly to a small project like this, there > have been many bugfixes and huge changes i consider stable (almost > a thousand changesets) in between the v14.9.11 of Debian stable > and v14.9.17 in testing/unstable. Sorry! The package was orphaned, I'll now build it by myself, it'll prevent bugreports on obsolete versions. > But really, if you use that "pseudo-host" mechanism shown above > you can avoid password prompts altogether, and the bad background > / foreground process termios mess in between s-nail and less > should not happen. > I hope this helps. It helps a lot, indeed. Take care
