Activity log for bug #1172101

Date Who What changed Old value New value Message
2013-04-24 02:59:30 Mark Russell bug added bug
2013-04-24 03:00:23 Mark Russell bug added subscriber Canonical Support
2013-04-24 03:10:06 Mark Russell description In every currently supported Ubuntu version of wget, the wget-udeb 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 all things apt. 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. In every currently supported Ubuntu version of wget, the wget-udeb 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 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 all things apt. 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.
2013-04-24 03:25:51 Mark Russell attachment added wget.raring.1172101.debdiff https://bugs.launchpad.net/ubuntu/+source/wget/+bug/1172101/+attachment/3652081/+files/wget.raring.1172101.debdiff
2013-04-24 03:33:35 Mark Russell description In every currently supported Ubuntu version of wget, the wget-udeb 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 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 all things apt. 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. 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 all things apt. 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.
2013-04-24 04:18:20 Ubuntu Foundations Team Bug Bot tags patch
2013-04-24 04:18:27 Ubuntu Foundations Team Bug Bot bug added subscriber Ubuntu Sponsors Team
2013-04-24 13:32:50 Mark Russell 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 all things apt. 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. 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.
2013-04-24 19:04:51 Peter Matulis bug added subscriber Peter Matulis
2013-04-24 19:26:17 Launchpad Janitor wget (Ubuntu): status New Confirmed
2013-04-24 19:26:27 Leonardo Borda bug added subscriber Leonardo Borda
2013-05-15 12:24:37 Mark Russell tags patch patch precise quantal raring saucy
2013-05-15 12:43:01 Adam Stokes attachment added wget_1.14-1ubuntu2.saucy.debdiff https://bugs.launchpad.net/ubuntu/+source/wget/+bug/1172101/+attachment/3677274/+files/wget_1.14-1ubuntu2.saucy.debdiff
2013-05-17 10:12:39 Colin Watson bug added subscriber Colin Watson
2013-05-17 10:12:47 Colin Watson wget (Ubuntu): importance Undecided Low
2013-05-17 10:12:52 Colin Watson wget (Ubuntu): status Confirmed Triaged
2013-05-23 18:51:54 Bryan Quigley bug added subscriber Bryan Quigley
2013-06-23 17:53:03 Mark Russell attachment added syslog-wget-install.txt https://bugs.launchpad.net/ubuntu/+source/wget/+bug/1172101/+attachment/3711461/+files/syslog-wget-install.txt
2013-06-23 17:53:38 Mark Russell bug added subscriber Goobuntu Team
2013-06-23 17:55:01 Mark Russell bug added subscriber Adam Conrad
2013-08-08 12:03:50 Dimitri John Ledkov removed subscriber Ubuntu Sponsors Team
2014-02-07 15:47:23 Colin Watson bug task added base-installer (Ubuntu)
2014-02-07 15:53:52 Colin Watson bug task added debootstrap (Ubuntu)
2014-02-07 16:37:19 Launchpad Janitor branch linked lp:~ubuntu-core-dev/base-installer/ubuntu
2014-02-07 16:45:13 Colin Watson bug task added debian-installer-utils (Ubuntu)
2014-02-07 17:07:02 Launchpad Janitor branch linked lp:ubuntu/trusty-proposed/base-installer
2014-02-07 17:23:08 Launchpad Janitor base-installer (Ubuntu): status New Fix Released
2014-02-07 18:05:49 Launchpad Janitor debian-installer-utils (Ubuntu): status New Fix Released
2014-02-07 18:20:49 Launchpad Janitor branch linked lp:ubuntu/trusty-proposed/wget
2014-02-07 18:54:58 Launchpad Janitor wget (Ubuntu): status Triaged Fix Released
2014-02-07 22:19:16 Launchpad Janitor branch linked lp:debian/base-installer
2014-02-07 22:19:51 Launchpad Janitor branch linked lp:debian/debian-installer-utils
2014-02-08 00:48:09 Launchpad Janitor debootstrap (Ubuntu): status New Fix Released
2014-02-12 03:54:13 Launchpad Janitor branch linked lp:~dannf/ubuntu/trusty/base-installer/xgene
2014-06-23 14:52:10 Colin Watson 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. SRU justification: This is a prerequisite for bug 833994, which is a customer requirement for Ubuntu 12.04.5. It's probably simplest to test them all together. Original report: 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.
2014-06-23 15:11:12 Launchpad Janitor branch linked lp:~ubuntu-core-dev/base-installer/precise-proposed
2014-06-23 15:20:17 Colin Watson nominated for series Ubuntu Precise
2014-06-23 15:20:17 Colin Watson bug task added debootstrap (Ubuntu Precise)
2014-06-23 15:20:17 Colin Watson bug task added wget (Ubuntu Precise)
2014-06-23 15:20:17 Colin Watson bug task added base-installer (Ubuntu Precise)
2014-06-23 15:20:17 Colin Watson bug task added debian-installer-utils (Ubuntu Precise)
2014-06-23 15:20:28 Colin Watson base-installer (Ubuntu Precise): status New Triaged
2014-06-23 15:20:31 Colin Watson debian-installer-utils (Ubuntu Precise): status New Triaged
2014-06-23 15:20:34 Colin Watson debootstrap (Ubuntu Precise): status New Triaged
2014-06-23 15:20:37 Colin Watson wget (Ubuntu Precise): status New Triaged
2014-06-23 15:21:00 Colin Watson debian-installer-utils (Ubuntu Precise): assignee Colin Watson (cjwatson)
2014-06-23 15:21:04 Colin Watson base-installer (Ubuntu Precise): importance Undecided High
2014-06-23 15:21:06 Colin Watson debian-installer-utils (Ubuntu Precise): importance Undecided High
2014-06-23 15:21:09 Colin Watson debootstrap (Ubuntu Precise): importance Undecided High
2014-06-23 15:21:11 Colin Watson wget (Ubuntu Precise): importance Undecided High
2014-06-23 15:21:14 Colin Watson base-installer (Ubuntu Precise): assignee Colin Watson (cjwatson)
2014-06-23 15:21:17 Colin Watson debootstrap (Ubuntu Precise): assignee Colin Watson (cjwatson)
2014-06-23 15:21:20 Colin Watson wget (Ubuntu Precise): assignee Colin Watson (cjwatson)
2014-06-23 15:21:28 Colin Watson debian-installer-utils (Ubuntu Precise): milestone ubuntu-12.04.5
2014-06-23 15:21:32 Colin Watson base-installer (Ubuntu Precise): milestone ubuntu-12.04.5
2014-06-23 15:21:35 Colin Watson debootstrap (Ubuntu Precise): milestone ubuntu-12.04.5
2014-06-23 15:21:38 Colin Watson wget (Ubuntu Precise): milestone ubuntu-12.04.5
2014-06-23 15:33:45 Launchpad Janitor branch linked lp:~ubuntu-core-dev/debian-installer-utils/precise-proposed
2014-06-23 15:55:21 Colin Watson base-installer (Ubuntu Precise): status Triaged In Progress
2014-06-23 15:57:57 Colin Watson debian-installer-utils (Ubuntu Precise): status Triaged In Progress
2014-06-23 15:58:02 Colin Watson debootstrap (Ubuntu Precise): status Triaged In Progress
2014-06-23 15:58:05 Colin Watson wget (Ubuntu Precise): status Triaged In Progress
2014-06-23 17:45:50 Chris J Arges base-installer (Ubuntu Precise): status In Progress Fix Committed
2014-06-23 17:45:54 Chris J Arges bug added subscriber Ubuntu Stable Release Updates Team
2014-06-23 17:45:58 Chris J Arges bug added subscriber SRU Verification
2014-06-23 17:46:07 Chris J Arges tags patch precise quantal raring saucy patch precise quantal raring saucy verification-needed
2014-06-23 17:49:05 Chris J Arges debian-installer-utils (Ubuntu Precise): status In Progress Fix Committed
2014-06-23 17:51:54 Chris J Arges debootstrap (Ubuntu Precise): status In Progress Fix Committed
2014-06-23 17:53:22 Chris J Arges wget (Ubuntu Precise): status In Progress Fix Committed
2014-06-23 18:04:44 Launchpad Janitor branch linked lp:ubuntu/precise-proposed/debian-installer-utils
2014-06-23 18:07:21 Launchpad Janitor branch linked lp:~ubuntu-branches/ubuntu/precise/wget/precise-proposed
2014-07-15 14:42:34 Mark Russell tags patch precise quantal raring saucy verification-needed patch precise quantal raring saucy verification-done
2014-07-15 16:23:29 Colin Watson removed subscriber Ubuntu Stable Release Updates Team
2014-07-15 16:24:09 Launchpad Janitor base-installer (Ubuntu Precise): status Fix Committed Fix Released
2014-07-15 16:24:15 Launchpad Janitor debootstrap (Ubuntu Precise): status Fix Committed Fix Released
2014-07-15 16:29:10 Launchpad Janitor wget (Ubuntu Precise): status Fix Committed Fix Released
2014-07-15 16:29:16 Launchpad Janitor debian-installer-utils (Ubuntu Precise): status Fix Committed Fix Released
2016-05-19 06:06:29 Poil bug added subscriber Poil