checksums do not match. Please ensure the snap is created with either 'snapcraft pack ’ (using snapcraft >= 2.38) or ‘mksquashfs -noappend -comp xz -all-root -no-xattrs -no-fragments’ (using squashfs-tools >= 4.3). If using electron-builder, please upgrade to latest stable (>= 20.14.7). See Automated reviews and snapcraft < 2.38 for details. security-snap-v2_squashfs_repack_checksum
@alexmurray or @roadmr do you have any thoughts on why the resquash test would fail for this snap? Snapcraft uses snap pack. Could it be related to the kernel on the builders or the test machine where this is run? But also, it only seems to be affecting this snap (anecdotal, I don’t have access to all the uploads and have not seen any other reports here).
I did release Wekan newest version for other platforms like Docker/Source/Sandstorm etc, but all Snap builds failed. About 9000 servers wordwide use Wekan Snap packages and are now without updates. There is often Node.js etc security updates.
The Snap Store package reviewing servers were updated to Ubuntu 20.04 (Focal) on July 5th. This matches the timing of when your failures started; your last successful wekan build was on 2021-07-05 13:33, the first failed build was on 2021-07-06 19:09, and the servers were updated on 2021-07-05 16:41 (all times are UTC).
I have confirmed that your snap passes automated review on a bionic system with squashfs-tools 4.3-6ubuntu0.18.04.2, and fails on a focal system with 4.4-1.
While we investigate further, one thing you could do is request manual review of revisions you want to publish, and we can likely override the unsquashfs check on our side, assuming the other more security-minded reviewers are fine with that.
But for Caddy, I only have that x64 binary from newest download of old Caddy v1. Other binaries could be built from https://github.com/caddyserver/caddy/tree/v1 , but Caddy has moved to Caddy v2 with not-so-compatible-yet adapter for v1 Caddyfile config format https://caddy.community/t/caddyfile-v1-adapter/9129 , that means some of those 9000 Wekan servers wordwide are still running old unmaintained Caddy v1 with it’s Caddyfile config format. And, if I would try to figure out, is there better Caddy v1 config format adapter now in Caddy, or should I try to contribute it myself as pull request (if it’s not too complex so Caddy devs would accept it), or how I could get it updated. Or alternatively, just only include Caddy v2 and leave configuration with examples to each server admin, but, that’s kind of not-automatic-upgrade, and too much manual work.
squashfs-tools 4.4. introduced reproducible mksquashfs output by default so I suspect this is the culprit. Perhaps snapcraft and review-tools should both be ported to core20 so they can get squashfs-tools 4.4 as a result? Thoughts @sergiusens?
@alexmurray@emitorino given that wekan is a known-good build and we’ve traced this down to the squashfs 4.3.x vs. 4.4 difference, are you OK with at least manually approving the revisions @xet7 noted above?
It was just pointed out to me that this snap is not using a base, triggering the use of snapcraft from the deb when used with launchpad which is probably using a 16.04 version of mksquashfs.
To answer your question @alexmurray, Snapcraft is moving to core20 for Snapcraft 6.0 (Snapcraft's 21.10 Roadmap), but Snapcraft packs using the snap command from snapd so Snapcraft’s move to core20 should not affect this.
hmm so snap pack will use the mksquashfs from the snapd snap which is from the 16.04 version of squashfs-tools…so I would have thought this would be the same as what LP is using when the deb is used … no?
@xet7 Hi there - I’ve been digging into this (lots of fun). I think you could get the build working again if you make post-refresh an actual file instead of a symlink to install (https://github.com/wekan/wekan/tree/master/snap/hooks). Just rm post-refresh && cp install post-refresh should do it. No promises, but maybe worth a try while we get a real fix out.