You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While reading this code to review an unrelated PR, I noticed that the package job in the release repository downloads the WAR file produced by the release job in the release repository from Artifactory using the jv tool, which does not appear to do any certificate verification or checksum verification. This means that any problem in the download would not be detected. For example, if the server closes the connection and we get a truncated file, we would likely happily drive on to publish that truncated WAR file. Or if, for some reason, there was a bit flip or filesystem corruption on the downloaded file (a phenomenon that seems unlikely but which I have personally observed with my own two eyes multiple times in my career), we would happily publish the corrupt artifact.
After downloading the WAR file from Artifactory with jv, we should verify it somehow—either by checksum or by verifying the GPG signature.
The text was updated successfully, but these errors were encountered:
somehow does checksum validation, but based on https://maven.apache.org/resolver/expected-checksums.html it appears to be implemented only for Sonatype Nexus 2 ETag headers, and I confirmed the ETag returned by Artifactory does not match the expected format.
Artifactory does store checksums, and provides them via its REST API, so one option would be to fetch the SHA1 checksum with the Artifactory REST API and then verify the download with it.
Experimental observation with wget -S https://repo.jenkins-ci.org/releases/org/jenkins-ci/main/jenkins-war/2.452/jenkins-war-2.452.war shows that Artifactory seems to send the MD5 checksum in an ETag header, but it's unclear whether that is a stable API that can be relied on or merely a side effect of Artifactory using S3 storage, which defaults to providing an MD5 checksum in an ETag header but may be subject to change in the future.
I confirmed that Artifactory provides an accurate SHA256 checksum via curl -s https://repo.jenkins-ci.org/api/storage/releases/org/jenkins-ci/main/jenkins-war/2.452/jenkins-war-2.452.war | jq -r .checksums.sha256 so this seems like the most straightforward option.
I seem to have stumbled on an even simpler way to get it from Artifactory: wget https://repo.jenkins-ci.org/releases/org/jenkins-ci/main/jenkins-war/2.452/jenkins-war-2.452.war.sha256.
While reading this code to review an unrelated PR, I noticed that the
package
job in therelease
repository downloads the WAR file produced by therelease
job in therelease
repository from Artifactory using thejv
tool, which does not appear to do any certificate verification or checksum verification. This means that any problem in the download would not be detected. For example, if the server closes the connection and we get a truncated file, we would likely happily drive on to publish that truncated WAR file. Or if, for some reason, there was a bit flip or filesystem corruption on the downloaded file (a phenomenon that seems unlikely but which I have personally observed with my own two eyes multiple times in my career), we would happily publish the corrupt artifact.After downloading the WAR file from Artifactory with
jv
, we should verify it somehow—either by checksum or by verifying the GPG signature.The text was updated successfully, but these errors were encountered: