Re: Debconf or not debconf
On Wed, 2 Jul 2003 15:57:01 -0500
Steve Langasek <vorlon@netexpress.net> wrote:
> On Wed, Jul 02, 2003 at 10:50:29AM -0400, Jim Penny wrote:
> > On Tue, 1 Jul 2003 20:40:02 -0500 Steve Langasek
> > <vorlon@netexpress.net> wrote:
>
> > > On Tue, Jul 01, 2003 at 05:12:22PM +0200, Julien LEMOINE wrote:
>
> > > > I received a bug report on stunnel package from an user [1]
> > > > that complained
> > > > about the fact that I didn't warning about the new
> > > > /etc/default/stunnel file introduced in package (thereis a note
> > > > in README.Debian and in changelog).
>
> > > > Since debconf is not really appreciated for this use, what is
> > > > the best
> > > > solution ? Inform users with debconf or give them informations
> > > > only in changelog and README.Debian ?
>
> > > Does the introduction of /etc/default/stunnel break a large
> > > percentage of installed systems? If so, I would recommend looking
> > > for a way to provide a more graceful upgrade -- this is worth much
> > > more than a note telling users that you've just broken their
> > > systems...
>
> > It breaks 100% of stunnel installations. The old stunnel was
> > command line oriented, the current one is configuration file
> > oriented. It would be very difficult to write a converter.
>
> > I am going to disagree with most responders here. I think that in
> > the case that if upgrading a package introduces substantial risk of
> > breakage, a debconf message is quite appropriate. When a security
> > related package has high risk of breakage, it is urgent.
>
> > Now, this breakage happens to be somewhat benign, in that without
> > configuration, it does not function at all. But it is also somewhat
> > difficult to test for many uses. Further, when the unconfigured
> > system fails to start, the failure is completely silent. This adds
> > to the problems.
>
> My original argument stands: we should not be telling our users that
> we broke their system, because we shouldn't be breaking it in the
> first place. In this instance, it sounds to me like a bout of
> upstream bogosity has resulted in a rather grave regression in the
> quality of the software. Why would it ever be a good idea to *not*
> give users the ability to control the program using commandline
> options?
Because of security considerations. The configuration file is read on
startup, and then stunnel chroots away, so that it is no longer visible.
The command line interface leaked information, internal IP
structure, internal ports, etc. that a really paranoid person might
prefer not be visible.
While it is indeed preferable to not break things, there are times when
avoiding breakage is quite difficult. This appears, to me, to be
one of those times.
I was aware of the issue, because I had looked at the upgrade for
Windows users. I still got mildly bitten by this upgrade. I would
prefer to have a hard stop message.
Jim Penny
Reply to: