touch-packages team mailing list archive

[Launchpad Bug Tracker <1172101@xxxxxxxxxxxxxxxxxx>]

This bug was fixed in the package base-installer - 1.122ubuntu7.4

---------------
base-installer (1.122ubuntu7.4) precise; urgency=medium

  * pkgdetails.c: Only interpret percentages following whitespace, to cope
    with GNU wget outputting the local file name (which may contain "%" due
    to URL-encoding) after it finishes the download (LP: #1172101).
  * Add HTTPS support: pass --no-check-certificate to debootstrap if
    debian-installer/allow_unauthenticated_ssl=true, set https_proxy if
    necessary, and copy any certificates that exist in d-i into the target
    system (LP: #1135163).
 -- Colin Watson <cjwatson@xxxxxxxxxx>   Mon, 23 Jun 2014 16:13:11 +0100

** Changed in: base-installer (Ubuntu Precise)
       Status: Fix Committed => Fix Released

** Changed in: debootstrap (Ubuntu Precise)
       Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to wget in Ubuntu.
https://bugs.launchpad.net/bugs/1172101

Title:
  wget-udeb should install to /usr/bin/wget instead of /usr/bin/wget.gnu

Status in “base-installer” package in Ubuntu:
  Fix Released
Status in “debian-installer-utils” package in Ubuntu:
  Fix Released
Status in “debootstrap” package in Ubuntu:
  Fix Released
Status in “wget” package in Ubuntu:
  Fix Released
Status in “base-installer” source package in Precise:
  Fix Released
Status in “debian-installer-utils” source package in Precise:
  Fix Released
Status in “debootstrap” source package in Precise:
  Fix Released
Status in “wget” source package in Precise:
  Fix Released

Bug description:
  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/base-installer/+bug/1172101/+subscriptions