RE: VOTE: OTC meeting will be called for next Tuesday

2020-09-30 Thread Dr. Matthias St. Pierre
> +1, but wondering why this needs a vote.

Because we decided to follow our own bylaws more closely. In particular the 
following two items:

> All OTC decisions are taken on the basis of a vote
https://www.openssl.org/policies/omc-bylaws.html#OTC

> ### OTC Transparency
> The majority of the activity of the OTC will take place in public.
https://www.openssl.org/policies/omc-bylaws.html#transparency


Matthias



> -Original Message-
> From: Kurt Roeckx 
> Sent: Wednesday, September 30, 2020 6:07 PM
> To: Dr. Matthias St. Pierre 
> Cc: openssl-project@openssl.org
> Subject: Re: VOTE: OTC meeting will be called for next Tuesday
> 
> On Wed, Sep 30, 2020 at 01:57:34PM +, Dr. Matthias St. Pierre wrote:
> > topic: OTC meeting will be called for next Tuesday
> 
> 
> 
> Kurt
> 




Re: VOTE: OTC meeting will be called for next Tuesday

2020-09-30 Thread Richard Levitte
+1

On Wed, 30 Sep 2020 15:57:34 +0200,
Dr. Matthias St. Pierre wrote:
> 
> The following vote has been proposed and voted on at the vF2F today:
> 
> topic: OTC meeting will be called for next Tuesday
> 
> It has been closed immediately by Tim, the verdict is
> 
> accepted:  yes  (for: 7, against: 0, abstained: 0, not voted: 4)
> 
> (Note: the OTC meeting will be held in place of the weekly OpenSSL 3.0 
> Planning
> meeting next Tuesday (2020-10-06) at 08:00 UTC. Pauli will send out a separate
> invitation to the OTC list.)
> 
> Matthias
> 
> 
> topic: OTC meeting will be called for next Tuesday (2020-10-06)
> Proposed by Matthias St. Pierre
> Public: yes
> opened: 2020-09-30
> closed: 2020-09-30
> accepted:  yes  (for: 7, against: 0, abstained: 0, not voted: 4)
> 
>   Matt   [+1]
>   Mark   [  ]
>   Pauli  [+1]
>   Viktor [  ]
>   Tim[+1]
>   Richard[+1]
>   Shane  [+1]
>   Tomas  [  ]
>   Kurt   [  ]
>   Matthias   [+1]
>   Nicola [+1]
> 
> 
-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/


Re: VOTE: OTC meeting will be called for next Tuesday

2020-09-30 Thread Kurt Roeckx
On Wed, Sep 30, 2020 at 01:57:34PM +, Dr. Matthias St. Pierre wrote:
> topic: OTC meeting will be called for next Tuesday

+1, but wondering why this needs a vote.


Kurt



Re: Integration of new algorithms

2020-09-30 Thread Kris Kwiatkowski
Hello,

In regards to OBJ_new_nid - yes, that's more or less what I already
do. I actually use OBJ_sn2nid() which, indeed calls a OBJ_new_nid().

But the problem that I've is different. In keygen (callback set by
EVP_PKEY_meth_set_keygen), there is no way to access NID. It seems
to be stored in the EVP_PKEY_CTX->pmeth->pkey_id, but there is
no way to read it (or at least I couldn't find any).
But, anyway - I've some sub-optimal solution, which uses
EVP_PKEY_meth_set_ctrl() to set scheme specific callback. Not
perfectly clean, but works perfectly well.

In regards to 3.0 - I've started to work on provider for PQ
schemes some time ago. Not finished yet, but indeed, it looks
easier/better. Nevertheless ENGINE for 1.1.1 is actually
something that is needed now for practical reasons (like integration
with existing software).

Kind regards,
Kris

On 9/30/20 8:05 AM, Dr Paul Dale wrote:
> Instead of using an engine, you should write a provider (assuming you’re
> using the soon to be released OpenSSL 3.0).  It doesn’t need a NID.
>
> If you are using OpenSSL 1.1.1, try the OBJ_new_nid() function.
>
>
> Pauli
> -- 
> Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
> Phone +61 7 3031 7217
> Oracle Australia
>
>
>
>
>> On 26 Aug 2020, at 6:48 pm, Kris Kwiatkowski > > wrote:
>>
>>
>> Hey,
>>
>> I'm working on development of OpenSSL ENGINE that integrates
>> post-quantum algorithms (new NIDs). During integration I
>> need to modify OpenSSL code to add custom function, but would
>> prefer not to need add anything to OpenSSL code (so engine
>> can be dynmicaly loaded by any modern OpenSSL).
>>
>> So, In three cases, namely when the code is in callbacks for keygen,
>> encryption and ctrl (called by EVP_PKEY_CTX_ctrl, EVP_PKEY_encrypt
>> and EVP_PKEY_keygen) I need to get NID of the scheme. The problem
>> is that, those functions are called with EVP_PKEY_CTX object
>> provided as an argument. The NID is stored in the
>> EVP_PKEY_CTX->pmeth->pkey_id. I think (AFAIK) there is no API
>> which would return that value.
>>
>> I've added a simple function that returns pkey_id from the ctx, but
>> that means that I need to change OpenSSL code. Is there any way
>> to get NID without changing OpenSSL?
>>
>> Kind regards,
>> Kris
>>
>>
>


Re: VOTE: OTC meeting will be called for next Tuesday

2020-09-30 Thread Tomas Mraz
+1

On Wed, 2020-09-30 at 13:57 +, Dr. Matthias St. Pierre wrote:
> The following vote has been proposed and voted on at the vF2F today:
> 
> topic: OTC meeting will be called for next Tuesday
> 
> It has been closed immediately by Tim, the verdict is
> 
> accepted:  yes  (for: 7, against: 0, abstained: 0, not voted: 4)
> 
> (Note: the OTC meeting will be held in place of the weekly OpenSSL
> 3.0 Planning
> meeting next Tuesday (2020-10-06) at 08:00 UTC. Pauli will send out a
> separate
> invitation to the OTC list.)
> 
> Matthias
> 
> 
> topic: OTC meeting will be called for next Tuesday (2020-10-06)
> Proposed by Matthias St. Pierre
> Public: yes
> opened: 2020-09-30
> closed: 2020-09-30
> accepted:  yes  (for: 7, against: 0, abstained: 0, not voted: 4)
> 
>   Matt   [+1]
>   Mark   [  ]
>   Pauli  [+1]
>   Viktor [  ]
>   Tim[+1]
>   Richard[+1]
>   Shane  [+1]
>   Tomas  [  ]
>   Kurt   [  ]
>   Matthias   [+1]
>   Nicola [+1]
> 
> 
-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]




Re: VOTE: OTC meeting will be called for next Tuesday

2020-09-30 Thread Mark J Cox
+1

On Wed, Sep 30, 2020 at 2:57 PM Dr. Matthias St. Pierre
 wrote:
>
> The following vote has been proposed and voted on at the vF2F today:
>
> topic: OTC meeting will be called for next Tuesday
>
> It has been closed immediately by Tim, the verdict is
>
> accepted:  yes  (for: 7, against: 0, abstained: 0, not voted: 4)
>
> (Note: the OTC meeting will be held in place of the weekly OpenSSL 3.0 
> Planning
> meeting next Tuesday (2020-10-06) at 08:00 UTC. Pauli will send out a separate
> invitation to the OTC list.)
>
> Matthias
>
> 
> topic: OTC meeting will be called for next Tuesday (2020-10-06)
> Proposed by Matthias St. Pierre
> Public: yes
> opened: 2020-09-30
> closed: 2020-09-30
> accepted:  yes  (for: 7, against: 0, abstained: 0, not voted: 4)
>
>   Matt   [+1]
>   Mark   [  ]
>   Pauli  [+1]
>   Viktor [  ]
>   Tim[+1]
>   Richard[+1]
>   Shane  [+1]
>   Tomas  [  ]
>   Kurt   [  ]
>   Matthias   [+1]
>   Nicola [+1]
>
>


VOTE: OTC meeting will be called for next Tuesday

2020-09-30 Thread Dr. Matthias St. Pierre
The following vote has been proposed and voted on at the vF2F today:

topic: OTC meeting will be called for next Tuesday

It has been closed immediately by Tim, the verdict is

accepted:  yes  (for: 7, against: 0, abstained: 0, not voted: 4)

(Note: the OTC meeting will be held in place of the weekly OpenSSL 3.0 Planning
meeting next Tuesday (2020-10-06) at 08:00 UTC. Pauli will send out a separate
invitation to the OTC list.)

Matthias


topic: OTC meeting will be called for next Tuesday (2020-10-06)
Proposed by Matthias St. Pierre
Public: yes
opened: 2020-09-30
closed: 2020-09-30
accepted:  yes  (for: 7, against: 0, abstained: 0, not voted: 4)

  Matt   [+1]
  Mark   [  ]
  Pauli  [+1]
  Viktor [  ]
  Tim[+1]
  Richard[+1]
  Shane  [+1]
  Tomas  [  ]
  Kurt   [  ]
  Matthias   [+1]
  Nicola [+1]




Re: Is OpenSSL 1.1.1g backward compatible with 1.0.2.f ?

2020-09-30 Thread Tomas Mraz
Hello,

unfortunately no, 1.1.1g is neither API nor ABI compatible with 1.0.2f.

You cannot directly replace 1.0.2f with 1.1.1g. The applications have
to support 1.1.1 release and be recompiled against it to work with it.

Regards,

Tomas Mraz

On Tue, 2020-09-22 at 14:08 +, Kapil Awate wrote:
> Hi,
>  
> Is OpenSSL 1.1.1g backward compatible with 1.0.2.f ? Can anyone help
> me with this ? Is there any impact on existing functionality after
> upgrading it to 1.1.1g ?
>  
> Thanks!
>  
> This email and any attachments thereto may contain private,
> confidential, and/or privileged material for the sole use of the
> intended recipient. Any review, copying, or distribution of this
> email (or any attachments thereto) by others is strictly prohibited.
> If you are not the intended recipient, please contact the sender
> immediately and permanently delete the original and any copies of
> this email and any attachments thereto.
-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]




Re: VOTE: Accept the OTC voting policy as defined:

2020-09-30 Thread Kurt Roeckx
On Mon, Sep 28, 2020 at 12:02:07PM +, Dr. Matthias St. Pierre wrote:
> topic: Accept the OTC voting policy as defined:
> 
>The proposer of a vote is ultimately responsible for updating the 
> votes.txt
>file in the repository.  Outside of a face to face meeting, voters 
> MUST reply
>to the vote email indicating their preference and optionally their 
> reasoning.
>Voters MAY update the votes.txt file in addition.
> 
>The proposed vote text SHOULD be raised for discussion before calling 
> the vote.
> 
>Public votes MUST be called on the project list, not the OTC list and 
> the
>subject MUST begin with "VOTE:".  Private votes MUST be called on the
>OTC list with "PRIVATE VOTE:" beginning subject.

+1


Kurt



Re: Memory leak in openssl 1.1.1d

2020-09-30 Thread Dr Paul Dale
This isn’t enough information to diagnose the issue.  Which of the leak summary 
records is the problem?
Are you sure that your application is cleaning up properly (hint: it isn’t, 
e.g. OpenSSL never calls operator new() from the second record).

Pauli
-- 
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
Phone +61 7 3031 7217
Oracle Australia




> On 10 Sep 2020, at 1:39 am, Abhi Arora  wrote:
> 
> I am using openssl 1.1.1d. I found out around 228 bytes are being directly 
> lost (as per valgrind) report. I have one application which uses curl (7.64) 
> and I wrote the same application using POCO HTTPS and I got the same result.
> 
> I thought it could be related to the cipher suit. I can see the leak is 
> dependent on the URL being used (all were https). For one of the urls, it was 
> leaking 228 (directly) per connection and disconnection. For one of the urls, 
> the same code doesn't leak atall (no matter how many times you run that code 
> in a for loop).
> 
> For the urls which were leaking, the following cipher suites were being used:
> 1. SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
> 2. SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
> 
> Here is the valgrind summary:
> ==8620== HEAP SUMMARY:
> ==8620== in use at exit: 121,777 bytes in 1,097 blocks
> ==8620==   total heap usage: 129,382 allocs, 128,285 frees, 10,635,842 bytes 
> allocated
> ==8620==
> ==8620== 8 bytes in 1 blocks are possibly lost in loss record 16 of 372
> ==8620==at 0x483EB28: malloc (vg_replace_malloc.c:307)
> ==8620==by 0x4E75523: ??? (in /usr/lib/libuamqp.so.1.2.12)
> ==8620==
> ==8620== 8 bytes in 1 blocks are definitely lost in loss record 17 of 372
> ==8620==at 0x483F310: operator new(unsigned int) (vg_replace_malloc.c:336)
> ==8620==by 0x36D15: main (sample_pki.cpp:27)
> ==8620==
> ==8620== 8 bytes in 1 blocks are definitely lost in loss record 18 of 372
> ==8620==at 0x483EB28: malloc (vg_replace_malloc.c:307)
> ==8620==by 0x4CBF14B: CRYPTO_zalloc (mem.c:230)
> ==8620==by 0x4C76E07: ECDSA_SIG_new (ec_asn1.c:1214)
> ==8620==by 0x537064B: pkcs11_try_pkey_ec_sign (p11_pkey.c:546)
> ==8620==by 0x537064B: pkcs11_pkey_ec_sign (p11_pkey.c:634)
> ==8620==by 0x4CB70CD: EVP_DigestSignFinal (m_sigver.c:148)
> ==8620==by 0x4BA9FF3: tls_construct_cert_verify (statem_lib.c:307)
> ==8620==by 0x4BA42C7: write_state_machine (statem.c:843)
> ==8620==by 0x4BA42C7: state_machine (statem.c:443)
> ==8620==by 0x4B8BABB: ssl3_read_bytes (rec_layer_s3.c:1278)
> ==8620==by 0x4B900E1: ssl3_read_internal (s3_lib.c:4473)
> ==8620==by 0x4B9013F: ssl3_read (s3_lib.c:4497)
> ==8620==by 0x4B96A6D: ssl_read_internal (ssl_lib.c:1761)
> ==8620==by 0x4B96B09: SSL_read (ssl_lib.c:1775)
> ==8620==
> ==8620== 16 bytes in 2 blocks are possibly lost in loss record 55 of 372
> ==8620==at 0x483EA30: malloc (vg_replace_malloc.c:306)
> ==8620==by 0x48419FF: realloc (vg_replace_malloc.c:834)
> ==8620==by 0x4E73B5D: amqpvalue_set_map_value (in 
> /usr/lib/libuamqp.so.1.2.12)
> ==8620==
> ==8620== 40 bytes in 10 blocks are possibly lost in loss record 182 of 372
> ==8620==at 0x483EA30: malloc (vg_replace_malloc.c:306)
> ==8620==by 0x48419FF: realloc (vg_replace_malloc.c:834)
> ==8620==by 0x4E738BB: amqpvalue_set_list_item (in 
> /usr/lib/libuamqp.so.1.2.12)
> ==8620==
> ==8620== 48 bytes in 1 blocks are possibly lost in loss record 210 of 372
> ==8620==at 0x483EB28: malloc (vg_replace_malloc.c:307)
> ==8620==by 0x4E7582D: ??? (in /usr/lib/libuamqp.so.1.2.12)
> ==8620==
> ==8620== 48 bytes in 2 blocks are possibly lost in loss record 211 of 372
> ==8620==at 0x48419B0: realloc (vg_replace_malloc.c:834)
> ==8620==by 0x4E73B5D: amqpvalue_set_map_value (in 
> /usr/lib/libuamqp.so.1.2.12)
> ==8620==
> ==8620== 56 bytes in 1 blocks are possibly lost in loss record 215 of 372
> ==8620==at 0x483EB28: malloc (vg_replace_malloc.c:307)
> ==8620==by 0x4E74FF9: ??? (in /usr/lib/libuamqp.so.1.2.12)
> ==8620==
> ==8620== 64 bytes in 2 blocks are possibly lost in loss record 228 of 372
> ==8620==at 0x483EB28: malloc (vg_replace_malloc.c:307)
> ==8620==by 0x4E74477: ??? (in /usr/lib/libuamqp.so.1.2.12)
> ==8620==
> ==8620== 64 bytes in 1 blocks are definitely lost in loss record 229 of 372
> ==8620==at 0x483EB28: malloc (vg_replace_malloc.c:307)
> ==8620==by 0x4A8D411: __libc_alloc_buffer_allocate 
> (alloc_buffer_allocate.c:26)
> ==8620==by 0x4AE2B51: alloc_buffer_allocate (alloc_buffer.h:143)
> ==8620==by 0x4AE2B51: __resolv_conf_allocate (resolv_conf.c:411)
> ==8620==by 0x4AE147D: __resolv_conf_load (res_init.c:592)
> ==8620==by 0x4AE292B: __resolv_conf_get_current (resolv_conf.c:163)
> ==8620==by 0x4AE19D7: __res_vinit (res_init.c:614)
> ==8620==by 0x4AE24B1: maybe_init (resolv_context.c:122)
> ==8620==by 0x4AE24B1: context_get.part.1 (resolv_context.c:184)
> ==8620==

Re: Integration of new algorithms

2020-09-30 Thread Dr Paul Dale
Instead of using an engine, you should write a provider (assuming you’re using 
the soon to be released OpenSSL 3.0).  It doesn’t need a NID.

If you are using OpenSSL 1.1.1, try the OBJ_new_nid() function.


Pauli
-- 
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
Phone +61 7 3031 7217
Oracle Australia




> On 26 Aug 2020, at 6:48 pm, Kris Kwiatkowski  wrote:
> 
> 
> Hey,
> 
> I'm working on development of OpenSSL ENGINE that integrates
> post-quantum algorithms (new NIDs). During integration I
> need to modify OpenSSL code to add custom function, but would
> prefer not to need add anything to OpenSSL code (so engine
> can be dynmicaly loaded by any modern OpenSSL).
> 
> So, In three cases, namely when the code is in callbacks for keygen,
> encryption and ctrl (called by EVP_PKEY_CTX_ctrl, EVP_PKEY_encrypt 
> and EVP_PKEY_keygen) I need to get NID of the scheme. The problem
> is that, those functions are called with EVP_PKEY_CTX object
> provided as an argument. The NID is stored in the 
> EVP_PKEY_CTX->pmeth->pkey_id. I think (AFAIK) there is no API
> which would return that value.
> 
> I've added a simple function that returns pkey_id from the ctx, but
> that means that I need to change OpenSSL code. Is there any way
> to get NID without changing OpenSSL?
> 
> Kind regards,
> Kris
> 
> 
> 
> 



RE: VOTE: Accept the OTC voting policy as defined:

2020-09-30 Thread Dr. Matthias St. Pierre
The vote has been closed, the verdict is

accepted:  yes  (for: 9, against: 0, abstained: 0, not voted: 2)


topic: Accept the OTC voting policy as defined:

   The proposer of a vote is ultimately responsible for updating the 
votes.txt
   file in the repository.  Outside of a face to face meeting, voters MUST 
reply
   to the vote email indicating their preference and optionally their 
reasoning.
   Voters MAY update the votes.txt file in addition.

   The proposed vote text SHOULD be raised for discussion before calling 
the vote.

   Public votes MUST be called on the project list, not the OTC list and the
   subject MUST begin with "VOTE:".  Private votes MUST be called on the
   OTC list with "PRIVATE VOTE:" beginning subject.

Proposed by Matthias St. Pierre (on behalf of the OTC)
Public: yes
opened: 2020-09-28
closed: 2020-09-29
accepted:  yes/no  (for: 9, against: 0, abstained: 0, not voted: 2)

  Matt   [+1]
  Mark   [+1]
  Pauli  [+1]
  Viktor [  ]
  Tim[+1]
  Richard[+1]
  Shane  [+1]
  Tomas  [+1]
  Kurt   [  ]
  Matthias   [+1]
  Nicola [+1]




RE: VOTE: Accept the OTC voting policy as defined:

2020-09-30 Thread Dr. Matthias St. Pierre
See pull request

#198 - Add 'OpenSSL Technical Policies' page with a 'Voting Policy' section
https://github.com/openssl/web/pull/198

Matthias



Integration of new algorithms

2020-09-30 Thread Kris Kwiatkowski

Hey,

I'm working on development of OpenSSL ENGINE that integrates
post-quantum algorithms (new NIDs). During integration I
need to modify OpenSSL code to add custom function, but would
prefer not to need add anything to OpenSSL code (so engine
can be dynmicaly loaded by any modern OpenSSL).

So, In three cases, namely when the code is in callbacks for keygen,
encryption and ctrl (called by EVP_PKEY_CTX_ctrl, EVP_PKEY_encrypt
and EVP_PKEY_keygen) I need to get NID of the scheme. The problem
is that, those functions are called with EVP_PKEY_CTX object
provided as an argument. The NID is stored in the
EVP_PKEY_CTX->pmeth->pkey_id. I think (AFAIK) there is no API
which would return that value.

I've added a simple function that returns pkey_id from the ctx, but
that means that I need to change OpenSSL code. Is there any way
to get NID without changing OpenSSL?

Kind regards,
Kris




Is OpenSSL 1.1.1g backward compatible with 1.0.2.f ?

2020-09-30 Thread Kapil Awate
Hi,

Is OpenSSL 1.1.1g backward compatible with 1.0.2.f ? Can anyone help me with 
this ? Is there any impact on existing functionality after upgrading it to 
1.1.1g ?

Thanks!

This email and any attachments thereto may contain private, confidential, 
and/or privileged material for the sole use of the intended recipient. Any 
review, copying, or distribution of this email (or any attachments thereto) by 
others is strictly prohibited. If you are not the intended recipient, please 
contact the sender immediately and permanently delete the original and any 
copies of this email and any attachments thereto.


Is OpenSSL 1.1.1g backward compatible with 1.0.2.f ?

2020-09-30 Thread Kapil Awate
Hi,

Is OpenSSL 1.1.1g backward compatible with 1.0.2.f ? Can anyone help me with 
this ? Is there any impact on existing functionality after upgrading it to 
1.1.1g ?

Thanks!

This email and any attachments thereto may contain private, confidential, 
and/or privileged material for the sole use of the intended recipient. Any 
review, copying, or distribution of this email (or any attachments thereto) by 
others is strictly prohibited. If you are not the intended recipient, please 
contact the sender immediately and permanently delete the original and any 
copies of this email and any attachments thereto.


Memory leak in openssl 1.1.1d

2020-09-30 Thread Abhi Arora
I am using openssl 1.1.1d. I found out around 228 bytes are being directly
lost (as per valgrind) report. I have one application which uses curl
(7.64) and I wrote the same application using POCO HTTPS and I got the same
result.

I thought it could be related to the cipher suit. I can see the leak is
dependent on the URL being used (all were https). For one of the urls, it
was leaking 228 (directly) per connection and disconnection. For one of the
urls, the same code doesn't leak atall (no matter how many times you run
that code in a for loop).

For the urls which were leaking, the following cipher suites were being
used:
1. SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
2. SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384

Here is the valgrind summary:

==8620== HEAP SUMMARY:
==8620== in use at exit: 121,777 bytes in 1,097 blocks
==8620==   total heap usage: 129,382 allocs, 128,285 frees, 10,635,842
bytes allocated
==8620==
==8620== 8 bytes in 1 blocks are possibly lost in loss record 16 of 372
==8620==at 0x483EB28: malloc (vg_replace_malloc.c:307)
==8620==by 0x4E75523: ??? (in /usr/lib/libuamqp.so.1.2.12)
==8620==
==8620== 8 bytes in 1 blocks are definitely lost in loss record 17 of 372
==8620==at 0x483F310: operator new(unsigned int) (vg_replace_malloc.c:336)
==8620==by 0x36D15: main (sample_pki.cpp:27)
==8620==
==8620== 8 bytes in 1 blocks are definitely lost in loss record 18 of 372
==8620==at 0x483EB28: malloc (vg_replace_malloc.c:307)
==8620==by 0x4CBF14B: CRYPTO_zalloc (mem.c:230)
==8620==by 0x4C76E07: ECDSA_SIG_new (ec_asn1.c:1214)
==8620==by 0x537064B: pkcs11_try_pkey_ec_sign (p11_pkey.c:546)
==8620==by 0x537064B: pkcs11_pkey_ec_sign (p11_pkey.c:634)
==8620==by 0x4CB70CD: EVP_DigestSignFinal (m_sigver.c:148)
==8620==by 0x4BA9FF3: tls_construct_cert_verify (statem_lib.c:307)
==8620==by 0x4BA42C7: write_state_machine (statem.c:843)
==8620==by 0x4BA42C7: state_machine (statem.c:443)
==8620==by 0x4B8BABB: ssl3_read_bytes (rec_layer_s3.c:1278)
==8620==by 0x4B900E1: ssl3_read_internal (s3_lib.c:4473)
==8620==by 0x4B9013F: ssl3_read (s3_lib.c:4497)
==8620==by 0x4B96A6D: ssl_read_internal (ssl_lib.c:1761)
==8620==by 0x4B96B09: SSL_read (ssl_lib.c:1775)
==8620==
==8620== 16 bytes in 2 blocks are possibly lost in loss record 55 of 372
==8620==at 0x483EA30: malloc (vg_replace_malloc.c:306)
==8620==by 0x48419FF: realloc (vg_replace_malloc.c:834)
==8620==by 0x4E73B5D: amqpvalue_set_map_value (in
/usr/lib/libuamqp.so.1.2.12)
==8620==
==8620== 40 bytes in 10 blocks are possibly lost in loss record 182 of 372
==8620==at 0x483EA30: malloc (vg_replace_malloc.c:306)
==8620==by 0x48419FF: realloc (vg_replace_malloc.c:834)
==8620==by 0x4E738BB: amqpvalue_set_list_item (in
/usr/lib/libuamqp.so.1.2.12)
==8620==
==8620== 48 bytes in 1 blocks are possibly lost in loss record 210 of 372
==8620==at 0x483EB28: malloc (vg_replace_malloc.c:307)
==8620==by 0x4E7582D: ??? (in /usr/lib/libuamqp.so.1.2.12)
==8620==
==8620== 48 bytes in 2 blocks are possibly lost in loss record 211 of 372
==8620==at 0x48419B0: realloc (vg_replace_malloc.c:834)
==8620==by 0x4E73B5D: amqpvalue_set_map_value (in
/usr/lib/libuamqp.so.1.2.12)
==8620==
==8620== 56 bytes in 1 blocks are possibly lost in loss record 215 of 372
==8620==at 0x483EB28: malloc (vg_replace_malloc.c:307)
==8620==by 0x4E74FF9: ??? (in /usr/lib/libuamqp.so.1.2.12)
==8620==
==8620== 64 bytes in 2 blocks are possibly lost in loss record 228 of 372
==8620==at 0x483EB28: malloc (vg_replace_malloc.c:307)
==8620==by 0x4E74477: ??? (in /usr/lib/libuamqp.so.1.2.12)
==8620==
==8620== 64 bytes in 1 blocks are definitely lost in loss record 229 of 372
==8620==at 0x483EB28: malloc (vg_replace_malloc.c:307)
==8620==by 0x4A8D411: __libc_alloc_buffer_allocate
(alloc_buffer_allocate.c:26)
==8620==by 0x4AE2B51: alloc_buffer_allocate (alloc_buffer.h:143)
==8620==by 0x4AE2B51: __resolv_conf_allocate (resolv_conf.c:411)
==8620==by 0x4AE147D: __resolv_conf_load (res_init.c:592)
==8620==by 0x4AE292B: __resolv_conf_get_current (resolv_conf.c:163)
==8620==by 0x4AE19D7: __res_vinit (res_init.c:614)
==8620==by 0x4AE24B1: maybe_init (resolv_context.c:122)
==8620==by 0x4AE24B1: context_get.part.1 (resolv_context.c:184)
==8620==by 0x4ABBAE7: gaih_inet.constprop.6 (getaddrinfo.c:751)
==8620==by 0x4ABC90B: getaddrinfo (getaddrinfo.c:2265)
==8620==by 0x4B4AA17: Curl_getaddrinfo_ex (in /usr/lib/libcurl.so.4.5.0)
==8620==
==8620== 80 bytes in 3 blocks are possibly lost in loss record 246 of 372
==8620==at 0x483EB28: malloc (vg_replace_malloc.c:307)
==8620==by 0x4E7547D: ??? (in /usr/lib/libuamqp.so.1.2.12)
==8620==
==8620== 92 bytes in 3 blocks are possibly lost in loss record 256 of 372
==8620==at 0x483EB28: malloc (vg_replace_malloc.c:307)
==8620==by 0x4E74E3D: ??? (in /usr/lib/libuamqp.so.1.2.12)