This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Fix p_secstodate overflow handling (bug 22463)


On 11/22/2017 12:00 AM, Paul Eggert wrote:
On 11/21/2017 02:38 PM, Joseph Myers wrote:
Where does it say that?

It's in RFC 4034 section 3.1.5, which says that the time values specify a "date and time in the form of a 32-bit unsigned number of seconds elapsed since 1 January 1970 00:00:00 UTC, ignoring leap seconds." Although section 3.2 says how these time values are represented, it does not give license to represent a date and time that is out of the 32-bit range. Section 3.1.5 goes on to say that the intent is to use serial number arithmetic a la RFC 1982, which boils down to using the low-order 32-bits of the full timestamp.

p_secstodate was added with an import from BIND in 1996:

Tue Aug 13 18:26:45 1996  Ulrich Drepper  <drepper@cygnus.com>
…
	(__dn_count_labels, __p_secstodate): New functions.

At this time, the DNSSEC RFCs did not require modulo interpretation of the signer field. It was truly restricted to 32 bits, as far as I can see:

  <https://tools.ietf.org/html/rfc2065>

I think we can change the function to always return NULL (or abort the process with an error message) and turn it into into a compat symbol. I very much doubt that there are any users at all because the function does not implement the current DNSSEC specification. (Anything DNSSEC-related still left in libresolv is equally useless because the protocol underwent several incompatible revisions.)

Thanks,
Florian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]