+1 for 2)
In [Imaging] we do something similar, but it was easier because there were many
methods that were already doing it (throwing ImageReadException or
ImageWriteException).
Bruno
On Sunday, 27 June 2021, 11:03:31 pm NZST, Stefan Bodewig
<bode...@apache.org> wrote:
Hi
I'd like to get closure on which approach we want to take.
When we read a broken archive it may trigger arbitrary RuntimeExceptions
because we are not explicitly checking for each and every sizuation
where a bounds check could fail, a negative size is sent to a classlib
method that then throws an IllegalArgumentException or whatnot (even a
NullPointerException may escape us every now and then).
Uncaught RuntimeExceptions are considered security issued by some tools
because of a potential DoS attack. Historically we have never agreed
with this point of view and I'm not suggesting to change that.
Even though we may not know what is wrong, when the RuntimeException
occurs, we do know the archive is broken and this is the reason for the
exception.
AFAICS there are two ways we can deal with it:
(1) every method that reads from the archive declares it can throw
arbitrary RuntimeExceptions as well. And we document that broken
archives may cause RuntimeExceptions and that we never consider such
a case a security issue.
(2) we catch RuntimeExceptions at every method that reads from the
archive and wrap them in a custom IOException, making sure such a
case can never escape us.
Personally I prefer (2) but can live with (1) - I've suggested something
along the lines of (2) in [1] and it seemed Gilles was opposed to this
idea (and Matt was torn).
In [2] Bernd seemed to support (2).
Are there any other opinions?
Stefan
[1]
https://lists.apache.org/thread.html/r5d2427566dff4c7d293e8d48f9ac62b7958d19047f730836ce5b3c60%40%3Cdev.commons.apache.org%3E
[2]
https://lists.apache.org/thread.html/r3ce77eb9ab9429097ca57c48cb99b8be497ee5b69d419b52a6722616%40%3Cdev.commons.apache.org%3E
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
