Git Product home page Git Product logo

Comments (3)

bengotow avatar bengotow commented on June 16, 2024

from mailspring-sync.

Phylu avatar Phylu commented on June 16, 2024

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

from mailspring-sync.

ReillyBrogan avatar ReillyBrogan commented on June 16, 2024

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.

Related Issues (3)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.