H Jacques,
thanks for your elaborate response.
I'm well aware of the SHA1 issue and all theory behind it but simply do
not see where the real threat is for the user in this special case. We
have a fixed url to download the files from a trusted source and
compare their checksums against the ones we have computed from those
files before, all in our own script. There is no threat like downloading
from anywhere else, any breakage or password scenario etc., hence my
question for the *real* threat for our case.
I'm not against changing this for the 17.12 release, I just don't see
the necessity. Please do as you please.
Thanks,
Michael
Am 12.04.21 um 11:43 schrieb Jacques Le Roux:
Hi Michael,
Le 11/04/2021 à 23:01, Michael Brohl a écrit :
As a user, I would find it annoying if the files would be deleted
just because I have not the right tools installed on the system.
This would stop the whole process of building and running OFBiz. We
already have the warning, let's leave the decision to the user.
Fortunately, though it was not obvious at start, I did not cross this
issue with Windows where PowerShell is reigning.
As Vladimir mentioned it's more complicated with Linux distributions.
If it's OK for the team, it's OK with me.
Can you explain where the real vulnerability is with the file checksums?
That's a weird question you ask. Don't we know all that SHA-1 is now
"deprecated"[1][2][3]?
You are lucky, I got some time to seriously answer. At
https://www.keylength.com/en/4/ I read:
(1) Algorithms and key lengths for 80-bit security strength may be
used because of their use in legacy applications (i.e., they can be
used to
process cryptographically protected data). They shall not be used
for applying cryptographic protection (e.g., encrypting).
(2) SHA-1 has been demonstrated to provide less than 80 bits of
security for digital signatures, which require collision resistance.
In 2020, the
security strength against digital signature collisions remains a
subject of speculation.
At https://www.keylength.com/en/compare/ look for recommended hashes
lengths, much more than what SHA-1 is capable.
Among others, at https://www.keylength.com/en/8/ the German federal
office for information security, BSI, recommends to use SHA-256 for
hashes. And BTW, that's what Gradle is using[7].
Another is https://www.keylength.com/en/3/ :
Recommended algorithms:
Hash Functions: For near term use, SHA-256 and for long term use,
SHA-512 and SHA-3 with a 512-bit result.
I don't see why you are so braced on this question, changing from
SHA-1 to SHA-256 in this case is really easy, isn't?
I note we are using SHA-512 for our releases checking, good.
Not really related, Federal Reserve Chairman Jerome Powell said recently:
<<cyber attacks on financial institutions are the Fed’s biggest
concern at the moment.>>[4]
Of course it's a bit politic from Powell. And I guess OFBiz is not
used by "financial institutions". But, as Scott mentioned in end of
2016[5] that's another warning after all the increasing DB crackings
since (you name it).
I could go on and on, like with my answer[6] at and we have still work
pending with passwords which are for now less at risk thanks to
salting passwords Adam's works
[1] https://en.wikipedia.org/wiki/SHA-1 Notably "publishing two
dissimilar PDF files which produced the same SHA-1 hash"
[2]
https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html?m=1
BTW you sent this one more than 4 years ago
[3] https://issues.apache.org/jira/browse/OFBIZ-10843 More links
there, notably in 2020 https://sha-mbles.github.io/ . I still want to
work on that...
[4] https://s.apache.org/grh4f
[5] https://markmail.org/message/rt3r6u4uyk4hbv4h
[6] https://markmail.org/message/yqybsqzigrqbyxgf
[7]
https://docs.gradle.org/current/userguide/gradle_wrapper.html#wrapper_checksum_verification
I hope you appreciated my answer
Jacques
Regards,
Michael
Am 11.04.21 um 19:29 schrieb Jacques Le Roux:
