Steve Dower added the comment:
I don't think that removing the readme.txt from the install constitutes a
breaking change (LICENSE would be a bigger deal), and removing the file from
the installer sounds simpler than updating the readme.
Also, if you choose the 3.6 branch from the GitHub
Changes by Steve Dower :
--
assignee: -> steve.dower
___
Python tracker
<http://bugs.python.org/issue29579>
___
___
Python-bugs-list mailing list
Unsubscrib
Steve Dower added the comment:
You should be able to update whatever package installed that module.
Unfortunately, we can't guess what that would be, but it's probably worthwhile
updating all the packages you have installed.
--
resolution: -> not a bug
stage: ->
Changes by Steve Dower :
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue29503>
___
___
Changes by Steve Dower :
--
pull_requests: +125
___
Python tracker
<http://bugs.python.org/issue29579>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Steve Dower :
--
pull_requests: +126
___
Python tracker
<http://bugs.python.org/issue29579>
___
___
Python-bugs-list mailing list
Unsubscribe:
Steve Dower added the comment:
Pull request is at https://github.com/python/cpython/pull/160 and backport at
https://github.com/python/cpython/pull/161
--
___
Python tracker
<http://bugs.python.org/issue29
Steve Dower added the comment:
New changeset 52a7e92e3d38d3d003552db6795de75db2e4 by GitHub in branch
'master':
bpo-29579: Removes readme.txt from the installer. (#160)
https://github.com/python/cpython/commit/52a7e92e3d38d3d003552db6795dee
Steve Dower added the comment:
New changeset d372cda5cd46712c4e59262ec1ab981773b20bff by GitHub in branch
'3.6':
bpo-29579: Removes readme.txt from the installer. (#161)
https://github.com/python/cpython/commit/d372cda5cd46712c4e59262ec1ab98
Changes by Steve Dower :
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue29579>
___
Steve Dower added the comment:
My guess is that IE is implemented using lower level APIs and it can choose
whether to bypass based on its own list. There's no reason for any other
software to take its settings into account.
That said, it would be great if urllib can avoid adding long d
Steve Dower added the comment:
I approved the two backports. Thanks Vinay!
--
___
Python tracker
<http://bugs.python.org/issue29565>
___
___
Python-bugs-list m
New submission from Steve Dower:
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
Steve Dower added the comment:
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 launch
Changes by Steve Dower :
--
pull_requests: +228
___
Python tracker
<http://bugs.python.org/issue29624>
___
___
Python-bugs-list mailing list
Unsubscribe:
Steve Dower added the comment:
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/R
Changes by Steve Dower :
--
pull_requests: +234
___
Python tracker
<http://bugs.python.org/issue27593>
___
___
Python-bugs-list mailing list
Unsubscribe:
Steve Dower added the comment:
It looks to me like we want:
branch=`git name-rev --name-only HEAD`
revision=`git rev-parse HEAD`
tag=`git name-rev --tags --name-only HEAD`
Unless we're planning on leaving out the tag?
My PR 262 makes the Windows build changes in master, but doesn
Changes by Steve Dower :
--
pull_requests: +235
___
Python tracker
<http://bugs.python.org/issue29624>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Steve Dower :
--
pull_requests: +236
___
Python tracker
<http://bugs.python.org/issue29624>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Steve Dower :
--
versions: +Python 3.6
___
Python tracker
<http://bugs.python.org/issue29191>
___
___
Python-bugs-list mailing list
Unsubscribe:
Steve Dower added the comment:
As far as I recall, there's a hosts file that resolves localhost to 127.0.0.1
on Windows, which means a user could break their own configuration if they so
desired. Definitely on all supported versions we should be able to assume
localhost can be resolve
Steve Dower added the comment:
Why can't we fix this in 3.6? We were meant to support pathlike in that
version, and this is an oversight, not a new feature.
--
___
Python tracker
<http://bugs.python.org/is
Steve Dower added the comment:
Just updated my PR to remove the GITTAG variable, so we'll just go with
GITBRANCH and GITVERSION.
(Any value in trying to extract the URL of the remote? That's probably going to
be a bit flimsy, but might help more clearly iden
Steve Dower added the comment:
Even sys.__stdout__ can be missing. In this context, falling back on the
default encoding is probably fine, but for 3.6 I'd like to make everything
default to UTF-8 on Windows, and force the console mode on startup (restore on
finalize) - apart from the
Steve Dower added the comment:
> There is right encoding, it's encoding that's actually used.
This is true, but it puts the decision entirely in the hands of the
developer(s) of the two processes involved.
All IPC on Windows uses bytes, and encodings _always_ need to be negot
Steve Dower added the comment:
I still want the behavior I described, since there's no value in overriding
just the executable name but not the rest of the path.
For 2.7 I think this'll help with long term maintainability enough to be the
Right Thing. For 3.5 I'm not as
Steve Dower added the comment:
> so ANSI is the natural default for a detached process
To clarify - ANSI is the natural default *for programs that don't support
Unicode*.
Unfortunately, since "Unicode" on Windows is an incompatible data type (wchar_t
rather than char),
Steve Dower added the comment:
The launcher issue is different from the original one posted here, so I'll
create a separate issue to track it.
--
___
Python tracker
<http://bugs.python.org/is
New submission from Steve Dower:
(Originally posted as a comment to issue26631 but confirmed separately.)
For 3.5.2 and 3.6.0a2, I updated the installer for the launcher so that it is
always shared between Python versions (i.e. if you install 3.6 followed by 3.5,
it won't touch the lau
Changes by Steve Dower :
--
nosy: +Steven.Barker
___
Python tracker
<http://bugs.python.org/issue27314>
___
___
Python-bugs-list mailing list
Unsubscribe:
Steve Dower added the comment:
Launcher issue is issue27314
--
___
Python tracker
<http://bugs.python.org/issue26631>
___
___
Python-bugs-list mailing list
Unsub
Steve Dower added the comment:
Okay, it's not an issue with the newer versions, and I don't see any reason to
worry about 3.6.0a1.
One issue that remains is that installing the launcher with 3.6.0 creates a
separate add-remove programs entry and doesn't remove the 3.5.2rc1
Steve Dower added the comment:
It seems to work fine on my build machine (Win Server 2012) but not my laptop
(Win 10 Home). I suspect there's a different certificate being loaded that's
causing the crash, but until I get a chance to debug properly I can't be sure.
Hopefully I&
Steve Dower added the comment:
That should be enough from your side, but let me run a test build before you
tag in case we need to fix anything.
--
___
Python tracker
<http://bugs.python.org/issue26
Steve Dower added the comment:
A build issue like that is fairly likely - I don't touch 2.7 apart from
releases and so all I did was restart my build VM, pull and hit rebuild. There
may be another clean step required when the OpenSSL version changes.
We're getting another update
Steve Dower added the comment:
I went ahead and updated the subprocess call just in _msvccompiler to use cmd
/u, as I like that fix.
Not so keen on doing it for all subprocess(shell=True) calls, since we can't
reliably predict whether the output will actually respect the o
Steve Dower added the comment:
Oh, and before anyone asks, I used "errors='replace'" because we get all the
env variables but don't use most of them. If we do end up needing one that
can't be decoded, this should make it obvious, but there's no point failin
Steve Dower added the comment:
Just made another "release" build from the latest source (with OpenSSL 1.0.2h)
and can no longer repro this issue, so I'm closing it.
If anyone wants to try with the same build, it will be up at
https://ptvs.blob.core.windows.net/temp/python-2.7.1
Steve Dower added the comment:
All looked good to me, and as far as I could see all of Berker's feedback was
addressed, so consider it in!
--
assignee: -> steve.dower
resolution: -> fixed
stage: patch review -> resolved
status:
Steve Dower added the comment:
That'll handle the test fine, though I wonder whether we should try and
conditionally define the constant at runtime?
Probably at least want to add a note to the docs about Win 8 being the minimum,
especially since so many people are still
Steve Dower added the comment:
That's the best function to use.
--
___
Python tracker
<http://bugs.python.org/issue26536>
___
___
Python-bugs-list m
Changes by Steve Dower :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue26930>
___
___
Python-bugs-list mailing list
Unsubscrib
Steve Dower added the comment:
Test build went fine, was validated in another thread.
--
___
Python tracker
<http://bugs.python.org/issue26930>
___
___
Python-bug
Steve Dower added the comment:
If someone wants to make a patch, the manifest we embed is in PC/python.manifest
--
___
Python tracker
<http://bugs.python.org/issue27
Steve Dower added the comment:
> Would it be possible to tie this to _tkinter.pyd instead of python{w}.exe?
Afraid not, Windows needs to load a different version of a particular DLL for
the entire process. But at this stage it shouldn't negatively affect anyone.
I'd even be o
Steve Dower added the comment:
Wow, that sucks.
I just rebuilt it and it's still detected, so presumably somebody distributed
malware as a bdist_exe and it made it into the signature. There haven't been
any unexpected modifications to the sources.
I've submitted the file to t
Steve Dower added the comment:
This was done! Just never closed
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Steve Dower added the comment:
Actually, the correct link is amd64/, but it didn't upload on my second try,
apparently. Or somehow disappeared...
Fixing that now.
--
___
Python tracker
<http://bugs.python.org/is
Steve Dower added the comment:
Should be good now. Thanks for the heads-up!
--
resolution: -> fixed
stage: -> resolved
___
Python tracker
<http://bugs.python.org/i
Steve Dower added the comment:
It can be found at PCbuild/prepare_ssl.py in the default branch.
Copying it into the 2.7 branch wouldn't hurt I guess, and I'm okay with having
build scripts in there that depend on Python 3 ;)
--
___
Pyth
Steve Dower added the comment:
It would need someone to volunteer to port and maintain it. I don't believe any
of the current team want to maintain two different versions of the script,
considering we all use Python 3 and have it available when updating the version
of OpenSSL
Steve Dower added the comment:
FYI the definitions have been updated and I'm no longer seeing the false
positive.
Definition version: 1.223.2858.0
--
___
Python tracker
<http://bugs.python.org/is
Steve Dower added the comment:
Unless you can show that it's loaded after the installer elevates, I'm not
concerned. "User can run arbitrary code as themselves" is not a security
vulnerability. (Hint: when the bundle elevates, it copies the exe to a new
directory and r
New submission from Steve Dower:
I'd like to enable calling CoInitializeEx on Python startup for 3.6 (and into
the future). See
https://msdn.microsoft.com/en-us/library/windows/desktop/ms695279.aspx
This would enable us to use more advanced Windows features within Python that
requir
Steve Dower added the comment:
This now depends on issue27417, since we can't enable AMSI without enabling
COM, and doing that has a number of back-compat implications.
--
dependencies: +Call CoInitializeEx on startup
___
Python tracker
Steve Dower added the comment:
It would enable wrapping up anything from this list too, and more:
https://msdn.microsoft.com/en-us/library/windows/desktop/bb774328(v=vs.85).aspx
Plenty of cool potential features in there :)
--
___
Python tracker
Steve Dower added the comment:
> If it allowed user code to access COM without needing a 3rd party dependency,
> I'd be +1, but I don't think that's being proposed here.
It's a prerequisite to adding features to the stdlib that access COM (whether
or not COM is di
Steve Dower added the comment:
> But do I understand correctly that, if you implement this, there's no way for
> me to select MTA?
MTA would be the default, with no -X argument. But we could support a no-op
"-X:MTA" as well.
Because of the potential for use in security f
Steve Dower added the comment:
I'm also okay to discuss whether MTA or STA should be the default, but I'll
also be seeking advice from work colleagues on this who know COM really well.
--
___
Python tracker
<http://bugs.python.o
Steve Dower added the comment:
> pythoncom and comtypes use the value of sys.coinit_flags when imported
Good to know. Assume we'll add that as well.
Also, with respect to threading, we'd want to initialize on all new threads
too. That will require a way to specify that a new thr
Steve Dower added the comment:
AMSI is intended for local scanners that are entirely on your own machine, so
code never goes anywhere, and everything that passes through the file system is
already scanned because of hooks whether you wrote it or not (maybe you're
thinking of SmartS
Steve Dower added the comment:
Mark:
> CoInitialize will load a number of COM DLLs into the process, which isn't
> free and will have some memory and performance costs for programs that don't
> use COM. I see around 10 such DLLs loaded.
Very good point. Most of those shoul
Steve Dower added the comment:
> So the malicious payload is the whole python command, not just file.bin
Yeah, sorry that wasn't clear. Many vulnerabilities allow attackers to schedule
process launches (e.g. via cron/Task Scheduler/etc.) without actually being
able to add any file
Steve Dower added the comment:
> What about instead of unconditionally calling CoInitializeEx in all cases,
> add a Py_EnsureCOM(flags) C API function?
This is essentially what CoInitializeEx does anyway - if the flags don't match
the existing ones, it returns an error. So all w
Steve Dower added the comment:
> what's to stop the attacker from distributing their own interpreter that just
> doesn't use AMSI?
AppLocker https://technet.microsoft.com/en-us/library/ee619725.aspx
(In short, restrict which executables can be run on a particular system by
Steve Dower added the comment:
And in case it's not clear, I *totally* recognize that AMSI is not for
everyone. If you're running in a developer environment, your security is almost
certainly so lax that it's irrelevant.
However, once you start getting serious about what
Steve Dower added the comment:
The warnings are expected - Python has to be able to handle arbitrarily bad
parameters/use without crashing, while the CRT assumes that bugs belong to the
direct caller who needs to fix them. As a result, it will assert and terminate
for blatantly incorrect
Steve Dower added the comment:
It's not even that the risk is low, it's that we can't actually fix it. There
are zero explicit DLL loads in the installer (either the part we own or the
third-party core) that are insecure, and the four DLLs referenced by the
third-party core
Steve Dower added the comment:
Try removing the handler completely and see what the default behavior is.
Otherwise, I'll do some research and figure out the right one.
--
___
Python tracker
<http://bugs.python.org/is
Steve Dower added the comment:
Okay thanks. I'll see if I can track down the right one on Monday.
--
assignee: -> steve.dower
___
Python tracker
<http://bugs.python.org
Steve Dower added the comment:
Got some digging done today and it looks like we're probably best to write our
own drop handler. It can probably be embedded into the py.exe launcher, which
will keep all the registration in the one file.
At worst, we should switch to {86C86720-42A0-1069
Steve Dower added the comment:
I don't want Python to get into the business of changing the command line.
I've started looking into building the shell extension so we can pass through
arguments correctly. Once we have this, there are likely other features we can
add to it (may
Steve Dower added the comment:
I believe changes to the batch build dialog are local to your machine, so there
won't be any changes to the solution file.
A regular build should include all packages. Can you explain what didn't work
and why you needed
Steve Dower added the comment:
I just checked and the pcbuild.sln you posted is identical to what's currently
checked in.
Batch build settings are not part of the checkin, so if you want to use that
rather than using the build scripts we provide (see PCBuild/build.bat) then
you'
Steve Dower added the comment:
Environment variables shouldn't make any different to the embeddable distro -
it is designed to ignore them. Have you modified it at all?
The path is not as clean as I'd like it to be, but the initialization changes
necessary are too significant for 3
Steve Dower added the comment:
LGTM.
This is the kind of patch I can't wait to have a one-click merge button...
right now it'll have to wait until I have a clean repo. But if anyone else
wants to get it, go ahead.
--
stage: -> patch review
type: -> behavior
versi
Steve Dower added the comment:
Attached my first pass at the shell extension.
As this has the potential to crash Windows Explorer, I want to be _really_
thorough, so all reviews and feedback welcomed.
--
keywords: +patch
Added file: http://bugs.python.org/file43760/27469_1.patch
Steve Dower added the comment:
No, it's not a security fix, so it doesn't go in 2.7.
--
___
Python tracker
<http://bugs.python.org/issue27533>
___
___
Steve Dower added the comment:
Maybe so. If you find a core developer who cares about performance in 2.7,
maybe they'll merge it :)
--
___
Python tracker
<http://bugs.python.org/is
Steve Dower added the comment:
Whoops, that wasn't supposed to slip in. I'll fix :)
--
assignee: -> steve.dower
versions: +Python 3.5
___
Python tracker
<http://bugs.pytho
Changes by Steve Dower :
--
assignee: -> steve.dower
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python
Steve Dower added the comment:
Thanks, I've merged that change into my patch.
I doubt anyone else is going to build and test this, but just in case I'll let
it set for a couple of days before merging. Perhaps someone will at least look
a
Steve Dower added the comment:
Mark's argument is strong, so I'm withdrawing this proposal.
Thanks for the discussion and comments, everyone!
--
resolution: -> rejected
status: open -> closed
___
Python tracker
<http://bugs.py
Steve Dower added the comment:
Giving this to Zach to resolve/close as he feels appropriate.
--
assignee: -> zach.ware
___
Python tracker
<http://bugs.python.org/issu
Steve Dower added the comment:
A custom icon for .pyd files doesn't require a shell extension - it only really
requires the icon.
I don't want to use the same as .pyc, since that has the implication that it
can be deleted safely, or .py, since that can be double-clicked. So
Steve Dower added the comment:
Updated the manifest to include the correct common controls DLL, which ensures
the correct style is used for native dialogs.
I applied this to Python 3.5 and 3.6, since it's not a behavioural change and
should not break any code, and arguably since it'
Steve Dower added the comment:
You should get these files by installing the latest Windows 10 SDK (regardless
of your OS - the SDK version relates to the latest it can target, not the
latest it can be used on).
For some reason, they decided it shouldn't be "automatic" to updat
Steve Dower added the comment:
Sure, added a new patch with all of your suggestions. I also added
pyshellext.vcxproj to pcbuild.sln.
(And my final word on the magic used to load DLLs from memory is that I'm not
willing to maintain that code within CPython itself, so it won't be
Steve Dower added the comment:
Lot of different people involved in those areas, so can't promise an answer,
but I'll see.
Also, unless you think a closed issue needs to be reopened, please avoid using
them for chat.
--
___
Python trac
Steve Dower added the comment:
Or if you first repair 2.7.11 and then install 2.7.12.
This error often happens because your pip installation is corrupt, and then pip
fails to uninstall itself which aborts the whole installation. Generally
repairing the install before uninstalling resolves it
Steve Dower added the comment:
You're compiling Python in a completely unsupported way right now, so I'm
afraid you'll need to submit a patch to get it fixed.
Python 2.7 is only officially supported with VC 9.0 (not VC 14.0), and I don't
believe the other volunteers tes
Steve Dower added the comment:
Unfortunately, you can't do that either. Projects including static libraries
all need to use the same compiler.
So either build python27.dll separately and dynamically link to it (or just use
the one that we build and release, and be careful not to mix up m
Steve Dower added the comment:
You should have another log file for "core_JustForMe" near the one you
uploaded. Could you include that one too?
--
___
Python tracker
<http://bugs.python.o
Steve Dower added the comment:
We're a couple more updates along and it all seems good.
--
resolution: -> out of date
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.pyth
Steve Dower added the comment:
Hmm... very unusual to get this error code without more information about what
failed - the log file is oddly empty.
Do you perhaps need to reboot your machine to finish installing some other
program or update? Do you have an earlier version of Python 3.5
Steve Dower added the comment:
Any chance this is a regression in the "extension module within a package"
issue we saw during 3.5?
There's a pretty relevant difference between:
>>> import nacl._sodium
>>> import _cffi_backend
--
_
Steve Dower added the comment:
That time it looks like it failed to install the launcher for all users. Did
you get an elevation prompt?
--
___
Python tracker
<http://bugs.python.org/issue27
Steve Dower added the comment:
Fixed. This should get out into the wild first with 3.6.0a4, and then 3.5.3[rc1]
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Steve Dower added the comment:
The "Edit in IDLE" submenu we implemented could be moved from a collection of
registry keys into the shell extension, which would also let us detect all
Python installations, as right now we only have 3.5 and later (we could even
filter out thos
4401 - 4500 of 5794 matches
Mail list logo
