My upload_release script[1] downloads the tarball built after a tag is pushed, prompts me to GPG-sign it and uploads it to LP. It checks that the MD5 on LP is the same as the tarball it downloaded.
That leaves the possibility of corruption in the first steps of the process (artefact copy to tarballs.o.o, and download from there). Ideally the Jenkins job which produces the tarball would compute the MD5 for that before copying anything, publish that and my script would check that the end result (uploaded file as seen from LP) still has the same MD5.
To that effect, I need to be able to query Jenkins with $project and $tag as parameters, and get an MD5 in return.
Proposed implementation (by mordred) is to set two Jenkins metadata as the result of its job: tag and md5, and then I could query using API the recent $project-tarball jobs for jobs with tag=$tag, and retrieve the corresponding md5.
I think a simple way to publish the md5 would be to upload a $PACKAGE_NAME.md5 file along with the actual sdist upload. For this to be useful we will need to put the items we publish behind HTTPS to avoid a MiTM. This may be overkill though. Releases currently go to launchpad from tarballs via ttx so we need only make the path from tarballs to ttx trusted. In any case this could probably use a little more discussion.