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

The keychain package, its debconf templates, the security hole induced


as part of my current effort of getting rid of packages using debconf
without providing support to translators, I had a bug repport against the
keychain package asking simply to drop this template:

Description: Information for people upgrading from versions prior to 2.0.
 With this new version of keychain, the output of ssh-agent will be
 redirected to the ~/.keychain/[hostname]-{c}sh files.  Any cron job or
 login script that uses keychain needs to be updated to use the new
 directory location.
 For more information please read the man page.

IMHO, it's clearly a debconf abuse which should be changed to a
README.Debian entry. Moreover, the message is shown each time without even
checking whether the user upgrades from an old version or not (what a pitty
to show this on new installs). Not speaking from the fact that it's called
from postinst instead of config and will thus stop the installation process
right in the middle.

My bug was close with a laconic changelog entry:
  * l10n changes Closes: #235812,#259567,#262738,#266356,#274900,#192165

And now, I'm mad about this. 

A closer check to the package reveals that it's only useful if you want to
open a security risk on your machine. All info relatives to the ssh-agent
are written into a well known file, allowing cron jobs and attackers to use
them without prior knowledge of your passwords.

Dudes. There is a reason why those informations are not written to file by
ssh itself. If my local machine gets corrupted, I'm happy to see the
password I've set on my keys slowing down the attacker enough to allow me
dropping the ssh keys from remote hosts. 

You should at least speak about the potential security risk in the

I'd drop the package from the archive right away. I have several cron jobs
using ssh keys (a new key for each cron, without pass and allowed to do only
one specific command on the remote host).

So, please do at least the following to your package:
 - speak about the potential security hazard in description
 - check the pre-installed version before showing your crufty template (or
   use README.Debian, it's what it's good for)
 - use a proper config script instead of blocking the install with a db_get
   in the postinst (just read the debconf documentation)
 - do usefull changelog entries in your packages in the future.
Bye, Mt.

Attachment: signature.asc
Description: Digital signature

Reply to: