PfSense image hashes, folly?

  • LAYER 8 Netgate

    Isn't it kind of silly to upload MD5 and SHA256 hashes to the same mirrors hosting the images?

    If someone can insert a bad image, can't they just insert a corresponding hash file to match?

    Shouldn't there, instead, be PGP signatures?

    Or at least a PGP-signed block of text in some release notes, blog post, etc. containing the image file names and what they should hash to?

  • Netgate Administrator

    The release images are signed. The MD5 hashes are really there so you can check the download was not corrupted.


    Note if you're installing an image from the snapshots server, you will receive a warning that "The digital signature on this image is invalid." This is normal, the snapshot releases are built automatically and signing them requires manual intervention so none of the snapshot releases are signed.


  • LAYER 8 Netgate

    Isn't that only true for upgrades, not new installs downloading, say, pfSense-LiveCD-2.1-RELEASE-amd64.iso.gz ??

  • I have my ISOs hand delivered from PFsense HQ to ensure integrity.

    But, what scheme would you suggest for the masses?

  • Netgate Administrator

    Derelict suggests signed hashes. Doesn't seem unreasonable.


  • Yeah - How do you implement it in a way that can't be forged?  (I'm not web guru)
    I'd assume the entire site would have to be something other than flat http?

  • LAYER 8 Netgate

    Electric Sheep Fencing generates a PGP key and signs all release announcements which would include hashes of the release distribution files.

    That way there would at least be something to check.  And it could be checked even if the files were downloaded from Russian warez sites.

    There could also be PGP signatures generated for every file alongside the existing md5 and sha256 hashes.  Either way, doesn't matter.

    Emailed security announcements could be signed as well.

    The public key could also be used to encrypt security vulnerability discoveries to the team if that situation should arise.

  • LAYER 8 Netgate

    Recent email I received.  This has value to me, maybe not to anyone else:

    Hash: RIPEMD160


    This is a prior notice email to permit postmasters to preload PGP keys
    needed for validating the next Exim release.

    Two of the team members, Todd Lyons and Jeremy Harris, shall
    soon start the work of cutting the Exim 4.82 release and beginning the
    RC series.

    We currently expect that the 4.82 Release Candidates, final Release, and
    announcement message shall be PGP signed using Todd's key:


    This key is in the PGP strong set, although it does not at time of
    writing include any signatures directly from any other UIDs.
    There is a trust path from my key to Todd's via a key belonging to Phil
    Dibowitz, 0x3795E8C5A1E732BB.

    For the record: I know Mr Dibowitz as a former colleague, he is very
    security conscious and does not issue PGP signatures without diligent
    checking.  He's the author of the PGP tutorial documentation available
    at <http:"" pgp="">and is one of the few people to whose keys
    I assign a GnuPG trust ranking of '4'.  Thus I have a high degree of
    confidence in this trust path.

    You can retrieve Todd's key from any of the normal PGP keyservers; for

    (click on the keyid in the "pub" line at the top).

    This Exim release is long overdue and I'd like to take this opportunity
    to thank Todd and Jeremy for stepping up to make it happen.


    • -Phil Pennock
      -----BEGIN PGP SIGNATURE-----

    -----END PGP SIGNATURE-----</http:>

  • LAYER 8 Netgate

    #NSA #BUMP

Log in to reply