Hacker News Reader

Comment by galangalalgol | Hacker News Reader

Supply chain attacks are worsened if everyone lives at the head. Staying far enough behind that some brave (and hopefully small) project discovers the compromise of a repo for some dependency five layers deep before you re-pin to a new version is probably the best mitigation short of some permissions based model like Austral is working on.

View on HN

C++ doesn't have the same kind of head as you are thinking. The standard gets pretty well-tested before being standardized as the most recent ("head") version. C++'s head gets more testing than most libraries ever get for any version.

Anyone with proper experience on C++ ecosystem knows this isn't the case.

Not only is ISO full of DR and things that probably shouldn't have been standardized in first place (thankfully some of them were latter removed), there is plethora of compilers to chose from.

Most people looking for modern C++ are choosing one of three compilers. Most code mostly works.

Those three compilers don't work everywhere, aren't allowed everywhere, and mostly works isn't "The standard gets pretty well-tested before being standardized as the most recent".

How were GC API, auto_ptr, modules, concepts and co-routines pretty well tested?

In those three compilers they surely weren't, so in which ones?

Most people are using more than one compiler at the same time. For instance, MSVC plus some combination of clang-based tooling for static analysis and/or local dev.

And folks using a full stack of MS tooling are probably using the EDG compiler as an implementation detail for IntelliSense support.

Yeah everyone seemed to have atarted talking about living at head in general. My concerns about living at head for c++ is primarily compiler and static analysis support. I like my pipeline to build for clang and gcc and run unit tests in both clang tidy modernize, gcov, cppcheck asan etc.

By the time all of that is supported for a language release we are on the next one, and I value that pipelene more than the changes currently being made.

The flip side is that exposure to software vulnerabilities is lengthened if people stay on older versions. So, you’ll be less vulnerable to intentional bugs in the software, but more vulnerable to unintentional bugs - and the latter are far more likely in practice.

Granted, the former can be quite a bit more severe - but that’s why we should do things like build on dedicated servers with restricted access to the internet etc.

There are older versions (no new features) and then there are older versions (no security updates). Most security updates don't break compatibility and can be installed without modifying anything that takes that version as a dependency.

This works as long as compatiblity-breaking changes are kept rare so that you can feasibly have someone doing security updates for each of the incompatible versions.

There are solutions to this - things like Dependabot go a long way and can integrate pretty seamlessly into your existing Git workflow.

Supply chain attacks only matter for libraries that can make their own network call, or libraries that directly touch unsanitized web input however?

How does one restrict network access for a library?

That was my thinking. In Austral that is a thing, but in c++ not so much. And if you are building the dependency from source, which is pretty common, the common build systems are all Turing complete themselves so they can take over your pipeline and do bad things.

Run your CI in an allow listed only network and only allow access to either your private, security scanned, mirror or else keep well trusted things. Even if a bitcoin miner gets into the stack it can’t send the results to the source so it is less dangerous.

But it can insert itself in your pipeline so that anyone who depends on you is also infected. We have already seen CI worms for thevlack of a better term. One was briefly spreading in crates.io early last year as part of the "crate depression" thing.

Supply chain attacks matter anytime you need to trust the code being run. Which is usually always.

Most libraries have network access, but even if they didn't, supply chain attacks could be relavent (but probably less generic)

Reply on news.ycombinator.com