[Bug 1157943] Re: apt-get update fails hash checks on https repositories when file size changes

[David Kalnischkies]

#6: SHOULD means that there are servers outwhere behaving like that. So we have to support both. Not that we can ignore should-clauses.
#7: Do I really have to comment that? I am not that good at explaining jokes, but lets try:
1. APT downloads a part of a file.
2. replaces the file on the server
3+4. Deal with the current file on the server which is from APTs view-point a new file as it has a part of the old file.
So in which way is it not dealing with changed content? 

Both do not change the fact that you usually have a part smaller than
the (new) file downloaded in which case the patch doesn't help
(actually, I wonder how the patch is supposed to help at all as we still
write the result unconditionally to the end of the file) – and it also
doesn't change that I said I am not the one to talk to about https as I
am not a big fan of "works correctly as the compiler isn't
complaining"-patches and that is all I could do for https currently as I
don't use https. (aka: I will try to help review working patches, but I
am not producing one myself)

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to apt in Ubuntu.
https://bugs.launchpad.net/bugs/1157943

Title:
  apt-get update fails hash checks on https repositories when file size
  changes

Status in “apt” package in Ubuntu:
  New
Status in “apt” source package in Precise:
  New

Bug description:
  apt uses its own strategy for sending Range: requests on https,
  instead of the libcurl handling. Here's is a scenario where it gets it
  wrong:

  1) apt downloads the file but doesn't put the file in place yet (perhaps it got interrupted or something)
  2) the file on the server gets replaced by a smaller file
  3) the next update run wants to download the file, sees a partial read, and asks for Range: (len(file)-1)-
  4) the server sees a Range: request for a byte-range past the end of (the current version of) the file, considers it invalid, and streams the entire file. (This is correct behavior.)
  5) apt assumes the response is the range it expected, and appends it to the local staging copy (minus one byte).

  Instead of rolling apt's own attempt to handle ranges in the https
  method, it should just use libcurl's. Attached is a patch which solves
  the problem.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1157943/+subscriptions