Re: Coordinating uploads with identical tarballs

[Salvatore Bonaccorso]

Hi,

On Mon, Aug 01, 2016 at 09:35:34PM +0200, Emilio Pozuelo Monfort wrote:
> On 01/08/16 21:29, Moritz Mühlenhoff wrote:
> > Hi,
> > when making uploads with an identical tarball in lts and stable-security
> > you really need to coordinate with t...@security.debian.org! Due to dak's
> > crappy orig tarball handling only of the uploads can be made with the
> > tarball included and if you race to the upload without coordination you're
> > only causing extra work on our side as it happened for the openjdk-7
> > DLA :-/
> 
> Very sorry about that. I didn't think about it. Thanks for letting me know -
> I'll keep that in mind for future updates.

JFTR, in this case, the actual problem was that openjdk-7 for
wheezy-security was stuck in unchecked, due to a broken .dsc file. I'm
cc'ing Ansgar, who can certainly explain better what happened.

Regards,
Salvatore

Re: Bug#832908: mongodb: CVE-2016-6494: world-readable .dbshell history file: LTS update and upgrade handling

[Ola Lundqvist]

Hi again

I just realize that we need to change back the umask after the file is
created. I'll update the patch tomorrow and send one that I know works.

// Ola

On Tue, Aug 2, 2016 at 12:13 AM, Ola Lundqvist  wrote:

> Hi all
>
> I have prepared a preliminary patch for wheezy. I have not yet been able
> to test it fully (it is building right now). It looks like attached. You
> may need to modify it for later versions.
>
> Please comment. The principles should be ok even if I may have made some
> stupid copy+paste mistake. It worked fine in a little test program I made.
>
> Hope this helps
>
> // Ola
>
> On Mon, Aug 1, 2016 at 5:53 AM, Chris Lamb  wrote:
>
>> > 2) How do you plan to handle the "upgrade case" that is will you try to
>> > change the permission on already created history file or will you just
>> > handle the creation case?
>>
>> For redis, what I did was set and then unset the umask (for creation) and
>> chmod(2) the file afterwards to "upgrade" existing ones.
>>
>> I don't recommend a postinst approach (ie. chmod 0600 /home/*/.filename)
>> for
>> various reasons.
>>
>>
>> Regards,
>>
>> --
>>   ,''`.
>>  : :'  : Chris Lamb
>>  `. `'`  la...@debian.org / chris-lamb.co.uk
>>`-
>>
>
>
>
> --
>  --- Inguza Technology AB --- MSc in Information Technology 
> /  o...@inguza.comFolkebogatan 26\
> |  o...@debian.org   654 68 KARLSTAD|
> |  http://inguza.com/Mobile: +46 (0)70-332 1551 |
> \  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
>  ---
>
>


-- 
 --- Inguza Technology AB --- MSc in Information Technology 
/  o...@inguza.comFolkebogatan 26\
|  o...@debian.org   654 68 KARLSTAD|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---

Re: Bug#832908: mongodb: CVE-2016-6494: world-readable .dbshell history file: LTS update and upgrade handling

[Ola Lundqvist]

Hi all

I have prepared a preliminary patch for wheezy. I have not yet been able to
test it fully (it is building right now). It looks like attached. You may
need to modify it for later versions.

Please comment. The principles should be ok even if I may have made some
stupid copy+paste mistake. It worked fine in a little test program I made.

Hope this helps

// Ola

On Mon, Aug 1, 2016 at 5:53 AM, Chris Lamb  wrote:

> > 2) How do you plan to handle the "upgrade case" that is will you try to
> > change the permission on already created history file or will you just
> > handle the creation case?
>
> For redis, what I did was set and then unset the umask (for creation) and
> chmod(2) the file afterwards to "upgrade" existing ones.
>
> I don't recommend a postinst approach (ie. chmod 0600 /home/*/.filename)
> for
> various reasons.
>
>
> Regards,
>
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-
>



-- 
 --- Inguza Technology AB --- MSc in Information Technology 
/  o...@inguza.comFolkebogatan 26\
|  o...@debian.org   654 68 KARLSTAD|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---
Description: World readable dbshell log file
 This correction make sure the ~/.dbshell log file is not world readable.
 .
 mongodb (1:2.0.6-1deb7u1) wheezy-security; urgency=high
 .
   * Non-maintainer upload by the Long Term Security Team.
   * Make sure dbshell log file is not readable by others.
Author: Ola Lundqvist 
Origin: other
Bug: https://jira.mongodb.org/browse/SERVER-25335
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832908
Forwarded: no
Reviewed-By: Ola Lundqvist 
Last-Update: 2016-08-01

Index: mongodb-2.0.6/third_party/linenoise/linenoise.cpp
===
--- mongodb-2.0.6.orig/third_party/linenoise/linenoise.cpp	2012-06-04 13:42:54.0 +
+++ mongodb-2.0.6/third_party/linenoise/linenoise.cpp	2016-08-01 22:05:34.234826380 +
@@ -104,11 +104,13 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -799,6 +801,9 @@
 /* Save the history in the specified file. On success 0 is returned
  * otherwise -1 is returned. */
 int linenoiseHistorySave(const char *filename) {
+mode_t prev_mask = umask(0022);
+// Make sure this file is not readable by others
+umask(prev_mask | S_IROTH | S_IWOTH | S_IXOTH);
 FILE *fp = fopen(filename,"w");
 int j;
 
@@ -817,6 +822,16 @@
  * If the file exists and the operation succeeded 0 is returned, otherwise
  * on error -1 is returned. */
 int linenoiseHistoryLoad(const char *filename) {
+struct stat fileStat;
+if (stat(filename,) < 0) return -1;
+if (fileStat.st_mode & S_IROTH ||
+	fileStat.st_mode & S_IWOTH ||
+	fileStat.st_mode & S_IXOTH) {
+  // If the file is world readable, writeable or executable
+  // make sure it is not but keep all other permissions.
+  chmod(filename, fileStat.st_mode & 070);
+}
+
 FILE *fp = fopen(filename,"r");
 char buf[LINENOISE_MAX_LINE];
 

Re: Redis not uploaded and timely security announcements

[Chris Lamb]

> Ahh, I wasn't going mad after all:
> 
> 14:30 < carnil> lamby ftr, due to some dak problems your redis upload 
> is stuck in unchecked, ansgar will look into it tonight
> 
> 14:31 < carnil> so please be pantient, should be processed as soon 
> the dak problem is solved on security-master, ansgar told me he will look 
> into it tonight.

Just received "redis_2.4.14-1+deb7u1_amd64.changes ACCEPTED into oldstable".


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Accepted redis 2:2.4.14-1+deb7u1 (source amd64) into oldstable

[Chris Lamb]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Mon, 01 Aug 2016 11:32:06 -0400
Source: redis
Binary: redis-server
Architecture: source amd64
Version: 2:2.4.14-1+deb7u1
Distribution: wheezy-security
Urgency: high
Maintainer: Chris Lamb 
Changed-By: Chris Lamb 
Description: 
 redis-server - Persistent key-value database with network interface
Closes: 832460
Changes: 
 redis (2:2.4.14-1+deb7u1) wheezy-security; urgency=high
 .
   * CVE-2013-7458: Prevent world-readable ~/.rediscli_history files.
 (Closes: #832460)
Checksums-Sha1: 
 a0f0a5f2d8f8947db410a2e8cc91d01fa1790d0d 1812 redis_2.4.14-1+deb7u1.dsc
 3f0a2ac2eef9319edb0d789d3553f77b2a3dc31d 627494 redis_2.4.14.orig.tar.gz
 a46f0d89961c6d938436929036165c673f59b590 18087 
redis_2.4.14-1+deb7u1.debian.tar.gz
 575c93e87830b4623dc52ac099c3bca9f557286f 235564 
redis-server_2.4.14-1+deb7u1_amd64.deb
Checksums-Sha256: 
 b17d944e84964c697bbc33909e930d24d007d9812545813a3ad40710bda0770f 1812 
redis_2.4.14-1+deb7u1.dsc
 4f26ae8cad0f9143ef30b9bb9565a1618570654eb86ee911c20966971660cc7e 627494 
redis_2.4.14.orig.tar.gz
 5135be5c69ff3729f570f10a134a5d475b4755bedd92a25d87617b44614d1368 18087 
redis_2.4.14-1+deb7u1.debian.tar.gz
 24180b92380459fa114caf67b09de062aaf4c67e7c663a629ee5cd4bcaac4f30 235564 
redis-server_2.4.14-1+deb7u1_amd64.deb
Files: 
 7842731a86529facd095b92fceebb52e 1812 database optional 
redis_2.4.14-1+deb7u1.dsc
 1bc8f833b955ef119d643da08084433f 627494 database optional 
redis_2.4.14.orig.tar.gz
 941847fcdee14ef44fcd0005c4a9cd41 18087 database optional 
redis_2.4.14-1+deb7u1.debian.tar.gz
 34c81a309131d5aea56ade0f270922ea 235564 database optional 
redis-server_2.4.14-1+deb7u1_amd64.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJXn2wJAAoJEB6VPifUMR5YF4AQAIwYLn/05oYo9fdBSVASxKts
tPqLB4KgJVSKENiQUrDM9+6NP5jMXsZnSSkvLuJI4qJcNNH3xdZv3ak5B+2lUBzn
FwxA5Qm18o/7ImAlnupPOVyOgmvmHZ+LW17dHPg5NkE0gImPDAxYqUM/p59Lt7HM
Y+2USCdj46BDFtYocKXVxz/kPhNZN3dnfjBRDx0/uhOa1+mrmEin+v8tpjDl4ZiO
ANTxHqqMT3I22smJG7KFdDNuqO8NGDadNIpDmdWfglCM5RWTKPCazDksX5zD63J4
ac6ICxwHdFqLOh3+eHBdjcZKKnxyV5Dc3lCInaZRFXVrtGBkjqWrzObsExCZuOnw
o05NxOfB0Rzwx/sukl0MCWInHbwTp7tSg9T7+fWo2UQHG+6tA+SeMzBIg/cBKUi0
Gqqhze1kZgRSEWQuw+lIohb2moHKOyEh7RglKmwpFhbHHNevAMtQmiMETbdDIE8Q
+P7eWmsFVIbAC7FQ5EiMwCKjVoQlfhwZT94Yaw12nVeVEcsPIAZE5MMuADG1JjPt
4NPbdmnVY1WPelJrEk2E+QlYzLQwBgvE7mF7vktOnryi8KV6sj40vLZPx3R61yXO
ks4/B9KtdtJEg3nOdvkx+nT3FCOl9n1cVbObBlBDt4ZZjGe5oDCVrBMQv5EnLUMh
AgsQhoRs93Q0UGwFTPLo
=dYvP
-END PGP SIGNATURE-

Re: Icedtea plugin

[Markus Koschany]

On 01.08.2016 23:01, Emilio Pozuelo Monfort wrote:
> On 31/07/16 19:41, Roberto C. Sánchez wrote:
>> On Sun, Jul 31, 2016 at 07:34:28PM +0200, Emilio Pozuelo Monfort wrote:
>>> Hi,
>>>
>>> Currently, icedtea-plugin depends on icedtea-6-plugin, i.e. Java6. Given
>>> openjdk-6 is unsupported, we should change it to depend on icedtea-7-plugin
>>> instead. See the attached source debdiff (the control file is 
>>> autogenerated).
>>>
>>> Thoughts?
>>>
>>> If no-one objects, I will upload that soon.
>>>
>>
>> It looks good to me.
> 
> Markus said on IRC that another option was to mark icedtea-plugin and
> icedtea-6-plugin as unsupported. However, I think we should only do that for
> icedtea-6-plugin, and update the metapackage to depend on Java7.

Yes, it wouldn't hurt to update the dependency package icedtea-plugin.
As far as I know it has no important reverse-dependencies though, for
instance OpenJDk 6 only suggests it. So we could also just mark it as
unsupported but I leave the decision up to you.

Regards,

Markus




signature.asc
Description: OpenPGP digital signature

Re: Redis not uploaded and timely security announcements

[Chris Lamb]

Chris Lamb wrote:

> > DLA-577-1 has been issued two days ago but redis hasn't been uploaded
> > yet. Chris could you investigate please?
> 
> Very odd; I distinctly remember uploading this as my machine was
> aggressively firewalled (internet cafe!) so I had to route it through
> another host. "Re"-uploaded now.

Ahh, I wasn't going mad after all:

14:30 < carnil> lamby ftr, due to some dak problems your redis upload 
is stuck in unchecked, ansgar will look into it tonight

14:31 < carnil> so please be pantient, should be processed as soon the 
dak problem is solved on security-master, ansgar told me he will look into it 
tonight.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Re: Icedtea plugin

[Emilio Pozuelo Monfort]

On 31/07/16 19:41, Roberto C. Sánchez wrote:
> On Sun, Jul 31, 2016 at 07:34:28PM +0200, Emilio Pozuelo Monfort wrote:
>> Hi,
>>
>> Currently, icedtea-plugin depends on icedtea-6-plugin, i.e. Java6. Given
>> openjdk-6 is unsupported, we should change it to depend on icedtea-7-plugin
>> instead. See the attached source debdiff (the control file is autogenerated).
>>
>> Thoughts?
>>
>> If no-one objects, I will upload that soon.
>>
> 
> It looks good to me.

Markus said on IRC that another option was to mark icedtea-plugin and
icedtea-6-plugin as unsupported. However, I think we should only do that for
icedtea-6-plugin, and update the metapackage to depend on Java7.

Cheers,
Emilio

Re: Coordinating uploads with identical tarballs

[Emilio Pozuelo Monfort]

On 01/08/16 21:29, Moritz Mühlenhoff wrote:
> Hi,
> when making uploads with an identical tarball in lts and stable-security
> you really need to coordinate with t...@security.debian.org! Due to dak's
> crappy orig tarball handling only of the uploads can be made with the
> tarball included and if you race to the upload without coordination you're
> only causing extra work on our side as it happened for the openjdk-7
> DLA :-/

Very sorry about that. I didn't think about it. Thanks for letting me know -
I'll keep that in mind for future updates.

Cheers,
Emilio

Coordinating uploads with identical tarballs

[Moritz Mühlenhoff]

Hi,
when making uploads with an identical tarball in lts and stable-security
you really need to coordinate with t...@security.debian.org! Due to dak's
crappy orig tarball handling only of the uploads can be made with the
tarball included and if you race to the upload without coordination you're
only causing extra work on our side as it happened for the openjdk-7
DLA :-/

Cheers,
Moritz

Wheezy and jessie updates of lighttpd

[Santiago R.R.]

Hi,

El 29/07/16 a las 09:54, Krzysztof Krzyżaniak escribió:
> 
> 
> W dniu czw 28 lip, 2016 o 22∶36 użytkownik Thorsten Alteholz
>  napisał:
> 
> Hello dear maintainer(s), the Debian LTS team would like to fix the
> security issues which are currently open in the Wheezy version of 
> lighttpd:
> https://security-tracker.debian.org/tracker/CVE-2016-1000212 Would you 
> like
> to take care of this yourself?
> 
> 
> I don't have any Wheezy on my own. I would need to install it on some vm, it
> think I could maybe do this over the weekend. So if you have someone else to 
> do
> it faster feel free to do it. 
> 
>   eloy
> *

Please, find attached debdiffs to mitigate this in wheezy (that I plan
to upload) and jessie. I have tested it with a python cgi taken from
httpoxy's PoCs, and it seems to work well. However, I am not familiar
with lighttpd, so any review is welcome.

Cheers,

Santiago
diff -Nru lighttpd-1.4.31/debian/changelog lighttpd-1.4.31/debian/changelog
--- lighttpd-1.4.31/debian/changelog2016-02-23 11:10:46.0 +0100
+++ lighttpd-1.4.31/debian/changelog2016-08-01 18:01:58.0 +0200
@@ -1,3 +1,12 @@
+lighttpd (1.4.31-4+deb7u5~1) santiago-wheezy; urgency=medium
+
+  * Non-maintainer upload by the Debian LTS Team.
+  * Fix CVE-2016-1000212: Mitigate HTTPoxy vulnerability.
+  * Add buffer_is_equal_caseless_string.patch
+  * Add mitigate-httpoxy-779c133c16f9af168b004dce7a2a64f16c1cb3a4.patch
+
+ -- Santiago R.R.   Fri, 29 Jul 2016 18:16:19 +0200
+
 lighttpd (1.4.31-4+deb7u4) wheezy-security; urgency=high
 
   * Non-maintainer upload.
diff -Nru lighttpd-1.4.31/debian/patches/buffer_is_equal_caseless_string.patch 
lighttpd-1.4.31/debian/patches/buffer_is_equal_caseless_string.patch
--- lighttpd-1.4.31/debian/patches/buffer_is_equal_caseless_string.patch
1970-01-01 01:00:00.0 +0100
+++ lighttpd-1.4.31/debian/patches/buffer_is_equal_caseless_string.patch
2016-08-01 18:01:58.0 +0200
@@ -0,0 +1,67 @@
+Description: backport buffer.c buffer_is_equal_caseless_string()
+ needed to mitigate httpoxy vulnerability.
+Author: Santiago R.R. 
+
+--- a/src/buffer.c
 b/src/buffer.c
+@@ -533,6 +533,15 @@
+   return buffer_is_equal(a, );
+ }
+ 
++/* buffer_is_equal_caseless_string(b, CONST_STR_LEN("value")) */
++int buffer_is_equal_caseless_string(const buffer *a, const char *s, size_t 
b_len) {
++  force_assert(NULL != a);
++  if (a->used != b_len + 1) return 0;
++  force_assert('\0' == a->ptr[a->used - 1]);
++
++  return (0 == strcasecmp(a->ptr, s));
++}
++
+ /* simple-assumption:
+  *
+  * most parts are equal and doing a case conversion needs time
+@@ -1075,3 +1084,10 @@
+ 
+   return 0;
+ }
++
++void log_failed_assert(const char *filename, unsigned int line, const char 
*msg) {
++  /* can't use buffer here; could lead to recursive assertions */
++  fprintf(stderr, "%s.%u: %s\n", filename, line, msg);
++  fflush(stderr);
++  abort();
++}
+--- a/src/buffer.h
 b/src/buffer.h
+@@ -82,6 +82,7 @@
+ int buffer_is_equal(buffer *a, buffer *b);
+ int buffer_is_equal_right_len(buffer *a, buffer *b, size_t len);
+ int buffer_is_equal_string(buffer *a, const char *s, size_t b_len);
++int buffer_is_equal_caseless_string(const buffer *a, const char *s, size_t 
b_len);
+ int buffer_caseless_compare(const char *a, size_t a_len, const char *b, 
size_t b_len);
+ 
+ typedef enum {
+@@ -125,6 +126,8 @@
+ #define CONST_STR_LEN(x) x, x ? sizeof(x) - 1 : 0
+ #define CONST_BUF_LEN(x) x->ptr, x->used ? x->used - 1 : 0
+ 
++void log_failed_assert(const char *filename, unsigned int line, const char 
*msg) LI_NORETURN;
++#define force_assert(x) do { if (!(x)) log_failed_assert(__FILE__, __LINE__, 
"assertion failed: " #x); } while(0)
+ 
+ #define SEGFAULT() do { fprintf(stderr, "%s.%d: aborted\n", __FILE__, 
__LINE__); abort(); } while(0)
+ #define UNUSED(x) ( (void)(x) )
+--- a/src/settings.h
 b/src/settings.h
+@@ -9,6 +9,12 @@
+ # define __USE_GNU /* a hack in my eyes,  F_SETSIG should work with 
_GNU_SOURCE */
+ #endif
+ 
++#ifdef __GNUC__
++# define LI_NORETURN __attribute__((noreturn))
++#else
++# define LI_NORETURN
++#endif
++
+ #define BV(x) (1 << x)
+ 
+ #define INET_NTOP_CACHE_MAX 4
diff -Nru 
lighttpd-1.4.31/debian/patches/mitigate-httpoxy-779c133c16f9af168b004dce7a2a64f16c1cb3a4.patch
 
lighttpd-1.4.31/debian/patches/mitigate-httpoxy-779c133c16f9af168b004dce7a2a64f16c1cb3a4.patch
--- 
lighttpd-1.4.31/debian/patches/mitigate-httpoxy-779c133c16f9af168b004dce7a2a64f16c1cb3a4.patch
  1970-01-01 01:00:00.0 +0100
+++ 
lighttpd-1.4.31/debian/patches/mitigate-httpoxy-779c133c16f9af168b004dce7a2a64f16c1cb3a4.patch
  2016-08-01 18:02:27.0 +0200
@@ -0,0 +1,126 @@
+Description: backported patch to mitigate httpoxy vulnerability
+Origin: upstream, 

Re: Wheezy update of python-django?

[Brian May]

Brian May  writes:

> In any case I am looking at doing this now, will start off without
> git. If there is any demand I can move things across (including prior
> revisions) to git later.

Attached is my current patch. It only includes changes to
debian/*. Still needs more work. In particular, I think the
CVE-2016-2513.diff patch is needed; didn't apply it yet as one hunk
conflicts, will look into this now.

Need to double check that all the other patches really are not required.
-- 
Brian May 
diff -Nru python-django-1.4.5/debian/changelog python-django-1.4.22/debian/changelog
--- python-django-1.4.5/debian/changelog	2016-03-26 00:39:46.0 +1100
+++ python-django-1.4.22/debian/changelog	2016-08-01 07:59:10.0 +1000
@@ -1,3 +1,10 @@
+python-django (1.4.22-1) UNRELEASED; urgency=medium
+
+  * New upstream release
+  * Update wheezy to latest version in 1.4.x series.
+
+ -- Brian May   Mon, 01 Aug 2016 07:58:39 +1000
+
 python-django (1.4.5-1+deb7u16) wheezy-security; urgency=high
 
   * Non-maintainer upload by the Security Team.
diff -Nru python-django-1.4.5/debian/patches/CVE-2016-2512.diff python-django-1.4.22/debian/patches/CVE-2016-2512.diff
--- python-django-1.4.5/debian/patches/CVE-2016-2512.diff	2016-03-26 00:39:46.0 +1100
+++ python-django-1.4.22/debian/patches/CVE-2016-2512.diff	2016-08-01 08:00:51.0 +1000
@@ -14,7 +14,7 @@
 
 --- a/django/utils/http.py
 +++ b/django/utils/http.py
-@@ -237,8 +237,12 @@ def is_safe_url(url, host=None):
+@@ -237,8 +237,12 @@
  url = url.strip()
  if not url:
  return False
@@ -31,7 +31,7 @@
  if url.startswith('///'):
 --- a/django/contrib/auth/tests/views.py
 +++ b/django/contrib/auth/tests/views.py
-@@ -312,7 +312,12 @@ class LoginTest(AuthViewsTestCase):
+@@ -312,7 +312,12 @@
  'ftp://exampel.com',
  '///example.com',
  '//example.com',
@@ -45,7 +45,7 @@
  
  nasty_url = '%(url)s?%(next)s=%(bad_url)s' % {
  'url': login_url,
-@@ -335,6 +340,7 @@ class LoginTest(AuthViewsTestCase):
+@@ -335,6 +340,7 @@
   'https://testserver/',
   'HTTPS://testserver/',
   '//testserver/',
diff -Nru python-django-1.4.5/debian/patches/CVE-2016-2512-regression.diff python-django-1.4.22/debian/patches/CVE-2016-2512-regression.diff
--- python-django-1.4.5/debian/patches/CVE-2016-2512-regression.diff	2016-03-26 00:39:46.0 +1100
+++ python-django-1.4.22/debian/patches/CVE-2016-2512-regression.diff	2016-08-01 08:00:52.0 +1000
@@ -10,7 +10,7 @@
 
 --- a/django/utils/http.py
 +++ b/django/utils/http.py
-@@ -8,7 +8,7 @@ import unicodedata
+@@ -8,7 +8,7 @@
  from email.utils import formatdate
  
  from django.utils.datastructures import MultiValueDict
@@ -19,7 +19,7 @@
  from django.utils.functional import allow_lazy
  
  ETAG_MATCH = re.compile(r'(?:W/)?"((?:\\.|[^"])*)"')
-@@ -237,6 +237,10 @@ def is_safe_url(url, host=None):
+@@ -237,6 +237,10 @@
  url = url.strip()
  if not url:
  return False
@@ -38,7 +38,7 @@
  import sys
  
  from django.utils import http
-@@ -111,3 +113,12 @@ class TestUtilsHttp(unittest.TestCase):
+@@ -111,3 +113,12 @@
   '//testserver/',
   '/url%20with%20spaces/'):
  self.assertTrue(http.is_safe_url(good_url, host='testserver'), "%s should be allowed" % good_url)
diff -Nru python-django-1.4.5/debian/patches/series python-django-1.4.22/debian/patches/series
--- python-django-1.4.5/debian/patches/series	2016-03-26 00:39:46.0 +1100
+++ python-django-1.4.22/debian/patches/series	2016-08-01 19:39:36.0 +1000
@@ -1,32 +1,8 @@
 02_disable-sources-in-sphinxdoc.diff
 03_manpage.diff
 06_use_debian_geoip_database_as_default.diff
-is_safe_url-1.4.diff
 uri-fix.diff
-ssi-tag-1.4.diff
-password-dos.diff
-password-2.5-compat.diff
-reverse-execution-1.4.x.patch
-cache-csrf-1.4.x.patch
-mysql-typecast-1.4.x.diff
-2601.patch
-is_safe_url_1_4.diff
-drop_fix_ie_for_vary_1_4.diff
-FTBFS-exception-in-servers-tests-tear-down.patch
-admin-data-leak-1.4.diff
-file-upload-1.4.diff
-remote-user-1.4.diff
-reverse-1.4.diff
-CVE-2015-0219.diff
-CVE-2015-0219-fix.diff
-CVE-2015-0220.diff
-CVE-2015-0221.diff
-CVE-2015-0221-regression-fix.diff
-CVE-2015-2317.diff
-session-1.4.x.diff
-newlines-1.4.x.diff
-session-store-1.4.x.diff
 date-leak-1.4.x.diff
 CVE-2016-2512.diff
 CVE-2016-2512-regression.diff
-CVE-2016-2513.diff
+# CVE-2016-2513.diff
diff -Nru python-django-1.4.5/debian/patches/uri-fix.diff python-django-1.4.22/debian/patches/uri-fix.diff
--- python-django-1.4.5/debian/patches/uri-fix.diff	2016-03-26 00:39:46.0 +1100
+++ python-django-1.4.22/debian/patches/uri-fix.diff	2016-08-01 08:00:47.0 +1000
@@ -4,9 +4,9 @@
 Subject: Use name that won't resolve in tests.
 --- 

[SECURITY] [REGRESSION] [DLA -] graphite2 regression update

[Balint Reczey]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Package: graphite2
Version: 1.3.6-1~deb7u2

The previous upload of graphite2 (on 2016-04-26) included a .shlib
file which did not match the shipped shared libraries preventing
packages build-depending on graphite2 libraries to build.

For Debian 7 "Wheezy", these problems have been fixed in version
1.3.6-1~deb7u2.

We recommend that you upgrade your graphite2 packages.

Further information about Debian LTS security advisories, how to apply
these updates to your system and frequently asked questions can be
found at: https://wiki.debian.org/LTS
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJXnx8DAAoJEPZk0la0aRp97uoP/jzwIsRlkymI4zVLe2jWprtS
FYG2k41hg6YHXLoVSj4UK3B5iLf6nXY0G2JgrBmSBYfgOaW+slQflt7p7GkPGctF
MheNJRSJ/5IqfOGVtdxNXW7TqlnzgVssDCg6tglTubxxRURRdcl577onnuMoIiUy
pyDrkIyeiGa2xRZtKsB9Qv1DyDP2MhmUMKr41X4IFMzKGdJto4e4PjV0lq8PSHRK
UIiWulIlg6EliIWjwziIg4ISq+RwtK1GFX7lILU/yrRSe+QInzTmXcgXZ4GXMkxn
ckCWa2wUtw1RIZdfOEKOR/IM2ZrwSIhS/dzSKkI5kkjlb4tcZ7fxc7iBWJNWf1Bn
ntorfrtbi+h2X02dYRi9aZ2lPvo9Or/wMh6PEMJVJb+oXROGbo8Fv1c9nPk7s+V7
dfInY7Hfr7iZqi1I2gsFExYJo29l3zF5Jqcmldch3REhS2dNT5wUKZh9ZP2PSrQo
RNZMaRvE9US4iIWeNoy7vSCchIYoWC3IBtJG7oDO3Os332t4P0Vgudy3iTIV4+qR
vefjLXuJG+J6NuMInO/LBblhEAEt9NqGP/yry+0c7rOC8Oac0JGe47bMqgOrODF1
P8SRRhPcTiDoiO6qge0uUL+kmTHrmA33Vyogu2438XIZUV/VxFOd4EqGoRuv2XtB
LKyPgS3gCksYIobuHoG5
=CmfM
-END PGP SIGNATURE-

Re: Wheezy update of python-django?

[Brian May]

Lucas Kanashiro  writes:

> My bad, I checked out the repo and I saw that the mentioned branch is
> debian/wheezy :)

Not sure if this means you were looking at this or not...

Also note that the debian/wheezy branch in git is not up-to-date.

In any case I am looking at doing this now, will start off without
git. If there is any demand I can move things across (including prior
revisions) to git later.
-- 
Brian May 

Re: Redis not uploaded and timely security announcements

[Bálint Réczey]

Hi Markus,

2016-08-01 10:35 GMT+02:00 Markus Koschany :
> Hi all,
>
> DLA-577-1 has been issued two days ago but redis hasn't been uploaded
> yet. Chris could you investigate please?
>
> I also noticed that sometimes the delay between the upload and actual
> security announcement takes too long. For arch:all packages the update
> is available on the mirrors within minutes after you receive the e-mail
> on debian-lts-changes. The vast majority of arch:any packages won't need
> 24h for building.
>
> Balint I noticed this because of your upload of cakephp and kdelibs4 and
> there hasn't been a DLA for graphite2 yet. I suggest to send the
> announcement after you receive the -changes e-mail and as soon as the
> packages are marked as installed. Remember it's a security mirror, so
> you don't need to wait for the upload to propagate to all mirrors.

Thank you for the reminder. I did delay the DLA-s because of possible
mirror propagations but it is not needed indeed.

Cheers,
Balint