Paul Wise <p...@debian.org> writes: > I think the discussion we are having here is orthogonal to > containers/flatpaks.
> If Debian were to have a repository of containers/flatpaks, then it > should meet Debian standards. We cannot just say "here are some > containers, completely unsupported and might not up to our standards". > To achieve that, I think it would be best to automatically convert it > from Debian binary packages. Also, since we are already doing packaging > work, it makes sense to base any container efforts on that, just like > our cloud efforts have been. I agree with this. Putting aside completely missing licenses or completely missing source code (these are sometimes more fixable problems, since those are considered suspect practices even in the upstream communities), the root problem here is vendored dependencies. Most modern languages, not just Java and Node, are switching to vendored dependencies with some mechanism for freezing the dependencies for a project. See Rust, Go, and increasingly, Python and Ruby, and I would expect to see the same for any new, popular programming language. For better or worse, there's a general consensus upstream of us in a lot of language communities that API backward compatibility and continuous upgrades are simply too hard, and breaking changes (ideally with semver) plus freezing and vendoring dependencies are the best solution. We can certainly disagree with this, but this approach has a ton of momentum behind it, and we're swimming upstream right now. We convince some folks, but not many, and the Node ecosystem in particular is so firmly committed to this approach that it's hard to imagine them backing away from it. So, where does that leave us? The reason why Debian in general doesn't like to support vendored source is because of the security implications: when there's a security vulnerability in one of the vendored libraries, updating the relevant packages becomes a nightmare. It's a logistical challenge even if the vendored source can be safely upgraded, but of course it usually can't since that's the whole point of vendoring the source. So we would be faced with backporting security fixes to every vendored version of the package, and we don't have the resources to do this. Note that this is not a *Debian* problem, this is an *ecosystem* problem. No one *else* has the resources to do this either, and generally what happens out there in the world is that this is just not done. Those applications blithely continue running with vulnerable versions of their dependencies, and aren't updated. I think it's important to note here that we're not wrong. Our approach is substantially more secure because we can patch software. Vendoring everything is substantially less secure since you're relying on the application developer to re-vendor fixed versions, and they may not even know there was a vulnerability. (High-quality vulnerability feeds for a lot of these ecosystems are very hard to come by.) It's not that someone else is succeeding where we're failing; it's that lots of other people have decided to just blow off security in the name of convenience and hope they don't get bitten by this. Using flatpak therefore doesn't really change the equation. It *does* provide some jailing by default, which can protect some against a certain type of vulnerabilities (and which we could provide in other ways as well; flatpak just makes it easier). But it does nothing against the more common problems of, say, XSS vulnerabilities in some Javascript library used for the web front end of the application. It's hard to avoid the feeling that we have two choices with these sorts of applications: 1. Lower our security standards and provide whatever the application developer provides, relying on them to re-vendor for security updates. This would probably mean not releasing these packages with stable releases or immediately adding them to the unsupported security list, unless we're going to significantly relax the normal security guarantees we provide. 2. Maintain our security standards, reject packages with large amounts of vendored software, and therefore, in practice, ask our users to separately install such software via whatever means the application developer provides. Users who choose to do this won't be any more secure (they'll probably be somewhat less secure since those updates won't be hooked into their normal system update process), but at least they have to make a conscious choice to opt in to that behavior, and a Debian installation with pure Debian packages is relatively secure by default. So far, we've defaulted in option 2, which means we're not packaging a lot of very useful software. But I don't think this is due to some obvious error on our part. The only practical alternative appears to be 1, and 1 is really not very appealing. It does make things more convenient for our users, but at a substantial cost to our security guarantees. I suppose a possible third option would be a new archive that explicitly has no security support, sort of similar conceptually to how we handle non-free or contrib. That would be a sort of compromise, but I'm not sure it would make anyone happy. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>