[RELEASED] Python 3.4.0b2
On behalf of the Python development team, I'm pleased to announce the second beta release of Python 3.4. This is a preview release, and its use is not recommended for production settings. Python 3.4 includes a range of improvements of the 3.x series, including hundreds of small improvements and bug fixes. Major new features and changes in the 3.4 release series include: * PEP 428, a "pathlib" module providing object-oriented filesystem paths * PEP 435, a standardized "enum" module * PEP 436, a build enhancement that will help generate introspection information for builtins * PEP 442, improved semantics for object finalization * PEP 443, adding single-dispatch generic functions to the standard library * PEP 445, a new C API for implementing custom memory allocators * PEP 446, changing file descriptors to not be inherited by default in subprocesses * PEP 450, a new "statistics" module * PEP 451, standardizing module metadata for Python's module import system * PEP 453, a bundled installer for the *pip* package manager * PEP 454, a new "tracemalloc" module for tracing Python memory allocations * PEP 456, a new hash algorithm for Python strings and binary data * PEP 3154, a new and improved protocol for pickled objects * PEP 3156, a new "asyncio" module, a new framework for asynchronous I/O Python 3.4 is now in "feature freeze", meaning that no new features will be added. The final release is projected for late February 2014. To download Python 3.4.0b2 visit: http://www.python.org/download/releases/3.4.0/ Please consider trying Python 3.4.0b2 with your code and reporting any new issues you notice to: http://bugs.python.org/ Enjoy! -- Larry Hastings, Release Manager larry at hastings.org (on behalf of the entire python-dev team and 3.4's contributors)
On Sun, 05 Jan 2014 13:20:50 -0800, Larry Hastings wrote:
On behalf of the Python development team, I'm pleased to announce the second beta release of Python 3.4.
Thanks, Larry and all the devs, your hard work is appreciated. However, why does this new version look like adware or other malware when installing? This is the first time I ever installed a version of Python which caused something called "MSIEXEC.EXE" to try to access some commercial dot-com site. Naturally, my firewall stopped it, but what's going on? (A "command prompt" Windows box opened, followed by my firewall firing off a set of warnings about having blocked attempted unauthorized outbound connections to blah-blah-blah-dot-com.) When I attempted to run the python interpreter it appeared to open normally, but I haven't tried doing anything with it. If this has to do with "ensure_pip" or whatever it's called, perhaps some other solution is called for which is more user-friendly and not as likely to incite unease and mistrust by attempting to silently access a commercial site while Python is installing. At the very least a warning seems to be called for (possibly along with an opt-out). Also, a more friendly site (python.org?) to connect to would help to restore some faith. If it *is* about the pip thing, I can only imagine the frustration of Window users: Having to reconfigure firewalls to (properly?) upgrade Python, or ignoring the firewall-warning "glitch" assuming it's okay. Or, possibly, a silent failure of "something" if they're firewalled with warnings turned off? If it's not pip, what is it? Finally, is my install now broken? Are offline installs now not possible. Does one now need an always-on internet connection to use Python? Thanks -- Bob Hanson -- Snowden reveals that George Orwell was an extreme optimist.
-- Regards, Benjamin On Sun, Jan 5, 2014, at 04:19 PM, Bob Hanson wrote:
On Sun, 05 Jan 2014 13:20:50 -0800, Larry Hastings wrote:
On behalf of the Python development team, I'm pleased to announce the second beta release of Python 3.4.
Thanks, Larry and all the devs, your hard work is appreciated.
However, why does this new version look like adware or other malware when installing?
This is the first time I ever installed a version of Python which caused something called "MSIEXEC.EXE" to try to access some commercial dot-com site.
Naturally, my firewall stopped it, but what's going on?
(A "command prompt" Windows box opened, followed by my firewall firing off a set of warnings about having blocked attempted unauthorized outbound connections to blah-blah-blah-dot-com.)
Well, what is blah-blah-blah.com exactly?
When I attempted to run the python interpreter it appeared to open normally, but I haven't tried doing anything with it.
If this has to do with "ensure_pip" or whatever it's called, perhaps some other solution is called for which is more user-friendly and not as likely to incite unease and mistrust by attempting to silently access a commercial site while Python is installing. At the very least a warning seems to be called for (possibly along with an opt-out). Also, a more friendly site (python.org?) to connect to would help to restore some faith.
If it *is* about the pip thing, I can only imagine the frustration of Window users: Having to reconfigure firewalls to (properly?) upgrade Python, or ignoring the firewall-warning "glitch" assuming it's okay. Or, possibly, a silent failure of "something" if they're firewalled with warnings turned off?
If it's not pip, what is it?
Finally, is my install now broken? Are offline installs now not possible. Does one now need an always-on internet connection to use Python?
Thanks --
Bob Hanson
-- Snowden reveals that George Orwell was an extreme optimist.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/benjamin%40python.org
[Benjamin Peterson]
... This is the first time I ever installed a version of Python which caused something called "MSIEXEC.EXE"
msiexec.exe is not part of the Python download.. msiexec.exe is part of the Windows operating system, and is precisely the program that installs .msi files (which the Python installer is).
to try to access some commercial dot-com site.
Naturally, my firewall stopped it, but what's going on?
Possible: you have a virus or trojan that replaced the system msiexec.exe with its own malware. Run a full virus scan ASAP, try Malwarebyte's anti-malware program, etc etc etc.
[Bob Hanson]
This is the first time I ever installed a version of Python which caused something called "MSIEXEC.EXE"
[Tim Peters]
msiexec.exe is not part of the Python download.. msiexec.exe is part of the Windows operating system, and is precisely the program that installs .msi files (which the Python installer is).
That is correct. ;-) [Bob Hanson]
to try to access some commercial dot-com site.
Naturally, my firewall stopped it, but what's going on?
[Tim Peters]
Possible: you have a virus or trojan that replaced the system msiexec.exe with its own malware. Run a full virus scan ASAP, try Malwarebyte's anti-malware program, etc etc etc.
Didn't think this likely, but I have now quintuple-checked everything again. Everything says I have the real McCoy msiexec.exe in its proper location -- just upgraded another app which used MSI installers and it went as per normal. I'm presuming, still, that it is something to do with the "ensure that pip is present on Windows" thing? [See the bottom of my original post.] Do Nick or Martin (or other dev) have any comments? Bob Hanson -- Sent from my Smart shoephone.
[Bob Hanson]
... Didn't think this likely, but I have now quintuple-checked everything again. Everything says I have the real McCoy msiexec.exe in its proper location -- just upgraded another app which used MSI installers and it went as per normal.
That sounds most likely to me too ;-)
I'm presuming, still, that it is something to do with the "ensure that pip is present on Windows" thing? [See the bottom of my original post.]
As Benjamin asked, could you please flesh out what "blah-blah-blah-dot-com" means - what, exactly, was the site your firewall warned you about? My firewall didn't complain when I installed 3.4.0b2 on Windows.
On Sun, 5 Jan 2014 20:09:23 -0600, Tim Peters wrote:
As Benjamin asked, could you please flesh out what "blah-blah-blah-dot-com" means - what, exactly, was the site your firewall warned you about?
Forgive me, but I'm an old man with very poor vision. Using my magnifying glass, I see it is two very long URLs ending with something like after the blah-blah: < ... akametechnology.com> More precisely, these two IP addresses: 23.59.190.113:80 23.59.190.106:80
My firewall didn't complain when I installed 3.4.0b2 on Windows.
I don't use the Windows firewall, and I have mine sent to block all apps connecting in or out unless I make specific rules for them. I have never authorized C:/Windows/System32/msiexec.exe to connect in or out (and it didn't ;-) ). Bob Hanson
[Bob Hanson]
Forgive me, but I'm an old man with very poor vision. Using my magnifying glass, I see it is two very long URLs ending with something like after the blah-blah: < ... akametechnology.com>
More precisely, these two IP addresses: 23.59.190.113:80 23.59.190.106:80
So: C:\Code>ping -a 23.59.190.113 Pinging a23-59-190-113.deploy.static.akamaitechnologies.com [23.59.190.113] with 32 bytes of data: ... C:\Code>ping -a 23.59.190.106 Pinging a23-59-190-106.deploy.static.akamaitechnologies.com [23.59.190.106] with 32 bytes of data: So it's just Akamai caching content. Common as mud. Can't say specifically what was being cached, but it _could_ be that your ISP contracts with Akamai.
My firewall didn't complain when I installed 3.4.0b2 on Windows.
I don't use the Windows firewall, and I have mine sent to block all apps connecting in or out unless I make specific rules for them. I have never authorized C:/Windows/System32/msiexec.exe to connect in or out (and it didn't ;-) ).
Same here on both counts. We're getting nowhere with admirable speed ;-)
On Sun, 5 Jan 2014 21:09:53 -0600, Tim Peters wrote:
[Bob Hanson]
Forgive me, but I'm an old man with very poor vision. Using my magnifying glass, I see it is two very long URLs ending with something like after the blah-blah: < ... akametechnology.com>
More precisely, these two IP addresses: 23.59.190.113:80 23.59.190.106:80
So:
C:\Code>ping -a 23.59.190.113
Pinging a23-59-190-113.deploy.static.akamaitechnologies.com [23.59.190.113] with 32 bytes of data:
[...]
So it's just Akamai caching content. Common as mud. Can't say specifically what was being cached, but it _could_ be that your ISP contracts with Akamai.
Still not following *why* this should be happening. I was installing from my harddrive -- nothing needed to be cached as far as I was concerned. Indeed, I would normally think I could install while offline -- and often do on my PCs which are "air-gapped." Still wondering why, all of a sudden after years of using a firewalled msiexec.exe, I get it now trying to connect out while installing 3.4.0b2 from my harddrive...?
My firewall didn't complain when I installed 3.4.0b2 on Windows.
I don't use the Windows firewall, and I have mine sent to block all apps connecting in or out unless I make specific rules for them. I have never authorized C:/Windows/System32/msiexec.exe to connect in or out (and it didn't ;-) ).
Same here on both counts. We're getting nowhere with admirable speed ;-)
So, we just need to make some distance -- our speed is good? ;-) Less non-seriously, thanks for all the help, Tim (and others) -- Bob Hanson
On Sun, 05 Jan 2014 19:32:15 -0800, Bob Hanson <d2mp1a9@newsguy.com> wrote:
On Sun, 5 Jan 2014 21:09:53 -0600, Tim Peters wrote:
So it's just Akamai caching content. Common as mud. Can't say specifically what was being cached, but it _could_ be that your ISP contracts with Akamai.
Still not following *why* this should be happening. I was installing from my harddrive -- nothing needed to be cached as far as I was concerned. Indeed, I would normally think I could install while offline -- and often do on my PCs which are "air-gapped."
Still wondering why, all of a sudden after years of using a firewalled msiexec.exe, I get it now trying to connect out while installing 3.4.0b2 from my harddrive...?
The ensurepip developers will have to say for sure, but my understanding is that it does *not* go out to the network. On the other hand, it is conceivable that pip 1.5, unlike the earlier version in Beta1, is doing some sort of "up to date check" that it shouldn't be doing in the ensurepip scenario. I presume you did have the installer install pip. If you haven't already, You might try reinstalling and unchecking that option, and see if it msiexec still tries to go out to the network. That would confirm it is ensurepip that is the issue (although that does seem most likely). --David
ensurepip uses —no-index so it shouldn’t be hitting the network at all. On Jan 5, 2014, at 11:06 PM, R. David Murray <rdmurray@bitdance.com> wrote:
On Sun, 05 Jan 2014 19:32:15 -0800, Bob Hanson <d2mp1a9@newsguy.com> wrote:
On Sun, 5 Jan 2014 21:09:53 -0600, Tim Peters wrote:
So it's just Akamai caching content. Common as mud. Can't say specifically what was being cached, but it _could_ be that your ISP contracts with Akamai.
Still not following *why* this should be happening. I was installing from my harddrive -- nothing needed to be cached as far as I was concerned. Indeed, I would normally think I could install while offline -- and often do on my PCs which are "air-gapped."
Still wondering why, all of a sudden after years of using a firewalled msiexec.exe, I get it now trying to connect out while installing 3.4.0b2 from my harddrive...?
The ensurepip developers will have to say for sure, but my understanding is that it does *not* go out to the network. On the other hand, it is conceivable that pip 1.5, unlike the earlier version in Beta1, is doing some sort of "up to date check" that it shouldn't be doing in the ensurepip scenario.
I presume you did have the installer install pip. If you haven't already, You might try reinstalling and unchecking that option, and see if it msiexec still tries to go out to the network. That would confirm it is ensurepip that is the issue (although that does seem most likely).
--David _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/donald%40stufft.io
----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
On 06.01.2014 05:12, Donald Stufft wrote:
ensurepip uses —no-index so it shouldn’t be hitting the network at all.
Do you have a test to ensure that ensurepip doesn't try to use network connections? You could e.g. mock socket.create_connection() and socket.socket() in a custom socket module. The subprocess makes it a little bit more complicated to test its behavior. Christian
[For the record: I'm running 32bit Windows XP (Pro) SP2 and installing "for all users."] TL;DR: No matter what I tried this morning re uninstalling and reinstalling 3.4.0b2, pip or no pip, MSI still tried to connect to the Akamai URLs. On Sun, 05 Jan 2014 23:06:49 -0500, R. David Murray wrote:
Still wondering why, all of a sudden after years of using a firewalled msiexec.exe, I get it now trying to connect out while installing 3.4.0b2 from my harddrive...?
The ensurepip developers will have to say for sure, but my understanding is that it does *not* go out to the network. On the other hand, it is conceivable that pip 1.5, unlike the earlier version in Beta1, is doing some sort of "up to date check" that it shouldn't be doing in the ensurepip scenario.
I presume you did have the installer install pip.
To be honest, I forgot all about pip until after I become a wee bit alarmed by the installer going out to the interwebs -- didn't even notice a checkbox for that option.
If you haven't already, You might try reinstalling and unchecking that option, and see if it msiexec still tries to go out to the network. That would confirm it is ensurepip that is the issue (although that does seem most likely).
Working again on this, this morning: Uninstalled and then reinstalled 3.4.0b2. No check box for pip, but there was that strange "tree" of collapsed options which included a pip one and which appeared to default to "install pip." Left pip on as was the default. Curiously, although I hadn't remembered this happening yesterday, this morning, the installer said there was already a 3.4x installed and do I want to overwrite it. (Uninstalling 3.4.0b2 had left behind my addition of sympy and another file or two of my own from 3.4.0b1.) I told MSI to go ahead and overwrite. Sure enough, the installer tried to connect to the same two IPs (Akamai I'm now told) with the installer left at default options. --- Next, I uninstalled 3.4.0b2 again, this time removing the entire dir after uninstalling. Reinstalling (still default settings on installer) this time gave me a bunch of *new* additions to site-packages including pip, setuptools, easy_install.py -- all of which were *not* installed into site-packages when priorly overinstalling. Again, this time, msiexec.exe still attempted to connect (two bursts -- each time, twice to each of the aforementioned URLs). --- Finally, I uninstalled 3.4.0b2, removed the dir, and reinstalled yet again, this time selecting the "don't install pip" option in the funky Windows "option tree" in the MSI installer. Yet *still* again, there were several sets of attempts by msiexec.exe to connect to the same two Akamai URLs -- but, no pip or other cruft in site-packages nor any pip-things in Scripts after the install finished. So, whatever I have tried -- pip or no pip -- msiexec.exe still attempts to connect to those Akamai URLs. [Hopefully, I kept accurate notes this morning and didn't typo them above.] At any rate, the attempts to connect to the network seem like undesirable behavior to this man. If pip is necessary, then some Window users may well end up without it -- and then not know why something later doesn't work. Got to go now, but will check in this evening or in the morning, tomorrow. Again, many thanks to all for the help -- Bob Hanson
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? On Mon, Jan 6, 2014 at 5:29 AM, Bob Hanson <d2mp1a9@newsguy.com> wrote:
[For the record: I'm running 32bit Windows XP (Pro) SP2 and installing "for all users."]
TL;DR: No matter what I tried this morning re uninstalling and reinstalling 3.4.0b2, pip or no pip, MSI still tried to connect to the Akamai URLs.
On Sun, 05 Jan 2014 23:06:49 -0500, R. David Murray wrote:
Still wondering why, all of a sudden after years of using a firewalled msiexec.exe, I get it now trying to connect out while installing 3.4.0b2 from my harddrive...?
The ensurepip developers will have to say for sure, but my understanding is that it does *not* go out to the network. On the other hand, it is conceivable that pip 1.5, unlike the earlier version in Beta1, is doing some sort of "up to date check" that it shouldn't be doing in the ensurepip scenario.
I presume you did have the installer install pip.
To be honest, I forgot all about pip until after I become a wee bit alarmed by the installer going out to the interwebs -- didn't even notice a checkbox for that option.
If you haven't already, You might try reinstalling and unchecking that option, and see if it msiexec still tries to go out to the network. That would confirm it is ensurepip that is the issue (although that does seem most likely).
Working again on this, this morning: Uninstalled and then reinstalled 3.4.0b2. No check box for pip, but there was that strange "tree" of collapsed options which included a pip one and which appeared to default to "install pip." Left pip on as was the default.
Curiously, although I hadn't remembered this happening yesterday, this morning, the installer said there was already a 3.4x installed and do I want to overwrite it. (Uninstalling 3.4.0b2 had left behind my addition of sympy and another file or two of my own from 3.4.0b1.) I told MSI to go ahead and overwrite.
Sure enough, the installer tried to connect to the same two IPs (Akamai I'm now told) with the installer left at default options.
---
Next, I uninstalled 3.4.0b2 again, this time removing the entire dir after uninstalling. Reinstalling (still default settings on installer) this time gave me a bunch of *new* additions to site-packages including pip, setuptools, easy_install.py -- all of which were *not* installed into site-packages when priorly overinstalling.
Again, this time, msiexec.exe still attempted to connect (two bursts -- each time, twice to each of the aforementioned URLs).
---
Finally, I uninstalled 3.4.0b2, removed the dir, and reinstalled yet again, this time selecting the "don't install pip" option in the funky Windows "option tree" in the MSI installer.
Yet *still* again, there were several sets of attempts by msiexec.exe to connect to the same two Akamai URLs -- but, no pip or other cruft in site-packages nor any pip-things in Scripts after the install finished.
So, whatever I have tried -- pip or no pip -- msiexec.exe still attempts to connect to those Akamai URLs.
[Hopefully, I kept accurate notes this morning and didn't typo them above.]
At any rate, the attempts to connect to the network seem like undesirable behavior to this man. If pip is necessary, then some Window users may well end up without it -- and then not know why something later doesn't work.
Got to go now, but will check in this evening or in the morning, tomorrow.
Again, many thanks to all for the help --
Bob Hanson
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40python.org
-- --Guido van Rossum (python.org/~guido)
On Mon, Jan 6, 2014 at 9:43 AM, Guido van Rossum <guido@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-ce... 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
Am 06.01.14 17:26, schrieb Michael Urman:
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-ce... 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.
I think that could be close. The MSI file has two signatures in it: the PSF code signing signature, and a Verisign timestamping signature. For the PSF certificate, the CRL is at csc3-2010-crl.verisign.com, which is (here) a CNAME for crl.ws.symantec.com.edgekey.net, which in turn is a CNAME for e6845.ce.akamaiedge.net. The timestamping signature has its CRL at ts-crl.ws.symantec.com, which is a CNAME for crl.ws.symantec.com.edgekey.net again. So the most plausible reason is indeed that it tries to download CRLs, though not Microsoft ones, but Verisign/Symantic ones. Regards, Martin
[Top-post fixed (use-case is an exception to the GvR rule ;-) ) and some attributions restored with my additional comments following for the ease of future readers.] TL;DR: Outbound-connection attempts seem to be happening only to me, therefore, most likely not a Python problem -- but some problem at my end. Thanks to all. On Mon, 6 Jan 2014 05:43:38 -1000, Guido van Rossum wrote:
On Mon, Jan 6, 2014 at 5:29 AM, Bob Hanson <d2mp1a9@newsguy.com> wrote:
[For the record: I'm running 32bit Windows XP (Pro) SP2 and installing "for all users."]
TL;DR: No matter what I tried this morning re uninstalling and reinstalling 3.4.0b2, pip or no pip, MSI still tried to connect to the Akamai URLs.
On Sun, 05 Jan 2014 23:06:49 -0500, R. David Murray wrote:
On Sun, 05 Jan 2014 19:32:15 -0800, Bob Hanson wrote:
Still wondering why [...] msiexec.exe [is] trying to connect out while installing 3.4.0b2 from my harddrive...?
The ensurepip developers will have to say for sure, but my understanding is that it does *not* go out to the network. On the other hand, it is conceivable that pip 1.5, unlike the earlier version in Beta1, is doing some sort of "up to date check" that it shouldn't be doing in the ensurepip scenario.
I presume you did have the installer install pip.
To be honest, I forgot all about pip [...] didn't even notice a checkbox for that option.
If you haven't already, You might try reinstalling and unchecking that option, and see if it msiexec still tries to go out to the network. That would confirm it is ensurepip that is the issue (although that does seem most likely).
[...snip synopsis of various uninstall-reinstall dances...]
So, whatever I have tried -- pip or no pip -- msiexec.exe still attempts to connect to those Akamai URLs.
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?
When I read this comment of yours, Guido, I immediately started wondering about this. You may well be right -- indeed, I have a very old install (c.2007) which has not been updated (other than one or three new MS "drivers"). Perhaps the Python 3.4.0b2 MSI installer uses a new capability, which, as you say, causes the installer to at least attempt to upgrade...? In any event, as there's been no other reports, this seems to be something happening only to me. As such, it seems to be not a Python problem, but some misconfiguration on my own system, say. If I retain interest in investigating this, and if I *do* find an actual problem with Python, I'll post again. Thanks go to you, Guido, as well as to Tim and all the others who helped me with this. Regards, Bob Hanson -- Write once, read many.
On 9 January 2014 00:43, Bob Hanson <d2mp1a9@newsguy.com> wrote:
When I read this comment of yours, Guido, I immediately started wondering about this. You may well be right -- indeed, I have a very old install (c.2007) which has not been updated (other than one or three new MS "drivers").
Perhaps the Python 3.4.0b2 MSI installer uses a new capability, which, as you say, causes the installer to at least attempt to upgrade...?
I believe the pip bootstrapping involves an MSI feature we haven't previously used (MvL would be able to confirm). If so, then MSI may be looking for a new version to interpret that new setting. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
Am 08.01.14 16:03, schrieb Nick Coghlan:
On 9 January 2014 00:43, Bob Hanson <d2mp1a9@newsguy.com> wrote:
When I read this comment of yours, Guido, I immediately started wondering about this. You may well be right -- indeed, I have a very old install (c.2007) which has not been updated (other than one or three new MS "drivers").
Perhaps the Python 3.4.0b2 MSI installer uses a new capability, which, as you say, causes the installer to at least attempt to upgrade...?
I believe the pip bootstrapping involves an MSI feature we haven't previously used (MvL would be able to confirm). If so, then MSI may be looking for a new version to interpret that new setting.
That's not true. The pip bootstrapping uses a custom action, and we already have one that is similar (compile to pyc), although that isn't run by default. My guess is that it might try verifying signatures, and somehow tries to obtain the CA certificates (although it's puzzling that it would get them from akamai - perhaps MS is hosting the CA bundle there). Regards, Martin
On 6 January 2014 15:29, Bob Hanson <d2mp1a9@newsguy.com> wrote:
At any rate, the attempts to connect to the network seem like undesirable behavior to this man. If pip is necessary, then some Window users may well end up without it -- and then not know why something later doesn't work.
I have installed python 3.4b2 on Windows (7, 64-bit) and seen no network connections like this. I didn't check too closely, and I don't know that my (corporate) firewall would necessarily report this to me. But it seemed fine to me. I'll see if I can try an install on a VM with no network access at some point, and see what that does. One possibility which might be worth investigating - some Windows software can insert itself into the network stack and trigger extra net calls (I believe it's common with things like parental control software, and I once ended up with a thoroughly broken network because ZoneAlarm did something nasty to me). As no-one else seems to be having the issues you are, could it be that something else is intercepting part of the install process, unrelated to Python? It's also worth noting that the Python MSI is "just" a database of files and settings to install (plus some post-install scripts that would behave the same on all systems, and don't connect to the net AIUI). The MSI is interpreted, as you note, by the OS-supplied msiexec.exe. Is it possible that you have some sort of patched msiexec (there's lots of opportunity for OEM customisation in Windows, maybe your hardware supplier added something to get a logo/advert from their website when installs run)? I'm clutching at straws here, certainly, but it does look like it's an issue local to your setup. Paul
Bob Hanson writes:
On Sun, 5 Jan 2014 20:09:23 -0600, Tim Peters wrote:
As Benjamin asked, could you please flesh out what "blah-blah-blah-dot-com" means - what, exactly, was the site your firewall warned you about?
Forgive me, but I'm an old man with very poor vision. Using my magnifying glass, I see it is two very long URLs ending with something like after the blah-blah: < ... akametechnology.com>
I suppose you tried cutting and pasting? Note that you don't need to be exact as long as you're pretty sure you got the whole thing -- your readers who have better eyesight can parse out the URL easily enough.
More precisely, these two IP addresses: 23.59.190.113:80 23.59.190.106:80
Somebody who doesn't know the rules of capitalization (see ww1.akamitechnologies.com) appears to be spoofing Akamai (the web caching/distribution service used by President Obama among other prominent users). The domain referenced is presumably some variation on <IP address>.deploy.static.akamitechnologies.com (according to host <IP>), and the long URL is rooted at /ses/ so it's trying to convince you it's a session (whether that is actually true or not I don't know, that's just what I would guess if I were trying to reverse engineer an honest URL, which this sure doesn't seem to be). So your alarm seems to be verified, but why this happened to a Python download I don't know. It could be DNS hacking between you and python.org, as well as something in the Python MSI. HTH Steve
[Bob Hanson]
... magnifying glass, I see it is two very long URLs ending with something like after the blah-blah: < ... akametechnology.com>
[Stephen J. Turnbull]
I suppose you tried cutting and pasting? Note that you don't need to be exact as long as you're pretty sure you got the whole thing -- your readers who have better eyesight can parse out the URL easily enough.
I don't think this was cut 'n paste. Looking up the IP addresses returns legit Akamai URLs:
More precisely, these two IP addresses: 23.59.190.113:80 23.59.190.106:80
C:\Code>ping -a 23.59.190.113 Pinging a23-59-190-113.deploy.static.akamaitechnologies.com [23.59.190.113] with 32 bytes of data: ... C:\Code>ping -a 23.59.190.106 Pinging a23-59-190-106.deploy.static.akamaitechnologies.com [23.59.190.106] with 32 bytes of data: ... Bob's "< ... akametechnology.com>" just looks like compounded typos.
... So your alarm seems to be verified, but why this happened to a Python download I don't know. It could be DNS hacking between you and python.org, as well as something in the Python MSI.
Honestly, for all we _know_, this firewall alert may have been triggered by some other program that just happened to wake up while Bob was installing Python. Sure, that's unlikely. But so is everything else about this ;-)
On Sun, 5 Jan 2014 23:54:41 -0600, Tim Peters wrote: [Bob Hanson]
... magnifying glass, I see it is two very long URLs ending with something like after the blah-blah: < ... akametechnology.com>
[Stephen J. Turnbull]
I suppose you tried cutting and pasting? [...]
Tried, but was unsuccessful. [Tim Peters]
I don't think this was cut 'n paste. Looking up the IP addresses returns legit Akamai URLs:
[...]
C:\Code>ping -a 23.59.190.113
Pinging a23-59-190-113.deploy.static.akamaitechnologies.com [23.59.190.113] with 32 bytes of data: ... C:\Code>ping -a 23.59.190.106
Pinging a23-59-190-106.deploy.static.akamaitechnologies.com [23.59.190.106] with 32 bytes of data: ...
Bob's "< ... akametechnology.com>" just looks like compounded typos.
Typos or blindos. ;-) Took a screenshot just now and zoomed in -- I can now verify that the URLs are as Tim has 'em above. [Stephen J. Turnbull]
So your alarm seems to be verified, but why this happened to a Python download I don't know. It could be DNS hacking between you and python.org, as well as something in the Python MSI.
[Tim Peters]
Honestly, for all we _know_, this firewall alert may have been triggered by some other program that just happened to wake up while Bob was installing Python. Sure, that's unlikely. But so is everything else about this ;-)
Unlikely as the firewall alert has the full correct path for *msiexec.exe*. I also keep tabs on all processes running, watch my firewall routinely, etc. And -- I'm almost paranoid enough to be a computer security guy. ;-) Wanted to add this tiny bit of info, but now I need to retire for the night. I'll check further on things in the morning. Bob Hanson
participants (14)
-
"Martin v. Löwis" -
Benjamin Peterson -
Bob Hanson -
Christian Heimes -
Donald Stufft -
Ethan Furman -
Guido van Rossum -
Larry Hastings -
Michael Urman -
Nick Coghlan -
Paul Moore -
R. David Murray -
Stephen J. Turnbull -
Tim Peters