Package: ejabberd
Version: 1.0.0-2
Severity: critical
Justification: breaks unrelated software
RC abuse of /etc/ssl/certs, rendering certificate validation
inoperable.
There are two problems with this packages use of /etc/ssl/certs:
* Files in /etc/ssl/certs must be a+r
- GNUTLS reads files in /etc/ssl/certs, and will not verify a
remote certificate once it encounters an unreadable file in
/etc/ssl/certs.
- OPENSSL also must read files in /etc/ssl/certs, but seems to
be more forgiving of errors incurred in the process.
* This packages combines the key and cert into one file - which
of course means it can't be world readable... and there for should
not be in /etc/ssl/certs. At least the key file should be in some
package private /etc/ directory - with the appropriate
permissions.
You can still use a combined file, but it just needs to be
elsewhere.
I noticed this when I couldn't connect to my corporate LDAP servers
using ldaps://, but the breakage is going to be further spread (likely any
GNUTLS client app needing to lookup certificate chains).
-- System Information:
Debian Release: testing/unstable
APT prefers testing-proposed-updates
APT policy: (500, 'testing-proposed-updates'), (500, 'proposed-updates'),
(500, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Versions of packages ejabberd depends on:
ii erlang-base-hipe [erlang-runt 1:10.b.9-4 Erlang base system (virtual machin
ii erlang-nox 1:10.b.9-4 Concurrent, real-time, distributed
ii libc6 2.3.6-9 GNU C Library: Shared libraries
ii libexpat1 1.95.8-3.2 XML parsing C library - runtime li
ii libssl0.9.7 0.9.7i-1 SSL shared libraries
ii openssl 0.9.8b-2 Secure Socket Layer (SSL) binary a
ejabberd recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
