Allow make_template_fragment_key() to work on FIPS systems#10605
Allow make_template_fragment_key() to work on FIPS systems#1060501000101 wants to merge 5 commits intodjango:masterfrom 01000101:osp13-fips-min
Conversation
|
I see there's some (seemingly unrelated) Jenkins errors. Can anyone shed some light as to why? |
|
Nice, that was a daylight savings time error. You could rebase your changes and force-push them again, or add an empty git commit on top (git commit --allow-empty) and push again. That being said, here's already an issue with some discussion how to approach the FIPS problem: https://code.djangoproject.com/ticket/28401 |
|
|
||
| # Try to generate an MD5 hash but fall up to SHA256 if in FIPS mode | ||
| try: | ||
| args = hashlib.md5(key.encode()) |
There was a problem hiding this comment.
Rather than try this each time could we not include the is_fips_mode method in this module and do a conditional check? We can wrap it in an @lru_cache to ensure it's not called more than once.
There was a problem hiding this comment.
I completely agree, but it sounds like first some decisions about the overall approach (crafting a solution vs. waiting for hashlib to implement FIPS-awareness) are still in flux. Once that's resolved, I'd be happy to implement something more complete, optimized.
| def test_without_vary_on(self): | ||
| key = make_template_fragment_key('a.fragment') | ||
| self.assertEqual(key, 'template.cache.a.fragment.d41d8cd98f00b204e9800998ecf8427e') | ||
| if is_fips_mode(): |
There was a problem hiding this comment.
As we don't run any Jenkins executors in FIPS mode we could instead use some subtests here and mock the return value of is_fips_mode if it's included in cache/utils.py?
|
I'm not convinced about the solution and other areas of Django are affected. See https://code.djangoproject.com/ticket/28401 for some discussion (all patches like this should be linked to a Trac ticket anyway). |
|
The ticket seems relatively stale and the hashlib with the parameters
mentioned are still very distro specific. My approach at least provides a
more generic (and immediate) solution, even if it was created to patch an
issue specific to an OpenStack deployment and not the whole of Django.
Should I comment in that ticket instead or is this the right place to
discuss a more full solution?
…On Sun, Nov 4, 2018, 12:50 Tim Graham ***@***.***> wrote:
I'm not convinced about the solution and other areas of Django are
affected. See https://code.djangoproject.com/ticket/28401 for some
discussion (all patches like this should be linked to a Trac ticket anyway).
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#10605 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AHHc96taQQ1SA_HbWgNRYQuF2W7bLQDyks5uryjcgaJpZM4YNFEj>
.
|
isort ordering failure on tests flake8 compliance
…nto osp13-fips-min
|
Closing per ticket. I also think that it's not a good approach. You can start a discussion on DevelopersMailingList if you don't agree. |
Systems in "FIPS mode" (fips=1 kernel flag set) cannot use MD5. There's some exception for allowed use cases, but that's mostly academic in nature considering software like OpenSSL will block MD5 regardless of intended use on FIPS mode systems. This patch specifically addresses an issue encountered on a deployment of Red Hat OpenStack 13, albeit using an older Red Hat packaged version of python-django (1.8.18-1.el7ost).