-----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
