Bug#221531: ssh: uses high priority debconf warning
severity 221531 normal
thanks
On Tue, Nov 18, 2003 at 06:28:26PM -0500, Joe Drew wrote:
> Package: ssh
> Version: 1:3.6.1p2-9
> Severity: important
>
> ssh uses a high priority debconf warning to talk about PrivSep instead
> of using NEWS.Debian.
>
> Debconf warnings (notes) should not be used for these types of issues.
In 1:3.8p1-1, the privsep_ask and privsep_tell questions have been
removed, since it's my belief that most issues with privilege separation
(in particular, all of those mentioned in the texts of the questions)
have been fixed. Thus, downgrading, as that was the most intrusive
question.
> After reporting this bug I noticed that your package had other debconf
> warnings (notes). All of your package's debconf warnings (notes) should
> be removed.
>
> Warnings are only to be used when something which cannot be
> automatically fixed is going to break on the user's system (eg a
> database's format has been changed, and it's impossible to know where
> those databases are or how to automatically update them). In all other
> cases, either use README.Debian or NEWS.Debian.
I certainly have my doubts about some of the notes, but it seems not to
be true that "all of [them] should be removed", for the reason you cite:
Template: ssh/user_environment_tell
Type: note
_Description: Environment options on keys have been deprecated
This version of OpenSSH disables the environment option for public keys by
default, in order to avoid certain attacks (for example, LD_PRELOAD). If
you are using this option in an authorized_keys file, beware that the keys
in question will no longer work until the option is removed.
.
To re-enable this option, set "PermitUserEnvironment yes" in
/etc/ssh/sshd_config after the upgrade is complete, taking note of the
warning in the sshd_config(5) manual page.
The disabling of the environment option means that users whose
authorized_keys files contain it will be unable to ssh into the system
until they fix the problem. If the sysadmin is one such user, they might
reasonably count that as breakage, and it can't be automatically fixed.
(The option was disabled for a good reason, so just enabling it on all
upgrades isn't a good idea either.)
Likewise, ssh/encrypted_host_key_but_no_keygen signals breakage on
upgrade from the old non-free ssh which the sysadmin needs to fix.
All other remaining templates are at priority medium or lower. At least
ssh/ssh2_keys_merged looks like a good candidate for being moved into
README.Debian.
Cheers,
--
Colin Watson [cjwatson@flatline.org.uk]
Reply to: