4 ms·

Do the above steps generate an actual signed release, or just a signed tag?

by dsp1234 11y ago

creshal 11y ago
A tag, not a release. I didn't realize there was a difference, but in hindsight, I'd argue it's superior anyway: I'm much more comfortable to sign my local repository copy than signing an archive generated by github in a non-reproducible way. I can verify the contents of github's archives, but I cannot, in good faith, say I've verified that the archives do not contain malicious code that triggers vulnerabilities in zip/tar/gzip.
- chungy 11y ago
  Reproducing GitHub's archives locally is trivial. They just use a standard git command to do it anyway. git archive -o project-0.5.tar.gz --prefix project-0.5/ v0.5
  - creshal 11y ago
    I think we have different standards for "reproducible". You can replicate the archive structure and naming, but the archive metadata – and thus checksums – will be different: $ curl -sL https://github.com/creshal/yspave/archive/0.1.0.zip https://github.com/creshal/yspave/archive/0.1.0.zip | sha512sum 375564f127b46f3d1208c30b4eb5c39725985ca09d7bacf940d346727e8bcf9362966f8523c39e6c4f6f1a86b52ceba8823c2f4b016fdedb5947cd6a6bafc930 - $ git clone git@github.com:creshal/yspave.git … $ cd yspave $ git archive -o 0.1.0.zip --prefix yspave-0.1.0/ 0.1.0 $ sha512sum 0.1.0.zip aca1163d5270e8ad6796f10511f49b0cf5fe61007fed0786a6643ae522e59a6aa7d6b0cddf4e5b94a435da8d99aa09b2f2ebef7788a82d4c2e7d8d4ad79e0634 0.1.0.zip ––––– So, I can verify that the contents weren't tampered with, but I cannot verify the archives themselves unless I happen to understand the zip/tar/gz… specifications better than most people implementing it.
    - chungy 11y ago
      That's interesting. I'm not able to replicate your results. Cloning that respository and doing the same git archive command produces an identical file to what GitHub serves. I'm on a fully updated Arch Linux with the latest Git. If you have an older version, that might be making the difference.
      - Xylakant 11y ago
        I can reproduce the result: The content of the file is identical, the checksum differs.
        deleted 11y ago
        [deleted]
      - creshal 11y ago
        > I'm on a fully updated Arch Linux with the latest Git. Same, actually.
    - Xylakant 11y ago
      you can verify by downloading the archive and comparing the content of the archive with the content of the archive produced by git archive. The issue seems to be that the zip file contains the version of the zip utility used to create the file, so you'd need the exact same version to make a reproducible build.
    - yrro 11y ago
      According to diffoscope, the (only) differences are in the archive member modification times: --- ../0.1.0.zip +++ 0.1.0.zip ├── zipinfo -v {} │ @@ -28,15 +28,15 @@ │ file system or operating system of origin: MS-DOS, OS/2 or NT FAT │ version of encoding software: 0.0 │ minimum file system compatibility required: MS-DOS, OS/2 or NT FAT │ minimum software version required to extract: 1.0 │ compression method: none (stored) │ file security status: not encrypted │ extended local header: no │ - file last modified on (DOS date/time): 2016 Apr 8 06:33:12 │ + file last modified on (DOS date/time): 2016 Apr 8 14:33:12 │ file last modified on (UT extra field modtime): 2016 Apr 8 13:33:13 local │ file last modified on (UT extra field modtime): 2016 Apr 8 13:33:13 UTC │ 32-bit CRC value (hex): 00000000 │ compressed size: 0 bytes │ uncompressed size: 0 bytes │ length of filename: 13 characters │ length of extra field: 9 bytes │ @@ -63,15 +63,15 @@ │ version of encoding software: 0.0 │ minimum file system compatibility required: MS-DOS, OS/2 or NT FAT │ minimum software version required to extract: 1.0 │ compression method: deflated │ compression sub-type (deflation): normal │ file security status: not encrypted │ extended local header: no │ - file last modified on (DOS date/time): 2016 Apr 8 06:33:12 │ + file last modified on (DOS date/time): 2016 Apr 8 14:33:12 │ file last modified on (UT extra field modtime): 2016 Apr 8 13:33:13 local │ file last modified on (UT extra field modtime): 2016 Apr 8 13:33:13 UTC │ 32-bit CRC value (hex): 570b4391 │ compressed size: 52 bytes │ uncompressed size: 78 bytes │ length of filename: 23 characters │ length of extra field: 9 bytes │ @@ -97,15 +97,15 @@ │ file system or operating system of origin: Unix │ version of encoding software: 2.3 │ minimum file system compatibility required: MS-DOS, OS/2 or NT FAT │ minimum software version required to extract: 1.0 │ compression method: none (stored) │ file security status: not encrypted │ extended local header: no │ - file last modified on (DOS date/time): 2016 Apr 8 06:33:12 │ + file last modified on (DOS date/time): 2016 Apr 8 14:33:12 │ file last modified on (UT extra field modtime): 2016 Apr 8 13:33:13 local │ file last modified on (UT extra field modtime): 2016 Apr 8 13:33:13 UTC │ 32-bit CRC value (hex): bc890775 │ compressed size: 59 bytes │ uncompressed size: 59 bytes │ length of filename: 20 characters │ length of extra field: 9 bytes (rest of output omitted as it's too long for an HN comment; the full output can be found at http://paste.debian.net/432708/ http://paste.debian.net/432708/)
  - creshal 11y ago
    Ahh, never mind. The tar.gz is indeed identical, "only" the zip differs.
- dsp1234 11y ago
  I'm much more comfortable to sign my local repository copy than signing an archive generated by github Both can be part of the process. However, signing the tag doesn't really help someone who isn't cloning the repository. For those people that are just downloading the source tarball directly, having a GPG signature for the release can ensure that github(or other attacker) hasn't modified the contents of the tarball.
  - ownagefool 11y ago
    Sort of. I mean if github wants to modify the contents of the tarball, they'll also modify the signature. So unless you're also confirming that it's the right signature, and not just that it's signed, what exactly are you doing?
    - ashitlerferad 11y ago
      That is where signing other people's OpenPGP keys comes in, and the web of trust for those who haven't met their upstreams. github can also modify signed tags.

Do the above steps generate an actual signed release, or just a signed tag?

by dsp1234 11y ago

Do the above steps generate an actual signed release, or just a signed tag?

A tag, not a release. I didn't realize there was a difference, but in hindsight, I'd argue it's superior anyway: I'm much more comfortable to sign my local repository copy than signing an archive generated by github in a non-reproducible way. I can verify the contents of github's archives, but I cannot, in good faith, say I've verified that the archives do not contain malicious code that triggers vulnerabilities in zip/tar/gzip.

chungy 11y ago
Reproducing GitHub's archives locally is trivial. They just use a standard git command to do it anyway. git archive -o project-0.5.tar.gz --prefix project-0.5/ v0.5
- creshal 11y ago
  I think we have different standards for "reproducible". You can replicate the archive structure and naming, but the archive metadata – and thus checksums – will be different: $ curl -sL https://github.com/creshal/yspave/archive/0.1.0.zip https://github.com/creshal/yspave/archive/0.1.0.zip | sha512sum 375564f127b46f3d1208c30b4eb5c39725985ca09d7bacf940d346727e8bcf9362966f8523c39e6c4f6f1a86b52ceba8823c2f4b016fdedb5947cd6a6bafc930 - $ git clone git@github.com:creshal/yspave.git … $ cd yspave $ git archive -o 0.1.0.zip --prefix yspave-0.1.0/ 0.1.0 $ sha512sum 0.1.0.zip aca1163d5270e8ad6796f10511f49b0cf5fe61007fed0786a6643ae522e59a6aa7d6b0cddf4e5b94a435da8d99aa09b2f2ebef7788a82d4c2e7d8d4ad79e0634 0.1.0.zip ––––– So, I can verify that the contents weren't tampered with, but I cannot verify the archives themselves unless I happen to understand the zip/tar/gz… specifications better than most people implementing it.
  - chungy 11y ago
    That's interesting. I'm not able to replicate your results. Cloning that respository and doing the same git archive command produces an identical file to what GitHub serves. I'm on a fully updated Arch Linux with the latest Git. If you have an older version, that might be making the difference.
    - Xylakant 11y ago
      I can reproduce the result: The content of the file is identical, the checksum differs.
      - deleted 11y ago
        [deleted]
    - creshal 11y ago
      > I'm on a fully updated Arch Linux with the latest Git. Same, actually.
  - Xylakant 11y ago
    you can verify by downloading the archive and comparing the content of the archive with the content of the archive produced by git archive. The issue seems to be that the zip file contains the version of the zip utility used to create the file, so you'd need the exact same version to make a reproducible build.
  - yrro 11y ago
    According to diffoscope, the (only) differences are in the archive member modification times: --- ../0.1.0.zip +++ 0.1.0.zip ├── zipinfo -v {} │ @@ -28,15 +28,15 @@ │ file system or operating system of origin: MS-DOS, OS/2 or NT FAT │ version of encoding software: 0.0 │ minimum file system compatibility required: MS-DOS, OS/2 or NT FAT │ minimum software version required to extract: 1.0 │ compression method: none (stored) │ file security status: not encrypted │ extended local header: no │ - file last modified on (DOS date/time): 2016 Apr 8 06:33:12 │ + file last modified on (DOS date/time): 2016 Apr 8 14:33:12 │ file last modified on (UT extra field modtime): 2016 Apr 8 13:33:13 local │ file last modified on (UT extra field modtime): 2016 Apr 8 13:33:13 UTC │ 32-bit CRC value (hex): 00000000 │ compressed size: 0 bytes │ uncompressed size: 0 bytes │ length of filename: 13 characters │ length of extra field: 9 bytes │ @@ -63,15 +63,15 @@ │ version of encoding software: 0.0 │ minimum file system compatibility required: MS-DOS, OS/2 or NT FAT │ minimum software version required to extract: 1.0 │ compression method: deflated │ compression sub-type (deflation): normal │ file security status: not encrypted │ extended local header: no │ - file last modified on (DOS date/time): 2016 Apr 8 06:33:12 │ + file last modified on (DOS date/time): 2016 Apr 8 14:33:12 │ file last modified on (UT extra field modtime): 2016 Apr 8 13:33:13 local │ file last modified on (UT extra field modtime): 2016 Apr 8 13:33:13 UTC │ 32-bit CRC value (hex): 570b4391 │ compressed size: 52 bytes │ uncompressed size: 78 bytes │ length of filename: 23 characters │ length of extra field: 9 bytes │ @@ -97,15 +97,15 @@ │ file system or operating system of origin: Unix │ version of encoding software: 2.3 │ minimum file system compatibility required: MS-DOS, OS/2 or NT FAT │ minimum software version required to extract: 1.0 │ compression method: none (stored) │ file security status: not encrypted │ extended local header: no │ - file last modified on (DOS date/time): 2016 Apr 8 06:33:12 │ + file last modified on (DOS date/time): 2016 Apr 8 14:33:12 │ file last modified on (UT extra field modtime): 2016 Apr 8 13:33:13 local │ file last modified on (UT extra field modtime): 2016 Apr 8 13:33:13 UTC │ 32-bit CRC value (hex): bc890775 │ compressed size: 59 bytes │ uncompressed size: 59 bytes │ length of filename: 20 characters │ length of extra field: 9 bytes (rest of output omitted as it's too long for an HN comment; the full output can be found at http://paste.debian.net/432708/ http://paste.debian.net/432708/)
- creshal 11y ago
  Ahh, never mind. The tar.gz is indeed identical, "only" the zip differs.
dsp1234 11y ago
I'm much more comfortable to sign my local repository copy than signing an archive generated by github Both can be part of the process. However, signing the tag doesn't really help someone who isn't cloning the repository. For those people that are just downloading the source tarball directly, having a GPG signature for the release can ensure that github(or other attacker) hasn't modified the contents of the tarball.
- ownagefool 11y ago
  Sort of. I mean if github wants to modify the contents of the tarball, they'll also modify the signature. So unless you're also confirming that it's the right signature, and not just that it's signed, what exactly are you doing?
  - ashitlerferad 11y ago
    That is where signing other people's OpenPGP keys comes in, and the web of trust for those who haven't met their upstreams. github can also modify signed tags.