Re: CVS commit: src
On Dec 20, 9:44pm, Maxime Villard wrote: } Le 20/12/2019 à 20:52, Martin Husemann a écrit : } > On Fri, Dec 20, 2019 at 07:54:36PM +0100, Maxime Villard wrote: } >> Alright, fair enough. I will revert my removal over the week-end, because it } >> hasn't received sufficient public discussion. } > } > Thank you! } > } >> As well, I will revert secteam's } >> killing of the feature, because there has been no public discussion on that at } >> all. } > } > Please do not. You *do* have a point here, but: } > } > 1) public discussion upfront for a security issue is not always possible, } > as you are well aware } } I'm afraid that's no excuse, in that several of the security issues in the } past have had to be discussed publicly. (On your own personal insistence, } by the way, and I see no reason why the policy would change all of a } sudden just because you personally decided otherwise.) } } > 2) there has been a public security advisory which assumes this change } > and would need to be revised in case of reversal } } This only means secteam doubled down in being wrong. } } Specifically, it seems to me that removing /dev/filemon would have been } sufficient, instead of removing the kmod. People could re-create } /dev/filemon with minimal effort, should they be interested in the feature. } As opposed to that, rebuilding a kmod is a much bigger effort. I don't wish to get embroiled in this debate (even if I did start it by requesting the reversion). I just want to point out that there is a relatively simple way disable the autoloading of a module. From module(9): The directory from which the module is loaded will be searched for a file with the same name as the module file, but with the suffix ``.plist''. If this file is found, the prop_dictionary it contains will be loaded and passed to the module's modcmd() routine. If this prop_dictionary contains a ``noautoload'' property which is set to ``true'' then the system will refuse to load the module. The simplest way to do the above is: modload -p -b noautoload=true > .plist }-- End of excerpt from Maxime Villard
Re: CVS commit: src
Security-team is not perfect. We're happy to discuss a better way to disable filemon provisionally, and/or how to better address the existing users if we are to delete it -- after you do as core asked you to do to resolve the interim dispute by restoring the tree. This is a social process. We can work together to make it better for everyone, but you have to be willing to work with the community, including accepting rulings by core to resolve disputes. Constantly against the community hurts everyone, including you because it brews resentment against the good work you do and makes that work harder to get through. It's especially harmful when much of the developer community likely agrees with you on technical grounds -- you seem to be stepping on toes and lashing out for no reason.
Re: CVS commit: src
Le 20/12/2019 à 20:52, Martin Husemann a écrit : On Fri, Dec 20, 2019 at 07:54:36PM +0100, Maxime Villard wrote: Alright, fair enough. I will revert my removal over the week-end, because it hasn't received sufficient public discussion. Thank you! As well, I will revert secteam's killing of the feature, because there has been no public discussion on that at all. Please do not. You *do* have a point here, but: 1) public discussion upfront for a security issue is not always possible, as you are well aware I'm afraid that's no excuse, in that several of the security issues in the past have had to be discussed publicly. (On your own personal insistence, by the way, and I see no reason why the policy would change all of a sudden just because you personally decided otherwise.) 2) there has been a public security advisory which assumes this change and would need to be revised in case of reversal This only means secteam doubled down in being wrong. Specifically, it seems to me that removing /dev/filemon would have been sufficient, instead of removing the kmod. People could re-create /dev/filemon with minimal effort, should they be interested in the feature. As opposed to that, rebuilding a kmod is a much bigger effort. So, in addition to the fact that the disabling of filemon hasn't been discussed at all, it seems to me it was disabled the wrong way. If you're serious one minute about doing things correctly with consensus, secteam's commit should be reverted immediately, especially considering that secteam's solution seems to be technically the least preferable, since we apparently care about the users of filemon. Obviously, if we were even more serious here, we would all understand that in the end filemon should be removed completely and that secteam's only mistake was to do only half the job. But you prefer to go the procedural bullshit way, so let's go down that path together. Regarding the SA, local DoSes are not considered security issues, yet for some reason the advisory mentions that as a security problem; the real problem with the races here is undefined behavior, which can separately lead to memory disclosures and privilege escalations, both being real security issues. Notice also the gross typo in the title; it's "escalation", people, not "escallation". Maxime
Re: CVS commit: src
On Fri, Dec 20, 2019 at 07:54:36PM +0100, Maxime Villard wrote: > Alright, fair enough. I will revert my removal over the week-end, because it > hasn't received sufficient public discussion. Thank you! > As well, I will revert secteam's > killing of the feature, because there has been no public discussion on that at > all. Please do not. You *do* have a point here, but: 1) public discussion upfront for a security issue is not always possible, as you are well aware 2) there has been a public security advisory which assumes this change and would need to be revised in case of reversal 3) formally backing out other developers changes requires core approval Thanks! Martin
Re: CVS commit: src
Le 19/12/2019 à 17:57, Taylor R Campbell a écrit : Date: Thu, 19 Dec 2019 08:19:07 +0100 From: Maxime Villard I think you meant to say "REMOVING things you don't like". Correct, I made an editing error. Sorry for the confusion. In the meantime, I have absolutely no intent to reinstate filemon. You can reinstate it if you want, but it should come as no surprise to you in the near future that filemon, after whatever "necessary" discussion or different forms of bureaucratic idiocy you want to throw at it, will be deleted almost as fast as it came back from the attic. Especially considering the emails sent from the other people since I proceeded. This is not negotiable. It is core's position that the filemon removal should be undone for the time being, so please go ahead and undo it. Thanks, -Riastradh, on behalf of core Alright, fair enough. I will revert my removal over the week-end, because it hasn't received sufficient public discussion. As well, I will revert secteam's killing of the feature, because there has been no public discussion on that at all. Maxime
Re: CVS commit: src/share/mk
On Thu, Dec 19, 2019 at 11:04:25PM -0500, Christos Zoulas wrote: > Module Name: src > Committed By:christos > Date:Fri Dec 20 04:04:25 UTC 2019 > > Modified Files: > src/share/mk: bsd.sys.mk sys.mk > > Log Message: > move MV to sys.mk because it is used there. Pointed out by joerg@ Since the original change was apparently in January, does this need to be in -9? -- David A. Holland dholl...@netbsd.org
