Enhance support for Checksums

[theonlypwner]

Describe the enhancement

Continuation of #5130, #5138

• Support cksum format checksum size and checksum size name (not popular enough?)
• Add .digest and .cksum to extensions
• Add digest to aliases
• Support popular formats in .digest files

[theonlypwner]

@Alhadis, this is from #5130:

but is there a way to highlight it when it is explicitly specified, such as ```hash blocks in Markdown?

Unfortunately not. ```hash blocks are highlighted by the same mechanism responsible for highlighting a file's source-code. For all intents and purposes, they're exactly the same.

Don't the blocks below highlight differently? They are ```c, ```html, and ``` blocks, respectively.

int main() {} // <strong attr="val">HTML</strong>

int main() {} // <strong attr="val">HTML</strong>

int main() {} // <strong attr="val">HTML</strong>

Here's what I was trying to get at with that post:

Since the highlighting can be controlled by the info string after the three backticks, how does that work? Is it related to the aliases property? If so, can we use that to let users specify cksum specifically? Or is cksum not even popular enough for us to care about?

[Nixinova]

Since the highlighting can be controlled by the info string after the three backticks, how does that work? Is it related to the aliases property?

Yes, if the content of that infostring matches the language name or any of its aliases then that language is applied.

[Alhadis]

@theonlypwner Any of the aliases listed in languages.yml will activate checksum highlighting. Be aware that there's no correlation between which alias you pick and what checksums get highlighted; i.e., all supported checksum patterns will be highlighted, even if the code-block was tagged with, say, ```md5 (a hypothetical example, seeing as how md5 isn't currently supported as an alias).

If so, can we use that to let users specify cksum specifically? Or is cksum not even popular enough for us to care about?

I think we can add cksum as an alias. As a file-extension, a quick search for *.cksum files shows there's some usage on GitHub. You'll need to submit a pull-request and wait for @lildude to run an evaluation of its usage to know for sure, though.

[theonlypwner]

@Alhadis

there's no correlation between which alias you pick and what checksums get highlighted

My point was that if we create another language entry with aliases, filenames, and extensions specifically for cksum, we can highlight in the cksum format for only ```cksum blocks and *.cksum files because you said it's better to have no highlighting than wrong highlighting. Creating another language entry would create the correlation between the chosen alias and how the highlighting is performed.

But if the cksum format isn't popular enough, then it might not be necessary. In a search for *.cksum files, most results look like the SHA1SUMS file format, which is already supported. I would recommend adding .cksum to extensions, which I have added to the task list. I don't think it is necessary to add cksum to aliases.

---

I will also respond to your other comment from #5138:

Well, I can add support for patterns like this…

digest1:dwLYXWqDkzaJhlo1P6sQqpxgU5cBRRYM9Sna/buqhHIoAX6/np9fYp9Zbgb3Rc7I

… however, I'm unfamiliar with whatever program generates this kind of output, and I'd ideally like some authoritative reference on what formats are accepted in such lines (the example looks to be using base64, but I'd rather not go by guesswork if I can help it).

It seems like digest1: is an encryption prefix in GeoServer passwd files. That prefix, crypt1:, and crypt2: precede a base64 string, while plain: precedes a plaintext password. Should passwd-type files also be included in the Checksums language, or should that be in another language like passwd?

I could not find any other documentation for digest1.

Also, I noticed some files in the format name whitespace hash instead of hash whitespace name, which I hope either won't cause issues for the syntax highlighter or can be fixed later.

There's no foolproof way to tell name hash from a filename that contains spaces, followed by a word that happens to contain n alphanumeric characters. Conversely, a line that begins with precisely n characters is a little less ambiguous. Consider files that begin with arbitrary text (e.g., comments), or even files like this that aren't technically a checksum list, but are still highlighted non-intrusively.

If there's no foolproof way, should we just simply give up and not support the name hash format?