Hi,
I wrote an analysis in June
https://lists.debian.org/debian-lts/2021/06/msg00024.html
https://lists.debian.org/debian-lts/2021/06/msg00040.html
I believe we should postpone these CVEs with the goal of tracking how
/upstream/ reverse dependencies are adapting to the removal of the
blacklist, and backport the changes to the /packaged/ reverse dependencies.
Cheers!
Sylvain
On 27/08/2021 13:27, Ola Lundqvist wrote:
Hi fellow LTS contributors
I have helped Thorsten (this weeks front-deskl) to triage the java packages.
The problem in the libxstream-java is that there are a lot of ways
arbitrary code can be executed. The upstream fix is to make the
recommended way to use the library the default. The recommendation is to
use a white-list instead of a blacklist. The default has changed now in
the latest fixed version. As I see it this is a non-backwards compatible
change and may break packages if they rely on xml that is not in the
default whitelist. Therefore I suggest ignoring these CVEs.
Thorsten had the following opinion on my suggestion to ignore these CVEs.
"I don't like this blacklist/whitelist stuff and I even more dislike
when defaults change. But I also dislike ignoring CVEs with a real
issue. So, I don't have a good solution for it and ignoring might be
appropriate ..."
I see the following alternatives:
1) Ignore the issues. The motivation is that if the recommended
practices are followed by application developers the software is not
exploitable.
2) Develop out own fixes in a similar way to how earlier CVEs have been
fixed. I guess upstream got tired of making a lot of special fixes... I
suggest not since this would diverge from how upstream have handled it.
3) Backport the backwards incompatible change. I recommend not to do
this since it is likely to break software.
I'm writing this email to inform that I plan to mark the CVEs as
ignored, but I want you to have the possibility to comment on this.
