Not too familiar with the provenance of the MD5Checker or why we have to generate our own hashes, so please forgive me if this is a “already known" question 😊 Does adobe and Google host the expected MD5 hashes for the artifacts that we download from them? If so, would it be possible to check against that rather than our own generated hash? That way as they update them, we will know the right hash to check against.
Chris Sent from Surface From: Alex Harui Sent: Tuesday, June 02, 2015 6:22 PM To: dev@flex.apache.org Using [DISCUSS] tag because this thread might result in an Infra ticket. Those of you who are subscribed to commits@ have seen the not-so-occasional MD5Checker build failures. They seem to magically occur when I’m not near my computer. MD5Checker runs hourly to check if the MD5’s of various downloads in Apache Flex releases are valid. When I first set this up, it never occurred to me that the MD5’s of existing downloads would ever change, but Adobe keeps changing the MD5’s of old SDK packages, SWFObject just changed their MD5, and Google Closure Library also changes frequently. We run the build often, because as soon as an MD5 does change, people can’t install until we get a chance to update the list of MD5s we keep at flex.a.o that the install scripts reference. IF we don’t do MD5 checks at all, we see installers crash since Ant doesn’t have good exception handling when unzipping things so in past discussions, we keep deciding to use MD5s so the failure experience is less jarring. The problem with fully automating MD5 updates is that the list is kept at flex.a.o and there is no way to automatically update that without SVN login credentials. I don’t think we want to keep SVN login credentials on a server somewhere. Further, MD5 checker is running on my CI server. So, I think it is time to change something. Some ideas I have: 1) Redirect to pull the list directly off my CI server. That would be 44K per install (actually 88K since it gets pulled once by the Installer UI and again by the Ant script. That might turn out to be more bandwidth than I would like to support. 2) Do #1, but move the MD5Checker task to build.a.o. The problem is that it is an AIR app, so I think I’d just be trading one headache for another since we can’t get to the builds.a.o machine directly to deal with AIR updates. 3) Request an Azure VM from Infra and move MD5Checker there. 4) Hack something in the Installer to override the MD5s by pulling a small file containing just the MD5s from the CI server. This would not help folks using Ant and not the installer. I think #3 is my favorite option right now. I tried to find a way to stick the MD5s in the .properties files and redirect to those on the CI server (they are currently 4K or less) but I couldn’t find a way to pull different MD5s for different AIR or Flash versions. Solutions of changing future install scripts are reasonable, but don’t help the folks still trying to install older releases. Thoughts? -Alex
