Details
-
Bug
-
Resolution: Unresolved
-
Major
-
None
-
3.18.1
-
3
Description
The remote at https://jitpack.io is misconfigured today ( Sept 16, 2019 ), it is returning zero length content when it detects a Nexus Repo user agent header.
We correctly block download of the maven-metedata.xml files and checksum files when these zero length files are received, but we are allowing zero length pom and jar files to be downloaded. Note that older versions of repo would also cache zero length checksum and metadata files.
The reproduce case today is to simply make a maven2 proxy repository against https://jitpack.io, and then request a pom or jar file through the proxy. This file does not have to exist on the remote.
curl -v http://localhost:8081/repository/maven-jitpack/com/foo/bar/1.0/bar-1.0.pom curl -v http://localhost:8081/repository/maven-jitpack/com/foo/bar/1.0/bar-1.0.jar
External References
https://github.com/jitpack/jitpack.io/issues/3977
https://github.com/jitpack/jitpack.io/issues/3978
Update Sept 17, 2019
jitpack.io support reports the following to Sonatype:
It was indeed an issue on our side and we've released a fix. Those requests should now be returning 404.
So if you've been affected by this, removing the bad files from your jitpack.io proxy repository, or just deleting and recreating the proxy repository will provide a workaround.
Expected
File content validation should reject zero length pom.
Note that we need to be careful here, zero length tar files are (sadly) valid, and zero length text and css files are also common. So we can't block download of all files that are zero length. I think the safest thing to do would be to disallow zero length pom files, and also zero length zip archives of any type (jar, war, ear, zip, etc.).
Updated the above based on internal discussion... turns out Maven will deploy zero length jar files in some circumstances). So we should just worry about pom files.