Opinion
Num texto publicado em setembro, Mark Russinovich, CTO (Chief Technology Officer) do Azure, afirmou que para projetos novos, as linguagens C e C++ deveriam ser evitadas a todo o custo e substituídas por uma outra, da mesma “família”, chamada Rust. Mark Russinovich é uma figura respeitada na indústria
Por Henrique Carreiro . 17/10/2022
Não apenas detém um doutoramento em ciência de computadores, como é fundador de uma empresa chamada Sysinternals, que foi posteriormente comprada pela Microsoft, como é ainda autor de livros sobre os “internals” do Windows e sobre cibersegurança. É certo que, hoje, poucos projetos se começarão de raiz com tais linguagens, especialmente uma vez que as grandes empresas, como a Microsoft, a Google, a Meta ou a Amazon são utilizadores declarados de Rust. Mas milhares de milhão de linhas de C/C++ persistem em código legado, e são em parte essas que dão origem aos constantes e bem conhecidos problemas com que nos deparamos atualmente. Para a escrita de programas de sistema, os que estão mais próximos do hardware, linguagens populares como Python ou C# não são opção, já que introduzem demasiada carga e imprevisibilidade nos tempos de processamento. Assim, ao longo de décadas, primeiro C, que esteve na base do Unix e depois C++, que introduziu melhorias em termos de produtividade, nomeadamente no que respeita à orientação a objetos, mas que quis manter a compatibilidade com C, têm sido usados para criar sistemas operativos e drivers, entre muitos outros componentes do nível mais baixo. Uma das razões para tal é a enorme liberdade que dão aos programadores para tirar partido de todas as capacidades subjacentes do hardware. Mas tal liberdade torna mais difícil criar programas seguros, especialmente porque não é possível a um programador, a trabalhar normalmente sobre pressão de tempo, antever todas as possibilidades que podem ser usadas para causar uma exceção ao código que está a criar. Rust, uma linguagem mais recente, concebida para minorar tais problemas, introduz verificações mais estritas a nível de compilador que, ainda que não travando a liberdade ao programador, tornam mais difícil suceder o tipo de problemas que estão na base de quase setenta por cento dos problemas de segurança atuais, segundo números da Microsoft. Rust deverá ser usado também no kernel do Linux, segundo afirmado recentemente por Linus Thorvalds, o seu criador e principal responsável pela respetiva manutenção. Não que a preocupação de segurança desde a origem e não à posteriori seja nova, mas a urgência tem aumentado à medida que a severidade dos ataques se agrava, também, de algum modo, exacerbada pelas tensões geopolíticas, uma vez que a exploração de vulnerabilidades de software é hoje, também, uma arma bélica. Prova disso é que, já em setembro, a Casa Branca emitiu uma ordem executiva com um conjunto bem específico de requisitos de segurança que os organismos do estado norte-americano deverão cumprir quando adquirem software, nomeadamente das garantias que exigem aos fabricantes e fornecedores. A Casa Branca recorreu ao respeitado NIST (National Institute of Standards and Technology) para produzir uma recomendação denominada Secure Software Development Framework, que deve ser seguida por todos os fornecedores que pretendam vender software ao governo norte-americano, provavelmente o maior cliente em todo mundo. Evidentemente, a criação de software mais seguro não acontece por decreto. Há processos a mudar – e tal leva anos – e código legado a rever – e tal leva décadas. Mas é um bom princípio ver uma nova vaga de fundo a levantar-se, vinda simultaneamente dos fornecedores e dos clientes, ou, pelo menos, de quem os pode representar com poder real para decisões em larga escala. Só resta que estas iniciativas sejam adotadas depressa e de forma eficaz noutras latitudes. Com todos os riscos que existem atualmente, o que o mundo não precisa são dos derivados de “leaks” de memória, “overflows” de “buffers” ou ponteiros perdidos. Quanto mais depressa estes forem mitigados, mais recursos poderão ser atribuídos a mitigar outros – que não param, esses também, de crescer. |