[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#917174: davmail: FTBFS with libjackrabbit-java 2.18.0

Hello all,

Please check my answer below.

Le 04/01/2019 à 14:41, Markus Koschany a écrit :
Hello Alex,

Am 04.01.19 um 13:16 schrieb Alexandre Rossi:
unfortunately davmail fails to build from source with
libjackrabbit-java 2.18.0. Long deprecated methods have been removed.
Your package build-depends on a very old version of jackrabbit (2.4.3).
This is too much work and I'm afraid if I do not get help I'll miss
the 2019-02-12 - Soft-freeze deadline for davmail to be part of the
Debian buster release. I'll continue working on this anyhow. My work
will be regularly published at

For davmail in buster, the options are :
1) let davmail being removed from buster (because it does not work
with the newer libjackrabbit, because low popcon, because a backport
can be made available later)
2) upload a libjackrabbit-old-java compatible with davmail and build
against this (I can prepare this).
3) holding libjackrabbit-java 2.18 from reaching buster because it
breaks its only rdep.
4) fixing the 1300+ compile errors before the soft freeze and ensure
few regressions (unlikely I can do this by February as I'm learning
libhttpclient-java and the davmail codebase at the same time)
Admittedly the upload happened on short notice and it was not my
intention to force you into porting davmail to a newer version of
jackrabbit-webdav. I think we can just prevent libjackrabbit-java 2.18
from moving to Buster which should solve this issue in the near-term.
However then we don't ship the current stable version of jackrabbit but
only an oldstable one that is maintained (at the moment) but will be EOL
during the Buster release cycle which is not so great either in my opinion.

I think the general problem is that upstream depends on an obsolete
version of jackrabbit-webdav, version 2.4.3, that has known security
vulnerabilities [1], CVE-2016-6801 and CVE-2015-1833. I only took care
of jackrabbit to make backports of security patches easier for all of
us. Ideally you should take care of jackrabbit too and maintain both
packages under the Java team umbrella. In any case I recommend to not
ship davmail in Bullseye if it can't be upgraded to supported versions
of jackrabbit and httpclient in the future.



[1] https://security-tracker.debian.org/tracker/source-package/jackrabbit

I upgraded Jackrabbit in DavMail upstream to 2.14.6 (released Sep 11, 2018), this is the last version to support HttpClient 3.

I don't think DavMail is impacted by Jackrabbit vulnerabilities, as we use it only in client mode, but upgrading to more recent version is definitely a good step forward.

Note that Jackrabbit is only used for Exchange 2003 and 2007 compatibility.

I would definitely stick with this version for a stable release, as HttpClient 4 is not a simple update but a major rewrite of HttpClient 3:

- new API that separates request/response instead of method class

- new way to handle connection pooling

- new API for state (cookies) handling

- ...

In the future we need to move to a more recent http client version, that may or may not be HttpClient 4.


Mickael Guessant

Reply to: