Re: [Python-Dev] [python-committers] Do we need to sign Windows files with GnuPG?

[M.-A. Lemburg]

On 04.04.2015 02:49, Donald Stufft wrote:
> 
>> On Apr 3, 2015, at 6:38 PM, M.-A. Lemburg  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's download
>> pages.
> 
> FTR if we’re relying on people to get the GPG keys from the download
> pages then there’s no additional benefit over just using a hash
> published on the same page.

Well, it's still better than just the hashes...

> In order to get additional benefit we’d need to get Steve’s key
> signed by enough people to get him into the strong set.

...but having the key signed by fellow core devs will certainly
add more goodness :-)

>> 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
>>> Sent: ‎4/‎3/‎2015 10:55
>>> To: Steve Dower; Larry 
>>> Hastings; Python 
>>> Dev; 
>>> python-committers
>>> 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 ... 

Re: [Python-Dev] Socket timeout: reset timeout at each successful syscall?

[Antoine Pitrou]

On Fri, 3 Apr 2015 13:56:44 +0200
Victor Stinner  wrote:
> 
> The problem is that the socket.sendall() method may require multiple
> syscalls. In this case, does the timeout count for the total time or
> only for a single syscall? Asked differently: should we reset the
> timeout each time a syscall succeed?

>From a user's point of view, it should count for the total time, IMO.
If people want a timeout for each syscall, they should call send()
iteratively.

Regards

Antoine.


___
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/archive%40mail-archive.com

Re: [Python-Dev] [python-committers] Do we need to sign Windows files with GnuPG?

[Wes Turner]

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"  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'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
> > Sent: ‎4/‎3/‎2015 10:55
> > To: Steve Dower; Larry
> Hastings; Python Dev python-dev@python.org>; python-committers python-committ...@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 ? 

Re: [Python-Dev] Socket timeout: reset timeout at each successful syscall?

[Ludovic Gasc]

On Sat, Apr 4, 2015 at 1:27 PM, Antoine Pitrou  wrote:

> On Fri, 3 Apr 2015 13:56:44 +0200
> Victor Stinner  wrote:
> >
> > The problem is that the socket.sendall() method may require multiple
> > syscalls. In this case, does the timeout count for the total time or
> > only for a single syscall? Asked differently: should we reset the
> > timeout each time a syscall succeed?
>
> From a user's point of view, it should count for the total time, IMO.
> If people want a timeout for each syscall, they should call send()
> iteratively.


I'm agree with Antoine for a global timeout.

When you exchange data with the external world, very often, you can't trust
the other part.
If you reset the timeout each time you send or receive something, the other
part could use this property to send few bytes during a long time to force
you to block for almost nothing during a longer time than with a global
timeout.
It's like an old granny at the checkout of a supermarket who pays coin by
coin, you don't know if only her age or if she purposely be as slow.

It's the same principle with Slowloris attack:
http://ha.ckers.org/slowloris/
BTW, when I've learnt AsyncIO, I've reimplemented Slowloris attack with
AsyncIO in a quick'd'dirty Python script.
The funny thing is that the Python script consumed less CPU and was more
efficient than the original Perl script.
If somebody is interested in, I can send you the script.
--
Ludovic Gasc (GMLudo)
http://www.gmludo.eu/
___
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/archive%40mail-archive.com

Re: [Python-Dev] [python-committers] Do we need to sign Windows files with GnuPG?

[Steve Dower]

"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
Sent: ‎4/‎4/‎2015 6:42
To: M. -A. Lemburg
Cc: Python-Dev; 
python-committers; Larry 
Hastings; Steve 
Dower
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" 
mailto:m...@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'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>
> Sent: ‎4/‎3/‎2015 10:55
> To: Steve 
> Dower>; 
> Larry Hastings>; Python 
> Dev>; 
> python-committers>
> 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 behin

Re: [Python-Dev] [Python-checkins] Daily reference leaks (e10ad4d4d490): sum=333

[Brett Cannon]

Anyone know what is causing the deque leakage?

On Sat, Apr 4, 2015, 04:48   wrote:

> results for e10ad4d4d490 on branch "default"
> 
>
> test_collections leaked [0, -4, 0] references, sum=-4
> test_collections leaked [0, -2, 0] memory blocks, sum=-2
> test_deque leaked [91, 91, 91] references, sum=273
> test_deque leaked [21, 21, 21] memory blocks, sum=63
> test_functools leaked [0, 0, 3] memory blocks, sum=3
>
>
> Command line was: ['./python', '-m', 'test.regrtest', '-uall', '-R',
> '3:3:/home/psf-users/antoine/refleaks/reflogK5OSop', '--timeout', '7200']
> ___
> Python-checkins mailing list
> python-check...@python.org
> https://mail.python.org/mailman/listinfo/python-checkins
>
___
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/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] Daily reference leaks (e10ad4d4d490): sum=333

[Benjamin Peterson]

On Sat, Apr 4, 2015, at 10:33, Brett Cannon wrote:
> Anyone know what is causing the deque leakage?

https://hg.python.org/cpython/rev/3409f4d945e8
___
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/archive%40mail-archive.com

Re: [Python-Dev] [python-committers] Do we need to sign Windows files with GnuPG?

[Steve Dower]

"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"

This is the point of this discussion. I'm willing to make such a break because 
I believe Authenticode is so much more convenient for end users that it isn't 
worth producing GPG signatures. So far, the responses seem to be:

"I'd use them on Windows" x1
"I'd consider using them on another OS" x2-3
"Please don't change" everyone else

At least that's the impression I'm getting, so I hope that helps clarify why 
I'm still not convinced it's that critical.

Cheers,
Steve

Top-posted from my Windows Phone

From: M.-A. Lemburg
Sent: ‎4/‎3/‎2015 15:38
To: Steve Dower; Larry 
Hastings; Python Dev; 
python-committers
Subject: Re: [python-committers] [Python-Dev] Do we need to sign Windows files 
with GnuPG?

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'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
> Sent: ‎4/‎3/‎2015 10:55
> To: Steve Dower; Larry 
> Hastings; Python 
> Dev; 
> python-committers
> 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
> n

Re: [Python-Dev] Socket timeout: reset timeout at each successful syscall?

[Victor Stinner]

Le samedi 4 avril 2015, Ludovic Gasc  a écrit :
>
> From a user's point of view, it should count for the total time, IMO.
>> If people want a timeout for each syscall, they should call send()
>> iteratively.
>
>
> I'm agree with Antoine for a global timeout.
>

 Ok, I also agree. I will modify sendall in Python 3.5 and suggest to loop
on send to keep the same behaviour on timeout.

I don't want to change python 3.4 or 2.7, it would be strange to have a
different behaviour in a minor python version.

Victor
___
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/archive%40mail-archive.com

Re: [Python-Dev] [python-committers] Do we need to sign Windows files with GnuPG?

[Barry Warsaw]

On Apr 04, 2015, at 02:41 PM, Steve Dower wrote:

>"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"

It's the "only" part I have a question about.

Does the use of Authenticode preclude detached GPG signatures of the exe file?
I can't see how it would, but maybe there's something (well, a lot of
somethings ;) I don't know about Windows.

If not, then what's the problem with also providing a GPG signature?

Cheers,
-Barry
___
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/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] Daily reference leaks (e10ad4d4d490): sum=333

[Brett Cannon]

Thanks for fixing it!

On Sat, Apr 4, 2015, 10:53 Benjamin Peterson  wrote:

>
>
> On Sat, Apr 4, 2015, at 10:33, Brett Cannon wrote:
> > Anyone know what is causing the deque leakage?
>
> https://hg.python.org/cpython/rev/3409f4d945e8
> ___
> 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/
> brett%40python.org
>
___
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/archive%40mail-archive.com

Re: [Python-Dev] [python-committers] Do we need to sign Windows files with GnuPG?

[M.-A. Lemburg]

On 04.04.2015 16:41, Steve Dower wrote:
> "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"
> 
> This is the point of this discussion. I'm willing to make such a break 
> because I believe Authenticode is so much more convenient for end users that 
> it isn't worth producing GPG signatures. So far, the responses seem to be:
> 
> "I'd use them on Windows" x1
> "I'd consider using them on another OS" x2-3
> "Please don't change" everyone else
> 
> At least that's the impression I'm getting, so I hope that helps clarify why 
> I'm still not convinced it's that critical.

Just to clarify:

I have absolutely nothing against using Authenticode on Windows :-)

I'm only trying to convince you that *additionally* providing GPG
sigs for Windows downloads is a good thing and we should not stop
doing this, since it makes verification of downloaded files
easier. It's not hard to do, can be automated and provides additional
security which can be verified on any platform, not only Windows.

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/
___
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/archive%40mail-archive.com

Re: [Python-Dev] [python-committers] Do we need to sign Windows files with GnuPG?

[Steve Dower]

Small clarification: there certificates *are* the same format as for SSL, and 
OpenSSL it's able to validate them in the same way as well as generate them 
(but not extract embedded ones, AFAICT). But generally SSL certificates are not 
marked as suitable for code signing so you need to buy a separate one.

Both Martin and I have the PSF's code signing cert private key, which is how we 
can sign with the "Python Software Foundation" name. The public key is embedded 
into every signed file, just like an SSL cert is attached to a site or an 
S/MIME cert is embedded in a signed email.

Cheers,
Steve

Top-posted from my Windows Phone

From: Steve Dower
Sent: ‎4/‎4/‎2015 7:25
To: Wes Turner; M. -A. 
Lemburg
Cc: python-committers; 
Python-Dev
Subject: Re: [python-committers] [Python-Dev] Do we need to sign Windows files 
with GnuPG?

"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
Sent: ‎4/‎4/‎2015 6:42
To: M. -A. Lemburg
Cc: Python-Dev; 
python-committers; Larry 
Hastings; Steve 
Dower
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" 
mailto:m...@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'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 o

Re: [Python-Dev] [python-committers] Do we need to sign Windows files with GnuPG?

[Kurt B. Kaiser]

For the record, that is a Symantec/Verisign code signing certificate. We
paid $1123 for it last April.  It expires April 2017.

If you don't switch to a different vendor, e.g. startssl, please contact
me for renewal in 2017.

KBK

On Sat, Apr 4, 2015, at 10:35 AM, Steve Dower wrote:
> Small clarification: there certificates *are* the same format as for SSL,
> and OpenSSL it's able to validate them in the same way as well as
> generate them (but not extract embedded ones, AFAICT). But generally SSL
> certificates are not marked as suitable for code signing so you need to
> buy a separate one.
> 
> Both Martin and I have the PSF's code signing cert private key, which is
> how we can sign with the "Python Software Foundation" name. The public
> key is embedded into every signed file, just like an SSL cert is attached
> to a site or an S/MIME cert is embedded in a signed email.
> 
> Cheers,
> Steve
> 
> Top-posted from my Windows Phone
> 
> From: Steve Dower
> Sent: ‎4/‎4/‎2015 7:25
> To: Wes Turner; M. -A.
> Lemburg
> Cc: python-committers;
> Python-Dev
> Subject: Re: [python-committers] [Python-Dev] Do we need to sign Windows
> files with GnuPG?
> 
> "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
> Sent: ‎4/‎4/‎2015 6:42
> To: M. -A. Lemburg
> Cc: Python-Dev;
> python-committers; Larry
> Hastings; Steve
> Dower
> 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"
> mailto:m...@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'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 avai

Re: [Python-Dev] [python-committers] Do we need to sign Windows files with GnuPG?

[M.-A. Lemburg]

On 04.04.2015 21:02, Kurt B. Kaiser wrote:
> For the record, that is a Symantec/Verisign code signing certificate. We
> paid $1123 for it last April.  It expires April 2017.
> 
> If you don't switch to a different vendor, e.g. startssl, please contact
> me for renewal in 2017.

FWIW: The PSF mostly uses StartSSL nowadays and they also support
code signing certificates. Given that this option is a lot cheaper
than Verisign, I think we should switch, unless there are
significant reasons not to. We should revisit this in 2017.

> KBK
> 
> On Sat, Apr 4, 2015, at 10:35 AM, Steve Dower wrote:
>> Small clarification: there certificates *are* the same format as for SSL,
>> and OpenSSL it's able to validate them in the same way as well as
>> generate them (but not extract embedded ones, AFAICT). But generally SSL
>> certificates are not marked as suitable for code signing so you need to
>> buy a separate one.
>>
>> Both Martin and I have the PSF's code signing cert private key, which is
>> how we can sign with the "Python Software Foundation" name. The public
>> key is embedded into every signed file, just like an SSL cert is attached
>> to a site or an S/MIME cert is embedded in a signed email.
>>
>> Cheers,
>> Steve
>>
>> Top-posted from my Windows Phone
>> 
>> From: Steve Dower
>> Sent: ‎4/‎4/‎2015 7:25
>> To: Wes Turner; M. -A.
>> Lemburg
>> Cc: python-committers;
>> Python-Dev
>> Subject: Re: [python-committers] [Python-Dev] Do we need to sign Windows
>> files with GnuPG?
>>
>> "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
>> Sent: ‎4/‎4/‎2015 6:42
>> To: M. -A. Lemburg
>> Cc: Python-Dev;
>> python-committers; Larry
>> Hastings; Steve
>> Dower
>> 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"
>> mailto:m...@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 k

Re: [Python-Dev] [python-committers] Do we need to sign Windows files with GnuPG?

[Kurt B. Kaiser]

On Sat, Apr 4, 2015, at 03:35 PM, M.-A. Lemburg wrote:
> On 04.04.2015 21:02, Kurt B. Kaiser wrote:
> > For the record, that is a Symantec/Verisign code signing
> > certificate. We paid $1123 for it last April.  It expires
> > April 2017.
> >
> > If you don't switch to a different vendor, e.g. startssl, please
> > contact me for renewal in 2017.
>
> FWIW: The PSF mostly uses StartSSL nowadays and they also support code
> signing certificates. Given that this option is a lot cheaper than
> Verisign, I think we should switch, unless there are significant
> reasons not to. We should revisit this in 2017.

Agree - apparently the starlssl process for getting a signing cert is
complex/obscure, so we should start early.

Let me know if I can help providing PSF organization verification.

KBK
___
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/archive%40mail-archive.com

Re: [Python-Dev] [python-committers] Do we need to sign Windows files with GnuPG?

[M.-A. Lemburg]

On 04.04.2015 21:49, Kurt B. Kaiser wrote:
> 
> 
> On Sat, Apr 4, 2015, at 03:35 PM, M.-A. Lemburg wrote:
>> On 04.04.2015 21:02, Kurt B. Kaiser wrote:
>>> For the record, that is a Symantec/Verisign code signing
>>> certificate. We paid $1123 for it last April.  It expires
>>> April 2017.
>>>
>>> If you don't switch to a different vendor, e.g. startssl, please
>>> contact me for renewal in 2017.
>>
>> FWIW: The PSF mostly uses StartSSL nowadays and they also support code
>> signing certificates. Given that this option is a lot cheaper than
>> Verisign, I think we should switch, unless there are significant
>> reasons not to. We should revisit this in 2017.
> 
> Agree - apparently the starlssl process for getting a signing cert is
> complex/obscure, so we should start early.

Not really. Once you have the org verification it's really easy.

> Let me know if I can help providing PSF organization verification.

I already completed that for the current cycle.

-- 
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@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [python-committers] Do we need to sign Windows files with GnuPG?

[Kurt B. Kaiser]

On Sat, Apr 4, 2015, at 03:54 PM, M.-A. Lemburg wrote:
> On 04.04.2015 21:49, Kurt B. Kaiser wrote:
> > 
> > 
> > On Sat, Apr 4, 2015, at 03:35 PM, M.-A. Lemburg wrote:
> >> On 04.04.2015 21:02, Kurt B. Kaiser wrote:
> >>> For the record, that is a Symantec/Verisign code signing
> >>> certificate. We paid $1123 for it last April.  It expires
> >>> April 2017.
> >>>
> >>> If you don't switch to a different vendor, e.g. startssl, please
> >>> contact me for renewal in 2017.
> >>
> >> FWIW: The PSF mostly uses StartSSL nowadays and they also support code
> >> signing certificates. Given that this option is a lot cheaper than
> >> Verisign, I think we should switch, unless there are significant
> >> reasons not to. We should revisit this in 2017.
> > 
> > Agree - apparently the starlssl process for getting a signing cert is
> > complex/obscure, so we should start early.
> 
> Not really. Once you have the org verification it's really easy.
> 
> > Let me know if I can help providing PSF organization verification.
> 
> I already completed that for the current cycle.

One can hope.  We shall see :-)

KBK
___
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/archive%40mail-archive.com

Re: [Python-Dev] PEP 487 vs 422 (dynamic class decoration)

[Eric Snow]

On Fri, Apr 3, 2015 at 6:44 AM, Martin Teichmann
 wrote:
>> When I first wrote PEP 422 I was of the view that "Python 2 allows
>> class definition postprocessing injection, we should allow it in
>> Python 3 as well". I've since changed my view to "Having to declare
>> post-processing of a class definition up front as a decorator, base
>> class or metaclass is a good thing for readability, as otherwise
>> there's nothing obvious when reading a class definition that tells you
>> whether or not postprocessing may happen, so you have to assume its
>> possible for *every* class definition".
>
> Nick, I couldn't agree more with you, yet I think PJ actually brought
> up a very interesting point. Post-processing is a very common thing
> these days, and has been re-written so many times that I think it is
> about time that something like it should be in the standard library.
>
> I'm less thinking about decorated methods, more about descriptors.
> They always have the problem that they don't know which attribute they
> belong to, so every author of a framework that defines descriptors
> writes a metaclass which goes through all the descriptors and tells
> them their attribute name.
>
> I propose to have some metaclass in the standard library that does
> that. I think it would fit nicely in my metaclass module proposed in
> PEP 487.
>
> It would basically do the following:
>
> class Metaclass(type):
> def __init__(self, name, bases, dict):
> super().__init__(name, bases, dict)
> for k, v in dict.items():
> if hasattr(v, "__post_process__"):
> v.__post_process__(k, self)
>
> So each descriptor could define a __post_process__ hook that tells
> it the attribute name and also the class it belongs to. This would for
> sure also work for decorated methods.
>
> This should mature on PyPI, then introduced into the standard library,
> and if demand is really that high, maybe even be introduced into
> type.__init__. It should be noted that this can also be easily written
> as a PEP 487 class using __subclass_init__, I just used the classical
> metaclass notion as I guess people are more used to that.
>
> This proposal can actually be seen as an extension to the __class__
> and super() mechanism of normal methods: methods currently have the
> priviledge to know which classes they are defined in, while descriptors
> don't. So we could unify all this by giving functions a __post_process__
> method which sets the __class__ in the function body. This is about the
> same as what happened when functions got a __get__ method to turn
> them into object methods.

I've felt for a long time that it would be helpful in some situations
to have a reverse descriptor protocol.  What you are describing it a
strict subset of that concept (which is fine).  It may be worth
considering a method name that would also be used for that more
generic reverse descriptor, rather than having 2 names for the same
thing.  Even if such a protocol never materializes, the name borrowed
here would still be informative.

-eric
___
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/archive%40mail-archive.com

Re: [Python-Dev] PEP 487 vs 422 (dynamic class decoration)

[Greg Ewing]

Eric Snow wrote:

I've felt for a long time that it would be helpful in some situations
to have a reverse descriptor protocol.


Can you elaborate on what you mean by that?

--
Greg
___
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/archive%40mail-archive.com

Re: [Python-Dev] [python-committers] Do we need to sign Windows files with GnuPG?

[Steve Dower]

There's no problem, per se, but initially it was less trouble to use the 
trusted PSF certificate and native support than to add an extra step using a 
program I don't already use and trust, am restricted in use by my employer 
(because of the license and the fact there are alternatives), and developing 
the trust in a brand new certificate.

Eventually the people saying "do it" will win through sheer persistence, since 
I'll get sick of trying to get a more detailed response and just concede. Not 
sure if that's how we want to be running the project though...

Top-posted from my Windows Phone

From: Barry Warsaw
Sent: ‎4/‎4/‎2015 9:11
To: python-dev@python.org
Subject: Re: [Python-Dev] [python-committers] Do we need to sign Windows files 
with GnuPG?

On Apr 04, 2015, at 02:41 PM, Steve Dower wrote:

>"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"

It's the "only" part I have a question about.

Does the use of Authenticode preclude detached GPG signatures of the exe file?
I can't see how it would, but maybe there's something (well, a lot of
somethings ;) I don't know about Windows.

If not, then what's the problem with also providing a GPG signature?

Cheers,
-Barry
___
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/steve.dower%40microsoft.com
___
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/archive%40mail-archive.com

Re: [Python-Dev] PEP 487 vs 422 (dynamic class decoration)

[Nick Coghlan]

On 4 April 2015 at 06:36, PJ Eby  wrote:
> On Fri, Apr 3, 2015 at 4:21 AM, Nick Coghlan  wrote:
>> No, you can't do it currently without risking a backwards
>> incompatibility through the introduction of a custom metaclass.
>
> Right...  which is precisely why I'm suggesting  the `noconflict()`
> metaclass factory function as a *general* solution for providing
> useful metaclasses, and why I think that PEP 487 should break the
> namespacing and subclass init features into separate metaclasses, and
> add that noconflict feature.  It will then become a good example for
> people moving forward writing metaclasses.
>
> Basically, as long as you don't have the pointless conflict errors,
> you can write co-operative metaclass mixins as easily as you can write
> regular co-operative mixins.  I was missing this point myself because
> I've been too steeped in Python 2's complexities: writing a usable
> version of `noconflict()` is a lot more complex and its invocation far
> more obscure.  In Python 2, there's classic classes, class- and
> module-level __metaclass__, ExtensionClass, and all sorts of other
> headaches for automatic mixing.  In Python 3, though, all that stuff
> goes out the window, and even my 90-line version that's almost half
> comments is probably still overengineered compared to what's actually
> needed to do the mixing.

D'oh, I had the same problem you did - I'd been assuming this was
entirely infeasible because of all the complexities it involved back
in Python 2, and had never adequately reconsidered the question in a
PEP 3115 based world :(

So actually reading https://gist.github.com/pjeby/75ca26f8d2a7a0c68e30
properly, you're starting to convince me that a "noconflict" metaclass
resolver would be a valuable and viable addition to the Python 3 type
system machinery.

The future possible language level enhancement would then be to make
that automatic resolution of metaclass conflicts part of the *default*
metaclass determination process. I realise you've been trying to
explain that to me for a few days now, I'm just writing it out
explicitly to make it clear I finally get it :)

>> Given my change of heart, I believe that at this point, if you were
>> willing to champion a revived PEP 422 that implemented the behaviour
>> you're after, that would be ideal, with monkeypatching the desired
>> behaviour in as a fallback plan if the PEP is still ultimately
>> rejected. Alternatively, you could go the monkeypatching path first,
>> and then potentially seek standardisation later after you've had some
>> practical experience with it - I now consider it an orthogonal
>> capability to the feature in PEP 487, so the acceptance of the latter
>> wouldn't necessarily preclude acceptance of a hook for class
>> postprocessing injection.
>
> A lot of things have changed since the original discussion, mostly in
> the direction of me having even *less* time for Python work than
> previously, so it's unlikely that me championing a PEP is a realistic
> possibility.  Frankly, I'm immensely fatigued at the discussion
> *already*, and the need to go over the same questions a *third* time
> seems like not something I'm going to want to put energy into.

Heh, one of the main reasons PEP 422 ended up languishing for so long
is that I started putting more time into other projects (PyPA, the
PSF, the import system, Python 3 advocacy, etc), so with both you & me
occupied elsewhere, we didn't really have anyone driving the
discussion forward on the metaclass machinery side of things. Martin's
very pertinent challenges to some of the unnecessary design complexity
in PEP 422 has noticeably changed that dynamic for the better :)

> However it sounds like there *is* some growing consensus towards the
> idea of simply notifying interested class members of their class
> membership, so if there ends up being a consensus to standardize
> *that* protocol and what part of the class-building process it gets
> invoked in, then I will implement a backport (or use such a backport
> if someone else implements it), when I actually start porting my
> libraries to Python 3.  But that would make my timeline somewhat
> dependent on how much of a consensus there is, and how much clarity I
> could get before going forward.

In a separate RFE, Martin convinced me that we really want to kick as
much of this off from type.__init__ as we can, and that the problem
with zero-argument super() currently not working when called from
metaclass __init__ methods should be treated as a bug in the way
zero-argument super() is currently implemented.

That position makes a lot of sense to me (especially since it was
backed up with a patch to fix the bug using a modifed implementation
that's inspired by the way that setting __qualname__ works), and is
what makes it possible to assume we can just use the metaclass system
to deal with this, rather than having to rely on modifications to
__build_class__.

> Even if PEP 422 never was officially tagged with "Appro

Re: [Python-Dev] PEP 487 vs 422 (dynamic class decoration)

[Nick Coghlan]

On 5 April 2015 at 10:40, Greg Ewing  wrote:
> Eric Snow wrote:
>>
>> I've felt for a long time that it would be helpful in some situations
>> to have a reverse descriptor protocol.
>
>
> Can you elaborate on what you mean by that?

My guess from the name and the context: having a way to notify
descriptor objects when they're added to or removed from a class.

That is, the current descriptor protocol works as follows:

1. Descriptor *instances* are stored on *class* objects
2. Descriptor *instance methods* are invoked to control class
*instance* attribute access & modification
3. Descriptors play no role in *class* attribute access &
modification, you have to put descriptors on a metaclass for that

A "reverse descriptor" protocol would be aimed at addressing point 3
without needing a custom metaclass. For example, suppose we took
Martin's "__post_process__" idea, and instead changed it to:

def __addclassattr__(self, cls, attr):
"Notifies the descriptor of a new reference from a class attribute"
...

def __delclassattr__(self, cls, attr):
"Notifies the descriptor of the removal of a reference from a
class attribute"
   ...

If a descriptor had an "__addclassattr__" defined, then not only would
type.__init__ call it during type creation, but so would class
attribute assignment (on the descriptor being assigned, not on one
that is already present). Class attribute *deletion* would call
"descr.__delclassattr__(cls, attr)" on the current descriptor value,
and "__delclassattr__" would also be called on the *current* attribute
descriptor when a class attribute is set to something different. Class
attribute retrieval would remain unaffected, and just return the
descriptor object as it does now.

It would be up to the descriptor implementor to decide how to handle
"__addclassattr__" being called multiple times on the same descriptor
instance (e.g. you might allow it for aliasing purposes within a
single class, but throw an exception if you try to register the same
instance with a second class without removing it from the old one
first).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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/archive%40mail-archive.com

Re: [Python-Dev] [python-committers] Do we need to sign Windows files with GnuPG?

[Nathaniel Smith]

On Sat, Apr 4, 2015 at 6:07 PM, Steve Dower  wrote:
> There's no problem, per se, but initially it was less trouble to use the
> trusted PSF certificate and native support than to add an extra step using a
> program I don't already use and trust, am restricted in use by my employer
> (because of the license and the fact there are alternatives), and developing
> the trust in a brand new certificate.
>
> Eventually the people saying "do it" will win through sheer persistence,
> since I'll get sick of trying to get a more detailed response and just
> concede. Not sure if that's how we want to be running the project though...

I don't get the impression that there's any particularly detailed
rationale that people aren't giving you; it's just that to the average
python-dev denizen, gpg-signing seems to provide some mild benefits
and with no downside. The certificate trust issue isn't a downside,
just a mild dilution of the upside. And I suspect python-dev generally
doesn't put much weight on the extra effort required (release managers
have all been using gpg for decades, it's pretty trivial), or see any
reason why Microsoft's internal GPL-hate should have any effect on the
PSF's behaviour. Though it's kinda inconvenient for you, obviously. (I
guess you could call Larry or someone, read them a hash over the
phone, and then have them create the actual gpg signatures.)

-n
___
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/archive%40mail-archive.com

Re: [Python-Dev] [python-committers] Do we need to sign Windows files with GnuPG?

[Robert Collins]

On 4 April 2015 at 11: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.

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 
Distinguished Technologist
HP Converged Cloud
___
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/archive%40mail-archive.com