Huawei savaged by Brit code review board over poor dev practices

Not until someone in a company has a great idea of hooking that up to the internet insecurely...

Basically the medical equivalent of attaching the internet on Jeep's CAN bus...

In large companies there is never 'a' team of programmers, there are N teams of programmers with varying amounts of communications and cooperation going on between them, where "varying" often includes being completely unaware of the other teams existence.

N different teams working independently of each other each implement a variation of feature X to solve their own problem. The someone decides it's time to merge the whole thing together and it's easier to just use the N different implementations of X rather than to try to refactor and debug a single implementation of X that works for all N cases.

"Just get it out the door and we'll fix it later". I've heard that from most managers I've known.

Instead of this:

"We need to audit then refactor the existing codebase to bring it up release quality. It will delay release by 2 months, but we are dealing with customer PII so we have to be as stable as possible to prevent break-ins."

Or this:

"Don't deploy the prototype to production"

The "culture" behind this is endemic to industry and isn't anything unique to Huawei.

People have already commented on this not being a "team". Let me focus on "programmers".

What probably happened is that many of Huawei's programmers are EEs who happened to take a programming course or two in college.

But learning to think and behave like a good programmer is much more than that. It requires a certain mindset. It may require a certain amount of avocation and enthusiasm, beyond what is taught in an introductory programming course. It requires one to grok good software practices.

Most non-CS majors in college (USA or China or whatever country) probably don't get much of that cultural indoctrination during the few programming courses they take. The engineer wants to pass/ace the programming course. Learning the aesthetics or nuances isn't a priority.

Programming is just too easy. Type a few lines into a file, compile, debug syntax errors, tweak until you get something that looks right. There's no rigor involved. No style. No aesthetic.

Don Knuth called it "The Art of Computer Programming". I submit that many engineers don't think of programming as an art. It's just a means to an end.

E.g. here's an example from a large codebase that was extensively reviewed. The context was Toyota's unintended acceleration problem of about 15 years ago. The design review found things like: Other egregious deviations from standard practice were the number of global variables in the system. (A variable is a location in memory that has a number in it. A global variable is any piece of software anywhere in the system can get to that number and read it or write it.) The academic standard is zero. Toyota had more than 10,000 global variables.[1]

None of this will ever change until and unless a company's top level management understands the problem and mandates change.

Additionally, there's always an incredible push to bring new products to market. That's 1000x more important than it is to follow best software practices.

[1] http://www.safetyresearch.net/blog/articles/toyota-unintende...

There is also the fact that cryptographic libraries that are certified are often on a 2-3 month delay from the non-certified modules. You have to verify that the Host OS's kernel, the runtime that is providing the containing environment, and every single Docker image that is used to run an application, ensure that each application is running in an appropriate FIPS 140-2 mode inside the container, and also verify that every container is being appropriately kept up to date.

Using Docker does not eschew responsibilities you have to ensure that your OpenSSL and other materials is up to date, especially since Docker doesn't give you any protections when it comes to encryption over the wire or encryption with data at rest which is exactly where a cryptographic library with a vulnerability like in the original article leaves a vulnerability where there shouldn't be one.

Yes, and it also highlights that we need independent review of any code going into critical public infrastructure, no matter where it comes from.

I'm failing to find more information (googling for ssl issues on ssl termination equipment doesn't work well,) though it sounds like it'd be a good read - if you have any more details to share, please...

The memcpy shadowing is really, really, really bad. If I see something like that in production code I would never touch it. Removing it could break code from both, people who relied on a check and those who didn't.

The 4 versions of openssh? Happens if you are in business for a longer time in my experience. We don't know on how many devices the software is run on.

Sure, it could probably be cleaner, but so could nearly every form of production code I saw in the real world. I would surprise me to see a different situation elsewhere.

There's no such thing as 'trust people'. If you write the code yourself you decide whether your own code is safe enough. If you are a manager, you look for unit tests, static analysis or do a detailed code review.