User tests: Successful: Unsuccessful:
light porting of #17555 from 4.0 to 3.8
trigger the checksum check on install/update
if the update server manifest have an hash tag like these:
only return:
the installation/update works as before
see #17555
the main difference is it install anyway so there is no force button
checking the integrity of the package with: SHA256,SHA384,SHA512 hash algos
no check is made
new tags <sha256><sha256/><sha384><sha384/><sha512><sha512/>
on update server manifest
Category | ⇒ | Administration com_installer Language & Strings Libraries |
Status | New | ⇒ | Pending |
Title |
|
Labels |
Added:
?
?
|
We need to make a decision on what hashes to support. In 2017, md5 and sha1 aren't great options.
sha256 ?
I can't say I know much about sha256's security off hand.
This should be incorporated into com_joomlaupdate as well so core can use it.
sure, can we do in a separate pr ?
We need to make a decision on what hashes to support. In 2017, md5 and sha1 aren't great options.
sha256 should be OK nowdays ...or not
Labels |
Added:
?
|
I already know what he's going to nudge toward but I'm going to ask an opinion anyway.
@paragonie-scott are there any major issues to be aware of with using sha256 or sha512 with hash_file()
as a means for validating a checksum of an extension (or our core) package as a short-to-mid term solution? (Clearly we could/should continue to work for better options, so right now this is basically a starting point; the one thing this wouldn't address is a compromise of anyone's distribution platform)
in the gsoc 17 EEM meeting yesterday, i've discovered that there are some 3dp extensions that use
md5/sha1 like ARS, so apart the discussion about weakness, should we consider to support those weak algos?
one step forward (sha512) and one step back (md5,sha1)
I'm well aware that ARS generates them. That still doesn't necessarily make md5/sha1 good to introduce into new APIs in the core libraries in 2017 as a means for validating package integrity.
are there any major issues to be aware of with using sha256 or sha512 with hash_file() as a means for validating a checksum of an extension (or our core) package as a short-to-mid term solution?
There's a length extension attack, but that doesn't break preimage security, and since it's an unkeyed hash, it's not giving the attacker a capability they don't already have.
However, if you want to be conservative here, follow Composer's example and go with SHA384 specifically.
so we can go with: sha256,sha384,sha512 ?
That seems fair to me.
now hash supported are:
I have tested this item
Tested OK, as part of #17632
For more info about the test and comment: https://issues.joomla.org/tracker/joomla-cms/17632#event-3
I have tested this item
Status | Pending | ⇒ | Ready to Commit |
RTC after two successful tests.
Title |
|
Status | Ready to Commit | ⇒ | Fixed in Code Base |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2018-03-08 22:05:54 |
Closed_By | ⇒ | wilsonge | |
Labels |
Added:
?
|
LGTM :)
This should be incorporated into com_joomlaupdate as well so core can use it.
We need to make a decision on what hashes to support. In 2017, md5 and sha1 aren't great options.