Error when TLS connection not properly closed #529
Comments
|
Just to be sure, which version of Himalaya CLI do you use? IMAP logs look like from the previous library. Make sure you are using the |
|
Full config: Installed it via Cargo but error persists: Version: Config (when installed via Cargo): |
|
Please upgrade to the |
|
The error persists when installed with Version: |
|
Both IMAP lib used (before and now) were based on Rustls, it looks like the issue is beyond Himalaya scope. I do not understand how and why it appears, especially that I do not reproduce it with my own Gmail account. According to Rustls:
So it is not really an error (do you confirm that the message is moved properly?), it is more like a security warning about the connection not properly closed. Not sure if as a lib consumer it is safe to ignore the error. @duesee any opinion? |
Absolutely! In all settings - Cargo, nixpkgs, repo flake. Please give me a day to test it with another Gmail account. |
|
Since it is more like a warning, it maybe makes sense to treat it as such, by emitting a log instead? |
|
Log should be appropriate given no other reports. Same behavior with a second account. |
|
As far as I understand, some implementations don't do a clean TLS shutdown which results in this error/warning. The attack which one can be worried about is a truncation attack. For example, if a Bash script is piped into a shell and an attacker can truncate the script, it may leave a machine in an incosistent state. For IMAP, I cannot come up with a good attack, though. If an attacker can truncate a message, it will propably always result in a parsing error. Maybe there is a case I miss, but I don't see how to truncate a message in a way that would change it's meaning (ignoring parse errors). Examples:
Maybe a warning is enough? |
|
What is the worst that can happen if an attacker can truncate at any point? I feel it should be not too much because it would also be a reliability problem. Non-atomic move comes to mind:
If truncation happens after copy and before delete, we'll end up habing a duplicate message. But... yeah :-) |
|
Awesome, thank you for your replies. Let's go for a simple warning for the next release! |
soywod
added
bug
soywod
changed the title
|
I started to work on this issue, and there is an edge case I'm not sure how to properly handle. Let's say you move a message. The client sends the request to the server, and the server processes the move but returns a missing How to handle this case? My naive intuition tells me to show a warning only when an IMAP task does not produce any output. Otherwise return a better error like "the action may not have been executed due to an unexpected closed stream". |
|
To give more context about the @vglfr moving message issue, the |
|
As an extra data point to this issue, I get a similar error for my personal gmail accounts with this .toml configuration: [accounts.example]
default = true
email = "[email protected]"
display-name = "First Last"
signature = """
V/r,
"""
signature-delim = """
--
"""
downloads-dir = "~/Downloads"
[accounts.example.folder.aliases]
inbox = "INBOX"
all = "[Gmail]/All Mail"
drafts = "[Gmail]/Drafts"
important = "[Gmail]/Important"
sent = "[Gmail]/Sent Mail"
spam = "[Gmail]/Spam"
starred = "[Gmail]/Starred"
trash = "[Gmail]/Trash"
[accounts.example.folder.list]
page-size = 25
[accounts.example.envelope.list]
page-size = 30
[accounts.example.backend]
type = "imap"
host = "imap.gmail.com"
port = 993
login = "[email protected]"
[accounts.example.backend.encryption]
type = "tls"
[accounts.example.backend.auth]
type = "password"
command = "pass show email/example/app_pass"
[accounts.example.message.send.backend]
type = "smtp"
host = "smtp.gmail.com"
port = 587
login = "[email protected]"
[accounts.example.message.send.backend.encryption]
type = "start-tls"
[accounts.example.message.send.backend.auth]
type = "password"
command = "pass show email/example/app_pass"Here is the relevant error contents when running:
I can also confirm that the mail is indeed removed, and actually moved to the However, these are some interesting anecdotes I've found when diagnosing the issue. With the original .toml configuration of alias However, if I change the folder alias for trash to be Now when running the delete command As a last note, I'm not sure of the relevance of this, but when listing mailboxes (doesn't matter for the .toml config changes here) via: Btw, love the project. Migrated from neomutt to himalaya. Also this is my first comment on GitHub, so I hope I'm doing this right.
Himalaya version: System specs: |
|
Thanks for the additional information. Indeed, really strange that the error disappears on a custom folder. I am still not sure how to properly handle this case, I will have to discuss more in depth with @duesee (as it is related to IMAP libs).
This is normal, the mailbox has the No Select attribute which makes it not selectable, therefore it is skipped from the listing. |
After setting
folder.alias.trash = "[Gmail]/Trash"message is deleted successfully but an error is thrown.Command:
himalaya message delete 27301 --traceLog exert:
Executing
a35 uid move 27302 "[Gmail]/Trash"inopenssl s_clientthrows406788D0607F0000:error:0A000126:SSL routines::unexpected eof while reading:ssl/record/rec_layer_s3.c:687:and quits repl but the message got deleted.Executing
a32 store 11044 +flags \deleteddeletes message successfully.The text was updated successfully, but these errors were encountered: