Insecure Dependencies

[ReillyBrogan]

This project apparently depends on some incredibly old versions of various dependencies. Most of them do not seem to have seen any updates since their initial inclusion:

• Openssl 1.1.0f, released in May of 2017. The entire 1.1.0 series has been EOL for four years now, this is especially concerning since it's compiled in as a static library which means that ALL encrypted email traffic goes over this fundamentally insecure library.
• libcurl 7.70.0, released in April of 2020
• nlohman 3.7.0, July 2019.
• icalendarlib didn't have any commits between 2012 and 2022, but the commits in 2022 are not in the local copy so it too clearly hasn't been updated
• sqlitecpp 2.0.0, July 2016. Notably also using the ancient sqlite 3.13.
• stanfordcpplib, circa 2019 as far as I can tell

Moreover, the build system builds with Ubuntu Xenial 16.04 images, and builds with static libs from that distribution. Ubuntu Xenial has been end-of-life since 2021, and those dependencies have been completely unmaintained since then. Example, the shipped version of libxml2 is version 2.9.4 which has had numerous reported vulnerabilities since 2021.

[bengotow]

Happy to accept PRs updating any of this stuff! I think the OpenSSL library is probably the highest priority. If I remember right, I think we build against these old versions because we support Ubuntu 16 and everything has to link. I can’t remember to what extent it’s possible to link against the new libs, and then run on Ubuntu 16. I remember it was a lot more nuanced than on macOS and I was surprised at the time how hard it was to get a build-once-run-everywhere Linux binary… Maybe we just compromise and drop Ubuntu 16 support… it is awfully ancient at this point.

…

On Wed, Nov 15, 2023 at 9:07 PM Reilly Brogan ***@***.***> wrote: This project apparently depends on some incredibly old versions of various dependencies. Most of them do not seem to have seen any updates since their initial inclusion: - Openssl 1.1.0f, released in *May of 2017*. The entire 1.1.0 series has been EOL for four years now, this is especially concerning since it's compiled in as a static library which means that ALL encrypted email traffic goes over this fundamentally insecure library. - libcurl 7.70.0, released in April of 2020 - nlohman 3.7.0, July 2019. - icalendarlib didn't have any commits between 2012 and 2022, but the commits in 2022 are not in the local copy so it too clearly hasn't been updated - sqlitecpp 2.0.0, July *2016*. Notably also using the ancient sqlite 3.13. - stanfordcpplib, circa 2019 as far as I can tell Moreover, the build system builds with Ubuntu Xenial 16.04 images, and builds with static libs from that distribution. Ubuntu Xenial has been end-of-life since 2021, and those dependencies have been completely unmaintained since then. Example, the shipped version of libxml2 is version 2.9.4 which has had numerous reported vulnerabilities since 2021. — Reply to this email directly, view it on GitHub <#9>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAH5HHFAZU7EQCR3KJHDKDLYEV7PFAVCNFSM6AAAAAA7NOWJN2VHI2DSMVQWIX3LMV43ASLTON2WKOZRHE4TKOJWGI2TMMI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[Phylu]

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

[ReillyBrogan]

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.