From dkg at fifthhorseman.net Wed Jul 8 17:51:41 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 8 Jul 2015 13:51:41 -0400 Subject: [getdns-users] [PATCH] remove GETDNS_COMPILATION_COMMENT Message-ID: <1436377901-6300-1-git-send-email-dkg@fifthhorseman.net> It's not clear that GETDNS_COMPILATION_COMMENT is useful; as a header (a #define), it's likely to get embedded in applications during their build time. It is not embedded in the library itself at all, so removal of it doesn't change the ABI (there is a slight change in the API because the #define is no longer visible in getdns.h, but i think this is OK, see below). When a built application that uses GETDNS_COMPILATION_COMMENT is executed, linked against a different version of the library it was built from, there is no way to detect that these values differ. How is it useful at runtime? The #define also introduces arbitrariness in the getdns build process when --with-current-date isn't supplied, because it embeds the current timestamp in getdns.h. This makes it more difficult to build a byte-for-byte reproducible binary package. http://codesearch.debian.net/results/GETDNS_COMPILATION_COMMENT indicates that there are no projects in debian actually using the defined variable (there may be non-debian projects that use it, though it's not clear how it is expected to be used at runtime at all). Removing this #define removes a source of confusion for users of the project, and doesn't change the ABI. --- ChangeLog | 1 + configure | 15 --------------- configure.ac | 9 --------- spec/index.html | 5 ----- src/getdns/getdns.h.in | 2 -- 5 files changed, 1 insertion(+), 31 deletions(-) diff --git a/ChangeLog b/ChangeLog index a70879d..438c1b5 100644 --- a/ChangeLog +++ b/ChangeLog @@ -5,6 +5,7 @@ GETDNS_TRANSPORT_STARTTLS. * Added new context setting for idle_timeout * CSYNC RR type + * remove GETDNS_COMPILATION_COMMENT, CURRENT_DATE, and --with-current-date * 2015-05-21: Version 0.2.0 * Fix libversion numbering: Thanks Daniel Kahn Gillmor diff --git a/configure b/configure index c86c59f..9e01aab 100755 --- a/configure +++ b/configure @@ -706,7 +706,6 @@ LDFLAGS CFLAGS CC GETDNS_LIBVERSION -GETDNS_COMPILATION_COMMENT RELEASE_CANDIDATE target_alias host_alias @@ -749,7 +748,6 @@ SHELL' ac_subst_files='' ac_user_opts=' enable_option_checking -with_current_date enable_shared enable_static with_pic @@ -1420,8 +1418,6 @@ Optional Features: Optional Packages: --with-PACKAGE[=ARG] use PACKAGE [ARG=yes] --without-PACKAGE do not use PACKAGE (same as --with-PACKAGE=no) - --with-current-date - current date of the compilation, set to fixed date for reproducible builds [default=system] --with-pic[=PKGS] try to use only PIC/non-PIC objects [default=use both] @@ -2371,17 +2367,6 @@ ac_compiler_gnu=$ac_cv_c_compiler_gnu -# Set current date from system if not set - -# Check whether --with-current-date was given. -if test "${with_current_date+set}" = set; then : - withval=$with_current_date; CURRENT_DATE="$with_current_date" -else - CURRENT_DATE="`date -u +%Y-%m-%dT%H:%M:%SZ`" -fi - -GETDNS_COMPILATION_COMMENT="getdns 0.2.0 configured on $CURRENT_DATE for the January 2015 version of the API" - # Library version # --------------- # current:revision:age diff --git a/configure.ac b/configure.ac index 48bb399..ef060ea 100644 --- a/configure.ac +++ b/configure.ac @@ -34,14 +34,6 @@ AC_PREREQ([2.56]) AC_INIT([getdns], [0.2.0], [stub-resolver at verisignlabs.com], [], [http://getdnsapi.net]) AC_SUBST(RELEASE_CANDIDATE, []) -# Set current date from system if not set -AC_ARG_WITH([current-date], - [AS_HELP_STRING([--with-current-date] - [current date of the compilation, set to fixed date for reproducible builds @<:@default=system@:>@])], - [CURRENT_DATE="$with_current_date"], - [CURRENT_DATE="`date -u +%Y-%m-%dT%H:%M:%SZ`"]) -GETDNS_COMPILATION_COMMENT="AC_PACKAGE_STRING configured on $CURRENT_DATE for the January 2015 version of the API" - # Library version # --------------- # current:revision:age @@ -62,7 +54,6 @@ GETDNS_COMPILATION_COMMENT="AC_PACKAGE_STRING configured on $CURRENT_DATE for th # GETDNS_LIBVERSION=2:2:1 -AC_SUBST(GETDNS_COMPILATION_COMMENT) AC_SUBST(GETDNS_LIBVERSION) AC_CONFIG_SRCDIR([src/getdns/getdns.h.in]) # AM_INIT_AUTOMAKE diff --git a/spec/index.html b/spec/index.html index a98e37c..a6dd53a 100644 --- a/spec/index.html +++ b/spec/index.html @@ -2521,11 +2521,6 @@ of this API must support synchronous calls with getdns_general_sync() -

The API's .h file contains a macro called GETDNS_COMPILATION_COMMENT. This can be useful -to an application which will use the API because it can check the string without calling any -functions. Each time the API implementation is compiled, this string should be updated with unique -information about the implementation build.

-

The implementation of both the async and sync getdns functions will copy all the values of the parameters into local memory, in case the application changes or deallocates them.

diff --git a/src/getdns/getdns.h.in b/src/getdns/getdns.h.in index 3f133a4..133d9cb 100644 --- a/src/getdns/getdns.h.in +++ b/src/getdns/getdns.h.in @@ -44,8 +44,6 @@ extern "C" { #endif -#define GETDNS_COMPILATION_COMMENT "@GETDNS_COMPILATION_COMMENT@" - /* Return values */ typedef enum getdns_return_t { GETDNS_RETURN_GOOD = 0, -- 2.1.4 From shollenbeck at verisign.com Wed Jul 8 17:58:56 2015 From: shollenbeck at verisign.com (Hollenbeck, Scott) Date: Wed, 8 Jul 2015 17:58:56 +0000 Subject: [getdns-users] [PATCH] remove GETDNS_COMPILATION_COMMENT In-Reply-To: <1436377901-6300-1-git-send-email-dkg@fifthhorseman.net> References: <1436377901-6300-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <831693C2CDA2E849A7D7A712B24E257F4A016A89@BRN1WNEXMBX01.vcorp.ad.vrsn.com> I'm currently using GETDNS_COMPILATION_COMMENT in the PHP language bindings to display the getdns library version used to build the PHP extension. If GETDNS_COMPILATION_COMMENT goes away is there another way of retrieving the getdns library version information at compilation time? Scott > -----Original Message----- > From: Users [mailto:users-bounces at getdnsapi.net] On Behalf Of Daniel > Kahn Gillmor > Sent: Wednesday, July 08, 2015 1:52 PM > To: users at getdnsapi.net > Subject: [getdns-users] [PATCH] remove GETDNS_COMPILATION_COMMENT > > It's not clear that GETDNS_COMPILATION_COMMENT is useful; as a header > (a #define), it's likely to get embedded in applications during their > build time. It is not embedded in the library itself at all, so > removal of it doesn't change the ABI (there is a slight change in the > API because the #define is no longer visible in getdns.h, but i think > this is OK, see below). > > When a built application that uses GETDNS_COMPILATION_COMMENT is > executed, linked against a different version of the library it was > built from, there is no way to detect that these values differ. How > is it useful at runtime? > > The #define also introduces arbitrariness in the getdns build process > when --with-current-date isn't supplied, because it embeds the current > timestamp in getdns.h. This makes it more difficult to build a > byte-for-byte reproducible binary package. > > http://codesearch.debian.net/results/GETDNS_COMPILATION_COMMENT > indicates that there are no projects in debian actually using the > defined variable (there may be non-debian projects that use it, though > it's not clear how it is expected to be used at runtime at all). > > Removing this #define removes a source of confusion for users of the > project, and doesn't change the ABI. > --- > ChangeLog | 1 + > configure | 15 --------------- > configure.ac | 9 --------- > spec/index.html | 5 ----- > src/getdns/getdns.h.in | 2 -- > 5 files changed, 1 insertion(+), 31 deletions(-) > > diff --git a/ChangeLog b/ChangeLog > index a70879d..438c1b5 100644 > --- a/ChangeLog > +++ b/ChangeLog > @@ -5,6 +5,7 @@ > GETDNS_TRANSPORT_STARTTLS. > * Added new context setting for idle_timeout > * CSYNC RR type > + * remove GETDNS_COMPILATION_COMMENT, CURRENT_DATE, and --with- > current-date > > * 2015-05-21: Version 0.2.0 > * Fix libversion numbering: Thanks Daniel Kahn Gillmor > diff --git a/configure b/configure > index c86c59f..9e01aab 100755 > --- a/configure > +++ b/configure > @@ -706,7 +706,6 @@ LDFLAGS > CFLAGS > CC > GETDNS_LIBVERSION > -GETDNS_COMPILATION_COMMENT > RELEASE_CANDIDATE > target_alias > host_alias > @@ -749,7 +748,6 @@ SHELL' > ac_subst_files='' > ac_user_opts=' > enable_option_checking > -with_current_date > enable_shared > enable_static > with_pic > @@ -1420,8 +1418,6 @@ Optional Features: > Optional Packages: > --with-PACKAGE[=ARG] use PACKAGE [ARG=yes] > --without-PACKAGE do not use PACKAGE (same as --with- > PACKAGE=no) > - --with-current-date > - current date of the compilation, set to fixed date for > reproducible builds [default=system] > > --with-pic[=PKGS] try to use only PIC/non-PIC objects > [default=use > both] > @@ -2371,17 +2367,6 @@ ac_compiler_gnu=$ac_cv_c_compiler_gnu > > > > -# Set current date from system if not set > - > -# Check whether --with-current-date was given. > -if test "${with_current_date+set}" = set; then : > - withval=$with_current_date; CURRENT_DATE="$with_current_date" > -else > - CURRENT_DATE="`date -u +%Y-%m-%dT%H:%M:%SZ`" > -fi > - > -GETDNS_COMPILATION_COMMENT="getdns 0.2.0 configured on $CURRENT_DATE > for the January 2015 version of the API" > - > # Library version > # --------------- > # current:revision:age > diff --git a/configure.ac b/configure.ac > index 48bb399..ef060ea 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -34,14 +34,6 @@ AC_PREREQ([2.56]) > AC_INIT([getdns], [0.2.0], [stub-resolver at verisignlabs.com], [], > [http://getdnsapi.net]) > AC_SUBST(RELEASE_CANDIDATE, []) > > -# Set current date from system if not set > -AC_ARG_WITH([current-date], > - [AS_HELP_STRING([--with-current-date] > - [current date of the compilation, set to fixed date for > reproducible builds @<:@default=system@:>@])], > - [CURRENT_DATE="$with_current_date"], > - [CURRENT_DATE="`date -u +%Y-%m-%dT%H:%M:%SZ`"]) > -GETDNS_COMPILATION_COMMENT="AC_PACKAGE_STRING configured on > $CURRENT_DATE for the January 2015 version of the API" > - > # Library version > # --------------- > # current:revision:age > @@ -62,7 +54,6 @@ GETDNS_COMPILATION_COMMENT="AC_PACKAGE_STRING > configured on $CURRENT_DATE for th > # > GETDNS_LIBVERSION=2:2:1 > > -AC_SUBST(GETDNS_COMPILATION_COMMENT) > AC_SUBST(GETDNS_LIBVERSION) > AC_CONFIG_SRCDIR([src/getdns/getdns.h.in]) > # AM_INIT_AUTOMAKE > diff --git a/spec/index.html b/spec/index.html > index a98e37c..a6dd53a 100644 > --- a/spec/index.html > +++ b/spec/index.html > @@ -2521,11 +2521,6 @@ of this API must support synchronous calls with > getdns_general_sync() this API is "getdns April 2013". Each implementation is free to set > the implementation string as it > feels fit.

> > -

The API's .h file contains a macro called > GETDNS_COMPILATION_COMMENT. This can be useful > -to an application which will use the API because it can check the > string without calling any > -functions. Each time the API implementation is compiled, this string > should be updated with unique > -information about the implementation build.

> - >

The implementation of both the async and sync getdns > functions will > copy all the values of the parameters into local memory, in case the > application changes or > deallocates them.

> diff --git a/src/getdns/getdns.h.in b/src/getdns/getdns.h.in > index 3f133a4..133d9cb 100644 > --- a/src/getdns/getdns.h.in > +++ b/src/getdns/getdns.h.in > @@ -44,8 +44,6 @@ > extern "C" { > #endif > > -#define GETDNS_COMPILATION_COMMENT "@GETDNS_COMPILATION_COMMENT@" > - > /* Return values */ > typedef enum getdns_return_t { > GETDNS_RETURN_GOOD = 0, > -- > 2.1.4 > > _______________________________________________ > Users mailing list > Users at getdnsapi.net > http://getdnsapi.net/mailman/listinfo/users From melinda.shore at nomountain.net Wed Jul 8 18:06:55 2015 From: melinda.shore at nomountain.net (Melinda Shore) Date: Wed, 08 Jul 2015 10:06:55 -0800 Subject: [getdns-users] [PATCH] remove GETDNS_COMPILATION_COMMENT In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F4A016A89@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <1436377901-6300-1-git-send-email-dkg@fifthhorseman.net> <831693C2CDA2E849A7D7A712B24E257F4A016A89@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Message-ID: <559D66BF.20508@nomountain.net> On 7/8/15 9:58 AM, Hollenbeck, Scott wrote: > I'm currently using GETDNS_COMPILATION_COMMENT in the PHP language > bindings to display the getdns library version used to build the PHP > extension. If GETDNS_COMPILATION_COMMENT goes away is there another > way of retrieving the getdns library version information at > compilation time? Yes, you can pull version_string out of what's returned by context_get_api_info(). That's what I'm doing in the Python bindings. Melnda -- Melinda Shore No Mountain Software melinda.shore at nomountain.net "Software longa, hardware brevis." From dkg at fifthhorseman.net Wed Jul 8 18:14:29 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 08 Jul 2015 14:14:29 -0400 Subject: [getdns-users] [PATCH] remove GETDNS_COMPILATION_COMMENT In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F4A016A89@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <1436377901-6300-1-git-send-email-dkg@fifthhorseman.net> <831693C2CDA2E849A7D7A712B24E257F4A016A89@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Message-ID: <87380yh5yy.fsf@alice.fifthhorseman.net> Hi Scott-- Thanks for the quick response! I'm not sure of the answer to your questions, but i want to better understand why you want this info, and how it's useful. Maybe i'm missing a use case, in which case i'd happily withdraw my suggestion here. On Wed 2015-07-08 13:58:56 -0400, Hollenbeck, Scott wrote: > I'm currently using GETDNS_COMPILATION_COMMENT in the PHP language > bindings to display the getdns library version used to build the PHP > extension. How do you expect users (PHP developers, presumably) to actually use this? If the PHP binding uses shared libraries (links against libgetdnsapi.so.1 or whatever), what guarantees do your users have about what code they're actually running against? > If GETDNS_COMPILATION_COMMENT goes away is there another way of > retrieving the getdns library version information at compilation time? Why does library version information (other than the traditionally-tracked SONAME/ABI versioning scheme, which should be handled automatically during compilation based on -L) matter at compile time? getting library version information at runtime seems like it could be useful (e.g. we could introduce a const char* getdns_version_string()), but GETDNS_COMPILATION_COMMENT isn't useful for that in the first place, since it's a build-time and not a runtime setting. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From shollenbeck at verisign.com Wed Jul 8 18:19:11 2015 From: shollenbeck at verisign.com (Hollenbeck, Scott) Date: Wed, 8 Jul 2015 18:19:11 +0000 Subject: [getdns-users] [PATCH] remove GETDNS_COMPILATION_COMMENT In-Reply-To: <559D66BF.20508@nomountain.net> References: <1436377901-6300-1-git-send-email-dkg@fifthhorseman.net> <831693C2CDA2E849A7D7A712B24E257F4A016A89@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <559D66BF.20508@nomountain.net> Message-ID: <831693C2CDA2E849A7D7A712B24E257F4A016AD9@BRN1WNEXMBX01.vcorp.ad.vrsn.com> > -----Original Message----- > From: Users [mailto:users-bounces at getdnsapi.net] On Behalf Of Melinda > Shore > Sent: Wednesday, July 08, 2015 2:07 PM > To: users at getdnsapi.net > Subject: Re: [getdns-users] [PATCH] remove GETDNS_COMPILATION_COMMENT > > On 7/8/15 9:58 AM, Hollenbeck, Scott wrote: > > I'm currently using GETDNS_COMPILATION_COMMENT in the PHP language > > bindings to display the getdns library version used to build the PHP > > extension. If GETDNS_COMPILATION_COMMENT goes away is there another > > way of retrieving the getdns library version information at > > compilation time? > > Yes, you can pull version_string out of what's returned by > context_get_api_info(). That's what I'm doing in the Python > bindings. That means I would need to create a context, send a query, parse the returned dictionary, and destroy the context every time PHP loads the extension. I'd much rather use a defined constant (just the version number would be useful) that could be available when the extension is compiled. Scott From dkg at fifthhorseman.net Wed Jul 8 18:20:55 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 08 Jul 2015 14:20:55 -0400 Subject: [getdns-users] [PATCH] remove GETDNS_COMPILATION_COMMENT In-Reply-To: <87380yh5yy.fsf@alice.fifthhorseman.net> References: <1436377901-6300-1-git-send-email-dkg@fifthhorseman.net> <831693C2CDA2E849A7D7A712B24E257F4A016A89@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <87380yh5yy.fsf@alice.fifthhorseman.net> Message-ID: <87y4iqfr3s.fsf@alice.fifthhorseman.net> On Wed 2015-07-08 14:14:29 -0400, Daniel Kahn Gillmor wrote: > getting library version information at runtime seems like it could be > useful (e.g. we could introduce a const char* getdns_version_string()), I retract this suggestion in deference to Melinda's better-informed suggestion upthread about extracting a string from context_get_api_info() -- no need to introduce a new function. --dkg From dkg at fifthhorseman.net Wed Jul 8 18:26:29 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 08 Jul 2015 14:26:29 -0400 Subject: [getdns-users] [PATCH] remove GETDNS_COMPILATION_COMMENT In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F4A016AD9@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <1436377901-6300-1-git-send-email-dkg@fifthhorseman.net> <831693C2CDA2E849A7D7A712B24E257F4A016A89@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <559D66BF.20508@nomountain.net> <831693C2CDA2E849A7D7A712B24E257F4A016AD9@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Message-ID: <87si8yfqui.fsf@alice.fifthhorseman.net> On Wed 2015-07-08 14:19:11 -0400, Hollenbeck, Scott wrote: > [Melinda Shore wrote:] >> Yes, you can pull version_string out of what's returned by >> context_get_api_info(). That's what I'm doing in the Python >> bindings. > > That means I would need to create a context, send a query, parse the > returned dictionary, and destroy the context every time PHP loads the > extension. I'd much rather use a defined constant (just the version > number would be useful) that could be available when the extension is > compiled. Is there any circumstance where two separate contexts could return a different api_info ? --dkg From shollenbeck at verisign.com Wed Jul 8 18:32:40 2015 From: shollenbeck at verisign.com (Hollenbeck, Scott) Date: Wed, 8 Jul 2015 18:32:40 +0000 Subject: [getdns-users] [PATCH] remove GETDNS_COMPILATION_COMMENT In-Reply-To: <87380yh5yy.fsf@alice.fifthhorseman.net> References: <1436377901-6300-1-git-send-email-dkg@fifthhorseman.net> <831693C2CDA2E849A7D7A712B24E257F4A016A89@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <87380yh5yy.fsf@alice.fifthhorseman.net> Message-ID: <831693C2CDA2E849A7D7A712B24E257F4A016B3E@BRN1WNEXMBX01.vcorp.ad.vrsn.com> > -----Original Message----- > From: Daniel Kahn Gillmor [mailto:dkg at fifthhorseman.net] > Sent: Wednesday, July 08, 2015 2:14 PM > To: Hollenbeck, Scott; libgetdns users list > Subject: Re: [getdns-users] [PATCH] remove GETDNS_COMPILATION_COMMENT > > Hi Scott-- > > Thanks for the quick response! I'm not sure of the answer to your > questions, but i want to better understand why you want this info, and > how it's useful. Maybe i'm missing a use case, in which case i'd > happily withdraw my suggestion here. > > On Wed 2015-07-08 13:58:56 -0400, Hollenbeck, Scott wrote: > > I'm currently using GETDNS_COMPILATION_COMMENT in the PHP language > > bindings to display the getdns library version used to build the PHP > > extension. > > How do you expect users (PHP developers, presumably) to actually use > this? If the PHP binding uses shared libraries (links against > libgetdnsapi.so.1 or whatever), what guarantees do your users have > about > what code they're actually running against? > > > If GETDNS_COMPILATION_COMMENT goes away is there another way of > > retrieving the getdns library version information at compilation > time? > > Why does library version information (other than the > traditionally-tracked SONAME/ABI versioning scheme, which should be > handled automatically during compilation based on -L) matter at compile > time? > > getting library version information at runtime seems like it could be > useful (e.g. we could introduce a const char* getdns_version_string()), > but GETDNS_COMPILATION_COMMENT isn't useful for that in the first > place, > since it's a build-time and not a runtime setting. Here's my use case: PHP extensions can publish information that is made available to clients who call the phpinfo() function. It's typically used to publish version numbers, information about dependencies, and the like. Here's what my PHP extension currently publishes: "getdns GetDNS Support => enabled Extension Version => 0.7.2 getdns Library Version => getdns 0.2.0 configured on 2015-05-21T12:51:51Z for the January 2015 version of the API Author => Scott Hollenbeck " I currently get the "getdns Library Version" information using GETDNS_COMPILATION_COMMENT because it's compiled into my code and available when PHP loads the extension. There are no function calls that might break at run time if the getdns library isn't available. I need a value that is 100% guaranteed to be available when PHP loads the extension even if the getdns library is unavailable. Scott From shollenbeck at verisign.com Wed Jul 8 18:37:08 2015 From: shollenbeck at verisign.com (Hollenbeck, Scott) Date: Wed, 8 Jul 2015 18:37:08 +0000 Subject: [getdns-users] [PATCH] remove GETDNS_COMPILATION_COMMENT In-Reply-To: <87si8yfqui.fsf@alice.fifthhorseman.net> References: <1436377901-6300-1-git-send-email-dkg@fifthhorseman.net> <831693C2CDA2E849A7D7A712B24E257F4A016A89@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <559D66BF.20508@nomountain.net> <831693C2CDA2E849A7D7A712B24E257F4A016AD9@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <87si8yfqui.fsf@alice.fifthhorseman.net> Message-ID: <831693C2CDA2E849A7D7A712B24E257F4A016B5D@BRN1WNEXMBX01.vcorp.ad.vrsn.com> > -----Original Message----- > From: Daniel Kahn Gillmor [mailto:dkg at fifthhorseman.net] > Sent: Wednesday, July 08, 2015 2:26 PM > To: Hollenbeck, Scott; libgetdns users list > Subject: Re: [getdns-users] [PATCH] remove GETDNS_COMPILATION_COMMENT > > On Wed 2015-07-08 14:19:11 -0400, Hollenbeck, Scott wrote: > > [Melinda Shore wrote:] > >> Yes, you can pull version_string out of what's returned by > >> context_get_api_info(). That's what I'm doing in the Python > >> bindings. > > > > That means I would need to create a context, send a query, parse the > > returned dictionary, and destroy the context every time PHP loads the > > extension. I'd much rather use a defined constant (just the version > > number would be useful) that could be available when the extension is > > compiled. > > Is there any circumstance where two separate contexts could return a > different api_info ? I don't think so, at least not with two contexts created with the same loaded instance of my extension. Scott From melinda.shore at nomountain.net Wed Jul 8 18:54:33 2015 From: melinda.shore at nomountain.net (Melinda Shore) Date: Wed, 08 Jul 2015 10:54:33 -0800 Subject: [getdns-users] [PATCH] remove GETDNS_COMPILATION_COMMENT In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F4A016AD9@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <1436377901-6300-1-git-send-email-dkg@fifthhorseman.net> <831693C2CDA2E849A7D7A712B24E257F4A016A89@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <559D66BF.20508@nomountain.net> <831693C2CDA2E849A7D7A712B24E257F4A016AD9@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Message-ID: <559D71E9.5030106@nomountain.net> On 7/8/15 10:19 AM, Hollenbeck, Scott wrote: > That means I would need to create a context, send a query, parse the > returned dictionary, and destroy the context every time PHP loads the > extension. I'd much rather use a defined constant (just the version > number would be useful) that could be available when the extension is > compiled. Well, as Daniel points out that tells you which version you compiled against, not which you're running against, and I'm not sure that's actually useful (runtime version would be). Library version string is associated with a context in the API definition and that may not have been a great decision but it's what we've got. Melinda -- Melinda Shore No Mountain Software melinda.shore at nomountain.net "Software longa, hardware brevis." From dkg at fifthhorseman.net Wed Jul 8 18:57:04 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 08 Jul 2015 14:57:04 -0400 Subject: [getdns-users] [PATCH] remove GETDNS_COMPILATION_COMMENT In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F4A016B3E@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <1436377901-6300-1-git-send-email-dkg@fifthhorseman.net> <831693C2CDA2E849A7D7A712B24E257F4A016A89@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <87380yh5yy.fsf@alice.fifthhorseman.net> <831693C2CDA2E849A7D7A712B24E257F4A016B3E@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Message-ID: <87lheqfpfj.fsf@alice.fifthhorseman.net> On Wed 2015-07-08 14:32:40 -0400, Hollenbeck, Scott wrote: > Here's my use case: > > PHP extensions can publish information that is made available to > clients who call the phpinfo() function. It's typically used to > publish version numbers, information about dependencies, and the > like. Here's what my PHP extension currently publishes: > > "getdns > > GetDNS Support => enabled > Extension Version => 0.7.2 > getdns Library Version => getdns 0.2.0 configured on 2015-05-21T12:51:51Z for the January 2015 version of the API > Author => Scott Hollenbeck " > > I currently get the "getdns Library Version" information using > GETDNS_COMPILATION_COMMENT because it's compiled into my code and > available when PHP loads the extension. There are no function calls > that might break at run time if the getdns library isn't available. I > need a value that is 100% guaranteed to be available when PHP loads > the extension even if the getdns library is unavailable. hm, i don't think other comparable php bindings have the same constraint (or maybe they're buggy?). Do you want to report "GetDNS Support => enabled" even if the getdns library is unavailable? By comparison, the jsonc module produces its info output from both compile-time and runtime information: http://sources.debian.net/src/php-json/1.3.6-1/jsonc-1.3.6/json.c/#L278 If i move libjson-c.so.2 out of the way (so that dlopen can't find it) and re-run phpinfo(), i find that the php json module just doesn't load at all, and produces nothing in phpinfo(): ---------------- 0 dkg at alice:~$ printf '' | php | grep -C2 -i ^json imagick.skip_version_check => 0 => 0 json json support => enabled json version => 1.3.6 JSON-C headers version => 0.11.99 JSON-C library version => 0.11.99 libxml 0 dkg at alice:~$ printf '' | php | grep -C2 -i ^json PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php5/20131226/json.so' - libjson-c.so.2: cannot open shared object file: No such file or directory in Unknown on line 0 1 dkg at alice:~$ ---------------- Should getdns be different? --dkg From dkg at fifthhorseman.net Wed Jul 8 19:02:56 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 08 Jul 2015 15:02:56 -0400 Subject: [getdns-users] [PATCH] remove GETDNS_COMPILATION_COMMENT In-Reply-To: <559D71E9.5030106@nomountain.net> References: <1436377901-6300-1-git-send-email-dkg@fifthhorseman.net> <831693C2CDA2E849A7D7A712B24E257F4A016A89@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <559D66BF.20508@nomountain.net> <831693C2CDA2E849A7D7A712B24E257F4A016AD9@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <559D71E9.5030106@nomountain.net> Message-ID: <87d202fp5r.fsf@alice.fifthhorseman.net> On Wed 2015-07-08 14:54:33 -0400, Melinda Shore wrote: > On 7/8/15 10:19 AM, Hollenbeck, Scott wrote: >> That means I would need to create a context, send a query, parse the >> returned dictionary, and destroy the context every time PHP loads the >> extension. I'd much rather use a defined constant (just the version >> number would be useful) that could be available when the extension is >> compiled. > > Well, as Daniel points out that tells you which version you compiled > against, not which you're running against, and I'm not sure that's > actually useful (runtime version would be). Library version string is > associated with a context in the API definition and that may not have > been a great decision but it's what we've got. We could also add a version info function without breaking backward API compatibility, if the concern is that the cost of making a context and parsing the response is too expensive. During build time, it's also possible (albeit a little bit of hoop-jumping) to extract the library's runtime version if you want to embed that in your binding. (though i'm still not sure how useful that is). --dkg From edmonds at debian.org Wed Jul 8 19:57:13 2015 From: edmonds at debian.org (Robert Edmonds) Date: Wed, 8 Jul 2015 15:57:13 -0400 Subject: [getdns-users] [PATCH] remove GETDNS_COMPILATION_COMMENT In-Reply-To: <87d202fp5r.fsf@alice.fifthhorseman.net> References: <1436377901-6300-1-git-send-email-dkg@fifthhorseman.net> <831693C2CDA2E849A7D7A712B24E257F4A016A89@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <559D66BF.20508@nomountain.net> <831693C2CDA2E849A7D7A712B24E257F4A016AD9@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <559D71E9.5030106@nomountain.net> <87d202fp5r.fsf@alice.fifthhorseman.net> Message-ID: <20150708195713.GA3732@mycre.ws> Daniel Kahn Gillmor wrote: > We could also add a version info function without breaking backward API > compatibility, if the concern is that the cost of making a context and > parsing the response is too expensive. I recently added version info capabilities to a C library that I maintain. I based it on how libevent2 does it, which is to export library functions that return the version number as a string or encoded into a 32-bit integer. libevent2 also exposes the same values as library headers. [...] /** Get the Libevent version. Note that this will give you the version of the library that you're currently linked against, not the version of the headers that you've compiled against. @return a string containing the version number of Libevent */ const char *event_get_version(void); /** Return a numeric representation of Libevent's version. Note that this will give you the version of the library that you're currently linked against, not the version of the headers you've used to compile. The format uses one byte each for the major, minor, and patchlevel parts of the version number. The low-order byte is unused. For example, version 2.0.1-alpha has a numeric representation of 0x02000100 */ ev_uint32_t event_get_version_number(void); /** As event_get_version, but gives the version of Libevent's headers. */ #define LIBEVENT_VERSION _EVENT_VERSION /** As event_get_version_number, but gives the version number of Libevent's * headers. */ #define LIBEVENT_VERSION_NUMBER _EVENT_NUMERIC_VERSION [...] /* Version number of package */ #define _EVENT_VERSION "2.0.21-stable" [...] /* Numeric representation of the version */ #define _EVENT_NUMERIC_VERSION 0x02001500 [...] So you get the version number in two different forms (string/numeric), and for both the headers that were used at compile time as well as the runtime library. I'm not saying it's a good idea to rely on these for anything, but this seems to cover the use cases commonly requested by library users, at least IME. +1 to reproducible builds. -- Robert Edmonds edmonds at debian.org From dkg at fifthhorseman.net Wed Jul 8 22:42:45 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 08 Jul 2015 18:42:45 -0400 Subject: [getdns-users] git rm spec/getdns-0.601.tgz ? Message-ID: <877fqae0ey.fsf@alice.fifthhorseman.net> I just noticed that there's a tarball in the develop branch at spec/getdns-0.601.tgz. Does that belong there? if so, why, and what is it for? It was only touched a couple days ago, maybe in a mistaken commit? 0 dkg at alice:~/src/getdns/getdns$ git log spec/*.tgz commit 43980e90208d89be326d3167d26542b4ab5072b6 Author: Willem Toorop Date: Mon Jul 6 14:14:46 2015 +0200 [API 0.601] CSYNC RR type 0 dkg at alice:~/src/getdns/getdns$ --dkg From willem at nlnetlabs.nl Thu Jul 9 07:54:25 2015 From: willem at nlnetlabs.nl (Willem Toorop) Date: Thu, 09 Jul 2015 09:54:25 +0200 Subject: [getdns-users] git rm spec/getdns-0.601.tgz ? In-Reply-To: <877fqae0ey.fsf@alice.fifthhorseman.net> References: <877fqae0ey.fsf@alice.fifthhorseman.net> Message-ID: <559E28B1.5070304@nlnetlabs.nl> Hi Daniel, The API spec was there before the implementation. It has it's own repository which is not public (it is at vpnc.org). It contains a script which creates the index.html specification from a templates (and the examples C code) and it also produces the tarball which is referenced from the index.html spec. Although we've also taken over the editor's pen, I still commit modifications to the spec on the repository at vpnc.org and use the script therein to generate it. We include the spec within the repository to publish the version of the spec that the library implements. Since the spec references the tarball, I've until now included that too. The examples from the spec within the tarball are extracted though, because I've created some support files around it (Makefile.in and a different getdns_core_only.h and getdns_libevent.h) to enable compiling the examples with the library. -- Willem Op 09-07-15 om 00:42 schreef Daniel Kahn Gillmor: > I just noticed that there's a tarball in the develop branch at > spec/getdns-0.601.tgz. Does that belong there? if so, why, and what is > it for? It was only touched a couple days ago, maybe in a mistaken > commit? > > 0 dkg at alice:~/src/getdns/getdns$ git log spec/*.tgz > commit 43980e90208d89be326d3167d26542b4ab5072b6 > Author: Willem Toorop > Date: Mon Jul 6 14:14:46 2015 +0200 > > [API 0.601] CSYNC RR type > 0 dkg at alice:~/src/getdns/getdns$ > > --dkg > _______________________________________________ > Users mailing list > Users at getdnsapi.net > http://getdnsapi.net/mailman/listinfo/users > From willem at nlnetlabs.nl Thu Jul 9 08:11:20 2015 From: willem at nlnetlabs.nl (Willem Toorop) Date: Thu, 09 Jul 2015 10:11:20 +0200 Subject: [getdns-users] [PATCH] remove GETDNS_COMPILATION_COMMENT In-Reply-To: <1436377901-6300-1-git-send-email-dkg@fifthhorseman.net> References: <1436377901-6300-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <559E2CA8.7030601@nlnetlabs.nl> Thank you Daniel, The way it works now is ordained by the API specification. I quote from section 10.2: The API's .h file contains a macro called GETDNS_COMPILATION_COMMENT. This can be useful to an application which will use the API because it can check the string without calling any functions. Each time the API implementation is compiled, this string should be updated with unique information about the implementation build. The define from the getdns_core_only.h file from the API spec tarball, has this value: #define GETDNS_COMPILATION_COMMENT The API implementation should fill in something here, such as a compilation version string and date, and change it each time the API is compiled. Hence the way it is. We can change of course, with the consensus of the people on the API list (CC'ed). You could propose some new text. Cheers, -- Willem Op 08-07-15 om 19:51 schreef Daniel Kahn Gillmor: > It's not clear that GETDNS_COMPILATION_COMMENT is useful; as a header > (a #define), it's likely to get embedded in applications during their > build time. It is not embedded in the library itself at all, so > removal of it doesn't change the ABI (there is a slight change in the > API because the #define is no longer visible in getdns.h, but i think > this is OK, see below). > > When a built application that uses GETDNS_COMPILATION_COMMENT is > executed, linked against a different version of the library it was > built from, there is no way to detect that these values differ. How > is it useful at runtime? > > The #define also introduces arbitrariness in the getdns build process > when --with-current-date isn't supplied, because it embeds the current > timestamp in getdns.h. This makes it more difficult to build a > byte-for-byte reproducible binary package. > > http://codesearch.debian.net/results/GETDNS_COMPILATION_COMMENT > indicates that there are no projects in debian actually using the > defined variable (there may be non-debian projects that use it, though > it's not clear how it is expected to be used at runtime at all). > > Removing this #define removes a source of confusion for users of the > project, and doesn't change the ABI. > --- > ChangeLog | 1 + > configure | 15 --------------- > configure.ac | 9 --------- > spec/index.html | 5 ----- > src/getdns/getdns.h.in | 2 -- > 5 files changed, 1 insertion(+), 31 deletions(-) > > diff --git a/ChangeLog b/ChangeLog > index a70879d..438c1b5 100644 > --- a/ChangeLog > +++ b/ChangeLog > @@ -5,6 +5,7 @@ > GETDNS_TRANSPORT_STARTTLS. > * Added new context setting for idle_timeout > * CSYNC RR type > + * remove GETDNS_COMPILATION_COMMENT, CURRENT_DATE, and --with-current-date > > * 2015-05-21: Version 0.2.0 > * Fix libversion numbering: Thanks Daniel Kahn Gillmor > diff --git a/configure b/configure > index c86c59f..9e01aab 100755 > --- a/configure > +++ b/configure > @@ -706,7 +706,6 @@ LDFLAGS > CFLAGS > CC > GETDNS_LIBVERSION > -GETDNS_COMPILATION_COMMENT > RELEASE_CANDIDATE > target_alias > host_alias > @@ -749,7 +748,6 @@ SHELL' > ac_subst_files='' > ac_user_opts=' > enable_option_checking > -with_current_date > enable_shared > enable_static > with_pic > @@ -1420,8 +1418,6 @@ Optional Features: > Optional Packages: > --with-PACKAGE[=ARG] use PACKAGE [ARG=yes] > --without-PACKAGE do not use PACKAGE (same as --with-PACKAGE=no) > - --with-current-date > - current date of the compilation, set to fixed date for reproducible builds [default=system] > > --with-pic[=PKGS] try to use only PIC/non-PIC objects [default=use > both] > @@ -2371,17 +2367,6 @@ ac_compiler_gnu=$ac_cv_c_compiler_gnu > > > > -# Set current date from system if not set > - > -# Check whether --with-current-date was given. > -if test "${with_current_date+set}" = set; then : > - withval=$with_current_date; CURRENT_DATE="$with_current_date" > -else > - CURRENT_DATE="`date -u +%Y-%m-%dT%H:%M:%SZ`" > -fi > - > -GETDNS_COMPILATION_COMMENT="getdns 0.2.0 configured on $CURRENT_DATE for the January 2015 version of the API" > - > # Library version > # --------------- > # current:revision:age > diff --git a/configure.ac b/configure.ac > index 48bb399..ef060ea 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -34,14 +34,6 @@ AC_PREREQ([2.56]) > AC_INIT([getdns], [0.2.0], [stub-resolver at verisignlabs.com], [], [http://getdnsapi.net]) > AC_SUBST(RELEASE_CANDIDATE, []) > > -# Set current date from system if not set > -AC_ARG_WITH([current-date], > - [AS_HELP_STRING([--with-current-date] > - [current date of the compilation, set to fixed date for reproducible builds @<:@default=system@:>@])], > - [CURRENT_DATE="$with_current_date"], > - [CURRENT_DATE="`date -u +%Y-%m-%dT%H:%M:%SZ`"]) > -GETDNS_COMPILATION_COMMENT="AC_PACKAGE_STRING configured on $CURRENT_DATE for the January 2015 version of the API" > - > # Library version > # --------------- > # current:revision:age > @@ -62,7 +54,6 @@ GETDNS_COMPILATION_COMMENT="AC_PACKAGE_STRING configured on $CURRENT_DATE for th > # > GETDNS_LIBVERSION=2:2:1 > > -AC_SUBST(GETDNS_COMPILATION_COMMENT) > AC_SUBST(GETDNS_LIBVERSION) > AC_CONFIG_SRCDIR([src/getdns/getdns.h.in]) > # AM_INIT_AUTOMAKE > diff --git a/spec/index.html b/spec/index.html > index a98e37c..a6dd53a 100644 > --- a/spec/index.html > +++ b/spec/index.html > @@ -2521,11 +2521,6 @@ of this API must support synchronous calls with getdns_general_sync() this API is "getdns April 2013". Each implementation is free to set the implementation string as it > feels fit.

> > -

The API's .h file contains a macro called GETDNS_COMPILATION_COMMENT. This can be useful > -to an application which will use the API because it can check the string without calling any > -functions. Each time the API implementation is compiled, this string should be updated with unique > -information about the implementation build.

> - >

The implementation of both the async and sync getdns functions will > copy all the values of the parameters into local memory, in case the application changes or > deallocates them.

> diff --git a/src/getdns/getdns.h.in b/src/getdns/getdns.h.in > index 3f133a4..133d9cb 100644 > --- a/src/getdns/getdns.h.in > +++ b/src/getdns/getdns.h.in > @@ -44,8 +44,6 @@ > extern "C" { > #endif > > -#define GETDNS_COMPILATION_COMMENT "@GETDNS_COMPILATION_COMMENT@" > - > /* Return values */ > typedef enum getdns_return_t { > GETDNS_RETURN_GOOD = 0, > From willem at nlnetlabs.nl Thu Jul 9 08:21:26 2015 From: willem at nlnetlabs.nl (Willem Toorop) Date: Thu, 09 Jul 2015 10:21:26 +0200 Subject: [getdns-users] [PATCH] remove GETDNS_COMPILATION_COMMENT In-Reply-To: <20150708195713.GA3732@mycre.ws> References: <1436377901-6300-1-git-send-email-dkg@fifthhorseman.net> <831693C2CDA2E849A7D7A712B24E257F4A016A89@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <559D66BF.20508@nomountain.net> <831693C2CDA2E849A7D7A712B24E257F4A016AD9@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <559D71E9.5030106@nomountain.net> <87d202fp5r.fsf@alice.fifthhorseman.net> <20150708195713.GA3732@mycre.ws> Message-ID: <559E2F06.6090407@nlnetlabs.nl> Thanks Robert, I think I prefer this. If everybody here agrees I can put version functions and defines in getdns_extra.h. We can always move them to getdns.h if the API list likes it this way too. -- Willem Op 08-07-15 om 21:57 schreef Robert Edmonds: > Daniel Kahn Gillmor wrote: >> We could also add a version info function without breaking backward API >> compatibility, if the concern is that the cost of making a context and >> parsing the response is too expensive. > > I recently added version info capabilities to a C library that I > maintain. I based it on how libevent2 does it, which is to export > library functions that return the version number as a string or encoded > into a 32-bit integer. libevent2 also exposes the same values as > library headers. > > [...] > /** > Get the Libevent version. > > Note that this will give you the version of the library that you're > currently linked against, not the version of the headers that you've > compiled against. > > @return a string containing the version number of Libevent > */ > const char *event_get_version(void); > > /** > Return a numeric representation of Libevent's version. > > Note that this will give you the version of the library that you're > currently linked against, not the version of the headers you've used to > compile. > > The format uses one byte each for the major, minor, and patchlevel parts of > the version number. The low-order byte is unused. For example, version > 2.0.1-alpha has a numeric representation of 0x02000100 > */ > ev_uint32_t event_get_version_number(void); > > /** As event_get_version, but gives the version of Libevent's headers. */ > #define LIBEVENT_VERSION _EVENT_VERSION > /** As event_get_version_number, but gives the version number of Libevent's > * headers. */ > #define LIBEVENT_VERSION_NUMBER _EVENT_NUMERIC_VERSION > [...] > /* Version number of package */ > #define _EVENT_VERSION "2.0.21-stable" > [...] > /* Numeric representation of the version */ > #define _EVENT_NUMERIC_VERSION 0x02001500 > [...] > > So you get the version number in two different forms (string/numeric), > and for both the headers that were used at compile time as well as the > runtime library. > > I'm not saying it's a good idea to rely on these for anything, but this > seems to cover the use cases commonly requested by library users, at > least IME. > > +1 to reproducible builds. > From shollenbeck at verisign.com Thu Jul 9 10:54:46 2015 From: shollenbeck at verisign.com (Hollenbeck, Scott) Date: Thu, 9 Jul 2015 10:54:46 +0000 Subject: [getdns-users] [PATCH] remove GETDNS_COMPILATION_COMMENT In-Reply-To: <559E2F06.6090407@nlnetlabs.nl> References: <1436377901-6300-1-git-send-email-dkg@fifthhorseman.net> <831693C2CDA2E849A7D7A712B24E257F4A016A89@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <559D66BF.20508@nomountain.net> <831693C2CDA2E849A7D7A712B24E257F4A016AD9@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <559D71E9.5030106@nomountain.net> <87d202fp5r.fsf@alice.fifthhorseman.net> <20150708195713.GA3732@mycre.ws> <559E2F06.6090407@nlnetlabs.nl> Message-ID: <831693C2CDA2E849A7D7A712B24E257F4A01731A@BRN1WNEXMBX01.vcorp.ad.vrsn.com> > -----Original Message----- > From: Users [mailto:users-bounces at getdnsapi.net] On Behalf Of Willem > Toorop > Sent: Thursday, July 09, 2015 4:21 AM > To: users at getdnsapi.net > Subject: Re: [getdns-users] [PATCH] remove GETDNS_COMPILATION_COMMENT > > Thanks Robert, > > I think I prefer this. If everybody here agrees I can put version > functions and defines in getdns_extra.h. We can always move them to > getdns.h if the API list likes it this way too. Same here, as long as any functions are lightweight. Scott From ngoyal at gmail.com Thu Jul 9 11:52:53 2015 From: ngoyal at gmail.com (Neel Goyal) Date: Thu, 09 Jul 2015 11:52:53 +0000 Subject: [getdns-users] [PATCH] remove GETDNS_COMPILATION_COMMENT In-Reply-To: <559E2F06.6090407@nlnetlabs.nl> References: <1436377901-6300-1-git-send-email-dkg@fifthhorseman.net> <831693C2CDA2E849A7D7A712B24E257F4A016A89@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <559D66BF.20508@nomountain.net> <831693C2CDA2E849A7D7A712B24E257F4A016AD9@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <559D71E9.5030106@nomountain.net> <87d202fp5r.fsf@alice.fifthhorseman.net> <20150708195713.GA3732@mycre.ws> <559E2F06.6090407@nlnetlabs.nl> Message-ID: I think this approach also makes sense. Never a bad thing to follow precedence. On Thu, Jul 9, 2015 at 4:21 AM Willem Toorop wrote: > Thanks Robert, > > I think I prefer this. If everybody here agrees I can put version > functions and defines in getdns_extra.h. We can always move them to > getdns.h if the API list likes it this way too. > > -- Willem > > > Op 08-07-15 om 21:57 schreef Robert Edmonds: > > Daniel Kahn Gillmor wrote: > >> We could also add a version info function without breaking backward API > >> compatibility, if the concern is that the cost of making a context and > >> parsing the response is too expensive. > > > > I recently added version info capabilities to a C library that I > > maintain. I based it on how libevent2 does it, which is to export > > library functions that return the version number as a string or encoded > > into a 32-bit integer. libevent2 also exposes the same values as > > library headers. > > > > [...] > > /** > > Get the Libevent version. > > > > Note that this will give you the version of the library that > you're > > currently linked against, not the version of the headers that > you've > > compiled against. > > > > @return a string containing the version number of Libevent > > */ > > const char *event_get_version(void); > > > > /** > > Return a numeric representation of Libevent's version. > > > > Note that this will give you the version of the library that > you're > > currently linked against, not the version of the headers you've > used to > > compile. > > > > The format uses one byte each for the major, minor, and > patchlevel parts of > > the version number. The low-order byte is unused. For example, > version > > 2.0.1-alpha has a numeric representation of 0x02000100 > > */ > > ev_uint32_t event_get_version_number(void); > > > > /** As event_get_version, but gives the version of Libevent's > headers. */ > > #define LIBEVENT_VERSION _EVENT_VERSION > > /** As event_get_version_number, but gives the version number of > Libevent's > > * headers. */ > > #define LIBEVENT_VERSION_NUMBER _EVENT_NUMERIC_VERSION > > [...] > > /* Version number of package */ > > #define _EVENT_VERSION "2.0.21-stable" > > [...] > > /* Numeric representation of the version */ > > #define _EVENT_NUMERIC_VERSION 0x02001500 > > [...] > > > > So you get the version number in two different forms (string/numeric), > > and for both the headers that were used at compile time as well as the > > runtime library. > > > > I'm not saying it's a good idea to rely on these for anything, but this > > seems to cover the use cases commonly requested by library users, at > > least IME. > > > > +1 to reproducible builds. > > > > _______________________________________________ > Users mailing list > Users at getdnsapi.net > http://getdnsapi.net/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From melinda.shore at nomountain.net Thu Jul 9 13:26:22 2015 From: melinda.shore at nomountain.net (Melinda Shore) Date: Thu, 09 Jul 2015 05:26:22 -0800 Subject: [getdns-users] [PATCH] remove GETDNS_COMPILATION_COMMENT In-Reply-To: <559E2F06.6090407@nlnetlabs.nl> References: <1436377901-6300-1-git-send-email-dkg@fifthhorseman.net> <831693C2CDA2E849A7D7A712B24E257F4A016A89@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <559D66BF.20508@nomountain.net> <831693C2CDA2E849A7D7A712B24E257F4A016AD9@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <559D71E9.5030106@nomountain.net> <87d202fp5r.fsf@alice.fifthhorseman.net> <20150708195713.GA3732@mycre.ws> <559E2F06.6090407@nlnetlabs.nl> Message-ID: <559E767E.90803@nomountain.net> On 7/9/15 12:21 AM, Willem Toorop wrote: > I think I prefer this. If everybody here agrees I can put version > functions and defines in getdns_extra.h. We can always move them to > getdns.h if the API list likes it this way too. I agree! Melinda -- Melinda Shore No Mountain Software melinda.shore at nomountain.net "Software longa, hardware brevis." From edmonds at debian.org Thu Jul 9 17:07:58 2015 From: edmonds at debian.org (Robert Edmonds) Date: Thu, 9 Jul 2015 13:07:58 -0400 Subject: [getdns-users] [PATCH] remove GETDNS_COMPILATION_COMMENT In-Reply-To: <559D66BF.20508@nomountain.net> References: <1436377901-6300-1-git-send-email-dkg@fifthhorseman.net> <831693C2CDA2E849A7D7A712B24E257F4A016A89@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <559D66BF.20508@nomountain.net> Message-ID: <20150709170758.GA26599@mycre.ws> Melinda Shore wrote: > On 7/8/15 9:58 AM, Hollenbeck, Scott wrote: > > I'm currently using GETDNS_COMPILATION_COMMENT in the PHP language > > bindings to display the getdns library version used to build the PHP > > extension. If GETDNS_COMPILATION_COMMENT goes away is there another > > way of retrieving the getdns library version information at > > compilation time? > > Yes, you can pull version_string out of what's returned by > context_get_api_info(). That's what I'm doing in the Python > bindings. Looking at the version-related stuff in http://www.vpnc.org/getdns-api/, I'm a bit confused. The 'version_string' field in the dict returned by getdns_context_get_api_information() is defined as: version_string (a bindata) represents the version string for this version of the DNS API. That's the version of the getdns API, right? Which is supposed to be something like "getdns February 2014". But in getdns (argh, the "getdns" implementation, not the "getdns API"), that field is set to something like (in hexadecimal notation) 30 2E 32 2E 30 00 (i.e., the NUL-terminated C string "0.2.0"), which is the getdns PACKAGE_VERSION value. Shouldn't the version of the API rather than the implementation be returned in version_string? That seems to be implied by the function being called getdns_context_get_*api*_information(). -- Robert Edmonds edmonds at debian.org From dkg at fifthhorseman.net Thu Jul 9 18:05:21 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 09 Jul 2015 14:05:21 -0400 Subject: [getdns-users] [PATCH] remove GETDNS_COMPILATION_COMMENT In-Reply-To: <559E2CA8.7030601@nlnetlabs.nl> References: <1436377901-6300-1-git-send-email-dkg@fifthhorseman.net> <559E2CA8.7030601@nlnetlabs.nl> Message-ID: <87k2u9cila.fsf@alice.fifthhorseman.net> On Thu 2015-07-09 04:11:20 -0400, Willem Toorop wrote: > Thank you Daniel, > > The way it works now is ordained by the API specification. > I quote from section 10.2: > > The API's .h file contains a macro called > GETDNS_COMPILATION_COMMENT. This can be useful to an > application which will use the API because it can check the > string without calling any functions. Each time the API > implementation is compiled, this string should be updated with > unique information about the implementation build. yes, my patch removed that section from the spec because i don't see how it is ever useful. Simpler is better :) > The define from the getdns_core_only.h file from the API spec tarball, > has this value: > > #define GETDNS_COMPILATION_COMMENT The API implementation should fill > in something here, such as a compilation version string and date, and > change it each time the API is compiled. > > Hence the way it is. But why is this useful? What aim does it serve? The request to embed a change each time it's compiled seems like it makes things unreproducible for the sake of unreproducibility. *and* it doesn't help users figure anything out at runtime. > We can change of course, with the consensus of the people on the API > list (CC'ed). You could propose some new text. I propose to remove it entirely :) If we need a way to fetch library versioning information, it should be done at runtime, along the lines of libevent versioning (or other similar libraries, as discussed on the getdns-users list. --dkg From edmonds at debian.org Thu Jul 9 18:42:59 2015 From: edmonds at debian.org (Robert Edmonds) Date: Thu, 9 Jul 2015 14:42:59 -0400 Subject: [getdns-users] bindata string encoding? (was: Re: [PATCH] remove GETDNS_COMPILATION_COMMENT) In-Reply-To: <20150709170758.GA26599@mycre.ws> References: <1436377901-6300-1-git-send-email-dkg@fifthhorseman.net> <831693C2CDA2E849A7D7A712B24E257F4A016A89@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <559D66BF.20508@nomountain.net> <20150709170758.GA26599@mycre.ws> Message-ID: <20150709184259.GA18292@mycre.ws> Robert Edmonds wrote: > Looking at the version-related stuff in http://www.vpnc.org/getdns-api/, > I'm a bit confused. The 'version_string' field in the dict returned by > getdns_context_get_api_information() is defined as: > > version_string (a bindata) represents the version string for this > version of the DNS API. Hi, I wrote a C program to retrieve the version_string bindata from a getdns context object, and then I ported it to Python (see attached). I was expecting these programs to print equivalent output, since the "bindata" type holds arbitrary binary data: bindata is a struct to hold binary data. It is defined as { size_t size; uint8_t *binary_stuff; }. However, I got different output from the C and Python versions: $ ./getdns_version version_string = (6 bytes) '0.2.0\x00' $ ./getdns_version.py version_string = (5 bytes) '0.2.0' $ It looks like the getdns library intentionally appends a NUL byte to the bindata value when it converts a string: https://github.com/getdnsapi/getdns/blob/v0.2.0/src/util-internal.c#L86 Note the "strlen(value) + 1", which is one more byte than the length of the string (excluding the terminating NUL byte). So the bindata includes a NUL byte at the end. And it looks like Python getdns library binding then assumes this bindata value is NUL-terminated and truncates the sequence at the first NUL byte: https://github.com/getdnsapi/getdns-python-bindings/blob/v0.3.1/context.c#L630 Note the use of PyString_FromString rather than PyString_FromStringAndSize. I think this is backwards: if you have a byte sequence and an explicit length, this allows for embedded NUL bytes, and you should use the explicit length rather than assuming the byte sequence is a C-style string and truncating it at the first NUL byte (or, worse, performing an out-of-bounds read if it turned out this assumption was incorrect and the sequence didn't contain a NUL byte). So, I would recommend that the getdns C library should set the bindata 'size' field to strlen(value) rather than strlen(value)+1 when it converts a C string to a getdns bindata, and the getdns Python C library should use PyString_FromStringAndSize, with the len argument to that function set to the bindata 'size' field. (I couldn't find anything one way or the other in the getdns API spec that describes how strings should be packed into bindata's, though.) This is slightly inconvenient for C code (you can't pretend the uint8_t* is a char* and just print it), but most languages for which you would want to write bindings for the C library don't use C-style strings and would need to explicitly account for how to handle a trailing NUL byte, if any. Sometimes confusion as to how a string is encoded (explicit length vs NUL-termination) results in security vulnerabilities, e.g. see "Null Prefix Attacks Against SSL/TLS Certificates" for an infamous example: http://www.thoughtcrime.org/papers/null-prefix-attacks.pdf -- Robert Edmonds edmonds at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: getdns_version.c Type: text/x-csrc Size: 1119 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: getdns_version.py Type: text/x-python Size: 283 bytes Desc: not available URL: From melinda.shore at nomountain.net Thu Jul 9 19:05:07 2015 From: melinda.shore at nomountain.net (Melinda Shore) Date: Thu, 09 Jul 2015 11:05:07 -0800 Subject: [getdns-users] bindata string encoding? In-Reply-To: <20150709184259.GA18292@mycre.ws> References: <1436377901-6300-1-git-send-email-dkg@fifthhorseman.net> <831693C2CDA2E849A7D7A712B24E257F4A016A89@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <559D66BF.20508@nomountain.net> <20150709170758.GA26599@mycre.ws> <20150709184259.GA18292@mycre.ws> Message-ID: <559EC5E3.4080707@nomountain.net> On 7/9/15 10:42 AM, Robert Edmonds wrote: > I think this is backwards: if you have a byte sequence and an explicit > length, this allows for embedded NUL bytes, and you should use the > explicit length rather than assuming the byte sequence is a C-style > string and truncating it at the first NUL byte (or, worse, performing an > out-of-bounds read if it turned out this assumption was incorrect and > the sequence didn't contain a NUL byte). I'm kind of "meh" on that - I'm not sure that it's reasonable to assume the possible presence of a 0 byte in the middle of something that's agreed to be a C-format string. There are definitely places we're punting the bounds-checking to the Python libraries and that may not be reasonable. Melinda -- Melinda Shore No Mountain Software melinda.shore at nomountain.net "Software longa, hardware brevis." From dkg at fifthhorseman.net Thu Jul 9 19:50:34 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 09 Jul 2015 15:50:34 -0400 Subject: [getdns-users] git rm spec/getdns-0.601.tgz ? In-Reply-To: <559E28B1.5070304@nlnetlabs.nl> References: <877fqae0ey.fsf@alice.fifthhorseman.net> <559E28B1.5070304@nlnetlabs.nl> Message-ID: <87615tcdpx.fsf@alice.fifthhorseman.net> Hi Willem-- On Thu 2015-07-09 03:54:25 -0400, Willem Toorop wrote: > The API spec was there before the implementation. It has it's own > repository which is not public (it is at vpnc.org). It contains a > script which creates the index.html specification from a templates (and > the examples C code) and it also produces the tarball which is > referenced from the index.html spec. > > Although we've also taken over the editor's pen, I still commit > modifications to the spec on the repository at vpnc.org and use the > script therein to generate it. Hm, shipping the data from the spec as a tarball makes it much more complicated to see the differences between specs as they evolve. and the files themselves are not very big; with git, it would probably be more space-efficient (and easier reading) to store the expanded directory, rather than the tarball itself. If we want to include a script to reproduce the tarball so that spec/index.html can reference the right thing, that'd be quick and simple to write. shall i write it? > The examples from the spec within the tarball are extracted though, > because I've created some support files around it (Makefile.in and a > different getdns_core_only.h and getdns_libevent.h) to enable compiling > the examples with the library. What does it mean for the library to ship different .h files than the api's canonical .h files? this seems like an odd thing to do when trying to target a specific API, but maybe i'm not understanding the rationale here. Can you explain? I suppose I'm a bit confused about the api as a distinct project from the implemenation, tbh. --dkg From edmonds at debian.org Thu Jul 9 20:15:32 2015 From: edmonds at debian.org (Robert Edmonds) Date: Thu, 9 Jul 2015 16:15:32 -0400 Subject: [getdns-users] bindata string encoding? In-Reply-To: <559EC5E3.4080707@nomountain.net> References: <1436377901-6300-1-git-send-email-dkg@fifthhorseman.net> <831693C2CDA2E849A7D7A712B24E257F4A016A89@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <559D66BF.20508@nomountain.net> <20150709170758.GA26599@mycre.ws> <20150709184259.GA18292@mycre.ws> <559EC5E3.4080707@nomountain.net> Message-ID: <20150709201532.GA21955@mycre.ws> Melinda Shore wrote: > On 7/9/15 10:42 AM, Robert Edmonds wrote: > > I think this is backwards: if you have a byte sequence and an explicit > > length, this allows for embedded NUL bytes, and you should use the > > explicit length rather than assuming the byte sequence is a C-style > > string and truncating it at the first NUL byte (or, worse, performing an > > out-of-bounds read if it turned out this assumption was incorrect and > > the sequence didn't contain a NUL byte). > > I'm kind of "meh" on that - I'm not sure that it's reasonable to > assume the possible presence of a 0 byte in the middle of something > that's agreed to be a C-format string. Hi, Melinda: I agree, if a field is defined to be a C-style NUL-terminated string, then by definition it ends at the first \0 byte and the string cannot contain embedded NULs. But the version of the spec I'm looking at (https://getdnsapi.net/spec.html) only says that the 'version_string' bindata field represents a "string", without specifying how the string is encoded. My confusion comes about because the string is passed through an interface (the getdns_bindata type) that also passes an explicit length. > There are definitely places we're punting the bounds-checking to the > Python libraries and that may not be reasonable. Yeah, AFAICT, the Python binding is just passing the bindata 'data' field to PyString_FromString(), which then calls strlen() on it. So there's no bounds-checking at all, it's relying on the 'data' field to be NUL-terminated. That's why I recommend explicitly relying on the bounds information that the bindata type provides :-) -- Robert Edmonds edmonds at debian.org From willem at nlnetlabs.nl Thu Jul 9 20:44:34 2015 From: willem at nlnetlabs.nl (Willem Toorop) Date: Thu, 09 Jul 2015 22:44:34 +0200 Subject: [getdns-users] git rm spec/getdns-0.601.tgz ? In-Reply-To: <87615tcdpx.fsf@alice.fifthhorseman.net> References: <877fqae0ey.fsf@alice.fifthhorseman.net> <559E28B1.5070304@nlnetlabs.nl> <87615tcdpx.fsf@alice.fifthhorseman.net> Message-ID: <559EDD32.90001@nlnetlabs.nl> Op 09-07-15 om 21:50 schreef Daniel Kahn Gillmor: > Hi Willem-- > > On Thu 2015-07-09 03:54:25 -0400, Willem Toorop wrote: > >> The API spec was there before the implementation. It has it's own >> repository which is not public (it is at vpnc.org). It contains a >> script which creates the index.html specification from a templates (and >> the examples C code) and it also produces the tarball which is >> referenced from the index.html spec. >> >> Although we've also taken over the editor's pen, I still commit >> modifications to the spec on the repository at vpnc.org and use the >> script therein to generate it. > > Hm, shipping the data from the spec as a tarball makes it much more > complicated to see the differences between specs as they evolve. and > the files themselves are not very big; with git, it would probably be > more space-efficient (and easier reading) to store the expanded > directory, rather than the tarball itself. > > If we want to include a script to reproduce the tarball so that > spec/index.html can reference the right thing, that'd be quick and > simple to write. shall i write it? That doesn't feel quite right. I will ask Paul Hoffman if we can make the repository public up from the revision where I started editing it. >> The examples from the spec within the tarball are extracted though, >> because I've created some support files around it (Makefile.in and a >> different getdns_core_only.h and getdns_libevent.h) to enable compiling >> the examples with the library. > > What does it mean for the library to ship different .h files than the > api's canonical .h files? this seems like an odd thing to do when > trying to target a specific API, but maybe i'm not understanding the > rationale here. Can you explain? Well you can have a look for yourself by opening up the tarball. Those header files assume the API's repositories build environment. The alternative Makefile.in and header files make the examples linkable with libtool against our implementation in its build environment. > I suppose I'm a bit confused about > the api as a distinct project from the implemenation, tbh. The API was quite a community effort. When it was most active, I was not yet there. I wanted to point out the getdns-api mailing-list archive to you, but I cannot access it at vpnc.org any more. I will ask Paul Hoffman about that. > > --dkg > From melinda.shore at nomountain.net Thu Jul 9 21:45:15 2015 From: melinda.shore at nomountain.net (Melinda Shore) Date: Thu, 09 Jul 2015 13:45:15 -0800 Subject: [getdns-users] bindata string encoding? In-Reply-To: <20150709201532.GA21955@mycre.ws> References: <1436377901-6300-1-git-send-email-dkg@fifthhorseman.net> <831693C2CDA2E849A7D7A712B24E257F4A016A89@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <559D66BF.20508@nomountain.net> <20150709170758.GA26599@mycre.ws> <20150709184259.GA18292@mycre.ws> <559EC5E3.4080707@nomountain.net> <20150709201532.GA21955@mycre.ws> Message-ID: <559EEB6B.9070107@nomountain.net> On 7/9/15 12:15 PM, Robert Edmonds wrote: > My confusion comes about because the string is passed > through an interface (the getdns_bindata type) that also passes an > explicit length. Right, and I was working from something of a (dis)advantage, which was knowledge of how getdns was passing data around. I'm still ambivalent about the lack of a string type, given their ubiquity, and that strings and binary blobs are encoded as the same type while 32-bit integers have their own type. But, you get what you get and fortunately we're able to mask that to a large extent inside the Python bindings. But you're right about the use of the length field for validating bounds, and I'll open a ticket on that. Melinda -- Melinda Shore No Mountain Software melinda.shore at nomountain.net "Software longa, hardware brevis." From willem at nlnetlabs.nl Fri Jul 10 10:04:25 2015 From: willem at nlnetlabs.nl (Willem Toorop) Date: Fri, 10 Jul 2015 12:04:25 +0200 Subject: [getdns-users] getdns 0.3.0 release candidate Message-ID: <559F98A9.30007@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear All, I am pleased to announce the special IETF93 edition release candidate for version 0.3.0 of our getdns API implementation. Besides bugfixes and DNS parameter updates, this release follows the (yes to be published, but within the tarball) updated version of the API, which has a new function to set a list of transports: getdns_context_set_dns_transport_list(). If only one transport value is specified, it will be the only transport used. Should it not be available, basic resolution will fail. Fallback transport options are specified by including multiple values in the list. The values are GETDNS_TRANSPORT_UDP, GETDNS_TRANSPORT_TCP, GETDNS_TRANSPORT_TLS, or GETDNS_TRANSPORT_STARTTLS. The default is a list containing GETDNS_TRANSPORT_UDP then GETDNS_TRANSPORT_TCP. Also, for transport options TCP, TLS and STARTTLS, the connection will now always be tried to be kept open and multiple queries will be pipelined over it. When there are no pending queries, the connection is not closed for a period of time that can be specified with the new API function: getdns_context_set_idle_timeout(). Besides these new transport options, the release has improved DNSSEC support. Before, when using stub resolution mode, libunbound was still used (in forwarding mode) when one of the DNSSEC extensions was set. This release has native stub DNSSEC validation on board, so all DNSSEC extensions can now be combined with all the other hob-by-hob communication features available with stub resolution mode, such as the new transport options, cookies and fine grained control over EDNS0 options. To realise native stub validation, both the dnssec_return_validation_chain extension and the getdns_validate_dnssec() function have been thoroughly improved. Before the dnssec_return_validation_chain extension only returned the chain of DS/DNSKEY's starting at the signers name of the signatures in the answer and authority section of the request. Now, the extension will also return the support records needed to asses the DNSSEC status of replies without signatures, and even for replies without any RR's at all. Note that even an empty packet may be BOGUS or INSECURE depending on the proof of non-existence of the DS of the zone for the request of one of its parents. Also, the dnssec_return_validation_chain extension will try to return a single RRSIG RR per RRset. The one that it has used itself to asses the DNSSEC status of the RRset. This to alleviate the eventual validation effort that will be done with the chain. Note that the improved behaviour can be viewed live on the "Do a query" page of our website: https://getdnsapi.net/query.html Complementary to this improvement, the getdns_validate_dnssec() function can now also asses DNSSEC status for RRsets without signatures and even empty replies when given such "validation_chain" as the support_records. As the record_to_validate parameter, complete replies may now be given. It will deal with everything needed to correctly asses DNSSEC status for a reply, such as (but not limited to) NSEC3 opt-out evaluation and handling of by DNAME synthesized CNAMEs. Note that this is a release candidate. It is distributed for you to review before we do an actual release. Please review this candidate carefully. If no issues arise the actual 0.3.0 release will follow over one week on the seventeenth of July 2015. link : https://getdnsapi.net/dist/getdns-0.3.0rc1.tar.gz md5 : 27a1100d5d5d70c087b79109d1109ef3 sha1 : d79db12590109c826f627417da1b480f67c3839c pgp sig: https://getdnsapi.net/dist/getdns-0.3.0rc1.tar.gz.asc ChangeLog ========= * 2015-07-??: Version 0.3.0 * Unit test for spurious execute bits. Thanks Paul Wouters. * Added new transport list options in API. The option is now an ordered list of GETDNS_TRANSPORT_UDP, GETDNS_TRANSPORT_TCP, GETDNS_TRANSPORT_TLS, GETDNS_TRANSPORT_STARTTLS. * Added new context setting for idle_timeout * CSYNC RR type * EDNS0 COOKIE option code set to 10 * dnssec_return_validation_chain for negative and insecure responses. * dnssec_return_validation_chain return a single RRSIG on each RRSET (whenever possible) * getdns_validate_dnssec() accept replies from the replies_tree * getdns_validate_dnssec() asses negative and insecure responses. * Native stub dnssec validation * Implemented getdns_context_set_dnssec_trust_anchors() * Switch freely between stub and recursive mode * getdns_query -k shows default trust anchors * functions and defines to get library and API versions in string and numeric values: getdns_get_version(), getdns_get_version_number(), getdns_get_api_version() and getdns_get_api_version_number() -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJVn5ilAAoJEOX4+CEvd6SYougQAJ877hgMv5BRHz0ql+e7P2mp Ax7cu0skCTs45//0toFjb8J8PBVNbO5Pg1TGuYDBSFvdddR66H/YogsbEMuvWlfd 9sV582X1J7Qpmzb91IrY7AqC6O6IXXjBt2EHUaFk6Q/gIB0RiFhAJB21GeM3QVGd tp3Z1DyilVyJsonaB/eZz2PZPju/FJ7J5p4Of74BHBmrpQV2Rctllm1FWai0xM1L ptIAtUXeIKdwAoHapth057GHzInuj4G7Yt5nuUVA5g0Qz5U7G9MCct8BoNgO2LkN x64mmv34yrmv3K3RJDX4vFFo5IhcKL62dL+XZoCtm6dwwmy5CHeM3VhR0cwH/xhP JwlOXlI4xcoVEvf56tN3poEBbkoKbeX1ULi9JUa0Pa67eDr98IaTulV10mCGov35 WsCAFB4gmVgb2VvO40y038MApn1DBxlow/hbD8PM15wQjnWw8rueEidP98Jh/FBn CKHRgxd/B5gtk+uUGysyMf0dHnI+azzTdOGiCQTOx1iBggjAdiWVpZtLvI02C1sl ZHM6JUOmcRyxbg57PWJJvXpTuNdXMbh5yX8TtBA2feKw/TO+HpYantj1xJyK9u8B 5/sYb8bGrPY5w5x3Sl0Mpsmt0CNpc0Y6i662gmMS51gyQDZ0vJlonq2TgpWOA1RH f3vkq2txKIOEJm2JF1od =QW3b -----END PGP SIGNATURE----- From shollenbeck at verisign.com Fri Jul 10 15:59:13 2015 From: shollenbeck at verisign.com (Hollenbeck, Scott) Date: Fri, 10 Jul 2015 15:59:13 +0000 Subject: [getdns-users] getdns 0.3.0 release candidate In-Reply-To: <559F98A9.30007@nlnetlabs.nl> References: <559F98A9.30007@nlnetlabs.nl> Message-ID: <831693C2CDA2E849A7D7A712B24E257F4A018B8E@BRN1WNEXMBX01.vcorp.ad.vrsn.com> I just discovered a small issue with some debug print information being emitted from context.c. Here's a patch: diff --git src/context.c src/context.c index f7b87f8..817cc3f 100644 --- src/context.c +++ src/context.c @@ -2067,7 +2067,6 @@ priv_getdns_ns_dns_setup(struct getdns_context *context) (void) gldns_wire2str_rr_buf(rr->pos, rr->nxt - rr->pos, ta_str, sizeof(ta_str)); - fprintf(stderr, "TA: %s\n", ta_str); (void) ub_ctx_add_ta( context->unbound_ctx, ta_str); } I hope to have these new features in the development branch for the PHP bindings before next weekend. Scott From dkg at fifthhorseman.net Fri Jul 10 16:31:20 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 10 Jul 2015 12:31:20 -0400 Subject: [getdns-users] bindata string encoding? In-Reply-To: <20150709201532.GA21955@mycre.ws> References: <1436377901-6300-1-git-send-email-dkg@fifthhorseman.net> <831693C2CDA2E849A7D7A712B24E257F4A016A89@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <559D66BF.20508@nomountain.net> <20150709170758.GA26599@mycre.ws> <20150709184259.GA18292@mycre.ws> <559EC5E3.4080707@nomountain.net> <20150709201532.GA21955@mycre.ws> Message-ID: <87y4io9dpj.fsf@alice.fifthhorseman.net> On Thu 2015-07-09 16:15:32 -0400, Robert Edmonds wrote: > I agree, if a field is defined to be a C-style NUL-terminated string, > then by definition it ends at the first \0 byte and the string cannot > contain embedded NULs. But the version of the spec I'm looking at > (https://getdnsapi.net/spec.html) only says that the 'version_string' > bindata field represents a "string", without specifying how the string > is encoded. My confusion comes about because the string is passed > through an interface (the getdns_bindata type) that also passes an > explicit length. I think i agree with Robert here; the spec allows and makes use of null-terminated strings specifically in the presentation formats for DNS labels, but every bindata instance is a length-prefixed string, not a C string. >> There are definitely places we're punting the bounds-checking to the >> Python libraries and that may not be reasonable. > > Yeah, AFAICT, the Python binding is just passing the bindata 'data' > field to PyString_FromString(), which then calls strlen() on it. So > there's no bounds-checking at all, it's relying on the 'data' field to > be NUL-terminated. That's why I recommend explicitly relying on the > bounds information that the bindata type provides :-) I think the right fix is for the python bindings to treat the string as a proper bindata, but i also think that the bindata string returned from the C library in getdns_get_api_info's version_string probably shouldn't have the embedded NUL in it. Fixing the python bindings before fixing the C library is probably the safest way to go, though. --dkg From edmonds at debian.org Fri Jul 10 17:09:04 2015 From: edmonds at debian.org (Robert Edmonds) Date: Fri, 10 Jul 2015 13:09:04 -0400 Subject: [getdns-users] bindata string encoding? In-Reply-To: <87y4io9dpj.fsf@alice.fifthhorseman.net> References: <1436377901-6300-1-git-send-email-dkg@fifthhorseman.net> <831693C2CDA2E849A7D7A712B24E257F4A016A89@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <559D66BF.20508@nomountain.net> <20150709170758.GA26599@mycre.ws> <20150709184259.GA18292@mycre.ws> <559EC5E3.4080707@nomountain.net> <20150709201532.GA21955@mycre.ws> <87y4io9dpj.fsf@alice.fifthhorseman.net> Message-ID: <20150710170904.GA22267@mycre.ws> Daniel Kahn Gillmor wrote: > I think the right fix is for the python bindings to treat the string as > a proper bindata, but i also think that the bindata string returned from > the C library in getdns_get_api_info's version_string probably shouldn't > have the embedded NUL in it. Fixing the python bindings before fixing > the C library is probably the safest way to go, though. Maybe something like the attached? Related: porting this code to Python 3 brings up a choice between treating these fields as the Python 3 'str' type, or the Python 3 'bytes' type. 'str' is a little bit easier to work with if dealing with textual data (IMO), but it requires selecting an explicit character encoding. If you're going to explicitly allow these fields to contain C-style string termination, there's not much harm in also explicitly defining that they must be encoded with a specific character encoding, say UTF-8 or 7-bit US-ASCII. That would make language bindings authors happier :-) -- Robert Edmonds edmonds at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Check-bounds-on-version_string-and-implementation_st.patch Type: text/x-diff Size: 1673 bytes Desc: not available URL: From dkg at fifthhorseman.net Fri Jul 10 18:02:19 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 10 Jul 2015 14:02:19 -0400 Subject: [getdns-users] bindata string encoding? In-Reply-To: <20150710170904.GA22267@mycre.ws> References: <1436377901-6300-1-git-send-email-dkg@fifthhorseman.net> <831693C2CDA2E849A7D7A712B24E257F4A016A89@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <559D66BF.20508@nomountain.net> <20150709170758.GA26599@mycre.ws> <20150709184259.GA18292@mycre.ws> <559EC5E3.4080707@nomountain.net> <20150709201532.GA21955@mycre.ws> <87y4io9dpj.fsf@alice.fifthhorseman.net> <20150710170904.GA22267@mycre.ws> Message-ID: <87pp3zao2c.fsf@alice.fifthhorseman.net> On Fri 2015-07-10 13:09:04 -0400, Robert Edmonds wrote: > Related: porting this code to Python 3 brings up a choice between > treating these fields as the Python 3 'str' type, or the Python 3 > 'bytes' type. 'str' is a little bit easier to work with if dealing with > textual data (IMO), but it requires selecting an explicit character > encoding. If you're going to explicitly allow these fields to contain > C-style string termination, there's not much harm in also explicitly > defining that they must be encoded with a specific character encoding, > say UTF-8 or 7-bit US-ASCII. That would make language bindings authors > happier :-) Python3's distinction between string data and raw bytes is really useful. for things like dns labels (and maybe all dictionary labels?) maybe we can make an explicit statement that they must be UTF-8-encoded text (which is a superset of 7-bit US-ASCII). But for response data from the DNS in general, i don't think we're able to make such a categorical assumption, so i think it'll need to be converted to raw bytes objects. It would be nice if the getdns API itself were to distinguish between these types, but i think it's generic enough to not want to do that. --dkg From edmonds at debian.org Fri Jul 10 18:07:59 2015 From: edmonds at debian.org (Robert Edmonds) Date: Fri, 10 Jul 2015 14:07:59 -0400 Subject: [getdns-users] bindata string encoding? In-Reply-To: <87pp3zao2c.fsf@alice.fifthhorseman.net> References: <1436377901-6300-1-git-send-email-dkg@fifthhorseman.net> <831693C2CDA2E849A7D7A712B24E257F4A016A89@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <559D66BF.20508@nomountain.net> <20150709170758.GA26599@mycre.ws> <20150709184259.GA18292@mycre.ws> <559EC5E3.4080707@nomountain.net> <20150709201532.GA21955@mycre.ws> <87y4io9dpj.fsf@alice.fifthhorseman.net> <20150710170904.GA22267@mycre.ws> <87pp3zao2c.fsf@alice.fifthhorseman.net> Message-ID: <20150710180759.GA26555@mycre.ws> Daniel Kahn Gillmor wrote: > But for response data from the DNS in general, i don't think we're > able to make such a categorical assumption, so i think it'll need to > be converted to raw bytes objects. Definitely, I was only talking about the cases where strings generated by the library are aliased by the getdns_bindata type. -- Robert Edmonds edmonds at debian.org From dkg at fifthhorseman.net Mon Jul 13 04:46:52 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 13 Jul 2015 00:46:52 -0400 Subject: [getdns-users] getdns 0.3.0 release candidate In-Reply-To: <559F98A9.30007@nlnetlabs.nl> References: <559F98A9.30007@nlnetlabs.nl> Message-ID: <87si8s7jgj.fsf@alice.fifthhorseman.net> On Fri 2015-07-10 06:04:25 -0400, Willem Toorop wrote: > I am pleased to announce the special IETF93 edition release candidate > for version 0.3.0 of our getdns API implementation. This release candidate is now in the debian experimental repository. Users of debian testing or debian unstable should be able to install it directly: https://packages.qa.debian.org/g/getdns/news/20150713T041858Z.html I've introduced the patch attached below to make the "date" part of the man pages refer to the API version string. This provides appropriate versioning, and avoids a source of non-determinism in manpage generation (building the same source package next month will put "August 2015" into the manpages, despite the fact that they have not been updated or targeted to a new version of the API. (date's +%B output is also locale-dependent, introducing another source of non-determinism) If you want to adopt this patch upstream, i'd be happy. If you think it's not appropriate for some reason, i'm happy to discuss other approaches to deterministic manpage generation. looking forward to the full 0.3.0 release! Happy hacking, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-report-manpage-date-based-on-the-name-of-the-API.patch Type: text/x-diff Size: 1138 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From willem at nlnetlabs.nl Mon Jul 13 12:33:32 2015 From: willem at nlnetlabs.nl (Willem Toorop) Date: Mon, 13 Jul 2015 14:33:32 +0200 Subject: [getdns-users] getdns 0.3.0 release candidate In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F4A018B8E@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <559F98A9.30007@nlnetlabs.nl> <831693C2CDA2E849A7D7A712B24E257F4A018B8E@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Message-ID: <55A3B01C.3020805@nlnetlabs.nl> Thank you Scott, I had fixed this already, but strangely enough it only got committed on the v0.3.0rc1 tag and not to the v0.3.0 branch even though the tag is on the branch! Very mysterious... https://github.com/getdnsapi/getdns/commit/431415bd Thanks for updating the PHP bindings! -- Willem Op 10-07-15 om 17:59 schreef Hollenbeck, Scott: > I just discovered a small issue with some debug print information being emitted from context.c. Here's a patch: > > diff --git src/context.c src/context.c > index f7b87f8..817cc3f 100644 > --- src/context.c > +++ src/context.c > @@ -2067,7 +2067,6 @@ priv_getdns_ns_dns_setup(struct getdns_context *context) > > (void) gldns_wire2str_rr_buf(rr->pos, > rr->nxt - rr->pos, ta_str, sizeof(ta_str)); > - fprintf(stderr, "TA: %s\n", ta_str); > (void) ub_ctx_add_ta( > context->unbound_ctx, ta_str); > } > > I hope to have these new features in the development branch for the PHP bindings before next weekend. > > Scott > > _______________________________________________ > Users mailing list > Users at getdnsapi.net > http://getdnsapi.net/mailman/listinfo/users > From willem at nlnetlabs.nl Mon Jul 13 13:26:53 2015 From: willem at nlnetlabs.nl (Willem Toorop) Date: Mon, 13 Jul 2015 15:26:53 +0200 Subject: [getdns-users] bindata string encoding? In-Reply-To: <87y4io9dpj.fsf@alice.fifthhorseman.net> References: <1436377901-6300-1-git-send-email-dkg@fifthhorseman.net> <831693C2CDA2E849A7D7A712B24E257F4A016A89@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <559D66BF.20508@nomountain.net> <20150709170758.GA26599@mycre.ws> <20150709184259.GA18292@mycre.ws> <559EC5E3.4080707@nomountain.net> <20150709201532.GA21955@mycre.ws> <87y4io9dpj.fsf@alice.fifthhorseman.net> Message-ID: <55A3BC9D.5080202@nlnetlabs.nl> Op 10-07-15 om 18:31 schreef Daniel Kahn Gillmor: > I think the right fix is for the python bindings to treat the string as > a proper bindata, but i also think that the bindata string returned from > the C library in getdns_get_api_info's version_string probably shouldn't > have the embedded NUL in it. Fixing the python bindings before fixing > the C library is probably the safest way to go, though. I guess it is safe to fix the C library too (but secretly make sure a '\0' byte is still underneath; don't tell!). In fact, there are very few places where strings are returned in bindata's. There is the (superfluous) "address_type" key, in dicts representing IP addresses; the "version_string" and "implementation_string" from getdns_context_get_api_information() and the bindata's in the list returned from getdns_dict_get_names(). Personally I also prefer not including the trailing '\0' byte. Has anyone objections if I change the behaviour? (we'd still have our secret safety net... shhht) -- Willem From shollenbeck at verisign.com Mon Jul 13 14:52:59 2015 From: shollenbeck at verisign.com (Hollenbeck, Scott) Date: Mon, 13 Jul 2015 14:52:59 +0000 Subject: [getdns-users] PHP Language Bindings v0.8.0 Message-ID: <831693C2CDA2E849A7D7A712B24E257F4A01A4CA@BRN1WNEXMBX01.vcorp.ad.vrsn.com> I just pushed v0.8.0 of the PHP language bindings to the development branch on github. This version was built for compatibility with version v0.3.0rc1 of the getdns library. All unit tests pass without error. The master branch contains version v0.7.2. This version should be compatible with getdns library version v0.1.8. Scott From willem at nlnetlabs.nl Fri Jul 17 17:02:33 2015 From: willem at nlnetlabs.nl (Willem Toorop) Date: Fri, 17 Jul 2015 19:02:33 +0200 Subject: [getdns-users] getdns 0.3.0 released Message-ID: <55A93529.4060203@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear All, I am pleased to announce the special IETF93 edition release: version 0.3.0 of our getdns API implementation. Besides bugfixes and DNS parameter updates, this release follows the July 2015 version of the API specification, which has a new function to set a list of transports: getdns_context_set_dns_transport_list(). If only one transport value is specified, it will be the only transport used. Should it not be available, basic resolution will fail. Fallback transport options are specified by including multiple values in the list. The values are GETDNS_TRANSPORT_UDP, GETDNS_TRANSPORT_TCP, GETDNS_TRANSPORT_TLS, or GETDNS_TRANSPORT_STARTTLS. The default is a list containing GETDNS_TRANSPORT_UDP then GETDNS_TRANSPORT_TCP. Connections for transport options TCP, TLS and STARTTLS will now always be kept open and multiple queries will be pipelined over them. We have a new API function, getdns_context_set_idle_timeout(), with which you can specify how long a connection is kept open when there are no pending queries. The default is 0 milliseconds. Besides the transports list, this release has improved DNSSEC support. Before, with stub resolution, libunbound was still used (in forwarding mode) when one of the DNSSEC extensions was set. This release has native stub DNSSEC validation on board, so all DNSSEC extensions can now be combined with all features available with stub resolution mode, such as the new transport options, cookies and fine grained control over EDNS0 options. In the process to realise native stub validation, both the dnssec_return_validation_chain extension and the getdns_validate_dnssec() function have been thoroughly improved. Before the dnssec_return_validation_chain extension only returned the chain of DS/DNSKEY's starting at the signers name of signatures. Now, the extension will return support records needed to assess all DNSSEC statuses. For example, it will also include the proof of non-existance of a parent DS for INSECURE answers. But also for BOGUS answers, just like with all DNSSEC statuses, everything needed to reassess that DNSSEC status will be included. The dnssec_return_validation_chain extension will now also try to return a single RRSIG RR per RRset; The one that was used to validate that RRset. This to maximally assist in reassessing the DNSSEC status with the "validation_chain" as support records. The latest improved behaviour can be viewed live on the "Do a query" page of our website: https://getdnsapi.net/query.html Complementary to this improvement, the getdns_validate_dnssec() function can now also assess DNSSEC status for RRsets without signatures and even empty replies when given such "validation_chain" as the support_records. The function can now also validate complete replies, taking into account everything that affects the validation process, such as (but not limited to) NSEC3 opt-out evaluation and handling of by DNAME synthesized CNAMEs. link : https://getdnsapi.net/dist/getdns-0.3.0.tar.gz md5 : 8f1e6b3bf6489d7e49fd1d18366a5ece sha1 : 84e4a8c21ede346d8fcf3e73860679dd87c8e65f pgp sig: https://getdnsapi.net/dist/getdns-0.3.0.tar.gz.asc ChangeLog ========= * 2015-07-17: Version 0.3.0 * Unit test for spurious execute bits. Thanks Paul Wouters. * Added new transport list options in API. The option is now an ordered list of GETDNS_TRANSPORT_UDP, GETDNS_TRANSPORT_TCP, GETDNS_TRANSPORT_TLS, GETDNS_TRANSPORT_STARTTLS. * Added new context setting for idle_timeout * CSYNC RR type * EDNS0 COOKIE option code set to 10 * dnssec_return_validation_chain for negative and insecure responses. * dnssec_return_validation_chain return a single RRSIG on each RRSET (whenever possible) * getdns_validate_dnssec() accept replies from the replies_tree * getdns_validate_dnssec() asses negative and insecure responses. * Native stub dnssec validation * Implemented getdns_context_set_dnssec_trust_anchors() * Switch freely between stub and recursive mode * getdns_query -k shows default trust anchors * functions and defines to get library and API versions in string and numeric values: getdns_get_version(), getdns_get_version_number(), getdns_get_api_version() and getdns_get_api_version_number() -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJVqTUoAAoJEOX4+CEvd6SYVigP/2WVjz8lOnljeaJnlFbxh18Q qHMFgRwGaDtbKqhv4m3nWR7EbRAkY2yFybs2QEpHi+jFqTRILfQX+0EGbNb+J3S+ b/14bHilWie5gy1+YGrCu2Pbu+UGJyusStCcNjWVrqnVQDRNjVrI1L47sqek1v+e 9Jknl3evzRQtbSUw4aBAPC1XHZqccPCdDwFUk5m/cz7dekYzbik/sHcFDXEyMYLU zQSLBKKrTyyQU901EyuNcwz5nbspAXLAlyHy94ZjtXasb489clfHSkXa2Kpuo0o9 f2w1axcFvHmS5R+qh2nyXaRj0hQ7b5wegr6js7yupATMA0PewJVLZJzxtI7UEB2V jQTI+boPdtl7Oux7ctF0ZZ1u0BrPYixA8rt2X7eadm6+vQN5r3DR7ArIfxwAALJE XGqxST+TqQzOrWEMg2xGJ9Wp75FYqiSOYDyJmJqYXzolafB1NtbptGgS9Mjiqak7 PJy0yGx+wkvesNRuiXehIQY/JxELOHh+eXH1NsleGJQ2BpEBhGIVFsCtUA91mA+W BtJ9gPCtpyQC0sIRTGauIUrO9GjoFRghEMcc+T6hlpdvSTifRvxVnx4J2jqQKL8O QkA2kqijpkSeJL5yQro7Tdx4addCbXcyyEkHAccWUKOjlKDlllpy2fbYbFKACIl+ C6ZWqM4QxhKMnNZ1+3Z0 =VwWv -----END PGP SIGNATURE----- From willem at nlnetlabs.nl Fri Jul 17 17:21:50 2015 From: willem at nlnetlabs.nl (Willem Toorop) Date: Fri, 17 Jul 2015 19:21:50 +0200 Subject: [getdns-users] bindata string encoding? In-Reply-To: <55A3BC9D.5080202@nlnetlabs.nl> References: <1436377901-6300-1-git-send-email-dkg@fifthhorseman.net> <831693C2CDA2E849A7D7A712B24E257F4A016A89@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <559D66BF.20508@nomountain.net> <20150709170758.GA26599@mycre.ws> <20150709184259.GA18292@mycre.ws> <559EC5E3.4080707@nomountain.net> <20150709201532.GA21955@mycre.ws> <87y4io9dpj.fsf@alice.fifthhorseman.net> <55A3BC9D.5080202@nlnetlabs.nl> Message-ID: <55A939AE.6030506@nlnetlabs.nl> Although I do believe it is quite safe, I did not dare to put it in the release already. Next release candidate will have this patch... -- Willem Op 13-07-15 om 15:26 schreef Willem Toorop: > Op 10-07-15 om 18:31 schreef Daniel Kahn Gillmor: >> I think the right fix is for the python bindings to treat the string as >> a proper bindata, but i also think that the bindata string returned from >> the C library in getdns_get_api_info's version_string probably shouldn't >> have the embedded NUL in it. Fixing the python bindings before fixing >> the C library is probably the safest way to go, though. > > I guess it is safe to fix the C library too (but secretly make sure a > '\0' byte is still underneath; don't tell!). > > In fact, there are very few places where strings are returned in bindata's. > > There is the (superfluous) "address_type" key, in dicts representing IP > addresses; the "version_string" and "implementation_string" from > getdns_context_get_api_information() and the bindata's in the list > returned from getdns_dict_get_names(). > > Personally I also prefer not including the trailing '\0' byte. > > Has anyone objections if I change the behaviour? > (we'd still have our secret safety net... shhht) > > -- Willem > From dkg at fifthhorseman.net Fri Jul 17 23:52:47 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 18 Jul 2015 01:52:47 +0200 Subject: [getdns-users] getdns 0.3.0 released In-Reply-To: <55A93529.4060203@nlnetlabs.nl> References: <55A93529.4060203@nlnetlabs.nl> Message-ID: <87twt2pcj4.fsf@alice.fifthhorseman.net> On Fri 2015-07-17 19:02:33 +0200, Willem Toorop wrote: > I am pleased to announce the special IETF93 edition release: > version 0.3.0 of our getdns API implementation. I've just uploaded 0.3.0 to debian unstable, and it's working its way through the build daemons. Interested users on that platform should be able to install it after the next archive update (before the IETF Hackathon starts, hopefully). --dkg From shollenbeck at verisign.com Sat Jul 18 14:18:58 2015 From: shollenbeck at verisign.com (Hollenbeck, Scott) Date: Sat, 18 Jul 2015 14:18:58 +0000 Subject: [getdns-users] getdns 0.3.0 released In-Reply-To: <55A93529.4060203@nlnetlabs.nl> References: <55A93529.4060203@nlnetlabs.nl> Message-ID: <831693C2CDA2E849A7D7A712B24E257F4A01F7BF@BRN1WNEXMBX01.vcorp.ad.vrsn.com> > -----Original Message----- > From: Users [mailto:users-bounces at getdnsapi.net] On Behalf Of Willem > Toorop > Sent: Friday, July 17, 2015 1:03 PM > To: users at getdnsapi.net > Subject: [getdns-users] getdns 0.3.0 released > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Dear All, > > I am pleased to announce the special IETF93 edition release: > version 0.3.0 of our getdns API implementation. The master branch of the PHP language bindings has been updated to be consistent with this release. Scott From willem at nlnetlabs.nl Sat Jul 18 17:05:24 2015 From: willem at nlnetlabs.nl (Willem Toorop) Date: Sat, 18 Jul 2015 19:05:24 +0200 Subject: [getdns-users] getdns 0.3.1 emergency release Message-ID: <55AA8754.6010008@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear All, We have an emergency release, version 0.3.1 of getdns. This release fixes a single bug which will cause getdns to hang on querying RR types with repeating final rdata fields. The previous release contained a fix that would allow for empty rdata fields. This is the case with the "type bitmap" rdata field with NSEC3 RRs on empty non terminals. Parsing that properly is essential for sound DNSSEC validation. Unfortunately the fix introduced a new bug, which allowed repeating rdata fields to be empty too. Parsing such RR types would lead to an infinite list of empty rdata fields. This emergency release has this fixed. We apologize our current test suite did not catch this problem. We will address this by extending our test coverage for all supported RR types before next release. We urgently advise to update the previous version to v0.3.1 immediately. link : https://getdnsapi.net/dist/getdns-0.3.1.tar.gz md5 : ecfb1e3c2e5f3e018a5225d60ad6a6c3 sha1 : a5293963e1a3af224cdb7a65a04c0ac79799697e pgp sig: https://getdnsapi.net/dist/getdns-0.3.1.tar.gz.asc ChangeLog ========= * 2015-07.18: Version 0.3.1 * Fix repeating rdata fields -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJVqodUAAoJEOX4+CEvd6SYcNoP+wUJtP2+eHJscgJpm9jOXgLe m/SNoQKOhdLYRBEgYVnt2CBwk54563RScGrg25rSEFwLSmTiAuYGhrlV5bMmekZi oo+Ow/ORsut/2l4dybRxMWUAaLLRemYelnL4RyZ8x+1TEcFZT84ZmoYaAXnHRsOa Nuvn5XfYKbA/9qeorY+upOh1onZAO3vuRlHwkZ4r06S9Hte9JGfE3QSQSJ5un6mY sIUSSoGUOY6bWPKtIJVoR5dtsyuG0rn5+yWxfiX2x0iHJo+QR5G57josLCOJXVU8 HpqlMHLnglDPuEbWVwVR3TSUT3NVxqvX9KPkEAOokTkx8M5dmxg7DVOzthDi2Q0v VIIzfa0smrPtYEWP9ME8R9jtmt1kmgRciEtAQ/7VuXK8RF5CSkUEZBg88p9PWcm0 gaSDAgZW4eE0NaH91rp3eGB3AJCM1qkt9Y2Gt4Hpf2GViG1U4VchET5kot2jyaTM 8ah538KgwN/nNO187zMsKm27n8Z++l8gzUOSdfyS/x6ZzAVhJz8LCtpNgyxcizZ/ tBXGE4506NJSHv9Zz25dwr2uJmEwNHD8Hvpa40zRH42dw8l9DPcjRrJeTISKJ4QO wt1y3W7KsLl9tnVhhvf7gYs8ZZ5hFjf0Jx/xwwSXm4qDekwFUo/DfpCjyEbKqBdw RlnYirrbPmk7cF89w3xJ =iWA5 -----END PGP SIGNATURE----- From dkg at fifthhorseman.net Sun Jul 19 01:13:44 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sun, 19 Jul 2015 03:13:44 +0200 Subject: [getdns-users] getdns 0.3.1 emergency release In-Reply-To: <55AA8754.6010008@nlnetlabs.nl> References: <55AA8754.6010008@nlnetlabs.nl> Message-ID: <87615hne47.fsf@alice.fifthhorseman.net> On Sat 2015-07-18 19:05:24 +0200, Willem Toorop wrote: > We have an emergency release, version 0.3.1 of getdns. This release > fixes a single bug which will cause getdns to hang on querying RR > types with repeating final rdata fields. 0.3.1 is now in debian unstable. thanks for your work on this, Willem. Regards, --dkg From shollenbeck at verisign.com Sun Jul 19 10:02:39 2015 From: shollenbeck at verisign.com (Hollenbeck, Scott) Date: Sun, 19 Jul 2015 10:02:39 +0000 Subject: [getdns-users] getdns 0.3.1 emergency release In-Reply-To: <55AA8754.6010008@nlnetlabs.nl> References: <55AA8754.6010008@nlnetlabs.nl> Message-ID: <831693C2CDA2E849A7D7A712B24E257F4A02056D@BRN1WNEXMBX01.vcorp.ad.vrsn.com> > -----Original Message----- > From: Users [mailto:users-bounces at getdnsapi.net] On Behalf Of Willem > Toorop > Sent: Saturday, July 18, 2015 1:05 PM > To: users at getdnsapi.net > Subject: [getdns-users] getdns 0.3.1 emergency release > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Dear All, > > We have an emergency release, version 0.3.1 of getdns. This release > fixes a single bug which will cause getdns to hang on querying RR > types with repeating final rdata fields. Willem, I think I just found a small bug in 0.3.1. The getdns_extra.h header file includes these #define statements: #define GETDNS_VERSION "0.3.1" #define GETDNS_NUMERIC_VERSION 0x00030000 GETDNS_VERSION is fine, but shouldn't GETDNS_NUMERIC_VERSION be 0x00030100? Scott From willem at nlnetlabs.nl Sun Jul 19 11:13:21 2015 From: willem at nlnetlabs.nl (Willem Toorop) Date: Sun, 19 Jul 2015 13:13:21 +0200 Subject: [getdns-users] getdns 0.3.1 emergency release In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F4A02056D@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <55AA8754.6010008@nlnetlabs.nl> <831693C2CDA2E849A7D7A712B24E257F4A02056D@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Message-ID: <55AB8651.2030303@nlnetlabs.nl> It should! Thanks! Op 19-07-15 om 12:02 schreef Hollenbeck, Scott: >> -----Original Message----- >> From: Users [mailto:users-bounces at getdnsapi.net] On Behalf Of Willem >> Toorop >> Sent: Saturday, July 18, 2015 1:05 PM >> To: users at getdnsapi.net >> Subject: [getdns-users] getdns 0.3.1 emergency release >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Dear All, >> >> We have an emergency release, version 0.3.1 of getdns. This release >> fixes a single bug which will cause getdns to hang on querying RR >> types with repeating final rdata fields. > > Willem, I think I just found a small bug in 0.3.1. The getdns_extra.h header file includes these #define statements: > > #define GETDNS_VERSION "0.3.1" > #define GETDNS_NUMERIC_VERSION 0x00030000 > > GETDNS_VERSION is fine, but shouldn't GETDNS_NUMERIC_VERSION be 0x00030100? > > Scott > > _______________________________________________ > Users mailing list > Users at getdnsapi.net > http://getdnsapi.net/mailman/listinfo/users > From willem at nlnetlabs.nl Wed Jul 22 15:07:51 2015 From: willem at nlnetlabs.nl (Willem Toorop) Date: Wed, 22 Jul 2015 17:07:51 +0200 Subject: [spec] Negeer dit Message-ID: <55AFB1C7.6050302@nlnetlabs.nl> Dit is slechts een test voor een mailing-list migratie. Ik heb de dkim-testers list gebruikt om uit te proberen. Dus jullie zullen niet echt lid worden... Sorry voor de spam. -- Willem From willem at nlnetlabs.nl Thu Jul 23 12:02:35 2015 From: willem at nlnetlabs.nl (Willem Toorop) Date: Thu, 23 Jul 2015 14:02:35 +0200 Subject: [getdns-api] Getdns-api mailing-list moved to getdnsapi.net Message-ID: <55B0D7DB.9020604@nlnetlabs.nl> Hi all, Since November 2013, the getdnsapi.net team has taken over the getdns API specification editor's pen from Paul Hoffman. We have made (and make) sure that we manage changes the same way Paul did. We listen to the getdns-api mailing-list and when there is consensus on changes, we post the modified text on the list for review. This morning I sat down with Paul Hoffman at Chez Louis (the IETF93 Lounge) in Prague to finish this transfer and also migrate the getdns-api list from vpnc.org to getdnsapi.net. The API specification list is now called spec at getdnsapi.net. We have migrated the complete configuration, including all member subscriptions and the archive which can now be found here: https://getdnsapi.net/pipermail/spec/ . Messages to getdns-api at vpnc.org will be forwarded to spec at getdnsapi.net but you should mail to spec at getdnsapi.net now really as I do not know for how long Paul will keep the getdns-api at vpnc.org address around. I will test the forwarding myself with another announcement, because... ... for those who are at the IETF93, tonight there will be a Beer BoF in the Istanbul room from 20:00 till 24:00! Hope to see you there! Cheers, -- Willem From willem at nlnetlabs.nl Thu Jul 23 12:12:40 2015 From: willem at nlnetlabs.nl (Willem Toorop) Date: Thu, 23 Jul 2015 14:12:40 +0200 Subject: [getdns-api] Beer BoF at the IETF93 tonight from 20:00 till 24:00 Message-ID: <55B0DA38.1070109@nlnetlabs.nl> Hi All, Tonight Verisign Labs will give a beer BoF at room Istanbul at the IETF 93 in Prague. If you are here, please drop by! Cheers, -- Willem