sha3-384 mismatch

[Didier Roche]

Le 05/12/2016 à 15:38, Gustavo Niemeyer a écrit :
>
>
> On Mon, Dec 5, 2016 at 12:23 PM, Didier Roche <didrocks at ubuntu.com
> <mailto:didrocks at ubuntu.com>> wrote:
>
>     I did though write on the bug: "contrary to curl or wget which
>     both supports large downloads."
>     The feedback thread mentioned as well "while same assets can be
>     successfully downloaded via curl or wget". 
>
>     I thought that was really obvious that they worked consistently
>     and that I did rerun then multiple times or I wouldn't have opened
>     the bug report + write this feedback. Sorry if that wasn't clear
>     enough, let's move on :)
>
>
> If you file a bug and a developer asks for specific information that
> wasn't provided, it means the specific information is not obvious.
>
>>     Is it the case?  Did you ever get a failure with them?  Are they
>>     retrying while they work? Do you have a verbose dumb of the process?
>     Yes, as mentioned. I never got any failure with any of them and I
>     did retry multiple times in loop when I saw the snapd failures.
>     wget is in verbose mode by default and I never got any hint that
>     it was retrying (just getting the normal download output).
>
>     I did just try a verbose download in curl (here, an ubuntu 300M
>     image). Here is the output: http://paste.ubuntu.com/23583568/
>     <http://paste.ubuntu.com/23583568/>. It seems that curl doesn't
>     complain of any reconnect.
>
>
> You are downloading an image from an arbitrary server on the internet
> unrelated to the problem we're trying to debug.
>
> Can you please attempt these several curl downloads while using the
> exact same URL that failed for snapd?

As a developer asking for more debug information, can you please paste
the exact instructions on how to get those?

I'm trying the https://public.apps.ubuntu.com/anon/download-snap/ based
url with the .snap showing up in the logs to get the exact same assets I
pasted snapd information on. However, curl -v returns (output stripped out):
*   Trying 162.213.33.92...
* Connected to public.apps.ubuntu.com (162.213.33.92) port 443 (#0)
* found 173 certificates in /etc/ssl/certs/ca-certificates.crt
* found 692 certificates in /etc/ssl/certs
* ALPN, offering http/1.1
* SSL connection using TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256
*      server certificate verification OK
*      server certificate status verification SKIPPED
*      common name: public.apps.ubuntu.com (matched)
*      server certificate expiration date OK
*      server certificate activation date OK
*      certificate public key: RSA
*      certificate version: #3
*      subject: C=GB,L=London,O=Canonical Group
Ltd,CN=public.apps.ubuntu.com
*      start date: Mon, 30 May 2016 00:00:00 GMT
*      expire date: Wed, 21 Jun 2017 12:00:00 GMT
*      issuer: C=US,O=DigiCert Inc,CN=DigiCert SHA2 Secure Server CA
*      compression: NULL
* ALPN, server did not agree to a protocol
> GET /anon/download-snap/YZ7LshLxDQQIrhAL6DMLub2yTVUA2DIK_15.snap HTTP/1.1
> Host: public.apps.ubuntu.com
> User-Agent: curl/7.47.0
> Accept: */*
>
< HTTP/1.1 302 FOUND

I guess that's due to the macaroon exchanged system and I'm not
authorized or something else?
Thanks for helping debugging.

Cheers,
Didier
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/snapcraft/attachments/20161205/10b343a4/attachment.html>