[Bug 1172101] Re: wget-udeb should install to /usr/bin/wget instead of /usr/bin/wget.gnu
Dmitrijs Ledkovs
launchpad at surgut.co.uk
Tue Jul 9 09:55:54 UTC 2013
Colon in the package version string denotes epoch, and is not present in the actual .deb filename.
For example, just on a normal system:
$ apt-get download bsdutils
Get:1 Downloading bsdutils 1:2.20.1-5.1ubuntu8 [40.4 kB]
Fetched 40.4 kB in 1s (32.8 kB/s)
$ ls
bsdutils_2.20.1-5.1ubuntu8_amd64.deb
But this does suggest that something in the installer relies on exact
string matching, somewhere...
A simple test between GNU and busybox, does show differences in the output:
$ wget http://127.0.0.1/:
--2013-07-09 10:45:24-- http://127.0.0.1/:
Connecting to 127.0.0.1:80... connected.
HTTP request sent, awaiting response... 404 Not Found
2013-07-09 10:45:24 ERROR 404: Not Found.
$ busybox wget http://127.0.0.1/:
Connecting to 127.0.0.1 (127.0.0.1:80)
wget: server returned error: HTTP/1.1 404 Not Found
Now looking into debian-installer-utils, reveals README.wget404 which
explains in detail that fetching urls, depends on text matching of
wget's output.
Have you considered adding a new fetch-url-methods/https, which uses wget.gnu (if available) with correct wget.gnu 404 parsing?
Or one can modify existing fetch-url-methods/http to accommodate for either busybox or GNU.
--
You received this bug notification because you are a member of Ubuntu
Sponsors Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1172101
Title:
wget-udeb should install to /usr/bin/wget instead of /usr/bin/wget.gnu
Status in “wget” package in Ubuntu:
Triaged
Bug description:
In the Ubuntu raring (13.04) version of wget, there is a wget-udeb
which installs its binary executable to /usr/bin/wget.gnu.
This is presumably done in order to not break any setups that depend
on busybox's wget implementation.
However, since the primary reason wget-udeb exists in Ubuntu (wget-
udeb is not built in Debian afaik) is because of the lack of SSL
support in d-i and busybox-wget, it seems logical (to me) that it
should overwrite the busybox wget symlink. You're choosing to opt-in
to GNU wget, so you're already rebuilding d-i/debian-cd and therefore
know you're somewhat on your own.
Unless there is a common use case I'm not considering where you want
SSL support for something else, but somehow depend on the busybox
implementation of wget for the debootstrap portion of the install.
What I expect to happen:
1) modify d-i source to include wget-udeb
2) rebuild d-i and point my sources to HTTPS repositories
3) install Ubuntu without fear of the traffic being snooped in transit
What happens instead:
1) modify d-i source to include wget-udeb
2) rebuild d-i and point sources to HTTPS repositories
3) install fails because d-i calls /usr/bin/wget which points to busybox (which has no SSL support)
Thanks for your time!
Please note: this suggestion is not intended to securely authenticate
the repository; that's absolutely another issue. This is simply to
address potential snooping of traffic in transit.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/wget/+bug/1172101/+subscriptions
More information about the Ubuntu-sponsors
mailing list