Bug 285027 - makefs: cd9660 images w/ RockRidge extensions are not reproducible
Summary: makefs: cd9660 images w/ RockRidge extensions are not reproducible
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Only Me
Assignee: Ed Maste
URL:
Keywords: reproducible-builds
Depends on:
Blocks: 236081
  Show dependency treegraph
 
Reported: 2025-02-25 15:36 UTC by Ed Maste
Modified: 2025-03-04 20:59 UTC (History)
0 users

See Also:
emaste: mfc-stable14+


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ed Maste freebsd_committer freebsd_triage 2025-02-25 15:36:45 UTC
makefs' cd9660 Rock Ridge extension PX record stores the inode from the underlying filesystem, which makes the created ISO image nonreproducible.

Demonstration:

dir=$(mktemp -d)

# Create two files
touch $dir/a
touch $dir/b
makefs -t cd9660 -o R -o l=2 t1.iso $dir

# Copy the files so we have different inodes, and move copies to original names
cp -p $dir/a $dir/c
cp -p $dir/b $dir/d
mv $dir/c $dir/a
mv $dir/d $dir/b
makefs -t cd9660 -o R -o l=2 t2.iso $dir

rm -rf $dir

Diffoscope output:

--- t1.iso
+++ t2.iso
├── isoinfo -l -i {} -R
│┄ error from `isoinfo -l -i {} -R`:
│┄ Setting input-charset to 'UTF-8' from locale.
│ @@ -1,6 +1,6 @@
│  
│  Directory listing of /
│        9332 drwx------   2 1001    0       2048 Feb 25 2025 [     20 02] . 
│        9332 drwx------   2 1001    0       2048 Feb 25 2025 [     20 02] .. 
│ -      9991 -rw-r--r--   1 1001    0          0 Feb 25 2025 [     21 00] a 
│ -      9992 -rw-r--r--   1 1001    0          0 Feb 25 2025 [     21 00] b 
│ +      9951 -rw-r--r--   1 1001    0          0 Feb 25 2025 [     21 00] a 
│ +      9458 -rw-r--r--   1 1001    0          0 Feb 25 2025 [     21 00] b
Comment 1 Ed Maste freebsd_committer freebsd_triage 2025-02-25 15:38:59 UTC
PX inodes added here:

commit 516e01684419a7475cd3ce04d2777d56979e4a45
Author: Marius Strobl <marius@FreeBSD.org>
Date:   Sun Dec 29 16:43:35 2013 +0000

    Record the IEEE P1282 Rock Ridge version 1.12 POSIX File Serial Number,
    i. e. the POSIX:5.6.1 st_ino field, which can be used to detect hard links
    in the file system. This is also the default in mkisofs(8) and according to
    its man page, no system only being able to cope with Rock Ridge version 1.10
    is known to exist.
    
    PR:             185138
    Submitted by:   Kurt Lidl
    MFC after:      1 week
Comment 2 Ed Maste freebsd_committer freebsd_triage 2025-02-26 19:02:51 UTC
A potential approach in https://reviews.freebsd.org/D49141
Comment 3 commit-hook freebsd_committer freebsd_triage 2025-02-28 20:36:20 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/src/commit/?id=518cdd344ec51584478f39b9a9cac77fc0766ce1

commit 518cdd344ec51584478f39b9a9cac77fc0766ce1
Author:     Ed Maste <emaste@FreeBSD.org>
AuthorDate: 2025-02-26 16:44:12 +0000
Commit:     Ed Maste <emaste@FreeBSD.org>
CommitDate: 2025-02-28 20:34:52 +0000

    makefs: Make cd9660 Rock Ridge inodes reproducible

    Rock Ridge extensions include an inode field:

        "POSIX File Serial Number" shall have the same meaning as and may be
        used for the st_ino field of POSIX:5.6.1. This field shall be
        recorded according to ISO 9660:7.3.3. Directory Records which share
        the value of this field are defined as links (see POSIX:2.2.2.17)
        and, by definition, point to the same file or directory.

    Previously we'd store the source file's st_ino (except that in metalog
    mode we'd record 0 for files with nlink = 1).  This had two issues: the
    generated ISO image was nonreproducible due to the arbitrary inode
    numbers, and files without hard links would falsely be detected (by
    certain tools) as hard links to each other.

    Note that the kernel's cd9660(5) file system ignores the Rock Ridge
    PX File Serial Number, so this issue isn't observed by mounting such a
    file system.

    Instead of using the source inode directly, assign target inode numbers
    sequentially.  Use a map so that files with the same source inode (hard
    links) still receive the same target inode number.

    PR:             284795
    PR:             285027
    Reviewed by:    brooks
    Sponsored by:   The FreeBSD Foundation
    Differential Revision: https://reviews.freebsd.org/D49141

 usr.sbin/makefs/cd9660.h              | 12 +++++++
 usr.sbin/makefs/cd9660/iso9660_rrip.c | 67 ++++++++++++++++++++++++++++++-----
 usr.sbin/makefs/cd9660/iso9660_rrip.h |  2 +-
 3 files changed, 71 insertions(+), 10 deletions(-)
Comment 4 commit-hook freebsd_committer freebsd_triage 2025-03-04 20:59:25 UTC
A commit in branch stable/14 references this bug:

URL: https://cgit.FreeBSD.org/src/commit/?id=e4bcef6daba71546570c623e6091fdef982a596b

commit e4bcef6daba71546570c623e6091fdef982a596b
Author:     Ed Maste <emaste@FreeBSD.org>
AuthorDate: 2025-02-26 16:44:12 +0000
Commit:     Ed Maste <emaste@FreeBSD.org>
CommitDate: 2025-03-04 20:57:26 +0000

    makefs: Make cd9660 Rock Ridge inodes reproducible

    Rock Ridge extensions include an inode field:

        "POSIX File Serial Number" shall have the same meaning as and may be
        used for the st_ino field of POSIX:5.6.1. This field shall be
        recorded according to ISO 9660:7.3.3. Directory Records which share
        the value of this field are defined as links (see POSIX:2.2.2.17)
        and, by definition, point to the same file or directory.

    Previously we'd store the source file's st_ino (except that in metalog
    mode we'd record 0 for files with nlink = 1).  This had two issues: the
    generated ISO image was nonreproducible due to the arbitrary inode
    numbers, and files without hard links would falsely be detected (by
    certain tools) as hard links to each other.

    Note that the kernel's cd9660(5) file system ignores the Rock Ridge
    PX File Serial Number, so this issue isn't observed by mounting such a
    file system.

    Instead of using the source inode directly, assign target inode numbers
    sequentially.  Use a map so that files with the same source inode (hard
    links) still receive the same target inode number.

    PR:             284795
    PR:             285027
    Reviewed by:    brooks
    Sponsored by:   The FreeBSD Foundation
    Differential Revision: https://reviews.freebsd.org/D49141

    (cherry picked from commit 518cdd344ec51584478f39b9a9cac77fc0766ce1)
    (cherry picked from commit 337f5e7a44c4d5ac29e0b0c0fe957bb3b9bae222)
    (cherry picked from commit a18be39aafc1b55fd67603ee6a6d820d0fcd877f)

 usr.sbin/makefs/cd9660.h              | 13 +++++++
 usr.sbin/makefs/cd9660/iso9660_rrip.c | 73 ++++++++++++++++++++++++++++++-----
 usr.sbin/makefs/cd9660/iso9660_rrip.h |  2 +-
 3 files changed, 78 insertions(+), 10 deletions(-)