Hi, On Thu, 2020-04-23 at 23:29 +0300, Hannu Nyman wrote: > W. Michael Petullo kirjoitti 23.4.2020 klo 19.50: > > I have started to notice a gunzip warning when decompressing the > > OpenWrt images I build. This is with master df27e949: > > > > gunzip openwrt/bin/targets/x86/64/openwrt-x86-64-generic-ext4- > > combined.img.gz -c >/dev/null > > gzip: openwrt-aquinas-git/bin/targets/x86/64/openwrt-x86-64-generic- > > ext4-combined.img.gz: decompression OK, trailing garbage ignored > > > > Aside from the warning, gunzip exits with a code of 2. The gunzip man > > page indicates that an exit code of 2 indicates a warning. > > > > Is this a result of an intended change? Should I expect this to > > continue? Are we sneaking a hash or signature in there? If so, I > > suppose I will adjust some of the scripts I use to account for the > > non-zero exit code. > > Likely we are attaching a signature since commit f81412160 a week ago: > > https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=f814121600e5cf43fd75fe93e5b1b54f65b71bcd >
The sysupgrade process automatically handels compressed images, however the validation does not. Currently fwtool validation in /usr/lib/fwtool.sh reads the sysupgrade(.gz) as is: if ! fwtool -q -s /tmp/sysupgrade.ucert "$1"; then A fix could be to use "append-metadata | gzip" for the firmware images and then unpack the firmware before validating it's signature and metadata, e.g. with the following command in fwtool.sh source /usr/bin/common.sh if ! get_image "$1" | fwtool -q -s /tmp/sysupgrade.ucert -; then This worked in my qemu test, not tested on a real hardware. Rafał Miłecki worked recently on the validation, maybe he can share an opinion. Best, Paul _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel