Different 10th byte gzip header between zlib and pako on Mac OS 13

[ciphrd]

Overview

The 10th byte of the gzip header is different between pako and zlib on Mac OS 13.5.1 (M2 chip)—untested on other OSs. Looking at the RFC 1952 / 2.3.1, pako seems to follow the spec by producing 0x03 as the 10th byte, while zlib produces 0x13. It seems weird as 0x13 doesn't refer to anything in the RFC spec, so Pako seems to follow the spec nicely here.

         OS (Operating System)
            This identifies the type of file system on which compression
            took place.  This may be useful in determining end-of-line
            convention for text files.  The currently defined values are
            as follows:

                 0 - FAT filesystem (MS-DOS, OS/2, NT/Win32)
                 1 - Amiga
                 2 - VMS (or OpenVMS)
                 3 - Unix
                 4 - VM/CMS
                 5 - Atari TOS
                 6 - HPFS filesystem (OS/2, NT)
                 7 - Macintosh
                 8 - Z-System
                 9 - CP/M
                10 - TOPS-20
                11 - NTFS filesystem (NT)
                12 - QDOS
                13 - Acorn RISCOS
               255 - unknown

I realise this isn't a Pako-related issue per-say, however I'm really curious as to why zlib would set the 10th byte to 0x13, so if eventually I get an answer to that or if anyone has it it'd be interesting to have it for posterity.

Minimal reproducing example

• node -v: 18.17.1
• pako: 2.1.0
• OS: Mac OS 13.5.1 (22G90); M2 chip

const pako = require("pako")
const zlib = require("node:zlib")

const input = Buffer.from(`random`)

const zlibZip = zlib.gzipSync(input) // 1f8b08000000000000132b4acc4bc9cf0500d5da3b1606000000
const pakoZip = pako.gzip(input)     // 1f8b08000000000000032b4acc4bc9cf0500d5da3b1606000000
                                     //                   ↑

[ciphrd]

Linking this issue on the zlib repo which is related: madler/zlib#320