PfSense image hashes, folly?

[Derelict]

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?

[stephenw10]

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

@https://doc.pfsense.org/index.php/Can_I_upgrade_my_pfSense_through_the_web_interface%3F:

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.

Steve

[Derelict]

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

[kejianshi]

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

But, what scheme would you suggest for the masses?

[stephenw10]

Derelict suggests signed hashes. Doesn't seem unreasonable.

Steve

[kejianshi]

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?

[Derelict]

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.

[Derelict]

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

–---BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Folks,

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

Two of the exim.org 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:

0xC4F4F94804D29EBA

This key is in the PGP strong set, although it does not at time of
writing include any signatures directly from any other @exim.org 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: phildev.net="" 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
instance:

http://ha.pool.sks-keyservers.net:11371/pks/lookup?op=vindex&search=0xC4F4F94804D29EBA

(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.

Regards,

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

iEYEAREDAAYFAlJBKwoACgkQQDBDFTkDY38YkQCfb7gyG7BTaRhRz45pJqUqg65d
KCkAn321P2lmc7nQWH/9XdbszN4PsjNQ
=djB8
-----END PGP SIGNATURE-----</http:>

[Derelict]

#NSA #BUMP