Your message dated Mon, 15 Dec 2014 20:50:05 -0500 (EST)
with message-id <alpine.DEB.2.10.1412151649070.15216@kubuntu>
and subject line Re: Bug#773237: dovecot-core: Potentially dangerous
modification of a configuration file
has caused the Debian Bug report #773237,
regarding dovecot-core: should not use ucf for 10-ssl.conf and modify the file
at the same time
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
773237: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773237
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: dovecot-core
Version: 1:2.2.13-11
Severity: serious
The postinst for this package has a line like this one:
echo \# old config >> /etc/dovecot/conf.d/10-ssl.conf
Please *don't* do that. It does not only violate the spirit of policy
(user changes should be preserved), it is also a recipe for disaster.
Suppose I had the old configuration file served by puppet. The upgrade
modifies the file, then puppet restores the file to its original state.
Then the next upgrade will change the file to the new ucf default,
which may be completely unsuitable for my system.
Quoting policy:
These two styles of configuration file handling must not be mixed, for
that way lies madness: `dpkg' will ask about overwriting the file
every time the package is upgraded.
I see that there is a default in ucf, but apparently the default for
wheezy may not be updated to the default in jessie without breaking
currently working systems.
I wonder, then, why ucf is used at all to manage the file.
More quotes from policy:
The easy way to achieve this behavior is to make the configuration
file a `conffile'. This is appropriate only if it is possible to
distribute a default version that will work for most installations,
although some system administrators may choose to modify it.
I understand that UCF falls in the "easy way" category. However, there
is not a default version that will work for most installations.
IMHO, it ucf is not suitable for 10-ssl.cnf, it follows that this
package should not use the ucf mechanism for such file. I wonder
what's the problem in copying the file from a default somewhere in
/usr/share/dovecot the very first time the package is installed and
not modify the file at all on upgrades.
I'm setting this to serious because I believe this package should not
reach testing in its current state, but feel free to disagree.
Thanks.
--- End Message ---
--- Begin Message ---
On Mon, 15 Dec 2014, Santiago Vila wrote:
The postinst for this package has a line like this one:
echo \# old config >> /etc/dovecot/conf.d/10-ssl.conf
Please *don't* do that. It does not only violate the spirit of policy
(user changes should be preserved), it is also a recipe for disaster.
The point of it was to preserve user changes.
Suppose I had the old configuration file served by puppet. The upgrade
modifies the file, then puppet restores the file to its original state.
Then the next upgrade will change the file to the new ucf default,
which may be completely unsuitable for my system.
Look at the surrounding lines. The upgrade modifies the file if and only
if its md5sum matches that of an _unmodified_ 10-ssl.conf from -6 or
earlier. If your puppet installation is serving the packages default
version of this file than the addition of a comment won't make any
difference. If it was modified you won't even get the comment. I fail to
see the potential danger here.
Quoting policy:
These two styles of configuration file handling must not be mixed, for
that way lies madness: `dpkg' will ask about overwriting the file
every time the package is upgraded.
No it won't because after -6 the file will be managed by ucf. It was only
for <= -6 that this was needed. And the reason is that ucf has no way of
saying "start diffing changes from this point." It will always assume
that the file was a blank slate and overwrite it with the default from the
first ucf-using version. Even if there were user changes.
I see that there is a default in ucf, but apparently the default for
wheezy may not be updated to the default in jessie without breaking
currently working systems.
The default configuration used to assume that SSL was on and there were
certificates in certain locations. We no longer generate the certificates
(that was another huge source of bugs) and therefore SSL is turned off by
default. If you are upgrading and already had a working SSL setup I think
you would be rather upset if we suddenly turned it off. However as ucf
would have no previous memory of this file it would blindly overwrite it
like I said.
I wonder, then, why ucf is used at all to manage the file.
ucf will do the right thing now. It was only the transition which
required special handling.
I understand that UCF falls in the "easy way" category. However, there
is not a default version that will work for most installations.
IMHO, it ucf is not suitable for 10-ssl.cnf, it follows that this
package should not use the ucf mechanism for such file. I wonder
what's the problem in copying the file from a default somewhere in
/usr/share/dovecot the very first time the package is installed and
not modify the file at all on upgrades.
If you have modified 10-ssl.conf then you will get a debconf dialog on
upgrades where you are given the opportunity to accept the new
version, keep the old version or merge differences just as if it is a
dpkg-managed conffile. If you haven't modified it, you will get the
packages version just as if it is a dpkg-managed conffile. I am sorry but
I fail to see your objection here.
On Mon, 15 Dec 2014, Santiago Vila wrote:
I forgot a minor detail: If the file is managed by puppet, there would
be nothing to worry about, right?
No, I don't think so:
1. I upgrade dovecot-core to the current version
2. postinst modifies the file
_IF_ it was the unmodified default from previous versions.
3. puppet restores the file and removes the added comment line
4. the next upgrade of dovecot-core upgrades to the ucf default
which does not work
5. puppet restores the file again
How do you deal with any conffile changes in puppet? (I know of it but I
haven't used it myself.) Presumably you periodically update it as
packages change no? This is one of those times.
The problem is the time window between 4 and 5 in which dovecot will
not work at all.
To reiterate. If you haven't made any changes to the default, the
addition of this line will not make any difference.
Note: I have a linode running wheezy and I want to upgrade it to jessie.
For now I'm running upgrade simulations using qemu and I am naturally
keeping an eye on the upgrade problem that this package had, but even
if it has been reported that the upgrade now "works", I believe that
the current solution to the upgrade problem is too hacky.
Hacky? Perhaps though I think ucf is working as it is supposed to.
(That it has a missing feature is another issue altogether.)
But if I may vent some frustration here, for most of the time this package
gets no attention and then suddenly just as we are about to freeze lots of
people start upgrading and then all the bug reports start coming out of
the woodwork. The time to do things perfectly was six months ago. Now I
can only do things adequately.
My previous question remains: Why the file is managed by UCF at all?
Because its a conffile.
Would be possible to consider keeping the certificate generation code
(and ssl=yes) in jessie as a better solution to the upgrade problem?
No. The cert generation code had its own set of problems and I definitely
don't want to be responsible for for the lifetime of Jessie. Hopefully
people will come up with solutions for improving the package including
more bulletproof cert handling. (Ideally Debian-wide like we do with
adduser/deluser.) But I predict what will actually happen is everyone
will disappear until a couple of weeks before stretch freezes. C'est la
vie.
On Mon, 15 Dec 2014, Santiago Vila wrote:
I'm setting this to serious because I believe this package should not
reach testing in its current state, but feel free to disagree.
I hope I have satisfactorily explained why this isn't a bug at all. I am
closing it.
--
Jaldhar H. Vyas <[email protected]>
--- End Message ---
