On 2020-08-25, Eric W. Biederman <ebied...@xmission.com> wrote: > C) You have overstated what I have agreed to here. > I have have previously said that I agree that having a MAINTAINERS > entry so people who are unfamiliar with the situation with namespaces > can find us. Given that most of the changes going forward are likely > to be maintenance changes. > > I also said we need to talk about how we plan to maintain the code > here. > > It feels like you are pushing this hard, and I am not certain why you > are pushing and rushing this. With my maintainer hat on my big > concern is we catch the issues that will introduce security issue. > Recently I have seen a report that there is an issue on Ubuntu > kernels where anyone can read /etc/shadow. The problem is that > Ubuntu has not been cautions and has not taken the time to figure out > how to enable things for unprivileged users safely, and have just > enabled the code to be used by unprivileged users because it is > useful. > > In combination with you pushing hard and not taking the time to > complete this conversation in private with me, this MAINTAINERS entry > makes me uneasy as it feels like you may be looking for a way to push > the code into the mainline kernel like has been pushed into the > Ubuntu kernel. I may be completely wrong I just don't know what to > make of your not finishing our conversation in private, and forcing > my hand by posting this patch publicly.
Eric, with all due respect, Christian is not a sleeper agent of some shadow Ubuntu kernel team that is tirelessly trying to slip things by you. I have no idea where you could have possibly gotten this impression, given his track record of the past few years. I also don't understand why you feel the need to talk about things which he had nothing to do with -- what relationship does the /etc/shadow thing have to do with his work and track record? Were Debian kernel contributors considered untrustworthy because of the OpenSSL weak keys issue? Would it be fair to question your competence because some RHEL kernel backports were borked? Of course not -- that would be ridiculous! > At the same time I am not convinced you are actually going to do the > work to make new code maintainable and not a problem for other kernel > developers. > > A big part the job over the years has been to make the namespace ideas > proposed sane, and to keep the burden from other maintainers of naive > and terrible code. Pushing this change before we finished our private > conversation makes me very nervous on that front. What gives you that impression? This whole thing seems incredibly strange -- we've all met IRL several times, and have had many long discussions about the best way to solve problems without placing undue burden on kernel maintenance. Furthermore, I don't think this is an acceptable way to talk about a peer within the kernel community -- attributing malicious intent without any justification other than "I feel this is the case" is little more than a character assassination, and I don't see why you would feel that such a statement is justified. -- Aleksa Sarai Senior Software Engineer (Containers) SUSE Linux GmbH <https://www.cyphar.com/>
signature.asc
Description: PGP signature
