Django db backend not FIPS compliant

[Brandon Williams]

I'm running into issues when trying to migrate my models in an environment that is running FIPS restrictions regarding MD5.  Here is the stack trace:

Operations to perform:
  Apply all migrations: admin, auth, contenttypes, dashboard, kombu_transport_django, sessions
Running migrations:
  Applying contenttypes.0001_initial...Traceback (most recent call last):
  File "manage.py", line 10, in <module>
    execute_from_command_line(sys.argv)
  File "/usr/lib64/python2.7/site-packages/django/core/management/__init__.py", line 367, in execute_from_command_line
    utility.execute()
  File "/usr/lib64/python2.7/site-packages/django/core/management/__init__.py", line 359, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/usr/lib64/python2.7/site-packages/django/core/management/base.py", line 294, in run_from_argv
    self.execute(*args, **cmd_options)
  File "/usr/lib64/python2.7/site-packages/django/core/management/base.py", line 345, in execute
    output = self.handle(*args, **options)
  File "/usr/lib64/python2.7/site-packages/django/core/management/commands/migrate.py", line 204, in handle
    fake_initial=fake_initial,
  File "/usr/lib64/python2.7/site-packages/django/db/migrations/executor.py", line 115, in migrate
    state = self._migrate_all_forwards(state, plan, full_plan, fake=fake, fake_initial=fake_initial)
  File "/usr/lib64/python2.7/site-packages/django/db/migrations/executor.py", line 145, in _migrate_all_forwards
    state = self.apply_migration(state, migration, fake=fake, fake_initial=fake_initial)
  File "/usr/lib64/python2.7/site-packages/django/db/migrations/executor.py", line 244, in apply_migration
    state = migration.apply(state, schema_editor)
  File "/usr/lib64/python2.7/site-packages/django/db/migrations/migration.py", line 129, in apply
    operation.database_forwards(self.app_label, schema_editor, old_state, project_state)
  File "/usr/lib64/python2.7/site-packages/django/db/migrations/operations/models.py", line 532, in database_forwards
    getattr(new_model._meta, self.option_name, set()),
  File "/usr/lib64/python2.7/site-packages/django/db/backends/base/schema.py", line 333, in alter_unique_together
    self.execute(self._create_unique_sql(model, columns))
  File "/usr/lib64/python2.7/site-packages/django/db/backends/base/schema.py", line 913, in _create_unique_sql
    "name": self.quote_name(self._create_index_name(model, columns, suffix="_uniq")),
  File "/usr/lib64/python2.7/site-packages/django/db/backends/base/schema.py", line 819, in _create_index_name
    index_unique_name = '_%s' % self._digest(table_name, *column_names)
  File "/usr/lib64/python2.7/site-packages/django/db/backends/base/schema.py", line 123, in _digest
    h = hashlib.md5()
ValueError: error:060800A3:digital envelope routines:EVP_DigestInit_ex:disabled for fips

 Is there a particular reason why MD5 is used here? Is there any harm in or backwards compatibility concerns regarding changing it to sh512 or something similar? Perhaps a setting to select another hash to be FIPS compliant?

[Tim Graham]

This usage generates a short, unique identifier for a database index name. The usage of md5 here isn't security sensitive. Changing it to some other hash could be backwards incompatible because Django would no longer know the names of indexes in existing projects. There are other usages of md5 in Django where a short, fast hash is needed. I'm not sure if prohibiting the usage of md5 in Django or adding a setting to allow selecting some other hash in all those places is worth the additional complexity. At least as a temporary workaround, maybe you can monkey patch hashlib.md5 to use your hash of choice?

[Adam Johnson]

After googling a bit I found this CPython ticket: https://bugs.python.org/issue9216 . It turns out that the block is in OpenSSL and not really python land. They didn't find a solution to it in the standard library on that ticket, but I think it should be pretty easy to monkey patch in a pure python implementation of MD5 to hashlib.md5, or if you are really worried about security, monkey patch the hashlib module in only select Django modules you have audited it to not be using it for security purposes.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscribe@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/f49df38f-180a-4827-98fc-ba4bc903315c%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Adam

[Andrew DiPrinzio]

I am having the same problem. Anyone have a solution other than patch hashlib?

To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.

Visit this group at https://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/f49df38f-180a-4827-98fc-ba4bc903315c%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Adam

[Andrew DiPrinzio]

All, 

I have submitted a ticket where i propose the use of the "usedforsecurity=False" flag. Please take a look and comment if you have any thoughts. 

https://code.djangoproject.com/ticket/28401