On 26.09.2019 18:45, Maxime Villard wrote: > Le 26/09/2019 à 18:15, Manuel Bouyer a écrit : >> On Thu, Sep 26, 2019 at 05:28:11PM +0200, Maxime Villard wrote: >>> Le 26/09/2019 à 17:25, Brian Buhrow a écrit : >>>> [...] >>>> One implication of your proposal is that you'll disable the >>>> autoload >>>> functionality, users will turn it back on, use it, and be more >>>> vulnerable >>>> than they are now because the primary developers aren't concern with >>>> making >>>> things work or secure anymore. >>> >>> Nobody is making compat_linux work, nobody is making compat_linux >>> secure. > > My experience with a Linux program using forks and signals is that it > does not > work at all; the children get killed randomly for no reason, the parent > doesn't > receive the signals, and after some time everything needs to be killed and > restarted to work again. Completely broken. I didn't manage to find where > exactly the problem was. > > Under reasonable assumptions, compat_linux indeed used to be the most > maintained compat layer we had. This isn't the case anymore. Under > reasonable > assumptions as well, it has a marginal use case, and can be disabled. > > Maybe Manuel can understand that for a minute? Or is he still looking for > evidence that I'm not the Pope? > >> Secure, I don't know. > > Well Manuel can pretend everything he wants, but when it comes to > security and > compat_linux, we're entering the world of facts, and not reasonable > assumptions. > > compat_linux has a history of being vulnerable, the main reason being that > it is is poorly tested - no ATF, no reliable way to exercise the code > comprehensively -, and not actively maintained either. This has led to a > series > of exploitable vulnerabilities in the past, and a few weeks ago I found > even > more of them using a rather simplistic QA technique. > > I want to remind you, once again, that no one is talking about removing > functionality. We are talking about disabling it by default. The > functionality > will still be there, and only one command away from being enabled. > FreeBSD has > been doing that for a while, and OpenBSD did too before removing their > version > of compat_linux. It is simple, and it makes sense, and I don't > understand the > fuss and the nonsence that Manuel is trying to throw here. Maybe propose a plan to TNF to get it into a better shape? Statement that Linux-compat is not much used is false at least due to adobe-flash-plugin-11.2.202.644nb1. I find this package as a must have for a web browser.
Attachment:
signature.asc
Description: OpenPGP digital signature