Hi Michael,
After some experiences, globally my thinking is now "there is always a treat".
For SHA-1, as I reported below:
<>
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
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
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
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
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
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
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, jler...@apache.org a écrit :
This is an automated email from the ASF dual-hosted git repository.
jleroux pushed a commit to branch release17.12
in repository
