notpeter
Clean up grammar + add SHA256sums
I've added a bunch (not all) SHA256sums into the mix, and added some misc releases like Snow Leopard Server (10A403). There's still a lot more to be done with adding the remaining hashes and OS releases.
A few Q's:
- should the word checksum still be used? most people are used to the word "hash", although it is more vague.
- should the readme be split up by OS release? (10.10.x, 10.11.x, etc.)
- adding on to the second point: i have an org setup at https://github.com/hashcheck. is that too much effort for a small project like this?
Thanks!
@citrusui I kind of hope that a spinoff of this (or similar projects) involves into a huge database of checksums for all sorts of programs.
Thanks for the PR @citrusui!
There's been some discussion about SHA256 in #10 and my hesitation is the wide table (horizontal scroll bar) markdown as shown rendered on your branch.
@dodekeract I've been having similar thoughts. That work is on the [csv branch] (https://github.com/notpeter/apple-installer-checksums/tree/csv) where in I've been playing with more structured representation of data. Including easy hyde github pages html and [csv output] from the same json source.
But I'm mixed about loosing the simplicity of just markdown files with checksums.
I understand. I mean, we could add 7 more hash algorithms to the table because we can, but is it really useful? I don't think so.
Off-topic: I had a very similar idea about structured data and such! My idea is to create a website that allows you to search for hashes of macOS installers/Xcode. The front page would be very minimal, only containing a search bar, and once a user starts typing, results start to load. A interface somewhat similar to http://cssreference.io seems decent. Actual data containing lists of known hashes are stored as JSON and all that good stuff.
Of course, that's just a thought :P. I don't have the time to create a fully working prototype just yet.
is it really useful? I don't think so. — @citrusui
I actually think it is. Hear me out:
The way users find this project is by either searching for "macos installer checksums" or by searching for checksums directly. Now, we don't know if that specific user prefers SHA1 or SHA512 or even MD5. So this wouldn't be as useful for someone who already knows this, but it'd help people find the project by searching for checksums.
The maintenance work is only slightly increased. It's trivial to write a script that can auto-generate all checksums at once in the right format. Also, using multiple hash algorithms is a pretty damn safe way to guarantee that it's nearly impossible to ever create a second file with the same checksums, even if all individual algorithms are considered broken in the future.
@dodekeract Perhaps I should clarify:
There are a total of 33 cryptographic functions, as seen on Wikipedia.
Most of these we don’t need, like MD2 and MD4. Of course, it wouldn’t hurt to add these, just in case, but it would add overhead to the hashing process. With such a large number of hashes (which is bound to happen, no matter if we accept 1 or 33 hash functions), it would only be fitting that they are stored in JSON format, and if the JSON files become too big (very likely), they might not fit on GitHub.
Of course, to use JSON effectively, one would need to create a website to visualize the file hashes...
Edit: If the project ever were to expand, it would be a huge undertaking to begin hashing all the software you can think of. Think Homebrew formulae, but maybe 20x the size?
