Re: [Python-Dev] [python-committers] Do we need to sign Windows files with GnuPG?
On 04.04.2015 02:49, Donald Stufft wrote: On Apr 3, 2015, at 6:38 PM, M.-A. Lemburg 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. 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. Lemburgmailto:m...@egenix.com Sent: 4/3/2015 10:55 To: Steve Dowermailto:steve.do...@microsoft.com; Larry Hastingsmailto:la...@hastings.org; Python Devmailto:python-dev@python.org; python-committersmailto: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 ? ;-) -- 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
Re: [Python-Dev] Socket timeout: reset timeout at each successful syscall?
On Fri, 3 Apr 2015 13:56:44 +0200 Victor Stinner victor.stin...@gmail.com 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?
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 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. Lemburgmailto:m...@egenix.com Sent: 4/3/2015 10:55 To: Steve Dowermailto:steve.do...@microsoft.com; Larry Hastingsmailto:la...@hastings.org; Python Devmailto: python-dev@python.org; python-committersmailto: 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 ? ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source Python/Zope
Re: [Python-Dev] Socket timeout: reset timeout at each successful syscall?
Le samedi 4 avril 2015, Ludovic Gasc gml...@gmail.com 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?
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 Turnermailto:wes.tur...@gmail.com Sent: 4/4/2015 6:42 To: M. -A. Lemburgmailto:m...@egenix.com Cc: Python-Devmailto:python-dev@python.org; python-committersmailto:python-committ...@python.org; Larry Hastingsmailto:la...@hastings.org; Steve Dowermailto:steve.do...@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 m...@egenix.commailto: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.orghttp://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. Lemburgmailto:m...@egenix.commailto:m...@egenix.com Sent: 4/3/2015 10:55 To: Steve Dowermailto:steve.do...@microsoft.commailto:steve.do...@microsoft.com; Larry Hastingsmailto:la...@hastings.orgmailto:la...@hastings.org; Python Devmailto:python-dev@python.orgmailto:python-dev@python.org; python-committersmailto:python-committ...@python.orgmailto: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
Re: [Python-Dev] [Python-checkins] Daily reference leaks (e10ad4d4d490): sum=333
Anyone know what is causing the deque leakage? On Sat, Apr 4, 2015, 04:48 solip...@pitrou.net 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
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?
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-committers] Do we need to sign Windows files with GnuPG?
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. Lemburgmailto:m...@egenix.com Sent: 4/3/2015 15:38 To: Steve Dowermailto:steve.do...@microsoft.com; Larry Hastingsmailto:la...@hastings.org; Python Devmailto:python-dev@python.org; python-committersmailto:python-committ...@python.org 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. Lemburgmailto:m...@egenix.com Sent: 4/3/2015 10:55 To: Steve Dowermailto:steve.do...@microsoft.com; Larry Hastingsmailto:la...@hastings.org; Python Devmailto:python-dev@python.org; python-committersmailto: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
Re: [Python-Dev] [python-committers] Do we need to sign Windows files with GnuPG?
On Sat, Apr 4, 2015 at 6:07 PM, Steve Dower steve.do...@microsoft.com 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] PEP 487 vs 422 (dynamic class decoration)
On 4 April 2015 at 06:36, PJ Eby p...@telecommunity.com wrote: On Fri, Apr 3, 2015 at 4:21 AM, Nick Coghlan ncogh...@gmail.com 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 Approved status in the PEP
Re: [Python-Dev] [python-committers] Do we need to sign Windows files with GnuPG?
On 4 April 2015 at 11:14, Steve Dower steve.do...@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 rbtcoll...@hp.com 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
Re: [Python-Dev] [python-committers] Do we need to sign Windows files with GnuPG?
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 Warsawmailto:ba...@python.org Sent: 4/4/2015 9:11 To: python-dev@python.orgmailto: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)
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] PEP 487 vs 422 (dynamic class decoration)
On 5 April 2015 at 10:40, Greg Ewing greg.ew...@canterbury.ac.nz 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?
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-checkins] Daily reference leaks (e10ad4d4d490): sum=333
Thanks for fixing it! On Sat, Apr 4, 2015, 10:53 Benjamin Peterson benja...@python.org 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?
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 Dowermailto:steve.do...@microsoft.com Sent: 4/4/2015 7:25 To: Wes Turnermailto:wes.tur...@gmail.com; M. -A. Lemburgmailto:m...@egenix.com Cc: python-committersmailto:python-committ...@python.org; Python-Devmailto:python-dev@python.org 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 Turnermailto:wes.tur...@gmail.com Sent: 4/4/2015 6:42 To: M. -A. Lemburgmailto:m...@egenix.com Cc: Python-Devmailto:python-dev@python.org; python-committersmailto:python-committ...@python.org; Larry Hastingsmailto:la...@hastings.org; Steve Dowermailto:steve.do...@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 m...@egenix.commailto: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.orghttp://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
Re: [Python-Dev] [python-committers] Do we need to sign Windows files with GnuPG?
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 Dowermailto:steve.do...@microsoft.com Sent: 4/4/2015 7:25 To: Wes Turnermailto:wes.tur...@gmail.com; M. -A. Lemburgmailto:m...@egenix.com Cc: python-committersmailto:python-committ...@python.org; Python-Devmailto:python-dev@python.org 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 Turnermailto:wes.tur...@gmail.com Sent: 4/4/2015 6:42 To: M. -A. Lemburgmailto:m...@egenix.com Cc: Python-Devmailto:python-dev@python.org; python-committersmailto:python-committ...@python.org; Larry Hastingsmailto:la...@hastings.org; Steve Dowermailto:steve.do...@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 m...@egenix.commailto: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.orghttp://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
Re: [Python-Dev] PEP 487 vs 422 (dynamic class decoration)
On Fri, Apr 3, 2015 at 6:44 AM, Martin Teichmann lkb.teichm...@gmail.com 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] [python-committers] Do we need to sign Windows files with GnuPG?
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 Dowermailto:steve.do...@microsoft.com Sent: 4/4/2015 7:25 To: Wes Turnermailto:wes.tur...@gmail.com; M. -A. Lemburgmailto:m...@egenix.com Cc: python-committersmailto:python-committ...@python.org; Python-Devmailto:python-dev@python.org 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 Turnermailto:wes.tur...@gmail.com Sent: 4/4/2015 6:42 To: M. -A. Lemburgmailto:m...@egenix.com Cc: Python-Devmailto:python-dev@python.org; python-committersmailto:python-committ...@python.org; Larry Hastingsmailto:la...@hastings.org; Steve Dowermailto:steve.do...@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 m...@egenix.commailto: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.orghttp://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.
Re: [Python-Dev] [python-committers] Do we need to sign Windows files with GnuPG?
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?
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] [python-committers] Do we need to sign Windows files with GnuPG?
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
