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

Bug#226255: ssh: Please lower debconf priority for some questions



On Mon, Jan 05, 2004 at 01:49:20PM +0100, Christian Perrier wrote:
> Package: ssh
> Version: 1:3.6.1p2-10
> Severity: normal
> 
> The ssh package asks several question at priority "high" or higher.
> 
> Please consider lowring the priority of these questions.
> 
> Quoting debconf-devel(7):
> 
>               low Very trivial items that have defaults that will work in
> 	      the vast majority of cases; only control freaks see these.
> 		      
>               medium Normal items that have reasonable defaults.
> 				     
>               high   Items that don't have a reasonable default.
> 	       
> 	      critical Items that will probably break the system without
> 	      user intervention.
> 
> All questions asked by the sssh package should therefore be of "medium"
> priority as all have reasonable defaults.

The two remaining high-priority questions in 1:3.8p1-1 are:

Template: ssh/encrypted_host_key_but_no_keygen
Type: note
_Description: Warning: you must create a new host key
 There is an old /etc/ssh/ssh_host_key, which is IDEA encrypted. OpenSSH
 can not handle this host key file, and I can't find the ssh-keygen utility
 from the old (non-free) SSH installation.
 .
 You will need to generate a new host key.

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 first of these requires administrator action to generate a new host
key, and the second requires administrator or user action to fix
authorized_keys files. In either case the system may become inaccessible
if the upgrade is being performed remotely and the warnings are not
heeded.

Is it really true that these shouldn't be priority high?

Thanks,

-- 
Colin Watson                                  [cjwatson@flatline.org.uk]




Reply to: