From paul at xelerance.com Tue Nov 1 17:32:11 2011 From: paul at xelerance.com (Paul Wouters) Date: Tue, 1 Nov 2011 13:32:11 -0400 (EDT) Subject: [ldns-users] ldns patch for ldns-verify-zone to take a time offset Message-ID: Hi, While investigating a dnssec-signzone bug, I had the need to verify signed zones in the future. Unfortunately, ldns-verify-zone did not support it. I wrote a patch, but it bleeds changes over the entire ldns API because we keep needing to pass the time offset around. The patch uses uint32_t because that was already used internally, though I think it should really use time_t. Perhaps the ldns authors can come up with a less invasive patch? Or if they deem this is the right fix, accept it and bump the SO version. Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: ldns-offset-check.diff Type: text/x-diff Size: 20249 bytes Desc: URL: From Willem at NLnetLabs.nl Tue Nov 1 22:24:23 2011 From: Willem at NLnetLabs.nl (Willem Toorop) Date: Tue, 01 Nov 2011 23:24:23 +0100 Subject: [ldns-users] ldns patch for ldns-verify-zone to take a time offset In-Reply-To: References: Message-ID: <4EB07197.7060908@NLnetLabs.nl> Paul, I faced the same problem when implementing a way to be able to specify how things should be converted to string; The output formats. You either have to do what you did (however with different function names so we don't break the API) or use a cover channel (carry the check_time in the rrsigs, or in the keys) but that is too weird, or use a global ( void dns_set_time_func(time_t (*time_func)(time_t *)) and maybe also time_t (*ldns_get_time_func())(time_t *) ). But globals are considered bad practise and also issues with thread safety arise. I am not sure what to do. Similar needs might arise in the future. A global modifiable configuration for ldns would be convenient. On the other hand, the API currently does not use (configurable) globals. It would be more in the style of the current API to pass the check_time down. It would also make explicit which functions eventually test against "current" time. -- Willem Op 01-11-11 18:32, Paul Wouters schreef: > > Hi, > > While investigating a dnssec-signzone bug, I had the need to verify > signed zones in the future. Unfortunately, ldns-verify-zone did not > support it. I wrote a patch, but it bleeds changes over the entire ldns > API because we keep needing to pass the time offset around. > > The patch uses uint32_t because that was already used internally, though > I think it > should really use time_t. > > Perhaps the ldns authors can come up with a less invasive patch? Or if > they deem this > is the right fix, accept it and bump the SO version. > > Paul > > > _______________________________________________ > ldns-users mailing list > ldns-users at open.nlnetlabs.nl > http://open.nlnetlabs.nl/mailman/listinfo/ldns-users From paul at xelerance.com Tue Nov 1 22:51:16 2011 From: paul at xelerance.com (Paul Wouters) Date: Tue, 1 Nov 2011 18:51:16 -0400 (EDT) Subject: [ldns-users] ldns patch for ldns-verify-zone to take a time offset In-Reply-To: <4EB07197.7060908@NLnetLabs.nl> References: <4EB07197.7060908@NLnetLabs.nl> Message-ID: On Tue, 1 Nov 2011, Willem Toorop wrote: > I faced the same problem when implementing a way to be able to specify > how things should be converted to string; The output formats. You either > have to do what you did (however with different function names so we > don't break the API) or use a cover channel (carry the check_time in the > rrsigs, or in the keys) but that is too weird, or use a global ( > void dns_set_time_func(time_t (*time_func)(time_t *)) I thought about those, but did not see an easy fix, as the call chain was pretty long it would be duplicating way too many functions. > and maybe also > time_t (*ldns_get_time_func())(time_t *) > ). But globals are considered bad practise and also issues with thread > safety arise. I've seen some icky gpg library issue arise out of those, please avoid :) > I am not sure what to do. Similar needs might arise in the future. A > global modifiable configuration for ldns would be convenient. On the > other hand, the API currently does not use (configurable) globals. It > would be more in the style of the current API to pass the check_time > down. It would also make explicit which functions eventually test > against "current" time. Another more compatible, less invasive method might be to allow setting an TIME_OFFSET env variable? That way we would not need to pass the offset around all functions. It won't be as nice as an option to ldns-verify-zone, but it would give me something I can live with for now. And I do kinda need the option, but I want to avoid needing to maintain a privately butchered ldns :P Paul From miek at miek.nl Tue Nov 1 22:45:20 2011 From: miek at miek.nl (Miek Gieben) Date: Tue, 1 Nov 2011 23:45:20 +0100 Subject: [ldns-users] ldns patch for ldns-verify-zone to take a time offset In-Reply-To: <4EB07197.7060908@NLnetLabs.nl> References: <4EB07197.7060908@NLnetLabs.nl> Message-ID: <20111101224520.GA17681@miek.nl> [ Quoting at 23:24 on Nov 1 in "Re: [ldns-users] ldn..." ] > I am not sure what to do. Similar needs might arise in the future. A > global modifiable configuration for ldns would be convenient. On the > other hand, the API currently does not use (configurable) globals. It > would be more in the style of the current API to pass the check_time > down. It would also make explicit which functions eventually test > against "current" time. I would opt for passing 'check_time' down the API and default it to be 'current_time'. The current time is now implicitly used as a global variable defined by the OS. Global vars are evil (at least that's what I learned :-) ), and are IMHO often misused to not break an API, while instead breaking the API was the correct thing to do. grtz Miek -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From miek at miek.nl Tue Nov 1 22:55:25 2011 From: miek at miek.nl (Miek Gieben) Date: Tue, 1 Nov 2011 23:55:25 +0100 Subject: [ldns-users] ldns patch for ldns-verify-zone to take a time offset In-Reply-To: References: <4EB07197.7060908@NLnetLabs.nl> Message-ID: <20111101225525.GA24450@miek.nl> [ Quoting at 18:51 on Nov 1 in "Re: [ldns-users] ldn..." ] > Another more compatible, less invasive method might be to allow setting > an TIME_OFFSET env variable? That way we would not need to pass the offset > around all functions. Ugh, please no. If there is a good reason to change the API, you should change the API. grtz Miek -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From Willem at NLnetLabs.nl Wed Nov 2 13:27:19 2011 From: Willem at NLnetLabs.nl (Willem Toorop) Date: Wed, 02 Nov 2011 14:27:19 +0100 Subject: [ldns-users] ldns patch for ldns-verify-zone to take a time offset In-Reply-To: <20111101225525.GA24450@miek.nl> References: <4EB07197.7060908@NLnetLabs.nl> <20111101225525.GA24450@miek.nl> Message-ID: <4EB14537.8070602@NLnetLabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Op 01-11-11 23:55, Miek Gieben schreef: > Ugh, please no. > > If there is a good reason to change the API, you should change the > API. Okay! We will pass check_time down, but we don't have to break the API by creating new functions and let the old ones call the new ones with the value returned from time(NULL). - -- Willem -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOsUU3AAoJEOX4+CEvd6SYB70P/AuKPsmyJNVNR3N/sZoIk8iu 7Gx29Ig5Ixx/xGOIqKW2sEUsc9PzFjprGfzhMpbCaviNw8cU/7SHrPloy1DxkPOz nVN0AAj8C1Tt6CjJ3I7/9PCs69aqBH05b02fhXqjbZ/BngdUZa49DPBf/ain5JV3 RC8GBSMzTb2pZO5YAsa64QWHJMtbMa2Zyrg/UHP6snx+0bNQ9ZdaNLFt8kibpYK2 FN1EBI++15mP8+1PEZfDwN8sPSjUIIN1yS3mgZ6cWvagQBo1D17RfMXvqcH5Cymp 2Pb5nn8iUCUG6gthQ9+qB8GVMtZNSZOv+6y6pL1it4pcTYQUoMqoQVvsPMCSoWr4 eGkGugWDKxgFsFZSWFd45JhCBJreh4Tg6wXSXs++a3uu8jYOdlbq9QlHA95D++8A yLwmLzVBBSI1/K9wssLOInPcugbC/BqOXBsw5BbItkLlrHKHIAxNVcUJhUhFtY8q tcYCy8lerKU7pCx2rjzqHynoDbv8vSHavsyp2upB6mf+tTJ29X26yYaiv0FP3tje qxYfjQFea1USWKqyPwdxALRp7NjKsyTaAOSpATjhBLzecCiRucDntjZ7M1ajn2f3 vFNxnP6F/pOCjJXU4XnXcB9ppu3UauF4K3Y4P1VhJB6iGEAUHa5qaz/nkkd1VHDL c6ju9F1t+3G5h/TXpcd4 =D8w8 -----END PGP SIGNATURE----- From miek at miek.nl Wed Nov 2 13:44:32 2011 From: miek at miek.nl (Miek Gieben) Date: Wed, 2 Nov 2011 14:44:32 +0100 Subject: [ldns-users] ldns patch for ldns-verify-zone to take a time offset In-Reply-To: <4EB14537.8070602@NLnetLabs.nl> References: <4EB07197.7060908@NLnetLabs.nl> <20111101225525.GA24450@miek.nl> <4EB14537.8070602@NLnetLabs.nl> Message-ID: <20111102134432.GA3736@miek.nl> [ Quoting at 14:27 on Nov 2 in "Re: [ldns-users] ldn..." ] > Op 01-11-11 23:55, Miek Gieben schreef: > > Ugh, please no. > > > > If there is a good reason to change the API, you should change the > > API. > > Okay! We will pass check_time down, but we don't have to break the API > by creating new functions and let the old ones call the new ones with > the value returned from time(NULL). That's a nice idea. Maybe in ldns 2.0 (or 1.8 or whatever) they can be removed again? Having too many functions makes a library more difficult to use. grtz Miek -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From paul at xelerance.com Wed Nov 2 18:18:09 2011 From: paul at xelerance.com (Paul Wouters) Date: Wed, 2 Nov 2011 14:18:09 -0400 (EDT) Subject: [ldns-users] ldns patch for ldns-verify-zone to take a time offset In-Reply-To: <4EB14537.8070602@NLnetLabs.nl> References: <4EB07197.7060908@NLnetLabs.nl> <20111101225525.GA24450@miek.nl> <4EB14537.8070602@NLnetLabs.nl> Message-ID: On Wed, 2 Nov 2011, Willem Toorop wrote: >> If there is a good reason to change the API, you should change the >> API. > > Okay! We will pass check_time down, but we don't have to break the API > by creating new functions and let the old ones call the new ones with > the value returned from time(NULL). Ok. In case it is useful, here is the full patch that also addresses drill and ldns-python to deal with the check_time argument. Note that you might want to consider allowing a negative off set as well, so you could check the zone file based on "yesterday". Since there are casts to uinet32_t right now, that might not work currently. Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: ldns-check_time.patch Type: text/x-diff Size: 28452 bytes Desc: URL: From Willem at NLnetLabs.nl Wed Nov 2 21:42:06 2011 From: Willem at NLnetLabs.nl (Willem Toorop) Date: Wed, 02 Nov 2011 22:42:06 +0100 Subject: [ldns-users] ldns patch for ldns-verify-zone to take a time offset In-Reply-To: References: <4EB07197.7060908@NLnetLabs.nl> <20111101225525.GA24450@miek.nl> <4EB14537.8070602@NLnetLabs.nl> Message-ID: <4EB1B92E.4000202@NLnetLabs.nl> Thanks Paul, I am already preparing a patch with new function names so that those programs keep working unmodified. I believe it is safe to replace int32_t with time_t because it was only used like that in ldns_rrsig_check_timestamps which wasn't exported from the library anyway. It will all be in trunk when you wake up tomorrow (which means I am going to finish it tomorrow morning myself). -- Willem Op 02-11-11 19:18, Paul Wouters schreef: > On Wed, 2 Nov 2011, Willem Toorop wrote: > >>> If there is a good reason to change the API, you should change the >>> API. >> >> Okay! We will pass check_time down, but we don't have to break the API >> by creating new functions and let the old ones call the new ones with >> the value returned from time(NULL). > > Ok. In case it is useful, here is the full patch that also addresses > drill and ldns-python to deal with the check_time argument. > > Note that you might want to consider allowing a negative off set as well, > so you could check the zone file based on "yesterday". > > Since there are casts to uinet32_t right now, that might not work > currently. > > Paul From kaustubh.gadkari at gmail.com Fri Nov 4 05:27:06 2011 From: kaustubh.gadkari at gmail.com (Kaustubh Gadkari) Date: Thu, 3 Nov 2011 23:27:06 -0600 Subject: [ldns-users] Private-key-format v1.3 Message-ID: Hi, I am trying to read a key from a file with the ldns_key_new_frm_fp_l() function. However, the key I have is in the Private-key-format v1.3 and I get an version mismatch error. The documentation mentions that only v1.2 is supported. But bind's dnssec-keygen tool generates v1.3 keys. Is there any way of reading v1.3 keys? Thanks, Kaustubh -- Kaustubh Gadkari From Willem at NLnetLabs.nl Fri Nov 4 13:39:27 2011 From: Willem at NLnetLabs.nl (Willem Toorop) Date: Fri, 04 Nov 2011 14:39:27 +0100 Subject: [ldns-users] Private-key-format v1.3 In-Reply-To: References: Message-ID: <4EB3EB0F.8070000@NLnetLabs.nl> Hi Kaustubh, In the release notes for BIND 9.7.0, I read: 2731. [func] Additional work on change 2709. The key parser will now ignore unrecognized fields when the minor version number of the private key format has been increased. It will reject any key with the major version number increased. [RT #20310] We should do this for ldns too. I don't think ISC has documented Private-key-format files (or at least I couldn't find it), but I did have a peek in the parser for bind (dst_parse.c). All the new fields look related to key rollovers which is currently not applicable for ldns so, I have relaxed the version checking ? la BIND. Thanks, Willem Op 04-11-11 06:27, Kaustubh Gadkari schreef: > Hi, > > I am trying to read a key from a file with the ldns_key_new_frm_fp_l() > function. However, the key I have is in the Private-key-format v1.3 > and I get an version mismatch error. The documentation mentions that > only v1.2 is supported. But bind's dnssec-keygen tool generates v1.3 > keys. Is there any way of reading v1.3 keys? > > Thanks, > Kaustubh > From fixie at chrissmith.org Wed Nov 16 19:28:46 2011 From: fixie at chrissmith.org (Chris Smith) Date: Wed, 16 Nov 2011 14:28:46 -0500 Subject: [ldns-users] compile failure Message-ID: SVN Rev 3598 fails when configured with --pyldns : ============================== ./install-sh -d doc cat ./ldns/*.h | ./doc/doxyparse.pl -m ./doc/function_manpages 2>&1 | \ grep -v ^doxygen | grep -v ^cat > doc/ldns_manpages /usr/bin/swig -python -o contrib/python/ldns_wrapper.c -I. -I. -DHAVE_CONFIG_H -I/usr/include/python2.7 contrib/python/file_py3.i No module name specified using %module or -module. ============================== SVN Rev 3597 compiles fine. From Willem at NLnetLabs.nl Wed Nov 16 22:50:05 2011 From: Willem at NLnetLabs.nl (Willem Toorop) Date: Wed, 16 Nov 2011 23:50:05 +0100 Subject: [ldns-users] compile failure In-Reply-To: References: Message-ID: <4EC43E1D.10502@NLnetLabs.nl> Thanks Chris. It should be okay again now. It happened in the process of making the Makefile GNU and BSD compatible. -- Willem Op 16-11-11 20:28, Chris Smith schreef: > SVN Rev 3598 fails when configured with --pyldns : > ============================== > ./install-sh -d doc > cat ./ldns/*.h | ./doc/doxyparse.pl -m ./doc/function_manpages 2>&1 | \ > grep -v ^doxygen | grep -v ^cat > doc/ldns_manpages > /usr/bin/swig -python -o contrib/python/ldns_wrapper.c -I. -I. > -DHAVE_CONFIG_H -I/usr/include/python2.7 contrib/python/file_py3.i > No module name specified using %module or -module. > ============================== > > SVN Rev 3597 compiles fine. > _______________________________________________ > ldns-users mailing list > ldns-users at open.nlnetlabs.nl > http://open.nlnetlabs.nl/mailman/listinfo/ldns-users