News for hackers. Stuff that matters.
Re:Ubuntu Systemd Vulnerability by Someone1234 on Wednesday June 28, 2017 @12:48PM (#14655748)
Linux was written in 1991. Systemd was started in 2010.

The further you go back in time the less relevant the question is. And arguably any projects in the future written in C instead of a safer language really need to justify that choice if they sit on a security boundary.

C will be around for another hundred years or more. But hopefully new software looks beyond C giving that programmers seemingly cannot write and maintain secure software in it.

Re:Ubuntu Systemd Vulnerability by pjmlp on Wednesday June 28, 2017 @01:51PM (#14656452)
> The further you go back in time the less relevant the question is.

As Hoare so elegantly described at his Turing award speech, regarding Algol compilers, done in 1981:

"Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law."

Algol dialects like ESPOL and its successor NEWP where used for systems programming the Burroughs B5500 in 1961, 10 years before C was born, nowadays still sold by Unisys as ClearPath MCP.

Re:Ubuntu Systemd Vulnerability by Koshkin on Wednesday June 28, 2017 @03:24PM (#14657394)
Well, I guess, this has got to be said: security should never be a concern for application software developers.

This may or may not apply to things like systemd which live somewhere on the boundary between what would be pure "system" and "application" programs, but it is undeniably true that application program code, such as that of a document editor or a calculator, should be solely concerned with the application side of things, i.e. correctness and efficient implementation of what is otherwise known as "business logic", and security is usually not one of them - contrary to a very common, but mistaken, perception. It is the "system" component of the execution environment that should focus on what it has been designed for in the first place.

Therefore, ideally, it should not matter what programming language is used to write application software - whether it is C, Rust, Prolog, or SQL; it does sound ironic, though, that the most demanding pieces of a system - demanding in terms of reliability and security - are usually written in an "unsafe" language.