Re: [openssl-dev] [openssl.org #3910] [PATCH] Build correctly when no_des option is enabled
On Sun, Jun 14, 2015 at 11:59:59PM +, 84.le0n via RT wrote: > > I've had the same problem Osvaldo Calles had when building OpenSSL with > no-des option enabled . > This patch simply add an #ifndef around the first if clause avoiding > EVP_des_ede3_wrap call. This at least causes a test suite error: /usr/bin/perl cms-test.pl CMS => PKCS#7 compatibility tests signed content DER format, RSA key: OK signed detached content DER format, RSA key: OK signed content test streaming BER format, RSA: OK signed content DER format, DSA key: OK signed detached content DER format, DSA key: OK signed detached content DER format, add RSA signer: OK signed content test streaming BER format, DSA key: OK signed content test streaming BER format, 2 DSA and 2 RSA keys: OK signed content test streaming BER format, 2 DSA and 2 RSA keys, no attributes: OK signed content test streaming S/MIME format, 2 DSA and 2 RSA keys: OK signed content test streaming multipart S/MIME format, 2 DSA and 2 RSA keys: OK enveloped content test streaming S/MIME format, 3 recipients: generation error Makefile:334: recipe for target 'test_cms' failed make[1]: *** [test_cms] Error 1 I'm not sure what that code is trying to do, so I wonder if we should return an error in case EVP_CIPHER_type(cipher) == NID_des_ede3_cbc but OPENSSL_NO_DES is defined. Kurt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4110] [PATCH] fix ssl_new() error handling on out of memory condition
This should be fixed now. Kurt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4111] [PATCH] fix ssl3_free NULL dereference on out of memory condition
This should be fixed now. Kurt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [libcrypto EVP] valgrind reports many memory leaks in wiki-example
>> Attached is the valgrind-output. It says: >>34 not-freed blocks The sample program doesn't clean up everything. Look at the function apps_shutdown in apps/openssl.c (in master) ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [libcrypto EVP] valgrind reports many memory leaks in wiki-example
U.Mutlu wrote on 11/23/2015 06:43 AM: U.Mutlu wrote on 11/23/2015 06:32 AM: Hi, running the following example from the openssl wiki site under valgrind gives many memory-leaks in the underlying library functions: https://wiki.openssl.org/index.php/EVP_Symmetric_Encryption_and_Decryption $ valgrind --tool=memcheck --leak-check=full --show-leak-kinds=all --track-origins=yes -v ./a.out &>valgrind-output.txt Attached is the valgrind-output. It says: 34 not-freed blocks Are these maybe false-positives? The leak summary in the output says this: ==9895== LEAK SUMMARY: ==9895==definitely lost: 0 bytes in 0 blocks ==9895==indirectly lost: 0 bytes in 0 blocks ==9895== possibly lost: 0 bytes in 0 blocks ==9895==still reachable: 2,632 bytes in 34 blocks ==9895== suppressed: 0 bytes in 0 blocks Has nobody a clue what the above output means? ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback
On Friday 20 November 2015 12:58:59 John Denker wrote: > On 11/19/2015 12:28 PM, Viktor Dukhovni wrote: > > What algorithms people use on > > their own data is their choice and risk decision not ours. > > To say the same thing yet another way, fundamentally we have a > communication problem, or rather two separate communication > problems: > A) The experts on this list know that certain crypto primitives > are "broken or outdated". This needs to be communicated to the > people who are actually in a position to make and implement > policy. > B) There is some question as to whether users in the field have > received message (A) and successfully ended all use of the > deprecated primitives. It would be nice if the people who > know the status could communicate this back to the developers. There are certain situations in which using "broken or outdated" algorithms is both secure and unavoidable. See my email from Wed, 18 Nov 2015 14:05:07 +0100. And to repeat myself: TLS is *not* the only way OpenSSL is used. -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: This is a digitally signed message part. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread
On 23/11/15 20:34, Matt Caswell wrote: > On 23/11/15 17:49, Nico Williams wrote: > >> Still, if -lpthread avoidance were still desired, you'd have to find an >> alternative to pthread_key_create(), pthread_getspecific(), and friends. > > Just a point to note about this. The async code that introduced this has > 3 different implementations: > > - posix > - windows > - null > > The detection code will check if you have a suitable posix or windows > implementation and use that. Otherwise the fallback position is to use > the null implementation. With "null" everything will compile and run but > you won't be able to use any of the new async functionality. I hope there will be the ability to plug in different operating systems and it's not hard coded to just these choices. There are embedded systems which use OpenSSL which do not have POSIX thread APIs (POSIX is very heavyweight for many). For example, GCC abstracts their threading dependenencies with a "gthread" API which OS implementers can write against. What would be bad would be direct calls to pthread* dotted around the OpenSSL code base. > One other option we could pursue is to use the "__thread" syntax for > thread local variables and avoid the need for libpthread altogether. An > earlier version of the code did this. I have not found a way to reliably > detect at compile time the capability to do this and my understanding is > that this is a lot less portable. Behind the scenes, if pthreads are available on an OS, then the compiler will probably just end up using pthread functions anyway, meaning there's no advantage over having just linked against libpthread. Jifl -- eCosCentric Limited http://www.eCosCentric.com/ The eCos experts Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571 Registered in England and Wales: Reg No 4422071. --["Si fractum non sit, noli id reficere"]-- Opinions==mine ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #4155] In function int_thread_del_item, when hash == int_thread_hash, one is passed to free and the other is used in a comparison
This issue is similar in nature to 4151 (http://www.mail-archive.com/openssl-dev@openssl.org/msg40950.html ): it is about a dangling pointer being used, but not used for dereferencing, so it's not a memory error. The dangling pointer is used in a comparison. The function int_thread_del_item can reach the point were it calls “lh_ERR_STATE_free(int_thread_hash);” with hash == int_thread_hash. That attached patch prints a message like “hash == int_thread_hash == 0xb2a6d0” when this happens. Just after the call to lh_ERR_STATE_free, both hash and int_thread_hash contain dangling pointers. The variable int_thread_hash is immediately set to NULL. The problem that I am reporting is that just afterwards, is passed to the function int_thread_release: https://github.com/openssl/openssl/blob/079a1a9014b89661f0a612a5a9724ad9c77f21a3/crypto/err/err.c#L412 In that function, the argument “hash” points to the local variable “hash” of int_thread_del_item (which contains a dangling pointer). Thus the comparison “*hash == NULL” involves a dangling pointer: https://github.com/openssl/openssl/blob/079a1a9014b89661f0a612a5a9724ad9c77f21a3/crypto/err/err.c#L343 With the attached patch, executing test/enginetest reproduces the problem for me: $ ./enginetest enginetest beginning … Tests completed happily hash == int_thread_hash == 0x1a3f6d0 Now using *hash (0x1a3f6d0) in a comparison show_pointers.patch Description: Binary data ___ openssl-bugs-mod mailing list openssl-bugs-...@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread
On 24/11/15 15:16, Jonathan Larmour wrote: > On 23/11/15 20:34, Matt Caswell wrote: >> On 23/11/15 17:49, Nico Williams wrote: >> >>> Still, if -lpthread avoidance were still desired, you'd have to find an >>> alternative to pthread_key_create(), pthread_getspecific(), and friends. >> >> Just a point to note about this. The async code that introduced this has >> 3 different implementations: >> >> - posix >> - windows >> - null >> >> The detection code will check if you have a suitable posix or windows >> implementation and use that. Otherwise the fallback position is to use >> the null implementation. With "null" everything will compile and run but >> you won't be able to use any of the new async functionality. > > I hope there will be the ability to plug in different operating systems > and it's not hard coded to just these choices. There are embedded systems > which use OpenSSL which do not have POSIX thread APIs (POSIX is very > heavyweight for many). > > For example, GCC abstracts their threading dependenencies with a "gthread" > API which OS implementers can write against. What would be bad would be > direct calls to pthread* dotted around the OpenSSL code base. We are talking specifically about the new async functionality here. The three implementations are all you get for that. That has no impact on the rest of OpenSSL functionality. So if you happen to be on a non-posix and non-windows platform then OpenSSL will function as it does today. You just don't get the new async functionality on top. There are pthread references in one (internal) header file and one c source code file. If the new threading API discussed elsewhere in this thread goes ahead, then those references would be replaced with calls to that instead. Matt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
