On 2024/05/03 08:59:17 Mark Thomas wrote: > > > 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.
My bad, I didn't make myself clear: there is not negative testing explicitly for bad input data. > > 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? Yes, look at SAN:otherName. this custom field in CHOICE [0] is used in Active Directory environments to embed the user principal name into the certificate. With that UPN you can authenticate with certs from smartcard and find the subject in AD via LDAP. The actual code: [1] with the change to Tomcat's parser [2]. That contribution is a separate mail and PR, of course. > > 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? My minimal, for the use case at least few hundred lines. > > 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? UTF8String, typed tagged values. Basically they are trivial. Simple types, not constructed. > 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. I'll do the PRs for our parser. > > 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. What is the benefit of a single JAR here for the public? [1] https://github.com/michael-o/tomcatspnegoad/blob/ca5096b4f0ae7b90ef479a31c066e3808aa70ef2/tomcat90/src/main/java/net/sf/michaelo/tomcat/realm/ActiveDirectoryRealm.java#L372-L408 [2] https://github.com/michael-o/tomcatspnegoad/commit/7d7616a834aadfc80d3533f7eea93458bb2bf53f --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
