Hi, Am Mittwoch, dem 22.09.2021 um 20:57 +0200 schrieb Sylvain Beucler: [...] > > > > I am pretty surprised because I had concluded that all reverse-dependencies > > would break, due to not white-listing any app-specific class: > > https://lists.debian.org/debian-lts/2021/06/msg00040.html > > > > I'll test your package shortly to see if my angle is relevant with this > > patch. > > I had a look again. IIUC you mean no Debian non-lib package actually > use xstream at all, or the breakage has negligible impact > (e.g. Jajuk's support for Last.FM scrobbling should become more > network-intensive since the submission cache won't load anymore). > > User code that link to our xstream.jar may break though (see below > with an application that uses libjsap-java), so it's a bold move, but > your call. You are right that all applications will break which rely on the deserialization feature of xstream and were not using a whitelist before. Everything else that just writes a POJO to XML should be unaffected. In general we won't be able to support every custom user application that links to a system library but there is a simple workaround for this problem because you can override the permissions and even return back to a blacklist. So that leaves us with all the dependencies of libxstream-java in Debian. I don't see any major regressions by this switch but indeed deserialization without properly initializing xstream will no longer work. libjsap-java has an optional feature to read configuration parameters from an xml file (jsap files) but it still works in normal mode. It should be possible to override JSAPConfig but I will file a bug report anyway because this version is from 2006 and it does not look like it is maintained upstream. Quote from upstream: "The key message for application developers is that deserializing arbitrary user-supplied content is a dangerous proposition in all cases." "A blacklist for special classes only creates therefore a scenario for a false security, because no-one can assure, that no other vulnerability is found" I agree with him and I believe it is better to use the whitelist instead of relying on the blacklist. The alternative is to continue with the blacklist until bullseye is EOL. Regards, Markus
Attachment:
signature.asc
Description: This is a digitally signed message part