Closed jpflori closed 10 years ago
Changed keywords from none to spkg pycrypto
This would be a good time to cleanup spkg scripts.
Branch: u/jpflori/ticket/14854
Description changed:
---
+++
@@ -1 +1,5 @@
We ship 2.1.0.
+
+Use git branch and upstream tarball at:
+* http://boxen.math.washington.edu/home/jpflori/upstream/pycrypto-2.6.1.tar.gz
+
Author: Jean-Pierre Flori
Dependencies: #12399
This was in #15531 but I'm pretty sure it applies here just as well:
sage -t --long src/sage/crypto/block_cipher/miniaes.py # 1 doctest failed
sage -t --long src/sage/crypto/block_cipher/sdes.py # 1 doctest failed
sage -t --long src/sage/crypto/classical_cipher.py # 1 doctest failed
sage -t --long src/sage/crypto/stream_cipher.py # 1 doctest failed
sage -t --long src/sage/crypto/util.py # 1 doctest failed
sage -t --long src/sage/crypto/public_key/blum_goldwasser.py # 1 doctest failed
sage -t --long src/sage/monoids/string_monoid.py # 1 doctest failed
sage -t --long src/sage/monoids/string_monoid_element.py # 1 doctest failed
Oops, I'll have a look at it.
The errors are because pycrpto wants a secure (hum, let's say more side channel attacks resistant) implem of modular exponentiation or issues a warning. It's available as mpz_powm_sec from recent GMP releases, but MPIR does not supply that. (Also note that wiith FLINT 2.4 we should be able to build all of Sage IIRC on top of gmp, time for a new spkg?) So we should just ignore the warnings (or add them to the doctests but would fail with Sage on top of GMP). Anyway, we don't really care within Sage, at least that's my point of view, nobody would or should use Sage to do real crypto.
Branch pushed to git repo; I updated commit sha1. New commits:
a76e9a3 | Filter pycrypto warning about insecure modular exponentiaiton. |
The solution I've implemented is to filter pycrypto warnings in the warnings module. Feel free to say it is a bad solution and we should rather modify the tests, or move the piece of code I've added somewhere else (maybe it really slows down Sage startup, I don't know).
On a different topic, the only funciton actually used is in the monoids files, and that's only the byte_to_long function, so maybe we should implement this ourselves. I don't suggest to remove the pycrypto pkg though.
I'd rather modify the tests and preserve the warning...
Should we explicitely match the warning or filter it with "..."?
Explicit is better than implicit (one of Python's credos), but then I don't care that much ;-)
Let's go for explicit. As I said, I think we should get rid of the pycrypto use in the monoid stuff anyway, so when that's the case it will force us to remove the explicit things rather than leaving ... evrywhere.
Unfortunately I'm not sure I can do anything else as what I did as the warning only comes up the first time the BinaryStrings().encoding("") is used so it depends on the order the tests within the file will be run.
Maybe better reimplement bytes_to_long and long_to_bytes directly.
The order of doctests is top to bottom, isn't it?
I've replaced the pycrypto functions by plain python funcitons which seem to be adequate for our use.
lgtm
Reviewer: Volker Braun
We ship 2.1.0.
Use git branch and upstream tarball at:
Depends on #12399
Component: packages: standard
Keywords: spkg pycrypto
Author: Jean-Pierre Flori
Branch/Commit: u/jpflori/ticket/14854 @
83eeb4b
Reviewer: Volker Braun
Issue created by migration from https://trac.sagemath.org/ticket/14854