O uso de determinada linguagem de programação está relacionada a vários argumentos, incluindo garantir uma variedade de segurança, entre elas a proteção de memória inerente. O assunto foi tema de um documento publicado recentemente pela Agência Nacional de Segurança norte-americana (NSA), que mencionou exemplos de linguagem segura de memória, como também provocou reações do criador do C++, que rebateu o trabalho em um ‘call to action‘.

Em novembro passado, a NSA divulgou o ‘Software Memory Safety’, um documento aconselhando organizações a considerarem uma mudança estratégica das linguagens de programação que fornecem pouca ou nenhuma proteção de memória inerente a uma que seja segura para a memória quando possível. No relatório, a agência citou C#, Go, Java, Ruby, Rust e Swift como exemplos de escolha segura, excluindo explicitamente o C e C++, o que chamou a atenção de Bjarne Stroustrup, o pai da linguagem.

“As linguagens comumente usadas, tais como C e C++, proporcionam muita liberdade e flexibilidade na gestão da memória e, ao mesmo tempo, confiando fortemente no programador para realizar o verificação das referências de memória. Erros simples podem deixar a memória explorável sob vulnerabilidades” — em ‘Software Memory Safety‘, da NSA.

O cientista da computação dinamarquês rebateu os argumentos em no paper “A call to action: Think seriously about ‘safety’; then do something sensible about it” (“Uma chamada para ação: Pense seriamente sobre ‘segurança’; depois faça algo sensato a respeito disso”, em tradução livre), publicado em janeiro em seu site, explicitando que não considera nenhuma das escolhas da NSA linguagens ‘seguras’ e superiores ao C++ para a gama de usos com os quais ele se preocupa.

Segurança do Rust não é superior ao de C++, rebate pai da linguagem

Imagem: Julia Kryuchkova, CC BY-SA 2.5 <https://creativecommons.org/licenses/by-sa/2.5>, via Wikimedia Commons

“Isso exclui específica e explicitamente o C e o C++ por não serem seguros. Como é muito comum, ela junta o C e C++ em uma categoria única C/C+++, ignorando mais de 30 anos de progresso. Infelizmente, o uso massivo do C+++ também está preso a um passado distante, ignorando as melhorias, incluindo formas de melhorar drasticamente a segurança”, critica o dinamarquês.

“Trabalhei durante décadas para tornar possível escrever o C++ melhor, mais seguro e mais eficiente. Em particular, o trabalho sobre as Diretrizes Essenciais C++ visa especificamente fornecer C+++ estaticamente garantido para pessoas que precisam disso sem interromper as bases de código que podem gerenciar sem essas fortes garantias ou introduzir cadeias de ferramentas adicionais. Por exemplo, o analisador Visual Studio da Microsoft e seu perfil de segurança de memória fornecem grande parte do suporte de CG atualmente e qualquer bom analisador estático (por exemplo, Clang-Tidy, que tem algum suporte de CG) poderia ser voltado para fornecer completamente essas garantias a uma fração do custo de uma mudança para uma variedade de novas linguagens ‘seguras'”, diz o criador do C++, citando artigos relacionados à segurança e à linguagem.

Segurança do Rust não é superior ao de C++, rebate pai da linguagem

Imagem: CStudio/Freepik

Ele também critica o termo usado pela agência governamental: “‘seguro’ está limitado à segurança da memória, deixando de fora na ordem de uma dúzia de outras maneiras que uma linguagem poderia (e será) usada para violar alguma forma de segurança e proteção”.

“Não há apenas uma definição de ‘segurança’, e podemos alcançar uma variedade de tipos de segurança por uma combinação de estilos de programação, bibliotecas de suporte e aplicação por meio de análise estática. P2410r0 dá um breve resumo da abordagem. Prevejo opções de compilação e anotações de código para solicitar regras a serem aplicadas. O mais óbvio seria solicitar a garantia de segurança total do tipo e dos recursos”, rebate.

Criador do C++ questiona fonte de relatório da NSA e afirma que ignorar segurança não é uma opção

Stroustrup defendeu ainda que as questões de segurança são tão importantes que ignorá-las prejudicaria setores e grande parte da comunidade C++, bem como o foco exclusivo em tal característica. Ele revelou que outros trabalhos estão em andamento para melhorias da linguagem. “O que poderia ser “algo sensato de se fazer”? Sugiro fazer uma lista de questões que poderiam ser consideradas questões de segurança (incluindo UB) e encontrar maneiras de evitá-las no âmbito do P2687R0″, recomenda.

“A adoção gradual de regras de segurança e adoção de regras de segurança diferentes serão importantes. Se por nenhum outro motivo exceto as bilhões de linhas do código C++ desaparecerem por mágica, até mesmo o código ‘seguro’ (em qualquer linguagem) terá que chamar o tradicional código C ou C++ ou ser chamado pelo código tradicional que não oferece garantias específicas de segurança”.

O programador ainda questionou o que a NSA chama de “comunidade global de software”. “Até onde eu sei, nenhum especialista do comitê de normas ISO C++ foram consultados”, criticou.

 

Com informações Slashdot e Stroustrup

Comentários

0

Please give us your valuable comment

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Inscrever-se
Notificar de
0 Comentários
Feedbacks embutidos
Ver todos os comentários