Processed: found 702475 in 2.4.2-1, notfound 702475 in 2.2.22-12
Processing commands for cont...@bugs.debian.org: found 702475 2.4.2-1 Bug #702475 [apache2] apache2: the itk MPM is underlinked: sys/capability.h symbols are not resolved Ignoring request to alter found versions of bug #702475 to the same values previously set notfound 702475 2.2.22-12 Bug #702475 [apache2] apache2: the itk MPM is underlinked: sys/capability.h symbols are not resolved Ignoring request to alter found versions of bug #702475 to the same values previously set thanks Stopping processing here. Please contact me if you need assistance. -- 702475: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=702475 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#701864: marked as done ('Frontier Artistic License' text missing in debian/copyright)
Your message dated Fri, 08 Mar 2013 09:32:40 + with message-id e1udtfm-0002ch...@franck.debian.org and subject line Bug#701864: fixed in cfengine3 3.2.4-2+nmu1 has caused the Debian Bug report #701864, regarding 'Frontier Artistic License' text missing in debian/copyright to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 701864: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=701864 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: cfengine3 Version: 3.0.5+dfsg-1 Severity: serious The copyright file of cfengine3 version 3.0.5+dfsg-1 misses the full text of the Frontier Artistic License, violating Debian Policy 12.5. A pointer to a web page with the license is not a verbatim copy of its copyright information and distribution license. Thanks for considering, dam -- System Information: Debian Release: 7.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=bg_BG.UTF-8, LC_CTYPE=bg_BG.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash ---End Message--- ---BeginMessage--- Source: cfengine3 Source-Version: 3.2.4-2+nmu1 We believe that the bug you reported is fixed in the latest version of cfengine3, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 701...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Michael Gilbert mgilb...@debian.org (supplier of updated cfengine3 package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 03 Mar 2013 08:53:27 + Source: cfengine3 Binary: cfengine3 cfengine3-dbg Architecture: source amd64 Version: 3.2.4-2+nmu1 Distribution: unstable Urgency: medium Maintainer: Antonio Radici anto...@debian.org Changed-By: Michael Gilbert mgilb...@debian.org Description: cfengine3 - tool for configuring and maintaining network machines cfengine3-dbg - debugging symbols for cfengine3 Closes: 701864 Changes: cfengine3 (3.2.4-2+nmu1) unstable; urgency=medium . * Non-maintainer upload. * Include full text of the Frontier Artistic License (closes: #701864). Checksums-Sha1: a20c6048f93718a597345446516bdf34a8a01964 2683 cfengine3_3.2.4-2+nmu1.dsc 163f972096e612e8c55621944b71f72a1ed87ccd 13945 cfengine3_3.2.4-2+nmu1.debian.tar.gz 43d57cb4f1aab4cbbe8034f6dc51bb8fc570d487 2627846 cfengine3_3.2.4-2+nmu1_amd64.deb fc54ef15749c7e01242164eb9fae247c59dc221c 4740710 cfengine3-dbg_3.2.4-2+nmu1_amd64.deb Checksums-Sha256: 0e5fdb544bc7844491f13b91cd1679d68eb3cce9f4c406611f73135567473de4 2683 cfengine3_3.2.4-2+nmu1.dsc 214d19ba5f4730a978a0981ed2aff4b083b3836776ba440da9e9ffb827f13a19 13945 cfengine3_3.2.4-2+nmu1.debian.tar.gz 9010abbb4be63653eed13e258edb399097ea8087bd9c3a1f79c023fbe76f1208 2627846 cfengine3_3.2.4-2+nmu1_amd64.deb 29b714b484161eb6a7167490053727c91e8f71149d6f804972c71c263ba13bc7 4740710 cfengine3-dbg_3.2.4-2+nmu1_amd64.deb Files: 55ad4f3528b9fc4d332e064321943fb9 2683 admin optional cfengine3_3.2.4-2+nmu1.dsc 2acd443b0f034afec212d4290d27dc50 13945 admin optional cfengine3_3.2.4-2+nmu1.debian.tar.gz 0c90d27324e2c5eef5cae2868b251dbe 2627846 admin optional cfengine3_3.2.4-2+nmu1_amd64.deb a1b7d4ca6b817fba4daff175a67a2017 4740710 debug extra cfengine3-dbg_3.2.4-2+nmu1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQQcBAEBCAAGBQJRMxBMAAoJELjWss0C1vRzoVAgAIe4q8liA8fBdgN3wQZS06kG 1pzBqCtIHOVd275T+TbsQRHbgLjYAN4grHkNt0l7aU8FIqCFmpar+X8C5vXaBcLR tyQSEXwBIlb1zny53O3muadDSMMpnGBBQJL9g+bELDiH3T1CN1dUpYJVNLFmCDhh YSGFEJ34/zODWRaH9WV46PueQ79gU5faeIB5Sf3e2Mi1nOF4cBcfnOrxeKAsjnrO 4zP/RLlwQ724XNhIEBM/GuRTd6Ph9yQ8N1wq4gQDdSCzBFzE/su9j7MmN8usFDtu 3+jlypzfPtaSwL2gOQXUA+Tyhwb6i1HnA1/vwkQxA1oIRcZYZ/OMptQlCbA5knLs BMXaLY2ZahCb+/FMxHaRK/0oC2LFuctO2PVp7UiTDF555vzBlTWjwyWLWsmrzGHG yJan13+qPUmybPa94JsgizpkD3BZqLANdXLgSaUaa0E9iIi9D+dC9Y3WZhK/kk+P PFt+9WTaENPNOs14N+G7D9U4/fCNO7fPW/3iUVkffOJ3ZImwrWLsYDhCGrjTHSw/ MjydXVzMBPJBwuiagpxcHz3HAinB0KyNYaDO6fxU6Ppb9e8di3mpPJwAF9A4l+TM XPeHTUYqNkT6mtcnvj6WLMkEohF1BbnRkLvqwpm6kfuSjUKWxsE6FkBesQfsPIXS
Bug#702512: marked as done (openms: FTBFS when DEB_HOST_MULTIARCH != DEB_BUILD_GNU_TYPE (e.g., on i386))
Your message dated Fri, 08 Mar 2013 09:48:31 + with message-id e1udtuh-0007ob...@franck.debian.org and subject line Bug#702512: fixed in openms 1.9.0-3 has caused the Debian Bug report #702512, regarding openms: FTBFS when DEB_HOST_MULTIARCH != DEB_BUILD_GNU_TYPE (e.g., on i386) to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 702512: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=702512 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Source: openms Version: 1.9.0-2 Severity: serious Justification: fails to build from source Builds of openms on certain architectures (i386 and kfreebsd-i386 so far) have been failing because they base expected multiarch paths on DEB_BUILD_GNU_TYPE rather than DEB_HOST_MULTIARCH, which may differ. (For instance, on i386, DEB_BUILD_GNU_TYPE is i486-linux-gnu, whereas DEB_HOST_MULTIARCH is i386-linux-gnu.) cd /build/buildd-openms_1.9.0-2-i386-iJCLgn/openms-1.9.0/debian/build \ /usr/bin/cmake -DCMAKE_FIND_LIBRARY_SUFFIXES=.so \ -DCONTRIB_LIB_DIR=/usr/lib;/usr/lib/i486-linux-gnu;/lib/i486-linux-gnu \ -DCF_OPENMS_DATA_PATH=/usr/share/openms-common/OpenMS/ \ -DCF_OPENMS_DOC_PATH=/usr/share/doc/openms-doc/ \ -DCMAKE_BUILD_TYPE=release ../.. -- The C compiler identification is GNU 4.7.2 -- The CXX compiler identification is GNU 4.7.2 [...] CMake Error at cmake/OpenMSBuildSystem_macros.cmake:11 (MESSAGE): Unable to find xerces_c library! Searched names are: [xerces-c_3;xerces-c_static_3;libxerces-c;xerces-c] Please make sure it is part of the contrib (which we assume to be in either of these directories: /usr/lib;/usr/lib/i486-linux-gnu;/lib/i486-linux-gnu;/build/buildd-openms_1.9.0-2-i386-iJCLgn/openms-1.9.0/contrib/lib/;/opt/local/lib/;/usr/local/lib/) According to cmake's changelog, find_library has supported multiarch paths since 2.8.4+dfsg.1-3 from 2011, so you shouldn't necessarily need to override its search path at all; however, if you do, please do so on the basis of the correct variable. Thanks! -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (300, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash ---End Message--- ---BeginMessage--- Source: openms Source-Version: 1.9.0-3 We believe that the bug you reported is fixed in the latest version of openms, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 702...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Filippo Rusconi lopi...@debian.org (supplier of updated openms package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Thu, 07 Mar 2013 18:38:56 +0100 Source: openms Binary: libopenms1 libopenms-dev topp openms-common openms-doc openms Architecture: source amd64 all Version: 1.9.0-3 Distribution: unstable Urgency: low Maintainer: The Debichem Group debichem-de...@lists.alioth.debian.org Changed-By: Filippo Rusconi lopi...@debian.org Description: libopenms-dev - library for LC/MS data management and analysis - dev files libopenms1 - library for LC/MS data management and analysis - runtime openms - package for LC/MS data management and analysis openms-common - package for LC/MS data management and analysis - shared data openms-doc - package for LC/MS data management and analysis - documentation topp - set of programs implementing The OpenMS Proteomic Pipeline Closes: 702512 702518 Changes: openms (1.9.0-3) unstable; urgency=low . * debian/rules: fix problem with DEB_BUILD_GNU_TYPE not holding proper values on some platforms, like i386, by adding DEB_HOST_MULTIARCH. Thanks to Aaron M. Ucko u...@debian.org (Closes: #702512); * Fix the watch file, thanks to Nick Black nick.bl...@sprezzatech.com (Closes: #702518); . * New code in patch ensures that there is no creation of symlinks by CMake after building of the libraries, since the symlinks are created anyways in debian/. Checksums-Sha1:
Bug#697230: asterisk: Two security issues: AST-2012-014 / AST-2012-015
Hello, why has this bug been marked as not found in the version in sid again? I can't see a new version of the package in the repository and it's still listed as vulnerable on security-tracker.debian.org. As I'm currently using the version from squeeze-backports, I'd really like to see this fixed in sid (and then wheezy and then squeeze-backports, hopefully). -- So long, Christian. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#655969: lirc: prompting due to modified conffiles which where not modified by the user
Le vendredi 8 mars 2013 03:32:29, Stefan Lippers-Hollmann a écrit : Hi On Thursday 07 March 2013, Thomas Preud'homme wrote: tags 655969 + patch thanks Le samedi 26 janvier 2013 19:22:23, Jonathan Wiltshire a écrit : On Wed, Jan 18, 2012 at 01:34:08AM +0100, Stefan Lippers-Hollmann wrote: Thanks for the notice, while I don't exactly share that severity classification (although that is of course covered by the policy text), I'll work on this as soon as possible. Ping? It's been a year, and with a popcon of over 60,000 a *lot* of people are going to start seeing this prompt very soon... What about this patch? It checks whether the md5 of the lirc/hardware.conf conffile installed on the system matches the md5 of the file as modified by the postinst in an automatic install. If that is the case, it sets the file back to the content as shipped in the .deb package so that dpkg doesn't detect the file as modified. I reproduced the bug in pbuilder and the bug disappear when using this patch. […] Thanks for looking into this bug, the patch itself is correct and will avoid the reported piuparts upgrade issue (which is technically RC), so please feel free to upload the NMU (I'd appreciate it). Great, I've been suggested to add a test for the version being upgraded from and testing if the file exist. Once done, I'll upload it (should be today or sunday). Just be aware that it only papers over a larger issue that forces most lircd users actually driving various lirc hardware to reconfigure their config file regardless of this change; please see http://anonscm.debian.org/viewvc/pkg- lirc/lirc/trunk/debian/NEWS?view=mark up or https://lists.debian.org/debian-backports/2012/04/msg00076.html for background information. Ack, the patch is not as useful as it could be. Can't lirc be installed by a Recommends dependency? If yes, it might be that the package is not of interest of the user and this message would thus annoy him/her. If lirc is on the contrary always installed when the user intend to use it, then the best approach is probably to tag it wheezy-ignore. It would be an even smaller change than this patch. For these reasons, I probably would have asked for a wheezy-ignore, in order to get a complete fix into jessie, rather than only fixing the reported bug. However your proposed nmudiff won't interfere with those for-jessie changes and I'd appreciate if you could upload it. If lirc is always installed to be used (never pulled by a Recommends), then tag it wheezy-ignore is probably the best approach indeed. Thanks for the background. Thanks a lot. Regards Stefan Lippers-Hollmann [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=14;bug=655969 Best regards, Thomas signature.asc Description: This is a digitally signed message part.
Bug#702509: unattended-upgrades: does not run autonomously, even after it was enabled
On Fri, Mar 8, 2013 at 6:50 AM, Michael Vogt m...@debian.org wrote: On Thu, Mar 07, 2013 at 04:43:03PM +0100, g0to wrote: Package: unattended-upgrades Version: 0.79.4 Severity: grave Tags: security Justification: renders package unusable Thanks for your bugreport. after trying to make it run by myself and googling and make a few questions here[1] and there[2], I've decided to contact you to report what seems to be a lack of functionality of the package. Following the instructions in /usr/share/doc/unattended-upgrades/README, after installing the package, I enabled it sudo dpkg-reconfigure -plow unattended-upgrades uncommented the proper lines in /etc/apt/apt.conf.d/50unattended-upgrades (below) and waited for it to unattendedly keeps my system update. But that didn't happen. After checking the logs in /var/log/unattended-upgrades/ and /var/log/apt/history.log for several days, no activity was recorded there. I also tried running it in the --dry-run way and it dry worked with no errors. I've tagged the bug like a security issue because someone could trust the security updates of their system after installing and enabling the package and don't check if it's working after a long, and potentially insecure, time. Thank you for your time and for your job maintaining the package. The way you enabled it should work so I would need some additional information from you to figure out what is going on. Could you please send me the output of: $ apt-config dump|grep Periodic APT::Periodic ; APT::Periodic::Update-Package-Lists 1; APT::Periodic::Unattended-Upgrade 1; and then the debug output that: $ sudo unattended-upgrade --debug --dry-run /tmp/un.output 21 This will generate a file /tmp/un.output that I need too. I think that you had a typo at the end of your line. This is the output of running $ sudo unattended-upgrade --debug --dry-run /tmp/un.output 21 Initial blacklisted packages: Starting unattended upgrades script Allowed origins are: ['o=Debian,n=wheezy', 'o=Debian,n=wheezy-updates', 'o=Debian,n=wheezy-proposed-updates', 'o=Debian,n=wheezy,l=Debian-Security'] pkgs that look like they should be upgraded: Fetched 0 B in 0s (0 B/s) fetch.run() result: 0 blacklist: [] Packages that are auto removed: '' InstCount=0 DelCount=0 BrokenCout=0 No packages found that can be upgraded unattended and finally the file: /var/log/unattended-upgrades/unattended-upgrades.log Note that this file didn't exist until I ran the line above (the --dry-run). Here's its content: 2013-03-08 11:48:08,316 INFO Initial blacklisted packages: 2013-03-08 11:48:08,322 INFO Starting unattended upgrades script 2013-03-08 11:48:08,328 INFO Allowed origins are: ['o=Debian,n=wheezy', 'o=Debian,n=wheezy-updates', 'o=Debian,n=wheezy-proposed-updates', 'o=Debian,n=wheezy,l=Debian-Security'] 2013-03-08 11:49:15,411 DEBUG pkgs that look like they should be upgraded: 2013-03-08 11:49:15,488 DEBUG fetch.run() result: 0 2013-03-08 11:49:15,490 DEBUG blacklist: [] 2013-03-08 11:49:35,734 INFO Packages that are auto removed: '' 2013-03-08 11:49:35,736 DEBUG InstCount=0 DelCount=0 BrokenCout=0 2013-03-08 11:49:35,741 INFO No packages found that can be upgraded unattended That hopefully gives me enough information to figure out what is going on. I suspect for some reason the script is not run in your cron which is strange. It hooks into /etc/cron.daily/apt, you can also run: $ sudo sh -x /etc/cron.daily/apt + test -r /var/lib/apt/extended_states + cd /var/backups + cmp -s apt.extended_states.0 /var/lib/apt/extended_states + which apt-config + AutoAptEnable=1 + apt-config shell AutoAptEnable APT::Periodic::Enable + eval + [ 1 -eq 0 ] + VERBOSE=0 + apt-config shell VERBOSE APT::Periodic::Verbose + eval + debug_echo verbose level 0 + [ 0 -ge 1 ] + [ 0 -le 2 ] + XSTDOUT=/dev/null + XSTDERR=2/dev/null + XAPTOPT=-qq + XUUPOPT= + [ 0 -ge 3 ] + check_power + which on_ac_power + return 0 + which apt-get + eval apt-get check -f -qq 2/dev/null + apt-get check -f -qq + date +%s + now=1362740095 + UpdateInterval=0 + apt-config shell UpdateInterval APT::Periodic::Update-Package-Lists + eval UpdateInterval='1' + UpdateInterval=1 + DownloadUpgradeableInterval=0 + apt-config shell DownloadUpgradeableInterval APT::Periodic::Download-Upgradeable-Packages + eval + UnattendedUpgradeInterval=0 + apt-config shell UnattendedUpgradeInterval APT::Periodic::Unattended-Upgrade + eval UnattendedUpgradeInterval='1' + UnattendedUpgradeInterval=1 + AutocleanInterval=0 + apt-config shell AutocleanInterval APT::Periodic::AutocleanInterval + eval + BackupArchiveInterval=0 + apt-config shell BackupArchiveInterval APT::Periodic::BackupArchiveInterval + eval + Debdelta=1 + apt-config shell Debdelta APT::Periodic::Download-Upgradeable-Packages-Debdelta + eval + [ 1 -eq 0 ] + do_cache_backup 0 + BackupArchiveInterval=0 + [ 0 -eq 0 ] + return + random_sleep + RandomSleep=1800 + apt-config shell RandomSleep
Bug#702509: unattended-upgrades: does not run autonomously, even after it was enabled
Hi, Teodor,
On Fri, Mar 8, 2013 at 7:50 AM, Teodor MICU mteo...@gmail.com wrote:
2013/3/7 g0to amo...@gmail.com:
-- Configuration Files:
/etc/apt/apt.conf.d/50unattended-upgrades changed:
// Automatically upgrade packages from these origin patterns
Unattended-Upgrade::Origins-Pattern {
// Codename based matching:
// This will follow the migration of a release through different
// archives (e.g. from testing to stable and later oldstable).
o=Debian,n=wheezy;
o=Debian,n=wheezy-updates;
o=Debian,n=wheezy-proposed-updates;
o=Debian,n=wheezy,l=Debian-Security;
This config was removed in version 0.79.5 and might not work at all:
- remove codename based matching example as this needs a newer
python-apt than available in wheezy, thanks to Russell Stuart
I'm currently using 0.79.4, therefore the config change does not affect me,
right?
// Archive or Suite based matching:
// Note that this will silently match a different release after
// migration to the specified archive (e.g. testing becomes the
// new stable).
// o=Debian,a=stable;
// o=Debian,a=stable-updates;
// o=Debian,a=proposed-updates;
// origin=Debian,archive=stable,label=Debian-Security;
};
Usually this is what you need to enable, plus an extra line if you are
using testing or unstable.
Anyway, my main issue is that the unattended upgrades don't run. If it
would be only a config file problem, they would run but with no upgradable
candidates.
Please, correct me if I'm wrong and thanks for your input.
Cheers.
Cheers
Bug#702560: extremetuxracer: Starting a race tux turns left
Package: extremetuxracer Version: 0.5beta-2 Severity: grave Justification: renders package unusable Hallo, when I want to play extremetuxracer game in wheezy, tux turns left just immediate after starting a race (without touching keyboard). Player is not able to turn right, when he press right arrow, tux continues stright away. It is turn right from previous state, but it is not expected behavior. I've tried at first version 0.4-5 from wheezy, then 0.4-4 from stable and then experimental 0.5beta version. Bug is present in all checked versions in wheezy environment. Stable version in stable environment works fine. Wheezy version in stable system requires library update so I didn't test it. I am almost sure that bug is in another package, but I cannot find the right package. Regards, Pavel -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages extremetuxracer depends on: ii extremetuxracer-data 0.5beta-2 ii libc6 2.13-38 ii libfreetype6 2.4.9-1.1 ii libgcc1 1:4.7.2-5 ii libgl1-mesa-glx [libgl1] 8.0.5-3 ii libglu1-mesa [libglu1]8.0.5-3 ii libice6 2:1.0.8-2 ii libpng12-01.2.49-1 ii libsdl-mixer1.2 1.2.12-3 ii libsdl1.2debian 1.2.15-5 ii libsm62:1.2.1-2 ii libstdc++64.7.2-5 ii libx11-6 2:1.5.0-1 ii libxext6 2:1.3.1-2 ii libxi62:1.6.1-1 ii libxmu6 2:1.1.1-1 ii libxt61:1.1.3-1 ii tcl8.58.5.11-2 ii zlib1g1:1.2.7.dfsg-13 extremetuxracer recommends no packages. extremetuxracer suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702261: libv8: CVE-2012-5153 CVE-2013-0836
On 04/03/2013 16:39, Moritz Muehlenhoff wrote: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-5153 Fix: https://code.google.com/p/v8/source/detail?r=13161 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-0836 Fix: https://code.google.com/p/v8/source/detail?r=12543 Cheers, Giuseppe. signature.asc Description: OpenPGP digital signature
Processed: All license issues clarified, pending upload after Wheezy release
Processing commands for cont...@bugs.debian.org: tags 694908 pending Bug #694908 [emboss] Contains non-free data Added tag(s) pending. thanks Stopping processing here. Please contact me if you need assistance. -- 694908: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=694908 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processed: your mail
Processing commands for cont...@bugs.debian.org: severity 702560 normal Bug #702560 [extremetuxracer] extremetuxracer: Starting a race tux turns left Severity set to 'normal' from 'grave' thanks Stopping processing here. Please contact me if you need assistance. -- 702560: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=702560 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688577: [Pkg-cas-maintainers] (no subject)
On Thu, March 7, 2013 21:44, Thijs Kinkhorst wrote: On Thu, March 7, 2013 19:31, Mathieu Parent wrote: severity 688577 grave tag 688577 + patch upstream fixed-upstream thanks Hi, Raising severity as this renders the package unusable. Confirmed, fixed, will upload. Thijs -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702509: unattended-upgrades: does not run autonomously, even after it was enabled
Hi g0to, This looks to be an anacron issue, and /etc/cron.daily/apt not running automatically. Please could you take a look at: # cat /var/spool/anacron/cron.daily # grep daily /var/log/cron.log.1 # ps aux | grep cron | grep -v grep Thanks! Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#694908: Contains non-free data
Hi, latest status update: Tag pending was set. All known license issues are now solved in debian/copyright of packaging Git. However, the version of EMBOSS in the Git repository is already higher than in wheezy, so we decided to wait with an upload until after the release. The fact that RC team has set wheezy-ignore seems to support this decision. Kind regards and thanks to all who helped solving this problem Andreas. On Sat, Jan 26, 2013 at 12:51:23PM +, Julien Cristau wrote: Control: tag -1 wheezy-ignore Seems there's good progress towards fixing this, so tagging wheezy-ignore. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702573: libopenms1 - No stable ABI
Package: libopenms1 Version: 1.9.0-2 Severity: serious OpenMS upstream does not provide a stable ABI of libOpenMS. So neither the patch to add one nor this package name are appropriate. Bastian -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.7-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702574: TYPO3-CORE-SA-2013-001: SQL Injection and Open Redirection in TYPO3 Core
Package: typo3-src
Severity: critical
Tags: security
It has been discovered that TYPO3 Core is susceptible to SQL Injection
and Open Redirection
Component Type: TYPO3 Core
Affected Versions: 4.5.0 up to 4.5.23, 4.6.0 up to 4.6.16, 4.7.0 up to
4.7.8 and 6.0.0 up to 6.0.2
Vulnerability Types: SQL Injection, Open Redirection
Overall Severity: High
Release Date: March 6, 2013
Vulnerable subcomponent: Extbase Framework
Vulnerability Type: SQL Injection
Severity: Critical
Suggested CVSS v2.0: AV:N/AC:M/Au:N/C:C/I:C/A:N/E:H/RL:O/RC:C
Problem Description: Failing to sanitize user input, the Extbase
database abstraction layer is susceptible to SQL Injection. TYPO3 sites
which have no Extbase extensions installed are not affected. Extbase
extensions are affected if they use the Query Object Model and relation
values are user generated input. (e.g. :
$query-contains('model.categories', $userProvidedValue) )
Note: It has been reported to the TYPO3 Security Team that this problem
is known and exploited in the wild.
Vulnerable subcomponent: Access tracking mechanism
Vulnerability Type: Open Redirection
Severity: Medium
Suggested CVSS v2.0: AV:N/AC:L/Au:N/C:N/I:P/A:N/E:H/RL:O/RC:C
Problem Description: Failing to validate user provided input, the access
tracking mechanism allows redirects to arbitrary URLs.
Important Notes: To fix this vulnerability, we had to break existing
behaviour of TYPO3 sites that use the access tracking mechanism (jumpurl
feature) to transform links to external sites. The link generation has
been changed to include a hash that is checked before redirecting to an
external URL. This means that old links that have been distributed (e.g.
by a newsletter) will not work any more. If you are using the jumpurl
feature you need to do the following:
lookup more information on
http://typo3.org/teams/security/security-bulletins/typo3-core/typo3-core-sa-2013-001/
--
MfG, Christian Welzel
GPG-Key: http://www.camlann.de/de/pgpkey.html
Fingerprint: 4F50 19BF 3346 36A6 CFA9 DBDC C268 6D24 70A1 AD15
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702509: unattended-upgrades: does not run autonomously, even after it was enabled
On Fri, Mar 8, 2013 at 3:20 PM, Steven Chamberlain ste...@pyro.eu.orgwrote: Hi g0to, Hello, Steven! This looks to be an anacron issue, and /etc/cron.daily/apt not running automatically. Please could you take a look at: # cat /var/spool/anacron/cron.daily 20130308 # grep daily /var/log/cron.log.1 The file /var/log/cron.log.1 does not exist. # ps aux | grep cron | grep -v grep root 1962 0.0 0.4 4368 952 ?Ss 11:22 0:00 /usr/sbin/cron Thanks! Cheers, mate. Regards, g0to. Regards, -- Steven Chamberlain ste...@pyro.eu.org
Bug#688577: marked as done (libapache2-mod-auth-cas: Cannot load module (undefined symbol: CRYPTO_THREADID_get_id_callback))
Your message dated Fri, 08 Mar 2013 15:10:09 + with message-id e1udyvx-0007m7...@franck.debian.org and subject line Bug#688577: fixed in libapache2-mod-auth-cas 1.0.9.1-2 has caused the Debian Bug report #688577, regarding libapache2-mod-auth-cas: Cannot load module (undefined symbol: CRYPTO_THREADID_get_id_callback) to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 688577: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=688577 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: libapache2-mod-auth-cas Version: 1.0.9.1-1 Severity: normal Hi, Perhaps I am missing something obvious. I installed the package and enabled the module with a2enmod but on attempting to restart Apache I got: line 1 of /etc/apache2/mods-enabled/auth_cas.load: Cannot load /usr/lib/apache2/modules/mod_auth_cas.so into server: /usr/lib/apache2/modules/mod_auth_cas.so: undefined symbol: CRYPTO_THREADID_get_id_callback which Google seems to suggest needs a patch to the .h file... but this is presumably working for others? Thanks for all your work on this package, CT. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libapache2-mod-auth-cas depends on: ii apache2.2-common 2.2.22-11 ii libc6 2.13-35 ii libcurl3 7.26.0-1 ii libssl1.0.0 1.0.1c-4 libapache2-mod-auth-cas recommends no packages. libapache2-mod-auth-cas suggests no packages. -- no debconf information ---End Message--- ---BeginMessage--- Source: libapache2-mod-auth-cas Source-Version: 1.0.9.1-2 We believe that the bug you reported is fixed in the latest version of libapache2-mod-auth-cas, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 688...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Thijs Kinkhorst th...@debian.org (supplier of updated libapache2-mod-auth-cas package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Fri, 08 Mar 2013 14:35:48 +0100 Source: libapache2-mod-auth-cas Binary: libapache2-mod-auth-cas Architecture: source amd64 Version: 1.0.9.1-2 Distribution: unstable Urgency: high Maintainer: CAS packaging team pkg-cas-maintain...@lists.alioth.debian.org Changed-By: Thijs Kinkhorst th...@debian.org Description: libapache2-mod-auth-cas - CAS authentication module for Apache2 Closes: 688577 Changes: libapache2-mod-auth-cas (1.0.9.1-2) unstable; urgency=high . * Fix changed function names in OpenSSL 1.0 (closes: #688577). Checksums-Sha1: 1f76bbc120c4fc3ac73a67b1927d825c49dec62e 1915 libapache2-mod-auth-cas_1.0.9.1-2.dsc e5e2ce32b5574c72e597f4f5dcdc42ba7a96ead3 5447 libapache2-mod-auth-cas_1.0.9.1-2.debian.tar.gz a1805842a73518bd470d084bbf9fce10e820886c 34532 libapache2-mod-auth-cas_1.0.9.1-2_amd64.deb Checksums-Sha256: 4e6c534f87995cba1d361ce75578dbf2601b7e21e56a580b2f8c70c79b945190 1915 libapache2-mod-auth-cas_1.0.9.1-2.dsc 6154c5cf2a585e9ec673a813503d325963a7a3d40a677c1373505b80afc07022 5447 libapache2-mod-auth-cas_1.0.9.1-2.debian.tar.gz 1847d559eed7c32555366670d1e92be78846a85bb691d8656ac54958f003c920 34532 libapache2-mod-auth-cas_1.0.9.1-2_amd64.deb Files: 0bc299ed6a06a06334b14a3450f34215 1915 httpd extra libapache2-mod-auth-cas_1.0.9.1-2.dsc 82d6926e0d939c78fcd8b7eeb8575174 5447 httpd extra libapache2-mod-auth-cas_1.0.9.1-2.debian.tar.gz a61d4b83a8255100bc8c121cad6517d3 34532 httpd extra libapache2-mod-auth-cas_1.0.9.1-2_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJROe2jAAoJEFb2GnlAHawEbd0H/1XAJjuPSC67dbdF5qIRubqD cBEhviw/BNUMlsonS0ZhCjHiTIe4ZpztsEI7ConnvskyAFBklOFE/L9Pme2VPJxZ ohu8FUlOGKHKA1oDCWpR0oFj/PhZy3v81LXbmuVMXaB+ZTn+bII4biUbb0mJ1aHX 2jwT7lv2BdUEZcJ+Td3tZTBAWSGmeAPOOfx9Uh3W2ZEqQobnyOK7Tvezhbuxe4j/ qBXS+X1ODIBxjomAvea8deTusIeuovATkrghi7VAQix+k7mbiF8K9NSSxLnEX1Rr DvpzROnE0Pj/6LcOMEioTj1x0SWN5XwrggBc0NjOuQ3XYByQBsdu0YPcGcKupss=
Bug#702509: unattended-upgrades: does not run autonomously, even after it was enabled
On 08/03/13 15:08, Arturo Moral wrote: # cat /var/spool/anacron/cron.daily 20130308 This means 'cron' was working properly, and it updated the timestamp in that file. What about the file /etc/cron.d/anacron ? Is it there, what are its contents? Also: $ ls -al /usr/sbin/anacron /etc/init.d/anacron /usr/bin/on_ac_power # grep daily /var/log/cron.log.1 The file /var/log/cron.log.1 does not exist. Thank you. On my system (with rsyslogd) that would be created by logrotate from cron.daily... What about this file instead? # grep daily /var/log/cron.log Thanks. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702509: unattended-upgrades: does not run autonomously, even after it was enabled
On Fri, Mar 8, 2013 at 4:15 PM, Steven Chamberlain ste...@pyro.eu.orgwrote: On 08/03/13 15:08, Arturo Moral wrote: # cat /var/spool/anacron/cron.daily 20130308 This means 'cron' was working properly, and it updated the timestamp in that file. What about the file /etc/cron.d/anacron ? Is it there, what are its contents? # /etc/cron.d/anacron: crontab entries for the anacron package SHELL=/bin/sh PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin 30 7* * * roottest -x /etc/init.d/anacron /usr/sbin/invoke-rc.d anacron start /dev/null Also: $ ls -al /usr/sbin/anacron /etc/init.d/anacron /usr/bin/on_ac_power ls: cannot access /usr/bin/on_ac_power: No such file or directory -rwxr-xr-x 1 root root 2,0K may 21 2012 /etc/init.d/anacron -rwxr-xr-x 1 root root 30K jun 2 2012 /usr/sbin/anacron # grep daily /var/log/cron.log.1 The file /var/log/cron.log.1 does not exist. Thank you. On my system (with rsyslogd) that would be created by logrotate from cron.daily... What about this file instead? # grep daily /var/log/cron.log That file doesn't exist either. I use to check cron outputs in /var/log/syslog so I ran: # grep -i daily /var/log/syslog Mar 8 11:27:51 raspi anacron[1920]: Job `cron.daily' terminated Thanks. Regards, -- Steven Chamberlain ste...@pyro.eu.org
Bug#702509: unattended-upgrades: does not run autonomously, even after it was enabled
On 16:27, Arturo Moral wrote: # grep -i daily /var/log/syslog Mar 8 11:27:51 raspi anacron[1920]: Job `cron.daily' terminated The log was probably rotated at that point. Is there anythikng more of interest in the preceding log, e.g. syslog.1 or syslog.1.gz? Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702509: unattended-upgrades: does not run autonomously, even after it was enabled
On Fri, Mar 8, 2013 at 4:49 PM, Steven Chamberlain ste...@pyro.eu.orgwrote: On 16:27, Arturo Moral wrote: # grep -i daily /var/log/syslog Mar 8 11:27:51 raspi anacron[1920]: Job `cron.daily' terminated The log was probably rotated at that point. Is there anythikng more of interest in the preceding log, e.g. syslog.1 or syslog.1.gz? Here are all the daily occurrences inside syslog, syslog.1 and syslog.2.gz: Mar 4 21:25:01 raspi /USR/SBIN/CRON[20013]: (root) CMD (test -x /usr/sbin/anacron || ( cd / run-parts --report /etc/cron.daily )) Mar 5 00:30:24 raspi anacron[1781]: Will run job `cron.daily' in 5 min. Mar 5 10:16:35 raspi anacron[1781]: Job `cron.daily' started Mar 5 10:16:36 raspi anacron[2631]: Updated timestamp for job `cron.daily' to 2013-03-05 Mar 5 10:28:38 raspi anacron[1781]: Job `cron.daily' terminated Mar 5 21:25:01 raspi /USR/SBIN/CRON[21063]: (root) CMD (test -x /usr/sbin/anacron || ( cd / run-parts --report /etc/cron.daily )) Mar 6 21:25:01 raspi /USR/SBIN/CRON[23904]: (root) CMD (test -x /usr/sbin/anacron || ( cd / run-parts --report /etc/cron.daily )) Mar 7 00:28:24 raspi anacron[1939]: Will run job `cron.daily' in 5 min. Mar 7 12:47:32 raspi anacron[1939]: Job `cron.daily' started Mar 7 12:47:32 raspi anacron[3205]: Updated timestamp for job `cron.daily' to 2013-03-07 Mar 7 12:54:22 raspi anacron[1939]: Job `cron.daily' terminated Mar 7 21:25:01 raspi /USR/SBIN/CRON[32538]: (root) CMD (test -x /usr/sbin/anacron || ( cd / run-parts --report /etc/cron.daily )) Mar 8 00:10:23 raspi anacron[1920]: Will run job `cron.daily' in 5 min. Mar 8 11:27:42 raspi anacron[1920]: Job `cron.daily' started Mar 8 11:27:42 raspi anacron[4741]: Updated timestamp for job `cron.daily' to 2013-03-08 Mar 8 11:27:51 raspi anacron[1920]: Job `cron.daily' terminated Thanks, Thank you for your quick responses, Steven. For me, everything seems to be working properly. I can't spot the problem. Cheers. Regards, -- Steven Chamberlain ste...@pyro.eu.org
Processed: your mail
Processing commands for cont...@bugs.debian.org:
tag 680635 + pending
Bug #680635 [pyside-tools] pyside-tools: fails to install: SyntaxError:
('invalid syntax',
('/usr/lib/python2.7/dist-packages/pysideuic/port_v3/proxy_base.py', 26, 26,
'class ProxyBase(metaclass=ProxyType):\n'))
Added tag(s) pending.
thanks
Stopping processing here.
Please contact me if you need assistance.
--
680635: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=680635
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#655969: lirc: prompting due to modified conffiles which where not modified by the user
Hi On Friday 08 March 2013, Thomas Preud'homme wrote: Le vendredi 8 mars 2013 03:32:29, Stefan Lippers-Hollmann a écrit : […] On Thursday 07 March 2013, Thomas Preud'homme wrote: […] Thanks for looking into this bug, the patch itself is correct and will avoid the reported piuparts upgrade issue (which is technically RC), so please feel free to upload the NMU (I'd appreciate it). Great, I've been suggested to add a test for the version being upgraded from and testing if the file exist. Once done, I'll upload it (should be today or sunday). ack, thanks a lot. Just be aware that it only papers over a larger issue that forces most lircd users actually driving various lirc hardware to reconfigure their config file regardless of this change; please see http://anonscm.debian.org/viewvc/pkg- lirc/lirc/trunk/debian/NEWS?view=mark up or https://lists.debian.org/debian-backports/2012/04/msg00076.html for background information. Ack, the patch is not as useful as it could be. Can't lirc be installed by a Recommends dependency? If yes, it might be that the package is not of interest of the user and this message would thus annoy him/her. If lirc is on the contrary always installed when the user intend to use it, then the best approach is probably to tag it wheezy-ignore. It would be an even smaller change than this patch. [detailed analysis below, feel free to skip this list] The rdepends of lirc, excluding packages built from the lirc source package itself, are: - vdr Video Disk Recorder for DVB cards Recommends: lirc, ttf-bitstream-vera | ttf-freefont vdr has three different ways of navigation (channel selection, lirc is probably the most important one which always works (provided you have properly configured hardware), keyboard based navigation is only possible through selected frontends (e.g. xineliboutput-sxfe, only this special frontend can transport key presses to the vdr dæmon) or web based, through e.g vdr-plugin-live. This makes it, while not mandatory, rather likely that a vdr user also uses lirc hardware; it's probably a wishlist bug that vdr doesn't have an alternative recommends on inputlirc (an alternative lircd implementation) - inputlirc Zeroconf LIRC daemon using input event devices Suggests: lirc, input-utils not pulled in automatically, the suggests looks weird at a first glance (as inputlirc can provide a full lircd replacement for a subset (only event based-) devices also supported by lircd, but the reasons for this are the supporting tools of the lirc package (mostly irw, to generate button -- keycode mappings, eventually irexec). Technically speaking, it might make sense to split out these tools out of the lirc package, but that would leave lircd/ lircmd in a tiny package of their own - something ftp-master doesn't exactly prefer. - kremotecontrolfrontend for using remote controls Recommends: lirc This one is a tough call, isolated to kremotecontrol, the Recommends is correct, but kremotecontrol is a hard dependency of kdeutils (meta package, probably installed for most KDE users), which in turn is a hard dependency of kde-full… Besides the typical lirc | inputlirc suggestion, this may be a larger cause for lirc installations even if the user actually has not need for it; it's also a relatively new dependency, as its KDE3 predecessor -kdelirc- was not part of kdeutils at the time. Technically the dependency chain is totally correct and weakening it wouldn't be a logical conclusion for these meta packages, but given the lirc is only useful, if you have special, non-standard hardware (an IR receiver and a remote to use it) a suggests might be more in order. kremotecontrol didn't exist in squeeze, only its predecessor kdelirc, which was a seperate source package and not part of kdeutils; it was only suggested by kdetv, no hard dependencies or recommends. - freevo-lirc home theater framework - LIRC support Depends: freevo (= 1.9.2b2-4.2), python-pylirc, lirc This one seems to be fine, no rdepends - not even a suggestion from any other package. (disclaimer, I've never used freevo) - enna a powerful MediaCenter application based on EFL Suggests: lirc only a suggests, so no issue here. (disclaimer, I've never used enna) - banshee-extension-lircLIRC integration extension for Banshee Depends: banshee-extensions-common (= 2.4.0-1), lirc, libc6 (= 2.2.5), liblircclient0, libmono-corlib4.0-cil (= 2.10.1) A recommends of banshee-community-extensions, a meta package, which in turn has no rdepends, this may be slightly inflate the number of unneeded lirc installations, but I'm not sure of how commonly this meta package is in the banchee community - probably the same Depends vs Suggests considerations as for kdeutils above apply. (disclaimer, I've never used banshee) So the
Bug#680635: marked as done (pyside-tools: fails to install: SyntaxError: ('invalid syntax', ('/usr/lib/python2.7/dist-packages/pysideuic/port_v3/proxy_base.py', 26, 26, 'class ProxyBase(metaclass=Prox
Your message dated Fri, 08 Mar 2013 16:33:28 +
with message-id e1ue0ea-0003dv...@franck.debian.org
and subject line Bug#680635: fixed in pyside-tools 0.2.14-2
has caused the Debian Bug report #680635,
regarding pyside-tools: fails to install: SyntaxError: ('invalid syntax',
('/usr/lib/python2.7/dist-packages/pysideuic/port_v3/proxy_base.py', 26, 26,
'class ProxyBase(metaclass=ProxyType):\n'))
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
680635: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=680635
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
---BeginMessage---
Package: pyside-tools
Version: 0.2.14-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
Hi,
during a test with piuparts I noticed your package failed to install. As
per definition of the release team this makes the package too buggy for
a release, thus the severity.
From the attached log (scroll to the bottom...):
Selecting previously unselected package pyside-tools.
(Reading database ... 9097 files and directories currently installed.)
Unpacking pyside-tools (from .../pyside-tools_0.2.14-1_amd64.deb) ...
Setting up pyside-tools (0.2.14-1) ...
SyntaxError: ('invalid syntax',
('/usr/lib/python2.7/dist-packages/pysideuic/port_v3/proxy_base.py', 26, 26,
'class ProxyBase(metaclass=ProxyType):\n'))
SyntaxError: ('invalid syntax',
('/usr/lib/python2.6/dist-packages/pysideuic/port_v3/proxy_base.py', 26, 26,
'class ProxyBase(metaclass=ProxyType):\n'))
dpkg: error processing pyside-tools (--configure):
subprocess installed post-installation script returned error exit status 101
Errors were encountered while processing:
pyside-tools
cheers,
Andreas
pyside-tools_0.2.14-1.log.gz
Description: GNU Zip compressed data
---End Message---
---BeginMessage---
Source: pyside-tools
Source-Version: 0.2.14-2
We believe that the bug you reported is fixed in the latest version of
pyside-tools, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 680...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Didier Raboud o...@debian.org (supplier of updated pyside-tools package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@debian.org)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Fri, 08 Mar 2013 17:08:14 +0100
Source: pyside-tools
Binary: pyside-tools
Architecture: source amd64
Version: 0.2.14-2
Distribution: unstable
Urgency: low
Maintainer: Debian Python Modules Team
python-modules-t...@lists.alioth.debian.org
Changed-By: Didier Raboud o...@debian.org
Description:
pyside-tools - development tools for PySide (uic, rcc, lupdate)
Closes: 680635
Changes:
pyside-tools (0.2.14-2) unstable; urgency=low
.
* Drop v3 files from python2 dist-packages directories; fixes the
package installation. (Closes: #680635)
Checksums-Sha1:
501772d80ec53add6cf42ea317137def7241ec48 2022 pyside-tools_0.2.14-2.dsc
240ef30b1b328daaf55a50cab613d13b114db521 3658
pyside-tools_0.2.14-2.debian.tar.gz
ae2fd2e9cd0f6ab03c3d631b56b1c73678f43d68 167020 pyside-tools_0.2.14-2_amd64.deb
Checksums-Sha256:
a379fdcd81374662f4badd55062478884ad3b416cbba1a8d86954292df32a29a 2022
pyside-tools_0.2.14-2.dsc
790ad5d28daf3fc1722b680cd89676b0bcae75b009e3aec58cc7f3d8647f005b 3658
pyside-tools_0.2.14-2.debian.tar.gz
3d7ef0c19dede94984ccf1b12f102dd9b7e83c2409d8bb1203bcb7c5e6525ab1 167020
pyside-tools_0.2.14-2_amd64.deb
Files:
8fca3e2b857e448cf8a75fd59b63b42c 2022 python optional pyside-tools_0.2.14-2.dsc
927836cc087e2662eb7782eddab61c40 3658 python optional
pyside-tools_0.2.14-2.debian.tar.gz
2d5cff3b1b50712fde8c1f6cb062044e 167020 python optional
pyside-tools_0.2.14-2_amd64.deb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
iQGcBAEBCAAGBQJROg6VAAoJEIvPpx7KFjRVUUAL/jQxL/+ecdE+KEY+xhfbvGm/
1EOtlH750JI6yk5CZKwgc1odtNNGm64+s2gd0PY1OHJw47gIcDcu+9aN865WcTE7
I4ZzFX0YQTjBclqoIkqRZUmf5XygdxJCh6Cu+nRUHLpp6jRbYKzwrH5Ix5AZtGIp
yQWIBNVS6Obi5xpjQNgNEDR80SbG3on4PuaqtLKfLqc9vuYYRKnlArm3vVVYpn4W
TEK8GpWJ6GLmeQVhE0sOUoNk+SrBCgO0uPFom+hTvF4zVSNgZ3Uwfuu3gowgKSxD
6QPEGDy7ExylavR4qdYQGSIcUHntKMoS+WXv8HcZXb0hsZMFCecWN1SgpmWFsvYw
y6YZ32h9VarSMrJF6G788/hn0TwrlerRJ9C4ACA0rmyvw/WSHD9WyZ4oQb3b1RoJ
Bug#655969: lirc: prompting due to modified conffiles which where not modified by the user
[Note to RT: this is about adding a wheezy-ignore tag for #655969] Le vendredi 8 mars 2013 17:27:33, Stefan Lippers-Hollmann a écrit : Hi On Friday 08 March 2013, Thomas Preud'homme wrote: Le vendredi 8 mars 2013 03:32:29, Stefan Lippers-Hollmann a écrit : […] On Thursday 07 March 2013, Thomas Preud'homme wrote: […] Thanks for looking into this bug, the patch itself is correct and will avoid the reported piuparts upgrade issue (which is technically RC), so please feel free to upload the NMU (I'd appreciate it). Great, I've been suggested to add a test for the version being upgraded from and testing if the file exist. Once done, I'll upload it (should be today or sunday). ack, thanks a lot. Just be aware that it only papers over a larger issue that forces most lircd users actually driving various lirc hardware to reconfigure their config file regardless of this change; please see http://anonscm.debian.org/viewvc/pkg- lirc/lirc/trunk/debian/NEWS?view=mark up or https://lists.debian.org/debian-backports/2012/04/msg00076.html for background information. Ack, the patch is not as useful as it could be. Can't lirc be installed by a Recommends dependency? If yes, it might be that the package is not of interest of the user and this message would thus annoy him/her. If lirc is on the contrary always installed when the user intend to use it, then the best approach is probably to tag it wheezy-ignore. It would be an even smaller change than this patch. [detailed analysis below, feel free to skip this list] The rdepends of lirc, excluding packages built from the lirc source package itself, are: - vdr Video Disk Recorder for DVB cards Recommends: lirc, ttf-bitstream-vera | ttf-freefont vdr has three different ways of navigation (channel selection, lirc is probably the most important one which always works (provided you have properly configured hardware), keyboard based navigation is only possible through selected frontends (e.g. xineliboutput-sxfe, only this special frontend can transport key presses to the vdr dæmon) or web based, through e.g vdr-plugin-live. This makes it, while not mandatory, rather likely that a vdr user also uses lirc hardware; it's probably a wishlist bug that vdr doesn't have an alternative recommends on inputlirc (an alternative lircd implementation) - inputlirc Zeroconf LIRC daemon using input event devices Suggests: lirc, input-utils not pulled in automatically, the suggests looks weird at a first glance (as inputlirc can provide a full lircd replacement for a subset (only event based-) devices also supported by lircd, but the reasons for this are the supporting tools of the lirc package (mostly irw, to generate button -- keycode mappings, eventually irexec). Technically speaking, it might make sense to split out these tools out of the lirc package, but that would leave lircd/ lircmd in a tiny package of their own - something ftp-master doesn't exactly prefer. - kremotecontrol frontend for using remote controls Recommends: lirc This one is a tough call, isolated to kremotecontrol, the Recommends is correct, but kremotecontrol is a hard dependency of kdeutils (meta package, probably installed for most KDE users), which in turn is a hard dependency of kde-full… Besides the typical lirc | inputlirc suggestion, this may be a larger cause for lirc installations even if the user actually has not need for it; it's also a relatively new dependency, as its KDE3 predecessor -kdelirc- was not part of kdeutils at the time. Technically the dependency chain is totally correct and weakening it wouldn't be a logical conclusion for these meta packages, but given the lirc is only useful, if you have special, non-standard hardware (an IR receiver and a remote to use it) a suggests might be more in order. kremotecontrol didn't exist in squeeze, only its predecessor kdelirc, which was a seperate source package and not part of kdeutils; it was only suggested by kdetv, no hard dependencies or recommends. Yes this one. I had a vague memory of lirc being installed for me with KDE but I wasn't sure I could trust my memory. Thank you for the apt-rdepends foo :) […] Pulling in the lirc (or inputlirc for that matter) package, which means the dæmon, without a strong indication that the user actually owns IR receivers/ transceivers and wants to use them is most likely a bug. lirc (or inputlirc) cannot do anything useful, unless properly configured, which means at least selecting the driver type (out of ~60 options - userspace and staging drivers, most of them can't be autoprobed), specifying the device node it should listen on (in many cases a custom udev rule is also needed, to get a stable event device symlink) and the remote button -- key event mapping is required.
Bug#702509: unattended-upgrades: does not run autonomously, even after it was enabled
control: -1 severity normal 2013/3/8 Arturo Moral amo...@gmail.com: This config was removed in version 0.79.5 and might not work at all: I'm currently using 0.79.4, therefore the config change does not affect me, right? You should not use it, 0.79.5 will migrate to testing on the following days. Anyway, my main issue is that the unattended upgrades don't run. If it would be only a config file problem, they would run but with no upgradable candidates. You didn't show that u-a doesn't work. From what we've seen so far it works as expected, maybe you need to investigate why Cron doesn't run?! Do you know for sure that there are packages to be upgraded? Running apt-get upgrade will tell you. If apt-get doesn't find packages to be upgraded, neither does u-a. Cheers -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698068: MySQL 5.5.30 does not fix CVE-2012-4414, what to do next?
Please refer to [1] as the rest of this message assumes the reader has read the log thus far. I have just now comitted MariaDB's test for CVE-2012-4414 to the SVN repo where we maintain mysql-5.5 unstable packaging. The package fails to build right now because this test fails. Lifting the test out of the commit is easy. To lift the fix out, is much more complicated. I know it can be done, because Percona did it in their branch. But I do not have the time to commit to such a delicate operation. So, we are left with some options: 1) Un-block unstable's 5.5.29 and let it proceed into testing, which will fix several other CVE's. This will introduce CVE-2012-4414. Its a lower priority fix, so this seems like a valid option if we are pressed for time. 2) Somebody step up and give us a patch for 5.5.30 which fixes CVE-2012-4414. There's probably a commit in percona's tree somewhere that can solve the issue with perhaps some fuzz to resolve. 3) Wait until 5.5.31 comes out, and pray that Oracle have actually fixed this security vulnerability. They've been releasing patch versions on a 2-3 month pace, so we should be able to expect 5.5.31 by late April at the latest. Its actually a good sign that the changelog for 5.5.31 [2] has nothing in it. The security fixes are never enumerated there due to Oracle's non-disclosure policy. We will end up shipping 5.5.31 in the security pocket anyway. This is as much FYI as halp! for the release team. Any advice is appreciated. Thank you [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=698068 [2] http://dev.mysql.com/doc/relnotes/mysql/5.5/en/news-5-5-31.html -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702574: marked as done (TYPO3-CORE-SA-2013-001: SQL Injection and Open Redirection in TYPO3 Core)
Your message dated Fri, 08 Mar 2013 17:32:45 +
with message-id e1ue19x-00060z...@franck.debian.org
and subject line Bug#702574: fixed in typo3-src 4.5.19+dfsg1-5
has caused the Debian Bug report #702574,
regarding TYPO3-CORE-SA-2013-001: SQL Injection and Open Redirection in TYPO3
Core
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
702574: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=702574
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
---BeginMessage---
Package: typo3-src
Severity: critical
Tags: security
It has been discovered that TYPO3 Core is susceptible to SQL Injection
and Open Redirection
Component Type: TYPO3 Core
Affected Versions: 4.5.0 up to 4.5.23, 4.6.0 up to 4.6.16, 4.7.0 up to
4.7.8 and 6.0.0 up to 6.0.2
Vulnerability Types: SQL Injection, Open Redirection
Overall Severity: High
Release Date: March 6, 2013
Vulnerable subcomponent: Extbase Framework
Vulnerability Type: SQL Injection
Severity: Critical
Suggested CVSS v2.0: AV:N/AC:M/Au:N/C:C/I:C/A:N/E:H/RL:O/RC:C
Problem Description: Failing to sanitize user input, the Extbase
database abstraction layer is susceptible to SQL Injection. TYPO3 sites
which have no Extbase extensions installed are not affected. Extbase
extensions are affected if they use the Query Object Model and relation
values are user generated input. (e.g. :
$query-contains('model.categories', $userProvidedValue) )
Note: It has been reported to the TYPO3 Security Team that this problem
is known and exploited in the wild.
Vulnerable subcomponent: Access tracking mechanism
Vulnerability Type: Open Redirection
Severity: Medium
Suggested CVSS v2.0: AV:N/AC:L/Au:N/C:N/I:P/A:N/E:H/RL:O/RC:C
Problem Description: Failing to validate user provided input, the access
tracking mechanism allows redirects to arbitrary URLs.
Important Notes: To fix this vulnerability, we had to break existing
behaviour of TYPO3 sites that use the access tracking mechanism (jumpurl
feature) to transform links to external sites. The link generation has
been changed to include a hash that is checked before redirecting to an
external URL. This means that old links that have been distributed (e.g.
by a newsletter) will not work any more. If you are using the jumpurl
feature you need to do the following:
lookup more information on
http://typo3.org/teams/security/security-bulletins/typo3-core/typo3-core-sa-2013-001/
--
MfG, Christian Welzel
GPG-Key: http://www.camlann.de/de/pgpkey.html
Fingerprint: 4F50 19BF 3346 36A6 CFA9 DBDC C268 6D24 70A1 AD15
---End Message---
---BeginMessage---
Source: typo3-src
Source-Version: 4.5.19+dfsg1-5
We believe that the bug you reported is fixed in the latest version of
typo3-src, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 702...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Christian Welzel gaw...@camlann.de (supplier of updated typo3-src package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@debian.org)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Fri, 08 Mar 2013 17:02:05 +0100
Source: typo3-src
Binary: typo3-src-4.5 typo3-database typo3-dummy typo3
Architecture: source all
Version: 4.5.19+dfsg1-5
Distribution: unstable
Urgency: low
Maintainer: Christian Welzel gaw...@camlann.de
Changed-By: Christian Welzel gaw...@camlann.de
Description:
typo3 - web content management system (meta)
typo3-database - web content management system (database)
typo3-dummy - web content management system (basic site structure)
typo3-src-4.5 - web content management system (core)
Closes: 702574
Changes:
typo3-src (4.5.19+dfsg1-5) unstable; urgency=low
.
* Added patch for TYPO3-SA-2013-001. (Closes: #702574)
* Set patch level version to -pl.4.5.25.
Checksums-Sha1:
560985208fca743574aeb29cf7902d1ca624a4d5 2056 typo3-src_4.5.19+dfsg1-5.dsc
b93098c7446b593b1977ad58e9bd07871661c8b2 391828
typo3-src_4.5.19+dfsg1-5.debian.tar.gz
1c16dd9e0768fa3238068571c8a3cd19647f8275 20071780
typo3-src-4.5_4.5.19+dfsg1-5_all.deb
577751e57c56ec3899a06a057a987f9832012226 281972
typo3-database_4.5.19+dfsg1-5_all.deb
62a00ff5b7595d9b1d1c52143f79a4adab48e0cb 289994
typo3-dummy_4.5.19+dfsg1-5_all.deb
Bug#702509: unattended-upgrades: does not run autonomously, even after it was enabled
Hey, Teodor, On Fri, Mar 8, 2013 at 6:09 PM, Teodor MICU mteo...@gmail.com wrote: control: -1 severity normal 2013/3/8 Arturo Moral amo...@gmail.com: This config was removed in version 0.79.5 and might not work at all: I'm currently using 0.79.4, therefore the config change does not affect me, right? You should not use it, 0.79.5 will migrate to testing on the following days. I'm using it because it's the current version in testing. It's not a personal choice and I will be happy upgrading to 0.79.5 when that time comes. Anyway, my main issue is that the unattended upgrades don't run. If it would be only a config file problem, they would run but with no upgradable candidates. You didn't show that u-a doesn't work. From what we've seen so far it works as expected, maybe you need to investigate why Cron doesn't run?! So far, cron is doing its job with the rest of the jobs. I did not find any reference about tweaking cron in unattended-upgrades documentation for making the package works. For me, if unattended-upgrades is not doing its daily check after being enabled and well configured, the package does not work properly. If I missed a final step after installing, enabling and configuring for making it work autonomously, please let me know. Do you know for sure that there are packages to be upgraded? Running apt-get upgrade will tell you. If apt-get doesn't find packages to be upgraded, neither does u-a. I've been doing the upgrades manually and there were several packages to upgrade since I installed and enabled unattended-upgrades. Anyway, I'm not having any issue on what updates or what doesn't. I should see a log file inside /var//log/unattended-upgrades/ with details on every day's check but the file didn't exist until I ran a --dry-run days after enabling. Cheers
Bug#702475: apache2: the itk MPM is underlinked: sys/capability.h symbols are not resolved
On Thu, Mar 07, 2013 at 12:55:39AM +0100, Arno Töll wrote: While testing the 2.4.4 upload I noticed the ITK MPM does not load anymore, because it is underlinked despite of -lcap being there and used. In 2.4.4-1 i386 build logs -lcap is not used for mod_mpm_itk.la. -- WBR, wRAR signature.asc Description: Digital signature
Processed: limit package to apache2, notfound 702475 in apache2/2.2.22-4, found 702475 in apache2/2.4.2-2
Processing commands for cont...@bugs.debian.org: limit package apache2 Limiting to bugs with field 'package' containing at least one of 'apache2' Limit currently set to 'package':'apache2' notfound 702475 apache2/2.2.22-4 Bug #702475 [apache2] apache2: the itk MPM is underlinked: sys/capability.h symbols are not resolved Ignoring request to alter found versions of bug #702475 to the same values previously set found 702475 apache2/2.4.2-2 Bug #702475 [apache2] apache2: the itk MPM is underlinked: sys/capability.h symbols are not resolved Marked as found in versions apache2/2.4.2-2. thanks Stopping processing here. Please contact me if you need assistance. -- 702475: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=702475 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processed: severity of 702509 is normal
Processing commands for cont...@bugs.debian.org: severity 702509 normal Bug #702509 [unattended-upgrades] unattended-upgrades: does not run autonomously, even after it was enabled Severity set to 'normal' from 'grave' thanks Stopping processing here. Please contact me if you need assistance. -- 702509: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=702509 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processed: Re: Bug#702525: ruby1.9.1: CVE-2013-1821: entity expansion DoS vulnerability in REXML
Processing control commands: tags -1 + patch Bug #702525 [src:ruby1.9.1] ruby1.9.1: CVE-2013-1821: entity expansion DoS vulnerability in REXML Ignoring request to alter tags of bug #702525 to the same tags previously set -- 702525: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=702525 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702525: ruby1.9.1: CVE-2013-1821: entity expansion DoS vulnerability in REXML
Control: tags -1 + patch
Hi
I propose the attached patch applied from upstream's svn. I can do a
NMU in case needed, but want first to have a second check on the
resulting package.
Regards,
Salvatore
diff -Nru ruby1.9.1-1.9.3.194/debian/changelog
ruby1.9.1-1.9.3.194/debian/changelog
--- ruby1.9.1-1.9.3.194/debian/changelog2013-02-23 15:29:56.0
+0100
+++ ruby1.9.1-1.9.3.194/debian/changelog2013-03-08 21:49:19.0
+0100
@@ -1,3 +1,14 @@
+ruby1.9.1 (1.9.3.194-8.1) unstable; urgency=high
+
+ * Non-maintainer upload.
+ * Add CVE-2013-1821.patch patch.
+CVE-2013-1821: Fix entity expansion DoS vulnerability in REXML. When
+reading text nodes from an XML document, the REXML parser could be
+coerced into allocating extremely large string objects which could
+consume all available memory on the system. (Closes: #702525)
+
+ -- Salvatore Bonaccorso car...@debian.org Fri, 08 Mar 2013 21:48:20 +0100
+
ruby1.9.1 (1.9.3.194-8) unstable; urgency=low
* ruby1.9.1: add Breaks: apt-listbugs ( 0.1.6) to avoid breaking the
diff -Nru ruby1.9.1-1.9.3.194/debian/patches/CVE-2013-1821.patch
ruby1.9.1-1.9.3.194/debian/patches/CVE-2013-1821.patch
--- ruby1.9.1-1.9.3.194/debian/patches/CVE-2013-1821.patch 1970-01-01
01:00:00.0 +0100
+++ ruby1.9.1-1.9.3.194/debian/patches/CVE-2013-1821.patch 2013-03-08
21:49:19.0 +0100
@@ -0,0 +1,110 @@
+Description: Fix entity expansion DoS vulnerability in REXML
+ CVE-2013-1821
+Origin: upstream,
http://svn.ruby-lang.org/cgi-bin/viewvc.cgi?view=revisionrevision=39384view=patch
+Bug-Debian: http://bugs.debian.org/702525
+Forwarded: not-needed
+Author: Salvatore Bonaccorso car...@debian.org
+Last-Update: 2013-03-08
+Applied-Upstream: yes
+
+--- a/lib/rexml/document.rb
b/lib/rexml/document.rb
+@@ -217,6 +217,18 @@
+ return @@entity_expansion_limit
+ end
+
++@@entity_expansion_text_limit = 10_240
++
++# Set the entity expansion limit. By default the limit is set to 10240.
++def Document::entity_expansion_text_limit=( val )
++ @@entity_expansion_text_limit = val
++end
++
++# Get the entity expansion limit. By default the limit is set to 1.
++def Document::entity_expansion_text_limit
++ return @@entity_expansion_text_limit
++end
++
+ attr_reader :entity_expansion_count
+
+ def record_entity_expansion
+--- a/lib/rexml/text.rb
b/lib/rexml/text.rb
+@@ -380,25 +380,35 @@
+
+ # Unescapes all possible entities
+ def Text::unnormalize( string, doctype=nil, filter=nil, illegal=nil )
++ sum = 0
+ string.gsub( /\r\n?/, \n ).gsub( REFERENCE ) {
+-ref = $
+-if ref[1] == ?#
+- if ref[2] == ?x
+-[ref[3...-1].to_i(16)].pack('U*')
+- else
+-[ref[2...-1].to_i].pack('U*')
+- end
+-elsif ref == 'amp;'
+- ''
+-elsif filter and filter.include?( ref[1...-1] )
+- ref
+-elsif doctype
+- doctype.entity( ref[1...-1] ) or ref
++s = Text.expand($, doctype, filter)
++if sum + s.bytesize Document.entity_expansion_text_limit
++ raise entity expansion has grown too large
+ else
+- entity_value = DocType::DEFAULT_ENTITIES[ ref[1...-1] ]
+- entity_value ? entity_value.value : ref
++ sum += s.bytesize
+ end
++s
+ }
+ end
++
++def Text.expand(ref, doctype, filter)
++ if ref[1] == ?#
++if ref[2] == ?x
++ [ref[3...-1].to_i(16)].pack('U*')
++else
++ [ref[2...-1].to_i].pack('U*')
++end
++ elsif ref == 'amp;'
++''
++ elsif filter and filter.include?( ref[1...-1] )
++ref
++ elsif doctype
++doctype.entity( ref[1...-1] ) or ref
++ else
++entity_value = DocType::DEFAULT_ENTITIES[ ref[1...-1] ]
++entity_value ? entity_value.value : ref
++ end
++end
+ end
+ end
+--- a/test/rexml/test_entity.rb
b/test/rexml/test_entity.rb
+@@ -104,6 +104,24 @@
+ assert_equal source, out
+ end
+
++ def test_entity_string_limit
++template = '!DOCTYPE bomb [ !ENTITY a ^ ] bomb$/bomb'
++len = 5120 # 5k per entity
++template.sub!(/\^/, B * len)
++
++# 10k is OK
++entities = 'a;' * 2 # 5k entity * 2 = 10k
++xmldoc = REXML::Document.new(template.sub(/\$/, entities))
++assert_equal(len * 2, xmldoc.root.text.bytesize)
++
++# above 10k explodes
++entities = 'a;' * 3 # 5k entity * 2 = 15k
++xmldoc = REXML::Document.new(template.sub(/\$/, entities))
++assert_raises(RuntimeError) do
++ xmldoc.root.text
++end
++ end
++
+ def test_raw
+ source = '!DOCTYPE foo [
+ !ENTITY ent replace
diff -Nru ruby1.9.1-1.9.3.194/debian/patches/series
ruby1.9.1-1.9.3.194/debian/patches/series
--- ruby1.9.1-1.9.3.194/debian/patches/series 2013-02-13 16:20:21.0
+0100
+++ ruby1.9.1-1.9.3.194/debian/patches/series
Bug#702606: openms: FTBFS due to truncated object files
Source: openms Version: 1.9.0-3 Severity: serious Justification: fails to build from source Builds of openms on several architectures (including i386 now that it's gotten past #702512 -- thanks for the quick fix there!) are failing with errors about truncated object files at various points. Could the linker somehow be trying to run before the compiler's finished? If so, running make in traditional sequential mode may be more reliable. At any rate, please do take a look. Thanks! -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698832: Solving the issue by recreating icons
Would creating similar icons and include it in the package solve this issue? I’m not sure I’m really qualified for that but I don’t see what else can be done. If creating icons would solve the issue, what licence would be best? Regards, -- Vincent Lhote signature.asc Description: This is a digitally signed message part
Bug#702609: pidgin-audacious: Not able to activate
Package: pidgin-audacious Version: 2.0.0-2 Severity: grave Justification: renders package unusable Dear Maintainer, when I try to activate the Pidgin-Audacious plugin in pidgin nothing happens. When I click on Plugin Details the following error message shows up: Error: undefined symbol: audacious_remote_is_playing Check the plugin website for an update. Regards, Christian -- System Information: Debian Release: 7.0 APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages pidgin-audacious depends on: ii libatk1.0-0 2.4.0-2 ii libaudcore1 3.2.4-1 ii libc6 2.13-38 ii libcairo2 1.12.2-3 ii libdbus-1-3 1.6.8-1 ii libdbus-glib-1-20.100.2-1 ii libfontconfig1 2.9.0-7.1 ii libfreetype62.4.9-1.1 ii libgdk-pixbuf2.0-0 2.26.1-1 ii libglib2.0-02.33.12+really2.32.4-5 ii libgtk2.0-0 2.24.10-2 ii libmcs1 0.7.2-2.1 ii libmowgli2 1.0.0-1 ii libpango1.0-0 1.30.0-1 ii pidgin 2.10.6-3 Versions of packages pidgin-audacious recommends: ii audacious 3.2.4-1 pidgin-audacious suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processed: your mail
Processing commands for cont...@bugs.debian.org:
found 702574 4.3.8-1
Bug #702574 {Done: Christian Welzel gaw...@camlann.de} [typo3-src]
TYPO3-CORE-SA-2013-001: SQL Injection and Open Redirection in TYPO3 Core
There is no source info for the package 'typo3-src' at version '4.3.8-1' with
architecture ''
Unable to make a source version for version '4.3.8-1'
Marked as found in versions 4.3.8-1.
thanks
Stopping processing here.
Please contact me if you need assistance.
--
702574: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=702574
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#701916: Kill local user processes on logout
Control: tags 701916 -pending +unreproducible I'm having trouble reproducing the problem on a fatclient... I've tried with icewm, LXDE, XFCE and GNOME, with a variety of applications open. None seem to linger after logout as a fatclient, and the homedir gets unmounted appropriately... Also tried with localapps, but couldn't reproduce the problem. Please provide more information about how to reproduce the problem when you get a chance! live well, vagrant -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processed: Re: Bug#701916: Kill local user processes on logout
Processing control commands: tags 701916 -pending +unreproducible Bug #701916 [ltsp-client-core] Kill local user processes on logout Removed tag(s) pending. Bug #701916 [ltsp-client-core] Kill local user processes on logout Added tag(s) unreproducible. -- 701916: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=701916 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processed: Re: Bug#701916: Kill local user processes on logout
Processing commands for cont...@bugs.debian.org: tags 701916 +moreinfo Bug #701916 [ltsp-client-core] Kill local user processes on logout Added tag(s) moreinfo. thanks Stopping processing here. Please contact me if you need assistance. -- 701916: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=701916 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#701185: marked as done (CVE-2013-0200: Insecure temporary files)
Your message dated Sat, 09 Mar 2013 01:03:25 +
with message-id e1ue8c5-ef...@franck.debian.org
and subject line Bug#701185: fixed in hplip 3.13.3-1
has caused the Debian Bug report #701185,
regarding CVE-2013-0200: Insecure temporary files
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
701185: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=701185
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
---BeginMessage---
Package: hplip
Severity: grave
Tags: security
Justification: user security hole
Several further insecurely handled temporary files were discovered by Red Hat:
https://www.redhat.com/archives/enterprise-watch-list/2013-February/msg00024.html
I've extracted the patch from the RHEL update, it's attached to this mail.
Cheers,
Moritz
diff -up hplip-3.12.4/prnt/hpcups/HPCupsFilter.cpp.CVE-2013-0200 hplip-3.12.4/prnt/hpcups/HPCupsFilter.cpp
--- hplip-3.12.4/prnt/hpcups/HPCupsFilter.cpp.CVE-2013-0200 2013-01-22 10:57:13.651460928 +
+++ hplip-3.12.4/prnt/hpcups/HPCupsFilter.cpp 2013-01-22 10:57:34.087541538 +
@@ -637,19 +637,22 @@ int HPCupsFilter::processRasterData(cups
{
charszFileName[32];
memset(szFileName, 0, sizeof(szFileName));
-snprintf (szFileName, sizeof(szFileName), /tmp/hpcupsfilterc_%d.bmp, current_page_number);
+snprintf (szFileName, sizeof(szFileName), /tmp/hpcupsfilterc_%d.bmp.XX, current_page_number);
if (cups_header.cupsColorSpace == CUPS_CSPACE_RGBW ||
cups_header.cupsColorSpace == CUPS_CSPACE_RGB)
{
-cfp = fopen (szFileName, w);
-chmod (szFileName, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
+ int fd = mkstemp (szFileName);
+ if (fd != -1)
+ cfp = fdopen (fd, w);
}
if (cups_header.cupsColorSpace == CUPS_CSPACE_RGBW ||
cups_header.cupsColorSpace == CUPS_CSPACE_K)
{
-szFileName[17] = 'k';
-kfp = fopen (szFileName, w);
-chmod (szFileName, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
+ int fd;
+ snprintf (szFileName, sizeof(szFileName), /tmp/hpcupsfilterk_%d.bmp.XX, current_page_number);
+ fd = mkstemp (szFileName);
+ if (fd != -1)
+ kfp = fdopen (fd, w);
}
WriteBMPHeader (cfp, cups_header.cupsWidth, cups_header.cupsHeight, COLOR_RASTER);
diff -up hplip-3.12.4/prnt/hpcups/SystemServices.cpp.CVE-2013-0200 hplip-3.12.4/prnt/hpcups/SystemServices.cpp
--- hplip-3.12.4/prnt/hpcups/SystemServices.cpp.CVE-2013-0200 2012-04-10 09:32:37.0 +0100
+++ hplip-3.12.4/prnt/hpcups/SystemServices.cpp 2013-01-22 10:57:34.088541545 +
@@ -36,10 +36,12 @@ SystemServices::SystemServices(int iLogL
m_fp = NULL;
if (iLogLevel SAVE_PCL_FILE)
{
+ int fd;
charfname[32];
-sprintf(fname, /tmp/hpcups_job%d.out, job_id);
-m_fp = fopen(fname, w);
-chmod(fname, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
+sprintf(fname, /tmp/hpcups_job%d.out.XX, job_id);
+ fd = mkstemp (fname);
+ if (fd != -1)
+ m_fp = fdopen(fd, w);
}
}
diff -up hplip-3.12.4/prnt/hpijs/hpijs.cpp.CVE-2013-0200 hplip-3.12.4/prnt/hpijs/hpijs.cpp
--- hplip-3.12.4/prnt/hpijs/hpijs.cpp.CVE-2013-0200 2013-01-22 10:57:12.219455275 +
+++ hplip-3.12.4/prnt/hpijs/hpijs.cpp 2013-01-22 10:57:34.089541549 +
@@ -96,13 +96,12 @@ void setLogLevel(UXServices *pSS)
if (pSS-m_iLogLevel SAVE_PCL_FILE)
{
+ int fd;
charszFileName[32];
- sprintf (szFileName, /tmp/hpijs_%d.out, getpid());
- pSS-outfp = fopen (szFileName, w);
- if (pSS-outfp)
- {
- chmod (szFileName, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
- }
+ sprintf (szFileName, /tmp/hpijs_%d.out.XX, getpid());
+ fd = mkstemp (szFileName);
+ if (fd != -1)
+ pSS-outfp = fdopen (fd, w);
}
}
diff -up hplip-3.12.4/prnt/hpps/hppsfilter.c.CVE-2013-0200 hplip-3.12.4/prnt/hpps/hppsfilter.c
--- hplip-3.12.4/prnt/hpps/hppsfilter.c.CVE-2013-0200 2012-04-10 09:32:37.0 +0100
+++ hplip-3.12.4/prnt/hpps/hppsfilter.c 2013-01-22 10:57:34.089541549 +
@@ -92,10 +92,12 @@ void open_dbg_outfile(char* szjob_id)
g_fp_outdbgps = NULL;
if (g_savepsfile SAVE_PS_FILE)
{
+ int fd;
charsfile_name[FILE_NAME_SIZE] = {0};
-sprintf(sfile_name, DBG_PSFILE, szjob_id);
-g_fp_outdbgps= fopen(sfile_name, w);
-chmod(sfile_name, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
+sprintf(sfile_name, DBG_PSFILE .XX, szjob_id);
+ fd = mkstemp (sfile_name);
+ if
Bug#700738: valgrind summary
On 2013-03-06 20:02:16, Antoine Beaupré wrote: So I ran the patched version under valgrind, which I am not familiar with at all so YMMV. I attach the output. Basically, what I see is one of those: ==3852== Conditional jump or move depends on uninitialised value(s) ==3852== Use of uninitialised value of size 8 ==3852== Syscall param rt_sigaction(act-sa_mask) points to uninitialised byte(s) This seems consistent with the original report of problems with the signal handler, in general, but I haven't dug much deeper yet. Those valgrind warnings can be fixed quite easily. valgrind is complaining because some members of ttyclock malloc'd in main and sigaction in init are read before they were initialized. For example, in line 70 it is checked if ttyclock-geo.x is zero, but ttyclock-geo.x has no well defined value at this point. To silence the warnings it should be enough to just run memset over the allocated memory: once for ttyclock after the first malloc in main and once for sig in init. Regards -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#702475: apache2: the itk MPM is underlinked: sys/capability.h symbols are not resolved
tags 702475 experimental notfound 702475 2.2.22-12 thanks On 08.03.2013 18:46, Andrey Rahmatullin wrote: On Thu, Mar 07, 2013 at 12:55:39AM +0100, Arno Töll wrote: While testing the 2.4.4 upload I noticed the ITK MPM does not load anymore, because it is underlinked despite of -lcap being there and used. In 2.4.4-1 i386 build logs -lcap is not used for mod_mpm_itk.la. ... but it is used for regular modules which are linked with apr. Looks like the (itk) MPM link command line ignores EXTRA_LIBS which contains -lcap. Looking to our older build logs, it looks itk was never linked with -lcap for 2.4. Sesse, do you want to fix that? Alternatively we could wait until 2.4.5 is released which might contain all patches you require for your most recent itk patch. That would allow us to build itk with apxs without patching the Apache source, possibly even in a separate source package. That might be worth a discussion as well. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Processed: Re: Bug#702475: apache2: the itk MPM is underlinked: sys/capability.h symbols are not resolved
Processing commands for cont...@bugs.debian.org: tags 702475 experimental Bug #702475 [apache2] apache2: the itk MPM is underlinked: sys/capability.h symbols are not resolved Added tag(s) experimental. notfound 702475 2.2.22-12 Bug #702475 [apache2] apache2: the itk MPM is underlinked: sys/capability.h symbols are not resolved Ignoring request to alter found versions of bug #702475 to the same values previously set thanks Stopping processing here. Please contact me if you need assistance. -- 702475: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=702475 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processed: bug 700738 is forwarded to https://github.com/carla-v/tty-clock/issues/1
Processing commands for cont...@bugs.debian.org: forwarded 700738 https://github.com/carla-v/tty-clock/issues/1 Bug #700738 [src:tty-clock] tty-clock: use-after-free and other unsafeties Set Bug forwarded-to-address to 'https://github.com/carla-v/tty-clock/issues/1'. thanks Stopping processing here. Please contact me if you need assistance. -- 700738: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700738 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#700738: valgrind summary
On 2013-03-08, Sebastian Ramacher wrote: On 2013-03-06 20:02:16, Antoine Beaupré wrote: So I ran the patched version under valgrind, which I am not familiar with at all so YMMV. I attach the output. Basically, what I see is one of those: ==3852== Conditional jump or move depends on uninitialised value(s) ==3852== Use of uninitialised value of size 8 ==3852== Syscall param rt_sigaction(act-sa_mask) points to uninitialised byte(s) This seems consistent with the original report of problems with the signal handler, in general, but I haven't dug much deeper yet. Those valgrind warnings can be fixed quite easily. valgrind is complaining because some members of ttyclock malloc'd in main and sigaction in init are read before they were initialized. For example, in line 70 it is checked if ttyclock-geo.x is zero, but ttyclock-geo.x has no well defined value at this point. To silence the warnings it should be enough to just run memset over the allocated memory: once for ttyclock after the first malloc in main and once for sig in init. So it turns out that there's a new upstream at github that worked a bit on the code, at the very least to cleanup the use-after-free problems. But there are other changes on that branch, including providing a manpage and fixing the readme, so that may not be fit for a release... Here's the diffstat: Makefile| 18 +- README | 24 ++-- tty-clock.1 | 121 + ttyclock.c | 93 ++--- ttyclock.h | 10 ++ 5 files changed, 240 insertions(+), 26 deletions(-) But almost all warnings are fixed in that 2.0 release out there, only those remain: ==14964== Syscall param rt_sigaction(act-sa_mask) points to uninitialised byte(s) ==14964==at 0x52AC60E: __libc_sigaction (sigaction.c:65) ==14964==by 0x401A6B: init (ttyclock.c:75) ==14964==by 0x4033D5: main (ttyclock.c:593) ==14964== Address 0x7fefffc18 is on thread 1's stack ==14964== ==14964== Syscall param rt_sigaction(act-sa_mask) points to uninitialised byte(s) ==14964==at 0x52AC60E: __libc_sigaction (sigaction.c:65) ==14964==by 0x401A84: init (ttyclock.c:76) ==14964==by 0x4033D5: main (ttyclock.c:593) ==14964== Address 0x7fefffc18 is on thread 1's stack ==14964== ==14964== Syscall param rt_sigaction(act-sa_mask) points to uninitialised byte(s) ==14964==at 0x52AC60E: __libc_sigaction (sigaction.c:65) ==14964==by 0x401A9D: init (ttyclock.c:77) ==14964==by 0x4033D5: main (ttyclock.c:593) ==14964== Address 0x7fefffc18 is on thread 1's stack ==14964== ==14964== Syscall param rt_sigaction(act-sa_mask) points to uninitialised byte(s) ==14964==at 0x52AC60E: __libc_sigaction (sigaction.c:65) ==14964==by 0x401AB6: init (ttyclock.c:78) ==14964==by 0x4033D5: main (ttyclock.c:593) ==14964== Address 0x7fefffc18 is on thread 1's stack I really wonder what to do at this point. I can certainly upload the 2.0 version to experimental to allow people to test this more thoroughly (but then again, it's just once C file, easy enough to test). But I don't feel those bugs are serious enough to block the Wheezy release. It doesn't seem those issues are critical enough to justify the serious severity, but maybe I am wrong. Would I would like to do is to upload a 1.1-2 with Bremner's patch and then request an unblock and close this bug report. Another option would be to upload upload 2.0-1 to sid and try to unblock *that*, but I feel this would take too much time from the release managers. Any opinions on the way to go forward here? Are the signal handlers warnings important enough to block the wheezy release? Also note that I have forwarded to our new upstream, we'll see what happens there.. Thanks for the feedback, A. -- Information is not knowledge Knowledge is not wisdom Wisdom is not truth - Frank Zappa pgpt3D8cAjTvb.pgp Description: PGP signature
Bug#700738: marked as done (tty-clock: use-after-free and other unsafeties)
Your message dated Sat, 09 Mar 2013 04:17:47 +
with message-id e1uebeb-0004kp...@franck.debian.org
and subject line Bug#700738: fixed in tty-clock 2.0-1
has caused the Debian Bug report #700738,
regarding tty-clock: use-after-free and other unsafeties
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
700738: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700738
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
---BeginMessage---
Source: tty-clock
Version: 1.1-1
Severity: serious
Justification: use-after-free and who knows what else
Hi!
Just saw ttyclock in the wanna-build Needs-Build list for m68k,
and thought to have a look at what it can do (comparison with
my /usr/share/doc/mksh/examples/uhr.gz script, for example),
compiled and run it under MirBSD (since I sat at it), SIGABRT.
Okay, what’s it do…
tg@blau:~ $ gdb --args ./ttyclock -i
GNU gdb 6.3.50.20050707
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as --host=i386-ecce-mirbsd10 --target=...
(gdb) r
Starting program: /home/tg/ttyclock -i
TTY-Clock 2 © by Martin Duquesnoy (xor...@gmail.com)
ttyclock in free(): error: bogus pointer (double free?) 0xdfdfdfdf
Program received signal SIGABRT, Aborted.
0x03e435e7 in kill () from /usr/lib/libc.so.41.10
(gdb) bt
#0 0x03e435e7 in kill () from /usr/lib/libc.so.41.10
#1 0x03e7aac8 in abort () from /usr/lib/libc.so.41.10
#2 0x03e637a0 in wrterror () from /usr/lib/libc.so.41.10
#3 0x03e64fcd in free () from /usr/lib/libc.so.41.10
#4 0x1c001f5d in main (argc=2, argv=0xcfbf9670) at ttyclock.c:482
(gdb) frame 4
#4 0x1c001f5d in main (argc=2, argv=0xcfbf9670) at ttyclock.c:482
482free(ttyclock-option.format);
(gdb) print *ttyclock
$1 = {running = 3755991007, bg = -538976289, option = {second = 3755991007,
twelve = 3755991007,
center = 3755991007, rebound = 3755991007, box = 3755991007,
format = 0xdfdfdfdf Address 0xdfdfdfdf out of bounds, color = -538976289,
delay = -538976289}, geo = {
x = -538976289, y = -538976289, w = -538976289, h = -538976289, a =
-538976289, b = -538976289}, date = {
hour = {3755991007, 3755991007}, minute = {3755991007, 3755991007}, second
= {3755991007, 3755991007},
datestr = '�' repeats 256 times}, tm = 0xdfdfdfdf, lt =
-2314885530818453537,
meridiem = 0xdfdfdfdf Address 0xdfdfdfdf out of bounds, framewin =
0xdfdfdfdf, datewin = 0xdfdfdfdf}
Argh. Okay. So omalloc found something… looking at the source:
479 case 'i':
480puts(TTY-Clock 2 © by Martin Duquesnoy
(xor...@gmail.com));
481free(ttyclock);
482free(ttyclock-option.format);
483exit(EXIT_SUCCESS);
This is an obvious use-after-free. The code is full with it.
I think that this program is not in shape for distribution.
Calling stdio (line 130), ncurses (line 119, 120, 129) and
other funny stuff in the signal handler is also almost cer‐
tainly broken. Even line 125 will not work, as the only data
type that can safely be accessed from a signal handler is of
the type “volatile sig_atomic_t”, which ttyclock-running is
not.
bye,
//mirabilos
--
Support mksh as /bin/sh and RoQA dash NOW!
‣ src:bash (257 (276) bugs: 0 RC, 178 (192) IN, 79 (84) MW, 0 (0) FP)
‣ src:dash (84 (98) bugs: 3 RC, 39 (43) IN, 42 (52) MW, 0 FP)
‣ src:mksh (1 bug: 0 RC, 0 IN, 1 MW, 0 FP)
http://qa.debian.org/data/bts/graphs/d/dash.png is pretty red, innit?
---End Message---
---BeginMessage---
Source: tty-clock
Source-Version: 2.0-1
We believe that the bug you reported is fixed in the latest version of
tty-clock, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 700...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Antoine Beaupré anar...@debian.org (supplier of updated tty-clock package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@debian.org)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Fri, 08 Mar 2013 22:30:45
Bug#702475: apache2: the itk MPM is underlinked: sys/capability.h symbols are not resolved
On Sat, Mar 09, 2013 at 03:58:15AM +0100, Arno Töll wrote: Alternatively we could wait until 2.4.5 is released which might contain all patches you require for your most recent itk patch. That would allow us to build itk with apxs without patching the Apache source, possibly even in a separate source package. That might be worth a discussion as well. Hi, I'm in Tokyo at the moment, and I'll be pretty spotty when it comes to email. However, my long-term plan is definitely to build mpm-itk out-of-tree and a separate source package; if the Debian Apache maintainers want to include the patches needed, I think this would make the lives easier for all of us :-) /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702525: ruby1.9.1: diff for NMU version 1.9.3.194-8.1
tags 702525 + pending
thanks
Dear maintainer,
I've prepared an NMU for ruby1.9.1 (versioned as 1.9.3.194-8.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.
Regards,
Salvatore
diff -Nru ruby1.9.1-1.9.3.194/debian/changelog ruby1.9.1-1.9.3.194/debian/changelog
--- ruby1.9.1-1.9.3.194/debian/changelog 2013-02-23 15:29:56.0 +0100
+++ ruby1.9.1-1.9.3.194/debian/changelog 2013-03-08 21:49:19.0 +0100
@@ -1,3 +1,14 @@
+ruby1.9.1 (1.9.3.194-8.1) unstable; urgency=high
+
+ * Non-maintainer upload.
+ * Add CVE-2013-1821.patch patch.
+CVE-2013-1821: Fix entity expansion DoS vulnerability in REXML. When
+reading text nodes from an XML document, the REXML parser could be
+coerced into allocating extremely large string objects which could
+consume all available memory on the system. (Closes: #702525)
+
+ -- Salvatore Bonaccorso car...@debian.org Fri, 08 Mar 2013 21:48:20 +0100
+
ruby1.9.1 (1.9.3.194-8) unstable; urgency=low
* ruby1.9.1: add Breaks: apt-listbugs ( 0.1.6) to avoid breaking the
diff -Nru ruby1.9.1-1.9.3.194/debian/patches/CVE-2013-1821.patch ruby1.9.1-1.9.3.194/debian/patches/CVE-2013-1821.patch
--- ruby1.9.1-1.9.3.194/debian/patches/CVE-2013-1821.patch 1970-01-01 01:00:00.0 +0100
+++ ruby1.9.1-1.9.3.194/debian/patches/CVE-2013-1821.patch 2013-03-08 21:49:19.0 +0100
@@ -0,0 +1,110 @@
+Description: Fix entity expansion DoS vulnerability in REXML
+ CVE-2013-1821
+Origin: upstream, http://svn.ruby-lang.org/cgi-bin/viewvc.cgi?view=revisionrevision=39384view=patch
+Bug-Debian: http://bugs.debian.org/702525
+Forwarded: not-needed
+Author: Salvatore Bonaccorso car...@debian.org
+Last-Update: 2013-03-08
+Applied-Upstream: yes
+
+--- a/lib/rexml/document.rb
b/lib/rexml/document.rb
+@@ -217,6 +217,18 @@
+ return @@entity_expansion_limit
+ end
+
++@@entity_expansion_text_limit = 10_240
++
++# Set the entity expansion limit. By default the limit is set to 10240.
++def Document::entity_expansion_text_limit=( val )
++ @@entity_expansion_text_limit = val
++end
++
++# Get the entity expansion limit. By default the limit is set to 1.
++def Document::entity_expansion_text_limit
++ return @@entity_expansion_text_limit
++end
++
+ attr_reader :entity_expansion_count
+
+ def record_entity_expansion
+--- a/lib/rexml/text.rb
b/lib/rexml/text.rb
+@@ -380,25 +380,35 @@
+
+ # Unescapes all possible entities
+ def Text::unnormalize( string, doctype=nil, filter=nil, illegal=nil )
++ sum = 0
+ string.gsub( /\r\n?/, \n ).gsub( REFERENCE ) {
+-ref = $
+-if ref[1] == ?#
+- if ref[2] == ?x
+-[ref[3...-1].to_i(16)].pack('U*')
+- else
+-[ref[2...-1].to_i].pack('U*')
+- end
+-elsif ref == 'amp;'
+- ''
+-elsif filter and filter.include?( ref[1...-1] )
+- ref
+-elsif doctype
+- doctype.entity( ref[1...-1] ) or ref
++s = Text.expand($, doctype, filter)
++if sum + s.bytesize Document.entity_expansion_text_limit
++ raise entity expansion has grown too large
+ else
+- entity_value = DocType::DEFAULT_ENTITIES[ ref[1...-1] ]
+- entity_value ? entity_value.value : ref
++ sum += s.bytesize
+ end
++s
+ }
+ end
++
++def Text.expand(ref, doctype, filter)
++ if ref[1] == ?#
++if ref[2] == ?x
++ [ref[3...-1].to_i(16)].pack('U*')
++else
++ [ref[2...-1].to_i].pack('U*')
++end
++ elsif ref == 'amp;'
++''
++ elsif filter and filter.include?( ref[1...-1] )
++ref
++ elsif doctype
++doctype.entity( ref[1...-1] ) or ref
++ else
++entity_value = DocType::DEFAULT_ENTITIES[ ref[1...-1] ]
++entity_value ? entity_value.value : ref
++ end
++end
+ end
+ end
+--- a/test/rexml/test_entity.rb
b/test/rexml/test_entity.rb
+@@ -104,6 +104,24 @@
+ assert_equal source, out
+ end
+
++ def test_entity_string_limit
++template = '!DOCTYPE bomb [ !ENTITY a ^ ] bomb$/bomb'
++len = 5120 # 5k per entity
++template.sub!(/\^/, B * len)
++
++# 10k is OK
++entities = 'a;' * 2 # 5k entity * 2 = 10k
++xmldoc = REXML::Document.new(template.sub(/\$/, entities))
++assert_equal(len * 2, xmldoc.root.text.bytesize)
++
++# above 10k explodes
++entities = 'a;' * 3 # 5k entity * 2 = 15k
++xmldoc = REXML::Document.new(template.sub(/\$/, entities))
++assert_raises(RuntimeError) do
++ xmldoc.root.text
++end
++ end
++
+ def test_raw
+ source = '!DOCTYPE foo [
+ !ENTITY ent replace
diff -Nru ruby1.9.1-1.9.3.194/debian/patches/series ruby1.9.1-1.9.3.194/debian/patches/series
--- ruby1.9.1-1.9.3.194/debian/patches/series 2013-02-13 16:20:21.0 +0100
+++ ruby1.9.1-1.9.3.194/debian/patches/series 2013-03-08
Processed: ruby1.9.1: diff for NMU version 1.9.3.194-8.1
Processing commands for cont...@bugs.debian.org: tags 702525 + pending Bug #702525 [src:ruby1.9.1] ruby1.9.1: CVE-2013-1821: entity expansion DoS vulnerability in REXML Added tag(s) pending. thanks Stopping processing here. Please contact me if you need assistance. -- 702525: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=702525 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
