chiark / gitweb /
dgit: Cope if the archive server sends an HTTP redirect
authorIan Jackson <ijackson@chiark.greenend.org.uk>
Sat, 8 Jul 2017 17:05:36 +0000 (18:05 +0100)
committerIan Jackson <ijackson@chiark.greenend.org.uk>
Sat, 8 Jul 2017 17:05:38 +0000 (18:05 +0100)
We achieve this by passing -L to curl.

We also pass an appropriate-seeming --proto-redir, because the curl
manual is not entirely reassuring that following redirections with the
default configuration is safe.

This finally fixes #867185/#867309.  What happens there is that curl
gets a redirect, along with an HTML error document.  curl then exits
with status zero, effectively pretending that the error document is
the resource which was requested.  dgit notices that something is
wrong because the file does not have the expected cryptographic
checksum.

I suspect that there are other download problems which would give a
similar effect.  Sadly the curl manpage doesn't seem to suggest a way
to avoid this.  At least, dgit will never carry on in such a
situation, since it insists that the file has the right hash.  And if
it does have the right hash we don't really care how it was obtained.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
debian/changelog
dgit

index 942c77b..05f08e7 100644 (file)
@@ -2,6 +2,8 @@ dgit (3.11~) unstable; urgency=medium
 
   * dgit: fix rpush+buildinfo: Transfer buildinfos for signing.
     Closes:#867693.
+  * dgit: Cope if the archive server sends an HTTP redirect,
+    by passing -L to curl.  Closes:#867185,#867309.
 
  --
 
diff --git a/dgit b/dgit
index 8d7af11..2685b6c 100755 (executable)
--- a/dgit
+++ b/dgit
@@ -100,7 +100,7 @@ our $rewritemap = 'dgit-rewrite/map';
 
 our (@git) = qw(git);
 our (@dget) = qw(dget);
-our (@curl) = qw(curl);
+our (@curl) = qw(curl --proto-redir -all,http,https -L);
 our (@dput) = qw(dput);
 our (@debsign) = qw(debsign);
 our (@gpg) = qw(gpg);