[Python-Dev] Web accessible core code search and other devguide questions
Hi again, http://docs.python.org/devguide/faq.html?highlight=search What can I use to browse, search and troubleshoot core Python sources online? Why the question "Where do I find Python core code?" is not the first in the dev. guide? =) There is clearly a lot of stuff on http://hg.python.org/ that requires some guidance. I'd also include some more technical information at the top. And FAQ is very strange. "What standards of behaviour are expected in these communication channels?" - is that really the question people frequently ask? IMHO the question should be "Where can I get help with development?" and the answer include a link to dev.guide chapter on this matter. -- anatoly t. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] return type of __complex__
On 10/21/2012 09:35 PM, Steven D'Aprano wrote: so as far as I can tell, the only way you could accidentally get a complex number without expecting one is by exponentiation, either by ** or the builtin pow. This includes square roots. Exponentiation isn't as common as the basic four arithmetic operators, but it is hardly exotic. Any time you have a non-integer power and a negative base, you will get a complex number. No, only via the builtin pow. % python3 Python 3.3.0 (default, Sep 29 2012, 22:42:55) [GCC 4.6.3] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import math >>> pow(-1, 0.5) (6.123031769111886e-17+1j) >>> -1 ** 0.5 -1.0 >>> math.pow(-1, 0.5) Traceback (most recent call last): File "", line 1, in ValueError: math domain error >>> //arry/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] return type of __complex__
On Mon, Oct 22, 2012 at 7:34 AM, Larry Hastings wrote: -1 ** 0.5 > -1.0 Be careful about order of operations! >>> (-1)**.5 (6.123233995736766e-17+1j) -- Devin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Segmentaion fault with wrongly set PYTHONPATH on Windows
Could anybody reopen http://bugs.python.org/issue8766 ? I can't. Reproducible 100% with Python 3.2 and 3.3 (3.1 didn't test). > set PYTHONHOME=C:\ > python BTW, what is the role of PYTHONPATH on Windows? Is it a path for %INSTALLDIR%\Lib\site-packages? -- anatoly t. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Segmentaion fault with wrongly set PYTHONPATH on Windows
Am 22.10.2012 15:31, schrieb anatoly techtonik: > Could anybody reopen http://bugs.python.org/issue8766 ? I can't. > Reproducible 100% with Python 3.2 and 3.3 (3.1 didn't test). > >> set PYTHONHOME=C:\ >> python The segfault isn't caused by faulty code but by a call to abort() in Py_FatalError(). The interpreter fails with an hard error because it is unable to locate the encodings package. $ PYTHONHOME=/ python3.2 Fatal Python error: Py_Initialize: Unable to get the locale encoding ImportError: No module named encodings Abgebrochen (Speicherabzug geschrieben) $ gdb /usr/bin/python3.2 core [...] (gdb) bt #0 0x7fb05cd37445 in __GI_raise (sig=) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x7fb05cd3abab in __GI_abort () at abort.c:91 #2 0x00482d0e in Py_FatalError () #3 0x00482f14 in initfsencoding () #4 0x00483e56 in Py_InitializeEx () #5 0x00493e1a in Py_Main () #6 0x0041d307 in main () ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Segmentaion fault with wrongly set PYTHONPATH on Windows
You are more likely to get action on bugs by posting to the bug tracker. That said, since 8766 was fixed, your issue is most likely a new one. Please open a new bug report. --David On Mon, 22 Oct 2012 16:31:34 +0300, anatoly techtonik wrote: > Could anybody reopen http://bugs.python.org/issue8766 ? I can't. > Reproducible 100% with Python 3.2 and 3.3 (3.1 didn't test). > > > set PYTHONHOME=C:\ > > python > > BTW, what is the role of PYTHONPATH on Windows? > Is it a path for %INSTALLDIR%\Lib\site-packages? > -- > anatoly t. > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/rdmurray%40bitdance.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Segmentaion fault with wrongly set PYTHONPATH on Windows
2012/10/22 anatoly techtonik : > Could anybody reopen http://bugs.python.org/issue8766 ? I can't. > Reproducible 100% with Python 3.2 and 3.3 (3.1 didn't test). > >> set PYTHONHOME=C:\ >> python The issue #8766 is about PYTHONPATH environment variable, not PYTHONHOME. Test on Linux with Python 3.4: $ PYTHONHOME=/x ./python Fatal Python error: Py_Initialize: Unable to get the locale encoding ImportError: No module named 'encodings' Abandon (core dumped) It's not a segfault, but an "abort". It's different: abort() is called by the application (Python) when something goes wrong. In this case, Python is unable to locate the standard library. It's not a bug: I asked Python to look in /x directory, whereas this directory doesn't exist. > BTW, what is the role of PYTHONPATH on Windows? > Is it a path for %INSTALLDIR%\Lib\site-packages? Same role than PYTHONPATH on Linux: specify where third party modules are installed. Victor ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Segmentaion fault with wrongly set PYTHONPATH on Windows
On Mon, Oct 22, 2012 at 04:31:34PM +0300, anatoly techtonik wrote: > Could anybody reopen http://bugs.python.org/issue8766 ? I can't. Even if you add a comment? > BTW, what is the role of PYTHONPATH on Windows? The same as on Unix -- it's inserted into (but not replaced) sys.path. And nothing else. Oleg. -- Oleg Broytmanhttp://phdru.name/[email protected] Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Build the _sha3 module with VS 2008.
Am 21.10.12 21:52, schrieb Christian Heimes: Ultimately it's your decision. You are the expert and build master for Windows releases. I've no hard feelings if you prefer to include the code in the main dll. Just say so and I will change the module ASAP. It doesn't really matter much either way to me; the status quo is fine (although I think a patch to Tools/msi/msi.py is still needed). We may have to ship our own SHA-3 code for quite a while. OpenSSL hasn't even began to include SHA-3. Well... I find it cute to have SHA-3 implemented in Python, however, it probably wouldn't have hurt to only add support five years from now. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Segmentaion fault with wrongly set PYTHONPATH on Windows
On Oct 22, 2012, at 03:40 PM, Victor Stinner wrote: >The issue #8766 is about PYTHONPATH environment variable, not >PYTHONHOME. Test on Linux with Python 3.4: > >$ PYTHONHOME=/x ./python >Fatal Python error: Py_Initialize: Unable to get the locale encoding >ImportError: No module named 'encodings' >Abandon (core dumped) > >It's not a segfault, but an "abort". It's different: abort() is called >by the application (Python) when something goes wrong. In this case, >Python is unable to locate the standard library. It's not a bug: I >asked Python to look in /x directory, whereas this directory doesn't >exist. We have this bug in Ubuntu: https://bugs.launchpad.net/ubuntu/+source/python3.2/+bug/938869 This is caused by the VMware player installer playing games with $PYTHONHOME to try to point it at its own *Python 2* runtime, and trying to call lsb_release (a Python 3 script on Ubuntu 12.10) while $PYTHONHOME is pointing at the wrong runtime. I personally think this is a bug in the VMware player installer script. -Barry ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Segmentaion fault with wrongly set PYTHONPATH on Windows
Am 22.10.2012 16:18, schrieb Barry Warsaw: > This is caused by the VMware player installer playing games with $PYTHONHOME > to try to point it at its own *Python 2* runtime, and trying to call > lsb_release (a Python 3 script on Ubuntu 12.10) while $PYTHONHOME is pointing > at the wrong runtime. > > I personally think this is a bug in the VMware player installer script. I think it's a bug in lsb_release, too. It should use the -E option in its shebang: with "#!/usr/bin/python" $ PYTHONHOME=/invalid /usr/bin/lsb_release ImportError: No module named site with "#!/usr/bin/python -E" $ PYTHONHOME=/invalid /usr/bin/lsb_release LSB Version: core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Segmentaion fault with wrongly set PYTHONPATH on Windows
On Oct 22, 2012, at 04:30 PM, Christian Heimes wrote: >I think it's a bug in lsb_release, too. It should use the -E option in >its shebang: Indeed, thanks! I'd forgotten about -E. (bug updated btw) -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Segmentaion fault with wrongly set PYTHONPATH on Windows
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Am 22.10.2012 16:43, schrieb Barry Warsaw: > On Oct 22, 2012, at 04:30 PM, Christian Heimes wrote: > >> I think it's a bug in lsb_release, too. It should use the -E >> option in its shebang: > > Indeed, thanks! I'd forgotten about -E. > > (bug updated btw) You might want -s, too. - -E : ignore PYTHON* environment variables (such as PYTHONPATH) - -s : don't add user site directory to sys.path - -E -s are useful for system commands and mandatory for suid commands. Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBCAAGBQJQhVx9AAoJEMeIxMHUVQ1F3YEP/RUP6jp0I73zhXKX218PTW3C 1TFqe3V+1hoItaG3wAxTtGFfhlNfiQ2P0cJxXz3XecqKR5N23tC1ESn+sjHBfCtS rzB4d8h3F3BO1r15NzTnEKiZD6SxMAtiPksd6HQtwcAiPmiSbKded1v8WS2nQfKV xaz05NSEkbsG09Cj4DIGx+Vb7dJb3y+j9oVxI/8EQijURfSXXqx10x3mTy3upH6c 3LK+qtPbnrC3OFdHVKnZcAcHTNXzALs3vagcye04I3Jes927y6SdboEx77kptRbm rDmMQyRbvQgsYP+tXhJvJg8zf68t7F20pP4ato+FkYlaJJjkDXeSloGD8x8KSGvP P5QHmeMjFCazrKIjYNH00mLLUlW7cMZzapPvJP/sUaMFSVn+eEsU7L0Wj2fxxIsu s7kBAvso7t8Ins3OP2vn+RbFfo1wj8FV7DtBQoPo0MAjXKLZToaE7hCrqx0pBEmc nodQxgwaJXsRQAx4n4ZpfRCzqeUTIlgbvNpf7UPTEIGaWz6J98FZe5I3Gpa9VUDR h40lHvHoCy7UypmBYAvBh6q/EamSrpanUPIECHaxKqiehnUeChUz67A5hsIQ482z 7frVmgTcLHn8Q8+XlyXbCy6nBNU1Jpgy3yWbybPPsrDZWSJVtpdfgSURkimDZ2wG tRSwF3gWtTTU4te2NkYP =Suu/ -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Segmentaion fault with wrongly set PYTHONPATH on Windows
On Mon, Oct 22, 2012 at 4:40 PM, Victor Stinner wrote: >> >>> set PYTHONHOME=C:\ >>> python > > The issue #8766 is about PYTHONPATH environment variable, not > PYTHONHOME. Test on Linux with Python 3.4: > > $ PYTHONHOME=/x ./python > Fatal Python error: Py_Initialize: Unable to get the locale encoding > ImportError: No module named 'encodings' > Abandon (core dumped) > > It's not a segfault, but an "abort". It's different: abort() is called > by the application (Python) when something goes wrong. In this case, > Python is unable to locate the standard library. It's not a bug: I > asked Python to look in /x directory, whereas this directory doesn't > exist. I don't know what is abort() on Linux, but I believe coredumps is not something you want to get while setting some environment variable. On Windows it outputs a standard crash dialog box, which immediately raises questions about Python stability and potential exploitability in this direction. >> BTW, what is the role of PYTHONPATH on Windows? >> Is it a path for %INSTALLDIR%\Lib\site-packages? > > Same role than PYTHONPATH on Linux: specify where third party modules > are installed. I meant PYTHONHOME, sorry. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Segmentaion fault with wrongly set PYTHONPATH on Windows
Am 22.10.2012 18:26, schrieb anatoly techtonik: > I don't know what is abort() on Linux, but I believe coredumps is not > something you want to get while setting some environment variable. On > Windows it outputs a standard crash dialog box, which immediately > raises questions about Python stability and potential exploitability > in this direction. abort() is a C stdlib function that kills the current process with SGIABRT or similar. It's designed to draw attention to a fatal error. Are you proposing that Python should rather use _exit() than abort() here? Both forcedly shut down the process immediately. Christian ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 427 comment: code signing
On Thu, Oct 18, 2012 at 3:37 PM, Daniel Holth wrote: > On Thu, Oct 18, 2012 at 2:21 PM, wrote: >> I'm -1 on the usage of ed25519 in PEP 427. While the PEP proposes to use >> JSON >> Web signatures, this algorithm is not supported by the current JWS draft >> [1]. >> >> Instead, I suggest to use the ES256 algorithm from JWS, i.e. ECDSA with the >> NIST P-256 curve and SHA-256. This has the advantage of using standard >> algorithms [2]. >> >> I don't know what the rationale for suggesting ed25519 is; I suppose that >> existence of a pure-Python implementation played a role. However: >> - ECDSA also has a pure-Python implementation >> - ECDSA is well-supported by OpenSSL, i.e. a signature generator may also >> invoke the OpenSSL command line for efficient implementation. I believe >> M2Crypto also exposes enough of OpenSSL tp perform ECDSA signing and >> verification. Added a FAQ entry: Why are you using Ed25519 and JWS instead of PGP, S/MIME, or ECDSA? Wheel's signing scheme is designed to protect against cryptography that is not used. Wheel tries to encourage signing by making it very fast and easy. Signature verification is encouraged by including the signature in the archive itself rather than making it a separate download, and by including a Python implementation of the entire signing system in the reference implementation. JWS and Ed25519 yield small, pure-Python implementations. Ed25519 is fast enough that public-key cryptography can be considered for applications where it was traditionally too slow to be used, so wheels can be signed without worrying about performance. In Ed25519, unlike ECDSA, only key generation, but not signing, depends on a continuing high-quality source of entropy. The combination of increased performance, convenience, and availability compared to using a separate program means digital signatures can always be enabled in wheel. Wheel uses simplified keys and a signature system where key generation is about as fast as signing, making it possible to consider signing keys an abundant resource. Keys could represent a build server or a package rather than the publisher's entire digital identity. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] accept the wheel PEPs 425, 426, 427
http://hg.python.org/peps/rev/50e8ea1a17a0 Based on the other "required" field's absence in the wild, only "Metadata-Version", "Name", "Version", and "Summary" are required. Hopefully a clearer explanation of 0, 1, or many occurrences of each field. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 427 comment: code signing
On Mon, 22 Oct 2012 12:51:19 -0400 Daniel Holth wrote: > On Thu, Oct 18, 2012 at 3:37 PM, Daniel Holth wrote: > > On Thu, Oct 18, 2012 at 2:21 PM, wrote: > >> I'm -1 on the usage of ed25519 in PEP 427. While the PEP proposes to use > >> JSON > >> Web signatures, this algorithm is not supported by the current JWS draft > >> [1]. > >> > >> Instead, I suggest to use the ES256 algorithm from JWS, i.e. ECDSA with the > >> NIST P-256 curve and SHA-256. This has the advantage of using standard > >> algorithms [2]. > >> > >> I don't know what the rationale for suggesting ed25519 is; I suppose that > >> existence of a pure-Python implementation played a role. However: > >> - ECDSA also has a pure-Python implementation > >> - ECDSA is well-supported by OpenSSL, i.e. a signature generator may also > >> invoke the OpenSSL command line for efficient implementation. I believe > >> M2Crypto also exposes enough of OpenSSL tp perform ECDSA signing and > >> verification. > > Added a FAQ entry: > > Why are you using Ed25519 and JWS instead of PGP, S/MIME, or ECDSA? > Wheel's signing scheme is designed to protect against cryptography > that is not used. Wheel tries to encourage signing by making it very > fast and easy. Signature verification is encouraged by including > the signature in the archive itself rather than making it a separate > download, and by including a Python implementation of the entire > signing system in the reference implementation. Can you explain how the RECORD.jws file is obtained (and, if possible, post an example of how it looks like)? Specifically, which data is signed exactly? The binary contents of the RECORD file? Something else? Thanks Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 427 comment: code signing
On Mon, Oct 22, 2012 at 3:07 PM, Antoine Pitrou wrote: > On Mon, 22 Oct 2012 12:51:19 -0400 > Daniel Holth wrote: >> On Thu, Oct 18, 2012 at 3:37 PM, Daniel Holth wrote: >> > On Thu, Oct 18, 2012 at 2:21 PM, wrote: >> >> I'm -1 on the usage of ed25519 in PEP 427. While the PEP proposes to use >> >> JSON >> >> Web signatures, this algorithm is not supported by the current JWS draft >> >> [1]. >> >> >> >> Instead, I suggest to use the ES256 algorithm from JWS, i.e. ECDSA with >> >> the >> >> NIST P-256 curve and SHA-256. This has the advantage of using standard >> >> algorithms [2]. >> >> >> >> I don't know what the rationale for suggesting ed25519 is; I suppose that >> >> existence of a pure-Python implementation played a role. However: >> >> - ECDSA also has a pure-Python implementation >> >> - ECDSA is well-supported by OpenSSL, i.e. a signature generator may also >> >> invoke the OpenSSL command line for efficient implementation. I believe >> >> M2Crypto also exposes enough of OpenSSL tp perform ECDSA signing and >> >> verification. >> >> Added a FAQ entry: >> >> Why are you using Ed25519 and JWS instead of PGP, S/MIME, or ECDSA? >> Wheel's signing scheme is designed to protect against cryptography >> that is not used. Wheel tries to encourage signing by making it very >> fast and easy. Signature verification is encouraged by including >> the signature in the archive itself rather than making it a separate >> download, and by including a Python implementation of the entire >> signing system in the reference implementation. > > Can you explain how the RECORD.jws file is obtained (and, if possible, > post an example of how it looks like)? > Specifically, which data is signed exactly? The binary contents of the > RECORD file? Something else? The decoded contents are like the JSON documents at http://www.python.org/dev/peps/pep-0427/#json-web-signatures-extensions Signing is implemented at: https://bitbucket.org/dholth/wheel/src/tip/wheel/signatures/__init__.py?at=default#cl-25 The SHA-256 hash of RECORD is what is signed together with JWS signature header. The JWS spec elaborates on the general format. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 427: pure / plat distinction
Hello, How does the pure / plat distinction as outlined in PEP 427 cope with Debian's system of separating installed files into pyshared (for *.py and *.egg-info files) and pythonX.Y/dist-packages (for *.pyc and *.so files)? Thanks, Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Segmentaion fault with wrongly set PYTHONPATH on Windows
On Mon, Oct 22, 2012 at 7:37 PM, Christian Heimes wrote: > Am 22.10.2012 18:26, schrieb anatoly techtonik: >> I don't know what is abort() on Linux, but I believe coredumps is not >> something you want to get while setting some environment variable. On >> Windows it outputs a standard crash dialog box, which immediately >> raises questions about Python stability and potential exploitability >> in this direction. > > abort() is a C stdlib function that kills the current process with > SGIABRT or similar. It's designed to draw attention to a fatal error. > > Are you proposing that Python should rather use _exit() than abort() > here? Both forcedly shut down the process immediately. I am not a C coder and don't have any core Unix programming background. If Python is unable to start because it can not find its libraries, I prefer an explanative error message with standard system error code. Even if it is Fatal Python error - this case is still in user land and should be fixed normally. The error message could be improved though. Right now I get: E:\>python Fatal Python error: Py_Initialize: unable to load the file system codec ImportError: No module named 'encodings' This could be improved to: Fatal Python error: Py_Initialize: unable to find module named 'encodings' in 'C:\' -- anatoly t. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 427 comment: code signing
On Mon, 22 Oct 2012 15:20:01 -0400 Daniel Holth wrote: > > The decoded contents are like the JSON documents at > http://www.python.org/dev/peps/pep-0427/#json-web-signatures-extensions > > Signing is implemented at: > https://bitbucket.org/dholth/wheel/src/tip/wheel/signatures/__init__.py?at=default#cl-25 > > The SHA-256 hash of RECORD is what is signed together with JWS > signature header. The JWS spec elaborates on the general format. Thank you. Could you fix the terminology in the PEP? You are using the term "payload" in a different sense from the JWS draft. Specifically, the PEP should mention that the "JWS Payload" is the binary contents of the RECORD file. What you are calling payload is actually the "JWS Signature". Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 427: pure / plat distinction
On Mon, Oct 22, 2012 at 3:27 PM, Antoine Pitrou wrote: > > Hello, > > How does the pure / plat distinction as outlined in PEP 427 cope with > Debian's system of separating installed files into pyshared (for *.py > and *.egg-info files) and pythonX.Y/dist-packages (for *.pyc and *.so > files)? > > Thanks, > > Antoine. It is only there because distutils has a purelib/platlib distinction, so the spec represents it. See http://hg.python.org/cpython/file/49de26395d1a/Lib/distutils/command/install.py#l85 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 427 comment: code signing
On Mon, Oct 22, 2012 at 3:37 PM, Antoine Pitrou wrote:
> On Mon, 22 Oct 2012 15:20:01 -0400
> Daniel Holth wrote:
>>
>> The decoded contents are like the JSON documents at
>> http://www.python.org/dev/peps/pep-0427/#json-web-signatures-extensions
>>
>> Signing is implemented at:
>> https://bitbucket.org/dholth/wheel/src/tip/wheel/signatures/__init__.py?at=default#cl-25
>>
>> The SHA-256 hash of RECORD is what is signed together with JWS
>> signature header. The JWS spec elaborates on the general format.
>
> Thank you. Could you fix the terminology in the PEP? You are using the
> term "payload" in a different sense from the JWS draft. Specifically,
> the PEP should mention that the "JWS Payload" is the binary
> contents of the RECORD file.
>
> What you are calling payload is actually the "JWS Signature".
>
> Regards
Which line is confusing? The payload is the hash of the contents of
RECORD as a small JSON document: { "hash":
"sha256=ADD-r2urObZHcxBW3Cr-vDCu5RJwT4CaRTHiFmbcIYY" } instead of
including a base64-encoded copy of RECORD in the signature.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 427 comment: code signing
On Mon, 22 Oct 2012 15:49:34 -0400
Daniel Holth wrote:
> On Mon, Oct 22, 2012 at 3:37 PM, Antoine Pitrou wrote:
> > On Mon, 22 Oct 2012 15:20:01 -0400
> > Daniel Holth wrote:
> >>
> >> The decoded contents are like the JSON documents at
> >> http://www.python.org/dev/peps/pep-0427/#json-web-signatures-extensions
> >>
> >> Signing is implemented at:
> >> https://bitbucket.org/dholth/wheel/src/tip/wheel/signatures/__init__.py?at=default#cl-25
> >>
> >> The SHA-256 hash of RECORD is what is signed together with JWS
> >> signature header. The JWS spec elaborates on the general format.
> >
> > Thank you. Could you fix the terminology in the PEP? You are using the
> > term "payload" in a different sense from the JWS draft. Specifically,
> > the PEP should mention that the "JWS Payload" is the binary
> > contents of the RECORD file.
> >
> > What you are calling payload is actually the "JWS Signature".
> >
> > Regards
>
> Which line is confusing? The payload is the hash of the contents of
> RECORD as a small JSON document: { "hash":
> "sha256=ADD-r2urObZHcxBW3Cr-vDCu5RJwT4CaRTHiFmbcIYY" } instead of
> including a base64-encoded copy of RECORD in the signature.
Thanks for the explanation. Can you add it to the PEP?
In your JWS header example:
{
"alg": "Ed25519",
"typ": "JWT",
"key": {
"alg": "Ed25519",
"vk": "tmAYCrSfj8gtJ10v3VkvW7jOndKmQIYE12hgnFu3cvk"
}
}
Why are you using "key" instead of "jwk" for the JSON Web Key?
Regards
Antoine.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 427: pure / plat distinction
On Mon, 22 Oct 2012 15:39:07 -0400 Daniel Holth wrote: > On Mon, Oct 22, 2012 at 3:27 PM, Antoine Pitrou wrote: > > > > Hello, > > > > How does the pure / plat distinction as outlined in PEP 427 cope with > > Debian's system of separating installed files into pyshared (for *.py > > and *.egg-info files) and pythonX.Y/dist-packages (for *.pyc and *.so > > files)? > > > > Thanks, > > > > Antoine. > > It is only there because distutils has a purelib/platlib distinction, > so the spec represents it. See > http://hg.python.org/cpython/file/49de26395d1a/Lib/distutils/command/install.py#l85 Ok, so does this mean Debian would have to build their own installer if they want to spread the wheel's contents as appropriate for their directory layout? Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 427 comment: code signing
On Mon, Oct 22, 2012 at 4:12 PM, Antoine Pitrou wrote:
> On Mon, 22 Oct 2012 15:49:34 -0400
> Daniel Holth wrote:
>> On Mon, Oct 22, 2012 at 3:37 PM, Antoine Pitrou wrote:
>> > On Mon, 22 Oct 2012 15:20:01 -0400
>> > Daniel Holth wrote:
>> >>
>> >> The decoded contents are like the JSON documents at
>> >> http://www.python.org/dev/peps/pep-0427/#json-web-signatures-extensions
>> >>
>> >> Signing is implemented at:
>> >> https://bitbucket.org/dholth/wheel/src/tip/wheel/signatures/__init__.py?at=default#cl-25
>> >>
>> >> The SHA-256 hash of RECORD is what is signed together with JWS
>> >> signature header. The JWS spec elaborates on the general format.
>> >
>> > Thank you. Could you fix the terminology in the PEP? You are using the
>> > term "payload" in a different sense from the JWS draft. Specifically,
>> > the PEP should mention that the "JWS Payload" is the binary
>> > contents of the RECORD file.
>> >
>> > What you are calling payload is actually the "JWS Signature".
>> >
>> > Regards
>>
>> Which line is confusing? The payload is the hash of the contents of
>> RECORD as a small JSON document: { "hash":
>> "sha256=ADD-r2urObZHcxBW3Cr-vDCu5RJwT4CaRTHiFmbcIYY" } instead of
>> including a base64-encoded copy of RECORD in the signature.
>
> Thanks for the explanation. Can you add it to the PEP?
>
> In your JWS header example:
>
> {
> "alg": "Ed25519",
> "typ": "JWT",
> "key": {
> "alg": "Ed25519",
> "vk": "tmAYCrSfj8gtJ10v3VkvW7jOndKmQIYE12hgnFu3cvk"
> }
> }
>
> Why are you using "key" instead of "jwk" for the JSON Web Key?
bug.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 427: data directory
Hello,
The FAQ has this weird statement:
“This specification does not have an opinion on how you should organize
your code. The .data directory is just a place for any files that are
not normally installed inside site-packages or on the PYTHONPATH.”
But, say, if I want to install some init script to /etc/init.d by using
distutils' data_files argument:
setup.py(...,
data_files=[('/etc/init.d', ['my-init-script'])]
)
How is it stored and represented by the wheel format?
Regards
Antoine.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 427: pure / plat distinction
On Mon, Oct 22, 2012 at 4:13 PM, Antoine Pitrou wrote: > On Mon, 22 Oct 2012 15:39:07 -0400 > Daniel Holth wrote: >> On Mon, Oct 22, 2012 at 3:27 PM, Antoine Pitrou wrote: >> > >> > Hello, >> > >> > How does the pure / plat distinction as outlined in PEP 427 cope with >> > Debian's system of separating installed files into pyshared (for *.py >> > and *.egg-info files) and pythonX.Y/dist-packages (for *.pyc and *.so >> > files)? >> > >> > Thanks, >> > >> > Antoine. >> >> It is only there because distutils has a purelib/platlib distinction, >> so the spec represents it. See >> http://hg.python.org/cpython/file/49de26395d1a/Lib/distutils/command/install.py#l85 > > Ok, so does this mean Debian would have to build their own installer if > they want to spread the wheel's contents as appropriate for their > directory layout? Sorry if this is a lame observation, but Debian has already built their own installer called dpkg. The Python-specific binary format will mainly be used to populate virtualenvs. It may also turn out to be a convenient intermediate step to build an .rpm or .deb but that is not the primary design goal. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 427: data directory
On Mon, Oct 22, 2012 at 4:20 PM, Antoine Pitrou wrote:
>
> Hello,
>
> The FAQ has this weird statement:
>
> “This specification does not have an opinion on how you should organize
> your code. The .data directory is just a place for any files that are
> not normally installed inside site-packages or on the PYTHONPATH.”
>
> But, say, if I want to install some init script to /etc/init.d by using
> distutils' data_files argument:
>
> setup.py(...,
> data_files=[('/etc/init.d', ['my-init-script'])]
> )
>
> How is it stored and represented by the wheel format?
>
> Regards
>
> Antoine.
Distutils' "data" category in a wheel package-1.0.data/data/ directory
usually maps to / (or the root of the virtualenv). Your init script
would probably wind up in there.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 427: pure / plat distinction
Le lundi 22 octobre 2012 à 16:25 -0400, Daniel Holth a écrit : > On Mon, Oct 22, 2012 at 4:13 PM, Antoine Pitrou wrote: > > On Mon, 22 Oct 2012 15:39:07 -0400 > > Daniel Holth wrote: > >> On Mon, Oct 22, 2012 at 3:27 PM, Antoine Pitrou > >> wrote: > >> > > >> > Hello, > >> > > >> > How does the pure / plat distinction as outlined in PEP 427 cope with > >> > Debian's system of separating installed files into pyshared (for *.py > >> > and *.egg-info files) and pythonX.Y/dist-packages (for *.pyc and *.so > >> > files)? > >> > > >> > Thanks, > >> > > >> > Antoine. > >> > >> It is only there because distutils has a purelib/platlib distinction, > >> so the spec represents it. See > >> http://hg.python.org/cpython/file/49de26395d1a/Lib/distutils/command/install.py#l85 > > > > Ok, so does this mean Debian would have to build their own installer if > > they want to spread the wheel's contents as appropriate for their > > directory layout? > > Sorry if this is a lame observation, but Debian has already built > their own installer called dpkg. Right :) > The Python-specific binary format will mainly be used to populate > virtualenvs. It may also turn out to be a convenient intermediate step > to build an .rpm or .deb but that is not the primary design goal. Well, I would expect people to also use it for regular installations, especially under Windows (thanks to the ABI tag for extension modules). Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 427: data directory
On Mon, 22 Oct 2012 16:26:57 -0400
Daniel Holth wrote:
> On Mon, Oct 22, 2012 at 4:20 PM, Antoine Pitrou wrote:
> >
> > Hello,
> >
> > The FAQ has this weird statement:
> >
> > “This specification does not have an opinion on how you should organize
> > your code. The .data directory is just a place for any files that are
> > not normally installed inside site-packages or on the PYTHONPATH.”
> >
> > But, say, if I want to install some init script to /etc/init.d by using
> > distutils' data_files argument:
> >
> > setup.py(...,
> > data_files=[('/etc/init.d', ['my-init-script'])]
> > )
> >
> > How is it stored and represented by the wheel format?
> >
> > Regards
> >
> > Antoine.
>
> Distutils' "data" category in a wheel package-1.0.data/data/ directory
> usually maps to / (or the root of the virtualenv). Your init script
> would probably wind up in there.
Ok, thanks. Might be nice to add as a FAQ entry :-)
Regards
Antoine.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 427: data directory
On Mon, Oct 22, 2012 at 4:26 PM, Daniel Holth wrote: > On Mon, Oct 22, 2012 at 4:20 PM, Antoine Pitrou wrote: >> >> Hello, >> >> The FAQ has this weird statement: >> >> “This specification does not have an opinion on how you should organize >> your code. The .data directory is just a place for any files that are >> not normally installed inside site-packages or on the PYTHONPATH.” I mean to say that just because there is a .data/ directory it doesn't mean you have to stop using pkgutil.get_data(package, resource). Some people will take those 4 letters "data" to mean that any file that doesn't start with .py has to go there instead of in the root of the archive. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 427 comment: code signing
Zitat von Daniel Holth : Why are you using Ed25519 and JWS instead of PGP, S/MIME, or ECDSA? Wheel's signing scheme is designed to protect against cryptography that is not used. Wheel tries to encourage signing by making it very fast and easy. Signature verification is encouraged by including the signature in the archive itself rather than making it a separate download, and by including a Python implementation of the entire signing system in the reference implementation. JWS and Ed25519 yield small, pure-Python implementations. Ed25519 is fast enough that public-key cryptography can be considered for applications where it was traditionally too slow to be used, so wheels can be signed without worrying about performance. I believe this analysis of reasons for not using cryptography is incorrect. Speed never is an issue in deciding whether or not to use cryptographic algorithms, today (except for cases with very limited CPU capabilities). Instead, the primary reason for not choosing cryptography is ease-of-use. For that reason, I still think that using an established algorithm would be the better choice. I remain -1 on this choice. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 427 comment: code signing
On Mon, Oct 22, 2012 at 6:20 PM, wrote: > > Zitat von Daniel Holth : > > >> Why are you using Ed25519 and JWS instead of PGP, S/MIME, or ECDSA? >> Wheel's signing scheme is designed to protect against cryptography >> that is not used. Wheel tries to encourage signing by making it very >> fast and easy. Signature verification is encouraged by including >> the signature in the archive itself rather than making it a separate >> download, and by including a Python implementation of the entire >> signing system in the reference implementation. >> >> JWS and Ed25519 yield small, pure-Python implementations. Ed25519 >> is fast enough that public-key cryptography can be considered for >> applications where it was traditionally too slow to be used, so >> wheels can be signed without worrying about performance. > > > I believe this analysis of reasons for not using cryptography is incorrect. > Speed never is an issue in deciding whether or not to use cryptographic > algorithms, today (except for cases with very limited CPU capabilities). > Instead, the primary reason for not choosing cryptography is ease-of-use. > > For that reason, I still think that using an established algorithm would > be the better choice. I remain -1 on this choice. You are right that in this application, it probably doesn't matter. In other applications like public key authentication for individual packets the Ed25519 performance is necessary. A relevant advantage is the deterministic signatures property; the Playstation lost their key because they forgot to use randomness when generating ECDSA signatures. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Segmentaion fault with wrongly set PYTHONPATH on Windows
anatoly techtonik writes: > I am not a C coder and don't have any core Unix programming > background. If Python is unable to start because it can not find its > libraries, I prefer an explanative error message with standard system > error code. Even if it is Fatal Python error - this case is still in > user land and should be fixed normally. Python can't know that the problem is in "user land" as you call it. For all Python knows, the directory containing its libraries is corrupt, or that the file system code itself experienced a mysterious glitch. While in the technical sense the problem here is in userland, not in the kernel, the distinction you're making is incoherent. For most users, it doesn't matter whether an environment variable is set incorrectly without their knowledge, or if the kernel is buggy, or if the disk is corrupt. And from Python's point of view, the world as a whole no longer makes. So it shuts down abnormally. That's what an abort means, in programming as in rocket launches. Users should be scared if this happens; somebody really screwed up. (Unless it's themselves, and then they only have themselves to blame.) > The error message could be > improved though. Right now I get: > > E:\>python > Fatal Python error: Py_Initialize: unable to load the file system codec > ImportError: No module named 'encodings' > > This could be improved to: > > Fatal Python error: Py_Initialize: unable to find module named 'encodings' > in 'C:\' That may be an improvement. But in that case it might be worth explaining where "C:\" came from (in this case PYTHONHOME, I guess?) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Fwd: Python 3.3 can't sort memoryviews as they're unorderable
Original Message Subject: Python 3.3 can't sort memoryviews as they're unorderable Date: Sun, 21 Oct 2012 12:24:32 +0100 From: Mark Lawrence To: [email protected] Newsgroups: gmane.comp.python.general http://docs.python.org/dev/whatsnew/3.3.html states "memoryview comparisons now use the logical structure of the operands and compare all array elements by value". So I'd have thought that you should be able to compare them and hence sort them, but this is the state of play. Python 3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 10:55:48) [MSC v.1600 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. memoryview(bytearray(range(5))) == memoryview(bytearray(range(5))) True memoryview(bytearray(range(5))) != memoryview(bytearray(range(5))) False memoryview(bytearray(range(5))) < memoryview(bytearray(range(5))) Traceback (most recent call last): File "", line 1, in TypeError: unorderable types: memoryview() < memoryview() Okay then, let's subclass memoryview to provide the functionality. class Test(memoryview): ... pass ... Traceback (most recent call last): File "", line 1, in TypeError: type 'memoryview' is not an acceptable base type Oh dear. http://docs.python.org/py3k/library/stdtypes.html#typememoryview only gives examples of equality comparisons and there was nothing that I could see in PEP3118 to explain the rationale behind the lack of other comparisons. What have I missed? Nobody on the main Python ml could answer this so can someone please explain the background to how memoryviews work in this instance as I'm confused, thanks. Mark Lawrence. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Segmentaion fault with wrongly set PYTHONPATH on Windows
Stephen J. Turnbull wrote: For most users, it doesn't matter whether an environment variable is set incorrectly without their knowledge, or if the kernel is buggy, or if the disk is corrupt. And from Python's point of view, the world as a whole no longer makes. So it shuts down abnormally. That's what an abort means, in programming as in rocket launches. Seems to me the only reason to use SIGABRT rather than exit() with an error code is to provoke a core dump, and that's only useful if we suspect a bug in Python itself. That's not the case here -- the cause is clearly something external. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 427 comment: code signing
[email protected] writes: > Instead, the primary reason for not choosing cryptography is ease-of-use. > > For that reason, I still think that using an established algorithm would > be the better choice. I don't understand this. An established algorithm might be cryptographically safer, but what could be easier to use than the default algorithm that is built-in? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 427 comment: code signing
You could just include a different algorithm. He meant that the speed of ed25519 is not an advantage in this use case. Did I mention that its c implementation has defense against timing attacks? On Oct 22, 2012 8:24 PM, "Stephen J. Turnbull" wrote: > [email protected] writes: > > > Instead, the primary reason for not choosing cryptography is > ease-of-use. > > > > For that reason, I still think that using an established algorithm would > > be the better choice. > > I don't understand this. An established algorithm might be > cryptographically safer, but what could be easier to use than the > default algorithm that is built-in? > > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 427 comment: code signing
Well, let's try again. I know Ed25519 is not on anyone's list, but I
would like to show at minimum that it is interesting.
%timeit wheel.tool.unpack('lxml-3.0.1-cp27-none-linux_x86_64.whl')
10 loops, best of 3: 123 ms per loop
.unpack() verifies the signature and extracts the file. Installation
is not much more costly than unpack. Removing the C extension to use
the Python Ed25519 instead,
%timeit wheel.tool.unpack('lxml-3.0.1-cp27-none-linux_x86_64.whl')
1 loops, best of 3: 153 ms per loop
With python-ecdsa, verifying a single signature,
import ecdsa
sk = ecdsa.SigningKey.generate(ecdsa.NIST256p)
sig = sk.sign("message")
vk = sk.get_verifying_key()
%timeit vk.verify(sig, "message")
1 loops, best of 3: 144 ms per loop
takes about as long as the whole unpack() including verification.
You will notice the difference when you are rebuilding a virtualenv
with 30+ dependencies every time you commit, keeping the old
virtualenv around in case something broke. It wouldn't matter if we
were building from source because we would avoid creating new
virtualenvs just to save time.
Also python-ecdsa does not work on Python 3.
ECDSA's verifying (public) keys at the same security level are 64
bytes instead of the 32-byte Ed25519 keys, which would make the
proposed "inline public keys" syntax half as convenient.
package[ed25519=ouBJlTJJ4SJXoy8Bi1KRlewWLU6JW7HUXTgvU1YRuiA]
I hope that the speed of wheel, and the properties of its signature
scheme, will inspire people to invent new applications that require
those features.
If necessary we could also just remove algorithms from the spec and
make the signing implementation pluggable. For key management reasons,
the signing interface used by the build tool is already "run the wheel
command line tool in a subprocess" which is also what you would do if
you needed to take advantage of the allowed S/MIME RECORD.p7s.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 427 comment: code signing
Zitat von Daniel Holth :
Well, let's try again. I know Ed25519 is not on anyone's list, but I
would like to show at minimum that it is interesting.
I have no doubt about that, and I believe that this ("it is interesting")
might be your primary motivation for using it, i.e. "coolness", which
is really a form of purity.
%timeit wheel.tool.unpack('lxml-3.0.1-cp27-none-linux_x86_64.whl')
1 loops, best of 3: 153 ms per loop
With python-ecdsa, verifying a single signature,
import ecdsa
sk = ecdsa.SigningKey.generate(ecdsa.NIST256p)
sig = sk.sign("message")
vk = sk.get_verifying_key()
%timeit vk.verify(sig, "message")
1 loops, best of 3: 144 ms per loop
takes about as long as the whole unpack() including verification.
This isn't really convincing, as you are comparing different operations.
It may well be that in pure-python ed25519, it's also the validation
that takes most of the time.
But it's really irrelevant. We are talking about a runtime of 0.1s.
If this really becomes an issue, an openssl version can be used instead.
Also python-ecdsa does not work on Python 3.
Which certainly can be fixed.
If necessary we could also just remove algorithms from the spec and
make the signing implementation pluggable. For key management reasons,
the signing interface used by the build tool is already "run the wheel
command line tool in a subprocess" which is also what you would do if
you needed to take advantage of the allowed S/MIME RECORD.p7s.
I'm also -1 on the notion that the entire key distribution matter is out
of scope. With that approach, I feel that the package signing is essentially
pointless.
As a general note on this, this entire issue lacks a threat model:
what kind of attack do you want to protect against? I can't think of
any realistic threat that is effectively protected against with your
signature scheme.
Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 427 comment: code signing
Zitat von "Stephen J. Turnbull" : [email protected] writes: > Instead, the primary reason for not choosing cryptography is ease-of-use. > > For that reason, I still think that using an established algorithm would > be the better choice. I don't understand this. An established algorithm might be cryptographically safer, but what could be easier to use than the default algorithm that is built-in? That's exactly what I want: it (PEP 427) should use one of the algorithms that is built-in (into web signatures). Web signatures give a choice of three algorithms; yet Daniel proposes to deviate and use a non-builtin algorithm. None of the algorithms in question are built in in Python; the two standard algorithms with public keys (i.e. RSA and ECDSA) are both built into OpenSSL. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
