Agreed, too early. No need to make it more complex:
Suggestion: - First phase: put some notes in Javadoc about this. I'll be happy to suggest / draft a PR. Adding to javadoc should be uncontroversial and immediately implementable. Right? - Second phase: More thorough analysis: How can the JDK possibly be amended to be more "compliant" in this area. Not sure an analysis of the ZIPs in the wild is relevant. In any case, this step is likely to be a lot more involved and spur discussions: Would breaking changes be acceptable or better to implement new methods / classes parallel to old ones? Etc. Further, my suggestion is to create two tickets from JDK-8355338, each representing the two phases above. This way, if we get bogged down by discussions on #2 then at least we can say we did #1. :-) But yes, I'll be happy to invest time in #2 as well. /Lars On 23/04/2025 11.47, Alan Bateman wrote: > On 23/04/2025 09:24, Lars Bruun-Hansen wrote: >> : >> >> There is also a security angle: Spoofing file names in ZIP files >> is a common technique. Some implementations takes cautionary >> steps on this. For example, the Windows Explorer's ZIP reader >> simply will not show entries which start with ".." or ".". >> Well done, I would say. It is of course unfair to compare a library >> (the JDK) to an end-user tool like Windows Explorer as the >> objectives are different, however can we fault a user of the JDK >> if user would expect the entry names returned from ZipFile class >> (i.e. when READING) to be compliant ZIP file names? >> >> Bottom line: My point is that the subtle point that the JDK's >> implementation is based off a very old spec from Info-ZIP is likely >> to be lost on most users. Now that the "official" spec (PKWARE's) has >> become blatantly clear on file naming (except I wish they would have >> mentioned that starting the file name with "./" or "../" is illegal too), >> I believe the JDK's javadocs should at least have something to say on >> the topic of ZIP entry naming and the architectural choices made >> in the implementation (accept anything). >> >> So that is my suggestion: a "strengthening" of the Javadoc. I'll be happy >> to propose the text. A more thorough approach would be to create new >> name entry validating methods and possibly deprecate the existing ones. >> Just thought I would propose the easiest solution first: javadoc. >> > > JDK-8355338 was only created this week. As noted, the ZIP spec changed > from "should not" to "MUST not", a change that was not noticed until > this bug report. > > I think too early to give an opinion on whether to change the spec > and/or implementation. Preliminary data from a scan of ~1 million > ZIP/JAR files suggests there aren't too many cases of this but more > analysis will be required to inform and help narrow down options. Note > that Oracle employees (and probably many others here) cannot engage in > any discussion about security issues so discussion here will be more > focused on the compatibility impact and options. > > Most of the ZIP/JAR creation will likely come from tools in the eco > system, e.g.Maven plugins. I think it would be useful to gather some > data to see if there are usages of these tools/plugins that would > cause them to attempt to create ZIP/JAR files with these bad entry > names. Is this something you have cycles to help gather? > > -Alan >
