Re: Upcoming GMime 3.0 changes
Peter Bloomfield <[email protected]>
| Newsgroups | gmane.comp.gnome.apps.balsa |
|---|---|
| Message-ID | <[email protected]> |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Albrecht, On 06/22/2017 03:26:16 PM Thu, Albrecht Dreß wrote: > Hi Peter: > > Am 21.06.17 22:03 schrieb(en) Peter Bloomfield: >> I installed GMime 3.0.1 from git, and I have a patch against Balsa git master for building with it, keeping the ability to build with 2.6 through the magic of #if. It just adapts Balsa's current code to work with the new API, but even so it's a big mess, over 2k lines of patch, touching 32 files and creating 160 blocks of conditionally compiled code. > > Ouch. It's very interesting and encouraging to hear that you succeeded in compiling the sources. But I strongly advise against using it through preprocessor conditionals. It basically makes the code unreadable and unmaintainable, and has always been a source for funny (more or less, actually) errors. Better create a new branch... Agreed. … > If we want to make Balsa more popular, IMO we have completely different problems. I don't watch other distos, but Debian and Ubuntu all ship with some 2.4.12 variant. But this one will just stop sending messages at some (near?) point in the future as it relies on the ancient libesmtp library which supports (insecure) SSL 3 and TLS 1.0 only, so MTA's will probably simply refuse to talk to Balsa. > > Package maintainers *hopefully* now look at Balsa's master branch, iirc you sent an announcement last year. Again changing master to something relying on non-standard packages is an extremely bad idea and will encourage maintainers not to put too much effort in something which looks like a quite unstable and experimental project. Until Balsa disto packages silently die for the reasons above. > > Looking at my personal agenda, I think the following points should be addressed shortly: > - Some improvements in the crypto code, in particular replacing the clumsy gpg code for talking to key servers by GpgME. Goal: remove gpg config dependency, better user experience, preparation for EasyGPG which will rely on Gpgme keyserver interaction (see <https://wiki.gnupg.org/EasyGpg2016>). I'm working on that. > - Replace the low-level networking parts in libimap, depending on openssl, by libnetclient. Probably much work, I'll look into it after finishing the first task. Goal: drop openssl dependency (and its frequent security issues), as everything will then be in gio (i.e GnuTLS). > > And, if everything has been tested, it would be time for a new stable release IMO, which should be promoted for inclusion into distos. Looks like a plan! > Oh, and I think we should also look into the code quality (see e.g. <https://www.securecoding.cert.org/confluence/display/c/SEI+CERT+C+Coding+Standard> and <http://www.embedded.com/electronics-blogs/beginner-s-corner/4023981/Introduction-to-MISRA-C>), documentation and coding style. Static analysis (FlexeLint or similar) would be great. Not visible to the user, but improves stability and security. For the cosmetic part, we could uncrustify the whole tree. Improving code quality will take longer! Best, Peter -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAllNJQ8ACgkQH1/UtbkqdPUIbQCfUWdDACdfbm4uA98InnUjP9rG f9YAn3pYSK/CEALuEjZeZ1iUsDB0crXi =wg7Z -----END PGP SIGNATURE----- _______________________________________________ balsa-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/balsa-list