"Dmitry E. Oboukhov" <[email protected]> writes: > Tracking vendored deps in the security tracker seems quite doable. > Python deps are already listed in requirements.txt, JS in package.json, > etc. If the maintainer marks which of these are used as embedded, we can > automate tracking: when a CVE appears in libfoo, automatically file bugs > for all packages that ship it. That does not replace the current > workflow (patch/report upstream + Debian bug) but complements it.
There's a bit of a chicken and egg problem here: Presumably no one is going to want to do the work to build that tooling unless it's in service of being able to bundle dependencies, but bundling dependencies feels extremely unsafe to me until this tooling has been built. Do you have any ideas about how to break that circular dependency? Would it make sense to only allow bundling for language ecosystems where this tooling is already in place and ready to go? Also, by *far* the easiest way to address a security vulnerability if one was found would be to update the pinned dependency to a newer version with a fix. Often upstreams of small libraries don't make single-purpose patches available, and attempting to reconstruct the upstream fix is fraught with problems. Upstreams of such packages will almost always tell downstream users to just upgrade. If we're adopting a new workflow here, we should build a workflow that allows us to easily do that, since I suspect in most cases, a point release update of a dependency will just work. I do this all the time at work for the Python ecosystem and problems are very rare (probably less than 1% of updates). Having tools in place would address my other concern, which is that I'm worried that you are overestimating the feasibility of reliable automation to associate CVEs with package names with Debian embedded code copies and trigger a workflow that gets a fix into the right places. I'm very open to being happily proven wrong, but I kind of would like to be proven wrong before we relax this constraint. There's a lot of pressure towards using embedded code copies that we have resisted for (I think) valid reasons, if perhaps not persuasive reasons, and I'm worried that if we relax this rule prematurely we are going to get a *lot* of embedded code copies before we're ready to deal with it. I am also a bit reluctant to rely on CVEs, since a lot of the lower-level libraries that tend to be embedded don't issue CVEs. In some cases, my understanding is that they get CVEs precisely because Debian packaged them separately and we either issue or encourage others to issue them. If a library exists in Debian only as an embedded code copy, are you sure we'll even know if it has a security vulnerability? Personally, I have no philosophical objection to bundled code copies, and I think Debian clings to this line a bit too dogmatically, but I want to see a really solid plan and workflow for what we're going to do instead. All of Debian's tracking infrastructure is currently built around *not* doing this, and we have a lot of past history with embedded code copies that has underscored why we strongly discourage them (admittedly, mostly with embedded C code, which I think is a harder problem than the language ecosystems you're focused on). I think we need a plan and probably some working code for a new workflow so that we can look at something concrete and go "oh, okay, I see how that will work" or "no, this still doesn't solve these problems." The Policy team is probably not the right team to decide that the plan looks workable. I think that's probably the security and release teams, since this affects them the most (due to the security concerns and the impact on stable updates). > On “vulnerabilities” in this kind of application Bottles is an > application for running games, unprivileged. Even if a vulnerability is > found in one of those libraries, in this context it often will not be a > practical security issue. Stability for the user is critical, and > testing all usage scenarios here is hardly realistic. Yes, this is a separate problem that Debian, and the entire free software ecosystem, has, and I have no idea how to solve it. It's very common for the vast majority of security vulnerabilities in a library to have no meaningful security impact on a given user of that library, but it's quite difficult to be sure that this is the case without human review by an expert in that package. We don't have the resources, in general, to do that review, so we err on the side of patching all security vulnerabilities even if in practice they are not exploitable. There are many cases where this produces unnecessary churn and would be an overall benefit to both our workload and to our users to avoid that churn, but it's not at all clear how to do that safely. Every upstream with pinned dependencies has the same problem and I've yet to see a good solution to it. In my day job, we take the same approach Debian takes: We agressively update every pinned dependency on every release on the grounds that, on average, this will fix more security vulnerabilities (including ones that never got CVEs) than it introduces. That belief is mostly a guess and is not supported by rigorous data. Anyone reading this can think of a few obvious and dangerous counter-examples. The reality is that the free software ecosystem as a whole is very, very bad at tracking security vulnerabilities and understanding when upgrades are necessary and when they are risky. This is not just a Debian problem, and I don't think anyone has solved it. One could imagine somehow classifying some Debian packages as not interesting from a security standpoint based on how they're used, and in theory saving some work and churn, but in practice doing this is incredibly difficult, in part because people are not required to tell us how they are using software and use it in all sorts of unexpected ways. Most upstreams don't even have a written security policy that clearly explains what they consider their security boundaries to be and what classes of bugs they will not treat as security bugs, so users don't have the information required to make informed decisions. > Hence the question of value: what matters more to the user — being able > to run Windows games on Debian, or having e.g. patool 4.0.4 in the tree? > I would optimise for the former and for policy on vendored deps and the > security tracker not making such applications unrealistically hard to > maintain for little security gain. I disagree with this phrasing of the conflict, for whatever it's worth. I think the hard problems here are around sustainability of Debian's core teams and general reliability and security guarantees, and the marginal benefits of making available a few more packages to a few more users are dwarfed by those concerns. Even from a strict "our priorities are our users" standpoint, I think Debian's security and stability guarantees are more valuable to our users than an increase in package breadth. Users who want a package that we don't currently package have a wealth of options to install it; users who want fairly strong guarantees about consistency and security support have no good alternative if we weaken our guarantees. Obviously in an ideal world we would like to provide both, and there are probably cases where we're holding a line that we could relax a little without much harm, but if the tradeoff is stark, I think our existing practice is superior. The goal in this discussion, at least as far as I'm concerned, is to try to find a way to have everyone get what they want, not to make a harsh binary tradeoff. -- Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
