[Python-Dev] [RELEASED] Python 3.4.0b2 (original) (raw)
Michael Urman murman at gmail.com
Mon Jan 6 17:26:47 CET 2014
- Previous message: [Python-Dev] [RELEASED] Python 3.4.0b2
- Next message: [Python-Dev] [RELEASED] Python 3.4.0b2
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Mon, Jan 6, 2014 at 9:43 AM, Guido van Rossum <guido at python.org> wrote:
Since MSIEXEC.EXE is a legit binary (not coming from our packager) and Akamai is a legitimate company (MS most likely has an agreement with them), at this point I would assume that there's something that MSIEXEC.EXE wants to get from Akamai, which is unintentionally but harmlessly triggered by the Python install. Could it be checking for upgrades?
Here's some more guesswork. Does it seem possible that msiexec is trying to verify the revocation status of the certificate used to sign the python .msi file? Per http://blogs.technet.com/b/pki/archive/2006/11/30/basic-crl-checking-with-certutil.aspx it looks like crl.microsoft.com is the host; this is hosted on akamai: crl.microsoft.com is an alias for crl.www.ms.akadns.net. crl.www.ms.akadns.net is an alias for a1363.g.akamai.net.
There are various things you could try to verify this. You could test with simpler .msi files where one is signed and another is not signed (I'll leave it up to you to find such things, but ORCA is a common "test" .msi file). Or you could take a verbose log of the installation process (msiexec /l*v python.log python.msi OR http://support.microsoft.com/kb/223300), sit on the prompt for network access so you can uniquely identify the log's timestamps, and try to identify at what point of the installation the network access occurs. Once that is known, more steps can be taken to identify and resolve any actual issues.
Michael
- Previous message: [Python-Dev] [RELEASED] Python 3.4.0b2
- Next message: [Python-Dev] [RELEASED] Python 3.4.0b2
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]