search

pytroll / pyresample

Geospatial image resampling in Python
http://pyresample.readthedocs.org
GNU Lesser General Public License v3.0
343 stars 95 forks source link

Remove Configobj as Dependency Due To Security Vulnerability and No Longer Maintaned #589

Open aarande opened 4 months ago

aarande commented 4 months ago

Configobj has an identified security vulnerability and seems to be no longer maintained. Recommend removing configobj as a dependency so pyresample is not affected or limited in use because of this. It appears it is only used in one place so believe this should not be too difficult and I will look at doing it and creating a pull request. The _create_area method in area_config.py line 352 is the only place I see this is used.

Configobj has an open CVE, https://github.com/advisories/GHSA-c33w-24p9-8m24, All versions of the package configobj are vulnerable to Regular Expression Denial of Service (ReDoS) via the validate function. There is an open issue in the github repo along with a pull request for over a year with no movement. This package appears to be unmaintained and abandoned.

https://github.com/DiffSK/configobj/issues/232

Thanks, Aaron

djhoese commented 4 months ago

Configobj is used for parsing all legacy format areas config files. The newer format uses YAML. It would be a major deprecation to remove support for the legacy format. That said, no new uses of pyresample should be using this older format (we don't use it in Satpy for example). Dropping support for the configobj format was my plan as part of pyresample 2.0, but I'm not sure what the timeline is for that release given my funding for that type of development has dried up. I'd be OK removing it as a hard requirement with plenty of deprecation warnings added.

@mraspaud @pnuu and others, what are your thoughts?

pnuu commented 4 months ago

I would be fine removing the legacy area definition support. I think we've had the yaml version already for so long, that even without a deprecation cycle it should be pretty safe. If someone is still using them, I doubt they'd notice the deprecation messages anyway :sweat_smile:

djhoese commented 4 months ago

If someone is still using them, I doubt they'd notice the deprecation messages anyway

This is a good point. We could have a release or two with it non-functional or with the hard requirement removed. Then in 2.0 or maybe sooner we could remove the functionality entirely.