O que alguém pode fazer contra os riscos de obsolescência em RFCs?

Question

o RFC 4880 , um documento que descreve a criptografia OpenPGP padrão, encontra suas raízes em RFC 2440 , publicado em 1998 (isto é, dezesseis anos atrás / em>, supostamente antes de sistemas de 64 bits surgiram). Ambas as especificações dizem a mesma coisa sobre como os timestamps são tratados:

.

3.5 . Campos de tempo

Um campo de tempo é um número não assinado de quatro octetos contendo o número de segundos decorridos desde a meia-noite, 1 de janeiro de 1970 UTC.

Se alguém tentar seguir RFCs o mais próximo possível (e, aqui, enfrentar um doce ano 2038 bug um dia)? É "arriscado" para um desenvolvedor não seguir partes de padrões / especificações / RFCs (especialmente quando se trata de criptografia), quando eles já são vistos como potencialmente obsoletos?

Eu sou um pouco com medo de perguntar porque a questão soa boba, mas se eu implementar RFC 4880 ", mas da minha maneira, não é mais a coisa oficial. Então, Qual é a melhor coisa que um desenvolvedor deve fazer contra o que ela vê como partes "obsoletas" de especificações? Nada?

Answer 1

primeiro: eu acho que o exemplo em sua pergunta está errado. rfc4880 usa um inteiro insignado 32 bits.O problema Y2K38 é um problema para assinado inteiros de 32 bits.De acordo com a Wikipedia, inteiros não assinados de 32 bits até o ano 2106. Um pouco mais de tempo.

Para responder sua pergunta: Eu acho que a melhor maneira é entrar em contato com o grupo de trabalho RFC / os autores do RFC e fala sobre a obsolescência.Talvez, um RFC de acompanhamento conserte esse problema.

Para o seu exemplo, acho que você pode se abster de entrar em contato com o OpenPGP WG.Eu acho que até 2106 haverá muitas atualizações e suspeito de chaves V5 para ter campos de tempo de 8 octetos.