Debian discusses vendoring—again

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

Backports of security bugs don't change APIs.

to post comments

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.