-
-
Notifications
You must be signed in to change notification settings - Fork 436
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fixes issue #475, reduce reprocessed jpeg image file size by defaulting image quality to 85% #2629
Fixes issue #475, reduce reprocessed jpeg image file size by defaulting image quality to 85% #2629
Conversation
This change must be accompanied by an explanation in the README. First of all, why was it introduced in Magento 1.9.3.3 and was it hardcoded until now. Strictly on security aspects. As has been discussed, it is not just a problem of not compressing an already compressed file, but a more complex, malicious one. If no suitable explanation can be found, the PRs/Issues where they were discussed can be indicated for the beginning. |
@addison74 See the original comment here magento-lts/app/code/core/Mage/Core/etc/config.xml Lines 500 to 503 in fb12d0f
<!-- NOTE: If you turn off images reprocessing, then your upload images process may cause security risks. --> This PR doesn't change what was introduced, if someone uses it in some custom The new feature is the ability to set the image quality in backend, which should satisfy everyone . Ref the discussion thread in issue #475, some want to turn it off, some wants to have another value for the image quality. With this PR, you can turn it off by setting the image quality to zero, or set any image quality you want. |
I think I found the reason: https://web.archive.org/web/20180406222439/https://magento.com/security/patches/supee-9767 |
Good find! |
This makes sense now:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks solid. Suggestion to precise the commit message upon merge.
Let's wait a few more opinions before merging. |
Just FYI, OpenMage is much less susceptible to attacks using media uploads than Magento because we addressed the "allow_symlinks" option by removing it altogether and adding extra checks to prevent use of "../" in block template paths in #442 . So even if a malicious file was uploaded one would not be able to execute it with a template hack as far as we know. Still I think it is a good idea to reprocess these images to be safe but the CVEs referenced are completely irrelevant to OpenMage since it no longer even has an "AllowSymlinks" option and is probably more secure than even when it was on. |
So for existing installations:
Only problem is users that changed their XML will not be able to modify via the UI without removing their XML update so this could be confusing/unexpected.. I propose changing the logic so the default value is empty and if there is a non-empty value for the new config always use it, then check for the legacy config and use it and otherwise default to 85. |
How about a RSS notification to re-set this value in admin config? |
…recated config exists.
@colinmollenhour actually described a bug (users not able to modify image quality in backend if deprecated config exists), and I like his fix, which is implemented: The new config is no longer a required entry, image quality is In edge cases where there is a custom XML with the deprecated config, it means it wants to skip the image reprocessing. Otherwise, there is no reason to override the config. This PR will comply with the directive. Now, the same users come across the config in backend, they can set it to zero, to continue skipping image reprocessing, or they can set a value, which will take effect. Thanks @colinmollenhour for the neat solution. |
Mhhh ... i'm not so happy to check for an orphan config entry just for BC. How about an update script that move value from old to new config path?
|
By "update script", do you mean add a file in
That I do not know how to do. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me.
@sreichel The code is only executed when files are uploaded so the overhead of checking a deprecated config value is nil and it's just a few lines of code. This seems like a sufficient solution to me and a database migration is extra coding time but for what added value? Probably 99% of users don't even know about this config option. The ones that disabled it will still get the same behavior but now have the option to set it in the GUI so win-win IMHO.
@colinmollenhour it's not about "overhead". Why to deal with a non-existing config node? Simple update script .... <?php
$installer = $this;
$installer->startSetup();
# change config values
$installer->run("
UPDATE {$this->getTable('core_config_data')}
SET path = 'admin/security/reprocess_image_quality'
WHERE path = 'general/reprocess_images/active';
");
$installer->endSetup(); Comment/note in config sections seems to be clear ... no need for special rss update ... |
To me it's mostly a matter of time being well spent including/especially discussion time.. we have a working PR now.. and although it isn't complex, it is not quite that simple. The setup script you put in the comment isn't a commit so it can't be approved yet, it doesn't account for the value being set in the XML (XML values don't get saved to the database unless they are also in system.xml, I am sure of this) and the old value is boolean while the new one is 0-100. |
This statement
can be true or false, but in our case, it is false for Whereas this one
is true, I tested it. It means the upgrade script needs to do a scan for |
This is the second PR in which I make comments about the wording of some phrases. They are not discussed but simply ignored. More attention should be paid in this regard because it is what the OM user read. |
@addison74 Please comment again the ignored "wording of some phrases". If you can help to review again, I will look into it and incorporate them in this PR. Regarding "an explanation in the README", can you help to make a PR after this is merged? Basically, the original code make jpeg image files too large due to saving it at 100% quality. This PR reduces it to 85%. The backend config is really cater for edge cases where the users can play with the quality setting. I do not really see a need to explain it in README, I think a note in release commit is sufficient. |
@kiatng - If you opened this page in a browser you can see my comment above. It is also in "File changed" section. |
@addison74 I can't see any review of yours here. Perhaps you forgot to submit it? |
In Files changed tab, [Review changes] button has a badge. Here is a screenshot: On the same page bellow you may find that review: In Conversation tab, my comment can be found too. See bellow My comment is 3 days old. I don't post to GitHub from Phpstorm, I just use the browser. In other two merged PR's the same situation. I am starting to wonder if it is still necessary to make comments since they are being ignored. |
I learned that when it says “pending” you’re the only one that can see it. Tou have to “submit the review” or “add single comment” 😉 |
Your comments are not being ignored, no one can see them yet because they are still pending, you have to actually submit the review ("Review changes" -> "Submit review") for it to be public. This is a common confusion with the GitHub UI, it happened with Fabrizio before too. |
@fballiano - GitHub has an incomprehensible behavior, if I leave a comment it doesn't appear for the others (I logged out to check before). It is only displayed if I request changes. It should have been displayed as long as GitHub explicitly mentions that choosing Comment means "Submit general feedback without explicit approval". Is it a general feedback but it is displayed only for me? Anyway, I appreciate for pointing me out, I will pay more attention from now on to what is displayed when I am not logged in. |
It's for batching multiple comments in a single review. But you can always just choose "Add single comment". |
I used "Add single comment" button but you may see the result above, it was hidden from everyone else. I had to start a review or request for a change. Of the two options, the change request has priority and cancels all previous approvals. |
Unit Test Results1 files 1 suites 0s ⏱️ Results for commit 6efea4b. |
* Fixed "should return string but returns false" * Fixed "should return XYZ but returns false" * Fixed "should return array but returns null" * Fixed "should return string but returns null" * Fixed "should return int but returns null" * Fixed "should return bool but returns" * Fixed docs (see comments) * Fixed "should return array" * Update app/code/core/Mage/Adminhtml/Block/Widget/Grid/Massaction/Abstract.php Co-authored-by: Ng Kiat Siong <kiatsiong.ng@gmail.com> * Update app/code/core/Mage/Catalog/Model/Product/Attribute/Tierprice/Api.php Co-authored-by: Ng Kiat Siong <kiatsiong.ng@gmail.com> * Update app/code/core/Mage/Tag/Model/Resource/Tag.php Co-authored-by: Ng Kiat Siong <kiatsiong.ng@gmail.com> * Update app/code/core/Mage/Customer/Block/Form/Register.php Co-authored-by: Ng Kiat Siong <kiatsiong.ng@gmail.com> * Added module names to helper(#2617) * Get catalog search result collection from engine (#2634) * Add PHP dependencies security check workflow (#2639) * [security-workflow] Fixed cron syntax (#2640) * Added OpenMage Contributors Copyright (#2295) * Added ddev snippets to docs (#2575) * Improve dev/openmage/install.sh script for newer versions of Docker - no longer requires separate compose. * Only run workflows when relevant files change (#2641) * Add back notification popup severity icons URL (#2633) * Reduce reprocessed jpeg file size by defaulting quality to 85% (#2629) * Fixed issue #475. * Removed <frontend_type>text</frontend_type> as it is the default. * Fixed bug on users not able to modify image quality in backend if deprecated config exists. * Fixed bug on incorrect check if image quality was not set in backend. * Improved note in system.xml. * Prevented editing of a non-editable order (#2632) * Fix dev/openmage/install.sh script setting permissions on var directory. * Allowed automatic full invoice from API (#2393) * Add check if array key isset before using it (#2649) * Fixed phpstan-baseline.neon * Fixed phpstan-baseline.neon (updated dev tools) * Revert "Fixed phpstan-baseline.neon" This reverts commit 3c82e76. * Fixed getRegion() Co-authored-by: Ng Kiat Siong <kiatsiong.ng@gmail.com> Co-authored-by: Mohamed ELIDRISSI <67818913+elidrissidev@users.noreply.github.com> Co-authored-by: Justin Beaty <51970393+justinbeaty@users.noreply.github.com> Co-authored-by: Colin Mollenhour <colin@mollenhour.com> Co-authored-by: luigifab <31816829+luigifab@users.noreply.github.com> Co-authored-by: Przemysław Piotrowski <przemyslaw.p@deligo.pl>
Description (*)
Config
general/reprocess_images/active
is removed and replaced withadmin/security/reprocess_image_quality
, where it is default to 85.For BC, checking ofgeneral/reprocess_images/active
takes precedent.Fixed Issues (if relevant)