Note for ReviewBoard , Django 1.6.11.3 backport the fix :
https://raw.githubusercontent.com/beanbaginc/django/security-backports/1.6.x/docs/releases/1.6.11.3.txt

CVE-2016-2513 and CVE-2016-2512

Ubuntu has issued an advisory for this on March 1:
http://www.ubuntu.com/usn/usn-2915-1/

URL: (none) => http://lwn.net/Vulnerabilities/678395/

python-django-1.8.10-1.mga5.noarch.rpm
python-django-bash-completion-1.8.10-1.mga5.noarch.rpm
python3-django-1.8.10-1.mga5.noarch.rpm
python-django-doc-1.8.10-1.mga5.noarch.rpm

from python-django-1.8.10-1.mga5.src.rpm

Are in 5/core/updates_testing

Cauldron updated too for 1.8 and 1.6

Advisory

Mark Striemer discovered that Django incorrectly handled user-supplied
redirect URLs containing basic authentication credentials. A remote
attacker could possibly use this issue to perform a cross-site scripting
attack or a malicious redirect. (CVE-2016-2512)

Sjoerd Job Postmus discovered that Django incorrectly handled timing when
doing password hashing operations. A remote attacker could possibly use
this issue to perform user enumeration. (CVE-2016-2513)

Ref :
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2512
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2513
http://www.ubuntu.com/usn/usn-2915-1/
https://www.djangoproject.com/weblog/2016/mar/01/security-releases/

Thanks Philippe!

I thought we were going to remove 1.6 from Cauldron and just have it in an infra_6 repository?

CC: (none) => makowski.mageia
CVE: CVE-2016-2512 and CVE-2016-2513 => CVE-2016-2512, CVE-2016-2513
Version: Cauldron => 5
Whiteboard: MGA5TOO => (none)

Testing procedure:
https://bugs.mageia.org/show_bug.cgi?id=13251#c6

Whiteboard: (none) => has_procedure

I will test this for x64.

CC: (none) => lewyssmith

Testing x64

As well as the test procedure noted in Comment 5, there is an addendum:
 https://bugs.mageia.org/show_bug.cgi?id=17215#c5
I summarise both integrated for future ref:
Python
-----
 $ django-admin startproject mysite               [NOT django-admin.py]
 $ cd mysite/
 $ python manage.py runserver
Performing system checks...

System check identified no issues (0 silenced).

You have unapplied migrations; your app may not work properly until they are applied.
Run 'python manage.py migrate' to apply them.

March 04, 2016 - 18:58:12
Django version 1.8.10, using settings 'mysite.settings'
Starting development server at http://127.0.0.1:8000/
Quit the server with CONTROL-C.
^C
 $ python manage.py migrate
Operations to perform:
  Synchronize unmigrated apps: staticfiles, messages
  Apply all migrations: admin, contenttypes, auth, sessions
Synchronizing apps without migrations:
  Creating tables...
    Running deferred SQL...
  Installing custom SQL...
Running migrations:
  Rendering model states... DONE
  Applying contenttypes.0001_initial... OK
  Applying auth.0001_initial... OK
  Applying admin.0001_initial... OK
  Applying contenttypes.0002_remove_content_type_name... OK
  Applying auth.0002_alter_permission_name_max_length... OK
  Applying auth.0003_alter_user_email_max_length... OK
  Applying auth.0004_alter_user_username_opts... OK
  Applying auth.0005_alter_user_last_login_null... OK
  Applying auth.0006_require_contenttypes_0002... OK
  Applying sessions.0001_initial... OK
 $ python manage.py runserver
Performing system checks...

System check identified no issues (0 silenced).
March 04, 2016 - 18:58:46
Django version 1.8.10, using settings 'mysite.settings'
Starting development server at http://127.0.0.1:8000/
Quit the server with CONTROL-C.

[ Point a browser to http://localhost:8000/ and you should see:
"It worked!
 Congratulations on your first Django-powered page." ]

^C
$ cd ..                [To tidy up]
$ rm -rf mysite/

Python3
------
 $ python3-django-admin startproject mysite     [NOT python3-django-admin.py]
 $ cd mysite/
 $ python3 manage.py runserver
Performing system checks...
...etc as above...
^C
 $ python3 manage.py migrate
...O/P as above...
 $ python3 manage.py runserver
Performing system checks...
...etc as above...
[ Same browser test as above]
^C
$ cd ..                [To tidy up]
$ rm -rf mysite/

Did this both before and after the innocuous update to:
 python-django-1.8.10-1.mga5
 python3-django-1.8.10-1.mga5
 python-django-bash-completion-1.8.10-1.mga5
 python-django-doc-1.8.10-1.mga5
Test results were the same for both python & python3. Update OK.

Whiteboard: has_procedure => has_procedure MGA5-64-OK

This is a noarch package but I am confirming that it runs on a 32-bit virtualbox.
Pre-update:
Results of the tests were exactly the same as in the 64bit case above.
[lcl@alkaid ~/mysite]$ python manage.py runserver
Performing system checks...

System check identified no issues (0 silenced).
March 06, 2016 - 21:04:46
Django version 1.8.7, using settings 'mysite.settings'
Starting development server at http://127.0.0.1:8000/
Quit the server with CONTROL-C.
# Pointed the browser at localhost:8000 and saw the success message.
[06/Mar/2016 21:06:11] "GET / HTTP/1.1" 200 1767
[06/Mar/2016 21:06:11] "GET /favicon.ico HTTP/1.1" 404 1936
[06/Mar/2016 21:06:11] "GET /favicon.ico HTTP/1.1" 404 1936
^C
Cleaned up and ran python3 tests.
These finished with a single line:
[06/Mar/2016 21:18:53] "GET / HTTP/1.1" 200 1767

Updated the packages and repeated these actions for python and python3 and
observed precisely the same behaviour.

@lewis
Leaving you to validate this sir.

CC: (none) => tarazed25

Update validated.
 SRPM: python-django-1.8.10-1.mga5.src.rpm
 Advisory (yet to be uploaded) in Comment 3
Could sysadmin please push from core/updates_testing to core/updates.

Keywords: (none) => validated_update
CC: (none) => sysadmin-bugs
Source RPM: python-django-1.8.7-1.mga5.src.rpm => python-django-1.8.10-1.mga5.src.rpm

Advisory uploaded.

Whiteboard: has_procedure MGA5-64-OK MGA5-32-OK => has_procedure MGA5-64-OK MGA5-32-OK advisory

An update for this issue has been pushed to the Mageia Updates repository.

http://advisories.mageia.org/MGASA-2016-0096.html

Status: NEW => RESOLVED
Resolution: (none) => FIXED

Note this from Ubuntu about a regression caused by the CVE-2016-2512 fix:
http://www.ubuntu.com/usn/usn-2915-2

Damn! Can we pull back this update (I doubt it); or do another one quickly?

I doubt it's serious enough to pull it back, but we can do another one.

It looks like 1.8.11 will fix the regression and be released shortly if it hasn't been released already.  The three upstream commits for the regression fix are linked in the Ubuntu Launchpad bug.

I submitted 1.8.11

(In reply to Philippe Makowski from comment #15)
> I submitted 1.8.11

Thanks.  Bug 17915 filed.