Installer loops forever retrying failed download

[Paul Whittaker]

Binary package hint: hyperspec

System version:

 bash$ lsb_release -rd
 Description: Ubuntu 10.04.1 LTS
 Release: 10.04

Package version:

 hyperspec 1.28

Problem description:

When installing the hyperspec package via aptitude from a machine that cannot access the required download URL, the setup script does not correctly handle the failure to download HyperSpec-7-0.tar.gz. (In my case I was behind a firewall and I hadn't told it about the proxy server e.g via environment variables.)

There appears to be logic in the postinst script to ask the user if they want to continue after a failed download (I assume this is what "db_input medium hyperspec/tryagain" should do), but this is not being triggered for me, and so the download is attempted repeatedly without end. I expected it to either ask me if I wanted to continue, to try a different URL (e.g. using HTTP which my firewall would have allowed), or to stop trying and inform me of how to work around the problem manually.

Effects:

This stops the installation of this package from being able to complete, along with that of other packages that may be being installed at the same time. It also prevents graceful termination of aptitude and dpkg, which in my case caused me to also run into bug #349469. It was also very difficult to stop the repeated downloading: Ctrl-C at the terminal repeatedly had no effect, so in the end I killed aptitude with SIGTERM from another shell. Doing so left apt/dpkg in a state that raised various errors when I tried to use aptitude again (namely "Could not get lock /var/lib/dpkg/lock", "dpkg was interrupted, you must manually run 'sudo dpkg --configure -a' to correct the problem" and "debconf: DbDriver "config": /var/cache/debconf/config.dat is locked by another process").

Cleaning up after this was complex: I had to remove /var/lib/dpkg/lock and kill the process identified by "sudo fuser -v /var/cache/debconf/config.dat" (as per #349469), before I could run "sudo dpkg --configure -a". This last step would then try the download again, unless I manually left the downloaded file at /root/tmp/HyperSpec-7-0.tar.gz and gave it *non-root* owner and group.

I have attached a copy of terminal output that demonstrates the problem occurring. I have also marked this as a security vulnerability, as this bug could (accidentally or deliberately) cause aptitude to become unavailable for other users/processes, thereby preventing security updates from being applied to the system.

[Marc Deslauriers (mdeslaur)]

Thanks for taking the time to report this bug and helping to make Ubuntu better. We appreciate the difficulties you are facing, but this appears to be a "regular" (non-security) bug. I have unmarked it as a security issue since this bug does not show evidence of allowing attackers to cross privilege boundaries nor directly cause loss of data/privacy. Please feel free to report any other bugs you may find.

[Paul Whittaker (launchpad-pdw)]

Hi Marc,

On 30 November 2010 21:05, Marc Deslauriers
<email address hidden>wrote:

> I have unmarked it as a security
> issue since this bug does not show evidence of allowing attackers to
> cross privilege boundaries nor directly cause loss of data/privacy.
>

I'd agree with that assessment. I didn't know how paranoid we would be
about these things when I reported it, but if those are the criteria we're
using for security issues then yes, please leave it un-flagged.

Thanks for your swift response,

Best regards,

Paul.