The problem here is just that we're checking the digest mismatch before we check the error reading from the network. Obviously, if we fail to read from the network, the mismatch will always occur. If the mismatch doesn't occur, we might not even report the network error since we got all the data we needed anyway.
Offending logic: https://github.com/snapcore/snapd/blob/master/store/store.go#L1388 On Fri, Dec 2, 2016 at 4:15 PM, Gustavo Niemeyer < gustavo.nieme...@canonical.com> wrote: > The broken snap is a prefix of the actual snap: > > [niemeyer@nomade ~/test]% dd if=cr5pkasGhR7N3M8wKfP9DJqGxbBGeET2_25.snap > of=broken.snap bs=409018 count=1 > 1+0 records in > 1+0 records out > 409018 bytes (409 kB, 399 KiB) copied, 0,0024764 s, 165 MB/s > > [niemeyer@nomade ~/test]% sha3384 broken.snap > broken.snap: d0e1cd6d578c8eaab13e10dac4acb > d7e8f6337da45b291fa7ae0358a29393059732b29bb61a65d18e693b8e6e8a53b62 > > > Either the CDN is returning a successful code on interruption, or we're > mishandling the actual interruption code. > > > > On Fri, Dec 2, 2016 at 2:52 PM, Michael Vogt <michael.v...@canonical.com> > wrote: > >> On Fri, Dec 02, 2016 at 02:32:03PM +0100, David Barth wrote: >> > On Fri, Dec 2, 2016 at 1:04 PM, Pegenaute Bresme, Xavier < >> > xpegenaut...@iam.cat> wrote: >> [..] >> > > - Download snap "snapweb" (25) from channel "stable" (sha3-384 >> mismatch >> > > downloading snapweb: got 8b83c8eb7f7aa306bc342fd1b424fa >> > > 95ccf379c068c4735085bc81ee6b51bb02a23b8c3c2a34f842619d7650b3152787 >> but >> > > expected d0e1cd6d578c8eaab13e10dac4acbd7e8f6337da45b291fa7ae0358a2939 >> > > 3059732b29bb61a65d18e693b8e6e8a53b62) >> > > >> > >> > What is surprising is the "expected" signature. >> > Snap is downloading the correct armhf build for 0.21.2, ie #25, and the >> > SHA3 it obtained corresponds to the published version. >> >> This version of snapd has a mixup of expected vs actual hash, this is >> fixed in git. Sorry for the confusion. >> >> I would love to see the actual file that got downloaded, that is >> probably tricky because currently we delete those iirc. It would be >> good to have the file to see if its garbage or a mostly valid squashfs >> with some garbage in between or something else. Also size would be >> interessting etc. >> >> Cheers, >> Michael >> >> -- >> Snapcraft mailing list >> Snapcraft@lists.snapcraft.io >> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >> an/listinfo/snapcraft >> > > > > -- > gustavo @ http://niemeyer.net > -- gustavo @ http://niemeyer.net
-- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
