On Mon, Dec 14, 2020 at 9:20 PM Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> wrote: > > On Mon, Dec 14, 2020 at 03:32:57PM -0800, Brian C. Lane wrote: > > The problem I see with dropping it is that without it you do not know if > > there are errors in the packages you are installing. With non-live > > installs you can depend on rpm to detect that, but not with live since > > we're just copying the files over. > > With the live media, though, it's a squashfs that gets uncompressed, right? > > I just did a very rudimentary test of copying the Fedora Workstation 33 > squashfs.img and injecting a single random bit flip 1000 times, then running > unsquashfs. Of these 1000 tests, the result was a failure to unpack (with an > error code) every single time. Squashfs doesn't have error detection for its metadata or the data contained in it. I'm not sure why you're having such a high success rate. Whether lossy or lossless compression algorithms in images, my experience it is only sometimes results in an error, often we just get artifacts. i.e. a bit flip turns into multiple wrong bytes of image data, sometimes an entire row of pixels gets obliterated (thousands). It just depends on what gets hit. But maybe lzma, which is what xz is based on and what's used in squashfs images currently, could be particularly susceptible to bit flips translating into something detectable. But also, we're not using unsquashfs for boot or installation. The squashfs image is loop mounted and treated as a random access file system. Decompression of blocks is on demand. > I'm sure this isn't a cryptographically-secure verification, but it seems > like a decent enough practical one. Am I missing something? It seems like > the case of the live cd booting successfully but then installing a corrupted > system is astronomically unlikely. If there is random corruption of typical size on a USB stick, will it manifest in some way that stops the installation? I wouldn't bet on it unless it's based one a design that's intended to detect such incidental corruptions. -- Chris Murphy _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
