Hi Albrecht:
On 01/19/2017 01:56:54 PM Thu, Albrecht Dreß wrote:
Hi all,
in March 2016 we discussed on this list the status of the libesmtp library [1].
It appears that libesmtp is either dead or no longer supported. At least the
web site is not reachable any more. In particular, security fixes (afaict,
libesmtp supports only TLS 1.0, but not the recommended TLS 1.2) are not
applied.
On the other hand, GLib/GIO actually has everything we need for networking:
classes for TCP streams, with and without TLS encryption (the latter based on
gnutls), and data input streams for line-based CRLF terminated input. And
GMime implements all message encoding stuff, so we can simply use these
well-maintained components to implement everything we need.
As only a limited set of the functionality from RFC 5321 is required in Balsa,
my idea is to write a few simple classes (as a separate library included in
balsa) on top of GIO as to replace libesmtp. This would remove all conditional
code (mainly in libbalsa/send.c) checking for the existence of libesmtp.
I started with the implementation a while ago, and have a "proof-of-concept"
version up and running on top of the balsa-master branch. The current status of the
library:
- implemented the base class
- implemented the SMTP class, supporting SMTP with and without STARTTLS as well
as SSMTP, plus everything we need in Balsa
- support for LOGIN, PLAIN, CRAM-MD5 and CRAM-SHA1 authentication and for DSN's
- documentation (almost complete...)
- unit tests with coverage analysis and leak checks using inetsim
- implementation tries to follow the MISRA C:2012 (MISRA C3) [2] and SEI CERT
Secure Coding [3] standards for safer code
In Balsa, I removed all libesmtp-related conditional stuff.
Still missing:
- using the Balsa authentication cache and the certificate acceptance dialogues
(easy)
- implementation of private (user) certificate authentication (easy; rarely
used, though)
- more AUTH mechanisms (Kerberos, NTLM, ...; probably difficult, but I /think/
they are also rarely used)
As an additional benefit for further code simplification, it should be easy to
derive classes for the (also line-based, CLRF-terminated) POP3 and IMAP
protocols from the base class. I actually have a /very/ basic POP3
implementation, but it's neither documented and tested thoroughly, nor included
in Balsa.
What do you think about this approach? If you think this would be a good idea
for Balsa, should we create a new branch, or directly use it in master (see
also Peter's somewhat related message today regarding Gtk4)?
Thanks in advance,
Albrecht.
[1] <https://mail.gnome.org/archives/balsa-list/2016-March/msg00007.html>
[2] <https://www.misra.org.uk/Publications/tabid/57/Default.aspx>
[3]
<https://www.securecoding.cert.org/confluence/display/c/SEI+CERT+C+Coding+Standard>
That's huge! The library would bring Balsa up to date with security
developments, and open the way to keeping it that way.
This is definitely something we should implement in master, and get into a new
release as soon as it's been tested. Please send in patches whenever you're
ready to install them.
Thanks for all the efforts!
Peter
_______________________________________________
balsa-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/balsa-list
