Re: [RFC/Proposal] Replacing libesmtp in Balsa



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]