Bug#723180: [PATCH] Revert "x86: Disable IST stacks for debug/int 3/stack fault for PREEMPT_RT"
where do I start. Let me explain what is going on here. The code
sequence
| pushf
| pop%edx
| or $0x1,%dh
| push %edx
| mov$0xe0,%eax
| popf
| sysenter
triggers the bug. On 64bit kernel we see the double fault (with 32bit and
64bit userland) and on 32bit kernel there is no problem. The reporter said
that double fault does not happen on 64bit kernel with 64bit userland and
this is because in that case the VDSO uses the "syscall" interface instead
of "sysenter".
The bug. "popf" loads the flags with the TF bit set which enables
"single stepping" and this leads to a debug exception. Usually on 64bit
we have a special IST stack for the debug exception. Due to patch [0] we
do not use the IST stack but the kernel stack instead. On 64bit the
sysenter instruction starts in kernel with the stack address NULL. The
code sequence above enters the debug exception (TF flag) after the
sysenter instruction was executed which sets the stack pointer to NULL
and we have a fault (it seems that the debug exception saves some bytes
on the stack).
To fix the double fault I'm going to drop patch [0]. It is completely
pointless. In do_debug() and do_stack_segment() we disable preemption
which means the task can't leave the CPU. So it does not matter if we run
on IST or on kernel stack.
There is a patch [1] which drops preempt_disable() call for a 32bit
kernel but not for 64bit so there should be no regression.
And [1] seems valid even for this code sequence. We enter the debug
exception with a 256bytes long per cpu stack and migrate to the kernel
stack before calling do_debug().
[0] x86-disable-debug-stack.patch
[1] fix-rt-int3-x86_32-3.2-rt.patch
Reported-by: Brian Silverman
Cc: Andi Kleen
Signed-off-by: Sebastian Andrzej Siewior
---
arch/x86/include/asm/page_64_types.h | 21 ++---
arch/x86/kernel/cpu/common.c | 2 --
arch/x86/kernel/dumpstack_64.c | 4
3 files changed, 6 insertions(+), 21 deletions(-)
diff --git a/arch/x86/include/asm/page_64_types.h
b/arch/x86/include/asm/page_64_types.h
index 695e04d..43dcd80 100644
--- a/arch/x86/include/asm/page_64_types.h
+++ b/arch/x86/include/asm/page_64_types.h
@@ -14,21 +14,12 @@
#define IRQ_STACK_ORDER 2
#define IRQ_STACK_SIZE (PAGE_SIZE << IRQ_STACK_ORDER)
-#ifdef CONFIG_PREEMPT_RT_FULL
-# define STACKFAULT_STACK 0
-# define DOUBLEFAULT_STACK 1
-# define NMI_STACK 2
-# define DEBUG_STACK 0
-# define MCE_STACK 3
-# define N_EXCEPTION_STACKS 3 /* hw limit: 7 */
-#else
-# define STACKFAULT_STACK 1
-# define DOUBLEFAULT_STACK 2
-# define NMI_STACK 3
-# define DEBUG_STACK 4
-# define MCE_STACK 5
-# define N_EXCEPTION_STACKS 5 /* hw limit: 7 */
-#endif
+#define STACKFAULT_STACK 1
+#define DOUBLEFAULT_STACK 2
+#define NMI_STACK 3
+#define DEBUG_STACK 4
+#define MCE_STACK 5
+#define N_EXCEPTION_STACKS 5 /* hw limit: 7 */
#define PUD_PAGE_SIZE (_AC(1, UL) << PUD_SHIFT)
#define PUD_PAGE_MASK (~(PUD_PAGE_SIZE-1))
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index c0dcf06..2793d1f 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -1105,9 +1105,7 @@ DEFINE_PER_CPU(struct task_struct *, fpu_owner_task);
*/
static const unsigned int exception_stack_sizes[N_EXCEPTION_STACKS] = {
[0 ... N_EXCEPTION_STACKS - 1]= EXCEPTION_STKSZ,
-#if DEBUG_STACK > 0
[DEBUG_STACK - 1] = DEBUG_STKSZ
-#endif
};
static DEFINE_PER_CPU_PAGE_ALIGNED(char, exception_stacks
diff --git a/arch/x86/kernel/dumpstack_64.c b/arch/x86/kernel/dumpstack_64.c
index 52b4bcd..addb207 100644
--- a/arch/x86/kernel/dumpstack_64.c
+++ b/arch/x86/kernel/dumpstack_64.c
@@ -21,14 +21,10 @@
(N_EXCEPTION_STACKS + DEBUG_STKSZ/EXCEPTION_STKSZ - 2)
static char x86_stack_ids[][8] = {
-#if DEBUG_STACK > 0
[ DEBUG_STACK-1 ] = "#DB",
-#endif
[ NMI_STACK-1 ] = "NMI",
[ DOUBLEFAULT_STACK-1 ] = "#DF",
-#if STACKFAULT_STACK > 0
[ STACKFAULT_STACK-1] = "#SS",
-#endif
[ MCE_STACK-1 ] = "#MC",
#if DEBUG_STKSZ > EXCEPTION_STKSZ
[ N_EXCEPTION_STACKS ...
--
1.8.5.2
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#604256: xsd: FTBFS on armel, hppa, mips, powerpc, s390 and sparc
Package: src:xsd Version: 3.3.0-2 Severity: serious Your package: FTBFS on a few architectures [0]. Mips, powerpc, s390 and sparc are all big endian. All architectures which built were little endian. Here is a snippet from powerpc [1]: |ld /build/buildd-xsd_3.3.0-2-powerpc-MuXwhF/xsd-3.3.0/xsd-srcdir/xsd/tests/cxx/tree/encoding/char/utf-8/driver |test /build/buildd-xsd_3.3.0-2-powerpc-MuXwhF/xsd-3.3.0/xsd-srcdir/xsd/tests/cxx/tree/encoding/char/utf-8/driver |Binary files /build/buildd-xsd_3.3.0-2-powerpc-MuXwhF/xsd-3.3.0/xsd-srcdir/xsd/tests/cxx/tree/encoding/char/utf-8/test.std and - differ |make[1]: *** [/build/buildd-xsd_3.3.0-2-powerpc-MuXwhF/xsd-3.3.0/xsd-srcdir/xsd/tests/cxx/tree/encoding/char/utf-8/.test] Error 2 |make[1]: Leaving directory `/build/buildd-xsd_3.3.0-2-powerpc-MuXwhF/xsd-3.3.0/xsd-srcdir' |dh_auto_test: make -j1 test returned exit code 2 |make: *** [build] Error 29 |dpkg-buildpackage: error: debian/rules build gave error exit status 2 I assume that this has something to do with the endianess of the architecture but I could be wrong. It also failed on armel which is little endian but the error there was different [2]: |ld /build/buildd-xsd_3.3.0-2-armel-RuYpA2/xsd-3.3.0/xsd-srcdir/xsd/tests/cxx/parser/built-in/driver |/build/buildd-xsd_3.3.0-2-armel-RuYpA2/xsd-3.3.0/xsd-srcdir/xsd/tests/cxx/parser/built-in/driver.o: In function `virtual thunk to xsd::cxx::parser::non_validating::base64_binary_pimpl::post_base64_binary()': |/build/buildd-xsd_3.3.0-2-armel-RuYpA2/xsd-3.3.0/xsd-srcdir/xsd/tests/cxx/parser/built-in/driver.cxx:531: undefined reference to `_ZNSt8auto_ptrIN3xsd3cxx6parser6bufferEEcvSt12auto_ptr_refIT_EIS3_EEv' |/build/buildd-xsd_3.3.0-2-armel-RuYpA2/xsd-3.3.0/xsd-srcdir/xsd/tests/cxx/parser/built-in/driver.cxx:531: undefined reference to `std::auto_ptr::auto_ptr(std::auto_ptr_ref)' |/build/buildd-xsd_3.3.0-2-armel-RuYpA2/xsd-3.3.0/xsd-srcdir/xsd/tests/cxx/parser/built-in/driver.o: In function `virtual thunk to xsd::cxx::parser::non_validating::hex_binary_pimpl::post_hex_binary()': |/build/buildd-xsd_3.3.0-2-armel-RuYpA2/xsd-3.3.0/xsd-srcdir/xsd/tests/cxx/parser/built-in/driver.cxx:531: undefined reference to `_ZNSt8auto_ptrIN3xsd3cxx6parser6bufferEEcvSt12auto_ptr_refIT_EIS3_EEv' |/build/buildd-xsd_3.3.0-2-armel-RuYpA2/xsd-3.3.0/xsd-srcdir/xsd/tests/cxx/parser/built-in/driver.cxx:531: undefined reference to `std::auto_ptr::auto_ptr(std::auto_ptr_ref)' |collect2: ld returned 1 exit status |make[1]: *** [/build/buildd-xsd_3.3.0-2-armel-RuYpA2/xsd-3.3.0/xsd-srcdir/xsd/tests/cxx/parser/built-in/driver] Error 1 |make[1]: Leaving directory `/build/buildd-xsd_3.3.0-2-armel-RuYpA2/xsd-3.3.0/xsd-srcdir' |dh_auto_test: make -j1 test returned exit code 2 |make: *** [build] Error 29 |dpkg-buildpackage: error: debian/rules build gave error exit status 2 [0] https://buildd.debian.org/status/package.php?p=xsd. [1] https://buildd.debian.org/fetch.cgi?pkg=xsd&arch=powerpc&ver=3.3.0-2&stamp=1290293922&file=log&as=raw [2] https://buildd.debian.org/fetch.cgi?pkg=xsd&arch=armel&ver=3.3.0-2&stamp=1290298701&file=log&as=raw Sebastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#604766: fmtools: FTBFS on all buildds, missing configure files
Package: src:fmtools Version: 2.0.4 Severity: serious Your package FTBS on all buildds[0]. Here is snippet from s390: |dh_clean | debian/rules build |dh_testdir |./configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib |configure: error: cannot find install-sh, install.sh, or shtool in build-aux "."/build-aux |make: *** [build-stamp] Error 1 |dpkg-buildpackage: error: debian/rules build gave error exit status 2 [0] https://buildd.debian.org/status/package.php?p=fmtools&suite=unstable [1] https://buildd.debian.org/fetch.cgi?pkg=fmtools&arch=s390&ver=2.0.4&stamp=1290534790&file=log&as=raw Sebastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#605225: raidutils: ftbfs on all architectures, missing autotools_dev
Package: src:raidutils Version: 0.0.6-14 Severity: serious Your package FTBFS on all architectures [0]. Here is a snippet from powerpc[1]: |pkg-buildpackage: source package raidutils |dpkg-buildpackage: source version 0.0.6-14 | dpkg-source --before-build raidutils-0.0.6 |dpkg-buildpackage: host architecture powerpc | /usr/bin/fakeroot debian/rules clean |dh clean --with autotools_dev |dh: unable to load addon autotools_dev: Can't locate Debian/Debhelper/Sequence/autotools_dev.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.10.1 /usr/local/share/perl/5.10.1 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl .) at (eval 8) line 2. |BEGIN failed--compilation aborted at (eval 8) line 2. | |make: *** [clean] Error 2 |dpkg-buildpackage: error: /usr/bin/fakeroot debian/rules clean gave error exit status 2 [0] https://buildd.debian.org/status/package.php?p=raidutils [1] https://buildd.debian.org/fetch.cgi?pkg=raidutils&arch=powerpc&ver=0.0.6-14&stamp=1290787801&file=log&as=raw Sebastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#723987: Debian Bug report logs - #723987
On 26.01.14, Jose Miguel Mata wrote: > root@debian01:~# apt-get -f install > Leyendo lista de paquetes... Hecho > Creando árbol de dependencias > Leyendo la información de estado... Hecho > 0 actualizados, 0 se instalarán, 0 para eliminar y 0 no actualizados. > 1 no instalados del todo o eliminados. > Se utilizarán 0 B de espacio de disco adicional después de esta operación. > Configurando console-common (0.7.88) ... > Looking for keymap to install: > es > update-rc.d: warning: start and stop actions are no longer supported; > falling back to defaults > root@debian01:~# apt-get -f install > Leyendo lista de paquetes... Hecho > Creando árbol de dependencias > Leyendo la información de estado... Hecho > 0 actualizados, 0 se instalarán, 0 para eliminar y 0 no actualizados. > root@debian01:~# So I got the english version of it and it did not go away on the second invocation. I took Hans' service file which is in [0] and it made it go away. Could this be fixed like this? [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=723987#15 Sebastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#723180: Double fault when single-stepping compat task with PREEMPT_RT
On 09/25/2013 03:24 PM, Ben Hutchings wrote:
> On Tue, 2013-09-24 at 13:43 -0700, Brian Silverman wrote: [...]
>> I got down to a really simple program that reproduces this bug:
>>
>>
>> #include #include int main() { // I've
>> tried SYS_getpid, SYS_write, and SYS_read here too.
>> syscall(SYS_gettid); }
Brian, thank you for this excellent stripped down test case.
I think I know what is going on, will dig more later.
> Ben.
>
Sebastian
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#732323: merge dupe with 732208
reassign 732323 src:linux found 732323 3.2.53-1 forcemerge 732208 732323 thanks this is a copy of #732208 which has been fixed in the meantime. Sebastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#723180: [PATCH] Revert "x86: Disable IST stacks for debug/int 3/stack fault for PREEMPT_RT"
* Andi Kleen | 2014-01-04 19:18:07 [+0100]: >On Fri, Jan 03, 2014 at 02:55:48PM +0100, Sebastian Andrzej Siewior wrote: >> where do I start. Let me explain what is going on here. The code >> sequence > >Yes the IST stacks are needed for correctness, even in more cases than >the example below. You cannot just disable them, just because you don't >like them. Andi, you were the Author of that patch. I plan to migrate from the IST stack to the kernel stack so I can enable preemption. This is he case on 32bit. You mention more cases than this. Could you please give me some examples so I can consider them? >-Andi Sebastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#710195: [Pkg-libvirt-maintainers] Processed: Re: Bug#710195 closed by Guido Günther (Bug#710195: fixed in libvirt 1.2.4-1)
On 2014-05-17 15:09:00 [+0200], Guido Günther wrote: > which dependency are you still seeing? > -- Guido I think he meant: >From b19ba46d6a9c3b67a8a70457ed1970924bb97489 Mon Sep 17 00:00:00 2001 From: Sebastian Andrzej Siewior Date: Thu, 26 Jun 2014 20:08:04 +0200 Subject: [PATCH] drop libhal dependency last piece of #710195 Signed-off-by: Sebastian Andrzej Siewior --- debian/changelog | 6 ++ debian/control | 1 - 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/debian/changelog b/debian/changelog index 3868cc6..3da0075 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,9 @@ +libvirt (1.2.4-4) UNRELEASED; urgency=low + + * Remove last piece of hal (Closes: #710195) + + -- Sebastian Andrzej Siewior Thu, 26 Jun 2014 20:06:54 +0200 + libvirt (1.2.4-3) unstable; urgency=medium * [b0b7359] Don't pretend kFreeBSD supports linux only features. So far we diff --git a/debian/control b/debian/control index e20a0b1..dbfb930 100644 --- a/debian/control +++ b/debian/control @@ -22,7 +22,6 @@ Uploaders: Guido Günther , Laurent Léonard = 0.105-4~), -- 2.0.0 Sebastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#752861: CVE-2014-4607: potential integer overflow, fixed in 2.07
Package: src:lzo2 Version: 2.03-2 Severity: important Tags: security >From http://www.oberhumer.com/opensource/lzo/: |LZO 2.07 has been released: | |Fixed a potential integer overflow condition in the "safe" decompressor |variants which could result in a possible buffer overrun when processing |maliciously crafted compressed input data. | |As this issue only affects 32-bit systems and also can only happen if |you use uncommonly huge buffer sizes where you have to decompress more |than 16 MiB (2^24 bytes) compressed bytes within a single function call |the practical implications are limited. | |POTENTIAL SECURITY ISSUE. But then, I personally do not know about any |client program that actually is affected. I used the version from oldstable because it seems that all version of liblzo2 are affected. http://www.openwall.com/lists/oss-security/2014/06/26/20 Sebastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#710195: [Pkg-libvirt-maintainers] Processed: Re: Bug#710195 closed by Guido Günther (Bug#710195: fixed in libvirt 1.2.4-1)
* Guido Günther | 2014-06-26 21:54:40 [+0200]: >Already in VCS as 9321997cddf7bb5b030d6328d9db67eb4f5830f6 since May. >Cheers, It seems to be part of the experimental branch which also has new v1.2.5 in it. Please add the Closes tag to finally close the bug :) > -- Guido Sebastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#740059: clamav: LibClamAV Error: CRITICAL: fmap() failed
tags 740059 + upstream
forwarded 740059 https://bugzilla.clamav.net/show_bug.cgi?id=10971
thanks
On 2014-03-15 20:37:01 [+0100], Sebastian Andrzej Siewior wrote:
> On 2014-03-16 00:16:38 [+0700], Ста Деюс wrote:
> > Здравствуй, Sebastian.
Hello Ста,
the patch below is what I sent to clamav's bugzilla. It drops the memory
constrain a little which means it should be fine on 64bit. Now I wait what
upstream says.
>From 0a6fe67b724919a8c5583a762b7e10330c06b271 Mon Sep 17 00:00:00 2001
From: Sebastian Andrzej Siewior
Date: Thu, 10 Apr 2014 23:08:02 +0200
Subject: [PATCH] libclamav: fmap: try to mmap() the file instead read it
completly
On unix platform the fmap_check_empty() function maps the complete file
by allocating the memory via mmap() with the write flag on. On systems
with not a lot of memory it means that a file can't be scanned. For
instance a 1GiB file on a system with 512MiB of memory.
This patch changes the behaviour to what we have on win32:
- the malloc() cl_fmap_t structure
- mmap() the file as RO only. Since it content is backed by file on disk
we mmap() any file as long as our virtual memory space is large
enough. That means this will fail on 32bit architectures which try
scan a file which is ~2.8GiB. This failed before as well but now we
aleast not limited by our physical memory.
Signed-off-by: Sebastian Andrzej Siewior
---
libclamav/fmap.c | 85 +-
1 file changed, 71 insertions(+), 14 deletions(-)
diff --git a/libclamav/fmap.c b/libclamav/fmap.c
index 09b2306..929b496 100644
--- a/libclamav/fmap.c
+++ b/libclamav/fmap.c
@@ -52,6 +52,7 @@ static inline unsigned int fmap_which_page(fmap_t *m, size_t
at);
/* pread proto here in order to avoid the use of XOPEN and BSD_SOURCE
which may in turn prevent some mmap constants to be defined */
ssize_t pread(int fd, void *buf, size_t count, off_t offset);
+static cl_fmap_t *cl_fmap_mmap_fd(int fd, size_t offset, size_t len);
/* v POSIX STUFF BELOW v */
static off_t pread_cb(void *handle, void *buf, size_t count, off_t offset)
@@ -61,12 +62,8 @@ static off_t pread_cb(void *handle, void *buf, size_t count,
off_t offset)
fmap_t *fmap_check_empty(int fd, off_t offset, size_t len, int *empty) {
-unsigned int pages, mapsz, hdrsz;
-unsigned short dumb = 1;
-int pgsz = cli_getpagesize();
STATBUF st;
fmap_t *m;
-void *handle = (void*)(ssize_t)fd;
*empty = 0;
if(FSTAT(fd, &st)) {
@@ -84,10 +81,11 @@ fmap_t *fmap_check_empty(int fd, off_t offset, size_t len,
int *empty) {
cli_warnmsg("fmap: attempted oof mapping\n");
return NULL;
}
-m = cl_fmap_open_handle((void*)(ssize_t)fd, offset, len, pread_cb, 1);
+m = cl_fmap_mmap_fd(fd, offset, len);
if (!m)
return NULL;
m->mtime = st.st_mtime;
+m->handle = (void*)(long)fd;
m->handle_is_fd = 1;
return m;
}
@@ -161,6 +159,15 @@ fmap_t *fmap_check_empty(int fd, off_t offset, size_t len,
int *empty) { /* WIN3
}
#endif /* _WIN32 */
+/* v MEMORY STUFF BELOW v */
+
+static const void *mem_need(fmap_t *m, size_t at, size_t len, int lock);
+static void mem_unneed_off(fmap_t *m, size_t at, size_t len);
+static const void *mem_need_offstr(fmap_t *m, size_t at, size_t len_hint);
+static const void *mem_gets(fmap_t *m, char *dst, size_t *at, size_t max_len);
+
+static void unmap_none(fmap_t *m) {}
+
/* v SHARED STUFF BELOW v */
#define FM_MASK_COUNT 0x3fff
@@ -277,6 +284,65 @@ extern cl_fmap_t *cl_fmap_open_handle(void *handle, size_t
offset, size_t len,
return m;
}
+static void unmap_free_mmap(fmap_t *m)
+{
+ void *data = (void *)m->data;
+ munmap(data, m->real_len);
+ free(m);
+}
+
+static cl_fmap_t *cl_fmap_mmap_fd(int fd, size_t offset, size_t len)
+{
+cl_fmap_t *m;
+void *data;
+int pgsz = cli_getpagesize();
+
+if(offset < 0 || offset != fmap_align_to(offset, pgsz)) {
+ cli_warnmsg("fmap: attempted mapping with unaligned offset\n");
+ return NULL;
+}
+if(!len) {
+ cli_dbgmsg("fmap: attempted void mapping\n");
+ return NULL;
+}
+if (offset >= len) {
+ cli_warnmsg("fmap: attempted oof mapping\n");
+ return NULL;
+}
+
+m = cli_calloc(1, sizeof(*m));
+if (!m) {
+ cli_warnmsg("fmap: map allocation failed 1\n");
+ return NULL;
+}
+
+data = mmap(NULL, len, PROT_READ, MAP_SHARED, fd, offset);
+if (data == MAP_FAILED) {
+ cli_warnmsg("fmap: mmap() in file failed: %m\n");
+ goto err_free;
+}
+
+if(!m) {
+ cli_warnmsg("fmap: map allocation failed 2\n");
+ return NULL;
+}
+m->data = data;
+m->len = len;
+m->real_len = len;
+m->pgsz = pgsz;
+m->pages = fmap_align_items(len, pgsz);;
+m-&
Bug#744314: [Pkg-clamav-devel] Bug#744314: Bug#744314: clamav: [INTL:de] Update for the German debonf messages
tags 744314 - patch thanks On 2014-04-13 21:06:49 [+0200], Holger Wansing wrote: > Hi, Hi Holger, > > Can someone then review and improve it? > > Will be done. Good. In the meantime I remove the patch tag. > Thanks > > > Holger Sebastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#745754: [Pkg-clamav-devel] Bug#745754: clamav: [INTL:pt] Updated Portuguese translation for debconf messages
tags 745754 + pending thanks On 2014-04-24 19:37:26 [+0100], Américo Monteiro wrote: > Updated Portuguese translation for clamav's debconf messages. > (1 String updated) > Translator: Américo Monteiro > Feel free to use it. Thanks you. Sebastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#719069: git: "fatal: protocol error: bad line length character: Remo"
On 2013-09-24 09:50:56 [+0200], Sebastian Andrzej Siewior wrote: > On Thu, Aug 08, 2013 at 09:53:35AM -0700, Jonathan Nieder wrote: > > Yes, this is worth fixing in stable. Thanks for a clear report. > > Thanks. It seems 7.2 will be released on 12.Oct. Do you think you get this in > p-u? Is there anything I can help you with? ping. > > > Regards, > > Jonathan Sebastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#743874: [Pkg-clamav-devel] Bug#743874: clamav: [INTL:ja] New Japanese debconf translation
tags 743874 +pending thanks. On 2014-04-08 03:03:07 [+0900], victory wrote: > Dear clamav package maintainer, > > Here's Japanese po-debconf template translation (ja.po) file that > reviewed by several Japanese Debian developers and users. > > Could you apply it, please? Yes, thank you. Sebastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#542954: libclamunrar: No detection with big rar-Files without compression
On 2009-08-22 15:01:00 [+0200], nutzteil wrote:
> I made rar-archives with the compression-levels '-m0' to '-m5'.
> ('-m0' is RAR-Archive v14, the others are v1d)
>
> Put eicar / clamav-testfiles in it.
> When ther are small number of files, all is ok.
> But with a big number of files ( ~ 50 MB ~ 360 files from sp3.cab (WinXP)),
> the testfile is not detected in compression-level '-m0' (without compression).
Could it have something to do with --max-filesize & --max-scansize ?
Which means clamscan would stop early because the archive is too big.
If not, could you please provide a link to a testcase?
Sebastian
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#749027: [Pkg-clamav-devel] Bug#749027: The ClamAV daemon stops working.
On 2014-05-23 20:13:54 [+0800], Jim Barber wrote: > So the sequence of events was the upgrade on the 19th; freshclam on the > 20th; > then the first hang on the 21st. I see. Could you please go back to 0.98.3 and see if the issue goes away? It might be a regression in the comming up 0.98.4 of clamav. Just want to make sure. > Regards, > > Jim Barber Sebastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#749478: please enable support for python3 bindings
Package: src:babeltrace
Version: 1.2.1-2
Tags: patch
Severity: wishlist
Please enable python3 bindings in the babeltrace package. Patch
attached.
Sebastian
>From 52db172006200d97e3da7e3b87d1f29af0a9 Mon Sep 17 00:00:00 2001
From: Sebastian Andrzej Siewior
Date: Tue, 27 May 2014 10:45:20 +0200
Subject: [PATCH] enable build of the python3 bindings
It does not work with python2 at all (it compiles but this is it). The
readme says that python3.0+ is required. Therefore I specified the
python intepreter and config in the configure run instead of using a
build-conflict on python2.7, 2.6 and so on.
Signed-off-by: Sebastian Andrzej Siewior
---
debian/control| 15 ++-
debian/python3-babeltrace.install | 1 +
debian/rules | 5 -
3 files changed, 19 insertions(+), 2 deletions(-)
create mode 100644 debian/python3-babeltrace.install
diff --git a/debian/control b/debian/control
index 68fc9f8..9101c0c 100644
--- a/debian/control
+++ b/debian/control
@@ -3,7 +3,8 @@ Section: libs
Priority: extra
Maintainer: Jon Bernard
Build-Depends: debhelper (>= 9~), libglib2.0-dev (>= 2.16), uuid-dev,
- libpopt-dev, dh-autoreconf
+ libpopt-dev, dh-autoreconf, python3-dev, swig
+X-Python3-Version: >= 3.0
Standards-Version: 3.9.5
Vcs-Git: git://anonscm.debian.org/collab-maint/babeltrace.git
Vcs-Browser: http://anonscm.debian.org/gitweb/?p=collab-maint/babeltrace.git;a=summary
@@ -75,3 +76,15 @@ Description: Common Trace Format (CTF) development files
.
This package provides the development headers to link applications directly
against libbabeltrace-ctf.
+
+Package: python3-babeltrace
+Architecture: any
+Multi-Arch: same
+Pre-Depends: ${misc:Pre-Depends}
+Depends: ${shlibs:Depends}, ${misc:Depends}, ${python3:Depends}
+Description: Babeltrace conversion libraries
+ Babeltrace provides trace reading and writing libraries, as well as a trace
+ converter. Plugins can be created for any trace format to allow its conversion
+ to/from any other supported format.
+ .
+ This package provides the python bindings for babeltrace.
diff --git a/debian/python3-babeltrace.install b/debian/python3-babeltrace.install
new file mode 100644
index 000..4606faa
--- /dev/null
+++ b/debian/python3-babeltrace.install
@@ -0,0 +1 @@
+usr/lib/python3*
diff --git a/debian/rules b/debian/rules
index 47b025c..bd0aae3 100755
--- a/debian/rules
+++ b/debian/rules
@@ -4,7 +4,10 @@
export DEB_BUILD_MAINT_OPTIONS := hardening=+all
%:
- dh $@ --with autoreconf
+ dh $@ --with autoreconf --with python3
+
+override_dh_auto_configure:
+ PYTHON=python3 PYTHON_CONFIG=/usr/bin/python3-config dh_auto_configure -- --enable-python-bindings
override_dh_auto_build:
dh_auto_build -- V=1
--
2.0.0.rc4
Bug#749715: [Pkg-clamav-devel] Bug#749715: Bug#749715: clamav: Please update clamav with fix for upstream Bug #10960
On 2014-05-29 18:37:40 [+0200], Andreas Cadhalpun wrote: > As I don't know, when the PowerPC failure will be fixed, it's probably best > to cherry-pick this fix for wheezy. > > Scott, what do you think? I'm going to cherry-pick it for wheezy soon. > Best regards, > Andreas Sebastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#749715: [Pkg-clamav-devel] Bug#749715: Bug#749715: Bug#749715: clamav: Please update clamav with fix for upstream Bug #10960
On 2014-05-29 18:42:15 [+0200], Sebastian Andrzej Siewior wrote: > On 2014-05-29 18:37:40 [+0200], Andreas Cadhalpun wrote: > > As I don't know, when the PowerPC failure will be fixed, it's probably best > > to cherry-pick this fix for wheezy. > > > > Scott, what do you think? > > I'm going to cherry-pick it for wheezy soon. pushed to wheezy branch & build-tested on wheezy-amd64 Scott: I branched off 0.98.1+dfsg-4 & stole the changelog from stable. > > > Best regards, > > Andreas > Sebastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#749715: [Pkg-clamav-devel] Bug#749715: clamav: Please update clamav with fix for upstream Bug #10960
On 2014-05-29 23:28:56 [-0400], Scott Kitterman wrote: > Thanks. If I do UNRELEASED/unstable and make a source package and then > debdiff > 7u3 to 7u4 I get the attached diff, which is more than we want. For > resolving > this bug we want the minimal change. I can produce a reduced change tomorrow > or wait for you to do it in git, either way. Sorry, I assumed that they are the same. I re-pushed wheezy. Now I used git-dpm import-dsc from the last stable release. This sucked all the changes we had so far in stable as one patch. > Scott K Sebastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#749715: [Pkg-clamav-devel] Bug#749715: clamav: Please update clamav with fix for upstream Bug #10960
* Scott Kitterman | 2014-05-31 12:42:26 [-0400]:
>That also resulted in a stack of conflicts when I pulled from Alioth that I
git reset --hard origin/wheezy should fix this.
>don't have time to sort out right now. Please make a debdiff and attach it to
>the bug.
No problem.
>Scott K
Sebastian
diff -Nru clamav-0.98.1+dfsg/debian/changelog clamav-0.98.1+dfsg/debian/changelog
--- clamav-0.98.1+dfsg/debian/changelog 2014-05-31 21:00:42.0 +0200
+++ clamav-0.98.1+dfsg/debian/changelog 2014-05-31 21:00:43.0 +0200
@@ -1,3 +1,11 @@
+clamav (0.98.1+dfsg-1+deb7u4) UNRELEASED; urgency=medium
+
+ * cherry pick upstream patches to fix a crash while using clamscan. Added
+patches: c6f5ef98d ("bb #10970 - Force a filesize limit of UINT_MAX - 2")
+and 99ee2138c ("Key off INT_MAX") (Closes: #749715).
+
+ -- Sebastian Andrzej Siewior Fri, 30 May 2014 20:46:42 +0200
+
clamav (0.98.1+dfsg-1+deb7u3) stable; urgency=medium
[ Sebastian Andrzej Siewior ]
diff -Nru clamav-0.98.1+dfsg/libclamav/scanners.c clamav-0.98.1+dfsg/libclamav/scanners.c
--- clamav-0.98.1+dfsg/libclamav/scanners.c 2014-01-13 18:02:34.0 +0100
+++ clamav-0.98.1+dfsg/libclamav/scanners.c 2014-05-31 21:00:43.0 +0200
@@ -3107,6 +3107,19 @@
{
cli_ctx ctx;
int rc;
+STATBUF sb;
+
+/* We have a limit of around 2.17GB (INT_MAX - 2). Enforce it here. */
+if (map != NULL) {
+if ((size_t)(map->real_len) > (size_t)(INT_MAX - 2))
+return CL_CLEAN;
+} else {
+if (FSTAT(desc, &sb))
+return CL_ESTAT;
+
+if ((size_t)(sb.st_size) > (size_t)(INT_MAX - 2))
+return CL_CLEAN;
+}
memset(&ctx, '\0', sizeof(cli_ctx));
ctx.engine = engine;
Bug#750075: [Pkg-clamav-devel] Bug#750075: clamav: Wrong declaration of function destroy_ctx to cause undefined behaviour
tags 750075 + patch pending
thanks
On 2014-06-01 11:34:14 [+0100], Michael Tautschnig wrote:
fixed upstream by commit e0f667e7f1 ("bb11023 - Wrong declaration of
function destroy_ctx to cause undefined behavior").
> Best,
> Michael
Sebastian
>From e0f667e7f12ec561e6b87a3664f6f673c12908d3 Mon Sep 17 00:00:00 2001
From: Shawn Webb
Date: Mon, 2 Jun 2014 08:54:43 -0400
Subject: [PATCH] bb11023 - Wrong declaration of function destroy_ctx to cause
undefined behavior
---
sigtool/sigtool.c | 4 ++--
sigtool/vba.c | 3 ++-
sigtool/vba.h | 2 +-
3 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/sigtool/sigtool.c b/sigtool/sigtool.c
index 04279bc..60bd850 100644
--- a/sigtool/sigtool.c
+++ b/sigtool/sigtool.c
@@ -1530,12 +1530,12 @@ static int vbadump(const struct optstruct *opts)
return -1;
}
if(cli_ole2_extract(dir, ctx, &vba)) {
- destroy_ctx(ctx);
+ destroy_ctx(-1, ctx);
cli_rmdirs(dir);
free(dir);
return -1;
}
-destroy_ctx(ctx);
+destroy_ctx(-1, ctx);
if (vba)
sigtool_vba_scandir(dir, hex_output, vba);
cli_rmdirs(dir);
diff --git a/sigtool/vba.c b/sigtool/vba.c
index 08b2806..09fe6d2 100644
--- a/sigtool/vba.c
+++ b/sigtool/vba.c
@@ -93,7 +93,8 @@ cli_ctx *convenience_ctx(int fd) {
void destroy_ctx(int desc, cli_ctx *ctx) {
funmap(*(ctx->fmap));
-close(desc);
+if (desc >= 0)
+close(desc);
free(ctx->fmap);
cl_engine_free((struct cl_engine *)ctx->engine);
free(ctx);
diff --git a/sigtool/vba.h b/sigtool/vba.h
index 96ce1de..b321357 100644
--- a/sigtool/vba.h
+++ b/sigtool/vba.h
@@ -25,6 +25,6 @@
int sigtool_vba_scandir(const char *dirname, int hex_output, struct uniq *U);
cli_ctx *convenience_ctx(int fd);
-void destroy_ctx(cli_ctx *ctx);
+void destroy_ctx(int desc, cli_ctx *ctx);
#endif
--
2.0.0
Bug#750075: [Pkg-clamav-devel] Bug#750075: Included in 0.98.4
On 2014-06-02 14:49:50 [-0400], Scott Kitterman wrote: > The fix for this will be in 0.98.4. No need for a separate patch. Yes, I just learned that and that they will release 0.98.4 any time soon. Sebastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#748180: [Pkg-clamav-devel] Bug#748180: clamav: FTBFS on powerpc: test failure
On 2014-05-15 11:54:23 [+0800], Paul Wise wrote: > 99%: Checks: 960, Failures: 1, Errors: 1 > check_bytecode.c:136:F:arithmetic:test_bswap_jit:0: Invalid return value from > bytecode run, expected: beef, have: dead1 > > check_bytecode.c:111:E:arithmetic:test_inflate_int:0: (after this point) > Received signal 11 (Segmentation fault) > ... This is known. Scott filled an upstream bug. I assumed that this has something to do with the fact that we switched from in-tree llvm to what we have in Debian. I tried to build it with llvm-3.0, 2.9 and the testcase still failed. Yesterday I tried to bring the in-tree llvm-back and build it. The build failed, too. The log is available at [0]. Based on this, I assume an upstream change between 0.98.1 … 0.98.2 is responsible for this. [0] https://breakpoint.cc/buildlog-ppc-clamav-0.98.3+dfsg-2-internal-llvm.txt Sebastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#748180: [Pkg-clamav-devel] Bug#748180: Bug#748180: clamav: FTBFS on powerpc: test failure
tags 748180 + upstream forwarded 748180 https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=10;mbox=yes;bug=748180 thanks On 2014-05-15 14:19:10 [+0200], Sebastian Andrzej Siewior wrote: > Yesterday I tried to bring the in-tree llvm-back and build it. The build > failed, too. The log is available at [0]. Based on this, I assume an > upstream change between 0.98.1 … 0.98.2 is responsible for this. I have no fast box to bisect this. I've been told upstream is working on this (I can't access the bug report). They plan to release 0.94.4 quite soon, too. Would it be okay to drop jit/llvm on powerpc and bring it back once upstream fixed it? Afterall it blocks the update for wheezy not just the transition to testing. Sebastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#537249: command-line/options ignore
On 2009-07-17 11:06:16 [+0100], Joao Paulo Serrachinha wrote: > Sorry for my frustration, but this is an upstream problem. All i want is all > old command line options have a new On* directive. Meanwhile stick with > stable. Now, almost 5years later. Is this problem still there? I don't quite understand what you suggest we should do here. In case the problem is still there, you please explain the sollution you expect here? > Thanks in advance, > > João Serrachinha Sebastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#740059: clamav: LibClamAV Error: CRITICAL: fmap() failed
On 2014-02-25 17:08:56 [+0700], Sthu wrote: > FYI: about three weeks (after update) i see this behavior: > > /usr/bin/clamscan -r --bell --infected --detect-pua=yes --scan-elf=yes > --scan-mail=yes --algorithmic-detection=yes --scan-pe=yes --scan-ole2=yes > --scan-pdf=yes --scan-html=yes --scan-archive=yes ./dir > > LibClamAV Warning: fmap: map allocation failed > LibClamAV Error: CRITICAL: fmap() failed > LibClamAV Warning: fmap: map allocation failed > LibClamAV Error: CRITICAL: fmap() failed > > --- SCAN SUMMARY --- > Known viruses: 3137431 > Engine version: 0.98.1 > Scanned directories: 2 > Scanned files: 1 > Infected files: 0 > Total errors: 2 > Data scanned: 0.15 MB > Data read: 2736.85 MB (ratio 0.00:1) > Time: 12.648 sec (0 m 12 s) I tried a few things and didn't manage to reproduce this. It seems you try to scan one file which is approx. 2.7 GiB in size and the error message you quoted comes if you ran out of memory. Could you please state the amount of memory you have. Is it possible to share that file you try scan? If not can you give something else that shows that error? Sebastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#636881: Milter socket permissions not set properly
On 2011-10-27 07:16:54 [-0700], Dara Adib wrote:
> See my reply to #636877, but basically one either has to make clamav a
> member of group postfix or set SOCKET_RWGROUP
> in /etc/default/clamav-milter but not in clamav-milter.conf.
>
> > root@domine:/var/spool/postfix/clamav# grep Milter
> > /etc/clamav/clamav-milter.conf
> > MilterSocket /var/spool/postfix/clamav/clamav-milter.ctl
> > MilterSocketGroup postfix
> > MilterSocketMode 660
>
> clamav needs to be a member of group postfix so that it can set postfix
> group ownership for the milter socket.
>
> > s- 1 clamav clamav 0 Aug 6 19:20 clamav-milter.ctl
>
> Reproducing this problem, it seems that this is the behavior when
> clamav-milter cannot change the socket group ownership. There should be
> an error message "Failed to change socket ownership to group postfix"
> in syslog.
That error message appears in a recent version.
> And it does that as root. It seems the MilterSocket settings in
> clamav-milter.conf are applied by default after privileges are dropped,
> as clamav by default which can't change group ownership unless it is a
> member of the group.
>
> What works for me (besides adding clamav to group postfix, which might
> be an extra security risk?):
>
> $ grep Milter /etc/clamav/clamav-milter.conf
> MilterSocket /var/spool/postfix/clamav/clamav-milter.ctl
> #MilterSocketGroup postfix # handled by /etc/default/clamav-milter
> MilterSocketMode 660
> $ ls -l
> total 0
> srw-rw 1 clamav postfix 0 Oct 27 07:13 clamav-milter.ctl
> $ grep -v ^\# /etc/default/clamav-milter
> SOCKET_RWGROUP=postfix
> SOCKET_PATH=/var/spool/postfix/clamav/clamav-milter.ctl
>
> Since clamav-milter is started as root anyways and then drops privileges
> to user clamav in the default configuration, I would assume that the
> socket group ownership as specified in clamav-milter.conf could be
> changed earlier on as root, and that this would be the preferred fix
> (depending on upstream), obsoleting /etc/default/clamav-milter.
I have the following patch to get this behaviour.
>From dca6bd7cd4544fb2d30cf79fb3b9c4117e6b52c4 Mon Sep 17 00:00:00 2001
From: Sebastian Andrzej Siewior
Date: Tue, 11 Mar 2014 21:09:32 +0100
Subject: [PATCH] clamav-milter: setup socket before dropping root permission
If the milter socket should be setup as
|User clamav
|MilterSocket /var/run/clamav/clamav-milter.ctl
|MilterSocketGroup postfix
|MilterSocketMode 660
and the user clamav is not a member of the postfix then the start fails
with
| -> ERROR: Failed to change socket ownership to group postfix
This is not really required because the process is started as root. It
can first setup the socket and then drop the root permission and change
to the clamav user.
This patch does so. BTS #636881
Signed-off-by: Sebastian Andrzej Siewior
---
clamav-milter/clamav-milter.c | 193 +-
1 file changed, 98 insertions(+), 95 deletions(-)
diff --git a/clamav-milter/clamav-milter.c b/clamav-milter/clamav-milter.c
index 95ff8a0..49cca71 100644
--- a/clamav-milter/clamav-milter.c
+++ b/clamav-milter/clamav-milter.c
@@ -114,6 +114,104 @@ int main(int argc, char **argv) {
}
}
+if(!(my_socket = optget(opts, "MilterSocket")->strarg)) {
+ logg("!Please configure the MilterSocket directive\n");
+ logg_close();
+ optfree(opts);
+ return 1;
+}
+
+if(smfi_setconn(my_socket) == MI_FAILURE) {
+ logg("!smfi_setconn failed\n");
+ logg_close();
+ optfree(opts);
+ return 1;
+}
+if(smfi_register(descr) == MI_FAILURE) {
+ logg("!smfi_register failed\n");
+ logg_close();
+ optfree(opts);
+ return 1;
+}
+opt = optget(opts, "FixStaleSocket");
+umsk = umask(0777); /* socket is created with 000 to avoid races */
+if(smfi_opensocket(opt->enabled) == MI_FAILURE) {
+ logg("!Failed to create socket %s\n", my_socket);
+ logg_close();
+ optfree(opts);
+ return 1;
+}
+umask(umsk); /* restore umask */
+if(strncmp(my_socket, "inet:", 5) && strncmp(my_socket, "inet6:", 6)) {
+ /* set group ownership and perms on the local socket */
+ char *sock_name = my_socket;
+ mode_t sock_mode;
+ if(!strncmp(my_socket, "unix:", 5))
+ sock_name += 5;
+ if(!strncmp(my_socket, "local:", 6))
+ sock_name += 6;
+ if(*my_socket == ':')
+ sock_name ++;
+
+ if(optget(opts, "MilterSocketGroup")->enabled) {
+ char *gname = optget(opts, "MilterSocketGroup")->strarg, *end;
+ gid_t sock_gid = strtol(gname, &end,
Bug#636877: /etc/default/clamav-milter no longer used
On 2011-08-06 19:20:32 [+0200], martin f krafft wrote:
> /etc/default/clamav-milter used to define the RWGROUP for the milter
> socket (for postfix). This seems to be handled in clamav-milter.conf
> now.
With #636881 fixed, the patch below could be used to get rid of
etc/default/clamav-milter.
There is no need for that SOCKET_RWGROUP hack including waiting until
clamav-milter is up so that we can alter the permissions of the socket.
This can be handled by clamav-milter itself if it is started as root.
Signed-off-by: Sebastian Andrzej Siewior
---
debian/clamav-milter.default | 13 -
debian/clamav-milter.init.in | 30 +-
2 files changed, 5 insertions(+), 38 deletions(-)
delete mode 100644 debian/clamav-milter.default
diff --git a/debian/clamav-milter.default b/debian/clamav-milter.default
deleted file mode 100644
index 68b2d1e..000
--- a/debian/clamav-milter.default
+++ /dev/null
@@ -1,13 +0,0 @@
-#
-# clamav-milter init options
-#
-
-## SOCKET_RWGROUP
-# by default, the socket created by the milter has permissions
-# clamav:clamav:755. SOCKET_RWGROUP changes the group and changes the
-# permissions to 775 to give read-write access to that group.
-#
-# If you are using postfix to speak to the milter, you have to give permission
-# to the postfix group to write
-#
-#SOCKET_RWGROUP=postfix
diff --git a/debian/clamav-milter.init.in b/debian/clamav-milter.init.in
index 6f29b02..5298ab7 100644
--- a/debian/clamav-milter.init.in
+++ b/debian/clamav-milter.init.in
@@ -27,8 +27,6 @@ CLAMAVDAEMONUPGRADE="/var/run/clamav-daemon-being-upgraded"
. /lib/lsb/init-functions
-[ -r /etc/default/clamav-milter ] && . /etc/default/clamav-milter
-
if [ ! -f "$CLAMAVCONF" ]; then
log_failure_msg "There is no configuration file for clamav-milter."
log_failure_msg "Please either dpkg-reconfigure $DESC, or copy the example
from"
@@ -38,7 +36,10 @@ if [ ! -f "$CLAMAVCONF" ]; then
fi
slurp_config "$CLAMAVCONF"
-[ -n "$User" ] || User=clamav
+if [ -z "$User" ]; then
+ log_failure_msg "'User' not specified in $CLAMAVCONF"
+ exit 1
+fi
if [ -n "$Example" ]; then
log_failure_msg "$DESC is not configured."
@@ -71,23 +72,6 @@ wait_for_socket()
test $retries -ne 0
}
-change_socket_group()
-{
- local socket; socket="$1"
- local group; group="$2"
- local retries; retries=${3:-15}
- local sleeptime; sleeptime=${4:-1}
-
- [ -n "$group" ] || return 0
-
- if wait_for_socket "$socket" $retries $sleeptime; then
-chmod g+w "$SOCKET_PATH"
-chgrp "$SOCKET_RWGROUP" "$SOCKET_PATH"
- else
-log_warning_msg "Tried to change socket group, but socket did not appear."
- fi
-}
-
case "$SOCKET" in
/*)
SOCKET_PATH="$SOCKET"
@@ -124,7 +108,6 @@ else
fi
[ "$PID" = '1' ] && unset PID
-[ -n "$User" ] || User=clamav
[ -n "$DataBaseDirectory" ] || DataBaseDirectory=/var/run/clamav
make_dir "$DataBaseDirectory"
@@ -153,7 +136,7 @@ case "$1" in
fi
if [ -z "$RUN_SUPERVISED" ] ; then
log_daemon_msg "Starting $DESC" "$NAME"
-start-stop-daemon --start -o -c $User --exec $DAEMON
+start-stop-daemon --start -o --exec $DAEMON
ret=$?
else
log_daemon_msg "Starting $DESC" "$NAME (supervised)"
@@ -161,9 +144,6 @@ case "$1" in
ret=$?
fi
- # try 15*1 seconds to change the socket group
- change_socket_group "$SOCKET_PATH" "$SOCKET_RWGROUP" 15 1
-
log_end_msg $ret
;;
stop)
--
1.9.0
Any comments? I didn't manage to get /etc/default/clamav-milter removed
on update.
Sebastian
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#636877: [Pkg-clamav-devel] Bug#636877: /etc/default/clamav-milter no longer used
On 2014-03-13 19:37:22 [-0400], Scott Kitterman wrote: > Does it drop privileges itself somehow? Given clamav's security history and > what it does, I don't think running as root is a good idea. Yes it does but only if you specify "User" in clamav-milter.conf. I could alter it to refuse to start if it remains as root. Sebastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#636877: [Pkg-clamav-devel] Bug#636877: /etc/default/clamav-milter no longer used
On 2014-03-14 15:08:41 [-0400], Scott Kitterman wrote: > In principle, we could check during configure if a User was specified in the > .conf (and set it if it wasn't). That would be, I believe, a sane transition > from starting as user to starting as root and letting the milter itself drop > privs. Okay. So we have a user by default or atleast by config (default one) had a user specified. The init script however fallbacks to clamav if none was specified. Don't know if this was case once. And then you have SOCKET_RWGROUP which seems to be used by people as a workaround. What about SOCKET_RWGROUP? Do you want to edit the config file and this group in /etc/clamav/clamav-milter.conf? > I don't think it should refuse to start as root. If the user actively works > at shooting themselves in the foot, then it isn't our job to stop them. We > mostly need to find a sane default. fair enough. > Please (probably via bugzilla) see if you can get an upstream review of the > patch. Failing that, sgran could likely do it, but there'll be some latency > there since he's very busy with other stuff. Done. Waiting for feedback. > > Scott K Sebastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#740059: clamav: LibClamAV Error: CRITICAL: fmap() failed
On 2014-03-16 00:16:38 [+0700], Ста Деюс wrote: > Здравствуй, Sebastian. Hello Ста, > You have guessed right: i less than 2.7 GB of RAM, while i was > scanning file of 2.7 GB in size. What kind of file is it? Is this some kind of raw data or an archive? > So, you can assuredly close my report. Thank you for your work for > Debian! So you definitly do not want any more investigation on this? From my point of view it should be possible to scan a file which larger than your RAM. > Хорошего времени суток. > > > С уважением, > Ста. Sebastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#414122: clamav-freshclam: does not honor umask
On 2007-03-10 10:58:23 [+0100], Marc Haber wrote: > It would be great if this were configurable. Upstream suggests [0] to use OnUpdateExecute to alter the permisions after the update. Does this work for you? [0] https://bugzilla.clamav.net/show_bug.cgi?id=470#c3 > Greetings > Marc > Sebastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#669287: clamav-daemon: if clamd is not running with userid clamav logrotate will go wrong
found 669287 0.97.3+dfsg-1 fixed 669287 0.98.1+dfsg-4 thanks. On 2012-04-11 22:46:06 [+0200], Ruud Baart wrote: > > I configured to run clamav with User = "amavis". This means that the logfiles > in /var/log/clamav should be owned > by "amavis". However in /etc/logrotate.d/clamav-daemon is "create 640 clamav > adm". Logfile /var/log/clamav/clamav.log > can't be written after very logrotate. The problem exists if you use configuration frontend. As far as I can see, this has been fixed Andreas in the latest version. Now, if you select "Do you want to enable log rotation?" => yes then newly created lograte config file will use the proper user. Sebastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#693632: gcc-snapshot: depends on libc6-dev-x32 which is not in Debian
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sun, Nov 18, 2012 at 07:59:39PM +, Thorsten Glaser wrote: > tg@zigo:~ $ sudo apt-get --purge dist-upgrade > Broken gcc-snapshot:amd64 Depends on libc6-dev-x32 [ amd64 ] < none > ( none > ) (>= 2.11) This isn't that critical. A binary-NMU could solve that problem. I have a rebuilt of it with SHA1 fa846fdc9182b840b38c982be38a208c6d7ad3bd gcc-snapshot_20121116-1_amd64.deb at [0] if you want :) The package does not build on i386 for instance. It ends with |libtool: compile: /mnt/sdb/bigeasy/gcc-snapshot-20121116/build/./gcc/g++ -B/mnt/sdb/bigeasy/gcc-snapshot-20121116/build/./gcc/ -nostdinc++ -nostdinc++ -I/mnt/sdb/bigeasy/gcc-snapshot-20121116/build/i486-linux-gnu/64/libstdc++-v3/include/i486-linux-gnu -I/mnt/sdb/bigeasy/gcc-snapshot-20121116/build/i486-linux-gnu/64/libstdc++-v3/include -I/mnt/sdb/bigeasy/gcc-snapshot-20121116/src/libstdc++-v3/libsupc++ -I/mnt/sdb/bigeasy/gcc-snapshot-20121116/src/libstdc++-v3/include/backward -I/mnt/sdb/bigeasy/gcc-snapshot-20121116/src/libstdc++-v3/testsuite/util -L/mnt/sdb/bigeasy/gcc-snapshot-20121116/build/i486-linux-gnu/64/libstdc++-v3/src -L/mnt/sdb/bigeasy/gcc-snapshot-20121116/build/i486-linux-gnu/64/libstdc++-v3/src/.libs -B/usr/lib/gcc-snapshot/i486-linux-gnu/bin/ -B/usr/lib/gcc-snapshot/i486-linux-gnu/lib/ -isystem /usr/lib/gcc-snapshot/i486-linux-gnu/include -isystem /usr/lib/gcc-snapshot/i486-linux-gnu/sys-include -m64 -D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -DASAN_HAS_EXCEPTIONS=1 -DASAN_FLEXIBLE_MAPPING_AND_OFFSET=0 -DASAN_NEEDS_SEGV=1 -I. -I../../../../../src/libsanitizer/asan -I ../../../../../src/libsanitizer/include -I ../../../../../src/libsanitizer -Wall -W -Wno-unused-parameter -Wwrite-strings -pedantic -Wno-long-long -fPIC -fno-builtin -fno-exceptions -fomit-frame-pointer -funwind-tables -fvisibility=hidden -Wno-variadic-macros -Wno-c99-extensions -g -O2 -D_GNU_SOURCE -m64 -MT asan_new_delete.lo -MD -MP -MF .deps/asan_new_delete.Tpo -c ../../../../../src/libsanitizer/asan/asan_new_delete.cc -fPIC -DPIC -o .libs/asan_new_delete.o |In file included from ../../../../../src/libsanitizer/asan/asan_new_delete.cc:18:0: |/mnt/sdb/bigeasy/gcc-snapshot-20121116/src/libstdc++-v3/libsupc++/new:41:28: fatal error: bits/c++config.h: No such file or directory | #include |^ |compilation terminated. |make[8]: *** [asan_new_delete.lo] Error 1 |make[8]: Leaving directory `/mnt/sdb/bigeasy/gcc-snapshot-20121116/build/i486-linux-gnu/64/libsanitizer/asan' The header file in question is available: |./build/i486-linux-gnu/64/libstdc++-v3/include/x86_64-linux-gnu/bits/c++config.h |./build/i486-linux-gnu/libstdc++-v3/include/i486-linux-gnu/bits/c++config.h I'm not 100% sure about the multi lib paths but either the 64 path should use i486-linux-gnu instead of x86_64-linux-gnu _or_ the -I parameter passed to libsanitizer has to be changed to x86_64-linux-gnu instead of i486… I think the latter is the correct one. [0] http://download.breakpoint.cc/gcc-snapshot_20121116-1_amd64.deb Sebastian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQq8Q+AAoJEHuW6BYqjPXR/24P/08325OB6+Cn+OyZ7ZiWS+sT lEZSC20xXEIRNReNUAzkUiglJk7IDAKslsdT2OOcmShgJ7XCtQfmKx8IgCNWCzjQ CexSJwll7KFq/MB+Wv0gc5aa2LbUYPQj/u6ilqj6U8NFWPKVcs2tnBQRY38hkM7w FTguDxTfHCFuui5heiD/Cykn8R2rLKIw4xsyeZ/DyRkOZU4y7FBeCR9y13XwBvgP psLEj5QiDzQiLP8NF47je9tBb/8zaZ5rY+QlTUzfFNJfxW7SevGOo9IqdNiYHFdl tkhKwcoWgGbOG1u0DAowrdEExIV9UCtyQEMWS5nLlQTqDGelpRmAFEzOiV1153PP a7jfPmZpSZnSaXnPF8bRj1VZw8JGGezhS2toy55ieZnG74GrhExW73sU0ga4Qbf2 JsALrGmXy+A+18dbXo3W0SzIzUsT52E4FQQva9BW0Hlu5SU/eNejOndoQB+Q56cM 4Gg1O69QmO+zosUXBzEgxGAcUWnYrb+bVSYou8yUdTNMc5KeJzdX1zaJQQdIKnfU 27LGpgnm48M84S6GiHNl01VOsxflVLegAq7VlE1qgThVoMvt9mD28YStb4dYrFf0 24nEiQ2E8nm0tVgCHypyXbcaBfGGM/LmHyK9Ylx46DczGVcxG9BT83tX30ePDhK4 WGC7V0KDY0UXhR8uNmTa =9MpD -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#656225: targetcli: please add python-urwid somewhere
Package: targetcli Version: 2.0rc1-2 Severity: minor Please add "python-urwid" to package's suggest list. It does not really depend on it but it can make use of it. For instance if don't have it installed and enter "cd" then you see a backtrace. With this package installed you are able to browse and click on the folder where you want to step in. Sebastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#682389: refdbg: wrong lib paths
Package: src:refdbg
Version: 1.2+git20101215+aa5cb3-2
Severity: Serious
I have here 1.2+git20101215+aa5cb3-2+b1 installed. refdbg binary ends with:
| if [ "x${REFDBG_OPTIONS}" == "x" ] ; then
| LD_PRELOAD=/usr/lib/librefdbg.so "${@:ndx}"
| else
| REFDBG_OPTIONS="${REFDBG_OPTIONS}" LD_PRELOAD=/usr/lib/librefdbg.so \
| "${@:ndx}"
| fi
There are patches in debian/patches to fix this but there are not applied.
According to debian/source the patches should be applied during source
extraction via "dpkg-source -x" but this did not happen according to [0]. This
could be fixed via
index 324ed54..520bbb4 100644
--- a/debian/control
+++ b/debian/control
@@ -2,7 +2,7 @@ Source: refdbg
Section: devel
Priority: optional
Maintainer: Jonny Lamb
-Build-Depends: debhelper (>= 5), autotools-dev, pkg-config, libglib2.0-dev,
binutils-dev, libtool, automake
+Build-Depends: debhelper (>= 5), autotools-dev, pkg-config, libglib2.0-dev,
binutils-dev, libtool, automake, quilt
Standards-Version: 3.9.1
Homepage: http://refdbg.sourceforge.net/
Vcs-Git: git://git.jonnylamb.com/git/packaging/refdbg.git
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..be3a1a2
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1,2 @@
+0001-Add-disable-visibility-gobject-library-to-path.patch
+0002-Change-location-of-librefdbg.so.patch
diff --git a/debian/rules b/debian/rules
index fbeaae2..67d7c52 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,4 +1,5 @@
#!/usr/bin/make -f
+include /usr/share/quilt/quilt.make
DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
--
or a properly generated source package :)
While here, the git link does not work:
|git clone git://git.jonnylamb.com/git/packaging/refdbg.git
|Cloning into 'refdbg'...
|fatal: unable to connect to git.jonnylamb.com:
|git.jonnylamb.com[0: 212.110.189.148]: errno=Connection refused
|git.jonnylamb.com[1: 2001:41c8:1:61c5::148]: errno=Network is unreachable
[0]
https://buildd.debian.org/status/fetch.php?pkg=refdbg&arch=amd64&ver=1.2%2Bgit20101215%2Baa5cb3-2%2Bb1&stamp=1330942717
Sebastian
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#683161: intel-microcode: does not work with IUCODE_TOOL_SCANCPUS=yes
Package: intel-microcode
Version: 1.20120606.2
The cpuid driver is required for this to work, without it it fails silently:
|# iucode_tool -v -S
|iucode_tool: checked the signature of 0 processor(s)
|# echo $?
|0
This fix this, the /usr/share/initramfs-tools/hooks/intel-microcode could
be modified to something like this
|if [ -z "${IUCODE_TOOL}" -o "${IUCODE_TOOL_SCANCPUS}" != "yes" ] ; then
|verbose "Adding microcode for all Intel processor models"
|else
|verbose "Adding microcode for currently online Intel processors"
|if [ $(grep cpu/cpuid /proc/devices | wc -l) -eq 0 ]
|then
|modprobe cpuid
|fi
|if [ $(grep cpu/cpuid /proc/devices | wc -l) -eq 1 ]
|then
|IUCODE_TOOL_OPTIONS="${IUCODE_TOOL_OPTIONS} --scan-system"
|else
|verbose "msr module not found. IUCODE_TOOL_SCANCPUS can not
work"
|fi
|fi
Sebastian
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#711363: rt-tests: hackbench does not work in stable on armhf
Package: rt-tests Version: 0.83-1 Severity: serious Tags: patch fixed-upstream hackbench is a major component in this package and it can't be used on armhf: |$ hackbench |Running in process mode with 10 groups using 40 file descriptors each (== 400 tasks) |Each sender will pass 100 messages of 100 bytes |0 children started. Expected 40 |sending SIGTERM to all child processes |signaling 0 worker threads to terminate |Creating workers (error: Success) There is a fix for this: https://git.kernel.org/cgit/linux/kernel/git/clrkwllms/rt-tests.git/commit/?h=work&id=dd6ae1155dc7fbee79426ae5952d48b4151c1cd7 It is not in 0.84. Can you fix this in stable, please? armel seems not to be affected. Sebastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#571305: Swarm does not boot on .32 anymore.
* Martin Michlmayr | 2010-02-26 07:47:30 [-0500]: >* Sebastian Andrzej Siewior [2010-02-26 08:50]: >> > can you get Ralf or David Daney to submit it for inclusion into >> > the 2.6.32-stable series? >> It is allready there [0]. >> >> [0] >> http://git.kernel.org/?p=linux/kernel/git/ralf/linux.git;a=shortlog;h=refs/heads/linux-2.6.32-stable > >Ok, so this should be in the next stable update. Okay, so you were not talkin about Ralf's tree but about tree maintained by the stable-kernel team. Ups. I've sent it there now :) Sebastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#575158: dpkg: Add new 'e500' architecture to triplettable and ostable
* Moffett, Kyle D | 2010-03-25 17:49:33 [-0500]:
>We can just use --enable-e500-double when building (recent?) GCC.
Yep, looks good.
>Ok, so hopefully we can all agree on "e500v2"? That's the name I'm going to
>go ahead and use in my newest build-cycle.
Yep, I think so. However we will see what will slips into dpkg once it
is there.
>For reference, I've included a summary of the rationale behind the
>suggestion:
>
> * The only chipset families that support "SPE" instructions are:
>* PowerPC e200
>* PowerPC e500v1
>* PowerPC e500v2
>
> * The incompatibility between various SPE-capable CPUs mean that an arch
>spec of "spe" or "powerpcspe" is probably insufficiently descriptive.
Yes, "probably". Right now we don't see any.
> * The "e200" processor series is an automotive processor and has
>insufficient storage to run even something like Emdebian Crush, let alone to
>be able to build anything on its own. It should therefore be excluded from
>our discussion. This means we just care about e500v{1,2} cores.
Right. The spec says, that e200z4 and e200z6 are binary compatible with
e500. However, they also mention that double precision can only be
achieved in software. So this looks like double precision opcodes result
in an invalid opcode and we have to emulate them in kernel. This counts
as binary compatible I guess.
> * Freescale has indicated that they will not be building any more chipset
>families including the SPE instructions, so we don't have to worry about any
>newer chipset families.
>
> * We can't tell exactly how common or uncommon the e500v1 chipsets are
>because Freescale's chipset comparison tables all just say "e500" without
>referring to the version. As a result, we should probably be safe rather
>than sorry and refer to the version in the arch name (IE: e500v1/e500v2).
>
> * We should just call it just "e500v2":
>* Sufficiently descriptive of the hardware architecture
>* Shorter and easier to type in commands (of which there are a lot)
>* Similar situation to "lpia" (which is not called "i386lpia")
>
>The "easier-to-type" reason is especially applicable if we do a uclibc port,
>as the name "uclibc-linux-powerpce500" is much more of a pain to type out
>repeatedly than "uclibc-linux-e500".
>
>Is there anything I left out?
No, I think it is fine. You summarzied it well.
>The difference between a regular cross-compile and an icecc/distcc
>cross-buildd is that all the ./configure shell-script madness and some of
>the preprocessor crap is run *entirely* on the target system, then the
>preprocessed code is shipped across the network to a big beefy x86 box for
>building. The environment is indistinguishable from a native build. (except
>for the fact that things build a lot faster)
I know how it works. I used it myself thus the bug I pointed you to. I
used it only for the first iteration, second (and following) were native
only.
Compile a little program with -fstack-protector native and cross with
icecc. I saw different results with gcc 4.3 and I haven't checked later.
>So even a relatively wimpy 1GHz dual-core system can keep 8-16 cores worth
>of beefy x86 systems busy, especially if it's ugly template-heavy C++ code
>or something else very CPU intensive to compile. The downside is that the
>shell scripts, preprocessor, and linker all need to be run on the target
>board, but that's still way better than doing the whole build there.
Right. I'm okay using icecc/distcc on buildds if the target icecc
machine runs native architecture. I don't want to compile cross even
with icecc unless I have to.
Looking at the build time of xulrunner 1.9.0.14:
- s390: 30min
- i386: 33min
- kfreebsd i386 : 39mins
- powerpc: 1h
- alpha: 1:01
- ia64: 1:20
- me[0]: 1:29
- sparc: 1:35
- hppa: 2h
- mipsel: 3h
- mips: 3h
- armel: 14h
So I think it does not look too bad.
[0] I've built it complete, including all debs, ro clue how much extra
time it takes.
>Cheers,
>Kyle Moffett
Sebastian
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#497605: Getting Debian to release the PowerPC port
* Rog?rio Brito | 2008-09-17 02:08:27 [-0300]: >> git://www.jld.com/software/dtc.git >Thanks for the information. I put it there on that page. The git tree is still okay, however the Homepage button packages.qa.d.o points to 404 page. The currently valid link would be http://git.jdl.com/gitweb/?p=dtc.git;a=summary Sebastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#629636: linux-image-2.6.32-5-kirkwood: IPsec aes-sha1 with kirkwood/mv_cesa causes CPU to spin
* Alexander Clouter | 2011-06-08 09:54:58 [+]: >Whilst deploying IPsec (with strongswan-ike2) I ran into a complication[1] >that causes mv_cesa to spin the CPU when the system receives an IPsec ESP >packet; it seems to be able to send traffic (before the CPU spin) as a >ICMP Echo request (a la pin) out from the system out is okay, until the >ICMP Reply comes back. The packet never 'arrives' as far as userspace is >concerned and the only way to stop the CPU spinning is a reboot. I've been working on that and forgot about it in the meantime. The problem is that incremental sha1 checksum are wrong i.e. the previous state is ignored by the hardware. Kernel's auto-test droppped an error message which disappeared in later a kernel so I assumed that it was fixed. This was not case but "oldconfig" disabled the algorithm test. Sebastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#641005: openoffice-common: unopkg failed during upgrade [ERROR: com.sun.star.registry.SimpleRegistry.open...]
Package: libreoffice-common
Version: 1:3.4.3-1
Severity: important
My dist-upgrade of my amd64 sid system ended early with:
|Processing triggers for libreoffice-common ...
|
|ERROR:
com.sun.star.registry.SimpleRegistry.open(file:///usr/lib/libreoffice/basis3.4/program/services.rdb):
underlying Registry::open/create() = 3
|Exception details:
|(com.sun.star.registry.InvalidRegistryException) { { Message =
"com.sun.star.registry.SimpleRegistry.open(file:///usr/lib/libreoffice/basis3.4/program/services.rdb):
underlying Registry::open/create() = 3", Context =
(com.sun.star.uno.XInterface) @85cc20 (ImplementationName =
"com.sun.star.comp.stoc.SimpleRegistry") } }
|
|unopkg failed.
|dpkg: error processing libreoffice-common (--unpack):
| subprocess installed post-installation script returned error exit status 1
|configured to not write apport reports
| Errors were encountered while processing:
| libreoffice-common
|E: Sub-process /usr/bin/dpkg returned an error code (1)
The old/new version was according to dpkg.log:
| upgrade libreoffice-common 1:3.3.4-2 1:3.4.3-1
After
apt-get -f install ; apt-get purge libreoffice-common && apt-get install
libreoffice
things got back to normal so it can be closed in case it is assumend to be a
local problem.
Sebastian
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#641005: openoffice-common: unopkg failed during upgrade [ERROR: com.sun.star.registry.SimpleRegistry.open...]
On Fri, Sep 09, 2011 at 01:38:50PM +0200, Rene Engelhard wrote: > Was the file there when this was tried? Should be, but? Do you have I can only tell from the content of an older .deb file. > th eupgrade order logged somewhere? I don't have the output from the console anymore but would dpkg.log output help? > Regards, > > Rene Sebastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#590526: iptraf: IPTraf doesn't show ethernet card
* Thus spake Frederic Peters (fpet...@debian.org): > Sebastian Andrzej Siewior wrote: > > > * Thus spake Frederic Peters (fpet...@debian.org): > > > > Frederic, any chance to see an updated iptraf package in Debian? > > > > > > Development is now happening in "iptraf-ng"[1], but they renamed > > > binaries after they released 1.0.2 months ago and didn't make a new > > > release yet; as it will affect packaging (conflicts, replaces...) > > > progress have been stalled since February... > > > > So Frederic, what do you thing should be done? Fixing this bug and making > > the > > tool usefull is probably not bad. > > Anyway, switching to iptraf-ng doesn't sound that bad as they have _this_ > > bug > > fixed. I'm running the -ng package atm and can't complain. > > Do want some help with packaging of the -ng package or NMU for this bug? > > As noted the currently blocking issue is the lack of a release; you > could go and ask Nikola Pajkovsky about his > plans. There was a release of iptraf-ng v1.0.2 [0]. The diff between .2 and .3 is just the removal of some documentation. The .2 release has this bug fixed. > Alternatively iptraf-ng could be ignored (no changes since February) > and the relevant patches incorporated in the iptraf package. What do > you thinkg about this? I just pulled everything into git [1] to have a look on it. The diff of iptraf v3.0.0 vs v3.0.1 are just some header changes. This release is not even announced on the homepage [2]. Their mailing list isn't very active either. iptraf-ng continued after v3.0.0. Nikola collected various patches from other distros and applied them. He announced it the mailing list with no reaction. Based on that, I would switch over to iptraf-ng because the original upstream looks dead and the fork fixed atleast one bug which is bothering people. Additionaly it provides support for IPv6 which would close #44113. Maybe there are other bugs which could be closed :) Cherry-picking the individual patches ontop of iptraf does not make much sense in my opinion. [0] https://fedorahosted.org/releases/i/p/iptraf-ng/iptraf-ng-1.0.2.tar.gz [1] git://git.breakpoint.cc/bigeasy/iptraf.git [2] http://iptraf.seul.org/ > Fred Sebastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#629636: linux-image-2.6.32-5-kirkwood: IPsec aes-sha1 with kirkwood/mv_cesa causes CPU to spin
* Thus spake Alexander Clouter (a...@digriz.org.uk): > I have just been tasked with putting together an active-active IPsec VPN > concentrator (with a need to use AES-SHA1 it seems) and I was hoping to > use the OpenRD's (and mv_cesa). Have you got a patch I can test that > fixes things for SHA1? The patch below should work around the problem by not using it. You could try the kernel from backports. If I remember correctly than it seems that the later kernel passes one big chunk instead of three requests (init, update, fin). If that works out for then the only problem are fragmanted packets. diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c index 3cf303e..f556a71 100644 --- a/drivers/crypto/mv_cesa.c +++ b/drivers/crypto/mv_cesa.c @@ -1062,7 +1062,7 @@ static int mv_probe(struct platform_device *pdev) "Could not register aes-cbc driver\n"); goto err_unreg_ecb; } - +#if 0 ret = crypto_register_ahash(&mv_sha1_alg); if (ret == 0) cpg->has_sha1 = 1; @@ -1076,7 +1076,7 @@ static int mv_probe(struct platform_device *pdev) printk(KERN_WARNING MV_CESA "Could not register hmac-sha1 driver\n"); } - +#endif return 0; err_unreg_ecb: crypto_unregister_alg(&mv_aes_alg_ecb); > Cheers Sebastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#637175: irssi: negative files sizes in perl scripts
Package: irssi
Version: 0.8.15-2
Severity: normal
Tags: patch
The Perl interface gets negative file size injected which leads to funny
behavior if the script relies on positve and advancing numbers.
The patch attached fixes the issue.
Sebastian
>From b01f3d0ffbfc211883349b19f52267f0d85d6423 Mon Sep 17 00:00:00 2001
From: Sebastian Andrzej Siewior
Date: Sun, 7 Aug 2011 19:42:18 +0200
Subject: [PATCH] perl: use newSVpv for dcc's file size fields
Using newSViv() makes numbers >2GiB negative because it translate the number
into an signed integer. This patch use a tiny trick by converting the number
into a string. Once perl starts using this numbers for computation in
translates them into a 32bit (unsigned) integer or a 64bit one. Been testing
with a 5GiB file and it seems to do the job.
This changes the transfd (transfer bytes), size (total file size) and skipped
(skipped bytes uppon transfer) members.
Signed-off-by: Sebastian Andrzej Siewior
---
src/common.h|3 +++
src/perl/irc/Irc.xs | 13 ++---
2 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/src/common.h b/src/common.h
index bb24696..7cb84b7 100644
--- a/src/common.h
+++ b/src/common.h
@@ -58,10 +58,13 @@
#if defined (UOFF_T_INT)
typedef unsigned int uoff_t;
+#define uoff_t_printf "%u"
#elif defined (UOFF_T_LONG)
typedef unsigned long uoff_t;
+#define uoff_t_printf "%lu"
#elif defined (UOFF_T_LONG_LONG)
typedef unsigned long long uoff_t;
+#define uoff_t_printf "%llu"
#else
# error uoff_t size not set
#endif
diff --git a/src/perl/irc/Irc.xs b/src/perl/irc/Irc.xs
index 251efb8..5b0da51 100644
--- a/src/perl/irc/Irc.xs
+++ b/src/perl/irc/Irc.xs
@@ -36,6 +36,8 @@ static void perl_ban_fill_hash(HV *hv, BAN_REC *ban)
static void perl_dcc_fill_hash(HV *hv, DCC_REC *dcc)
{
+ char fsize[22];
+
hv_store(hv, "type", 4, new_pv(dcc_type2str(dcc->type)), 0);
hv_store(hv, "orig_type", 9, new_pv(dcc_type2str(dcc->orig_type)), 0);
hv_store(hv, "created", 7, newSViv(dcc->created), 0);
@@ -53,7 +55,8 @@ static void perl_dcc_fill_hash(HV *hv, DCC_REC *dcc)
hv_store(hv, "port", 4, newSViv(dcc->port), 0);
hv_store(hv, "starttime", 9, newSViv(dcc->starttime), 0);
- hv_store(hv, "transfd", 7, newSViv(dcc->transfd), 0);
+ snprintf(fsize, sizeof(fsize), uoff_t_printf, dcc->transfd);
+ hv_store(hv, "transfd", 7, newSVpv(fsize, 0), 0);
}
static void perl_dcc_chat_fill_hash(HV *hv, CHAT_DCC_REC *dcc)
@@ -67,10 +70,14 @@ static void perl_dcc_chat_fill_hash(HV *hv, CHAT_DCC_REC *dcc)
static void perl_dcc_file_fill_hash(HV *hv, FILE_DCC_REC *dcc)
{
+ char fsize[22];
+
perl_dcc_fill_hash(hv, (DCC_REC *) dcc);
- hv_store(hv, "size", 4, newSViv(dcc->size), 0);
- hv_store(hv, "skipped", 7, newSViv(dcc->skipped), 0);
+ snprintf(fsize, sizeof(fsize), uoff_t_printf, dcc->size);
+ hv_store(hv, "size", 4, newSVpv(fsize, 0), 0);
+ snprintf(fsize, sizeof(fsize), uoff_t_printf, dcc->skipped);
+ hv_store(hv, "skipped", 7, newSVpv(fsize, 0), 0);
}
static void perl_dcc_get_fill_hash(HV *hv, GET_DCC_REC *dcc)
--
1.7.5.4
Bug#621778: stimfit: FTBFS on powerpc: Both BIG_ENDIAN and LITTLE_ENDIAN defined
Version: 0.10.18-1 thanks. On Tue, Sep 13, 2011 at 01:26:18PM +0100, Christoph Schmidt-Hieber wrote: > https://launchpad.net/ubuntu/+source/stimfit/0.10.18-1/+build/2781444 > > Can we consider this bug as fixed? Yes, because it built on debian buildd [0]. Please use this as reference :) >If so, how do I mark it? See [1]. I think Yaroslav forgot to add ':' and this is why it is still open. Lets see what happens now. > Apologies for not closing it in the changelog. :) [0] https://buildd.debian.org/status/fetch.php?pkg=stimfit&arch=powerpc&ver=0.10.18-1&stamp=1315711621 [1] http://www.debian.org/Bugs/Developer#closing > Christoph Sebastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#712078: btrfs-progs: fsck.btrfs -a is not working
Package: btrfs-tools Version: 0.19+20130315-2 Severity: important Just upgraded from stable to sid on a machine where rootfs is on a btrfs partition. The machine does hangs during boot because fsck failed. The call chain is: | init boot | \_ /bin/sh /etc/init.d/rc S | \_ startpar -p 4 -t 20 -T 3 -M boot -P N -R S | \_ /bin/sh /etc/init.d/checkroot.sh start | \_ logsave -s /var/log/fsck/checkroot fsck -C -a -t btrfs /run /rootdev | \_ fsck -C -a -t btrfs /run/rootdev | \_ /bin/sh /sbin/fsck.btrfs -a /run/rootdev | with |lrwxrwxrwx 1 root root 7 May 20 11:23 /sbin/fsck.btrfs -> btrfsck and the output is | $ /sbin/fsck.btrfs -a /run/rootdev | Unknown option: -a | usage: btrfs [--help] [--version] [...] [] | $ echo $? | 129 -a and -y should be probably mapped to --repair by fsck for btrfs or implemented by btrfs-tools. Any idea what is the better way? Sebastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#721066: nmu: libuuid-perl_0.02-5
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Please binnum libuuid-perl in unstable as it currently depends on perlapi-5.14.2 but we have perlapi-5.18.1 provided by perl-base 5.18.1-2. In my recent dist-upgraded I ended up without a kernel and a few other packages… After a manual rebuild of libuuid-perl I was able to install the kernel back, will look after the others… Sebastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#721069: nmu: libtext-iconv-perl_1.7-5
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Please nmu libtext-iconv-per in unstable as it currently depends on perlapi-5.12.2 but we have perlapi-5.18.1 provided by perl-base 5.18.1-2. In my recent dist-upgraded I lost dictionaries-common and a few depending on it. After a manual rebuild of libtext-iconv-perl I was able to install them back. Sebastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#721066: nmu: libuuid-perl_0.02-5
On Tue, Aug 27, 2013 at 08:05:53PM +0200, gregor herrmann wrote: > Hi Sebastian, Hi Gregor, > thanks for your bug reports. > > You are right that libuuid-perl and libtext-iconv-per need binNMUs; > just like 525 other packages, as mentioned on > http://release.debian.org/transitions/html/perl5.18.html . Okay. > The release team is well aware of the ongoing perl 5.18 transition: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712615 > And filing bugs for each single package doesn't help them :) I realized this too late. > (BTW: Running unstable and blindly updating without checking which > packages are removed is not the best strategy in the long run …) Yes. It removed just a few packages and I noticed this a little too late. > Cheers, > gregor Sebastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#719069: git: "fatal: protocol error: bad line length character: Remo"
Package: git Version: 1:1.7.2.5-3 Severity: important Tags: patch Control: fixed -1 1:1.8.1~rc0-1 The following has been observed: | $ git push ko | ko: Counting objects: 332, done. | Delta compression using up to 4 threads. | Compressing objects: 100% (110/110), done. | Writing objects: 100% (130/130), 32.27 KiB, done. | Total 130 (delta 106), reused 21 (delta 20) | Auto packing the repository for optimum performance. | fatal: protocol error: bad line length character: Remo | error: error in sideband demultiplexer | To ra.kernel.org:/pub/scm/git/git.git at http://www.mail-archive.com/git@vger.kernel.org/msg05623.html and decoded and patched at http://www.mail-archive.com/git@vger.kernel.org/msg05723.html as commit 90b29cb7a in the git repository. This patch is part of v1.7.12.1. This version never made it into Debian but the follow-up version (1:1.8.4~rc1-1) did so the current version which sits in sid is fixed. Both oldstable and stable are still effected which results in user emails now and then. Could this be please fixed atleast in stable for the next point release? Sebastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#719069: git: "fatal: protocol error: bad line length character: Remo"
On Thu, Aug 08, 2013 at 09:53:35AM -0700, Jonathan Nieder wrote: > Yes, this is worth fixing in stable. Thanks for a clear report. Thanks. It seems 7.2 will be released on 12.Oct. Do you think you get this in p-u? Is there anything I can help you with? > Regards, > Jonathan Sebastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#590526: iptraf: IPTraf doesn't show ethernet card
* Thus spake Frederic Peters (fpet...@debian.org): > > Frederic, any chance to see an updated iptraf package in Debian? > > Development is now happening in "iptraf-ng"[1], but they renamed > binaries after they released 1.0.2 months ago and didn't make a new > release yet; as it will affect packaging (conflicts, replaces...) > progress have been stalled since February... So Frederic, what do you thing should be done? Fixing this bug and making the tool usefull is probably not bad. Anyway, switching to iptraf-ng doesn't sound that bad as they have _this_ bug fixed. I'm running the -ng package atm and can't complain. Do want some help with packaging of the -ng package or NMU for this bug? > Frederic Sebastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#711363: rt-tests: hackbench does not work in stable on armhf
On Thu, Jun 06, 2013 at 09:49:21PM +0100, Adam D. Barratt wrote: > fwiw, as unstable also has 0.83, it would need to be fixed there first. Yes. I tried to point out that upstream did not release a version including this fix yet. Now we have unstable fixed. Could the maintainer be please so kind to prepare a version for proposed-updates? > Regards, > > Adam Sebastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#651290: Please ship gcc 4.6 man pages.
Package: gcc-doc-defaults Version: 5:3 Severity: wishlist gcc-4.6 ist in testing and I can only find gcc-4.4-doc-non-dfsg in the archive. Mind packaging 4.6' man pages? Need a hand with this? Sebastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#651291: gcc-snapshot contains evil gfdl licensed man pages
Package: gcc-snapshot Version: 20111203-1 Severity could be serious but this package won't be shipped so The man pages are under the gfdl according to tail of /usr/lib/gcc-snapshot/share/man/man1/gcc.1 and this is not compatible with the main archive. Doko, please don't get me wrong. I've been looking for a recent gcc man page and this is the only place I could find. I wouldn't mind if it stays :) Sebastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#502963: exim4-daemon-light: Error sending mail with Apple's Mail.app to exim4 over TLS with authentication.
On Tue, Oct 21, 2008 at 06:43:26PM +0100, WS wrote: > > Still does not work. However, the error has changed: > > 2008-10-21 18:38:00 no IP address found for host laptop (during SMTP > connection from [192.168.1.41]) > 2008-10-21 18:38:07 TLS error on connection from ([192.168.1.41]) > [192.168.1.41] (gnutls_handshake): A TLS packet with unexpected length was > received. I had this error message only because my authentification setup was wrong. Instead of a proper error message with a hint, iMail tried a few things and broke up. The TLS connection was just left as it and later closed. > WS Sebastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#659251: openssl: enc: Bad compression ration with -z (zlib compression)
tags 659251 + patch
thanks
* Roland Stigge | 2012-02-09 15:52:21 [+0100]:
>$ openssl enc -bf -in /usr/share/common-licenses/GPL-3 -out GPL-3.enc
>enter bf-cbc encryption password:
>Verifying - enter bf-cbc encryption password:
>$ openssl enc -bf -in /usr/share/common-licenses/GPL-3 -out GPL-3.enc-z -z
>enter bf-cbc encryption password:
>Verifying - enter bf-cbc encryption password:
>$ gzip -c /usr/share/common-licenses/GPL-3 > GPL-3.gz
>$ ls -l GPL-3* /usr/share/common-licenses/GPL-3
>-rw-r--r-- 1 rst rst 35168 Feb 9 15:39 GPL-3.enc
>-rw-r--r-- 1 rst rst 35189 Feb 9 15:39 GPL-3.enc-z
>-rw-r--r-- 1 rst rst 12143 Feb 9 15:40 GPL-3.gz
>-rw-r--r-- 1 root root 35147 Jul 2 2007 /usr/share/common-licenses/GPL-3
>$
The problem is that openssl tries to compress encrypted content which
seems not to work. The patch attached changes the order to first
compress and then encrypt.
Sebastian
From: Sebastian Andrzej Siewior
Subject: [PATCH] enc: compress before compress/base64 is applied
The command
|openssl enc -pass pass:pass -iv 0 -K 0 -S 0 -aes-256-cbc -base64 < file > file.enc.b64
first performs the encryption followed by base64 encoding. That means the output
is base64 encoded as requests.
The command
|openssl enc -pass pass:pass -iv 0 -K 0 -S 0 -aes-256-cbc -z < file > file.enc.z
first performs the encryption followed by compression. That means the encrypted
data is compressed which should not give any improvement because a good
encryption algorithm should not produce anything that can be compressed.
The command
| openssl enc -pass pass:pass -iv 0 -K 0 -S 0 -aes-256-cbc -z -base64 < file > file.enc.z.base64
first performs the encryption, followed by base64 encoding followed by
compression. The output is no longer base64 encoded as requests but compressed
by zlib.
This patch changes the order of the individual steps to
- compress the input
- encrypt the content
- encode is as base64
the -d step is in reverse order.
That means the last command will produce a base64 encoded file which was
compressed before encrypted.
The *now* created files are no longer compatible with the files created with
an earlier version of openssl if the -z option was involved.
To get the "old" content with new binary the following step is required:
| openssl enc -d -z < file.old | \
| openssl enc -d -aes-256-cbc > file
where the first step simply decompresses the content and the second performs the
decryption.
Signed-off-by: Sebastian Andrzej Siewior
---
apps/enc.c | 32 +---
1 file changed, 17 insertions(+), 15 deletions(-)
diff --git a/apps/enc.c b/apps/enc.c
index 719acc3..a6fd07e 100644
--- a/apps/enc.c
+++ b/apps/enc.c
@@ -475,19 +475,6 @@ bad:
rbio=in;
wbio=out;
-#ifdef ZLIB
-
- if (do_zlib)
- {
- if ((bzl=BIO_new(BIO_f_zlib())) == NULL)
- goto end;
- if (enc)
- wbio=BIO_push(bzl,wbio);
- else
- rbio=BIO_push(bzl,rbio);
- }
-#endif
-
if (base64)
{
if ((b64=BIO_new(BIO_f_base64())) == NULL)
@@ -653,9 +640,24 @@ bad:
}
}
- /* Only encrypt/decrypt as we write the file */
if (benc != NULL)
- wbio=BIO_push(benc,wbio);
+ {
+ if (!enc)
+ rbio=BIO_push(benc,rbio);
+ else
+ wbio=BIO_push(benc,wbio);
+ }
+#ifdef ZLIB
+ if (do_zlib)
+ {
+ if ((bzl=BIO_new(BIO_f_zlib())) == NULL)
+ goto end;
+ if (enc)
+ wbio=BIO_push(bzl,wbio);
+ else
+ rbio=BIO_push(bzl,rbio);
+ }
+#endif
for (;;)
{
--
1.7.9.5
Bug#628847: mumble locks up on startup
On Tue, Apr 03, 2012 at 01:49:44PM +0200, Patrick Matth?i wrote: > Could you retest your issue please with 1.2.3-309-g7176ff4-1 ? I just installed 1.2.3-313-ge5c4657-1 and have the same problem. It went away after I executed chown myuid:mygid /dev/input/event* after that I got the gtk window & wizard. They were owned by root:root and perms were 600. Not sure if this is my local problem not... Sebastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#628847: mumble locks up on startup
On Sat, May 05, 2012 at 11:17:50PM +0200, Tobias Diedrich wrote: > 1.2.3-313-ge5c4657-1 seems to work fine for me now (despite > /dev/input/event* being root-owned). > OTOH I've recently installed pulseaudio (which also pulls in > policykit), maybe that makes a difference here. Yes, I see the same here. I installed pulseaudio and changed event* to be owned by root only and it still works. So it looks like pulseaudio is required or access to event* devices. An error message here would be nice. What do you suggest as the final fix? A dep on pulseaudio? Sebastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#593340: linux-2.6: please add new Debian arch: powerpcspe
* Ben Hutchings | 2012-06-02 18:55:17 [+0100]: >Sorry we haven't done anything about this. No worries :) >Are you still working on powerpcspe? Can you provide a patch suitable No, I dropped the ball. >for the current version in sid or experimental? I haven't seen much progress here from Kyle or his team at Boeing. I guess they don't care anymore. That said, I'm perfectly fine if you close the bug as-it if you don't see any patches here within next one or two weeks. >Ben. Sebastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#843064: [Pkg-openssl-devel] Bug#843064: Bug#843064: openssl: incompatibility for enc command between openssl 1.1.0b-2 and previous 1.0.x versions
On 2016-11-03 22:15:50 [+0100], Marek Lukaszuk wrote: > Thanks, it works, I feel like an idiot for not finding this. it wasn't documented. how should you find it? I just figured it out myself. > > Let me see what upstream says… > > It is a bit of a surprise, normally I would argue for a bit more clear error > message but in this case I'm not sure if that would be ok. I will try to add something to the error message (more than just "decompression failed") and maybe something to the news file. Will check with Kurt. The c release is around the corner… > Marek Sebastian
Bug#843532: dnssec-trigger: broken by OpenSSL 1.1.0
control: tags -1 patch
On 2016-11-07 08:39:17 [-0500], Zack Weinberg wrote:
> Nov 07 08:34:17 moxana dnssec-triggerd[20281]: Nov 07 08:34:17
> dnssec-triggerd[20281] error: could not set SSL_OP_NO_SSLv2 crypto
> error:
could someone please check if the patch attached works? I am confident
but don't time todo it myself just now.
Sebastian
>From 05cd529e19d317b8bcc69f7d883873a27195b904 Mon Sep 17 00:00:00 2001
From: Sebastian Andrzej Siewior
Date: Mon, 7 Nov 2016 20:59:11 +
Subject: [PATCH] dnssec-trigger: openssl 1.1.0 fixup
- SSL_OP_NO_SSLv2 / SSLv2 has been removed from openssl 1.1.0 and as
such it can't be tested (the way it is) if disabling it worked.
- SSL_CTX_load_verify_locations() return 1 un success and 0 on failure.
The check for the result code is bogus and has nothing to do with the
switch to openssl 1.1.0 itself
- ERR_remove_state() and friends are NOPs in current openssl 1.1.0 due
the threading model. This operations are nops therefore and do nothing
and can be removed in a later version.
Signed-off-by: Sebastian Andrzej Siewior
---
riggerd/cfg.c | 2 ++
riggerd/net_help.c | 4 +++-
riggerd/riggerd.c | 2 ++
riggerd/svr.c | 2 ++
4 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/riggerd/cfg.c b/riggerd/cfg.c
index 03f4f73..08b2028 100644
--- a/riggerd/cfg.c
+++ b/riggerd/cfg.c
@@ -540,9 +540,11 @@ cfg_setup_ctx_client(struct cfg* cfg, char* err, size_t errlen)
if(!ctx)
return ctx_err_ret(ctx, err, errlen,
"could not allocate SSL_CTX pointer");
+#if OPENSSL_VERSION_NUMBER < 0x1010
if(!(SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv2) & SSL_OP_NO_SSLv2))
return ctx_err_ret(ctx, err, errlen,
"could not set SSL_OP_NO_SSLv2");
+#endif
if(!SSL_CTX_use_certificate_file(ctx,c_cert,SSL_FILETYPE_PEM) ||
!SSL_CTX_use_PrivateKey_file(ctx,c_key,SSL_FILETYPE_PEM)
|| !SSL_CTX_check_private_key(ctx))
diff --git a/riggerd/net_help.c b/riggerd/net_help.c
index 21e79e7..b17486c 100644
--- a/riggerd/net_help.c
+++ b/riggerd/net_help.c
@@ -447,11 +447,13 @@ void* listen_sslctx_create(char* key, char* pem, char* verifypem)
return NULL;
}
/* no SSLv2 because has defects */
+#if OPENSSL_VERSION_NUMBER < 0x1010
if(!(SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv2) & SSL_OP_NO_SSLv2)){
log_crypto_err("could not set SSL_OP_NO_SSLv2");
SSL_CTX_free(ctx);
return NULL;
}
+#endif
if(!SSL_CTX_use_certificate_file(ctx, pem, SSL_FILETYPE_PEM)) {
log_err("error for cert file: %s", pem);
log_crypto_err("error in SSL_CTX use_certificate_file");
@@ -517,7 +519,7 @@ void* connect_sslctx_create(char* key, char* pem, char* verifypem)
}
}
if(verifypem && verifypem[0]) {
- if(!SSL_CTX_load_verify_locations(ctx, verifypem, NULL) != 1) {
+ if(SSL_CTX_load_verify_locations(ctx, verifypem, NULL) != 1) {
log_crypto_err("error in SSL_CTX verify");
SSL_CTX_free(ctx);
return NULL;
diff --git a/riggerd/riggerd.c b/riggerd/riggerd.c
index 9cb6023..2490a72 100644
--- a/riggerd/riggerd.c
+++ b/riggerd/riggerd.c
@@ -393,10 +393,12 @@ int main(int argc, char *argv[])
#ifdef HAVE_OPENSSL_CONF_H
CONF_modules_free();
#endif
+#if OPENSSL_VERSION_NUMBER < 0x1010
CRYPTO_cleanup_all_ex_data();
ERR_remove_state(0);
ERR_free_strings();
RAND_cleanup();
+#endif
#ifdef USE_WINSOCK
if(WSACleanup() != 0) {
diff --git a/riggerd/svr.c b/riggerd/svr.c
index 0b46b1d..5f232f4 100644
--- a/riggerd/svr.c
+++ b/riggerd/svr.c
@@ -162,10 +162,12 @@ static int setup_ssl_ctx(struct svr* s)
return 0;
}
/* no SSLv2 because has defects */
+#if OPENSSL_VERSION_NUMBER < 0x1010
if(!(SSL_CTX_set_options(s->ctx, SSL_OP_NO_SSLv2) & SSL_OP_NO_SSLv2)){
log_crypto_err("could not set SSL_OP_NO_SSLv2");
return 0;
}
+#endif
s_cert = s->cfg->server_cert_file;
s_key = s->cfg->server_key_file;
verbose(VERB_ALGO, "setup SSL certificates");
--
2.10.2
Bug#828556: sslscan: FTBFS with openssl 1.1.0
On 2016-11-10 12:10:04 [+0200], Adrian Bunk wrote: > On Thu, Sep 01, 2016 at 09:55:46PM +0200, Sebastian Andrzej Siewior wrote: > > control: forwarded -1 https://github.com/rbsec/sslscan/issues/108 > > Sebastian, Marvin, what is the status regarding getting this patch that > was applied upstream included in Debian? Adrian: which patch? Marvin: unless Adrian pulls out a patch I suggest you prepare a package to build against libssl1.0-dev. I have currently no better suggestion. I can sponsor the upload if you want me to. > Thanks > Adrian Sebastian
Bug#843532: [Pkg-dns-devel] Bug#843532: dnssec-trigger: broken by OpenSSL 1.1.0
On 2016-11-10 12:10:41 [+0100], Ondřej Surý wrote: > Sebastian, Hi Ondřej, > thanks for the patch. The 0.13~svn685-7 version in unstable includes > your patch, > and I would really appreciate if someone could test whether > dnssec-trigger now > works. I managed to get around to test it. So the initial error is gone - the daemon can be started. Are going the forward the two patches upstream or should I do it? > Ondrej Sebastian
Bug#843603: [Pkg-openssl-devel] Bug#843603: Bug#843603: openssl fails on sid version to handshake with tls_1.2 to postfix echos ssl_errors
On 2016-11-11 19:21:26 [+0100], sternasky wrote: > Hello, Hi, > after some analysis i found infos about php security changes after > 5.6,7.0.12.2 > > Self Signed Certs like > > SSLCertificateFile/etc/ssl/certs/ssl-cert-snakeoil.pem > SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key > > which are set to CN localhost are blocked by postfix from PHP Mailers > like Roundcube.. Errors often are seen: > > .. ssl cert not accepted or SSLv3 Error.. They might be blocked because PHP can't verify the cert chain. SSLv3 is disabled in stable+ so this won't work. So far it does not look like a openssl bug. For localhost connections you could skip the SSL link. > Thanks.. > www.linuxonlinehelp.de Sebastian
Bug#843960: [Pkg-openssl-devel] Bug#843960: Bug#843960: /test/recipes/90-test_srp.t: Keys mismatch during build tests
On 2016-11-12 17:22:42 [+0100], Kurt Roeckx wrote: > On Fri, Nov 11, 2016 at 09:21:41AM +0100, jean-christophe manciot wrote: > > Package: openssl > > Version: 1.1.0c-1 > > > skipped: Test only supported in a shared build > > ../test/recipes/90-test_srp.t .. > > This test did not fail as far as I can see. Why did it say "Keys mismatch" then? I don#t see this in a normal built. > Kurt Sebastian
Bug#843960: [Pkg-openssl-devel] Bug#843960: Bug#843960: /test/recipes/90-test_srp.t: Keys mismatch during build tests
On 2016-11-12 21:21:23 [+0100], Kurt Roeckx wrote: > On Sat, Nov 12, 2016 at 08:51:09PM +0100, Sebastian Andrzej Siewior wrote: > > Why did it say "Keys mismatch" then? I don#t see this in a normal built. > > I see it in all the logs? But it seems to be at a slighty different line. Yes, you are right. Maybe we shouldn't run the testsuite in parallel. Also the fact the published only a snipped of testsuite output is something that let me jump in conclusions :/ > > Kurt Sebastian
Bug#843960: [Pkg-openssl-devel] Bug#843960: Bug#843960: /test/recipes/90-test_srp.t: Keys mismatch during build tests
On 2016-11-12 21:57:29 [+0100], Kurt Roeckx wrote: > > Yes, you are right. Maybe we shouldn't run the testsuite in parallel. > The test suite should not be running parallel? As far as I know > that's not supported, and we're not doing it. I think so. Looking at logs of armel, amd64, arm64 the "keys missmatch" line is the same spot. It is probably something else that led to this… > Kurt Sebastian
Bug#844254: libesmtp: FTBFS with openssl 1.1.0
Source: libesmtp Version: 1.0.6-4 Severity: serious Control: block 827061 by -1 OpenSSL 1.1.0 has been released. During a rebuild of all packages using OpenSSL this package succeeded to build but it should have failed. That is why this bug is coming so late. The build simply deactivated TLS supported, continued and then succeeded. A log of that build can be found at: https://breakpoint.cc/openssl-1.1-rebuild-2016-08-26/failed/libesmtp_1.0.6-4_amd64-2016-08-26T19%3A06%3A11Z On https://wiki.openssl.org/index.php/1.1_API_Changes you can see various of the reasons why it might fail. There are also updated man pages at https://www.openssl.org/docs/manmaster/ that should contain useful information. If you have problems making things work, feel free to contact us. Sebastian
Bug#843988: stunnel4 segfaults (client mode)
On 2016-11-11 16:05:05 [+0100], gregor herrmann wrote:
> As soon as fetchnews connects, stunnel4 segfaults.
I tried your config against a http server and mail server with no luck.
> The messages in the syslog:
> Nov 11 15:53:55 jadzia stunnel: LOG2[2]: Double free attempt:
> ptr=0x7f6340010430 alloc=crypto/asn1/asn1_lib.c:277 free#1=str.c:200
> free#2=crypto/asn1/asn1_lib.c:323
…
> Nov 11 15:53:55 jadzia stunnel: LOG2[3]: Double free attempt:
> ptr=0x7f633800ff60 alloc=`..8c.:277 free#1=:200
> free#2=crypto/asn1/asn1_lib.c:323
> Nov 11 15:53:55 jadzia stunnel: INTERNAL ERROR: Bad magic at
> crypto/asn1/asn1_lib.c, line 323
based on this it seems that stunnel itself tries to free memory
allocated by openssl which it should not do. And this goes on until it
finds that is not a chunk but something completely different and then
goes boom.
Can you try the patch attached on stunnel, recompile it and check if it
still goes boom?
> Cheers,
> gregor
Sebastian
diff --git a/src/tls.c b/src/tls.c
index 3964f9ce6f2d..8b2b18938d74 100644
--- a/src/tls.c
+++ b/src/tls.c
@@ -100,6 +100,7 @@ void tls_cleanup() {
tls_data=tls_get();
if(!tls_data)
return;
+OPENSSL_thread_stop();
str_cleanup(tls_data);
str_free(tls_data->id); /* detached allocation */
tls_set(NULL);
Bug#843988: stunnel4 segfaults (client mode)
On 2016-11-14 00:17:31 [+0100], gregor herrmann wrote:
> Thanks, but nope, still the same:
What about this one?
Sebastian
>From b436cd6527a2a32bd94b67ff10363e45a2f52430 Mon Sep 17 00:00:00 2001
From: Sebastian Andrzej Siewior
Date: Mon, 14 Nov 2016 21:03:24 +
Subject: [PATCH] take #2
---
src/client.c | 22 +-
src/tls.c| 1 +
2 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/src/client.c b/src/client.c
index e2648d26eda3..581ca43a3372 100644
--- a/src/client.c
+++ b/src/client.c
@@ -131,11 +131,31 @@ void client_main(CLI *c) {
c->fds=NULL;
str_stats(); /* client thread allocation tracking */
/* c allocation is detached, so it is safe to call str_stats() */
-if(service_options.next) /* no tls_cleanup() in inetd mode */
+if(service_options.next) { /* no tls_cleanup() in inetd mode */
+ SSL_SESSION *old_session;
+
+ CRYPTO_THREAD_write_lock(stunnel_locks[LOCK_SESSION]);
+ old_session = c->opt->session;
+ c->opt->session = NULL;
+ CRYPTO_THREAD_write_unlock(stunnel_locks[LOCK_SESSION]);
+ if (old_session)
+ SSL_SESSION_free(old_session); /* release the old one */
+
tls_cleanup();
+ }
}
} else
client_run(c);
+{
+ SSL_SESSION *old_session;
+
+ CRYPTO_THREAD_write_lock(stunnel_locks[LOCK_SESSION]);
+ old_session = c->opt->session;
+ c->opt->session = NULL;
+ CRYPTO_THREAD_write_unlock(stunnel_locks[LOCK_SESSION]);
+ if (old_session)
+ SSL_SESSION_free(old_session); /* release the old one */
+}
str_free(c);
}
diff --git a/src/tls.c b/src/tls.c
index 3964f9ce6f2d..8b2b18938d74 100644
--- a/src/tls.c
+++ b/src/tls.c
@@ -100,6 +100,7 @@ void tls_cleanup() {
tls_data=tls_get();
if(!tls_data)
return;
+OPENSSL_thread_stop();
str_cleanup(tls_data);
str_free(tls_data->id); /* detached allocation */
tls_set(NULL);
--
2.10.2
Bug#843988: stunnel4 segfaults (client mode)
On 2016-11-14 22:43:16 [+0100], gregor herrmann wrote: > Control: tag -1 + patch > > On Mon, 14 Nov 2016 22:07:12 +0100, Sebastian Andrzej Siewior wrote: > > > On 2016-11-14 00:17:31 [+0100], gregor herrmann wrote: > > > Thanks, but nope, still the same: > > What about this one? > > Yay, this looks good! > > Built, installed, started, and it's still running after several > fetchnews runs. Thanks! Thank you for the confirmation. And now please explain why it works with openssl 1.0.2. It should have exploded the same way… > Cheers, > gregor > Sebastian
Bug#827061: Processed (with 1 error): block 827061 with 828253 828367 828586 828309 828307 828513 812166 828412 828298 828277
On 2016-11-15 12:39:25 [+0100], Apollon Oikonomopoulos wrote: > Hi Ian, Hi, > On 11:16 Tue 15 Nov , Ian Jackson wrote: > > 812166 is nothing to do with openssl AFAICT. > > I don't think Xen is involved with the openssl transition. > > > > Did you get the wrong bug ? > > I'm terribly sorry for this mess. I re-added the block that was > accidentally removed after cloning(!) #828286, and it appears that > #812166 was previously a blocker[1]. Xen (#812166) is (was) listed as a blocker because it depends on `openssl' and according to the bug it can't be build. It could be possible that Xen fails to build due to incompatible changes in the openssl binary. The rebuild also included the linux package which passed (so it is possible that Xen passes, too). > On a side note, I have no idea why the BTS removed all blocking bugs on > #827061 after cloning just one of them, and it turns out it did so on > two occasions, my clone[2] and Adrian's one[3]. The blocker are removed due to #820044. > Regards, > Apollon Sebastian
Bug#843988: stunnel4 segfaults (client mode)
On 2016-11-14 22:43:16 [+0100], gregor herrmann wrote:
> Yay, this looks good!
So upstream came up with the patch attached after I forwaded mine. Can
you please confirm whether this works or not?
> Cheers,
> gregor
Sebastian
diff --git a/src/prototypes.h b/src/prototypes.h
index c196f92..86f4631 100644
--- a/src/prototypes.h
+++ b/src/prototypes.h
@@ -776,6 +776,7 @@ void *str_alloc_debug(size_t, const char *, int);
#define str_alloc(a) str_alloc_debug((a), __FILE__, __LINE__)
void *str_alloc_detached_debug(size_t, const char *, int);
#define str_alloc_detached(a) str_alloc_detached_debug((a), __FILE__, __LINE__)
+void *str_realloc_detached_debug(void *, size_t, const char *, int);
void *str_realloc_debug(void *, size_t, const char *, int);
#define str_realloc(a, b) str_realloc_debug((a), (b), __FILE__, __LINE__)
void str_detach_debug(void *, const char *, int);
diff --git a/src/str.c b/src/str.c
index 524015a..b4331f7 100644
--- a/src/str.c
+++ b/src/str.c
@@ -90,6 +90,8 @@ NOEXPORT int leak_result_num=0;
NOEXPORT LPTSTR str_vtprintf(LPCTSTR, va_list);
#endif /* USE_WIN32 */
+NOEXPORT void *str_realloc_internal_debug(void *, size_t, const char *, int);
+
NOEXPORT ALLOC_LIST *get_alloc_list_ptr(void *, const char *, int);
NOEXPORT void str_leak_debug(const ALLOC_LIST *, int);
@@ -288,10 +290,22 @@ void *str_alloc_detached_debug(size_t size, const char *file, int line) {
}
void *str_realloc_debug(void *ptr, size_t size, const char *file, int line) {
+if(ptr)
+return str_realloc_internal_debug(ptr, size, file, line);
+else
+return str_alloc_debug(size, file, line);
+}
+
+void *str_realloc_detached_debug(void *ptr, size_t size, const char *file, int line) {
+if(ptr)
+return str_realloc_internal_debug(ptr, size, file, line);
+else
+return str_alloc_detached_debug(size, file, line);
+}
+
+NOEXPORT void *str_realloc_internal_debug(void *ptr, size_t size, const char *file, int line) {
ALLOC_LIST *prev_alloc_list, *alloc_list;
-if(!ptr)
-return str_alloc_debug(size, file, line);
prev_alloc_list=get_alloc_list_ptr(ptr, file, line);
str_leak_debug(prev_alloc_list, -1);
if(prev_alloc_list->size>size) /* shrinking the allocation */
diff --git a/src/tls.c b/src/tls.c
index 3964f9c..624022f 100644
--- a/src/tls.c
+++ b/src/tls.c
@@ -54,10 +54,10 @@ void tls_init() {
ui_tls=tls_alloc(NULL, NULL, "ui");
#if OPENSSL_VERSION_NUMBER>=0x1010L
CRYPTO_set_mem_functions(str_alloc_detached_debug,
-str_realloc_debug, str_free_debug);
+str_realloc_detached_debug, str_free_debug);
#else
CRYPTO_set_mem_ex_functions(str_alloc_detached_debug,
-str_realloc_debug, free_function);
+str_realloc_detached_debug, free_function);
#endif
}
Bug#828231: Building with OpenSSL 1.0.2 is sufficient for stretch
Control: tags -1 - patch On 2016-11-10 12:31:00 [+0200], Adrian Bunk wrote: > > Not a perfect solution but sufficient for stretch is the following > change to use OpenSSL 1.0.2: > > --- debian/control.old2016-11-10 10:20:58.0 + > +++ debian/control2016-11-10 10:21:32.0 + > @@ -5,7 +5,7 @@ > Uploaders: Andreas Tille , Luke Faraone > , > Unit 193 > Build-Depends: debhelper (>= 9), libldap2-dev, libpam0g-dev, libncurses-dev, > - libssl-dev, dh-autoreconf, ca-certificates, automake, autoconf, libtool, > libkrb5-dev, > + libssl1.0-dev, dh-autoreconf, ca-certificates, automake, autoconf, libtool, > libkrb5-dev, > aspell, dpkg-dev (>= 1.16.1~) > Standards-Version: 3.9.6 > Vcs-Browser: http://anonscm.debian.org/cgit/collab-maint/alpine.git Adrian, seriously? This is not a patch. While you are technically correct to describe this is a patch - it is not. The issue reported here (not building against openssl 1.1.0) is not solved by this. Tagging this as patch makes people think that there is indeed a patch which is not the case. If the maintainer decides to stick with openssl 1.0.2 for the Stretch release I assume he is able to do the change himself and lowering the severity to important rather than closing this bug. Please also untag any other patch tag in other bugs should they contain only this kind of a patch. > cu > Adrian Sebastian
Bug#844503: Acknowledgement (salt-call fails with libcrypto.so.1.1: undefined symbol: OPENSSL_no_config)
control: tags -1 patch
On 2016-11-16 12:14:43 [+0100], Filip Pytloun wrote:
> To reproduce the issue simply install salt-master and run salt-call:
>
> apt-get install salt-master
> salt-call
>
> Following exception will occur:
>
> Traceback (most recent call last):
> File "/usr/bin/salt-call", line 11, in
> salt_call()
…
> File "/usr/lib/python2.7/dist-packages/salt/utils/rsax931.py", line 63, in
> _init_libcrypto
> libcrypto.OPENSSL_no_config()
> File "/usr/lib/python2.7/ctypes/__init__.py", line 375, in __getattr__
> func = self.__getitem__(name)
> File "/usr/lib/python2.7/ctypes/__init__.py", line 380, in __getitem__
> func = self._FuncPtr((name_or_ordinal, self))
> AttributeError: /lib/x86_64-linux-gnu/libcrypto.so.1.1: undefined symbol:
> OPENSSL_no_config
the problem is that salt/rsax931.py loads the library manually and
expects certain symbols which are no longer available in OpenSSL 1.1.0.
And it loads the first libcrypto it finds plus has no dependency on
openssl.
Sebastian
>From 67676f782796071a793ec1908de50c7b86e9fbee Mon Sep 17 00:00:00 2001
From: Sebastian Andrzej Siewior
Date: Thu, 17 Nov 2016 20:43:04 +0000
Subject: [PATCH] load libcrypto.1.0.2 and not libcrypto.1.1.0
Signed-off-by: Sebastian Andrzej Siewior
---
debian/control| 1 +
salt/utils/rsax931.py | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/debian/control b/debian/control
index 5947de1336fb..b60ca31b52b2 100644
--- a/debian/control
+++ b/debian/control
@@ -31,6 +31,7 @@ Depends: python-apt,
python-requests (>= 1.0.0),
python-tornado (>= 4.2),
python-yaml,
+ libssl1.0.2,
${misc:Depends},
${python:Depends}
Recommends: lsb-release, python-croniter
diff --git a/salt/utils/rsax931.py b/salt/utils/rsax931.py
index 9eb1f4a1faf0..2d73cc2428ed 100644
--- a/salt/utils/rsax931.py
+++ b/salt/utils/rsax931.py
@@ -28,7 +28,8 @@ from ctypes.util import find_library
os.path.dirname(sys.executable),
'libcrypto.so*'))[0])
else:
-lib = find_library('crypto')
+# We need to load the lib from 1.0.2 and not what might come first
+lib = "libcrypto.so.1.0.2"
if not lib and salt.utils.is_smartos():
# smartos does not have libraries in std location
lib = glob.glob(os.path.join(
--
2.10.2
Bug#828357: isync: FTBFS with openssl 1.1.0
control: tags -1 patch fixed-upstream
On 2016-07-24 12:01:29 [+0200], Oswald Buddenhagen wrote:
> fixed in git on isync_1_2_branch.
Upstream fixed it
https://sourceforge.net/p/isync/isync/ci/41308e481466b91813f6765a0c92ad83fd9d1ab2/
In their 1.2 release branch which is available in experimental.
Alessandro: do you plan to upload the fixed 2.1 branch any time soon or
do you need something fixed for the 1.2 branch?
Sebastian
>From 41308e481466b91813f6765a0c92ad83fd9d1ab2 Mon Sep 17 00:00:00 2001
From: Oswald Buddenhagen
Date: Sun, 24 Jul 2016 11:58:57 +0200
Subject: [PATCH] fix build with openssl 1.1
they finally made their structs opaque, and provided proper getters.
---
src/socket.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/src/socket.c b/src/socket.c
index 94d0e7fba95f..3736fd5210b7 100644
--- a/src/socket.c
+++ b/src/socket.c
@@ -40,6 +40,10 @@
# include
# include
# include
+# if OPENSSL_VERSION_NUMBER < 0x1010L
+# define X509_OBJECT_get0_X509(o) ((o)->data.x509)
+# define X509_STORE_get0_objects(o) ((o)->objs)
+# endif
#endif
enum {
@@ -171,7 +175,7 @@ verify_cert_host( const server_conf_t *conf, conn_t *sock )
trusted = (STACK_OF(X509_OBJECT) *)sock->conf->trusted_certs;
for (i = 0; i < sk_X509_OBJECT_num( trusted ); i++) {
- if (!X509_cmp( cert, sk_X509_OBJECT_value( trusted, i )->data.x509 ))
+ if (!X509_cmp( cert, X509_OBJECT_get0_X509( sk_X509_OBJECT_value( trusted, i ) ) ))
return 0;
}
@@ -222,7 +226,7 @@ init_ssl_ctx( const server_conf_t *conf )
conf->cert_file, ERR_error_string( ERR_get_error(), 0 ) );
return 0;
}
- mconf->trusted_certs = (_STACK *)sk_X509_OBJECT_dup( SSL_CTX_get_cert_store( mconf->SSLContext )->objs );
+ mconf->trusted_certs = (_STACK *)sk_X509_OBJECT_dup( X509_STORE_get0_objects( SSL_CTX_get_cert_store( mconf->SSLContext ) ) );
if (mconf->system_certs && !SSL_CTX_set_default_verify_paths( mconf->SSLContext ))
warn( "Warning: Unable to load default certificate files: %s\n",
ERR_error_string( ERR_get_error(), 0 ) );
--
2.10.2
Bug#862229: libssl1.0.2: Illegal instruction on a PowerPC G4 (32 bits) "in OPENSSL_crypto207_probe () at ppccpuid.s:20"
On 2017-05-10 08:48:14 [+0200], Kurt Roeckx wrote: > This is normal and expected. This is only something you see in > a debugger, and is covered in the FAQ. Please just "continue". https://www.openssl.org/docs/faq.html#PROG17 >From looking at https://sources.debian.net/src/telegram-desktop/1.0.29-1/debian/patches/Multi-architecture.patch/ it does not look good. > Kurt Sebastian
Bug#862862: sogo: calendar sharing is not working
Package: sogo Version: 3.2.6-2 Severity: important It took me a while to setup this. In the end I went for postgresql as database including auth backend. I tried very hard to share a calendar between two users. It just won't happen. If I click on a calendar, preferences, share then there is almost nothing there. Which means the other user can't subscribe nor does he see something by default. Shortly before I decided to purge sogo and try something else I upgraded to the version in experimental. And see there, it works. I am sure that the test path was: restart sogo, tried => didn't work, upgraded to exp, tried => worked. I even purge the database and tried from scratch with the same result. The version in exp is similar to what I see in the live demo at [0] (click on calendar's preferences, share and there are things to click (private, public, confidation, authenticated user and so on) which is missing in the version in unstable. My question here: am I simply too $attribute to configure it properly or is this something that works perfectly with the LDAP auth-backend but not with SQL? If not, wouldn't it be material for testing _or_ at least document it? [0] http://demo.sogo.nu Sebastian
Bug#861686: unblock: openssl/1.1.0e-2
On 2017-05-07 16:39:00 [+], Niels Thykier wrote: > Sebastian Andrzej Siewior: > > uploaded and built on all releases architectures. > > Ack/RT unblock, CC'ing KiBi for a d-i ack. I don't want to rush or anything but in case it got forgotten, we are still waiting for the d-i ack. > Thanks, > ~Niels Sebastian
Bug#858828: golang-github-google-certificate-transparency: Please migrate to openssl1.1 in Buster
Package: golang-github-google-certificate-transparency Version: 0.0~git20160709.0.0f6e3d1~ds1-1 Severity: important Tags: sid buster User: pkg-openssl-de...@lists.alioth.debian.org Usertag: openssl-1.1-trans Please migrate to libssl-dev in the Buster cycle. Sebastian
Bug#858829: haskell-hookup: Please migrate to openssl1.1 in Buster
Package: haskell-hookup Version: 0.1.0.0-3 Severity: important Tags: sid buster User: pkg-openssl-de...@lists.alioth.debian.org Usertag: openssl-1.1-trans Please migrate to libssl-dev in the Buster cycle. Sebastian
Bug#858857: h323plus: Please migrate to openssl1.1 in Buster
Package: h323plus Version: 1.24.0~dfsg2-1.3 Severity: important Tags: sid buster User: pkg-openssl-de...@lists.alioth.debian.org Usertag: openssl-1.1-trans Please migrate to libssl-dev in the Buster cycle. I tried and failed to clone this from #84 where h323plus switched to libssl1.0-dev. Sebastian
Bug#761989: Please remove libdc0 from Debian
Control: reassign 761989 ftp.debian.org Control: retitle 761989 RM: RoQA; unmaintained, dead upstream, low popcon, library with no rdeps On 2017-01-17 10:16:52 [+], Simon McVittie wrote: > Control: reassign 761998 ftp.debian.org > Control: retitle 761998 RM: RoQA; unmaintained, dead upstream, low popcon, > library with no rdeps > > On Wed, 17 Sep 2014 at 21:54:52 +0700, Maia Everett wrote: > > libdc0/valknut's upstream is pretty much dead. The only user of libdc0 > > is valknut, for which I'm also filing a removal request and which can be > > replaced by its actively maintained fork, eiskaltdcpp. > > > > The last stable release of libdc0 was in 2009 and the last SVN commit > > was in 2011. > > This reasoning seems good to me. Reassigning to ftp.debian.org for removal. The reassign above (in the quoted mail) was sent to #761998 and looking at the history of #761998 it looks like it has been one twice by Simon McVittie so I _assume_ that one was intended for 761989/libdc0 since the bug report talks about both packages. Therefore I reassign the bug to ftp.d.o for the final removal. > S Sebastian
Bug#858989: libapache2-mod-auth-pubtkt: Please migrate to openssl1.1 in Buster
Package: libapache2-mod-auth-pubtkt Version: 0.10-1 Severity: important Tags: sid buster User: pkg-openssl-de...@lists.alioth.debian.org Usertags: openssl-1.1-trans Please migrate to libssl-dev in the Buster cycle. Sebastian
Bug#859050: lighttpd: Please migrate to openssl1.1 in Buster
Package: lighttpd Version: 1.4.44-1 Severity: important Tags: sid buster User: pkg-openssl-de...@lists.alioth.debian.org Usertags: openssl-1.1-trans Please migrate to libssl-dev in the Buster cycle. I have no idea why "libssl-dev|libssl1.0-dev" is currently used. Sebastian
Bug#859143: kup: please update to v0.3.6 due changes on k.o
Package: kup Version: 0.3.2-1 Severity: wishlist The kup-server on k.o will be probably upgraded / changed around kernel's rc6 and rc7 which renders current kup-client version useless / not working. Konstantin tagged as of today 0.3.6 which is working / contains the required changes on the client side. Sebastian
Bug#859143: kup: please update to v0.3.6 due changes on k.o
On 2017-03-30 22:45:57 [+0100], Ben Hutchings wrote: > Upgrading severity as it would be pointless to release with this > version. Sure. And probably something for current stable, I don't know. Should we ask on users@k.o or just do it? Anyway if you want some help here or there just say so. > Ben. Sebastian
Bug#859191: Manpages to s_client and s_server mentions tls1_3 but the programs don't support it
control: forwarded -1 https://github.com/openssl/openssl/pull/3099 Sebastian
Bug#729009: [Pkg-openssl-devel] Bug#729009: openssl: no man page for "srp" command
On 2017-03-22 09:29:45 [-0400], Brian Minton wrote: > This bug still exists in the most recent version of the openssl package. sad but true. And the master branch has also no manpage for srp. Do you mind witting one? Sebastian
Bug#859222: mongo-tools: Please migrate to openssl1.1 in Buster
Package: mongo-tools Version: 3.2.11-1 Severity: important Tags: sid buster User: pkg-openssl-de...@lists.alioth.debian.org Usertags: openssl-1.1-trans Please migrate to libssl-dev in the Buster cycle. Sebastian
Bug#859223: nagios-nrpe: Please migrate to openssl1.1 in Buster
Package: nagios-nrpe Version: 3.0.1-1~exp1 Severity: important Tags: sid buster User: pkg-openssl-de...@lists.alioth.debian.org Usertags: openssl-1.1-trans Please migrate to libssl-dev in the Buster cycle. Sebastian
Bug#859224: netkit-ftp-ssl: Please migrate to openssl1.1 in Buster
Package: netkit-ftp-ssl Version: 0.17.34+0.2-1 Severity: important Tags: sid buster User: pkg-openssl-de...@lists.alioth.debian.org Usertags: openssl-1.1-trans Please migrate to libssl-dev in the Buster cycle. Sebastian
Bug#859230: netsurf: Please migrate to openssl1.1 in Buster
Package: netsurf Version: 3.6-3.1 Severity: important Tags: sid buster User: pkg-openssl-de...@lists.alioth.debian.org Usertags: openssl-1.1-trans Please migrate to libssl-dev in the Buster cycle. It was moved to libssl1.0-dev in #846908 due to curl. Sebastian
