stef / pysodium Goto Github PK
View Code? Open in Web Editor NEWwrapper for libsodium providing high level crypto primitives
License: Other
wrapper for libsodium providing high level crypto primitives
License: Other
i'd like to use crypto_box_curve25519xsalsa20poly1305 so i know what i get, but it isn't provided.
Hi,
What are the meanings of 'ad' and 'nonce' in function test_aead_chacha20poly1305?
Thanks!
Hi I was having some trouble using your wrapper on windows. I installed the sodium dll in multiple places but ctypes.cdll.LoadLibrary would always return None. I saw a couple of other people having this problem on windows as well. I added the following few lines to the top of your file to search the system path. Thanks
import ctypes
import ctypes.util
import sys
import os
import platform
if platform.system() == 'Windows':
if platform.machine() == 'AMD64':
sodium_dll = 'libsodium-64.dll'
else:
sodium_dll = 'libsodium.dll'
def find_libsodium():
for path in sys.path:
filename = os.path.join(path, sodium_dll)
if os.path.isfile(filename):
return filename
sodium_path = find_libsodium()
if not sodium_path:
raise ValueError('Unable to find libsodium')
sodium = ctypes.cdll.LoadLibrary(sodium_path)
else:
sodium = ctypes.cdll.LoadLibrary(ctypes.util.find_library('sodium') or ctypes.util.find_library('libsodium'))
Hi,
Would you consider accepting a PR that makes pysodium
an "autonomous" Python package (that would not depend on the presence of libsodium.so
/libsodium.dll
on the target system) ?
The idea would be to provide a wheel for all platforms and the binary dependency would no longer be required on Windows and OSX. On linux, installing the package would still require an available libsodium
on the system (binary wheels are not supported for Linux afaik).
Users would only have to do:
pip install pysodium
To get a fully working pysodium
. Checks for the library failure on import
would also no longer be a concern for user-code.
Before I put on all the work for that, is this something you'd consider for inclusion ?
Thanks for the amazing work so far !
I need to use pysodium.crypto_secretstream_xchacha20poly1305_MESSAGEBYTES_MAX.value
in my code but I found that its value is not quite right.
The libsodium docs say it should be ~256GB and my reading of the libsodium code confirms but pysodium.crypto_secretstream_xchacha20poly1305_MESSAGEBYTES_MAX
and pysodium.crypto_secretstream_xchacha20poly1305_MESSAGEBYTES_MAX.value
both give me ~18.5EB which is a mite bigger than it should be.
I've got libsodium 1.0.18 (debian flavour) and pysodium 0.7.16 (pypi flavour). Another person confirmed with libsodium/pysodium 1.0.19 / 0.7.16 and a third with pysodium 0.7.16.
test/init.py is Copyright (c) 2001-2014 Acronis, Author Bulat Gaifullin ([email protected]), no license specified.
test/test_pysodium.py is Copyright (c) 2013-2014, Marsiske Stefan, license BSD-2-Clause.
It appears that both files were originally committed by @bgaifullin in commit 4fc0a48 and that the copyright and license for test/test_pysodium.py was changed to Copyright (c) 2013-2014, Marsiske Stefan, license BSD-2-Clause in commit 6e35c7c, but that the details for test/init.py were left unchanged.
Please could you confirm that test/init.py is licensed under BSD-2-Clause, and perhaps consider making the copyright statements consistent?
Thanks.
Christopher Hoskin
Found some more parameter type discrepancies, link to patch:
https://spideroak.com/storage/OJ2XA33MMU/shared/569346-28-1480/pysodium_parameter_size.patch?730b953742d3894a3bf6dd0a9a9b0f35
Any chance of exposing the remaining crypto_core_ristretto functions from libsoidium in pysodium
I'm trying to use crypto_box
and crypto_box_open
to let party A encrypt and sign data for party B.
From my understanding, the following code should work:
def test_cross_box():
pkA, skA = pysodium.crypto_sign_keypair()
pkB, skB = pysodium.crypto_sign_keypair()
nonce = pysodium.randombytes(pysodium.crypto_box_NONCEBYTES)
msg = "foo"
c = pysodium.crypto_box(msg, nonce, pkB, skA)
d = pysodium.crypto_box_open(c, nonce, pkA, skB)
assert msg == d
However, the above code raises a ValueError
in
/usr/local/lib/python2.7/site-packages/pysodium/__init__.py:256: in crypto_box_open __check(sodium.crypto_box_open(msg, padded, ctypes.c_ulonglong(len(padded)), nonce, pk, sk))
The unit test only seems to check for cases where the public and secret key are the same when calling crypto_box
and crypto_box_open
, and indeed the following code works:
def test_self_box():
pkA, skA = pysodium.crypto_sign_keypair()
nonce = pysodium.randombytes(pysodium.crypto_box_NONCEBYTES)
msg = "foo"
c = pysodium.crypto_box(msg, nonce, pkA, skA)
d = pysodium.crypto_box_open(c, nonce, pkA, skA)
assert msg == d
Am I missing something about how crypto_box
should be used, or is this a bug?
Using python 2.7, pysodium 0.6.8, libsodium 1.0.9
# crypto_generichash(m, k=b'', outlen=crypto_generichash_BYTES)
genericHash = pysodium.crypto_generichash(
m=_password + passwordSalt,
k=bytes(genericHashKey, 'utf-8'),
outlen=pysodium.crypto_generichash_BYTES_MAX
)
results in
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python3/dist-packages/pysodium/__init__.py", line 441, in crypto_generichash
__check(sodium.crypto_generichash(buf, ctypes.c_size_t(outlen), m, ctypes.c_ulonglong(len(m)), k, ctypes.c_size_t(len(k))))
File "/usr/lib/python3/dist-packages/pysodium/__init__.py", line 251, in __check
raise ValueError
ValueError
There are number of issues with the current implementation that prevent the use of pysodium in python3 applications.
I propose that we detect the python version at runtime and modify the wrapper functions to do the right thing for python2 and python3. Most notably, the message.encode() calls need to be fixed.
crypto_aead_chacha20poly1305_decrypt
'ad' can't be 'None'.
When 'ad' is 'None', it crash.
"TypeError: object of type 'NoneType' has no len()"
I wonder is there a reason why crypto_auth
and crypto_auth_verify
accept key which is empty byte string by default? Doesn't usage of empty string as a key defeat the purpose of authentication since everyone can make a valid authentication tag for a tampered message?
The crypto_auth() function computes a tag for the message in, whose length is inlen bytes, and the key k. k should be crypto_auth_KEYBYTES bytes. The function puts the tag into out. The tag is crypto_auth_BYTES bytes long.
(emphasis is mine)
Howdy,
I'm trying to use libsodium with PySodium, but found that there wasn't a binding already for the chacha20_poly1305 algorithm, so I took my first stab at writing one: https://gist.github.com/mojojoseph/9b43bd35a7ab3812d7bd
This code:
https://gist.github.com/mojojoseph/c555110400060bcf99a3
works fine on an AMD64 Linux server, but when I port it over to an ARMv6 (RaspberryPi) I get a nasty trace, and I am guessing somewhere in the FFI calls my stack goes bonkers.
The actual break is at
Program received signal SIGSEGV, Segmentation fault.
chacha_keysetup (x=0xbeffefc4, k=0x0) at crypto_stream/chacha20/ref/stream_chacha20_ref.c:69
69 x->input[4] = U8TO32_LITTLE(k + 0);
with a stacktrace - I notice that after the ffi_call_VFP() things go bonkers. I'm uncertain as to whether my ctypes binding is just wrong for the arguments that are needed or there's something going on with the ARM/FFI combination. Like I said it all works fine on the AMD64 linux server.
#0 chacha_keysetup (x=0xbeffefc4, k=0x0) at crypto_stream/chacha20/ref/stream_chacha20_ref.c:69
#1 0x4059dcbc in crypto_stream_chacha20_ref (c=0xbefff0e4 "\264\335\024", clen=<optimized out>, n=0x0, k=0x0)
at crypto_stream/chacha20/ref/stream_chacha20_ref.c:241
#2 0x40556f60 in crypto_aead_chacha20poly1305_encrypt (c=0x405385f4 "\206Йt\204\v\336", <incomplete sequence \312>, clen=0x437f44,
m=0x0, mlen=4634464344201201140, ad=0xa <Address 0xa out of bounds>, adlen=1079196860, nsec=0xa <Address 0xa out of bounds>, npub=
0x0, k=0x0) at crypto_aead/chacha20poly1305/sodium/aead_chacha20poly1305.c:49
#3 0x40501368 in ffi_call_VFP () from /usr/lib/python2.7/lib-dynload/_ctypes_d.so
#4 0x40500930 in ffi_call () from /usr/lib/python2.7/lib-dynload/_ctypes_d.so
#5 0x404ecf10 in _call_function_pointer (flags=4353, pProc=0x40556ea8 <crypto_aead_chacha20poly1305_encrypt>, avalues=0xbefff2d8,
atypes=0xbefff2a8, restype=0x402a6ed8, resmem=0xbefff308, argcount=9)
at /build/python2.7-xJctIx/python2.7-2.7.3/Modules/_ctypes/callproc.c:827
#6 0x404edb84 in _ctypes_callproc (pProc=0x40556ea8 <crypto_aead_chacha20poly1305_encrypt>, argtuple=
(<c_char_Array_26 at remote 0x4054fc68>, <c_ulonglong at remote 0x4054fcd0>, '\x86\xd0\x99t\x84\x0b\xde\xd2\xa5\xca', <c_ulonglong at remote 0x40307fa8>, '\x87\xe2)\xd4P\x08E\xa0y\xc0', <c_ulonglong at remote 0x4054fc00>, None, '\xcd|\xf6{\xe3\x9cyJ', "B\x90\xbc\xb1T\x1751\xf3\x14\xafW\xf3\xbe;P\x06\xda7\x1e\xce'*\xfa\x1b]\xbd\xd1\x10\n\x10\x07"), flags=4353, argtypes=0x0, restype=
<_ctypes.PyCSimpleType at remote 0x408920>, checker=0x0)
at /build/python2.7-xJctIx/python2.7-2.7.3/Modules/_ctypes/callproc.c:1174
#7 0x404e5154 in PyCFuncPtr_call (self=0x40518e90, inargs=
(<c_char_Array_26 at remote 0x4054fc68>, <c_ulonglong at remote 0x4054fcd0>, '\x86\xd0\x99t\x84\x0b\xde\xd2\xa5\xca', <c_ulonglong at remote 0x40307fa8>, '\x87\xe2)\xd4P\x08E\xa0y\xc0', <c_ulonglong at remote 0x4054fc00>, None, '\xcd|\xf6{\xe3\x9cyJ', "B\x90\xbc\xb1T\x1751\xf3\x14\xafW\xf3\xbe;P\x06\xda7\x1e\xce'*\xfa\x1b]\xbd\xd1\x10\n\x10\x07"), kwds=0x0)
at /build/python2.7-xJctIx/python2.7-2.7.3/Modules/_ctypes/_ctypes.c:3913
#8 0x0002fa08 in PyObject_Call (func=<_FuncPtr(__name__='crypto_aead_chacha20poly1305_encrypt') at remote 0x40518e90>, arg=
(<c_char_Array_26 at remote 0x4054fc68>, <c_ulonglong at remote 0x4054fcd0>, '\x86\xd0\x99t\x84\x0b\xde\xd2\xa5\xca', <c_ulonglong at remote 0x40307fa8>, '\x87\xe2)\xd4P\x08E\xa0y\xc0', <c_ulonglong at remote 0x4054fc00>, None, '\xcd|\xf6{\xe3\x9cyJ', "B\x90\xbc\xb1T\x1751\xf3\x14\xafW\xf3\xbe;P\x06\xda7\x1e\xce'*\xfa\x1b]\xbd\xd1\x10\n\x10\x07"), kw=0x0) at ../Objects/abstract.c:2529
Sodium does not seem to do any range checking on it's inputs, at least in the case of crypto_secretbox. If I pass in an empty key it still returns an encrypted result, which can be decrypted with an empty key. I'd expect an error if the the length of key is not equal to pysodium.crypto_secretbox_KEYBYTES.
nonce = pysodium.randombytes(pysodium.crypto_secretbox_NONCEBYTES)
pysodium.crypto_secretbox(b"some data", nonce, b"")
Additionally, if I pass an arbitrary integer as a nonce, the python interpreter segfaults.
pysodium.crypto_secretbox(b"some data", 0, b"")
Should pysodium be doing these range checks on behalf of sodium?
The constant added in #78 is crypto_aead_xchacha20poly1305_ietf_NPUBBYTES while the other AEAD variants have _NONCEBYTES. It would be nice if they were consistent. Maybe either rename the new one to be consistent or add _NPUBBYTES copies (to avoid breakage) of the old ones since that is what libsodium uses?
>>> import pysodium
>>> pysodium.crypto_generichash( 'salt0') == pysodium.crypto_generichash( 'salt1')
True
>>> pysodium.crypto_generichash(b'salt0') == pysodium.crypto_generichash(b'salt1')
False
>>>
observe that only the type of the salt[01]
input changed from str to byte, and only for bytes it gives the correct output.
may hastur haunt the dreams of those responsible for py3 string "handling"
Hello,
I can not find the "detached" variants of the functions crypto_secretbox_detached
and crypto_secretbox_open_detached
.
Is it possible to add this two functions?
Hi,
I do not want to install libsodium and pysodium system-wide. Is it possible to include libsodium from a custom path? At the moment I get this error. I guess that libsodium is not found by pysodium.
['/Users/xxx/Projekte/catmail/client', '/Library/Python/2.7/site-packages/pip-1.4.1-py2.7.egg', '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python27.zip', '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7', '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-darwin', '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac', '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac/lib-scriptpackages', '/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python', '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk', '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-old', '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload', '/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC', '/Library/Python/2.7/site-packages', '../3rdparty/pysodium-build/lib/python2.7/site-packages/pysodium-0.6.7-py2.7.egg']
Traceback (most recent call last):
File "main.py", line 6, in <module>
import pysodium
File "build/bdist.macosx-10.11-intel/egg/pysodium/__init__.py", line 34, in <module>
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/ctypes/__init__.py", line 378, in __getattr__
func = self.__getitem__(name)
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/ctypes/__init__.py", line 383, in __getitem__
func = self._FuncPtr((name_or_ordinal, self))
AttributeError: dlsym(RTLD_DEFAULT, crypto_pwhash_scryptsalsa208sha256_strprefix): symbol not found
Thanks in advance!
Hello! I saw you added support for crypto_stream_xchacha20_xor a few months back, and was hoping you would publish a new version containing it to pypi soon. Any plans around that?
Thank you for your work on this project! It has made working with libsodium much more convenient for my work on pypaseto!
Some of the constants/functions added in bca3999 do not exist in earlier versions of libsodium, like the one I have from Ubuntu 16.04, which is version 1.0.8. I get an error like:
File "pysodium/__init__.py", line 144, in <module>
crypto_pwhash_scryptsalsa208sha256_BYTES_MIN = sodium.crypto_pwhash_scryptsalsa208sha256_bytes_min()
File "/usr/lib/python2.7/ctypes/__init__.py", line 375, in __getattr__
func = self.__getitem__(name)
File "/usr/lib/python2.7/ctypes/__init__.py", line 380, in __getitem__
func = self._FuncPtr((name_or_ordinal, self))
AttributeError: /usr/lib/x86_64-linux-gnu/libsodium.so.18: undefined symbol: crypto_pwhash_scryptsalsa208sha256_bytes_min
I don't have time to figure out each of them at the moment or I would have tried to make a PR.
I have installed pysodium system wide as root, so that it's available to all users. However, when importing pysodium, I'm getting an IOError:
IOError: [Errno 2] No such file or directory: '/usr/lib/python2.7/dist-packages/pysodium/__pycache__/_cffi__x298fef8bx9b9c1209.c'
It seems like the same kind of problem has occurred in PyNaCl:
pyca/pynacl#26
The problem seems to be the ffi.verify()
call in sodium.py
, which needs the further ext_package
parameter according to the CFFI documentation:
http://cffi.readthedocs.org/en/release-0.6/#distributing-modules-using-cffi
The problem should be easy to fix also for pysodium along a similar lilne:
abspoel/pynacl@1262633
Is there any reason those are left out? If not, I'd be happy to submit a PR.
AttributeError: module 'pysodium' has no attribute 'crypto_secretbox_open_easy'
https://doc.libsodium.org/secret-key_cryptography/secretbox#example
Sorry if this is a libsodium noob question - According to the libsodium docs crypto_secretbox_easy is the suggested method to use for symmetric encryption.
The _easy and _detached APIs are faster and improve usability by not requiring padding, copying or tricky pointer arithmetic.
Is it possible to use pysodium with crypto_secretbox_easy? Is it intentionally left out or is this something a pull request would be welcome for? If I understand correctly, it's possible to simply not use the _easy functions but it creates a barrier to entry for new users and makes porting code between languages harder without 1 to 1 mappings for libsodium.
Hello,
The PyPi package has version 0.7.0_0
, whereas this GitHub repository has version 0.7.0
. Reading [https://www.python.org/dev/peps/pep-0440/], I'm not convinced that this is a valid version. It says _ can be used as a separator for pre, post, dev and local releases, but the implication seems to be that there should be at least one alphabetic character before the number. In particular, using the VERSION_PATTERN
regexp in Appendix B does not produce a match for 0.7.0_0
.
(I realise this may sound a bit like mindless pedantry, but I have a reason for asking. I'm the Uploader for the Debian package of pysodium, and the upstream version is used to detect when there is a new upstream release, and to form the Debian version for the package.)
Thanks.
Christopher
Python 3 is becoming much more common.
Also the pysodium3
mentioned in ticket #2 does not exist (any more).
I've just given it a try by installing the GitHub master, and it installed just fine via python3 setup install
, and the 11 unit tests also ran fine using nosetests3
.
Personally, I have only done a very brief test of the module itself, but it did import in the interactive Python3 shell, and getting random numbers has worked as well.
According to the revision history, a commit 5cd2f4a20d72fb31655908d0e6a05c6204abe4ab
was supposed to provide some Py3 support.
It would be nice if this package could also be made available to PyPI, which currently only hosts version 0.6.5.1 for Python 2.x.
I'm not familiar with the libsodium API yet, but on my OS the generichash functions fail with a segfault because you're doing a bit of weird pointer math to convert state pointers to statealign? Never seen this, but here's a diff that seems to make it run clean on my OSX system:
--- a/pysodium/__init__.py
+++ b/pysodium/__init__.py
@@ -163,24 +163,18 @@ def crypto_generichash(m, k=b'', outlen=crypto_generichash_BYTES):
#crypto_generichash_init(crypto_generichash_state *state, const unsigned char *key, const size_t keylen, const size_t outlen);
def crypto_generichash_init(outlen=crypto_generichash_BYTES, k=b''):
state = ctypes.create_string_buffer(crypto_generichash_state)
- statealign = ctypes.addressof(state) + 63
- statealign ^= statealign & 63
- sodium.crypto_generichash_init(statealign, k, ctypes.c_size_t(len(k)), ctypes.c_size_t(outlen))
+ sodium.crypto_generichash_init(state, k, ctypes.c_size_t(len(k)), ctypes.c_size_t(outlen))
return state
#crypto_generichash_update(crypto_generichash_state *state, const unsigned char *in, unsigned long long inlen);
def crypto_generichash_update(state, m):
- statealign = ctypes.addressof(state) + 63
- statealign ^= statealign & 63
- sodium.crypto_generichash_update(statealign, m, ctypes.c_ulonglong(len(m)))
+ sodium.crypto_generichash_update(state, m, ctypes.c_ulonglong(len(m)))
return state
#crypto_generichash_final(crypto_generichash_state *state, unsigned char *out, const size_t outlen);
def crypto_generichash_final(state, outlen=crypto_generichash_BYTES):
- statealign = ctypes.addressof(state) + 63
- statealign ^= statealign & 63
buf = ctypes.create_string_buffer(outlen)
- sodium.crypto_generichash_final(statealign, buf, ctypes.c_size_t(outlen))
+ sodium.crypto_generichash_final(state, buf, ctypes.c_size_t(outlen))
return buf.raw
def randombytes(size):
I imagine I'm not familiar with ctypes or libsodium enough to know why you did this, so rather than a pull request I'll just submit this diff and let you figure out the next step.
Could you add wrappers for crypto_box_seal() and crypto_box_seal_open() ?
These were added in libsodium 1.03: https://download.libsodium.org/doc/public-key_cryptography/sealed_boxes.html
/Sune
Given #111 and the hopeful upcoming fix I wanted to add to my code a version check where I could kludge a value for where pysodium.crypto_secretstream_xchacha20poly1305_MESSAGEBYTES_MAX.value
is broken and use it where it is fixed but there appears to be no way to do that programmatically.
Could this be added, please?
Is it possible that keypair derivation (crypto_box_seed_keypair
in libsodium) is not implemented yet?
crypto_box
is equivalent to crypto_box_easy
in libsodium?
Thanks in advance!
I don't see a license file here. How is this software licensed?
Thanks!
Can you say something about your code and the GIL? Does it release the GIL while doing crypto?
Would be good for multithreaded Python code, so in can use more cores.
pysodium seems to be missing wrappers for the functions documented at http://doc.libsodium.org/password_hashing/index.html
Could you update the python package index with the latest from master?
I'd really like to use the crypto_auth functions and it looks like the index hasn't been updated since 2016-06-02 (the functions were merged into master at commit b7e60d8 => Jun 27, 2016)
The second and fourth parameters are size_t, but they're passed as ctypes.c_uint, causing a crash on 64-bit Windows.
Hi, 2to3 runs cleanly on current pysodium - please apply it! Thanks!
Hey thanks for starting this!
On my box the hash functions cause core dumps. Here's why..
compilers from version to version will compile structures differently, and some types the size of a 'size_t' type might be 4 or 8 bytes.. On my box the
printf("%d\n", sizeof(struct crypto_generichash_blake2b_state));
is 361
I think you have it as 357 or something (hardcoded in python).. python gets very unhappy and core dumps. boo.
I'm not that familiar with ctypes (and sorry you switched from FFI), so I'm not sure if there is a nice way to find the size programmatically. if so use that.. otherwise, making it 361 won't hurt (will just waste a few bytes of space otherwise).
thanks again!
nickg
Do you intend to support the crypto_secretstream* functions, or is there another straightforward way to encrypt streams and large files without having the whole thing in memory?
Hi,
Yesterday I had the unpleasant surprise to find my app non-working after the update of pysodium to 0.6.9.
After a bit I found that the introduction of the aead* function was the root of the problem.
I'm on FreeBSD and the libsodium package is still 1.0.8 (aead* functions where introduced in 1.0.9).
So we have two possibility :
I will happily provide a patch depending on which way you prefer.
Cheers,
The test_crypto_generichash test fails when using pysodium with libsodium 1.0.13 (as packaged for Debian Sid):
python -m unittest discover -v
test_AsymCrypto_With_Seeded_Keypair (test.test_pysodium.TestPySodium) ... ok
test_aead_chacha20poly1305 (test.test_pysodium.TestPySodium) ... ok
test_aead_chacha20poly1305_detached (test.test_pysodium.TestPySodium) ... ok
test_aead_chacha20poly1305_ietf (test.test_pysodium.TestPySodium) ... ok
test_crypto_auth (test.test_pysodium.TestPySodium) ... ok
test_crypto_blake2b (test.test_pysodium.TestPySodium) ... ok
test_crypto_box_open (test.test_pysodium.TestPySodium) ... ok
test_crypto_box_open_afternm (test.test_pysodium.TestPySodium) ... ok
test_crypto_box_open_detached (test.test_pysodium.TestPySodium) ... ok
test_crypto_box_pk_from_sk (test.test_pysodium.TestPySodium) ... ok
test_crypto_box_seal (test.test_pysodium.TestPySodium) ... ok
test_crypto_generichash (test.test_pysodium.TestPySodium) ... *** Error in `python': double free or corruption (!prev): 0x0000003da50920b0 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x70bfb)[0x7fc7ccd26bfb]
/lib/x86_64-linux-gnu/libc.so.6(+0x76fc6)[0x7fc7ccd2cfc6]
/lib/x86_64-linux-gnu/libc.so.6(+0x7780e)[0x7fc7ccd2d80e]
/usr/lib/python2.7/lib-dynload/_ctypes.x86_64-linux-gnu.so(+0x11a03)[0x7fc7cc748a03]
python(+0x138243)[0x3da3a72243]
python(PyEval_EvalFrameEx+0x60c1)[0x3da3a3f671]
python(PyEval_EvalFrameEx+0x5e5f)[0x3da3a3f40f]
python(PyEval_EvalCodeEx+0x255)[0x3da3a37da5]
python(+0x11a5c8)[0x3da3a545c8]
python(PyObject_Call+0x43)[0x3da3a26163]
python(PyEval_EvalFrameEx+0x2eeb)[0x3da3a3c49b]
python(PyEval_EvalCodeEx+0x255)[0x3da3a37da5]
python(+0x11a40e)[0x3da3a5440e]
python(PyObject_Call+0x43)[0x3da3a26163]
python(+0x12fd7e)[0x3da3a69d7e]
python(PyObject_Call+0x43)[0x3da3a26163]
python(+0x19071b)[0x3da3aca71b]
python(PyObject_Call+0x43)[0x3da3a26163]
python(PyEval_EvalFrameEx+0x6072)[0x3da3a3f622]
python(PyEval_EvalCodeEx+0x255)[0x3da3a37da5]
python(+0x11a5c8)[0x3da3a545c8]
python(PyObject_Call+0x43)[0x3da3a26163]
python(PyEval_EvalFrameEx+0x2eeb)[0x3da3a3c49b]
python(PyEval_EvalCodeEx+0x255)[0x3da3a37da5]
python(+0x11a40e)[0x3da3a5440e]
python(PyObject_Call+0x43)[0x3da3a26163]
python(+0x12fd7e)[0x3da3a69d7e]
python(PyObject_Call+0x43)[0x3da3a26163]
python(+0x19071b)[0x3da3aca71b]
python(PyObject_Call+0x43)[0x3da3a26163]
python(PyEval_EvalFrameEx+0x6072)[0x3da3a3f622]
python(PyEval_EvalCodeEx+0x255)[0x3da3a37da5]
python(+0x11a5c8)[0x3da3a545c8]
python(PyObject_Call+0x43)[0x3da3a26163]
python(PyEval_EvalFrameEx+0x2eeb)[0x3da3a3c49b]
python(PyEval_EvalCodeEx+0x255)[0x3da3a37da5]
python(+0x11a40e)[0x3da3a5440e]
python(PyObject_Call+0x43)[0x3da3a26163]
python(+0x12fd7e)[0x3da3a69d7e]
python(PyObject_Call+0x43)[0x3da3a26163]
python(+0x19071b)[0x3da3aca71b]
python(PyObject_Call+0x43)[0x3da3a26163]
python(PyEval_EvalFrameEx+0x6072)[0x3da3a3f622]
python(PyEval_EvalCodeEx+0x255)[0x3da3a37da5]
python(+0x11a5c8)[0x3da3a545c8]
python(PyObject_Call+0x43)[0x3da3a26163]
python(PyEval_EvalFrameEx+0x2eeb)[0x3da3a3c49b]
python(PyEval_EvalCodeEx+0x255)[0x3da3a37da5]
python(+0x11a40e)[0x3da3a5440e]
python(PyObject_Call+0x43)[0x3da3a26163]
python(+0x12fd7e)[0x3da3a69d7e]
python(PyObject_Call+0x43)[0x3da3a26163]
python(+0x19071b)[0x3da3aca71b]
python(PyObject_Call+0x43)[0x3da3a26163]
python(PyEval_EvalFrameEx+0x6072)[0x3da3a3f622]
python(PyEval_EvalFrameEx+0x5e5f)[0x3da3a3f40f]
python(PyEval_EvalFrameEx+0x5e5f)[0x3da3a3f40f]
python(PyEval_EvalCodeEx+0x255)[0x3da3a37da5]
python(+0x11a5c8)[0x3da3a545c8]
python(PyObject_Call+0x43)[0x3da3a26163]
python(+0x12fd7e)[0x3da3a69d7e]
python(PyObject_Call+0x43)[0x3da3a26163]
python(+0x12fac7)[0x3da3a69ac7]
======= Memory map: ========
3da393a000-3da3c55000 r-xp 00000000 fd:01 925115 /usr/bin/python2.7
3da3e55000-3da3e57000 r--p 0031b000 fd:01 925115 /usr/bin/python2.7
3da3e57000-3da3ece000 rw-p 0031d000 fd:01 925115 /usr/bin/python2.7
3da3ece000-3da3ef1000 rw-p 00000000 00:00 0
3da4ef6000-3da50cb000 rw-p 00000000 00:00 0 [heap]
7fc7c4000000-7fc7c4021000 rw-p 00000000 00:00 0
7fc7c4021000-7fc7c8000000 ---p 00000000 00:00 0
7fc7cb726000-7fc7cb73c000 r-xp 00000000 fd:01 1052156 /lib/x86_64-linux-gnu/libgcc_s.so.1
7fc7cb73c000-7fc7cb93b000 ---p 00016000 fd:01 1052156 /lib/x86_64-linux-gnu/libgcc_s.so.1
7fc7cb93b000-7fc7cb93c000 r--p 00015000 fd:01 1052156 /lib/x86_64-linux-gnu/libgcc_s.so.1
7fc7cb93c000-7fc7cb93d000 rw-p 00016000 fd:01 1052156 /lib/x86_64-linux-gnu/libgcc_s.so.1
7fc7cb93d000-7fc7cb9aa000 r-xp 00000000 fd:01 920478 /usr/lib/x86_64-linux-gnu/libsodium.so.18.3.0
7fc7cb9aa000-7fc7cbbaa000 ---p 0006d000 fd:01 920478 /usr/lib/x86_64-linux-gnu/libsodium.so.18.3.0
7fc7cbbaa000-7fc7cbbab000 r--p 0006d000 fd:01 920478 /usr/lib/x86_64-linux-gnu/libsodium.so.18.3.0
7fc7cbbab000-7fc7cbbac000 rw-p 0006e000 fd:01 920478 /usr/lib/x86_64-linux-gnu/libsodium.so.18.3.0
7fc7cbbac000-7fc7cbe0d000 r-xp 00000000 fd:01 920381 /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
7fc7cbe0d000-7fc7cc00d000 ---p 00261000 fd:01 920381 /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
7fc7cc00d000-7fc7cc02b000 r--p 00261000 fd:01 920381 /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
7fc7cc02b000-7fc7cc039000 rw-p 0027f000 fd:01 920381 /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
7fc7cc039000-7fc7cc03c000 rw-p 00000000 00:00 0
7fc7cc03c000-7fc7cc09d000 r-xp 00000000 fd:01 920382 /usr/lib/x86_64-linux-gnu/libssl.so.1.1
7fc7cc09d000-7fc7cc29d000 ---p 00061000 fd:01 920382 /usr/lib/x86_64-linux-gnu/libssl.so.1.1
7fc7cc29d000-7fc7cc2a1000 r--p 00061000 fd:01 920382 /usr/lib/x86_64-linux-gnu/libssl.so.1.1
7fc7cc2a1000-7fc7cc2a7000 rw-p 00065000 fd:01 920382 /usr/lib/x86_64-linux-gnu/libssl.so.1.1
7fc7cc2a7000-7fc7cc2ac000 r-xp 00000000 fd:01 156 /usr/lib/python2.7/lib-dynload/_hashlib.x86_64-linux-gnu.so
7fc7cc2ac000-7fc7cc4ac000 ---p 00005000 fd:01 156 /usr/lib/python2.7/lib-dynload/_hashlib.x86_64-linux-gnu.so
7fc7cc4ac000-7fc7cc4ad000 r--p 00005000 fd:01 156 /usr/lib/python2.7/lib-dynload/_hashlib.x86_64-linux-gnu.so
7fc7cc4ad000-7fc7cc4ae000 rw-p 00006000 fd:01 156 /usr/lib/python2.7/lib-dynload/_hashlib.x86_64-linux-gnu.so
7fc7cc4ae000-7fc7cc52e000 rw-p 00000000 00:00 0
7fc7cc52e000-7fc7cc535000 r-xp 00000000 fd:01 921918 /usr/lib/x86_64-linux-gnu/libffi.so.6.0.4
7fc7cc535000-7fc7cc735000 ---p 00007000 fd:01 921918 /usr/lib/x86_64-linux-gnu/libffi.so.6.0.4
7fc7cc735000-7fc7cc736000 r--p 00007000 fd:01 921918 /usr/lib/x86_64-linux-gnu/libffi.so.6.0.4
7fc7cc736000-7fc7cc737000 rw-p 00008000 fd:01 921918 /usr/lib/x86_64-linux-gnu/libffi.so.6.0.4
7fc7cc737000-7fc7cc756000 r-xp 00000000 fd:01 151 /usr/lib/python2.7/lib-dynload/_ctypes.x86_64-linux-gnu.so
7fc7cc756000-7fc7cc955000 ---p 0001f000 fd:01 151 /usr/lib/python2.7/lib-dynload/_ctypes.x86_64-linux-gnu.so
7fc7cc955000-7fc7cc956000 r--p 0001e000 fd:01 151 /usr/lib/python2.7/lib-dynload/_ctypes.x86_64-linux-gnu.so
7fc7cc956000-7fc7cc95a000 rw-p 0001f000 fd:01 151 /usr/lib/python2.7/lib-dynload/_ctypes.x86_64-linux-gnu.so
7fc7cc95a000-7fc7ccb1b000 rw-p 00000000 00:00 0
7fc7ccb1b000-7fc7cccb6000 r--p 00000000 fd:01 920361 /usr/lib/locale/locale-archive
7fc7cccb6000-7fc7cce49000 r-xp 00000000 fd:01 1048732 /lib/x86_64-linux-gnu/libc-2.24.so
7fc7cce49000-7fc7cd049000 ---p 00193000 fd:01 1048732 /lib/x86_64-linux-gnu/libc-2.24.so
7fc7cd049000-7fc7cd04d000 r--p 00193000 fd:01 1048732 /lib/x86_64-linux-gnu/libc-2.24.so
7fc7cd04d000-7fc7cd04f000 rw-p 00197000 fd:01 1048732 /lib/x86_64-linux-gnu/libc-2.24.so
7fc7cd04f000-7fc7cd053000 rw-p 00000000 00:00 0
7fc7cd053000-7fc7cd156000 r-xp 00000000 fd:01 1048738 /lib/x86_64-linux-gnu/libm-2.24.so
7fc7cd156000-7fc7cd355000 ---p 00103000 fd:01 1048738 /lib/x86_64-linux-gnu/libm-2.24.so
7fc7cd355000-7fc7cd356000 r--p 00102000 fd:01 1048738 /lib/x86_64-linux-gnu/libm-2.24.so
7fc7cd356000-7fc7cd357000 rw-p 00103000 fd:01 1048738 /lib/x86_64-linux-gnu/libm-2.24.so
7fc7cd357000-7fc7cd370000 r-xp 00000000 fd:01 1048688 /lib/x86_64-linux-gnu/libz.so.1.2.8
7fc7cd370000-7fc7cd56f000 ---p 00019000 fd:01 1048688 /lib/x86_64-linux-gnu/libz.so.1.2.8
7fc7cd56f000-7fc7cd570000 r--p 00018000 fd:01 1048688 /lib/x86_64-linux-gnu/libz.so.1.2.8
7fc7cd570000-7fc7cd571000 rw-p 00019000 fd:01 1048688 /lib/x86_64-linux-gnu/libz.so.1.2.8
7fc7cd571000-7fc7cd573000 r-xp 00000000 fd:01 1086745 /lib/x86_64-linux-gnu/libutil-2.24.so
7fc7cd573000-7fc7cd772000 ---p 00002000 fd:01 1086745 /lib/x86_64-linux-gnu/libutil-2.24.so
7fc7cd772000-7fc7cd773000 r--p 00001000 fd:01 1086745 /lib/x86_64-linux-gnu/libutil-2.24.so
7fc7cd773000-7fc7cd774000 rw-p 00002000 fd:01 1086745 /lib/x86_64-linux-gnu/libutil-2.24.so
7fc7cd774000-7fc7cd776000 r-xp 00000000 fd:01 1048736 /lib/x86_64-linux-gnu/libdl-2.24.so
7fc7cd776000-7fc7cd976000 ---p 00002000 fd:01 1048736 /lib/x86_64-linux-gnu/libdl-2.24.so
7fc7cd976000-7fc7cd977000 r--p 00002000 fd:01 1048736 /lib/x86_64-linux-gnu/libdl-2.24.so
7fc7cd977000-7fc7cd978000 rw-p 00003000 fd:01 1048736 /lib/x86_64-linux-gnu/libdl-2.24.so
7fc7cd978000-7fc7cd990000 r-xp 00000000 fd:01 1086737 /lib/x86_64-linux-gnu/libpthread-2.24.so
7fc7cd990000-7fc7cdb8f000 ---p 00018000 fd:01 1086737 /lib/x86_64-linux-gnu/libpthread-2.24.so
7fc7cdb8f000-7fc7cdb90000 r--p 00017000 fd:01 1086737 /lib/x86_64-linux-gnu/libpthread-2.24.so
7fc7cdb90000-7fc7cdb91000 rw-p 00018000 fd:01 1086737 /lib/x86_64-linux-gnu/libpthread-2.24.so
7fc7cdb91000-7fc7cdb95000 rw-p 00000000 00:00 0
7fc7cdb95000-7fc7cdbb8000 r-xp 00000000 fd:01 1048725 /lib/x86_64-linux-gnu/ld-2.24.so
7fc7cdbdd000-7fc7cdc9d000 rw-p 00000000 00:00 0
7fc7cdcce000-7fc7cdd92000 rw-p 00000000 00:00 0
7fc7cddb3000-7fc7cddb4000 rw-p 00000000 00:00 0
7fc7cddb4000-7fc7cddb5000 rwxp 00000000 00:00 0
7fc7cddb5000-7fc7cddb8000 rw-p 00000000 00:00 0
7fc7cddb8000-7fc7cddb9000 r--p 00023000 fd:01 1048725 /lib/x86_64-linux-gnu/ld-2.24.so
7fc7cddb9000-7fc7cddba000 rw-p 00024000 fd:01 1048725 /lib/x86_64-linux-gnu/ld-2.24.so
7fc7cddba000-7fc7cddbb000 rw-p 00000000 00:00 0
7ffe9df70000-7ffe9df91000 rw-p 00000000 00:00 0 [stack]
7ffe9df9a000-7ffe9df9c000 r--p 00000000 00:00 0 [vvar]
7ffe9df9c000-7ffe9df9e000 r-xp 00000000 00:00 0 [vdso]
Aborted
Thanks.
Not all of the crypto_aead_chacha20poly1305_* functions accept None
for ad
.
Has support:
Doesn't have support:
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.