Need sha256 stable mkinitcpio images

GI Jack · 2014-02-17 03:51:49

for the longest time, CPIO images made with mkinitcpio used to be strictly reproducable from a security minded standpoint, that with the same versions, and the same config, mkinitcpio would make images that were exact copies. Exact to the point they would match hash sums.

for a project I am working on, I need this reproducability, mostly as a security check, that re-made mkinitcpio images will pass SHA256/GPG verification tests.

falconindy · 2014-02-17 16:54:14

I don't believe this has ever been true.

Older versions (~3 years ago) of mkinitcpio used to use a utility called gen_init_cpio (sources shipped with the kernel as usr/gen_init_cpio.c) to create the initramfs images. While this utility will preserve the mtimes of files, it will not preserve mtimes of directories and symlinks -- it instead uses the start time of the run (unless you pass the -t flag, which mkinitcpio didn't do). Inode numbering is made "stable" by starting with a seemingly arbitrary value of 721 and incrementing for each entry written.

Starting with mkinitcpio 0.7, bsdcpio is used to generate the images. In this case, none of the mtimes are preserved. Instead, the current time is used for everything (this smells like a bug). I also notice that the inode field is filled with junk. This also sounds like an upstream bug, but I haven't looked into the code yet. The inode field is fairly useless and only comes into play when dealing with hard links.

Regardless, this means that the only case where one can generate a hash-identical pair of images using either of these methods would be to use gen_init_cpio with a filelist containing only files. There's a slim chance that this would be a bootable image, and an even slimmer chance that this was created by mkinitcpio at any point in its history.

falconindy · 2014-02-17 17:28:09

Sorry, misspoke about bsdcpio's behavior. mtimes are correctly preserved where possible, but this still leaves inodes "randomized". mkinitcpio doesn't preserve mtimes because files are copied into a staging directory before being archived. Inodes are taken directly from the inodes on disk, which is the correct behavior for an archiving tool.

One could "fix" the mtime issue partially, but this still won't give you reproducible builds in any case.

Last edited by falconindy (2014-02-17 17:32:58)

falconindy · 2014-02-18 15:21:40

Responding to myself again, because I find myself rather interested by this topic.

More data points: Both initramfs-tools and dracut will not yield hash-identical images from successive runs with the same configuration. I was also pointed to a relevant bug from the OSTree camp who've attempted to fix this. They correctly point out the same problems that I've discussed above: mtimes and inodes. The mtime problem has an easy solution: just set everything to the epoch (january 1, 1970). The inode issue is tougher, but solvable. I might implement these two "fixups" behind a flag in mkinitcpio.

GI Jack · 2014-02-19 21:56:12

wow, thanks a million, I might be able hack something together in the meantime, but in any case, thanks for pointing me in the right dirrection.

edit: I don't know why it worked, but it used to work, up until about 2-3 months ago.

Last edited by GI Jack (2014-02-28 02:34:09)

Arch Linux

#1 2014-02-17 03:51:49

Need sha256 stable mkinitcpio images

#2 2014-02-17 16:54:14

Re: Need sha256 stable mkinitcpio images

#3 2014-02-17 17:28:09

Re: Need sha256 stable mkinitcpio images

#4 2014-02-18 15:21:40

Re: Need sha256 stable mkinitcpio images

#5 2014-02-19 21:56:12

Re: Need sha256 stable mkinitcpio images

Board footer