Bug#903474: openssh-server: ~/.ssh/authorized_keys no longer accepts environment option with underscores in name
Package: openssh-server Version: 1:7.7p1-2 Severity: normal Tags: upstream Dear Maintainer, The ~/.ssh/authorized_keys no longer accepts lines with an environment option where an underscore is used in the environment name. e.g. environment="LC_ALL=C" ssh-rsa ... my-public-key This stricter checking is added in openssh 7.7. As a result of this stricter check, I am no longer allowed to login with this key. Imho this is too restrictive and underscores should be allowed. The bug is fixed upstream here: https://bugzilla.mindrot.org/show_bug.cgi?id=2851 Best Regards, Bas van Sisseren -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.16.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages openssh-server depends on: ii adduser3.117 ii debconf [debconf-2.0] 1.5.67 ii dpkg 1.19.0.5+b1 ii libaudit1 1:2.8.3-1+b1 ii libc6 2.27-3 ii libcom-err21.44.2-1 ii libgssapi-krb5-2 1.16-2 ii libkrb5-3 1.16-2 ii libpam-modules 1.1.8-3.7 ii libpam-runtime 1.1.8-3.7 ii libpam0g 1.1.8-3.7 ii libselinux12.8-1+b1 ii libssl1.0.21.0.2o-1 ii libsystemd0239-5 ii libwrap0 7.6.q-27 ii lsb-base 9.20170808 ii openssh-client 1:7.7p1-2 ii openssh-sftp-server1:7.7p1-2 ii procps 2:3.3.15-2 ii ucf3.0038 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages openssh-server recommends: pn libpam-systemd pn ncurses-term pn xauth Versions of packages openssh-server suggests: pn molly-guard pn monkeysphere pn rssh pn ssh-askpass pn ufw -- debconf information: openssh-server/permit-root-login: true openssh-server/password-authentication: true
Bug#787630: libstdc++6: unsafe rm -rf on __pycache__ dir can wipe all filesystems
Package: libstdc++6 Version: 5.1.1-9 Severity: grave Justification: causes non-serious data loss The postinst script of libstdc++6 attempts to remove all __pycache__ dirs from /usr/share/gcc-4.9/python, but doesn't do this in a secure way. If you accidentally had created files in /usr/share/gcc-4.9/python with a space in the name, there is a possiblity that the package upgrade will trigger a 'rm -rf /'. The package upgrade also warns about non-existing /usr/share/gcc-4.9/python, when the dir does not exist. I would advise to use this instead: if [ -n $2 -a -d /usr/share/gcc-4.9/python ] dpkg --compare-versions $2 lt 5.1.1-9; then find /usr/share/gcc-4.9/python -name __pycache__ -print0 | xargs -0 -r rm -rf fi -- System Information: Debian Release: stretch/sid APT prefers squeeze-lts APT policy: (500, 'squeeze-lts'), (500, 'oldoldstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable') Architecture: i386 (x86_64) Foreign Architectures: amd64 Kernel: Linux 3.16-2-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#777158: Text functions segfault on i386
Package: libimage-magick-perl
Version: 8:6.8.9.9-5
Severity: normal
The PerlMagick/quantum/Makefile.PL was using the wrong
magick/magick-baseconfig.h file. I've attached a patch to fix this problem.
Regards,
Bas van Sisseren
--
Bas van Sisseren b...@quarantainenet.nl
Quarantainenet
Description: Fix include path for PerlMagick builds
The quantum/Makefile.PL.in defined the wrong include-path for the
magick/magick-baseconfig.h file. The hardcoded upstream version was
used instead. This patch adds an error to the hardcoded upstream
magick/magick-baseconfig.h file, to ensure we will not use that file,
and fixes the quantum/Makefile.PL.in.
Bug-Debian: https://bugs.debian.org/777158
--- imagemagick-6.8.9.9.orig/PerlMagick/quantum/Makefile.PL.in
+++ imagemagick-6.8.9.9/PerlMagick/quantum/Makefile.PL.in
@@ -161,7 +161,7 @@ foreach my $delegate (@tested_delegates)
}
# defaults for LIBS INC CCFLAGS params that we later pass to Writemakefile
-my $INC_magick = '-I../ -I@top_srcdir@ @CPPFLAGS@ -I' . $Config{'usrinc'} . '/ImageMagick';
+my $INC_magick = '-I../../ -I@top_srcdir@ @CPPFLAGS@ -I' . $Config{'usrinc'} . '/ImageMagick';
my $LIBS_magick = '-L../../magick/.libs -lMagickCore-@MAGICK_MAJOR_VERSION@.@MAGICK_ABI_SUFFIX@ -lperl @MATH_LIBS@';
my $CCFLAGS_magick = $Config{'ccflags'} @CFLAGS@;
my $LDFLAGS_magick = -L../../magick/.libs -lMagickCore-@MAGICK_MAJOR_VERSION@.@MAGICK_ABI_SUFFIX@ $Config{'ldflags'} @LDFLAGS@;
--- imagemagick-6.8.9.9.orig/magick/magick-baseconfig.h
+++ imagemagick-6.8.9.9/magick/magick-baseconfig.h
@@ -1,3 +1,5 @@
+#error this is the upstream baseconfig.h. we should not include this file!
+
#ifndef _MAGICK_MAGICK_BASECONFIG_H
#define _MAGICK_MAGICK_BASECONFIG_H 1
Bug#764476: vde2: Segfaults due to race condition between find_in_hash() and hash_gc()
Package: vde2
Version: 2.3.2-4.2
Severity: important
Tags: upstream patch
Hello,
We're using the vde2-switch as network switch for several qemu-processes.
Lately we
noticed a lot of segfaults from the vde2-switch process. We were able to
trigger the
segfaults more often when we generate a lot of random mac-addresses on the
network,
combined with a lot of traffic.
After diving into the code, I noticed that the hash_gc() method is called from
the
SIGALRM signal handler, which could happen at the same time as a find_in_hash()
or
find_in_hash_update() lookup. The hash_gc() can then invalidate a pointer which
the
find_in_hash() or find_in_hash_update() call is still using, which causes a
segfault.
By simply delaying the hash_gc() to the next find_in_hash() or
find_in_hash_update()
call, it is no longer possible to have invalid pointers. The suggested patch
does this
by setting the new 'delayed_hash_gc' flag.
ps. Afaics, it is now also safe to remove all qtime_csenter()/qtime_csexit()
calls
in hash.c, but I'll leave that to the author of vde2 to verify that.
Regards,
Bas van Sisseren
-- System Information:
Debian Release: jessie/sid
APT prefers squeeze-lts
APT policy: (500, 'squeeze-lts'), (500, 'unstable'), (500, 'testing'), (500,
'stable'), (500, 'oldstable')
Architecture: i386 (x86_64)
Foreign Architectures: amd64
Kernel: Linux 3.16-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash
Versions of packages vde2 depends on:
ii adduser 3.113+nmu3
ii libc62.19-11
ii libpcap0.8 1.6.2-1
ii libvde0 2.3.2-4.2
ii libvdeplug2 2.3.2-4.2
vde2 recommends no packages.
Versions of packages vde2 suggests:
ii qemu 2.1+dfsg-5
pn qemu-kvm none
pn vde2-cryptcab none
-- no debconf information
diff -ru vde2-2.3.2.orig/src/vde_switch/hash.c vde2-2.3.2/src/vde_switch/hash.c
--- vde2-2.3.2.orig/src/vde_switch/hash.c 2011-11-23 17:41:17.0 +0100
+++ vde2-2.3.2/src/vde_switch/hash.c 2014-10-07 13:51:35.396596610 +0200
@@ -49,8 +49,11 @@
u_int64_t dst;
};
+static int delayed_hash_gc;
static struct hash_entry **h;
+static void hash_gc(void *arg); // forward declaration
+
static int calc_hash(u_int64_t src)
{
register int x = src * 0x030507090b0d1113LL;
@@ -89,6 +92,7 @@
* port */
int find_in_hash(unsigned char *dst,int vlan)
{
+ if (delayed_hash_gc) hash_gc(NULL);
struct hash_entry *e = find_entry(extmac(dst,vlan));
if(e == NULL) return -1;
return(e-port);
@@ -102,6 +106,7 @@
int k = calc_hash(esrc);
int oldport;
time_t now;
+ if (delayed_hash_gc) hash_gc(NULL);
for(e = h[k]; e e-dst != esrc; e = e-next)
;
if(e == NULL) {
@@ -267,9 +272,17 @@
static void hash_gc(void *arg)
{
time_t t = qtime();
+ delayed_hash_gc = 0;
for_all_hash(gc, t);
}
+/* actual handler which is called every GC_INTERVAL seconds. only set a flag
+ to stay thread-safe */
+static void hash_gc_flag(void *arg)
+{
+ delayed_hash_gc++;
+}
+
#define HASH_INIT(BIT) \
({ hash_bits=(BIT);\
hash_mask=HASH_SIZE-1;\
@@ -310,7 +323,7 @@
{
qtimer_del(gc_timerno);
gc_interval=p;
- gc_timerno=qtimer_add(gc_interval,0,hash_gc,NULL);
+ gc_timerno=qtimer_add(gc_interval,0,hash_gc_flag,NULL);
return 0;
}
@@ -410,7 +423,7 @@
gc_interval=GC_INTERVAL;
gc_expire=GC_EXPIRE;
- gc_timerno=qtimer_add(gc_interval,0,hash_gc,NULL);
+ gc_timerno=qtimer_add(gc_interval,0,hash_gc_flag,NULL);
ADDCL(cl);
#ifdef DEBUGOPT
ADDDBGCL(dl);
Bug#706074: less: Incorrect hilighting of search results
Package: less Version: 436-1 Severity: minor When searching for lines starting with some characters, less also sometimes hilight parts which match the regexp, except for that they do not start at the start of the line. Searching itself is not effected. Searching for the previous or next matching line works as expected. Used search queries: - /^[^ ] - /^[a-z] Reproducing works good on large text-files, e.g. /usr/share/common-licenses/GPL Open the file, and scroll to the end (use key 'G'). (one of the incorrect hilights start exactly 3 KB before the end of the file, so I assume the ^ in my search query matched the start of the buffer at that time, and not the \n) -- System Information: Debian Release: 6.0.7 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (x86_64) Kernel: Linux 3.2.0-4-amd64 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages less depends on: ii debianutils 3.4Miscellaneous utilities specific t ii libc6 2.11.3-4 Embedded GNU C Library: Shared lib ii libncurses5 5.7+20100313-5 shared libraries for terminal hand less recommends no packages. less 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#556388: Problem with cyrus-common-2.2.postinst script
Hello, It would help a lot to change these lines in /usr/sbin/cyrus-makedirs: (line 92) find $confdir -print0 \( -not -user cyrus -or -not -group mail \) | xargs -r -0 chown cyrus:mail (line 105) find $i -print0 \( -not -user cyrus -or -not -group mail \) | xargs -r -0 chown cyrus:mail (line 118) find $sievedir -print0 \( -not -user cyrus -or -not -group mail \) | xargs -r -0 chown cyrus:mail into: (line 92) find $confdir \( -not -user cyrus -or -not -group mail \) -print0 | xargs -r -0 chown cyrus:mail (line 105) find $i \( -not -user cyrus -or -not -group mail \) -print0 | xargs -r -0 chown cyrus:mail (line 118) find $sievedir \( -not -user cyrus -or -not -group mail \) -print0 | xargs -r -0 chown cyrus:mail This way the file is only chowned when the user/group is incorrect. With the -print0 statement in the front, just all files are printed, user cyrus or not.. If another security update will be released for oldstable, I would really like this fix. Without the fix, the upgrade took me more than 1.5 hours downtime. With the fix, this will probably be only 5 minutes. Regards, Bas van Sisseren -- Bas van Sisseren b...@quarantainenet.nl Quarantainenet -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#586207: metacity-common: metacity breaks with 17+ workspaces
Package: metacity-common Version: 1:2.30.1-2 Severity: normal Tags: patch metacity aborts on an assertion when using more than 16 workspaces. (workspace_names[i] != NULL) See also: https://bugs.launchpad.net/ubuntu/+source/metacity/+bug/583847 According to this link, metacity allows max. 36 workspaces. The fix is to add these workspace names to the schema file /usr/share/gconf/schemas/metacity.schemas -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: i386 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages metacity-common depends on: ii gconf22.28.1-3 GNOME configuration database syste ii sgml-base 1.26 SGML infrastructure and SGML catal metacity-common recommends no packages. metacity-common suggests no packages. -- no debconf information --- /usr/share/gconf/schemas/metacity.schemas.orig 2010-06-17 13:04:51.0 +0200 +++ /usr/share/gconf/schemas/metacity.schemas 2010-06-17 13:00:15.0 +0200 @@ -7820,6 +7820,26 @@ applyto/apps/metacity/workspace_names/name_14/applyto applyto/apps/metacity/workspace_names/name_15/applyto applyto/apps/metacity/workspace_names/name_16/applyto + applyto/apps/metacity/workspace_names/name_17/applyto + applyto/apps/metacity/workspace_names/name_18/applyto + applyto/apps/metacity/workspace_names/name_19/applyto + applyto/apps/metacity/workspace_names/name_20/applyto + applyto/apps/metacity/workspace_names/name_21/applyto + applyto/apps/metacity/workspace_names/name_22/applyto + applyto/apps/metacity/workspace_names/name_23/applyto + applyto/apps/metacity/workspace_names/name_24/applyto + applyto/apps/metacity/workspace_names/name_25/applyto + applyto/apps/metacity/workspace_names/name_26/applyto + applyto/apps/metacity/workspace_names/name_27/applyto + applyto/apps/metacity/workspace_names/name_28/applyto + applyto/apps/metacity/workspace_names/name_29/applyto + applyto/apps/metacity/workspace_names/name_30/applyto + applyto/apps/metacity/workspace_names/name_31/applyto + applyto/apps/metacity/workspace_names/name_32/applyto + applyto/apps/metacity/workspace_names/name_33/applyto + applyto/apps/metacity/workspace_names/name_34/applyto + applyto/apps/metacity/workspace_names/name_35/applyto + applyto/apps/metacity/workspace_names/name_36/applyto ownermetacity/owner typestring/type default/default
Bug#516717: coreutils: Missing conflict with package timeout
Package: coreutils Version: 7.1-1 Severity: normal Since coreutils 7.1, the coreutils package contains a binary 'timeout'. This conflicts with the package 'timeout', which contains an almost identical utility 'timeout'. A 'Conflicts: timeout' would be nice. -- System Information: Debian Release: 5.0 APT prefers oldstable APT policy: (500, 'oldstable'), (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.27-9-generic (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages coreutils depends on: ii libacl12.2.47-2 Access control list shared library ii libattr1 1:2.4.43-2Extended attribute shared library ii libc6 2.8~20080505-0ubuntu7 GNU C Library: Shared libraries ii libselinux12.0.65-5 SELinux shared libraries coreutils recommends no packages. coreutils 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#495788: perl: pending signals are processed in both the parent and child process after a fork()
Package: perl
Version: 5.10.0-13
Severity: normal
When system-calls are processed, all signals are enqueued until the next perl
instruction is executed. When the fork() system-call is processed, and the
parent receives a signal just before the fork() call, both the parent and the
child will process the enqueued signals.
Imho, the enqueued signal-list should be flushed when we are the child process
after the fork().
Example code:
==
use strict;
use Time::HiRes qw( alarm );
my $ppid = $$;
my $fork = 0;
$SIG{ALRM} = sub {
print [SIGALRM] ppid=$ppid pid=$$ fork=$fork\n if $$ != $ppid;
};
for (1..1) {
alarm(0.0002 + rand() * 0.0002);
$fork = 1;
my $pid = fork();
$fork = 0;
if (!defined $pid) {
warn fork(): $!\n;
} elsif ($pid == 0) {
exit(0);
}
}
sleep(1);
==
-- System Information:
Debian Release: lenny/sid
APT prefers oldstable
APT policy: (500, 'oldstable'), (500, 'unstable'), (500, 'testing'), (500,
'stable')
Architecture: i386 (i686)
Kernel: Linux 2.6.25-2-686 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash
Versions of packages perl depends on:
ii libc6 2.7-13 GNU C Library: Shared libraries
ii libdb4.6 4.6.21-10 Berkeley v4.6 Database Libraries [
ii libgdbm3 1.8.3-3GNU dbm database routines (runtime
ii perl-base 5.10.0-13 minimal Perl system
ii perl-modules 5.10.0-13 Core Perl modules
Versions of packages perl recommends:
ii netbase 4.33 Basic TCP/IP networking system
ii perl-doc 5.10.0-13 Perl documentation
Versions of packages perl suggests:
pn libterm-readline-gnu-perl | l none (no description available)
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#321132: bind9-host: fails with INSIST(..) when using -w and specify a dns-server
Package: bind9-host Version: 1:9.5.0.dfsg-3 Followup-For: Bug #321132 'host -w aavso.org' works ok, but 'host -w aavso.org 10.20.30.40' still fails: $ host -w aavso.org 10.20.30.40 timer.c:721: INSIST(result == 0 || result == 2) failed. Aborted 10.20.30.40 is a dummy ip address. I've tried several addresses. This doesn't seem to change the result. The client doesn't send any packets onto the network. -- System Information: Debian Release: lenny/sid APT prefers oldstable APT policy: (500, 'oldstable'), (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.18.8.0pundit1 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages bind9-host depends on: ii libbind9-40 1:9.5.0.dfsg-3 BIND9 Shared Library used by BIND ii libc6 2.7-12 GNU C Library: Shared libraries ii libcap2 2.10-1 support for getting/setting POSIX. ii libdns42 1:9.5.0.dfsg-3 DNS Shared Library used by BIND ii libisc41 1:9.5.0.dfsg-3 ISC Shared Library used by BIND ii libisccfg40 1:9.5.0.dfsg-3 Config File Handling Library used ii libkrb53 1.6.dfsg.4~beta1-3 MIT Kerberos runtime libraries ii liblwres401:9.5.0.dfsg-3 Lightweight Resolver Library used ii libssl0.9.8 0.9.8g-10.1SSL shared libraries ii libxml2 2.6.32.dfsg-2 GNOME XML library bind9-host recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#472181: librpc-xml-perl: RPC::XML support for empty base64 data
Package: librpc-xml-perl
Version: 0.59-1
Severity: normal
The RPC::XML package returns an error when encoding or decoding empty
strings of type base64.
Example code:
use strict;
use RPC::XML;
my $b64 = RPC::XML::base64-new('');
if ($RPC::XML::ERROR) {
print xmlrpc error: .$RPC::XML::ERROR.\n;
} else {
print encoded as: '.$b64-as_string.'\n;
}
Returns with:
xmlrpc error: RPC::XML::base64::new: Must be called with non-null
data or an open, seekable filehandle
Expected:
encoded as: 'base64/base64'
-- System Information:
Debian Release: 4.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18.8.0qnet-p4.2
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Versions of packages librpc-xml-perl depends on:
ii libwww-perl 5.805-1 WWW client/server library for Perl
ii libxml-parser-perl 2.34-4.2 Perl module for parsing XML files
ii perl5.8.8-7etch1 Larry Wall's Practical Extraction
librpc-xml-perl recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#471358: race condition in /etc/network/if-up.d/ntpdate with many interfaces
Package: ntpdate Version: 1:4.2.2.p4+dfsg-2 Severity: important When after a reboot all interfaces are brought up, the /etc/network/if-up.d/ntpdate script spawns a 'ntpdate ' for every interface. With many interfaces and an incorrectly set hardware-clock, this can result in a mayor time-shift: Mar 17 15:05:21 qserver ntpdate[1408]: step time server 81.171.44.131 offset -3468.662657 sec Mar 17 14:07:33 qserver ntpdate[1585]: step time server 87.238.168.160 offset -3468.664036 sec Mar 17 13:09:45 qserver ntpdate[1618]: step time server 87.238.168.160 offset -3468.664084 sec Mar 17 12:11:58 qserver ntpdate[1651]: step time server 87.238.168.160 offset -3468.663937 sec Mar 17 11:14:10 qserver ntpdate[1684]: step time server 87.238.168.160 offset -3468.663897 sec Mar 17 10:16:22 qserver ntpdate[1720]: step time server 192.87.106.2 offset -3468.662245 sec The problem can be fixed by forcing that only one ntpdate process is running at a time. You could choose not to background the ntpdate task (I think the 1 second timeout is good enough), or use a lockfile to hold off the other ntpdate processes. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.23.8-cfs-v24-hrt3.0-qnet64.2 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages ntpdate depends on: ii libc6 2.3.6.ds1-13etch5 GNU C Library: Shared libraries ii libcap11:1.10-14 support for getting/setting POSIX. ii libssl0.9.80.9.8c-4etch1 SSL shared libraries ii netbase4.29 Basic TCP/IP networking system ntpdate recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468313: libfrontier-rpc-perl: fails to report faults correctly when using 'use-objects'
Package: libfrontier-rpc-perl
Version: 0.07b4-3
Severity: normal
Tags: patch
When using Frontier::Client to call an XMLRPC method and the method
returned a fault, the fault is not readable when using 'use_objects':
Fault returned from XML RPC Server, fault code
Frontier::RPC2::Integer=SCALAR(0x86deec4):
Frontier::RPC2::String=SCALAR(0x859e9b4)
Added patch to un-object the fault code and string.
==
--- lib/Frontier/Client.pm.orig 2008-02-28 09:57:36.0 +0100
+++ lib/Frontier/Client.pm 2008-02-28 10:01:56.0 +0100
@@ -75,8 +75,16 @@
my $result = $self-{'enc'}-decode($content);
if ($result-{'type'} eq 'fault') {
- die Fault returned from XML RPC Server, fault code .
$result-{'value'}[0]{'faultCode'} . :
- . $result-{'value'}[0]{'faultString'} . \n;
+ my $fault_code = $result-{'value'}[0]{'faultCode'};
+ my $fault_string = $result-{'value'}[0]{'faultString'};
+
+ if (defined $self-{'use_objects'} $self-{'use_objects'}) {
+ $fault_code = $fault_code-value;
+ $fault_string = $fault_string-value;
+ }
+
+ die Fault returned from XML RPC Server, fault code $fault_code:
+ . $fault_string\n;
}
return $result-{'value'}[0];
==
-- System Information:
Debian Release: 4.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18.8.0qnet-p4.2
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Versions of packages libfrontier-rpc-perl depends on:
ii libwww-perl 5.805-1 WWW client/server library for Perl
ii libxml-parser-perl 2.34-4.2 Perl module for parsing XML files
ii perl5.8.8-7etch1 Larry Wall's Practical Extraction
libfrontier-rpc-perl recommends no packages.
-- no debconf information
--- lib/Frontier/Client.pm.orig 2008-02-28 09:57:36.0 +0100
+++ lib/Frontier/Client.pm 2008-02-28 10:01:56.0 +0100
@@ -75,8 +75,16 @@
my $result = $self-{'enc'}-decode($content);
if ($result-{'type'} eq 'fault') {
- die Fault returned from XML RPC Server, fault code .
$result-{'value'}[0]{'faultCode'} . :
- . $result-{'value'}[0]{'faultString'} . \n;
+ my $fault_code = $result-{'value'}[0]{'faultCode'};
+ my $fault_string = $result-{'value'}[0]{'faultString'};
+
+ if (defined $self-{'use_objects'} $self-{'use_objects'}) {
+ $fault_code = $fault_code-value;
+ $fault_string = $fault_string-value;
+ }
+
+ die Fault returned from XML RPC Server, fault code $fault_code:
+ . $fault_string\n;
}
return $result-{'value'}[0];
Bug#309954: xmlrpc-c: Curl support still not linked in
Package: xmlrpc-c Version: 1.06.18-1 Followup-For: Bug #309954 The xmlrpc-c packages were probably built on a system without the libcurl4-openssl-dev package. I think adding this package to the source-dependencies should be enough. (i've locally rebuilt the xmlrpc-c packages with the libcurl4-openssl-dev package installed; this solved the SSL-support problem for me) -- System Information: Debian Release: lenny/sid APT prefers oldstable APT policy: (500, 'oldstable'), (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.18.8.0pundit1 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#356810: libcrypt-cbc-perl: behaviour-change; header_iv bugs (both sending as receiving)
Package: libcrypt-cbc-perl
Version: 2.12-1sarge1
Severity: grave
Justification: renders package unusable
I've detected 4 problems with the security update of libcrypt-cbc-perl;
1. I'm using Crypt::CBC between several systems; the one system encrypts
data and the other decrypts data. In this security update, you've
changed the header from 'RandomIV' to 'Salted__'. Unfortunately, when
using Crypt::CBC on both sides (one old version of the package, and the
other this new libcrypt-cbc-perl version), the older one cannot decrypt
the messages from the new debian package anymore. I don't think you
would like to have this in a stable release. (at least.. not as default
without a compatibility fallback)
2. The prepend_iv option (default ON) sets the 'my $prepend_header'
variable, but the encrypt function expects this to be
$self-{prepend_header}. Result: $self-{prepend_header} is always
undef, and no header is prepended.
3. On decrypting, the salt and/or iv option is retrieved from the
data-stream. The Salted__ option doesn't work:
$self-{salt} = $salt; # Replace manually-specified salt
undef $self-{key}; # reset the key and iv
undef $self-{iv};
and after that:
my $salt = $self-_get_random_bytes(8);
my ($key,$iv) = $self-_salted_key_and_iv($self-{key},$salt);
$self-{key} ||= $key; # don't replace manually-specified key
$self-{iv} ||= $iv;# don't replace manually-specified IV
Why is $salt randomized here. Should $salt not just be $self-{salt}?
(not tested, might be wrong)
4. On decrypting, the RandomIV option doesn't work either. Haven't
investigated this one further.
-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.15.5.0magnatz11
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Versions of packages libcrypt-cbc-perl depends on:
ii libcrypt-blowfish-perl 2.09-5Blowfish cryptography for Perl
ii libcrypt-des-perl 2.03-3Perl DES encryption module
ii perl 5.8.4-8sarge3 Larry Wall's Practical Extraction
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#356810: Acknowledgement (libcrypt-cbc-perl: behaviour-change; header_iv bugs (both sending as receiving))
About item 4: To work around the problems i've had, I encoded my data with: my $encrypted = 'RandomIV'.$crypt-iv.$crypt-encrypt(some data); Since the iv is not generated in the constructor but at the moment we start encrypting, the iv was undef/'', and my test failed. I've retested the library with: my $encrypted = $crypt-encrypt(some data); $encrypted = 'RandomIV'.$crypt-iv.$encrypted; This worked without any problems, so scrap bugreport item 4 :) -- Bas van Sisseren [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#322145: libopensc1 0.9.6-2 triggers assertion in card.c
If you mean the libopensc2 package which is in unstable for about 1.5 weeks now, then yes. I haven't tested it very extensively, but i had the same problems with the ssh-agent as i had with the libopensc1 0.9.6-2 package. I can do some more testing when i am on the office next tuesday. On Sat, 14 Jan 2006, Eric Dorland wrote: Are you still seeing this with the 0.10 series? * Bas van Sisseren ([EMAIL PROTECTED]) wrote: On 10/08/05 23:39, Eric Dorland wrote: * Bas van Sisseren ([EMAIL PROTECTED]) wrote: Package: opensc Version: 0.9.6-2 Severity: important I'm using a recompiled ssh-agent with opensc support on debian unstable. (using it for my cryptoflex e-gate 32k token) With libopensc1 version 0.9.6-1 everything works perfectly: (ssh-agent -d output:) debug1: type 20 debug1: sc_get_keys called: id = 0 debug1: sc_read_pubkey() with cert id 45 debug1: fingerprint 2048 key fingerprint debug1: XXX shrink: 3 4 debug1: type 11 debug1: type 13 debug1: XXX shrink: 3 4 But with libopensc1 version 0.9.6-2, an assertion error is triggered: (ssh-agent -d output:) debug1: type 11 debug1: XXX shrink: 3 4 debug1: type 20 debug1: sc_get_keys called: id = 0 debug1: sc_read_pubkey() with cert id 45 debug1: fingerprint 2048 key fingerprint debug1: XXX shrink: 3 4 debug1: type 11 debug1: type 13 ssh-agent: card.c:205: sc_transceive: Assertion `recvsize = 2' failed. Aborted Since there aren't many changes between these releases, i think it is caused by some library you are linking with. Unfortunately, i don't have much extra information at the moment, but if there's something you would like me to test, let me know. Are you using openct or pcsc-lite as your terminal driver? I'm using openct. -- Bas van Sisseren [EMAIL PROTECTED] Quarantainenet -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#322145: libopensc1 0.9.6-2 triggers assertion in card.c
On 10/08/05 23:39, Eric Dorland wrote: * Bas van Sisseren ([EMAIL PROTECTED]) wrote: Package: opensc Version: 0.9.6-2 Severity: important I'm using a recompiled ssh-agent with opensc support on debian unstable. (using it for my cryptoflex e-gate 32k token) With libopensc1 version 0.9.6-1 everything works perfectly: (ssh-agent -d output:) debug1: type 20 debug1: sc_get_keys called: id = 0 debug1: sc_read_pubkey() with cert id 45 debug1: fingerprint 2048 key fingerprint debug1: XXX shrink: 3 4 debug1: type 11 debug1: type 13 debug1: XXX shrink: 3 4 But with libopensc1 version 0.9.6-2, an assertion error is triggered: (ssh-agent -d output:) debug1: type 11 debug1: XXX shrink: 3 4 debug1: type 20 debug1: sc_get_keys called: id = 0 debug1: sc_read_pubkey() with cert id 45 debug1: fingerprint 2048 key fingerprint debug1: XXX shrink: 3 4 debug1: type 11 debug1: type 13 ssh-agent: card.c:205: sc_transceive: Assertion `recvsize = 2' failed. Aborted Since there aren't many changes between these releases, i think it is caused by some library you are linking with. Unfortunately, i don't have much extra information at the moment, but if there's something you would like me to test, let me know. Are you using openct or pcsc-lite as your terminal driver? I'm using openct. -- Bas van Sisseren [EMAIL PROTECTED] Quarantainenet -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#322145: libopensc1 0.9.6-2 triggers assertion in card.c
Package: opensc Version: 0.9.6-2 Severity: important I'm using a recompiled ssh-agent with opensc support on debian unstable. (using it for my cryptoflex e-gate 32k token) With libopensc1 version 0.9.6-1 everything works perfectly: (ssh-agent -d output:) debug1: type 20 debug1: sc_get_keys called: id = 0 debug1: sc_read_pubkey() with cert id 45 debug1: fingerprint 2048 key fingerprint debug1: XXX shrink: 3 4 debug1: type 11 debug1: type 13 debug1: XXX shrink: 3 4 But with libopensc1 version 0.9.6-2, an assertion error is triggered: (ssh-agent -d output:) debug1: type 11 debug1: XXX shrink: 3 4 debug1: type 20 debug1: sc_get_keys called: id = 0 debug1: sc_read_pubkey() with cert id 45 debug1: fingerprint 2048 key fingerprint debug1: XXX shrink: 3 4 debug1: type 11 debug1: type 13 ssh-agent: card.c:205: sc_transceive: Assertion `recvsize = 2' failed. Aborted Since there aren't many changes between these releases, i think it is caused by some library you are linking with. Unfortunately, i don't have much extra information at the moment, but if there's something you would like me to test, let me know. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12.4-qbas.6 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages opensc depends on: ii libc6 2.3.5-3GNU C Library: Shared libraries an ii libopensc10.9.6-2SmartCard library with support for ii libssl0.9.7 0.9.7g-1 SSL shared libraries opensc recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
