Bug#984939: python-netaddr-docs: Many topics are empty

[Teddy Hogeborn]

Package: python-netaddr-docs
Version: 0.7.19-4
Severity: grave
Justification: renders package unusable

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?

I wanted to read the documentation for the python-netaddr and
python3-netaddr packages.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

I opened the HTML files in /usr/share/doc/python-netaddr-docs,
expecting to read the documentation for the python-netaddr package.

   * What was the outcome of this action?

The HTML files are there, but the following chapters/topics are empty
of text, and therefore unusable as documentation:

* Installing netaddr
* Tutorial 1: IP Addresses, Subnets and Ranges
* Tutorial 2: MAC addresses
* Tutorial 3: Working with IP sets
* Contributors

Only the "API Reference" topic/chapter has useful documentation, but a
dry reference is not always very helpful.

   * What outcome did you expect instead?

I expected the above-mentioned files to contain equivalent
documentation as seen on these corresponding web pages:

https://netaddr.readthedocs.io/en/latest/installation.html

https://netaddr.readthedocs.io/en/latest/tutorial_01.html

https://netaddr.readthedocs.io/en/latest/tutorial_02.html

https://netaddr.readthedocs.io/en/latest/tutorial_03.html

https://netaddr.readthedocs.io/en/latest/contributors.html

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: 10.8
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-0.bpo.3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:C:en:en_GB:sv_SE:sv_FI (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python-netaddr-docs depends on:
ii  libjs-sphinxdoc  1.8.4-1

python-netaddr-docs recommends no packages.

python-netaddr-docs suggests no packages.

-- no debconf information

Bug#939084: BytesWarning: Comparison between bytes and string

[Teddy Hogeborn]

Package: python3-urwid
Version: 2.0.1-2+b1
Severity: minor
Tags: upstream

When running an urwid program using "/usr/bin/python3 -b" (note the -b
option), the urwid package triggered a warning:

[...]
  File "/usr/lib/python3/dist-packages/urwid/display_common.py", line 760, in 
stop
self._stop()
  File "/usr/lib/python3/dist-packages/urwid/curses_display.py", line 147, in 
_stop
self.tty_signal_keys(*self._old_signal_keys)
  File "/usr/lib/python3/dist-packages/urwid/display_common.py", line 700, in 
tty_signal_keys
if intr == 'undefined': intr = 0
BytesWarning: Comparison between bytes and string

I would expect a Python 3 module such as python3-urwid to be able to
run (when the -b option to python3 is used) without generating such
warnings.

-- System Information:
Debian Release: 10.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:C:en:en_GB:sv_SE:sv_FI (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-urwid depends on:
ii  libc62.28-10
ii  python3  3.7.3-1

python3-urwid recommends no packages.

Versions of packages python3-urwid suggests:
pn  python-urwid-doc  

-- no debconf information

Bug#928415: firefox-esr: All extensions are disabled

[Teddy Hogeborn]

Hartmut Buhrmester  wrote:

> So I think, that the setting xpinstall.signatures.required = false is
> not really needed.
> 
> Enabling "studies" and using a short update interval of 5 seconds
> should do the trick.

I think the opposite is true.

I had xpinstall.signatures.required set to false before the certificate
expired, and no extensions were or are disabled for me.  The only effect
is the display of the text "[Extension] could not be verified for use in
Firefox.  Proceed with caution." displayed for every single extension in
the add-on page, and that was only after I had prodded it by clicking
"Check for updates".

My settings for app.shield.optoutstudies.enabled and
app.normandy.run_interval_seconds are the default values (false and
86400, respectively).

Do you have any information indicating that the "studies" can be
activated in any way in the Debian version of Firefox?  I tend to
believe the Preferences page text (right where the studies checkbox is
disabled): "Data reporting is disabled for this build configuration".
That is, the Debian version is compiled without this available.  Do you
have any reason to believe this to be false?

Your observed behavior could easily be explained by the fact that
Firefox doesn't check the signatures immediately, and it might have
happened to check them just as you were altering the "studies" settings,
which themselves did nothing.

My installed version is:

Package: firefox-esr
Version: 60.6.1esr-1~deb9u1

/Teddy Hogeborn

Bug#922209: unblock: mandos/1.8.3-3

[Teddy Hogeborn]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Hi Release Team,

Please allow mandos to migrate into testing and subsequent freeze.  The
mandos package was removed because libgnutls30 3.6.0 had removed
functionality which Mandos depended on, but libgnutls30 3.6.6, with
suitable replacement functionality, was not released until a few weeks
ago, and we (also being upstream) had to scramble to implement a new
protocol using the new GnuTLS features.  This was done on this past
Sunday (with a few more releases done on Saturday to fix minor bugs).
We would have done it sooner after the package removal, but we needed
GnuTLS 3.6.6, which *is* going into buster.

It seems a pity to lose the mandos package after 10 years in Debian
entirely because of the bad timing of GnuTLS 3.6.6 and the Debian freeze
being so close.

I brought this up on IRC #debian-release, and issue with the packaging
(#922202) was revealed, but it was easily fixed since the offending code
was only for backports, so a new version (1.8.3-3) has been uploaded
with the relevant code simply removed.  We are prepared to do any
further required changes to the package (and/or upstream) as needed.

/Teddy Hogeborn

-- 
The Mandos Project
https://www.recompile.se/mandos

Bug#917029: systemd: Reproducible instant reboot without diagnostics even in debug mode

[Teddy Hogeborn]

Package: systemd
Version: 239-12~bpo9+1
Severity: normal
Tags: upstream

There is a way to get systemd to instantly reboot the system; this
behaviour is 100% reproducible if run on real hardware, i.e. not in
Qemu or similar.  The cause is a misconfigured system, but this bug is
mainly about the lack of any diagnostics or journal messages of any
kind - the system instantly reboots without any message, even in
systemd debug mode.

Steps to reproduce:

1. Make sure nss-systemd is used in /etc/nsswitch.conf; i.e. that file
   should contain this line:

passwd: compat systemd

2. Create a systemd generator script (i.e. an arbitrarily named
   executable file in the /lib/systemd/system-generators directory),
   containing only the following two lines:

#!/bin/sh

getent passwd > /dev/null

3. Run "sudo systemctl daemon-reload".

4. The system will reboot in a few seconds, without any journal
   message or console output of any kind, even when running systemd in
   debug mode.

Again, note that we have never been able to reproduce this reboot when
running an emulated system using Qemu, only when running on real
hardware. The bug has been reproduced on multiple different hardware
platforms.

-- Package-specific info:

-- System Information:
Debian Release: 9.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-8-amd64 (SMP w/24 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages systemd depends on:
ii  adduser 3.115
ii  libacl1 2.2.52-3+b1
ii  libapparmor12.11.0-3+deb9u2
ii  libaudit1   1:2.6.7-2
ii  libblkid1   2.29.2-1+deb9u1
ii  libc6   2.24-11+deb9u3
ii  libcap2 1:2.25-1
ii  libcryptsetup4  2:1.7.3-4
ii  libgcrypt20 1.7.6-2+deb9u3
ii  libgnutls30 3.5.8-5+deb9u4
ii  libgpg-error0   1.26-2
ii  libidn111.33-1
ii  libip4tc0   1.6.0+snapshot20161117-6
ii  libkmod223-2
ii  liblz4-10.0~r131-2+b1
ii  liblzma55.2.2-1.2+b1
ii  libmount1   2.29.2-1+deb9u1
ii  libpam0g1.1.8-3.6
ii  libseccomp2 2.3.1-2.1+deb9u1
ii  libselinux1 2.6-3+b3
ii  libsystemd0 239-12~bpo9+1
ii  mount   2.29.2-1+deb9u1
ii  procps  2:3.3.12-3+deb9u1
ii  util-linux  2.29.2-1+deb9u1

Versions of packages systemd recommends:
ii  dbus1.10.26-0+deb9u1
ii  libpam-systemd  239-12~bpo9+1

Versions of packages systemd suggests:
pn  policykit-1
pn  systemd-container  

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.130
ii  udev 239-12~bpo9+1

-- Configuration Files:
/etc/systemd/resolved.conf changed:
[Resolve]
FallbackDNS=

/etc/systemd/system.conf changed:
[Manager]
RuntimeWatchdogSec=20


-- no debconf information
[EXTENDED]   /lib/systemd/system/apache2.service -> 
/etc/systemd/system/apache2.service.d/requires-etc-apache2.conf
[EXTENDED]   /lib/systemd/system/apache2.service -> 
/etc/systemd/system/apache2.service.d/stop.conf
[EXTENDED]   /lib/systemd/system/apache2.service -> 
/etc/systemd/system/apache2.service.d/var-run-evasive.conf
[EXTENDED]   /lib/systemd/system/rc-local.service -> 
/lib/systemd/system/rc-local.service.d/debian.conf
[EXTENDED]   /lib/systemd/system/systemd-journald.service -> 
/etc/systemd/system/systemd-journald.service.d/restart.conf
[EXTENDED]   /lib/systemd/system/systemd-networkd-wait-online.service -> 
/etc/systemd/system/systemd-networkd-wait-online.service.d/override.conf
[EXTENDED]   /lib/systemd/system/systemd-resolved.service -> 
/lib/systemd/system/systemd-resolved.service.d/resolvconf.conf
[EXTENDED]   /lib/systemd/system/systemd-timesyncd.service -> 
/lib/systemd/system/systemd-timesyncd.service.d/disable-with-time-daemon.conf

8 overridden configuration files found.
==> /var/lib/systemd/deb-systemd-helper-enabled/quota.service.dsh-also <==
/etc/systemd/system/sysinit.target.wants/quota.service

==> /var/lib/systemd/deb-systemd-helper-enabled/inetd.service.dsh-also <==
/etc/systemd/system/multi-user.target.wants/inetd.service

==> /var/lib/systemd/deb-systemd-helper-enabled/smartd.service.dsh-also <==
/etc/systemd/system/multi-user.target.wants/smartd.service

==> /var/lib/systemd/deb-systemd-helper-enabled/irqbalance.service.dsh-also <==
/etc/systemd/system/multi-user.target.wants/irqbalance.service

==> 
/var/lib/systemd/deb-systemd-helper-enabled/network-online.target.wants/networking.service
 <==

==> /var/lib/systemd/deb-systemd-helper-enabled/syslog.service <==

==> /var/lib/systemd/deb-systemd-helper-enabled/uuidd.service.dsh-also <==
/etc/systemd/system/sockets.target.wants/uuidd.socket

==> /var/lib/systemd/deb-systemd-helper-enabled/lvm2-monitor.service.dsh-also 
<==
/etc/systemd/system/sysinit.target.wants/lvm2-monitor.service

==> 

Bug#894495: mandos-client: Mandos client fails while booting but works from chroot into unpacked initramfs

[Teddy Hogeborn]

Michel Bouissou <mic...@bouissou.net> writes:

> Okay I finally pinned it.
>
> By trying to run manually the GPG key import in the initramfs, I
> discovered that the issue was...
>
> THAT THE RASPBERRY PI HAS NO REAL TIME CLOCK !

...Right.

Would you mind trying the attached mandos-client.c?  It tries to work
around the problem by, if the time is unset or is January 1970, setting
the time to the timestamp of the key file.  If it works, I'll commit it
and probably make a new release with this code.

I would have liked to simply tell GnuPG to no care about keys created in
the future by using the options --ignore-time-conflict and/or
--ignore-valid-from, but from what I can see, there does not seem to be
a way to pass those through GPGME.  So we'll do it the hard way, by
setting the system clock, like you did.

/Teddy Hogeborn

-- 
The Mandos Project
https://www.recompile.se/mandos
/*  -*- coding: utf-8 -*- */
/*
 * Mandos-client - get and decrypt data from a Mandos server
 *
 * This program is partly derived from an example program for an Avahi
 * service browser, downloaded from
 * <http://avahi.org/browser/examples/core-browse-services.c>.  This
 * includes the following functions: "resolve_callback",
 * "browse_callback", and parts of "main".
 * 
 * Everything else is
 * Copyright © 2008-2018 Teddy Hogeborn
 * Copyright © 2008-2018 Björn Påhlsson
 * 
 * This file is part of Mandos.
 * 
 * Mandos is free software: you can redistribute it and/or modify it
 * under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 * 
 * Mandos is distributed in the hope that it will be useful, but
 * WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
 * General Public License for more details.
 * 
 * You should have received a copy of the GNU General Public License
 * along with Mandos.  If not, see <http://www.gnu.org/licenses/>.
 * 
 * Contact the authors at <man...@recompile.se>.
 */

/* Needed by GPGME, specifically gpgme_data_seek() */
#ifndef _LARGEFILE_SOURCE
#define _LARGEFILE_SOURCE
#endif	/* not _LARGEFILE_SOURCE */
#ifndef _FILE_OFFSET_BITS
#define _FILE_OFFSET_BITS 64
#endif	/* not _FILE_OFFSET_BITS */

#define _GNU_SOURCE		/* TEMP_FAILURE_RETRY(), asprintf() */

#include 		/* fprintf(), stderr, fwrite(),
   stdout, ferror() */
#include  		/* uint16_t, uint32_t, intptr_t */
#include 		/* NULL, size_t, ssize_t */
#include  		/* free(), EXIT_SUCCESS, srand(),
   strtof(), abort() */
#include 		/* bool, false, true */
#include 		/* strcmp(), strlen(), strerror(),
   asprintf(), strncpy(), strsignal()
*/
#include 		/* ioctl */
#include 		/* socket(), inet_pton(), sockaddr,
   sockaddr_in6, PF_INET6,
   SOCK_STREAM, uid_t, gid_t, open(),
   opendir(), DIR */
#include 		/* open(), S_ISREG */
#include 		/* socket(), struct sockaddr_in6,
   inet_pton(), connect(),
   getnameinfo() */
#include 		/* open(), unlinkat(), AT_REMOVEDIR */
#include 		/* opendir(), struct dirent, readdir()
 */
#include 		/* PRIu16, PRIdMAX, intmax_t,
   strtoimax() */
#include 		/* perror(), errno, EINTR, EINVAL,
   EAI_SYSTEM, ENETUNREACH,
   EHOSTUNREACH, ECONNREFUSED, EPROTO,
   EIO, ENOENT, ENXIO, ENOMEM, EISDIR,
   ENOTEMPTY,
   program_invocation_short_name */
#include 		/* nanosleep(), time(), sleep() */
#include 		/* ioctl, ifreq, SIOCGIFFLAGS, IFF_UP,
   SIOCSIFFLAGS, if_indextoname(),
   if_nametoindex(), IF_NAMESIZE */
#include 		/* IN6_IS_ADDR_LINKLOCAL,
   INET_ADDRSTRLEN, INET6_ADDRSTRLEN
*/
#include 		/* close(), SEEK_SET, off_t, write(),
   getuid(), getgid(), seteuid(),
   setgid(), pause(), _exit(),
   unlinkat() */
#include 		/* inet_pton(), htons() */
#include 		/* not, or, and */
#include 		/* struct argp_option, error_t, struct
   argp_state, struct argp,
   argp_parse(), ARGP_KEY_ARG,
   ARGP_KEY_END, ARGP_ERR_UNKNOWN */
#include 		/* sigemptyset(), sigaddset(),
   sigaction(), SIGTERM, sig_atomic_t,
   raise() */
#include 		/* EX_OSERR, EX_USAGE, EX_UNAVAILABLE,
   EX_NOHOST, EX_IOERR, EX_PROTOCOL */
#include 		/* waitpid(), WIFEXITED(),
   WEXITSTATUS(), WTERMSIG() */
#include 		/* setgroups() */
#include 		/* argz_add_sep(), argz_next(),
   argz_delete(), argz_append(),
   argz_stringify(), argz_add(),
   argz_count() */
#include 		/* getnameinfo(), NI_NUMERICHOST,
   EAI_SYSTEM, gai_strerror() */

#ifdef __linux__
#include  		/* klogctl() */
#endif	/* __linux__ */

/* Avahi */
/* All Avahi types, constants and functions
 Avahi*, avahi_*,
 AVAHI_* */
#include 
#include 
#include 
#include 
#include 
#include 

/* GnuTLS */
#include 	/* All GnuTLS types, constants and
   functions:
	

Bug#894495: mandos-client: Mandos client fails while booting but works from chroot into unpacked initramfs

[Teddy Hogeborn]

Michel Bouissou <mic...@bouissou.net> writes:

> After a more thourough dive in GPGME logs, it is now crystal clear to
> me that the matter is that GPG is unable to import the key data that
> GPGME tries to feed into it at key import time.
>
> Here is the result of the GPG secret key import (working) inside the
> chroot :
>
> [GNUPG:] KEY_CONSIDERED .
> [GNUPG:] IMPORTED .
> [GNUPG:] IMPORT_OK 1 .
> [GNUPG:] IMPORT_RES 1 0 1 0 0 0 0 0 0 1 1 0 0 0 0
>
> - Count : 1
> - Imported : 1
> - Sec Read : 1
> - Sec Imported : 1
>
> And now the failing one from initramfs :
>
> [GNUPG:] IMPORT_RES 1 1 0 0 0 0 0 0 0 1 0 0 0 0 0.
>
> - Count : 1
> - No_User_ID : 1
> - Imported : 0
> - Sec Read : 1
> - Sec Imported : 0
>
> IMPORT_RES 
>  
>   
>
> However it further seems to properly receive the encrypted data, but
> is unable to decrypt it because it has no keys.
>
> I have no clue about why, and what the difference can be, but I need a
> break for now as I have spent my entire sunday wrestling with this :-\

I've added, to the latest revision of mandos-client.c in trunk, an
additional check for errors in the GPGME key importing code, and lots of
code for outputting whatever GPGME says went wrong.  Latest revision of
mandos-client.c, and a bare diff with just this change, are attached.

This should hopefully show what GPGME thinks is the problem.  Whatever
it is, it can't be a problem reading the key files, because we can
import them into GnuTLS just fine.  It must, I think, be some problem
with writing or locking the GPGME keyring files, which is why I'm still
leaing towards the unwriteable /tmp problem, or something very much like
it.

/Teddy Hogeborn

-- 
The Mandos Project
https://www.recompile.se/mandos
/*  -*- coding: utf-8 -*- */
/*
 * Mandos-client - get and decrypt data from a Mandos server
 *
 * This program is partly derived from an example program for an Avahi
 * service browser, downloaded from
 * <http://avahi.org/browser/examples/core-browse-services.c>.  This
 * includes the following functions: "resolve_callback",
 * "browse_callback", and parts of "main".
 * 
 * Everything else is
 * Copyright © 2008-2018 Teddy Hogeborn
 * Copyright © 2008-2018 Björn Påhlsson
 * 
 * This file is part of Mandos.
 * 
 * Mandos is free software: you can redistribute it and/or modify it
 * under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 * 
 * Mandos is distributed in the hope that it will be useful, but
 * WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
 * General Public License for more details.
 * 
 * You should have received a copy of the GNU General Public License
 * along with Mandos.  If not, see <http://www.gnu.org/licenses/>.
 * 
 * Contact the authors at <man...@recompile.se>.
 */

/* Needed by GPGME, specifically gpgme_data_seek() */
#ifndef _LARGEFILE_SOURCE
#define _LARGEFILE_SOURCE
#endif	/* not _LARGEFILE_SOURCE */
#ifndef _FILE_OFFSET_BITS
#define _FILE_OFFSET_BITS 64
#endif	/* not _FILE_OFFSET_BITS */

#define _GNU_SOURCE		/* TEMP_FAILURE_RETRY(), asprintf() */

#include 		/* fprintf(), stderr, fwrite(),
   stdout, ferror() */
#include  		/* uint16_t, uint32_t, intptr_t */
#include 		/* NULL, size_t, ssize_t */
#include  		/* free(), EXIT_SUCCESS, srand(),
   strtof(), abort() */
#include 		/* bool, false, true */
#include 		/* strcmp(), strlen(), strerror(),
   asprintf(), strncpy(), strsignal()
*/
#include 		/* ioctl */
#include 		/* socket(), inet_pton(), sockaddr,
   sockaddr_in6, PF_INET6,
   SOCK_STREAM, uid_t, gid_t, open(),
   opendir(), DIR */
#include 		/* open(), S_ISREG */
#include 		/* socket(), struct sockaddr_in6,
   inet_pton(), connect(),
   getnameinfo() */
#include 		/* open(), unlinkat(), AT_REMOVEDIR */
#include 		/* opendir(), struct dirent, readdir()
 */
#include 		/* PRIu16, PRIdMAX, intmax_t,
   strtoimax() */
#include 		/* perror(), errno, EINTR, EINVAL,
   EAI_SYSTEM, ENETUNREACH,
   EHOSTUNREACH, ECONNREFUSED, EPROTO,
   EIO, ENOENT, ENXIO, ENOMEM, EISDIR,
   ENOTEMPTY,
   program_invocation_short_name */
#include 		/* nanosleep(), time(), sleep() */
#include 		/* ioctl, ifreq, SIOCGIFFLAGS, IFF_UP,
   SIOCSIFFLAGS, if_indextoname(),
   if_nametoindex(), IF_NAMESIZE */
#include 		/* IN6_IS_ADDR_LINKLOCAL,
   INET_ADDRSTRLEN, INET6_ADDRSTRLEN
*/
#include 		/* close(), SEEK_SET, off_t, write(),
   getuid(), getgid(), seteuid(),
   setgid(), pause(), _exit(),
   unlinkat() */
#include 		/* inet_pton(), htons() */
#include 		/* not, or, and */
#include 		/* struct argp_option, error_t, struct
   argp_sta

Bug#894495: [tethys] mandos-client: Mandos client fails while booting but works from chroot into unpacked initramfs

[Teddy Hogeborn]

Michel Bouissou <mic...@bouissou.net> writes:

> /lib/mandos/plugin-runner
>
> I assume the latter starts the clients with the exact options from
> /conf/conf.d/mandos/plugin-runner.conf

Yes, as documented in plugin-runner(8mandos).

> ... and there is no --dh-params option.

There isn't?

To be precise, do you mean that the
/conf/conf.d/mandos/plugin-runner.conf file does not contain the line
--options-for=mandos-client:--dh-params=/conf/conf.d/mandos/dhparams.pem
at the top?  What, exactly, *does* it contain?  Does it lack the
--groupid and --userid options too?

If so, that is odd; these options should have been added when creating
the initramfs image.  The script which adds the Mandos client to the
initramfs image also adds these options when copying the base
/etc/mandos/plugin-runner.conf to /conf/conf.d/mandos/plugin-runner.conf
in the initramfs image.

If the --userid and --groupid options are not in
/conf/conf.d/mandos/plugin-runner.conf, that might explain the observed
behavior.

Maybe the Mandos initramfs creation hook script aborts for some reason
before it comes that far?  Does "update-initramfs -k all -u" (as root,
on the client system) give some error messages or warnings?

> > Since GPGME is giving the error, and it has been a problem in the
> > past, until it has beeen proved otherwise I suspect that the proper
> > binaries are not present in the system, or that they are not
> > runnable somehow.
>
> Well, they are surely there as it works in the chrooted copy of
> initramfs...

Well, maybe they aren't runnable because plugin-runner is switching to
the wrong user and group ID.  But in that case it's strange that it
could read the OpenPGP key files.

/Teddy Hogeborn

-- 
The Mandos Project
https://www.recompile.se/mandos


signature.asc
Description: PGP signature

Bug#894495: [tethys] mandos-client: Mandos client fails while booting but works from chroot into unpacked initramfs

[Teddy Hogeborn]

root <ro...@bouissou.org> writes:

> Package: mandos-client
> Version: 1.7.15-1
> Severity: important

If practical, try the latest version, 1.7.19.

> Mandos plugin mandos-client: Trying to decrypt OpenPGP data
> Mandos plugin mandos-client: bad gpgme_op_decrypt: GPGME: Decryption failed

That is the important message.  It means that it failed to decrypt the
data from the server using the GPGME library.  In the past, this error
has been due to all the necessary GnuPG binaries not having been copied
into the initramfs image.

> plugins.d/mandos-client.c:422:2: runtime error: null pointer passed as 
> argument 3, which is declared to never be null

That error is simply about not being able to print an error message
about any "unsupported algorithm", since that field is NULL.  I.e. a
spurious error message from the error handling routing itself.  Ignore
it for now.

> If I test the client per the manual instructions, it WORKS.
>
> If I unpack the initramfs, chroot into it and run the client, it WORKS.
>
> But when the system boots, it FAILS.
> 
> During system boot, I can SSH into the running initramfs using
> dropbear, then if I run the client manually, it fails with the exact
> same error that I can see displayed on screen when booting unattended.

First, when SSHing into the running system, make sure that /tmp is made
writeable by the unprivileged _mandos user.  This is fixed by the
automatic scripts when booting, but if you are running things manually
it might not be done.  Simply run "chmod a=rwxt /tmp" in the initramfs
file system.

Second, be aware that the instructions for running the client manually
does not contain the optional --dh-params option (Usually passed with an
argument of /etc/keys/mandos/dhparams.pem), but this option is used
automatically by the boot scripts.  Just to make sure, does it work when
run manually with or without a chroot with this option?  (Passing this
option also makes the client startup quite a bit faster, speeding up
debugging.)

> Any help in solving this will be greatly appreciated :-)

Since GPGME is giving the error, and it has been a problem in the past,
until it has beeen proved otherwise I suspect that the proper binaries
are not present in the system, or that they are not runnable somehow.

What does the "gpgconf" command output, in the normal system, in chroot,
and at boot?  Do the listed binaries all exist in all three systems,
i.e. what is the output of this command?

ls -laF $(gpgconf | awk -F: '{ print $3 }')

(Also don't forget to double check for a non-writeable /tmp.)

/Teddy Hogeborn

-- 
The Mandos Project
https://www.recompile.se/mandos


signature.asc
Description: PGP signature

Bug#886595: closed by Teddy Hogeborn <te...@recompile.se> (Bug#886595: fixed in mandos 1.7.17-1)

[Teddy Hogeborn]

Edward Shornock <ed.shorn...@gmail.com> writes:

> On 10.02.2018 23:24, Debian Bug Tracking System wrote:
> >* Fix "fails with "LeakSanitizer has encountered a fatal error""
> >  by fixing memory leak in plugin-runner (Closes: #886595)
>
> For what it's worth I still see an occasional "LeakSanitizer" crash
> with 1.7.18-1. I don't have any packages installed with *plymouth* in
> the name.
>
> Please let me know what I can do to help troubleshoot this.

You could probably *avoid* the problem entirely by recompiling the
program without "-fsanitize=leak".  Of course, that only hides the
actual memory leak, but it avoids the problem it causes.

To help *finding* the memory leak, I would suggest the following:
Disable all the plugins you don't use; put the following into
/etc/mandos/plugin-runner.conf:

--disable=askpass-fifo
--disable=plymouth
--disable=splashy
--disable=usplash

(Make sure to rebuild the initramfs image with "update-initramfs -k all
-u" after changing that file.)  After doing this, do you still see
"LeakSanitizer" output when booting?

If you do, try to disable the "password-prompt" and/or the
"mandos-client" plugins as well.  Note: disabling the "mandos-client"
plugin will necessitate the manual typing of the password on boot, and
disabling "password-prompt" plugin will rely on the Mandos client for
getting the password.  You could also disable them *both*, and the
plugin-runner will fall back to asking for the password itself on the
console.  I am wondering which, if any, of these disablings will make
the LeakSanitizer errors go away on your system.  That would help to
narrow the problem down significantly.

/Teddy Hogeborn

-- 
The Mandos Project
https://www.recompile.se/mandos


signature.asc
Description: PGP signature

Bug#879538: mandos: (tries to) use GnuTLS OpenPGP support

[Teddy Hogeborn]

Andreas Metzler <ametz...@bebt.de> writes:

> plugins.d/mandos-client.c actually uses GnuTLS OpenPGP support. This
> code was marked deprecated in 3.5.9 and was removed in 3.6.0. Noop stub
> functions are still shipped to avoid ABI breakage but return 
> GNUTLS_E_UNIMPLEMENTED_FEATURE.
>
> Please drop GnuTLS OpenPGP support in mandos.

We can't do that, it's an integral part of the Mandos client/server
network protocol; removing it would entail creating an entirely new
incompatible protocol.  We plan to do that using a feature not yet
available in GnuTLS called "raw public keys" (RFC7250), but its
developer has not merged it to GnuTLS upstream yet.

/Teddy Hogeborn

-- 
The Mandos Project
https://www.recompile.se/mandos


signature.asc
Description: PGP signature

Bug#859861: transcriber: Waveform cursor is invisible (patch included)

[Teddy Hogeborn]

Package: transcriber
Version: 1.5.1.1-10
Severity: important
Tags: patch

Dear Maintainer,

In olden times, lo, many Debian releases ago, when playing audio in
transcriber, a dashed red line was visible in the audio waveform at the
point where the audio was playing or paused.  The line is no longer
visible, which sadly makes the entire program almost completely
unusable.  I have investigated and, without fully understanding the
mechanisms, have written a patch to fix the problem (also attached):

--- transcriber-1.5.1.1/src/wavfm.c.~1~ 2017-04-08 04:07:20.0 +0200
+++ transcriber-1.5.1.1/src/wavfm.c 2017-04-08 04:07:53.350918541 +0200
@@ -508,8 +508,8 @@
 
/* Cursor graphic context */
gcValues.foreground = w->cursorcolor->pixel;
-   gcValues.line_style = LineOnOffDash;
-   gcValues.dashes = 3;
+   gcValues.line_style = LineSolid;
+   gcValues.dashes = 2;
newGC = Tk_GetGC(w->tkwin,
  GCBackground|GCForeground|GCLineStyle|GCDashList|GCGraphicsExposures,
  );

(This makes it a solid red line instead of a dashed red line, but I
think it is not an important difference.)

/Teddy Hogeborn

-- System Information:
Debian Release: 8.7
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'stable')
Architecture: i386 (i686)

Kernel: Linux 3.16.0-4-686-pae (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages transcriber depends on:
ii  libc6  2.19-18+deb8u7
ii  libtcl8.6  8.6.2+dfsg-2
ii  libtk8.6   8.6.2-1
ii  libx11-6   2:1.6.2-3
ii  sox14.4.1-5
ii  tcl-snack  2.2.10.20090623-dfsg-4
ii  tcl-tclex  1.2a1-16
ii  tk 8.6.0+8

transcriber recommends no packages.

transcriber suggests no packages.

-- no debconf information

--- transcriber-1.5.1.1/src/wavfm.c.~1~	2017-04-08 04:07:20.0 +0200
+++ transcriber-1.5.1.1/src/wavfm.c	2017-04-08 04:07:53.350918541 +0200
@@ -508,8 +508,8 @@
 
/* Cursor graphic context */
gcValues.foreground = w->cursorcolor->pixel;
-   gcValues.line_style = LineOnOffDash;
-   gcValues.dashes = 3;
+   gcValues.line_style = LineSolid;
+   gcValues.dashes = 2;
newGC = Tk_GetGC(w->tkwin,
  GCBackground|GCForeground|GCLineStyle|GCDashList|GCGraphicsExposures,
  );


signature.asc
Description: PGP signature

Bug#855589: mandos: Seems not to be honoring zeroconf option at mandos.conf

[Teddy Hogeborn]

Pablo Abelenda <pabele...@igalia.com> writes:

> Package: mandos
> Version: 1.6.9
> Severity: normal
> Tags: patch
>
> Dear Maintainer,
>
> I've been making a mandos server setup. The service and the servers
> it has to unlock are running on different networks and, due to this,
> zeroconf is not useful for me. As I was not using zeroconf, avahi
> service was not running while running all my tests.
>
> Thing is that, while starting up mandos server with the init script,
> I obtained the following error:
>
> --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
> ERROR: Introspect error on org.freedesktop.Avahi:/: \
> dbus.exceptions.DBusException: org.freedesktop.DBus.Error.Spawn.FileInvalid: \
> Cannot do system-bus activation with no user
> --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
>
> I asked myself why was mandos trying to communicate with Avahi if
> I have configured zeroconf to be false? I then tried to manually
> run the service like this:
>
> mandos --no-zeroconf
>
> This time the service started up correctly.
>
> Taking a look around I ended up on the options parsing section of
> /usr/sbin/mandos. Seems like zeroconf option is missing there,
> therefore, not matter True or False, service will be always trying
> to use zeroconf, as the default value is True.
>
> --- mandos.orig   2017-02-20 15:11:40.228977179 +0100
> +++ mandos2017-02-20 15:12:18.381015090 +0100
> @@ -2370,7 +2370,7 @@
>  # Convert the SafeConfigParser object to a dict
>  server_settings = server_config.defaults()
>  # Use the appropriate methods on the non-string config options
> -for option in ("debug", "use_dbus", "use_ipv6", "foreground"):
> +for option in ("debug", "use_dbus", "use_ipv6", "foreground", 
> "zeroconf"):
>  server_settings[option] = server_config.getboolean("DEFAULT",
> option)
>  if server_settings["port"]:
>
> With this little modification, things started to work as expected.
>
> I've also looked to the sid package as well, and seems to be having
> the same issue.
>
> Many thanks in advance for taking care of this.

Many thanks for the bug report and fix!  It seems the "restore" options
was also affected by the same bug.  I have committed a fix to trunk; I
will make a full release with this after I have made some tests.

/Teddy Hogeborn

-- 
The Mandos Project
https://www.recompile.se/mandos


signature.asc
Description: PGP signature

Bug#847594: ACCOUNT_KEY_JSON: unbound variable

[Teddy Hogeborn]

Package: letsencrypt.sh
Version: 0.3.0-1~bpo8+1
Severity: grave
Tags: patch
Justification: renders package unusable

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?

I installed letsencrypt.sh version 0.3.0-1~bpo8+1.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

I ran "letsencrypt --cron" as root.

   * What was the outcome of this action?

/usr/bin/letsencrypt.sh: line 179: ACCOUNT_KEY_JSON: unbound variable

   * What outcome did you expect instead?

A successful run.

There is a typo on line 179; the $ and { characters seem to be
transposed.  Patch included.

/Teddy Hogeborn

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: 8.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/16 CPU cores)
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages letsencrypt.sh depends on:
ii  ca-certificates  20141019+deb8u2
ii  curl 7.38.0-4+deb8u5
ii  openssl  1.0.1t-1+deb8u5

letsencrypt.sh recommends no packages.

letsencrypt.sh suggests no packages.

-- no debconf information

-- debsums errors found:
debsums: changed file /usr/bin/letsencrypt.sh (from letsencrypt.sh package)
--- /usr/bin/letsencrypt.sh.~1~	2016-12-08 15:24:46.0 +0100
+++ /usr/bin/letsencrypt.sh	2016-12-09 18:23:08.306160178 +0100
@@ -176,7 +176,7 @@
   fi
   if [[ -f "${ACCOUNT_KEY_JSON:-"${BASEDIR}/private_key.json"}" ]] && [[ ! -f "${new_ACCOUNT_KEY_JSON}" ]]; then
 echo "! Moving private_key.json to ${new_ACCOUNT_KEY_JSON}"
-mv -v "{$ACCOUNT_KEY_JSON:-"${BASEDIR}/private_key.json"}" "${new_ACCOUNT_KEY_JSON}"
+mv -v "${ACCOUNT_KEY_JSON:-"${BASEDIR}/private_key.json"}" "${new_ACCOUNT_KEY_JSON}"
   fi
   ACCOUNT_KEY="${new_ACCOUNT_KEY}"
   ACCOUNT_KEY_JSON="${new_ACCOUNT_KEY_JSON}"

Bug#819982: mandos-client: bad gpgme_op_decrypt: GPGME: Decryption failed.

[Teddy Hogeborn]

Felix Koop <f...@fkoop.de> writes:

> > The photo actually does contain *some* more information about the error,
> > but it is not very helpful:
> > 
> > Trying to decrypt OpenPGP data
> > bad gpgme_op_decrypt: GPGME: Decryption failed
> > Unsupported algorithm: (null)
> > Wrong key usage: 0
> > Public key algorithm: RSA
> > Key ID: F8118489CABEB18B
> > Secret key available: Yes

I've done some searching, and it seems that this error can, due to a bug
<https://bugs.gnupg.org/gnupg/issue1020> also be reported when the
private key is not available.  However, I'm not sure how this could be
the case here, since the client should abort if it failed to import the
private key from the seckey.txt file.

> > So I'm guessing that the key ID for the client is F8118489CABEB18B?
> > This should be what the fingerprint should end with in the
> > client.conf file on the server, at least.
> 
> That was not the case. But when trying to fix the problem I upgraded
> the mandos-client package to the testing version. To have again a
> clean system, I purged everything related to mandos and reinstalled. I
> get the same error (photo attached, other key ID, of course). The Key
> ID on the photo B76C46544768EBD7 is different from what I have as
> fingerprint in the client.conf file (content also deleted and newly
> generated configuration inserted):
>
> fingerprint = 7BB742A419FA7D4436BC68E5AB68E8FF70C4627B

Is the key in the error message possibly the subkey ID?  I don't know.
Even if it was, I don't know how it would help.

> If that matters: The server is an ubuntu wily system with mandos
> 1.7.0-1.

We always recommend using the latest released version of Mandos, but I
can see no change which would fix this bug in any later version.

> New listing attached.

Nothing new there, except you seem to have switched from Mandos 1.7.2 or
later to 1.7.1 or earlier, and from Debian unstable to stable.

> > > > 3. Boot your system with the additional kernel command line
> > > >argument "break".  This will start an emergency shell.
> > > >First, run the command
> > > > 
> > > > chmod a=rwxt /tmp
> > > > 
> > > >Then you should be able to run the /lib/mandos/plugin-runner
> > > >program, and by running the command multiple times you should
> > > >be able to debug the problem.  Also, the output of the
> > > >"gpgconf" command in this mode should be informative,
> > > >especially compared to its output when run in the normal
> > > >system.
> > > 
> > > I don't get the emergency shell, but a kernel panic instead. Then
> > > the system reboots. This continues.
> > 
> > Right.  I suggest you take that up with the initramfs-tools
> > maintainer.

I think this is the only way forward - find out why it doesn't work in
the initramfs by actually debugging it interactively in the initramfs.

You could try one of these kernel command line parameters (listed in
order of preference) instead of simple "break":

break=mount
break=premount
break=modules
break=top

> > Can you reproduce the problem by unpacking the initramfs (as above),
> > chrooting into it, and running the mandos-client from inside it?
>
> Done:
>
> Mandos plugin mandos-client: Trying to decrypt OpenPGP data
> Mandos plugin mandos-client: Decryption of OpenPGP data succeeded
> Mandos plugin mandos-client: Decrypted password is:  
[…]
> 
>
> So there it is, the correct password. Everything seems to run fine in
> the chroot.
>
> Any idea what else to check?

The only way to even reproduce the problem seems to run in the actual
initramfs environment.  When you try to enter an interactive shell in
that environment, you get a kernel panic.  This could be an indication
of a larger problem with your initramfs environment, and since we can't
even reproduce the problem outside this environment, I don't know what
else to do at this point.  I would try to fiddle with it to get an
emergency initramfs shell to work - it seems to be the only alternative
at this point.

/Teddy Hogeborn

-- 
The Mandos Project
https://www.recompile.se/mandos


signature.asc
Description: PGP signature

Bug#819982: mandos-client: bad gpgme_op_decrypt: GPGME: Decryption failed.

[Teddy Hogeborn]

tags 819982 + unreproducible
quit

Felix Koop <f...@fkoop.de> writes:

> > Teddy Hogeborn <te...@recompile.se> hat am 5. April 2016 um 10:12 
> > geschrieben:
> > 
> > So the client works in the normal system but fails in the initrd?
> > That is odd.  I have a few suggestions to gather more data to help
> > with debugging:
> > 
> > 1. Uncomment the line in /etc/mandos/plugin-runner.conf which says
> >"--options-for=mandos-client:--debug", and rebuild the initramfs
> >image with "update-initramfs -k all -u".  When booting, the
> >Mandos client should now output debug information, including more
> >details about the error you reported.
> > 
> I don't see any more specific error, but I have attached a photo of
> the boot process when the error happens (hope that helps).

The photo actually does contain *some* more information about the error,
but it is not very helpful:

Trying to decrypt OpenPGP data
bad gpgme_op_decrypt: GPGME: Decryption failed
Unsupported algorithm: (null)
Wrong key usage: 0
Public key algorithm: RSA
Key ID: F8118489CABEB18B
Secret key available: Yes

So I'm guessing that the key ID for the client is F8118489CABEB18B?
This should be what the fingerprint should end with in the client.conf
file on the server, at least.

> > 2. Unpack the initramfs image and list the files it contains -
> >perhaps it is missing something important for some odd reason.
> >This is most easily done by running the "initramfs-unpack" script
> >from the Mandos source tree, which will unpack all initramfs
> >images to /tmp.  The script file is available here:
> > 
> >   
> > <http://bzr.recompile.se/loggerhead/mandos/trunk/view/head:/initramfs-unpack>.
> 
> Listing is attached.

You do have some *extra* stuff in your initramfs image compared to what
I have on Debian stable, but nothing seems to be *missing*.

> > 3. Boot your system with the additional kernel command line argument
> >"break".  This will start an emergency shell.  First, run the
> >command
> > 
> > chmod a=rwxt /tmp
> > 
> >Then you should be able to run the /lib/mandos/plugin-runner
> >program, and by running the command multiple times you should be
> >able to debug the problem.  Also, the output of the "gpgconf"
> >command in this mode should be informative, especially compared
> >to its output when run in the normal system.
>
> I don't get the emergency shell, but a kernel panic instead. Then the
> system reboots. This continues.

Right.  I suggest you take that up with the initramfs-tools maintainer.

Can you reproduce the problem by unpacking the initramfs (as above),
chrooting into it, and running the mandos-client from inside it?

/Teddy Hogeborn

-- 
The Mandos Project
https://www.recompile.se/mandos

Bug#819982: mandos-client: bad gpgme_op_decrypt: GPGME: Decryption failed.

[Teddy Hogeborn]

Felix Koop <f...@fkoop.de> writes:

> when booting the client I get the following error message:
>
> bad gpgme_op_decrypt: GPGME: Decryption failed.
>
> I installed mandos-client and created the key on the client. Then
> included the resulting text in the clients.conf file on the server.
> Testing the key with the procedure described in the README file works
> flawlessly. When booting, I have to enter the key manually as
> I only get the above mentioned error message.
>
> Do you need any additional information?

So the client works in the normal system but fails in the initrd?  That
is odd.  I have a few suggestions to gather more data to help with
debugging:

1. Uncomment the line in /etc/mandos/plugin-runner.conf which says
   "--options-for=mandos-client:--debug", and rebuild the initramfs
   image with "update-initramfs -k all -u".  When booting, the Mandos
   client should now output debug information, including more details
   about the error you reported.

2. Unpack the initramfs image and list the files it contains - perhaps
   it is missing something important for some odd reason.  This is most
   easily done by running the "initramfs-unpack" script from the Mandos
   source tree, which will unpack all initramfs images to /tmp.  The
   script file is available here:
   
<http://bzr.recompile.se/loggerhead/mandos/trunk/view/head:/initramfs-unpack>.

3. Boot your system with the additional kernel command line argument
   "break".  This will start an emergency shell.  First, run the command

chmod a=rwxt /tmp

   Then you should be able to run the /lib/mandos/plugin-runner program,
   and by running the command multiple times you should be able to debug
   the problem.  Also, the output of the "gpgconf" command in this mode
   should be informative, especially compared to its output when run in
   the normal system.

/Teddy Hogeborn

-- 
The Mandos Project
https://www.recompile.se/mandos


signature.asc
Description: PGP signature

Bug#813138: python-gnutls: Still depends on libgnutls-deb0-28 instead of libgnutls30

[Teddy Hogeborn]

peter green <plugw...@p10link.net> writes:

> > even after a binNMU python-gnutls still depends on libgnutls-deb0-28
> > as it does not make use of the shlibs system. Please upgrade to use
> > GnuTLS 3.4
> 
> It's easy enough to change the gnutls version to 30 and update the
> package dependencies.
>
> Unfortunately after doing so the code doesn't work. I get loads of
> errors trying to import functions that no longer exist, I tried to
> remove/fix these imports but I still couldn't get the examples in the
> package to work.
>
> ccing the maintainers of mandos which seems to be the only reverse
> dependency of this package.

In Mandos, it was easy enough to forgo the use of the python-gnutls
module entirely and simply write our own pseudo-module which calls the
GnuTLS library direcly through ctypes, so that's what we did.

On the other hand, there seems to be some upstream activity -
Python-GnuTLS 3.0.0 was released on March 9th, claiming to support
GnuTLS 3.2 and later.

/Teddy Hogeborn

-- 
The Mandos Project
https://www.recompile.se/mandos


signature.asc
Description: PGP signature

Bug#816513: Call to configure_network in initramfs script broken due to set -e

[Teddy Hogeborn]

Ben Hutchings <b...@decadent.org.uk> writes:

> On Wed, 2016-03-02 at 14:19 +0100, Carlos Alberto Lopez Perez wrote:
> [...]
> > A possible fix is the following patch:
> > 
> > --- a/usr/share/initramfs-tools/scripts/init-premount/mandos
> > 2016-03-02 10:41:43.437960673 +0100
> > +++ b/usr/share/initramfs-tools/scripts/init-premount/mandos
> > 2016-03-02 13:00:27.392153826 +0100
> > @@ -94,7 +94,7 @@
> >  # If we are connecting directly, run "configure_networking" (from
> >  # /scripts/functions); it needs IPOPTS and DEVICE
> >  if [ "${connect+set}" = set ]; then
> > -configure_networking
> > +configure_networking || true
> [...]
>
> Why not:
>
>      set +e  # required by library functions
>      configure_networking
>      set -e

Thank you both.  Fixed in trunk.

/Teddy Hogeborn

-- 
The Mandos Project
http://www.recompile.se/mandos


signature.asc
Description: PGP signature

Bug#804869: vsftpd: OOPS: 421 Service not available, remote server has closed connection

[Teddy Hogeborn]

Jörg Frings-Fürst  writes:

> please test this workaround from the FAQ:
>
> Add
>
> isolate_network=NO
>
> to your vsftpd.conf file

I already have that.

/Teddy

Bug#804869: vsftpd: OOPS: 421 Service not available, remote server has closed connection

[Teddy Hogeborn]

reopen 804869
stop

Jörg Frings-Fürst  writes:

> I have test it again with your notes (NIS user) and I also can't
> reproduce the error.

Well, *I* can reliably reproduce the bug.  Detail: I log in using FTP
using the same user which exists only in NIS, which works.  But listing
a directory with files owned by the same user and group causes "OOPS:
421 Service not available".  If I manually add the user and group to the
local /etc/passwd and /etc/group files, the directory listing succeeds.

(It does not matter if I start vsftpd from inetd.conf or run it
standalone.)

I just retried with vsftpd 3.0.3-2.  Same.

Reopening.

/Teddy

Bug#804869: vsftpd: OOPS: 421 Service not available, remote server has closed connection

[Teddy Hogeborn]

Jörg Frings-Fürst  writes:

> I have test the access with 100.000 files and 5 clients with no errors.
>
> Can you tell me your circumstances that led to the error?

The "OOPS: 421" error happens when vsftpd has "seccomp_sandbox=YES" and
it tries to show a directory containing a file owned by a user that
exists only via NIS, not in the local passwd file.

I can no longer reproduce any error with large directories.

/Teddy


signature.asc
Description: PGP signature

Bug#804869: vsftpd: OOPS: 421 Service not available, remote server has closed connection

[Teddy Hogeborn]

Jörg Frings-Fürst <deb...@jff-webhosting.net> writes:

> tags 804869 + moreinfo
> thanks
> Please can you test the release 3.0.3-1 from testing/unstable with
> enabled seccom sandbox?

Yes, the bug is still present.

/Teddy Hogeborn

Bug#804869: vsftpd: OOPS: 421 Service not available, remote server has closed connection

[Teddy Hogeborn]

Package: vsftpd
Version: 3.0.2-17
Severity: important
Tags: upstream

Dear Maintainer,

When trying to list a large directory, the server instead says "OOPS:
421 Service not available, remote server has closed connection", or
sometimes "OOPS:  priv_sock_get_cmd".  This is exactly Red Hat Bug
845980 , and the
fix discussed at that page (setting seccomp_sandbox=NO) does indeed
fix the problem.

/Teddy

-- Package-specific info:

-- System Information:
Debian Release: 8.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages vsftpd depends on:
ii  adduser3.113+nmu3
ii  debconf [debconf-2.0]  1.5.56
ii  dialog 1.2-20140911-1
ii  init-system-helpers1.22
ii  libc6  2.19-18+deb8u1
ii  libcap21:2.24-8
ii  libpam-modules 1.1.8-3.1
ii  libpam0g   1.1.8-3.1
ii  libssl1.0.01.0.1k-3+deb8u1
ii  libwrap0   7.6.q-25
ii  netbase5.3

Versions of packages vsftpd recommends:
ii  logrotate  3.8.7-1+b1
ii  ssl-cert   1.0.35

vsftpd suggests no packages.

-- Configuration Files:
/etc/vsftpd.conf changed [not included]

-- debconf information:
* vsftpd/directory: /srv/ftp
* vsftpd/username: ftp

Bug#787758: 'Failed at step NAMESPACE spawning'when using ReadOnlyDirectories in multi-instance service file

[Teddy Hogeborn]

tags 787758 +patch +fixed-upstream
stop

I think this is an instance of Red Hat Bug #1184016, here:

https://bugzilla.redhat.com/show_bug.cgi?id=1184016

A pair of upstream patches is given in comment #33 by Michal Schmidt:

http://cgit.freedesktop.org/systemd/systemd/commit/?id=2230852bd9755e1b7bfd1260082471f559b0a005
http://cgit.freedesktop.org/systemd/systemd/commit/?id=a0827e2b123010c46cfe4f03eebba57d92f9efc4

/Teddy Hogeborn

Bug#799355: emacs-goodies-el: apache-mode has incorrect highlighting

[Teddy Hogeborn]

Package: emacs-goodies-el
Version: 35.12
Severity: minor
Tags: upstream

The apache-mode.el has incorrect highlighting; it highlights the word
"temporary" when in fact the correct syntax for Apache is "temp".
(See line 563 in apache-mode.el.)

-- System Information:
Debian Release: 7.9
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable-proposed-updates'), 
(500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages emacs-goodies-el depends on:
ii  bash   4.2+dfsg-0.1+deb7u3
ii  dpkg   1.16.16
ii  emacs23 [emacsen]  23.4+1-4
ii  install-info   4.13a.dfsg.1-10

Versions of packages emacs-goodies-el recommends:
pn  dict  
ii  perl-doc  5.14.2-21+deb7u2
ii  wget  1.13.4-3+deb7u2

emacs-goodies-el suggests no packages.

-- no debconf information

Bug#720081: Install file trigger for /usr/share/initramfs-tools

[Teddy Hogeborn]

Thomas Lange la...@informatik.uni-koeln.de wrote:

 I think the proper way is to add a dracut trigger to all packages
 that may add some stuff to initrd whether this is generated by
 initramfs-tools or dracut.

How would such a trigger look like?  The default dracut command
without arguments won't work, because that creates an initramfs image
with the wrong file name (initramfs-* instead of initrd.img-*).  There
is code in /etc/kernel/postinst.d/dracut to use the correct name but
that code is for one initramfs image only, and gets the kernel version
to build for free as arguments to itself.  Initramfs-tools had the
option -k all to rebuild all existing initramfs images.  What would be
the corresponding command for dracut?  I.e. what would such a dracut
trigger that you mention look like?

/Teddy Hogeborn

-- 
The Mandos Project
http://www.recompile.se/mandos

Bug#719740: dracut does not boot with an encrypted hard disk

[Teddy Hogeborn]

I noticed (with dracut 040+1-1) that I can make encrypted disks just
work (and without the annoying repeating password questions you get with
rd.auto=1) *IF* I configure dracut to use hostonly mode (hostonly=yes in
/etc/dracut.conf).

I also note that there's a separate wishlist bug (#752660) to make
hostonly mode the default, like other distributions do.

/Teddy Hogeborn

-- 
The Mandos Project
http://www.recompile.se/mandos

Bug#767013: RFP: mstpd -- A daemon implementing the RSTP (Rapid Spanning Tree Protocol) protocol for bridges

[Teddy Hogeborn]

Package: wnpp
Severity: wishlist

* Package name: mstpd
  Version : 0.0.3
  Upstream Author : Srinivas Aji aji_srini...@emc.com
* URL : http://sourceforge.net/projects/mstpd/
* License : GPLv2
  Programming Lang: C
  Description : A daemon implementing the RSTP (Rapid Spanning Tree 
Protocol) protocol for bridges

STP (Spanning Tree Protocol) is implemented by Linux's bridge module,
but it's very old and slow.  RTSP (Rapid Spanning Tree Protocol) is
much better, but is not in Linux yet.  This daemon implements RSTP.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#764258: mandos-client loops forever waiting for server

[Teddy Hogeborn]

Private correspondence with the initial bug reporter has determined that
this bug is a duplicate of bug #764034, so this bug has been merged with
that one.

/Teddy Hogeborn

-- 
The Mandos Project
http://www.recompile.se/mandos


pgpEOSBL58R1i.pgp
Description: PGP signature

Bug#764258: mandos-client loops forever waiting for server

[Teddy Hogeborn]

C. Dominik Bódi dominik.b...@gmx.de writes:

 mandos-client stopped working after having updated to mandos-client
 1.6.9-1.

 Running the client as described in READE.Debian.gz, with --debug
 enabled shows that the client actually seems to communicate with the
 server, but then shows the following debug messages:

 Mandos plugin mandos-client: Check current_server if we should run it, or wait
 Mandos plugin mandos-client: Blocking for 1 ms

 It then waits for 10 seconds, talks with the server again, shows the
 same waiting message again and thus loops around forever.

 The mandos-monitor on the server never says that the client received
 its secret, though. The server runs 1.6.9-1 , as well.

I think I know what the problem is.  The server and client do not run
the same release of Debian, right?  Does the mandos-client --debug
output include this?

Mandos plugin mandos-client: *** GnuTLS Handshake failed ***
GnuTLS error: An unknown public key algorithm was encountered.

As we wrote in the release announcement for Mandos 1.6.9[1], Debian is
transitioning from one major version of GnuTLS to a newer one[2][3], and
the GnuTLS versions are *not* compatible when used in the way Mandos
uses them.  Therefore, Mandos running on Debian jessie/unstable/sid
*cannot* give or receive passwords to or from Debian wheezy/stable, even
if the Mandos is backported to be the same version.  Unfortunately, we
cannot do anything about this.  The way we heard it, this is essentially
an unavoidable incompatible change in GnuTLS, and we'll all just have to
hold our breaths until we emerge on the other side of the transition.

If this is *not* the problem, please give some more details.
Specifically, you could run mandos-monitor on the server and see if
any log messages show up when the client connects.

1) http://mail.recompile.se/pipermail/mandos-dev/2014-October/000305.html
2) https://release.debian.org/transitions/html/gnutls28.html
3) https://wiki.debian.org/gnutls3

/Teddy Hogeborn

-- 
The Mandos Project
http://www.recompile.se/mandos


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#762349: mandos: still uses GnutLS 2.x

[Teddy Hogeborn]

Andreas Metzler ametz...@bebt.de writes:

 python-gnutls has now been fixed, with the attached trivial patch mandos
 builds successfully.

  * GnuTLS v3 transition. Update b-d to libgnutls28-dev, version
  python-gnutls dependency. Closes: #762349

I am confused by your patch.  Didn't you say that Jessie would not
contain libgnutls26?  In that case, why change the Build-Depends from
libgnutls-dev to libgnutls28-dev?  Mandos will work with either, and
when libgnutls26 is removed, libgnutls-dev will be libgnutls28-dev, and
everything will be fine.

(The reason I am loathe to change this is that I would like to be
build-compatible with wheezy when possible.  This makes it easier for
those running wheezy, like, say, server operators not wanting to upgrade
to a new Debian release right away.  And server operators are the
principal users of Mandos.)

The change which the patch makes to the Depends line for the mandos
package baffles me even more; the mandos binary package does not
depend on any specific version of python-gnutls, it uses what's
available, and runs well with either.

/Teddy Hogeborn

-- 
The Mandos Project
http://www.recompile.se/mandos


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#762349: mandos: still uses GnutLS 2.x

[Teddy Hogeborn]

Andreas Metzler ametz...@bebt.de writes:

  I am confused by your patch.  Didn't you say that Jessie would not
  contain libgnutls26?  In that case, why change the Build-Depends
  from libgnutls-dev to libgnutls28-dev?  Mandos will work with
  either, and when libgnutls26 is removed, libgnutls-dev will be
  libgnutls28-dev, and everything will be fine.

 This not going to happen. libgnutls-dev will simply be removed. It
 will not be taken over by gnutls28.

I see.  What do you say about build-depending on libgnutls28-dev |
libgnutls-dev?  Or perhaps libgnutls28-dev | gnutls-dev?  I am
leaning towards the latter.

/Teddy Hogeborn

-- 
The Mandos Project
http://www.recompile.se/mandos


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#764034: python-gnutls: GnuTLS OpenPGP functions not in gnutls.library.functions

[Teddy Hogeborn]

Package: python-gnutls
Version: 2.0.1-1
Severity: normal
Tags: patch upstream

In gnutls/library/functions.py, line 1401, it tries to access the C
library function gnutls_certificate_get_openpgp_key, to determine if
the OpenPGP functions are present in the library.  (This is a change
from the old code for the old GnuTLS library, which tried to access
gnutls_certificate_get_openpgp_keyring instead, but that function
has been removed in the new GnuTLS library, so the change was
necessary.)  The problem is that the function accessed, called
gnutls_certificate_get_openpgp_key, does not exist, and has never
existed in any version of GnuTLS I could find.  Therefore, the code in
functions.py determines that OpenPGP support is not present and does
not import the needed functions from the C library.  By reading the
following code in functions.py, and comparing with the old version, I
am pretty sure that what was actually meant was instead the function
gnutls_certificate_set_openpgp_key.  Indeed, when changed to that,
the functions in the Python module are present, callable and working.

/Teddy Hogeborn

-- 
The Mandos Project
http://www.recompile.se/mandos

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'oldstable'), (50, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.14-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages python-gnutls depends on:
ii  libgnutls-deb0-28  3.3.8-2
ii  python 2.7.8-1

Versions of packages python-gnutls recommends:
ii  python-twisted-core  14.0.2-2

python-gnutls suggests no packages.

-- no debconf information

-- debsums errors found:
debsums: changed file 
/usr/lib/python2.7/dist-packages/gnutls/library/functions.py (from 
python-gnutls package)
--- gnutls/library/functions.py.~1~	2014-06-26 18:01:34.0 +0200
+++ gnutls/library/functions.py	2014-10-05 02:19:39.424176013 +0200
@@ -1398,7 +1398,7 @@
 #
 
 try:
-gnutls_certificate_get_openpgp_key = libgnutls.gnutls_certificate_get_openpgp_key
+gnutls_certificate_set_openpgp_key = libgnutls.gnutls_certificate_set_openpgp_key
 except AttributeError:
 pass
 else:

Bug#762760: bash: still vulnerable to environment exploits

[Teddy Hogeborn]

tags 762760 +patch
stop

Chet Ramey has posted a patch for this (also attached):

http://www.openwall.com/lists/oss-security/2014/09/25/10

/Teddy Hogeborn
*** ../bash-20140912/parse.y	2014-08-26 15:09:42.0 -0400
--- parse.y	2014-09-24 22:47:28.0 -0400
***
*** 2959,2962 
--- 2959,2964 
word_desc_to_read = (WORD_DESC *)NULL;
  
+   eol_ungetc_lookahead = 0;
+ 
current_token = '\n';		/* XXX */
last_read_token = '\n';

Bug#750516: Fwd: Re: Bug#750516: mandos: FTBFS with clang instead of gcc

[Teddy Hogeborn]

Sylvestre Ledru sylves...@debian.org writes:

 Nested functions are NOT part of the C and C++ standard:
 http://en.wikipedia.org/wiki/Nested_function#Languages

 The gcc support is a mistake.

Nested functions is an official GCC extension:

https://gcc.gnu.org/onlinedocs/gcc-4.9.0/gcc/Nested-Functions.html

/Teddy

-- 
The Mandos Project
http://www.recompile.se/mandos


pgp7dhfJ6GGvu.pgp
Description: PGP signature

Bug#750516: mandos: FTBFS with clang instead of gcc

[Teddy Hogeborn]

Sylvestre Ledru sylves...@debian.org writes:

   Nested functions are NOT part of the C and C++ standard:
   http://en.wikipedia.org/wiki/Nested_function#Languages
  
   The gcc support is a mistake.
  
  Nested functions is an official GCC extension:
  
  https://gcc.gnu.org/onlinedocs/gcc-4.9.0/gcc/Nested-Functions.html
 
 Yes. It has been implemented as a side effect of the ADA support in gcc
 (just like Variable Length Array).

That may be the historical reason for its existence, but, for as long as
it is documented, it is an officially supported extension by GCC.

 It is not because gcc supports it that it is standard C...

This is true, it is not standard C; ANSI or otherwise.

 Arthur's patch is doing the correct implementation (static function in
 the same object file).

The correct implementation?  We have, in our program, chosen to use
many non-standardized extensions: We use Linux-specific features and not
only those of the POSIX kernel functions.  We use GLibc-specific
features and not only those of the POSIX standard library.  We also, as
you have noticed, use features specific to GCC and not only those of the
ANSI C standard.  Is this not correct?

/Teddy Hogeborn

-- 
The Mandos Project
http://www.recompile.se/mandos


pgpJPoqEpf312.pgp
Description: PGP signature

Bug#633582: initramfs-tools: All files in initrd owned by root

[Teddy Hogeborn]

intrigeri intrig...@boum.org writes:

 Michael Prokop wrote (23 Nov 2011 11:45:14 GMT) :
 
  maximilian: i've scheduled the patch for inclusion via
  mika/user_permissions.

 Was this included eventually?

No.

We have, for two years now, a very ugly workaround in mandos-client
to deal with this.

/Teddy Hogeborn

-- 
The Mandos Project
http://www.recompile.se/mandos


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#736282: RFS: mandos/1.6.3-1 [RC] -- do unattended reboots with an encrypted root file system

[Teddy Hogeborn]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package mandos

* Package name: mandos
  Version : 1.6.3-1
  Upstream Author : Mandos Maintainers man...@recompile.se
* URL : http://www.recompile.se/mandos
* License : GPL-3+
  Section : admin

It builds those binary packages:

mandos - server giving encrypted passwords to Mandos clients
mandos-client - do unattended reboots with an encrypted root file system

To access further information about this package, please visit the
following URL:

http://mentors.debian.net/package/mandos


Alternatively, one can download the package with dget using this
command:

dget -x 
http://mentors.debian.net/debian/pool/main/m/mandos/mandos_1.6.3-1.dsc

More information about Mandos can be obtained from
http://www.recompile.se/mandos

Changes since the last upload:

Last upload was 1.6.0-1, and since then a number of bugs have been
fixed in non-uploaded versions:  1.6.1 fixed #690639 and #721903, and
1.6.2 fixed #702120.  These account for all bugs in the Debian BTS.

Since our previous sponsor can no longer sponsor us, we would
appreciate a new regular sponsor for the forseeable future.

Regards,
 Teddy Hogeborn

-- 
The Mandos Project
http://www.recompile.se/mandos


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#733464: netpbm: pamdice(1) synopsis has program name as pamslice

[Teddy Hogeborn]

Package: netpbm
Version: 2:10.0-15+b1
Severity: minor
Tags: fixed-upstream


NAME
   pamdice - slice a Netpbm image into many horizontally and/or vertically

SYNOPSIS
   pamslice  -outstem=filenamestem  [-width=width] [-height=height] [-ver‐
   bose] [filename]


Note the naming inconsistency; pamdice/pamslice.

/Teddy

-- System Information:
Debian Release: 7.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/16 CPU cores)
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages netpbm depends on:
ii  libc62.13-38+deb7u1
ii  libjpeg8 8d-1
ii  libnetpbm10  2:10.0-15+b1
ii  libpng12-0   1.2.49-1
ii  libtiff4 3.9.6-11
ii  zlib1g   1:1.2.7.dfsg-13

Versions of packages netpbm recommends:
ii  ghostscript  9.05~dfsg-6.3+deb7u1

netpbm suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#725792: opendnssec: Tab characters in TXT (and SRV) records data makes signer ignore those records

[Teddy Hogeborn]

Package: opendnssec
Version: 1.3.2-1~bpo60+1
Severity: normal

A normal SPF (or legacy TXT) record starts with the prefix v=spf1,
followed by a space character.  If this space character is
accidentally replaced with a TAB character (ASCII 0x09), the
OpenDNSSEC signer ignores the record, and it is not present in the
signed zone.

-- System Information:
Debian Release: 6.0.7
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable-proposed-updates'), 
(500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages opendnssec depends on:
ii  libhsm-bin   1.3.2-1~bpo60+1 library for interfacing PKCS#11 Ha
ii  opendnssec-common1.3.2-1~bpo60+1 common configuration files for Ope
ii  opendnssec-enforcer  1.3.2-1~bpo60+1 tool to prepare DNSSEC keys (commo
ii  opendnssec-enforcer-sqli 1.3.2-1~bpo60+1 tool to prepare DNSSEC keys (sqlit
ii  opendnssec-signer1.3.2-1~bpo60+1 daemon to sign DNS zone files peri

Versions of packages opendnssec recommends:
ii  opendnssec-auditor   1.3.2-1~bpo60+1 tool to audit DNS signed zones acc

Versions of packages opendnssec suggests:
ii  softhsm  1.3.0-1~bpo60+1 a cryptographic store accessible t

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#702120: mandos: Mandos/gnutls fails to establish connection, an algorithm that is not enabled was negotiated

[Teddy Hogeborn]

Félix Sipma felix+deb...@gueux.org writes:

 I do not see this bug anymore (no need to set
 priority = SECURE256:!CTYPE-X.509:+CTYPE-OPENPGP:+SIGN-RSA-SHA224
 in /etc/mandos/mandos.conf).

 So, this bug may be closed, at least on sid... But I would be nice to
 understand why it works now :-)

The source of these problems is entirely GnuTLS - it seems it has issues
connecting with SECURE256, especially using OpenPGP keys, and
*particularly* when that key is a DSA key with an Elgamal subkey.  As I
recall, the few times I have had a bit of time to test it I've only
gotten confusing results.  I will have to do some more tests in my
copious spare time.

/Teddy Hogeborn

-- 
The Mandos Project
http://www.recompile.se/mandos


pgpJcDij3sBGl.pgp
Description: PGP signature

Bug#702120: mandos: Mandos/gnutls fails to establish connection, an algorithm that is not enabled was negotiated

[Teddy Hogeborn]

Uncommenting the priority setting in mandos.conf and appending
:+SIGN-RSA-SHA224 makes it work; i.e. this line should be present in
/etc/mandos.conf:

priority = SECURE256:!CTYPE-X.509:+CTYPE-OPENPGP:+SIGN-RSA-SHA224

I wish I knew why this works - I arrived at this by trial and error.
I'm suspecting a GnuTLS regression with SECURE256 and CTYPE-OPENPGP.

Note: The clients need no changes.

/Teddy Hogeborn

-- 
The Mandos Project
http://www.recompile.se/mandos


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#702120: mandos: Mandos/gnutls fails to establish connection, an algorithm that is not enabled was negotiated

[Teddy Hogeborn]

Teddy Hogeborn te...@recompile.se writes:

 Uncommenting the priority setting in mandos.conf and appending
 :+SIGN-RSA-SHA224 makes it work; i.e. this line should be present in
 /etc/mandos.conf:

 priority = SECURE256:!CTYPE-X.509:+CTYPE-OPENPGP:+SIGN-RSA-SHA224

I meant, of course, /etc/mandos/mandos.conf.

/Teddy Hogeborn

-- 
The Mandos Project
http://www.recompile.se/mandos


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#682472: unblock: mandos/1.6.0-1

[Teddy Hogeborn]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock


Please unblock package mandos

We released Mandos version 1.6.0 well in advance of the anticipated
Debian freeze, and have been using it ourselves since then, but our
sponsor did not upload it with his usual promptness.  This release has
a very nice labor-saving autodetection feature for the client side
(clients most likely won't need any configuration anymore), and no
other incompatible changes since 1.5.5, but many packaging fixes.
Also, our popcon count is rather low: 11 for mandos and 14 for
mandos-client, and about half of those are our own systems.

Could you *please* consider including this release in wheezy?  We, the
upstream and uploaders of Mandos, feel that we did everything we could
for 1.6.0 to be included in wheezy, and that we are the victims of
circumstances outside our control (viz. that our sponsor, Daniel
Baumann, was late uploading it because of his being traveling due to
Debconf).

This configuration-less client feature is our last nice feature we
once dreamed of being able to provide for our users; future releases
of the package will consist mainly of minor polish to other parts, but
no features are missing.  Please make our dream come true?

unblock mandos/1.6.0-1

-- System Information:
Debian Release: 6.0.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.38-bpo.2-amd64 (SMP w/16 CPU cores)
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#651865: python-gnutls: gnutls.library.functions fails with libgnutls28-3.0.8-2

[Teddy Hogeborn]

Package: python-gnutls
Version: 1.2.0-2+b1
Severity: normal

python-gnutls 1.2.0-2 seems wholly incompatible with libgnutls28
3.0.8-2.

Steps to reproduce:
python -c import gnutls.library.functions

gives:
Traceback (most recent call last):
  File string, line 1, in module
  File /usr/lib/pymodules/python2.7/gnutls/library/__init__.py, line 133, in 
module
initialize_gcrypt()
  File /usr/lib/pymodules/python2.7/gnutls/library/__init__.py, line 117, in 
initialize_gcrypt
gcry_control = libgnutls.gcry_control
  File /usr/lib/python2.7/ctypes/__init__.py, line 378, in __getattr__
func = self.__getitem__(name)
  File /usr/lib/python2.7/ctypes/__init__.py, line 383, in __getitem__
func = self._FuncPtr((name_or_ordinal, self))
AttributeError: /usr/lib/x86_64-linux-gnu/libgnutls.so.28: undefined symbol: 
gcry_control

Python-gnutls finds libgnutls28 before it finds libgnutls26, which has
the gcry_control symbol it needs.

/Teddy Hogeborn

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'oldstable'), (50, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.1.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages python-gnutls depends on:
ii  libc6   2.13-22
ii  libgnutls26 2.12.14-4
ii  python  2.7.2-9
ii  python-support  1.0.14

Versions of packages python-gnutls recommends:
ii  python-twisted-core  11.0.0-2

python-gnutls suggests no packages.

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#651725: python-gobject: Segfault with multiprocessing and subprocess

[Teddy Hogeborn]

Package: python-gobject
Version: 3.0.2-4
Severity: normal
Tags: upstream

I can get an intermittent segfault when running, then interrupting
with Ctrl-C, the attached program.  The program uses the gobject main
loop as the only non-built-in Python module, so I report it here,
since I can't reproduce the problem without using the gobject main
loop.

The segfault is a bit tricky to reproduce, I have to be pretty fast
when pressing Ctrl-C after starting the program, and even then it
doesn't always happen.  But it is fairly repeatable with some
perseverance.

The attached program is a pared-down version of a much much larger
program which exibited the same behavior.

I also attach a backtrace obtained when running Python 2.7 in gdb.

The problem happens both with and without the from __future__
imports, and in all of python2.6, python2.7, and python3.2.

/Teddy Hogeborn


-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'oldstable'), (50, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.1.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages python-gobject depends on:
ii  python-gi 3.0.2-4
ii  python-gobject-2  2.28.6-8

python-gobject recommends no packages.

python-gobject suggests no packages.

-- no debconf information
#!/usr/bin/python
# -*- mode: python; coding: utf-8 -*-

#from __future__ import (division, absolute_import, print_function,
#unicode_literals)

import multiprocessing

try:
import gobject
except ImportError:
# Python 3 gobject package
from gi.repository import GObject as gobject

import subprocess

def main():
multiprocessing_manager = multiprocessing.Manager()
main_loop = gobject.MainLoop()

proc = subprocess.Popen(/bin/true)
gobject.child_watch_add(proc.pid, lambda pid, cond: None)

main_loop.run()

if __name__ == '__main__':
main()
$ gdb python
GNU gdb (GDB) 7.3-debian
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type show copying
and show warranty for details.
This GDB was configured as x86_64-linux-gnu.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /usr/bin/python...Reading symbols from /usr/lib/debug/usr/b
in/python2.7...done.
done. 
(gdb) handle SIGINT nostop print pass
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) y

SignalStop  Print   Pass to program Description
SIGINTNoYes Yes Interrupt
(gdb) run ./segfaultexample.py
Starting program: /usr/bin/python ./segfaultexample.py
[Thread debugging using libthread_db enabled]
[New Thread 0x74fda700 (LWP 7966)]
^C
Program received signal SIGINT, Interrupt.
Traceback (most recent call last):
  File ./segfaultexample.py, line 27, in module

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x74fda700 (LWP 7966)]
0x004267b4 in PyObject_Call (func=optimized out, arg=
('Failed to read from child watch wake up pipe: Interrupted system call',), 
kw=0x0) at ../Objects/abstract.c:2527
2527../Objects/abstract.c: No such file or directory.
in ../Objects/abstract.c
(gdb) bt
#0  0x004267b4 in PyObject_Call (func=optimized out, arg=
('Failed to read from child watch wake up pipe: Interrupted system call',), 
#1  0x00426877 in call_function_tail (callable=
built-in method match of _sre.SRE_Pattern object at remote 
0x77e2a108, args=
('Failed to read from child watch wake up pipe: Interrupted system call',))
at ../Objects/abstract.c:2561
#2  0x004296f8 in PyObject_CallMethod (o=optimized out, name=
0x5ffba5 match, format=0x554ac3 O) at ../Objects/abstract.c:2638
#3  0x0049e789 in check_matched (obj=optimized out, 
arg=optimized out) at ../Python/_warnings.c:25
#4  0x0049f09e in check_matched (arg=optimized out, 
obj=optimized out) at ../Python/_warnings.c:23
#5  get_filter (item=synthetic pointer, module='__main__', lineno=27, text=
'Failed to read from child watch wake up pipe: Interrupted system call', 
category=type at remote 0xa3a670) at ../Python/_warnings.c:145
#6  warn_explicit (category=type at remote 0xa3a670, message=
Warning at remote 0x750e1a00, filename='./segfaultexample.py', 
lineno=27, module='__main__', registry={}, sourceline=0x0)
at ../Python/_warnings.c:349
#7  0x0049f605 in do_warn (message=
'Failed to read from child watch wake up pipe: Interrupted system call', 
category=type at remote 0xa3a670, stack_level=optimized out)
at ../Python/_warnings.c:597
#8  0x0049f99d in PyErr_WarnEx

Bug#642926: ipsec-tools: Misspelling in libipsec/ipsec_strerror.[hc]: direciton should be direction

[Teddy Hogeborn]

Package: ipsec-tools
Version: 1:0.7.3-12
Severity: minor
Tags: patch

The EIPSEC_INVAL_DIR error has Invalid direciton as a string; it
should be Invalid direction.

/Teddy Hogeborn

-- System Information:
Debian Release: 6.0.2
  APT prefers proposed-updates
  APT policy: (500, 'proposed-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.38-bpo.2-686 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages ipsec-tools depends on:
ii  libc6   2.11.2-10Embedded GNU C Library: Shared lib
ii  libcomerr2  1.41.12-4stable1 common error description library
ii  libgssapi-krb5-21.8.3+dfsg-4squeeze2 MIT Kerberos runtime libraries - k
ii  libk5crypto31.8.3+dfsg-4squeeze2 MIT Kerberos runtime libraries - C
ii  libkrb5-3   1.8.3+dfsg-4squeeze2 MIT Kerberos runtime libraries
ii  libpam0g1.1.1-6.1Pluggable Authentication Modules l
ii  libssl0.9.8 0.9.8o-4squeeze2 SSL shared libraries

ipsec-tools recommends no packages.

ipsec-tools suggests no packages.

-- no debconf information
--- ipsec-tools-0.7.3//src/libipsec/ipsec_strerror.h.~1~2006-09-09 
18:22:09.0 +0200
+++ ipsec-tools-0.7.3//src/libipsec/ipsec_strerror.h2011-09-25 
19:18:37.0 +0200
@@ -54,7 +54,7 @@
 #define EIPSEC_INVAL_KEYLEN14  /*invalid key length*/
 #define EIPSEC_INVAL_FAMILY15  /*invalid address family*/
 #define EIPSEC_INVAL_PREFIXLEN 16  /*SPI range violation*/
-#define EIPSEC_INVAL_DIR   17  /*Invalid direciton*/
+#define EIPSEC_INVAL_DIR   17  /*Invalid direction*/
 #define EIPSEC_INVAL_SPI   18  /*invalid prefixlen*/
 #define EIPSEC_NO_PROTO19  /*no protocol specified*/
 #define EIPSEC_NO_ALGS 20  /*No algorithm specified*/
--- ipsec-tools-0.7.3//src/libipsec/ipsec_strerror.c.~1~2007-08-01 
13:52:17.0 +0200
+++ ipsec-tools-0.7.3//src/libipsec/ipsec_strerror.c2011-09-25 
19:19:01.0 +0200
@@ -63,7 +63,7 @@
 Invalid key length,  /*EIPSEC_INVAL_KEYLEN*/
 Invalid address family,  /*EIPSEC_INVAL_FAMILY*/
 Invalid prefix length,   /*EIPSEC_INVAL_PREFIXLEN*/
-Invalid direciton,   /*EIPSEC_INVAL_DIR*/
+Invalid direction,   /*EIPSEC_INVAL_DIR*/
 SPI range violation, /*EIPSEC_INVAL_SPI*/
 No protocol specified,   /*EIPSEC_NO_PROTO*/
 No algorithm specified,  /*EIPSEC_NO_ALGS*/

Bug#602957: Patch

[Teddy Hogeborn]

Teddy Hogeborn te...@fukt.bsnet.se writes:

 I have realized (and attached) this patch, which worked for me to fix
 this bug.

Yeah, that patch was reversed.  Fixed version attached.

/Teddy Hogeborn


pgpjDLLsWYGv3.pgp
Description: PGP signature
--- mod-gnutls-0.5.6.~1~/src/gnutls_hooks.c	2010-03-17 16:39:34.0 +0100
+++ mod-gnutls-0.5.6/src/gnutls_hooks.c	2011-06-11 04:25:21.521191493 +0200
@@ -686,7 +686,8 @@
 	return DECLINED;
 }
 
-if(c-remote_addr-hostname)
+if(c-remote_addr-hostname ||
+   apr_strnatcmp(c-remote_ip,c-local_ip) == 0)
   /* Connection initiated by Apache (mod_proxy) = ignore */
   return OK;
 


pgp0yXiB2pE1d.pgp
Description: PGP signature

Bug#535649: How to reproduce and fix

[Teddy Hogeborn]

I could reproduce this bug by having the libpam-gnome-keyring and
libpam-smbpass packages installed - when I removed them, the bug
vanished.

/Teddy



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#616113: Link workaround

[Teddy Hogeborn]

Workaround: add
isolate_network=NO
to your vsftpd.conf file.  This worked for me.

I got this information from a comment by Michal Seben here:
https://bugzilla.novell.com/show_bug.cgi?id=615034#c2

/Teddy Hogeborn



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#610522: doc-iana: Extra whitespace at start of html/assignments/xml-registry/schema/domain-1.0.xsd

[Teddy Hogeborn]

Package: doc-iana
Version: 20081201-1
Severity: normal


The file
/usr/share/doc/doc-iana/html/assignments/xml-registry/schema/domain-1.0.xsd
starts with three space characters before the ?xml declaration.  This
makes the file invalid and unusable.

Proposed fix: Replace the file with an updated version from
http://www.iana.org/assignments/xml-registry/schema/domain-1.0.xsd;
it has no space characters and is valid.  Alternatively, simply remove
the three space characters from the start of the file.

/Teddy

-- System Information:
Debian Release: 5.0.8
  APT prefers proposed-updates
  APT policy: (500, 'proposed-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-2-686 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

doc-iana depends on no packages.

Versions of packages doc-iana recommends:
ii  libjs-prototype   1.6.0.2-4  JavaScript Framework for dynamic w

doc-iana suggests no packages.

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#541172: net-tools: Patch

[Teddy Hogeborn]

Package: net-tools
Version: 1.60-22
Followup-For: Bug #541172

affects 541172 + munin-node
tags 541172 + patch
thanks

/Teddy

-- System Information:
Debian Release: 5.0.4
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-2-686 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages net-tools depends on:
ii  libc6   2.7-18lenny2 GNU C Library: Shared libraries

net-tools recommends no packages.

net-tools suggests no packages.

-- no debconf information
--- netstat.c.~1~   2010-06-09 08:37:03.0 +0200
+++ netstat.c   2010-06-09 08:37:24.0 +0200
@@ -1761,12 +1761,14 @@
  parsesnmp6(flag_raw, flag_tcp, flag_udp);
 #else
  printf(Address type not supported for stats\n);
+ exit(1);
 #endif
-}
-else
+} else {
  printf(Address type not supported for stats\n);
+exit(1);
+   }
 }
-exit(1);
+exit(0);
 }
 
 if (flag_rou) {

Bug#574453: request-tracker3.6: update-rt-siteconfig uses backup files

[Teddy Hogeborn]

Package: request-tracker3.6
Version: 3.6.7-5+lenny3
Severity: important
Tags: patch

/usr/sbin/update-rt-siteconfig does not ignore backup files, i.e.
files ending with ~.  The attached patch fixes the problem.

/Teddy

-- Package-specific info:
Changed files:
  usr/sbin/update-rt-siteconfig-3.6

-- System Information:
Debian Release: 5.0.4
  APT prefers proposed-updates
  APT policy: (500, 'proposed-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.26-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages request-tracker3.6 depends on:
ii  dbconfig-common  1.8.39  common framework for packaging dat
ii  debconf [debconf-2.0]1.5.24  Debian configuration management sy
ii  libapache-session-perl   1.86-1  Perl modules for keeping persisten
ii  libcache-simple-timedexp 0.27-2  Perl module to cache and expire ke
ii  libcalendar-simple-perl  1.20-1  Perl extension to create simple ca
ii  libclass-returnvalue-per 0.55-1  A return-value object that lets yo
ii  libcss-squish-perl   0.07-1  Compact many CSS files into one bi
ii  libdbi-perl  1.605-1 Perl5 database interface by Tim Bu
ii  libdbix-searchbuilder-pe 1.54-1  Encapsulate SQL queries and rows i
ii  libdevel-stacktrace-perl 1.1902-1Stack trace and stack trace frame 
ii  libgd-graph-perl 1.44-3  Graph Plotting Module for Perl 5
ii  libgd-text-perl  0.86-5  Text utilities for use with GD
ii  libhtml-mason-perl   1:1.39-1HTML::Mason Perl module
ii  libhtml-parser-perl  3.56-1+lenny1   A collection of modules that parse
ii  libhtml-scrubber-perl0.08-4  Perl extension for scrubbing/sanit
ii  liblocale-maketext-fuzzy 0.02-3  Maketext from already interpolated
ii  liblocale-maketext-lexic 0.66-1  Lexicon-handling backends for Loc
ii  liblog-dispatch-perl 2.18-1  Dispatches messages to multiple Lo
ii  libmailtools-perl2.03-1  Manipulate email in perl programs
ii  libmime-tools-perl [libm 5.427-1 Perl5 modules for MIME-compliant m
ii  libmodule-versions-repor 1.05-1  Report versions of all modules in 
ii  libregexp-common-perl2.122-1 Provide commonly requested regular
ii  libtext-autoformat-perl  1.14.0-1Perl module for automatic text wra
ii  libtext-template-perl1.44-1.2Text::Template perl module
ii  libtext-wikiformat-perl  0.78-1  translates Wiki formatted text int
ii  libtext-wrapper-perl 1.02-1  Simple word wrapping routine
ii  libtime-modules-perl 2006.0814-2 Various Perl modules for time/date
ii  libtimedate-perl 1.1600-9Time and date functions for Perl
ii  libtree-simple-perl  1.18-1  A simple tree object
ii  libuniversal-require-per 0.11-1  Load modules from a variable
ii  libxml-rss-perl  1.33-1  Perl module for managing RSS (RDF 
ii  libxml-simple-perl   2.18-1  Perl module for reading and writin
ii  perl 5.10.0-19lenny2 Larry Wall's Practical Extraction 
ii  postfix [mail-transport- 2.5.5-1.1   High-performance mail transport ag
ii  rsyslog [system-log-daem 3.18.6-4enhanced multi-threaded syslogd
ii  rt3.6-apache23.6.7-5+lenny3  Apache 2 specific files for reques
ii  rt3.6-clients3.6.7-5+lenny3  Mail gateway and command-line inte
ii  rt3.6-db-postgresql  3.6.7-5+lenny3  PostgreSQL database backend for re
ii  ucf  3.0016  Update Configuration File: preserv

Versions of packages request-tracker3.6 recommends:
ii  libtext-quoted-perl   2.05-2 Extract the structure of a quoted 

Versions of packages request-tracker3.6 suggests:
pn  rt3.6-rtfmnone (no description available)

-- debconf information:
  request-tracker3.6/app-password-confirm: (password omitted)
  request-tracker3.6/pgsql/app-pass: (password omitted)
  request-tracker3.6/mysql/app-pass: (password omitted)
  request-tracker3.6/mysql/admin-pass: (password omitted)
  request-tracker3.6/password-confirm: (password omitted)
  request-tracker3.6/pgsql/admin-pass: (password omitted)
* request-tracker3.6/dbconfig-install: true
  request-tracker3.6/pgsql/method: unix socket
  request-tracker3.6/upgrade-backup: true
  request-tracker3.6/dbconfig-remove:
  request-tracker3.6/internal/skip-preseed: true
  request-tracker3.6/pgsql/no-empty-passwords:
  request-tracker3.6/dbconfig-upgrade: true
  request-tracker3.6/mysql/admin-user: root
* request-tracker3.6/organization: rt.nmugroup.se
  request-tracker3.6/pgsql/authmethod-user: password
* request-tracker3.6/handle-siteconfig-permissions: true
  request-tracker3.6/passwords-do-not-match:
  request-tracker3.6/upgrade-error: abort
  request-tracker3.6/missing-db-package-error: 

Bug#574111: E: main.c: Failed to create '/tmp/pulse-$USER': Permission denied

[Teddy Hogeborn]

Package: libpulsecore5
Version: 0.9.10-3+lenny2
Severity: grave
Justification: renders package unusable

The update from 0.9.10-3+lenny1 to 0.9.10-3+lenny2 made pulseaudio
stop working:

te...@bris:~$ pulseaudio
E: main.c: Failed to create '/tmp/pulse-teddy': Permission denied
te...@bris:~$

It worked fine in version 0.9.10-3+lenny1.

/Teddy

-- System Information:
Debian Release: 5.0.4
  APT prefers proposed-updates
  APT policy: (500, 'proposed-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.26-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages libpulsecore5 depends on:
ii  libc62.7-18lenny2GNU C Library: Shared libraries
ii  libcap1  1:1.10-14   support for getting/setting POSIX.
ii  libltdl3 1.5.26-4+lenny1 A system independent dlopen wrappe
ii  liboil0.30.3.15-1Library of Optimized Inner Loops
ii  libsamplerate0   0.1.4-1 audio rate conversion library
ii  libsndfile1  1.0.17-4+lenny2 Library for reading/writing audio

Versions of packages libpulsecore5 recommends:
ii  pulseaudio   0.9.10-3+lenny2 PulseAudio sound server

libpulsecore5 suggests no packages.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#551907: mandos-client adds unnecessary files to initrd

[Teddy Hogeborn]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

C. Dominik Bodi dominik.b...@gmx.de writes:

 The update-initramfs hook script for mandos client adds several
 files into the initrd that are not necessary for its operation.

Yes, that is indeed a bug.  Very sorry about that.  We will fix this
right away.

 One of the files being added causes a severe security risk for other
 mandos client in case the client acts as a mandos server, as well.

I must confess that I do not understand how this can be the case.

(I guess it would be terrible if a client would, by some mistake, be
set up to be its own Mandos server, but that would never work anyway,
so nobody is supposed to even *have* that configuration.)

 The superfluous files can be found in
 initrd_root/etc/conf/conf.d/mandos/

Yes, I see them.  We'll change this now to just copy the needed files
(or file, as it happens).

 [...], if the mandos server package is installed on the same
 computer, the /etc/mandos/mandos.conf and /etc/mandos/clients.conf
 will be added to the initrd, as well.

Yes.  This was, of course, not intended, and we will fix it now.

 The latter contains the fingerprints of other mandos clients.
 If the initrd file was compromised, it would be very easy to to set
 up a rogue mandos server in order to snoop the other client's disk
 encryption passwords.

I do not see how this would be possible.  If someone got a copy of
/etc/mandos/clients.conf, it would *not* get them the disk encryption
passwords unless they *also* got the seckey.txt from the client.

Sure, this is bad, and we will fix this right away, but I do not think
this is a root security hole.  It cannot be exploited unless there
is *also* a root compromise or a hardware seizure on *both* the server
and the client - i.e. no worse than without disk encryption, at least.
And if only *one* of the server or client is compromised, there is no
problem.

It is *not* possible to snoop a client's disk encryption password by
being a rogue Mandos server.  The Mandos server receives nothing
except the client's public key, and a public key never made an
attacker any happier.

If you think I'm wrong, please explain in a little more detail how an
attack would be constructed with this bug in place.  (But I *am*
fixing this bug immediately.)

/Teddy Hogeborn

- -- 
The Mandos Project
http://www.fukt.bsnet.se/mandos
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkrfjQ8ACgkQOWBmT5XqI91sVQCdEAJkudrGWWjlimmELf0c/84b
PIQAni0hgEHNH/IkUq4KXU1dgoxcD+09
=r57Z
-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#549585: mandos-client: fails with: fatal: no entropy gathering module detected.

[Teddy Hogeborn]

package mandos-client
retitle 549585 udev: creates /dev/{u,}random with too strict permissions
summary 549585 20
tags 549585 patch
reassign 549585 udev 146-3
package udev
affects 549585 mandos-client
thanks

Teddy Hogeborn te...@fukt.bsnet.se writes:

 Indeed, it seems that both /dev/random and urandom are readable
 only by user and group, respectively.

 [...]  What were the exact permissions and ownerships?  crw-rw
 root root?  That would be very strange.  I'll have to wait until
 tomorrow (when I should have access to a sid machine) [...]

I installed a virtual machine with sid here, and could reproduce the
problem.

 On the bright side, we seem to have found the actual cause of the
 problem; we just need to get udev to create the devices with the
 proper permissions.

I was correct; it is all caused by a recent change in udev; the same
thing was the cause of bug #549275.  Here is a patch for udev which
fixes our version of the problem:

diff -u /usr/share/initramfs-tools/hooks/udev.\~1\~ 
/usr/share/initramfs-tools/hooks/udev
--- /usr/share/initramfs-tools/hooks/udev.~1~   2009-09-27 01:37:44.0 
+0200
+++ /usr/share/initramfs-tools/hooks/udev   2009-10-05 08:35:37.0 
+0200
@@ -25,7 +25,7 @@
 mkdir -p $DESTDIR/lib/udev/rules.d/
 for rules in 50-udev-default.rules 60-persistent-storage.rules \
80-drivers.rules 70-persistent-net.rules \
-   60-persistent-storage-lvm.rules \
+   60-persistent-storage-lvm.rules 91-permissions.rules \
55-dm.rules 60-persistent-storage-dm.rules; do
   if   [ -e /etc/udev/rules.d/$rules ]; then
 cp -p /etc/udev/rules.d/$rules $DESTDIR/lib/udev/rules.d/

I am reassigning this to udev, since that is where the problem can be
fixed; I do not see how to fix this from our package.

/Teddy Hogeborn

-- 
The Mandos Project
http://www.fukt.bsnet.se/mandos



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#549585: mandos-client: fails with: fatal: no entropy gathering module detected.

[Teddy Hogeborn]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

C. Dominik Bodi dominik.b...@gmx.de writes:

 After installing mandos [...], booting a mandos-enabled kernel,
 mandos will not run. The cryptsetup password prompt appears and I
 have to type in the crypt volume's password manually to make the
 system continue to boot.
 At virtually the same time the cryptsetup password prompt appears,
 an error message is printed on the console:
 Fatal: no entropy gathering module detected

I agree that this is bad and should not happen.  We have never seen
this problem, so it must be some new factor.  Let's see if we can find
out what it is.

 According to google that message seems to be related to gnutls.
 However, as mandos-client doesn't seem to have a debug mode when run
 from initrd, I wasn't able to dig deeper.

Good news: it is actually possible to run mandos-client in debug mode
in the initrd.  If you uncomment the line:
- --options-for=mandos-client:--debug
in /etc/mandos/plugin-runner.conf and rebuild your initrd image file
with update-initrd -u -k all, the mandos-client plugin should be
extremely generous with debug messages when booting.

 There is no such error message when testing mandos-client as
 described in README.Debian

You could boot your system with the kernel parameter break, you
should get a shell running in the initrd environment.  You could check
if the problem is the lack of a proper readable /dev/urandom - this is
what the search results suggest is the usual cause of this message.

Would it be possible for you to do that and report back?  We don't
have many machines running testing or unstable, and I don't have
access to any at the moment.

 Kernel: Linux 2.6.30-2-amd64 (SMP w/1 CPU core)

I suspect that - Linux 2.6.30 - to be the cause.  We probably need to
force some specific module to be loaded in the initrd - which used to
be loaded by default or compiled in - to provide the random device
drivers.  In that case, the question is: what module?

/Teddy Hogeborn

- -- 
The Mandos Project
http://www.fukt.bsnet.se/mandos
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFKyNtpOWBmT5XqI90RAk9jAJ47AXTtespMGUIrI1HXff5Ku2mMwACguVx0
OVwvLHWavVIUKXD3gP9GM2Y=
=SFSQ
-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#549585: mandos-client: fails with: fatal: no entropy gathering module detected.

[Teddy Hogeborn]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

C. Dominik Bodi dominik.b...@gmx.de writes:

 After installing mandos [...], booting a mandos-enabled kernel,
 mandos will not run. The cryptsetup password prompt appears and I
 have to type in the crypt volume's password manually to make the
 system continue to boot.
 At virtually the same time the cryptsetup password prompt appears,
 an error message is printed on the console:
 Fatal: no entropy gathering module detected

I agree that this is bad and should not happen.  We have never seen
this problem, so it must be some new factor.  Let's see if we can find
out what it is.

 According to google that message seems to be related to gnutls.
 However, as mandos-client doesn't seem to have a debug mode when run
 from initrd, I wasn't able to dig deeper.

Good news: it is actually possible to run mandos-client in debug mode
in the initrd.  If you uncomment the line:
- --options-for=mandos-client:--debug
in /etc/mandos/plugin-runner.conf and rebuild your initrd image file
with update-initrd -u -k all, the mandos-client plugin should be
extremely generous with debug messages when booting.

 There is no such error message when testing mandos-client as
 described in README.Debian

You could boot your system with the kernel parameter break, you
should get a shell running in the initrd environment.  You could check
if the problem is the lack of a proper readable /dev/urandom - this is
what the search results suggest is the usual cause of this message.

Would it be possible for you to do that and report back?  We don't
have many machines running testing or unstable, and I don't have
access to any at the moment.

 Kernel: Linux 2.6.30-2-amd64 (SMP w/1 CPU core)

I suspect that - Linux 2.6.30 - to be the cause.  We probably need to
force some specific module to be loaded in the initrd - which used to
be loaded by default or compiled in - to provide the random device
drivers.  In that case, the question is: what module?

/Teddy Hogeborn

- -- 
The Mandos Project
http://www.fukt.bsnet.se/mandos
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFKyNs1OWBmT5XqI90RAlGhAKCHK9H1I42skB0SfwwubApXIfkbAACfRgs7
uLYbeXwiKKcFm2167uicef0=
=AoHj
-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#549585: mandos-client: fails with: fatal: no entropy gathering module detected.

[Teddy Hogeborn]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

C. Dominik Bódi dominik.b...@gmx.de writes:

 After having enabled the debug mode via plugin-runner.conf as you
 suggested.  The fatal error occurs immediately after the first
 debug messages, which is:
 Initializing GNUTLS

- From mandos-client.c:

  if(debug){
fprintf(stderr, Initializing GnuTLS\n);
  }
  
  ret = gnutls_global_init();

So the problem is definitely reported by GnuTLS (or libgcrypt).

 Then I booted the kernel with the break option and ran sh
 scripts/init- premount/udev.

Right, I forgot you need to run that too; sorry.

 Indeed, it seems that both /dev/random and urandom are readable only
 by user and group, respectively.

I was hoping for it to be just a missing module to load, but no such
luck, I guess.  What were the exact permissions and ownerships?
crw-rw root root?  That would be very strange.  I'll have to
wait until tomorrow (when I should have access to a sid machine) to
check which of the many changes from lenny to sid could cause it.

On the bright side, we seem to have found the actual cause of the
problem; we just need to get udev to create the devices with the
proper permissions.

/Teddy Hogeborn

- -- 
The Mandos Project
http://www.fukt.bsnet.se/mandos
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFKyPBEOWBmT5XqI90RAj0ZAJ4zYgbOjEGAC3yCGX0wHv1z0WBxkwCdEmHB
+ruOGs6j2NdDLNr+vyrYAGo=
=bUBW
-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#546928: mandos: Incorrect dependencies in init.d script

[Teddy Hogeborn]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Petter Reinholdtsen p...@hungry.com writes:

 Hi.  Any hope of having this fixed soon?  Please object if I should
 not NMU to solve it.

I'd be very happy if you would sponsor the new version (1.0.12-1,
available on mentors.d.o) which fixes this and other bugs.

/Teddy Hogeborn

- -- 
The Mandos Project
http://www.fukt.bsnet.se/mandos
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFKueMmOWBmT5XqI90RAnY+AKC7KRWAQHYZWKGvtMKw5WiCi3+O1ACgwoOj
jSv1QCi3xSl6AinUlspWtZk=
=aqpm
-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#547452: timelimit: Does not re-raise signals properly, returns bogus exit code instead

[Teddy Hogeborn]

Package: timelimit
Version: 1.4-2
Severity: normal
Tags: patch


Returning signal+128 does *not* tell the invoking shell that the
program terminated by a signal.  Quote from
http://www.cons.org/cracauer/sigint.html:

You cannot fake the proper exit status by an exit(3) with a
special numeric value, even if you look up the numeric value
for your system.  People often assume this since the manuals
for shells often list some return value for exactly this.  But
this is just a naming convention for your shell script.  It
does not work from one UNIX API program to another.  The real
information did I exit on a signal yes/no it not contained
in the returned numeric value, it just looks that way in a
shell which has just cooked up what the Unix API returned.

Patch:

--- timelimit-1.4/timelimit.c.~1~   2008-11-12 10:20:39.0 +0100
+++ timelimit-1.4/timelimit.c   2009-09-19 22:47:48.0 +0200
@@ -318,8 +318,29 @@
(long)pid);
if (WIFEXITED(status))
return (WEXITSTATUS(status));
-   else if (WIFSIGNALED(status))
-   return (WTERMSIG(status) + 128);
+   else if (WIFSIGNALED(status)) {
+#ifdef HAVE_SIGACTION
+   struct sigaction act;
+   
+   memset(act, 0, sizeof(act));
+   act.sa_handler = SIG_DFL;
+   act.sa_flags = 0;
+   if (sigaction(WTERMSIG(status), act, NULL)  0) {
+   err(EX_OSERR, restoring signal handler for %d,
+  WTERMSIG(status));
+   abort();
+   }
+#else  /* HAVE_SIGACTION */
+   if (signal(sig, SIG_DFL) == SIG_ERR) {
+   err(EX_OSERR, restoring signal handler for %d,
+  WTERMSIG(status));
+   abort();
+   }
+#endif /* HAVE_SIGACTION */
+   raise(WTERMSIG(status));
+   while (1)
+   pause();
+   }
else
return (EX_OSERR);
 }

-- System Information:
Debian Release: 5.0.3
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.26-2-686
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages timelimit depends on:
ii  libc6  2.7-18 GNU C Library: Shared libraries

timelimit recommends no packages.

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#529836: Version 1.0.11 of Mandos is released

[Teddy Hogeborn]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Version 1.0.11 of Mandos is released.  This is a very minor bug fix
release.  Nothing to see here.  Move along.

Version 1.0.11 (2009-05-23)
* Client
** Bug fix: Use pkg-config instead of old libgnutls-config.

The upload would fix these Debian bugs: 529836
The Debian package for unstable can be found on mentors.debian.net:
- - dget http://mentors.debian.net/debian/pool/main/m/mandos/mandos_1.0.11-1.dsc

/Teddy Hogeborn

- -- 
The Mandos Project
http://www.fukt.bsnet.se/mandos
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFKF4yEOWBmT5XqI90RAgWYAJ9EkS7d0k4RFTZDjZqSkKMRYCRI2ACgzSrE
r40phO61lir7aRERmdhKtoM=
=yese
-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#517074: manpages: ipv6(7) has wrong type for sockaddr_in6.sin6_family

[Teddy Hogeborn]

Package: manpages
Version: 3.05-1
Severity: normal
Tags: patch


ipv6(7) has the wrong type for both the sin6_family and sin6_port
fields of the sockaddr_in6 struct.  Patch attached.

/Teddy Hogeborn

-- System Information:
Debian Release: 5.0
  APT prefers proposed-updates
  APT policy: (500, 'proposed-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

manpages depends on no packages.

manpages recommends no packages.

Versions of packages manpages suggests:
ii  man-db [man-browser]  2.5.2-4on-line manual pager

-- no debconf information
--- manpages-3.05/man7/ipv6.7.~1~	2008-07-23 16:12:29.0 +0200
+++ manpages-3.05/man7/ipv6.7	2009-02-25 14:04:33.0 +0100
@@ -64,8 +64,8 @@
 .in +4n
 .nf
 struct sockaddr_in6 {
-uint16_tsin6_family;   /* AF_INET6 */
-uint16_tsin6_port; /* port number */
+sa_family_t sin6_family;   /* AF_INET6 */
+in_port_t   sin6_port; /* transport layer port # */
 uint32_tsin6_flowinfo; /* IPv6 flow information */
 struct in6_addr sin6_addr; /* IPv6 address */
 uint32_tsin6_scope_id; /* Scope ID (new in 2.4) */

Bug#430074: ldm does not display many locales

[Teddy Hogeborn]

Package: ldm
Version: 0.99debian11
Severity: normal
Tags: patch l10n

If the server har very many locales installed, LDM only displays a
certain number of them, and does not display any sessions (only the
Default session).  Reproduce this by having a server with all locales
installed.

This is because /usr/lib/ltsp/greeters/gtk limits the response from
ldminfod to 1024 bytes.  A simple fix is to make the buffer larger:

--- /usr/lib/ltsp/greeters/gtk.~1~  2007-01-11 08:20:45.0 +0100
+++ /usr/lib/ltsp/greeters/gtk  2007-06-22 07:55:41.0 +0200
@@ -396,7 +396,7 @@
 sesslist=[]
 langlist=[]
 
-for line in ldm_info.recv(1024).split('\n'):
+for line in ldm_info.recv(8192, socket.MSG_WAITALL).split('\n'):
 if line.startswith('/'):
 sesslist.append(line)
 else:


/Teddy

Bug#395470: phpbb2: Users can not select gallery avatars

[Teddy Hogeborn]

Package: phpbb2
Version: 2.0.13-6sarge3
Severity: normal


I have a problem using the avatar gallery feature of phpBB.  First, to
get the gallery avatars to show up at all, I had to run the command
chmod g+r /var/lib/phpbb2/avatars/gallery.  And I also had to make
all the gallery subdirectories[1] I had to create also be readable and
executable by the www-data group.  (I suspect this bug to still be
present in phpbb2-2.0.21-4.)  Anyway, with this, a user can see the
avatar images in the galleries and can select them when editing his
profile.

BUT, when the user then selects Submit on the profile editing
screen, the avatar setting is ignored and the database is not updated.
The SQL UPDATE command issued does not include the 'user_avatar' or
'user_avatar_type' columns.  So the previous avatar setting is kept,
except that if the previous avatar setting was a user-uploaded image
file, this file will still be deleted, so the avatar setting will then
be set to a non-existing image file.

Note that changing the avatar image to one from a gallery *does* work
*if* done using the Administration Panel/User Admin/Management page.
But the user can not do it himself from the Profile page.

/Teddy

1) http://www.phpbb.com/support/documents.php?mode=faq, question 15:
   How do I use the avatar settings?

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.16-2-686-smp
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages phpbb2 depends on:
ii  apache2  2.0.54-5sarge1  next generation, scalable, extenda
ii  apache2-mpm-prefork [htt 2.0.54-5sarge1  traditional model for Apache2
ii  boa [httpd]  0.94.14rc20-1.2 Lightweight and High Performance W
ii  debconf  1.4.30.13   Debian configuration management sy
ii  libapache2-mod-php4  4:4.3.10-16 server-side, HTML-embedded scripti
ii  php4 4:4.3.10-16 server-side, HTML-embedded scripti
ii  php4-mysql   4:4.3.10-16 MySQL module for php4
ii  php4-pgsql   3:4.3.10-4  PostgreSQL module for php4

-- debconf information:
* phpbb2/httpd: apache2


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#324788: tcpd: No way to block depending on socket options

[Teddy Hogeborn]

   I use IPsec. I would like to block connections to a service if
   the client is not using IPsec (similar to only allowing IMAPS

[EMAIL PROTECTED] (Marco d'Itri) writes:

  Send a patch, and test it well.
 Do you have any plan to work on this?

No.  Should I have?  I am not a programmer.  I am reporting a
potentially useful missing feature, not volunteering to implement it.
This is what wishlist bugs are for, are they not?

Why are you closing the bug report?  Have you forwarded this issue
upstream?  Has upstream decided that the feature is a bad idea?

(Sorry for not replying, my email domain has changed.)

/Teddy

Bug#376041: emacs21: M-x occur with regexp ^[^#] fails with Args out of range:.

[Teddy Hogeborn]

Package: emacs21
Version: 21.4a-1
Severity: normal

I wanted to show the non-comment lines in a config file I was editing,
so I tried to use the M-x occur (a.k.a. list-matching-lines) command
with the regexp ^[^#] (without the quotes).  This failed with Args
out of range: NUMBER NUMBER.  It turns out that the [^#] fragment
also matches the newline character, which I was not expecting, since
the documentation for the occur command says Display a list showing
each *line* in the buffer that contains a match... (my emphasis).

The current behaviour is not useful, inconsistent with documentation,
and an nuisance to the use of the command.  I consider it a bug; in my
opinion it should be changed to not match the newline character.

/Teddy

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.16-2-686-smp
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages emacs21 depends on:
ii  emacs21-bin-common 21.4a-1   The GNU Emacs editor's shared, arc
ii  libc6  2.3.2.ds1-22sarge4GNU C Library: Shared libraries an
ii  libice64.3.0.dfsg.1-14sarge1 Inter-Client Exchange library
ii  libjpeg62  6b-10 The Independent JPEG Group's JPEG 
ii  libncurses55.4-4 Shared libraries for terminal hand
ii  libpng12-0 1.2.8rel-1PNG library - runtime
ii  libsm6 4.3.0.dfsg.1-14sarge1 X Window System Session Management
ii  libtiff4   3.7.2-5   Tag Image File Format (TIFF) libra
ii  libungif4g 4.1.3-2sarge1 shared library for GIF images (run
ii  libx11-6   4.3.0.dfsg.1-14sarge1 X Window System protocol client li
ii  libxext6   4.3.0.dfsg.1-14sarge1 X Window System miscellaneous exte
ii  libxmu64.3.0.dfsg.1-14sarge1 X Window System miscellaneous util
ii  libxpm44.3.0.dfsg.1-14sarge1 X pixmap library
ii  libxt6 4.3.0.dfsg.1-14sarge1 X Toolkit Intrinsics
ii  xaw3dg 1.5+E-8   Xaw3d widget set
ii  xlibs  4.3.0.dfsg.1-14sarge1 X Keyboard Extension (XKB) configu
ii  zlib1g 1:1.2.2-4.sarge.2 compression library - runtime

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#344484: Asterisk crashes on sparc when playing 'demo-moreinfo'

[Teddy Hogeborn]

Here too on a Sun Enterprise 3000 (UltraSparc II) .  I can fix it by
not using GSM, either by deselecting it from the client or by setting
disallow=gsm under [general] in sip.conf.

/Teddy

Bug#358673: racoon: Racoon crashes with SIGSEGV (Segmentation fault)

[Teddy Hogeborn]

Package: racoon
Version: 1:0.5.2-1sarge1
Severity: important


Since upgrading to sarge I have been experiencing infrequent crashes
by racoon on more than one machine which did not exhibit this
behaviour in woody.  I attached a strace to the racoon process on
two of the machines which exhibited the most crashes and got a live
SEGV fault.  I am reluctant to include the full trace in a public bug
tracking system, so I have replaced some data with  in the trace
below:

===
[...]
time([1143105094])  = 1143105094
time([1143105094])  = 1143105094
time([1143105094])  = 1143105094
select(12, [3 4 7 9 10 11], NULL, NULL, {3, 0}) = 1 (in [10], left {2, 996000})
getsockname(10, {sa_family=AF_INET, sin_port=htons(500), 
sin_addr=inet_addr(194.47.143.3)}, [16]) = 0
recvmsg(10, {msg_name(16)={sa_family=AF_INET, sin_port=htons(500), 
sin_addr=inet_addr(194.47.144.23)}, msg_iov(1)=[{..., 32}], 
msg_controllen=24, {cmsg_len=24, cmsg_level=SOL_IP, cmsg_type=, ...}, 
msg_flags=MSG_TRUNC}, MSG_PEEK) = 32
getsockname(10, {sa_family=AF_INET, sin_port=htons(500), 
sin_addr=inet_addr(194.47.143.3)}, [16]) = 0
recvmsg(10, {msg_name(16)={sa_family=AF_INET, sin_port=htons(500), 
sin_addr=inet_addr(194.47.144.23)}, msg_iov(1)=[{..., 68}], 
msg_controllen=24, {cmsg_len=24, cmsg_level=SOL_IP, cmsg_type=, ...}, 
msg_flags=0}, 0) = 68
time(NULL)  = 1143105094
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
Process 1671 detached
===

194.47.143.3 above is the host machine itself, 194.47.144.23 is a
Windows machine I have been trying (with only partial success) to talk
IPsec with.

The crashes are infrequent (only 5 or so crashes have happened in
total) but recurring, and on more on one machine, which leads me to
exclude the possibility of hardware failure.

/Teddy

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.8-2-686
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages racoon depends on:
ii  debconf  1.4.30.13   Debian configuration management sy
ii  ipsec-tools  1:0.5.2-1sarge1 IPsec tools for Linux
ii  libc62.3.2.ds1-22GNU C Library: Shared libraries an
ii  libssl0.9.7  0.9.7e-3sarge1  SSL shared libraries
ii  perl 5.8.4-8sarge3   Larry Wall's Practical Extraction 

-- debconf information:
* racoon/config_mode: racoon-tool


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#329701: [Adduser-devel] Bug#329701: Local (non-NIS) users and groups

[Teddy Hogeborn]

Marc Haber [EMAIL PROTECTED] writes:

   Which change is suggested to adduser?
  
  The change of LAST_SYSTEM_UID in /etc/adduser.conf from 999 to 499.
 
 /etc/adduser.conf is a conffile. The range 100-999 is laid down in
 policy 9.2.2, so changing the default in adduser is out of the
 question.

I'm trying to affect a policy change here.  But -policy consistently
refers to package maintainers to change their packages before a policy
change can be considered.  Therefore I'm trying to get packages to
change.  It can't be *impossible* to change, one or the other has to
be changed first.  I tried (several times) to bring up the issue in
debian-policy but no one replied.  That is why I'm now bringing up the
issue with you, the package maintainers of the affected packages.  So
far I have gotten the nis package maintainer to agree to the change if
done in concert with the other affected packages.

  If this is done, Group IDs of 500 to 999 can be used for
  NIS-exported groups, but this is not anything which adduser has to
  be concerned about.
 
 Right, adduser can be locally configure to handle this.

I know.  I'm talking about what the default should be.

  One additional possibility is for adduser to support an interface
  to add users/groups in this new range, which would involve a new
  configuration option and at least one new command line option.
  But this is not necessarily requested or required.
 
 I'm actually not convinced that this would do any good. adduser
 traditionally does not care about NIS/LDAP setup, and I think that
 accounts and groups that will appear on multiple systems should not be
 created by adduser.

Fair enough for me; it was the nis package maintainer who suggested
that the proposal might be more convincing if adduser had an interface
to add users in this range.  I'm not attached to the idea.

Just to make something clear, though: users that are added by adduser
are already exported by NIS, since NIS by default exports all users
from ID 1000 and up (all except 65534).

/Teddy

Bug#329701: Local (non-NIS) users and groups

[Teddy Hogeborn]

Mark Brown [EMAIL PROTECTED] writes:

  And it's not like this would be changed on a running system,
  right?
 
 That is not the case.  /var/yp/Makefile is a conffile and so will be
 updated if it hasn't been modified.

Oh, I see.  Sorry.  (Hmm, the installation scripts would have to check
for preexisting GIDs in the range 500-999 then, and warn
appropriately.)

  (From what I can see, absolutely no one on -policy cares about
  this, since I have asked about this on two occasions now and both
  times gotten no reply whatsoever.)
 
 You might find that coming up with a concrete proposal for policy
 might help there.

I have the feeling that all that would happen is that maybe someone
would ask the maintainers for the affected packages what *they* think,
and hold off on any policy change until the packages are changed.  But
it would be easy to write a specific change proposal, so I'll do that
once someone actually needs one.

  If you want to avoid even that remote possibility, this change
  should be coordinated with a change in the adduser package to
  lower LAST_SYSTEM_UID in /etc/adduser.conf.
 
 That would probably help too.  A patch implementing support for the
 new GID range you want to add might also be helpful.

Support?  You mean something like adduser --system-shared?  That's a
bit more than I am asking for; I just wanted to have the range
*available* as a general policy, not necessarily have a nice UI to it.
But thank you for the suggestion.

  Is this what you want?  Would you be willing to make the change if
  the maintainers for adduser were, too?
 
 What I want is for any change in the default handling of UID and GID
 ranges in NIS to be made in other parts of Debian too.

Fair enough, but what parts other than adduser are there?  (And
don't say debian-policy, please.)

 You are asking me to have the NIS package take part of an existing
 GID range and give it a new meaning without updating anything else
 in Debian to understand this.  I don't think that's a good idea.

All right, but I think you are overestimating the impact this would
have.  No other package (except for adduser) even cares about the ID
ranges in question, from what I can see.  But I'll jump through
whatever hoops are necessary to have this proposal actually
considered.

 It is very easy for people who want this behaviour to change their
 local configuration suitably.  Doing it in NIS alone will at best
 provide a small part of what you are asking for

(Actually, it would solve all my problems.  This change is the only
one I need to apply to use this GID range the way I want.)

I mean, I have already solved my problems by making the change locally
(on a number of systems).  But I don't like making such changes to a
system policy, and Debian doesn't provide for a way to do what I want,
so I'm therefore trying to make Debian adopt my policy.  If I succeed,
it's one thing less odd about my systems compared to a standard
install.  I'll even be just as happy if Debian decides to adopt some
other way to do the same thing, just as long as I can do what I want
on my systems with minimal change to system policy.

 and may actually cause breakage.

Extremly unlikely, in my opinion.  But I'll approach things the Right
Way, as long as someone can say what way that is.  But not as long as
everybody keeps pointing at someone else.

To summarize:

Would you be OK with making this change if the adduser package was
changed too?  (Of course, after both packages are changed, the Debian
Policy would be approachable for change, after which everything would
be nice again.)  Or are there more parts of Debian that, in your
opinion, need to be changed in concert?  I would need to know this if
I am to approach maintainers with this proposal.

/Teddy

Bug#329701: Local (non-NIS) users and groups

[Teddy Hogeborn]

reassign 329701 adduser
thanks

Maintainers of adduser, please review the log of bug #329701 and
comment.  Thank you.

Mark Brown [EMAIL PROTECTED] writes:

 It might be helpful to have everything ready to be changed in one
 fell swoop in order to avoid skew between policy and reality and to
 ensure that everyone is up to speed prior to the change.

All right, sounds good.  After I've gotten the OK from all involved
maintainers, I'll start with that.

  Support?  You mean something like adduser --system-shared?
 
 It might help convince people to accept such a change if there were
 a user interface for using it.

Right.  If the adduser maintainers are agreeable to the idea I'll look
into it.

  Fair enough, but what parts other than adduser are there?
 
 Off the top of my head there are some other implementations of
 adduser around.

Hmm, in what packages?  The only one I can find is adduser-ng which
does not seem to know *anything* about any ranges, it simply calls
useradd and groupadd.  Since it it already range-ignorant, it does
not need to be changed.

(Maintainers of adduser, do you know of any more?)

  Would you be OK with making this change if the adduser package
  was changed too?  (Of course, after both packages are changed, the
  Debian
 
 I would probably go along with the adduser maintainers on this one.

Thank you.  Allright then.

/Teddy

Bug#329701: Local (non-NIS) users and groups

[Teddy Hogeborn]

Marc Haber [EMAIL PROTECTED] writes:

 Not having a clue about NIS and never having had any sizeable amount
 of local users, I'd like to have an executive summary for this bug
 report.
 
 Which change is suggested to adduser?

The change of LAST_SYSTEM_UID in /etc/adduser.conf from 999 to 499.

If this is done, Group IDs of 500 to 999 can be used for NIS-exported
groups, but this is not anything which adduser has to be concerned
about.

One additional possibility is for adduser to support an interface to
add users/groups in this new range, which would involve a new
configuration option and at least one new command line option.  But
this is not necessarily requested or required.

If both adduser and the nis package can make this change, the Debian
Policy can then be approached to be changed to list the new ID range.

/Teddy

Bug#329701: Local (non-NIS) users and groups

[Teddy Hogeborn]

Mark Brown [EMAIL PROTECTED] writes:

I submit that this is not a problem in practice since I'd bet no one
using NIS has created more than 400 local groups that must not be
exported.

And it's not like this would be changed on a running system, right?
It would just be the default value in /var/yp/Makefile for new package
installations for new NIS master servers.

  Noone needs to wait for debian-policy before changing their
  packages.  The way to change the Debian policy is to change the
  workings of the relevant packages (in this case just nis) and
  then report this fact to debian-policy as an agreed-upon policy by
  the maintainers in question.
 
 Unfortunately, this affects any package which creates a group since
 that's the range those groups come from.  If things were changed such
 that the 100-999 range were split into a 100-499 local range and a
 500-999 exported range

You mean changed in the Debian Policy, I take it.

 that would be addressed and I'd have no problem with making the
 change you request.

That's not how changes happen in Debian Policy, as I understand it.
Instead, package maintainers change their packages' behavior and then
present their working changes to debian-policy as a fait accompli.
Policy reflect package behavior, not the reverse.  So the policy
change you are asking for can only come after you change the package.

And I'm not actually seeing a conflict with policy in this case, since
policy does not mention NIS exporting at all.

If you want to touch ground you (as the actual maintainer you might
get more responses than I got) could ask debian-policy if anyone would
OBJECT to the change.  (From what I can see, absolutely no one on
-policy cares about this, since I have asked about this on two
occasions now and both times gotten no reply whatsoever.)

The only thing I can foresee delaying this change is if you really
want to be CERTAIN that no one does adduser --system --group 400
times and suddenly gets into the exported GID range (not that I see
anyone actually doing that, but...).  If you want to avoid even that
remote possibility, this change should be coordinated with a change in
the adduser package to lower LAST_SYSTEM_UID in /etc/adduser.conf.
Is this what you want?  Would you be willing to make the change if the
maintainers for adduser were, too?

(Note that adduser --system by itself does not add more group IDs;
it places system users in the nogroup group by default.  The
additional --group option is needed to consume group IDs, and this
would have to be done more than 400 times to actually overflow.)

/Teddy

Bug#329701: Local (non-NIS) users and groups

[Teddy Hogeborn]

package debian-policy
reassign 329701 nis
thanks

(No reply from anybody on -policy for a few months now, so I follow up
myself.)

Mark Brown [EMAIL PROTECTED] writes:

 This looks like a question for policy rather than the NIS package
 since coordination with things like adduser seems at least desirable
 so I'm reassigning the bug there.

Actually, no.  For this proposal, no cooperation with adduser is
needed; adduser will work the same as always using the same number
ranges.

 My instinct is that this is probably something that is best handled
 by the local administrator since having it work effectively requires
 more coordination between machines than is likely to be achived
 automatically but I've not considerd the issues too deeply.

Yes, of course, but a lot of configuration is needed to get NIS up and
running anyway.  What I am asking for is for the *default* in the NIS
package to not be changed when this change makes it more difficult to
allow NIS-exported groups.  I don't think it's that strange since I am
just asking for Debian not to change the default upstream value.  The
current nis package's change of the MINGID value to 1000 serves no
purpose that I can see.

Noone needs to wait for debian-policy before changing their packages.
The way to change the Debian policy is to change the workings of the
relevant packages (in this case just nis) and then report this fact
to debian-policy as an agreed-upon policy by the maintainers in
question.

/Teddy

Bug#329701: Local (non-NIS) users and groups

[Teddy Hogeborn]

Package: nis
Version: 3.13-2
Severity: wishlist

(I tried to raise this question for general discussion some time ago
but no one replied.  See
http://lists.debian.org/debian-policy/1998/10/msg00198.html.
Therefore I now submit a more specific proposal as a wishlist bug in
the hope of some feedback.)

In regards to NIS (and LDAP), there is no standard place for
domain-exported groups which are not user-private groups.  I propose
that the system GID space be split in half and all GIDs at 500 and
above be considered domain-exported and those below to be
machine-local.

The only change necessary in the nis package is to *not* change MINGID
in nis-3.13/ypserv-2.14/scripts/ypMakefile.in.  The original value
is already 500; just leave it.

(I guess this ought to be written into the policy manual at some
point, but you have to start somewhere, and it's easier to change a
package than the Debian Policy.)

/Teddy

Bug#324788: tcpd: No way to block depending on socket options

[Teddy Hogeborn]

Package: tcpd
Version: 7.6.dbs-8
Severity: wishlist

I use IPsec. I would like to block connections to a service if the
client is not using IPsec (similar to only allowing IMAPS and not
IMAP).  IPsec use can be detected by a socket option
(IP_IPSEC_POLICY).  It would therefore be useful to me to be able to
specify required socket options on a socket and not only client
addresses.

The shell command options (spawn and twist) are not adequate
because they run with /dev/null as stdin and stdout/stderr and have
no way to access the socket.  There is also no way to predicate the
access on the result of such an external command.

I could, I suppose, use the twist option to run my own checker which
then runs the service (if allowed), but then there would be no need to
actually use the wrapper and I could just call the checker from inetd
directly.  And I feel that tcpd is the proper place for this kind of
functionality.

Or maybe this is what the IPsec SPD is for, but I never found any
sensible documentation for that stuff.

/Teddy

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.4.27-2-686
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages tcpd depends on:
ii  debconf [debconf-2.0]   1.4.30.13Debian configuration management sy
ii  libc6   2.3.2.ds1-22 GNU C Library: Shared libraries an
ii  libwrap07.6.dbs-8Wietse Venema's TCP wrappers libra

-- debconf information:
  tcpd/paranoid-mode: false


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#296259: racoon-tool asn1dn with string argument does not work

[Teddy Hogeborn]

Package: racoon
Version: 0.5.2-1
Severity: normal
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

This is an updated patch for racoon-0.5.2-1.

/Teddy

- BEGIN PATCH
- --- /usr/sbin/racoon-tool.~1~ 2005-05-04 10:33:32.0 +0200
+++ /usr/sbin/racoon-tool   2005-06-11 06:33:00.0 +0200
@@ -1328,7 +1328,7 @@

   
 chomp;
 
- -if (! m/^[-\{}()\[\]_;[EMAIL PROTECTED]:\/]+$/) {
+if (! m/^[-\{}()\[\]_;[EMAIL PROTECTED]:\/=]+$/) {
 prog_warn 0, bad data in $conffile, line $line:;
 prog_warn 0, $_;
 # $barf = 1;
@@ -1464,7 +1464,6 @@
$peer_list{$peer}{'syntax_error'} = 1;
next LINE;
}
- - $value = value_lc($section, $property, $value);
$peer_list{$peer}{$property} = $value; 
} elsif ( $section eq 'peer' ) {
 prog_warn 0, $peer - unrecognised tag in $conffile, 
line $line:;
- END PATCH
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.6 http://mailcrypt.sourceforge.net/

iD8DBQFCqwdXOWBmT5XqI90RArjaAJ93N3m10L/4Jh/7gMxSCA9smuLbZgCeI9Ya
vFTqEZhNAOG0SIF6Fqgqhis=
=pYuL
-END PGP SIGNATURE-

Bug#308341: glibc-doc: SO_RCVBUF documented as size_t, but is int in Linux.

[Teddy Hogeborn]

Package: glibc-doc
Version: 2.3.2.ds1-21
Severity: normal

In (libc)Socket-Level Options, SO_RCVBUF is documented as having a
type size_t.  In Linux, it is of type int.  The man page socket(7)
does not say what type it is.  The same goes for SO_SNDBUF.

This is mostly a problem on 64-bit architechtures where size_t is not an
int.  If SO_RCVBUF should be size_t, then this is a Linux bug and this
bug should be reassigned.

/Teddy

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: sparc (sparc64)
Kernel: Linux 2.4.27-2-sparc64-smp
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#296259: racoon-tool asn1dn with string argument does not work

[Teddy Hogeborn]

Package: racoon
Version: 0.3.3-1
Severity: normal
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

The peers_identifier asn1dn command in racoon-tool.conf allows a
string argument to be specified, but there are two things preventing
it from working:

1. It rejects = (equals) characters from the string, which is
   necessary for a valid ASN.1 identifier

2. It lowercases the whole string before writing it to racoon.conf,
   making the string invalid.  (I dont't see any point in lowercasing
   stuff so I just removed it.)

Patch for both problems follows.

/Teddy

- BEGIN PATCH
- --- /usr/sbin/racoon-tool.~1~ Fri Jun 18 11:28:25 2004
+++ /usr/sbin/racoon-tool   Mon Feb 21 12:41:51 2005
@@ -1322,7 +1322,7 @@

   
 chomp;
 
- -if (! m/^[-{}()\[\]_;[EMAIL PROTECTED]:\/]+$/) {
+if (! m/^[-{}()\[\]_;[EMAIL PROTECTED]:\/=]+$/) {
 prog_warn 0, bad data in $conffile, line $line:;
 prog_warn 0, $_;
 # $barf = 1;
@@ -1458,7 +1458,6 @@
$peer_list{$peer}{'syntax_error'} = 1;
next LINE;
}
- - $value = value_lc($section, $property, $value);
$peer_list{$peer}{$property} = $value; 
} elsif ( $section eq 'peer' ) {
 prog_warn 0, $peer - unrecognised tag in $conffile, 
line $line:;
- END PATCH

- -- System Information
Debian Release: 3.0
Architecture: sparc
Kernel: Linux flash 2.4.27 #1 Tue Jan 18 09:00:30 CET 2005 sparc64
Locale: LANG=C, LC_CTYPE=en_US.UTF-8

Versions of packages racoon depends on:
ii  debconf   1.2.35 Debian configuration management sy
ii  ipsec-tools   0.3.3-1IPsec tools for Linux
ii  libc6 2.2.5-11.8 GNU C Library: Shared libraries an

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQFCGc3iOWBmT5XqI90RAn0xAKDeyoBoe0IhVMjlThJ0/3dDpXu2YwCdH3yN
fA2vE49yAhZP3H5UTlz8m4g=
=y0LE
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]