Bug#780797: Package modifying a user-modified config file? [Bug #780797]
On 2015-03-23 01:19:17 +0100, Christoph Anton Mitterer wrote: Again, I don't see that Vincent wrote that this is a complete showstopper for him... even his bug title was about the modification of the config file, not about the new value itself. The new value is a problem too, but I can modify the file in new installations of my machines. For the other machines where I have a shell account, I would have to ask the admin to add some AcceptEnv variables (and this is not a hole with a full shell account and this is what upstream suggests to do) so that I have a way to pass information to the other side. -- Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#780797: Package modifying a user-modified config file? [Bug #780797]
On Sun, 2015-03-22 at 20:35 +, Colin Watson wrote: Anyway, I would appreciate it if people could refrain from filling my mailbox further about this bug. :-) One last thing perhaps. O:-) Colin: my apologies for adding work [especially so if any of the work added is unnecessary]. I'm sure you meant well; I do too. On 03/22/2015 06:18 PM, Christoph Anton Mitterer wrote: [...] I haven't had time to deal with it over the last couple of days (Debian developer in having a social life shocker!), but in brief I intend to revert the offending change in its entirety as it's clearly causing far more trouble than it can possibly be worth. I'll post further rationale when I get half a chance. Well I don't really care that much, as said my intention was just to improve defaults for others. But to be honest, and without intending to offend any of the others,... it kinda seems to me that people make a mountain out of a molehill. Christoph: there may be a lack of empathy in your response statements. Please try to put yourself in the user's shoes -- the issue looks very different from that perspective. [I'm likewise considering this from the maintainer perspective.] The change is really little, for well grounded security reasons it's actually intended by upstream that non env vars are send/accepted unless explicitly allowed by the admin. So people who complain now likely just abused that hole in Debian's default all the years, which is however no grant for a right to do so forever. Again: at least for me, it's not about /this/ particular change, it's about changes happening to user-modified configs on upgrades without dpkg prompting. sshd_config is literally /the/ most important config file on systems for me, and therefore it's also the file that's most sensitive. [ssh_config similarly.] In terms of the /particular/ changes made to ssh_config and sshd_config in this case, I made the assumption that it was for good reasons and with good intentions so that's why I didn't object to that. But... at the same time I keep in mind that the road to hell is paved with good intentions. (Which could also include me strongly objecting.) It feels a bit like the systemd debate where a loud minority started an outcry about things which in reality probably didn't even affect them. Since you mention it, I'll just say that the systemd debate is another place marked by arguments that often lack empathy and understanding of the the other person's perspective. -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#780797: Package modifying a user-modified config file? [Bug #780797]
I didn't read much of this thread at it occurred; am catching up now. It is absolutely and unquestionably essential that no file in /etc which has *any* local modifications ever be edited on package upgrade w/o the admin's consent. Adding users and groups on install is one thing, editing a locally edited config file during a package upgrade w/o asking for permission, OTOH, is UNacceptable. The normal dialog, with the options for seeing the diff, accepting the maintainers' version, keeping the local version or starting a shell manually to handle it, works fine. The openssh package should use that just like everything else. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 0x997A9F17ED7DAEA6 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#780797: Package modifying a user-modified config file? [Bug #780797]
On Sun, Mar 22, 2015 at 04:01:30PM -0400, James Cloos wrote: I didn't read much of this thread at it occurred; am catching up now. It is absolutely and unquestionably essential that no file in /etc which has *any* local modifications ever be edited on package upgrade w/o the admin's consent. Adding users and groups on install is one thing, editing a locally edited config file during a package upgrade w/o asking for permission, OTOH, is UNacceptable. This is naïve in the context of sshd_config, I'm afraid. (For details, see the postinst, and it's worth noting that most of the necessary upgrade fixes applied there have been non-events and haven't attracted this sort of well-meaning commentary.) The normal dialog, with the options for seeing the diff, accepting the maintainers' version, keeping the local version or starting a shell manually to handle it, works fine. The openssh package should use that just like everything else. Firstly, everything else is a gross exaggeration. Many configuration files certainly are dpkg-managed conffiles, but many are not. dpkg implements a simple baseline algorithm for managing configuration files which is appropriate for a subset of them. Secondly: that would perhaps be nice, but we can't get there from here. Due to what I view as historical errors, sshd_config doesn't really have a single canonical state on all upgraded systems. If it had been a dpkg-managed conffile from the start then that would have been much better, but as it is we have to make do with what we have. Although I would point out that if sshd_config had been dpkg-managed then there would have been multiple grave bugs in the past about sshd failing to start on upgrade due to people failing to notice the changes they had to merge, so, you know, we kind of have to consider practicalities as well as ideals here. Anyway, I would appreciate it if people could refrain from filling my mailbox further about this bug. :-) I haven't had time to deal with it over the last couple of days (Debian developer in having a social life shocker!), but in brief I intend to revert the offending change in its entirety as it's clearly causing far more trouble than it can possibly be worth. I'll post further rationale when I get half a chance. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#780797: Package modifying a user-modified config file? [Bug #780797]
On Sun, 2015-03-22 at 19:20 -0400, Chris Knadle wrote: Christoph: there may be a lack of empathy in your response statements. Please try to put yourself in the user's shoes -- the issue looks very different from that perspective. [I'm likewise considering this from the maintainer perspective.] Again, I don't see that Vincent wrote that this is a complete showstopper for him... even his bug title was about the modification of the config file, not about the new value itself. And you understand me wrong, if you think I'd have no empathy: There should be no reason for Vincent (or others) to get caught by that change by surprise, which I fully agree, but apart from that this is really such a small change that can be corrected in minutes. What would happen at other packages like apache when they go from 2.2 to 2.4 and config doesn't just work anymore? Or when the maintainer of gitolite finally gives up upon 2.x and replaces the gitolite with the gitolite3 package? These things require considerable work by the admin,... are people then going to start a war because something changes? What about OpenSSH, when they finally drop/disable unsafe alogs? I'm not discussing for that particular AcceptEnv/SendEnv issue so enthusiastically because I think it is so important by itself - but rather as this could be taken as precedent for other changes (like dropping unsafe algos) in the future. Best wishes, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#780797: Package modifying a user-modified config file? [Bug #780797]
On Sun, 2015-03-22 at 20:35 +, Colin Watson wrote: Anyway, I would appreciate it if people could refrain from filling my mailbox further about this bug. :-) One last thing perhaps. O:-) Due to what I view as historical errors, sshd_config doesn't really have a single canonical state on all upgraded systems. If it had been a dpkg-managed conffile from the start then that would have been much better, but as it is we have to make do with what we have. Well maybe it's time to make a clear cut: - declare all previous configs no longer handled by future upgrades in stretch - create fresh default config, which also got rid of all other questionable Debian modifications - make it dpkg managed That could also greatly simplify the maintainer scripts. Although I would point out that if sshd_config had been dpkg-managed then there would have been multiple grave bugs in the past about sshd failing to start on upgrade due to people failing to notice the changes they had to merge, so, you know, we kind of have to consider practicalities as well as ideals here. Well if people don't read their NEWS.Debian files and their release notes it's simply their fault. You cannot just protect them from everything, and you make your own life as maintainer much harder... and others who do their admin homework kinda suffer as well. I haven't had time to deal with it over the last couple of days (Debian developer in having a social life shocker!), but in brief I intend to revert the offending change in its entirety as it's clearly causing far more trouble than it can possibly be worth. I'll post further rationale when I get half a chance. Well I don't really care that much, as said my intention was just to improve defaults for others. But to be honest, and without intending to offend any of the others,... it kinda seems to me that people make a mountain out of a molehill. The change is really little, for well grounded security reasons it's actually intended by upstream that non env vars are send/accepted unless explicitly allowed by the admin. So people who complain now likely just abused that hole in Debian's default all the years, which is however no grant for a right to do so forever. It feels a bit like the systemd debate where a loud minority started an outcry about things which in reality probably didn't even affect them. Bye, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#780797: Package modifying a user-modified config file? [Bug #780797]
On Sun, Mar 22, 2015 at 11:18:03PM +0100, Christoph Anton Mitterer wrote: On Sun, 2015-03-22 at 20:35 +, Colin Watson wrote: Due to what I view as historical errors, sshd_config doesn't really have a single canonical state on all upgraded systems. If it had been a dpkg-managed conffile from the start then that would have been much better, but as it is we have to make do with what we have. Well maybe it's time to make a clear cut: - declare all previous configs no longer handled by future upgrades in stretch - create fresh default config, which also got rid of all other questionable Debian modifications - make it dpkg managed That could also greatly simplify the maintainer scripts. I'm afraid I'm not interested in the very considerable amount of work required to get there well. Well if people don't read their NEWS.Debian files and their release notes it's simply their fault. You cannot just protect them from everything, and you make your own life as maintainer much harder... and others who do their admin homework kinda suffer as well. You are entitled to your opinion, but I respectfully disagree. But to be honest, and without intending to offend any of the others,... it kinda seems to me that people make a mountain out of a molehill. The change is really little, for well grounded security reasons it's actually intended by upstream that non env vars are send/accepted unless explicitly allowed by the admin. So people who complain now likely just abused that hole in Debian's default all the years, which is however no grant for a right to do so forever. I disagree with you that this is a problem worth fixing. If you consider this a hole, well, I'll just have to live with that. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#780797: Package modifying a user-modified config file? [Bug #780797]
On Sun, Mar 22, 2015 at 07:20:06PM -0400, Chris Knadle wrote: On 03/22/2015 06:18 PM, Christoph Anton Mitterer wrote: Well I don't really care that much, as said my intention was just to improve defaults for others. But to be honest, and without intending to offend any of the others,... it kinda seems to me that people make a mountain out of a molehill. Christoph: there may be a lack of empathy in your response statements. Please try to put yourself in the user's shoes -- the issue looks very different from that perspective. I entirely agree. Vincent is clearly a real person affected by this change (I've seen things from them before where they were doing interesting things with character map handling; they didn't just suddenly pop up with a convenient fiction here!). Describing them as part of a loud minority with an issue that in reality probably didn't even affect them seems like an entirely unnecessary personal attack, and I'd like to disassociate myself from that kind of approach to users. [ssh_config similarly.] For the record, ssh_config is a dpkg-managed conffile - it doesn't have the historical complications of sshd_config - and is not subject to the problems being discussed here. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#780797: Package modifying a user-modified config file? [Bug #780797]
Chris Knadle chris.kna...@coredump.us writes: At present the openssh-server and openssh-client packages are altering /etc/ssh/ssh_config and /etc/ssh/sshd_config without prompting the user beforehand, even when they've been locally modified. I've pointed section § 10.7.3 of Debian Policy: • local changes must be preserved during a package upgrade (Appendix E also discusses this which I saw later) however the argument being made now is that the particular section of the config being altered wasn't changed by the user. Correct. The Policy statement is about preserving user changes, not about never touching any file that a user has modified in any way. The package is free to modify unchanged portions of the configuration file, and this has been routinely done during package updates in Debian for as long as I've been involved in the project. This is the current bug (severity serious): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780797 I think the maintainer should downgrade the severity of this bug, since I don't think it meets the definition of serious, but I'll leave that to Colin. Separately, I personally am not fond of this change and would rather that it only take effect on new installations, not existing installations. I find the security argument for this change to be rather dubious. But this is not a Policy violation; it's a judgement call by the maintainer whether the benefit of the change is worth the disruption of changed behavior on upgrades. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#780797: Package modifying a user-modified config file? [Bug #780797]
On 2015-03-21 13:14:08 -0700, Russ Allbery wrote: Chris Knadle chris.kna...@coredump.us writes: At present the openssh-server and openssh-client packages are altering /etc/ssh/ssh_config and /etc/ssh/sshd_config without prompting the user beforehand, even when they've been locally modified. I've pointed section § 10.7.3 of Debian Policy: • local changes must be preserved during a package upgrade (Appendix E also discusses this which I saw later) however the argument being made now is that the particular section of the config being altered wasn't changed by the user. Correct. The Policy statement is about preserving user changes, not about never touching any file that a user has modified in any way. The package is free to modify unchanged portions of the configuration file, and this has been routinely done during package updates in Debian for as long as I've been involved in the project. I disagree. In such a case there would be *no way* for the user to tell Debian not to modify his configuration, i.e. an upgrade could silently break the user configuration, like this happened here. The only time where a maintainer script could change a config file modified by the user is when this is absolutely necessary, e.g. because the behavior changed in the software, an option has been renamed, and things like that. But even in these cases, this should be announced in the NEWS file. -- Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#780797: Package modifying a user-modified config file? [Bug #780797]
Vincent Lefevre vinc...@vinc17.net writes: On 2015-03-21 13:14:08 -0700, Russ Allbery wrote: Correct. The Policy statement is about preserving user changes, not about never touching any file that a user has modified in any way. The package is free to modify unchanged portions of the configuration file, and this has been routinely done during package updates in Debian for as long as I've been involved in the project. I disagree. You disagree that this is what Policy says, or you disagree that this is a good idea? If it's the latter, I understand your point. If it's the former, well, you can disagree, but you're incorrect. Sorry. You have probably been misled by dpkg's behavior with conffiles, but that's primiarly because dpkg conffile handling is at the per-file level, and only knows whether the file has changed at all. This is not how configuration files that are not conffiles have been handled, and it applies only at the file granularity with conffiles. Consider a configuration that's broken into four or five separate conffiles. The ones that the user didn't change have always been updated silently. The Policy statement here is primarily about semantics, not about files. In such a case there would be *no way* for the user to tell Debian not to modify his configuration, i.e. an upgrade could silently break the user configuration, like this happened here. Policy does not prohibit every thing that a maintainer might want to do that may not be a good idea. I get that you find the change surprising. I don't particularly agree with it either. But Policy is not the stick with which to solve every problem you might have with what a package maintainer chooses to do. Sometimes things are just old-fashioned bug reports. :) The only time where a maintainer script could change a config file modified by the user is when this is absolutely necessary, e.g. because the behavior changed in the software, an option has been renamed, and things like that. That's certainly a valid point of view, but this is not the line that Debian has historically drawn. And drawing that line would result in a lot more prompting during dist-upgrades, so there's a tradeoff here. But even in these cases, this should be announced in the NEWS file. I'm inclined to agree with you in this case, but Policy doesn't currently make that a requirement. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
