On 03/05/2024 08:17, Michael Osipov wrote:
Hi folks,
currenly we have a minimalistic ASN.1 parser in the code tree w/o any
testing
The ASN.1 parsing is covered by the test suite.
since it assumes that the passed byte array is properly encoded.
Correct. For the Tomcat use case it is sufficient that parsing fails if
the input is invalid. It doesn't need to be particularly elegant at that
point.
Now, I do have some X.509 related improvements which I'd like to bring
upstream from my OSS project which I think will benefit everyone using
X.509 (processing SAN from a client cert) in the enterprise world,
I'm not seeing much/any demand for this. Can you expand on the use case?
but
this requires extending the parser. In fact, I have written a
minimalistic parser for my use case with error handling and swapped for
the Tomcat's one and most tests fail with ArrayIndexOutOfBoundsException
because our code does not check anything.
How minimal is minimal? Lines of code / JAR size?
I do not want to write yet another full-blown parser, but do not also
want to reinvent the wheel.
So several questions come to my mind:
1. Since I do also have other OSS components for Tomcat which do require
an ASN.1 parser would our position be use our parser at your own risk or
solve the problem yourself? I need only SEQUENCEs, tagged types. Nothing
fancy.
What do you need that the current Tomcat implementation doesn't provide?
I think our position is use Tomcat's if it works for you. We'll consider
PRs for enhancements if it doesn't. You are, of course, free to write
you own or use another implementation.
2. Should we consider ditching it for something public and shade it like
we do with other components? Apache Kerby ASN.1 is quite small and very
decent.
Tomcat - 180 lines. Kerby - 100 kB JAR.
Kerby looks like a good choice if we want to go this route.
There have been discussions about a new tomcat-shaded JAR that would
provide all the shaded dependencies we use both internally and with the
migration tool. My general concern with that is the volume of code. The
migration tool is already a 1MB JAR - most of it shaded code that is
never going to be used. There are tradeoffs to make there that need a
longer discussion. It is likely to be one of the topics at the Tomcat
Security day in Bratislava.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
