On behalf of the Python development community and the Python 3.5 release
team, I'm thrilled to announce the availability of Python 3.5.0a4.
Python 3.5.0a4 is the fourth and alpha release of Python 3.5, which will
be the next major release of Python. Python 3.5 is still under
development, and is not yet complete.
This is a preview release, and its use is not recommended for production
settings.
The next release of Python 3.5 will be 3.5.0b1, the first beta release.
Python 3.5 will enter "feature freeze" at this time; no new features
will be added to 3.5 after this point. Python 3.5.0b1 is scheduled to
be released May 22, 2015.
Three important notes for Windows users about Python 3.5.0a4:
* If you have previously installed Python 3.5.0a1, you may need to
manually uninstall it before installing Python 3.5.0a4 (issue23612).
* If installing Python 3.5.0a4 as a non-privileged user, you may need
to escalate to administrator privileges to install an update to your
C runtime libraries.
* There is now a third type of Windows installer for Python 3.5. In
addition to the conventional installer and the web-based installer,
Python 3.5 now has an embeddable installer designed to be run as
part of a larger application's installer for apps using or extending
Python.
You can find Python 3.5.0a4 here:
https://www.python.org/downloads/release/python-350a4/
Happy hacking,
//arry/
"Authenticode does not have a PKI"
If you got that from this discussion, I need everyone to at least skim read this: https://msdn.microsoft.com/en-us/library/ie/ms537361(v=vs.85).aspx
Authenticode uses the same certificate infrastructure as SSL (note: not the same certificates). As I see it, anyone running on Windows has access to verification that is at least as good as GPG, and the only people who would benefit from GPG sigs are those checking Windows files on another OS or those with an existing GPG workflow on Windows (before this thread, I knew nobody who used GPG on Windows for anything, so forgive me for thinking this is very rare).
Cheers,
Steve
Top-posted from my Windows Phone
________________________________
From: Wes Turner<mailto:wes.turner@gmail.com>
Sent: 4/4/2015 6:42
To: M. -A. Lemburg<mailto:mal@egenix.com>
Cc: Python-Dev<mailto:python-dev@python.org>; python-committers<mailto:python-committers@python.org>; Larry Hastings<mailto:larry@hastings.org>; Steve Dower<mailto:Steve.Dower@microsoft.com>
Subject: Re: [Python-Dev] [python-committers] Do we need to sign Windows files with GnuPG?
So, AFAIU from this discussion:
* Authenticode does not have a PKI
* GPG does have PKI
* ASC signatures are signed checksums
As far as downstream packaging on Windows (people who should/could be subscribed to release ANNs):
For Choclatey NuGet:
* https://chocolatey.org/packages/python
* https://chocolatey.org/packages/python.x86
* https://chocolatey.org/packages/python2
* https://chocolatey.org/packages/python-x86_32
* https://chocolatey.org/packages/python3
Python(x,y):
* https://code.google.com/p/pythonxy/
For Anaconda (the MS Azure chosen python distribution):
* http://docs.continuum.io/anaconda/install.html#windows-install
...
These should/could/are checking GPG signatures for Windows packages downstream.
http://www.scipy.org/install.html
On Apr 3, 2015 5:38 PM, "M.-A. Lemburg" <mal(a)egenix.com<mailto:mal@egenix.com>> wrote:
On 04.04.2015 00:14, Steve Dower wrote:
> The thing is, that's exactly the same goodness as Authenticode gives, except everyone gets that for free and meanwhile you're the only one who has admitted to using GPG on Windows :)
>
> Basically, what I want to hear is that GPG sigs provide significantly better protection than hashes (and I can provide better than MD5 for all files if it's useful), taking into consideration that (I assume) I'd have to obtain a signing key for GPG and unless there's a CA involved like there is for Authenticode, there's no existing trust in that key.
Hashes only provide checks against file corruption (and then
only if you can trust the hash values). GPG provides all the
benefits of public key encryption on arbitrary files (not just
code).
The main benefit in case of downloadable installers is to
be able to make sure that the files are authentic, meaning that
they were created and signed by the people listed as packagers.
There is no CA infrastructure involved as for SSL certificates
or Authenticode, but it's easy to get the keys from key servers
given the key signatures available from python.org<http://python.org>'s download
pages.
If you want to sign a package file using GPG, you will need
to create your own key, upload it to the key servers and then
place the signature up on the download page.
Relying only on Authenticode for Windows installers would
result in a break in technology w/r to the downloads we
make available for Python, since all other files are (usually)
GPG signed:
https://www.python.org/ftp/python/3.4.3/
Cheers,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try our new mxODBC.Connect Python Database Interface for free ! ::::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
http://www.egenix.com/company/contact/
> Cheers,
> Steve
>
> Top-posted from my Windows Phone
> ________________________________
> From: M.-A. Lemburg<mailto:mal@egenix.com<mailto:mal@egenix.com>>
> Sent: 4/3/2015 10:55
> To: Steve Dower<mailto:Steve.Dower@microsoft.com<mailto:Steve.Dower@microsoft.com>>; Larry Hastings<mailto:larry@hastings.org<mailto:larry@hastings.org>>; Python Dev<mailto:python-dev@python.org<mailto:python-dev@python.org>>; python-committers<mailto:python-committers@python.org<mailto:python-committers@python.org>>
> Subject: Re: [python-committers] [Python-Dev] Do we need to sign Windows files with GnuPG?
>
> On 03.04.2015 19:35, Steve Dower wrote:
>>> My Windows development days are firmly behind me. So I don't really have an
>>> opinion here. So I put it to you, Windows Python developers: do you care about
>>> GnuPG signatures on Windows-specific files? Or do you not care?
>>
>> The later replies seem to suggest that they are general goodness that nobody on Windows will use. If someone convinces me (or steamrolls me, that's fine too) that the goodness of GPG is better than a hash then I'll look into adding it into the process. Otherwise I'll happily add hash generation into the upload process (which I'm going to do anyway for the ones displayed on the download page).
>
> FWIW: I regularly check the GPG sigs on all important downloaded
> files, regardless of which platform they target, including the
> Windows installers for Python or any other Windows installers
> I use which provide such sigs.
>
> The reason is simple:
> The signature is a proof of authenticity which is not bound to
> a particular file format or platform and before running .exes
> it's good to know that they were built by the right people and
> not manipulated by trojans, viruses or malicious proxies.
>
> Is that a good enough reason to continue providing the GPG
> sigs or do you need more proof of goodness ? ;-)
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source
>>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
> ________________________________________________________________________
>
> ::: Try our new mxODBC.Connect Python Database Interface for free ! ::::
>
>
> eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
> D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
> Registered at Amtsgericht Duesseldorf: HRB 46611
> http://www.egenix.com/company/contact/
>
_______________________________________________
Python-Dev mailing list
Python-Dev(a)python.org<mailto:Python-Dev@python.org>
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/wes.turner%40gmail.com
"One question, if you will - I don't think this was asked so far - is
authenticode verifiable from Linux, without Windows? And does it work
for users of WINE ?"
I've seen some info suggesting that it's verifiable, but you do need to extract the cert and calculate the hash against less than the signed file. Seemed like Mono had a tool for it, but OpenSSL can handle the cert.
Currently the new installer doesn't run on Wine because of missing APIs (since I want to discuss alternate distribution ideas I haven't treated this as a priority), and I've heard they haven't implemented enough crypto yet to handle it, but that could be outdated.
"GPG sigs will provide protection against replay attacks"
How does this work?
Cheers,
Steve
Top-posted from my Windows Phone
________________________________
From: Robert Collins<mailto:robertc@robertcollins.net>
Sent: 4/4/2015 21:59
To: Steve Dower<mailto:Steve.Dower@microsoft.com>
Cc: M.-A. Lemburg<mailto:mal@egenix.com>; Larry Hastings<mailto:larry@hastings.org>; Python Dev<mailto:python-dev@python.org>; python-committers<mailto:python-committers@python.org>
Subject: Re: [Python-Dev] [python-committers] Do we need to sign Windows files with GnuPG?
On 4 April 2015 at 11:14, Steve Dower <Steve.Dower(a)microsoft.com> wrote:
> The thing is, that's exactly the same goodness as Authenticode gives, except
> everyone gets that for free and meanwhile you're the only one who has
> admitted to using GPG on Windows :)
>
> Basically, what I want to hear is that GPG sigs provide significantly better
> protection than hashes (and I can provide better than MD5 for all files if
> it's useful), taking into consideration that (I assume) I'd have to obtain a
> signing key for GPG and unless there's a CA involved like there is for
> Authenticode, there's no existing trust in that key.
GPG sigs will provide protection against replay attacks [unless we're
proposing to revoke signatures on old point releases with known
security vulnerabilities - something that Window software vendors tend
not to do because of the dramatic and immediate effect on the deployed
base...]
This is not relevant for things we're hosting on SSL, but is if anyone
is mirroring our installers around. They dont' seem to be so perhaps
its a bit 'meh'.
OTOH I also think there is value in consistency: signing all our
artifacts makes checking back on them later easier, should we need to.
One question, if you will - I don't think this was asked so far - is
authenticode verifiable from Linux, without Windows? And does it work
for users of WINE ?
-Rob
--
Robert Collins <rbtcollins(a)hp.com>
Distinguished Technologist
HP Converged Cloud
As of Python 3.5 Steve Dower has taken over the Windows builds of Python
from Martin van Loewis. He's also taken over for 2.7--though Martin's
still doing builds for 3.4.
For both versions, Steve is using all-new tooling for the build
process. The output is different, too; he's producing .exe installers
instead of .msi installers, and he has snazzy new "web-based" installers
where the initial download is small, then it downloads the rest dynamically.
Steve's also changed the authentication process. His new installers
rely on a Windows digital signature technology called Authenticode where
the signature is built right into the .exe file. Windows platforms will
automatically authenticate executables signed with Authenticode, so this
is both secure and convenient.
Martin's build process also digitally signed the files he built, but not
using Authenticode (or at least I don't think so). Like the Mac and
source code releases, his automation used GnuPG to produce separate
".asc" files containing digital signatures. This meant authentication
was a manual process.
The Authenticode approach sounds great. But there are advantages to the
GnuPG approach too:
* Using GnuPG means we can authenticate the files from any platform,
not just Windows. If there were a security breach on the Python
content delivery network, any developer could get GnuPG for their
platform and authenticate that the installers are unmodified. If we
use Authenitcode,
* GnuPG is agnostic about the data it digitally signs. So, for
example, Martin's build process digitally signs the Windows help
file--the ".chm" file--produced by his build process. The help file
Steve builds is currently completely unsigned; Steve says he can try
signing it but he's not sure it'll work. Note that .chm files
actually /can/ contain live code, so this is at least a plausible
vector for attack.
My Windows development days are firmly behind me. So I don't really
have an opinion here. So I put it to you, Windows Python developers: do
you care about GnuPG signatures on Windows-specific files? Or do you
not care?
//arry/
p.s. And, of course, my thanks to both Steve and Martin for their past
and continuing service to the Python community! It's a pleasure working
with each of them. (Both of them? I forget how English works.)
The implementation for PEP 488 is basically done (sans Windows installer
stuff). I did the work in a features repo at
https://hg.python.org/features/pep-488/ . Once I have addressed reviewer
comments at http://bugs.python.org/issue23731 , would people prefer I
simply push the features repo to hg.python.org/cpython and have the more
granular history but have various "merge default" commits, or would people
rather I do one massive commit?
We'll have the 2.7.10 release in the coming months. This will be the first
release with a two digit subminor version number, so please could we prepare for
that early? Feature tests in python are unfortunately way too often based on
version comparisons. Suggesting to push the following patch to the 2.7 branch.
The patch also changes PY_RELEASE_LEVEL to "beta" quality. Currently this is a
value which is not touched on the branches.
Matthias
diff -r d444496e714a Include/patchlevel.h
--- a/Include/patchlevel.h Wed Apr 01 16:53:53 2015 +0300
+++ b/Include/patchlevel.h Wed Apr 01 20:56:46 2015 +0200
@@ -22,12 +22,12 @@
/*--start constants--*/
#define PY_MAJOR_VERSION 2
#define PY_MINOR_VERSION 7
-#define PY_MICRO_VERSION 9
-#define PY_RELEASE_LEVEL PY_RELEASE_LEVEL_FINAL
+#define PY_MICRO_VERSION 10
+#define PY_RELEASE_LEVEL PY_RELEASE_LEVEL_BETA
#define PY_RELEASE_SERIAL 0
/* Version as a string */
-#define PY_VERSION "2.7.9+"
+#define PY_VERSION "2.7.10-"
/*--end constants--*/
/* Subversion Revision number of this file (not of the repository). Empty
