Bug#1071459: wireplumber-doc: un-expanded references to $datadir and $sysconfdir

[Michael Gold]

Package: wireplumber-doc
Version: 0.5.2-3

Dear Maintainer,

The "Locations of WirePlumber’s files" page refers to $sysconfdir and
$datadir in several places, and says:
$syscondir and $datadir refer to meson’s directory options
[https://mesonbuild.com/Builtin-options.html#directories]
and are hardcoded at build time

/usr/share/doc/wireplumber/html/daemon/locations.html

On the meson page, searching for $datadir gives "share" as the location,
and one has to read the section above that to see it's relative to a
"prefix", which may be /usr, /usr/local, or something else.

This variability may be useful when the documentation's posted online.
When included in a binary package, I think it would be better to have
the variables pre-expanded.  In other words, replace every instance of
$datadir with /usr/share and $sysconfdir with /etc, and remove the
"meson's directory options" sentence.

- Michael


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.8.9-amd64 (SMP w/32 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- debconf-show failed



signature.asc
Description: PGP signature

Bug#1071457: wireplumber-doc: whether XDG variables have default values is not stated

[Michael Gold]

Package: wireplumber-doc
Version: 0.5.2-3

Dear Maintainer,

The "Locations of WirePlumber’s files" page refers to XDG environment
variables (such as $XDG_DATA_HOME) in several places, and links to the
specification.  However, it doesn't say what happens if one of those
variables is not set.  The specification says a default "should" be
used, which is to say that using a default is optional.

WirePlumber does seem to use the default values, and that should be
documented.

- Michael


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.8.9-amd64 (SMP w/32 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- debconf-show failed



signature.asc
Description: PGP signature

Bug#1071458: wireplumber-doc: "in order of priority" statements are unclear

[Michael Gold]

Package: wireplumber-doc
Version: 0.5.2-3

Dear Maintainer,

The "Locations of WirePlumber’s files" page is unclear about priority
in two places.  The page starts with this statement:
WirePlumber’s default locations of its configuration files are
the following, in order of priority:
1. $XDG_CONFIG_HOME/wireplumber
2. $XDG_CONFIG_DIRS/wireplumber
3. $sysconfdir/wireplumber
4. $XDG_DATA_DIRS/wireplumber
5. $datadir/wireplumber
[…]
At runtime, WirePlumber will seek out the directory with the highest
priority that contains the required configuration file.

/usr/share/doc/wireplumber/html/daemon/locations.html

Similar wording is used for "Location of scripts".  "Highest" could mean
numerically largest, closest to the top of the list, or something else.
I recommend changing this to something like "in descending order of
priority"; user files taking priority over system files makes sense, and
seems to be the behaviour.

The "DIR" environment variables, by contrast, are well explained:
If multiple directories are specified, the first one has the highest
priority and the last one has the lowest.

- Michael


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.8.9-amd64 (SMP w/32 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- debconf-show failed



signature.asc
Description: PGP signature

Bug#1065004: getmail6: prints spurious "handler called, but no children" warnings

[Michael Gold]

Package: getmail6
Version: 6.18.13-1
Severity: minor

Since upgrading from getmail6 6.18.11-2 to 6.18.13-1, I've been getting
this warning whenever getmail delivers a message:
  handler called, but no children

The message comes from the ForkingBase class, whose signal handler is
getting called for a SIGCHLD other than from the expected child.  Then
the expected SIGCHLD comes and is handled, waking up _wait_for_child().

I've attached a test case showing the problem.  Run as follows:
  cd getmailtest
  socat TCP6-LISTEN:1110,fork EXEC:./pop3 &
  getmail -g cfg/

I guess ForkingBase only exists to handle the "user" option, which I'm
not using.  Otherwise, forking would be unnecessary or could be handled
by Python's subprocess module--and as of Python 3.9, that module can do
the setreuid() and setregid() calls too.  It also supports a timeout,
which is the only justification I can see for messing around with the
process's SIGCHLD handler (if not for that, a simple waitpid() would
work).

Given that no timeout seems to be documented for filter and destination
classes, and it could cause problems for people not expecting it, I'm
inclined to call that a bug.  I've attached a patch that gets rid of the
handler and its timeout.
  ( To the extent possible under law, the author(s) have dedicated all
copyright and related and neighboring rights to this work to the
public domain worldwide.
See https://creativecommons.org/publicdomain/zero/1.0/legalcode )

I've done only trivial testing on the patched version.  As hinted above,
a cleaner fix would be to delete all this code and use the subprocess
module (or os.seteuid() and such for cases not requiring a sub-process).

- Michael


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.6.15-amd64 (SMP w/32 CPU threads; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages getmail6 depends on:
ii  python3  3.11.6-1

getmail6 recommends no packages.

getmail6 suggests no packages.

-- no debconf information


getmailtest.tar.gz
Description: Binary data
diff --git a/getmail b/getmail
index 58ad52b0353e..821cfb22f579 100755
--- a/getmail
+++ b/getmail
@@ -643,6 +643,8 @@ No other entry is `Unseen`, i.e. `-s,` means 
`imap_search,imap_on_delete=Unseen,
 s += '%s="%s"' % (attr, pprint.pformat(getattr(options, attr)))
 log.debug('parsed options:  %s\n' % s)
 
+signal.signal(signal.SIGCHLD, signal.SIG_DFL)
+
 imap_override = {}
 flags,search = imap_search_flags(options.override_imap)
 if flags:
diff --git a/getmailcore/baseclasses.py b/getmailcore/baseclasses.py
index cc2ed948c59d..d081926de25d 100755
--- a/getmailcore/baseclasses.py
+++ b/getmailcore/baseclasses.py
@@ -403,60 +403,28 @@ class ForkingBase(object):
 log - an object of type getmailcore.logging.Logger()
 
 '''
-def _child_handler(self, sig, stackframe):
-def notify():
-self.__child_exited.acquire()
-self.__child_exited.notify_all()
-self.__child_exited.release()
-self.log.trace('handler called for signal %s' % sig)
+
+def _wait_for_child(self, child_pid):
 try:
-pid, r = os.waitpid(self.child.childpid,0)
+pid, status = os.waitpid(child_pid, 0)
 except OSError as o:
-# No children on SIGCHLD.  Can't happen?
-self.log.warning('handler called, but no children (%s)' % o)
-notify()
+self.log.warning('waitpid() failed (%s)' % o)
 return
-if self.__orig_handler:
-signal.signal(signal.SIGCHLD, self.__orig_handler)
-self.__child_pid = pid
-self.__child_status = r
-self.log.trace('handler reaped child %s with status %s' % (pid, r))
-notify()
-
-def _prepare_child(self):
-self.log.trace('')
-self.__child_exited = Condition()
-self.__child_pid = 0
-self.__child_status = None
-self.__orig_handler = None
-self.__orig_handler = signal.signal(signal.SIGCHLD, 
self._child_handler)
-
-def _wait_for_child(self, childpid):
-self.__child_exited.acquire()
-if self.__child_exited.wait(socket.getdefaulttimeout() or 60) == 
False: # py2, 

signature.asc
Description: PGP signature

Bug#1063930: bwrap --dev prevents mount commands from working

[Michael Gold]

Package: bubblewrap
Version: 0.8.0-2

When the --dev option is used, the 'mount' command cannot be used inside
the container, even when permissions would appear to allow it.  A script
that demonstrates this is attached:
$ ./bwrap-test.sh
bash-5.2$ mount -t tmpfs x /tmp
mount: /tmp: must be superuser to use mount.
   dmesg(1) may have more information after failed mount system 
call.
bash-5.2$ exit
exit
$ ./bwrap-test.sh -a
bash-5.2$ mount -t tmpfs x /tmp
bash-5.2$ exit
exit
$ 

When "-a" is used, "--dev-bind /dev /dev" replaces "--dev /dev", and the
"mount" command works.  This is kind of the opposite of what I'd expect,
as --dev seems safer than a full --dev-bind.  Nothing is logged to dmesg
either way.

A work-around is to use something like "--dev-bind /dev /real-dev", then
bind-mount chosen devices to a new /dev tree before unmounting /real-dev
("umount --no-mtab --lazy /real-dev" seems to work).

- Michael


-- Package-specific info:
Permissions of /usr/bin/bwrap:
-rwxr-xr-x 1 root root 72080 Feb 28  2023 /usr/bin/bwrap
/etc/sysctl.d/*-bubblewrap.conf:
cat: '/etc/sysctl.d/*-bubblewrap.conf': No such file or directory
/usr/lib/sysctl.d/50-bubblewrap.conf:
# Enable unprivileged creation of new user namespaces in older Debian
# kernels.
#
# If this is not desired, copy this file to
# /etc/sysctl.d/50-bubblewrap.conf and change the value of this parameter
# to 0, then use dpkg-statoverride to make /usr/bin/bwrap setuid root.
#
# For more details see https://deb.li/bubblewrap or
# /usr/share/doc/bubblewrap/README.Debian
kernel.unprivileged_userns_clone=1
/proc/sys/kernel/unprivileged_userns_clone:
1
/proc/sys/user/max_cgroup_namespaces:
256640
/proc/sys/user/max_ipc_namespaces:
256640
/proc/sys/user/max_mnt_namespaces:
256640
/proc/sys/user/max_net_namespaces:
256640
/proc/sys/user/max_pid_namespaces:
256640
/proc/sys/user/max_time_namespaces:
256640
/proc/sys/user/max_user_namespaces:
256640
/proc/sys/user/max_uts_namespaces:
256640

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.6.15-amd64 (SMP w/32 CPU threads; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages bubblewrap depends on:
ii  libc62.37-15
ii  libcap2  1:2.66-5
ii  libselinux1  3.5-2

Versions of packages bubblewrap recommends:
ii  procps  2:4.0.4-4

bubblewrap suggests no packages.

-- no debconf information
#!/bin/sh
set -e  #errexit
set -u  #nounset

alt_dev=0
while getopts 'a' opt
do
case "$opt" in
a) alt_dev=1;;
\? | *) exit 2;;
esac
done
shift "$((OPTIND - 1))"

if test "$#" -ne 0
then
printf 'Usage: %s [-a]\n' "${0##*/}" >&2
exit 2
fi

set -- bwrap
set -- "$@" --unshare-pid
set -- "$@" --cap-add CAP_DAC_OVERRIDE
set -- "$@" --cap-add CAP_SETPCAP
set -- "$@" --cap-add CAP_SYS_ADMIN
set -- "$@" --ro-bind /usr/ /usr
set -- "$@" --setenv PATH /usr/bin
set -- "$@" --symlink /usr/lib/ /lib
set -- "$@" --symlink /usr/lib64/ /lib64
set -- "$@" --proc /proc
set -- "$@" --dir /tmp

if test "$alt_dev" -eq 0
then
# this prevents future 'mount' calls...
set -- "$@" --dev /dev
else
# ...but this does not
set -- "$@" --dev-bind /dev/ /dev
fi

#printf '%s\n' "$*"
"$@" -- /usr/bin/bash


signature.asc
Description: PGP signature

Bug#1063931: "strace -f" gets an infinite SIGSEGV loop if namespace PID 1 calls abort()

[Michael Gold]

Package: strace
Version: 6.5-0.1

When the process being strace'd is PID 1 in a PID namespace and calls
abort(), strace shows an infinite SIGSEGV loop.  Here's a test case:
#include 
int main() { abort(); }

With glibc, running "unshare -prf ./a.out" results in the process dying
from a segmentation fault.

By contrast, "strace -f unshare -prf ./a.out" produces an infinite loop
of segfaults.  Perhaps this could be considered a bug in glibc or Linux,
but it seems less than ideal that strace loops forever in a case where
the non-strace'd process would have died.

If strace is capable of detecting that the traced process has no handler
for the signal, it would be nice to detect and avoid the loop.

- Michael


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.6.13-amd64 (SMP w/32 CPU threads; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages strace depends on:
ii  libc6   2.37-15
ii  libunwind8  1.6.2-3

strace recommends no packages.

strace suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1063728: keyboard-configuration: format of XKBOPTIONS not specified

[Michael Gold]

Package: keyboard-configuration
Version: 1.226
Severity: minor

Dear Maintainer,

/etc/default/keyboard refers to "the keyboard(5) manual page", which
says:
  XKBOPTIONS
Specifies the XKB keyboard option components. Options usually
relate to the behavior of the special keys (, ,
, , etc.) Default: not set.

This does not say how multiple options should be separated.  Luckily,
there are examples suggesting the value can be a comma-separated list
with no whitespace.

The actual expectations should be stated explicitly, and the same goes
for XKBVARIANT.

- Michael


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.6.13-amd64 (SMP w/32 CPU threads; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages keyboard-configuration depends on:
ii  debconf [debconf-2.0]   1.5.85
ii  liblocale-gettext-perl  1.07-6+b1
ii  xkb-data2.41-1

keyboard-configuration recommends no packages.

keyboard-configuration suggests no packages.

Versions of packages console-setup depends on:
ii  console-setup-linux1.226
ii  debconf [debconf-2.0]  1.5.85
ii  xkb-data   2.41-1

Versions of packages console-setup suggests:
ii  locales2.37-15
ii  sysvinit-utils [lsb-base]  3.08-6

Versions of packages console-setup-linux depends on:
ii  init-system-helpers  1.66
ii  kbd  2.6.4-2

Versions of packages console-setup-linux suggests:
ii  console-setup  1.226

Versions of packages keyboard-configuration is related to:
pn  console-common
pn  console-data  
pn  console-tools 
pn  gnome-control-center  
ii  kbd   2.6.4-2
ii  systemd   255.3-2

-- debconf information:
  keyboard-configuration/unsupported_options: true
  console-setup/fontsize-text47: 8x16
  console-setup/guess_font:
  console-setup/fontsize-fb47: 8x16
  console-setup/store_defaults_in_debconf_db: true
* keyboard-configuration/model: Generic 105-key PC
* keyboard-configuration/store_defaults_in_debconf_db: true
* keyboard-configuration/switch: No temporary switch
  keyboard-configuration/unsupported_config_layout: true
* keyboard-configuration/layout:
  console-setup/charmap47: UTF-8
* keyboard-configuration/compose: No compose key
  keyboard-configuration/unsupported_layout: true
  console-setup/use_system_font:
  console-setup/fontface47: Fixed
  console-setup/framebuffer_only:
* keyboard-configuration/layoutcode: us
* keyboard-configuration/toggle: No toggling
* keyboard-configuration/xkb-keymap: us(dvorak)
* keyboard-configuration/altgr: The default for the keyboard layout
  console-setup/codeset47: # Latin1 and Latin5 - western Europe and Turkic 
languages
  console-setup/codesetcode: Lat15
* keyboard-configuration/other:
  debian-installer/console-setup-udeb/title:
* keyboard-configuration/variantcode: dvorak
* keyboard-configuration/modelcode: pc105
* keyboard-configuration/variant: English (US) - English (Dvorak)
  console-setup/fontsize: 8x16
  keyboard-configuration/ctrl_alt_bksp: false
* keyboard-configuration/optionscode: ctrl:swapcaps
  keyboard-configuration/unsupported_config_options: true


signature.asc
Description: PGP signature

Bug#1063725: xkb-data: keymap alias 'dvorak' no longer available

[Michael Gold]

Package: xkb-data
Version: 2.41-1

Dear Maintainer,

I noticed a "setxkbmap dvorak" command, run by my X session scripts,
starting giving an error with the latest xkb-data:
Error loading new keyboard description

It started after upgrading the following 4 packages together:
console-setup:amd64 (1.223, 1.226)
console-setup-linux:amd64 (1.223, 1.226)
xkb-data:amd64 (2.38-2, 2.41-1),
keyboard-configuration:amd64 (1.223, 1.226)
(The xkb-data changes look the most substantial, which is why I've filed
against that package.)

My keyboard layout was still as expected, but downgrading those packages
to the versions from 'testing' eliminated the error.

Here's the output of "setxkbmap -verbose 10 -print dvorak" with 2.38-2:
Setting verbose level to 10
locale is C
Warning! Multiple definitions of keyboard layout
 Using command line, ignoring X server
Trying to load rules file ./rules/evdev...
Trying to load rules file /usr/share/X11/xkb/rules/evdev...
Success.
Applied rules from evdev:
rules:  evdev
model:  pc105
layout: dvorak
options:ctrl:swapcaps,compose:menu
Trying to build keymap using the following components:
keycodes:   evdev+aliases(qwerty)
types:  complete
compat: complete
symbols:pc+us(dvorak)+inet(evdev)+ctrl(swapcaps)+compose(menu)
geometry:   pc(pc105)
xkb_keymap {
xkb_keycodes  { include "evdev+aliases(qwerty)" };
xkb_types { include "complete"  };
xkb_compat{ include "complete"  };
xkb_symbols   { include 
"pc+us(dvorak)+inet(evdev)+ctrl(swapcaps)+compose(menu)"};
xkb_geometry  { include "pc(pc105)" };
};

And with 2.41-1:
Setting verbose level to 10
locale is C
Warning! Multiple definitions of keyboard layout
 Using command line, ignoring X server
Trying to load rules file ./rules/evdev...
Trying to load rules file /usr/share/X11/xkb/rules/evdev...
Success.
Applied rules from evdev:
rules:  evdev
model:  pc105
layout: dvorak
options:ctrl:swapcaps,compose:menu
Trying to build keymap using the following components:
keycodes:   evdev+aliases(qwerty)
types:  complete
compat: complete
symbols:pc+dvorak+inet(evdev)+ctrl(swapcaps)+compose(menu)
geometry:   pc(pc105)
xkb_keymap {
xkb_keycodes  { include "evdev+aliases(qwerty)" };
xkb_types { include "complete"  };
xkb_compat{ include "complete"  };
xkb_symbols   { include 
"pc+dvorak+inet(evdev)+ctrl(swapcaps)+compose(menu)"};
xkb_geometry  { include "pc(pc105)" };
};

The contents of /etc/default/keyboard:
# KEYBOARD CONFIGURATION FILE

# Consult the keyboard(5) manual page.

XKBMODEL="pc105"
XKBLAYOUT="us"
XKBVARIANT="dvorak"
XKBOPTIONS="ctrl:swapcaps"

BACKSPACE="guess"

My X session was configured to run this command at startup:
setxkbmap -option 'ctrl:swapcaps' -option 'compose:menu' dvorak

After looking at the above output, I changed "dvorak" to "us(dvorak)" in
the command, and it worked without error.

It's not clear whether support for just "dvorak" was dropped on purpose,
but I don't recall seeing any deprecation warnings about it, and don't
see any relevant Debian changelog or "NEWS" entry.

- Michael


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.6.13-amd64 (SMP w/32 CPU threads; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- no debconf information


signature.asc
Description: PGP signature

Bug#1060651: mc: doesn't fully resize itself if reading directory while terminal's resized

[Michael Gold]

On Sat, Jan 13, 2024 at 04:47:00 +, Michael Gold wrote:
> Simply sticking a "return" at the top of rotate_dash() makes the problem
> unreproducible, and gives me a PASS from the test case.

Setting g->winch_pending in group_init() also works, and I don't imagine
it would have any negative effect.

-- Michael


signature.asc
Description: PGP signature

Bug#1060651: mc: doesn't fully resize itself if reading directory while terminal's resized

[Michael Gold]

On Fri, Jan 12, 2024 at 03:07:04 +, Michael Gold wrote:
> I sometimes notice this if I navigate into a large directory, and resize
> the window while the "spinner" is animating at the top-right corner.  It
> can be difficult to reproduce once Linux has the data cached.

It looks like the spinner--rotate_dash()--is actually the culprit.  That
calls mc_refresh(), which empties sigwinch_pipe before do_nc() makes its
first dlg_run() call:
(gdb) bt
#0  tty_flush_winch () at ./lib/tty/tty.c:224
#1  0x556567fb in dialog_change_screen_size () at 
./lib/widget/dialog-switch.c:426
#2  0x55656781 in mc_refresh () at 
./lib/widget/dialog-switch.c:411
#3  0x5558f98e in rotate_dash (show=1) at 
./src/filemanager/layout.c:1087
#4  0x5559995c in panel_dir_list_callback (state=DIR_READ, 
data=0x55704ac0) at ./src/filemanager/panel.c:4359
#5  0x555fdff7 in dir_list_load (list=0x55801688, 
vpath=0x557f5020, sort=0x555fccec , sort_op=0x55801760, 
filter=0x558017c0) at ./src/filemanager/dir.c:670
#6  0x5559a1b7 in panel_sized_with_dir_new 
(panel_name=0x556784aa "New Right Panel", y=0, x=0, lines=0, cols=0, 
vpath=0x0) at ./src/filemanager/panel.c:4612
#7  0x5558d975 in panel_sized_new (panel_name=0x556784aa 
"New Right Panel", y=0, x=0, lines=0, cols=0) at 
../../src/filemanager/panel.h:272
#8  0x5558ed29 in restore_into_right_dir_panel (idx=1, 
last_was_panel=0, y=0, x=0, lines=0, cols=0) at ./src/filemanager/layout.c:668
#9  0x5558fca3 in create_panel (num=1, type=view_listing) at 
./src/filemanager/layout.c:1189
#10 0x5558279a in create_panels () at 
./src/filemanager/filemanager.c:658
#11 0x55582ee3 in create_file_manager () at 
./src/filemanager/filemanager.c:911
#12 0x55584bed in do_nc () at 
./src/filemanager/filemanager.c:1840
#13 0x55570a92 in main (argc=1, argv=0x7fffe248) at 
./src/main.c:458
(gdb) 

It's dlg_run() that will put the file browser into the top_dlg list; but
top_dlg is still empty in the above backtrace, so no MSG_RESIZE messages
are sent.  If SIGWINCH comes at the "expected" time, I see this:
(gdb) bt
#0  send_message (w=0x557f5a80, sender=0x0, msg=MSG_RESIZE, parm=0, 
data=0x0) at ../../lib/widget/widget-common.h:250
#1  0x55655e79 in dialog_switch_resize (d=0x557f5a80) at 
./lib/widget/dialog-switch.c:136
#2  0x556568cc in dialog_change_screen_size () at 
./lib/widget/dialog-switch.c:447
#3  0x55657020 in frontend_dlg_run (h=0x557f5a80) at 
./lib/widget/dialog.c:293
#4  0x55657ac2 in dlg_run (h=0x557f5a80) at 
./lib/widget/dialog.c:574
#5  0x55584bff in do_nc () at 
./src/filemanager/filemanager.c:1841
#6  0x55570a92 in main (argc=1, argv=0x7fffe248) at 
./src/main.c:458
(gdb) 

Simply sticking a "return" at the top of rotate_dash() makes the problem
unreproducible, and gives me a PASS from the test case.  Something like
a global 'is_ready' flag might be a better way to do it; or just ensure
dialog_change_screen_size() doesn't flush the pipe if the dialog list is
empty.

While debugging this, I noticed a related bug in toggle_subshell(),
which has this code:
was_sigwinch = tty_got_winch ();
tty_flush_winch ();

If a SIGWINCH were handled after setting was_sigwinch to 0 but before
flushing the pipe, the SIGWINCH would be missed.  I never saw it happen,
but it could be easily fixed by replacing that code with:
was_sigwinch = tty_flush_winch ();
and making that function return the appropriate boolean value.

-- Michael


signature.asc
Description: PGP signature

Bug#1060651: mc: doesn't fully resize itself if reading directory while terminal's resized

[Michael Gold]

On Fri, Jan 12, 2024 at 03:07:04 +, Michael Gold wrote:
> I'm experimenting with an automated version of this test, but don't know
> how reliable it will be.

The attached test case seems able to determine the width of the panels.
Without proper xterm-control and UTF-8 parsing, it may be fragile.

To build and run:
  gcc -shared -o readdir-wait.so readdir-wait.c
  gcc mc-terminal-resize-during-readdir.c
  ./a.out
Or run "./a.out -P" to skip the $LD_PRELOAD setting, in which case the
signal isn't likely to come during readdir() and we'll measure a width
of 90 columns, as expected.  So, I suspect it will print "PASS" if the
bug is fixed, but I don't know for sure.

-- Michael
// Verify that mc resizes its panel(s) properly when the terminal is resized.
// See https://bugs.debian.org/1060651#.

/*
This is free and unencumbered software released into the public domain.

Anyone is free to copy, modify, publish, use, compile, sell, or
distribute this software, either in source code form or as a compiled
binary, for any purpose, commercial or non-commercial, and by any
means.

In jurisdictions that recognize copyright laws, the author or authors
of this software dedicate any and all copyright interest in the
software to the public domain. We make this dedication for the benefit
of the public at large and to the detriment of our heirs and
successors. We intend this dedication to be an overt act of
relinquishment in perpetuity of all present and future rights to this
software under copyright law.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
IN NO EVENT SHALL THE AUTHORS BE LIABLE FOR ANY CLAIM, DAMAGES OR
OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
OTHER DEALINGS IN THE SOFTWARE.

For more information, please refer to <https://unlicense.org/>
*/

#define _POSIX_C_SOURCE 200809L
#define _XOPEN_SOURCE 700
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 


struct measurer_arg {
int pty_master;
unsigned saw_width;
};

static void
die_perror(const char *str)
{
perror(str);
exit(EXIT_FAILURE);
}

static void
die_usage(const char *name)
{
fprintf(stderr, "Usage: %s\n", name);
exit(2);
}

static unsigned
utf8_measure_badly(const uint8_t *p)
{
// this is just good enough to parse mc's output, at the time of
// writing; we don't want any embedded control sequences, double-width
// or combining characters, or any other weird surprises
int ret = 0;
for (; *p; p++) {
if (*p >= 240) --ret;
if (*p >= 224) --ret;
if (*p >= 192) --ret;
++ret;
}
return (ret < 0) ? 0 : (unsigned)ret;
}

static unsigned
measure_panel_width(const uint8_t *buf)
{
// find the last instance of U+2514 BOX DRAWINGS LIGHT UP AND RIGHT
// (at the bottom-left corner of the rightmost panel) before mc exited
const uint8_t *u2514 = "\xe2\x94\x94";
uint8_t *p;

p = (uint8_t*)strstr((char*)buf, u2514);
while (p) {
uint8_t *q = (uint8_t*)strstr((char*)[1], u2514);
if (!q) break;
p = q;
}
if (!p) {
return 0;
}

// rewind to the last control character
while ((p > buf) && (*p >= 32)) {
--p;
}

// if at an escape sequence, move to its end
if (*p == '\x1b') {
while (*p && !isalpha((int)*p) ) {
++p;
}
}
++p;

// p should now be pointing at the beginning of the panel-bottom-drawing
// sequence.  We assume mc draws the bottom of all visible panels as one
// uninterrupted sequence.

// cut at the end of the line, or an escape sequence
{
char *dummy;
strtok_r((char*)p, "\r\n\x1b", );
}
return utf8_measure_badly(p);
}

static void*
measurer(void *arg_)
{
struct measurer_arg *arg = arg_;
int err = 0;
ssize_t rv;
size_t bufsize = 1024 * 1024, i = 0;

uint8_t *buf = malloc(bufsize);
if (!buf) {
die_perror("malloc");
}

while (i < bufsize - 1) {
rv = read(arg->pty_master, [i], bufsize - 1 - i);
if (rv < 0) {
// On Linux, we get EIO when mc exits
if (EIO == errno) break;
die_perror("measurer:read");
} else if (!rv) {
  

Bug#1060456: rxvt-unicode: 9.31-1+b1 breaks UTF-8 display

[Michael Gold]

On Thu, Jan 11, 2024 at 23:06:05 +0100, gregor herrmann wrote:
> I've rebuilt rxvt-unicode with this patch and I can confirm that it
> seems to work for all cases I've suffered from before.

Thanks Sven and gregor.

> I think a quick upload would be good to spare all the people running
> unstable & updating perl to 5.38 in the next hours the troubles :)

For anyone hitting this before the fix is ready, I had no trouble at all
with an "apt install rxvt-unicode/testing".  (I didn't have to downgrade
any of the perl libraries.)

-- Michael


signature.asc
Description: PGP signature

Bug#1060651: mc: doesn't fully resize itself if reading directory while terminal's resized

[Michael Gold]

Package: mc
Version: 3:4.8.30-1

Dear Maintainer,

If a terminal window's resized at a "bad time", mc's panels seem to keep
their old sizes indefinitely--even I press CTRL-L or navigate to another
directory.  Oddly, the command bar at the bottom of the screen ("1Help",
etc.) does seem to be drawn with the proper width, but not on the proper
line.  The rest of the interface doesn't react at all.

I sometimes notice this if I navigate into a large directory, and resize
the window while the "spinner" is animating at the top-right corner.  It
can be difficult to reproduce once Linux has the data cached.

I've had some luck using an LD_PRELOAD library that hooks readdir() with
a usleep() call inserted.  I'll attach that.  To use it:
gcc -shared -o readdir-usleep.so readdir-usleep.c
export LD_PRELOAD="$(pwd)/readdir-usleep.so"
cd /var/lib  # or something with about 50 files
mc
When mc clears the screen and starts animating the "/" at the top-right,
enlarge the terminal window.  I'm using urxvt (rxvt-unicode).

I'm experimenting with an automated version of this test, but don't know
how reliable it will be.

- Michael


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.6.9-amd64 (SMP w/32 CPU threads; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages mc depends on:
ii  libc6 2.37-13
ii  libext2fs21.47.0-2+b1
ii  libglib2.0-0  2.78.3-1
ii  libgpm2   1.20.7-10+b2
ii  libslang2 2.3.3-3
ii  libssh2-1 1.11.0-4
ii  mc-data   3:4.8.30-1

Versions of packages mc recommends:
ii  mailcap 3.70+nmu1
ii  perl5.38.2-2
ii  sensible-utils  0.0.20
ii  unzip   6.0-28

Versions of packages mc suggests:
pn  arj  
ii  atril [pdf-viewer]   1.26.1-3
ii  bzip21.0.8-5+b2
pn  dbview   
pn  djvulibre-bin
ii  epub-utils   0.2.2-6
ii  evince [pdf-viewer]  45.0-1+b1
ii  file 1:5.45-2+b1
ii  genisoimage  9:1.1.11-3.4
ii  gv [pdf-viewer]  1:3.7.4-2+b1
ii  imagemagick  8:6.9.12.98+dfsg1-5+b1
ii  imagemagick-6.q16 [imagemagick]  8:6.9.12.98+dfsg1-5+b1
ii  libaspell-dev0.60.8.1-1+b1
ii  links2.29-1+b1
ii  lynx 2.9.0dev.12-1
ii  mupdf [pdf-viewer]   1.23.7+ds1-1
pn  odt2txt  
ii  poppler-utils22.12.0-2+b1
pn  python   
pn  python-boto  
pn  python-tz
ii  texlive-binaries 2023.20230311.66589-8
ii  unar 1.10.7+ds1+really1.10.1-2+b3
pn  wimtools 
ii  zip  3.0-13

-- no debconf information

#define _GNU_SOURCE// make dlfcn.h define RTLD_NEXT
#include 
#include 
#include 
#include 

struct dirent *
readdir(DIR *dirp)
{
struct dirent *ret = NULL;
struct dirent *(*real_fn)(DIR*);

usleep(10);

real_fn = dlsym(RTLD_NEXT, __func__);
if (!real_fn) {
errno = ELIBACC;
goto out;
}
ret = real_fn(dirp);
out:
return ret;
}


signature.asc
Description: PGP signature

Bug#1060456: rxvt-unicode: 9.31-1+b1 breaks UTF-8 display

[Michael Gold]

Package: rxvt-unicode
Version: 9.31-1+b1
Severity: important

Dear Maintainer,

After upgrading rxvt-unicode today, it's no longer displaying UTF-8
properly.  /var/log/apt/history.log shows:
  Upgrade: rxvt-unicode:amd64 (9.31-1, 9.31-1+b1)

I still have an old window open, in which this command:
  printf '\xe2\x80\x94\n'
properly produces an EM DASH (U+2014); in the newer version, it produces
U+00E2 LATIN SMALL LETTER A WITH CIRCUMFLEX.

Another simple test is to run "mc" and note that all the box-drawing
characters are corrupted.

- Michael


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.6.9-amd64 (SMP w/32 CPU threads; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages rxvt-unicode depends on:
ii  base-passwd   3.6.3
ii  libc6 2.37-13
ii  libfontconfig12.14.2-6+b1
ii  libgcc-s1 13.2.0-9
ii  libgdk-pixbuf-2.0-0   2.42.10+dfsg-3
ii  libglib2.0-0  2.78.3-1
ii  libperl5.38   5.38.2-2
ii  libptytty02.0-1+b1
ii  libstartup-notification0  0.12-6+b1
ii  libx11-6  2:1.8.7-1
ii  libxext6  2:1.3.4-1+b1
ii  libxft2   2.3.6-1
ii  libxmu6   2:1.1.3-3
ii  libxrender1   1:0.9.10-1.1
ii  ncurses-base  6.4+20231209-1
ii  ncurses-term  6.4+20231209-1

Versions of packages rxvt-unicode recommends:
ii  fonts-dejavu  2.37-8
ii  fonts-ipafont-gothic [fonts-japanese-gothic]  00303-23
ii  fonts-vlgothic [fonts-japanese-gothic]20220612-1

Versions of packages rxvt-unicode suggests:
ii  sensible-utils  0.0.20

-- no debconf information



signature.asc
Description: PGP signature

Bug#1060039: lirc: atilibusb driver no longer present

[Michael Gold]

Package: lirc
Version: 0.10.2-0.2

Dear Maintainer,

My remote control wasn't working today, and I saw this error in my logs:
lircd[117053]: Driver `atilibusb' not found or not loadable (wrong or missing 
-U/--plugindir?).

I suspect this may be related to bug #810445; however, the package still
ships /usr/share/lirc/configs/atilibusb.conf, and the source package has
the driver code, so I'm not sure why the binary is missing.  I don't see
anything in the changelog about it.

- Michael


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.6.9-amd64 (SMP w/32 CPU threads; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lirc depends on:
ii  libasound2   1.2.10-3
ii  libc62.37-13
ii  libftdi1-2   1.5-6+b3
ii  libgcc-s113.2.0-9
ii  liblirc-client0  0.10.2-0.2
ii  liblirc0 0.10.2-0.2
ii  libportaudio219.6.0-1.2
ii  libstdc++6   13.2.0-9
ii  libsystemd0  255.2-3
ii  libusb-1.0-0 2:1.0.26-1
ii  python3  3.11.6-1

Versions of packages lirc recommends:
pn  gir1.2-vte-2.91  
ii  python3-gi   3.46.0-3
pn  python3-yaml 
ii  systemd  255.2-3

Versions of packages lirc suggests:
pn  ir-keytable  
pn  lirc-compat-remotes  
ii  lirc-doc 0.10.2-0.2
pn  lirc-drv-irman   
pn  lirc-x   
pn  setserial


signature.asc
Description: PGP signature

Bug#1056764: grub-efi-amd64: can't boot with GRUB 2.12~rc1-12

[Michael Gold]

On Sun, Nov 26, 2023 at 09:01:12 +, Mate Kukri wrote:
> The mechanism used to load the kernel has changed from GRUB 2.06 to
> GRUB 2.12, it is possible that there are unfortunate bugs in either in
> GRUB and/or your firmware that is stopping the new mechanism from
> loading the kernel.

Just as a point of comparison, I updated a Lenovo ThinkPad T470 from
2.12~rc1-11 to 2.12~rc1-12 today, and didn't see any trouble.

The boot log shows "Kernel is locked down from EFI Secure Boot", and the
initial system installation was done in January 2023 with 2.06-3~deb11u5
as the GRUB version (from "installer build 20210731+deb11u7+b1").

-- Michael


signature.asc
Description: PGP signature

Bug#1057738: chrony: use cached or "fallback" IP addresses on DNS failure

[Michael Gold]

Package: chrony
Version: 4.5-1
Severity: wishlist

Dear Maintainer,

I saw this change in the 4.4 release notes:
* Refresh address of NTP sources periodically

That made me think it could also be useful to support some "pre-seeding"
and/or caching of DNS results.  I usually configure a few sources via IP
addresses, just in case DNS is slow or unavailable at boot time (perhaps
DNSSEC is failing due to a terribly inaccurate clock).  But IP addresses
could change without me noticing, and some server operators request that
DNS be used whenever possible.

Maybe it should be possible to specify fallback addresses, to be used in
the case of a temporary lookup failure; for example,
  server ntp.example.net ip=2001:db8::7b ip=192.0.2.123

And I've already got .nts files in /var/lib/chrony for serveral sources,
which makes me think there could also be files caching the last-known IP
addresses for each server (possibly with expiry times and enabled via an
option such as "cacheaddr").  For servers with NTS, that data appears to
already be available.

- Michael


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.5.0-5-amd64 (SMP w/32 CPU threads; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages chrony depends on:
ii  adduser  3.137
ii  init-system-helpers  1.66
ii  iproute2 6.6.0-1
ii  libc62.37-13
ii  libcap2  1:2.66-4
ii  libedit2 3.1-20230828-1
ii  libgnutls30  3.8.2-1
ii  libnettle8   3.9.1-2
ii  libseccomp2  2.5.4-2+b1
ii  tzdata-legacy2023c-11
ii  ucf  3.0043+nmu1

chrony recommends no packages.

Versions of packages chrony suggests:
ii  bind9-dnsutils [dnsutils]  1:9.19.17-1
pn  networkd-dispatcher

-- no debconf information


signature.asc
Description: PGP signature

Bug#1057012: prlimit crashes when given unacceptable values

[Michael Gold]

Package: util-linux
Version: 2.39.2-6

Dear Maintainer,

prlimit crashes with a segmentation fault when given an unacceptable
value:
  $ prlimit --data=1073741824 printf 'hello\n'
  hello
  $ prlimit --data=0x4000 printf 'hello\n'
  Segmentation fault
  $ 

It should cleanly reject unacceptable values with an error message.

This relates to my previous bug report about acceptable value formats
being undocumented:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057011

- Michael


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.5.0-4-amd64 (SMP w/32 CPU threads; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages util-linux depends on:
ii  libblkid1  2.39.2-6
ii  libc6  2.37-12
ii  libcap-ng0 0.8.3-1+b3
ii  libcrypt1  1:4.4.36-2
ii  libmount1  2.39.2-6
ii  libpam0g   1.5.2-9.1
ii  libselinux13.5-1
ii  libsmartcols1  2.39.2-6
ii  libsystemd0255~rc3-2
ii  libtinfo6  6.4+20231121-1
ii  libudev1   255~rc3-2
ii  libuuid1   2.39.2-6
ii  zlib1g 1:1.3.dfsg-3

Versions of packages util-linux recommends:
ii  sensible-utils  0.0.20

Versions of packages util-linux suggests:
ii  dosfstools  4.2-1
ii  kbd 2.5.1-1+b1
ii  util-linux-extra2.39.2-6
ii  util-linux-locales  2.39.2-6

-- no debconf information


signature.asc
Description: PGP signature

Bug#1057011: prlimit manual page should list units

[Michael Gold]

Package: util-linux
Version: 2.39.2-6
Severity: wishlist

Dear Maintainer,

The prlimit manual page lists the options that can be used to configure
limits, but doesn't say what units are used for each or what forms of
value are acceptable (for example: decimal, hexadecimal, or whether any
suffixes like "G" are accepted).  It should.

Running prlimit without any arguments will list units for each setting,
but that's not an obvious thing to try.

- Michael


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.5.0-4-amd64 (SMP w/32 CPU threads; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages util-linux depends on:
ii  libblkid1  2.39.2-6
ii  libc6  2.37-12
ii  libcap-ng0 0.8.3-1+b3
ii  libcrypt1  1:4.4.36-2
ii  libmount1  2.39.2-6
ii  libpam0g   1.5.2-9.1
ii  libselinux13.5-1
ii  libsmartcols1  2.39.2-6
ii  libsystemd0255~rc3-2
ii  libtinfo6  6.4+20231121-1
ii  libudev1   255~rc3-2
ii  libuuid1   2.39.2-6
ii  zlib1g 1:1.3.dfsg-3

Versions of packages util-linux recommends:
ii  sensible-utils  0.0.20

Versions of packages util-linux suggests:
ii  dosfstools  4.2-1
ii  kbd 2.5.1-1+b1
ii  util-linux-extra2.39.2-6
ii  util-linux-locales  2.39.2-6

-- no debconf information


signature.asc
Description: PGP signature

Bug#1057010: open(2) should document ENOENT for trying to create file in deleted directory

[Michael Gold]

Package: manpages-dev
Version: 6.03-2

Dear Maintainer,

'man 2 open' lists 3 cases in which ENOENT can be returned:
   ENOENT O_CREAT is not set and the named file does not exist.
   ENOENT A directory component in pathname does not exist or is a
  dangling symbolic link.
   ENOENT pathname refers to a nonexistent directory, O_TMPFILE and one
  of O_WRONLY or O_RDWR were specified in flags, but this kernel
  version does not provide the O_TMPFILE functionality.

I suggest another be listed:
   ENOENT The directory in which the file is to be created no longer
  exists.
(Or the second case could be re-worded to cover that.)

A simple test shows it can happen:
   $ mkdir foo
   $ cd foo
   $ rmdir ../foo
   $ touch bar
   touch: cannot touch 'bar': No such file or directory
   $ 

strace shows:
   openat(AT_FDCWD, "bar", O_WRONLY|O_CREAT|O_NOCTTY|O_NONBLOCK, 0666)
= -1 ENOENT (No such file or directory)
And POSIX requires openat(AT_FDCWD, ...) to be identical to open(...).

O_CREAT was set, pathname included no directory component, and O_TMPFILE
was not used--so ENOENT did not correspond to anything listed.  The same
result occurs if AT_FDCWD is replaced by a file descriptor for "foo"; in
both cases, though, pathnames such as "../bar" still work.

- Michael


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.5.0-4-amd64 (SMP w/32 CPU threads; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages manpages-dev depends on:
ii  manpages  6.03-2

manpages-dev recommends no packages.

Versions of packages manpages-dev suggests:
ii  man-db [man-browser]  2.12.0-1

-- no debconf information


signature.asc
Description: PGP signature

Bug#699710: socat wishlist item: please support Linux IP-level IP_TRANSPARENT option

[Michael Gold]

On Sun, Feb 03, 2013 at 23:15:19 +0100, David Madore wrote:
> Linux has an IP-level (level=SOL_IP) socket option called
> IP_TRANSPARENT, which allows binding on a non-local address (with
> superuser privileges) to implement transparent proxy support.  It
> would be useful if socat could have an option to reflect this.

I've been successfully using socat's "ip-transparent" option to test
some "tproxy" nftables rules.  I think this is what you were asking for,
and is in Debian package version 1.7.4.4-2.

-- Michael


signature.asc
Description: PGP signature

Bug#1056361: socat: should provide a way to wait until a listening socket is ready

[Michael Gold]

Package: socat
Version: 1.7.4.4-2
Severity: wishlist

While there are several ways to create listening sockets via socat, I've
been unable to find a good way to make a script wait for socat to set up
that socket.  For example, the manual page gives this command:
socat UNIX-LISTEN:/tmp/.X11-unix/X1,fork \
SOCKS4:host.victim.org:127.0.0.1:6000,socksuser=nobody,sourceport=20

I might want to put something like that in a script, and immediately run
"DISPLAY=:1 xmessage test" to use the connection.  If I put a "&" at the
end of the socat command, it could fail to listen without me knowing, or
xmessage might fail because it runs before the socket's ready.  Adding a
"sleep" command usually works but can't be considered reliable.  I guess
with 2 "-d" options I could parse stderr with the shell's "read" command
and look for "] N listening ".

It would be nice to have an easy way to do this.  For example, an option
that makes socat spawn a sub-process when ready, and shut down when that
sub-process exits.  Another way would be an option to make socat go into
the background when ready (but then a script would have to find some way
to kill it when done with it).

- Michael


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.5.0-4-amd64 (SMP w/32 CPU threads; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages socat depends on:
ii  libc6 2.37-12
ii  libssl3   3.0.12-2
ii  libwrap0  7.6.q-32

socat recommends no packages.

socat suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1053688: wait(2) says si_status will contain the exit code "as given"

[Michael Gold]

Package: manpages-dev
Version: 6.03-2

Dear Maintainer,

I saw that the manual for exit(3) claimed "the least significant byte of
status (i.e., status & 0xFF) is returned to the parent".  This surprised
me because I was pretty sure that POSIX required the full status to made
available.  It does:
   "the full value shall be available from waitid() and in the siginfo_t
passed to a signal handler for SIGCHLD."
   https://pubs.opengroup.org/onlinepubs/9699919799/functions/exit.html

And the wait(2) manual page documents it as such:
   "waitid()
…
si_status
Either the exit status of the child, as given  to  _exit(2)  (or
exit(3)),  or  the  signal  that  caused the child to terminate,
stop, or continue.  The si_code field can be used  to  determine
how to interpret this field."

However, this doesn't actually work on Linux.  Here's a test program:
#include 
#include 
#include 
#include 
int main() {
pid_t pid=fork();
if(pid<0){perror("fork"); exit(1);}
if(pid==0)_exit(12345);
siginfo_t si={0};
pid=waitid(P_PID,pid,,WEXITED);
if(pid<0)perror("waitid");
printf("pid=%d, status=%d\n",pid,si.si_status);
}

It prints status=57 (12345 & 255), which is not "as given".  Until Linux
is changed to follow the recent POSIX requirement, the manual should say
that si_status is the low 8 bits.  It might also be helpful to note this
as a deviation from the 2018 edition of POSIX.

By the way, running the test with "strace -f" shows that the child gives
the full status code to the kernel, and the waitid() syscall returns the
truncated version.

- Michael


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.5.0-1-amd64 (SMP w/32 CPU threads; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages manpages-dev depends on:
ii  manpages  6.03-2

manpages-dev recommends no packages.

Versions of packages manpages-dev suggests:
ii  man-db [man-browser]  2.12.0-1

-- no debconf information


signature.asc
Description: PGP signature

Bug#1053416: git: mangles curl proxy setting and breaks AF_UNIX proxies

[Michael Gold]

Package: git
Version: 1:2.42.0-1
Tags: patch

Dear Maintainer,

git does not support AF_UNIX proxies, despite the git-config manual page
suggesting it will accept anything supported by curl:
  http.proxy
  Override the HTTP proxy, normally configured using the http_proxy,
  https_proxy, and all_proxy environment variables (see curl(1)). In
  addition to the syntax understood by curl, it is possible to
  specify a proxy string with a user name but no password,

I tried to use "torsocks git fetch" with a .onion remote I'd cloned from
in the past, and got an error:
fatal: unable to access 'http://[elided].onion/git/': Not resolving 
.onion address (RFC 7686)

It seems to be a known problem, and I tried working around it by setting
an AF_UNIX proxy as documented for --proxy in the curl(1) manual:
export all_proxy=socks5h://localhost/run/tor/socks

That works for curl, but "git fetch" gives an error:
fatal: unable to access 'http://[elided].onion/git/': Failed to connect 
to localhost port 1080 after 0 ms: Couldn't connect to server

While debugging, I found that git was reading this environment variable,
parsing it poorly, and overriding it by giving libcurl a proxy string of
just "localhost"; seeing no path or port number, curl tries AF_INET6 and
AF_INET with port 1080.

I'm attaching a patch that fixes this.  I haven't tested thoroughly, but
tried to avoid unnecessary changes to the credential code (which I think
should use libcurl to parse URLs).  The flags for curl_url_set() are the
same as in curl's own parse_proxy() function.

  Permission is hereby granted, irrevocably and free of charge, to any
  person obtaining a copy of this software and associated documentation
  files (the "Software"), to deal in the Software without restriction,
  including without limitation the rights to use, copy, modify, merge,
  publish, distribute, sublicense, and/or sell copies of the Software,
  and to permit persons to whom the Software is furnished to do so.

  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
  EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
  MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
  IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
  CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
  TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
  SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

- Michael


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.5.0-1-amd64 (SMP w/32 CPU threads; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages git depends on:
ii  git-man  1:2.42.0-1
ii  libc62.37-11
ii  libcurl3-gnutls  8.3.0-2
ii  liberror-perl0.17029-2
ii  libexpat12.5.0-2
ii  libpcre2-8-0 10.42-4
ii  perl 5.36.0-9
ii  zlib1g   1:1.2.13.dfsg-3

Versions of packages git recommends:
ii  ca-certificates  20230311
ii  less 590-2
ii  openssh-client [ssh-client]  1:9.4p1-1
ii  patch2.7.6-7

Versions of packages git suggests:
ii  gettext-base  0.21-13+b1
pn  git-cvs   
pn  git-daemon-run | git-daemon-sysvinit  
ii  git-doc   1:2.42.0-1
ii  git-email 1:2.42.0-1
pn  git-gui   
pn  git-mediawiki 
pn  git-svn   
ii  gitk  1:2.42.0-1
pn  gitweb

-- no debconf information

diff --git a/http.c b/http.c
index e138b4b96fb9..7ba155a77406 100644
--- a/http.c
+++ b/http.c
@@ -1135,32 +1135,39 @@ static CURL *get_curl_handle(void)
 */
curl_easy_setopt(result, CURLOPT_PROXY, "");
} else if (curl_http_proxy) {
-   if (starts_with(curl_http_proxy, "socks5h"))
-   curl_easy_setopt(result,
-   CURLOPT_PROXYTYPE, CURLPROXY_SOCKS5_HOSTNAME);
-   else if (starts_with(curl_http_proxy, "socks5"))
-   curl_easy_setopt(result,
-   CURLOPT_PROXYTYPE, CURLPROXY_SOCKS5);
-   else if (starts_with(curl_http_proxy, "socks4a"))
-   curl_easy_setopt(result,
-   CURLOPT_PROXYTYPE, CURLPROXY_SOCKS4A);
-   else if (starts_with(curl_http_proxy, "socks"))
-   curl_easy_setopt(result,
-   CURLOPT_PROXYTYPE, CURLPROXY_SOCKS4);
-#ifdef 

Bug#1051373: libglib2.0-0: 2.77.3-1 breaks Midnight Commander extension file

[Michael Gold]

Package: libglib2.0-0
Version: 2.77.3-1
Severity: important

Dear Maintainer,

After upgrading libglib2.0-0 from 2.77.2-1 to 2.77.3-1, I'm no longer
able to open files by selecting them in Midnight Commander and pressing
Enter.  A change in the behaviour of g_key_file_get_string() appears to
be the cause.  For example, one section of the mc.ext.ini file contains:
[pdf]
Regex=\.(pdf|PDF|ps|djvu)$
Open=pdf %f &

With the new package, a call to g_key_file_get_string() for the "Regex"
value returns NULL.  If I pre-load the old library version, it returns
the string, and mc executes the specified command if I press Enter with
a PDF file selected.

The package version of "mc" is "3:4.8.29-2".

- Michael


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.4.0-4-amd64 (SMP w/32 CPU threads; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libglib2.0-0 depends on:
ii  libc6 2.37-7
ii  libffi8   3.4.4-1
ii  libmount1 2.39.2-1
ii  libpcre2-8-0  10.42-4
ii  libselinux1   3.5-1
ii  zlib1g1:1.2.13.dfsg-3

Versions of packages libglib2.0-0 recommends:
ii  libglib2.0-data   2.77.3-1
ii  shared-mime-info  2.2-1
ii  xdg-user-dirs 0.18-1

Versions of packages libglib2.0-0 suggests:
pn  low-memory-monitor  

-- no debconf information


signature.asc
Description: PGP signature

Bug#1041068: yt-dlp: options in manual page don't work when pasted, due to non-ASCII prefixes

[Michael Gold]

Package: yt-dlp
Version: 2023.07.06-1

Dear Maintainer,

The options listed in the yt-dlp manual page don't work when pasted onto
a command line.  As an example, run "man yt-dlp", copy the first option,
and pass it as an argument to yt-dlp:
$ yt-dlp ‐‐help
[generic] Extracting URL: ‐‐help
ERROR: [generic] None: '‐‐help' is not a valid URL. Set 
--default-search "ytsearch" (or run  yt-dlp "ytsearch:‐‐help" ) to search 
YouTube

This option actually needs to be "--help", which looks the same but uses
the ASCII hyphen-minus (U+002D).  The manual uses "U+2010 HYPHEN", which
is not accepted as an option prefix.

/usr/share/man/man1/yt-dlp.1.gz, when uncompressed, uses only ASCII; but
comparing against /usr/share/man/man1/whoami.1.gz suggests that a hyphen
needs to be escaped with a preceding backslash.  I don't see any similar
problem with "man whoami": the listed options work when pasted.

- Michael


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

Kernel: Linux 6.3.0-2-amd64 (SMP w/32 CPU threads; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages yt-dlp depends on:
ii  python33.11.4-5
ii  python3-brotli 1.0.9-2+b6
ii  python3-certifi2022.9.24-1
ii  python3-mutagen1.46.0-2
ii  python3-pkg-resources  68.0.0-1
ii  python3-pycryptodome   3.11.0+dfsg1-4
ii  python3-websockets 10.4-1

Versions of packages yt-dlp recommends:
ii  ca-certificates  20230311
ii  curl 7.88.1-10
ii  ffmpeg   7:5.1.3-1
pn  python3-pyxattr  
pn  rtmpdump 
ii  wget 1.21.3-1+b2

Versions of packages yt-dlp suggests:
pn  libfribidi-bin | bidiv  
ii  mplayer 2:1.5+svn38423-2
ii  mpv 0.35.1-4+b1
pn  phantomjs   

-- no debconf information


signature.asc
Description: PGP signature

Bug#1035325: prctl(2): PR_SET_CHILD_SUBREAPER description is misleading in relation to PID namespaces

[Michael Gold]

Package: manpages-dev
Version: 6.03-1
Severity: minor

Dear Maintainer,

The prctl manual page says:
PR_SET_CHILD_SUBREAPER (since Linux 3.4)
[…]
A subreaper fulfills the role of init(1) for its descendant pro‐
cesses.  When a process becomes orphaned  (i.e.,  its  immediate
parent  terminates), then that process will be reparented to the
nearest still living ancestor subreaper.  […]

Part of the role of init(1) is to remain running while any child process
needs to be running: the kernel will panic if the global init goes away,
and will send SIGKILL to all processes of the namespace whose init dies.
The reference to a "still living" subreaper, however, suggests that this
does not apply to subreapers, and a test program confirms it; therefore,
subreapers do not fulfill the full role of init(1).  That's overly vague
anyway; "man 1 init" references many things a subreaper wouldn't have to
do, and POSIX has only a few passing references to init or PID 1.

Also, the text contradicts pid_namespaces(7), which says:
   When a child process becomes orphaned, it is reparented to the "init"
   process  in the PID namespace of its parent (unless one of the nearer
   ancestors of the parent employed the prctl(2)  PR_SET_CHILD_SUBREAPER
   command […]

A process that dies in a PID namespace could be reparented to its PID 1,
even if "the nearest still living ancestor subreaper" is another process
outside the namespace.

- Michael


-- System Information:
Debian Release: 12.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-8-amd64 (SMP w/32 CPU threads; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages manpages-dev depends on:
ii  manpages  6.03-1

manpages-dev recommends no packages.

Versions of packages manpages-dev suggests:
ii  man-db [man-browser]  2.11.2-2

-- no debconf information


signature.asc
Description: PGP signature

Bug#1035320: pdftotext: Manual page incorrectly lists PDF-file as an optional argument

[Michael Gold]

Package: poppler-utils
Version: 22.12.0-2+b1
Severity: minor

Dear Maintainer,

The pdftotext manual page shows the synopsis:
  pdftotext [options] [PDF-file [text-file]]

But it looks like this should be:
  pdftotext [options] PDF-file [text-file]

If run with no PDF-file argument, the program exits with status 99 after
printing a usage message (in which it's not shown as optional).

- Michael


-- System Information:
Debian Release: 12.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-8-amd64 (SMP w/32 CPU threads; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages poppler-utils depends on:
ii  libc6  2.36-9
ii  libcairo2  1.16.0-7
ii  libfreetype6   2.12.1+dfsg-5
ii  liblcms2-2 2.14-2
ii  libpoppler126  22.12.0-2+b1
ii  libstdc++6 12.2.0-14

poppler-utils recommends no packages.

poppler-utils suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1034122: feh: excessively noisy and unclear if inotify_init() fails

[Michael Gold]

Package: feh
Version: 3.9.1-2
Severity: wishlist

Dear Maintainer,

feh prints some warnings to stderr if inotify_init() fails:
feh WARNING: inotify_init failed: Too many open files
feh WARNING: Disabling inotify-based auto-reload

I reported a related crash here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034121
But I consider the warnings to be problematic too.

A program shouldn't print a warning relating to an optional feature that
I did not specifically enable, based on a function that must be expected
to "randomly" fail (due to its reliance on an extremely limited resource
shared with unrelated programs: by default, each user has a limit of 128
inotify instances).

It is also unclear from the text whether auto-reloading was disabled, or
remains operational via some non-inotify fallback.  The program's manual
page is similarly ambiguous.  I don't see any fallback in the code.

- Michael


-- System Information:
Debian Release: 12.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-7-amd64 (SMP w/32 CPU threads; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages feh depends on:
ii  libc6 2.36-8
ii  libcurl4  7.88.1-8
ii  libexif12 0.6.24-1+b1
ii  libimlib2 1.10.0-4+b1
ii  libpng16-16   1.6.39-2
ii  libx11-6  2:1.8.4-2
ii  libxinerama1  2:1.1.4-3
ii  yudit-common  3.1.0-1

Versions of packages feh recommends:
ii  libjpeg-progs  1:9e-1

feh suggests no packages.

-- no debconf information



signature.asc
Description: PGP signature

Bug#1034121: feh: makes a bad FD_SET() call and aborts if inotify_init() fails

[Michael Gold]

Package: feh
Version: 3.9.1-2
Severity: important

Dear Maintainer,

Today I'm getting the following error whenever I try to run feh:
feh WARNING: inotify_init failed: Too many open files
feh WARNING: Disabling inotify-based auto-reload
*** bit out of range 0 - FD_SETSIZE on fd_set ***: terminated
Aborted

It turns out that inotify_init() has the very low limit of 128 instances
per user by default, and lsof shows they are mostly used by instances of
dbus-daemon, dconf-service, and xdg-desktop-portal.

feh_main_iteration() calls FD_SET(opt.inotify_fd, ) if auto_reload
is enabled, regardless of whether inotify_fd is valid.  It also needs to
check 'opt.inotify_fd >= 0' in the 'if' statement.

A workaround is to use the --reload=0 command line option.

- Michael


-- System Information:
Debian Release: 12.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-7-amd64 (SMP w/32 CPU threads; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages feh depends on:
ii  libc6 2.36-8
ii  libcurl4  7.88.1-8
ii  libexif12 0.6.24-1+b1
ii  libimlib2 1.10.0-4+b1
ii  libpng16-16   1.6.39-2
ii  libx11-6  2:1.8.4-2
ii  libxinerama1  2:1.1.4-3
ii  yudit-common  3.1.0-1

Versions of packages feh recommends:
ii  libjpeg-progs  1:9e-1

feh suggests no packages.

-- no debconf information



signature.asc
Description: PGP signature

Bug#1031375: wpa_cli: non-root server may be unable to reply to wpa_cli

[Michael Gold]

Package: wpasupplicant
Version: 2:2.10-11

Dear Maintainer,

I configured wpa_supplicant to run as a non-root user (with CAP_NET_RAW
and CAP_NET_ADMIN as the README suggests), and found that wpa_cli would
hang on startup when trying to connect to it.  strace shows that wpa_cli
creates named sockets in /tmp (despite $TMPDIR pointing elsewhere):
  bind(3, {sa_family=AF_UNIX, sun_path="/tmp/wpa_ctrl_4848-1"}, 110) = 0
  bind(4, {sa_family=AF_UNIX, sun_path="/tmp/wpa_ctrl_4848-2"}, 110) = 0
And then wpa_supplicant cannot reply:
  sendto(12, "OK\n", 3, 0, {sa_family=AF_UNIX, sun_path=
 "/tmp/wpa_ctrl_4824-2"}, 23) = -1 EACCES (Permission denied)
This is due to the umask and uid/gid being applied:
  srwx--x--x 1 michael michael 0 Feb 15 14:10 /tmp/wpa_ctrl_4824-2

A workaround is to set umask to 0 before running wpa_cli.

On Linux, it would be better for wpa_cli to use the "autobind" feature
(see man 7 unix) by calling bind() with addrlen==sizeof(sa_family_t).
This seems to work fine, and then the server needs no special permission
to reply and doesn't need access to /tmp (and the client won't leave
garbage there if it exits abnormally).

Also, maybe wpa_cli's existing Android code to chmod() the socket should
be enabled more widely.  POSIX says, for connect(), that "For SOCK_DGRAM
sockets, the peer address [...] limits the remote sender for subsequent
recv() functions"; so, if anyone other than the server sent messages to
the world-writable socket, the client wouldn't see them.

(I think SOCK_SEQPACKET would be a better fit than SOCK_DGRAM for the
control sockets, but that would require server and client changes.)

- Michael


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

Kernel: Linux 6.1.0-4-amd64 (SMP w/32 CPU threads; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages wpasupplicant depends on:
ii  adduser3.131
ii  libc6  2.36-8
ii  libdbus-1-31.14.6-1
ii  libnl-3-2003.7.0-0.2+b1
ii  libnl-genl-3-200   3.7.0-0.2+b1
ii  libnl-route-3-200  3.7.0-0.2+b1
ii  libpcsclite1   1.9.9-1
ii  libreadline8   8.2-1.3
ii  libssl33.0.8-1

wpasupplicant recommends no packages.

Versions of packages wpasupplicant suggests:
pn  libengine-pkcs11-openssl  
pn  wpagui

-- no debconf information




signature.asc
Description: PGP signature

Bug#1031176: overlayfs: Manual page unclear about lowerdir, upperdir, workdir

[Michael Gold]

Package: mount
Version: 2.38.1-4

Dear Maintainer,

[Some new text for the manual page is suggested below.]

'man 8 mount' says under "Mount options for overlay":
  A read-only overlay of two read-only filesystems may use any filesystem type.
  The options lowerdir and upperdir are combined into a merged directory

When trying to set this up, the kernel logged this error:
  overlayfs: upper fs is r/o, try multi-lower layers mount

The manual doesn't mention any such possibility, and seems to contradict
it (unless the following text is read very carefully, using a definition
of "upper" differing from that used in the source code):
  An overlay filesystem combines two filesystems - an upper filesystem
  and a lower filesystem.
  …
  The options lowerdir and upperdir are combined…

I tried using 'lowerdir' multiple times, but that doesn't work.  Looking
at the source code revealed 'lowerdir' is treated as a list separated by
colons, with backslash as an escape character.  'upperdir' and 'workdir'
are single items and don't require or support escaping.

It's also unclear about whether the 'workdir' is mandatory.  If upperdir
is specified, it is; otherwise, it's useless and ignored, and the kernel
will log a message saying that.

The statement that "workdir needs to be an empty directory" is false; it
can contain a "work" subdirectory, at least, but I see no enforcement at
all in the code.  (The kernel will create a "work" subdirectory.  If the
workdir had to be empty, a user would have to delete that before reusing
the same workdir later.)

A kernel comment says "Workdir should not be subdir of upperdir and vice
versa"--and "should" is misleading because the mount will fail if either
is true.  The manual doesn't say this (as a suggestion or requirement).

The code implements an optional "exclusive upperdir protection" feature,
also used for the workdir, not mentioned in the manual.  If either is in
use for another overlay mount, it's an error--except that if "index=off"
was used, it's only a warning.


I suggest the text from "An overlay filesystem combines" to "userxattr"
be replaced with the following:
  An overlay filesystem combines two or more directory trees:
  one or more read-only lower trees, and an optional upper tree.
  Directories are merged, with any non-directory path in a
  higher tree hiding any such path that exists in a lower tree.

  A read-only overlay mount would normally be created using
  multiple lower trees; for example,
mount -t overlay overlay -o ro,lowerdir=/top:/bottom /merged

  A read/write mount requires upper and work trees; for example,
mount -t overlay overlay -o lowerdir=/lower,upperdir=/upper,workdir=/work 
/merged

  lowerdir=directory[:directory]
One or more directory paths separated by colons, with each tree to
be mounted below any that precede it.  Any filesystem supported by
Linux is acceptable, even if it's read-only or is itself an overlay.
Each colon or backslash in a path must be escaped by preceding it
with a backslash.

  upperdir=directory
One (un-escaped) directory path to be mounted above everything
in the lowerdir list.  It should not be in use as the upperdir or
workdir of any other overlay.  A read/write overlay requires an
upperdir and workdir on the same writable filesystem, with neither
being inside the other; this filesystem must support the creation
of trusted.* extended attributes, and must provide a valid d_type
in readdir response (so, NFS is not suitable).

  workdir=directory
One (un-escaped) directory path to be used internally by overlayfs.
It must be on the same filesystem as upperdir, without being inside
upperdir.  It should be empty, and should not be in use as the
upperdir or workdir of any other overlay.

I waive any copyright in this text (per public-domain.txt, attached).

- Michael


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

Kernel: Linux 6.1.0-4-amd64 (SMP w/32 CPU threads; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages mount depends on:
ii  libblkid1  2.38.1-4
ii  libc6  2.36-8
ii  libmount1  2.38.1-4
ii  libselinux13.4-1+b5
ii  libsmartcols1  2.38.1-4

mount recommends no packages.

Versions of packages mount suggests:
pn  nfs-common  

-- no debconf information
Permission is hereby granted, free of charge, to any person obtaining a
copy of this software and associated documentation files (the "Software"),
to deal in the Software without restriction, including without limitation
the rights to use, copy, modify, merge, publish, distribute, sublicense,
and/or sell copies of the Software, and to permit persons to whom the
Software is furnished to do so.

THE SOFTWARE IS PROVIDED "AS 

Bug#1027247: keyboard-layout: fails to load Dvorak keyboard layout on boot

[Michael Gold]

Package: keyboard-layout
Version: 1.213
Severity: important

Dear Maintainer,

After upgrading keyboard-configuration and console-setup from 1.212 to
1.213 and rebooting, I saw a "syntax error" message before my full-disk-
encryption passphrase prompt.  I then failed several times to enter a
valid passphrase; the keypresses were being handled as QWERTY instead
of Dvorak, but there was no obvious way to know this because they were
invisible.  After typing in QWERTY, I was able to boot successfully.

Running the keyboard setup script shows the error:
# /etc/console-setup/cached_setup_keyboard.sh
syntax error, unexpected ERROR, expecting CCHAR or UNUMBER or AS

In "dpkg-reconfigure keyboard-layout" I've chosen:
 * Generic 105-key PC
 * English (US) - English (Dvorak)
 * [AltGr] The default for the keyboard layout
 * No compose key
 * No Control+Alt+Backspace

- Michael


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

Kernel: Linux 6.0.0-6-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled


signature.asc
Description: PGP signature

Bug#1025900: pw-mon doesn't accept -N option

[Michael Gold]

Package: pipewire-bin
Version: 0.3.62-1

Dear Maintainer,

The man page and help text of pw-mon list a '-N' option, but pw-mon does
not accept it:

$ pw-mon -N
pw-mon: invalid option -- 'N'
pw-mon [options]
  -h, --helpShow this help
  --version Show version
  -r, --remote  Remote daemon name
  -N, --no-colors   disable color output
  -C, --color[=WHEN]whether to enable color support. WHEN 
is `never`, `always`, or `auto`
$ 

- Michael


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

Kernel: Linux 6.0.0-6-amd64 (SMP w/32 CPU threads; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages pipewire-bin depends on:
ii  libasound2   1.2.8-1
ii  libc62.36-6
ii  libdbus-1-3  1.14.4-1
ii  libncursesw6 6.3+20220423-2
ii  libpipewire-0.3-00.3.62-1
ii  libpipewire-0.3-modules  0.3.62-1
ii  libreadline8 8.2-1.2
ii  libsndfile1  1.1.0-3+b1
ii  libtinfo66.3+20220423-2

Versions of packages pipewire-bin recommends:
ii  dbus-user-session  1.14.4-1
ii  rtkit  0.13-4+b1
ii  wireplumber0.4.12-1+b1

pipewire-bin suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1021748: mupen64plus: no video (SDL reports an invalid pitch)

[Michael Gold]

Source: mupen64plus
Version: 2.5+6
Severity: important

Dear Maintainer,

With the most recent mupen64plus package, I no longer see video with any
game.  (A previous version was working.)  The console shows some errors:
Core: Setting video mode: 960x720
Core Error: SDL_SetVideoMode failed: Parameter 'pitch' is invalid
Video Error: Could not set video mode.
Core: Setting video mode: 960x720
Core Error: SDL_SetVideoMode failed: Parameter 'pitch' is invalid
Video Error: Could not set video mode.
Video Error: Error setting display mode

This bug was already reported and fixed upstream:
https://github.com/mupen64plus/mupen64plus-core/issues/969

In case anyone's looking for a workaround, I've attached some code that
can be built as a shared object and loaded via $LD_PRELOAD.

- Michael


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.19.0-2-amd64 (SMP w/32 CPU threads; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages mupen64plus-audio-all depends on:
ii  mupen64plus-audio-sdl  2.5-5

mupen64plus-audio-all recommends no packages.

mupen64plus-audio-all suggests no packages.

-- no debconf information
#define _GNU_SOURCE// make dlfcn.h define RTLD_NEXT
#include 
#include 
#include 
#include 

struct SDL_Surface*
SDL_CreateRGBSurfaceFrom(void *pixels,
int width, int height, int depth, int pitch,
uint32_t Rmask, uint32_t Gmask, uint32_t Bmask, uint32_t Amask)
{
static struct SDL_Surface*(*real_fn)(void*, int, int, int, int,
uint32_t, uint32_t, uint32_t, uint32_t) = NULL;
if (!pitch) {
pitch = (depth + 7) / 8 * width;
}
if (!real_fn) {
real_fn = dlsym(RTLD_NEXT, __func__);
if (!real_fn) {
errno = ELIBACC;
return (void*)0;
}
}
return real_fn(pixels, width, height, depth, pitch,
Rmask, Gmask, Bmask, Amask);
}


signature.asc
Description: PGP signature

Bug#1021360: no video output from HDMI ports on Radeon RX 6600 [amdgpu]

[Michael Gold]

Package: src:linux
Version: 5.19.11-1
Severity: important

Dear Maintainer,

I just bought a new video card:
"Gigabyte EAGLE Radeon RX 6600 8GB PCI-E w/ Dual HDMI, Dual DP"

After installing it (as the sole video card) and connecting two monitors
via the HDMI ports (with HDMI-to-DVI adapters/cables), everything seemed
fine at first: the firmware, GRUB, and early Linux messages were visible
on my primary monitor.  Near the point in the boot process when the font
visibly changes (10-20 seconds in), it lost its signal and both monitors
remained unusable.

I was able to SSH in, and see that no monitors were detected by Linux or
the X server.  dmesg showed:
 [   16.211071] amdgpu :0a:00.0: [drm] Cannot find any crtc or sizes
xrandr showed "disconnected" beside each output ("HDMI-A-0", "HDMI-A-1",
"DisplayPort-0", and "DisplayPort-1").

Based on some web searching, I passed "amdgpu.dc=0" and "amdgpu.runpm=0"
to the kernel; neither helped.  "nomodeset" got my primary monitor going
(seeing a 1920×1080 signal, stretched unevenly from 1280-by-something).

After looking at the kernel code, I found the outputs could be forced on
using kernel options: "video=HDMI-A-1:D video=HDMI-A-2:D".  That kind of
worked.  The primary monitor (NEC EA231WMi) is fully working.  The other
one (BenQ BL2400) was detected--the X server read the EDID and created a
proper mode list--but just showed "no signal" on a black screen (or, one
time, on a blue screen after I tried forcing some custom modes).

The BenQ monitor started working as soon as I tried a DisplayPort cable.
Naturally, I'd had no such cable on hand when I noticed the problem, nor
any device with an HDMI input.  I'm wondering if something is broken for
the "DVI over HDMI" support.  I consider it an important feature: around
10 years ago, when I bought the monitors, many manufacturers were trying
to avoid paying HDMI's per-port fees, and DisplayPort was not yet common
in the (several-year-old) video cards people were likely to connect them
to.  (So, others are likely to have similar cables/adapters plugged into
their monitors.)

Additionally, the feature of disabling all video outputs when nothing is
detected seems like something that ought to be reconsidered.

- Michael


-- Package-specific info:
** Version:
Linux version 5.19.0-2-amd64 (debian-ker...@lists.debian.org) (gcc-11 (Debian 
11.3.0-6) 11.3.0, GNU ld (GNU Binutils for Debian) 2.38.90.20220713) #1 SMP 
PREEMPT_DYNAMIC Debian 5.19.11-1 (2022-09-24)

** Command line:
BOOT_IMAGE=/vmlinuz-5.19.0-2-amd64 root=UUID= ro 
rootflags=subvol=@rootfs quiet

** Not tainted

** Kernel log:
Attached.

** Model information
sys_vendor: ASUS
product_name: System Product Name
product_version: System Version
chassis_vendor: Default string
chassis_version: Default string
bios_vendor: American Megatrends Inc.
bios_version: 2403
board_vendor: ASUSTeK COMPUTER INC.
board_name: ROG STRIX B550-E GAMING
board_version: Rev X.0x

** Loaded modules:
snd_seq_dummy
snd_hrtimer
snd_seq
snd_seq_device
nft_redir
nft_chain_nat
nf_nat
nft_reject_inet
nf_reject_ipv4
nf_reject_ipv6
nft_reject
nft_ct
nf_conntrack
nf_defrag_ipv6
nf_defrag_ipv4
nf_tables
nfnetlink
binfmt_misc
amdgpu
btusb
iwlmvm
btrtl
btbcm
btintel
btmtk
bluetooth
snd_hda_codec_realtek
mac80211
snd_hda_codec_generic
ledtrig_audio
snd_hda_codec_hdmi
intel_rapl_msr
intel_rapl_common
snd_hda_intel
jitterentropy_rng
amd64_edac
snd_intel_dspcfg
edac_mce_amd
joydev
libarc4
asus_ec_sensors
gpu_sched
snd_intel_sdw_acpi
snd_hda_codec
drm_display_helper
kvm_amd
sha512_ssse3
iwlwifi
sha512_generic
cec
snd_hda_core
eeepc_wmi
kvm
snd_hwdep
asus_wmi
rc_core
cfg80211
drm_ttm_helper
snd_pcm
platform_profile
irqbypass
battery
ttm
drbg
sparse_keymap
video
evdev
rapl
snd_timer
ansi_cprng
drm_kms_helper
wmi_bmof
mxm_wmi
snd
pcspkr
sp5100_tco
efi_pstore
ccp
ecdh_generic
k10temp
soundcore
watchdog
i2c_algo_bit
xpad
rng_core
rfkill
ecc
ff_memless
acpi_cpufreq
button
sg
nct6775
nct6775_core
hwmon_vid
parport_pc
ppdev
lp
drm
parport
fuse
configfs
ip_tables
x_tables
autofs4
btrfs
blake2b_generic
zstd_compress
nls_ascii
nls_cp437
vfat
fat
ext4
crc16
mbcache
jbd2
dm_crypt
dm_mod
efivarfs
raid10
raid456
async_raid6_recov
async_memcpy
async_pq
async_xor
async_tx
xor
raid6_pq
libcrc32c
crc32c_generic
raid0
multipath
linear
ses
enclosure
sd_mod
scsi_transport_sas
hid_generic
raid1
uas
usbhid
usb_storage
hid
crc32_pclmul
crc32c_intel
md_mod
ahci
libahci
ghash_clmulni_intel
xhci_pci
nvme
libata
xhci_hcd
nvme_core
t10_pi
aesni_intel
usbcore
igc
scsi_mod
crc64_rocksoft_generic
crypto_simd
cryptd
crc64_rocksoft
ptp
crc_t10dif
i2c_piix4
crct10dif_generic
crct10dif_pclmul
pps_core
crc64
usb_common
scsi_common
crct10dif_common
gpio_amdpt
wmi
gpio_generic

** PCI devices:
00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse 
Root Complex [1022:1480]
Subsystem: ASUSTeK Computer Inc. Starship/Matisse Root Complex 
[1043:8808]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- 

Bug#1018851: bash: long PS1 may or may not cause bad cursor positioning, depending on the position of a space

[Michael Gold]

Package: bash
Version: 5.2~rc2-2

Dear Maintainer,

I was seeing incorrect cursor behaviour when my PS1 prompt got long, and
was surprised to learn that merely moving a space character from after a
control sequence to before it fixed the problem.  Based on the man page,
I think I've used the "non-printing" escapes correctly.

Try this in an 80-character-wide terminal:
x159=''
while [ "${#x159}" -lt 159 ]; do x159=x$x159; done
PS1=$'\\[\x1b[0;33;40m\\]'$x159$'$\\[\x1b[0m\\] '

Then enter an ordinary character such as 't'.  I see my cursor move up a
line to the final 'x' before '$', instead of the expected position after
the 't' I just entered.  But I see no problem with this prompt:
PS1=$'\\[\x1b[0;33;40m\\]'$x159$'$ \\[\x1b[0m\\]'

I only moved the trailing space.  It's outside the non-printing sequence
delimited by \[ and \] in both cases, so I'd expect no difference except
the colour of that cell.

- Michael


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.18.0-4-amd64 (SMP w/32 CPU threads; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages bash depends on:
ii  base-files   12.2
ii  debianutils  5.7-0.3
ii  libc62.34-7
ii  libtinfo66.3+20220423-2

Versions of packages bash recommends:
pn  bash-completion  

Versions of packages bash suggests:
pn  bash-doc  

-- no debconf information


signature.asc
Description: PGP signature

Bug#992383: debianutils: which is noisy and doesn't suggest a different option

[Michael Gold]

On Wed, Aug 18, 2021 at 12:53:53 -0400, Jason Riedy wrote:
> I've been using which for decades, including on SunOS and AIX. When I know
> it's a script, less `which foobar` is quick and easy.

Adding this to ~/.bashrc or similar might help:
  which () { bash -c 'command -v "$@"' which "$@"; }

It won't find binaries shadowed by shell builtins or functions, though I
don't imagine this would be a common problem.

-- Michael


signature.asc
Description: PGP signature

Bug#992383: debianutils: which is noisy and doesn't suggest a different option

[Michael Gold]

On Wed, Aug 18, 2021 at 13:28:14 +0900, Norbert Preining wrote:
...
> but being noisy about it on any invocation, **without** providing
> an alternative is a no go
...
> Please use NEWS, or whatever other channels, and above all, **provide
> information on a replacement!**

I checked 'man which' when I saw the text; the DEPRECATION section hints
at the replacements, though it could more directly suggest 'command -v'.
That appears equivalent for any use with a single argument, when special
printing of a shell alias, function, or builtin is acceptable.  Notably,
it would handle everything I saw in /var/lib/dpkg/info, where I observed
3 patterns of use:
 * direct, as in console-setup.config:
  if which uname >/dev/null; then
 * redundantly combined with test -x, as in libssl1.1:amd64.postinst:
  if [ -x "`which invoke-rc.d 2>/dev/null`" ]; then
 * used with an "invalid" argument, as in libreoffice-common.postrm:
  if [ -x "`which ucfr --force 2>/dev/null`" ]; then

All are simply checking whether a command is present.

How about providing the following text?
  The 'which' utility will be removed in the future.  Shell scripts often use
  it to check whether a command is available.  A more standard way to do this
  is with 'command -v'; for example:
  if command -v update-icon-caches >/dev/null; then
update-icon-caches /usr/share/icons/...
  fi

'2>/dev/null' is unnecessary when using 'command': POSIX says "no output
shall be written" if the command isn't found.  It's also unnecessary for
the debianutils version of 'which', and hides the deprecation warning.

-- Michael


signature.asc
Description: PGP signature

Bug#888620: evince: apparmor profile prevents loading git-annex files

[Michael Gold]

On Thu, Sep 13, 2018 at 11:47:40 -0500, Jason Crain wrote:
> My understanding is that this limitation is in the Linux kernel's
> security module framework. Symbolic links are resolved before AppArmor
> can verify permission for the path, so AppArmor only sees
> "/xr0/michael/...etc...", not "/home/michael/...etc...".

That makes some sense.  It would be reasonable to set different security
policies on different filesystems--even directories within a filesystem,
when fs.protected_hardlinks is in use.

$HOME vs. /xr0 is only part of the problem.  The apparmor rules say that
evince can open:
 * any file under $HOME
 * any file outside of $HOME named *.pdf

What is actually triggering the denial is that the target git-annex path
has no extension.  I don't understand the security benefit, because:
 * the symlink, its target, and both directories are owned by me and not
   writable by anyone else
 * anyone trying to exploit users will simply give the file the expected
   extension (otherwise people would have trouble opening it)
 * harmful files are most likely to be in web/mail download directories,
   which are probably under $HOME so don't even get the extension check

-- Michael


signature.asc
Description: PGP signature

Bug#888620: evince: apparmor profile prevents loading git-annex files

[Michael Gold]

On Thu, Sep 13, 2018 at 16:22:03 +0200, Antonio Ospite wrote:
> I am not the maintainer or anything, but I am curios, what are the
> permissions of the _destination_ file?
> 
> I mean, what does "ls -l --dereference meltdown.pdf" say?

-r 1 michael michael 188549 Jan 27  2018 meltdown.pdf

Prefix my previously included commands with these if you want to try it:
umask 0066
wget https://meltdownattack.com/meltdown.pdf

-- Michael


signature.asc
Description: PGP signature

Bug#897654: libpam-systemd: "Failed to create session: No such process"

[Michael Gold]

On Fri, May 04, 2018 at 18:28:36 +0200, Michael Biebl wrote:
> Use a drop-in config as described in the Arch wiki:
> 
> For user sessions to work correctly, an exception needs to be added for
> systemd-logind:
> 
> /etc/systemd/system/systemd-logind.service.d/hidepid.conf containing
> 
> [Service]
> SupplementaryGroups=proc

Odd, I thought I had created exactly that file (but named override.conf
and with "adm") via "systemctl edit systemd-logind", and got this error:
  Service has more than one ExecStart= setting

But it's working fine now and I do get a session.

> Well, I think granting read access to the syslog files (and the journal
> fwiw) as a side effect of granting read access to /proc makes group adm
> a poor choice. Those should be treated separately.
> 
> A dedicated "proc" group, as the Arch wiki suggests, makes much more
> sense to me.

Access to /proc isn't really a side-effect if 'adm' is for "system
monitoring/security".  Though in practice it does just seem to be used
for log access.

I can't really ask you to add "SupplementaryGroups=proc" when the group
doesn't exist by default.  Of course, anyone enabling hidepid can do it
either way, once they figure out what's going on.  The systemd overrides
make it pretty convenient (e.g., I don't have to maintain an entire copy
of the service file with one extra line).

-- Michael


signature.asc
Description: PGP signature
-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.

Bug#897654: libpam-systemd: "Failed to create session: No such process"

[Michael Gold]

On Fri, May 04, 2018 at 18:02:09 +0200, Michael Biebl wrote:
> I guess you have two options here:
> Either drop gid=4 from your mount flags or you add
> SupplementaryGroups=adm to systemd-logind.service

I haven't figured out how to override that .service file locally yet,
but I'm trying to add SupplementaryGroups=adm.

If I just drop 'gid=4' I won't be able to use "pidin aux" myself.

> Why adm is a suitable group for that purpose is not clear to me, but
> that's besides the point.
> https://wiki.archlinux.org/index.php/Security#hidepid suggests to use a
> dedicated group like proc which makes more sense to me.

Kind of, but that's not a standard Debian group.  adm is, and does make
sense based on the documentation (also note that johnw independently had
the same idea):
https://wiki.debian.org/SystemGroups
"adm: Group adm is used for system monitoring tasks. Members of this
 group can read many log files in /var/log, …
 staff: Allows users to add local modifications … Compare with group
 'adm', which is more related to monitoring/security."

> Anyway, this really seems to simply be a local (mis)configuration issue.

You're right it's a local problem--though not a reasonably foreseeable,
noticeable, or easily debuggable consequence of 'hidepid'.  If you were
willing to add "SupplementaryGroups=adm" to the shipped file, that would
be helpful and I think reasonable based on the stated purpose of 'adm'.
I'm having trouble thinking of a "proper" way for systemd to handle it
while Debian ships with hidepid disabled.

-- Michael


signature.asc
Description: PGP signature
-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.

Bug#897654: libpam-systemd: "Failed to create session: No such process"

[Michael Gold]

On Thu, May 03, 2018 at 23:42:34 +0200, Michael Biebl wrote:
> Am 03.05.2018 um 23:12 schrieb Michael Gold:
> > Is this problem already tracked?
> I'd say this is a duplicate of #892585

Agreed.  I think there should be a wishlist item requesting that the
failure be more obvious.  Shall I file one, or just repurpose this one?

-- Michael


signature.asc
Description: PGP signature
-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.

Bug#897654: libpam-systemd: "Failed to create session: No such process"

[Michael Gold]

On Thu, May 03, 2018 at 23:25:05 +0200, Michael Biebl wrote:
> Well, logind is running as root, but the the service file is locked down
> considerably:
> 
> CapabilityBoundingSet=CAP_SYS_ADMIN CAP_MAC_ADMIN CAP_AUDIT_CONTROL
> CAP_CHOWN CAP_KILL CAP_DAC_REA
> MemoryDenyWriteExecute=yes
> RestrictRealtime=yes
> RestrictNamespaces=yes
> RestrictAddressFamilies=AF_UNIX AF_NETLINK AF_INET AF_INET6
> SystemCallFilter=~@clock @cpu-emulation @debug @keyring @module
> @obsolete @raw-io @reboot @swap
> SystemCallArchitectures=native
> LockPersonality=yes
> IPAddressDeny=any
> FileDescriptorStoreMax=512
> 
> You will probably have to tweak those settings yourself, if you want to
> continue to use hidepid

Looking at the Linux code, neither uid 0 or gid 0 is actually special-
cased [fs/proc/base.c]:
static bool has_pid_permissions(struct pid_namespace *pid,
 struct task_struct *task,
 int hide_pid_min)
{
if (pid->hide_pid < hide_pid_min)
return true;
if (in_group_p(pid->pid_gid))
return true;
return ptrace_may_access(task, PTRACE_MODE_READ_FSCREDS);
}

So I guess it's always just looked like root had special access (e.g.,
"ps aux" works fine as uid=gid=0 with no supplementary groups), based on
that ptrace permission which logind probably lacks.

I found the file you're quoting from in /lib/systemd/system/.  What's
the recommended way to do local changes?  Copy to /etc/systemd/system/
and edit?

This failure is really obscure.  Perhaps logind should try to open
/proc/1 when it hits this case, and log an explicit message about
hidepid if it gets ENOENT there.

-- Michael


signature.asc
Description: PGP signature
-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.

Bug#897654: libpam-systemd: "Failed to create session: No such process"

[Michael Gold]

retitle 897654 libpam-systemd: hidepid causes "Failed to create session: No 
such process"
thanks

On Thu, May 03, 2018 at 22:53:34 +0200, Michael Biebl wrote:
> On Thu, 3 May 2018 16:31:53 -0400 Michael Gold <mg...@qnx.com> wrote:
> > Apr 09 11:37:30 golbez lightdm[14767]: pam_systemd(lightdm:session): 
> > pam-systemd initializing
> > Apr 09 11:37:30 golbez lightdm[14767]: pam_systemd(lightdm:session): 
> > Asking logind to create session: uid=1000 pid=14767 service=lightdm 
> > type=x11 class=user desktop=lightdm-xsession seat=seat0 vtnr=7 tty= 
> > display=:0 remote=no remote_user= remote_host=
> > Apr 09 11:37:30 golbez lightdm[14767]: pam_systemd(lightdm:session): 
> > Failed to create session: No such process
...
> Are you using hidepid?

Yes, "proc /proc proc rw,relatime,gid=4,hidepid=2 0 0".  After running
"mount /proc -o remount,hidepid=0" I logged in on a VT and saw a session
in the list.

(I was wrong about this working on the other system.  I'm using the same
mount options there and also have 0 sessions, at least over ssh.)

Thanks for the quick response.  Is this problem already tracked?  Any
idea why it would happen, given that systemd-logind is running as root?

-- Michael


signature.asc
Description: PGP signature
-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.

Bug#897654: libpam-systemd: "Failed to create session: No such process"

[Michael Gold]

Package: libpam-systemd
Version: 238-4
Severity: important

At some point in the past, I was able to shut down my system as a
non-root user:
dbus-send --system --print-reply --dest=org.freedesktop.login1 
/org/freedesktop/login1 "org.freedesktop.login1.Manager.PowerOff" boolean:true

But it now gives me this error:
Error org.freedesktop.DBus.Error.InteractiveAuthorizationRequired: 
Interactive authentication required.

...probably because I have no loginctl session:
$ loginctl
   SESSIONUID USER SEAT TTY

0 sessions listed.
$ loginctl session-status
Could not get properties: No such process
$ strace -f loginctl session-status 2>&1|grep ESRCH
$ 

I log in via lightdm and run an xsession script.  It may have worked in
the past because I was running ck-launch-session, which apparently no
longer exists.  pam_systemd also logs "No such process":
Apr 09 11:37:30 golbez lightdm[14767]: pam_systemd(lightdm:session): 
pam-systemd initializing
Apr 09 11:37:30 golbez lightdm[14767]: pam_systemd(lightdm:session): 
Asking logind to create session: uid=1000 pid=14767 service=lightdm type=x11 
class=user desktop=lightdm-xsession seat=seat0 vtnr=7 tty= display=:0 remote=no 
remote_user= remote_host=
Apr 09 11:37:30 golbez lightdm[14767]: pam_systemd(lightdm:session): 
Failed to create session: No such process

The same happens if I log in on a tty rather than X11:
Apr 09 12:07:58 golbez login[16106]: pam_systemd(login:session): 
pam-systemd initializing
Apr 09 12:07:58 golbez login[16106]: pam_systemd(login:session): Asking 
logind to create session: uid=1000 pid=16106 service=login type=tty class=user 
desktop= seat= vtnr=0 tty=tty3 display= remote=no remote_user= remote_host=
Apr 09 12:07:58 golbez login[16106]: pam_systemd(login:session): Failed 
to create session: No such process

logind is running:
root 15741  0.0  0.0  64304  5808 ?Ss   11:59   0:00 
/lib/systemd/systemd-logind
(I restarted it after the first failure.)

strace shows that logind fails to open a 'cgroup' file:
openat(AT_FDCWD, "/proc/16134/cgroup", O_RDONLY|O_CLOEXEC) = -1 ENOENT 
(No such file or directory)
sendmsg(12, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base=..., 
iov_len=104}, {iov_base="\17\0\0\0No such process\0", iov_len=20}], 
msg_iovlen=2, msg_controllen=0, msg_flags=0}, MSG_DONTWAIT|MSG_NOSIGNAL) = 124

I'm marking this "important" because, according to the package
description, registering this session is the only purpose of the
package.  But on another system, I do seem to get a valid session.

- Michael


-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (900, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages libpam-systemd depends on:
ii  dbus1.12.6-2
ii  libc6   2.27-3
ii  libpam-runtime  1.1.8-3.7
ii  libpam0g1.1.8-3.7
ii  systemd 238-4
ii  systemd-sysv238-4

libpam-systemd recommends no packages.

libpam-systemd suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature
-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.

Bug#888620: evince: apparmor profile prevents loading git-annex files

[Michael Gold]

Package: evince
Version: 3.26.0-2

A recent kernel upgrade pulled in AppArmor, after which I was no longer
able to view (some) PDF files in git-annex repositories.  For example:
$ cd
$ pwd -P
/home/michael
$ cd ~/x
$ mkdir git-annex-test
$ cd git-annex-test/
$ pwd -P
/xr0/michael/x/git-annex-test
$ git init
Initialized empty Git repository in /xr0/michael/x/git-annex-test/.git/
$ git annex init
init  ok
(recording state in git...)
$ cp ~/download/meltdown.pdf .
$ git annex add --backend=SHA256 meltdown.pdf
add meltdown.pdf ok
(recording state in git...)
$ ls -l
total 4
lrwxrwxrwx 1 michael michael 186 Jan 27 14:54 meltdown.pdf -> 
.git/annex/objects/j9/5J/SHA256-s188549--593ea59090a096211b06194fb5985d5c2ea2b5bd85b540d01802d5d7da2d36f8/SHA256-s188549--593ea59090a096211b06194fb5985d5c2ea2b5bd85b540d01802d5d7da2d36f8
$ /usr/bin/evince meltdown.pdf

(This is basically the same setup I use to store most of my PDF files.)

The evince window appears and shows this error:
Unable to open document 
“file:///home/michael/x/git-annex-test/meltdown.pdf”.
And this message is logged:
apparmor="DENIED" operation="open" profile="/usr/bin/evince" 
name="/xr0/michael/x/git-annex-test/.git/annex/objects/j9/5J/SHA256-s188549--593ea59090a096211b06194fb5985d5c2ea2b5bd85b540d01802d5d7da2d36f8/SHA256-s188549--593ea59090a096211b06194fb5985d5c2ea2b5bd85b540d01802d5d7da2d36f8"
 pid=21442 comm="EvJobScheduler" requested_mask="r" denied_mask="r" fsuid=1000 
ouid=1000

The problem seems to be that the file isn't treated as being under $HOME
and isn't treated as having a ".pdf" suffix.  Both are true for the name
being opened, but not for the target.

Workaround (disables the policy):
# ln -s ../usr.bin.evince /etc/apparmor.d/disable/
# apparmor_parser -R /etc/apparmor.d/usr.bin.evince

I don't understand what the policy is trying to guard against; a comment
says requiring an extension is "more secure", but doesn't explain why.

- Michael


-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64, mips, i386

Kernel: Linux 4.14.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages evince depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.26.1-2
ii  evince-common3.26.0-2
ii  gsettings-desktop-schemas3.24.1-2
ii  libatk1.0-0  2.26.1-2
ii  libc62.26-2
ii  libcairo-gobject21.15.8-3
ii  libcairo21.15.8-3
ii  libevdocument3-4 3.26.0-2
ii  libevview3-3 3.26.0-2
ii  libgdk-pixbuf2.0-0   2.36.11-1
ii  libglib2.0-0 2.54.2-5
ii  libgnome-desktop-3-123.26.2-4
ii  libgtk-3-0   3.22.26-2
ii  libnautilus-extension1a  3.26.2-1
ii  libpango-1.0-0   1.40.14-1
ii  libpangocairo-1.0-0  1.40.14-1
ii  libsecret-1-00.18.5-5
ii  shared-mime-info 1.9-2

Versions of packages evince recommends:
ii  dbus-x11 [dbus-session-bus]  1.12.2-1

Versions of packages evince suggests:
pn  gvfs 
pn  nautilus-sendto  
ii  poppler-data 0.4.8-2
pn  unrar

-- no debconf information


signature.asc
Description: PGP signature

Bug#887041: notmuch: add an option to change the database path

[Michael Gold]

Package: notmuch
Version: 0.25.3-1
Severity: wishlist

I upgraded to isync 1.3.0-1, and it seems unhappy about where notmuch is
storing its database:
  Maildir error: found subfolder '.notmuch/xapian', but store 'local' does not 
specify SubFolders style
(That's a fatal error and I don't see a way to make it ignore the file.)

A notmuch option to change the database path would be nice to have.
There's 'database.path', but that's actually the mail path rather than
the database path.  I see no obvious way to make it store its database
outside of the mail tree.

- Michael


-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages notmuch depends on:
ii  libc6   2.26-2
ii  libglib2.0-02.54.2-5
ii  libgmime-3.0-0  3.0.5-1
ii  libnotmuch5 0.25.3-1
ii  libtalloc2  2.1.10-2
ii  zlib1g  1:1.2.8.dfsg-5

Versions of packages notmuch recommends:
ii  alot 0.6-2
ii  elpa-notmuch 0.25.3-1
ii  gnupg-agent  2.2.4-1
ii  gpg-agent [gnupg-agent]  2.2.4-1
ii  gpgsm2.2.4-1

notmuch suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature
-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.

Bug#878087: qemu-system-x86: xmodmap + qemu, keyboard settings is ignored

[Michael Gold]

On Mon, Oct 09, 2017 at 21:02:43 +0300, Michael Tokarev wrote:
> 09.10.2017 20:34, Antonio wrote:
> > Package: qemu-system-x86
> > Version: 1:2.10.0+dfsg-2
> > 
> > Dear Maintainer,
> > 
> > if you modify some keys with xmodmap (eg: xmodmap -e "keycode 91=Delete" -e 
> > "keycode 90=Insert" -e "keycode 79=Home" -e "keycode 87=End" -e "keycode 
> > 81=Prior" -e "keycode 89=Next")
> > and then run qemu-system-x86_64, keyboard setting (-k it) is ignored and 
> > en-us keyboard is set as default.
> > 
> > With previous version 1:2.10.0+dfsg-1 there was no problem.
> 
> It looks like this is a wontfix bug. The "problem" seems to be that
> more recent ui frontends (sdl2 which is enabled in -2 compared to
> obsolete sdl1 used before, and gtk to be enabled later), keyboard
> handling has been reworked, and qemu now always uses raw keycodes,
> not preprocessed by modmap and other tools, with guest being able
> to see all keyboard keys.  You have to use xmodmap INSIDE the guest
> to achieve what you want.

I've recently been affected by this as well, and don't find the proposed
solution practical.  It assumes the guest is also using X11 or otherwise
allows the desired remapping, but in many guest OSes the ability doesn't
exist or is restricted (only allowing for "popular" layouts/tweaks).  If
the ability is there, but there's no persistent or network-mounted disk,
the mapping will need to be redone at every boot, which may be difficult
with the "wrong" layout.  If I share an image with someone else, they'll
need to find some way to reset it to a more familiar layout.

The ability to "hide" host settings such that people can use a common OS
image is a very useful feature of qemu.  I'd like to see it work for the
keyboard layout, as it does for other things: network hardware/settings,
CPU type/count, etc.  Is any workaround for this known?  And does the -k
option have any effect now?  My preference is to have it work as before;
but if it will have no effect, it should raise an error or be removed.

-- Michael


signature.asc
Description: PGP signature

Bug#873363: musl-dev: amd64 and mips versions conflict

[Michael Gold]

Package: musl-dev
Version: 1.1.16-3
Severity: wishlist

( I previously filed a similar bug for the musl package:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=803577 )

I wanted to compile a program for MIPS, linked against musl, and found I
had to remove musl-dev:amd64 to install musl-dev:mips.  I don't see any
good reason why musl-dev can't be installed for several architectures at
the same time.  Most of the content is already in architecture-specific
directories:
/usr/include/mips-linux-musl/
/usr/lib/mips-linux-musl/
/lib/mips-linux-musl
/etc/ld-musl-mips.d

The stuff outside those directories looks like it would be the same for
all architectures.  I don't see any explicit 'Conflicts' lines in the
'apt show' output, but apt believes they conflict:
$ apt install musl-dev musl-dev:mips
The following packages have unmet dependencies:
 musl-dev : Recommends: linux-musl-dev but it is not installable
Conflicts: musl-dev:mips but 1.1.16-3 is to be installed
 musl-dev:mips : Recommends: linux-musl-dev:mips but it is not 
installable
 Conflicts: musl-dev but 1.1.16-3 is to be installed

- Michael


-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64, mips, i386

Kernel: Linux 4.12.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages musl-dev depends on:
ii  musl  1.1.16-3

Versions of packages musl-dev recommends:
pn  linux-musl-dev  

musl-dev suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#873364: musl-dev: should provide .specs file for cross-compiling

[Michael Gold]

Package: musl-dev
Version: 1.1.16-3
Severity: wishlist

musl-tools:mips depends on gcc:mips, and I wasn't able to install either
package on my amd64 system.  But I was able to install musl-dev:mips and
use gcc-mips-linux-gnu:amd64 to build a working program after extracting
musl-gcc.specs from musl-tools:mips manually:
mips-linux-gnu-gcc -static -o hello hello.c \
-specs /usr/share/dpkg/no-pie-compile.specs \
-specs /usr/share/dpkg/no-pie-link.specs \
-specs ~/gcc-mips-linux-musl.specs
(This command is based on /usr/bin/musl-gcc.)

Perhaps the packages could be adjusted as follows to make this easier:
 * Move the .specs files into musl-dev as-is, and move /usr/bin/musl-gcc
   there as /usr/bin/mips-linux-musl-gcc (assuming mips; 'cc' inside the
   script would have to be changed to 'mips-linux-gnu-gcc').
 * Have /usr/bin/musl-gcc from musl-tools just run the native *-musl-gcc
   script.

- Michael


-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64, mips, i386

Kernel: Linux 4.12.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages musl-dev depends on:
ii  musl  1.1.16-3

Versions of packages musl-dev recommends:
pn  linux-musl-dev  

musl-dev suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#857745: vbindiff: segmentation fault at end of file

[Michael Gold]

Package: vbindiff
Version: 3.0-beta4-1+b3
Severity: important

I'm seeing segfaults in vbindiff, apparently when it reaches the end of
the file(s).  These steps trigger it immediately:
  echo test > a
  echo test > b
  vbindiff a b

gdb shows a crash in strlen().

For larger files, it works until I scroll to the end.

- Michael


-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages vbindiff depends on:
ii  libc62.24-9
ii  libgcc1  1:6.3.0-6
ii  libncurses5  6.0+20161126-1
ii  libstdc++6   6.3.0-6
ii  libtinfo56.0+20161126-1

vbindiff recommends no packages.

vbindiff suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature
-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.

Bug#839278: oathtool: has no secure way to provide a key

[Michael Gold]

Package: oathtool
Version: 2.6.1-1

According to the man page, oathtool only accepts a key as a command-line
parameter.  This is generally insecure: command lines are visible to all
system users, unless procfs isn't available or has been mounted with the
non-default "hidepid" option.

There should be a secure way to provide the key, and the man page should
encourage its use.  It could be an environment variable or configuration
file.  Accepting a key on stdin would also be OK, as long as one doesn't
first pass it to an external utility like /bin/printf or /bin/echo using
command-line parameters.

- Michael


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64, mips, i386

Kernel: Linux 4.7.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages oathtool depends on:
ii  libc6 2.24-3
ii  liboath0  2.6.1-1

oathtool recommends no packages.

oathtool suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#839277: chromium: sandbox won't run unless world-executable

[Michael Gold]

Package: chromium
Version: 53.0.2785.113-1
Severity: wishlist

/usr/lib/chromium/chrome-sandbox won't run unless it's world-executable,
due to this code in sandbox/linux/suid/client/setuid_sandbox_host.cc:
  if (access(sandbox_binary.c_str(), X_OK) != 0 || (st.st_uid != 0) ||
  ((st.st_mode & S_ISUID) == 0) || ((st.st_mode & S_IXOTH)) == 0) {
LOG(FATAL) << "The SUID sandbox helper binary was found, but is not "
  "configured correctly. Rather than run without sandboxing "
  "I'm aborting now. You need to make sure that "
   << sandbox_binary << " is owned by root and has mode 4755.";
  }

Please remove the last check (IXOTH).  System accounts like 'nobody' and
'lp' should never run the sandbox, so I've used chgrp and 'chmod o-x' to
ensure only users with GUI access can run it on my system.  And it works
as long as this check is disabled.  The access() check should be enough,
anyway, to verify it will run.

I'm not sure the other checks are useful either--a similar message could
instead be printed when execve() fails or the sandbox sees EPERM/EACCES.
The sandbox itself looks like it will try to continue when geteuid()!=0,
until something important actually fails; this might let it work without
being setuid if the administrator has enabled filesystem capabilities or
unprivileged namespaces.

- Michael


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64, mips, i386

Kernel: Linux 4.7.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages chromium depends on:
ii  libasound2   1.1.2-1
ii  libatk1.0-0  2.22.0-1
ii  libavcodec57 7:3.1.3-1+b3
ii  libavformat577:3.1.3-1+b3
ii  libavutil55  7:3.1.3-1+b3
ii  libc62.24-3
ii  libcairo21.14.6-1+b1
ii  libcups2 2.2.0-2
ii  libdbus-1-3  1.10.10-1
ii  libexpat12.2.0-1
ii  libfontconfig1   2.11.0-6.7
ii  libfreetype6 2.6.3-3+b1
ii  libgcc1  1:6.2.0-4
ii  libgdk-pixbuf2.0-0   2.36.0-1
ii  libglib2.0-0 2.50.0-1
ii  libgnome-keyring03.12.0-1+b1
ii  libgtk-3-0   3.22.0-1
ii  libharfbuzz0b1.2.7-1+b1
ii  libjpeg62-turbo  1:1.5.1-1
ii  libnettle6   3.2-1
ii  libnspr4 2:4.12-6
ii  libnss3  2:3.26-2
ii  libpango-1.0-0   1.40.3-2
ii  libpangocairo-1.0-0  1.40.3-2
ii  libpci3  1:3.3.1-1.1
ii  libpulse09.0-3
ii  libspeechd2  0.8.5-1
ii  libstdc++6   6.2.0-4
ii  libx11-6 2:1.6.3-1
ii  libxcomposite1   1:0.4.4-1
ii  libxcursor1  1:1.1.14-1+b1
ii  libxdamage1  1:1.1.4-2+b1
ii  libxext6 2:1.3.3-1
ii  libxfixes3   1:5.0.2-1
ii  libxi6   2:1.7.6-1
ii  libxml2  2.9.4+dfsg1-2
ii  libxrandr2   2:1.5.0-1
ii  libxrender1  1:0.9.9-2
ii  libxslt1.1   1.1.29-1
ii  libxss1  1:1.2.2-1
ii  libxtst6 2:1.2.2-1+b1
ii  x11-utils7.7+3
ii  xdg-utils1.1.1-1

Versions of packages chromium recommends:
ii  fonts-liberation  1:1.07.4-2

Versions of packages chromium suggests:
pn  chromium-l10n  

-- no debconf information


signature.asc
Description: PGP signature

Bug#825974: [Pkg-mc-devel] Bug#825974: mc: subshell no longer sees correct terminal size

[Michael Gold]

On Wed, Jun 01, 2016 at 14:07:01 +0200, Yury V. Zaytsev wrote:
> On Tue, 31 May 2016, Michael Gold wrote:
> 
> > When I press CTRL-O in mc to use the subshell, and resize the terminal,
> > applications no longer see the new size (as they used to)--they always
> > see the original size.
> 
> Hi Michael,
> 
> I think that this might be a regression caused by this fix:
> 
>http://www.midnight-commander.org/ticket/3639#comment:13
> 
> It would be great if you could confirm that the proposed solution fixes your
> problem... Sorry about that!

Thank you.  Reverting the linked changeset and applying that diff fixed
the problem.  I've attached an automated regression test.  (If running
without installing, prepend the build directory to $PATH.)

-- Michael
// Verify that mc's subshell sees the correct terminal size
// after it's changed.  See https://bugs.debian.org/825974#.

/*
This is free and unencumbered software released into the public domain.

Anyone is free to copy, modify, publish, use, compile, sell, or
distribute this software, either in source code form or as a compiled
binary, for any purpose, commercial or non-commercial, and by any
means.

In jurisdictions that recognize copyright laws, the author or authors
of this software dedicate any and all copyright interest in the
software to the public domain. We make this dedication for the benefit
of the public at large and to the detriment of our heirs and
successors. We intend this dedication to be an overt act of
relinquishment in perpetuity of all present and future rights to this
software under copyright law.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
IN NO EVENT SHALL THE AUTHORS BE LIABLE FOR ANY CLAIM, DAMAGES OR
OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
OTHER DEALINGS IN THE SOFTWARE.

For more information, please refer to <https://unlicense.org/>
*/

#define _POSIX_C_SOURCE 200809L
#define _XOPEN_SOURCE 700
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

static void
die_perror(const char *str)
{
	perror(str);
	exit(1);
}

static void
die_usage(const char *name)
{
	fprintf(stderr, "Usage: %s\n", name);
	exit(2);
}

static void*
drainer(void *arg)
{
	char buf[1024];
	int *p_fd = arg;
	ssize_t rv;

	do {
		rv = read(*p_fd, [0], sizeof buf);
	} while (rv > 0);

	return (rv == 0) ? NULL : (void*)(intptr_t)errno;
}

static void
close_fd(int fd)
{
	do {} while (close(fd) < 0 && errno == EINTR);
}

static void
write_str_or_die(int fd, const char *str)
{
	size_t offset = 0, len = strlen(str);
	while (offset < len) {
		ssize_t rv = write(fd, [offset], len);
		if (rv < 0) {
			if (errno == EINTR) continue;
			die_perror("write");
		}
		offset += (size_t)rv;
	}
}

static size_t
read_to_eof_or_die(int fd, char *buf, size_t bufsz)
{
	size_t offset = 0;
	while (offset < bufsz) {
		ssize_t rv = read(fd, [offset], bufsz-offset);
		if (rv < 0) {
			if (errno == EINTR) continue;
			die_perror("read");
		} else if (rv == 0) {
			break;
		}
		offset += (size_t)rv;
	}
	return offset;
}

int
main(int argc, char **argv)
{
	int opt;
	int pty_master, pty_slave;
	int pipefd[2];
	int child_pid;
	const char *slave_path;
	char buf[256];
	pthread_t drainer_tid;
	struct winsize winsz = { .ws_row = 25, .ws_col = 55 };

	while ((opt = getopt(argc, argv, "")) != -1) {
		switch (opt) {
		default:
		case '?':
			die_usage(argv[0]);
		}
	}
	if (optind > argc) {
		die_usage(argv[0]);
	}

	// Set up a pseudoterminal
	pty_master = posix_openpt(O_RDWR | O_NOCTTY | O_CLOEXEC);
	if (pty_master < 0) {
		die_perror("posix_openpt");
	}
	if (grantpt(pty_master) < 0) {
		die_perror("grantpt");
	}
	if (unlockpt(pty_master) < 0) {
		die_perror("unlockpt");
	}
	slave_path = ptsname(pty_master);
	if (!slave_path) {
		die_perror("ptsname");
	}

	// Set the initial size
	if (ioctl(pty_master, TIOCSWINSZ, ) < 0) {
		die_perror("ioctl(TIOCSWINSZ)");
	}

	pty_slave = open(slave_path, O_RDWR | O_NOCTTY);
	if (pty_slave < 0) {
		die_perror("open(slave)");
	}

	// Create a pipe to communicate with mc
	if (pipe([0]) < 0) {
		die_perror("pipe");
	}

	// Fork a process to run mc
	child_pid = fork();
	if (child_pid < 0) {
		die_perror("fork");
	} else if (!child_pid) {
		char *exec_args[] = {"mc", (char*)NULL};

		if (setsid() < 0) {
			die_perror("setsid");
		}
		if (ioctl(pty_slave, TIOCSCTTY, NULL) < 0) {
			die_perror("ioctl(TIOCSCTTY)");
		}
		if (dup2(pty_slave, 0) < 0
|| dup2(pty_slave, 1) < 0
|| dup2(pty_sla

Bug#825974: mc: subshell no longer sees correct terminal size

[Michael Gold]

Package: mc
Version: 3:4.8.17-1

When I press CTRL-O in mc to use the subshell, and resize the terminal,
applications no longer see the new size (as they used to)--they always
see the original size.

E.g., open a urxvt window, run mc, press CTRL-O, and run "stty size";
then resize the window and run "stty size" again.  It should show the
new size, but instead shows the same values as before.  Outside of mc
this works as expected.

The effect can also be seen when viewing a text file in vim: after
enlarging the terminal, vim won't fill the screen.  However, when I
press F4 to run vim, its size does update correctly.

- Michael


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64, mips

Kernel: Linux 4.5.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages mc depends on:
ii  e2fslibs  1.43-2
ii  libc6 2.22-9
ii  libglib2.0-0  2.48.1-1
ii  libgpm2   1.20.4-6.2
ii  libslang2 2.3.0-2.3
ii  libssh2-1 1.5.0-2.1
ii  mc-data   3:4.8.17-1

Versions of packages mc recommends:
ii  mime-support  3.60
ii  perl  5.22.2-1
ii  unzip 6.0-20

Versions of packages mc suggests:
ii  arj  3.10.22-14
ii  bzip21.0.6-8
ii  catdvi   0.14-12.1
pn  dbview   
ii  djvulibre-bin3.5.27.1-5
ii  evince [pdf-viewer]  3.20.0-3
ii  file 1:5.25-2
ii  genisoimage  9:1.1.11-3
ii  gv [pdf-viewer]  1:3.7.4-1
ii  imagemagick  8:6.8.9.9-7+b2
ii  links2.12-2
ii  lynx 2.8.9dev9-1
ii  mupdf [pdf-viewer]   1.7a-1+b1
pn  odt2txt  
ii  poppler-utils0.38.0-3
ii  python   2.7.11-1
pn  python-boto  
ii  python-tz2015.7+dfsg-0.1
ii  texlive-binaries 2016.20160513.41080-2
ii  w3m  0.5.3-28
ii  zip  3.0-11

-- no debconf information


signature.asc
Description: PGP signature

Bug#824277: openpgpkey fails with "Unexpected fingerprint collision"

[Michael Gold]

Package: hash-slinger
Version: 2.7-1

I have "keyring /usr/share/keyrings/debian-keyring.gpg" in my gpg.conf,
and always get an error when trying to encode a key with the openpgpkey
tool:
$ openpgpkey --output rfc mich...@bitplane.org
Traceback (most recent call last):
  File "/usr/bin/openpgpkey", line 223, in 
disk_keys = gpgdisk.list_keys()
  File "/usr/lib/python2.7/dist-packages/gnupg.py", line 1170, in 
list_keys
return self._get_list_output(p, 'list')
  File "/usr/lib/python2.7/dist-packages/gnupg.py", line 1139, in 
_get_list_output
getattr(result, keyword)(L)
  File "/usr/lib/python2.7/dist-packages/gnupg.py", line 488, in fpr
raise ValueError('Unexpected fingerprint collision: %s' % fp)
ValueError: Unexpected fingerprint collision: 
3A8385A5E0D831094589C894824E72CE975B9053
$ 

Commenting out that line of gpg.conf makes it work.

- Michael


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64, mips

Kernel: Linux 4.4.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages hash-slinger depends on:
ii  ca-certificates20160104
ii  dns-root-data  2015052300+h+1
ii  libpython2.7-stdlib [python-argparse]  2.7.11-9
ii  openssh-client 1:7.2p2-5
ii  python 2.7.11-1
ii  python-dnspython   1.12.0-1
ii  python-gnupg   0.3.8-2
ii  python-ipaddr  2.1.11-2
ii  python-m2crypto0.24.0-1
ii  python-unbound 1.5.8-1

hash-slinger recommends no packages.

hash-slinger suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#810727: msmtp: should be able to pull hostname from server greeting (for gssapi)

[Michael Gold]

On Mon, Jan 11, 2016 at 11:42:53 -0500, Michael Gold wrote:
> The server greeting ("220" line) includes the canonical hostname:
>   220 HOSTNAME.example Microsoft ESMTP MAIL Service ready at Mon, 11 Jan 2016 
> 11:21:25 -0500
> Please consider using this value, instead of the configured hostname,
> for gssapi authentication.  I'd do this by default, with an option to
> disable it.  It should be safe--RFC 5321 states:
>   "all the greeting-type replies have the official name (the fully-
>qualified primary domain name) of the server host as the first word
>following the reply code."

It occurs to me that this will enable a new attack vector if not done
carefully.  Normally if somebody spoofs DNS to point the user to another
server, or otherwise diverts the connection, the Kerberos authentication
will fail because the fake server doesn't have the proper key.  But this
protection won't work if we pull the hostname from the greeting.  So, it
could only be done after some extra checks, e.g.:
 * DNSSEC validation or TLS certificate validation on the original name,
 * some kind of secure out-of-band lookup like LDAP; or,
 * a configured list of acceptable aliases.

-- Michael


signature.asc
Description: PGP signature
-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.

Bug#810727: msmtp: should be able to pull hostname from server greeting (for gssapi)

[Michael Gold]

Package: msmtp
Version: 1.6.3-1
Severity: wishlist

My company's mail server is normally accessed through a round-robin DNS
alias; but, for gssapi (krb5) authentication to work, I had to put one
of the actual hostnames in .msmtprc (and set dns_canonicalize_hostname
to false in krb5.conf because reverse-DNS is broken).

The server greeting ("220" line) includes the canonical hostname:
  220 HOSTNAME.example Microsoft ESMTP MAIL Service ready at Mon, 11 Jan 2016 
11:21:25 -0500
Please consider using this value, instead of the configured hostname,
for gssapi authentication.  I'd do this by default, with an option to
disable it.  It should be safe--RFC 5321 states:
  "all the greeting-type replies have the official name (the fully-
   qualified primary domain name) of the server host as the first word
   following the reply code."
(Passing that hostname to passwordeval somehow might be useful too.)

- Michael


-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages msmtp depends on:
ii  debconf [debconf-2.0]  1.5.58
ii  libc6  2.21-6
ii  libgnutls-deb0-28  3.3.19-1
ii  libgsasl7  1.8.0-8
ii  libidn11   1.32-3
ii  ucf3.0031

Versions of packages msmtp recommends:
ii  ca-certificates  20160104

Versions of packages msmtp suggests:
pn  msmtp-mta  

-- debconf information:
  msmtp/tls: false
  msmtp/sysconfig: false
  msmtp/port: 25
  msmtp/auto_from: true
  msmtp/maildomain:
  msmtp/host:


signature.asc
Description: PGP signature
-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.

Bug#810741: gsasl: produces unhelpful error message on Kerberos failure

[Michael Gold]

Package: gsasl
Version: 1.8.0-8

As I noted in Debian bug #810727, I need to use the proper hostname to
connect to my SMTP server; otherwise Kerberos authentication will fail.
But this wasn't easy to figure out, as the message returned by msmtp is
kind of useless (it seems to just print whatever text is returned by GNU
SASL):
msmtp: GNU SASL: GSSAPI error in client while negotiating security
context in gss_init_sec_context() in SASL library.  This is most
likely due insufficient credentials or malicious interactions.

This makes it seem like I used a bad password or the SMTP server didn't
like the ticket.  In fact, the Kerberos server didn't recognise the
hostname, and according to a Wireshark dump returned a perfectly clear
error message:
krb-error
pvno: 5
msg-type: krb-error (30)
stime: 2016-01-11 16:08:01 (UTC)
susec: 299239
error-code: eRR-S-PRINCIPAL-UNKNOWN (7)
realm: EXAMPLE.COM
sname
name-type: kRB5-NT-SRV-HST (3)
name-string: 2 items
KerberosString: smtp
KerberosString: smtp-server.EXAMPLE.COM

I suggest a message like the following, based on the libkrb5 text:
"Server not found in Kerberos database:
 smtp/smtp-server.example@example.com"

- Michael


-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages gsasl depends on:
ii  dpkg   1.18.4
ii  install-info   6.0.0.dfsg.1-4
ii  libc6  2.21-6
ii  libgnutls-deb0-28  3.3.19-1
ii  libgsasl7  1.8.0-8

gsasl recommends no packages.

gsasl suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature
-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.

Bug#806644: git-annex: can't add files with names >= 127 characters

[Michael Gold]

Package: git-annex
Version: 5.20151116-1

'git annex add' no longer works for filenames of 127 characters or more.
I have longer names in my repository, so it must be a recent regression.
A workaround is to add with a shorter name and use 'git mv'.

$ touch 
PPP
$ git annex add 
PPP
add 
PPP
 
git-annex: 
../../../../.git/annex/objects/Jx/11/SHA1-s0--da39a3ee5e6b4b0d3255bfef95601890afd80709/SHA1-s0--da39a3ee5e6b4b0d3255bfef95601890afd80709:
 createSymbolicLink: invalid argument (File name too long)
failed
git-annex: add: 1 failed
$ touch 
PP
$ git annex add 
PP
$ 

- Michael


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64, mips

Kernel: Linux 4.2.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages git-annex depends on:
ii  curl   7.45.0-1+b1
ii  git1:2.6.2-1
ii  libc6  2.19-22
ii  libffi63.2.1-3
ii  libgmp10   2:6.1.0+dfsg-2
ii  libgnutls-deb0-28  3.3.18-1
ii  libgsasl7  1.8.0-8
ii  libidn11   1.32-3
ii  libsqlite3-0   3.9.2-1
ii  libxml22.9.2+zdfsg1-4
ii  openssh-client 1:6.9p1-3
ii  rsync  3.1.1-3
ii  wget   1.17-1
ii  zlib1g 1:1.2.8.dfsg-2+b1

Versions of packages git-annex recommends:
ii  aria2  1.19.0-1
ii  bind9-host 1:9.9.5.dfsg-12+b1
ii  git-remote-gcrypt  0.20130908-7
ii  gnupg  1.4.19-6
ii  lsof   4.89+dfsg-0.1
ii  nocache0.9-2
ii  quvi   0.4.2-2

Versions of packages git-annex suggests:
ii  bup  0.27-1
ii  graphviz 2.38.0-12
pn  libnss-mdns  
pn  tahoe-lafs   

-- no debconf information


signature.asc
Description: PGP signature

Bug#804511: systemd: won't let me mount /media/dvd after plugging in a USB optical drive

[Michael Gold]

On Mon, Nov 09, 2015 at 05:06:56 +0100, Michael Biebl wrote:
> Am 09.11.2015 um 04:49 schrieb Michael Gold:
> > On Mon, Nov 09, 2015 at 03:41:44 +0100, Michael Biebl wrote:
> >> Is the behaviour reproducible? If so, what are the exact steps?
> > 
> > It's still unmounting as soon as I mount something.  If you know of a
> > way to clear the association without rebooting, I'll see whether I can
> > get it into that state again.
> 
> Hm, I'd probably try systemctl stop media-dvd.mount and systemctl
> daemon-reload.

Thanks, that seemed to work.  I'm still trying to reproduce the problem,
but, so far, unsuccessfully.

I've noticed that the /dev/dvd symlink changes from sr0 to sr1 when the
drive is attached, which may be relevant.  And systemd first tried to
unmount the drive (and failed repeatedly) after a VFS message:
Nov  8 17:45:00 terra kernel: [1232466.900550] VFS: busy inodes on 
changed media or resized disk sr1
Nov  8 17:45:00 terra systemd[1]: Unmounting /media/dvd...
Nov  8 17:45:00 terra umount[16978]: umount: /media/dvd: target is busy
Nov  8 17:45:00 terra systemd[1]: media-dvd.mount: Mount process 
exited, code=exited status=32
Nov  8 17:45:00 terra systemd[1]: Failed unmounting /media/dvd.
Nov  8 17:45:00 terra systemd[1]: media-dvd.mount: Unit is bound to 
inactive unit dev-sr1.device. Stopping, too.
Nov  8 17:45:00 terra systemd[1]: Unmounting /media/dvd...
...
Nov  8 17:45:00 terra systemd[1]: media-dvd.mount: Unit is bound to 
inactive unit dev-sr1.device, but not stopping since we tried this too often 
recently.
Nov  8 17:45:36 terra kernel: [1232502.432925] usb 4-1.6.1: USB 
disconnect, device number 37
Nov  8 18:00:02 terra systemd[1]: media-dvd.mount: Unit entered failed 
state.

A more detailed log is attached.  I don't remember exactly what I was
doing.  In general, I was dd'ing images from disc and loopback-mounting
the files (on /media/dvd), with one direct disc-mount to grab a file I
missed.  The drive had been unplugged a few hours before I attempted
another loopback mount:
Nov  8 20:34:33 terra kernel: [1242629.850891] UDF-fs: INFO Mounting 
volume 'CDROM', timestamp 2015/11/08 23:14 (1000)
Nov  8 20:34:33 terra systemd[1]: media-dvd.mount: Unit is bound to 
inactive unit dev-sr1.device. Stopping, too.
Nov  8 20:34:33 terra systemd[1]: Unmounting /media/dvd...
Nov  8 20:34:33 terra systemd[1]: Unmounted /media/dvd.
Nov  8 20:34:33 terra systemd[1]: media-dvd.mount: Unit entered failed 
state.

-- Michael
Nov  8 09:22:45 terra kernel: [1202360.436774] usb 4-1.5: new high-speed USB 
device number 36 using ehci-pci
Nov  8 09:22:45 terra kernel: [1202360.529028] usb 4-1.5: New USB device found, 
idVendor=0424, idProduct=2514
Nov  8 09:22:45 terra kernel: [1202360.529033] usb 4-1.5: New USB device 
strings: Mfr=0, Product=0, SerialNumber=0
Nov  8 09:22:45 terra kernel: [1202360.529460] hub 4-1.5:1.0: USB hub found
Nov  8 09:22:45 terra kernel: [1202360.529641] hub 4-1.5:1.0: 4 ports detected
Nov  8 13:32:05 terra kernel: [1217306.479150] usb 4-1.6.1: new high-speed USB 
device number 37 using ehci-pci
Nov  8 13:32:05 terra kernel: [1217306.576431] usb 4-1.6.1: New USB device 
found, idVendor=0e8d, idProduct=1806
Nov  8 13:32:05 terra kernel: [1217306.576445] usb 4-1.6.1: New USB device 
strings: Mfr=1, Product=2, SerialNumber=3
Nov  8 13:32:05 terra kernel: [1217306.576448] usb 4-1.6.1: Product: MT1887 
Nov  8 13:32:05 terra kernel: [1217306.576450] usb 4-1.6.1: Manufacturer: 
MediaTek Inc
Nov  8 13:32:05 terra kernel: [1217306.580218] usb-storage 4-1.6.1:1.0: USB 
Mass Storage device detected
Nov  8 13:32:05 terra kernel: [1217306.580674] scsi host12: usb-storage 
4-1.6.1:1.0
Nov  8 13:32:05 terra mtp-probe: checking bus 4, device 37: 
"/sys/devices/pci:00/:00:1d.0/usb4/4-1/4-1.6/4-1.6.1"
Nov  8 13:32:05 terra mtp-probe: bus: 4, device: 37 was not an MTP device
Nov  8 13:32:06 terra kernel: [1217307.580959] scsi 12:0:0:0: CD-ROM
TSSTcorp CDDVDW SE-208GB  TS00 PQ: 0 ANSI: 0
Nov  8 13:32:06 terra kernel: [1217307.612053] sr 12:0:0:0: [sr1] scsi3-mmc 
drive: 8x/24x writer dvd-ram cd/rw xa/form2 cdda tray
Nov  8 13:32:06 terra kernel: [1217307.612336] sr 12:0:0:0: Attached scsi 
CD-ROM sr1
Nov  8 13:32:06 terra kernel: [1217307.612477] sr 12:0:0:0: Attached scsi 
generic sg10 type 5
Nov  8 13:32:22 terra kernel: [1217323.591386] sr 12:0:0:0: [sr1] FAILED 
Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Nov  8 13:32:22 terra kernel: [1217323.591394] sr 12:0:0:0: [sr1] Sense Key : 
Medium Error [current] 
Nov  8 13:32:22 terra kernel: [1217323.591397] sr 12:0:0:0: [sr1] Add. Sense: 
L-EC uncorrectable error
Nov  8 13:32:22 terra kernel: [1217323.591401] sr 12:0:0:0: [sr1] CDB: Read(10) 
28 00 00 05 7a 70 00 00 02 00 00 00
Nov  8 13:32:22 terra kernel: [1217323.591405] blk_update_reque

Bug#804512: systemd: typo in reportbug output ("analzye")

[Michael Gold]

Package: systemd
Version: 227-2
Severity: minor

When I run "reportbug --template systemd", it includes this text:
> state of running services and units (output of systemd-analzye dump).

The command is "systemd-analyze", not "systemd-analzye".

- Michael


-- Package-specific info:

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64, mips

Kernel: Linux 4.2.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages systemd depends on:
ii  adduser 3.113+nmu3
ii  libacl1 2.2.52-2
ii  libapparmor12.10-2+b1
ii  libaudit1   1:2.4.4-4
ii  libblkid1   2.27.1-1
ii  libc6   2.19-22
ii  libcap2 1:2.24-12
ii  libcap2-bin 1:2.24-12
ii  libcryptsetup4  2:1.6.6-5
ii  libgcrypt20 1.6.4-3
ii  libkmod221-1
ii  liblzma55.1.1alpha+20120614-2.1
ii  libmount1   2.27.1-1
ii  libpam0g1.1.8-3.1
ii  libseccomp2 2.2.3-2
ii  libselinux1 2.3-2+b1
ii  libsystemd0 227-2
ii  mount   2.27.1-1
ii  sysv-rc 2.88dsf-59.2
ii  udev227-2
ii  util-linux  2.27.1-1

Versions of packages systemd recommends:
ii  dbus1.10.2-1
ii  libpam-systemd  227-2

Versions of packages systemd suggests:
pn  systemd-container  
pn  systemd-ui 

-- no debconf information


signature.asc
Description: PGP signature

Bug#804511: systemd: won't let me mount /media/dvd after plugging in a USB optical drive

[Michael Gold]

Package: systemd
Version: 227-2

I have an optical drive in my PC, with an fstab entry:
  /dev/dvd /media/dvd udf,iso9660 user,noauto 0 0
Today I plugged in another optical drive via USB; and since unplugging
it, systemd won't let me use /media/dvd for a loopback mount.

For example, I run "mount -o loop test.iso /media/dvd; ls -l /media/dvd"
and can see the contents.  But systemd immediately unmounts it:
  Nov 08 20:48:51 terra kernel: UDF-fs: warning (device loop0): udf_load_vrs: 
No anchor found
  Nov 08 20:48:51 terra kernel: UDF-fs: Rescanning with blocksize 2048
  Nov 08 20:48:51 terra kernel: UDF-fs: warning (device loop0): udf_load_vrs: 
No anchor found
  Nov 08 20:48:51 terra kernel: UDF-fs: Rescanning with blocksize 2048
  Nov 08 20:48:51 terra kernel: UDF-fs: INFO Mounting volume 'CDROM', timestamp 
2015/11/08 23:14 (1000)
  Nov 08 20:48:51 terra systemd[1]: media-dvd.mount: Unit is bound to inactive 
unit dev-sr1.device. Stopping, too.
  Nov 08 20:48:51 terra systemd[1]: Unmounting /media/dvd...
  Nov 08 20:48:51 terra systemd[1]: Unmounted /media/dvd.
  Nov 08 20:48:51 terra systemd[1]: media-dvd.mount: Unit entered failed state.

I've included the "media-dvd.mount" section from systemd-analyze below.
I don't know how that job got associated with sr1 or how to disassociate
it (/dev/dvd points to sr0).  Given that "noauto" is set, I don't expect
systemd to react at all.

A workaround is to use another mountpoint.

-- Michael


-> Unit media-dvd.mount:
Description: /media/dvd
Instance: n/a
Unit Load State: loaded
Unit Active State: failed
Inactive Exit Timestamp: Sun 2015-11-08 20:48:51 EST
Active Enter Timestamp: Sun 2015-11-08 20:48:51 EST
Active Exit Timestamp: Sun 2015-11-08 20:48:51 EST
Inactive Enter Timestamp: Sun 2015-11-08 20:48:51 EST
GC Check Good: yes
Need Daemon Reload: no
Transient: no
Slice: system.slice
CGroup: n/a
CGroup realized: no
CGroup mask: 0x0
CGroup members mask: 0x0
Name: media-dvd.mount
Documentation: man:fstab(5)
Documentation: man:systemd-fstab-generator(8)
Fragment Path: /run/systemd/generator/media-dvd.mount
Source Path: /etc/fstab
Requires: -.mount
Wants: system.slice
BindsTo: dev-sr1.device
WantedBy: dev-sr1.device
Conflicts: umount.target
Before: local-fs.target
Before: umount.target
After: systemd-journald.socket
After: local-fs-pre.target
After: system.slice
After: dev-sr1.device
After: -.mount
References: -.mount
References: systemd-journald.socket
References: local-fs-pre.target
References: umount.target
References: dev-sr1.device
References: system.slice
References: local-fs.target
RequiresMountsFor: /media /dev/dvd
StopWhenUnneeded: no
RefuseManualStart: no
RefuseManualStop: no
DefaultDependencies: yes
OnFailureJobMode: replace
IgnoreOnIsolate: yes
IgnoreOnSnapshot: no
Mount State: failed
Result: exit-code
Where: /media/dvd
What: /dev/dvd
File System Type: udf,iso9660
Options: user,noauto
From /proc/self/mountinfo: no
From fragment: yes
DirectoryMode: 0755
UMask: 0022
WorkingDirectory: /
RootDirectory: /
NonBlocking: no
PrivateTmp: no
PrivateNetwork: no
PrivateDevices: no
ProtectHome: no
ProtectSystem: no
IgnoreSIGPIPE: yes
LimitNOFILE: 4096
StandardInput: null
StandardOutput: journal
StandardError: inherit
SyslogFacility: daemon
SyslogLevel: info
KillMode: control-group
KillSignal: SIGTERM
SendSIGKILL: yes
SendSIGHUP:  no

-- Package-specific info:

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64, mips

Kernel: Linux 4.2.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages systemd depends on:
ii  adduser 3.113+nmu3
ii  libacl1 2.2.52-2
ii  libapparmor12.10-2+b1
ii  libaudit1   1:2.4.4-4
ii  libblkid1   2.27.1-1
ii  libc6   2.19-22
ii  libcap2 1:2.24-12
ii  libcap2-bin 1:2.24-12
ii  libcryptsetup4  2:1.6.6-5
ii  libgcrypt20 1.6.4-3
ii  libkmod221-1
ii  liblzma55.1.1alpha+20120614-2.1
ii  libmount1   2.27.1-1
ii  libpam0g1.1.8-3.1
ii  libseccomp2 2.2.3-2
ii  libselinux1 2.3-2+b1
ii  libsystemd0 227-2
ii  mount   2.27.1-1
ii  sysv-rc 2.88dsf-59.2
ii  udev227-2
ii  util-linux  2.27.1-1

Bug#804511: systemd: won't let me mount /media/dvd after plugging in a USB optical drive

[Michael Gold]

On Mon, Nov 09, 2015 at 03:41:44 +0100, Michael Biebl wrote:
> Am 09.11.2015 um 03:22 schrieb Michael Gold:
> > For example, I run "mount -o loop test.iso /media/dvd; ls -l /media/dvd"
> > and can see the contents.  But systemd immediately unmounts it:
...
> >   Nov 08 20:48:51 terra systemd[1]: media-dvd.mount: Unit is bound to 
> > inactive unit dev-sr1.device. Stopping, too.
> >   Nov 08 20:48:51 terra systemd[1]: Unmounting /media/dvd...
...
> > I don't know how that job got associated with sr1 or how to disassociate
> > it (/dev/dvd points to sr0).
> 
> Was the optical drive you connected via USB using /dev/sr1? Did you
> mount that drive (manually) under /media/dvd?

It was sr1, and I did mount at once at /media/dvd.  Would that make
systemd associate them?  It would be surprising for a manual mount
command to do that.

> Is the behaviour reproducible? If so, what are the exact steps?

It's still unmounting as soon as I mount something.  If you know of a
way to clear the association without rebooting, I'll see whether I can
get it into that state again.

-- Michael


signature.asc
Description: PGP signature

Bug#803780: ifupdown: systemd hangs for 2 minutes at "Raise network interfaces" while booting

[Michael Gold]

Package: ifupdown
Version: 0.7.54

systemd has always been hanging on my laptop at "Starting LSB: Raise
network interfaces", for about 2 minutes at each boot.  Disabling
dhcp and commenting some "allow-hotplug"/"auto" lines in the interfaces
file didn't help, and booting with "systemd.log_level=debug
systemd.log_target=kmsg log_buf_len=1M" didn't reveal anything.

Finally I added "set -x" to /etc/init.d/networking and found it's the
"udevadm settle" command hanging the boot.  Its default timeout is 2
minutes.  The log is included below.  Commenting out the line makes the
system boot quickly.

I don't know what its purpose is or how to figure out why it's hanging.
Until it's fixed, I'd suggest logging a message before running the
command and logging "Configuring network interfaces..." only after it
completes.  Maybe a shorter --timeout option would be a good idea too.

- Michael


-- Logs begin at Mon 2015-11-02 08:56:55 EST, end at Mon 2015-11-02 09:29:15 
EST. --
...
Nov 02 08:57:03 golbez systemd[1]: Mounted /home.
Nov 02 08:57:03 golbez systemd[1]: Reached target Local File Systems.
Nov 02 08:57:03 golbez systemd[1]: Starting LSB: Raise network interfaces
Nov 02 08:57:03 golbez systemd[1]: Starting Tell Plymouth To Write Out Runtime 
Data...
Nov 02 08:57:03 golbez systemd[1]: Starting LSB: live-tools - System Support 
Scripts...
Nov 02 08:57:03 golbez networking[806]: + [ -x /sbin/ifup ]
Nov 02 08:57:03 golbez networking[806]: + [ -x /sbin/ifdown ]
Nov 02 08:57:03 golbez networking[806]: + . /lib/lsb/init-functions
Nov 02 08:57:03 golbez systemd[1]: Starting Create Volatile Files and 
Directories...
Nov 02 08:57:03 golbez systemd[1]: Reached target Remote File Systems.
Nov 02 08:57:03 golbez systemd[1]: Starting LSB: Prepare console...
Nov 02 08:57:03 golbez networking[806]: + run-parts --lsbsysinit --list 
/lib/lsb/init-functions.d
Nov 02 08:57:03 golbez networking[806]: + [ -r 
/lib/lsb/init-functions.d/20-left-info-blocks ]
Nov 02 08:57:03 golbez networking[806]: + . 
/lib/lsb/init-functions.d/20-left-info-blocks
Nov 02 08:57:03 golbez networking[806]: + [ -r 
/lib/lsb/init-functions.d/40-systemd ]
Nov 02 08:57:03 golbez networking[806]: + . /lib/lsb/init-functions.d/40-systemd
Nov 02 08:57:03 golbez networking[806]: + _use_systemctl=0
Nov 02 08:57:03 golbez networking[806]: + [ -d /run/systemd/system ]
Nov 02 08:57:03 golbez networking[806]: + [ -n  ]
Nov 02 08:57:03 golbez networking[806]: + [ 1 -ne 1 ]
Nov 02 08:57:03 golbez networking[806]: + export _SYSTEMCTL_SKIP_REDIRECT=true
Nov 02 08:57:03 golbez networking[806]: + [ 0 = 1 ]
Nov 02 08:57:03 golbez networking[806]: + [ -r 
/lib/lsb/init-functions.d/99-plymouth ]
Nov 02 08:57:03 golbez networking[806]: + . 
/lib/lsb/init-functions.d/99-plymouth
Nov 02 08:57:03 golbez networking[806]: + plymouth --ping
Nov 02 08:57:03 golbez systemd[1]: Started LSB: live-tools - System Support 
Scripts.
Nov 02 08:57:03 golbez networking[806]: + FANCYTTY=
Nov 02 08:57:03 golbez networking[806]: + [ -e /etc/lsb-base-logging.sh ]
Nov 02 08:57:03 golbez networking[806]: + true
Nov 02 08:57:03 golbez networking[806]: + CONFIGURE_INTERFACES=yes
Nov 02 08:57:03 golbez networking[806]: + EXCLUDE_INTERFACES=
Nov 02 08:57:03 golbez networking[806]: + VERBOSE=no
Nov 02 08:57:03 golbez networking[806]: + [ -f /etc/default/networking ]
Nov 02 08:57:03 golbez networking[806]: + . /etc/default/networking
Nov 02 08:57:03 golbez systemd[1]: Started Tell Plymouth To Write Out Runtime 
Data.
Nov 02 08:57:03 golbez networking[806]: + verbose=
Nov 02 08:57:03 golbez networking[806]: + [ no = yes ]
Nov 02 08:57:03 golbez networking[806]: + init_is_upstart
Nov 02 08:57:03 golbez networking[806]: + [ -x /sbin/initctl ]
Nov 02 08:57:03 golbez networking[806]: + return 1
Nov 02 08:57:03 golbez networking[806]: + process_options
Nov 02 08:57:03 golbez networking[806]: + [ -e /etc/network/options ]
Nov 02 08:57:03 golbez networking[806]: + return 0
Nov 02 08:57:03 golbez networking[806]: + check_ifstate
Nov 02 08:57:03 golbez networking[806]: + [ ! -d /run/network ]
Nov 02 08:57:03 golbez networking[806]: + [ ! -r /run/network/ifstate ]
Nov 02 08:57:03 golbez networking[806]: + :
Nov 02 08:57:03 golbez networking[806]: + [ yes = no ]
Nov 02 08:57:03 golbez networking[806]: + set -f
Nov 02 08:57:03 golbez networking[806]: + process_exclusions
Nov 02 08:57:03 golbez networking[806]: + set --
Nov 02 08:57:03 golbez networking[806]: + exclusions=
Nov 02 08:57:03 golbez networking[806]: + echo
Nov 02 08:57:03 golbez networking[806]: + exclusions=
Nov 02 08:57:03 golbez networking[806]: + log_action_begin_msg Configuring 
network interfaces
Nov 02 08:57:03 golbez networking[806]: + log_action_begin_msg_pre Configuring 
network interfaces
Nov 02 08:57:03 golbez networking[806]: + log_daemon_msg_pre Configuring 
network interfaces
Nov 02 08:57:03 golbez networking[806]: + log_use_fancy_output
Nov 02 08:57:03 golbez networking[806]: + TPUT=/usr/bin/tput
Nov 02 08:57:03 golbez 

Bug#803577: musl: x86_64 and mips packages not co-installable

[Michael Gold]

Package: musl
Version: 1.1.9-1

I have musl installed for x86_64 and tried to install musl:mips to
cross-compile software.  The installation failed as shown below.

-- Michael


root@terra:~# apt-get install musl:mips
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following NEW packages will be installed:
  musl:mips
0 upgraded, 1 newly installed, 0 to remove and 17 not upgraded.
Need to get 0 B/311 kB of archives.
After this operation, 737 kB of additional disk space will be used.
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
(Reading database ... 259701 files and directories currently installed.)
Preparing to unpack .../archives/musl_1.1.9-1_mips.deb ...
Unpacking musl:mips (1.1.9-1) ...
dpkg: error processing archive /var/cache/apt/archives/musl_1.1.9-1_mips.deb 
(--unpack):
 trying to overwrite shared '/usr/bin/musl-ldd', which is different from other 
instances of package musl:mips
Processing triggers for man-db (2.7.4-1) ...
Errors were encountered while processing:
 /var/cache/apt/archives/musl_1.1.9-1_mips.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
root@terra:~# 


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64, mips

Kernel: Linux 4.2.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

-- debconf-show failed


signature.asc
Description: PGP signature

Bug#797337: [Pkg-anonymity-tools] Bug#797337: torbrowser-launcher: gives misleading error on SOCKS connection failure

[Michael Gold]

Control: tag -1 + patch

On Sun, Aug 30, 2015 at 13:18:44 +0200, intrigeri wrote:
> Michael Gold wrote (29 Aug 2015 16:35:00 GMT) :
> > An strace reveals it was trying to connect to 127.0.0.1:9050, not to the
> > internet; code inspection reveals this to be a hard-coded SOCKS address.
> > The preceding "Downloading https://www.torproject.org…; message makes it
> > look like it was www.torproject.org that rejected the connection.
> 
> I agree this is a UX problem, thanks for reporting it to Debian.
> Do you want to report it upstream[0]? (I don't remember if the
> upstream author tracks the Debian BTS.)

Here's a patch.  I don't have an account there so I'm CCing Micah.

I didn't handle the case where the remote end rejects the connection.
I'm not sure what exactly it should say, but "Are you connected to the
internet?" isn't relevant in that case.

-- Michael
diff --git a/torbrowser_launcher/launcher.py b/torbrowser_launcher/launcher.py
index e88a9f0ca87d..c830750e98fa 100644
--- a/torbrowser_launcher/launcher.py
+++ b/torbrowser_launcher/launcher.py
@@ -32,7 +32,7 @@ from twisted.web.client import Agent, RedirectAgent, ResponseDone, ResponseFaile
 from twisted.web.http_headers import Headers
 from twisted.internet.protocol import Protocol
 from twisted.internet.ssl import ClientContextFactory
-from twisted.internet.error import DNSLookupError
+from twisted.internet.error import DNSLookupError, ConnectionRefusedError
 
 import OpenSSL
 
@@ -426,6 +426,13 @@ class Launcher:
 else:
 self.set_gui('error', _('The SSL certificate served by https://www.torproject.org is invalid! You may be under attack.'), [], False)
 
+elif isinstance(f.value, ConnectionRefusedError) and self.common.settings['update_over_tor']:
+# If we're using Tor, we'll only get this error when we fail to
+# connect to the SOCKS server.  If the connection fails at the
+# remote end, we'll get txsocksx.errors.ConnectionRefused.
+addr = self.common.settings['tor_socks_address']
+self.set_gui('error', _("Error connecting to Tor at {0}").format(addr), [], False)
+
 else:
 self.set_gui('error', _("Error starting download:\n\n{0}\n\nAre you connected to the internet?").format(f.value), [], False)
 


signature.asc
Description: PGP signature

Bug#797339: [Pkg-anonymity-tools] Bug#797339: torbrowser-launcher: assumes a hard-coded (and insecure) SOCKS port

[Michael Gold]

Control: tag -1 + patch

Hi intrigeri, Micah,

On Sun, Aug 30, 2015 at 13:30:49 +0200, intrigeri wrote:
> Michael Gold wrote (29 Aug 2015 16:55:28 GMT) :
> > It is inappropriate to assume Tor is running on this port, as any local
> > user could be running a service there (Debian bug #797335), possibly to
> > interfere with torbrowser-launcher.
> 
> Note that torbrowser-launcher Depends: tor, so this is correct if, and
> only if, the system administrator has disabled the tor service, or
> configured it to not listen on the default SOCKS port.

This would also be true if another user had caused Tor to crash or shut
down.  Tor is full of assertions (enabled in release builds) that could
cause it to intentionally shut down, leaving its SOCKS port available to
others.

> > torbrowser-launcher should allow the user to select an alternate TCP or
> > Unix-domain SOCKS address, and shouldn't connect to an unprivileged one
> > without confirmation.
> 
> Given 1. the design goals of torbrowser-launcher (that is: working
> out-of-the-box for non-technical users, AIUI); 2. the current state of
> things as described above; and 3. the fact that in practice this is
> a problem only if the system administrator tweaked torrc in a way that
> ignores #2, I beg to disagree that this would be a good solution to
> the (real) problem we have here.

Here's a patch to add it to the --settings screen.  I'm not sure whether
it's meant to be accessible to non-technical users (the mirror selection
box suggests it's assuming some technical ability).  Maybe it could be
moved to a command line option if the GUI is inappropriate.

> Now, *if* the quick fix I'm suggesting above works (checking who
> opened the SOCKs port before connecting to it), then it could be an
> acceptable temporary fix for users who get torbrowser-launcher from
> their distro.

I'm not aware of any good way to do this.  getpeereid only works on Unix
sockets (according to the man page; plus, if the socket were in a system
directory it would be unnecessary).  IDENT (rfc1413) is the standard way
way to check for a TCP connection, but it's rarely available.

Parsing /proc/self/net/tcp would work on Linux but it's non-portable and
ugly.  It would need to be done after connecting to avoid a race.

-- Michael
diff --git a/torbrowser_launcher/common.py b/torbrowser_launcher/common.py
index e5844b974eb1..9c80def37b81 100644
--- a/torbrowser_launcher/common.py
+++ b/torbrowser_launcher/common.py
@@ -194,6 +194,7 @@ class Common:
 'installed_version': False,
 'latest_version': '0',
 'update_over_tor': True,
+'tor_socks_address': 'tcp:127.0.0.1:9050',
 'check_for_updates': False,
 'modem_sound': False,
 'last_update_check_timestamp': 0,
diff --git a/torbrowser_launcher/launcher.py b/torbrowser_launcher/launcher.py
index 698949d929ac..e88a9f0ca87d 100644
--- a/torbrowser_launcher/launcher.py
+++ b/torbrowser_launcher/launcher.py
@@ -444,10 +444,10 @@ class Launcher:
 self.refresh_gtk()
 
 if self.common.settings['update_over_tor']:
-from twisted.internet.endpoints import TCP4ClientEndpoint
+from twisted.internet.endpoints import clientFromString
 from txsocksx.http import SOCKS5Agent
 
-torEndpoint = TCP4ClientEndpoint(reactor, '127.0.0.1', 9050)
+torEndpoint = clientFromString(reactor, self.common.settings['tor_socks_address'])
 
 # default mirror gets certificate pinning, only for requests that use the mirror
 if self.common.settings['mirror'] == self.common.default_mirror and '{0}' in url:
diff --git a/torbrowser_launcher/settings.py b/torbrowser_launcher/settings.py
index 5bd505ea8041..3aacc33962c1 100644
--- a/torbrowser_launcher/settings.py
+++ b/torbrowser_launcher/settings.py
@@ -85,6 +85,21 @@ class Settings:
 
 self.tor_update_checkbox.show()
 
+# Tor SOCKS address
+self.tor_addr_box = gtk.HBox(False, 10)
+self.settings_box.pack_start(self.tor_addr_box, True, True, 0)
+self.tor_addr_box.show()
+
+self.tor_addr_label = gtk.Label(_('Tor server'))
+self.tor_addr_label.set_line_wrap(True)
+self.tor_addr_box.pack_start(self.tor_addr_label, True, True, 0)
+self.tor_addr_label.show()
+
+self.tor_addr = gtk.Entry()
+self.tor_addr.set_text(self.common.settings['tor_socks_address'])
+self.tor_addr_box.pack_start(self.tor_addr, True, True, 0)
+self.tor_addr.show()
+
 # check for updates
 self.update_checkbox = gtk.CheckButton(_("Check for updates next launch"))
 self.settings_box.pack_start(self.update_checkbox, True, True, 0)
@@ -213,6 +228,7 @@ class Settings:
 self.common.settings['update_over_tor'] = self.tor_update_checkbox.get_active()
 self.common.s

Bug#797341: tor: refuses to create AF_LOCAL SOCKS sockets accessible by other users

[Michael Gold]

On Mon, Oct 19, 2015 at 19:27:59 +0200, Peter Palfrader wrote:
> I tend to agree.  Do you want to file a ticket upstream at
> https://trac.torproject.org/?  If not, I can forward it.

forwarded 797341 https://trac.torproject.org/projects/tor/ticket/17388
thanks

I wasn't able to create an account due to a series of intractable
CAPTCHAs, so I used the cypherpunks account.

-- Michael


signature.asc
Description: PGP signature

Bug#800608: mapiprofile: has no secure way to accept password

[Michael Gold]

Package: openchangeclient
Version: 1:2.2-7
Severity: wishlist

mapiprofile and openchangeclient want the password to be passed on the
command line, which in most systems is visible to other users (e.g. in
"ps aux" output).  It's secure on Linux if /proc is mounted with the
hidepid option, but that's not the default and can break other software.

The programs should have a way to read the password from an environment
variable or a file (possibly a /dev/fd path referring to an unlinked
tmpfs file).

- Michael


-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages openchangeclient depends on:
ii  libc6  2.19-22
ii  libical1a  1.0.1-0.1
ii  libldb12:1.1.20-2
ii  libmagic1  1:5.25-2
ii  libmapi0   1:2.2-7
ii  libmapiadmin0  1:2.2-7
ii  libocpf0   1:2.2-7
ii  libpopt0   1.16-10
ii  libsubunit00.0.18-4
ii  libtalloc2 2.1.3-1
ii  libtevent0 0.9.25-2
ii  samba-libs 2:4.1.17+dfsg-4

openchangeclient recommends no packages.

Versions of packages openchangeclient suggests:
ii  perl  5.20.2-6

-- no debconf information


signature.asc
Description: PGP signature
-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.

Bug#799476: libc6: strftime should allow extended-format timezone (ISO 8601)

[Michael Gold]

Package: libc6
Severity: wishlist

For a date in ISO 8601 extended format with "Difference between local
time and UTC of day" (§4.2.5.1), the timezone can be written only as
±hh:mm or ±hh.

§4.3.3d says (http://dotat.at/tmp/ISO_8601-2004_E.pdf#):
"the expression shall either be completely in basic format, in which
case the minimum number of separators necessary for the required
expression is used, or completely in extended format, in which case
additional separators shall be used in accordance with 4.1 and 4.2."

strftime should be able to output the timezone with a colon so a
compliant date could be produced without post-processing, and so a
locale could default to an ISO 8601 date and time format (other than
basic format).  Perhaps a new flag could be used, e.g. "%:z".

A way to output ±hh if mm==00, or ±hh:mm otherwise, may be useful too.
Maybe "%3z" or "%:3z" ("unspecified" per SUSv4: "a minimum field width
is specified for any conversion specifier other than C, F, G, or Y").

- Michael


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64

Kernel: Linux 4.1.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)


signature.asc
Description: Digital signature

Bug#799479: date --iso-8601=m does not use ISO 8601 format as documented

[Michael Gold]

Package: coreutils
Version: 8.23-4
Severity: minor

The manual page for 'date' says --iso-8601 will "output date/time in ISO
8601 format", but I don't believe the format actually complies with that
standard when a time is included.

§4.3.3d says (http://dotat.at/tmp/ISO_8601-2004_E.pdf#):
"the expression shall either be completely in basic format, in which
case the minimum number of separators necessary for the required
expression is used, or completely in extended format, in which case
additional separators shall be used in accordance with 4.1 and 4.2."

But --iso-8601=m uses extended format for the date and time, and basic
format for the timezone.  Since making the option actually use ISO 8601
format could break scripts, a note in the manual page is probably the
best fix.  E.g.,
  "output date/time in ISO 8601 extended format, except for the time
  zone which will be output in basic format when a time is included and
  omitted otherwise"

- Michael


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64

Kernel: Linux 4.1.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages coreutils depends on:
ii  libacl1  2.2.52-2
ii  libattr1 1:2.4.47-2
ii  libc62.19-20
ii  libselinux1  2.3-2+b1

coreutils recommends no packages.

coreutils suggests no packages.

-- debconf-show failed


signature.asc
Description: Digital signature

Bug#799476: libc6: strftime should allow extended-format timezone (ISO 8601)

[Michael Gold]

On Sat, Sep 19, 2015 at 12:20:39 -0400, Michael Gold wrote:
> strftime should be able to output the timezone with a colon
> [...] Perhaps a new flag could be used, e.g. "%:z".
> 
> A way to output ±hh if mm==00, or ±hh:mm otherwise, may be useful too.
> Maybe "%3z" or "%:3z"

Actually, I see the GNU date utility already defines formats for these:
%z +hhmm numeric time zone (e.g., -0400)
%:z+hh:mm numeric time zone (e.g., -04:00)
%::z   +hh:mm:ss numeric time zone (e.g., -04:00:00)
%:::z  numeric time zone with : to necessary precision
   (e.g., -04, +05:30)

It reimplements strftime to do so.

-- Michael


signature.asc
Description: Digital signature

Bug#796931: gnupg-agent: no longer writes $GNUPGHOME/gpg-agent-info-$(hostname) file

[Michael Gold]

On Mon, Aug 31, 2015 at 00:22:06 +0200, Thorsten Glaser wrote:
 On Sat, 29 Aug 2015, Michael Gold wrote:
 
  This seems to work for gpg1 and gpg2:
  : ${GPG_AGENT_INFO=${GNUPGHOME-$HOME/.gnupg}/S.gpg-agent:0:1}
  export GPG_AGENT_INFO
 
 I assume this needs to be written after the eval?

I was assuming that, but I don't think it matters.  2.1 won't give you
anything to eval, and 2.0 will overwrite any earlier setting.

  Trying to support gpg2.0 and 2.1 in one startup script is still annoying
 
 This is a requirement, though.

I've attached the script I'm using as an example.  I didn't test this
version with gpg 2.0 but I expect it will still work.  ('gpg2 --version'
is the obvious way to set $gpg21; I was just avoiding the subshell.)

-- Michael


70gnupg-agent.sh
Description: Bourne shell script


signature.asc
Description: Digital signature

Bug#796931: gnupg-agent: no longer writes $GNUPGHOME/gpg-agent-info-$(hostname) file

[Michael Gold]

 On Tue, 25 Aug 2015, Thorsten Glaser wrote:
 
  particular sharing now becomes impossible).
 
 It’s actually worse: when using startx or no X environment
 at all, I can no longer use gpg-agent:
 
 tglase@tglase-nb:~ $ eval $(gpg-agent --daemon --sh)
 tglase@tglase-nb:~ $ gpg --clearsign x
...
 gpg: gpg-agent is not available in this session

This seems to work for gpg1 and gpg2:
: ${GPG_AGENT_INFO=${GNUPGHOME-$HOME/.gnupg}/S.gpg-agent:0:1}
export GPG_AGENT_INFO

(It also makes mutt happy--if there's no GPG_AGENT_INFO, it will prompt
for a passphrase itself; GPG_AGENT_INFO='' is OK for mutt, too.)

Since there's a known location, you should be able to share across
sessions.

Trying to support gpg2.0 and 2.1 in one startup script is still annoying
for various reasons; e.g., 2.0 needs --use-standard-socket to get this
behaviour, but 2.1 will complain loudly about it.  And 2.1's automatic
agent spawning makes it look like things are working as expected, until
problems like this appear.

-- Michael


signature.asc
Description: Digital signature

Bug#797334: gpg-connect-agent exits with status 0 when no agent running

[Michael Gold]

Package: gnupg-agent
Version: 2.1.7-2

$ gpg-connect-agent --no-autostart -- NOP /bye
gpg-connect-agent: no gpg-agent running in this session
$ echo $?
0
$ 

The exit status should indicate an error if the connection fails, as it
did before GnuPG 2.1.  (My shell startup script runs gpg-agent for its
ssh support, when not already running, and this change breaks it.)

A workaround is to avoid --no-autostart, and pass a bad --agent-program:
$ gpg-connect-agent --agent-program /dev/null -- NOP /bye
gpg-connect-agent: no running gpg-agent - starting '/dev/null'
gpg-connect-agent: failed to start agent '/dev/null': Permission denied
gpg-connect-agent: can't connect to the agent: Permission denied
gpg-connect-agent: error sending standard options: No agent running
$ echo $?
1
$ 

- Michael


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64

Kernel: Linux 4.1.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages gnupg-agent depends on:
ii  libassuan0  2.2.1-1
ii  libc6   2.19-19
ii  libgcrypt20 1.6.3-2
ii  libgpg-error0   1.19-2
ii  libnpth01.2-1
ii  libreadline66.3-8+b3
ii  pinentry-curses [pinentry]  0.9.5-4
ii  pinentry-qt4 [pinentry] 0.9.5-4

Versions of packages gnupg-agent recommends:
ii  gnupg   1.4.19-5
ii  gnupg2  2.1.7-2

gnupg-agent suggests no packages.

-- no debconf information


signature.asc
Description: Digital signature

Bug#797335: tor: should open a Unix-domain SOCKSPort by default

[Michael Gold]

Package: tor
Version: 0.2.6.10-1
Severity: wishlist

There are various Debian programs that assume tor is running on port
9050, and send data to it.  This is inappropriate because the port can
be bound by any unprivileged user if tor is not running (or they can
crash it).  I'll file bugs separately for any programs I see doing this.

SOCKSPort supports Unix-domain sockets now.  The default torrc should
open one, to give programs a safe default.  E.g.,
  SOCKSPort unix:/var/run/tor-socks
Opening an extra TCP port below 1024 could be useful for programs with
no AF_LOCAL support.  I've been using 905.

- Michael


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64

Kernel: Linux 4.1.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages tor depends on:
ii  adduser  3.113+nmu3
ii  init-system-helpers  1.23
ii  libc62.19-19
ii  libevent-2.0-5   2.0.21-stable-2
ii  libseccomp2  2.2.3-1
ii  libssl1.0.0  1.0.2d-1
ii  libsystemd0  224-2
ii  lsb-base 4.1+Debian14
ii  zlib1g   1:1.2.8.dfsg-2+b1

Versions of packages tor recommends:
ii  logrotate3.8.7-2
ii  tor-geoipdb  0.2.6.10-1
ii  torsocks 2.1.0-1

Versions of packages tor suggests:
pn  apparmor-utils   none
pn  mixmasternone
ii  obfs4proxy   0.0.5-2
ii  obfsproxy0.2.13-1
ii  socat1.7.3.0-1
ii  tor-arm  1.4.5.0-1.1
ii  torbrowser-launcher  0.2.0-2

-- Configuration Files:
/etc/tor/torrc changed:
SocksPort 127.0.0.1:900 SessionGroup=900
SocksPort 127.0.0.1:901 SessionGroup=901
SocksPort 127.0.0.1:902 SessionGroup=902
SocksPort 127.0.0.1:903 SessionGroup=903
SocksPort 127.0.0.1:904 SessionGroup=904
SocksPort 127.0.0.1:905 SessionGroup=905
SocksPort 127.0.0.1:906 SessionGroup=906
SocksPort 127.0.0.1:907 SessionGroup=907
SocksPort 127.0.0.1:908 SessionGroup=908
SocksPort 127.0.0.1:909 SessionGroup=909
SocksPolicy accept 74.116.186.120/29
SocksPolicy accept 172.23.0.0/18
SocksPolicy accept 127.0.0.1/32
SocksPolicy reject *
HiddenServiceDir /var/lib/tor/hidden-ssh/
HiddenServicePort 22 127.0.0.1:22
HiddenServiceAuthorizeClient basic terra-mgold
ORPort 443
ORPort 143   # imap
ORPort 3690 NoAdvertise  # subversion
ORPort 8001 NoAdvertise
ORPort 389 NoAdvertise   # ldap
Address 74.116.186.120
Nickname terra
RelayBandwidthRate 75 KBytes
RelayBandwidthBurst 95 KBytes
ContactInfo 4096R/BA8239D3BD1DE48C
ExitPolicy reject *:* # no exits allowed


-- no debconf information


signature.asc
Description: Digital signature

Bug#797337: torbrowser-launcher: gives misleading error on SOCKS connection failure

[Michael Gold]

Package: torbrowser-launcher
Version: 0.2.0-2

$ torbrowser-launcher
Tor Browser Launcher
By Micah Lee, licensed under MIT
version 0.2.0
https://github.com/micahflee/torbrowser-launcher
Updating over Tor
Checking for update
Downloading 
https://www.torproject.org/projects/torbrowser/RecommendedTBBVersions
Download error: Connection was refused by other side: 111: Connection refused. 
class 'twisted.internet.error.ConnectionRefusedError'

### Tor Browser popup dialog appears:
Error starting download:
Connection was refused by other side: 111: Connection refused.
Are you connected to the internet?


An strace reveals it was trying to connect to 127.0.0.1:9050, not to the
internet; code inspection reveals this to be a hard-coded SOCKS address.
The preceding Downloading https://www.torproject.org…; message makes it
look like it was www.torproject.org that rejected the connection.

Nothing in the torbrowser-launcher man page, any included documentation,
or the console output notes a SOCKS connection is required or gives the
expected address.  Updating over Tor is a hint but is not obvious.

The launcher should at least print the address it failed to connect to.
Ideally, it should be able to differentiate between a failed connection
to the SOCKS proxy and an error returned by that proxy, and replace the
Are you connected to the internet? message in the former case.

-- Michael


signature.asc
Description: Digital signature

Bug#797341: tor: refuses to create AF_LOCAL SOCKS sockets accessible by other users

[Michael Gold]

Package: tor
Version: 0.2.6.10-1

I tried to use this option:
SocksPort unix:/var/run/tor-socks
(And also one in a directory owned by the Tor user with mode 0755.)

But Tor refuses to create the socket:
[warn] Before Tor can create a SOCKS socket in /var/run/tor-socks,
the directory /var/run needs to exist, and to be accessible only
by the user and group account that is running Tor.  (On some Unix
systems, anybody who can list a socket can connect to it, so Tor is
being careful.)

The point of the socket was to allow access by other users.  I don't see
a reason to restrict Unix SOCKS ports this way, since the TCP ports are
already accessible by all.  The Unix port could be more secure, because
Tor could get the uid of the client and enforce isolation between users.
This seems like a leftover ControlSocket restriction.

- Michael


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64

Kernel: Linux 4.1.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages tor depends on:
ii  adduser  3.113+nmu3
ii  init-system-helpers  1.23
ii  libc62.19-19
ii  libevent-2.0-5   2.0.21-stable-2
ii  libseccomp2  2.2.3-1
ii  libssl1.0.0  1.0.2d-1
ii  libsystemd0  224-2
ii  lsb-base 4.1+Debian14
ii  zlib1g   1:1.2.8.dfsg-2+b1

Versions of packages tor recommends:
ii  logrotate3.8.7-2
ii  tor-geoipdb  0.2.6.10-1
ii  torsocks 2.1.0-1

Versions of packages tor suggests:
pn  apparmor-utils   none
pn  mixmasternone
ii  obfs4proxy   0.0.5-2
ii  obfsproxy0.2.13-1
ii  socat1.7.3.0-1
ii  tor-arm  1.4.5.0-1.1
ii  torbrowser-launcher  0.2.0-2

-- Configuration Files:
/etc/tor/torrc changed:
SocksPort 127.0.0.1:900 SessionGroup=900
SocksPort 127.0.0.1:901 SessionGroup=901
SocksPort 127.0.0.1:902 SessionGroup=902
SocksPort 127.0.0.1:903 SessionGroup=903
SocksPort 127.0.0.1:904 SessionGroup=904
SocksPort 127.0.0.1:905 SessionGroup=905
SocksPort 127.0.0.1:906 SessionGroup=906
SocksPort 127.0.0.1:907 SessionGroup=907
SocksPort 127.0.0.1:908 SessionGroup=908
SocksPort 127.0.0.1:909 SessionGroup=909
SocksPolicy accept 74.116.186.120/29
SocksPolicy accept 172.23.0.0/18
SocksPolicy accept 127.0.0.1/32
SocksPolicy reject *
HiddenServiceDir /var/lib/tor/hidden-ssh/
HiddenServicePort 22 127.0.0.1:22
HiddenServiceAuthorizeClient basic terra-mgold
ORPort 443
ORPort 143   # imap
ORPort 3690 NoAdvertise  # subversion
ORPort 8001 NoAdvertise
ORPort 389 NoAdvertise   # ldap
Address 74.116.186.120
Nickname terra
RelayBandwidthRate 75 KBytes
RelayBandwidthBurst 95 KBytes
ContactInfo 4096R/BA8239D3BD1DE48C
ExitPolicy reject *:* # no exits allowed


-- no debconf information


signature.asc
Description: Digital signature

Bug#797339: torbrowser-launcher: assumes a hard-coded (and insecure) SOCKS port

[Michael Gold]

Package: torbrowser-launcher
Version: 0.2.0-2

After installing the torbrowser-launcher package and running the program
without any arguments, I immediately saw a connection refused error.
Code inspection reveals that the launcher assumes there's a SOCKS server
at 127.0.0.1:9050 that connects to the Tor network.

It is inappropriate to assume Tor is running on this port, as any local
user could be running a service there (Debian bug #797335), possibly to
interfere with torbrowser-launcher.  Assuming the https connection is
secure, this would only be a denial of service or an information leak.

torbrowser-launcher should allow the user to select an alternate TCP or
Unix-domain SOCKS address, and shouldn't connect to an unprivileged one
without confirmation.

- Michael


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64

Kernel: Linux 4.1.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages torbrowser-launcher depends on:
ii  gnupg1.4.19-5
ii  python   2.7.9-1
ii  python-gtk2  2.24.0-4
ii  python-lzma  0.5.3-3
ii  python-parsley   1.2-1
ii  python-psutil2.2.1-3
ii  python-twisted   15.2.1-1
ii  python-txsocksx  1.15.0.2-1
ii  tor  0.2.6.10-1
ii  wmctrl   1.07-7

torbrowser-launcher recommends no packages.

Versions of packages torbrowser-launcher suggests:
pn  apparmor   none
pn  python-pygame  none

-- no debconf information


signature.asc
Description: Digital signature

Bug#792639: apt-listbugs: should use https to access bug tracking system

[Michael Gold]

On Thu, Jul 30, 2015 at 22:35:17 +0200, Francesco Poli wrote:
 I have examined your second patch and I have made some
 modifications/simplifications to it.
 The main behavioral difference with respect to your patch is that I
 decided that all the command-line options are to be treated as equally
 important: any option specified later on the command line takes
 precedence over the ones specified earlier (hence --url will override
 --hostname/--port only when it follows them on the command line).
 After all, this is how all other command-line options work: specifying
 one option multiple times already causes the last specified value to
 overwrite the previously specified ones.
 For the record, the resulting revised patch is attached.

I thought of this when developing the patch.  The problem is that you'll
override more than just the host or port unless you're careful.  E.g.,
with -h foo -u https://192.0.2.1:999/bar.cgi -p 443 I think your code
will produce http://foo:443/cgi-bin/soap.cgi;, while I'd expect a URL
of https://192.0.2.1:443/bar.cgi;.  Note also that removing -p will
change the URL completely.

I'm not too concerned though.

 Now, the bad news is that I remembered that the libruby module
 providing SSL support links with libssl. And the OpenSSL license is
 well known to be GPL-incompatible.
 apt-listbugs is GPL-licensed and loads a number of GPL-licensed Ruby
 libraries: as a consequence, there may be license incompatibility
 issues preventing the distribution of a version of apt-listbugs which
 uses SSL.
 This licensing issue needs to be carefully investigated.
 I will try and see what can be done about it.
 Sadly, I will have to put the patch aside, until this situation is
 solved for the best.

This is kind of interesting--it's not clear who would be responsible if
libssl got loaded.  What if you merged the patch with a non-SSL default
for soapurl?  It might be useful for someone to override the cgi-bin/...
part on a local server, and in terms of libssl it would look the same as
before.  If some user chose to add an s, would Debian be responsible?
(If so, all users of this SOAP library would need to be audited.)

Even if Debian added the s, would the shipped software be derived from
libssl, or would the derived work exist purely in RAM without ever being
distributed?  It would surprise me if the the presence or absence of s
in apt-listbugs determines whether it's derived from libssl.  We're not
using the libssl API, and the underlying libraries could swap it out for
something else without us ever noticing.

Anyway, I'll leave these things for you to investigate.  Thanks for the
update.

-- Michael


signature.asc
Description: Digital signature

Bug#792639: apt-listbugs: should use https to access bug tracking system

[Michael Gold]

On Sun, Jul 19, 2015 at 15:58:47 +0200, Francesco Poli wrote:
 Thank you very much, your helpfulness is really appreciated!
 
 I am looking forward to seeing your updated patch.
 Please send it as soon as it's ready.

Here it is.

-- Michael
diff --git a/bin/apt-listbugs b/bin/apt-listbugs
index 4c5628f97c04..cf73e5de3242 100755
--- a/bin/apt-listbugs
+++ b/bin/apt-listbugs
@@ -46,7 +46,7 @@ installation/upgrade is safe.
 
 == USAGE
 
-apt-listbugs [-h] [-v] [-s severities] [-T tags] [-S states] [-B bug#] [-D] [-H hostname] [-p port] [-P priority] [-E title] [-q] [-C apt.conf] [-F] [-y] [-n] [-d] command [arguments]
+apt-listbugs [-h] [-v] [-s severities] [-T tags] [-S states] [-B bug#] [-D] [-u url] [-P priority] [-E title] [-q] [-C apt.conf] [-F] [-y] [-n] [-d] command [arguments]
 
 == OPTIONS
 
@@ -104,14 +104,21 @@ apt-listbugs [-h] [-v] [-s severities] [-T tags] [-S states] [-B bug#] [
 
   Show bugs of downgraded packages. (apt mode only)
 
+* -u url, --url url
+
+  Specifies the SOAP URL for the Debian Bug Tracking System
+  [https://bugs.debian.org:443/cgi-bin/soap.cgi]. The default URL may be
+  changed by setting the AptListbugs::URL configuration option.
+
 * -H hostname, --hostname hostname
 
-  Specifies the hostname of the Debian Bug Tracking System [bugs.debian.org].
+  Specifies the hostname of the Debian Bug Tracking System
+  (deprecated, and disables https; use --url instead).
 
 * -p port, --port port
 
   Specifies the port number of the web interface of the Debian Bug
-  Tracking System [80].
+  Tracking System (deprecated, and disables https; use --url instead).
 
 * -P priority, --pin-priority priority
 
@@ -221,6 +228,10 @@ notable configuration options are
   Useful for setting HTTP proxy for apt-listbugs.
   The special keyword 'DIRECT' will disable proxy.
 
+: AptListbugs::URL
+
+  Default SOAP URL for the Debian Bug Tracking System.
+
 : AptListbugs::Severities
 
   Default (comma-separated) list of bug severities to be shown. When
diff --git a/lib/aptlistbugs/debian/bts.rb b/lib/aptlistbugs/debian/bts.rb
index 5b31d1bffb8f..3a310819cb46 100644
--- a/lib/aptlistbugs/debian/bts.rb
+++ b/lib/aptlistbugs/debian/bts.rb
@@ -31,23 +31,21 @@ module Debian
   module BTS
 class Parser
 
-  def initialize(host, port)
-@host = host
-@port = port
+  def initialize(url)
+@soapurl = url
   end
 
   # use SOAP interface to obtain the index.
   class SoapIndex  Parser
-def initialize(host, port)
-  @host = host
-  @port = port
+def initialize(url)
+  @soapurl = url
   @indexes = {}
   @buf = nil
 end
 
 def parse_bug(bugnum)
   require 'aptlistbugs/debian/btssoap'
-  soap = Debian::BTSSOAP::Soap.new(@host, @port)
+  soap = Debian::BTSSOAP::Soap.new(@soapurl)
   sa = Debian::BTSSOAP::StringArray.new
 
   # query the BTS about the given bug number
@@ -58,7 +56,7 @@ module Debian
 
 def parse(ma_copies, parsestep, severities = [critical, grave])
   require 'aptlistbugs/debian/btssoap'
-  soap = Debian::BTSSOAP::Soap.new(@host, @port)
+  soap = Debian::BTSSOAP::Soap.new(@soapurl)
   sa = Debian::BTSSOAP::StringArray.new
   bugs = Debian::Bugs.new
 
diff --git a/lib/aptlistbugs/debian/btssoap.rb b/lib/aptlistbugs/debian/btssoap.rb
index 759ab7ff01ae..500e2f6d3260 100644
--- a/lib/aptlistbugs/debian/btssoap.rb
+++ b/lib/aptlistbugs/debian/btssoap.rb
@@ -23,8 +23,8 @@ module Debian
   module BTSSOAP
 class StringArray  Array; end
 class Soap
-  def initialize(host = bugs.debian.org, port = 80)
-@server=http://#{host}:#{port}/cgi-bin/soap.cgi;
+  def initialize(soapurl)
+@server=soapurl
 @ns = 'Debbugs/SOAP/'
 @drv = SOAP::RPC::Driver.new(@server, @ns)
 @drv.wiredump_dev = STDOUT if $DEBUG
diff --git a/lib/aptlistbugs/logic.rb b/lib/aptlistbugs/logic.rb
index 1e4289180866..b8923d6f8030 100644
--- a/lib/aptlistbugs/logic.rb
+++ b/lib/aptlistbugs/logic.rb
@@ -42,8 +42,15 @@ class AppConfig
   QUERYBTS = /usr/bin/querybts
   WWW_BROWSER = /usr/bin/www-browser
   SENSIBLE_BROWSER = /usr/bin/sensible-browser
+  DEFAULT_URL = https://bugs.debian.org:443/cgi-bin/soap.cgi;
+  # The default hostname and port are for backwards compatibility,
+  # and won't be used if neither --hostname nor --port is specified.
+  # These options disable https, so --url is preferred.
+  DEFAULT_HOSTNAME = bugs.debian.org
+  DEFAULT_PORT = 80
 
   def usage
+derive_settings
 $stderr.print _(Usage: ), File.basename($0),
   _( [options] command [arguments]),
   \n,
@@ -57,8 +64,7 @@ class AppConfig
   sprintf(_( -S states  : Filter bugs by pending-state categories you want to see\n[%s].\n), @stats.join(',')),
   _( -B bug#: Filter bugs by number, showing only the specified bugs.\n),
   _( -D   : Show 

Bug#792639: apt-listbugs: should use https to access bug tracking system

[Michael Gold]

On Fri, Jul 17, 2015 at 20:20:16 +0200, Francesco Poli wrote:
 On Thu, 16 Jul 2015 20:44:14 -0400 Michael Gold wrote:
 Well, more packages than versions, I would say, but anyway I fully
 acknowledge that some information is leaked.
 In some scenarios, one would prefer to keep these data undisclosed.

And by enabling it by default, those people will not stand out.

 This is good news, I wasn't aware that the Debian BTS SOAP interface
 was already able to be used through HTTPS!
 Actually, I admit that I haven't tried to find documentation about
 this...

I don't recall seeing any email or documentation, but I noticed that the
canonical BTS URLs changed to use https recently (if you use http: it
will redirect).

 I assume that you're contributing this patch (copyrighted by you as an
 individual) under the same terms as apt-listbugs (GNU GPL v2 or later).
 Please confirm this.

Yes.

  • obviously, it would have been simpler to just switch from http to
 https and add a --disable-ssl option for those who need unencrypted
 SOAP connections: please elaborate a bit on the rationale behind such a
 more sophisticated approach (deprecate two options, which still are
 supported and provide the old behavior, add another option that
 supports arbitrary URLs); I guess the main reason is that you really
 value backward compatibility...?

It's not clear to me why the --hostname and --port options exist; and
without knowing that, it's hard for me to know what will break by just
enabling TLS.  If the intention is to allow users to set up their own
servers, I expect they'll have no (valid) TLS there, and they'll have to
adjust their setup to add some --disable option.  And I guess you'd want
to show a notice about the change when upgrading (I find it annoying
when apt assigns me busywork like this).

I recommend removing --hostname and --port from the manual eventually,
to simplify it.  But I don't think they complicate the code too much.

  • why should the user need to explicitly specify /cgi-bin/soap.cgi?
 after all, it has been automatically added by apt-listbugs so far...
 the user could just specify --url https://bugs.debian.org:443; and the
 remainder could be added transparently; are there relevant scenarios
 where that last part of the URL won't be /cgi-bin/soap.cgi? or is it
 just who knows?

If we expect some users to run their own servers, the default path does
seem too generic.

But the real reason is because I considered adding an option to specify
TLS or non-TLS, and noticed it would be a roundabout way to give a URL
(especially if someone later requests a way to override soap.cgi).
It's trickier to put into a config file and makes backward compatibility
harder.  The URL is the standard way to specify everything we need to
know, and it's what the library wants anyway.

Your note does give me an idea: if the URL doesn't contain a slash after
the :// part, we could append /cgi-bin/soap.cgi.  What do you think?

  • I would prefer if the online help showed the current value of
 @soapurl between brackets, rather than its default value: apt-listbugs
 does so for other options; for instance

I didn't notice that.  I'll change it.

 Finally, could you please re-base your patch against the current tip of
 the master branch on the public git repository?

OK.

-- Michael


signature.asc
Description: Digital signature

Bug#792639: apt-listbugs: should use https to access bug tracking system

[Michael Gold]

On Fri, Jul 17, 2015 at 04:17:40 +0200, Christoph Anton Mitterer wrote:
 apt-listbugs uses an unencrypted connection to communicate with the
  BTS,
  leaking information about installed packages and versions.
 
 You shouldn't expect that much more security by just switching to TLS.
 
 Unfortunately Debian nowadays uses certificates issued by an externals
 CA (Gandi) which itself is just an intermediate CA to USERTrust.
 So everyone in that hierarchy could issue a forged certificate used for
 selective MitM attacks.
 And that already assumes that apt-listbugs would only trust the
 USERTrust or Gandi cert.

Right, but switching to https is a necessary step to allow other layers
to implement proper security.  I don't think apt-listbugs itself needs
to do much more.  There's a TLSA record on _443._tcp.bugs.debian.org;
the TLS library should refuse to connect if that can't be validated,
or if no DNSSEC records are seen for a domain that should be signed.
(Presumably it would fall back to CA-based checking if the DNS resolver
has no DNSSEC support, or the domain has chosen not to use it.)

Even if using CAs, https would stop trivial MITM attacks.  Random access
points, ISP ad-servers, etc., are not likely to be using illegitimate
certificates.  It seems even the NSA will think twice:
  Something that comes up again and again in the NSA documents is that
   they are amazingly risk-averse. ... The chance of being noticed by
   surveillance targets, or anyone else, weighs heavily on operational
   decisions.
  [https://www.schneier.com/news/archives/2014/03/glenn_greenwalds_enc.html#]

-- Michael


signature.asc
Description: Digital signature

Bug#792639: apt-listbugs: should use https to access bug tracking system

[Michael Gold]

Package: apt-listbugs
Version: 0.1.16
Severity: wishlist
Tags: patch security

apt-listbugs uses an unencrypted connection to communicate with the BTS,
leaking information about installed packages and versions.  (Note that
apt can talk https--and I see 26 Debian mirrors with valid certificates,
including mirrors.kernel.org.)

This turns out to be trivial to fix--just replace http: with https:.
The ruby libraries and the BTS already support it.  The attached patch
tries to do it properly to avoid breaking any local setups that depend
on an unencrypted SOAP connection:
 * Change the default URL to use https.
 * Add -u / --url / AptListbugs::URL settings to specify a full URL,
   including protocol.
 * Consider -H and -p deprecated; specifying either will trigger the
   old (unencrypted) behaviour.
 * Update documentation.

- Michael


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64

Kernel: Linux 4.0.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages apt-listbugs depends on:
ii  apt   1.0.9.10
ii  ruby  1:2.1.5.1
ii  ruby-debian   0.3.9+b1
ii  ruby-gettext  3.1.2-1
ii  ruby-soap4r   2.0.5-3
ii  ruby-unicode  0.4.4-2+b4
ii  ruby-xmlparser0.7.3-1+b1
ii  ruby1.9.1 [ruby-interpreter]  1.9.3.484-2
ii  ruby2.0 [ruby-interpreter]2.0.0.484+really457-3
ii  ruby2.1 [ruby-interpreter]2.1.5-3

Versions of packages apt-listbugs recommends:
ii  ruby-httpclient  2.3.3-3.1

Versions of packages apt-listbugs suggests:
ii  chromium [www-browser]   43.0.2357.130-1
ii  debianutils  4.5.1
ii  dillo [www-browser]  3.0.5-1
ii  elinks [www-browser] 0.12~pre6-10
ii  iceweasel [www-browser]  38.1.0esr-3
ii  links [www-browser]  2.9-3
ii  lynx-cur [www-browser]   2.8.9dev6-3
ii  reportbug6.6.3
ii  w3m [www-browser]0.5.3-22

-- no debconf information
diff -ur apt-listbugs-0.1.16-orig/apt-listbugs apt-listbugs-0.1.16/apt-listbugs
--- apt-listbugs-0.1.16-orig/apt-listbugs	2014-08-25 13:41:12.0 -0400
+++ apt-listbugs-0.1.16/apt-listbugs	2015-07-16 20:33:43.925422599 -0400
@@ -46,7 +46,7 @@
 
 == USAGE
 
-apt-listbugs [-h] [-v] [-s severities] [-T tags] [-S states] [-B bug#] [-D] [-H hostname] [-p port] [-P priority] [-E title] [-q] [-C apt.conf] [-F] [-y] [-n] [-d] command [arguments]
+apt-listbugs [-h] [-v] [-s severities] [-T tags] [-S states] [-B bug#] [-D] [-u url] [-P priority] [-E title] [-q] [-C apt.conf] [-F] [-y] [-n] [-d] command [arguments]
 
 == OPTIONS
 
@@ -104,14 +104,21 @@
 
   Show bugs of downgraded packages. (apt mode only)
 
+* -u url, --url url
+
+  Specifies the SOAP URL for the Debian Bug Tracking System
+  [https://bugs.debian.org:443/cgi-bin/soap.cgi]. The default URL may be
+  changed by setting the AptListbugs::URL configuration option.
+
 * -H hostname, --hostname hostname
 
-  Specifies the hostname of the Debian Bug Tracking System [bugs.debian.org].
+  Specifies the hostname of the Debian Bug Tracking System
+  (deprecated, and disables https; use --url instead).
 
 * -p port, --port port
 
   Specifies the port number of the web interface of the Debian Bug
-  Tracking System [80].
+  Tracking System (deprecated, and disables https; use --url instead).
 
 * -P priority, --pin-priority priority
 
@@ -214,6 +221,10 @@
   Useful for setting HTTP proxy for apt-listbugs.
   The special keyword 'DIRECT' will disable proxy.
 
+: AptListbugs::URL
+
+  Default SOAP URL for the Debian Bug Tracking System.
+
 : AptListbugs::Severities
 
   Default (comma-separated) list of bug severities to be shown. When
diff -ur apt-listbugs-0.1.16-orig/lib/apt-listbugs/logic.rb apt-listbugs-0.1.16/lib/apt-listbugs/logic.rb
--- apt-listbugs-0.1.16-orig/lib/apt-listbugs/logic.rb	2014-08-25 13:41:12.0 -0400
+++ apt-listbugs-0.1.16/lib/apt-listbugs/logic.rb	2015-07-16 20:40:29.519387373 -0400
@@ -42,6 +42,12 @@
   QUERYBTS = /usr/bin/querybts
   WWW_BROWSER = /usr/bin/www-browser
   SENSIBLE_BROWSER = /usr/bin/sensible-browser
+  DEFAULT_URL = https://bugs.debian.org:443/cgi-bin/soap.cgi;
+  # The default hostname and port are for backwards compatibility,
+  # and won't be used if neither --hostname nor --port is specified.
+  # They don't support https, so --url is preferred.
+  DEFAULT_HOSTNAME = bugs.debian.org
+  DEFAULT_PORT = 80
 
   def usage
 $stderr.print _(Usage: ), File.basename($0),
@@ -56,8 +62,7 @@
   sprintf(_( -S states  : Filter bugs by pending-state categories you want to see\n[%s].\n), @stats.join(',')),
   _( -B bug#: Filter bugs by number, showing only the specified bugs.\n),
   _( -D   : Show downgraded packages, 

Bug#778480: gpg-connect-agent: percent+ function doesn't encode '+'

[Michael Gold]

Package: gnupg-agent
Version: 2.0.26-4

The 'percent+' function URL-encodes its argument and replaces spaces
with plus signs.  But it doesn't encode plus signs in its argument;
e.g.,
  gpg-connect-agent --subst '/echo ${percent+ foo+ bar}' /bye
prints
  foo++bar
which would decode to foo  bar instead of foo+ bar.

Plus signs should be encoded as %2b to make the encoding reversible.
The above command should print foo%2b+bar.

When calling jnlib/stringhelp.c:percent_escape from gpg-connect-agent.c,
'+' could be added to the 'extra' argument to do this.  But I think it
would be preferable for percent_escape to always encode '+', like ':'
and '%' (unpercent_string will decode arbitrary hex values).  Actually,
there's a function percent_plus_escape in common/percent.c that appears
to do it properly.

- Michael


-- System Information:
Debian Release: 8.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages gnupg-agent depends on:
ii  libassuan0  2.1.2-2
ii  libc6   2.19-15
ii  libgcrypt20 1.6.2-4+b1
ii  libgpg-error0   1.17-3
ii  libpth202.0.7-20
ii  libreadline66.3-8+b3
ii  pinentry-curses [pinentry]  0.8.3-2
ii  pinentry-gtk2 [pinentry]0.8.3-2
ii  pinentry-qt4 [pinentry] 0.8.3-2

Versions of packages gnupg-agent recommends:
ii  gnupg   1.4.18-6
ii  gnupg2  2.0.26-4

gnupg-agent suggests no packages.

-- no debconf information


signature.asc
Description: Digital signature

Bug#632868: base-files: derive PATH in /etc/profile from /etc/login.defs

[Michael Gold]

On Wed, Jul 06, 2011 at 19:19:03 +0300, Georgios M. Zarkadas wrote:
 This is a solution to bug #571086 (now closed) which keeps /etc/login.defs as
 the only place to set PATH, by computing the set there value on the fly using
 only grep and coreutils (both essential packages and thus guaranteed to be 
 always present).

There's no need to call external programs for the parsing:
pathkey=ENV_PATH
if [ $(id -u) -eq 0 ]
then
pathkey=ENV_SUPATH
fi

ifs=${IFS+_$IFS}
unset IFS
while read -r key val
do
case $key in
$pathkey)
# the PATH= prefix is optional
PATH=${val#PATH=}
export PATH
;;
UMASK)  # may want to handle this too
umask $val
;;
esac
done  /etc/login.defs
[ -z $ifs ] || IFS=${ifs#?}
unset ifs pathkey key val

The uid check could also be changed, to avoid a subshell and to help
with the case where 'id' isn't found in $PATH:
if [ -f /proc/1/environ ]
then
if [ -r /proc/1/environ ]
then
pathkey=ENV_SUPATH
fi
elif [ $(id -u) -eq 0 ]
then
pathkey=ENV_SUPATH
fi
or (with non-bash still using a subshell):
if [ ${EUID:-$(id -u)} -eq 0 ]

-- Michael


signature.asc
Description: Digital signature

Bug#776160: bash-completion: /etc/profile.d/bash_completion causes warnings with '-o nounset'

[Michael Gold]

Package: bash-completion
Version: 1:2.1-4
Tags: patch

/etc/profile.d/bash_completion accesses some variables like $BASH and
$PS1 that may be unset, which will produce a warning or error if the
(POSIX-standard) 'nounset' option is enabled.  See #776154 for details.
E.g.,
$ set -u
$ . /etc/profile.d/bash_completion.sh
bash: BASH_COMPLETION_COMPAT_DIR: unbound variable

A patch is attached, which prevents errors when not loading completions
(i.e. in non-bash shells; but some of the completion scripts use unbound
variables).  I also quoted bmajor and bminor to guard against weird IFS
values.

- Michael


-- System Information:
Debian Release: 8.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages bash-completion depends on:
ii  bash  4.3-11+b1
ii  dpkg  1.17.22

bash-completion recommends no packages.

bash-completion suggests no packages.

-- no debconf information
--- bash_completion.sh.orig	2015-01-24 13:22:04.380023295 -0500
+++ bash_completion.sh	2015-01-24 13:23:23.758283088 -0500
@@ -1,9 +1,9 @@
 # Check for interactive bash and that we haven't already been sourced.
-if [ -n $BASH_VERSION -a -n $PS1 -a -z $BASH_COMPLETION_COMPAT_DIR ]; then
+if [ -n ${BASH_VERSION-} -a -n ${PS1-} -a -z ${BASH_COMPLETION_COMPAT_DIR-} ]; then
 
 # Check for recent enough version of bash.
 bash=${BASH_VERSION%.*}; bmajor=${bash%.*}; bminor=${bash#*.}
-if [ $bmajor -gt 4 ] || [ $bmajor -eq 4 -a $bminor -ge 1 ]; then
+if [ $bmajor -gt 4 ] || [ $bmajor -eq 4 -a $bminor -ge 1 ]; then
 [ -r ${XDG_CONFIG_HOME:-$HOME/.config}/bash_completion ]  \
 . ${XDG_CONFIG_HOME:-$HOME/.config}/bash_completion
 if shopt -q progcomp  [ -r /usr/share/bash-completion/bash_completion ]; then


signature.asc
Description: Digital signature

Bug#776154: base-files: /etc/profile causes warnings with '-o nounset'

[Michael Gold]

Package: base-files
Version: 8
Tags: patch

/etc/profile accesses some variables like $BASH and $PS1 that may be
unset, which will produce a warning or error if the (POSIX-standard)
'nounset' option is enabled.  To reproduce, run a login shell with '-u'
from a user account with no custom profile/rc/etc., e.g.,
$ dash -u -l
dash: 12: BASH: parameter not set
$ posh -u -l
posh: /etc/profile:25: BASH: parameter not set
$ 
While it's only a warning in these examples, it would be a fatal error
if a non-interactive shell loaded /etc/profile (A non-interactive shell
shall immediately exit).  Note that POSIX requires shells to accept -u
as a command-line argument, but not -l.

In practice the ${parameter+word} or ${parameter-word} syntaxes can be
used to avoid this problem (POSIX is silent about this, but I think it's
an oversight--it avoids a warning in every tested shell).  A trivial
patch to /etc/profile is attached.

- Michael


-- System Information:
Debian Release: 8.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages base-files depends on:
ii  gawk [awk]  1:4.1.1+dfsg-1
ii  mawk [awk]  1.3.3-17

base-files recommends no packages.

base-files suggests no packages.

-- Configuration Files:
/etc/profile 91901ce5707909cfec8b3a1a6efbfa61 [Errno 2] No such file or 
directory: u'/etc/profile 91901ce5707909cfec8b3a1a6efbfa61'

-- no debconf information
--- /etc/profile	2014-10-22 10:02:30.0 -0400
+++ profile	2015-01-24 11:51:39.272067172 -0500
@@ -8,8 +8,8 @@
 fi
 export PATH
 
-if [ $PS1 ]; then
-  if [ $BASH ]  [ $BASH != /bin/sh ]; then
+if [ ${PS1-} ]; then
+  if [ ${BASH-} ]  [ $BASH != /bin/sh ]; then
 # The file bash.bashrc already sets the default PS1.
 # PS1='\h:\w\$ '
 if [ -f /etc/bash.bashrc ]; then


signature.asc
Description: Digital signature

Bug#751585: systemd: opens emergency shell after prompting for unnecessary dm-crypt passwords

[Michael Gold]

Package: systemd
Version: 204-10
Severity: critical

After installing systemd today and rebooting, I saw a few lines (not
errors) about systemd-fsck on xfs filesystems, and then I was prompted
for dm-crypt passwords for 4 disks that are not necessary to boot the
system.  I pressed enter to bypass each prompt, and then saw I message
that I'd be dropped to an emergency shell.  It took about a minute to
open this shell each time (the shell died a few times while I was
working).

The disks it had prompted about were marked 'noauto' in /etc/crypttab,
and all had keyfiles available on the root filesystem (which is
encrypted but had been successfully mounted at the time); so no prompts
should have been shown.

I've marked this as critical because I was unable to use the system
until switching back to sysvinit.  Unfortunately, no logs of the event
seem to be available now, so it's not clear why systemd considered there
to be an emergency.

- Michael


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

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

Versions of packages systemd depends on:
ii  acl  2.2.52-1
ii  adduser  3.113+nmu3
ii  initscripts  2.88dsf-53
ii  libacl1  2.2.52-1
ii  libaudit11:2.3.6-1
ii  libc62.19-1
ii  libcap2  1:2.22-1.2
ii  libcap2-bin  1:2.22-1.2
ii  libcryptsetup4   2:1.6.4-4
ii  libdbus-1-3  1.8.2-1
ii  libgcrypt11  1.5.3-4
ii  libkmod2 17-2
ii  liblzma5 5.1.1alpha+20120614-2
ii  libpam0g 1.1.8-3
ii  libselinux1  2.3-1
ii  libsystemd-daemon0   204-10
ii  libsystemd-journal0  204-10
ii  libsystemd-login0204-10
ii  libudev1 204-10
ii  libwrap0 7.6.q-25
ii  sysv-rc  2.88dsf-53
ii  udev 204-10
ii  util-linux   2.20.1-5.8

Versions of packages systemd recommends:
pn  libpam-systemd  none

Versions of packages systemd suggests:
pn  systemd-ui  none


signature.asc
Description: Digital signature

Bug#751589: sysvinit-core: /sbin/init missing after switching from systemd to sysvinit

[Michael Gold]

Package: sysvinit-core
Version: 2.88dsf-53.2
Severity: critical

After a failed switch to systemd today (Debian bug #751585), I tried to
switch back to sysvinit but found /sbin/init missing after a reboot,
which of course prevented the system from booting.

/sbin was available in the emergency shell and contained some files, but
'init' wasn't there.  'dpkg -L sysvinit-core' ended at the line '/sbin'
(i.e., it was missing /sbin/shutdown, /sbin/init, etc.).  I eventually
figured out to run 'dpkg -i' on that .deb; this restored /sbin/init, and
then I was able to boot the system normally.

I've attached dpkg and apt logfiles, starting with the systemd
installation.

Note that systemd printed systemd is the active init system, please
switch to another before removing systemd when I tried to remove it;
but it gave no guidance on how to do this.  Did this mean to install
sysvinit and reboot (which is what I did)?  Was I supposed to do
something with update-alternatives or similar, or was I actually
supposed to be running sysvinit somehow before rebooting?  It's possible
this is actually a bug in dpkg, apt, or systemd.

- Michael


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

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

Versions of packages sysvinit-core depends on:
ii  debconf [debconf-2.0]  1.5.53
ii  debianutils4.4
ii  initscripts2.88dsf-53
ii  libc6  2.19-1
ii  libselinux12.3-1
ii  libsepol1  2.3-1
ii  sysv-rc2.88dsf-53
ii  sysvinit-utils 2.88dsf-53

sysvinit-core recommends no packages.

sysvinit-core suggests no packages.

-- debconf information:
  sysvinit/hurd-fix-inittab:
2014-06-14 08:58:14 startup archives unpack
2014-06-14 08:58:15 install systemd:amd64 none 204-10
2014-06-14 08:58:15 status half-installed systemd:amd64 204-10
2014-06-14 08:58:15 status triggers-pending dbus:amd64 1.8.2-1
2014-06-14 08:58:15 status half-installed systemd:amd64 204-10
2014-06-14 08:58:15 status triggers-pending man-db:amd64 2.6.7.1-1
2014-06-14 08:58:16 status triggers-pending dbus:amd64 1.8.2-1
2014-06-14 08:58:16 status unpacked systemd:amd64 204-10
2014-06-14 08:58:16 status unpacked systemd:amd64 204-10
2014-06-14 08:58:16 trigproc dbus:amd64 1.8.2-1 1.8.2-1
2014-06-14 08:58:16 status half-configured dbus:amd64 1.8.2-1
2014-06-14 08:58:17 status installed dbus:amd64 1.8.2-1
2014-06-14 08:58:17 trigproc man-db:amd64 2.6.7.1-1 2.6.7.1-1
2014-06-14 08:58:17 status half-configured man-db:amd64 2.6.7.1-1
2014-06-14 08:58:20 status installed man-db:amd64 2.6.7.1-1
2014-06-14 08:58:21 startup packages configure
2014-06-14 08:58:21 configure systemd:amd64 204-10 none
2014-06-14 08:58:21 status unpacked systemd:amd64 204-10
2014-06-14 08:58:21 status unpacked systemd:amd64 204-10
2014-06-14 08:58:21 status unpacked systemd:amd64 204-10
2014-06-14 08:58:21 status unpacked systemd:amd64 204-10
2014-06-14 08:58:21 status unpacked systemd:amd64 204-10
2014-06-14 08:58:21 status unpacked systemd:amd64 204-10
2014-06-14 08:58:21 status triggers-pending dbus:amd64 1.8.2-1
2014-06-14 08:58:21 status unpacked systemd:amd64 204-10
2014-06-14 08:58:21 status unpacked systemd:amd64 204-10
2014-06-14 08:58:21 status unpacked systemd:amd64 204-10
2014-06-14 08:58:21 status unpacked systemd:amd64 204-10
2014-06-14 08:58:21 status unpacked systemd:amd64 204-10
2014-06-14 08:58:21 status unpacked systemd:amd64 204-10
2014-06-14 08:58:22 status half-configured systemd:amd64 204-10
2014-06-14 08:58:22 status triggers-awaited systemd:amd64 204-10
2014-06-14 08:58:22 trigproc dbus:amd64 1.8.2-1 none
2014-06-14 08:58:22 status half-configured dbus:amd64 1.8.2-1
2014-06-14 08:58:22 status installed systemd:amd64 204-10
2014-06-14 08:58:22 status installed dbus:amd64 1.8.2-1
2014-06-14 08:58:22 startup packages remove
2014-06-14 08:58:22 status installed sysvinit-core:amd64 2.88dsf-53
2014-06-14 08:58:22 status installed sysvinit-core:amd64 2.88dsf-53
2014-06-14 08:58:23 status installed sysvinit-core:amd64 2.88dsf-53
2014-06-14 08:58:23 status installed sysvinit-core:amd64 2.88dsf-53
2014-06-14 08:58:23 status installed sysvinit-core:amd64 2.88dsf-53
2014-06-14 08:58:23 status installed sysvinit-core:amd64 2.88dsf-53
2014-06-14 08:58:23 status installed sysvinit-core:amd64 2.88dsf-53
2014-06-14 08:58:23 status installed sysvinit-core:amd64 2.88dsf-53
2014-06-14 08:58:23 status installed sysvinit-core:amd64 2.88dsf-53
2014-06-14 08:58:23 status installed sysvinit-core:amd64 2.88dsf-53
2014-06-14 08:58:23 status installed sysvinit-core:amd64 2.88dsf-53
2014-06-14 08:58:23 status installed sysvinit-core:amd64 2.88dsf-53
2014-06-14 08:58:23 status installed sysvinit-core:amd64 2.88dsf-53
2014-06-14 08:58:23 status installed sysvinit-core:amd64 2.88dsf-53
2014-06-14 08:58:23 

Bug#751585: systemd: opens emergency shell after prompting for unnecessary dm-crypt passwords

[Michael Gold]

On Sat, Jun 14, 2014 at 16:27:36 +0200, Michael Biebl wrote:
 Am 14.06.2014 16:04, schrieb Michael Gold:
  Package: systemd
  Version: 204-10
  Severity: critical
  
  After installing systemd today and rebooting, I saw a few lines (not
  errors) about systemd-fsck on xfs filesystems, and then I was prompted
  for dm-crypt passwords for 4 disks that are not necessary to boot the
  system.  I pressed enter to bypass each prompt, and then saw I message
  that I'd be dropped to an emergency shell.  It took about a minute to
  open this shell each time (the shell died a few times while I was
  working).
  
  The disks it had prompted about were marked 'noauto' in /etc/crypttab,
  and all had keyfiles available on the root filesystem (which is
  encrypted but had been successfully mounted at the time); so no prompts
  should have been shown.
 
 Can you attach your /etc/fstab and /etc/crypttab please.

Attached (with serial numbers scrubbed).

  I've marked this as critical because I was unable to use the system
  until switching back to sysvinit.  Unfortunately, no logs of the event
  seem to be available now, so it's not clear why systemd considered there
  to be an emergency.
 
 Does this happen on every boot i.e. can you reproduce the error reliably?

I didn't retry, and since I had some difficulty recovering (see bug
#751589) I'd rather not do it on this system.  I was thinking of trying
in a VM but that might take a while.

-- Michael
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# file systemmount point   type  options  dump pass
proc   /proc   procdefaults,hidepid=2,gid=4 
   0 0
/dev/mapper/vg_terra_base-lv_root  /   ext4
noatime,errors=remount-ro   0 1
/dev/mapper/vg_terra_base-lv_basehome  /home   ext4noatime,nodev,nosuid 
   0 2
/dev/mapper/vg_terra_base-lv_var   /varext4noatime,nodev,nosuid 
   0 2
/dev/mapper/md1_crypt  noneswapsw   
   0 0
none   /tmp-michael tmpfs 
uid=1000,gid=1000,mode=0751,nodev,nosuid,size=10% 0 0

/dev/mapper/md3_crypt  /xr0xfs 
inode64,logbsize=262144,noatime,nodev,nosuid  0 2
/dev/mapper/xi1_crypt  /bulk/xi1xfs 
inode64,logbsize=262144,noatime,nodev,nosuid  0 2
/dev/mapper/xi2_crypt  /bulk/xi2xfs 
inode64,logbsize=262144,noatime,nodev,nosuid  0 2
/dev/mapper/chimera-a  /bulk/chimera xfs 
inode64,logbsize=262144,noatime,nodev,nosuid 0 0
/dev/mapper/octomamm-a /bulk/octomamm xfs 
inode64,logbsize=262144,noatime,nodev,nosuid 0 0
/dev/mapper/panther-a  /bulk/panther-a xfs 
inode64,logbsize=262144,noatime,nodev,nosuid 0 0
/dev/mapper/panther-b  /bulk/panther-b xfs 
inode64,logbsize=262144,noatime,nodev,nosuid 0 0
/dev/mapper/raven-a/bulk/raven xfs 
inode64,logbsize=262144,noatime,nodev,nosuid 0 0
/dev/mapper/rubicant-a /bulk/rubicant xfs 
inode64,logbsize=262144,noatime,nodev,nosuid 0 0
/dev/disk/by-id/scsi-SSeagate_Expansion_Desk_XXX-part1 /media/panther-efi vfat 
noauto,fmask=137,dmask=027 0 0
/dev/disk/by-id/ata-STXXX-XXX_XXX-part1 /media/chimera-efi vfat 
noauto,fmask=137,dmask=027 0 0

/dev/dvd  /media/dvd  udf,iso9660  user,noauto  
  0 0

/dev/md0   /boot
 ext3  defaults 0 2
/dev/disk/by-id/scsi-SATA_Hitachi_XXX_XXX-part1   /boot/efi-terra1  vfat  
noauto,fmask=137,dmask=027   0 0
/dev/disk/by-id/scsi-SATA_ST2000DL003-XXX-part1   /boot/efi-terra2  vfat  
noauto,fmask=137,dmask=027   0 0
/dev/disk/by-id/scsi-SATA_INTEL_SSDXXX-part1  /boot/efi-terra3  vfat  
noauto,fmask=137,dmask=027   0 0
/dev/disk/by-id/usb-CBM_Flash_Disk_XXX-0:0-part1  /media/bootkeyext2  
noatime,nosuid,nodev 0 0
/dev/disk/by-id/usb-SanDisk_XXX-0:0-part1 /media/bootkey-sc ext2 
noatime,nosuid,nodev 0 0

/dev/mapper/usb-slug /media/slug ext4 noauto,user,noatime,nosuid,nodev 
0 0
/dev/mapper/usb-mantcore /media/mantcore ext4 noauto,user,noatime,nosuid,nodev 
0 0
/dev/mapper/usb-jestrex  /media/jestrex  ext4 noauto,user,noatime,nosuid,nodev 
0 0
/dev/mapper/usb-tortoise /media/tortoise ext4 noauto,user,noatime,nosuid,nodev 
0 0
/dev/mapper/usb-cannibal /media/cannibal ext4 noauto,user,noatime,nosuid,nodev 
0 0
/dev/disk/by-id/usb-SanDisk_XXX-0:0-part1 /media/cruzer vfat 
rw,user,noauto,utf8,uid=1000,gid=1000,fmask=177,dmask=077 0 0

/dev/disk/by-id/usb-Lexar_JumpDrive_XXX-0:0-part1  /media/slug-clear
 vfat noauto,fmask=137,dmask=027,uid=1000,gid=1000,user 0 0
/dev/disk/by-id/usb

Bug#751589: [Pkg-sysvinit-devel] Bug#751589: sysvinit-core: /sbin/init missing after switching from systemd to sysvinit

[Michael Gold]

On Sat, Jun 14, 2014 at 16:47:45 +0200, Petter Reinholdtsen wrote:
 [Michael Gold]
  /sbin was available in the emergency shell and contained some files,
  but 'init' wasn't there.  'dpkg -L sysvinit-core' ended at the line
  '/sbin' (i.e., it was missing /sbin/shutdown, /sbin/init, etc.).  I
  eventually figured out to run 'dpkg -i' on that .deb; this restored
  /sbin/init, and then I was able to boot the system normally.
 
 This is quite strange.  My version 2.88dsf-53.2 of sysvinit-core in
 unstable contain these files:
...
 root@freedomboxtest:~# dpkg -L sysvinit-core|grep sbin
 /sbin
 /sbin/init
 /sbin/halt
 /sbin/runlevel
 /sbin/shutdown
 /sbin/poweroff
 /sbin/reboot
 /sbin/telinit
 root@freedomboxtest:~# 
 
 Is the amd64 build broken?  Or did dpkg mess up something?  I switched
 from systemd to sysvinit earlier today in a test machine using
 unstable, so that should work fine too.

The build is fine--those files are there in 2.88dsf-53 and 2.88dsf-53.2,
and dpkg -L sysvinit-core shows them now.  And after all, /sbin/init
appeared after running dpkg -i on the same file apt tried to install.

But I'm certain they were missing and the output ended at /sbin when I
ran the command in the emergency shell.  It seemed strange that the
/sbin directory would be included without any files in it.  I was also
surprised to see the manual, init.8.gz, without the associated binary.

-- Michael


signature.asc
Description: Digital signature

Bug#751585: systemd: opens emergency shell after prompting for unnecessary dm-crypt passwords

[Michael Gold]

On Sat, Jun 14, 2014 at 17:14:35 +0200, Michael Biebl wrote:
 Just install the systemd package (but not systemd-sysv) and keep
 sysvinit-core installed.
 
 Then you can easily boot with systemd by specifying the kernel command
 line parameter
 init=/lib/systemd/systemd
 
 This allows you to test systemd without replacing sysvinit as default init.

OK, I might be able to try that later today.  If it's reproducible, what
should I do to gather information?

-- Michael


signature.asc
Description: Digital signature

Bug#751589: sysvinit-core: /sbin/init missing after switching from systemd to sysvinit

[Michael Gold]

On Sat, Jun 14, 2014 at 17:34:21 +0200, Michael Biebl wrote:
 That said, I can not reproduce the sequence of events which make
 /sbin/init dissappear.
 
 I've installed systemd-sysv in a VM, then ran apt-get install
 sysvinit-core and /sbin/init was available afterwards.
 
 So something else must have happened

Did you try apt-get remove systemd?  According to apt-history that was
the first command I ran after installing it.

-- Michael


signature.asc
Description: Digital signature

Bug#751585: systemd: opens emergency shell after prompting for unnecessary dm-crypt passwords

[Michael Gold]

On Sat, Jun 14, 2014 at 17:30:30 +0200, Michael Biebl wrote:
 I noticed that you don't have those crypt devices marked as noauto (or
 nofail) in /etc/fstab.
 This means, if they fail to show up during boot systemd will drop you in
 an emergency shell (which is what happened in your case).
 
 Try booting with systemd where those devices are marked accordingly in
 fstab.

OK, thanks.  I don't remember seeing a message to that effect, but I'll
look for it when retesting.

Perhaps the options I want are quiet in crypttab and nofail in
fstab, so they'll be mounted if available.  With sysvinit most of them
actually are automounted during startup--I have a udev script that runs
cryptdisks_start when the disks are detected, and I guess the timing is
different enough that it works there.

-- Michael


signature.asc
Description: Digital signature

Bug#751589: sysvinit-core: /sbin/init missing after switching from systemd to sysvinit

[Michael Gold]

On Sat, Jun 14, 2014 at 18:31:25 +0200, Michael Biebl wrote:
  Did you try apt-get remove systemd?  According to apt-history that was
  the first command I ran after installing it.
 
 You can't remove the systemd package while systemd is still the active init.
 How did you force the removal?

I just ran the apt-get commands shown in the apt-history.log, without
any flags to force it, and didn't run any dpkg commands (except the
eventual dpkg -i to recover).  I think what Sven reproduced is what
happened to me.  According to the logs, I started with sysvinit-core
2.88dsf-53 (not 53.2).

Note that the systemd removal didn't actually work until 9:22, when I
was running sysvinit again.  But one of the earlier commands left me
without an init.

-- Michael


signature.asc
Description: Digital signature

Bug#751585: systemd: opens emergency shell after prompting for unnecessary dm-crypt passwords

[Michael Gold]

severity 751585 normal
clone 751585 -1 -2 -3
retitle -1 systemd: shows unnecessary password prompts for encrypted disks
severity -1 normal
retitle -2 systemd: should print reason for starting emergency shell
severity -2 wishlist
retitle -3 systemd: emergency shell takes several minutes to start
severity -3 normal
thanks

On Sat, Jun 14, 2014 at 17:30:30 +0200, Michael Biebl wrote:
 Thanks.
 I noticed that you don't have those crypt devices marked as noauto (or
 nofail) in /etc/fstab.
 This means, if they fail to show up during boot systemd will drop you in
 an emergency shell (which is what happened in your case).
 
 Try booting with systemd where those devices are marked accordingly in
 fstab.

It turns that /media/bootkey was missing, and putting nofail there got
the system booting successfully.  This was just a regular unencrypted
USB flash drive, which had spontaneously zeroed itself a few months ago
but was still listed in my fstab.  Running journalctl showed a message
about it, but it wasn't obvious--there was some similarly-highlighted
text about a missing /bin/plymouth (apparently not an actual problem)
and a bunch of other verbosity that filled up the screen.

I'm reducing the severity because this is a configuration problem.  You
can close it if you want, or leave it open and try to detect situations
like this during installation or boot (since it works with sysvinit).

I'm splitting off some other bugs I noticed (see the attached
screenshot):
 * systemd shouldn't be pausing startup to show password prompts for
   anything marked noauto in crypttab, or anything with a keyfile
 * it should show an obvious message describing why it went into
   emergency mode
 * after printing Welcome to emergency mode!, it took a minute or two
   before a password prompt was shown; but that prompt died (I guess)
   without accepting any keyboard input, and after another few minutes I
   got another welcome message and password prompt (it worked this time)

-- Michael


signature.asc
Description: Digital signature