For some reason, the install bootstrapper for 3.5.3 x86 embedded the wrong hash value for launcher.msi. As a result, it will fail to download the file and install will be aborted.

The workaround is to deselect the launcher from being installed, and use the 64-bit installer to install the launcher. Or alternatively, install Python 3.6 to get the later version of the installer, which will then automatically skip it for the 3.5 installer.

Python 3.6 is unaffected, so this may just have been a build glitch, but it needs investigation and testing so it doesn't happen again. (Adding a /layout test after uploading is an easy way to test this.)

Since the webmaster@ address tends to bear the brunt of these, can I 
make sure I understand the situation?

* The only installers affected are those for x86/32-bit Windows 3.5.3

* By default [I just checked] the launcher checkbox is not checked

* If it *is* checked by the user, the entire install will abort

* If it is left unchecked, the install will succeed and it is then 
possible to run the x64 installer and select only the installer option.

Is there a possibility of producing a repaired installer? And/or should 
we hide that specific set of installers for the moment?

Creating a repaired installer is possible, though risky (it's easy when I still have the original build handy, but at this stage a rebuild will produce different hashes and make things worse). But I intend to look into that as soon as I can.

If the launcher is not already installed, or if an older version is installed, it will be selected by default. So it's a little harder to avoid, and more likely to cause problems for people who don't have 3.6.

There's a command line option to just install the launcher (LauncherOnly=1), but nothing in the UI. However, if you install and then uninstall Python, the launcher is left behind (must be uninstalled separately), so that's one way to get it. I'd suggest add/remove Python 3.6, as that will get the latest version of the launcher.

I have built an updated web installer which should allow us to replace just the one file on the server to fix the issue. The only downside is that it is not compatible with existing installs of 3.5.3 (that is, you can't run the executable to Modify/Repair/Remove an existing install, but unless you've corrupted your machine you can do those through Programs and Features).

If anyone would like to test it, I've attached the file here. I've done one test on my own machine (separate from the build machine) including installing the launcher and all optional components and it was fine, but some more validation before I replace the existing executable would be nice.

(Added RM Larry as FYI. This doesn't affect anything else.)

AFAICT so far, it appears to have been a build glitch where the launcher MSI was rebuilt in between 32-bit and 64-bit builds (the weird part here is that the rebuild was correct and the initial build was wrong, which is backwards from what I'd expect...). The upload included the rebuilt MSI but the bootstrapper was expecting the initial build.

I'm still trying to track down why that happened, but in the meantime I've added a test (PR 258) to my upload script that will detect problems like this before we announce the release.

New changeset e29741466df0cd01a49bf5ec3b1df3e2bad119a7 by Steve Dower in branch '3.5':
bpo-29624: Adds purge step and layout test after uploading files. (#258) (#263)
https://github.com/python/cpython/commit/e29741466df0cd01a49bf5ec3b1df3e2bad119a7

New changeset f2beceb7e54fadc507137f86cbe9d74f7e5b8f7c by Steve Dower in branch '3.6':
bpo-29624: Adds purge step and layout test after uploading files. (#258) (#264)
https://github.com/python/cpython/commit/f2beceb7e54fadc507137f86cbe9d74f7e5b8f7c

New changeset 1aceb024172ea3d6f9dd6e90f4fbe63ea1fb054e by Steve Dower in branch 'master':
bpo-29624: Adds purge step and layout test after uploading files. (#258)
https://github.com/python/cpython/commit/1aceb024172ea3d6f9dd6e90f4fbe63ea1fb054e

This is marked as "critical". Looks like it's fixed. Can we close it?