Hi everyone, Security team: thanks for your input. PuppetDB/Clojure maintainers: draft plan in this mail, feedback welcome.
Moritz Mühlenhoff <j...@inutil.org> (2018-12-31):
> On Mon, Dec 31, 2018 at 08:04:18AM +0100, Salvatore Bonaccorso wrote:
> > Furthermore if we only update to 1.13 there are likely some of the
> > currently <not-affected> CVEs which will make tika affected, because
> > the issue was introduced post 1.5. One example of this is for
> > instance CVE-2016-6809, where the Matlab file parser was only
> > introduced in 1.6 and the issue fixed in 1.14. Or CVE-2018-17197
> > which affects 1.8 to 1.19.1. CVE-2018-1338, which was introduced in
> > 1.7. CVE-2018-1335, present from 1.7 to 1.17.
> >
> > There might be others, so I think the new upstream version fixing all
> > known current CVE is actually needed.
There goes my vague idea of trying to handle a small(er) diff; of course
that makes a lot of sense…
> Agreed. Also 1.13 was released in May 2016, so by the time buster gets
> released it would be ~ 5 years old.
s/buster/bookworm/ I suppose but I see your point.
So, looking at current upstreams:
- 4.4.x branch of puppetdb seems a bit inactive (since 2018-02), even
if it has a few commits on top of the version currently sitting in
unstable; it still documents a dependency on pantomime(-clojure)
2.1.0, which itself documents a dependency on tika 1.5.
- pantomime upstream is at 2.10.0, released early 2018; it documents
a dependency on tika 1.19.1
- tika upstream is at 1.20
Keeping in mind my knowledge of Clojure, Java, and their respective
ecosystems is rather limited, I'd like to share some initial hunches
anyway.
puppetdb seems to only reference pantomime once (outside top-level
project.clj), in src/puppetlabs/puppetdb/middleware.clj:
| […] :require […] [pantomime.media :as media]
^^^^^^^^^^^^^^^^^^^^^^^^^
| […]
| (defn verify-content-type
| "Verification for the specified list of content-types."
| [app content-types]
| {:pre [(coll? content-types)
| (every? string? content-types)]}
| (fn [{:keys [headers] :as req}]
| (if (= (:request-method req) :post)
| (let [content-type (headers "content-type")
| mediatype (if (nil? content-type) nil
| (str (media/base-type content-type)))]
^^^^^^^^^^^^^^^
| (if (or (nil? mediatype) (some #{mediatype} content-types))
| (app req)
| (http/error-response (tru "content type {0} not supported"
mediatype)
| http/status-unsupported-type)))
| (app req))))
and hopefully that didn't change too much between pantomime 2.1.0 and
2.10.0 as that is likely the crux of pantomime?
With that in mind, but without having checked code changes in pantomime,
I hope it should be possible to bump the pantomime dependency from 2.1.0
to 2.10.0 on the puppetdb side (better catch up with upstream?).
On the pantomime side, it seems it should work fine with tika 1.19.1, as
documented in dependencies in the master branch (3 commits on top of the
v2.10.0 tag). That should help us consider tika 1.20, as possible
breaking changes should be manageable between those two versions?
Changes in dependencies in pantomime (project.clj) seem rather limited
here's an excerpt between the v2.1.0 and v2.10.0 tags (excluding changes
in :profiles and :aliases):
| - :dependencies [[org.clojure/clojure "1.5.1"]
| - [org.apache.tika/tika-core "1.5"]]
| + :dependencies [[org.clojure/clojure "1.9.0"]
| + [org.apache.tika/tika-parsers "1.17"]
| + [org.apache.commons/commons-compress "1.15"]]
This should be OK? We have clojure 1.9 in unstable, tika-parsers even
becomes 1.19.1 (as mentioned above, in the master branch), and we have
those versions for commons-compress:
| libcommons-compress-java | 1.13-1 | stable | source, all
| libcommons-compress-java | 1.18-1 | testing | source, all
| libcommons-compress-java | 1.18-1 | unstable | source, all
So maybe a way forward would be:
- keep puppetdb at the current version (or maybe taking an upstream
snapshot or suggesting a new upstream release with those few commits),
and leave switching to 5.x or 6.x branches for later
- bump pantomime-clojure to latest upstream (2.10)
- bump tika to latest upstream (1.20)
I doubt I would be able to deal with tika 1.20 alone (see the issues I
had to deal with when trying my luck with 1.15 in my previous mail),
even if we were to try and trim it down to the bare set of features that
pantomime needs.
Thoughts about the plan? If that doesn't look too crazy, anyone with
some availability to help me get tika 1.20 in shape?
Cheers,
--
Cyril Brulebois (k...@debian.org) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
signature.asc
Description: PGP signature
