On Wed, Dec 14, 2016 at 01:32:14AM +0100, Christoph Anton Mitterer wrote: > I've just stumbled (after much searching, since there seems to be no > changelog entry o.O) over commit 18a9bd1867ee6fb9d913515773b322a279759b5d.
That very commit includes a changelog entry. o.O, as you eloquently say. > Since I was quite sure that I didn't set prohibit-password and since don't use > the default config file shipped/generated by the package, I was pretty > concerned > at first that there might have been some intrusion. > So second, why is that change done silently/automagically at all? > Doesn't policy 10.7.3 "local changes must be preserved during a package > upgrade" > imply that this is forbidden? > And shouldn't one at least get some interaction or sshd_config.dpkg-new or > similar > hint that you mangled around with the config? I don't accept that policy forbids this change. The semantics are identical as far as sshd is concerned, it's not generally overwriting a local change, and in most cases it's in fact just updating a previous change that was made with debconf involvement. > In this case the change is not serious, of course, since the two mean the > same, but > it still has an effect, e.g. when the ssh config is checked with rkhunter and > that > in turn configured with ALLOW_SSH_ROOT_USER=without-password . I didn't know about that, admittedly, but that's the sort of problem that tools such as rkhunter are always going to have when parsing other packages' configuration files. After all, "without-password" was the default value for a while, so even just standard dpkg conffile handling with no local modifications would have exhibited the same behaviour. > There's another case where you, AFAICT, silently mangle around with the config > that may be user modified: Policy does *not* say that it is not permissible to modify a user-modified configuration file. It says that packages must preserve user changes. It does not specifically concern itself with whether those changes are at the file level or more fine-grained than that. This may seem like nitpicking but it's an important distinction. > if dpkg --compare-versions "$2" lt-nl 1:6.6p1-1 && \ > [ "$(get_config_option PermitRootLogin)" = yes ] && > db_get openssh-server/permit-root-login && [ "$RET" = true ]; then > set_config_option PermitRootLogin prohibit-password > fi > > Obviously this is in a way a good change, as it makes things more secure, but > AFAIU it's also applied on every config, whether the user made modifications > or not... and there doesn't seem to be a corresponding entry in NEWS.Debian. No, it's not applied on every config. openssh-server/permit-root-login defaults to false with a high-priority debconf question on upgrade from pre-1:6.6p1-1 unless no root password is set; and if no root password is set, then "PermitRootLogin prohibit-password" is effectively the same as the old default anyway. > Generally I'd say you never should make such auto-magical changes since there > may > be situations in which you just break things or even make them less secure, > and > this may not be directly visible. I'm afraid that in my experience it's simply not possible to maintain openssh with this absolutist philosophy. Upstream routinely (not necessarily frequently, but routinely) makes changes that cause old configuration files to be unparseable. If I didn't make the sort of "auto-magical changes" that upset you, I'd be underwater in RC bug reports because people's sshds would fail to start on upgrade. This is one of the essential tools in my arsenal for dealing with this kind of problem. > E.g. sshd_config may make use of Match blocks and only some of the directives > should be changed while others shouldn't where as you auto-magic cannot know > which. I would welcome constructive contributions to improve the processing, but I'm not going to change the fundamental approach. > But if you really feel you'd need to do such changes, properly document in > NEWS.Debian, even if it seems the change may be simple and just safe for > everyone. Some changes are suitable for documenting in NEWS.Debian, while others are suitable for documenting in the changelog - as I did. There is such a thing as swamping people with too much information. -- Colin Watson [cjwat...@debian.org]
