From Willem at NLnetLabs.nl  Fri Jun  1 14:56:35 2012
From: Willem at NLnetLabs.nl (Willem Toorop)
Date: Fri, 01 Jun 2012 16:56:35 +0200
Subject: [ldns-users] patch for feature, and a bug report :)
In-Reply-To: <alpine.LFD.2.02.1205272344370.30696@bofh.nohats.ca>
References: <alpine.LFD.2.02.1205272344370.30696@bofh.nohats.ca>
Message-ID: <4FC8D823.1090808@NLnetLabs.nl>

Hi Paul,

Op 28-05-12 05:44, Paul Wouters schreef:
> The attached patch adds the -0 option to ldns-read-zone:

It is a nice idea. Though we cannot let ldns_rr2buffer_str_fmt alter the
rr. It just has to print it. I've applied your patch with a few
adaptations so it doesn't destroy the rr fed to ldns_rr2buffer_str_fmt.
Thanks!

While I was at it I also added the long awaited -p option for
ldns-read-zone to prepend-pad SOA Serials to ten characters.

Op 28-05-12 05:44, Paul Wouters schreef:
> Now for the bug, when looking through the ldns-read-zone code, I
> noticed:
<snip>
> In fact, grepping through the source, it seems that no one ever sets
> these, so the code is effectively never called.

In fact LDNS_COMMENT_KEY is set by default. LDNS_COMMENT_RRSIGS may not
be used in our code, but may be used by users of the library. It is part
of the published library API. We can not simply remove it because we
don't use it ourselves. Someone else might.

Cheers,

-- Willem


From paul at nohats.ca  Fri Jun  1 21:52:14 2012
From: paul at nohats.ca (Paul Wouters)
Date: Fri, 1 Jun 2012 17:52:14 -0400 (EDT)
Subject: [ldns-users] patch for feature, and a bug report :)
In-Reply-To: <4FC8D823.1090808@NLnetLabs.nl>
References: <alpine.LFD.2.02.1205272344370.30696@bofh.nohats.ca>
 <4FC8D823.1090808@NLnetLabs.nl>
Message-ID: <alpine.LFD.2.02.1206011747390.21775@bofh.nohats.ca>

On Fri, 1 Jun 2012, Willem Toorop wrote:

> It is a nice idea. Though we cannot let ldns_rr2buffer_str_fmt alter the
> rr. It just has to print it. I've applied your patch with a few
> adaptations so it doesn't destroy the rr fed to ldns_rr2buffer_str_fmt.

It looks good, though I would replace printing "(null)" with "0". I
was just lazy in my patch.

And thanks for merging/rewriting the -p option for padding!!!

> In fact LDNS_COMMENT_KEY is set by default. LDNS_COMMENT_RRSIGS may not
> be used in our code, but may be used by users of the library. It is part
> of the published library API. We can not simply remove it because we
> don't use it ourselves. Someone else might.

Ah understood. Though the -b option to ldns-read-zone still seems
broken. I never see bubblebabble. The diff with and without -b shows:

> ubba07siftvdck58nh8gh6rdr52qrgf1.nohats.ca.	3600	IN	NSEC3
> 1 0 5 715e22f77cc2f0d7  v49osrpnehh59odbcpd91dmo21ed1pkv A AAAA RRSIG 
161c161
< 2bfea6kfe10im5ubfome6k9qrfb6r59n.nohats.ca.	3600	IN	NSEC3
1 0 5 715e22f77cc2f0d7  2i98vcbiuafk6ugr64fvl4frn4t23su6 ;{ flags: -}

So I do think the option handling code is still broken there.

Paul


From msheldon at godaddy.com  Tue Jun  5 22:41:36 2012
From: msheldon at godaddy.com (Michael Sheldon)
Date: Tue, 05 Jun 2012 15:41:36 -0700
Subject: [ldns-users] =?utf-8?q?Possible_memory_leak_in_ldns=5Fkey=5Fnew?=
	=?utf-8?q?=5Ffrm=5Falgorithm?=
Message-ID: <20120605154136.205a61dff9fc1684c258b274662bb912.ebd7eda7ad.wbe@email00.secureserver.net>

So I've been chasing down a small memory leak when generating dnssec
signing keys.

valgrind backtrace was this:

==20296== 688 (136 direct, 552 indirect) bytes in 1 blocks are
definitely lost in loss record 43 of 44
==20296==    at 0x4A05FDE: malloc (vg_replace_malloc.c:236)
==20296==    by 0x39E905D95D: CRYPTO_malloc (in
/usr/lib64/libcrypto.so.1.0.0)
==20296==    by 0x39E90A2A4E: DSA_new_method (in
/usr/lib64/libcrypto.so.1.0.0)
==20296==    by 0x39E90A3AB9: DSA_generate_parameters (in
/usr/lib64/libcrypto.so.1.0.0)
==20296==    by 0x39E2429AAA: ldns_key_new_frm_algorithm (keys.c:851)

And similar for RSA.

Through searching, I found that DSA_generate_parameters calls:

01002 ldns_key_set_dsa_key(ldns_key *k, DSA *d)
01003 {
01004         EVP_PKEY *key = EVP_PKEY_new();
01005         EVP_PKEY_set1_DSA(key, d);
01006         k->_key.key  = key;
01007 }

The documentation for EVP_PKEY_set1_DSA(EVP_PKEY *pkey,RSA *key), which
is described as:  set the key referenced by pkey to key.

But also mentioned is EVP_PKEY_assign_RSA(EVP_PKEY *pkey,RSA *key),
which has the description: also set the referenced key to key however
these use the supplied key internally and so key will be freed when the
parent pkey is freed.

This implies that d is not freed when k->_key.key is freed, and d is not
itself explicitly freed by either ldns_key_set_dsa_key or
ldns_key_new_frm_algorithm which would account for the memory leak.

The same applies for r when passed to  ldns_key_set_rsa_key



Or am I smoking something?

Michael Sheldon
Dev-DNS Services
GoDaddy.com





From msheldon at godaddy.com  Wed Jun  6 22:11:13 2012
From: msheldon at godaddy.com (Michael Sheldon)
Date: Wed, 06 Jun 2012 15:11:13 -0700
Subject: [ldns-users]
 =?utf-8?q?Possible=5Fmemory=5Fleak=5Fin=5Fldns=5Fkey?=
 =?utf-8?q?=5Fnew_=5Ffrm=5Falgorithm?=
Message-ID: <20120606151113.205a61dff9fc1684c258b274662bb912.29c8df38f4.wbe@email00.secureserver.net>

Been looking deeper, this may be an openssl thing. Certainly openssl
does not play nice with valgrind...

Michael Sheldon
Dev-DNS Services
GoDaddy.com
tel. (480)505-8800 x4372
mobile. (602)456-0255

> -------- Original Message --------
> Subject: [ldns-users] Possible_memory_leak_in_ldns_key_new
> _frm_algorithm
> From: "Michael Sheldon" <msheldon at godaddy.com>
> Date: Tue, June 05, 2012 3:41 pm
> To: ldns-users at open.nlnetlabs.nl
> 
> 
> So I've been chasing down a small memory leak when generating dnssec
> signing keys.
> 
> valgrind backtrace was this:
> 
> ==20296== 688 (136 direct, 552 indirect) bytes in 1 blocks are
> definitely lost in loss record 43 of 44
> ==20296==    at 0x4A05FDE: malloc (vg_replace_malloc.c:236)
> ==20296==    by 0x39E905D95D: CRYPTO_malloc (in
> /usr/lib64/libcrypto.so.1.0.0)
> ==20296==    by 0x39E90A2A4E: DSA_new_method (in
> /usr/lib64/libcrypto.so.1.0.0)
> ==20296==    by 0x39E90A3AB9: DSA_generate_parameters (in
> /usr/lib64/libcrypto.so.1.0.0)
> ==20296==    by 0x39E2429AAA: ldns_key_new_frm_algorithm (keys.c:851)
> 
> And similar for RSA.
> 
> Through searching, I found that DSA_generate_parameters calls:
> 
> 01002 ldns_key_set_dsa_key(ldns_key *k, DSA *d)
> 01003 {
> 01004         EVP_PKEY *key = EVP_PKEY_new();
> 01005         EVP_PKEY_set1_DSA(key, d);
> 01006         k->_key.key  = key;
> 01007 }
> 
> The documentation for EVP_PKEY_set1_DSA(EVP_PKEY *pkey,RSA *key), which
> is described as:  set the key referenced by pkey to key.
> 
> But also mentioned is EVP_PKEY_assign_RSA(EVP_PKEY *pkey,RSA *key),
> which has the description: also set the referenced key to key however
> these use the supplied key internally and so key will be freed when the
> parent pkey is freed.
> 
> This implies that d is not freed when k->_key.key is freed, and d is not
> itself explicitly freed by either ldns_key_set_dsa_key or
> ldns_key_new_frm_algorithm which would account for the memory leak.
> 
> The same applies for r when passed to  ldns_key_set_rsa_key
> 
> 
> 
> Or am I smoking something?
> 
> Michael Sheldon
> Dev-DNS Services
> GoDaddy.com
> 
> 
> 
> _______________________________________________
> ldns-users mailing list
> ldns-users at open.nlnetlabs.nl
> http://open.nlnetlabs.nl/mailman/listinfo/ldns-users




From Marc.Groeneweg at sidn.nl  Tue Jun 19 08:12:14 2012
From: Marc.Groeneweg at sidn.nl (Marc Groeneweg)
Date: Tue, 19 Jun 2012 08:12:14 +0000
Subject: [ldns-users] ldns on iPhone ?
In-Reply-To: <860161F1-56C7-4EAB-9B58-C67B476DCD28@asseily.com>
References: <4212CB92-1EE4-45B0-819C-C357CAF868D0@jones.name>
 <C7DA4FDE-2682-4B59-AAAA-DC25DD1839B9@asseily.com>
 <4F9A509C.4080301@sidn.nl> <39698E56-20AC-48AE-8D7F-BB70D3E74C06@jones.name>
 <5BFD186DCB661E4D951017B0818285AE275E844E@kambx1.SIDN.local>
 <860161F1-56C7-4EAB-9B58-C67B476DCD28@asseily.com>
Message-ID: <5BFD186DCB661E4D951017B0818285AE28B5438B@kambx2.SIDN.local>

Hi Henri,

SNAP
>The difference between a shared lib and a framework is simply one of bundling. 
SNAP
>sed -ie "s!^CFLAG=!CFLAG=-isysroot /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS${SDKVERSION}.sdk !" "Makefile"
># remove sig_atomic for iPhoneOS
>sed -ie "s!static volatile sig_atomic_t intr_signal;!static volatile intr_signal;!" "crypto/ui/ui_openssl.c"
>
>I can add that to my script and make a complete OpenSSL framework if you're interested.
Yes please. Then all can benefit from this.

>> For creating the libunbound, the same technique is needed, but you 
>> have to iterate because of the dependencies Unbound has with ldns. 
>> Three build runs were needed to create libunbound (with ldns) for the 
>> architectures needed for iOS devices (i386, armv6, armv7). Scripts can 
>> be found at SIDN labs as soon as the article on libunbound gets published
The article has been posted several weeks ago. Please see:
http://www.sidnlabs.nl/laatste-berichten/nieuwsdetail/article/dnssec-validatie-implementeren-op-ios/

It's in Dutch, but I'm pretty sure you understand. Otherwise Google translate might be your friend.

>Let me know if you need help. We could pretty much package the whole thing
> (OpenSSL + libunbound + ldns) into one drop-in framework.
Same applies as for the OpenSSL framework.

Best regards,
Marc