Fix p_secstodate overflow handling (bug 22463)

[Florian Weimer]

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