Bug#773237: dovecot-core: Should not use UCF for 10-ssl.conf
On Tue, Dec 16, 2014 at 07:18:19PM -0500, Jaldhar H. Vyas wrote: On Wed, 17 Dec 2014, Santiago Vila wrote: But we can leave the whole business of creating SSL certificates to the end user, and at the *same* time avoid useless UCF prompts on upgrades. If 10-ssl.conf exists and disables SSL, then upgraders with a previously working SSL configuration will face a nasty surprise. If 10-ssl.conf exists and enables SSL, then new installers without certificates (self-generated or otherwise) will find that the server doesn't start up which will cause dpkg to report an installation error. For umpteenth time: The file 10-ssl.conf does not have to be included in dovecot-core.deb! Try dpkg -S /root/.profile in your system. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773237: dovecot-core: Should not use UCF for 10-ssl.conf
On Wed, 17 Dec 2014, Santiago Vila wrote: For umpteenth time: The file 10-ssl.conf does not have to be included in dovecot-core.deb! Try dpkg -S /root/.profile in your system. I've reopened this is as a wishlist. Right now I need to make sure a never version of dovecot than -6 gets into Jessie so I don't want to make more changes unless the release team approves. -- Jaldhar H. Vyas jald...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773237: dovecot-core: Should not use UCF for 10-ssl.conf
On Tue, 16 Dec 2014, Jaldhar H. Vyas wrote: reopen 773237 severity wishlist thanks Thanks for reopening, but policy says this: Packages should try to minimize the amount of prompting they need to do, and they should ensure that the user will only ever be asked each question once. So the package is violating a should directive in policy and everything this bug deserves is a wishlist? This is really disappointing. Anyway, in case it helps, the fix could be something like the attached patch. Please be warned that this is *completely* untested, it's just something that could serve as the basis for the real fix. Do not forget to test the following scenarios: * Clean installs. * Upgrades from wheezy * Upgrades from current testing to the new version. * Package removals. So, this is only a suggestion, but in fact I don't see that the real fix would need to deviate a lot from it. Note that the continue word here is essential because we don't want the file to be managed by UCF at all (well, that's the idea). diff --git a/debian/dovecot-core.postinst b/debian/dovecot-core.postinst index fb3b8a5..adba953 100644 --- a/debian/dovecot-core.postinst +++ b/debian/dovecot-core.postinst @@ -107,12 +107,14 @@ if [ $1 = configure ]; then # maintainer version, and let it handle how to manage the real # configuration file in /etc/dovecot. -# special handling for 10-ssl.conf. If it is the default from = -6 -# we want to alter it so ucf in newer packages doesn't overwrite it. -if [ $conffile = 'conf.d/10-ssl.conf' ] -[ `ucfq --with-colons /etc/dovecot/$conffile | cut -d: -f4` = 'No' ] -[ `md5sum /etc/dovecot/$conffile | cut -d\ -f1` = '6813a2a50ff7e64b2a35af663c88c05f' ]; then -echo \# old config /etc/dovecot/conf.d/10-ssl.conf +# Special handling for 10-ssl.conf. +# Copy the file if it does not exist, do nothing otherwise. +if [ $conffile = 'conf.d/10-ssl.conf' ]; then + if [ ! -f /etc/dovecot/$conffile ]; then +cp /usr/share/dovecot/$conffile /etc/dovecot/$conffile +chmod 0644 /etc/dovecot/$conffile + fi + continue fi ucf --three-way --debconf-ok /usr/share/dovecot/$conffile /etc/dovecot/$conffile Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773237: dovecot-core: Should not use UCF for 10-ssl.conf
On Wed, Dec 17, 2014 at 06:40:55AM -0500, Jaldhar H. Vyas wrote: On Wed, 17 Dec 2014, Santiago Vila wrote: For umpteenth time: The file 10-ssl.conf does not have to be included in dovecot-core.deb! Try dpkg -S /root/.profile in your system. I've reopened this is as a wishlist. Right now I need to make sure a never version of dovecot than -6 gets into Jessie so I don't want to make more changes unless the release team approves. I know that we are in a freeze, but the package is violating a should directive in policy and the fix for this bug would actually make the postinst code cleaner and easier to understand for everybody, including the release team. Please do not discard the idea of fixing this bug for jessie. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773237: dovecot-core: Should not use UCF for 10-ssl.conf
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. [...] You are right that dpkg will not ask you about updating the file, because the file is not a conffile in the dpkg sense. But I was not quoting policy for the conffile mechanism itself but for the consequences of using it: The UCF mechanism works in exactly the same way as dpkg conffile mechanism, so instead of dpkg asking about this file over and over again on upgrades, we will have a *UCF* prompt asking about this file over and over again on upgrades. There is not a paragraph in policy speaking about UCF yet, but the spirit of policy is clearly violated by having 10.ssl.conf as a UCF-managed file. 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. My objection is that policy says that the conffile mechanism is only appropriate for files having a default that may work for everybody, and the rationale is that if most people need to modify it, then most people will get prompted on upgrades over and over again. Since UCF and the conffile mechanism behaves in the same way when the file is not the default, it should naturally follow that the UCF mechanism is not appropriate either, unless there is a default which works for most people. The current default disables SSL, which is insecure. We can't honestly claim that an insecure default will work for most people. [...] I hope I have satisfactorily explained why this isn't a bug at all. I am closing it. Actually, you have not. Policy says prompting should be reduced to a minimum. By using UCF on a file not having a good default that will work for most people, this package is not following policy at all. As I said in the initial report, I will not discuss about this being RC or not, this is up to you, but based on current policy, this is still a bug. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773237: dovecot-core: Should not use UCF for 10-ssl.conf
On Tue, 16 Dec 2014, Santiago Vila wrote: My objection is that policy says that the conffile mechanism is only appropriate for files having a default that may work for everybody, and the rationale is that if most people need to modify it, then most people will get prompted on upgrades over and over again. The package has to ship some kind of default or the server will not start. As you say there isn't a default which will satisfy everyone so we expect it to be changed by many users. But with normal operation of dpkg, new versions of the package will silently overwrite the changes. The only way to prevent this is to make it a conffile. The current default disables SSL, which is insecure. We can't honestly claim that an insecure default will work for most people. Sure it will. You will be able to receive IMAP and POP3 mail which is what an imapd/pop3d does. As a best practice you _should_ do IMAP/POP3 over SSL but it is not required. And I fully agree that in this day and age the more encryption working out of the box the better. But this has to be done right because half-assed security is worse than no security at all. There are many different scenarios: self-signed certificate versus purchased from a CA, different locations, different expiration policies etc. The previous code was not accounting for all of this properly. So the only configuration the package can ship which will definitely work for all people is SSL disabled. Atleast now a security-minded user knows where he stands and can harden the package the way he wants. I encourage you to work on a centralized SSL cert handling facility for Debian that not only dovecot but all server packages can use. I will gladly use it. -- Jaldhar H. Vyas jald...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773237: dovecot-core: Should not use UCF for 10-ssl.conf
On Tue, Dec 16, 2014 at 09:14:11AM -0500, Jaldhar H. Vyas wrote: On Tue, 16 Dec 2014, Santiago Vila wrote: My objection is that policy says that the conffile mechanism is only appropriate for files having a default that may work for everybody, and the rationale is that if most people need to modify it, then most people will get prompted on upgrades over and over again. The package has to ship some kind of default or the server will not start. As you say there isn't a default which will satisfy everyone so we expect it to be changed by many users. But with normal operation of dpkg, new versions of the package will silently overwrite the changes. The only way to prevent this is to make it a conffile. The only way? That's simply *not* true! It is perfectly allowed *not* to ship a configuration file inside the .deb and instead create it in the postinst, only if it does not exist. Please see /var/lib/dpkg/info/base-files.postinst for examples, where the install_from_default shell function is used to create files from the defaults, only the very first time the package is installed. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773237: dovecot-core: Should not use UCF for 10-ssl.conf
On Tue, 16 Dec 2014, Santiago Vila wrote: The only way? That's simply *not* true! It is perfectly allowed *not* to ship a configuration file inside the .deb and instead create it in the postinst, only if it does not exist. Creating the relevant configuration in postinst is what was broken in the first place. That's why I took it out. -- Jaldhar H. Vyas jald...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773237: dovecot-core: Should not use UCF for 10-ssl.conf
On Tue, Dec 16, 2014 at 04:49:18PM -0500, Jaldhar H. Vyas wrote: On Tue, 16 Dec 2014, Santiago Vila wrote: The only way? That's simply *not* true! It is perfectly allowed *not* to ship a configuration file inside the .deb and instead create it in the postinst, only if it does not exist. Creating the relevant configuration in postinst is what was broken in the first place. That's why I took it out. Bug number? References? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773237: dovecot-core: Should not use UCF for 10-ssl.conf
On Tue, 16 Dec 2014, Santiago Vila wrote: Creating the relevant configuration in postinst is what was broken in the first place. That's why I took it out. Bug number? References? Oh there have been various complaints about this or that use case for a long time. Unfortunately a lot of correspondence took place outside the BTS but #706216 and #730828 are examples. Here part of the problem was that originally following upstreams example, the certs were were created in /etc/ssl but I was asked in #608719 that they be moved to /etc/dovecot which other people did not want. #376146 asks to use the snakeoil cert like Ubuntu does but that was not considered a good idea for Debian when I asked about it. #763701 was a somewhat embarrassing example of me sucking at shell scripting. I contacted Mika about his offer to help but he never wrote back. Alas, this is what always happens when I ask for help. Looking through the bugs I see that I have been saying since 2005 that there should be a centralized utility for managing certs that all packages can use. This is the proper solution and everyone agrees it should be done but no one does it. So until that happens it is safest to leave the whole business to the end user which atleast is no worse than what he would have to do if he installed dovecot from upstream source. -- Jaldhar H. Vyas jald...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773237: dovecot-core: Should not use UCF for 10-ssl.conf
On Tue, Dec 16, 2014 at 06:10:29PM -0500, Jaldhar H. Vyas wrote: On Tue, 16 Dec 2014, Santiago Vila wrote: Creating the relevant configuration in postinst is what was broken in the first place. That's why I took it out. Bug number? References? Oh there have been various complaints about this or that use case for a long time. Unfortunately a lot of correspondence took place outside the BTS but #706216 and #730828 are examples. [...] Sorry but I don't follow your line of reasoning. In those examples, the file 10-ssl.conf has SSL certificates by default. But I'm not proposing that the default 10-ssl.conf has SSL enabled anymore. Everything I ask is that we avoid useless prompts in upgrades, which is what this bug is about, and it's also what policy says we should do. So: Why can't dovecot-core create the *current* file (the one *not* having SSL enabled) in the postinst instead of using UCF? Please don't tell me that you already tried that, because you have not. This would solve the problem of UCF asking the same question over and over again on upgrades. Why can't you do that? Using UCF for a file that everybody should change does not make any sense! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773237: dovecot-core: Should not use UCF for 10-ssl.conf
On Tue, Dec 16, 2014 at 06:10:29PM -0500, Jaldhar H. Vyas wrote: [...] it is safest to leave the whole business to the end user [...] But we can leave the whole business of creating SSL certificates to the end user, and at the *same* time avoid useless UCF prompts on upgrades. You seem to imply that I'm proposing something incompatible with leaving the certificate generation to the user. It's *not* the case! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773237: dovecot-core: Should not use UCF for 10-ssl.conf
On Wed, 17 Dec 2014, Santiago Vila wrote: Sorry but I don't follow your line of reasoning. In those examples, the file 10-ssl.conf has SSL certificates by default. The point is that the code to do that was broken. But I'm not proposing that the default 10-ssl.conf has SSL enabled anymore. Everything I ask is that we avoid useless prompts in upgrades, which is what this bug is about, and it's also what policy says we should do. So: Why can't dovecot-core create the *current* file (the one *not* having SSL enabled) in the postinst instead of using UCF? Please don't tell me that you already tried that, because you have not. No I haven't but tell me how I am ensure that that people who have modified that file do not see their changes get destroyed. When you cover all the use cases I bet you fill find that ucf has been reinvented--badly no doubt. This would solve the problem of UCF asking the same question over and over again on upgrades. Why can't you do that? Using UCF for a file that everybody should change does not make any sense! people who want SSL != everybody. People who want SSL in one particular configuration != everyone who wants SSL. That's the whole problem. -- Jaldhar H. Vyas jald...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773237: dovecot-core: Should not use UCF for 10-ssl.conf
On Wed, 17 Dec 2014, Santiago Vila wrote: But we can leave the whole business of creating SSL certificates to the end user, and at the *same* time avoid useless UCF prompts on upgrades. If 10-ssl.conf exists and disables SSL, then upgraders with a previously working SSL configuration will face a nasty surprise. If 10-ssl.conf exists and enables SSL, then new installers without certificates (self-generated or otherwise) will find that the server doesn't start up which will cause dpkg to report an installation error. -- Jaldhar H. Vyas jald...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773237: dovecot-core: Should not use UCF for 10-ssl.conf
On Tue, Dec 16, 2014 at 06:50:55PM -0500, Jaldhar H. Vyas wrote: On Wed, 17 Dec 2014, Santiago Vila wrote: So: Why can't dovecot-core create the *current* file (the one *not* having SSL enabled) in the postinst instead of using UCF? Please don't tell me that you already tried that, because you have not. No I haven't but tell me how I am ensure that that people who have modified that file do not see their changes get destroyed. [...] That is quite easy indeed: * The file is not included in the package.deb. * The very first time the package is installed, the file is created from the default by postinst. * On upgrades, you do nothing at all with the file. This is even simpler than using UCF and less prone to error. The file /root/.profile is an example. Have you ever seen your changes to /root/.profile being destroyed? Surely not. And the reason is that the file is created only once, it's not inside base-files.deb and it's completely left alone on upgrades. Please take a look at base-files postinst as I suggested. And please keep this report open. I think it should be clear by now that using UCF to manage 10-ssl.conf is not a good idea, as there is not a default that will work for everybody. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773237: dovecot-core: Should not use UCF for 10-ssl.conf
reopen 773237 severity wishlist thanks On Wed, 17 Dec 2014, Santiago Vila wrote: That is quite easy indeed: * The file is not included in the package.deb. * The very first time the package is installed, the file is created from the default by postinst. * On upgrades, you do nothing at all with the file. -- Jaldhar H. Vyas jald...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
