I'm not happy with that solution. Your PR weaken the checksum security.
Uppercase is different to lowercase. Period.

It's the update-server maintainers job to met the requirements of the Manifest's XML Checksum.
If it don't match, it don't match and rejecting it is the correct way.

From what i found the resulting hash is case insensitive: https://stackoverflow.com/questions/11892053/is-sha-256-case-insensitive
https://stackoverflow.com/questions/59871996/is-the-file-hashing-checksum-value-case-insensitive

So why should that weeken the security?

From what i found the resulting hash is case insensitive:
https://stackoverflow.com/questions/11892053/is-sha-256-case-insensitive

https://stackoverflow.com/questions/59871996/is-the-file-hashing-checksum-value-case-insensitive

So why should that weeken the security?

Simply because you exclude All uppercases from being used inside a
checksum, in case the characters match, but not the sizing.

Having Ae56GHffFF678 should treated be differently to aE56gHFFff678 easing
out by comparing them all lower (or upper-) case should not be done, when
the Joomla's XML requirements stating, that the checksum should be
lowercase (which is still wrong but at least a requirement)

And the best "answer" (from Stackoverflow, seriously?) stating "the algorithm is case-sensitive".

And so should be the input, everything else is weaking security.

on every paper i can have memory, on the lecterature, the exadecimal letters are always expressed with uppercase
just as a silly example ascii to ebcdic conversion table always use upper case ....
it could be for historic reason or for whatever else reason, but they are allways expressed with uppercase
so i don't like to change this "convention" for the sake of change

From what i found the resulting hash is case insensitive:
https://stackoverflow.com/questions/11892053/is-sha-256-case-insensitive

https://stackoverflow.com/questions/59871996/is-the-file-hashing-checksum-value-case-insensitive

So why should that weeken the security?

Simply because you exclude All uppercases from being used inside a
checksum, in case the characters match, but not the sizing.

Having Ae56GHffFF678 should treated be differently to aE56gHFFff678 easing
out by comparing them all lower (or upper-) case should not be done, when
the Joomla's XML requirements stating, that the checksum should be
lowercase (which is still wrong but at least a requirement)

And the best "answer" (from Stackoverflow, seriously?) stating "the algorithm is case-sensitive".

And so should be the input, everything else is weaking security.

Just to get it right the Algorithmen is case sensitive. And nothing else would make sense but the resulting string or better the hash sum, is a hex value and that is case insensitive.

Hashes and checksums are often presented in hexadecimal notation. Although it is common to use upper case A-F instead of lower case a-f, it does not make any difference.

https://stackoverflow.com/questions/59871996/is-the-file-hashing-checksum-value-case-insensitive

PHP will always return the hash hex value in lowercase as documented here:
https://www.php.net/manual/en/function.hash.php

raw_output
When set to TRUE, outputs raw binary data. FALSE outputs lowercase hexits.

(Where false is the default value as we usually just compare the hex value and not the binary data)

on every paper i can have memory, on the lecterature, the exadecimal letters are always expressed with uppercase
just as a silly example ascii to ebcdic conversion table always use upper case ....
it could be for historic reason or for whatever else reason, but they are allways expressed with uppercase
so i don't like to change this "convention" for the sake of change

Well as mention above php is defaulting to lowercase for the resulting hash values. I personally dont care which case we use i more like the lowercase as i think that easier to read but in this case its not displayed anyway.

With the change proposed here you can use any style that you prefere in the update.xml's right now you can just use the lowercase version that php provides.

With the change proposed here you can use any style that you prefere in
the update.xml's right now you can just use the lowercase version that php
provides.

I still don't see why Joomla should accept both.

If update server deliver the checksum in uppercase, that's a problem of
update server maintainer and can be easy fixed by send the checksum in
lowercase.

That should not be the job of Joomla.

When Joomla switches to case-sensitive Checksums of more secure algorithms
or other procedures (and that is just a matter of time, having the growing
power of Cloud capacity in mind..) it's another thing to be have to changed
back.

There is no real reason to accept this change, just for the lazyness not to
met the requirement of lowercase the checksum in the first place.

The question is:
It is already documented, that the checksum has to be in lowercase?

If yes, reject this pr.
If no, document the requirement and reject or accept this pr.

My point is that a checksum is a hex value which is case insensitive by definition, right? So why should we thread them case sensitive?

Additionally, when checksums are based on the hex-system, why don't Joomla
do not compare hex-wise, but instead implement a string comparison?

Edit: Aaah... the "magic type conversion" of PHP ...

I still have the impression, that the developer who wrote the check, intentionally used the case-sensitive check..

We compare hashes and we know our hashes are always in lowercase so also a attacker know this so an attacker wouldn't use uppercase hashes but on the other hand a ci that creates a hash automatically maybe better creating hashes in uppercase because used later somewhere else.

Anyway it's a silly discussion to compare a binary string that was converted to hex in upper or lower case if only one programmer doesn't spent one hour to find out the he/she needs to supply the string in lowercase instead of camelCase or what ever.

so please @innato update the pr and we can merge it if we get 2 tests.

Thanks

I agree with @HLeithner let's move on

Well, I still not agree.

It's clearly visible in the example for an update-server manifest.xml on docs.joomla.org as lowercase,
it's documented that Joomla in v4 will stop installation when comparision fail,
PHP own function produce as default lowercase,

so why change it?

Yes, an attacker who read the docs or analyse a manifest.xml will use lower case, all others who are not that smart, may fail because they try uppercase checksums.

So by allowing case-insensitive checksums, you give away 50% of security for every script-kid.
I don't think that's a silly discussion at all.

I have tested this item ✅ successfully on 4059d6a

So by allowing case-insensitive checksums, you give away 50% of security for every script-kid.

That assumption is just wrong: there security in this concept is created by the actual hashes, not by the question if the strings are compared case sensitive or case insensitive. The current case-insensitive compare is just wasting peoples time trying to debug issues related to it.

No developer would waste time if he take care of the documented example and also that Jommla will fail otherwise.
And that assumption is not wrong,

Either you compare checksum value AND case
OR
you just compare the value only.

Simple logic.

I've added the issue link into the post to get the issue.

I have tested this item ✅ successfully on 4059d6a

RTC

Thanks @innato for your first time contribution!

Thanks @innato ?

@HLeithner @zero24 Thanks for your kind remarks. It was an interesting first-time experience.