Typical security issues in C++: why the GC isn't your enemy

[H. S. Teoh]

On Thu, Dec 15, 2022 at 09:41:08AM +0000, areYouSureAboutThat via Digitalmars-d wrote:
> On Thursday, 15 December 2022 at 01:12:28 UTC, norm wrote:
[...]
> > Most security hacks (that I know of) are not due to C array
> > overruns.  Those headliners that usually come from C/C++ code
> > written >10yrs ago.  The majority of security breaches are due to
> > human activities, people clicking on fake email links, sharing
> > passwords, leaving computers unlocked, incorrect server and database
> > configuration etc. Rust and @safe will not solve these real world
> > problems.
> 
> you forget to mention.. 'and programmers blindly using third-party
> packages'
> 
> 'An Empirical Study on Production Dependencies in NPM' - 2022
> 
> "The problem is that developers struggle to identify what
> vulnerabilities may affect their software application.."
> 
> https://arxiv.org/pdf/2207.14711.pdf

+1, I have always been skeptical about the contemporary trend of using
fancy package managers with hairball external dependencies that make
your builds dependent on some opaque remote server somewhere out there
on the 'Net that you have no control over.  Some time ago somebody also
posted another article about how easy it is to conduct MITM attacks on
these external package repositories to insert a malicious package /
substitute a legitimate package with a malicious version.

Not only it's a security hazard, it's also a logistic time-bomb: you
never know if the remote server won't suddenly vanish off the face of
the internet right at the moment when you're about to release your
product and need to make the final production build. (It may come back
tomorrow or the day after, but deadlines would be missed, heads would
roll.)  You're basically putting yourself at the mercy (and/or
(in)competence) of some independent external entity you have zero
control or influence over.


T

-- 
In a world without fences, who needs Windows and Gates? -- Christian Surchi