NEW changes in stable-new
Processing changes file: apache2_2.2.22-13+deb7u2_mips.changes ACCEPT Processing changes file: kfreebsd-9_9.0-10+deb70.7_mips.changes ACCEPT -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1wwpl4-0001cm...@franck.debian.org
Bug#748535: transition: gnutls28
On 15/06/14 19:20, Andreas Metzler wrote: On 2014-06-15 Andreas Metzler ametz...@bebt.de wrote: On 2014-06-10 Emilio Pozuelo Monfort po...@debian.org wrote: On 06/06/14 20:30, Emilio Pozuelo Monfort wrote: [...] Looks like libgadu and wireshark are the only remaining problems. Good morning, Which would both be solved now. However afaict the dependency circle has grown, since the libetpan transition #747534 was started. Oi. Actually I was wrong, it simply propagated, since libetpan/testing is using libgnutls26. :-) Yep, it is done now. Do you want a tracker for the gnutls26 - gnutls28 transition as per your initial email? Regards, Emilio -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/539e9283.1000...@debian.org
Bug#751750: pu: package ldns/1.6.13-1+deb7u1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: pu -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi release team, I have prepared security, but non-dsa, update to ldns that creates private DNSSEC keys with default umask (CVE-2014-3209). The patch is very simple and it has been prepared by upstream. $ diffstat ldns_1.6.13-1+deb7u1.debdiff changelog |7 + gbp.conf |2 patches/003_dont_require_libldns_la_for_pyldns.patch |6 - patches/fix-permissions-when-creating-new-dnskey.patch | 76 + patches/series |1 5 files changed, 88 insertions(+), 4 deletions(-) The d/patches/003* update is just 'quilt refresh'. $ cat ldns_1.6.13-1+deb7u1_amd64.changes [...] ldns (1.6.13-1+deb7u1) stable-security; urgency=medium . * [CVE-2014-3209]: fix ldns-keygen writing private DNSKEYs with default umask (Closes: #746758) [...] It's not a critical issue (hence non-DSA), but it would be nice to have this fixed in stable. Thanks, Ondrej - -- System Information: Debian Release: 7.5 APT prefers stable APT policy: (900, 'stable'), (800, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJTnrzEAAoJEAyZtw70/LsHHOEP/0zuu4TRRoR1u7ZlBGN93KRt jk5ccf0PeybhGykP67/P3QxvDP+CYJBCCP1N2mJxQIcYdRzmxmy5UxUo5J2fs4hk wuJXAZSWvFi8fB93Wg8049+rli6Ve1XRVSIhVfb/aBs+RdGmZygHooEzIeD5uSWP 006QoEd1Tasx4a0bzikIDkzCyxCHkpiYxmM9Us8XF2wzweHXN6WV5A6C8ogF+Zsh fTKhKzDf/4wocisQ+jP75uJXGApb/D9dsQEzv8aRf3yRGEvB8vih+Qswuvvi6LLR 1U7i3FDl+PoBGt7r8M124Tbw19dIudbSfloyuWBwXVv1Slk8DwzmqiHnmwEZKcAv u9RBMQu79kJkhwUUpJ0YPpkNQFk6Uz4a/GY0b/eXHkD0PEJUmIMe8gDiN5VIzxMG BBn4fvy05J2q8y1Aakwts6h0G1Fg5oDGqd2bUbZTPjrU2GGa9/NNFhHLObd8ihC+ Jew+BznWom4Lv8LGn8Ck7lgdLv9VJeq6UUdq2vvTnDrvvV36+T7Csq9v2jn3mU2h I6QngY0x/ZI1tBv+Wh1x7izRS9NgYnekGUIBkMIZgm4Mz32nV6P8jVdgl3q3Am1/ /R5ETKRBPGD6pNy3B/zCQ9VcpSSUhfNC1ouGebfKkqOiPHbJrD2K0QcLO6uEQchI Sz3nCYlPsyiQBfH9l4Ur =L4LE -END PGP SIGNATURE- -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Fri, 13 Jun 2014 11:06:52 +0200 Source: ldns Binary: libldns1 libldns1-dbg libldns-dev ldnsutils python-ldns Architecture: source amd64 Version: 1.6.13-1+deb7u1 Distribution: stable-security Urgency: medium Maintainer: Ondřej Surý ond...@debian.org Changed-By: Ondřej Surý ond...@debian.org Description: ldnsutils - ldns library for DNS programming libldns-dev - ldns library for DNS programming libldns1 - ldns library for DNS programming libldns1-dbg - ldns library for DNS programming (debug symbols) python-ldns - Python bindings for the ldns library for DNS programming Closes: 746758 Changes: ldns (1.6.13-1+deb7u1) stable-security; urgency=medium . * [CVE-2014-3209]: fix ldns-keygen writing private DNSKEYs with default umask (Closes: #746758) Checksums-Sha1: 0cd068beec757941ae438c3d76b6c831ec766688 2156 ldns_1.6.13-1+deb7u1.dsc c44d5da534124964ef6d55b40b3ce1a2805b4ccd 13732 ldns_1.6.13-1+deb7u1.debian.tar.gz eb2b8ed91d993c91bf7a9c8f8670c997c0a0d7a0 167120 libldns1_1.6.13-1+deb7u1_amd64.deb c3b0d6a660d71d5ba3eb79cc27f333c5f456c9e0 349548 libldns1-dbg_1.6.13-1+deb7u1_amd64.deb 125b4269da30779f87e02d87afdf00bb62da4400 599848 libldns-dev_1.6.13-1+deb7u1_amd64.deb c3fa167226fa501dc120383c29084dbe9cdd5d9c 173250 ldnsutils_1.6.13-1+deb7u1_amd64.deb 39538bc2c88bd003a1cf417c02dd3290170d971d 425520 python-ldns_1.6.13-1+deb7u1_amd64.deb Checksums-Sha256: da11b2ca8116db749036dc122bf233f4c40120645e7b08eda8098eaf159eba96 2156 ldns_1.6.13-1+deb7u1.dsc 1ee0314ec9053aa12d235c47a9e02a6f6d28176970cf7f014096b3793a641941 13732 ldns_1.6.13-1+deb7u1.debian.tar.gz 2ad7be1d289477ce5eca042865769ae1e844b64f4502ecdca62d635f6f3edcad 167120 libldns1_1.6.13-1+deb7u1_amd64.deb 1da2fd310567b4b0c62ddb2e57a74db3349f62446ef9c0f0569d38932a025243 349548 libldns1-dbg_1.6.13-1+deb7u1_amd64.deb 5e3a3d791818778425e2e7b54d8f159e9ac4fd1c31a2a9ec321735e1312300ee 599848 libldns-dev_1.6.13-1+deb7u1_amd64.deb 3cc3e63dec881f494ac53abe55200ebb39f12fa678d428de959ee751089c8d2e 173250 ldnsutils_1.6.13-1+deb7u1_amd64.deb f00adda1ccdd0998bcd7c0ef4f5fe4cfae272de6413ff809f9a988e8db0b5d2e 425520 python-ldns_1.6.13-1+deb7u1_amd64.deb Files: de6b6c825529fc8164752dbbb0d53895 2156 net extra ldns_1.6.13-1+deb7u1.dsc 5b514cbfb13b79667f363a9def119504 13732 net extra ldns_1.6.13-1+deb7u1.debian.tar.gz 5c0289e15d8e326d17ef6af533ba0f30 167120 libs extra libldns1_1.6.13-1+deb7u1_amd64.deb a8a39ef222e676de21e6be49b3eea2f4 349548 debug extra libldns1-dbg_1.6.13-1+deb7u1_amd64.deb 07d3b14f84c492a3a88a537c68e714fc 599848 libdevel extra libldns-dev_1.6.13-1+deb7u1_amd64.deb
NEW changes in stable-new
Processing changes file: tzdata_2014e-0wheezy1_amd64.changes ACCEPT -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1wwurn-0003gb...@franck.debian.org
Bug#751780: transition: libstdc++6 unordered_{map,set} ABI changes between GCC 4.8/4.9 in c++11 mode
Package: release.debian.org
Severity: important
Tags: sid jessie
This change mentioned in the GCC 4.9 news:
Improved support for C++11, including:
The associative containers in map and set and the
unordered associative containers in unordered_map and
unordered_set meet the allocator-aware container
requirements
is an ABI incompatible change in the unordered_{map,set} classes built in c++11
mode. The libstdc++6 library itself is not affected, so instead of having a
libstdc++6 transition, all packages providing a library built in c++11 mode and
using the unordered_{map,set} classes should be transitioned (changing the name
of the library package).
A grep of all sources for #include *unordered_{map,set}, and then searching in
the log files for usage of -std=c++{0x,11} did show the following packages
building library packages (for packages not having verbose build logs I had to
look into the source package):
bobcat 3.22.00-1
c++-annotations 9.9.1-2
capnproto 0.4.0-1
condor 8.0.6~dfsg.1-1
liblo 0.28-3
mrpt 1:1.0.2-1
qtbase-opensource-src-gles 5.2.1+dfsg-1
rapicorn 13.07.0~ds0-1
shogun 3.2.0-2
tesseract 3.03.03-1
zeroc-ice 3.5.1-6
For those transitions should be considered.
Other packages found are listed here, although I assume they can be left
unchanged, or maybe just binNMUed:
aria2 1.18.5-1
bisonc++ 4.09.01-1
cbmc 4.5-2
clementine 1.2.0+dfsg-2
fakeroot-ng 0.18-4
fastx-toolkit 0.0.14-1
chromium-browser -
filezilla 3.8.0-1
flexc++ 2.01.00-1
grap 1.44-1
imagevis3d 3.1.0-2
jmtpfs 0.5-2
kcov 11.1
kdevelop-pg-qt 1.0.0-3
mira 4.0.2-1
mkvtoolnix 7.0.0-1
natlog 1.01.0-2
octave-image 2.2.1-1
pingus 0.7.6-1.1
python-casmoothing 0.1-2
qtcreator 3.0.1-0
ruby-passenger 4.0.37-3
spring 96.0+dfsg-2
sysdig 0.1.83-1
tcpflow 1.4.4+repack1-2
yrmcds 1.0.4-2
Proposing to make GCC 4.9 the default on the remaining non-release
architectures, then bumping the required g++ dependency in build-essential, then
file bug reports for the eleven packages mentioned in the first set, and then
transitioning these packages.
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/539f070f.1020...@debian.org
Bug#733564: pu: apache2 with ECDHE support
On Mon, June 16, 2014 00:06, Adam D. Barratt wrote: Control: tags -1 + pending On Sun, 2014-05-25 at 17:55 +0200, Stefan Fritsch wrote: I have just uploaded apache2_2.2.22-13+deb7u2: Flagged for acceptance; sorry for the delay. apache2 (2.2.22-13+deb7u2) wheezy; urgency=medium * Backport support for SSL ECC keys and ECDH ciphers. For anyone following the bug log, testing of the above change before the point release would be much appreciated. Running this version successfully on two machines, but maybe more interesting: we've been running a build of the same upstream patch on top of deb7u1 on about a hundred machines since a few months. Thijs -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/04210b4bf6a0beedc8048d7b781f3dc4.squir...@aphrodite.kinkhorst.nl
Bug#748535: transition: gnutls28
On 2014-06-16 Emilio Pozuelo Monfort po...@debian.org wrote: On 15/06/14 19:20, Andreas Metzler wrote: [...] Actually I was wrong, it simply propagated, since libetpan/testing is using libgnutls26. :-) Yep, it is done now. Do you want a tracker for the gnutls26 - gnutls28 transition as per your initial email? I would appreciate that, thank you. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140616170751.gb1...@downhill.g.la
Updating tor (was: Upcoming stable point release (7.6))
Hi! On Wed, 11 Jun 2014, Adam D. Barratt wrote: The next point release for wheezy (7.6) is scheduled for Saturday, July 12th. Stable NEW will be frozen during the preceding weekend. I propose to update Tor in stable to the version that is now in jessie. This would be a jump to the next major version of tor, not just a patch release update. The Tor version in stable is 0.2.3.25, the latest version of the old 0.2.3.x tree of Tor releases. The current stable Tor tree is 0.2.4.x, released as stable in December, with the current update being .22 from May. There's, of course, a whole bunch of reasons why 0.2.4.x is oh-so-much better than 0.2.3.x. One key-point is that about a quarter of the Tor network (just considering the relays, not any clients), is on 0.2.3.25, presumably because they run Debian stable. If they all upgraded to the 0.2.4.x tree, the network as a whole would become a lot more secure as 0.2.4.x allows clients to use stronger crypto for connections built through these nodes. Also, Tor upstream is not entirely sure what they would want to backport to 0.2.3.x in order to call it as DoS-resistant as 0.2.4.x. That is to say, they are not aware of any arbitrary-code-execution bugs that affect 0.2.3.x, but nobody knows which of the DoS/resource-leak bugs that were fixed in the new tree could or should be backported: | And indeed, we're basically done backporting fixes to 0.2.3. For | anything short of a remote overflow, we're probably not fixing | it. Obviously, since this is a major upstream version jump, reviewing the diff is not feasible. Even going over the upstream changelog took a good long while. That resulted in a number of things we'd really like to have.Changes include things like rejecting authority signing keys that might have been exposed due to heartbleed, TLS ciphersuits now being chosen by relays rather than clients (client lists have been chosen mainly for anti-fingerprinting purposes), always clearing bignums before freeing them, TLS 1.1 and 1.2 support, turning off client-side DNS cache by default (that fixes a huge linkability issue for clients), and much more. I can clean-up and provide a full(er) list on request. I don't expect the hand-full of reverse dependencies would have any problems with the version jump, and from a relay-operator or end-user point of view not much directly visible has changed. The default contents of the /etc/tor/torrc conffile have changed slightly. (In fact, the diff is so tiny - one date change and one typo fix in comments - that we could consider reverting that change to cut down on dpkg propmts if you prefer.) Existing configuration files are expected to continue to work in all cases. Is this update something we can do? Thanks for your consideration, weasel -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `-http://www.debian.org/ -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140616185313.ga17...@anguilla.noreply.org
Bug#746233: transition: libxmhtml1.1
On 07-06-14 11:32, Paul Gevers wrote: On 24-05-14 18:04, Emilio Pozuelo Monfort wrote: Please upload to experimental so that it can go through NEW. The upload has happened and the package was excepted. Please let us know when we can proceed with uploading xmhtml and grace. Paul signature.asc Description: OpenPGP digital signature
Re: Updating tor
Hi, Peter Palfrader wrote (16 Jun 2014 18:53:13 GMT) : I propose to update Tor in stable to the version that is now in jessie. We've been shipping Tor 0.2.4.x in Tails since last September, back when it was still a release candidate. This means that this branch of Tor has been started 6-11k times a day in this environment (i386, Squeeze-based) for 9 months. No problem so far. This experience, added to the reasons mentioned by weasel, and to the fact that I've not seen regressions caused by Tor 0.2.4.x in the few reverse-deps I'm maintaining in Debian, makes me positive that it's the way to go for Wheezy. Cheers, -- intrigeri -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/85mwdcpqr6@boum.org
Re: [SUA 59-1] Updated duo-unix version
On Mon, Jun 16, 2014 at 20:59:06 +0100, Adam D. Barratt wrote: --- Debian Stable Updates Announcement SUA 59-1 http://www.debian.org debian-release@lists.debian.org Kees Cook June 16th, 2014 --- Package : duo-unix Version : 1.8.1-1~deb7u1 Importance : high There doesn't appear to be a package called duo-unix in all of Debian[0]. Is this the correct package name? [0]: https://packages.debian.org/search?keywords=duo-unixsearchon=namessuite=allsection=all -- Chris Nehren pgpniSZlIHAbu.pgp Description: PGP signature
Re: [SUA 59-1] Updated duo-unix version
On Mon, 2014-06-16 at 16:53 -0400, Chris Nehren wrote: On Mon, Jun 16, 2014 at 20:59:06 +0100, Adam D. Barratt wrote: --- Debian Stable Updates Announcement SUA 59-1 http://www.debian.org debian-release@lists.debian.org Kees Cook June 16th, 2014 --- Package : duo-unix Version : 1.8.1-1~deb7u1 Importance : high There doesn't appear to be a package called duo-unix in all of Debian[0]. Is this the correct package name? [0]: https://packages.debian.org/search?keywords=duo-unixsearchon=namessuite=allsection=all It's the source package name; see https://packages.debian.org/search?suite=allsection=allarch=anysearchon=sourcenameskeywords=duo-unix Regards, Adam -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1402952405.31219.46.ca...@jacala.jungle.funky-badger.org
Re: Updating tor (was: Upcoming stable point release (7.6))
Peter Palfrader wea...@debian.org schrieb: Hi! On Wed, 11 Jun 2014, Adam D. Barratt wrote: The next point release for wheezy (7.6) is scheduled for Saturday, July 12th. Stable NEW will be frozen during the preceding weekend. I propose to update Tor in stable to the version that is now in jessie. One additional note: We already moved to a new upstream release in a previous DSA (DSA-2363-1, from 0.2.1.31-1 to 0.2.2.35-1) and it worked out well. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/slrnlpuoab.2kg@inutil.org
Bug#746233: transition: libxmhtml1.1
Control: tags -1 confirmed On 16/06/14 21:09, Paul Gevers wrote: On 07-06-14 11:32, Paul Gevers wrote: On 24-05-14 18:04, Emilio Pozuelo Monfort wrote: Please upload to experimental so that it can go through NEW. The upload has happened and the package was excepted. Please let us know when we can proceed with uploading xmhtml and grace. Please go ahead. Regards, Emilio -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/539f6d14.1030...@debian.org
Processed: Re: Bug#746233: transition: libxmhtml1.1
Processing control commands: tags -1 confirmed Bug #746233 [release.debian.org] transition: libxmhtml1.1 Added tag(s) confirmed. -- 746233: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746233 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/handler.s.b746233.140295708724362.transcr...@bugs.debian.org
Bug#748535: transition: gnutls28
Control: forwarded -1 https://release.debian.org/transitions/html/gnutls28.html On 16/06/14 19:07, Andreas Metzler wrote: On 2014-06-16 Emilio Pozuelo Monfort po...@debian.org wrote: On 15/06/14 19:20, Andreas Metzler wrote: [...] Actually I was wrong, it simply propagated, since libetpan/testing is using libgnutls26. :-) Yep, it is done now. Do you want a tracker for the gnutls26 - gnutls28 transition as per your initial email? I would appreciate that, thank you. https://release.debian.org/transitions/html/gnutls28.html BTW there are currently some issues with the gcrypt transition, see e.g.: https://buildd.debian.org/status/package.php?p=pycurl Are you aware of that? Not sure if that's part of the gnutls transition or if we should have another bug for that. Regards, Emilio -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/539f7094.6070...@debian.org
Processed: Re: Bug#748535: transition: gnutls28
Processing control commands: forwarded -1 https://release.debian.org/transitions/html/gnutls28.html Bug #748535 [release.debian.org] transition: gnutls28 Changed Bug forwarded-to-address to 'https://release.debian.org/transitions/html/gnutls28.html' from 'https://release.debian.org/transitions/html/libgnutls-deb0-28.html' -- 748535: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748535 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/handler.s.b748535.140295798430175.transcr...@bugs.debian.org
