* [PATCH] MAINTAINERS: add namespace entry @ 2020-08-25 15:41 Christian Brauner 2020-08-25 16:01 ` Joe Perches 2020-08-25 16:26 ` Eric W. Biederman 0 siblings, 2 replies; 7+ messages in thread From: Christian Brauner @ 2020-08-25 15:41 UTC (permalink / raw) To: linux-kernel Cc: Mauro Carvalho Chehab, Rob Herring, David S. Miller, Christian Brauner, Eric W. Biederman Namespace maintainership has never been formalized which has led to confusion when people need to determine where to send patches and who should take a look at them. Especially, since we have a dedicated list containers.lists.linuxfoundation.org already for a long time. In preparation of this patch I added the containers.lists.linuxfoundation.org mailing list to be archived on lore. This will not just make it easier to catch and review patches specific to namespaces and containers but also for changes not specifically touching namespaces but which nevertheless will have impact on namespaces and containers. Add an entry for Eric (who agreed to this) and me and add a first batch of files that are relevant. Currently, only a small set of files are added and only such namespaces that haven't gotten a separate maintainers entry (e.g. time namespaces). I expect this to grow more entries and/or regular expressions over time. For now these entries here are sufficient. I intend to route this patch upstream soon. Cc: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com> --- MAINTAINERS | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index f0068bceeb61..272211cdc327 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -11892,6 +11892,26 @@ S: Supported W: https://www.cspi.com/ethernet-products/support/downloads/ F: drivers/net/ethernet/myricom/myri10ge/ +NAMESPACES AND CONTAINERS +M: Christian Brauner <christian.brauner@ubuntu.com> +M: Eric W. Biederman <ebiederm@xmission.com> +L: containers.lists.linuxfoundation.org +S: Supported +T: https://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux.git/ +T: https://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git/ +F: ipc/namespace.c +F: kernel/nsproxy.c +F: kernel/pid_namespace.c +F: kernel/user_namespace.c +F: kernel/utsname.c +F: include/linux/nsproxy.h +F: include/linux/ipc_namespace.h +F: include/linux/ns_common.h +F: include/linux/nsproxy.h +F: include/linux/pid_namespace.h +F: include/linux/user_namespace.h +F: include/linux/utsname.h + NAND FLASH SUBSYSTEM M: Miquel Raynal <miquel.raynal@bootlin.com> R: Richard Weinberger <richard@nod.at> base-commit: d012a7190fc1fd72ed48911e77ca97ba4521bccd -- 2.28.0 ^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH] MAINTAINERS: add namespace entry 2020-08-25 15:41 [PATCH] MAINTAINERS: add namespace entry Christian Brauner @ 2020-08-25 16:01 ` Joe Perches 2020-08-25 16:06 ` Christian Brauner 2020-08-25 16:26 ` Eric W. Biederman 1 sibling, 1 reply; 7+ messages in thread From: Joe Perches @ 2020-08-25 16:01 UTC (permalink / raw) To: Christian Brauner, linux-kernel Cc: Mauro Carvalho Chehab, Rob Herring, David S. Miller, Eric W. Biederman On Tue, 2020-08-25 at 17:41 +0200, Christian Brauner wrote: > Namespace maintainership has never been formalized which has led to confusion > when people need to determine where to send patches and who should take a look > at them. Especially, since we have a dedicated list > containers.lists.linuxfoundation.org already for a long time. In preparation of > this patch I added the containers.lists.linuxfoundation.org mailing list to be > archived on lore. > > This will not just make it easier to catch and review patches specific to > namespaces and containers but also for changes not specifically touching > namespaces but which nevertheless will have impact on namespaces and > containers. > > Add an entry for Eric (who agreed to this) and me and add a first batch of > files that are relevant. Currently, only a small set of files are added and > only such namespaces that haven't gotten a separate maintainers entry (e.g. > time namespaces). I expect this to grow more entries and/or regular expressions > over time. For now these entries here are sufficient. I intend to route this > patch upstream soon. > > Cc: "Eric W. Biederman" <ebiederm@xmission.com> > Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com> > --- > MAINTAINERS | 20 ++++++++++++++++++++ > 1 file changed, 20 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index f0068bceeb61..272211cdc327 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -11892,6 +11892,26 @@ S: Supported > W: https://www.cspi.com/ethernet-products/support/downloads/ > F: drivers/net/ethernet/myricom/myri10ge/ > > +NAMESPACES AND CONTAINERS > +M: Christian Brauner <christian.brauner@ubuntu.com> > +M: Eric W. Biederman <ebiederm@xmission.com> > +L: containers.lists.linuxfoundation.org > +S: Supported > +T: https://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux.git/ > +T: https://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git/ > +F: ipc/namespace.c > +F: kernel/nsproxy.c > +F: kernel/pid_namespace.c > +F: kernel/user_namespace.c > +F: kernel/utsname.c > +F: include/linux/nsproxy.h > +F: include/linux/ipc_namespace.h > +F: include/linux/ns_common.h > +F: include/linux/nsproxy.h > +F: include/linux/pid_namespace.h > +F: include/linux/user_namespace.h > +F: include/linux/utsname.h Please sort the filename order alphabetically. F: include/linux/ipc_namespace.h F: include/linux/ns_common.h F: include/linux/nsproxy.h F: include/linux/nsproxy.h F: include/linux/pid_namespace.h F: include/linux/user_namespace.h F: include/linux/utsname.h F: ipc/namespace.c F: kernel/nsproxy.c F: kernel/pid_namespace.c F: kernel/user_namespace.c F: kernel/utsname.c ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] MAINTAINERS: add namespace entry 2020-08-25 16:01 ` Joe Perches @ 2020-08-25 16:06 ` Christian Brauner 0 siblings, 0 replies; 7+ messages in thread From: Christian Brauner @ 2020-08-25 16:06 UTC (permalink / raw) To: Joe Perches Cc: linux-kernel, Mauro Carvalho Chehab, Rob Herring, David S. Miller, Eric W. Biederman On Tue, Aug 25, 2020 at 09:01:01AM -0700, Joe Perches wrote: > On Tue, 2020-08-25 at 17:41 +0200, Christian Brauner wrote: > > Namespace maintainership has never been formalized which has led to confusion > > when people need to determine where to send patches and who should take a look > > at them. Especially, since we have a dedicated list > > containers.lists.linuxfoundation.org already for a long time. In preparation of > > this patch I added the containers.lists.linuxfoundation.org mailing list to be > > archived on lore. > > > > This will not just make it easier to catch and review patches specific to > > namespaces and containers but also for changes not specifically touching > > namespaces but which nevertheless will have impact on namespaces and > > containers. > > > > Add an entry for Eric (who agreed to this) and me and add a first batch of > > files that are relevant. Currently, only a small set of files are added and > > only such namespaces that haven't gotten a separate maintainers entry (e.g. > > time namespaces). I expect this to grow more entries and/or regular expressions > > over time. For now these entries here are sufficient. I intend to route this > > patch upstream soon. > > > > Cc: "Eric W. Biederman" <ebiederm@xmission.com> > > Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com> > > --- > > MAINTAINERS | 20 ++++++++++++++++++++ > > 1 file changed, 20 insertions(+) > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index f0068bceeb61..272211cdc327 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -11892,6 +11892,26 @@ S: Supported > > W: https://www.cspi.com/ethernet-products/support/downloads/ > > F: drivers/net/ethernet/myricom/myri10ge/ > > > > +NAMESPACES AND CONTAINERS > > +M: Christian Brauner <christian.brauner@ubuntu.com> > > +M: Eric W. Biederman <ebiederm@xmission.com> > > +L: containers.lists.linuxfoundation.org > > +S: Supported > > +T: https://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux.git/ > > +T: https://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git/ > > +F: ipc/namespace.c > > +F: kernel/nsproxy.c > > +F: kernel/pid_namespace.c > > +F: kernel/user_namespace.c > > +F: kernel/utsname.c > > +F: include/linux/nsproxy.h > > +F: include/linux/ipc_namespace.h > > +F: include/linux/ns_common.h > > +F: include/linux/nsproxy.h > > +F: include/linux/pid_namespace.h > > +F: include/linux/user_namespace.h > > +F: include/linux/utsname.h > > Please sort the filename order alphabetically. > > F: include/linux/ipc_namespace.h > F: include/linux/ns_common.h > F: include/linux/nsproxy.h > F: include/linux/nsproxy.h > F: include/linux/pid_namespace.h > F: include/linux/user_namespace.h > F: include/linux/utsname.h > F: ipc/namespace.c > F: kernel/nsproxy.c > F: kernel/pid_namespace.c > F: kernel/user_namespace.c > F: kernel/utsname.c Thanks, fixing now. Christian ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] MAINTAINERS: add namespace entry 2020-08-25 15:41 [PATCH] MAINTAINERS: add namespace entry Christian Brauner 2020-08-25 16:01 ` Joe Perches @ 2020-08-25 16:26 ` Eric W. Biederman 2020-08-25 16:40 ` Christian Brauner ` (2 more replies) 1 sibling, 3 replies; 7+ messages in thread From: Eric W. Biederman @ 2020-08-25 16:26 UTC (permalink / raw) To: Christian Brauner Cc: linux-kernel, Mauro Carvalho Chehab, Rob Herring, David S. Miller, Linux Containers A) If we are going to have this discussion in public we really should include the containers list. B) The challenge is that most of the namespace work has become part of it's upstream subsystem so we really need to list the containers list and ourselves as reviewers, more than maintainers who run a tree for the code. 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. The files you have listed are reasonable for a maintainers entry as they have no other maintainers. I know I have been less active after the birth of my young son, and I know the practical rule is that the person who does the work is the maintainer. 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. Eric Christian Brauner <christian.brauner@ubuntu.com> writes: > Namespace maintainership has never been formalized which has led to confusion > when people need to determine where to send patches and who should take a look > at them. Especially, since we have a dedicated list > containers.lists.linuxfoundation.org already for a long time. In preparation of > this patch I added the containers.lists.linuxfoundation.org mailing list to be > archived on lore. > > This will not just make it easier to catch and review patches specific to > namespaces and containers but also for changes not specifically touching > namespaces but which nevertheless will have impact on namespaces and > containers. > > Add an entry for Eric (who agreed to this) and me and add a first batch of > files that are relevant. Currently, only a small set of files are added and > only such namespaces that haven't gotten a separate maintainers entry (e.g. > time namespaces). I expect this to grow more entries and/or regular expressions > over time. For now these entries here are sufficient. I intend to route this > patch upstream soon. > > Cc: "Eric W. Biederman" <ebiederm@xmission.com> > Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com> > --- > MAINTAINERS | 20 ++++++++++++++++++++ > 1 file changed, 20 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index f0068bceeb61..272211cdc327 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -11892,6 +11892,26 @@ S: Supported > W: https://www.cspi.com/ethernet-products/support/downloads/ > F: drivers/net/ethernet/myricom/myri10ge/ > > +NAMESPACES AND CONTAINERS > +M: Christian Brauner <christian.brauner@ubuntu.com> > +M: Eric W. Biederman <ebiederm@xmission.com> > +L: containers.lists.linuxfoundation.org > +S: Supported > +T: https://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux.git/ > +T: https://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git/ > +F: ipc/namespace.c > +F: kernel/nsproxy.c > +F: kernel/pid_namespace.c > +F: kernel/user_namespace.c > +F: kernel/utsname.c > +F: include/linux/nsproxy.h > +F: include/linux/ipc_namespace.h > +F: include/linux/ns_common.h > +F: include/linux/nsproxy.h > +F: include/linux/pid_namespace.h > +F: include/linux/user_namespace.h > +F: include/linux/utsname.h > + > NAND FLASH SUBSYSTEM > M: Miquel Raynal <miquel.raynal@bootlin.com> > R: Richard Weinberger <richard@nod.at> > > base-commit: d012a7190fc1fd72ed48911e77ca97ba4521bccd ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] MAINTAINERS: add namespace entry 2020-08-25 16:26 ` Eric W. Biederman @ 2020-08-25 16:40 ` Christian Brauner 2020-08-25 18:27 ` Kees Cook 2020-08-26 7:26 ` Aleksa Sarai 2 siblings, 0 replies; 7+ messages in thread From: Christian Brauner @ 2020-08-25 16:40 UTC (permalink / raw) To: Eric W. Biederman Cc: linux-kernel, Mauro Carvalho Chehab, Rob Herring, David S. Miller, Linux Containers On Tue, Aug 25, 2020 at 11:26:07AM -0500, Eric W. Biederman wrote: > > A) If we are going to have this discussion in public we really should > include the containers list. Ah, just used the output from get_maintainers.pl. > > B) The challenge is that most of the namespace work has become part of > it's upstream subsystem so we really need to list the containers > list and ourselves as reviewers, more than maintainers who run > a tree for the code. > > 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. > > The files you have listed are reasonable for a maintainers entry as they > have no other maintainers. > > I know I have been less active after the birth of my young son, and I > know the practical rule is that the person who does the work is the > maintainer. 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. Ok, Eric. I've tried to do this with the best intentions possible and I would assume that this is the default assumption everyone would have after all these years. This type of response is very shocking to me and I honestly don't know how to respond! I'm dropping this completely because I'm not going to be accused of having a hidden agenda! Such an accusation is imho completely out of line and it is completely unacceptable to treat a peer like this! Christian ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] MAINTAINERS: add namespace entry 2020-08-25 16:26 ` Eric W. Biederman 2020-08-25 16:40 ` Christian Brauner @ 2020-08-25 18:27 ` Kees Cook 2020-08-26 7:26 ` Aleksa Sarai 2 siblings, 0 replies; 7+ messages in thread From: Kees Cook @ 2020-08-25 18:27 UTC (permalink / raw) To: Eric W. Biederman Cc: Christian Brauner, linux-kernel, Mauro Carvalho Chehab, Rob Herring, David S. Miller, Linux Containers On Tue, Aug 25, 2020 at 11:26:07AM -0500, Eric W. Biederman wrote: > B) The challenge is that most of the namespace work has become part of > it's upstream subsystem so we really need to list the containers > list and ourselves as reviewers, more than maintainers who run > a tree for the code. As a person who has to touch multiple subsystems regularly while doing treewide changes, I'm WAY happier to have a distinct set of maintainers for specific files, and I can track the patch acceptance because I see them appearing in a specific tree (via -next, etc). > 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. Eh? I don't see a conspiracy here; I think you are, as you suggest above, completely wrong. ;) I haven't seen the private emails, obviously, but what I see here is just Christian's drive to get things nailed down. It sounds like the "here's who to CC" part of the MAINTAINERS file was agreed to, but there was a misunderstanding about the resolution of group maintainership? > The files you have listed are reasonable for a maintainers entry as they > have no other maintainers. Agreed; if this was in place a few years ago, it might have been a bit easier to direct and land some of the (now straggling) refcount_t conversion patches. > I know I have been less active after the birth of my young son, and I > know the practical rule is that the person who does the work is the > maintainer. 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. O_O I find this opinion very surprising. I hold Christian's judgement in high regard (and yours). He's tackled the pidfd API (which solves so many ancient gnarly problems with pid management) in a clean, measured, and consistent manner. He and Aleksa have diligently worked on extensible syscalls, which solve years of headaches over code maintainability, and Christian regularly adds kernel selftests. I think he's absolutely got the best interests of other developers (and users) in mind. Certainly none of us are perfect, but your statement feels way way off base to me. > 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. I think you both want the same thing (generally awesome Linux, specifically sane and safe namespaces), and I think you're both deeply involved in the namespace code and the use-cases, so it seems natural to me that you'd have some form of shared maintainership. To that end, I hope this can get sorted out. I'd like to have a tree I can count on to have patches reviewed (and hopefully landed) that touch these areas. To me, it seems like there has just been an impedance mismatch on the expectations/priorities of communication speed. I don't see bad motivations here at all. > > [...] > > +T: https://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux.git/ > > +T: https://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git/ Obviously y'all still need to finish this discussion, I but I'd expect a single tree at the end of the day. No other subsystem has multiple trees that I can find: $ git grep -A1 ^T: -- MAINTAINERS | grep -- -T: | wc -l 0 And please use the "git" format for T: so you can specify branches, which helps immensely in tracking down "latest" commits: T: git git://URL/TREE.git BRANCH No other trees use a bare https schema: $ git grep ^T: -- MAINTAINERS | grep "git " | wc -l 632 $ git grep ^T: -- MAINTAINERS | grep -v "git " MAINTAINERS:T: quilt http://people.redhat.com/agk/patches/linux/editing/ MAINTAINERS:T: quilt http://jdelvare.nerim.net/devel/linux/jdelvare-dmi/ MAINTAINERS:T: hg http://tboot.hg.sourceforge.net:8000/hgroot/tboot/tboot MAINTAINERS:T: quilt https://ozlabs.org/~akpm/mmotm/ MAINTAINERS:T: quilt https://ozlabs.org/~akpm/mmots/ MAINTAINERS:T: git://git.infradead.org/nvme.git MAINTAINERS:T: git://git.infradead.org/nvme.git -- Kees Cook ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] MAINTAINERS: add namespace entry 2020-08-25 16:26 ` Eric W. Biederman 2020-08-25 16:40 ` Christian Brauner 2020-08-25 18:27 ` Kees Cook @ 2020-08-26 7:26 ` Aleksa Sarai 2 siblings, 0 replies; 7+ messages in thread From: Aleksa Sarai @ 2020-08-26 7:26 UTC (permalink / raw) To: Eric W. Biederman Cc: Christian Brauner, Mauro Carvalho Chehab, Rob Herring, Linux Containers, linux-kernel, David S. Miller [-- Attachment #1: Type: text/plain, Size: 3352 bytes --] On 2020-08-25, Eric W. Biederman <ebiederm@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/> [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 228 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2020-08-26 7:26 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-08-25 15:41 [PATCH] MAINTAINERS: add namespace entry Christian Brauner 2020-08-25 16:01 ` Joe Perches 2020-08-25 16:06 ` Christian Brauner 2020-08-25 16:26 ` Eric W. Biederman 2020-08-25 16:40 ` Christian Brauner 2020-08-25 18:27 ` Kees Cook 2020-08-26 7:26 ` Aleksa Sarai
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).