Articles

the Akamai Blog Subscribe

by admin

Shortly after Y2K we made jokes about ” next up, Y2038!”mas naquela época sentia-se uma eternidade no futuro e provavelmente seria um problema de outra pessoa. Agora que estamos a meio caminho, e já chegamos ao ponto em que os problemas do Y2038 podem causar falhas de software, é uma boa oportunidade para começar a planejar para o Y2038. Por exemplo, o software pode já ter problemas a trabalhar com certificados de 20 anos de vida ou hipotecas de 20 anos, e a frequência destes problemas só vai aumentar à medida que nos aproximamos do Y2038. Em Akamai, já estamos executando planejamento e testes internos estrategicamente orientados para o Y2038, e parece provável que o escopo deste trabalho continuará a crescer ao longo dos próximos 19 anos, à medida que este importante esforço aumenta de urgência.

Muito pouco deu errado em 1 de janeiro de 2000 para nós (curto de algum Javascript em um site de marketing Akamai exibindo “19100” como a data atual!), mas uma coisa que se perde é que o impacto global limitado que noite foi devido a dois fatores: 1) a quantidade de preparação avançada que foi feito; 2) muitos “problemas Y2K” realmente ocorreram com anos de antecedência em vez de durante o roll-over em si. Os segundos bissextos são, de certa forma, mais assustadores do que os problemas de formato de data, na medida em que são mais difíceis de testar e muito menos do impacto acontece com antecedência. Existe o risco de que a falta de impactos do Y2K possa levar organizações e tecnólogos a se prepararem para o Y2038. Também é mais difícil explicar “Y2038” para leigos do que o Y2K, tornando potencialmente mais difícil priorizar e focar o trabalho avançado. O grande número de dispositivos incorporados da Internet das Coisas (IoT) tornando-se onipresente em nosso ambiente também faz o risco provável e o impacto potencial consideravelmente mais elevado para Y2038 do que foi para Y2K.

muitos anos atrás eu ouvi uma anedota talvez apócrifa sobre um impacto inicial da produção do Y2K. Um armazém tinha dois trabalhos automatizados: um que procurava paletes de produtos expirados e os enviava para eliminação, e um segundo que procurava um inventário baixo e encomendava mais de um produto. Tomate enlatado foi o primeiro produto a ter datas de validade começando a atravessar para o ano 2000, e um bug Y2K dirigiu um operador de empilhadora para se livrar desses tomates (expirando em 1900!) quando chegaram. O sistema então identificou que havia um estoque baixo em tomates enlatados e iria pedir mais. Algumas semanas mais tarde chegariam, e alguns dias mais tarde o operador de empilhadora seria despachado para se livrar deles. Este ciclo continuou até que o operador de empilhadora finalmente percebeu algo errado e escalou o problema. É provável que algumas das primeiras questões do Y2038 sejam de natureza bastante semelhante.a nossa experiência inicial com o planeamento do Y2038 (além de ver o choque das pessoas ao ouvir preocupações que estão a ser levantadas que no primeiro som a 19 anos de distância) é que é necessária uma abordagem incremental e focada nesta fase. Muito mais envolvidos e programas abrangentes certamente serão necessários algum Número de anos ao longo da estrada. Nesta fase inicial, algumas áreas de foco incluem: 1) software que lida com horários e datas futuras; 2) mensagens on-the-wire e formatos de arquivos; 3) dispositivos com vida útil longa e suas dependências. É claro que à medida que nos aproximamos, será fundamental começar a focar em conjuntos mais amplos de sistemas, incluindo garantir que eles possam lidar com a transição Y2038 em segurança.

Software que lida com datas futuras

talvez a área mais importante para se concentrar inicialmente é o software que lida com datas no futuro, como para o tratamento de certificados X. 509 ou para o planeamento financeiro. Existem muitas representações de formato de data e hora, nem todas terão um problema Y2038. Por exemplo, software que precisa lidar com os tempos dos séculos passados (bem antes de 1970) muitas vezes escolheu diferentes datas e horas representações. No entanto, ao testar os casos de certificados X. 509 (como usados para HTTPS) e autoridades de certificados (CAs), encontramos inúmeros problemas de software no laboratório que começam a surgir com certificados e CAs expirando após Y2038.

OpenSSL em particular tem vários formatos de tempo, com ASN1_UTCTIME tendo um limite em Y2049( um problema distinto para planejar a partir de Y2038), então use as funções ASN1_TIME fornecer compatibilidade com todos os intervalos de tempo. Converter tempos de saída de uma biblioteca como o OpenSSL para 32-bit time_t é uma área adicional que provavelmente terá problemas.

em muitos destes casos, foi possível resolver os problemas simplesmente por portagem e Compilação de software legado para arquiteturas de 64 bits (eg, para mover de um tempo inteiro de 32 bits para um time_t de 64 bits). Em outros casos, mudanças mais extensas têm sido necessárias, especialmente quando os tempos são lançados em inteiros para matemática ou quando os formatos de fio de mensagem se envolvem ou para quando os valores são armazenados em bases de dados. No teste e fixação de suporte para 20 anos CAs, uma coisa que apareceu é que dependências a jusante também entram em jogo. Por exemplo, se uma data de 20 anos no futuro for introduzida em um sistema de registro ou sistema de monitoramento, e se aqueles por sua vez feed em sistemas de alerta ou relatórios de bases de dados ou sistemas de provisionamento, então todos eles também podem precisar de correções.

no-fio mensagem e formatos de arquivo

como mencionado acima, quando os tempos de 32 bits são colocados em mensagens, bases de dados, ou formatos de arquivo o impacto pode estender-se muito além de um sistema específico. Estes são também sistemas com dependências externas onde um planejamento mais avançado é muitas vezes necessário como interações cruzam os limites do sistema. Para essas coleções de sistemas interoperativos, mudanças podem precisar ser liberadas em uma ordem específica e compatibilidade reversa muitas vezes entra em jogo. Além disso, se houver protocolos formalmente ou informalmente padronizados que usam os valores de tempo da época de 32 bits em Mensagens, qualquer migração ou correção pode ser baseada na fixação do padrão. Como tal, estes tornam-se importantes para se preocupar como com uma cadeia de dependência, como:actualizar o protocolo / normas para suportar os intervalos de tempo pós-Y2038.

  • Implemente suporte para o padrão atualizado em bibliotecas de software.
  • obtenha uma nova versão das bibliotecas incorporadas em pacotes de software.obter pacotes de software incluídos no novo produto de transporte.

    • então se cada um destes leva alguns anos e o produto de transporte tem uma longa vida útil, então os longos prazos aqui pode já ser um problema.

    dispositivos com vida útil longa e suas dependências

    outra área para começar a se focar no início é dispositivos com vida útil longa. Como já foi mencionado, seguir através das dependências externas estes dispositivos têm também é importante. Dispositivos embarcados com hardware de 32-bit também podem não ter uma correção fácil de” apenas compilar para um time_t de 64-bit ” através de uma atualização de software, ou fazê-lo pode ter um impacto de desempenho inaceitável.

    Automóveis conectados e outros dispositivos IoT são provavelmente uma área de preocupação específica, mas tenho certeza de que existem muitos outros tipos semelhantes de dispositivos e aplicações. Por exemplo, dadas as tendências actuais, é provável que mais de 10% dos automóveis vendidos hoje ainda estejam a funcionar em Y2038, e com o aumento da Idade do veículo e do número de veículos na estrada este pode ser ainda mais elevado. Se leva alguns anos para os automóveis de transporte para ser geralmente y2038 compatível, com a atual (e crescente) distribuição de idades de veículos automóveis, podemos acabar com uma fração significativa de automóveis com o potencial de ter problemas graves em dezenove anos. Este mesmo padrão provavelmente existe também em algumas outras indústrias, como na eletrônica de consumo (como consolas de jogos domésticos e televisores inteligentes), onde os dispositivos podem ser enviados com certificados CA de mais de 20 anos pré-instalados.

    dispositivos com vida útil longa pode exigir testes mais abrangentes tanto do dispositivo quanto de suas dependências, tais como testar que o sistema operacional e o software continuam a funcionar corretamente antes, durante e depois do ponto de transição Y2038.Feliz Ano Novo!

    a edição Y2038 está numa categoria semelhante à IPv6: é uma expansão de várias décadas que no caso geral é importante, mas ainda não urgente (por matriz Eisenhower). A partir desta perspectiva, agora é um bom momento como qualquer outro para começar a planejar, triagem e testes antes que se torne urgente (ou tarde demais). Concentre-se em primeiro lugar em software que lida com datas futuras, mensagens on-the-wire e formatos de arquivos, e dispositivos com vida longa implantada. Em seguida, use a experiência do foco inicial para construir um programa mais abrangente nos próximos anos. Independentemente disso, defina uma barra mínima e comece a se certificar de que novos softwares, sistemas, protocolos e produtos que você está construindo e implantando não introduzam questões Y2038, e preocupações da bandeira quando você vê o tempo de 32 bits-desde-o-unix-epoch incluído em novos projetos.Erik Nygren é um arquiteto chefe da Organização De Engenharia de plataforma de Akamai. Ele vai celebrar o seu 20º aniversário em Akamai em junho.obrigado a várias pessoas da Akamai pelas suas contribuições para este artigo.embora tenham sido tomadas precauções na preparação deste documento, Akamai Technologies, Inc. não assume qualquer responsabilidade por erros, omissões ou danos resultantes da utilização das informações aqui contidas. A informação aqui está sujeita a alterações sem aviso prévio. Akamai e o logotipo Akamai wave são marcas registradas ou marcas de serviço nos Estados Unidos (Reg. U. S. Pat. & Tm. Nao). Publicado Em 10 De Janeiro De 2019.