On 5/23/2019 4:40 AM, Brian May wrote: > Brian May <b...@debian.org> writes: > >> This implies it should be possible for ap application to request 64 bit >> time_t, but not sure how. > > I see proposals to setting _TIME_BITS=64 from 2015, however I don't > actually see any reference to this being implemented yet. > > https://lwn.net/Articles/664800/
The proposed modification to glibc "Y2038ProofnessDesign" can be found here: https://sourceware.org/glibc/wiki/Y2038ProofnessDesign?rev=115 This proposal is not available in any glibc currently shipping. > I somewhat think this should have been the case for the certificates > supplied in Heimdal. Far better IMHO not to break existing and working > platforms at this stage, then to worry about 2038. Hopefully by the > time it is 2038, version 8 will have been released by then in any > case. I looked at trying to fix 2038 time handling yesterday and came to the conclusion it cannot be done in Heimdal without (a) support from glibc as described in the Y2038ProofnessDesign, or (b) Heimdal providing its own implementation of ctime(), gmtime(), strptime() and tm2time() including the databases for leap seconds, DST, etc for post-Y2038 timestamps. As the latter is unmanageable, the answer must be the former. Y2038 is a real issue for any software that manages x.509 certificates. There are many commercial CAs that are already shipping Root certificates with expiration times in 2040 and later. Heimdal also needs to be able to create and manipulate x.509 times and HDB times greater than Y2038. Doing so involves not only storing 64-bit times but converting 64-bit time between UTC and local timezones as well as between integers and human readable strings. Y2038 is a security issue today for any Linux distribution that continues to ship platforms restricted to 32-bit time_t. Anyone that deploys such a platform should expect access to web sites and the ability to authenticate using x.509 certificates to fail as certificate chains can no longer be verified. Platforms that are restricted to 32-bit time_t should not be used to host CAs or KDCs of which Heimdal is both. When it was noticed that Heimdal's test suite was failing because of expired certificates we intentionally generated certificates post Y2038 because testing Y2038 is critical to Heimdal today. For the Heimdal 7.7 release we will commit certificates that expire pre-Y2038. Heimdal does not intend to update the certificates on the master branch. Debian will preferably choose to ship 7.7 on its platforms and not cherry-pick the bits and pieces that it deems relevant. It is my hope that 7.7 will be released by early next week at the latest. In my opinion, the Debian community should have a long hard discussion about whether it can continue to ship platforms such as i386 if glibc cannot provide Y2038 compatibility for applications. Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
