392002484d
Merge pull request #2 from bithin/patch-1
...
StringIO was imported twice.
2012-02-09 12:30:37 -08:00
faf9629804
StringIO was imported twice.
2012-02-09 16:05:16 +05:30
44ea3f0b03
Updating setup.py to build properly on FreeBSD
2010-03-22 05:03:40 -07:00
1920cf75cd
Build a dylib on Darwin
2009-07-12 17:26:10 -07:00
bd7b33e66e
Add the ability to compile libseccure with 'slow' random, i.e. /dev/random instead of /dev/urandom
2009-07-10 14:51:51 -07:00
29bc27f854
Remove the docs directory for now, going to bring it back under gh-pages
2009-07-09 20:21:22 -07:00
1aa1382138
Update licensing on the seccure code, moving to LGPL thanks to B. Poettering
2009-07-09 20:21:13 -07:00
2f233b8d4e
Remove NULL returns in non-exception error conditions
2009-07-08 14:56:47 -07:00
270593d49c
Make sure the state and keypair objects are freed post-iterations as well
2009-07-08 13:45:36 -07:00
a8da85fc64
Run loops over reading and encrypting the same sizes of data
2009-07-08 01:18:24 -07:00
4c8353d1e4
Compare memory regions, just to be safe
2009-07-08 01:14:28 -07:00
216f5bc10d
Add a small test binary to encrypt random data *a lot*
2009-07-08 01:08:31 -07:00
a603a31daa
Prevent accidental attempts to re-initialize the secure memory pool
...
Also disabling the termination of the secure memory pool, once terminated
the memory pool cannot be revived for the life of the process.
2009-07-07 16:56:12 -07:00
a27592b5cc
Author info
2009-07-07 14:55:33 -07:00
b941e5cd9b
Add some basic README junk
2009-07-07 14:53:46 -07:00
fe51db906c
Move the markdwon readme to reStructured text
2009-07-07 14:47:09 -07:00
1c26e1db55
Add basic Sphinx-based documentation
2009-07-07 14:43:58 -07:00
1f9568b99a
Compile, *then* commit. Stupid semi-colons
2009-07-07 12:22:42 -07:00
b9d319695e
Missing jumps to return early from the function
2009-07-07 12:14:05 -07:00
fe1701e05d
Free the decrypted data object in the test as well
2009-07-07 12:13:21 -07:00
ecfde56e57
Ensure we're not inadvertantly returning a half-allocated ECC_Data struct
2009-07-07 11:57:02 -07:00
c6442de86a
Cleanup the encrypt test, add a couple more assertions to be safe
2009-07-07 11:56:47 -07:00
578c5b7a04
Forgot to remove the no-longer necessary assertion in ECC.encrypt()
2009-07-07 11:20:10 -07:00
debcea0d43
Make sure we're relying on the C API for the string length instead of len() which will only read to a NULL byte
2009-07-07 11:16:52 -07:00
378b80fd6a
Add a couple error condition tests
2009-07-07 11:16:22 -07:00
5057d4028e
Add a simplistic GC test case
2009-07-06 10:12:51 -07:00
6994400add
Reduce the number of loops, no need to run as many now that debugging is over
2009-07-06 10:12:24 -07:00
fc99bcd337
Add a wee bit more documentation
2009-07-06 10:02:39 -07:00
ac24a736af
Add some malloc() error checking
2009-07-06 08:02:17 -07:00
7be6b1b247
Fix a bad cast caught with clang(1)
2009-07-06 06:08:11 -07:00
cf6646f6b9
Add a *lot* more loops to find more leaks
2009-07-06 05:33:48 -07:00
9f65db74b0
Forcefully end the decrypted data string with a null byte
...
Lest we have allocated a segment in non-nullbyted (yes, nullbyted)
memory, and have garbage trailing off the end of the string.
2009-07-06 05:32:52 -07:00
612e112938
Set data member to NULL to make sure we can conditionalize against it later
2009-07-06 04:48:50 -07:00
99dcb2a214
Print out the errno that's running around (for debug)
2009-07-06 04:48:26 -07:00
64ff45319d
Fix a leak underneath seccure's decompress_string() function (used heavily by ecc_encrypt())
...
The gist of what's happening, is that dezerialize_mpi() gives us an (N) MPI which
an affine_point struct's x,y are then assertained with. This N MPI was not
being properly released after P.x and P.y were calculated, resulting in libseccure
exhausting libgcrypt's secure memory pool.
Valgrind results (valgrind --tool=memcheck --leak-check=full --show-reachable=yes ./test_integration -p /integration/keygen_encryptsalot):
Before:
LEAK SUMMARY:
definitely lost: 7,208 bytes in 360 blocks.
indirectly lost: 17,363 bytes in 179 blocks.
possibly lost: 992 bytes in 2 blocks.
still reachable: 16,042 bytes in 85 blocks.
suppressed: 0 bytes in 0 blocks.
After:
LEAK SUMMARY:
definitely lost: 3,232 bytes in 201 blocks.
indirectly lost: 19,628 bytes in 208 blocks.
possibly lost: 992 bytes in 2 blocks.
still reachable: 15,447 bytes in 67 blocks.
suppressed: 0 bytes in 0 blocks.
2009-07-06 04:39:32 -07:00
19d0796a77
Document some of the usage of pointers, etc
2009-07-06 04:37:05 -07:00
469d8c55e4
Set point members to NULL, just in case >_>
2009-07-06 04:36:28 -07:00
927e807510
Print out an error message if our hmac init fails
2009-07-06 04:35:34 -07:00
f23f27e6fc
Add another test case to generate a boatload of keys
2009-07-02 11:29:43 -07:00
e6f02ae624
Print timestamps just for kicks
2009-07-02 10:50:44 -07:00
d9facbd6bb
The behavior of generating different encrypted results is correct
...
Switch the test to make sure we're generating the same length at least
2009-07-02 10:45:51 -07:00
310798b48d
Working on (currently failing) test to verify the ecc_encrypt() results' consistency
2009-07-02 10:33:27 -07:00
e5db992e29
Make sure we NULL the pointers after freeing
2009-07-02 10:33:20 -07:00
c33f0e64ac
Ensure ecc_serialize_private_key() is null-terminating our string
2009-07-01 15:15:33 -07:00
8eb6363b93
I find all these values informative, I'm printing them, ha!
2009-07-01 15:15:16 -07:00
7e65949e7b
Ensure the released pointer gets set to NULL, lest we double free! :(
2009-07-01 14:58:28 -07:00
1eb11436be
Minor bit of documentation on the returned tuple from py_keygen()
2009-07-01 14:01:36 -07:00
c04327333d
Use ecc_new_keypair_s() in py_new_keypair() since we're given the lengths by Python
2009-07-01 14:01:15 -07:00
2fcc6a76ae
Return the curve as the third parameter, not the keypair
2009-07-01 12:19:16 -07:00
4523a8785f
Remove Python bindings for generating a public key based on a user-specified public key
2009-07-01 12:18:53 -07:00
R. Tyler Croy
Bithin A
R. Tyler Ballance