Upgrade to svgo@^2.x since svgo@^1.x contains a vulnerable dependency

[StudioMaX]

svgo@^1.3 has an indirect dependency on nth-check:

svgo@^1.3 > css-select@^2.0.0 > nth-check@^1.0.2

Information about the vulnerability in nth-check was recently published: GHSA-rp65-9cf3-cjxr
This vulnerability was fixed in nth-check@2.0.1. But our dependencies use the version nth-check@^1.0.2, which most likely will not be updated due to large changes.
svgo@^1.3 is also not supported since October 2019.

Therefore, in my opinion, it is necessary to prepare some plan for upgrading to svgo@^2.x.

[freekmurze]

Could you test if svgo 2 would just work? Maybe we can just update our docs?

[StudioMaX]

Unfortunately, we cannot simply upgrade to version 2.0, since the default configuration of image-optimizer uses the "disable" flag:

image-optimizer/src/OptimizerChainFactory.php

Lines 42 to 44 in 9c85625

	->addOptimizer(new Svgo([
	'--disable={cleanupIDs,removeViewBox}',
	]))

But this flag was removed from CLI since svgo 2.0: svg/svgo#1356 (comment)
And as far as I understand, the only way to disable any plugin is to use a special "svgo.config.js" file. Something like svgo --config=/path/to/svgo.config.js

Thus, the image-optimizer must store in its sources a config file with a modified configuration for svgo (that is, with two disabled plugins). And when executing the svgo, it will need to substitute the path to the config file.

Because of this, there will be a BC break between the new standard configuration in OptimizerChainFactory using the config file and between the svgo 1.x previously installed by users. And I have not yet been able to come up with an easy way to solve this problem.

[bricebou]

Hi,

Any news on this issue ?

Thanks for this great package and in advance :)

[chocolata]

Hi, I understand that there is no clear cut solution to this issue. Could I ask what would happen if we do not install SVGO v1 on our server? In my usecase optimizing SVG is not that important. It's more the JPGs, PNGs and WEBP files that are problematic.

Would image-optimizer still work if SVGO is not installed? Do we need to explicitly skip SVG files or will the libary do this automatically?

Thanks for your views.

[andimg93]

Unfortunately, we cannot simply upgrade to version 2.0, since the default configuration of image-optimizer uses the "disable" flag:

image-optimizer/src/OptimizerChainFactory.php

Lines 42 to 44 in 9c85625

	->addOptimizer(new Svgo([
	'--disable={cleanupIDs,removeViewBox}',
	]))

But this flag was removed from CLI since svgo 2.0: svg/svgo#1356 (comment) And as far as I understand, the only way to disable any plugin is to use a special "svgo.config.js" file. Something like svgo --config=/path/to/svgo.config.js

Thus, the image-optimizer must store in its sources a config file with a modified configuration for svgo (that is, with two disabled plugins). And when executing the svgo, it will need to substitute the path to the config file.

Because of this, there will be a BC break between the new standard configuration in OptimizerChainFactory using the config file and between the svgo 1.x previously installed by users. And I have not yet been able to come up with an easy way to solve this problem.

would something like this fix your issues @StudioMaX ?

->addOptimizer(new Svgo([ 
     '--plugins="cleanupIDs:false,removeViewBox:false"',
 ]));

[freekmurze]

We now suggest the latest version of svgo