Regarding #1(If-Modified-Since), the vulnerability is that if a hash in the Release file changes, but the file being referred to by the Release file gets served with a 304 response, apt will ignore the updated file and continue to use the old version of the file. even though the old version of the file doesn't match the new hash. An attacker could exploit this to prevent a system from receiving updates, though thankfully it doesn't seem to be possible to exploit this to cause apt to trust an arbitrary package.
Original incorrect speculation below:
Regarding #1 (If-Modified-Since), I'm wondering if perhaps their HTTP client incorrectly accepts a response body with a 304 response (contrary to the HTTP spec)? In that case a malicious server could deliver a file that's blindly trusted as long as it has a status of 304. (This is pure speculation, but I can't think of any other reason this would be a big deal.)
Comments
I concur with your analysis of 2-4.
Edit:
Regarding #1(If-Modified-Since), the vulnerability is that if a hash in the Release file changes, but the file being referred to by the Release file gets served with a 304 response, apt will ignore the updated file and continue to use the old version of the file. even though the old version of the file doesn't match the new hash. An attacker could exploit this to prevent a system from receiving updates, though thankfully it doesn't seem to be possible to exploit this to cause apt to trust an arbitrary package.
Original incorrect speculation below:
Regarding #1 (If-Modified-Since), I'm wondering if perhaps their HTTP client incorrectly accepts a response body with a 304 response (contrary to the HTTP spec)? In that case a malicious server could deliver a file that's blindly trusted as long as it has a status of 304. (This is pure speculation, but I can't think of any other reason this would be a big deal.)