Bug#497952: /etc/default/pgpool2 not sourced by init script
Package: pgpool2 Version: 1.3-2 Severity: normal /etc/default/pgpool2 is installed by the pgpool2 package, however the init script sources /etc/default/pgpool [EMAIL PROTECTED]:~$ grep /etc/default /etc/init.d/pgpool2 if [ -f /etc/default/pgpool ] ; then . /etc/default/pgpool [EMAIL PROTECTED]:~$ ls -l /etc/default/pgpool ls: cannot access /etc/default/pgpool: No such file or directory -- Kind Regards, Michael Shuler -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (700, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages pgpool2 depends on: ii libc6 2.7-13 GNU C Library: Shared libraries ii libpq58.3.3-1PostgreSQL C client library ii lsb-base 3.2-19 Linux Standard Base 3.2 init scrip ii postgresql-common 90 PostgreSQL database-cluster manage pgpool2 recommends no packages. pgpool2 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464345: New upstream release
Package: pgpool2
Tags: patch
Followup-For: Bug #464345
New version allows the use of restart - patch included for restart
option in init script.
--
Kind Regards,
Michael Shuler
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (700, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.26-1-686 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages pgpool2 depends on:
ii libc6 2.7-13 GNU C Library: Shared libraries
ii libpq58.3.3-1PostgreSQL C client library
ii lsb-base 3.2-19 Linux Standard Base 3.2 init scrip
ii postgresql-common 90 PostgreSQL database-cluster manage
pgpool2 recommends no packages.
pgpool2 suggests no packages.
-- no debconf information
--- pgpool2-1.3/debian/init.d 2008-08-25 10:32:26.0 -0500
+++ pgpool2_2.1/debian/init.d 2008-08-25 12:15:25.0 -0500
@@ -88,7 +88,15 @@
fi
;;
reload)
- exit 3
+ is_running
+ status=$?
+ if [ $status -eq 0 ]; then
+ log_daemon_msg Reloading pgpool-II pgpool
+ su -c $DAEMON -n $OPTS reload 21 /dev/null /dev/null 21
- postgres
+ else
+ log_failure_msg pgpool-II is not running.
+ exit $status
+ fi
;;
*)
log_failure_msg Usage: $0
{start|stop|status|restart|try-restart|reload|force-reload}
Bug#459513: ITP: libdata-password-perl -- Perl extension for assessing password quality
Package: wnpp Severity: wishlist Owner: Michael Shuler [EMAIL PROTECTED] * Package name: libdata-password-perl Version : 1.07 Upstream Author : Raz Information Systems : [EMAIL PROTECTED], [EMAIL PROTECTED] * URL : http://search.cpan.org/dist/Data-Password/ * License : Perl (GPL/Artistic) Programming Lang: Perl Description : Perl extension for assessing password quality Data::Password checks potential passwords for crackability. It checks that the password is in the appropriate length, that it has enough character groups, that it does not contain the same chars repeatedly or ascending or descending characters, or characters close to each other in the keyboard. It will also attempt to search the ispell word file for existance of whole words. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#453680: ITP: djbdns -- Replacement for BIND, written by Dan Bernstein
On 11/30/2007 10:28 AM, Robert Edmonds wrote: See the video clip on google video, which is dated yesterday. He says the pages on his site will be updated soon. (Obviously I won't upload packages until the license change really does occur.) Ah, I see - excellent. What would be the point of *-installer packages for djb software if the code becomes DFSG compatible? None - you are absolutely correct. I would then like to formally request that the following current patches in BTS for djbdns-installer be included (or at least seriously considered) in the djbdns package, if the binary redistribution stars align: #107578: djbdns-installer: IPv6 record types not supported (Merged with #107579) #243323: extra file in package (djbdns-conf-fhs) #274000: djbdns-installer: typo in description of tinydns #432900: Please add one-second.patch for performance #432903: Please add native SRV type to tinydns-data / axfr-get #432471: Truncation of alias chains by tinydns and axfrdns #447950: Advisory - L.ROOT-SERVERS.NET changing to 199.7.83.42 on 2007-11-01 (includes #432459: B.ROOT-SERVERS.NET IP address changed) A couple of these are minor/cosmetic (typo and djbdns-conf-fhs), the root servers are necessary, but IPv6, one-second, SRV, and the alias chain patch are highly important in our environment. My real desire is to have all the proper bits in place in the Debian package (binary or -installer) for our production authoritative server infrastructure, without the need to roll our own custom .deb's anymore. If Lenny releases to stable with all the right stuff, then I will be a happy user. Thanks for the vid link, Robert - I just saw your post to [EMAIL PROTECTED] and your link was not posted in BTS as of my reading. Do let me know if you need any help as you go along - we run a very large tinydns system at work. -- Warm Regards, Michael Shuler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#453680: ITP: djbdns -- Replacement for BIND, written by Dan Bernstein
On 11/30/2007 09:24 AM, Robert Edmonds wrote: Supposedly DJB has released all of his code into the public domain. If this is really the case and passes DFSG, I plan to package djbdns assuming Adam McKenna (maintainer of djbdns-installer) doesn't want to. Please provide the source documenting this copyrite/license change. I took a look at DJB's site and found no indication of this change, nor has there been any discussion/announcement on the [EMAIL PROTECTED] mailing list. DJB has been very clear for years about the software being public domain, but that redistribution of binaries is a completely different matter [0] In the last 6-9 months of multiple direct emails, bug reports, etc., I have received a single reply from Adam without any follow-up to subsequent messages. I had intended to work on an eventual sponsored NMU, and would be quite happy to help a fix up djbdns-installer. I asked around on #d-mentors, sent a detailed email to [EMAIL PROTECTED] on 08/20/2007, and basically got a casual OK to hijack the package. If you want to hijack djbdns-installer, I would be grateful to have a full DD as maintainer, so I can help out without asking for random sponsorship. ;) [0] http://cr.yp.to/distributors.html -- Kind Regards, Michael Shuler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#453680: ITP: djbdns -- Replacement for BIND, written by Dan Bernstein
http://cr.yp.to/distributors.html was updated 2007.12.28-29 with appropriate public domain notes. Build away! -- Kind Regards, Michael Shuler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#443263: ITP: libauthen-tacacsplus-perl -- Extension for authentication using tacacs+ server
Package: wnpp Severity: wishlist Owner: Michael Shuler [EMAIL PROTECTED] * Package name: libauthen-tacacsplus-perl Version : 0.16 Upstream Author : Mike Shoyher [EMAIL PROTECTED] : Mike McCauley [EMAIL PROTECTED] * URL : http://search.cpan.org/dist/TacacsPlus/ * License : Perl Artistic License [0] Programming Lang: Perl Description : Extension for authentication using tacacs+ server Authen::TacacsPlus allows you to authenticate using tacacs+ server. [0] License is not specified in the version 0.16 source, however, I have contacted the authors, and the next update to CPAN will include licensing information. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#443263: ITP: libauthen-tacacsplus-perl -- Extension for authentication using tacacs+ server
My sincere thanks to Mike Shoyher and Mike McCauley for the quick and responsive communication and source update. Mike McCauley has taken over upstream maintainership of this perl module, and has released 0.17 to CPAN: == 0.17 Sat Sep 22 2007, Mike McCauley - Mike McCauley ([EMAIL PROTECTED]) is now co-maintainer. - DISTNAME changed to Authen-TacacsPlus to be consistent with file naming of other Authen modules. - readme changed to README. - Added licensing statement to README, with the approval and consent of Mike Shoyher. - Fixed a typedef in md5.h that breaks md5 on 64 bit machines. Patch provided by Ernst Oudhof. - Removed bogus broken constant TACACS_CLIENT. - Fixed a number of compiler warnings, but still does not compile on Windows. == As indicated in the changelog entry, the base URL has changed to: http://search.cpan.org/dist/Authen-TacacsPlus/ I will roll up a .deb when time permits. It pays to ask the upstream author(s) for help with licensing clarification ;) -- Kind Regards, Michael Shuler signature.asc Description: OpenPGP digital signature
Bug#438478: djbdns-installer should depend on libc6-dev
In a fresh etch debootstrap (with only locales package added to get rid of annoying LANG warnings..) I was unable to reproduce - simple install of djbdns-installer with both aptitude and apt-get indicate that libc6-dev will be installed. libc6-dev is a Recommends: in gcc package (this is where your Recommend came from). libc6-dev is a Depends: in build-essential package. daemontools-installer includes a Depends: on build-essential (this is where my Depend came from), so it seems as if you may already have the daemontools binary package installed? Since daemontools-installer depends on build-essential, it may be appropriate to go ahead and add 'Depends: build-essential' to djbdns-installer dependencies - this would have pulled in the needed packages in Meder's case. -- Kind Regards, Michael Shuler = [EMAIL PROTECTED]:/# aptitude install djbdns-installer Reading package lists... Done Building dependency tree... Done Reading extended state information Initializing package states... Done Reading task descriptions... Done Building tag database... Done The following NEW packages will be automatically installed: binutils build-essential bzip2 cpp cpp-4.1 daemontools-installer debhelper dpkg-dev fakeroot file g++ g++-4.1 gcc gcc-4.1 gettext gettext-base html2text intltool-debian libc6-dev libcompress-zlib-perl libmagic1 libmail-sendmail-perl libmudflap0 libmudflap0-dev libssp0 libstdc++6-4.1-dev linux-kernel-headers make patch perl perl-doc perl-modules po-debconf The following NEW packages will be installed: binutils build-essential bzip2 cpp cpp-4.1 daemontools-installer debhelper djbdns-installer dpkg-dev fakeroot file g++ g++-4.1 gcc gcc-4.1 gettext gettext-base html2text intltool-debian libc6-dev libcompress-zlib-perl libmagic1 libmail-sendmail-perl libmudflap0 libmudflap0-dev libssp0 libstdc++6-4.1-dev linux-kernel-headers make patch perl perl-doc perl-modules po-debconf 0 packages upgraded, 34 newly installed, 0 to remove and 0 not upgraded. Need to get 32.4MB of archives. After unpacking 107MB will be used. Do you want to continue? [Y/n/?] n Abort. [EMAIL PROTECTED]:/# apt-get install djbdns-installer Reading package lists... Done Building dependency tree... Done The following extra packages will be installed: binutils build-essential cpp cpp-4.1 daemontools-installer debhelper dpkg-dev fakeroot file g++ g++-4.1 gcc gcc-4.1 gettext gettext-base html2text intltool-debian libc6-dev libmagic1 libssp0 libstdc++6-4.1-dev linux-kernel-headers make patch perl perl-modules po-debconf Suggested packages: binutils-doc cpp-doc gcc-4.1-locales dh-make ucspi-tcp-src debian-keyring gcc-4.1-doc lib64stdc++6 manpages-dev autoconf automake1.9 libtool flex bison gdb gcc-doc libc6-dev-amd64 lib64gcc1 lib64ssp0 cvs gettext-doc glibc-doc libstdc++6-4.1-doc make-doc-non-dfsg diff-doc libterm-readline-gnu-perl libterm-readline-perl-perl Recommended packages: bzip2 libmudflap0-dev perl-doc libmail-sendmail-perl libcompress-zlib-perl The following NEW packages will be installed: binutils build-essential cpp cpp-4.1 daemontools-installer debhelper djbdns-installer dpkg-dev fakeroot file g++ g++-4.1 gcc gcc-4.1 gettext gettext-base html2text intltool-debian libc6-dev libmagic1 libssp0 libstdc++6-4.1-dev linux-kernel-headers make patch perl perl-modules po-debconf 0 upgraded, 28 newly installed, 0 to remove and 0 not upgraded. Need to get 24.3MB of archives. After unpacking 92.5MB of additional disk space will be used. Do you want to continue [Y/n]? n Abort. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#438478: djbdns-installer should depend on libc6-dev
tags 438478 patch thanks I think this Depends looks about right: Depends: patch, fakeroot | sudo, wget, debhelper, build-essential, daemontools-installer | daemontools Kind Regards, Michael Shuler --- control.orig 2003-11-19 19:16:20.0 + +++ control 2007-08-21 02:22:09.0 + @@ -7,7 +7,7 @@ Package: djbdns-installer Architecture: all -Depends: dpkg-dev (= 1.4.0.20), patch (= 2.5-0bo1), fakeroot | sudo, gcc, make, debhelper, daemontools-installer | daemontools, wget +Depends: patch, fakeroot | sudo, wget, debhelper, build-essential, daemontools-installer | daemontools Suggests: ucspi-tcp-src Description: Source only package for building djbdns The following were taken from various HTML pages under
Bug#439018: djbdns-installer: update package to current standards
Package: djbdns-installer Version: 1.05-11 Please, update djbdns-installer to current Debian package standards. (native-package-with-dash-version is ok for this package, I believe) $ lintian djbdns-installer_1.05-11.dsc secmem usage: 0/0 bytes in 0/0 blocks of pool 0/32768 W: djbdns-installer source: debian-rules-sets-DH_COMPAT line 3 W: djbdns-installer source: package-uses-deprecated-debhelper-compat-version 2 W: djbdns-installer source: ancient-standards-version 3.5.8 (current is 3.7.2) E: djbdns-installer source: clean-should-be-satisfied-by-build-depends debhelper W: djbdns-installer source: native-package-with-dash-version -- Kind Regards, Michael Shuler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#434661: bind9: vulnerability with cryptographically weak transaction
Looks like this was done on July 25th, 2007 - bug should be closed: # [SECURITY] [DSA 1341-1] New bind9 packages fix DNS cache poisoning Moritz Muehlenhoff # [SECURITY] [DSA 1342-2] New bind9 packages fix DNS cache poisoning Moritz Muehlenhoff Thank you, Moritz. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#243323: extra file in package (djbdns-conf-fhs)
tags 243323 patch
thanks
djbdns-conf-fhs is the wrapper for the other *-conf utilities to set up
the various djbdns services, however, I think a check on how it was
called would not be a bad idea.
$ ls -l *-conf-fhs
lrwxrwxrwx 1 root root 15 Jul 9 13:08 axfrdns-conf-fhs - djbdns-conf-fhs
-rwxr-xr-x 1 root root 289 Jul 9 11:42 djbdns-conf-fhs
lrwxrwxrwx 1 root root 15 Jul 9 13:08 dnscache-conf-fhs -
djbdns-conf-fhs
lrwxrwxrwx 1 root root 15 Jul 9 13:08 pickdns-conf-fhs - djbdns-conf-fhs
lrwxrwxrwx 1 root root 15 Jul 9 13:08 rbldns-conf-fhs - djbdns-conf-fhs
lrwxrwxrwx 1 root root 15 Jul 9 13:08 tinydns-conf-fhs - djbdns-conf-fhs
lrwxrwxrwx 1 root root 15 Jul 9 13:08 walldns-conf-fhs - djbdns-conf-fhs
Kind Regards,
Michael Shuler
--- debian/djbdns-conf-fhs.orig 2003-11-18 22:39:05.0 -0600
+++ debian/djbdns-conf-fhs 2007-07-27 23:44:17.0 -0500
@@ -2,6 +2,13 @@
umask 022
+WRAPPER=`basename ${0}`
+if [[ $WRAPPER = djbdns-conf-fhs ]]; then
+echo $WRAPPER is the FHS wrapper for the djbdns *-conf utilities.
+echo $WRAPPER is not intended to be run directly.
+exit 1
+fi
+
fhslogdir () {
NEWLOGDIR=`basename $2`
mkdir -p /var/log/djbdns/${NEWLOGDIR}
Bug#433183: djbdns-installer: init.d script failed if installed in non-FHS fashion
I am curious if you manually removed the daemontools inittab entry in
your configuration, in preference of using the init.d script. I ask
this because, if daemontools is handling svscan, should the init.d
script gracefully fail? ie:
if grep svscanboot /etc/inittab; then
echo Daemontools is currently handling services from inittab..
exit 1
else
if [ -d /service ]; then
SVCDIR=/service
elif [ -d /var/lib/svscan ]; then
SVCDIR=/var/lib/svscan
else
echo Couldn't find your service dir..
exit 1
fi
case $1 in
start)
echo -n Starting djbdns:
for i in `ls -d $SVCDIR/dnscache* ...`; do
...
esac
fi
Would this work out ok in the init.d script, or should this be done
differently?
An added note, since the init.d script needs a little tlc - the usage
note has a typo, as well (s/dnscache/djbdns/):
*)
echo 'Usage: /etc/init.d/dnscache {start|stop|restart}'
exit 1
Kind Regards,
Michael Shuler
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#447950: Advisory - L.ROOT-SERVERS.NET changing to 199.7.83.42 on 2007-11-01
Package: djbdns-installer Version: 1.05-11 Severity: normal Tags: patch Please update L.ROOT-SERVERS.NET IP address in djbdns. A new dnsroots.diff is attached (which includes the B.ROOT change in bug #432459). Kind Regards, Michael Shuler Original Message Subject: [dns-operations] Advisory - L.ROOT-SERVERS.NET changing to 199.7.83.42 on 2007-11-01 Date: Wed, 24 Oct 2007 13:29:34 -0700 From: Kim Davies [EMAIL PROTECTED] Organization: Internet Assigned Numbers Authority To: [EMAIL PROTECTED] Colleagues, This is advance notice that there is a scheduled change to the IP address for one of the authorities listed for the DNS root zone. The change is to L.ROOT-SERVERS.NET, which is administered by ICANN. The new IPv4 address for this authority is: 199.7.83.42 This change is anticipated to be implemented in the root zone on 1 November 2007, however the new address is operational now. It will replace the previous IP address of 198.32.64.12. We encourage operators of DNS infrastructure to update any references to the old IP address, and replace it with the new address. In particular, many DNS resolvers have a DNS root hints file. This should be updated with the new IP address. New hints files will be available at the following URLs once the change has been formally executed: ftp://rs.internic.net/domain/db.cache ftp://rs.internic.net/domain/named.cache ftp://rs.internic.net/domain/named.root ftp://ftp.internic.net/domain/db.cache ftp://ftp.internic.net/domain/named.cache ftp://ftp.internic.net/domain/named.root It is expected that the old address will continue to work for at least six months after the transition, but will ultimately be retired from service. With kindest regards, Kim Davies Internet Assigned Numbers Authority --- dnsroots.global.orig 2001-02-11 21:11:45.0 + +++ dnsroots.global 2007-10-24 22:17:19.0 + @@ -1,5 +1,5 @@ 198.41.0.4 -128.9.0.107 +192.228.79.201 192.33.4.12 128.8.10.90 192.203.230.10 @@ -7,7 +7,7 @@ 192.112.36.4 128.63.2.53 192.36.148.17 -198.41.0.10 +192.58.128.30 193.0.14.129 -198.32.64.12 +199.7.83.42 202.12.27.33 signature.asc Description: OpenPGP digital signature
Bug#421662: libexo-0.3-0 missing dependency on liburi-perl
Package: libexo-0.3-0 Version: 0.3.1.12rc2-1 When selecting an email address from an xfce4-terminal session, I expected my preferred mail reader to open a compose window. Instead, I received an error window, Failed to execute default Mail Reader. Input/output error. In ~/.xsession-errors, I found: Can't locate URI/Escape.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .) at /usr/lib/libexo-0.3-0/exo-compose-mail-0.3 line 26. BEGIN failed--compilation aborted at /usr/lib/libexo-0.3-0/exo-compose-mail-0.3 line 26. A quick 'apt-get install install liburi-perl' solved this problem. Kind Regards, Michael Shuler Debian GNU/Linux 4.0 Etch, kernel 2.6.18.dfsg.1-12, libc6 2.3.6.ds1-13 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#432459: B.ROOT-SERVERS.NET IP address changed
Package: djbdns-installer Version: 1.05-11 Severity: normal According to the 2004-01-29 news posting: http://www.root-servers.org/news/new-ip-b.html The old address (128.9.0.107) will respond to DNS queries for a significant period of time, however, the file dnsroots.global should be updated for the new IP address: B.ROOT-SERVERS.NET. 360 A 192.228.79.201 A new dnsroots.diff is attached. Kind Regards, Michael Shuler --- dnsroots.global.orig 2001-02-11 21:11:45.0 + +++ dnsroots.global 2007-07-09 23:14:38.0 + @@ -1,5 +1,5 @@ 198.41.0.4 -128.9.0.107 +192.228.79.201 192.33.4.12 128.8.10.90 192.203.230.10 @@ -7,7 +7,7 @@ 192.112.36.4 128.63.2.53 192.36.148.17 -198.41.0.10 +192.58.128.30 193.0.14.129 198.32.64.12 202.12.27.33
Bug#274000: djbdns-installer: typo in description of tinydns
Tags: + patch patch attached --- debian/control.orig 2003-11-19 13:16:20.0 -0600 +++ debian/control 2007-07-09 21:29:25.0 -0500 @@ -19,7 +19,7 @@ save time later. . tinydns is a DNS server. It accepts iterative DNS queries from hosts - taround he Internet, and responds with locally configured information. + around the Internet, and responds with locally configured information. . pickdns is a load-balancing DNS server. It accepts iterative DNS queries from hosts around the Internet, and responds with a dynamic
Bug#432471: Truncation of alias chains by tinydns and axfrdns
Package: djbdns-installer
Version: 1.05-11
Severity: normal
Tags: patch
From:
http://homepages.tesco.net./~J.deBoynePollard/FGA/djbdns-problems.html#content-alias-chain-truncation
According to the algorithm in RFC 1034 § 4.3.2, a content DNS server
must search for a CNAME resource record for the domain name being
queried, and if it finds one it must substitute the domain name from the
data portion, add the resource record to the answer section of the
response, and restart processing. tinydns and axfrdns do not do this.
(plus more good info)
In production authoritative name service for 400,000+ domains, we found
the patch provided by Jonathan de Boyne Pollard at the above site
corrected the CNAME authority issues with tinydns/axfrdns.
A quick example of an erroneous response from an unpatched tinydns
(djbdns-installer_1.05):
$ dig kokopelli.pbandjelly.org @ns.rackspace.com
;kokopelli.pbandjelly.org. IN A
kokopelli.pbandjelly.org. 86400 IN CNAME kokopelli.homeunix.org.
pbandjelly.org. 86400 IN NS ns.rackspace.com.
pbandjelly.org. 86400 IN NS ns2.rackspace.com.
;; Received 128 bytes from 69.20.95.4#53(69.20.95.4) in 12 ms
A patched tinydns response as per the algorithm in RFC 1034:
$ dig kokopelli.pbandjelly.org @ns.rackspace.com
;kokopelli.pbandjelly.org. IN A
kokopelli.pbandjelly.org. 86400 IN CNAME kokopelli.homeunix.org.
;; Received 75 bytes from 69.20.95.4#53(69.20.95.4) in 13 ms
And the resulting recursive resolver response (which picks up the proper
authority from the external CNAME target):
$ dig kokopelli.pbandjelly.org
;kokopelli.pbandjelly.org. IN A
kokopelli.pbandjelly.org. 31057 IN CNAME kokopelli.homeunix.org.
kokopelli.homeunix.org. 60 IN A 10.1.100.156
homeunix.org. 11192 IN NS ns3.dyndns.org.
homeunix.org. 11192 IN NS ns4.dyndns.org.
homeunix.org. 11192 IN NS ns5.dyndns.org.
homeunix.org. 11192 IN NS ns1.dyndns.org.
homeunix.org. 11192 IN NS ns2.dyndns.org.
;; Received 268 bytes from 64.39.2.170#53(64.39.2.170) in 21 ms
Kind Regards,
Michael Shuler
--- djbdns-1.05-original/tdlookup.c Sun Feb 11 21:11:45 2001
+++ djbdns-1.05/tdlookup.c Thu Apr 3 11:56:47 2003
@@ -103,12 +103,13 @@
return response_addname(d1);
}
-static int doit(char *q,char qtype[2])
+static int doit1(char **pqname,char qtype[2])
{
unsigned int bpos;
unsigned int anpos;
unsigned int aupos;
unsigned int arpos;
+ char *q;
char *control;
char *wild;
int flaggavesoa;
@@ -122,6 +123,12 @@
int addrnum;
uint32 addrttl;
int i;
+ int loop = 0 ;
+
+RESTART:
+ if (loop++ = 100) return 0 ;
+
+ q = *pqname ;
anpos = response_len;
@@ -136,7 +143,14 @@
if (byte_equal(type,2,DNS_T_NS)) flagns = 1;
}
if (flagns) break;
-if (!*control) return 0; /* q is not within our bailiwick */
+if (!*control) { /* q is not within our bailiwick */
+ if (loop = 1)
+return 0 ;
+ else {
+response[2] = ~4;
+goto DONE; /* The administrator has issued contradictory instructions */
+ }
+}
control += *control;
control += 1;
}
@@ -172,8 +186,16 @@
continue;
}
if (!response_rstart(q,type,ttl)) return 0;
- if (byte_equal(type,2,DNS_T_NS) || byte_equal(type,2,DNS_T_CNAME) || byte_equal(type,2,DNS_T_PTR)) {
+ if (byte_equal(type,2,DNS_T_NS) || byte_equal(type,2,DNS_T_PTR)) {
+ if (!doname()) return 0;
+ }
+ else if (byte_equal(type,2,DNS_T_CNAME)) {
if (!doname()) return 0;
+if (byte_diff(type,2,qtype)) {
+ response_rfinish(RESPONSE_ANSWER);
+ if (!dns_domain_copy(pqname,d1)) return 0 ;
+ goto RESTART ;
+ }
}
else if (byte_equal(type,2,DNS_T_MX)) {
if (!dobytes(2)) return 0;
@@ -275,9 +297,21 @@
}
}
+DONE:
return 1;
}
+static int doit(char *qname,char qtype[2])
+{
+ int r ;
+ char * q = 0 ;
+
+ if (!dns_domain_copy(q, qname)) return 0 ;
+ r = doit1(q, qtype) ;
+ dns_domain_free(q) ;
+ return r ;
+}
+
int respond(char *q,char qtype[2],char ip[4])
{
int fd;
Bug#432903: Please add native SRV type to tinydns-data / axfr-get
Package: djbdns-installer
Version: 1.05-11
Severity: wishlist
Tags: patch
The attached patch adds native SRV record type to tinydns-data and
axfr-get (patch credit goes to Michael Handler for the initial patch,
and to Laurent G. Bercot for the updated patch for djbdns-1.05).
Native SRV record data type is far more useful than the opaque SRV
handling in the stock djbdns source.
Kind Regards,
Michael Shuler
From: Michael Handler [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: tinydns-data SRV axfr-get SRV/PTR patches
Date: Thu, 14 Sep 2000 20:37:50 -0400
Here's a combined patch that:
a) adds a native SRV type to tinydns-data
Sfqdn:ip:x:port:weight:priority:ttl:timestamp
Standard rules for ip, x, ttl, and timestamp apply. Port, weight, and
priority all range from 0-65535. Weight and priority are optional; they
default to zero if not provided.
Sconsole.zoinks.example.com:1.2.3.4:rack102-con1:2001:69:7:300:
b) makes axfr-get decompose SRV and PTR records and write them out in
native format, rather than opaque. Again, this is necessary because if the
DNAME fields in the records reference the same zone as fqdn, they can have
compression pointers that are bogus outside the context of that specific
packet, and which can't be correctly loaded into data.cdb by tinydns-data.
--michael
Laurent G. Bercot [EMAIL PROTECTED] updated it for djbdns-1.05:
diff -rNU3 djbdns-1.05/axfr-get.c djbdns-1.05-srv/axfr-get.c
--- djbdns-1.05/axfr-get.c Sun Feb 11 22:11:45 2001
+++ djbdns-1.05-srv/axfr-get.c Thu Oct 18 14:46:56 2001
@@ -209,6 +209,26 @@
if (!stralloc_cats(line,.:)) return 0;
if (!stralloc_catulong0(line,dist,0)) return 0;
}
+ else if (byte_equal(data,2,DNS_T_SRV)) {
+uint16 dist, weight, port;
+if (!stralloc_copys(line,S)) return 0;
+if (!dns_domain_todot_cat(line,d1)) return 0;
+if (!stralloc_cats(line,::)) return 0;
+pos = x_copy(buf,len,pos,data,2);
+uint16_unpack_big(data,dist);
+pos = x_copy(buf,len,pos,data,2);
+uint16_unpack_big(data,weight);
+pos = x_copy(buf,len,pos,data,2);
+uint16_unpack_big(data,port);
+x_getname(buf,len,pos,d1);
+if (!dns_domain_todot_cat(line,d1)) return 0;
+if (!stralloc_cats(line,.:)) return 0;
+if (!stralloc_catulong0(line,dist,0)) return 0;
+if (!stralloc_cats(line,:)) return 0;
+if (!stralloc_catulong0(line,weight,0)) return 0;
+if (!stralloc_cats(line,:)) return 0;
+if (!stralloc_catulong0(line,port,0)) return 0;
+ }
else if (byte_equal(data,2,DNS_T_A) (dlen == 4)) {
char ipstr[IP4_FMT];
if (!stralloc_copys(line,+)) return 0;
@@ -216,6 +236,14 @@
if (!stralloc_cats(line,:)) return 0;
x_copy(buf,len,pos,data,4);
if (!stralloc_catb(line,ipstr,ip4_fmt(ipstr,data))) return 0;
+ }
+ else if (byte_equal(data,2,DNS_T_PTR)) {
+if (!stralloc_copys(line,^)) return 0;
+if (!dns_domain_todot_cat(line,d1)) return 0;
+if (!stralloc_cats(line,:)) return 0;
+x_getname(buf,len,pos,d1);
+if (!dns_domain_todot_cat(line,d1)) return 0;
+if (!stralloc_cats(line,.)) return 0;
}
else {
unsigned char ch;
diff -rNU3 djbdns-1.05/dns.h djbdns-1.05-srv/dns.h
--- djbdns-1.05/dns.h Sun Feb 11 22:11:45 2001
+++ djbdns-1.05-srv/dns.h Thu Oct 18 14:46:56 2001
@@ -20,6 +20,7 @@
#define DNS_T_SIG \0\30
#define DNS_T_KEY \0\31
#define DNS_T_ \0\34
+#define DNS_T_SRV \0\41
#define DNS_T_AXFR \0\374
#define DNS_T_ANY \0\377
diff -rNU3 djbdns-1.05/tinydns-data.c djbdns-1.05-srv/tinydns-data.c
--- djbdns-1.05/tinydns-data.c Sun Feb 11 22:11:45 2001
+++ djbdns-1.05-srv/tinydns-data.c Thu Oct 18 14:50:53 2001
@@ -196,6 +196,7 @@
char type[2];
char soa[20];
char buf[4];
+ char srv[6];
umask(022);
@@ -360,6 +361,43 @@
rr_start(DNS_T_MX,ttl,ttd,loc);
uint16_pack_big(buf,u);
rr_add(buf,2);
+ rr_addname(d2);
+ rr_finish(d1);
+
+ if (ip4_scan(f[1].s,ip)) {
+ rr_start(DNS_T_A,ttl,ttd,loc);
+ rr_add(ip,4);
+ rr_finish(d2);
+ }
+ break;
+
+ case 'S':
+ if (!dns_domain_fromdot(d1,f[0].s,f[0].len)) nomem();
+ if (!stralloc_0(f[6])) nomem();
+ if (!scan_ulong(f[6].s,ttl)) ttl = TTL_POSITIVE;
+ ttdparse(f[7],ttd);
+ locparse(f[8],loc);
+
+ if (!stralloc_0(f[1])) nomem();
+
+ if (byte_chr(f[2].s,f[2].len,'.') = f[2].len) {
+ if (!stralloc_cats(f[2],.srv.)) nomem();
+ if (!stralloc_catb(f[2],f[0].s,f[0].len)) nomem();
+ }
+ if (!dns_domain_fromdot(d2,f[2].s,f[2].len)) nomem();
+
+ if (!stralloc_0(f[4])) nomem();
+ if (!scan_ulong(f[4].s,u)) u = 0;
+ uint16_pack_big(srv,u);
+ if (!stralloc_0(f[5])) nomem();
+ if (!scan_ulong(f[5].s,u)) u = 0;
+ uint16_pack_big(srv + 2,u);
+ if (!stralloc_0(f[3])) nomem();
+ if (!scan_ulong(f[3].s,u)) nomem();
+ uint16_pack_big(srv + 4,u);
+
+ rr_start(DNS_T_SRV,ttl,ttd,loc
Bug#432900: Please add one-second.patch for performance
Package: djbdns-installer
Version: 1.05-11
Severity: wishlist
Tags: patch
Attached is a patch for improving the performance of djbdns under high
load. This patch makes djbdns-1.05 cache its mmap() of the data.cdb
file up to a maximum of one second, which substantially reduces the
number of times that the database file needs to be mapped and unmapped
(patch credit goes to Lennert Buytenhek).
Kind Regards,
Michael Shuler
From [EMAIL PROTECTED] Sat Jul 23 15:19:58 2005
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
[1512 Tuesday 20 April 2004 13:06:49 +0200 Lennert Buytenhek [EMAIL PROTECTED] nil 61 patch to make djbdns 1.05 cache its mmap() of the data.cdb file ^From: nil nil 4 nil nil nil nil nil nil nil nil nil]
nil)
Return-Path: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
Received: (qmail 9047 invoked by alias); 23 Jul 2005 15:19:58 -
Delivered-To: [EMAIL PROTECTED]
Received: (qmail 9044 invoked by uid 500); 23 Jul 2005 15:19:58 -
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
s=dog; d=wantstofly.org;
b=IWNClqptgImEp3WfkGIht8VKuoHgvQcYS2QB6tjfjVSIFs+iulN4Fg1yMtJiDL3D ;
Message-ID: [EMAIL PROTECTED]
X-Original-To: buytenh
Delivered-To: [EMAIL PROTECTED]
User-Agent: Mutt/1.4.1i
X-Keywords:
X-UID: 800
From: Lennert Buytenhek [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: patch to make djbdns 1.05 cache its mmap() of the data.cdb file
Date: Tue, 20 Apr 2004 13:06:49 +0200
Hi,
This patch makes djbdns 1.05 cache its mmap() of the data.cdb file up to a
maximum of one second. Under high query load, this substantially reduces
the number of times that the database file needs to be mapped and unmapped,
and gives a two-digit percentage performance improvement under 100% system
load (as discussed on the djbdns mailing list.)
Could you stick a copy of the patch on www.tinydns.org please? I don't
have anywhere to host it myself at this point, and I would like to see it
on that page -- is that acceptable to you?
thanks,
Lennert
diff -urN djbdns-1.05.orig/tdlookup.c djbdns-1.05/tdlookup.c
--- djbdns-1.05.orig/tdlookup.c 2001-02-11 22:11:45.0 +0100
+++ djbdns-1.05/tdlookup.c 2004-04-18 13:56:13.0 +0200
@@ -280,15 +280,24 @@
int respond(char *q,char qtype[2],char ip[4])
{
- int fd;
+ static struct tai cdb_valid = { 0 };
+ static int fd = -1;
+ struct tai one_second;
int r;
char key[6];
tai_now(now);
- fd = open_read(data.cdb);
- if (fd == -1) return 0;
- cdb_init(c,fd);
-
+ if (tai_less(cdb_valid, now)) {
+if (fd != -1) {
+ cdb_free(c);
+ close(fd);
+}
+fd = open_read(data.cdb);
+if (fd == -1) return 0;
+cdb_init(c,fd);
+tai_uint(one_second, 1);
+tai_add(cdb_valid, now, one_second);
+ }
byte_zero(clientloc,2);
key[0] = 0;
key[1] = '%';
@@ -304,7 +313,5 @@
r = doit(q,qtype);
- cdb_free(c);
- close(fd);
return r;
}
- End forwarded message -
Bug#418449: submission entry for ignore.d.server/postfix
Package: logcheck
Version: 1.2.54
When Postfix is configured to listen on port tcp/587 by uncommenting the
submission line in the postfix master.cf, logcheck does not ignore the
anvil statistics log entries - attached is a patch from the current SVN
trunk.
Index: rulefiles/linux/ignore.d.server/postfix
===
--- rulefiles/linux/ignore.d.server/postfix (revision 1531)
+++ rulefiles/linux/ignore.d.server/postfix (working copy)
@@ -79,7 +79,7 @@
^\w{3} [ :0-9]{11} [._[:alnum:]-]+ postfix/local\[[0-9]+\]: [[:upper:][:digit:]]+: to=[^[:space:]]+,( orig_to=[^[:space:]]+,)* relay=local, delay=[0-9]+, status=sent \(delivered to command: exec /usr/bin/procmail\)$
^\w{3} [ :0-9]{11} [._[:alnum:]-]+ postfix/local\[[0-9]+\]: table hash:[^[:space:]]+\([-,|_[:alnum:]]+\) has changed -- restarting$
^\w{3} [ :0-9]{11} [._[:alnum:]-]+ postfix/policy-spf\[[0-9]+\]: : SPF pass: smtp_comment=.*: [.[:alnum:]]+ MX [.[:alnum:]]+ A [0-9a-f.:]+, header_comment=[.[:alnum:]+: domain of [%[:punct:][:alnum:[EMAIL PROTECTED]:alnum:]]+ designates [0-9a-f.:]{3,39} as permitted sender$
-^\w{3} [ :0-9]{11} [._[:alnum:]-]+ postfix/anvil\[[0-9]+\]: statistics: max (message|recipient|connection) (count|rate) [/[:digit:]s]+ for \(([.:[:xdigit:]]+)?(smtp(s)?|25|587):[.:[:xdigit:]]+\) at \w{3} [ :0-9]{11}$
+^\w{3} [ :0-9]{11} [._[:alnum:]-]+ postfix/anvil\[[0-9]+\]: statistics: max (message|recipient|connection) (count|rate) [/[:digit:]s]+ for \(([.:[:xdigit:]]+)?(smtp(s)?|25|submission|587):[.:[:xdigit:]]+\) at \w{3} [ :0-9]{11}$
^\w{3} [ :0-9]{11} [._[:alnum:]-]+ postfix/anvil\[[0-9]+\]: statistics: max cache size [[:digit:]]+ at \w{3} [ :0-9]{11}$
^\w{3} [ :0-9]{11} [._[:alnum:]-]+ postfix/scache\[[0-9]+\]: statistics: start interval \w{3} [ :0-9]{11}$
^\w{3} [ :0-9]{11} [._[:alnum:]-]+ postfix/scache\[[0-9]+\]: statistics: (domain|address) lookup hits=[0-9]+ miss=[0-9]+ success=[0-9]+%$
Bug#418449: submission entry for ignore.d.server/postfix
Here is an example of the event entries that prompted me to edit my postfix ignore, after I enabled postfix to listen to the submission port (tcp/587): System Events =-=-=-=-=-=-= Mar 3 13:31:27 aesop postfix/anvil[16286]: statistics: max connection rate 1/60s for (submission:69.153.32.239) at Mar 3 13:27:40 Mar 3 13:31:27 aesop postfix/anvil[16286]: statistics: max connection count 1 for (submission:69.153.32.239) at Mar 3 13:27:40 Kind Regards, Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#485681: Recommends unavailable package in Etch
Package: python-pysnmp4 Severity: important Version: 4.1.6a-1 A continuation of closed bug #377075 - the Etch version of python-pysnmp4_4.1.6a-1 has a Recommends on python-pysnmp4-apps. The package python-pysnmp4-apps is not available in Etch. Package: python-pysnmp4 Priority: optional Section: python Installed-Size: 824 Maintainer: Arnaud Fontaine [EMAIL PROTECTED] Architecture: all Version: 4.1.6a-1 Depends: python, python-support (= 0.2), libsmi2, libsmi2-common, python-pyasn1, python-pysnmp-common Recommends: python-crypto, python-pysnmp4-mibs, python-pysnmp4-apps Suggests: python-pysnmp4-doc Filename: pool/main/p/python-pysnmp4/python-pysnmp4_4.1.6a-1_all.deb ... [EMAIL PROTECTED]:/# apt-cache policy python-pysnmp4 python-pysnmp4: Installed: 4.1.6a-1 Candidate: 4.1.6a-1 Version table: 4.1.8a-1 0 400 http://ftp.us.debian.org testing/main Packages *** 4.1.6a-1 0 990 http://ftp.us.debian.org etch/main Packages 100 /var/lib/dpkg/status [EMAIL PROTECTED]:/# apt-cache policy python-pysnmp4-apps python-pysnmp4-apps: Installed: (none) Candidate: 0.2.6a-1 Version table: 0.2.6a-1 0 400 http://ftp.us.debian.org testing/main Packages Thanks for looking! -- Kind Regards, Michael Shuler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#443933: metacity window position also affected by font changes
Hello, I just wanted to concur on the top-left window stacking behavior in current testing metacity_2.22.0-1_i386, although I have not tried to kill/restart metacity or change it's startup priority. I am not certain of previous versions, since I used XFCE for quite a few years, and recently switched to a default install of Debian Lenny with gnome on one system. Saved sessions do not honor placement and stack all windows top-left. Opening of new applications or windows, of for instance iceweasel, all stack top-left. Seems kind of brain-dead. This window stacking appears to be the standard behavior of metacity from a bit of research I did [0], and this is the one serious annoyance I have testing out moving to gnome. [0] http://chad.glendenin.com/metacity/ -- Kind Regards, Michael Shuler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#605614: debian-installer: Ability to configure remote syslog
On 12/01/2010 02:06 PM, Ryan Lovett wrote: I would like to be able to configure debian-installer to log messages to a remote syslog server. I know that I can recover the log messages after installation is complete but it would be convenient for me to be able to monitor netbooted clients as they are installed. This is an interesting consideration, but as Christian pointed out, this would probably need to be a new d-i inclusion by someone interested enough to hack on and maintain such a feature. However, since I've done a few preseeded remote installs[0], I think you might be able to work with the existing network-console[1] and perhaps include your own syslog configuration and service restart via a preseed early_command script. Just a couple thoughts. [0] http://wiki.debian.org/DebianInstaller/Remote [1] http://wiki.debian.org/DebianInstaller/NetworkConsole -- Kind regards, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#538761: ITP: libnet-mosso-cloudfiles-perl -- Perl interface to Mosso CloudFiles service
Package: wnpp Severity: wishlist Owner: Michael Shuler mich...@pbandjelly.org * Package name: libnet-mosso-cloudfiles-perl Version : 0.43 Upstream Author : Léon Brocard l...@astray.com * URL : http://search.cpan.org/dist/Net-Mosso-CloudFiles/ * License : Perl (Artistic and GPL) Programming Lang: Perl Description : Perl interface to Mosso CloudFiles service Net::Mosso::CloudFiles provides a simple interface to the Mosso Cloud Files service. Cloud Files is reliable, scalable and affordable web-based storage for backing up and archiving all your static content. Find out more at http://www.mosso.com/cloudfiles.jsp. To use this module you will need to sign up to Mosso Cloud Files and provide a user and key. If you use this module, you will incurr costs as specified by Mosso. Please check the costs. If you use this module with your user and key you will be responsible for these costs. (This module will be maintained under the Debian Perl Group) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#569047: New mysql plugin does not function with default configuration
Package: munin-node
Version: 1.4.3-2
Severity: normal
Tags: + patch
I upgraded munin packages on several Lenny servers from 1.2.6 (Lenny) to
1.4.3 (Squeeze). I discovered the old mysql plugin note on the mysql
graphs and created the various plugin symlinks I wanted to use for the
new mysql plugin, while leaving the old mysql links intact, running both
old/new mysql plugins.
The the new /usr/share/munin/plugins/mysql_ plugin uses the DBD::Mysql
perl module (the old one uses mysqladmin), and testing out one of them
out, I got:
mshu...@bay:~$ sudo munin-run mysql_connections
DBI connect('mysql;mysql_connect_timeout=5','root',...) failed: Access
denied for user 'root'@'localhost' (using password: NO) at
/etc/munin/plugins/mysql_connections line 875
I added the following to [mysql*] in plugin-conf.d/munin-node:
env.mysqlconnection
DBI:mysql:mysql;mysql_read_default_file=/etc/mysql/debian.cnf
then received:
mshu...@bay:~$ sudo munin-run mysql_connections
DBI
connect('mysql;mysql_read_default_file=/etc/mysql/debian.cnf;mysql_connect_timeout=5','root',...)
failed: Access denied for user 'root'@'localhost' (using password: YES)
at /etc/munin/plugins/mysql_connections line 875
So the connection is still attempting user 'root' with the client
password of the debian-sys-maint user, which fails. One more env
addition that the new mysql plugin groks got me a successful run:
env.mysqluser debian-sys-maint
I am currently graphing both the old mysql and the new mysql2 graphs
successfully - the addition of the 2 lines to plugin-conf.d/munin-node
does not seem to interrupt the functionality of the old deprecated
plugin, if there are people that continue to use it. Some further
validation would be appreciated.
Patch attached.
--
Kind Regards,
Michael Shuler
--- debian/plugins.conf.orig 2010-02-09 08:54:14.0 -0600
+++ debian/plugins.conf 2010-02-09 10:23:26.704008243 -0600
@@ -76,7 +76,8 @@
[mysql*]
user root
env.mysqlopts --defaults-file=/etc/mysql/debian.cnf
-
+env.mysqluser debian-sys-maint
+env.mysqlconnection DBI:mysql:mysql;mysql_read_default_file=/etc/mysql/debian.cnf
[postfix_mailqueue]
user postfix
Bug#508376: rsyslog: /var/log/mail.log and /var/log/mail.info are identical
Package: rsyslog Version: 4.2.0-1 Severity: normal Tags: patch Hello, Just wanted to include that postfix mail logs are actually logged in triplicate, by default: 1) mail.log 2) mail.info, mail.warn, mail.err 3) syslog I attached a patch for rsyslog.conf that I am using to log mail.* only to mail.log -- Kind regards, Michael Shuler -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (700, 'testing'), (300, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.26-2-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages rsyslog depends on: ii libc6 2.9-23GNU C Library: Shared libraries ii lsb-base 3.2-23Linux Standard Base 3.2 init scrip ii zlib1g 1:1.2.3.3.dfsg-15 compression library - runtime Versions of packages rsyslog recommends: ii logrotate 3.7.7-3Log rotation utility Versions of packages rsyslog suggests: pn rsyslog-doc none (no description available) pn rsyslog-gnutlsnone (no description available) pn rsyslog-gssapinone (no description available) pn rsyslog-mysql | rsyslog-pgsql none (no description available) pn rsyslog-relp none (no description available) -- no debconf information --- /etc/rsyslog.conf.orig 2009-02-07 18:34:13.0 -0600 +++ /etc/rsyslog.conf 2009-08-08 21:47:24.0 -0500 @@ -53,7 +53,7 @@ # First some standard log files. Log by facility. # auth,authpriv.*/var/log/auth.log -*.*;auth,authpriv.none -/var/log/syslog +*.*;auth,authpriv.none;mail.none -/var/log/syslog #cron.*/var/log/cron.log daemon.* -/var/log/daemon.log kern.* -/var/log/kern.log @@ -65,9 +65,9 @@ # Logging for the mail system. Split it up so that # it is easy to write scripts to parse these files. # -mail.info -/var/log/mail.info -mail.warn -/var/log/mail.warn -mail.err /var/log/mail.err +#mail.info -/var/log/mail.info +#mail.warn -/var/log/mail.warn +#mail.err /var/log/mail.err # # Logging for INN news system.
Bug#543118: ITP: python-cloudfiles -- Python interface to Rackspace CloudFiles service
Package: wnpp Severity: wishlist Owner: Michael Shuler mich...@pbandjelly.org Package name: python-cloudfiles Version : 1.4.0 Upstream Author : Cloud Files cloudfi...@rackspacecloud.com URL : http://github.com/rackspace/python-cloudfiles/ License : MIT Programming Lang: Python Description : Python interface to Rackspace Cloud Files service python-cloudfiles provides a simple interface to the Rackspace Cloud Files service. Cloud Files is reliable, scalable and affordable web-based storage for backing up and archiving all your static content. Find out more at http://www.rackspacecloud.com/cloud_hosting_products/files. To use this module you will need to sign up to Rackspace Cloud Files and provide a user and key. If you use this module, you will incurr costs as specified by Rackspace. Please check the costs. If you use this module with your user and key you will be responsible for these costs. (This module will be maintained under the Debian Python Modules Team) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#574498: aiccu: Package upgrade fails in postinst
Package: aiccu Version: 20070115-12 Severity: important Upgrading from -11 to -12 hangs during postinst with defunct process hanging dist-upgrade: ... Setting up aiccu (20070115-12) ... Installing new version of config file /etc/init.d/aiccu ... Installing new version of config file /etc/default/aiccu ... Files /usr/share/aiccu/conf-templates/aiccu.conf and /etc/aiccu.conf differ _ ps: root 19064 0.0 0.9 22900 18864 pts/2S+ 10:20 0:00 | \_ apt-get dist-upgrade -V root 20883 0.0 0.3 9876 6984 pts/9Ss+ 10:25 0:00 | \_ /usr/bin/dpkg --status-fd 23 --configure module-init-tools aiccu libcurl3 curl dh-make libcurl3-gnutls libjpeg8 libjpeg-progs libmouse-perl libnet-ssleay-perl python-mako texlive-common texlive-base texlive-fonts-recommended texlive-fonts-recommended-doc texlive-generic-recommended texlive-latex-base texlive-latex-base-doc texlive-latex-recommended texlive-latex-recommended-doc texlive-luatex texlive-metapost texlive-metapost-doc xdg-utils root 20889 0.0 0.4 12656 9752 pts/9S+ 10:25 0:00 | \_ /usr/bin/perl -w /usr/share/debconf/frontend /var/lib/dpkg/info/aiccu.postinst configure 20070115-11 root 20924 0.0 0.0 0 0 pts/9Z+ 10:25 0:00 | \_ [aiccu.postinst] defunct I couldn't put my finger on exactly what section of the postinst might be at fault, but I'd be happy to downgrade/upgrade to test out any patches you might like to try out. -- Kind regards, Michael -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing'), (300, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.32-3-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages aiccu depends on: ii debconf [debconf-2.0] 1.5.28 Debian configuration management sy ii iproute 20100224-1 networking and traffic control too ii iputils-ping3:20071127-2 Tools to test the reachability of ii iputils-tracepath 3:20071127-2 Tools to trace the network path to ii libc6 2.10.2-6 Embedded GNU C Library: Shared lib ii libgnutls26 2.8.5-2 the GNU TLS library - runtime libr ii lsb-base3.2-23 Linux Standard Base 3.2 init scrip ii ucf 3.0025 Update Configuration File: preserv Versions of packages aiccu recommends: ii ntpdate 1:4.2.6+dfsg-1 client for setting system time fro aiccu suggests no packages. -- debconf information: * aiccu/username: MSJ18-SIXXS aiccu/notunnels: aiccu/badauth: * aiccu/tunnelname: T23440 aiccu/nobrokers: * aiccu/brokername: tic://tic.sixxs.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#602737: Failure to find iso image from thumb drive
On 11/07/2010 10:39 AM, Dr. David Alan Gilbert wrote: Nov 7 15:44:32 iso-scan: Mounted /dev/sdb for first pass Nov 7 15:44:32 iso-scan: Found ISO ./mini.iso on /dev/sdb Nov 7 15:44:32 kernel: [ 35.587459] ISO 9660 Extensions: Microsoft Joliet Level 3 Nov 7 15:44:32 kernel: [ 35.588958] ISO 9660 Extensions: RRIP_1991A Nov 7 15:44:32 iso-scan: Not a Debian ISO iso-scan found mini.iso, but the mini.iso does not contain a debian directory with the rest of the d-i udebs to continue installation. Please, try again with the netinst.iso on your USB key and I think you will get the results you would like - I use this method frequently :-) -- Kind regards, Michael Shuler -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#603409: r-cran-rcmdr: Rcmdr missing packages
Package: r-cran-rcmdr Version: 1.6-0-2 Severity: wishlist On first start of Rcmdr after installation, I was presented with a notification box with the following: The following packages used by Rcmdr are missing: leaps, Hmisc, aplpack Without these packages, some features will not be available. Install these packages? [Yes] [No] I selected no, as I am usually not fond of pulling in libraries outside of the system package manager. r-cran-hmisc is available in the Debian repository and a manual install of this package removes Hmisc from the warning notification, so a recommends (or depends) for r-cran-hmisc should be included. apt-cache searches for 'leaps' and 'aplpack' don't return any results, so it would be nice for these libraries to be packaged for Debian, if they are not included in some other R library - if they are, please recommend/depend on those packages as well. -- Kind regards, Michael -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (700, 'testing'), (300, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686-bigmem (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 Versions of packages r-cran-rcmdr depends on: ii libc6 2.11.2-7 Embedded GNU C Library: Shared lib ii r-base-core 2.11.1-6 GNU R core of statistical computat ii r-cran-abind 1.1.0-4GNU R abind multi-dimensional arra ii r-cran-car2.0-2-1GNU R Companion to Applied Regress ii r-cran-effects2.0.10-1 GNU R graphical and tabular effect ii r-cran-lmtest 0.9.27-1 GNU R package for diagnostic check ii r-cran-mgcv 1.6-2-1GNU R package for multiple paramet ii r-cran-multcomp 1.1-7-1GNU R package for multiple compari ii r-cran-mvtnorm0.9-92-1 GNU R package to compute multivari ii r-cran-relimp 1.0-1-3GNU R package for inference on rel ii r-cran-rgl0.91-1 GNU R package for three-dimensiona ii r-cran-sm 2.2-4.1-1 GNU R package for kernel smoothing ii r-cran-strucchange1.4-1-1GNU R package for structural chang r-cran-rcmdr recommends no packages. Versions of packages r-cran-rcmdr suggests: pn r-cran-rodbc none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#603409: (no subject)
I see there is an ITP for r-cran-aplpack - #588924 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#508019: trac-git: Defunct git processes left behind
Package: trac-git Version: 0.0.20080710-2 Severity: normal Unfortunately, I cannot pass along an example output of ps, but this issue was also found by others, and I found the upstream report and patch at http://trac-hacks.org/ticket/3675 fixed this issue for me. In addition to the packages below, I am using apache2 with mod_python to run trac. -- Kind Regards, Michael Shuler ii apache2 2.2.9-10 Apache HTTP Server metapackage ii apache2-mpm-worker 2.2.9-10 Apache HTTP Server - high speed threaded mod ii apache2-utils 2.2.9-10 utility programs for webservers ii apache2.2-common2.2.9-10 Apache HTTP Server common files ii libapache2-mod-python 3.3.1-5 Python-embedding module for Apache 2 -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.24-19-xen (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/bash Versions of packages trac-git depends on: ii git-core 1:1.5.6.5-1 fast, scalable, distributed revisi ii python 2.5.2-3 An interactive high-level object-o ii python-central 0.6.8 register and build utility for Pyt ii trac 0.11.1-2.1 Enhanced wiki and issue tracking s trac-git recommends no packages. trac-git suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#585154: general protection faults triggered by munin-graph
Awoke this morning to another fault (x2) and I've attached the log. -- Kind regards, Michael # This fault resulted in: # # root 2039 0.0 0.0 22168 1020 ?Ss Jun10 0:00 /usr/sbin/cron # root 15252 0.0 0.0 45292 1272 ?S02:55 0:00 \_ /USR/SBIN/CRON # munin15256 0.0 0.0 3888 556 ?Ss 02:55 0:00 \_ /bin/sh -c if [ -x /usr/bin/munin-cron ]; then /usr/bin/munin-cron; fi # munin15258 0.0 0.0 3888 540 ?S02:55 0:00 \_ /bin/sh /usr/bin/munin-cron # munin15891 0.0 0.1 107372 13604 ?SN 02:55 0:00 \_ /usr/bin/perl /usr/share/munin/munin-graph --cron # munin15899 0.0 0.0 0 0 ?DN 02:55 0:00 | \_ [munin-graph] # munin15892 0.0 0.0 5912 520 ?S02:55 0:00 \_ fgrep -v *** attempt to put segment in horiz list twice # # box rebooted at ~08:10 Jun 11 02:45:01 gaea /USR/SBIN/CRON[13808]: (root) CMD (if [ -x /etc/munin/plugins/apt_all ]; then /etc/munin/plugins/apt_all update 7200 12 /dev/null; elif [ -x /etc/munin/plugins/apt ]; then /etc/munin/plugins/apt update 7200 12 /dev/null; fi) Jun 11 02:45:01 gaea /USR/SBIN/CRON[13809]: (root) CMD (command -v debian-sa1 /dev/null debian-sa1 1 1) Jun 11 02:45:01 gaea /USR/SBIN/CRON[13810]: (munin) CMD (if [ -x /usr/bin/munin-cron ]; then /usr/bin/munin-cron; fi) Jun 11 02:50:01 gaea /USR/SBIN/CRON[14532]: (root) CMD (if [ -x /etc/munin/plugins/apt_all ]; then /etc/munin/plugins/apt_all update 7200 12 /dev/null; elif [ -x /etc/munin/plugins/apt ]; then /etc/munin/plugins/apt update 7200 12 /dev/null; fi) Jun 11 02:50:01 gaea /USR/SBIN/CRON[14533]: (munin) CMD (if [ -x /usr/bin/munin-cron ]; then /usr/bin/munin-cron; fi) Jun 11 02:55:01 gaea /USR/SBIN/CRON[15254]: (root) CMD (if [ -x /etc/munin/plugins/apt_all ]; then /etc/munin/plugins/apt_all update 7200 12 /dev/null; elif [ -x /etc/munin/plugins/apt ]; then /etc/munin/plugins/apt update 7200 12 /dev/null; fi) Jun 11 02:55:01 gaea /USR/SBIN/CRON[15255]: (root) CMD (command -v debian-sa1 /dev/null debian-sa1 1 1) Jun 11 02:55:01 gaea /USR/SBIN/CRON[15256]: (munin) CMD (if [ -x /usr/bin/munin-cron ]; then /usr/bin/munin-cron; fi) Jun 11 02:55:12 gaea kernel: [57509.073252] general protection fault: [#1] SMP Jun 11 02:55:12 gaea kernel: [57509.073256] last sysfs file: /sys/devices/system/cpu/cpu3/cpufreq/stats/time_in_state Jun 11 02:55:12 gaea kernel: [57509.073258] CPU 1 Jun 11 02:55:12 gaea kernel: [57509.073259] Modules linked in: ppdev lp parport tun sit tunnel4 xt_multiport iptable_filter ip_tables x_tables powernow_k8 cpufreq_powersave cpufreq_userspace cpufreq_stats cpufreq_conservative binfmt_misc vboxnetadp vboxnetflt vboxdrv fuse nfsd nfs lockd fscache nfs_acl auth_rpcgss sunrpc xfs exportfs it87 hwmon_vid loop firewire_sbp2 snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event nouveau snd_seq ttm drm_kms_helper snd_timer snd_seq_device drm i2c_algo_bit snd soundcore i2c_piix4 edac_core snd_page_alloc edac_mce_amd i2c_core pcspkr evdev xhci tpm_tis tpm tpm_bios button processor ext3 jbd mbcache raid456 async_raid6_recov async_pq raid6_pq async_xor xor async_memcpy async_tx raid1 md_mod sr_mod cdrom usbhid sd_mod crc_t10dif ata_generic firewire_ohci firewire_core sg hid pata_jmicron ohci_hcd r8169 crc_itu_t ehci_hcd pata_atiixp ahci mii libata usbcore nls_base thermal thermal_sys scsi_m Jun 11 02:55:12 gaea kernel: od [last unloaded: scsi_wait_scan] Jun 11 02:55:12 gaea kernel: [57509.073300] Pid: 15899, comm: munin-graph Not tainted 2.6.32-5-amd64 #1 GA-790XTA-UD4 Jun 11 02:55:12 gaea kernel: [57509.073302] RIP: 0010:[810ee7b3] [810ee7b3] sys_write+0x29/0x6e Jun 11 02:55:12 gaea kernel: [57509.073308] RSP: 0018:8802007a1f48 EFLAGS: 00010282 Jun 11 02:55:12 gaea kernel: [57509.073309] RAX: f7ff8801f48cee40 RBX: f7ff8801f48cee40 RCX: 7672657320646568 Jun 11 02:55:12 gaea kernel: [57509.073311] RDX: 88022f065350 RSI: 8802007a1f5c RDI: f7ff8801f48cee40 Jun 11 02:55:12 gaea kernel: [57509.073312] RBP: fff7 R08: 0a2934202a206365 R09: 706172472032313a Jun 11 02:55:12 gaea kernel: [57509.073314] R10: 7672657320646568 R11: 0246 R12: 0038 Jun 11 02:55:12 gaea kernel: [57509.073315] R13: 024bb660 R14: 0038 R15: 024bb660 Jun 11 02:55:12 gaea kernel: [57509.073317] FS: 7f2fb8a7f6f0() GS:880008c8() knlGS: Jun 11 02:55:12 gaea kernel: [57509.073318] CS: 0010 DS: ES: CR0: 80050033 Jun 11 02:55:12 gaea kernel: [57509.073320] CR2: 7f2fb8634260 CR3: 0002004fc000 CR4: 06e0 Jun 11 02:55:12 gaea kernel: [57509.073321] DR0: DR1: DR2: Jun 11 02:55:12 gaea kernel: [57509.073323] DR3:
Bug#585154: general protection faults triggered by munin-graph
I see Holger marked this bug as unreproducible - that's a good thing, but would anyone have any suggestions on how I might track this down to an actual cause? At this point, it's a bit of a mystery on where I might look next.. Thanks! Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#585154: general protection faults triggered by munin-graph
Package: munin Version: 1.4.4-1 Severity: normal Tags: squeeze I have logged 4 kernel general protection faults from 2010.03.04 through 2010.06.09 which all seem to have a pattern of being triggered by munin-graph runs. This is a testing (Squeeze) box updated daily with no other issues - I've run a few cycles of memtest and cpuburn over the past few months to see if hardware was a problem, which all pass. The munin versions may vary between the above dates and the fault logs are dated-timed. I'd be happy to provide any additional information or try any other testing - this one is a bit of a mystery to me, but due to the process pattern during the fault, I'm opening under munin. Kind regards, Michael Shuler -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (700, 'testing'), (300, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-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 Versions of packages munin depends on: ii adduser 3.112 add and remove users and groups ii cron 3.0pl1-111 process scheduling daemon pn libdigest-md5-perlnone (no description available) ii libhtml-template-perl 2.9-1 HTML::Template : A module for usin ii liblog-log4perl-perl 1.28-1 A Perl port of the widely popular ii librrds-perl 1.4.3-1time-series data storage and displ pn libstorable-perl none (no description available) ii munin-common 1.4.4-1network-wide graphing framework (c ii perl [libtime-hires-perl] 5.10.1-12 Larry Wall's Practical Extraction ii perl-modules 5.10.1-12 Core Perl modules ii rrdtool 1.4.3-1time-series data storage and displ ii ttf-dejavu2.30-2 Metapackage to pull in ttf-dejavu- Versions of packages munin recommends: ii libdate-manip-perl6.07-2 module for manipulating dates ii munin-node1.4.4-1network-wide graphing framework (n Versions of packages munin suggests: ii epiphany-browser [www-browser 2.30.2-2 Intuitive GNOME web browser ii iceweasel [www-browser] 3.5.9-3Web browser based on Firefox ii nginx [httpd] 0.7.65-6 small, but very powerful and effic ii w3m [www-browser] 0.5.2-4WWW browsable pager with excellent -- no debconf information # This fault resulted in many hung 'ps' processes started by subsequent munin # runs after the fault and load of 50+ when rebooted @21:31:26. Sorry no # additional data - box was pretty unresponsive, and I needed to get some work # done ;) Mar 24 19:40:01 gaea /USR/SBIN/CRON[25777]: (munin) CMD (if [ -x /usr/bin/munin-cron ]; then /usr/bin/munin-cron; fi) Mar 24 19:40:01 gaea /USR/SBIN/CRON[25779]: (root) CMD (if [ -x /etc/munin/plugins/apt_all ]; then /etc/munin/plugins/apt_all update 7200 12 /dev/null; elif [ -x /etc/munin/plugins/apt ]; then /etc/munin/plugins/apt update 7200 12 /dev/null; fi) Mar 24 19:45:01 gaea /USR/SBIN/CRON[27516]: (munin) CMD (if [ -x /usr/bin/munin-cron ]; then /usr/bin/munin-cron; fi) Mar 24 19:45:01 gaea /USR/SBIN/CRON[27517]: (root) CMD (command -v debian-sa1 /dev/null debian-sa1 1 1) Mar 24 19:45:01 gaea /USR/SBIN/CRON[27518]: (root) CMD (if [ -x /etc/munin/plugins/apt_all ]; then /etc/munin/plugins/apt_all update 7200 12 /dev/null; elif [ -x /etc/munin/plugins/apt ]; then /etc/munin/plugins/apt update 7200 12 /dev/null; fi) Mar 24 19:45:13 gaea kernel: [43448.696729] general protection fault: [#1] SMP Mar 24 19:45:13 gaea kernel: [43448.696733] last sysfs file: /sys/devices/system/cpu/cpu3/cpufreq/stats/time_in_state Mar 24 19:45:13 gaea kernel: [43448.696735] CPU 1 Mar 24 19:45:13 gaea kernel: [43448.696736] Modules linked in: ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 ppdev lp parport sco bridge stp bnep rfcomm l2cap crc16 bluetooth rfkill sit tunnel4 tun xt_multiport iptable_filter ip_tables x_tables vboxnetflt vboxnetadp vboxdrv powernow_k8 cpufreq_powersave cpufreq_userspace cpufreq_stats cpufreq_conservative binfmt_misc fuse nfsd nfs lockd fscache nfs_acl auth_rpcgss sunrpc it87 hwmon_vid loop firewire_sbp2 xfs exportfs snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device i2c_piix4 xhci snd edac_core i2c_core pcspkr evdev edac_mce_amd soundcore snd_page_alloc processor ext3 jbd mbcache raid456 async_raid6_recov async_pq usbhid hid raid6_pq async_xor xor async_memcpy async_tx raid1 md_mod ide_cd_mod cdrom ohci_hcd ata_generic ide_pci_generic firewire_ohci firewire_core sg sd_mod c rc_t10dif pata_jmicron ehci_hcd crc Mar 24 19:45:13 gaea kernel: _itu_t r8169 mii atiixp ide_core ahci
Bug#585625: linux-image-2.6 2.6.32-19 works for me
On 08/16/2010 09:49 PM, Ben Hutchings wrote: Is i915 also working for you in this version? Yes, i915 started working correctly for me with 2.6.32-19 (currently using 2.6.32-20 with i915 successfully). Andrew pointed me to this bug at DebConf10 - I had just purchased a ThinkPad X201, installed Squeeze a few days before heading to NYC, and was forced to use vesa for any video. Using the older 2.6.32-9 kernel allowed use of i915 instead of vesa, and starting with 2.6.32-19 I can use i915. Thanks! -- Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#585625: linux-image-2.6 2.6.32-19 works for me
I am tracking Squeeze and yesterday installed linux-image-2.6.32-5-686-bigmem version 2.6.32-19 from Sid on a Lenovo ThinkPad X201 with the identical video chipset as listed by Andrew in #585910 - so far, version 2.6.32-19 is working well for me and I thought I would pass along my success. -- Kind regards, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#546629: nginx_0.6.32-3+lenny2_i386 uninstallable because of libpcre3 (= 7.7)
Package: nginx Version: 0.6.32-3+lenny2 Severity: grave Justification: renders package unusable Security release of nginx on i386 is uninstallable (amd64 is ok on the 64-bit machines I have) mshu...@linode:~$ apt-cache policy nginx nginx: Installed: 0.6.32-3 Candidate: 0.6.32-3+lenny2 Version table: 0.6.32-3+lenny2 0 900 http://security.debian.org lenny/updates/main Packages *** 0.6.32-3 0 900 http://ftp.us.debian.org lenny/main Packages 100 /var/lib/dpkg/status mshu...@linode:~$ sudo apt-get install nginx=0.6.32-3+lenny2 Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: nginx: Depends: libpcre3 (= 7.7) but 7.6-2.1 is to be installed E: Broken packages Thanks, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#546629: thank you
nginx_0.6.32-3+lenny2+b1_i386 installs fine Thanks to all for the rebuild and quick release. Kind regards, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#464345: pgpool2 packaging
Hello, There are a couple of interested parties currently working on pgpool2 packaging - myself and Rodolphe Quiédeville are in touch on the pkg-postgresql-public mailing list, and we'll work together to get a clean, current package uploaded soon. I also CC'ed Andreas Putzo, the current owner of ITA #471826, on a list message regarding this ITA [0] to see what his plans might be. [0] http://lists.alioth.debian.org/pipermail/pkg-postgresql-public/2009-October/000471.html -- Kind regards, Michael Shuler signature.asc Description: OpenPGP digital signature
Bug#624203: verbose iproute makes vpnc fail connecting
Package: vpnc
Version: 0.5.3r449-2.1
Followup-For: Bug #624203
Since the previous report did not contain any details, I'll use this for the
connection issue I just encountered and found a fix for. I'm not really sure
if this is the identical problem Pedro found, but perhaps.. :-)
'ip route get ...' now adds a few more extra morsels of data that
vpnc-script does not take into account. The credit for the sed fix goes to
Alessandro Suardi and was found at: https://lkml.org/lkml/2011/3/24/645
The error when using vpnc-script (I'm actually using openconnect) was:
...
Got CONNECT response: HTTP/1.1 200 OK
CSTP connected. DPD 30, Keepalive 20
Error: either to is duplicate, or ipid is a garbage.
Connected cscotun0 as 192.168.101.178, using SSL
Continuing in background; pid 1328
Established DTLS connection
The routes pushed from the concentrator are set up fine, but the static route
for the concentrator IP address was not set, due to the extra data not being
correct for 'ip route add ...'
After the attached sed line fix, I get a static route for the concentrator
again.
Kind regards,
Michael Shuler
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (400, 'testing'), (300, 'unstable'), (100, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.39-1-686-pae (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages vpnc depends on:
ii libc62.13-4 Embedded GNU C Library: Shared lib
ii libgcrypt11 1.4.6-5 LGPL Crypto library - runtime libr
ii libgnutls26 2.10.5-1+b1 the GNU TLS library - runtime libr
Versions of packages vpnc recommends:
ii iproute 20110315-1 networking and traffic control too
Versions of packages vpnc suggests:
ii resolvconf1.48 name server information handler
-- Configuration Files:
/etc/vpnc/example.conf [Errno 13] Permission denied: u'/etc/vpnc/example.conf'
/etc/vpnc/vpnc-script [Errno 13] Permission denied: u'/etc/vpnc/vpnc-script'
-- no debconf information
--- /etc/vpnc/vpnc-script.orig 2010-03-20 23:08:13.0 -0500
+++ /etc/vpnc/vpnc-script 2011-06-07 19:09:22.0 -0500
@@ -116,7 +116,7 @@
if [ -n $IPROUTE ]; then
fix_ip_get_output () {
- sed 's/cache//;s/metric \?[0-9]\+ [0-9]\+//g;s/hoplimit
[0-9]\+//g'
+ sed 's/cache//;s/metric \?[0-9]\+ [0-9]\+//g;s/hoplimit
[0-9]\+//g;s/ipid 0x//g'
}
set_vpngateway_route() {
Bug#588219: ca-certificate's maintenance
On 09/07/2011 06:49 PM, Raphael Geissert wrote: Stefan doesn't seem to be active, at least regarding the adoption of ca-certs. I have not received a reply from Stefan, either. Michael: Thijs and I are interested in maintaining ca-certificates. What were your plans regarding its maintenance? I would like to help :-) I pulled the latest git repo that I could find (which was quite a few releases behind) and committed the last couple releases to have a place to start. I emailed Philipp Kern and asked if he had a repository that was more current, and again about a week ago to ask a couple other questions about his ideas on redesigning the package, which he mentioned in an email, but I haven't heard back (I know he's crazy busy :-) ). I've worked a bit on a local clone, working thru some of the existing bugs and I've been looking at how ca-certificates is used in other reverse dependencies. I've sort of been waiting to see if there is another repo to start with, before going too far and needing to rewrite lots of history. I think we should setup a git repo in collab-maint or something. I also just asked to be added to collab-maint for precisely the same reason - I think it would be a good place for maintenance of the package. My repo is a clone of pkern's with the last couple versions commited on top: http://anonscm.debian.org/gitweb/?p=users/mshuler-guest/ca-certificates.git -- Kind regards, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#597537: Looking for seconds to add the Amazon EC2 public certificate in ca-certificates.
On 08/22/2011 10:56 PM, Russ Allbery wrote: Charles Plessy ple...@debian.org writes: as per /usr/share/doc/ca-certificates/README.Debian, I am looking for additional signed recommendations for the addition of the Amazon Elastic Computer Cloud (EC2) public certificate to the ca-certificates packages. As someone not particularly familiar with the details of how certs work inside EC2, my main question would be: what's the signing policy used by the holder of the private key for this certificate? This is also my question - is this a CA that will be verifying and signing other certs? (I'll try to dig on the same info, as well) For the record, I intend to adopt ca-certificates relatively soon, as I have not heard back from the previous ITA poster in a few weeks. The package needs some TLC and I have some updates already queued up, but not pushed to my git repo, yet :-) -- Kind regards, Michael signature.asc Description: OpenPGP digital signature
Bug#588219: ca-certificate's maintenance
On 09/16/2011 01:21 AM, Raphael Geissert wrote: I don't think that some bits of vcs history should become a blocker. Let's better work with what we already have at hand. This sounds acceptable, but I thought of using snapshot.d.o to see if I could fill in some history, and I have some time Saturday to work on this. I think we should setup a git repo in collab-maint or something. I also just asked to be added to collab-maint for precisely the same reason - I think it would be a good place for maintenance of the package. I see that you've been added already, great. I init'ed collab-maint/ca-certificates, but I would like to see if I can at least fill in the release history, as mentioned above. A couple of questions: Have you already subscribed to the PTS? I am, now - thank you for the reminder. Do you have some experience in X.509 certificates, SSL/TLS, or the like? As a customer support and systems engineer at Rackspace (I no longer work there), I dealt with various Certificate Authorities regularly, on behalf of customers, set up various software to use SSL/TLS, troubleshoot problems, etc. While I would not consider myself a cryptography expert, I am familiar with the workings and the field interests me. Unless somebody has a different opinion, I think we should first: a) Clean-up the packaging, It is a bit out of date and it leads to a few warnings during the package build. b) Triage the bug reports, marking as 'confirmed' those that we consider valid and that should be fixed relatively soon. All certificate inclusion requests should be left on hold. This is what I had started working on - I started picking off some low-hanging fruit: packaging clean up start, po updates, etc. I'd like to find and fill in the few missing releases in git first, that would make me happy, then merge some of the changes I made. -- Kind regards, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#588219: ca-certificate's maintenance
On 09/16/2011 07:08 AM, Michael Shuler wrote: On 09/16/2011 01:21 AM, Raphael Geissert wrote: I init'ed collab-maint/ca-certificates, but I would like to see if I can at least fill in the release history, as mentioned above. I pulled all the missing releases from snapshot.d.o and imported them to the collab-maint/ca-certificates repository: git+ssh://git.debian.org/git/collab-maint/ca-certificates.git Clone away! Unless somebody has a different opinion, I think we should first: a) Clean-up the packaging, It is a bit out of date and it leads to a few warnings during the package build. b) Triage the bug reports, marking as 'confirmed' those that we consider valid and that should be fixed relatively soon. All certificate inclusion requests should be left on hold. I stashed my previous updates and I will see if I can find some additional time this weekend to push them to my ca-certificates repository and get someone to take a look at them. I haven't looked at many other collab-maint repos to get an idea of what branches might be needed - there is currently only master. -- Kind regards, Michael Shuler -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#588219: ITA - ca-certificates -- Common CA certificates
Hello Stefan, I would like to take over this ITA, since the package needs some care. I am starting to work on updates, today, so please, reply to #588219 if you intend to follow through with the adoption and we can merge some work, if you like. Kind regards, Michael Shuler signature.asc Description: OpenPGP digital signature
Bug#624182: ca-certificates: option --fresh not passed down to hook scripts
tags 624182 + moreinfo thanks Torsten, Is this actually still an issue? I see that the java keystore is getting fully updated with -f/--fresh when I was testing. Thanks! -- Kind regards, Michael mshuler@mana:~$ sudo update-ca-certificates Updating certificates in /etc/ssl/certs... 0 added, 0 removed; done. Running hooks in /etc/ca-certificates/update.d done. done. mshuler@mana:~$ sudo update-ca-certificates -f Clearing symlinks in /etc/ssl/certs...done. Updating certificates in /etc/ssl/certs... 151 added, 0 removed; done. Running hooks in /etc/ca-certificates/update.d Replacing debian:cacert.org.pem Replacing debian:ca.pem Replacing debian:ACEDICOM_Root.pem ...snip... Replacing debian:XRamp_Global_CA_Root.pem Replacing debian:spi-ca-2003.pem Replacing debian:spi-cacert-2008.pem Replacing debian:EC-ACC.pem Replacing debian:Hellenic_Academic_and_Research_Institutions_RootCA_2011.pem Replacing debian:Security_Communication_RootCA2.pem done. done. mshuler@mana:~$ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#680077: Net::DNS::Header::data: no such method at /usr/share/perl5/Net/DNS/Fingerprint.pm line 669
Package: fpdns Version: 0.9.3-4 Severity: important Hello, Apologies for not digging up a fix and patch, but time does not permit at the moment. I use fpdns only occasionally for curiosity and it is currently not working at all for me (thus, important severity): $ fpdns -d ns1.linode.com == PROCESS 69.93.127.10:53 0,IQUERY,0,0,1,0,0,0,NOERROR,0,0,0,0 . IN A Net::DNS::Header::data: no such method at /usr/share/perl5/Net/DNS/Fingerprint.pm line 669 $ -- Kind regards, Michael Shuler -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'testing'), (100, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.2.0-3-686-pae (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 Versions of packages fpdns depends on: ii libio-socket-inet6-perl 2.69-2 ii libnet-dns-fingerprint-perl 0.9.3-4 fpdns recommends no packages. fpdns suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#680077: Net::DNS::Header::data: no such method at /usr/share/perl5/Net/DNS/Fingerprint.pm line 669
On 07/03/2012 01:01 PM, Thorsten Alteholz wrote: I am using a fresh Sid VM and unfortunately get the following output: What version of libnet-dns-perl on that Sid VM? I run Sid and this appears to be the issue. With the version in testing (0.66-2+b2) fpdns works - with the version in Sid (0.68-1) fpdns breaks. I've attached some details. Not sure when 0.68-1 was uploaded, if it will migrate to Wheezy under the freeze.. (changelog was written Sat, 30 Jun 2012 17:11:59 +0200) -- Kind regards, Michael mshuler@mana:~$ apt-cache policy libnet-dns-perl libnet-dns-perl: Installed: 0.68-1 Candidate: 0.68-1 Version table: *** 0.68-1 0 900 http://ftp.us.debian.org/debian/ unstable/main i386 Packages 100 /var/lib/dpkg/status 0.66-2+b2 0 800 http://ftp.us.debian.org/debian/ testing/main i386 Packages mshuler@mana:~$ sudo apt-get install libnet-dns-perl=0.66-2+b2 Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be DOWNGRADED: libnet-dns-perl 0 upgraded, 0 newly installed, 1 downgraded, 0 to remove and 0 not upgraded. Need to get 298 kB of archives. After this operation, 32.8 kB disk space will be freed. Do you want to continue [Y/n]? Get:1 http://ftp.us.debian.org/debian/ testing/main libnet-dns-perl i386 0.66-2+b2 [298 kB] Fetched 298 kB in 2s (101 kB/s) dpkg: warning: downgrading libnet-dns-perl from 0.68-1 to 0.66-2+b2 (Reading database ... 186658 files and directories currently installed.) Preparing to replace libnet-dns-perl 0.68-1 (using .../libnet-dns-perl_0.66-2+b2_i386.deb) ... Unpacking replacement libnet-dns-perl ... Processing triggers for man-db ... Setting up libnet-dns-perl (0.66-2+b2) ... mshuler@mana:~$ fpdns ns.rackspace.com fingerprint (ns.rackspace.com, 69.20.95.4): ISC BIND 9.2.3rc1 -- 9.6.1-P1 mshuler@mana:~$ fpdns ns1.linode.com fingerprint (ns1.linode.com, 69.93.127.10): ISC BIND 9.2.3rc1 -- 9.6.1-P1 fingerprint (ns1.linode.com, 2600:3c00:0:0:0:0:0:a): ISC BIND 9.2.3rc1 -- 9.6.1-P1 mshuler@mana:~$ sudo apt-get install libnet-dns-perl Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be upgraded: libnet-dns-perl 1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 314 kB of archives. After this operation, 32.8 kB of additional disk space will be used. Get:1 http://ftp.us.debian.org/debian/ unstable/main libnet-dns-perl i386 0.68-1 [314 kB] Fetched 314 kB in 3s (88.7 kB/s) Reading changelogs... Done (Reading database ... 186652 files and directories currently installed.) Preparing to replace libnet-dns-perl 0.66-2+b2 (using .../libnet-dns-perl_0.68-1_i386.deb) ... Unpacking replacement libnet-dns-perl ... Processing triggers for man-db ... Setting up libnet-dns-perl (0.68-1) ... mshuler@mana:~$ fpdns ns.rackspace.com Net::DNS::Header::data: no such method at /usr/share/perl5/Net/DNS/Fingerprint.pm line 669 mshuler@mana:~$
Bug#624182: ca-certificates: option --fresh not passed down to hook scripts
Torsten, Might you have possibly added something to ca-certificates-java that is waiting to be passed a --fresh env variable? I'm working on an upload to fix a few other items and thought if there is and env var we can agree on, I might get it squeezed in for this update. CA_CERT_FRESH=true perhaps? -- Kind regards, Michael Shuler -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682125: ca-certificates: removes directories that were installed by another package: /etc/ssl/certs/
Thanks for the bug report, Andreas. I'll get this updated and tested as soon as I can. Kind regards, Michael Shuler signature.asc Description: OpenPGP digital signature
Bug#682125: ca-certificates: removes directories that were installed by another package: /etc/ssl/certs/
I recalled seeing this commit in the log - this bit of code was added to
please piuparts (see bug #454334), and piuparts is still angry? :)
--
(master)mshuler@mana:~/repos/git/ca-certificates$ git log -1
dfbc841749d7e8d0036d6ac0d6966f4efb8cdaa7
commit dfbc841749d7e8d0036d6ac0d6966f4efb8cdaa7
Author: Philipp Kern pk...@debian.org
Date: Thu Nov 27 18:18:48 2008 +0100
Remove /etc/ssl{,/certs} in postrm to please piuparts. (Closes:
#454334)
piuparts purges openssl first, which leaves `/etc/ssl/certs' on the
system. There was already a workaround for #454334 in place, but this
only covered `/etc/ssl', which was not removable due to `/etc/ssl/certs'
still in place.
(master)mshuler@mana:~/repos/git/ca-certificates$ git diff
7776067d434b7813470c23207d0185ae056a70be
dfbc841749d7e8d0036d6ac0d6966f4efb8cdaa7
diff --git a/debian/postrm b/debian/postrm
index 260a1c4..e4feb3e 100644
--- a/debian/postrm
+++ b/debian/postrm
@@ -28,8 +28,12 @@ case $1 in
purge)
rm -f /etc/ssl/certs/ca-certificates.crt*
- # Fix for #454334
- rmdir --ignore-fail-on-non-empty /etc/ssl
+
+ # Clean up even if openssl is removed before ca-certificates.
+ # (Which is what piuparts does.)
+ [ -d /etc/ssl/certs ] rmdir --ignore-fail-on-non-empty
/etc/ssl/certs
+ [ -d /etc/ssl ] rmdir --ignore-fail-on-non-empty /etc/ssl
+
rm -f /etc/ca-certificates.conf*
if test -e /usr/share/debconf/confmodule; then
. /usr/share/debconf/confmodule
(master)mshuler@mana:~/repos/git/ca-certificates$
--
In looking at #316521, I can understand this might be the problem. I'll
test out what happens with no explicit rmdir's in postinst and let dpkg
deal with the contents of debian/dirs.
--
Kind regards,
Michael Shuler
signature.asc
Description: OpenPGP digital signature
Bug#682125: ca-certificates: removes directories that were installed by another package: /etc/ssl/certs/
Andreas, this bug report would have much more helpful if it had included
an explanation that the piuparts version used to generate the provided
log was a patched version that is not available in the debian archives.
It took me a little bit to figure this out.
Since I don't have the version of piuparts used to report the bug, I am
unable to recreate the error, nor test that the removal of the directory
deletes satisfies your patched version of piuparts. Quite the opposite.
The latest piuparts (0.45) in archive reports success with the existing
ca-certificates_20120623, and of course, reports an error when those
rmdir lines are removed.. The diff and logs are attached.
I'm tempted to set #316521 as a blocker to this bug.
Andreas, if you would be so kind as to perhaps upload your patched
version of piuparts to experimental or somewhere else, I might be able
to do the needful. Or you could pull ca-certificates_20120721 from my
repository and report back that it passes, perhaps?
http://www.pbandjelly.org/debian/ca-certificates_20120721_all.deb
--
Kind regards,
Michael Shuler
diff --git a/debian/changelog b/debian/changelog
index 7736538..89d7d03 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,4 +1,4 @@
-ca-certificates (20120710) UNRELEASED; urgency=low
+ca-certificates (20120721) UNRELEASED; urgency=low
* Update mozilla/certdata.txt to version 1.85
Certificates added (+) (none removed):
@@ -8,8 +8,11 @@ ca-certificates (20120710) UNRELEASED; urgency=low
+ StartCom Certification Authority G2
+ Buypass Class 2 Root CA
+ Buypass Class 3 Root CA
+ * Correct piuparts package remove/purge behavior Closes: #682125
+- Remove deletes of /etc/ssl{,/certs} from debian/postrm
+- Add etc/ssl to debian/dirs
- -- Michael Shuler mich...@pbandjelly.org Tue, 10 Jul 2012 14:05:27 -0500
+ -- Michael Shuler mich...@pbandjelly.org Sat, 21 Jul 2012 09:54:25 -0500
ca-certificates (20120623) unstable; urgency=low
diff --git a/debian/dirs b/debian/dirs
index b64bbd3..840b840 100644
--- a/debian/dirs
+++ b/debian/dirs
@@ -1,3 +1,4 @@
+etc/ssl
etc/ssl/certs
usr/sbin
usr/share/ca-certificates/
diff --git a/debian/postrm b/debian/postrm
index 9b3c29c..11759fe 100644
--- a/debian/postrm
+++ b/debian/postrm
@@ -46,12 +46,6 @@ case $1 in
purge)
rm -f /etc/ssl/certs/ca-certificates.crt
remove_dangling_symlinks
-
-# Clean up even if openssl is removed before ca-certificates.
-# (Which is what piuparts does.)
-[ -d /etc/ssl/certs ] rmdir --ignore-fail-on-non-empty /etc/ssl/certs
-[ -d /etc/ssl ] rmdir --ignore-fail-on-non-empty /etc/ssl
-
rm -f /etc/ca-certificates.conf*
;;
ca-certificates_20120623-piuparts_0.45.log.gz
Description: application/gzip
ca-certificates_20120721-piuparts_0.45.log.gz
Description: application/gzip
signature.asc
Description: OpenPGP digital signature
Bug#501123: ca-certificates should be in squeeze-updates
retitle 501123 ca-certificates should be in squeeze-updates
thanks
Hi all. Considering the retirement of volatile, I changed the title. I
think it is a good idea to keep ca-certificates updated in
${stable}-updates from here on out. I have some additional work to get
ca-certificates in decent shape, but plan on uploading to
squeeze-updates when we're at a good place with some upgrade testing done.
Would it make sense to use backports as a sort-of stable-experimental
testing ground before upload to ${stable}-updates? Thanks!
--
Kind regards,
Michael Shuler
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#646767: ca-certificates: Please, remove gouv.fr/cert_igca_rsa.crt - IGC_A.pem RSA CA now included in mozilla bundle
Package: ca-certificates Version: 20111025 Severity: normal (and, please, research whether the DSA CA cert should also be removed) The French government RSA/DSA CA certs were added in version 20080617 (#416470). At some point the same RSA CA cert (IGC_A.crt, below) was included in mozilla bundle, which was updated in version 20110421, so we now see a duplicate warning on package upgrade and --fresh update: $ sudo update-ca-certificates --fresh Clearing symlinks in /etc/ssl/certs...done. Updating certificates in /etc/ssl/certs... WARNING: Skipping duplicate certificate cert_igca_rsa.pem WARNING: Skipping duplicate certificate cert_igca_rsa.pem 164 added, 0 removed; done. Running hooks in /etc/ca-certificates/update.ddone. $ -- Kind regards, Michael Shuler -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (300, 'unstable'), (100, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.0.0-2-686-pae (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 Versions of packages ca-certificates depends on: ii debconf [debconf-2.0] 1.5.41 ii openssl1.0.0e-2 ca-certificates recommends no packages. ca-certificates suggests no packages. -- debconf information: ca-certificates/title: * ca-certificates/enable_crts: brasil.gov.br/brasil.gov.br.crt, cacert.org/cacert.org.crt, debconf.org/ca.crt, gouv.fr/cert_igca_dsa.crt, gouv.fr/cert_igca_rsa.crt, mozilla/ACEDICOM_Root.crt, mozilla/AC_Raíz_Certicámara_S.A..crt, mozilla/AddTrust_External_Root.crt, mozilla/AddTrust_Low-Value_Services_Root.crt, mozilla/AddTrust_Public_Services_Root.crt, mozilla/AddTrust_Qualified_Certificates_Root.crt, mozilla/AffirmTrust_Commercial.crt, mozilla/AffirmTrust_Networking.crt, mozilla/AffirmTrust_Premium.crt, mozilla/AffirmTrust_Premium_ECC.crt, mozilla/America_Online_Root_Certification_Authority_1.crt, mozilla/America_Online_Root_Certification_Authority_2.crt, mozilla/ApplicationCA_-_Japanese_Government.crt, mozilla/A-Trust-nQual-03.crt, mozilla/Autoridad_de_Certificacion_Firmaprofesional_CIF_A62634068.crt, mozilla/Baltimore_CyberTrust_Root.crt, mozilla/Buypass_Class_2_CA_1.crt, mozilla/Buypass_Class_3_CA_1.crt, mozilla/CA_Disig.crt, mozilla/Camerfirma_Chambers_of_Commerce_Root .crt, mozilla/Camerfirma_Global_Chambersign_Root.crt, mozilla/Certigna.crt, mozilla/Certinomis_-_Autorité_Racine.crt, mozilla/Certplus_Class_2_Primary_CA.crt, mozilla/certSIGN_ROOT_CA.crt, mozilla/Certum_Root_CA.crt, mozilla/Certum_Trusted_Network_CA.crt, mozilla/Chambers_of_Commerce_Root_-_2008.crt, mozilla/CNNIC_ROOT.crt, mozilla/Comodo_AAA_Services_root.crt, mozilla/COMODO_Certification_Authority.crt, mozilla/COMODO_ECC_Certification_Authority.crt, mozilla/Comodo_Secure_Services_root.crt, mozilla/Comodo_Trusted_Services_root.crt, mozilla/ComSign_CA.crt, mozilla/ComSign_Secured_CA.crt, mozilla/Cybertrust_Global_Root.crt, mozilla/Deutsche_Telekom_Root_CA_2.crt, mozilla/DigiCert_Assured_ID_Root_CA.crt, mozilla/DigiCert_Global_Root_CA.crt, mozilla/DigiCert_High_Assurance_EV_Root_CA.crt, mozilla/Digital_Signature_Trust_Co._Global_CA_1.crt, mozilla/Digital_Signature_Trust_Co._Global_CA_3.crt, mozilla/DST_ACES_CA_X6.crt, mozilla/DST_Root_CA_X3.crt, mozilla/EBG_Elektronik_Sertif ika_Hizmet_Sağlayıcısı.crt, mozilla/E-Guven_Kok_Elektronik_Sertifika_Hizmet_Saglayicisi.crt, mozilla/Entrust.net_Premium_2048_Secure_Server_CA.crt, mozilla/Entrust.net_Secure_Server_CA.crt, mozilla/Entrust_Root_Certification_Authority.crt, mozilla/ePKI_Root_Certification_Authority.crt, mozilla/Equifax_Secure_CA.crt, mozilla/Equifax_Secure_eBusiness_CA_1.crt, mozilla/Equifax_Secure_eBusiness_CA_2.crt, mozilla/Equifax_Secure_Global_eBusiness_CA.crt, mozilla/Firmaprofesional_Root_CA.crt, mozilla/GeoTrust_Global_CA_2.crt, mozilla/GeoTrust_Global_CA.crt, mozilla/GeoTrust_Primary_Certification_Authority.crt, mozilla/GeoTrust_Primary_Certification_Authority_-_G2.crt, mozilla/GeoTrust_Primary_Certification_Authority_-_G3.crt, mozilla/GeoTrust_Universal_CA_2.crt, mozilla/GeoTrust_Universal_CA.crt, mozilla/Global_Chambersign_Root_-_2008.crt, mozilla/GlobalSign_Root_CA.crt, mozilla/GlobalSign_Root_CA_-_R2.crt, mozilla/GlobalSign_Root_CA_-_R3.crt, mozilla/Go_Daddy_Class_2_CA.crt, mo zilla/Go_Daddy_Root_Certificate_Authority_-_G2.crt, mozilla/GTE_CyberTrust_Global_Root.crt, mozilla/Hongkong_Post_Root_CA_1.crt, mozilla/IGC_A.crt, mozilla/Izenpe.com.crt, mozilla/Juur-SK.crt, mozilla/Microsec_e-Szigno_Root_CA_2009.crt, mozilla/Microsec_e-Szigno_Root_CA.crt, mozilla/NetLock_Arany_=Class_Gold=_Főtanúsítvány.crt, mozilla/NetLock_Business_=Class_B=_Root.crt, mozilla/NetLock_Express_=Class_C=_Root.crt, mozilla/NetLock_Notary_=Class_A=_Root.crt, mozilla/NetLock_Qualified_=Class_QA=_Root.crt, mozilla/Network_Solutions_Certificate_Authority.crt, mozilla/OISTE_WISeKey_Global_Root_GA_CA.crt, mozilla/QuoVadis_Root_CA_2.crt
Bug#619587: Update mozilla/certdata.txt
(CCing #619587) I committed an updated mozilla/blacklist.txt to explicitly blacklist the untrusted Bogus * and Explicitly Distrust DigiNotar * certificates, which will show up in the next upload [2]. On 10/28/2011 03:57 AM, Gijs Hillenius wrote: A bit of Googling did not explain me why Debian's Mozilla package was just updated with a bunch of 'Bogus $name' certificates. Could you maybe post a little note somewhere why this was done? The name does not inspire much confidence... but that might be the intention.. I added an entry to the changelog about these and bug report has some additional links to read [0] for more information. These Bogus * certificates were the ones that were created by an attacker using Comodo's CA roots, supposedly used for man in the middle (MITM) attacks. These bogus certificates were added by Mozilla with no trust bits set and they are ignored (you will not find them actually installed to /usr/share/ca-certificates/mozilla/). The notification is only clear when building the package [1], so I can see why this is not totally apparent. They are not installed as trusted root certificates by ca-certificates, but Mozilla included them in the bundle as non-trusted certificates. Perhaps I should not have listed them in the changelog as being added to the Mozilla bundle, since they are not trusted certificates actutally installed, but they are something of a different nature. Thoughts? These are interesting times for the CA infrastructure and one of the reasons I took over maintenance of ca-certificates - the package needs quite a bit more care, so keep a look out for more updates soon. I appreciate the note - feel free to mail anytime. [0] http://bugs.debian.org/619587 [1] http://www.pbandjelly.org/debian/ca-certificates_20111025_i386.build [2] http://anonscm.debian.org/gitweb/?p=collab-maint/ca-certificates.git;a=commit;h=a6435dc8edf7f72e8e2ea7b3677b9bcdbe0e -- Kind regards, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#537051: ca-certificates 20090709: installation error
tag 537051 + moreinfo unreproducible thanks This bug is a couple years old and I have not seen similar errors with recent versions of ca-certificates and ca-certificates-java. Is this error still happening? If so, could you provide some details on how to recreate the error? Thanks! -- Kind regards, Michael Shuler -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#538259: ca-certificates: error when attempting to upgrade
tag 538259 + moreinfo unreproducible thanks This bug is a couple years old and I have not seen similar errors. It may be possible that hardware issues(?) caused the segfault. Is this error still happening to you? If so, could you provide some details on how to recreate the error? Thank you! -- Kind regards, Michael Shuler -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#623882: error installing certs with non-ascii characters in their names
Hello Miles, I just wanted to let you know that Debian bug #623882 was closed by a merge with the fixed bug #623671 in ca-certificates-java. -- Kind regards, Michael Shuler -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#640696: Exception in thread main
reassign 640696 ca-certificates-java thanks Hello Ludovic, I am reassigning this bug to ca-certificates-java, as this error is coming from the java certificate update hook. Looking through the open and archived bugs for ca-certificates-java, I don't see an error quite like this one, so perhaps Torsten or someone else can help us out. -- Kind regards, Michael Shuler -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#573857: Where should the EC2 AMI certificate live?
tag 573857 + help tag 597537 + help thanks As Charles mentioned in #597537 [0], the EC2 AMI certificate is distributed in the euca2ools package in Ubuntu - should it live in euca2ools in Debian? Or, perhaps in the future cloud-utils package [1], as Charles mentions later in the same bug report? I am working on cleaning up the ca-certificates bug list and since AWS EC2 is not a signing Certificate Authority, I don't think it is appropriate for ca-certificates. I would like to reassign the merged bugs #573857 and #597537 to a proper package that would like to include the EC2 certificate. Thoughts? [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=597537#18 [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=622946 -- Kind regards, Michael Shuler -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#646767: ca-certificates: Please, remove gouv.fr/cert_igca_rsa.crt - IGC_A.pem RSA CA now included in mozilla
Considering the following note that was included with the initial request to Mozilla to Add French Government (DCSSI) CA certificate, I am removing the DSA certificate as well: IMPORTANT! Please close our request for the DSA certificate – the key was created for backup purpose in case of a cryptographic matter with RSA. It hasn’t be used yet, and we will soon use another key for this purpose. Then there is no need to include the DSA certificate anymore. [0] https://bugzilla.mozilla.org/show_bug.cgi?id=368970#c25 -- Kind regards, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#647548: ca-certificates: Mozilla is revoking trust in all certificates issued by DigiCert Sdn. Bhd.
Package: ca-certificates Version: 20111025 Severity: important DigiCert Sdn. Bhd. is an Entrust subordinate CA and has issued 22 certificates with weak keys. An attacker could use one of these weak certificates to impersonate the legitimate owners. Mozilla is revoking trust in all certificates issued by DigiCert Sdn. Bhd. Relevant Mozilla post: http://blog.mozilla.com/security/2011/11/03/revoking-trust-in-digicert-sdn-bhd-intermediate-certificate-authority/ Relevant Entrust statement: http://www.entrust.net/advisories/malaysia.htm -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (300, 'unstable'), (100, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.0.0-2-686-pae (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 Versions of packages ca-certificates depends on: ii debconf [debconf-2.0] 1.5.41 ii openssl1.0.0e-2 ca-certificates recommends no packages. ca-certificates suggests no packages. -- debconf information: ca-certificates/title: * ca-certificates/enable_crts: brasil.gov.br/brasil.gov.br.crt, cacert.org/cacert.org.crt, debconf.org/ca.crt, mozilla/ACEDICOM_Root.crt, mozilla/AC_Raíz_Certicámara_S.A..crt, mozilla/AddTrust_External_Root.crt, mozilla/AddTrust_Low-Value_Services_Root.crt, mozilla/AddTrust_Public_Services_Root.crt, mozilla/AddTrust_Qualified_Certificates_Root.crt, mozilla/AffirmTrust_Commercial.crt, mozilla/AffirmTrust_Networking.crt, mozilla/AffirmTrust_Premium.crt, mozilla/AffirmTrust_Premium_ECC.crt, mozilla/America_Online_Root_Certification_Authority_1.crt, mozilla/America_Online_Root_Certification_Authority_2.crt, mozilla/ApplicationCA_-_Japanese_Government.crt, mozilla/A-Trust-nQual-03.crt, mozilla/Autoridad_de_Certificacion_Firmaprofesional_CIF_A62634068.crt, mozilla/Baltimore_CyberTrust_Root.crt, mozilla/Buypass_Class_2_CA_1.crt, mozilla/Buypass_Class_3_CA_1.crt, mozilla/CA_Disig.crt, mozilla/Camerfirma_Chambers_of_Commerce_Root.crt, mozilla/Camerfirma_Global_Chambersign_Root.crt, mozilla/Certigna.crt, mozilla/Certinomis_-_Autorité_Racine.crt, mozilla/Certplus_Class_2_Primary_CA.crt, mozilla/certSIGN_ROOT_CA.crt, mozilla/Certum_Root_CA.crt, mozilla/Certum_Trusted_Network_CA.crt, mozilla/Chambers_of_Commerce_Root_-_2008.crt, mozilla/CNNIC_ROOT.crt, mozilla/Comodo_AAA_Services_root.crt, mozilla/COMODO_Certification_Authority.crt, mozilla/COMODO_ECC_Certification_Authority.crt, mozilla/Comodo_Secure_Services_root.crt, mozilla/Comodo_Trusted_Services_root.crt, mozilla/ComSign_CA.crt, mozilla/ComSign_Secured_CA.crt, mozilla/Cybertrust_Global_Root.crt, mozilla/Deutsche_Telekom_Root_CA_2.crt, mozilla/DigiCert_Assured_ID_Root_CA.crt, mozilla/DigiCert_Global_Root_CA.crt, mozilla/DigiCert_High_Assurance_EV_Root_CA.crt, mozilla/Digital_Signature_Trust_Co._Global_CA_1.crt, mozilla/Digital_Signature_Trust_Co._Global_CA_3.crt, mozilla/DST_ACES_CA_X6.crt, mozilla/DST_Root_CA_X3.crt, mozilla/EBG_Elektronik_Sertifika_Hizmet_Sağlayıcısı.crt, mozilla/E-Guven_Kok_El ektronik_Sertifika_Hizmet_Saglayicisi.crt, mozilla/Entrust.net_Premium_2048_Secure_Server_CA.crt, mozilla/Entrust.net_Secure_Server_CA.crt, mozilla/Entrust_Root_Certification_Authority.crt, mozilla/ePKI_Root_Certification_Authority.crt, mozilla/Equifax_Secure_CA.crt, mozilla/Equifax_Secure_eBusiness_CA_1.crt, mozilla/Equifax_Secure_eBusiness_CA_2.crt, mozilla/Equifax_Secure_Global_eBusiness_CA.crt, mozilla/Firmaprofesional_Root_CA.crt, mozilla/GeoTrust_Global_CA_2.crt, mozilla/GeoTrust_Global_CA.crt, mozilla/GeoTrust_Primary_Certification_Authority.crt, mozilla/GeoTrust_Primary_Certification_Authority_-_G2.crt, mozilla/GeoTrust_Primary_Certification_Authority_-_G3.crt, mozilla/GeoTrust_Universal_CA_2.crt, mozilla/GeoTrust_Universal_CA.crt, mozilla/Global_Chambersign_Root_-_2008.crt, mozilla/GlobalSign_Root_CA.crt, mozilla/GlobalSign_Root_CA_-_R2.crt, mozilla/GlobalSign_Root_CA_-_R3.crt, mozilla/Go_Daddy_Class_2_CA.crt, mozilla/Go_Daddy_Root_Certificate_Authority_-_G2.crt, mo zilla/GTE_CyberTrust_Global_Root.crt, mozilla/Hongkong_Post_Root_CA_1.crt, mozilla/IGC_A.crt, mozilla/Izenpe.com.crt, mozilla/Juur-SK.crt, mozilla/Microsec_e-Szigno_Root_CA_2009.crt, mozilla/Microsec_e-Szigno_Root_CA.crt, mozilla/NetLock_Arany_=Class_Gold=_Főtanúsítvány.crt, mozilla/NetLock_Business_=Class_B=_Root.crt, mozilla/NetLock_Express_=Class_C=_Root.crt, mozilla/NetLock_Notary_=Class_A=_Root.crt, mozilla/NetLock_Qualified_=Class_QA=_Root.crt, mozilla/Network_Solutions_Certificate_Authority.crt, mozilla/OISTE_WISeKey_Global_Root_GA_CA.crt, mozilla/QuoVadis_Root_CA_2.crt, mozilla/QuoVadis_Root_CA_3.crt, mozilla/QuoVadis_Root_CA.crt, mozilla/Root_CA_Generalitat_Valenciana.crt, mozilla/RSA_Root_Certificate_1.crt, mozilla/RSA_Security_2048_v3.crt, mozilla/Secure_Global_CA.crt, mozilla/SecureSign_RootCA11.crt, mozilla/SecureTrust_CA.crt,
Bug#647548: Mozilla bug#
Additional reading: https://bugzilla.mozilla.org/show_bug.cgi?id=698753 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#687693: ca-certificates: Cacert License is missing
Control: severity -1 serious Control: tags -1 pending (Setting to serious, due to policy violation) After reading the -legal thread, comments above, the CAcert mailing list thread, the Fedora explanation, and carefully reading the licensing myself, the cautious side of me says the right thing to do is remove the CAcert certificates from the package. This change will be committed to the collab-maint git repo shortly. I appreciate the bug report, mejiko, and for others taking the time to consider this issue. I will consider a ca-certificates-cacert ITP for inclusion in non-free. -- Kind regards, Michael signature.asc Description: OpenPGP digital signature
Bug#687693: ca-certificates: Cacert License is missing
On 11/03/2012 08:15 PM, Steve Langasek wrote: On Sat, Nov 03, 2012 at 03:28:08PM -0500, Michael Shuler wrote: After reading the -legal thread, comments above, the CAcert mailing list thread, the Fedora explanation, and carefully reading the licensing myself, the cautious side of me says the right thing to do is remove the CAcert certificates from the package. This change will be committed to the collab-maint git repo shortly. I appreciate the bug report, mejiko, and for others taking the time to consider this issue. I will consider a ca-certificates-cacert ITP for inclusion in non-free. Which debian-legal thread were you reading? Because the two comments I see cc:ed to this bug report from debian-legal, from Francesco Poli and Florian Weimer, both point out that *certificates are not copyrightable*. An SSL certificate is a unique representation of a mathematical fact; since it contains no creative element, copyright law does not provide for any monopoly rights prohibiting distribution. There was one other short reply on debian-legal that was not sent to the bug report. (Sorry if I broke the threading, I am not subscribed to debian-legal) I understand that SSL certificates, themselves, are math, and I understand the conclusion that they are not copyrightable. However, I am not fully convinced that, due to this conclusion, the CAcert license has no effect (or whatever the proper legal terminology would be). Among other suggestions, Francesco Poli recommended including a verbatim copy of this license. The CAcert license is therefore something we should entirely ignore, because it has no legal force. Is this really the case? Should Debian ignore CAcert's license on their root certificates? Here is my reasoning, distilled as best I can: CAcert has explicitly licensed their root certificates. Even if SSL certificates are not copyrightable, the RDL contains the language: In the event that any provision of this license is held to be invalid or unenforceable, the remaining provisions of this license remain in full force and effect. This statement, along with the use restriction, in my reading, means that the remainder of the CAcert RDL license is still applicable, as they have intended, regardless of the copyright question. It seems clear from Fedora's decision, as well as Francesco's opinion and Raphael's look (both non-legal opinions, as well as my own), that the use restriction makes the CAcert root certificates licensed under a non-free license. Am I reading and interpreting this incorrectly? If this license should be included in the ca-certificates package, then an interpretation by ftp-master, I assumed, would result in the same opinion. In addition, the Social Contract #1 states that all _components_ (not just copyrightable software) are to be 100% free. That was the kicker that made me think this license applies, regardless of copyrightability. Your proposal to remove it from the package without specific legal guidance to the contrary is a gross overreaction. I have spent several sessions, since this bug was reported, carefully reading the RDL license, other licenses, mailing list posts, etc. My (non-lawyer) interpretation of this issue led me to believe that the right thing to do was to remove the CAcerts from this package in main, due to it being licensed under a non-DFSG license. Additionally, including this CA as a non-free package for Debian users seems a reasonable workaround. I'm completely open to additional legal guidance with this, and I hope you can see my logic wasn't just some overreaction - perhaps misguided by trying to do the right thing following policy, I'll admit. Heck, I had no idea an SSL cert could be licensed, but it is clear to me that CAcert has intentionally done just that. -- Kind regards, Michael Shuler signature.asc Description: OpenPGP digital signature
Bug#687693: ca-certificates: Cacert License is missing
I meant to include a note that I'm fine with not removing CAcert from ca-certificates, as long as there is consensus with a) include the license in d/copyright, or b) ignore it (for now). We can work on this after wheezy, when we can add another package, if that is what we need to do. Sorry if the timing may not have been ideal, but this seemed important for the wheezy release. -- Kind regards, Michael signature.asc Description: OpenPGP digital signature
Bug#687693: ca-certificates: Cacert License is missing
Control: tags -1 wontfix On 11/04/2012 03:23 PM, Steve Langasek wrote: I hereby grant you a non-exclusive, worldwide, royalty-free license to eat cheese with salami, subject to the following conditions: - You do not use the name of debian-legal while talking with food in your mouth. - You do not eat cheese with wine. - Neither the name of the University of California nor the name of the Tillamook County Creamery Association may be used to endorse or promote products derived from your consumption of cheese and salami without specific prior written permission. In the event that any provision of this license is held to be invalid or unenforceable, the remaining provisions of this license remain in full force and effect. Hope that helps, Indeed! A realistic example helps me step back from tying to think like an attorney, and a good laugh helps, too. I really appreciate your insight, Steve. -- Warm regards, Michael Shuler signature.asc Description: OpenPGP digital signature
Bug#692323: ca-certificates: cacert.org.pem needs to be split - one cert per file (see: #642314)
Package: ca-certificates Version: 20120623 Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 The openssl maintainers would like to drop a patch for support of multiple certs in a single file, as it has caused a regression. The CAcert root.crt and class3.crt should be installed as separate files, as opposed to the current concatenation into cacert.org.crt. See openssl bug #642314 for details - -- Michael Shuler - -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (900, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-3-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 Versions of packages ca-certificates depends on: ii debconf [debconf-2.0] 1.5.46 ii openssl1.0.1c-4 ca-certificates recommends no packages. ca-certificates suggests no packages. - -- debconf information excluded -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQlvfvAAoJEKJ4t4H+SyvaL/8QAKVPrA+okodgxaDB6VWbaMwM N+5rxuaZ8Xh1iHehHtdXLOLFQh8xOo1roUjihe8lIzWEFh2LD8RzJnG40iRx++eP +TVTJse3yGzp7dk7lunvyO1112UJAjfpJ0rRX56vb8xbUz/1Ud06tOWRkKGSkCWj oDRgB6UKyS/9eDyGep7pmyzNRyjPiyEjOcycY21bWDIu6xVy/X4Oc3pZqS6aXeYj cvM3G8a0ECc17l30S0oRMMRvMSrsz0Lkwm1PKT0qYshCoSJY8dYOsUI6CXoQW92D Pfm3/W08+EYSyTIZI3sQZFfU9/vlPbbgU5Nsu3PKaljcShIS63OMO+o3VrEdBHJY sfbL0HUKvCkJcMKcbGSuH/tmJg+3hWyR+/oBXAYla8Hrjp6xWmHvdUJeegY+EalR ezAVIOYooS0cRiu/CSZp1D3hxxhVxP1ZsFltt6sdDnDvHOuLJ6YfgGa85nsCjXhT 1yw/Bk307AnGAgiEzS0Wo/nNNZE4HqMvUEahBRbW8GL/tlwa4kfXOQ78gqKLy46J G/7bpQCJYEb+NyynEMs2QSYYqzX1YYdCTzIKxcFxPFV9rU4tOOXifq6INO8PIjz7 u+boEq/BZNki3mlyFH/9+3RJgF2SZL9f7Fl7pUH2yA0o5V2pLbFdTjCU51xGCTwr e6qYQjqXWQlkJ7yt+XHm =sCGH -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692323: ca-certificates: cacert.org.pem needs to be split - one cert per file (see: #642314)
Control: tags -1 pending Double-checking cert hashes: Before (ver. 20120623): $ ls -l /etc/ssl/certs/|grep cacert.org lrwxrwxrwx 1 root root 14 Nov 4 16:58 590d426f.0 - cacert.org.pem lrwxrwxrwx 1 root root 14 Nov 4 16:58 5ed36f99.0 - cacert.org.pem lrwxrwxrwx 1 root root 14 Nov 4 16:58 99d0fa06.0 - cacert.org.pem lrwxrwxrwx 1 root root 52 Nov 4 16:58 cacert.org.pem - /usr/share/ca-certificates/cacert.org/cacert.org.crt lrwxrwxrwx 1 root root 14 Nov 4 16:58 e5662767.0 - cacert.org.pem After (tentative ver. 20121104): $ ls -l /etc/ssl/certs/|grep cacert.org lrwxrwxrwx 1 root root 21 Nov 4 17:51 590d426f.0 - cacert.org_class3.pem lrwxrwxrwx 1 root root 19 Nov 4 17:51 5ed36f99.0 - cacert.org_root.pem lrwxrwxrwx 1 root root 19 Nov 4 17:51 99d0fa06.0 - cacert.org_root.pem lrwxrwxrwx 1 root root 59 Nov 4 17:51 cacert.org_class3.pem - /usr/share/ca-certificates/cacert.org/cacert.org_class3.crt lrwxrwxrwx 1 root root 57 Nov 4 17:51 cacert.org_root.pem - /usr/share/ca-certificates/cacert.org/cacert.org_root.crt lrwxrwxrwx 1 root root 21 Nov 4 17:51 e5662767.0 - cacert.org_class3.pem -- Michael signature.asc Description: OpenPGP digital signature
Bug#692323: ca-certificates: cacert.org.pem needs to be split - one cert per file (see: #642314)
Control: tags -1 - pending + patch Setting to patch for some advice.. - 20090708 removed cacert.org/root.crt and cacert.org/class3.crt (deprecated in 20080809) - 20080809 concatenated both CACert Class 1 and Class 3 certificates into cacert.org.pem for certificate chaining, deprecating the individual cert files (but still installing them) - #494343 If we attempt to leave cacert.org.pem around, we disrupt the hashes to the individual files. The openssl maintainers wish us to go back to the split files, so they can remove a faulty patch. I'll need to touch base with this, when I get some additional time. -- Michael diff --git a/cacert.org/Makefile b/cacert.org/Makefile index 180ea6b..dba8d21 100644 --- a/cacert.org/Makefile +++ b/cacert.org/Makefile @@ -5,9 +5,8 @@ all: clean: - rm -f cacert.org.crt install: - cat root.crt class3.crt cacert.org.crt - install -m 644 cacert.org.crt $(CERTSDIR)/cacert.org.crt - + for p in *.crt; do \ + install -m 644 $$p $(CERTSDIR)/cacert.org_$$p ; \ + done signature.asc Description: OpenPGP digital signature
Bug#690204: ca-certificates{, -java}: many errors during squeeze-wheezy upgrades, probably related to configuration order and update.d/
merge 690204 537051 thanks Same errors in the attached log during a squeeze to wheezy dist-upgrade. However, immediately following the dist-upgrade, re-running 'update-ca-certificates --fresh' completes successfully and sets up the java keystore properly. In all cases, the end of the ca-certificates package update is: 151 added, 0 removed; done. and the hook for ca-certificates-java begins: Running hooks in /etc/ca-certificates/update.d updating keystore /etc/ssl/certs/java/cacerts... (errors..) From the lack of update errors after dist-upgrade and the new openjdk is installed makes me think that ca-certificates-java might need to pre-depend on a specific version of openjdk-6-jre-headless. (Does this sound reasonable?) I would be happy to add something to ca-certificates to delay the update hooks only when needed. Perhaps if a suggested patch could be submitted, since I'm not entirely sure what I would key off to make that delay happen only when needed. FWIW, there are no update errors with ca-certificates when ca-certificates-java is not installed. -- Kind regards, Michael squeeze2wheezy_dist-upgrade.log.gz Description: application/gzip signature.asc Description: OpenPGP digital signature
Bug#619587: Update mozilla/certdata.txt
On 11/05/2011 01:52 AM, Raphael Geissert wrote: On Friday 28 October 2011 07:37:28 Michael Shuler wrote: I committed an updated mozilla/blacklist.txt to explicitly blacklist the untrusted Bogus * and Explicitly Distrust DigiNotar * certificates, which will show up in the next upload [2]. Is there any specific reason you did that? The Explicitly * certs do add some more noise, but none of them are installed. Even if they were, they are invalid and wouldn't be used. The Bogus ones are not installed either, so that's okay. Indeed, I added them to mozilla/blacklist.txt to cut down on noise, but you are correct, they are not installed either way. Looking at the current openssl-blacklist package, I agree; I don't see value in adding the untrusted certs there. I was considering a way to whitelist the explicitly untrusted certs in ca-certificates, so that we were installing them, but that seems a bit outside the scope of the package, the more I think about it - if the CA is not installed, the request fails. I'll back out that commit. -- Kind regards, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642314: [Pkg-openssl-devel] Bug#642314: Bug#628780: Wrong hash link to cacert.org.pem and wron certificat hash handling at all
On 07/29/2012 07:53 AM, Kurt Roeckx wrote: On Thu, Sep 22, 2011 at 10:15:50AM +0200, Loïc Minier wrote: Just thought of another minor issue with the new c_rehash handling multiple certs in the same file: when a piece of software follows the hashed symlink, the certificate it's looking for might not be the first one. Is this verified to work with gnutls and openssl implementations? I wonder whether this could confuse some software in Debian that might be using the ssl API in a way that only the first certificate is tried. So I would like to drop the patch, but cacert.org.pem still contains 2 cert files. Michael, could you please consider splitting that file? I'll take a look at this. I don't recall the reason for combining those off the top of my head, but I'll work on this as soon as I can. Were you targeting the patch removal from openssl for Wheezy? -- Kind regards, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683403:
On 08/01/2012 09:37 AM, Marc Deslauriers wrote: OK, I am now convinced that we don't need the md2 certs, applications should be able to validate using the sha1 certs. I believe a bug in libsoup/glib-networking is causing the sha1 certs to not be used. Thanks for the clarification. We still should improve ca-certificates to make _sure_ that we're shipping the sha1 certs instead of the md2 certs, as it currently ships the sha1 certs by coincidence as they are listed later in Mozilla's file. If they ever change the order of their file, we'll be shipping the md2 ones by mistake. We strive to properly ship each trusted CA in the mozilla certdata.txt, so I agree and will work on correcting this. Thanks for the report :) -- Kind regards, Michael Shuler -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692911: unblock: ca-certificates/20121105
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Please unblock package ca-certificates
ca-certificates/20121105 has been uploaded to unstable and includes two
important fixes for Wheezy:
ca-certificates (20121105) unstable; urgency=low
* Update mozilla/certdata.txt to version 1.86 Closes: #683728
Certificates added (+) (none removed):
+ Actalis Authentication Root CA
+ Trustis FPS Root CA
+ StartCom Certification Authority (renewal/rehash)
+ StartCom Certification Authority G2
+ Buypass Class 2 Root CA
+ Buypass Class 3 Root CA
+ TÜRKTRUST Elektronik Sertifika Hizmet Sağlayıcısı
+ T-TeleSec GlobalRoot Class 3
+ EE Certification Centre Root CA
* Correct piuparts package remove/purge behavior Closes: #682125
- Remove deletes of /etc/ssl{,/certs} from debian/postrm
A debdiff against the package in testing is attached. Although #683728 was
requested by Eddy Nigg at StartCom, I think it is important to include the
latest available mozilla CA bundle for Wheezy.
unblock ca-certificates/20121105
- --
Kind regards,
Michael Shuler
- -- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (900, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)
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
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAEBCAAGBQJQnpRkAAoJEKJ4t4H+SyvaODsP/298BhE9G8y4wtxpPzBVZOkY
JcOXfbnQjDMTna4pySeiHjUVuDhdBiUZ3LebnyZlVHzBZL7CvTFEcYXaptgPV+ZA
PgPp3yiGk6RaNLKJ1+VRO+H3IfhtQ/zgajm6TvvnccQofzbr5tnLTDzbHjSj3chW
jT6hxjxnQmb/7IkncNZzzEU0YwqCpYlyQhWG0+m0gEGPfErT0/ZCxwsnUHDa/hNn
vY9L1a0m8JC93zpMWWlWXgfs1yBcuKhEqVHCCjKUEAaQa7SM2d6DemVUI8WvsbYu
hUnpKWZbXzU/YegCYBhKdGveBg81+0mwhf47Bh8uKreWK4sl/XGLoLSQ/IIretQ+
Ef6CKejhq2lVZIrUyEYU+4p1ZxboyPjGqfL1uR75vkFLjchKtVPOMDx4y5+3lD/X
B4YmTuRW7D0f84vyEyWHF8AtcgCFO6W5/iB2ZQ09FBZcP/aSsoIc2nlSu/hKLbmt
kUDodIAy1AqW2xTAXOSuIxn6Adg6HfULsbpCZMxwmN9i/oeScWvWCpAXIMAFoUYG
3yoNjA2Ffd9dw6kyTPiHO92WxgiKb5RiDtLm6LND/WHwLgzHBZNpID6MaHgel/ia
XNuvfLmcNgzo48xa4VQRsD0kgy9HvUIy6O8QFkzl6T9dlKHZxpf+D7zxVh2i6UYr
bhzwenLdp8iJe5mpI6YF
=4EpY
-END PGP SIGNATURE-
ca-certificates_20120623-20121105.debdiff.gz
Description: GNU Zip compressed data
Bug#692911: unblock: ca-certificates/20121105
On 11/10/2012 12:23 PM, intrigeri wrote: Michael Shuler wrote (10 Nov 2012 17:52:41 GMT) : unblock ca-certificates/20121105 There are multiple instances of: -CKA_TRUST_SERVER_AUTH CK_TRUST CKT_NSS_TRUST_UNKNOWN +CKA_TRUST_SERVER_AUTH CK_TRUST CKT_NSS_MUST_VERIFY_TRUST I guess that was imported from the new Mozilla certdata, but the way debian/changelog is phrased leads me believe the only changes is adding CA certificates, which apparently is not the case. Darn. I intended to add a comment that those lines are in the debdiff from the new certdata.txt and that they are innocuous. Otherwise, looks good to me. Thank you for the look. -- Kind regards, Michael signature.asc Description: OpenPGP digital signature
Bug#692911: unblock: ca-certificates/20121105
On 11/11/2012 12:15 PM, intrigeri wrote: That may be me nitpicking, but they are innocuous does not really address my desire to understand an undocumented change in a security-sensitive area. I'm still curious and feeling like this should be documented somehow, but I'll happily let others decide how important this concern of mine is important for Debian. For full context on the change, this came in an upstream patch for mozilla/certdata.txt 1.83-1.84 - this is the upstream bug: https://bugzilla.mozilla.org/show_bug.cgi?id=757189 mozilla/certdata.txt 1.83 was in ca-certificates_20120623 Quick summary of the mozilla bug: there were two different flags being used within certdata.txt to indicate no explicit trust: CKT_NSS_MUST_VERIFY_TRUST and CKT_NSS_TRUST_UNKNOWN. The change upstream was to get rid of the legacy TRUST_UNKNOWN flags and replace them with MUST_VERIFY_TRUST, since this is how new flags were being added. In parsing certdata.txt for the ca-certificates package, neither of these flags are used when the CA trust database is created, so both CKT_NSS_MUST_VERIFY_TRUST and CKT_NSS_TRUST_UNKNOWN flags are ignored. This is why I indicated these lines are innocuous - CKT_NSS_MUST_VERIFY_TRUST is ignored in the same manner as CKT_NSS_TRUST_UNKNOWN when both flags were present in the file, and now only CKT_NSS_MUST_VERIFY_TRUST is in certdata.txt, and there are no more instances of CKT_NSS_TRUST_UNKNOWN in certdata.txt 1.84. Should I re-upload with a changelog entry of something like: diff --git a/debian/changelog b/debian/changelog index 861abed..3fe8329 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,6 +1,9 @@ ca-certificates (20121105) unstable; urgency=low * Update mozilla/certdata.txt to version 1.86 Closes: #683728 +Clean up of no explicit trust flag CKT_NSS_TRUST_UNKNOWN to +CKT_NSS_MUST_VERIFY_TRUST +- https://bugzilla.mozilla.org/show_bug.cgi?id=757189 Certificates added (+) (none removed): + Actalis Authentication Root CA + Trustis FPS Root CA Or should I patch out these changes from mozilla/certdata.txt and re-upload? -- Kind regards, Michael Shuler signature.asc Description: OpenPGP digital signature
Bug#692323: ca-certificates: cacert.org.pem needs to be split - one cert per file (see: #642314)
On 11/04/2012 06:18 PM, Michael Shuler wrote: If we attempt to leave cacert.org.pem around, we disrupt the hashes to the individual files. The openssl maintainers wish us to go back to the split files, so they can remove a faulty patch. I'll need to touch base with this, when I get some additional time. I rebuilt openssl_1.0.1c-4 without c_rehash-multi.patch for some testing. The concatenated cacert.org.pem hash symlinks without the above patch included in openssl: root@mana:/# ls -l /etc/ssl/certs/|grep cacert.org lrwxrwxrwx 1 root root 14 Nov 12 05:21 5ed36f99.0 - cacert.org.pem lrwxrwxrwx 1 root root 14 Nov 12 05:21 99d0fa06.0 - cacert.org.pem lrwxrwxrwx 1 root root 52 Nov 12 05:17 cacert.org.pem - /usr/share/ca-certificates/cacert.org/cacert.org.crt root@mana:/# As suspected, if we include both the current concatenation and the individual certs, we have some problems: Unpacking replacement ca-certificates ... Setting up ca-certificates (20121105) ... Updating certificates in /etc/ssl/certs... WARNING: Skipping duplicate certificate cacert.org_root.pem WARNING: Skipping duplicate certificate cacert.org_root.pem 161 added, 0 removed; done. Running hooks in /etc/ca-certificates/update.ddone. root@mana:/# ls -l /etc/ssl/certs/|grep cacert.org lrwxrwxrwx 1 root root 21 Nov 12 05:32 590d426f.0 - cacert.org_class3.pem lrwxrwxrwx 1 root root 14 Nov 12 05:32 5ed36f99.0 - cacert.org.pem lrwxrwxrwx 1 root root 14 Nov 12 05:32 99d0fa06.0 - cacert.org.pem lrwxrwxrwx 1 root root 52 Nov 12 05:32 cacert.org.pem - /usr/share/ca-certificates/cacert.org/cacert.org.crt lrwxrwxrwx 1 root root 59 Nov 12 05:32 cacert.org_class3.pem - /usr/share/ca-certificates/cacert.org/cacert.org_class3.crt lrwxrwxrwx 1 root root 57 Nov 12 05:32 cacert.org_root.pem - /usr/share/ca-certificates/cacert.org/cacert.org_root.crt lrwxrwxrwx 1 root root 21 Nov 12 05:32 e5662767.0 - cacert.org_class3.pem root@mana:/# grep cacert.org /etc/ca-certificates.conf cacert.org/cacert.org.crt cacert.org/cacert.org_class3.crt cacert.org/cacert.org_root.crt root@mana:/# As I understand it, there is a high probability that there are a good number of users that may have configurations, for example apache, that rely on the existence of the concatenated cacert.org.pem file for root chaining. If we remove the concatenated file, we cause problems for users. If we include the concatenated file along with the individual root.crt and class3.crt, we are going to have some different problems. More ideas and testing are needed! -- Kind regards, Michael signature.asc Description: OpenPGP digital signature
Bug#692323: ca-certificates: cacert.org.pem needs to be split - one cert per file (see: #642314)
Similar to the removal of $CERTBUNDLE prior to calling c_rehash in sbin/update-ca-certificates (see http://bugs.debian.org/cgi-bin/643667), we could (using vars, etc. - this is just an idea): diff --git a/sbin/update-ca-certificates b/sbin/update-ca-certificates index 5375950..72acc5a 100755 --- a/sbin/update-ca-certificates +++ b/sbin/update-ca-certificates @@ -128,6 +128,7 @@ then fi rm -f $CERTBUNDLE +rm -f /etc/ssl/certs/cacert.org.pem ADDED_CNT=$(wc -l $ADDED) REMOVED_CNT=$(wc -l $REMOVED) @@ -145,6 +146,7 @@ fi chmod 0644 $TEMPBUNDLE mv -f $TEMPBUNDLE $CERTBUNDLE +ln -sf /usr/share/ca-certificates/cacert.org/cacert.org.crt /etc/ssl/certs/cacert.org.pem echo $ADDED_CNT added, $REMOVED_CNT removed; done. This would allow installation of concatenated pem for those that use it in configs for other services, gets it out of the way so the hash symlinks to the individual root.crt and class3.crt don't get stepped on, and gives us a path for deprecation of the chained cert later on. We can also document the use of SSLCACertificatePath instead of SSLCACertificateFile for Apache, for instance (for Jessie deprecation upgrade notes). -- Michael signature.asc Description: OpenPGP digital signature
Bug#692911: unblock: ca-certificates/20121105
On 11/14/2012 06:12 PM, intrigeri wrote: Michael Shuler wrote (11 Nov 2012 20:59:10 GMT) : In parsing certdata.txt for the ca-certificates package, neither of these flags are used when the CA trust database is created, so both CKT_NSS_MUST_VERIFY_TRUST and CKT_NSS_TRUST_UNKNOWN flags are ignored. This is why I indicated these lines are innocuous - Thanks a lot for the detailed explanation! No problem! Should I re-upload with a changelog entry of something like: * Update mozilla/certdata.txt to version 1.86 Closes: #683728 +Clean up of no explicit trust flag CKT_NSS_TRUST_UNKNOWN to +CKT_NSS_MUST_VERIFY_TRUST +- https://bugzilla.mozilla.org/show_bug.cgi?id=757189 I think it would be even better to replace clean up with some version of parsing certdata.txt for the ca-certificates package, neither of these flags are used when the CA trust database is created, so both CKT_NSS_MUST_VERIFY_TRUST and CKT_NSS_TRUST_UNKNOWN flags are ignored: IMHO, Clean up still describes the change itself, rather than the reason why it is reasonable, which is, I think, as important. Bummer. I was going to update this bug after 20121114 hit unstable. I built ca-certificates_20121114 before getting this note, and it is waiting for upload by my sponsors, as of writing. This upload is being coordinated with an upload of ca-certificates-java with version breaks and depends (see full debdiff). Here is what I did include for this change in 20121114: + * Update mozilla/certdata.txt to version 1.86 Closes: #683728 +- Replace legacy no explicit trust flag of CKT_NSS_TRUST_UNKNOWN for + CKT_NSS_MUST_VERIFY_TRUST, instead of a mix of both flags: + https://bugzilla.mozilla.org/show_bug.cgi?id=757189 +Certificates added (+) (none removed): ++ Actalis Authentication Root CA ... Full debdiff: http://www.pbandjelly.org/debian/ca-certificates_20120623-20121114.debdiff So, while I did include a note about the change for context for the reader of the diff (upstream change X: reference), I not go into detail about why this upstream change is not very meaningful to functionality or packaging (upstream change X: reference - this particular change doesn't really modify anything with ca-certificates because Y). That additional info seems a bit overkill to me, but we can add that, if it would be helpful. Again, I was going to reply after upload, but since there's another question on this, I thought I would take a moment to let you know what's coming. -- Kind regards, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692911: unblock: ca-certificates/20121105
On 11/15/2012 08:46 AM, Michael Shuler wrote: On 11/14/2012 06:12 PM, intrigeri wrote: I think it would be even better to replace clean up with some version of parsing certdata.txt for the ca-certificates package, neither of these flags are used when the CA trust database is created, so both CKT_NSS_MUST_VERIFY_TRUST and CKT_NSS_TRUST_UNKNOWN flags are ignored: IMHO, Clean up still describes the change itself, rather than the reason why it is reasonable, which is, I think, as important. 20121114 has not been uploaded to unstable, yet, so I had some time to rebuild and include an additional note, today: * Update mozilla/certdata.txt to version 1.86 Closes: #683728 - Replace legacy no explicit trust flag of CKT_NSS_TRUST_UNKNOWN for CKT_NSS_MUST_VERIFY_TRUST, instead of a mix of both flags: https://bugzilla.mozilla.org/show_bug.cgi?id=757189 This upstream fix does not change the CA certificates installed in ca-certificates as both flags are ignored. Only those CA certificates with the CKT_NSS_TRUSTED_DELEGATOR flag in certdata.txt are installed. I hope that helps with some clarity for that upstream change. :) Full testing debdiff: http://www.pbandjelly.org/debian/ca-certificates_20120623-20121114.debdiff -- Kind regards, Michael Shuler my penance: https://twitter.com/mshuler/status/269181404754096128 signature.asc Description: OpenPGP digital signature
Bug#693405: ca-certificates: Very unfortunate name for debconf.org certificate
On 11/16/2012 01:03 AM, Guillem Jover wrote: The debconf.org certifcate is named just ca.crt [0], which ends up being symlinked from /etc/ssl/certs/ as ca.pem. Please, rename the filename to denote it's coming from Debconf CA, and to avoid using such a generic and confusing name, in the same way all other certificates do. [0] /usr/share/ca-certificates/debconf.org/ca.crt Thanks for the bug report, Guillem. I'll work this in after the wheezy release. -- Kind regards, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#685038: ITP: mailscanner -- email gateway for virus scanning, spam and phishing detection
On 08/15/2012 07:35 PM, Aaron Schrab wrote: Package: wnpp Severity: wishlist Owner: Aaron Schrab aa...@schrab.com * Package name: mailscanner You may wish to contact the previous mailscanner maintainer [0][1] and dig through all the existing/archived bugs [2] to find out why it was removed from the archive post-squeeze, and if it may be suitable for debian in the future. [0] http://packages.debian.org/search?keywords=mailscanner [1] http://packages.qa.debian.org/m/mailscanner.html [2] http://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=both;src=mailscanner -- Kind regards, Michael Shuler -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#660689: Squeeze update for ca-certificates needs to note DigiNotar removal in NEWS, since previous version notes addition in NEWS
On 02/20/2012 02:50 PM, Josh Triplett wrote: When upgrading ca-certificates from lenny to squeeze, one of the previous ca-certificates NEWS entries mentions the addition of the DigiNotar root CA. The squeeze update to ca-certificates that removes DigiNotar does not include a corresponding NEWS entry. As a result, people upgrading from lenny to squeeze and using apt-listchanges see NEWS entries which note the addition of DigiNotar and not its removal. In my case this led me to wonder whether the version I upgraded to still had the DigiNotar certificate, and manually dig through the changelog to verify. The squeeze update for ca-certificates should have a NEWS entry noting the removed certificate. The blacklisting of the DigiNotar CA was done as an NMU. Per policy, as little changes to the package were made as possible, but as you found, the changelog clearly stated the DigiNotar blacklisting. Updating stable only to include a NEWS item seems rather irrelevant. However, I am planning on a stable-update for to include the latest version of the ca-certificates package. As I've wondered the value of NEWS for people searching for CA adds/removes, perhaps it is time to remove it - all that information is in debian/changelog. -- Kind regards, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#661785: [INTL:tr] Turkish debconf templates translation
tags 661785 pending thanks On 03/01/2012 04:04 AM, Atila KOÇ wrote: Please find attached the Turkish translation of the ca-certificates package. Pending next upload: http://anonscm.debian.org/gitweb/?p=collab-maint/ca-certificates.git;a=commit;h=5a85a493798455e2723c2f24d59b24fdb72dad31 Thanks! -- Kind regards, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659508: ca-certificates: Remove Trustwave CA
On 02/11/2012 11:16 AM, Martin Smith wrote: Trustwave CA /usr/share/ca-certificates/mozilla/SecureTrust_CA.crt This company has publicly admitted purposefully supplying a subordinate CA to a company forn the purpose of MITM attacks, by generating SSL certificates on the fly See http://blog.spiderlabs.com/2012/02/clarifying-the-trustwave-ca-policy-update.html This is currently being debated by Mozilla at https://bugzilla.mozilla.org/show_bug.cgi?id=724929 but it has now been 4 days since they have been notified with hardly a word from Mozilla and I don't think Mozilla are givng this the attention it deserves. I have been following the discussion on the Mozilla dev-security-policy mailing list, and read the bug report a couple days ago. I will catch up on the discussion to see if if the issue has gained any clarity. It is possible for any user to distrust any/all provided certificates they wish with 'dpkg-reconfigure ca-certificates'. If there is a personal desire to distrust the Trustwave CA at this time, prior to full discussion and decision by Mozilla, please do so. Since users have the means to trust/distrust any/all CAs, this particular CA will not be manually removed from the Mozilla CA bundle, until such time Mozilla removes it, if at all. People and businesses make mistakes all the time. Admitting them is highly unusual, and personally, I applaud the fact they are discussing this publicly. I can understand your feelings on the topic. How do you feel about the sneaky nature of the apparently multiple Verisign compromise disclosures, and the subsequent lack of public discussion - should we also remove their CAs? -- Kind regards, Michael Shuler signature.asc Description: OpenPGP digital signature
Bug#660002: [INTL:pl] Polish debconf translation
tags 660002 pending thanks On 02/15/2012 11:21 AM, Michał Kułach wrote: Please add attached Polish debconf translation. Pending next upload: http://anonscm.debian.org/gitweb/?p=collab-maint/ca-certificates.git;a=commit;h=926dd57f44e37eade9a6789c82ebeae7b42a52d0 Thank you! -- Kind regards, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#647849: ca-certificates: removal of signet.pl's CAs
tags 647849 + pending thanks On 11/19/2011 04:55 AM, Thijs Kinkhorst wrote: Given that all the CRL's have expired for years it does seem good to remove them from the next upload of ca-certificates. I'm not sure about the necessity of stable updates. While it indeed seems to have gone out of business or similar, it was webtrust certified in the past and as far as I can see there are no indications that there's acute danger with these certificates, is there? There is no danger, and it can be better information for users to leave expired certificates so an application may error with expired, instead of simply untrusted - see #493376 and #296827. However, I committed the removal of the CAs to keep cleaning up the clutter. -- Kind regards, Michael signature.asc Description: OpenPGP digital signature
Bug#647848: ca-certificates: no new CA should be accepted until proper procedure is defined
In my opinion, the first consideration of any new CA inclusion and subsequent update requests for ca-certificates should come from a verifiable representative of the CA organization (outside of additions/updates that come from Mozilla). The Mozilla CA process is well documented, and perhaps streamlining a similar process for Debian ca-certificates, modeled after Mozilla's, might be the way to go. -- Kind regards, Michael signature.asc Description: OpenPGP digital signature
Bug#668793: openshot: Update package to support new version of melt/python-mlt5
Package: openshot Version: 1.4.2-1 Severity: normal Hi Jonathan, The melt packages were updated, which removes python-mlt3 and subsequently openshot: $ sudo apt-get dist-upgrade -Vs Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done The following packages will be REMOVED: libmlt4 (0.7.8-2) openshot (1.4.2-1) python-mlt3 (0.7.8-2) The following NEW packages will be installed: libmlt5 (0.7.8+git20120409-1) The following packages will be upgraded: libmlt++3 (0.7.8-2 = 0.7.8+git20120409-1) melt (0.7.8-2 = 0.7.8+git20120409-1) 2 upgraded, 1 newly installed, 3 to remove and 0 not upgraded. Remv openshot [1.4.2-1] Remv python-mlt3 [0.7.8-2] Inst melt [0.7.8-2] (0.7.8+git20120409-1 Debian:unstable [i386]) [] Inst libmlt++3 [0.7.8-2] (0.7.8+git20120409-1 Debian:unstable [i386]) [] Remv libmlt4 [0.7.8-2] [] Inst libmlt5 (0.7.8+git20120409-1 Debian:unstable [i386]) Conf libmlt5 (0.7.8+git20120409-1 Debian:unstable [i386]) Conf melt (0.7.8+git20120409-1 Debian:unstable [i386]) Conf libmlt++3 (0.7.8+git20120409-1 Debian:unstable [i386]) Thanks! -- Kind regards, Michael -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'testing'), (100, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.2.0-2-686-pae (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 Versions of packages openshot depends on: ii fontconfig 2.8.0-3.1 ii gtk2-engines-pixbuf 2.24.10-1 ii librsvg2-common 2.36.0-5 ii melt none ii python 2.7.2-10 ii python-gtk2 2.24.0-3 ii python-httplib2 0.7.4-1 ii python-imaging 1.1.7-4 ii python-mlt3 0.7.8-2 ii python-pygoocanvas 0.14.1-1+b3 ii python-support 1.0.14 ii python-xdg 0.19-4 Versions of packages openshot recommends: ii frei0r-plugins 1.1.22git20091109-1.2 ii openshot-doc1.4.2-1 Versions of packages openshot suggests: ii blender none ii inkscape 0.48.3.1-1+b1 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717761: [ca-certificates] Cartificates with blank spaces in file name break ca-certificates.conf when running dpkg-reconfigure
On 07/24/2013 12:07 PM, Paolo Scarabelli wrote: If I add a new cerificate with blanks in the file name in /usr/share/ca-certificates, when I run: dpkg-reconfigure ca-certificates Why did you do it this way? Locally installed certificates should be placed in /usr/local/share/ca-certificates/ and they will be trusted. From README.Debian: If you want to install local certificate authorities to be implicitly trusted, please put the certificate files as single files ending with “.crt“ into “/usr/local/share/ca-certificates” and re-run “update-ca-certificates”. it adds a line for every part of the file name in ca-certificates.conf . In example, if I try to add the certificate: Actalis Authentication Root CA.crt it adds the following lines to ca-certificates.conf: Actalis Authentication Root CA.crt OK. I'll look to see if this can be escaped, but it really is unnecessary, since you wrote the file somewhere it really should not have been written to. In addition, the CA you wrote is already in the Mozilla bundle, if you were not aware of this. A quick test to see what happens when written with spaces to the correct local install location (c_rehash emits the warning about a duplicate cert) - it is added correctly symlinked in /etc/ssl/certs/ directory as well as appended to /etc/ssl/certs/ca-certificates.crt: mshuler@mana:~$ sudo cp -p /usr/share/ca-certificates/mozilla/Actalis_Authentication_Root_CA.crt /usr/local/share/ca-certificates/Actalis Authentication Root CA.withspaces.crt mshuler@mana:~$ ls -l /usr/local/share/ca-certificates/ total 4 -rw-r--r-- 1 root root 2049 Jun 10 13:21 Actalis Authentication Root CA.withspaces.crt mshuler@mana:~$ sudo update-ca-certificates Updating certificates in /etc/ssl/certs... WARNING: Skipping duplicate certificate Actalis_Authentication_Root_CA.withspaces.pem WARNING: Skipping duplicate certificate Actalis_Authentication_Root_CA.withspaces.pem 1 added, 0 removed; done. Running hooks in /etc/ca-certificates/update.ddone. mshuler@mana:~$ ls -l /etc/ssl/certs/|grep Actalis lrwxrwxrwx 1 root root 34 Jul 26 13:34 5f47b495.0 - Actalis_Authentication_Root_CA.pem lrwxrwxrwx 1 root root 34 Jul 26 13:34 930ac5d2.0 - Actalis_Authentication_Root_CA.pem lrwxrwxrwx 1 root root 69 Jul 26 13:32 Actalis_Authentication_Root_CA.pem - /usr/share/ca-certificates/mozilla/Actalis_Authentication_Root_CA.crt lrwxrwxrwx 1 root root 78 Jul 26 13:34 Actalis_Authentication_Root_CA.withspaces.pem - /usr/local/share/ca-certificates/Actalis Authentication Root CA.withspaces.crt mshuler@mana:~$ grep MIIFuzCCA6OgAwIBAgIIVwoRl0LE48wwDQYJKoZIhvcNAQELBQAwazELMAkGA1UE /etc/ssl/certs/ca-certificates.crt MIIFuzCCA6OgAwIBAgIIVwoRl0LE48wwDQYJKoZIhvcNAQELBQAwazELMAkGA1UE MIIFuzCCA6OgAwIBAgIIVwoRl0LE48wwDQYJKoZIhvcNAQELBQAwazELMAkGA1UE All the files installed by the package do not have spaces - these are the files configured by the package. I'll consider whether this bug should just be closed or if some further escaping is needed after looking more closely. -- Kind regards, Michael Shuler -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#718173: ca-certificates: /usr/local/share/ca-certificates/ handling broken
Control: severity -1 normal On 07/27/2013 08:52 PM, Christoph Anton Mitterer wrote: Hi. Hi Christoph - thanks for the bug report. I lowered the severity since I agree that some improvements can be made, but local certificate handling does work fine. Biggest hint I have is to use 'update-ca-certificates --fresh when modifying/removing local certs. I'd like to keep this bug open for improving the documentation in the README and man page for update-ca-certificates in handling local certs. Since some time the handling of certs in /usr/local/share/ca-certificates/ seems to be broken. This is rather vague. Could you provide some steps to reproduce your problem? Neither are these anymore shown up in debconf on reconfiure I do not think local certificates were ever available in debconf. Local certificates placed in /usr/local/share/ca-certificates/ are implicitly trusted on the system. Don't put them there, if you don't intend them to be trusted. With that in mind, there is no reason to have them in debconf - this is for updating trust for those certificates installed by the package. I sort of equate this with wanting the util-linux package to track scripts under /usr/local/bin/. nor are links in /etc/ssl/certs removed, created or re-created with new hash-values, when the cert got removed, added or changed so that a new hash resulted. I created a couple test CA certificates, installed test1, updated to test2, and then removed it successfully. I hope the attached example helps. Please, let me know some specifics, if I've misunderstood your report. -- Kind regards, Michael mshuler@mana:~$ openssl x509 -hash -fingerprint -noout -in 12.am_Root_CA_test1.crt 3f5b7c0e SHA1 Fingerprint=B5:EF:D4:C7:64:75:FD:C1:04:B7:87:B3:5F:2A:1A:A4:85:56:51:BD mshuler@mana:~$ openssl x509 -hash -fingerprint -noout -in 12.am_Root_CA_test2.crt 5a0c50c0 SHA1 Fingerprint=63:57:70:04:57:2D:AF:51:4F:6D:F6:26:97:33:61:A3:15:17:50:F0 mshuler@mana:~$ mshuler@mana:~$ cp 12.am_Root_CA_test1.crt /usr/local/share/ca-certificates/12.am_Root_CA.crt mshuler@mana:~$ mshuler@mana:~$ sudo update-ca-certificates Updating certificates in /etc/ssl/certs... 1 added, 0 removed; done. Running hooks in /etc/ca-certificates/update.ddone. mshuler@mana:~$ mshuler@mana:~$ ls -l /etc/ssl/certs/ | grep 12.am lrwxrwxrwx 1 root root 17 Jul 28 17:09 017dd8eb.0 - 12.am_Root_CA.pem lrwxrwxrwx 1 root root 50 Jul 28 17:09 12.am_Root_CA.pem - /usr/local/share/ca-certificates/12.am_Root_CA.crt lrwxrwxrwx 1 root root 17 Jul 28 17:09 3f5b7c0e.0 - 12.am_Root_CA.pem mshuler@mana:~$ mshuler@mana:~$ cp 12.am_Root_CA_test2.crt /usr/local/share/ca-certificates/12.am_Root_CA.crt mshuler@mana:~$ mshuler@mana:~$ sudo update-ca-certificates --fresh Clearing symlinks in /etc/ssl/certs...done. Updating certificates in /etc/ssl/certs... 157 added, 0 removed; done. Running hooks in /etc/ca-certificates/update.ddone. mshuler@mana:~$ mshuler@mana:~$ ls -l /etc/ssl/certs/ | grep 12.am lrwxrwxrwx 1 root root 50 Jul 28 17:09 12.am_Root_CA.pem - /usr/local/share/ca-certificates/12.am_Root_CA.crt lrwxrwxrwx 1 root root 17 Jul 28 17:09 5a0c50c0.0 - 12.am_Root_CA.pem lrwxrwxrwx 1 root root 17 Jul 28 17:09 b6339468.0 - 12.am_Root_CA.pem mshuler@mana:~$ mshuler@mana:~$ rm /usr/local/share/ca-certificates/12.am_Root_CA.crt mshuler@mana:~$ mshuler@mana:~$ sudo update-ca-certificates --fresh Clearing symlinks in /etc/ssl/certs...done. Updating certificates in /etc/ssl/certs... 157 added, 0 removed; done. Running hooks in /etc/ca-certificates/update.ddone. mshuler@mana:~$ mshuler@mana:~$ ls -l /etc/ssl/certs/ | grep 12.am mshuler@mana:~$
Bug#718434: ca-certificates: should CAcert.org be included?
In addition, I had an email conversation (link to thread is escaping me, at the moment) about removal due to their license statement [0] that You are bound by the Root Distribution Licence for any re-distributions of CAcert's roots. [1]. I was convinced by others that the certificates cannot be licensed, since they are essentially mathematics, but it still bothers me that we are not following their license, which may be non-free. Apologies for a quick reply, without some essential details about the conversation - I will dig up those details, as soon as I can, and send them along to this bug. Also, I am not a lawyer, so my opinion was based on layman reading of the CAcert license. [0] http://www.cacert.org/?id=3 [1] http://www.cacert.org/policy/RootDistributionLicense.php -- Kind regards, Michael signature.asc Description: OpenPGP digital signature
Bug#718434: ca-certificates: should CAcert.org be included?
On 07/31/2013 01:55 PM, Michael Shuler wrote: In addition, I had an email conversation (link to thread is escaping me, at the moment) about removal due to their license statement [0] that You are bound by the Root Distribution Licence for any re-distributions of CAcert's roots. [1]. That conversation was in http://bugs.debian.org/687693 My recollection was that it was on a mailing list. So, that is some further reading.. [0] http://www.cacert.org/?id=3 [1] http://www.cacert.org/policy/RootDistributionLicense.php -- Kind regards, Michael signature.asc Description: OpenPGP digital signature
Bug#697366: ca-certificates: remove turktrust certificates
Control: tags -1 pending Hello, The decision was made by the Mozilla CA team [0] to remove the recently added new CA for TÜRKTRUST Elektronik Sertifika Hizmet Sağlayıcısı, while leaving the two older Turktrust CA certificates enabled in certdata.txt version 1.87. ca-certificates_20121105 included the new CA. Version 1.87 of certdata.txt also includes the distrust for the two mis-issued intermediate certificates, but the ca-certificates package does not act on these bits, since the package only installs trusted CA certificates. I committed mozilla/certdata.txt version 1.87 to the collab-maint git repository. [0] https://bugzilla.mozilla.org/show_bug.cgi?id=825022#c26 -- Kind regards, Michael signature.asc Description: OpenPGP digital signature
Bug#701081: debian-policy: mandate an encoding for filenames in binary packages
On 04/07/2013 05:28 PM, Russ Allbery wrote: Charles Plessy ple...@debian.org writes: Here is a somewhat clumsy proposition. It sounds clear and concise to me. sec id=filenames headingFile names/heading p The name of the files installed by binary packages in the system PATH (namely tt/bin/tt, tt/sbin/tt, tt/usr/bin/tt, tt/usr/sbin/tt and tt/usr/games//tt) must be encoded in ASCII. /p p The name of the files and directories installed by binary packages outside the system PATH must be encoded in UTF-8 and should be restricted to ASCII when they can be represented in that character set. /p /sec This looks good to me. I think that strikes the right balance without going into too many details about what justification should or shouldn't be required for using UTF-8. Agreed. As one of the concerned package maintainers, I think this sounds fine. -- Kind regards, Michael Shuler -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
