first of all: This has hunted me for quite some time, and I’m trying to get some input on this and also to give possible users a warning.
The sourcecode is quite short so you can look it up for yourself.
- it is creating a file on disk with the email which should be send, with one function
- the other function just calls bash and does something like
sendmail < mail.txt
The problems I see with this are:
- the library assumes it can read and write to the workspace path, if somebody isolates his application for any reason it’ll crash
This is unexpected/undocumented behavior of a sub library.
- the file is stored on disk, so it can be read later on
- the file is not deleted upon completion of the task, it will stay forever
- it makes the library thread unsafe, as multiple calls to the lib would write to the same file (could this create any panics because of system locking?)
- the library does not test for the permissions, it will just panic. There are not returns to indicate any IO errors, be it the file writing or the process call.
- it depends on bash, which is another dependency
I’ve tried to fix this with a PR, it got merged (but changed a little bit without any comment, which I personally didn’t like). To be fair I changed the library to use one function, as we don’t need a text file and just push all over stdin pipes to the process of sendmail, basically replacing everything. Also I’ve added support for multiple recipients.
The PR got reverted without any further comment, which is the current state. Because of this I decided to write up a post.
I first wanted to wait till I have a better crate out, with a clean API and more support for options, then my current fork I use in production has. The recent reddit discussion on auditing crates created the urge to warn people and talk about this now.
The same author created also other mail sending crates, which behave in the same way, just calling another process than sendmail.
I am a little bit at loss, and would like to hear your feedback.