Bug#757858: ejabberd: Upgrade from 2.1.x to 14.05 causes inconsistent conf of Mnesia db in /etc/default/ejabberd
Package: ejabberd Version: 14.05-1~experimental2 Severity: grave Hi folks, when upgrading from 2.1.x to 14.05 the configuration of the Mnesia database is not properly updated. While older versions used ejabberd@$(hostname) for the EJABBERD_NODE it is ejabberd@localhost for the most recent one. This change is not reflected during the upgrade and causes the upgraded server to fail to start (with meaningless erlang error messages worth submitting to NIST as a new form of random bitstring generation - can't be worse than DualEC DRBG). Updating /etc/default/ejabberd to use the old value of ejabberd@$(hostname) for the EJABBERD_NODE setting solves the issue. Kind regards, BenBE. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (900, 'testing'), (800, 'stable'), (750, 'experimental'), (700, 'unstable'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 3.14-1-amd64 (SMP w/8 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 ejabberd depends on: ii adduser3.113+nmu3 ii debconf [debconf-2.0] 1.5.53 ii erlang-asn11:17.1-dfsg-4 ii erlang-base1:17.1-dfsg-4 ii erlang-crypto 1:17.1-dfsg-4 ii erlang-dev 1:17.1-dfsg-4 ii erlang-eunit 1:17.1-dfsg-4 ii erlang-inets 1:17.1-dfsg-4 ii erlang-jiffy 0.8.5+dfsg-1 ii erlang-lager 2.0.3-1 ii erlang-mnesia 1:17.1-dfsg-4 ii erlang-p1-cache-tab0.2014.04.30-1 ii erlang-p1-iconv0.2014.04.30-1 ii erlang-p1-mysql0.2014.03.10-2 ii erlang-p1-pam 0.2014.05.05-1 ii erlang-p1-pgsql0.2014.04.30-1 ii erlang-p1-sip 0.2014.06.12-1 ii erlang-p1-stringprep 0.2013.12.09-3 ii erlang-p1-stun 0.2014.05.08-1 ii erlang-p1-tls 0.2014.05.06-1 ii erlang-p1-xml 0.2014.07.02-1 ii erlang-p1-yaml 0.2014.06.11-1 ii erlang-p1-zlib 0.2014.05.06-1 ii erlang-parsetools 1:17.1-dfsg-4 ii erlang-ssl 1:17.1-dfsg-4 ii erlang-xmlrpc 0.2014.03.17-2 ii openssl1.0.1h-1benbe1 ii ucf3.0030 ejabberd recommends no packages. Versions of packages ejabberd suggests: ii imagemagick 8:6.7.7.10+dfsg-4 ii libunix-syslog-perl 1.1-2+b3 -- Configuration Files: /etc/default/ejabberd changed [not included] -- debconf information excluded -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751737: Package overwrites files from libssh2-php
Package: php5-ssh2 Version: 0.12-2 Severity: serious When upgrading from libssh2-php the package does not conflict on the package and thus dpkg tries to install libssh2-php and php5-ssh2 at the same time. Please add a proper stanza to the dependencies to indicate that php5-ssh2 superseeds libssh2-php and upgrade works more smoothly. Kind regards, Benny Baumann -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (900, 'testing'), (800, 'stable'), (750, 'experimental'), (700, 'unstable'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 3.14-1-amd64 (SMP w/8 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 php5-ssh2 depends on: ii libc6 2.19-1 ii libssh2-1 1.4.3-3 ii php-pear 5.6.0~beta4+dfsg-3 ii php5-common [phpapi-20131226] 5.6.0~beta4+dfsg-3 php5-ssh2 recommends no packages. php5-ssh2 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#748495: closed by Daniel Baumann daniel.baum...@progress-technologies.net (reply to daniel.baum...@progress-technologies.net) (Re: Missing required dependencies)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi Daniel, Am 21.05.2014 12:55, schrieb Daniel Baumann: On 05/19/2014 09:40 AM, Benny Baumann wrote: Even then you should make sure you are recommending the correct version (python3 = 3.3) which currently is not the case. there is no such thing as versioned recommends. Then it should be hinted in other places that this is necessary. Furthermore when running basic commands (and starting a container really IS basic) doesn't work then it makes this package unuseable for many people - despite this only appearing in one sub-command. you're confusing the convenience wrapper /usr/bin/lxc from lxc-stuff with /usr/bin/lxc-* from lxc. Actually: No, I'm not. This bug was filed against lxc-stuff which IS broken as you so so yourself just below. while it's true that the wrapper /usr/bin/lxc in lxc-stuff is useless without pythong (since it calls lxc-ls, which is python), the wrapper is only one part within lxc-stuff and thus doesn't make lxc-stuff unusuable. the 'basic commands' that you're refering to are all accessible/usable by calling /usr/bin/lxc-* from lxc itself. Which makes lxc-stuff kinda useless - and thus the bug report on lxc-stuff requiring python3 (= 3.3). Kind regards, Benny Baumann. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCgAGBQJTfPOXAAoJEPHTXLno4S6txLMQAIa6WlpGHYHJh6sHDBLRFasW Jq0PMuEMsVTpuvn/lcTuptL7xvFlYV10fMEg2670e9V6VrPYbjmg8G0p9SFziU4C Z1fGZbXe3BHW66Cor67nf/UKjqI8u58hFuJznZn0cmvoCYNj6K3BLRrGO3zZjfRv vWclzUCUWFjBXkelF2IGLD3b6MtPYzKm5ryTjOT4B4zlYCZ1/xlKkeOn6/dIljuB r0VhmyMtqiBi0zZ14l/LxOh6V88yYfgD0bJC02pjZdfDo0h2JYXy4RpCE24qr63w HJOZLtW5p9abJ6pjbGKcYe9DA8s7gFOLVVBUFsyyl0pCXSNZurpylBfwGMDWle9K zGO+aP+4HJl/LpAS41DLv0ykOHyD2dFhLJR2CT/uG2iOBsbluwyohyGy7n5I/2eb 89z41m2h/vVWCAvowEVCH8eqtOoY3tP8FVXV84e/UynXffD5iACPAMnlKRp3h1Rs +wshbquH80qk3ubiQpfBq4ym09Jjn/tzx87cOPmSPWK1LpqtgyOAhi01zWgUM2jk dVQVA253Gb4lz5BPddsI2v0pkCIXQ6iVbe8oulFDIbo7+FuZ66HlcWVfwyhvg8We 3ulpgk70ad9yV0EwlLZvRLkqToP3DeTUzINHFghkx/aVVmg2ur31gpOJOBGlx9QY JLxE51Lye0sDz+vHKi1P =/2zt -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748495: closed by Daniel Baumann daniel.baum...@progress-technologies.net (reply to daniel.baum...@progress-technologies.net) (Re: Missing required dependencies)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Even then you should make sure you are recommending the correct version (python3 = 3.3) which currently is not the case. Furthermore when running basic commands (and starting a container really IS basic) doesn't work then it makes this package unuseable for many people - despite this only appearing in one sub-command. Kind regards, Benny Baumann -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCgAGBQJTebVpAAoJEPHTXLno4S6t4soP/RyyKSxgAWnt0FrDsn7wPl2T FdtoDUi1x9lVVAxgH51a8sjE5x5P+oiHLU2m82Hvs+JMpuzuJZ0uWkLOQmBbflGH 2vdOiXFCqX97qlplgyOZfl9MtBd//pcxFpeo+4QNsJuIcvn49YqqaJKxTwyWeVtd zDsbirG9/boT0WsX5QG1SNqkRkZAhhh+Sx4kVIuBDciRmA98luD82GnZafqBk9eT WgJJ1jpLGPwyxNP4+2mkTX6/yv453fpbMDUiOfB7OkZDYdSV6vPTFa7KLH6bmTHQ 0zq3VddsskgmKsAV+8cR4LbD+DTKIzH2CaNa8gXjQVuYkh04JOFhmb1e9bmufTp6 4uXBvK5CDbqu7yyRNKs7wRDSYL3LbyZnVJ04z3I2alWT6KtVSPH3j9U8sY/csP5h O1dD7ppGjvKBfMQAMRUfxD3dHM4kxrd5PTIQYuW3KWSJCIKIn/yjl/J0/MtFKgZB uh8tA6qyVt2Y6H+PLDUQe1P6f5VZ6L2bgcYtCLAsgVGB3BBZyDyB3uA+kqLubKTV qX56Z1jBNK9EpqCIpROEEbrH6WPOzZKoRvUpzlUuIPENsTP2jgVmc+tShZEMuJ7k 3mtiJZemOPcOMivsr/qsinYn/sLctyxjF0hGj1TpaTJU3Kzc5AfpViBkoMvHtqwi 8L8bYg9yIg07QEatQRuT =wEjI -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748495: Acknowledgement (Missing required dependencies)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, The issue seems to go away when python3.3 or newer is installed. Thus having python3 (= 3.3) as a dependency (and not only recommendation) should fix those issues. Kind regards, Benny Baumann. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCgAGBQJTeJEqAAoJEPHTXLno4S6th7sP/jxYJg/tv5YAfLSK1XKhOd1E p468ozka+xl1Py5QXkxwxnF8O8WXoiWd919XYThQNqvUbsKC7YD8ESKVxneP8gKe NeGYK2z1bzW5Ln2QQqwJHDyejVh2zPd/wOnFyPiH7MUqJwoGAJsG/Y9BJksa07Gd 4EZNUWm+DUG86gALVSCbQONxH/Szgzo2l1bInAz0ESbo65wV/k0N3f2KVxjSCVY2 74DWwAb+yUQq2QOyJWgvMFbIKIUM4ym20rU1IjnVxwaycM4hzWlqsSSZgGrVr22H lvsYVbIF6PHtW3CkzAUIqJKtMDlUuO4tdrmBnddd8ba5xNVDZ8cgvtxKVWqq5w6k qEYAyWocrs6FaseN5iAQXOTpqzy2p6Czh6WzlYmpgxbJGOM3Pk8pYUSZxTCkD6qr 0NDKUpGuPJ1RoIO81NiWLVggZsWLnJBF5+hKEfvqdHRQBSPaI81pTA4qFzJL/srE LaR9i5bEmoToK5Zch5R9+ETocSLcsL1G05Z2yTNh7AR3NwhG2kAc/MXqEk0v9mTC AGoaz3uw0IG6T8MY/7uS8AHfUbIUvgW2I+vAj0vU6WHioCQWuKgGjE/099A5T5dV abzXDzXS3Ab5jVae7PNym+H7yn4VRklLF5/ZtOIhxPCRarY0JFx/v5AhGKzuOapG XsMm+B6UNDBup2M61vMS =g4Mo -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748495: Missing required dependencies
Package: lxc-stuff Version: 1.0.3-1 Severity: serious Hi, When recommended packages are not installed by default the package fails to find at least the following dependencies: - python3 If those are not installed lxc-stuff fails to execute even simple things like lxc start container -d Even after pulling those additional dependencies I run into [1]. Kind regards, Benny Baumann [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745418 -- System Information: Debian Release: wheezy/stable APT prefers stable APT policy: (900, 'stable'), (800, 'testing'), (750, 'unstable'), (700, 'experimental'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 3.13-1-amd64 (SMP w/8 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 lxc-stuff depends on: ii debconf [debconf-2.0] 1.5.53 ii lxc1.0.3-1 Versions of packages lxc-stuff recommends: ii debootstrap 1.0.60 pn irkernone Versions of packages lxc-stuff suggests: ii rsync 3.0.9-4 -- debconf information excluded -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#747666: Redefined macro messages scrolling by when compiling exhaust console backlog
Package: opensmtpd
Severity: serious
Tags: upstream patch
Justification: fails to build from source
When building this package a shitload of repeated warnings about a redefined
macro scroll by exhausting my precious console backlog unnecessarily.
The attached patch fixes this issue.
Kind regards,
Benny Baumann
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (900, 'testing'), (800, 'stable'), (750, 'experimental'), (700,
'unstable'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.13-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Description: Removes a shitload of stupid warnings due to redefining some macro unnecessarily
Author: Benny Baumann be...@geshi.org
---
The information above should follow the Patch Tagging Guidelines, please
checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:
Origin: other, url of original patch
Bug: url in upstream bugtracker
Bug-Debian: http://bugs.debian.org/bugnumber
Bug-Ubuntu: https://launchpad.net/bugs/bugnumber
Forwarded: no|not-needed|url proving that it has been forwarded
Reviewed-By: name and email of someone who approved the patch
Last-Update: -MM-DD
--- opensmtpd-5.4.1p1.orig/openbsd-compat/defines.h
+++ opensmtpd-5.4.1p1/openbsd-compat/defines.h
@@ -373,13 +373,13 @@ struct winsize {
#endif
/* user may have set a different path */
-#if defined(_PATH_MAILDIR) defined(MAIL_DIRECTORY)
+#if !defined(_PATH_MAILDIR) defined(MAILDIR)
# define _PATH_MAILDIR MAILDIR
-#endif /* defined(_PATH_MAILDIR) defined(MAIL_DIRECTORY) */
+#endif /* !defined(_PATH_MAILDIR) defined(MAIL_DIRECTORY) */
-#ifdef MAIL_DIRECTORY
+#if !defined(_PATH_MAILDIR) defined(MAIL_DIRECTORY)
# define _PATH_MAILDIR MAIL_DIRECTORY
-#endif
+#endif /* !defined(_PATH_MAILDIR) defined(MAIL_DIRECTORY) */
#ifdef MAILDIR
# undef MAILDIR
Bug#747673: Horrid default cipher settings without option to adjust them to sane values
Package: ejabberd Version: 2.1.11-1 Severity: grave Tags: security When setting up ejabberd with a default configuration it allows only connections with a weak SSL configuration - if this is even configured: 1. By default ejabberd allows SSLv3 which is broken in various ways and thus should no longer be used. 2. By default ejabberd uses weak cipher suites that make use of weak primitives like DES, RC2, RC4, MD5, export ciphers. 3. By default ejabberd does not provide ANY ciphers that make use of forward secrecy and thus jeopardizes the communication of users that crossed this server in case of a private key compromise. 4. Most importantly ejabberd does not provide any way to adjust the accepted security parameters (acceptable protocol versions, cipher string, cipher ordering, used ECC curves, used ECDHE/DHE parameters) Please make sure that a default configuration can be configured to use strong cryptography, using non-broken primitives and does so by default. Kind regards, Benny Baumann P.S.: By courtesy of #747453. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (900, 'testing'), (800, 'stable'), (750, 'experimental'), (700, 'unstable'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 3.13-1-amd64 (SMP w/8 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 ejabberd depends on: ii adduser3.113+nmu3 ii debconf [debconf-2.0] 1.5.53 ii erlang-asn11:17.0-dfsg-1 ii erlang-base [erlang-abi-15.b] 1:17.0-dfsg-1 ii erlang-crypto 1:17.0-dfsg-1 ii erlang-inets 1:17.0-dfsg-1 ii erlang-mnesia 1:17.0-dfsg-1 ii erlang-odbc1:17.0-dfsg-1 ii erlang-public-key 1:17.0-dfsg-1 ii erlang-ssl 1:17.0-dfsg-1 ii erlang-syntax-tools1:17.0-dfsg-1 ii libc6 2.18-5 ii libexpat1 2.1.0-4 ii libpam0g 1.1.8-3 ii libssl1.0.01.0.1g-3 ii openssl1.0.1g-3 ii ucf3.0028 ii zlib1g 1:1.2.8.dfsg-1 ejabberd recommends no packages. Versions of packages ejabberd suggests: ii imagemagick 8:6.7.7.10+dfsg-1 ii libunix-syslog-perl 1.1-2+b3 -- debconf information excluded -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#747471: libnss: Arbitrary key size limitation for client certificate authenticaton causing out-of-memory error
Source: iceweasel Severity: critical Tags: security upstream When using client certificate authentication with client certificates with keys of 4097 bit RSA or larger you always get a diagnostic from the SSL layer saying that no memory was available which is funny because usinga key of the same size for the SSL server works just fine. Also using a 4095 bit RSA client certificate works just fine as well. This breaks security in system where such keys are used and thus should be considered serious misbehaviour as cryptographic systems MUST NOT include an arbitrary limits on the key size of used cryptographic parameters. Please either remove this restriction completely or raise this to a much more sane value that is not limitting casually-paranoid configurations which use keys like 8192 Bit RSA for client authentication. A suggested increase could be 65536 Bit RSA, but better remove this limitation completely as it causes no real benefit. Furthermore RSA 8192 and up to RSA 16384 has to be considered as it corresponds roughly to 192-256 bit symmetric key sizes and thus properly configured systems enforcing 256 bit symmetric cryptography will also enforce asymmetric keys larger than 4096 bit for RSA or similarly for DSA and ECDSA. Kind regards, Benny Baumann -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (900, 'testing'), (800, 'stable'), (750, 'experimental'), (700, 'unstable'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 3.13-1-amd64 (SMP w/8 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#747453: Arbitrary key size limitations causing hard-to-diagnose problems when establishing a connection
Source: openssl Severity: critical Tags: security patch OpenSSL contains a set of arbitrary limitations on the size of accepted key parameters that make unrelated software fail to establish secure connections. The problem was found while debugging a XMPP s2s connection issue where two servers with long certificate keys (8192 Bit RSA) failed to establish a secure connection because OpenSSL rejected the handshake. The attached two patches fix the following issues: 1. Remove the restriction on DSA/DHE parameters to allow for arbitrary size 2. Increase the maximum allowed size for transmitted (client/server) keys from 516 byte (e.g. 4096 bit RSA) to 8200 byte (e.g. 65536 bit RSA) The first issue was found with a server using GnuTLS that used DH parameters with 13337 bits for negotiating the session key. While a website test succeeded in determining the cipher configuration it failed to negotiate a session key and did not provide any reasonable error message back to the user. As the issue depended on the ciphers offered by the client a real client like a webbrowser would not be able to gracefully fall back to some other algorithm. Thus the only workaround would be to use no encryption which would be the worst of all alternatives. The second issue was found while debugging issues with two ejabberd instances that both used certificates with 8192 bit RSA. While both servers could correctly determine the opposite's server's connection parameters (using provided SRV records) and properly established a cleartext connection they unexpectedly and without proper diagnosis terminated the SSL connection after negotiating to upgrade to STARTTLS. After both parties sent their certificates the connection was suddently terminated without even providing a SSL fatal error alert - thus no useful information could be provided by the application layer. Only after increasing the maximum size for key parameters were both servers able to connect to each other. This once again demonstrates that you MUST NOT introduce statically compiled-in magic numbers to place arbitrary limits on the size of used parameters. Furthermore it should be noted that the parameters used are neither very large, nor do they require excessive processing power (about 1-2 seconds for one handshake on average). This might not be an option for everybody but is well within parameters that are to be expected in casually-paranoid setups. Please apply both patches ASAP and forward them to be included upstream. Kind regards, Benny Baumann -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (900, 'testing'), (800, 'stable'), (750, 'experimental'), (700, 'unstable'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 3.13-1-amd64 (SMP w/8 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- no debconf informationn Description: Increase the maximum size allowed for client/server certificate packages on the wire Author: Benny Baumann be...@geshi.org --- The information above should follow the Patch Tagging Guidelines, please checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here are templates for supplementary fields that you might want to add: Origin: vendor|upstream|other, url of original patch Bug: url in upstream bugtracker Bug-Debian: http://bugs.debian.org/bugnumber Bug-Ubuntu: https://launchpad.net/bugs/bugnumber Forwarded: no|not-needed|url proving that it has been forwarded Reviewed-By: name and email of someone who approved the patch Last-Update: -MM-DD --- openssl-1.0.1e.orig/ssl/s3_srvr.c +++ openssl-1.0.1e/ssl/s3_srvr.c @@ -2926,7 +2926,7 @@ int ssl3_get_cert_verify(SSL *s) SSL3_ST_SR_CERT_VRFY_A, SSL3_ST_SR_CERT_VRFY_B, -1, - 516, /* Enough for 4096 bit RSA key with TLS v1.2 */ + 8200, /* Enough for 65536 bit RSA key with TLS v1.2 */ ok); if (!ok) return((int)n); Description: Remove DSA/DH keysize restrictions Author: Benny Baumann be...@geshi.org --- The information above should follow the Patch Tagging Guidelines, please checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here are templates for supplementary fields that you might want to add: Origin: vendor|upstream|other, url of original patch Bug: url in upstream bugtracker Bug-Debian: http://bugs.debian.org/bugnumber Bug-Ubuntu: https://launchpad.net/bugs/bugnumber Forwarded: no|not-needed|url proving that it has been forwarded Reviewed-By: name and email of someone who approved the patch Last-Update: -MM-DD --- openssl-1.0.1e.orig/crypto/dsa/dsa.h +++ openssl-1.0.1e/crypto/dsa/dsa.h @@ -84,10 +84,6 @@ #endif #endif -#ifndef OPENSSL_DSA_MAX_MODULUS_BITS -# define OPENSSL_DSA_MAX_MODULUS_BITS 1 -#endif - #define DSA_FLAG_CACHE_MONT_P 0x01 #define DSA_FLAG_NO_EXP_CONSTTIME 0x02 /* new with 0.9.7h; the built-in DSA * implementation now uses constant time
Bug#702489: Install dependency linux-kbuild-3.8 nowhere to be found
Package: linux-headers-3.8-trunk-amd64 Severity: grave Try installing the linux-headers-3.8-trunk-all package which fails due to this unmet dependency. Please build it properly as creation of custom kernel modules isn't possible otherwise. Regards, BenBE. -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (900, 'testing'), (800, 'stable'), (700, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.7.0-1-amd64 (SMP w/8 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#671690: is it still the case that libgamin0 makes courier non-functional
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi I can confirm this. Haven't noticed any issues recently with the current versions. Regards, BenBE. Am 07.01.2013 20:24, schrieb gregor herrmann: On Tue, 01 Jan 2013 14:48:02 -0500, Yaroslav Halchenko wrote: I haven't heard any bad report after 0.1.10-4.1 was uploaded... not sure about this specific issue, but I would vote just to consider it closed as well, unless there is an explicit confirmation that courier still experiences problems. FWIW -- I am also running courier-imap from squeeze (4.8.0-3) with libgamin0 0.1.10-4.1 -- and haven't had any problems FWIW: I've installed libgamin0 on a wheezy system last Friday and haven't heard any user complaints yet. # dpkg -l courier* libgamin0 | grep ^ii ii courier-authdaemon 0.63.0-6+b1 amd64 Courier authentication daemon ii courier-authlib 0.63.0-6+b1 amd64 Courier authentication library ii courier-authlib-userdb 0.63.0-6+b1 amd64 userdb support for the Courier authentication library ii courier-base 0.68.2-1 amd64 Courier mail server - base system ii courier-doc 0.68.2-1 all Courier mail server - additional documentation ii courier-imap 4.10.0-20120615-1 amd64 Courier mail server - IMAP server ii courier-imap-ssl 4.10.0-20120615-1 amd64 Courier mail server - IMAP over SSL ii courier-pop 0.68.2-1 amd64 Courier mail server - POP3 server ii courier-pop-ssl 0.68.2-1 amd64 Courier mail server - POP3 over SSL ii courier-ssl 0.68.2-1 amd64 Courier mail server - SSL/TLS Support ii libgamin0 0.1.10-4.1 amd64 Client library for the gamin file and directory monitoring system So, closing this bug with 0.1.10-4.1 also sounds reasonable to me. Cheers, gregor -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBAgAGBQJQ6yb6AAoJEPHTXLno4S6tOwMQAJujwMEkW/CRzHzqF83a6YvR xZ9C6NJiNJ5vgETSW9jg8IQ6m0VJ3GFOajcaqopmr67QvfF4BJkA+GgMRCYjkmJR +2JZ2+WtWgIWMqXDwvMqaiQwG4rBHCyl41TLFwsB80rQo6xQgCOk8zM5esg4KwxZ LvUecb4aHXlLSJuh5YgPfrIYQnx9Zo119I8nFeYHB5IIkyC8hWs1DtJn33VtqhYf mhsl9cxgPCQQC9bigsHAlzZe8A8cMrcUbXFgsy3bigGM7rOobkodA4wSJdu8Mp9y dC/2ZMohnrhuo+1FU5kKdwKsJ5wMJ2KPxPSNeBK+JpROl1Yps8Q7i42UEDgJ1rR9 sYvDILICdurz9VUROykgMxECqJwpmrOuVVzQ7cvK/OARB5adRDkCJaDCFssIfiR/ nAEXKTRpvXNQQwMsw0czKwJnVG+RIsfYH/xzY/k64rxurb9mAiXiP5Yz/2BeSpou 6YJybiJ633CjD/WM31+xmoDpNo6lX5daeVlDgTgxl9Vru4SUuAnMfVeDZwGhQiiR Fc7un+cmaq+qKKtAOpPJ5Bgcay1I+SHxZgl0ArXxmz368N5W1JKuC/OqWxokPZ6/ iJHeTd1c25jbEGEO0vYsLilnLS39lWGryNSxP0yT8MgpFg65P8DYdmZseHAEVZxA SKzWgNmrjJon5x3zylnH =c5ys -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#685323: Re: Bug#685324: Local File Inclusion Vulnerability in contrib script
Dear Steven, Am 20.08.2012 05:12, schrieb Steven Chamberlain: tags 685324 + moreinfo unreproducible tags 685323 + moreinfo unreproducible merge 685324 685323 severity 685326 wishlist merge 685326 584251 thanks Hi, Were these reports of security issues supposed to be genuine? Yes, they were, as they are really two distinct security issues. Or was this simply your idea on how to get them to update GeSHi. [1] Well, no. But it'd be a bit long for this mail to shed light on all the background. And since I don't want to bore you to death while you actually could be doing something useful (like e.g. updating the package) I refrain from doing so. You refer to vulnerabilities in unspecified contrib scripts, but it seems to me that Debian does not even ship them in the php-geshi package. Debian ships them. And the Security Team already has been notified about the details. That's also the reason why these two bugs have been made public as part of a longer discussion yesterday. Debian who STILL believes the most recent version is 1.0.8.4, actually identifies the latest version as 1.0.8.10 on the PTS [2], with a link to the source tarball, and that will surely update within a few hours to indicate the new 1.0.8.11 release. Just checked [2]: Still says 1.0.8.10. But that wasn't the point of the blog post: The point was about the packaging which was (and by the way still is) way behind; but more on this in a moment. Yes, you already filed a wishlist bug asking for someone to package the new version, so there was no reason to file a new 'serious'-severity duplicate just now demanding the same. There was a request on the #debian-qa channel when I talked to some people directly asking for it. If you'd like the log just ask. It seems to me you are in fact wasting the time of whoever would potentially package your software, of developers busy fixing serious issues to make the next Debian release happen, and of the security team, who would be kindly looking after users for the package's 2-3 year term in stable/oldstable. Oh, thanks for that compliment, but I've to decline. Given exactly the 2-3 years this package will be in stable/oldstable is the reason why there should be an update to something reasonably recent before the package is put into a distribution. Putting in a package which is ~40kLOCs in diffs behind the current version (to compare the core component only is about 5kLOC) will be a monster to support. Last time there was a report to fix something in a stable release took about 4 months of MY time to look up a patch that the Package maintainers requested; it would have taken about 2 days using upstream AND testing it thouroughly. Some users really prefer long-term, unchanging versions, because they deploy lots of software that they don't want to have to review for what's changed, update it, re-test and check compatibility on a regular basis. Debian's stable distribution fulfills that need. Yeah, no news to me. And BTW: I'm also using Debian on some of my systems. And if you really want to try: GeSHi 1.0.7.15 (which should be around etch IIRC) can be replaced by a current 1.0.8.11 and everything just keeps working. That's aboutith Cygwin half my system breaks everytime I install an update. The freeze deadline has already passed, for someone to have _volunteered_ to update the GeSHi package in time for the Wheezy release process. The only exception now might be for a genuine security fix or serious flaw (which would probably be only a minimal patch for the specific issue), Feel lucky I had the revisions for the bugfix still at hand... And regarding the packaging: It has been known for at least the time there was this wishlist ticket that GeSHi was needing an update in unstable/testing. It's absolutely not my fault that there's only someone waking up once a security problem is notified. Also: I repeatedly tried to get someone who was willing to do the packaging for php-geshi to resolve those long-standing issues. If again the packaging team can't manage to grant necessary privileges for about 5 month that's another problem on your side. It is possible for more frequent updates to be packaged in testing or backports, for example to support new programming languages, but it would require continued effort on the part of a volunteer maintainer. That person would have had to process your bug reports too. Correct. And I already did some work on this part prior and in parallel to these reports. So don't be as gentle as an elephant shopping for procelain. [1] http://blog.benny-baumann.de/?p=1297 [2] http://packages.qa.debian.org/g/geshi.html Regards, Regards, upstream. signature.asc Description: OpenPGP digital signature
Bug#685323: Non-persistent XSS vulnerability in contrib script
Package: php-geshi Version: 1.0.8.4-1 Severity: serious Tags: security upstream GeSHi 1.0.8.11 closes non-persistent XSS vulnerability in a contrib script provided in the GeSHi distribution. The vulnerability can be triggered by an attacker using a specially crafted URL when calling a vulnerable version of the script. Please upgrade the php-geshi package to the latest upstream version which fixes this issue. Regards, upstream. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.0.0-1-amd64 (SMP w/8 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 php-geshi depends on: ii php5 5.4.4-4 ii php5-cli 5.4.4-4 php-geshi recommends no packages. php-geshi 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#685324: Local File Inclusion Vulnerability in contrib script
Package: php-geshi Version: 1.0.8.4-1 Severity: serious Tags: security upstream GeSHi 1.0.8.11 closes a local file inclusion vulnerability present in one of the contrib scripts provided in the GeSHi distribution. The bug has been present for at least 1.0.8.4 (and maybe even longer). Please upgrade the php-geshi package to latest upstream. Regards, upstream. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.0.0-1-amd64 (SMP w/8 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 php-geshi depends on: ii php5 5.4.4-4 ii php5-cli 5.4.4-4 php-geshi recommends no packages. php-geshi 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#685326: Anchient version in stable and testing although update to more recent version requested for ages.
Package: php-geshi Version: 1.0.8.4-1 Severity: serious Tags: upstream Despite being asked for about two years ago this package hasn't been updated by the responsible maintainers. Also direct contact to the maintainers at several points in time and occasions achieved no response which would lead to new and fixed versions of the upstream package resolving all bugs of this Debian package being updated. Also in the latest upstream release there are fixes for two security bugs (reported to the security team) that need being deployed ASAP a the Debian package includes the vulnerable files. Even though just fixing those two security bugs might seem enough it actually isn't. Due to the wide range of web applications that include GeSHi or contain a plugin to use GeSHi fixing the three below bugs causes a lot of applications to profit from including a new upstream version. This not only fixes a few bugs reported to Debian directly but (maybe read the CHANGELOG) quite a lot of different highlighting problems people have reported upstream over the last two years. Thus it'd be /really/ nice if a updated version using latest upstream 1.0.8.11 by the time of this bug report) could be sent to stable/testing ASAP. Best regards, upstream. Bugs with severity normal 1) #579080 php-geshi: Can't render Scheme code 2) #613711 php-geshi: Incorrect HTML generation while parsing Java source files Bugs with severity wishlist 3) #584251 php-geshi: Upstream release 1.0.8.8 -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.0.0-1-amd64 (SMP w/8 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 php-geshi depends on: ii php5 5.4.4-4 ii php5-cli 5.4.4-4 php-geshi recommends no packages. php-geshi 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#671690: libgamin0 breaks courier-imap/courier-imap-ssl (Sudden termination of connection)
Package: libgamin0 Version: 0.1.10-4 Severity: critical Justification: breaks unrelated software Dear Maintainer, * What led up to the situation? I've been running a Courier IMAP and POP3 server on my system for quite some time which worked just fine except for some mail clients reporting filesystem errors when it was still running with some (older) libfam0 version. Replacing that libfam0 version by libgamin0 (which claims compatibility) worked fine and fixed the aforementioned problem at that time. * What exactly did you do (or not do) that was effective (or ineffective)? I recently updated the Courier IMAP server from 4.8 to 4.10. After this logins to IMAP stopped working. As I expected a problem with the most recent courier-imap(-ssl) update I tried a downgrade to stable (4.8) which didn't have any effect regarding this problem: Clients still could not login nor got an error message from the server. Additionally I checked for a permission problem and thus tried to disable the addional sanity checks Courier performs when reading the Maildir. This didn't change anything either. To reproduce I tried to create an IMAP account afresh in my mail client with proper settings for the login credentials but when trying to use IMAP it just hang a few seconds and then suddently terminated without providing a login status message (e.g. OK or error message). When switching IMAP for POP3 it just worked properly. * What was the outcome of this action? The outcome was that using the Courier IMAP server was impossible since although I could login according to authdaemond clients kept on disconnecting. After multiple hours of checking everything (including analyzing encrypted network traces, logfiles, various configurations, the answer to life the universe and everything ...) I incidentially tried to recompile Courier IMAP from source using apt-src install courier-imap-ssl which insisted on installing (the previously broken) libfam0 package(s). Interestingly NOW libfam0 worked without File system errors reported by the client AND the login returned to a working state. * What outcome did you expect instead? If libgamin0 claims to provide libfam0 it should behave like libfam0. Oh and secondly I expected software to just work ;-) Regards, BenBE. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.0.0-1-amd64 (SMP w/8 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 libgamin0 depends on: ii gamin 0.1.10-4 ii libc6 2.13-32 libgamin0 recommends no packages. libgamin0 suggests no packages. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670564: arduino-mk: Hardcoded path violating FHS
Package: arduino-mk Version: 0.8-1 Severity: grave Justification: renders package unusable In the included file /usr/share/arduino/ard-parse-boards script, line 12, there's a hardcoded path to some weird MacOSX application directory which is guaranteed to not exist on any sane Debian system by FHS. Modifying this line to point to the proper path of the boards.txt seems to work. -- System Information: Debian Release: 6.0.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (x86_64) Kernel: Linux 2.6.27 (SMP w/2 CPU cores) Locale: LANG=de_DE@euro, LC_CTYPE=de_DE@euro (charmap=ISO-8859-15) 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#670565: arduino-mk: Makefile hardcodes include line of non-existent header file into PDE files
Package: arduino-mk Version: 0.8-1 Severity: grave Justification: renders package unusable When compiling a custom project using the Arduino.mk file of this package you automatically get a line #include WProgram.h at the beginning of the internally compiled file of your project. As this file is no longer part of Arduino versions 1.0 and above this makes all .pde files uncompileable using this build scipt. Either replace this by Arduino.h or remove this additional compile line alltogether from this build script. -- System Information: Debian Release: 6.0.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (x86_64) Kernel: Linux 2.6.27 (SMP w/2 CPU cores) Locale: LANG=de_DE@euro, LC_CTYPE=de_DE@euro (charmap=ISO-8859-15) 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#556922: Console resize freezes mc causing system crash/hang
Am 01.12.2009 22:18, schrieb Iustin Pop: On Wed, Nov 18, 2009 at 11:54:31AM +0100, Benny Baumann wrote: Package: mc Version: 2:4.6.2~git20080311-4 Severity: critical Justification: breaks the whole system When running mc inside a screen session via SSH mc crashes as soon as you resize the window in which mc is displayed. When this error occures mc freezes and allocates memory in an endless loop in the background. Once system resources have been reached the entire system freezes. Sometimes (tested with a system with a Xen 3.2-1 hypervisor) this even might kernel-panic the hypervisor. Steps to verify (the ones that worked for me): - Fire up a DomU with Xen (3.2-1) - Connect to that DomU by SSH - apt-get install screen mc - Fire up new screen session or take over an existing with screen -d -RR - In that screen session start mc - Resize the Window of the screen session - MC freezes (now wait a few seconds for MC to fill up the memory) -- The system completely hangs, probably with Kernel Panic On the step where mc starts to hang have a view on top or htop regarding mc's memory usage which suddently increases rapidly. If you kill mc fast enough (before it reaches the maximum RAM available) no crash of the VM happens. This doesn't happen anymore with the unstable version (2:4.7.0-pre1-3). Could you try testing that and see if it indeed works for you (maybe by building it for lenny?) Might be a bit complicated as both systems I could test it on are running at most testing, which doesn't include 2:4.7.0-pre1-3 yet AFAIK. As both systems are production updating might take a bit for me to test - especially because of the system crash involved in this. Will have a look at this though and comment back. While this is indeed unpleasant, the fact that mc eats a lot of memory should not kill the whole system, and is more likely a wrong system configuration, I think. More or less a default Xen configuration with one hypervisor (only few RAM, but swapspace) and 2 DomUs which split the remaining RAM between them. So really no rocket-science in that configuration. The system crash on Xen comes as soon as MC reaches full RAM reserved for the DomU (unswapped) memory size which results in a kernel panic (full Dom0 reboot). Updating Xen doesn't work (The maschine/Dom0 won't boot with Xen 3.4 installed). Maybe FW for the Xen guys? regards, iustin Regards, BenBE. signature.asc Description: OpenPGP digital signature
Bug#556922: Console resize freezes mc causing system crash/hang
Package: mc Version: 2:4.6.2~git20080311-4 Severity: critical Justification: breaks the whole system When running mc inside a screen session via SSH mc crashes as soon as you resize the window in which mc is displayed. When this error occures mc freezes and allocates memory in an endless loop in the background. Once system resources have been reached the entire system freezes. Sometimes (tested with a system with a Xen 3.2-1 hypervisor) this even might kernel-panic the hypervisor. Steps to verify (the ones that worked for me): - Fire up a DomU with Xen (3.2-1) - Connect to that DomU by SSH - apt-get install screen mc - Fire up new screen session or take over an existing with screen -d -RR - In that screen session start mc - Resize the Window of the screen session - MC freezes (now wait a few seconds for MC to fill up the memory) -- The system completely hangs, probably with Kernel Panic On the step where mc starts to hang have a view on top or htop regarding mc's memory usage which suddently increases rapidly. If you kill mc fast enough (before it reaches the maximum RAM available) no crash of the VM happens. Regards, Benny. -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-2-xen-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages mc depends on: ii libc6 2.7-18 GNU C Library: Shared libraries ii libglib2.0-0 2.16.6-2 The GLib library of C routines ii libgpm2 1.20.4-3.1 General Purpose Mouse - shared lib ii libslang2 2.1.3-3The S-Lang programming library - r mc recommends no packages. Versions of packages mc suggests: pn arj none (no description available) ii bzip21.0.5-1 high-quality block-sorting file co pn dbview none (no description available) ii file 4.26-1 Determines file type using magic ii lynx 2.8.7dev9-2.1 Text-mode WWW Browser (transitiona ii mime-support 3.44-1 MIME files 'mime.types' 'mailcap pn odt2txt none (no description available) ii perl 5.10.0-19lenny2 Larry Wall's Practical Extraction ii unzip5.52-12 De-archiver for .zip files ii w3m 0.5.2-2+b1 WWW browsable pager with excellent pn xpdf none (no description available) pn zip none (no description available) -- 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
