Re: xz exploit and backdoor

Ivan Sergio Borgonovo said on Sat, 6 Apr 2024 01:46:38 +0200


>Eg. you may write bloated software because someone is in a hurry or
>have to sell it... but you may write complex software just because the 
>problem is complex.

1: Because in a hurry
2: Because the problem is complex

#1 is obviously no excuse. If you don't have time to do it right,
triage features.

#2 can be split:

a: Because the entire feature set is necessary
b: Because a feature "would be nice" or "enhance sales/acceptance"

Unfortunately, in software, cars, home appliances, and lots of other
usages, 2b is running rampant. And the chickens are coming home to
roost. Without an acceptance that every feature has a substantial cost,
2b becomes the law of the land.

But wait, there's more. There's a #3 that might seem like #1, but it's
different...

3: Philosophy caused complexity: Should I build for repairability?

I could write a short book on this topic. Some of you know that before
I wrote software, from 1978-1985 I fixed consumer audio equipment, on
commission.  When you're on commission, speed matters. This is how I,
of all people, documented the Universal Troubleshooting Process.

Another factor of repair speed is to the extent which the equipment was
built for repairability. As a generalized first stab at repairability,
repairable equipment is built with small modules easily plugged and
unplugged, with small interfaces. These modules can easily be swapped
or in many case tested on their own. 

Oppositely, repair-hostile equipment is built from the inside out. Easy
to manufacture, but hell to repair. An example was the Sanyo car
stereos of the 1980's. Most brands recognized that the main rubber belt
should be easily accessible, via a plate with 4 screws, because belts
stretched beyond function every year or two. Sanyo, on the other hand,
built from the center out, so the entire unit had to be disassembled
just to maintenance-replace the belt. 40 minutes vs 5 minutes. When
you're on commission, you notice that.

Also very noticeable during my audio repair career was that modularity
greatly enhanced repairability. Ability to simply swap in a known good
module is a spectacular time saver. Then in my programming career,
ability to test a module on its own became indispensable.

WHAT IS MODULARITY?

There was a time when modularity needed no explanation to anyone
dealing with any technology. Today we have Lennart Poettering defining
"modular" as being able to select which modules you want to include
(myth 6 at http://0pointer.de/blog/projects/the-biggest-myths.html).
And he defines "not monolithic" as having 69 distinct modules. In both
cases, he gives no thought to how many interfaces, what kind of
interfaces, and how many feedback loops. See my take on this at
http://www.troubleshooters.com/linux/systemd/repairability.htm#interaction_promiscuity_and_repairability
.

The leftmost figure in the preceding link is my idea of modularity. The
figure on the right

I don't mean to pick on Poettering or systemd alone. This kind of
interaction promiscuity is now a hip thing, and added to that is the
fact that the interactions are increasingly more complex, making unit
testing more and more difficult.

The left had figure 






>
>The need of certain features may change in time... some protocols may 
>have been abandoned etc... but even good software like postfix comes 
>with a lot of features that are rarely used or make sense just in 
>certain circumstances. Compiling it yourself just to reduce attack 
>surface will make things more complicated, hard to manage etc...
>doesn't come for free and it has its own draw backs even in terms of
>security.
>
>Then of course there is good software and bad software as there is
>good administration and bad administration. But knowing which is which
>again doesn't come for free... it could be cheap to know and
>understand... or it may not be.
>
>Again there is a quite large overlap between the reasons you chose a 
>package and the way I chose a library...
>
>-- 
>Ivan Sergio Borgonovo
>https://www.webthatworks.it https://www.borgonovo.net
>
>
>
>_______________________________________________
>conspire mailing list
>[email protected]
>http://linuxmafia.com/mailman/listinfo/conspire


SteveT

Steve Litt 

Autumn 2023 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21