Re: [ofbiz-framework] branch release17.12 updated: Improved: Replace Bintray by a new place to upload the Gradle Wrapper (OFBIZ-12192)

Hi,

I think we should at least discuss the 2 points below before releasing 17.12.07

Thanks

Jacques

Le 10/04/2021 à 14:10, [hidden email] a écrit :

> This is an automated email from the ASF dual-hosted git repository.
>
> jleroux pushed a commit to branch release17.12
> in repository https://gitbox.apache.org/repos/asf/ofbiz-framework.git
>
>
> The following commit(s) were added to refs/heads/release17.12 by this push:
>       new 564b605  Improved: Replace Bintray by a new place to upload the Gradle Wrapper (OFBIZ-12192)
> 564b605 is described below
>
> commit 564b605d5509cd85f8d7b6355b4ebe62280e5686
> Author: Jacques Le Roux <[hidden email]>
> AuthorDate: Sat Apr 10 14:10:43 2021 +0200
>
>      Improved: Replace Bintray by a new place to upload the Gradle Wrapper (OFBIZ-12192)
>      
>      The checksum part was missing in Windows init-gradle-wrapper.ps1 script
>      
>      I have noticed 2 points:
>      1. We should use SHA256, not SHA1
>      2. The unix-like shell script in OFBiz misses checksum verification in case
>      shasum command is not installed. In other words, if I launch the script it would
>      fail with "shasum not found, the downloaded files could not be verified".
>      However, the file will be kept there, so the user could launch unverified jar.
>      
>      Last point was reported by Vladimir Sitnikov at LEGAL-288
> ---
>   gradle/init-gradle-wrapper.ps1 | 8 ++++++++
>   1 file changed, 8 insertions(+)
>
> diff --git a/gradle/init-gradle-wrapper.ps1 b/gradle/init-gradle-wrapper.ps1
> index c4911bd..2401147 100644
> --- a/gradle/init-gradle-wrapper.ps1
> +++ b/gradle/init-gradle-wrapper.ps1
> @@ -25,6 +25,14 @@ If ($ExecutionContext.SessionState.LanguageMode -eq "ConstrainedLanguage") {
>       Invoke-WebRequest -outf gradle\wrapper\gradle-wrapper.jar https://github.com/gradle/gradle/raw/v4.5.1/gradle/wrapper/gradle-wrapper.jar
>   }
>  
> +$expected = "00d0743607178962f8b120da4ccad2c64c698aec"
> +$actual = (Get-FileHash gradle\wrapper\gradle-wrapper.jar -Algorithm SHA1).Hash.ToLower()
> +@{$true = 'OK: Checksum match'; $false = "ERROR: Checksum mismatch!`nExpected: $expected`nActual: $actual"}[$actual -eq $expected]
> +
> +if (!$true)  {
> +    Remove-Item gradle\wrapper\gradle-wrapper.jar
> +    }
> +
>   #Write-Host $ExecutionContext.SessionState.LanguageMode
>  
>   Start-Sleep -s 3

[Michael Brohl-3]

Hi Jacques,

why should we change the checksum algorithm now, for this release? I
would leave it as is and introduce another one beginning with trunk.

For the shasum part: the program is needed for the checks, like other
programs (curl/wget, grep, whereis) are needed also. The script clearly
states that when shasum is missing. I see no problem with that.

Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 10.04.21 um 14:16 schrieb [hidden email]:

> Hi,
>
> I think we should at least discuss the 2 points below before releasing
> 17.12.07
>
> Thanks
>
> Jacques
>
> Le 10/04/2021 à 14:10, [hidden email] a écrit :
>> This is an automated email from the ASF dual-hosted git repository.
>>
>> jleroux pushed a commit to branch release17.12
>> in repository https://gitbox.apache.org/repos/asf/ofbiz-framework.git
>>
>>
>> The following commit(s) were added to refs/heads/release17.12 by this
>> push:
>>       new 564b605  Improved: Replace Bintray by a new place to upload
>> the Gradle Wrapper (OFBIZ-12192)
>> 564b605 is described below
>>
>> commit 564b605d5509cd85f8d7b6355b4ebe62280e5686
>> Author: Jacques Le Roux <[hidden email]>
>> AuthorDate: Sat Apr 10 14:10:43 2021 +0200
>>
>>      Improved: Replace Bintray by a new place to upload the Gradle
>> Wrapper (OFBIZ-12192)
>>           The checksum part was missing in Windows
>> init-gradle-wrapper.ps1 script
>>           I have noticed 2 points:
>>      1. We should use SHA256, not SHA1
>>      2. The unix-like shell script in OFBiz misses checksum
>> verification in case
>>      shasum command is not installed. In other words, if I launch the
>> script it would
>>      fail with "shasum not found, the downloaded files could not be
>> verified".
>>      However, the file will be kept there, so the user could launch
>> unverified jar.
>>           Last point was reported by Vladimir Sitnikov at LEGAL-288
>> ---
>>   gradle/init-gradle-wrapper.ps1 | 8 ++++++++
>>   1 file changed, 8 insertions(+)
>>
>> diff --git a/gradle/init-gradle-wrapper.ps1
>> b/gradle/init-gradle-wrapper.ps1
>> index c4911bd..2401147 100644
>> --- a/gradle/init-gradle-wrapper.ps1
>> +++ b/gradle/init-gradle-wrapper.ps1
>> @@ -25,6 +25,14 @@ If ($ExecutionContext.SessionState.LanguageMode
>> -eq "ConstrainedLanguage") {
>>       Invoke-WebRequest -outf gradle\wrapper\gradle-wrapper.jar
>> https://github.com/gradle/gradle/raw/v4.5.1/gradle/wrapper/gradle-wrapper.jar 
>>
>>   }
>>   +$expected = "00d0743607178962f8b120da4ccad2c64c698aec"
>> +$actual = (Get-FileHash gradle\wrapper\gradle-wrapper.jar -Algorithm
>> SHA1).Hash.ToLower()
>> +@{$true = 'OK: Checksum match'; $false = "ERROR: Checksum
>> mismatch!`nExpected: $expected`nActual: $actual"}[$actual -eq $expected]
>> +
>> +if (!$true)  {
>> +    Remove-Item gradle\wrapper\gradle-wrapper.jar
>> +    }
>> +
>>   #Write-Host $ExecutionContext.SessionState.LanguageMode
>>     Start-Sleep -s 3

[Jacques Le Roux]

Hi Michael,

For using SHA256 instead of SHA1, since we did not release it yet, why not beginning with 18.12.01?
Even for 17.12.07 I'd say, why waiting a tiny but possible vulnerability? Switching from SHA1 to SHA256 is easily done, no?

It's not exactly the same case, but in init-gradle-wrapper.ps1 if the checksum fails the downloaded file is deleted.
It seems to me that there is a (very small, but real) chance that if shasum command is not installed the downloaded file could be dangerous and should
be deleted (disclaimer: I did not check if it's done,  just reported Vladimir's concern)

My 2cts

Le 11/04/2021 à 15:31, Michael Brohl a écrit :

> Hi Jacques,
>
> why should we change the checksum algorithm now, for this release? I would leave it as is and introduce another one beginning with trunk.
>
> For the shasum part: the program is needed for the checks, like other programs (curl/wget, grep, whereis) are needed also. The script clearly states
> that when shasum is missing. I see no problem with that.
>
> Best regards,
>
> Michael Brohl
>
> ecomify GmbH - www.ecomify.de
>
>
> Am 10.04.21 um 14:16 schrieb [hidden email]:
>> Hi,
>>
>> I think we should at least discuss the 2 points below before releasing 17.12.07
>>
>> Thanks
>>
>> Jacques
>>
>> Le 10/04/2021 à 14:10, [hidden email] a écrit :
>>> This is an automated email from the ASF dual-hosted git repository.
>>>
>>> jleroux pushed a commit to branch release17.12
>>> in repository https://gitbox.apache.org/repos/asf/ofbiz-framework.git
>>>
>>>
>>> The following commit(s) were added to refs/heads/release17.12 by this push:
>>>       new 564b605  Improved: Replace Bintray by a new place to upload the Gradle Wrapper (OFBIZ-12192)
>>> 564b605 is described below
>>>
>>> commit 564b605d5509cd85f8d7b6355b4ebe62280e5686
>>> Author: Jacques Le Roux <[hidden email]>
>>> AuthorDate: Sat Apr 10 14:10:43 2021 +0200
>>>
>>>      Improved: Replace Bintray by a new place to upload the Gradle Wrapper (OFBIZ-12192)
>>>           The checksum part was missing in Windows init-gradle-wrapper.ps1 script
>>>           I have noticed 2 points:
>>>      1. We should use SHA256, not SHA1
>>>      2. The unix-like shell script in OFBiz misses checksum verification in case
>>>      shasum command is not installed. In other words, if I launch the script it would
>>>      fail with "shasum not found, the downloaded files could not be verified".
>>>      However, the file will be kept there, so the user could launch unverified jar.
>>>           Last point was reported by Vladimir Sitnikov at LEGAL-288
>>> ---
>>>   gradle/init-gradle-wrapper.ps1 | 8 ++++++++
>>>   1 file changed, 8 insertions(+)
>>>
>>> diff --git a/gradle/init-gradle-wrapper.ps1 b/gradle/init-gradle-wrapper.ps1
>>> index c4911bd..2401147 100644
>>> --- a/gradle/init-gradle-wrapper.ps1
>>> +++ b/gradle/init-gradle-wrapper.ps1
>>> @@ -25,6 +25,14 @@ If ($ExecutionContext.SessionState.LanguageMode -eq "ConstrainedLanguage") {
>>>       Invoke-WebRequest -outf gradle\wrapper\gradle-wrapper.jar https://github.com/gradle/gradle/raw/v4.5.1/gradle/wrapper/gradle-wrapper.jar
>>>   }
>>>   +$expected = "00d0743607178962f8b120da4ccad2c64c698aec"
>>> +$actual = (Get-FileHash gradle\wrapper\gradle-wrapper.jar -Algorithm SHA1).Hash.ToLower()
>>> +@{$true = 'OK: Checksum match'; $false = "ERROR: Checksum mismatch!`nExpected: $expected`nActual: $actual"}[$actual -eq $expected]
>>> +
>>> +if (!$true)  {
>>> +    Remove-Item gradle\wrapper\gradle-wrapper.jar
>>> +    }
>>> +
>>>   #Write-Host $ExecutionContext.SessionState.LanguageMode
>>>     Start-Sleep -s 3

[Michael Brohl-3]

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.

Can you explain where the real vulnerability is with the file checksums?

Regards,

Michael


Am 11.04.21 um 19:29 schrieb Jacques Le Roux:

> Hi Michael,
>
> For using SHA256 instead of SHA1, since we did not release it yet, why
> not beginning with 18.12.01?
> Even for 17.12.07 I'd say, why waiting a tiny but possible
> vulnerability? Switching from SHA1 to SHA256 is easily done, no?
>
> It's not exactly the same case, but in init-gradle-wrapper.ps1 if the
> checksum fails the downloaded file is deleted.
> It seems to me that there is a (very small, but real) chance that if
> shasum command is not installed the downloaded file could be dangerous
> and should be deleted (disclaimer: I did not check if it's done,  just
> reported Vladimir's concern)
>
> My 2cts
>
> Le 11/04/2021 à 15:31, Michael Brohl a écrit :
>> Hi Jacques,
>>
>> why should we change the checksum algorithm now, for this release? I
>> would leave it as is and introduce another one beginning with trunk.
>>
>> For the shasum part: the program is needed for the checks, like other
>> programs (curl/wget, grep, whereis) are needed also. The script
>> clearly states that when shasum is missing. I see no problem with that.
>>
>> Best regards,
>>
>> Michael Brohl
>>
>> ecomify GmbH - www.ecomify.de
>>
>>
>> Am 10.04.21 um 14:16 schrieb [hidden email]:
>>> Hi,
>>>
>>> I think we should at least discuss the 2 points below before
>>> releasing 17.12.07
>>>
>>> Thanks
>>>
>>> Jacques
>>>
>>> Le 10/04/2021 à 14:10, [hidden email] a écrit :
>>>> This is an automated email from the ASF dual-hosted git repository.
>>>>
>>>> jleroux pushed a commit to branch release17.12
>>>> in repository https://gitbox.apache.org/repos/asf/ofbiz-framework.git
>>>>
>>>>
>>>> The following commit(s) were added to refs/heads/release17.12 by
>>>> this push:
>>>>       new 564b605  Improved: Replace Bintray by a new place to
>>>> upload the Gradle Wrapper (OFBIZ-12192)
>>>> 564b605 is described below
>>>>
>>>> commit 564b605d5509cd85f8d7b6355b4ebe62280e5686
>>>> Author: Jacques Le Roux <[hidden email]>
>>>> AuthorDate: Sat Apr 10 14:10:43 2021 +0200
>>>>
>>>>      Improved: Replace Bintray by a new place to upload the Gradle
>>>> Wrapper (OFBIZ-12192)
>>>>           The checksum part was missing in Windows
>>>> init-gradle-wrapper.ps1 script
>>>>           I have noticed 2 points:
>>>>      1. We should use SHA256, not SHA1
>>>>      2. The unix-like shell script in OFBiz misses checksum
>>>> verification in case
>>>>      shasum command is not installed. In other words, if I launch
>>>> the script it would
>>>>      fail with "shasum not found, the downloaded files could not be
>>>> verified".
>>>>      However, the file will be kept there, so the user could launch
>>>> unverified jar.
>>>>           Last point was reported by Vladimir Sitnikov at LEGAL-288
>>>> ---
>>>>   gradle/init-gradle-wrapper.ps1 | 8 ++++++++
>>>>   1 file changed, 8 insertions(+)
>>>>
>>>> diff --git a/gradle/init-gradle-wrapper.ps1
>>>> b/gradle/init-gradle-wrapper.ps1
>>>> index c4911bd..2401147 100644
>>>> --- a/gradle/init-gradle-wrapper.ps1
>>>> +++ b/gradle/init-gradle-wrapper.ps1
>>>> @@ -25,6 +25,14 @@ If ($ExecutionContext.SessionState.LanguageMode
>>>> -eq "ConstrainedLanguage") {
>>>>       Invoke-WebRequest -outf gradle\wrapper\gradle-wrapper.jar
>>>> https://github.com/gradle/gradle/raw/v4.5.1/gradle/wrapper/gradle-wrapper.jar
>>>>   }
>>>>   +$expected = "00d0743607178962f8b120da4ccad2c64c698aec"
>>>> +$actual = (Get-FileHash gradle\wrapper\gradle-wrapper.jar
>>>> -Algorithm SHA1).Hash.ToLower()
>>>> +@{$true = 'OK: Checksum match'; $false = "ERROR: Checksum
>>>> mismatch!`nExpected: $expected`nActual: $actual"}[$actual -eq
>>>> $expected]
>>>> +
>>>> +if (!$true)  {
>>>> +    Remove-Item gradle\wrapper\gradle-wrapper.jar
>>>> +    }
>>>> +
>>>>   #Write-Host $ExecutionContext.SessionState.LanguageMode
>>>>     Start-Sleep -s 3
>

[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:

[Michael Brohl-3]

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:
>
>

[Jacques Le Roux]

Hi Michael,

After some experiences, globally my thinking is now "there is always a treat". For SHA-1, as I reported below:

    <<Notably "publishing two dissimilar PDF files which produced the same SHA-1 hash">>

I agree it's quite tiny in this case but better use recommended SHA (ie at least 256).

Anyway, Jacopo has started the vote for 17.12.07, which is good. I'll only work on R18 and trunk.

Jacques

Le 12/04/2021 à 23:31, Michael Brohl a écrit :

> 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:
>>
>>