Re: Please remove non-lts architectures from wheezy-security

[Paul Wise]

On Wed, May 4, 2016 at 12:23 AM, Tom Turelinckx wrote:

> Jessie is not available for sparc.

If you are actually using sparc I would recommend you look at
migrating to and assisting the sparc64 porting efforts. Or reviving
sparc if you need 32-bit SPARC. Or switch to another architecture.

https://wiki.debian.org/Sparc64
https://lists.debian.org/debian-sparc/

> There is no wheezy directory in http://archive.debian.org/debian/dists/, nor 
> in http://archive.debian.org/debian-security/dists/.
...
> Have these packages been archived somewhere? What is the recommended 
> sources.list entry to access them?

Until the non-LTS wheezy architectures are properly archived, you can
use the Debian wayback machine with a date before the LTS started.

http://snapshot.debian.org/

Also keep in mind that you are going to have to recompile every LTS
update from source for sparc or not get security updates.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Accepted biogenesis 0.8-1+deb7u1 (source all) into oldstable

[dak]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Wed, 04 May 2016 00:19:39 +0200
Source: biogenesis
Binary: biogenesis
Architecture: source all
Version: 0.8-1+deb7u1
Distribution: wheezy-security
Urgency: high
Maintainer: Miriam Ruiz 
Changed-By: Markus Koschany 
Description: 
 biogenesis - artificial life program that simulates evolution of organisms
Changes: 
 biogenesis (0.8-1+deb7u1) wheezy-security; urgency=high
 .
   * Non-maintainer upload by the LTS team.
   * Add default-jdk as an alternive build-dependency.
 Depend on default-jre | java6-runtime.
Checksums-Sha1: 
 0eed9758fad4d718d034bc73853967d93097c436 2013 biogenesis_0.8-1+deb7u1.dsc
 48de96b187188c2b49a5fc79e38812f1a4a03441 247735 biogenesis_0.8.orig.tar.bz2
 0f300dc9e420a899b49462be3b0e451bb0dae683 17780 
biogenesis_0.8-1+deb7u1.debian.tar.bz2
 bfb9556da09a41df9198dbbb00b05bfaf42ebd38 337316 biogenesis_0.8-1+deb7u1_all.deb
Checksums-Sha256: 
 5d07a376c48e182d25052fa48380df320cc34bb5bac59a04a426f545967a1b04 2013 
biogenesis_0.8-1+deb7u1.dsc
 d8211e332baa084a083f988416b344bee37f7dee2b7fae88974d01d50aa95561 247735 
biogenesis_0.8.orig.tar.bz2
 853c8235b595d1783ca6f9e9cea0e676b79aff71acba433a6cffdc5dbe9ad6c0 17780 
biogenesis_0.8-1+deb7u1.debian.tar.bz2
 015ce8bbdf81ea49b69acba9a4d580f25c6cab2a14e5cb58f00e67ebd086a8ea 337316 
biogenesis_0.8-1+deb7u1_all.deb
Files: 
 8394adbf46fcb65aae66b3961f57005c 2013 science optional 
biogenesis_0.8-1+deb7u1.dsc
 608aed8913e6fbaddb7e5c7438e41c5d 247735 science optional 
biogenesis_0.8.orig.tar.bz2
 96e198b795ad21a0c15d323079c2a9c2 17780 science optional 
biogenesis_0.8-1+deb7u1.debian.tar.bz2
 53477f19277de313da95f8e916afee9b 337316 science optional 
biogenesis_0.8-1+deb7u1_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQJ8BAEBCgBmBQJXKSX/XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBQ0YzRDA4OEVGMzJFREVGNkExQTgzNUZE
OUFEMTRCOTUxM0I1MUU0AAoJENmtFLlRO1HkBwwP/0rhq09J489H4NbJsi1sJfJQ
puKqiE75kKzQYITCNKxM0DPgcExEW0LnHF2yw+pP9TJUAQI6HCxWvJ0IqdZUnLUY
wZixc5yqcHNNp9jRmAF3DHgUg/zviddbLnWRbI9hCOnVEJZlpx70wKAVK+Lh/hCs
YKlA2yt//8hrkpa1jN7iH86eVt1N296VgBwUWU21Yz3HBswcaTkt+StMknrZlanP
h1wZo3O969fZKW24X3NyHPi6E93bPipggtJi/ALBSOMw9Kf4WKZV/h9YeMOpRDD6
vYJXMTKsXdywwri3ZVZeyBXGIm8Wd2BuYUFLg6ysYEtlNqs4NgnaWyRZDIfj3lGz
7RhaGIPaqXm1wSlVYMgy0bQpIHKBAPS0PSLJ83Lpla+WlNZwNcd3iM+m5YWjAUt8
uU8e0NhYLRNUYoc/LWp5FOLpBkB+/M+V2GL/znn3UNAcbP7gHG4sT4+6DLzkupaw
rUavSr4T4+f44x+hXV46g7j5OXnJCPhrBcnQ+uPdazxD56dNdnnW/MxXoAe+2Y5O
ek0yM9ig4+pqZTAtpBiYesJP8w+bV6hB0uzteFVBxEqBkC+NZMw514HqBB8O8099
JBdGywKLsdK05QbfLjHAvAZF8iTEGmw10iXqeIXIQ7erNeTdUWLigxYo8zLUGbrY
3BM62c380k6lXNk1RDLg
=4mmm
-END PGP SIGNATURE-

Accepted rjava 0.9-3-1+deb7u1 (source amd64) into oldstable

[dak]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Wed, 04 May 2016 00:29:13 +0200
Source: rjava
Binary: r-cran-rjava
Architecture: source amd64
Version: 0.9-3-1+deb7u1
Distribution: wheezy-security
Urgency: high
Maintainer: Dirk Eddelbuettel 
Changed-By: Markus Koschany 
Description: 
 r-cran-rjava - GNU R low-level interface to Java
Changes: 
 rjava (0.9-3-1+deb7u1) wheezy-security; urgency=high
 .
   * Non-maintainer upload by the LTS team.
   * Build-Depend on default-jdk and depend on default-jre | java6-runtime to
 ensure that the default OpenJDK 7 will be used in Wheezy-LTS.
Checksums-Sha1: 
 5e3ed253e7c2f472338b1b82313ffd51d0ae9542 1858 rjava_0.9-3-1+deb7u1.dsc
 2d7fadc61517f1f499f6ae254d2c3825340f03c8 537153 rjava_0.9-3.orig.tar.gz
 0cbb3db87f6b534293af19c5b1489c3939add4f8 2245 rjava_0.9-3-1+deb7u1.diff.gz
 7bc65d758feef6ff996187bd8c22f0a69e888a3f 577916 
r-cran-rjava_0.9-3-1+deb7u1_amd64.deb
Checksums-Sha256: 
 1c2b603cdeb4bb2c6778e8e31c842078c061621677ae14cd69157d1ce2097aef 1858 
rjava_0.9-3-1+deb7u1.dsc
 4ac7fdd849f502b84c02b66a3924b0cba9174a7d769ace17a49e4e4645dcd049 537153 
rjava_0.9-3.orig.tar.gz
 7917e79c35b0da13ef096ba2f6de6dbb8b8e9758738b32772cb7a2b3a53a6e69 2245 
rjava_0.9-3-1+deb7u1.diff.gz
 153f9a216802e5f9d0e06579ddc7f0a597a3b31f923795dc0aa6716fee6a 577916 
r-cran-rjava_0.9-3-1+deb7u1_amd64.deb
Files: 
 9e97ea0dc36cf2885283384f58805206 1858 gnu-r optional rjava_0.9-3-1+deb7u1.dsc
 b3376127006ea978253988f2d5dc8249 537153 gnu-r optional rjava_0.9-3.orig.tar.gz
 b3edf93793458fa8471372d92f0607d6 2245 gnu-r optional 
rjava_0.9-3-1+deb7u1.diff.gz
 d14c35bbbc90337e17e8be44a14fa729 577916 gnu-r optional 
r-cran-rjava_0.9-3-1+deb7u1_amd64.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQJ8BAEBCgBmBQJXKSdmXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBQ0YzRDA4OEVGMzJFREVGNkExQTgzNUZE
OUFEMTRCOTUxM0I1MUU0AAoJENmtFLlRO1HkH1gP/0SYR9r3k8OuI1+E6+BCEcQu
SyL4bD2ky9fEckNrmbFMfE0fSb7WCh7Ak10WTHE/wZKDo/6v92Qwh0tGxudvGQNh
X+ClvWLii82EN/uvxXrT8qJNslPw1Fx2H7rZaVAuwGueS/n7r2pSodiR2iqjrv+i
3Y9g7BG53NqcZ6p5JEjxGvdg3HCcKZ2p9JOf/Cj6QHE7t0E3D1NnzVAtUvAs/iIN
1bWiT7s22bUdhePpbz5jIYq6Knr+SiXy+c+5AUtXhWqZ3+I71SvMgTxBNQYxO5t1
y0AQ3FcQdlqnrqR1mGIxM9UdCuAT0tR6i/FWNc62Mli+wzzFItEOOENqEix0vQRn
C8HL6V8F3njyfDYvJX+prFgUpGJFz8sWpjhNGiwPs0zAsEekx0V/XBPp9bHu9sqU
5kkWoQAUmr7xX1S41fqOWYlLjf09iuRkargnoTXv3/uPnhs4AzdIwKP3IBjyXQdq
KqTRB0KdhfIeEdMNU13s9giyOZV88A/1kXpjheGuUQKiUqYcOAk3vYWbE0/uvUJA
VJc3SbVMjv2ZwEooMnvzo5vVSoHM1c/ypXewV+/fTBX97RxvH/a6jQSpf1QBub/8
fr7Z0lqvmslYrcdFNW37et5eJDFGBCQ+NA4y4Td1r2yeahixTbXxtcJyPj+jdNtr
Mj27RJLc+EcWcKV601e7
=xv/s
-END PGP SIGNATURE-

Accepted jedit 4.5.2+dfsg-1+deb7u1 (source all) into oldstable

[dak]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 03 May 2016 22:38:11 +0200
Source: jedit
Binary: jedit
Architecture: source all
Version: 4.5.2+dfsg-1+deb7u1
Distribution: wheezy-security
Urgency: high
Maintainer: Debian Java Maintainers 

Changed-By: Markus Koschany 
Description: 
 jedit  - Plugin-based editor for programmers
Changes: 
 jedit (4.5.2+dfsg-1+deb7u1) wheezy-security; urgency=high
 .
   * Non-maintainer upload by the LTS team.
   * Depend on default-jre | java6-runtime.
Checksums-Sha1: 
 8a5666e1ba4126e9dd9642dc43790b55dd7f23ae 2311 jedit_4.5.2+dfsg-1+deb7u1.dsc
 4482260c77c200717330122c672bcd60ac8b4164 1696580 jedit_4.5.2+dfsg.orig.tar.xz
 93b2fb601f7c73f7159e66e623b41c7514489504 21264 
jedit_4.5.2+dfsg-1+deb7u1.debian.tar.xz
 1623d21bbfe041d4b7b4fc556285531a4ac346bd 2029064 
jedit_4.5.2+dfsg-1+deb7u1_all.deb
Checksums-Sha256: 
 e548119499e0da77bde223ce26d4bb225b72811d31067aa1145fb871d75d419b 2311 
jedit_4.5.2+dfsg-1+deb7u1.dsc
 1b113bb7983f1b6378bd29803a4c63b65874889d4e46010883a9124320058b17 1696580 
jedit_4.5.2+dfsg.orig.tar.xz
 0a84a8ddc55457597eebe7e23e1a14efba856a665851d097205e1c72228bfcf0 21264 
jedit_4.5.2+dfsg-1+deb7u1.debian.tar.xz
 5c3aacc44ab88dc12b94f4733963b3d5cd5832e8159cb3a2a9ba677c1fae0b9e 2029064 
jedit_4.5.2+dfsg-1+deb7u1_all.deb
Files: 
 b4fc188e69ba31ee898646c5087608e9 2311 editors optional 
jedit_4.5.2+dfsg-1+deb7u1.dsc
 ad720d399e8595b1f64f8aee674833c2 1696580 editors optional 
jedit_4.5.2+dfsg.orig.tar.xz
 ed3449b4c1dee1d2c9b4de02cf286e04 21264 editors optional 
jedit_4.5.2+dfsg-1+deb7u1.debian.tar.xz
 cfba2fba0f1de0679b2d810c9dcbc519 2029064 editors optional 
jedit_4.5.2+dfsg-1+deb7u1_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQJ8BAEBCgBmBQJXKRx1XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBQ0YzRDA4OEVGMzJFREVGNkExQTgzNUZE
OUFEMTRCOTUxM0I1MUU0AAoJENmtFLlRO1HkU8IP/jEVqydJL9/6LAveSvdIih52
MPxgQ7ahvSkk7GaSfpOH1Q2GJ85JgdSZKw6lCvKxZ3ciBbeDKy+S7vEB1sbN3oZq
F9JzwqC0I/lpRcajPGLtlKCpNxVxo0gQNB1zYk7I4CrTI9MvCQ8rpCRVw8zm5pUf
t7ml29EDAUq/xAFuZj6gPYcZPttCpkmIX1I0WMg63lTKTnchCdGCfx0biJvD96Yx
Dy/Sem7r7Jy23NgfP5u4RW+A0Tgu90IF/rlAemSXm7tgMUZPASo/DVdSa7dD5vBM
0cDDtWeSFZLkcj4SsnMIjlpugejRruHw0hXI0EhV/8SnHXVL4DQjTsT9h52lq/a4
DOr1DePzvL2WUJgDPwXmXDL+5rSx18dRZk1Pb6KOKIB4P2Fjs4ToTlOXUJt4QHit
4cd1K00DZI/XqlcuYHUrBv5uKe3CtgW7UCRlyiNrBorC9xO293iWREdKeqs5eCzG
bkZMzuru7TpBfwXebCZZGXRk3201o/d8790O1WopUKauYt4kzO1o0tinSHRYHCDg
13cIhoXIRYXOEkyPEnqh2HRhAuwNKYNGrLH2We4dL3zmB2X5G1eBOgIsP1MxfuT7
9TxwdDAZ6bRTzUS1Adq11NKlea8IrkxQrC5b27elk86r9X0pAzPV24fW2t9me3oo
r8v6LQxmqF8ftRUwj51w
=ufP1
-END PGP SIGNATURE-

Re: [SECURITY] [DLA 456-1] openssl security update

[Yoshi Tsunoda]

thanks for u r email


On 05/04/2016 05:53 AM, Kurt Roeckx wrote:

Package: openssl
Version: 1.0.1e-2+deb7u21
CVE ID : CVE-2016-2105 CVE-2016-2106 CVE-2016-2107 CVE-2016-2108
  CVE-2016-2109 CVE-2016-2176

Several vulnerabilities were discovered in OpenSSL, a Secure Socket Layer
toolkit.

CVE-2016-2105

 Guido Vranken discovered that an overflow can occur in the function
 EVP_EncodeUpdate(), used for Base64 encoding, if an attacker can
 supply a large amount of data. This could lead to a heap corruption.

CVE-2016-2106

 Guido Vranken discovered that an overflow can occur in the function
 EVP_EncryptUpdate() if an attacker can supply a large amount of data.
 This could lead to a heap corruption.

CVE-2016-2107

 Juraj Somorovsky discovered a padding oracle in the AES CBC cipher
 implementation based on the AES-NI instruction set. This could allow
 an attacker to decrypt TLS traffic encrypted with one of the cipher
 suites based on AES CBC.

CVE-2016-2108

 David Benjamin from Google discovered that two separate bugs in the
 ASN.1 encoder, related to handling of negative zero integer values
 and large universal tags, could lead to an out-of-bounds write.

CVE-2016-2109

 Brian Carpenter discovered that when ASN.1 data is read from a BIO
 using functions such as d2i_CMS_bio(), a short invalid encoding can
 casuse allocation of large amounts of memory potentially consuming
 excessive resources or exhausting memory.

CVE-2016-2176

 Guido Vranken discovered that ASN.1 Strings that are over 1024 bytes
 can cause an overread in applications using the X509_NAME_oneline()
 function on EBCDIC systems. This could result in arbitrary stack data
 being returned in the buffer.

Additional information about these issues can be found in the OpenSSL
security advisory at https://www.openssl.org/news/secadv/20160503.txt

Accepted jftp 1.52+dfsg-2+deb7u1 (source all) into oldstable

[dak]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Fri, 22 Apr 2016 21:58:26 +0200
Source: jftp
Binary: jftp
Architecture: source all
Version: 1.52+dfsg-2+deb7u1
Distribution: wheezy-security
Urgency: high
Maintainer: Debian Java maintainers 

Changed-By: Markus Koschany 
Description: 
 jftp   - Java GUI client for FTP, SMB, SFTP and NFS
Changes: 
 jftp (1.52+dfsg-2+deb7u1) wheezy-security; urgency=high
 .
   * Non-maintainer upload by the LTS team.
   * Depend on default-jre | java6-runtime.
Checksums-Sha1: 
 4cc42e933791a2969a5f190b1af1f8ab790037cb 2301 jftp_1.52+dfsg-2+deb7u1.dsc
 ddb040b827a7d20f883f58d01c7d6c858f2426dc 251852 jftp_1.52+dfsg.orig.tar.gz
 05ae0fa4a5fcb82a6aea3b50239f699ca8492fbb 19971 
jftp_1.52+dfsg-2+deb7u1.debian.tar.gz
 b0a742129ef69a7d432aa88ada4da55bfc165fa8 468424 jftp_1.52+dfsg-2+deb7u1_all.deb
Checksums-Sha256: 
 4f0505cfadc07510b7f3a3fcc17069e2ce3f27d7e155c0d21f945ddb9a9f3f90 2301 
jftp_1.52+dfsg-2+deb7u1.dsc
 d5ce242b767d0dd36e94c6f23549d092ac070654f1d23effaddde7e09f9b6890 251852 
jftp_1.52+dfsg.orig.tar.gz
 f5242435be0f54a7a4308d139390698bbb04b8602354f13d0fb37d1656cf9fa6 19971 
jftp_1.52+dfsg-2+deb7u1.debian.tar.gz
 e16a45f97abab4927d1f713c4deb28329f44cfb952f1fdc4ed6bdac740cabc42 468424 
jftp_1.52+dfsg-2+deb7u1_all.deb
Files: 
 0427aa32079277854f1c835d9be675fe 2301 net optional jftp_1.52+dfsg-2+deb7u1.dsc
 5b9893c0da88640522a0eeacc1e898d2 251852 net optional jftp_1.52+dfsg.orig.tar.gz
 a8c05d31baffa1e2858679eb9afa477c 19971 net optional 
jftp_1.52+dfsg-2+deb7u1.debian.tar.gz
 33597dd6f5037fe95f5f2fa62f6252e8 468424 net optional 
jftp_1.52+dfsg-2+deb7u1_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQJ8BAEBCgBmBQJXKQwIXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBQ0YzRDA4OEVGMzJFREVGNkExQTgzNUZE
OUFEMTRCOTUxM0I1MUU0AAoJENmtFLlRO1HktqwQAKRNgt5fiCrC3OFLTbACdQ3L
/Fb0uiOah7uscl9YhbkLU1my/ZyISBGLjUppO0heCK+xoP2o0yBi8DSYIX6ne0S0
5sB33MuDolzWMZa/RX91NPdsSz6aHjlHi//xNLFqLDJggc1V8hkoEhsKRLwq3DPN
gndzws1d+wJBlffZO0raCN/TDZaAEGxZo8jagfGJbMde/H283emE0BJGEwBmxgKI
WWR42RI0dtr5Jsy0cewXj3tPaTzfhJUfsT16d+uFZs7P5pnjK4GYwnOhRsiO8ik4
cODw++8aRcWW4DbifIPfNgx613e8gkF2v8W/3tsu6MaKCHalHWuWsZWDe8PseaGY
afzPpYTWusmO575ycebiEgRmf2h/vGtHAs2ptw7XSjX/u2huYXxamfXR8V1ZnMvr
r2dq67+yT8jYEPRG6hhouOZjvYRsfyEbcLjChptIAvZMOWyHAXq4WnyzNMw+io0+
IMzorVj5TAp2XmzE9ERn1QFbaCuI3owj6fIcUFcE/pdy12GxOS/yPg2pRgC1Y/rZ
3awpnBAKK/wDVKYlkyfdntsai7Pm13W+DXmXKt6TopR+4H58mBSK4U3R2x8XvuWS
KAyXov2eYrojJd7g7jwXWW3OohRTiNeRSzoijqnewfrHsf9d0Xmj0vRwg89crbPY
5aj8SEjYhRaP3ZR1xw9l
=7YTo
-END PGP SIGNATURE-

[SECURITY] [DLA 456-1] openssl security update

[Kurt Roeckx]

Package: openssl
Version: 1.0.1e-2+deb7u21
CVE ID : CVE-2016-2105 CVE-2016-2106 CVE-2016-2107 CVE-2016-2108 
 CVE-2016-2109 CVE-2016-2176

Several vulnerabilities were discovered in OpenSSL, a Secure Socket Layer
toolkit.

CVE-2016-2105

Guido Vranken discovered that an overflow can occur in the function
EVP_EncodeUpdate(), used for Base64 encoding, if an attacker can
supply a large amount of data. This could lead to a heap corruption.

CVE-2016-2106

Guido Vranken discovered that an overflow can occur in the function
EVP_EncryptUpdate() if an attacker can supply a large amount of data.
This could lead to a heap corruption.

CVE-2016-2107

Juraj Somorovsky discovered a padding oracle in the AES CBC cipher
implementation based on the AES-NI instruction set. This could allow
an attacker to decrypt TLS traffic encrypted with one of the cipher
suites based on AES CBC.

CVE-2016-2108

David Benjamin from Google discovered that two separate bugs in the
ASN.1 encoder, related to handling of negative zero integer values
and large universal tags, could lead to an out-of-bounds write.

CVE-2016-2109

Brian Carpenter discovered that when ASN.1 data is read from a BIO
using functions such as d2i_CMS_bio(), a short invalid encoding can
casuse allocation of large amounts of memory potentially consuming
excessive resources or exhausting memory.

CVE-2016-2176

Guido Vranken discovered that ASN.1 Strings that are over 1024 bytes
can cause an overread in applications using the X509_NAME_oneline()
function on EBCDIC systems. This could result in arbitrary stack data
being returned in the buffer.

Additional information about these issues can be found in the OpenSSL
security advisory at https://www.openssl.org/news/secadv/20160503.txt



signature.asc
Description: PGP signature

[SECURITY] [DLA 455-1] asterisk security update

[Thorsten Alteholz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package: asterisk
Version: 1:1.8.13.1~dfsg1-3+deb7u4
CVE ID : CVE-2014-2286 CVE-2014-4046 CVE-2014-6610 CVE-2014-8412
 CVE-2014-8418 CVE-2015-3008
Debian Bug : 741313 762164 771463 782411


CVE-2014-6610
 Asterisk Open Source 11.x before 11.12.1 and 12.x before 12.5.1
 and Certified Asterisk 11.6 before 11.6-cert6, when using the
 res_fax_spandsp module, allows remote authenticated users to
 cause a denial of service (crash) via an out of call message,
 which is not properly handled in the ReceiveFax dialplan
 application.

CVE-2014-4046
 Asterisk Open Source 11.x before 11.10.1 and 12.x before 12.3.1
 and Certified Asterisk 11.6 before 11.6-cert3 allows remote
 authenticated Manager users to execute arbitrary shell commands
 via a MixMonitor action.

CVE-2014-2286
 main/http.c in Asterisk Open Source 1.8.x before 1.8.26.1, 11.8.x
 before 11.8.1, and 12.1.x before 12.1.1, and Certified Asterisk
 1.8.x before 1.8.15-cert5 and 11.6 before 11.6-cert2, allows remote
 attackers to cause a denial of service (stack consumption) and
 possibly execute arbitrary code via an HTTP request with a large
 number of Cookie headers.

CVE-2014-8412
 The (1) VoIP channel drivers, (2) DUNDi, and (3) Asterisk Manager
 Interface (AMI) in Asterisk Open Source 1.8.x before 1.8.32.1,
 11.x before 11.14.1, 12.x before 12.7.1, and 13.x before 13.0.1
 and Certified Asterisk 1.8.28 before 1.8.28-cert3 and 11.6 before
 11.6-cert8 allows remote attackers to bypass the ACL restrictions
 via a packet with a source IP that does not share the address family
 as the first ACL entry.

CVE-2014-8418
 The DB dialplan function in Asterisk Open Source 1.8.x before 1.8.32,
 11.x before 11.1.4.1, 12.x before 12.7.1, and 13.x before 13.0.1 and
 Certified Asterisk 1.8 before 1.8.28-cert8 and 11.6 before 11.6-cert8
 allows remote authenticated users to gain privileges via a call from
 an external protocol, as demonstrated by the AMI protocol.

CVE-2015-3008
 Asterisk Open Source 1.8 before 1.8.32.3, 11.x before 11.17.1, 12.x
 before 12.8.2, and 13.x before 13.3.2 and Certified Asterisk 1.8.28
 before 1.8.28-cert5, 11.6 before 11.6-cert11, and 13.1 before
 13.1-cert2, when registering a SIP TLS device, does not properly
 handle a null byte in a domain name in the subject's Common Name (CN)
 field of an X.509 certificate, which allows man-in-the-middle attackers
 to spoof arbitrary SSL servers via a crafted certificate issued by a
 legitimate Certification Authority.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQJ8BAEBCgBmBQJXKQqWXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2MjAxRkJGRkRCQkRFMDc4MjJFQUJCOTY5
NkZDQUMwRDM4N0I1ODQ3AAoJEJb8rA04e1hHW2sP/A9EmShDJ8KbsbM/h8Z2kzpC
RBoSnGmFE75C64WhD4gvEWO8sy158gFw4P79qvSgPbAxTjjFDx7o+UIIGBN8z41d
ub1cfRkaFyLhud0iZKDUFCx0VPOoYAZEzSVYZZKZaF43kaTJXcHAarhrkeKVVYoa
1kPXwvQP/yPrpys6EilcZ+LvoXm3gGz8i1+szmVEv2QBqFpnoVeJmmAp3jK6E7H4
0hHGlxsByvrj2k1Ms6SS5SDMisYr6PnZoJIAra3FAIoVayBlVrkTGGPK/Qi87W83
lCB91N5bxruK5/nWVD8qmJY+cUZJ+lbzu8hJk35ZZyqwWmME2qn+Erg/o8BRP83d
b+a1aYXPrH3VjKLT2LfRC7QXN3odGf7mRbV27wwM+ewT/ROz/lhCzlGSsB3W7z5h
KPvd63BcW2amZk2S53+0Lt7OCcmqrEKcoeYgd+7nYggJR0qFLIES+s5eZzxRkDrW
GjUx70uIuj3yuJYCb1FRKfspM2KJrFso7qYgswfZhDtC3+oX6pL7Dnt2pw75MfTF
fK//lC6qVF7KtpxyoCOCfkh+mOHVBsRFfEHNeEPCGfJXqjxh2W+pPzpIjmh4OY5B
oXa9rUg83/t5/aeAqciIaXk79Bbrn7PV6fRYJQ7HrODfz0nDTlejg+5GXXX6ctm1
sbt+0FBgqD3KlhSUO5Al
=u17W
-END PGP SIGNATURE-

[SECURITY] [DLA 454-1] minissdpd security update

[Thorsten Alteholz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package: minissdpd
Version: 1.1.20120121-1+deb7u1
CVE ID : CVE-2016-3178 CVE-2016-3179

The minissdpd daemon contains a improper validation of array index
vulnerability (CWE-129) when processing requests sent to the Unix
socket at /var/run/minissdpd.sock the Unix socket can be accessed
by an unprivileged user to send invalid request causes an
out-of-bounds memory access that crashes the minissdpd daemon.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQJ8BAEBCgBmBQJXKQoqXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2MjAxRkJGRkRCQkRFMDc4MjJFQUJCOTY5
NkZDQUMwRDM4N0I1ODQ3AAoJEJb8rA04e1hHSYwP/0AyUDVqdegSSM54+Hk6eTpb
BL8oY2ZbYX91EVmnquAJRncWAhFJBKN9KYjEQW+9VGPag1SmiasdzSWW6qMeCDOg
sV6ZuPz7DDxIvPz3ZEV6qou/5/Hd3CYhYD4td+/gvDOLQ9aXGwPaQrE/5rv7piU4
5Oio16sHLg/FWYT2OO1ITwb//IxU4yAkNrVg6OCxHRYMUXgUEevVp+XWseQfdjfb
lCC0CJr/x8u7yePdMlFi3hW+fs76JpOjQ1L1mdVYOeUlcNlKQzhSY5jaAPnHqrHQ
crjV44QQFJEUQ2cQlaHrsjWOI5zCOa58MT1zs45JBsV6YnF/Ilr+d0NzkLJSNvn7
enqY7aifRfoAep1VIQVMarC1AOMQJlvqd+AVElYJ2F4Pw+FZLSZPVPfT78svEZLs
HpKxmUTO5ofp4UHjah9NRc8vBwjp9mgGSwG7DzqfWeILFnv+o+LetREiOiEP9Gr1
RULRQRw+/wdX4l2lpwOAVVuyNFNSp4zKH+iigCoEg1N4wrqgsgDuHRK9G/4iR4gS
bDN6LU3NRdJXAEMtlPEST3/R8ihSNKXfwFe7dA0n13VLhOZdo+/LM6ZTDOs63tkO
/1UaNZohJ3P0rs6xw+GvnOymT6b0kq2qBRVMJpgiFYGgDaMaE0fBZUVgtInrWSe5
OwNqnTkYlHwbwWuO73IJ
=UhdE
-END PGP SIGNATURE-

RE: Please remove non-lts architectures from wheezy-security

[Tom Turelinckx]

Markus,

If I do that, apt-get update can't find any of the Packages files.

There is no wheezy nor wheezy-updates on archive.debian.org/debian...

Tom

-Original Message-
From: Markus Koschany [mailto:a...@debian.org] 
Sent: Tuesday, May 03, 2016 6:35 PM
To: Tom Turelinckx
Cc: debian-lts@lists.debian.org
Subject: Re: Please remove non-lts architectures from wheezy-security

Hello Tom,

Am 03.05.2016 um 18:23 schrieb Tom Turelinckx:
> Hello Markus,
> 
> Jessie is not available for sparc.

True. sparc64 is the only non-official release architecture that comes somewhat 
close.

> 
> My /etc/apt/sources.list looks like this:
> 
> deb http://ftp.be.debian.org/debian wheezy main contrib non-free 
> deb-src http://ftp.be.debian.org/debian wheezy main contrib non-free
> 
> deb http://ftp.be.debian.org/debian/ wheezy-updates main contrib 
> non-free deb-src http://ftp.be.debian.org/debian/ wheezy-updates main 
> contrib non-free
> 
> deb http://security.debian.org/ wheezy/updates main contrib non-free 
> deb-src http://security.debian.org/ wheezy/updates main contrib 
> non-free
> 
> This stopped working when the non-lts architectures were removed from 
> security.debian.org:

[...]
> Have these packages been archived somewhere? What is the recommended 
> sources.list entry to access them?

Try to replace ftp.be.debian.org with archive.debian.org. That should do the 
trick.

Regards,

Markus

Re: Wheezy update of roundcube?

[Markus Koschany]

Am 03.05.2016 um 18:37 schrieb Moritz Muehlenhoff:
> On Tue, May 03, 2016 at 06:28:03PM +0200, Markus Koschany wrote:
>> The second best solution would be to backport either the 1.0.x branch or
>> your jessie-backport packages to Wheezy. Since you actively maintain
>> them, what do you think, how complex is the task to backport the
>> packages from jessie-backports to Wheezy?
> 
> What's the point in updating a server package like roundcube in LTS
> to the version from LTS+1? I creates significant churn on the sysadmin's
> side, which is better spent on upgrading the entire VM/machine to LTS+1.
> 
> Clearly not all packages are suitable for five years maintenance, so it's
> better to not paper over the systems, but rather make this explicit.

You should also take into consideration that Roundcube is a web
application and depending on the package in question and options
available, a backport is a reasonable solution, for the same reasons we
have backported other packages before. Also the whole point of LTS is
that you don't have to upgrade the entire system, especially if you run
multiple different PHP applications on the same server. The order of
options is still valid.

Regards,

Markus




signature.asc
Description: OpenPGP digital signature

Re: Wheezy update of roundcube?

[Moritz Muehlenhoff]

On Tue, May 03, 2016 at 06:28:03PM +0200, Markus Koschany wrote:
> The second best solution would be to backport either the 1.0.x branch or
> your jessie-backport packages to Wheezy. Since you actively maintain
> them, what do you think, how complex is the task to backport the
> packages from jessie-backports to Wheezy?

What's the point in updating a server package like roundcube in LTS
to the version from LTS+1? I creates significant churn on the sysadmin's
side, which is better spent on upgrading the entire VM/machine to LTS+1.

Clearly not all packages are suitable for five years maintenance, so it's
better to not paper over the systems, but rather make this explicit.

Cheers,
Moritz

Re: Please remove non-lts architectures from wheezy-security

[Markus Koschany]

Hello Tom,

Am 03.05.2016 um 18:23 schrieb Tom Turelinckx:
> Hello Markus,
> 
> Jessie is not available for sparc.

True. sparc64 is the only non-official release architecture that comes
somewhat close.

> 
> My /etc/apt/sources.list looks like this:
> 
> deb http://ftp.be.debian.org/debian wheezy main contrib non-free
> deb-src http://ftp.be.debian.org/debian wheezy main contrib non-free
> 
> deb http://ftp.be.debian.org/debian/ wheezy-updates main contrib non-free
> deb-src http://ftp.be.debian.org/debian/ wheezy-updates main contrib non-free
> 
> deb http://security.debian.org/ wheezy/updates main contrib non-free
> deb-src http://security.debian.org/ wheezy/updates main contrib non-free
> 
> This stopped working when the non-lts architectures were removed from 
> security.debian.org:

[...]
> Have these packages been archived somewhere? What is the recommended 
> sources.list entry to access them?

Try to replace ftp.be.debian.org with archive.debian.org. That should do
the trick.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Re: Wheezy update of roundcube?

[Markus Koschany]

Am 03.05.2016 um 17:49 schrieb Guilhem Moulin:
> On Tue, 03 May 2016 at 10:47:31 -0400, Antoine Beaupré wrote:
>> I agree, however I suspect most people using roundcube in production are
>> probably using the backport... There's even a dangling backport in
>> wheezy right now (0.9)... a little messy.
> 
> Sorry, I meant oldstable-backports not oldstable.  Packaging 1.0.x for
> wheezy-backports sounds much easier than backporting security patches to
> wheezy's 0.7.x.

Hi,

the backports team regularly rejects packages that try to fix bugs or
even security vulnerabilities by providing the fixes with
{wheezy|jessie}-backports instead of fixing them via stable or security
updates directly.

I'm not sure yet how difficult it would be to backport the fixes to the
0.7.x branch and if all CVEs apply to Wheezy but that would be the
preferred solution which might also be less disruptive.

The second best solution would be to backport either the 1.0.x branch or
your jessie-backport packages to Wheezy. Since you actively maintain
them, what do you think, how complex is the task to backport the
packages from jessie-backports to Wheezy?

>> I filed a bug about the dangling backport in wheezy:
>>
>>  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813843
>>
>> I wonder how best to deal with this: should the backport just be removed
>> or what?
> 
> Agreed, I think 0.9 should be either removed from the archive or
> superseeded by 1.0.x.

+1

I'm all for removing it as soon as possible from backports. We don't
need to wait for updated packages.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Re: Wheezy update of roundcube?

[Guilhem Moulin]

On Tue, 03 May 2016 at 10:47:31 -0400, Antoine Beaupré wrote:
> I agree, however I suspect most people using roundcube in production are
> probably using the backport... There's even a dangling backport in
> wheezy right now (0.9)... a little messy.

Sorry, I meant oldstable-backports not oldstable.  Packaging 1.0.x for
wheezy-backports sounds much easier than backporting security patches to
wheezy's 0.7.x.
 
> I filed a bug about the dangling backport in wheezy:
> 
>  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813843
> 
> I wonder how best to deal with this: should the backport just be removed
> or what?

Agreed, I think 0.9 should be either removed from the archive or
superseeded by 1.0.x.

Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

[SECURITY] [DLA 452-1] smarty3 security update

[Markus Koschany]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package: smarty3
Version: 3.1.10-2+deb7u1
CVE ID : CVE-2014-8350
Debian Bug : 765920

Smarty3, a template engine for PHP, allowed remote attackers to bypass
the secure mode restrictions and execute arbitrary PHP code as
demonstrated by "{literal}<{/literal}script language=php>" in a
template.

For Debian 7 "Wheezy", these problems have been fixed in version
3.1.10-2+deb7u1.

We recommend that you upgrade your smarty3 packages.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQJ8BAEBCgBmBQJXKMXOXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBQ0YzRDA4OEVGMzJFREVGNkExQTgzNUZE
OUFEMTRCOTUxM0I1MUU0AAoJENmtFLlRO1Hk+A4P/3BV5ruW9JbFToy9ac1JLYKg
M1ULaFfX0wf5Vj3GVCKC0+p7HMvfFbvpcgZlTOKqGL1My+PBUZV9z4vNu5rQleIE
B63A98Ii8lSasOI6baGNFeCg1aniQt8SM6Qa3f3MrMlsHgv7ejrTNGVQvIJo7eYX
8KzJGrKA/EBBhzE+EDRRAtf98z/ziVSmvJEMdn5FyJkG7AW/N5Xhw+QvKncEv1PX
xiK6HOvgyJPkJv1RB1QylRAG00Aonmue44s0LTVGnlNB8unWZGeHXIpbFYM+dHop
KzGePhcok0kC2xXNgnpYUdBJNWYwDJ2vIMiTP1Lg6JIzRvB/upoTwYAmShF8OMO8
yrr9pIM+gTZEy4Rk9jPRRt5Ff6sKQ8MSydoy9AGUGXsUmgbRZr37evjJUj6htXfZ
5x15LX6scIS2vKYM8OjEvf0Y1nE6A24kQI1gzC+NH+qB+IDVYqeuP+yff8uKOw2r
XrIeL0r1BpLC0L3wzz3cdx6ymXZvaxxWjOsRAD+y8QqwyE3sRV4G/0ZOAZG16tEV
eP60TfIwMzHIfKT7TQaETi7cMp4TBw6FYrfnJm9898GDhgsvWBxZRH7zMMmcr0+7
8mT75eQ1Sqa2Gx2sJ5QjvbQkQAhcZUW5OZZwyXXY5mx/jl+kOvlesYjhSblrUhvS
KhTnjR91mp368wLsqID+
=X5CK
-END PGP SIGNATURE-

Re: xen debdiff

[Antoine Beaupré]

On 2016-05-03 04:07:08, Brian May wrote:
> Hello,
>
> Raphael Hertzog asked me to post the debdiff of the Ubuntu package I am
> working on here.
>
> He had some concerns with using the Ubuntu version like this. In
> particular Ubuntu does some things differently with respect to init.d
> scripts, has a different changelog, and there are some changes other
> changes here that may not be security related.
>
> He probably does have some valid points.
>
> As a result it might be better to continue my previous efforts of
> porting the security fixes to the version of Xen in Debian wheezy.
>
> On the other hand the version in Ubuntu is tried and tested and possibly
> less risk of me breaking something.
>
> Or I could just leave xen for now and let somebody more experienced with
> Xen take over.
>
> What do other people hear think?

I also agree with Raphael in principle. Having worked myself on this
package, I can see it was a really confusing and difficult experience,
so I understand where you're coming from as well.

I can give this another go tomorrow, by importing the new upstream into
the wheezy package and merge the Ubuntu patches in.

A.

-- 
feature, n: a documented bug | bug, n: an undocumented feature
- Mario S F Ferreira 

Re: testing asterisk for Wheezy LTS

[Antoine Beaupré]

On 2016-05-02 18:58:23, Gabriel Filion wrote:
> Oops, I forgot to mention that I am not subscribed to the mailing list.
> So please include me in CC for replies.
>
>> thanks alot for testing the package, I really appreciate it.
>>
>> On Thu, 28 Apr 2016, Gabriel Filion wrote:
>>
>>>
> https://people.debian.org/~alteholz/packages/wheezy-lts/asterisk/amd64/
>>>
>>>however I've found a regression: manager connections (in my case
>>>established from localhost) are super slow and/or not responding
> at all.
>>
>>
>> ok, I uploaded a new package (with the same version), so if you don't
>> mind can you please test it again?
>
> Thanks for the update.
>
> I've downloaded the new packages and tested them and they seem to be
> working great. SIP/IAX2 are working fine and the management port is
> responding correctly this time. I've also tested the voicemail app and
> it's responding OK.

Thanks so much for testing, I guess we can go on with the DLA now!

A.

-- 
Les plus beaux chants sont les chants de revendications
Le vers doit faire l'amour dans la tête des populations.
À l'école de la poésie, on n'apprend pas: on se bat!
- Léo Ferré, "Préface"

Re: Wheezy update of roundcube?

[Antoine Beaupré]

On 2016-05-02 15:31:39, Guilhem Moulin wrote:
> Hi there,
>
> On Mon, 02 May 2016 at 21:19:13 +0200, Markus Koschany wrote:
>> Would you like to take care of this yourself?
>
> Not replying in the name of team (however I'm the one who pushed for
> Roundcube in jessie-backports and who is trying to taking care of it
> there), unfortunately I don't have the time nor energy to take care of
> an oldstable version.
>
> That being said, I think packaging the Roundcube 1.0.x (stable) branch
> would be the easiest for Wheezy.
>
> https://github.com/roundcube/roundcubemail/releases/

I agree, however I suspect most people using roundcube in production are
probably using the backport... There's even a dangling backport in
wheezy right now (0.9)... a little messy.

I filed a bug about the dangling backport in wheezy:

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813843

I wonder how best to deal with this: should the backport just be removed
or what?

A.

-- 
You Are What You Is
- Frank Zappa

Re: Looking for programmers handling security updates for Debian 7 LTS

[Eric Van Buggenhaut]

Bonjour,

Je viens de voir mon annonce pour le job de security updates. Je suis en
fait développeur Debian 'retired', est-ce que cela vous convient pour le
poste?

Amitiés,

2016-05-02 11:41 GMT+02:00 Raphael Hertzog :

> Hello,
>
> the amount of sponsorship for Debian LTS[1] has increased over the last
> couple of months and a few paid contributors took a break, so we are
> still actively looking for Debian contributors wishing to be paid to
> provide security updates for Debian 7 Wheezy.
>
> Please see the announce I posted earlier this year:
> https://raphaelhertzog.com/2016/01/14/working-as-a-paid-lts-contributor/
>
> And also the details on Freexian's website:
> https://www.freexian.com/services/debian-lts-details.html#join
>
> Please get in touch with me if you are interested.
>
> Cheers,
>
> [1] https://wiki.debian.org/LTS
>
> PS: I post this with my "Freexian manager" hat. I want to ensure that we
> have enough contributors to pay to spend all the sponsorship that Freexian
> is collecting (and thus to do all the security work that needs to happen).
> --
> Raphaël Hertzog ◈ Freexian SARL ◈ Tel: +33 (0)6 88 21 35 47
> http://www.freexian.com
>



-- 
Eric

[SECURITY] [DLA 451-1] openjdk-7 security update

[Markus Koschany]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package: openjdk-7
Version: 7u101-2.6.6-2~deb7u1
CVE ID : CVE-2016-0636 CVE-2016-0686 CVE-2016-0687
 CVE-2016-0695 CVE-2016-3425 CVE-2016-3426 CVE-2016-3427

Several vulnerabilities have been discovered in OpenJDK, an
implementation of the Oracle Java platform, resulting in breakouts of
the Java sandbox, denial of service or information disclosure.

For Debian 7 "Wheezy", these problems have been fixed in version
7u101-2.6.6-2~deb7u1.

We recommend that you upgrade your openjdk-7 packages.

Please note that OpenJDK 7 will be made the new default Java
implementation on 26 June 2016. For further information please refer to

https://wiki.debian.org/LTS/Wheezy
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQJ8BAEBCgBmBQJXKH90XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBQ0YzRDA4OEVGMzJFREVGNkExQTgzNUZE
OUFEMTRCOTUxM0I1MUU0AAoJENmtFLlRO1HkW0QP/2ZDU/KHdGSBGMuQcObKyC4L
5bBBT/9qBIJbeHmcl0UUm4mTFdKyvnK2JVJzmmIV+2HLd3kULFQ0Quq0cyG47WTO
WiByd/ylGkNJNjY/IjG/5JR6TOR28BA0qrIvLVUgJpeKV2pxy/6KYcEGas9wtZvF
95d99Kro8CTrjsw05pe1HzhGfYfdmNXyFcrr8uVOT9Io8Okvpbb3bCWExRoALlAt
AtBRgjIHtyW5Z6GNuWA1IqyXyiDuhWrs0XIU7qSUBi3+Y7hbBostxdBb7aCVCbEK
whr0Yq9TulH1d95O0L1O1UlE9Lm81FHX/LRALwGdvpuMAknyMEAY86JlKa6ce83O
NeAEqlBxHNdNXhkwSwMicr1uLo20QRjfeCvEEBYGIIesZshiqfdNrG0dfpPDIASu
E8EZdEtW768UbbTdJpL+plvqT507pOcp7BAy+NAWn1Zd6hUGAMQPe0BtbXdyHuou
zwz5kGiJAtOFdiB4d020uVkymdu4xVyhKC0YzC30qo/5RqkaSSED4AjteXYkVFzC
JkWbYD5r1sZ4yx7DV/aNswxbYmxFasxZ3I9j/J7fs3mcjJYyOdaitxXQkOJgkuy4
U8cfq3XhwYKLodFiDksapD95o4m9Y/qD30Gl7LBZ35v3EaGnoIZxS3TH37E6wDmS
xFpqCAXzXipxJ0wJR3f4
=KzbX
-END PGP SIGNATURE-

Re: xen debdiff

[Holger Levsen]

On Tue, May 03, 2016 at 11:01:16AM +0200, Raphael Hertzog wrote:
> I don't think that any Xen experience makes a big difference here as
> the problem I pointed out are in the packaging and not in the upstream
> source code. I still believe that we should update to the latest 4.1.x
> release.

FWIW, I agree with Raphael here.


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Re: Supporting libav in wheezy

[Raphael Hertzog]

On Tue, 03 May 2016, Brian May wrote:
> I have a suspicion that many of these installs may be due libav being
> installed to satisfy dependancies. There are a large number of packages
> that do depend on libav.

Yes, that's obvious, a library is usually installed by way of
dependencies. But if you assume that people do not install packages
that they do not need, they are likely using libav even though indirectly
and they might be vulnerable to attacks. It's quite likely that the
impact might be less severe than if they were using the library to
processe remotely submitted data (and in which case one would hope that
they would have told us about it) but we have no way to know that really.

> Is it worth continuing with this?

I believe it is worth at least investigating what kind of external support
we can get and how much it will cost us, yes. Then we can decide whether
we can afford it and whether it is worth its price.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Re: xen debdiff

[Raphael Hertzog]

On Tue, 03 May 2016, Brian May wrote:
> He had some concerns with using the Ubuntu version like this. In
> particular Ubuntu does some things differently with respect to init.d
> scripts, has a different changelog, and there are some changes other
> changes here that may not be security related.

Just to be more specific, if you look up the Ubuntu changelog, you will
see that the Ubuntu version is based on Debian's 4.1.1-3 while the wheezy
package is at 4.1.4-3. So all the Debian packaging changes between those
two versions are actually reverted by the switch to the Ubuntu package.

So I believe that you should start from the Debian package, switch to the
new upstream version and possibly rely on the Ubuntu package to update
the set of patches to fix all security issues that do apply on this
new upstream version.

Here are some of the important changes that are reverted by your
debdiff:

-xen (4.1.3~rc1+hg-20120614.a9c0a89c08f2-3) unstable; urgency=low
-
-  * Remove /usr/lib/xen-default. It breaks systems if xenstored is not
-compatible.

-xen (4.1.2-7) unstable; urgency=low
-  
-  * Really use ucf.
-  * Update init script dependencies:
-- Start $syslog before xen.
-- Start drbd and iscsi before xendomains. (closes: #626356)
-- Start corosync and heartbeat after xendomains.
-  * Remove /var/log/xen on purge. (closes: #656216)

-xen (4.1.2-6) unstable; urgency=low
-
-  * Fix generation of architectures for hypervisor packages.
-  * Remove information about loop devices, it is incorrect. (closes: #503044)
-  * Update xendomains init script:
-- Create directory for domain images only root readable. (closes: #596048)
-- Add missing sanity checks for variables. (closes: #671750)
-- Remove not longer supported config options.
-- Don't fail if no config is available.
-- Remove extra output if domain was restored.

-xen (4.1.2-5) unstable; urgency=low
-
-  * Actually force init script rename. (closes: #669341)
-  * Rewrite xendomains init script:
-- Use LSB output functions.
-- Make output more clear.
-- Use xen toolstack wrapper.
-- Use a python script to properly read domain details.

-xen (4.1.2-4) unstable; urgency=low
-
-  [ Bastian Blank ]
-  * Build-depend on ipxe-qemu instead of ipxe. (closes: #665070)
-  * Don't longer use a4wide latex package.
-  * Use ucf for /etc/default/xen.
-  * Remove handling for old udev rules link and xenstored directory.
-  * Rename xend init script to xen.

-xen (4.1.2-3) unstable; urgency=low
-
-  * Merge xen-common source package.
-  * Remove xend wrapper, it should not be called by users.
-  * Support xl in init script.
-  * Restart xen daemons on upgrade.
-  * Restart and stop xenconsoled in init script.
-  * Load xen-gntdev module.
-  * Create /var/lib/xen. (closes: #658101)
-  * Cleanup udev rules. (closes: #657745)

> As a result it might be better to continue my previous efforts of
> porting the security fixes to the version of Xen in Debian wheezy.
> 
> On the other hand the version in Ubuntu is tried and tested and possibly
> less risk of me breaking something.
> 
> Or I could just leave xen for now and let somebody more experienced with
> Xen take over.

I don't think that any Xen experience makes a big difference here as
the problem I pointed out are in the packaging and not in the upstream
source code. I still believe that we should update to the latest 4.1.x
release.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Re: Sending LTS changes to debian-lts-changes

[Raphael Hertzog]

On Mon, 02 May 2016, Ansgar Burchardt wrote:
> > Send them first only to debian-lts-changes@ as it might be that the
> > tracker gets them that way too.
> 
> Now I already set both mail addresses. Should I change that to only
> debian-lts-changes@?
> Note that security.d.o doesn't sent mail to @packages.qa.d.o.

Let's see how it behaves first. After further thinking, I believe it
should be good.  The new tracker does not follow debian-lts-changes AFAIK,
only the old one does for the news feed displayed on the package page.

> > (That said dak needs a general cleanup to send mail to the new tracker
> > directly and stop relying on @packages.qa.debian.org, as nobody did
> > anything in response to
> > https://lists.debian.org/debian-devel-announce/2015/12/msg1.html)
> 
> Should I just add dispatch@tracker.d.o to all suites where we sent out
> announcement mails for?
> 
> And in that case stop sending mail to @packages.qa.d.o?
> 
> And it looks like we also sometimes send mail to
> @packages.d.o.  So many different choices :)

Yes, I would like to simplify all this... and to some extent, I already
put the required infrastructure in place for it.

The package tracker needs a single copy of the mail arriving to dispatch@
but that copy can come from:
- a mail to @packages.d.o
- a direct mail to dispatch@tracker.d.o
- a mail to @packages.qa.debian.org (kept working for now until
  all services migrated)

So basically the rules are: when you send a mail to @packages.d.o, you
don't need to send a copy to dispatch@tracker.d.o. For all other (public)
mails, you should send a copy to dispatch@tracker.d.o. And you should no
longer send anything to @packages.qa.d.o.

Ideally, we would always use @packages.d.o as the single contact point.
(Except that it does not work very well for new packages as the list of
alias on that service is static. So in the long term I would like the
tracker to handle that email service directly.)

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Re: Sending LTS changes to debian-lts-changes

[Moritz Muehlenhoff]

On Mon, May 02, 2016 at 08:57:40PM +0200, Ansgar Burchardt wrote:
> Raphael Hertzog writes:
> > On Mon, 02 May 2016, Markus Koschany wrote:
> >> thank you for fixing the mirror bug. Moritz Mühlenhoff informed us on
> >> IRC that accepted mails for LTS uploads are still sent to dak AT
> >> security.debian.org. Can you filter those mails so that they are sent to
> >> debian-lts-changes instead and if possible also to
> >> dispatch _AT_ tracker.debian.org as Raphael had suggested? [1]
> >
> > Send them first only to debian-lts-changes@ as it might be that the
> > tracker gets them that way too.
> 
> Now I already set both mail addresses. Should I change that to only
> debian-lts-changes@?
> 
> Note that security.d.o doesn't sent mail to @packages.qa.d.o.

For wheezy-lts we don't need the changes mails send to d...@security.debian.org,
anyone in the security team interested in those can simply subscribe to
debian-lts-changes

Cheers,
Moritz