Debian discusses vendoring—again

Posted Jan 13, 2021 12:51 UTC (Wed) by dottedmag (subscriber, #18590)
In reply to: Debian discusses vendoring—again by pizza
Parent article: Debian discusses vendoring—again

This is obviously true for codepaths that are security-sensitive: depending on a CADT-model Web-facing or other untrusted-input library is a recipe for disaster (or increased blood pressure and loss of sleep at least).

Fortunately, not everything is security-sensitive, so the requirements may be relaxed there, and untrusted input boundaries are not that hard to contain if that's understood as a necessary part of engineering process.

> Meanwhile, in the real world, the choice is "use this library" or "write something equivalent from scratch". Repeated dozens of times.

Hard to reimplement, bad security policy => isolate. This one is tough. Containerization helps somehow, but it's best if this set is empty.

Easy to reimplement, bad security policy => drop. Over time I find more and more code falls into this bucket.

Hard to reimplement, good security policy => use. Precious. Rare.

Easy to reimplement, bad security policy => use if fits exactly. Freebies. Nice to have.

Debian discusses vendoring—again

Posted Jan 13, 2021 13:36 UTC (Wed) by pizza (subscriber, #46) [Link] (5 responses)

> This is obviously true for codepaths that are security-sensitive: depending on a CADT-model Web-facing or other untrusted-input library is a recipe for disaster (or increased blood pressure and loss of sleep at least).

Welcome to software development in the real world, where the _only_ consideration [1] is "how much will it cost this quarter"

(FWIW I don't disagree with anything you have written; but at the end of the day, the folks paying our salaries decide what our development priorities are)

[1] Beyond what is legally mandated by law or private contract (eg required by your payment processor or insurance carrier)

Debian discusses vendoring—again

Posted Jan 13, 2021 13:45 UTC (Wed) by dottedmag (subscriber, #18590) [Link] (4 responses)

I happen to be making these decisions and I know how to translate them to the money.

«This critical-and-not easy-to-replace library has N 0-day exploits with RCE per year. The choices are: 1) use it as is and sustain M break-ins, each conservatively estimated to cost $X / year in lost revenue, cleanups, damage control etc plus $Q for initial use of this library; 2) proactively monitor and patch vulnerabilities, estimated cost is $Y / year plus $Q for initial use of this library; 3) develop a replacement in-house, estimated cost is one-time $Z and $W / year maintenance»

Sure it takes some experience and data to start making these decisions, but once the data is there it becomes much easier to decide. Also over time (3) becomes cheaper as problems don't tend to be unique every time.

Debian discusses vendoring—again

Posted Jan 13, 2021 14:47 UTC (Wed) by pizza (subscriber, #46) [Link] (3 responses)

> 3) develop a replacement in-house, estimated cost is one-time $Z and $W / year maintenance»
> Also over time (3) becomes cheaper as problems don't tend to be unique every time.

You left out the cost of cleaning up after exploits found in your in-house library. Because your in-house code is far (far!) more likely to be full of holes than random F/OSS libraries that are used by a variety of other folks.

You also left out the fact that if it's in-house, $Z and $W are paid entirely by your organization, so while (3) might get smaller (relative to itself) over time, it will forever remain much larger than using a F/OSS library whose $Z and $W approach $0, as you're not shouldering the entire price of development and maintenance yourself.

In the end, most organizations go with (1) because they simply don't have the resources to do anything differently. (3) tends to only happen in areas where cost is not a primary consideration (eg military, medical, safety, and other highly regulated industries) or when there are specific requirements that cannot be met any other way. Varying degrees of (2) is where most organizations end up, typically balanced on the trailing edge of cost-benefit analyses.

Debian discusses vendoring—again

Posted Jan 13, 2021 18:36 UTC (Wed) by hkario (subscriber, #94864) [Link] (2 responses)

(3) also makes sense if any of the existing solutions don't share the goals you have (platform support, maintenance windows, etc.)

and just because you develop in-house doesn't mean you have a). started from zero, b). don't open-source it so that others that do share your goals can contribute

Debian discusses vendoring—again

Posted Jan 13, 2021 19:31 UTC (Wed) by pizza (subscriber, #46) [Link] (1 responses)

oh, quite right.

It's just that when you make that decision to go your own way, you can't assume that anyone else will ever contribute anything, much less shoulder the majority burden of developing/maintaining it.

Debian discusses vendoring—again

Posted Jan 13, 2021 19:36 UTC (Wed) by dottedmag (subscriber, #18590) [Link]

This equally applies to every open source library ever published, doesn't it? :)