Re: Are there use cases for storing null bytes in CharField/TextField?

[Jon Dufresne]

On Mon, May 15, 2017 at 10:30 AM, Tim Chase 
wrote:

> On 2017-05-15 08:54, Tim Graham wrote:
> > Does anyone know of a use case for using null bytes in
> > CharField/TextField?
>
> Is this not what BinaryField is for?  It would seem to me that
> attempting to store binary NULL bytes in a CharField/TextField should
> result in an error condition.
>

The null byte is also a valid Unicode code point [0].

I guess I'm a bit surprised that a valid code point can't be stored in a
PostgreSQL text column. This does appear to be documented for the char(int)
string function [1], although without justification.

> The NULL (0) character is not allowed because text data types cannot
store such bytes.

I'm curious behind PostgreSQL's decision to prohibit this code point. If
anyone has additional information to share on their reason, please pass it
along.


[0] http://www.fileformat.info/info/unicode/char//index.htm
[1] https://www.postgresql.org/docs/current/static/functions-string.html

Cheers

-- 
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+unsubscr...@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/CADhq2b6egRaJ8t23HRXwjfqTHjTJx%3DjRPSL8P%3D6MUTyotFsP6w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: should nonexistent template filter arguments resolve to string_if_invalid rather than raise VariableDoesNotExist?

[Jon Dufresne]

Just my opinion, but I think raising an exception is more helpful to
developers and will result in fewer unnoticed bugs.

More generally, I know the template engine has a history of silently
converting unknown variables to string_if_invalid but this is more harmful
than helpful in my experience. It continues to be a source of hard to catch
bugs on the projects I work on. So I'd prefer we avoid introducing more of
this pattern if possible.

On Wed, May 31, 2017 at 8:03 AM, Tim Graham  wrote:

> Should nonexistent template filter arguments raise an exception? Current
> behavior:
>
> {{ value|filter:nonexistent_template_var}}
>
> raises VariableDoesNotExist for nonexistent_template_var.
>
> I guess the proposal would be to make nonexistent_tempatle_var resolve to
> string_if_invalid. As for me, I think the current behavior is less error
> prone.
>
> Related tickets:
>
> https://code.djangoproject.com/ticket/13167
> This was first closed incorrectly as "fixed" by Jacob (actually a
> different issue was fixed), then amended as wontfix by Karen with the note,
> "I'm fine with wontfixing that, though it does rather seem to go against
> "template errors don't raise exceptions" philosophy."
>
> https://code.djangoproject.com/ticket/28172
> A follow up ticket requesting the same thing as #13167.
>
> --
> 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+unsubscr...@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/02727bd0-5a67-4cf9-9c3f-
> b0a0a7ea0a3a%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@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/CADhq2b6adbyeG_mQwZBhsu2TJq9D_EGZgKgakr1fnqqMN7tWFA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django db backend not FIPS compliant

[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.

On 31 May 2017 at 14:35, Tim Graham  wrote:

> 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?
>
> On Wednesday, May 31, 2017 at 9:28:29 AM UTC-4, Brandon Williams wrote:
>>
>> 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 
>>> 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?
>>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to 

Re: Value of tightening URLValidator/EmailValidator regular expressions?

[Collin Anderson]

Hi All,

There's a PR [0] to make validation match HTML. Though there's a question 
about what to do with domain_whitelist.

Here's the background:
- Originally Django didn't allow any dotless (non-FQDN) domain names.

- People wanted to use "localhost", but the SMTP spec said "Local nicknames 
or unqualified names MUST NOT be
   used." So domain_whitelist was added to allow more user-specified 
domains. https://code.djangoproject.com/ticket/4833

- We're proposing to change the behavior of email validation to allow a lot 
more email addresses including all dotless domains, so you don't need to 
specify specific domains to allow.

- Though maybe it still makes sense to deny dotless domain names.

I think the options currently are:
1 - Immediately remove domain_whitelist so people get a hard error. It's 
probably not used in third-party apps where multiple Django version support 
might be important.

2 - Deprecate domain_whitelist and ignore with a warning.

3 - Keep restricting dotless domains unless they are in domain_whitelist.

Collin

[0] https://github.com/django/django/pull/8081


On Tuesday, April 5, 2016 at 1:41:14 PM UTC-4, Tim Graham wrote:
>
> Any thoughts about whether or not to make similar simplifications to 
> URLValidator? There's an old ticket to add a DomainNameValidator [0] 
> which may or may not be worth moving forward with based on the decision.
>
> [0] https://code.djangoproject.com/ticket/18119
>
> On Saturday, April 2, 2016 at 3:05:14 AM UTC-4, Shai Berger wrote:
>>
>> On Saturday 02 April 2016 09:44:54 Josh Smeaton wrote: 
>> > For what reason Zach? 
>>
>> There is only one reason for which a strict and accurate validation is 
>> required, as far as I can see, and that is if your application is not 
>> just 
>> using existing email addresses (i.e. sending mail to users) but actually 
>> manages them (i.e. creates mail addresses). 
>>
>> Such applications are few and far between... 
>>
>> > Without a canonical regex implementation to copy or 
>> > include, we're stuck poorly reimplementing a bunch of esoteric rules to 
>> > what end? The main purpose of email validation is to provide relevant 
>> > feedback to the user, and to guard against obviously bad or malicious 
>> data. 
>> > "Looks vaguely like an email address" is probably too loose to be 
>> useful, I 
>> > admit. The proposal to copy the regex from the html5 email input widget 
>> > seems like a fine compromise to me. 
>> > 
>> > We should also err on the side of allowing incorrect addresses rather 
>> than 
>> > rejecting correct addresses. I'd much rather have bad signups that need 
>> to 
>> > be done again rather than users that can't sign up with their valid 
>> > addresses. 
>> > 
>>
>> ...and their needs should not imply a high burden of maintenance on the 
>> rest 
>> of the community; they can and should implement their own validation. 
>>
>> +1 everything Josh said. 
>>
>> Shai. 
>>
>

-- 
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+unsubscr...@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/e6074d2a-b84f-41cb-bd77-842c63169f2f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

migrate id field from integer to biginter (probable bug)

[drakkan]

Hi,

I have two models like these:

class Allarme(models.Model):


class Registrazione(models.Model):
   allarme = models.ForeignKey(Allarme, blank=True, null=True, 
on_delete=models.DO_NOTHING, db_constraint=False)
   

now I want to change id field for these models from int to bigint so I 
added to both

id = models.BigAutoField(primary_key=True)

and I did the migration,

python manage.py sqlmigrate

show something like this:

BEGIN;
--
-- Alter field id on allarme
--
ALTER TABLE "multimedia_allarmi" ALTER COLUMN "id" TYPE bigint USING 
"id"::bigint;
DROP SEQUENCE IF EXISTS "multimedia_allarmi_id_seq" CASCADE;
CREATE SEQUENCE "multimedia_allarmi_id_seq";
ALTER TABLE "multimedia_allarmi" ALTER COLUMN "id" SET DEFAULT 
nextval('"multimedia_allarmi_id_seq"');
SELECT setval('"multimedia_allarmi_id_seq"', MAX("id")) FROM 
"multimedia_allarmi";
ALTER TABLE "multimedia_registrazioni" ALTER COLUMN "allarme_id" TYPE 
bigint USING "allarme_id"::bigint;
*ALTER TABLE "multimedia_registrazioni" ADD CONSTRAINT 
"multimedia_registrazioni_allarme_id_4919213e_fk" FOREIGN KEY 
("allarme_id") REFERENCES "multimedia_allarmi" ("id") DEFERRABLE INITIALLY 
DEFERRED;*
--
-- Alter field id on registrazione
--
ALTER TABLE "multimedia_registrazioni" ALTER COLUMN "id" TYPE bigint USING 
"id"::bigint;
DROP SEQUENCE IF EXISTS "multimedia_registrazioni_id_seq" CASCADE;
CREATE SEQUENCE "multimedia_registrazioni_id_seq";
ALTER TABLE "multimedia_registrazioni" ALTER COLUMN "id" SET DEFAULT 
nextval('"multimedia_registrazioni_id_seq"');
SELECT setval('"multimedia_registrazioni_id_seq"', MAX("id")) FROM 
"multimedia_registrazioni";
COMMIT;

so as you can see a foreign key is added for a model field with 
db_constraint=False, 

can you please confirm that this is a bug? I'm using django 1.11.1

thanks!


-- 
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+unsubscr...@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/18bafe5a-6cc0-412d-8e51-672b15f08325%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Make bool(AnonymousUser) evaluate to false

[Tobias McNulty]

I second the objections; my assumption when reading the line 'if
request.user:' is that it's shorthand for 'if request.user is None', which
is not the case.

Grepping a project's code for incorrect usage of 'request.user' is simple
enough, so hopefully that will suffice. I don't recommend this because I
think existing Django developers would find it confusing, but technically
it would be possible to change or swap out instances of AnonymousUser via
middleware, too.

Lastly, this related ticket might be of interest:
https://code.djangoproject.com/ticket/20313

Tobias


*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.com

On Wed, May 31, 2017 at 12:56 PM, Tim Graham  wrote:

> My thoughts from the ticket, "The Django test suite passes with the change
> but I feel like that could have some backwards compatibility concerns. Also
> "explicit is better than implicit"?
>
> On Wednesday, May 31, 2017 at 12:44:51 PM UTC-4, Linus Lewandowski wrote:
>>
>> I suggest adding __bool__() method returning False to the AnonymousUser
>> class.
>>
>> This way it'll be possible to check if the user is authenticated by
>> simply writing "if request.user:"
>>
>> It's a frequent source of bugs (at least for me, but probably I'm not
>> alone) that right now this code returns True for anonymous users. If
>> unnoticed, such bugs can also lead to security issues.
>>
>> Related ticket: https://code.djangoproject.com/ticket/28259
>>
> --
> 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+unsubscr...@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/0c20c042-cc34-4707-a3e0-
> eed3ce2cf83d%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@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/CAMGFDKQCfScbHYA8JfLtb2cDqt9Nz%3DA%3D8Qg9wJRhkz0sGju6GQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Make bool(AnonymousUser) evaluate to false

[Tim Graham]

My thoughts from the ticket, "The Django test suite passes with the change 
but I feel like that could have some backwards compatibility concerns. Also 
"explicit is better than implicit"?

On Wednesday, May 31, 2017 at 12:44:51 PM UTC-4, Linus Lewandowski wrote:
>
> I suggest adding __bool__() method returning False to the AnonymousUser 
> class.
>
> This way it'll be possible to check if the user is authenticated by simply 
> writing "if request.user:"
>
> It's a frequent source of bugs (at least for me, but probably I'm not 
> alone) that right now this code returns True for anonymous users. If 
> unnoticed, such bugs can also lead to security issues.
>
> Related ticket: https://code.djangoproject.com/ticket/28259
>

-- 
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+unsubscr...@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/0c20c042-cc34-4707-a3e0-eed3ce2cf83d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Make bool(AnonymousUser) evaluate to false

[Adam Johnson]

I'm afraid I'm -1 on this. We already have if request.user.is_authenticated and
request.user.is_anonymous which are both more explicit and pythonic.
Additionally all python classes, and thus instances of User atm, are by
default truthy, so implementing this custom __bool__ introduces space for
more subtle bugs, e.g. the result of filter([request.user]) would change.

On 31 May 2017 at 17:44,  wrote:

> I suggest adding __bool__() method returning False to the AnonymousUser
> class.
>
> This way it'll be possible to check if the user is authenticated by simply
> writing "if request.user:"
>
> It's a frequent source of bugs (at least for me, but probably I'm not
> alone) that right now this code returns True for anonymous users. If
> unnoticed, such bugs can also lead to security issues.
>
> Related ticket: https://code.djangoproject.com/ticket/28259
>
> --
> 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+unsubscr...@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/065eb9a5-d935-466d-a301-
> d7de87e6fbb0%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Adam

-- 
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+unsubscr...@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/CAMyDDM38GohUBWwBp-TxKC9soHKhspKPjvX6BzcwmyhGgK%3Dbmg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Make bool(AnonymousUser) evaluate to false

[linus]

I suggest adding __bool__() method returning False to the AnonymousUser 
class.

This way it'll be possible to check if the user is authenticated by simply 
writing "if request.user:"

It's a frequent source of bugs (at least for me, but probably I'm not 
alone) that right now this code returns True for anonymous users. If 
unnoticed, such bugs can also lead to security issues.

Related ticket: https://code.djangoproject.com/ticket/28259

-- 
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+unsubscr...@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/065eb9a5-d935-466d-a301-d7de87e6fbb0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

should nonexistent template filter arguments resolve to string_if_invalid rather than raise VariableDoesNotExist?

[Tim Graham]

Should nonexistent template filter arguments raise an exception? Current 
behavior:

{{ value|filter:nonexistent_template_var}}

raises VariableDoesNotExist for nonexistent_template_var.

I guess the proposal would be to make nonexistent_tempatle_var resolve to 
string_if_invalid. As for me, I think the current behavior is less error 
prone.

Related tickets:

https://code.djangoproject.com/ticket/13167
This was first closed incorrectly as "fixed" by Jacob (actually a different 
issue was fixed), then amended as wontfix by Karen with the note, "I'm fine 
with wontfixing that, though it does rather seem to go against "template 
errors don't raise exceptions" philosophy."

https://code.djangoproject.com/ticket/28172
A follow up ticket requesting the same thing as #13167.

-- 
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+unsubscr...@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/02727bd0-5a67-4cf9-9c3f-b0a0a7ea0a3a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django db backend not 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?

On Wednesday, May 31, 2017 at 9:28:29 AM UTC-4, Brandon Williams wrote:
>
> 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 
>> 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?
>

-- 
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+unsubscr...@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.

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 
> 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?

-- 
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+unsubscr...@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/c99beff4-f117-4afc-918c-009b598ca018%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.