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
This should be fixed now.
Kurt
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
This should be fixed now.
Kurt
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>> 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:
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
$
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
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
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
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
