external dependencies

Magma Classic - Discussion / Documentation / Bugs
cs1
Posts: 8

external dependencies

Post#1 » Tue Jan 13, 2015 7:17 pm

Why are all external dependencies built from source rather than using the packages provided by the distro?

According to my research, most packages are available on both Debian 7 and CentOS 6.

Code: Select all

External Dependency         Debian 7 "Wheezy"                CentOS 6.6
Provided Archive            Development Package  Version     Develop. Package   Version
-----------------------------------------------------------------------------------------
bzip2-1.0.6.tar.gz          libbz2-dev           1.0.6-4     bzip2-devel        1.0.5-7
clamav-0.98.4.tar.gz        libclamav-dev        0.98.5      clamav-devel       0.98.5-1
curl-7.23.1.tar.gz          libcurl4-openssl-dev 7.26.0-1    libcurl-devel      7.19.7-40
dspam-3.10.1.tar.gz         libdspam7-dev        3.10.1      dspam-devel        3.10.2-4
freetype-2.5.3.tar.gz       libfreetype6-dev     2.4.9-1.1   freetype-devel     2.3.11-14
gd-2.0.35.tar.gz            libgd2-[no]xpm-dev   2.0.36      gd-devel           2.0.35-11
GeoIP-1.4.8.tar.gz          libgeoip-dev         1.4.8       GeoIP-devel        1.5.1-5
jansson-2.2.1.tar.gz        libjansson-dev       2.3.1-2     jansson-devel      2.6-1
jpeg-9a.tar.gz              libjpeg8-dev         8d-1        openjpeg-devel ??? 1.3-10
libmemcached-1.0.18.tar.gz  libmemcached-dev     1.0.8-1     libmemcached-devel 0.31-1.1
libpng-1.6.9.tar.gz         libpng12-dev         1.2.49-1    libpng-devel       1.2.49-1
libspf2-1.2.10.tar.gz       libspf2-dev          1.2.9-7     (((none found)))
libxml2-2.9.1.tar.gz        libxml2-dev          2.8.0       libxml2-devel      2.7.6-17
lzo-2.06.tar.gz             liblzo2-dev          2.06-1      lzo-devel          2.03-3.1
mysql-5.1.73.tar.gz         libmysqlclient-dev   5.5.40-0    mysql-devel        5.1.73-3
opendkim-2.9.0.tar.gz       libopendkim-dev      2.6.8-4     libopendkim-devel  2.9.0-2
openssl-1.0.1j.tar.gz       libssl-dev           1.0.1e-2    openssl-devel      1.0.1e-30
tokyocabinet-1.4.48.tar.gz  libtokyocabinet-dev  1.4.47-2    tokyocabinet-devel 1.4.33-6
zlib-1.2.8.tar.gz           zlib1g-dev           1:1.2.7     zlib-devel         1.2.3-29

moss
Posts: 14

Re: external dependencies

Post#2 » Thu Jan 15, 2015 10:18 am

I had the same reaction. Honestly makes me feel that this approach is a little brittle. But the justifications are in the docs. (can't find the exact text, so from memory..) There were some bug fixes and changes that were made to some libraries.

Perhaps it also prevents possible tampering in the distributed packages? I don't know. Just reaching.

cs1
Posts: 8

Re: external dependencies

Post#3 » Thu Jan 15, 2015 7:18 pm

I understand that custom build flags are used, e.g. -rdynamic, -D_FORTIFY_SOURCE=2. I assume all of this is for the sake of additional security plus a pretty unique way of software architecture (bundling dependencies in a single shared object).

However, having such custom builds makes it difficult if not impossible to have the daemon available as a package on most Linux distribution. I don't think that for instance Debian would accept a custom OpenSSL build.

Also, this approach means additional work for mail providers, work that would otherwise be provided by the respective Linux distribution (e.g. providing security fixes).

User avatar
ladar
Lavabit
Posts: 89
Contact:

Re: external dependencies

Post#4 » Wed Feb 18, 2015 5:32 pm

cs1 wrote:However, having such custom builds makes it difficult if not impossible to have the daemon available as a package on most Linux distribution. I don't think that for instance Debian would accept a custom OpenSSL build.

Also, this approach means additional work for mail providers, work that would otherwise be provided by the respective Linux distribution (e.g. providing security fixes).


When I was build/maintaining the code for Lavabit, building the dependencies myself made a lot of sense. It allowed me to stay up with security patches, create custom builds with slight variations that suited my needs, fix bugs in the deps I discovered during testing. Security was also an issue, as its relatively easy for someone with physical access to a machine (that isn't using FDE) to overwrite a system lib without anybody noticing (unless you employ certain countermeasures too look for this type of attack). I was also worried about an auto update pulling down an RPM that either broke some functionality my daemon relied on, overwrote a critical config, etc. Its happened before. And the auto part would mean that problem could take down all the nodes in a cluster during a relatively small window. (Like overnight while I slept.) Long story short, it made sense when maintaining Lavabit and by extension magma was my full time job. The only system packages I relied on were the kernel, and libc. (Generally speaking.)

As a side note, a lot of major online service providers use a similar approach when it comes to maintaining mission critical systems for their service. At least the technically sophisticated ones with full time developers on the payroll. Especially when they have customizations built atop the dependencies. It just makes sense.

I will admit this strategy doesn't make sense in the context of a generally version distributed via the distro package management tool. In the future we will likely invest the time/resources to make compiling magma against system libs, or against the included dependencies an easy switch. We'll also convert to a more traditional build system, probably autotools, or a custom shell script, or some other similar strategy that is distro agnostic.

User avatar
ladar
Lavabit
Posts: 89
Contact:

Re: external dependencies

Post#5 » Wed Feb 18, 2015 5:48 pm

I should also mention that OpenSSL and ClamAV are major dependancies that I couldn't use the distro variants for. That's because, at least on RHEL, the openssl package isn't compiled with the cipher support I wanted (ECC)... It's compiled in FIPS mode instead. I also try to avoid using assembly/hardware crypto implementations whenever possible, and especially when I'm handling data sensitive data (private user emails for example).

As for ClamAV, they have a bad track record of including major new pieces with seemingly minor version increments. And I frequently found parser bugs that would cause crashes, or leak memory. As for the new "features," they would often have major implications. For example when they decided to build LLVM directly into the scanner, so the virus definition files could ship with executable code that is jit compiled and executed using LLVM. I understand their reasoning - namely its hard/impossible to catch mutating malware using static definitions, while an executable algorithm could, but anyone whose worked in a high sensitivity environment knows that grabbing executable code from a 3rd party on the internet multiple times a day, and then running that newly retrieved code on a with access to highly sensitive data is a major security issue. That's why the version of ClamAV I create disables this functionality. (I believe there is a thread on the ClamAV mailing list from years ago where we discuss this.)

maxnort
Posts: 3

Re: external dependencies

Post#6 » Fri Feb 20, 2015 9:24 pm

this touches on a question I've asked in the DIME thread. some distributions include dependencies. some do not. we are in a time of increasing corporate involvement in Linux, even at the kernel level. corporations are perhaps more prone to cooperate with government. by extension, the less reliance on the distribution, the better.

even if it makes magma harder to install and maintain, it does make it more distribution-agnostic, and maybe one day more secure.

I expected to be reading and asking questions for weeks. instead, I think I'm ready to try this on Ubuntu now.
this is not here

User avatar
ladar
Lavabit
Posts: 89
Contact:

Re: external dependencies

Post#7 » Mon Feb 23, 2015 8:37 pm

maxnort wrote:some distributions include dependencies. some do not.


maxnort wrote:even if it makes magma harder to install and maintain, it does make it more distribution-agnostic, and maybe one day more secure.


I think the long term goal will be: if you download a tarball and compile from source, it will include/compile the dependencies. At the same time, we'll make it easy to flip a switch and the build system will use the system libraries instead, at least on the platforms where this is possible. A number of packages have taken a similar approach. I believe MySQL includes ZLIB... just as an example.

dirk
Posts: 1

Re: external dependencies

Post#8 » Thu Jun 25, 2015 11:52 am

Folks,

first off: thanks for this great effort and for tackling this problem for all privacy-minded folks.

I was just looking at the list of external dependencies and that quick glance showed a few dependencies with less than stellar security records (e.g. libpng and the lovely OpenSSL).
My question would be: are you considering these external dependencies as a "given" moving forward or should we maybe invest some time in reducing the number of external dependencies to the absolute minimum and look for alternatives to some of the troubled externals that will survive ?

In my perfect (dream) world I would imagine that we try to distance ourselves from some of these troubled packages.

Just a thought ..

Thanks

/Dirk

Return to “Magma Classic”

Who is online

Users browsing this forum: No registered users and 1 guest

cron