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 The API's .h file contains a macro called The implementation of both the async and sync getdns_general_sync()
-
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.getdns
functions will
copy all the values of the parameters into local memory, in case the application changes or
deallocates them.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.
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