On Fri, Sep 28, 2007 at 04:47:34PM +0100, Ian Jackson wrote: > Since I did the backport for Ubuntu I'm probably the right person to > prepare the update for etch (not that it's very hard). For concreteness, thanks to Aurelien's original addition to gai.conf before this was brought to the ctte, the patch is as simple as: diff -urb glibc-2.6.1-5/debian/patches/any/submitted-rfc3484-sortv4.diff glibc-2.6.1/debian/patches/any/submitted-rfc3484-sortv4.diff --- glibc-2.6.1-5/debian/patches/any/submitted-rfc3484-sortv4.diff 2007-09-29 12:36:14.000000000 +1000 +++ glibc-2.6.1/debian/patches/any/submitted-rfc3484-sortv4.diff 2007-09-29 12:38:50.000000000 +1000 @@ -18,9 +18,9 @@ # used. There are possible runtime problems. The default is no. # +# sortv4 <yes|no> -+# If set to no, getaddrinfo(3) will ignore IPv4 adresses in rule 9. See -+# section 6 in RFC 3484. The default is yes. Setting this option to -+# no breaks conformance to RFC 3484. ++# If set to yes, getaddrinfo(3) will sort IPv4 adresses in rule 9. See ++# section 6 in RFC 3484. The default is no. Setting this option to ++# yes enables stricter conformance to RFC 3484. +# # label <mask> <value> # Add another rule to the RFC 3484 label table. See section 2.1 in @@ -36,7 +36,7 @@ +static int gaiconf_reload_flag; + +/* Zero if we are supposed to ignore rule 9 for IPv4 addresses */ -+static int gaiconf_sortv4_flag = 1; ++static int gaiconf_sortv4_flag = 0; + +/* Last modification time. */ +static struct timespec gaiconf_mtime; @@ -73,7 +73,7 @@ if (strcmp (cmd, "reload") == 0) gaiconf_reload_flag = strcmp (val1, "yes") == 0; + else if (strcmp (cmd, "sortv4") == 0) -+ gaiconf_sortv4_flag = strcmp (val1, "no") != 0; ++ gaiconf_sortv4_flag = strcmp (val1, "yes") == 0; break; case 10: I still can't see any reason why "the right person" to apply the patch is anyone other than the maintainer. > > If so, conclusions that could potentially be drawn: > > (a) Using prefix matching to select IPv4 addresses isn't useful > > (b) Using prefix matching to select IPv4 addresses is harmful > > (c) Using prefix matching to select IPv4 addresses is harmful enough to > > be an RC issue for Debian > > If so, declaring this to be an RC issue justifies both an update to > > etch and (if necessary, which I don't expect) an NMU for sid/lenny, > > which seems all that's needed. > I don't see why RCness is relevant for updating sid. > Surely the TC should ensure that its decisions are implemented even if > we consider the issue non-RC ? If it's not an RC issue -- thus qualifying for a stable update as well -- I don't see why it's important enough to overrule the maintainer for sid, rather than simply leaving it as is while we provide the IETF with comments on why the RFC's recommendations need changing. The TC should only make decisions as a last resort; if this isn't an RC issue, I just don't think we're at that point: we haven't contacted either upstream or the IETF for example, and living with non-RC bugs, including this one, isn't difficult. > > I'm not sure if any or all of (d)-(f) would be sufficient recommendations > > to close the issue for IPv6 as well, or if there's something else that > > would make sense. > I think we should avoid getting too bogged down with IPv6. We can > safely leave that to the IETF to reconsider since we're evidently not > going to overrule the libc maintainer on that point. If, as an implementor, the Debian technical committee has a problem with the IETF's proposed standard, it's our job to fully explain what the problem is and suggest ways of avoiding the problem. If we're going to shirk that task, I don't believe we should be overruling the maintainer or upstream on the issue of complying with the proposed standard. Cheers, aj
Attachment:
signature.asc
Description: Digital signature