Insecure Dependencies about mailspring-sync HOT 3 OPEN

from mailspring-sync.

As of the Ubuntu lifecycle, I suggest to drop anything older than Ubuntu 20.04: https://ubuntu.com/about/release-cycle

from mailspring-sync.

Yes, Ubuntu 20.04 is a good baseline. Users still using EOL distro versions are accustomed to not having their applications be supported in the first place and there's little point in supporting what is likely a very small population of users.

Really, how this project should be build from a Linux perspective is the following:

• Use dependency management tooling. For C/C++ projects it looks like the best option might be conan.io.
• Hookup dependency update tooling to this repo to keep those dependencies updated. Github Dependabot and Renovate are both great options and will automatically open PRs with updates. You'll also receive alerts for known vulnerabilities in those dependencies and can make new Mailspring releases accordingly.
• Move all dependencies to that system. You shouldn't pull in static libs from the build environment since there's no visibility into what you're building with there (the compiled binaries do not preserve enough information to determine whether or not the static lib you built with was patched against a specific vulnerability). The only thing that the build environment should really change is the version of the compilers used to build with and the minimum glibc required to run the resulting binary. Binaries built against a specific system glibc are forwards compatible with newer versions of glibc but not backwards compatible with older ones (so in effect the binaries would not run on anything with an older version of glibc than runs on Ubuntu 20.04).
• Cmake should check the system version of each lib against a supported range of versions and if the system version is good enough should instead switch to dynamically linking against the system version. My understanding is that the cmake/conan combination can do this relatively simply and the "recipes" they provide can be statically or dynamically linked. The benefit of this is that if openssl/libcurl/zlib/etc are updated on the host system that the mailsync binary will not need to be re-compiled and will pickup those security fixes automically. The downside is that supporting this across all of the supported distros is likely to require multiple builds due to ABI variance across versions. Better CI can help substantially with automating the matrix of builds and configurations that would be required.
• Having dynamically-linked binaries would also help the flatpak, which really should be building the mailsync binary as part of the build. Flatpak apps are built in a layered approach, and the core OS of the containerized environment is regularly updated for vulnerabilities. That already provides a number of libraries including libxml2, libz, liblzma, libssl, libcurl etc. If the mailsync binary was dynamically linked against those libraries then the user would receive automatic security fixes without requiring mailspring updates. I am not familiar with snap, but I assume it uses a similar method.
• Perhaps to that end you could drop the rpms and debs and only support flatpaks and snaps? This would dramatically reduce the support burden of maintaining possible build configurations and nowadays virtually all Linux environments provide access to one (or both) of those.

My main concern with updating these dependencies now is that all it does is kick this can further down the road and doesn't address the core problem of poor dependency management. I'd rather see the latter fixed and then continuously updated and secure dependencies is the natural outcome.

CC @prateekmedia who appears to be the maintainer of the Flatpak. I don't have any visibility into how the Snap is built or I'd link that maintainer as well.

from mailspring-sync.