If you use a FIPS (Federal Information Processing Standards) enabled system, then you cannot useplt.savefig to save an image in SVG format. This is because theRenderSVG._make_id method takes the first 10 characters of ahashlib.md5 digest of entries in the SVG as the ID for entries in the SVG file.

The Python docs forhashlib includes the following note:

Constructors for hash algorithms that are always present in this module are sha1(), sha224(), sha256(), sha384(), sha512(), blake2b(), and blake2s(). md5() is normally available as well, though it may be missing if you are using a rare “FIPS compliant” build of Python.

PR Checklist

[na ] Has Pytest style unit tests
- Not sure if this is applicable to my change
Code isFlake 8 compliant
[na] New features are documented, with examples if plot related
Documentation is sphinx and numpydoc compliant
[na] Added an entry to doc/users/next_whats_new/ if major new feature (follow instructions in README.rst there)
- Not a major feature
Documented in doc/api/next_api_changes/* if API changed in a backward-incompatible way

Allow savefig to save SVGs on FIPS enabled systemsmatplotlib#18192

4f0b353

daytonb mentioned this pull request

Aug 6, 2020

Cannot save SVG file with FIPS compliant Python#18192

Closed

dstansby reviewed

Aug 6, 2020

View reviewed changes

Copy link

Member

dstansby left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Seems like a reasonable approach. Is this injected into the .svg files? If so it would be good to add a quick note todoc/api/next_api_changes/behavior to say that the contents will be slightly different, just in case there is anybody comparing the hashes of matplotlib generated .svg files.

Copy link

ContributorAuthor

daytonb commentedAug 6, 2020 via email

Ok. I can update that and add it to the pull request.

…

On Thu, Aug 6, 2020 at 5:20 PM David Stansby ***@***.***> wrote: ***@***.**** commented on this pull request. Seems like a reasonable approach. Is this injected into the .svg files? If so it would be good to add a quick note to doc/api/next_api_changes/behavior to say that the contents will be slightly different, just in case there is anybody comparing the hashes of matplotlib generated .svg files. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#18193 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABJTWIZER3MDYG477B3Y6KDR7MNCRANCNFSM4PWSKEPA> .

dopplershift added this to thev3.4.0 milestone

Aug 7, 2020

Copy link

ContributorAuthor

daytonb commentedAug 7, 2020

Alright I've added a file to thedoc/api/next_api_changes/behavior. Let me know if the description seems unclear and needs tweaking.

QuLogic reviewed

Aug 7, 2020

View reviewed changes

doc/api/next_api_changes/behavior/18193-BKB.rst OutdatedShow resolvedHide resolved

daytonb force-pushed thefips-compatible branch frombf4b626 to950302dCompare

August 7, 2020 10:46

Note change of SVG ID generation from MD5 to SHA512matplotlib#18192

47a0430

daytonb force-pushed thefips-compatible branch from950302d to47a0430Compare

August 7, 2020 10:49

Copy link

ContributorAuthor

daytonb commentedAug 7, 2020

I re-wrote the behavior change note to no longer reference the private method. I was also previously getting an error from the circleci doc tests that I think was from the warnings Sphinx gave about my references tohashlib.md5 andRenderSVG._make_id. The warnings said that Sphinx couldn't find thesepyobjs to link to them. Obviously I removed the reference toRenderSVG._make_id so that won't be a problem any more, but I also reworded my note abouthashlib.md5 to avoid having to do a intersphinx reference.

jklymak approved these changes

Aug 7, 2020

View reviewed changes

Copy link

Member

jklymak left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

This seems fine to me. I don't know that it really needs an API change note - the origin of the hash is just an implementation detail of the unique ID, and its not like the user needs to know that. But, I guess it doesn't hurt.