Check the input hash

[Maximvdw]

Check the input hash to match the 1649 build. Since it only allows the 1649 build (and a hash never changes) this should be an additional check

[md-5]

This isn't very extensible. Additionally the bps patch files themselves contain a crc32 of the file which they apply against, so this is already covered.

[shoghicp]

The CRC32 can be easily spoofed

[rlf]

I agree with you both.
a) There should be a better error-description (given the number of posts on the forum related to the wrong jar file used).
and
b) Hardcoding it isn't the best solution.

So, let's just figure out a way to better help the user, when the appropriate exception is thrown from jbeat.

[md-5]

The CRC32 can be easily spoofed
True, the input jar can be spoofed, however is it really possible to produce a patch with a spoofed crc which applies to a spoofed jar to which a spoofed crc matches. Thats 3 crc collisions in one. If we want to add more validation, we should read and embed the md5 in the BPS patch meta.

[Maximvdw]

Don't really get why hardcoding it is not good in this situation

1. We don't need this patcher if we can use the DMCA'd code again (= new builds)
2. At the moment the only verification people use is comparing the MD5 on the homepage with their Jar file. This just makes it a bit safer
3. Everything can be bypassed. Who knows maybe they even use the wrong patcher.
4. The input file (1649 build) will never just change hash unless it starts mutating

[jhead]

Spigot provides the required input checksum via an md5 file with the same name as the patch here: http://spigotmc.org/spigot-updates/

You can easily verify the input file prior to launching the patcher using a script.
ie. as I've done here: https://gist.github.com/jhead/52323a4e6483c637b2e4

[ghost]

I don't think this is such a good idea.

Daniel