Re: Debconf or not debconf
Jim Penny dijo [Wed, Jul 02, 2003 at 06:34:53PM -0400]:
> > 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.
Many times this cases are handled by creating a transitional package:
Keep stunnel as a stub package depending on either stunnel3 or stunnel4,
change the description of stunnel3 explaining the situation and urging
users to upgrade if possible.
Even more, stunnel3 and stunnel4 can coexist - and some users will find
it very valuable to have both the newest stunnel features and the ease
of keeping their old configurations, or not having to be root to start a
temporary or permanent new tunnel.
Gunnar Wolf - email@example.com - (+52-55)5630-9700 ext. 1366
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF