[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: imp blows away hand-edited changes...



On Sun, Nov 21, 1999 at 02:14:19AM -0500, Ivan E. Moore II wrote:
> -----
> >Package: imp
> >Version: 1:2.2.0.pre5-9.2
> >Severity: Critical
> >
> >extremely evil misuse of debconf results in hand-edited changes to imp's
> >config file being blown away by the postinst script.
> >
> >HAND-EDITED CONFIGURATION FILES SHOULD NEVER BE BLOWN AWAY BY ANY
> >CONFIGURATOR SCRIPT.  EVER.  FOR ANY REASON.
> >
> >at the very least, they should ask for permission first.
> >
> >this bug highlights a very serious flaw in debconf - not in the design,
> >but in the manner in which it can be misused by a package maintainer.
> >blowing away custom edits is evil and should be forbidden by policy.
> -----------------
> 
> defaults.php3 is not a conffile.  

it does not matter whether it is a listed conffile or not. what matters
is that it is a configuration file which is automatically blow away.

> And notice was made using debconf's facility as a note to state this
> to the end user that the defaults file is now rebuilt automatically
> each time it is installed...and that a backup was made prior to this.

providing notice that you're going to do something evil and
brain-damaged is no justification.

if every package took this attitude towards configuration files then
it would be too dangerous to ever upgrade a debian system. after every
upgrade the system admin would have to remember hundreds of config files
and edit them back to what they were before the upgrade fucked them up.

overwriting hand-edited config files is just plain wrong. no package
should ever do it, for any reason without asking specifically for
permission just prior to doing it.

> The package does follow policy in this manner.  

no it doesn't. in fact, imp is breaking policy because
/etc/imp/defaults.php3 is not in the package and therefore does not
belong to imp.


> Just because I haven't had the chance to finish my configuration
> pieces of it and work out other bugs doesn't mean I'm not following
> policy.

you should not have released a postinst script that overwrites a config
file UNTIL you had implemented a way of doing it safely and sanely.

craig

--
craig sanders


Reply to: