make-ssl-cert fails if HOME is unset or empty

That's because ssl-cert 1.0.14-0ubuntu2.1 fails to install:

Richte ssl-cert ein (1.0.14-0ubuntu2.1) ...
dpkg: Fehler beim Bearbeiten von ssl-cert (--configure):
 Unterprozess post-installation script gab den Fehlerwert 1 zurück

It fails in an automatic upgrade/installation environment because the PATH variables are different than if you're using a shell. /usr/sbin is not included if a cron runs the upgrade (or installation) - therefor the command "make-ssl-cert" fails to create the files (because the file is not executed) and then the "chmod" and "chgrp" fail because there is no file to modify and exit with code 1.
you could either change the PATH envorinment variable for cron OR adapt the script so it doesn't fail (should have absolute paths anyway!!!)

it's two times in the postinstallation script [line 32 and line 40]

if the path gets changed to an absolute one, everything works as expected (i tested this)

line 32 old:
make-ssl-cert generate-default-snakeoil --force-overwrite

line 32 new:
/usr/sbin/make-ssl-cert generate-default-snakeoil --force-overwrite

line 40 old:
make-ssl-cert generate-default-snakeoil

line 40 new:
/usr/sbin/make-ssl-cert generate-default-snakeoil

thats it ...! could be closed pretty easy and fast
also affects feisty version 1.0.13 --> same problem!
i haven't looked at the intrepid version of the postinst script, but i suspect the problem could be there too - worth a look ;)

Per discussion with james_w on IRC, it's a reasonable expectation for shells invoking dpkg to have /sbin and /usr/sbin in their path (for example, openssl will fail to install in the preconfiguration stage if the path does not include /sbin and /usr/sbin). Marking this as invalid. Please re-open if it turns out to not be a PATH related issue. Thanks!

well ... i am sorry - it seems i have made an error here. I don't know exactly what i did wrong but i retested everything and fixing the path is not enough.

the real problem is the ssleay.cnf that is being used to generate the standard pem file
it sets the RANDFILE variable to $ENV::HOME/.rnd

if the script is used via cron or anyother script that is being started automatically the user may still be "root", but the homedir is not set (i don't think that THIS is an error) and the creation of the file fails. If executed in a shell it works. changing the RANDFILE to /tmp/.rnd does the trick. i don't see the point why this file needs to be in the homedir of the user that installs the package or uses make-ssl-cert. isn't /tmp good enough?

[this needs reopening]

Hi,

/tmp is a really bad idea and a security hole, if the name .rnd is
used at least.

I think having it shared between users would perhaps be a security
hole as well.

Having it use a proper tmpfile may be possible, but it may still be at
risk.

I'm not sure the file is required though, so it may be possible to not
fail if the file can't be created, I'm not sure.

Thanks,

James

well you can try ... if used in an environment where there is no homedir set it does fail - no certificate is created or updated.

this has an effect on all packages (eg. lighttpd) that use a ssleay.cnf and may create or update certificates upon installation/upgrade

Perhaps something like this somewhere in make-ssl-cert:

  if [ ! -d "$HOME" ]; then
      temphome="$(mktemp -d)"
      cleanup () {
          rm -rf "$temphome"
      }
      trap cleanup EXIT HUP INT QUIT TERM
      export HOME="$temphome"
  fi

Ah, on investigation I've found that this is already fixed in Intrepid:

ssl-cert (1.0.16) unstable; urgency=low

  * Get rid of RANDFILE and just use /dev/urandom instead. Closes: #465279
  * Update Swedish translation. Closes: #446258
  * Update Brazilian translation. Closes: #448511
  * Add Japanese translation. Closes: #465679

 -- Tollef Fog Heen <email address hidden> Wed, 20 Feb 2008 13:27:11 +0100

-RANDFILE = $ENV::HOME/.rnd
+RANDFILE = /dev/urandom

I've provisionally marked this as a target to fix in Ubuntu 8.04.2.

if the make-ssl-cert script does not get changed this needs to be checked on other packages too (so they use /dev/urandom and not the homedir)

for the moment i think apache2 has a ssleay.cnf which uses the homedir

Colin, I was able to manually reproduce the bug by running:

   sudo sh -c "unset HOME ; /usr/share/debconf/frontend sh -ex /usr/sbin/make-ssl-cert generate-default-snakeoil --force-overwrite"

If you remove the redirection of stderr to /dev/null from the openssl invocation in make-ssl-cert, you'll see openssl's cryptic failure message where it complains about the variable not having a value:

  error on line 5 of /tmp/tmp.JOuWS24408
  24410:error:0E065068:configuration file routines:STR_COPY:variable has no value:conf_def.c:629:line 5

Hope this helps.

Hardy has seen the end of its life and is no longer receiving any updates. Marking the Hardy task for this ticket as "Won't Fix".