Debian discusses vendoring—again

Posted Jan 13, 2021 10:08 UTC (Wed) by mjg59 (subscriber, #23239)
In reply to: Debian discusses vendoring—again by LtWorf
Parent article: Debian discusses vendoring—again

> How is it any less work?

Not having to verify that an update doesn't also break functionality you depend on is less work than having to verify that everything still works fine with a nominally compatible security backport.

Debian discusses vendoring—again

Posted Jan 13, 2021 11:52 UTC (Wed) by LtWorf (subscriber, #124958) [Link] (9 responses)

Backports of security bugs don't change APIs.

Debian discusses vendoring—again

Posted Jan 13, 2021 12:21 UTC (Wed) by mjg59 (subscriber, #23239) [Link] (7 responses)

Ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha

(No)

Debian discusses vendoring—again

Posted Jan 13, 2021 14:45 UTC (Wed) by LtWorf (subscriber, #124958) [Link] (6 responses)

Care to point out 1 patch done by a distribution security team that did change API?

Debian discusses vendoring—again

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

> Care to point out 1 patch done by a distribution security team that did change API?

Sure. I lost soft scrollback in my linux consoles, because upstream's "fix" for the security hole was to strip out the feature entirely. Maintaining that feature would have required devising an independent fix (which IIRC never happened) or reverying the upstream changes, leaving that hole open.

Debian discusses vendoring—again

Posted Jan 14, 2021 13:11 UTC (Thu) by LtWorf (subscriber, #124958) [Link] (4 responses)

That's not an API.

Debian discusses vendoring—again

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

Okay, fine, if you want to split hairs, I'll be more explicit.

The linux kernel API that allowed for software-based console scrollback was completely removed as part of a "stable kernel security update" from my distribution.

Sure, the patch that removed it originated with the upstream kernel, but it was still an API change that the distro pushed out to its users.

Debian discusses vendoring—again

Posted Jan 15, 2021 14:01 UTC (Fri) by jafd (subscriber, #129642) [Link] (2 responses)

Was the scrollback something you could use programmatically via a kernel API? Or maybe it exposed an ioctl(2) API? Or was there another driver that stopped working entirely because it was using some of the functions that had been a part of scrollback and got obliterated?

I'm confident the world could be better without this very bizarre definition of "API" both you and mjg59 are using here.

Debian discusses vendoring—again

Posted Jan 15, 2021 15:20 UTC (Fri) by farnz (subscriber, #17727) [Link]

It was - TIOCLINUX subcode 13 (undocumented, but existed) let you control the scrollback from user space. There are documented ioctls for copy and paste you can use to programmatically extract data from a VC.

Debian discusses vendoring—again

Posted Jan 22, 2021 5:19 UTC (Fri) by HelloWorld (guest, #56129) [Link]

This definition isn't bizarre at all.

Debian discusses vendoring—again

Posted Jan 15, 2021 14:12 UTC (Fri) by jafd (subscriber, #129642) [Link]

Not always, and certainly not in the javascript/NodeJS world.

I won't get into the madness of the neighboring thread (where they are discussing a user-visible change which is not an API change), but here's a very real scenario I'm seeing in a proprietary app that's my job to work on:

1) for $REASONS, we're stuck using a tool of the major version N. It's rather expensive to move to a tool of major version N+1 or N+2.
2) by now, some fourth-order dependencies of the tool had security vulnerabilities discovered, and the only path forward is to bump their major versions. Because JavaScript developers don't believe in backports. A dozen small libraries, but they are all over the place.
3) bumping them will need also bumping the third-order dependencies and so on, which is going to break the tool of version N, no longer maintained.
4) this kind of yak-shaving can take a lot of time, and I'm not counting the regressions that crept in because the migration documentation is far from being complete or accurate. Oh, and new versions of the tool produced buggy output which wasn't our fault. Back to the drawing board we are.

So, basically, until we find time to bring the tool to N+2, we're hosed according to "npm audit". Thankfully the tool is not user-facing, but you can see how "minor fixes" sometimes necessitate bigger changes a project may not be ready to embrace yet.