Bug#1081514: libcurl-gnutls.so.4: undefined symbol: gnutls_free

[Russell Coker]

On Thursday, 12 September 2024 22:51:39 AEST Simon McVittie wrote:
> Looks like a duplicate of  which is a
> regression in libcurl3t64-gnutls. libcurl4t64 (curl with OpenSSL) looks OK
> according to packages.debian.org.

Yes the same issue.  Thanks for the quick response.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

Bug#1051181: more info

[Russell Coker]

# id test
uid=1001(test) gid=1001(test) groups=1001(test),1003(),1004(zzz2),
1005(test2),1006(test6),1007(test7),1008(test8),1009(test9),1010(test10),
1011(test11),1012(test12),1013(test13),1014(test14),1015(test15),1016(test16),
1017(test17),1018(test18),1019(test19)

The above is the test user I used for compiling.  The real use case was a user 
in a corporate network with 30+ groups from Active Directory.  This sort of AD 
configuration is increasingly common and should work.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

Bug#1051181: FTBFS: can't build package when user has more than 16 supplementary groups

[Russell Coker]

Package: fapolicyd
Version: 1.1.7-5
Severity: serious
Tags: patch ftbfs
Justification: fails to build from source (but built successfully in the past)

# TOTAL: 2
# PASS:  1
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: gid_proc_test
===

./gid_proc_test: Too many groups
FAIL gid_proc_test (exit status: 1)

Above are the relevant parts of the compile output when trying to build it by a
user with more than 16 supplementary groups.

Below is the patch to fix this:


Index: fapolicyd-1.1.7/src/tests/gid_proc_test.c
===
--- fapolicyd-1.1.7.orig/src/tests/gid_proc_test.c
+++ fapolicyd-1.1.7/src/tests/gid_proc_test.c
@@ -2,6 +2,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "attr-sets.h"
 #include "process.h"
@@ -9,7 +10,7 @@
 int main(void)
 {
int res, num, i, check_intersect = 0;
-   gid_t gid, gids[16];
+   gid_t gid, gids[NGROUPS_MAX];
attr_sets_entry_t *groups = get_gid_set_from_pid(getpid());
 
gid = getgid();
@@ -17,7 +18,7 @@ int main(void)
if (!res)
error(1, 0, "Group %d not found", gid);
 
-   num = getgroups(16, gids);
+   num = getgroups(NGROUPS_MAX, gids);
if (num < 0)
error(1, 0, "Too many groups");
 

-- System Information:
Debian Release: trixie/sid
Architecture: amd64 (x86_64)

Kernel: Linux 6.4.0-4-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU:en
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Bug#1037890: fixed in 4.3.5

[Russell Coker]

close 1037890
thanks

This was fixed upstream in 4.3.5

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

Bug#963497: not a bug for that version

[Russell Coker]

close 963497
thanks

Run "setsebool allow_execmem 1" before running certbot and it will be fine.  
After running certbot you can run "setsebool allow_execmem 0".  Or you could 
run "setsebool -P allow_execmem 1" to make the change continue to apply after 
a reboot.

The 2:2.20161023.1-9 policy doesn't have support for certbot so it's working 
as designed.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

Bug#963495: not a bug

[Russell Coker]

close 963495
thanks

Run "setsebool allow_execmem 1" before running certbot and it will be fine.  
After running certbot you can run "setsebool allow_execmem 0".  Or you could 
run "setsebool -P allow_execmem 1" to make the change continue to apply after 
a reboot.

There is no good solution to this as we don't want to allow execmem by 
default.  Also this only happens if you have openssl python libraries 
installed (typically dragged in by certbot dependencies).  If you don't have 
them installed then reportbug doesn't need execmem access.

This is annoying, but we just have some unpleasant choices.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

Bug#956568: libsepol: should build-depend on libselinux1-dev

[Russell Coker]

Source: libsepol
Version: 3.0-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Gives a compile error about missing flask.h.

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

Kernel: Linux 5.5.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Enforcing - Policy name: default

Bug#943495: Can't reproduce

[Russell Coker]

severity 943495 normal
thanks

I was unable to reproduce a problem when building with the latest packages 
from Unstable.  It appears to be building the Python 3.8 stuff in the 
cpython3_3.8 directory.

I've installed the gcc package from experimental to make all the gcc links 
point to version 10, it still has no problems.

Please tell us how to reproduce this problem and give us build logs showing 
the error.  If "a new compiler" means something other than GCC 10 please tell 
us what it is.

I also don't know why we would want to have this warning ignored if it happens 
at some future time.  Why not just fix the code to have all fields initialised?

Please provide build instructions for how to reproduce this issue and a 
rationale for using -Wno-error=missing-field-initializers instead of 
initialising all the fields.

Please don't change the priority without explaining how this is a problem.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

Bug#952896: kmail: message body section of kmail flickers rapidly and displays no content

[Russell Coker]

Package: kmail
Version: 4:19.08.3-1
Severity: critical
Justification: breaks unrelated software

I tagged this critical and breaks unrelated software as there seems no better
tag for software that is dangerous for epileptic people to use.

Every time I launch kmail the message body section flickers black and white
rapidly and displays no content.  This makes the program impossible to use,
uses 100% CPU time on one core, and makes it dangerous for some people to use.

If I run "ssh -Y localhost" before running kmail I get the same result of no
content being displayed but the flickering is slower due to X/ssh delays.

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

Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Enforcing - Policy name: default

Versions of packages kmail depends on:
ii  akonadi-server  4:19.08.3-1
ii  kdepim-runtime  4:19.08.3-2
ii  kio 5.62.1-2+b1
ii  libc6   2.29-10
ii  libgcc-s1 [libgcc1] 10-20200222-1
ii  libgcc1 1:10-20200222-1
ii  libgpgmepp6 1.13.1-6
ii  libkf5akonadiagentbase5 [libkf5akonadiagentbase5-19.08] 4:19.08.3-1
ii  libkf5akonadicontact5 [libkf5akonadicontact5-19.08] 4:19.08.3-1
ii  libkf5akonadicore5abi2 [libkf5akonadicore5-19.08]   4:19.08.3-1
ii  libkf5akonadimime5 [libkf5akonadimime5-19.08]   4:19.08.3-1
ii  libkf5akonadisearch-bin 4:19.08.3-1
ii  libkf5akonadisearch-plugins 4:19.08.3-1
ii  libkf5akonadisearchdebug5 [libkf5akonadisearchdebug5-19.08  4:19.08.3-1
ii  libkf5akonadisearchpim5 [libkf5akonadisearchpim5-19.08] 4:19.08.3-1
ii  libkf5akonadiwidgets5abi1 [libkf5akonadiwidgets5-19.08] 4:19.08.3-1
ii  libkf5bookmarks55.62.0-1+b1
ii  libkf5calendarcore5abi2 [libkf5calendarcore5-19.08] 4:19.08.3-2
ii  libkf5calendarutils5 [libkf5calendarutils5-19.08]   4:19.08.3-1
ii  libkf5codecs5   5.62.0-1
ii  libkf5completion5   5.62.0-1+b1
ii  libkf5configcore5   5.62.0-1+b1
ii  libkf5configgui55.62.0-1+b1
ii  libkf5configwidgets55.62.0-1+b1
ii  libkf5contacts5 [libkf5contacts5-19.08] 4:19.08.3-1
ii  libkf5coreaddons5   5.62.0-1
ii  libkf5crash55.62.0-1+b1
ii  libkf5dbusaddons5   5.62.0-1
ii  libkf5followupreminder5 [libkf5followupreminder5-19.08] 4:19.08.3-1
ii  libkf5grantleetheme-plugins 19.08.3-1
ii  libkf5gravatar5abi2 [libkf5gravatar5-19.08] 4:19.08.3-1
ii  libkf5guiaddons55.62.0-2
ii  libkf5i18n5 5.62.0-1
ii  libkf5iconthemes5   5.62.0-1+b1
ii  libkf5identitymanagement5 [libkf5identitymanagement5-19.08  19.08.3-1
ii  libkf5itemmodels5   5.62.0-1
ii  libkf5itemviews55.62.0-1+b1
ii  libkf5jobwidgets5   5.62.0-1+b1
ii  libkf5kcmutils5 5.62.0-1+b2
ii  libkf5kiocore5  5.62.1-2+b1
ii  libkf5kiofilewidgets5   5.62.1-2+b1
ii  libkf5kiowidgets5   5.62.1-2+b1
ii  libkf5kontactinterface5 [libkf5kontactinterface5-19.08] 19.08.3-1
ii  libkf5ksieveui5 [libkf5ksieveui5-19.08] 4:19.08.3-1
ii  libkf5libkdepim5 [libkf5libkdepim5-19.08]   4:19.08.3-1
ii  libkf5libkdepimakonadi5 [libkf5libkdepimakonadi5-19.08] 4:19.08.3-1
ii  libkf5libkleo5 [libkf5libkleo5-19.08]   4:19.08.3-1
ii  libkf5mailcommon5abi2 [libkf5mailcommon5-19.08] 4:19.08.3-1
ii  libkf5mailtransport5 [libkf5mailtransport5-19.08]   19.08.3-1
ii  libkf5mailtransportakonadi5 [libkf5mailtransportakonadi5-1  19.08.3-1
ii  libkf5messagecomposer5abi1 [libkf5messagecomposer5-19.08]   4:19.08.3-1

Bug#874191: not serious

[Russell Coker]

severity 874191 normal
thanks

Daemon in the wrong domain is not a reason to have the package removed from 
testing.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

Bug#874191: might be a duplicate

[Russell Coker]

On Thursday, 7 September 2017 8:06:12 PM AEST Harlan Lieberman-Berg wrote:
> Hm.  Looking more, you may be right.  What's odd is that some binaries
> that are (presumably) being launched by Gnome are being correctly
> given the right context; for example, gdm and X are running as
> system_u:system_r:xdm_t:s0-s0:c0.c1023.  evolution-calendar, though,
> is system_u:system_r:init_t:s0.  And yet other things that are
> probably also part of my user session are
> unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023.

gdm has the correct domain.  Maybe pam is not configured correctly.  Below is 
/etc/pam.d/sddm from one of my systems, try making your gdm pam configuration 
more like this and see if things work correctly.

#%PAM-1.0

# Block login if they are globally disabled
authrequisite   pam_nologin.so
authrequiredpam_succeed_if.so user != root quiet_success

# authsufficient  pam_succeed_if.so user ingroup nopasswdlogin
@include common-auth
# gnome_keyring breaks QProcess
-auth   optionalpam_gnome_keyring.so
-auth   optionalpam_kwallet5.so

@include common-account

# SELinux needs to be the first session rule.  This ensures that any
# lingering context has been cleared.  Without this it is possible that a
# module could execute code in the wrong domain.
session [success=ok ignore=ignore module_unknown=ignore default=bad] 
pam_selinux.so close
# Create a new session keyring.
session optionalpam_keyinit.so force revoke
session requiredpam_limits.so
session requiredpam_loginuid.so
@include common-session
# SELinux needs to intervene at login time to ensure that the process starts
# in the proper default security context.  Only sessions which are intended
# to run in the user's context should be run after this.
session [success=ok ignore=ignore module_unknown=ignore default=bad] 
pam_selinux.so open
-session optional   pam_gnome_keyring.so auto_start
-session optional   pam_kwallet5.so auto_start

@include common-password

# From the pam_env man page
# Since setting of PAM environment variables can have side effects to other 
modules, this module should be the last one on the stack.

# Load environment from /etc/environment
session requiredpam_env.so

# Load environment from /etc/default/locale
session requiredpam_env.so envfile=/etc/default/locale


-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

Bug#874191: might be a duplicate

[Russell Coker]

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874201

Yesterday I was investigating an issue that might be related and I just filed 
the above bug report.  Please investigate whether that might be the cause.

# ps axZ|grep sddm
system_u:system_r:xdm_t:s0-s0:c0.c1023 963 ?   Ssl0:00 /usr/bin/sddm

Run "ps axZ|grep gdm3" to see the context, the output should be something like 
the above if all goes well (xdm_t is the relevant part).

# ls -lZ /usr/bin/sddm
-rwxr-xr-x. 1 root root system_u:object_r:xdm_exec_t:s0 475968 Mar 14 19:50 /
usr/bin/sddm

Also run "ls -lZ" on the binary to see if it has the right context, the output 
should be something like the above, xdm_exec_t is the relevant part.

If those checks pass then run the systemctl command suggested in #874201 and 
restart gdm3 to see if it gets the right context.

PS  I gave up on gdm3 last time due to some other issues.  Is there a gdm3 
specific feature you really need?  If you want to improve Debian then 
debugging this is a good thing to do, if you just want a working system then 
sddm might be a better choice.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

Bug#853207: bluez: bluetooth.service doesn't start with systemd

[Russell Coker]

Package: bluez
Version: 5.43-1
Severity: grave
Justification: renders package unusable

# systemctl restart bluetooth.service
# systemctl status bluetooth.service
● bluetooth.service - Bluetooth service
   Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled; vendor preset
   Active: inactive (dead)
 Docs: man:bluetoothd(8)

When running systemd on Unstable the bluetooth daemon doesn't start and NOTHING
is logged about it.

It is possible that my laptop (the only PC I own with bluetooth hardware) is
somehow unsuitable for running bluetooth.  It could be that bluetooth is
exiting for a correct reason but the total lack of any logs (either in stdout/
stderr or in syslog) means that I can't determine if this is the case.

If I run /usr/lib/bluetooth/bluetoothd from the command-line as root it appears
to basically work (bluetoothctl will talk to it) so it seems to be something
related to the service file.

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

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

Versions of packages bluez depends on:
ii  dbus 1.10.14-1
ii  init-system-helpers  1.47
ii  kmod 23-2
ii  libc62.24-9
ii  libdbus-1-3  1.10.14-1
ii  libglib2.0-0 2.50.2-2
ii  libreadline7 7.0-2
ii  libudev1 232-14
ii  lsb-base 9.20161125
ii  udev 232-14

bluez recommends no packages.

Versions of packages bluez suggests:
pn  pulseaudio-module-bluetooth  

-- no debconf information

Bug#817677: already fixed

[Russell Coker]

close 817677
thanks

I fixed this in version 2.2.1-2 but forgot to put a closes: entry in the 
changelog.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

Bug#800258: already fixed

[Russell Coker]

close 800258
thanks

This was fixed in 0.13e but I forgot to list it in the changelog.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

Bug#849787: probably best to just ignore this for Stretch

[Russell Coker]

priority 849787 wishlist
thanks

I've made selinux policy packages conflict with mcstrans so this shouldn't be 
a problem any more.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

Bug#830472: can't reproduce, not serious

[Russell Coker]

severity 830472 normal
thanks

I can't reproduce this.  Version 0.74 fixed all the GCC6 related bugs that 
occur on my system.

Version 0.75 should stay in testing because the amd64 package I uploaded 
compiled without any serious warnings.

I'll fix this bug if I can reproduce it, but it's not a reason to remove 
postal from testing.  If you have any suggestions for reproducing it then 
please let me know.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

Bug#849787: mcstrans: Running mcstrans triggers 849748 and is the most serious SE Linux problem

[Russell Coker]

Package: mcstrans
Version: 2.6-2
Severity: critical
Tags: upstream
Justification: breaks unrelated software

While mcstrans has no problems for what it does, it triggers bad interactions
between systemd, dbus, and SE Linux.  I don't think it is possible to properly
solve these issues before the sid is frozen.  Therefore I think that mcstrans
should be removed from testing and not offered for installation in the next
stable release.

At this time this is the most serious problem we have with SE Linux in Debian.

As an aside by default Fedora doesn't run mcstrans.  I don't know whether it's
for the same reason, but in any case Fedora users are surviving well enough
without it.

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

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

Versions of packages mcstrans depends on:
ii  init-system-helpers  1.46
ii  libc62.24-8
ii  libcap2  1:2.25-1
ii  libpcre3 2:8.39-2
ii  libselinux1  2.6-3
ii  lsb-base 9.20161125
ii  selinux-utils2.6-3

mcstrans recommends no packages.

mcstrans suggests no packages.

-- no debconf information

Bug#835910: warzone2100: FTBFS when newer automake is installed

[Russell Coker]

Package: warzone2100
Version: 3.1.1-3
Severity: serious
Tags: upstream patch
Justification: fails to build from source (but built successfully in the past)

The warzone2100 build system insists on automake and aclocal version 1.11.  If
you have 1.15 installed it won't build.

The following patch makes it build when you have a version of automake newer
than 1.11 installed and the links automake and aclocal pointing to the newer
versions (as is the default when multiple versions are installed).

While it is possible to purge newer versions of automake from your system
before starting a build this shouldn't be required and doesn't work well if
your system is used for building packages that depend on newer versions of
automake.

I think this should be included in Unstable to make things easier for everyone
who wants to work on this package.  The same patch is needed for version 3.2.1.

Index: warzone2100-3.1.1/autogen.sh
===
--- warzone2100-3.1.1.orig/autogen.sh
+++ warzone2100-3.1.1/autogen.sh
@@ -148,13 +148,13 @@ not_version ()
 # Chdir to the srcdir, then run auto* tools.
 cd "$SRCDIR"
 
-version_check 0 "automake" "ftp://ftp.gnu.org/pub/gnu/automake/"; 1 12 && {
+version_check 0 "automake-1.11" "ftp://ftp.gnu.org/pub/gnu/automake/"; 1 12 && {
   echo "Sorry, automake 1.12+ is not supported yet, please use 1.11."
   exit 1
 }
 
 version_check 1 "autoconf" "ftp://ftp.gnu.org/pub/gnu/autoconf/"; 2 56 || DIE=1
-version_check 1 "automake" "ftp://ftp.gnu.org/pub/gnu/automake/"; 1 11 || DIE=1
+version_check 1 "automake-1.11" "ftp://ftp.gnu.org/pub/gnu/automake/"; 1 11 || 
DIE=1
 if [ "$DIE" -eq 1 ]; then
   exit 1
 fi
@@ -164,10 +164,10 @@ fi
   exit 1
 }
 
-echo "+ running aclocal ..."
-aclocal -I m4 || {
+echo "+ running aclocal-1.11 ..."
+aclocal-1.11 -I m4 || {
   echo
-  echo "aclocal failed - check that all needed development files are present 
on system"
+  echo "aclocal-1.11 failed - check that all needed development files are 
present on system"
   exit 1
 }
 echo "+ running autoheader ... "
@@ -182,10 +182,10 @@ autoconf || {
   echo "autoconf failed"
   exit 1
 }
-echo "+ running automake ... "
-automake -a -c --foreign || {
+echo "+ running automake-1.11 ... "
+automake-1.11 -a -c --foreign || {
   echo
-  echo "automake failed"
+  echo "automake-1.11 failed"
   exit 1
 }
 

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

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

Versions of packages warzone2100 depends on:
ii  libc6 2.23-5
ii  libfontconfig12.11.0-6.7
ii  libfreetype6  2.6.3-3+b1
ii  libfribidi0   0.19.7-1
ii  libgcc1   1:6.2.0-1
ii  libgl1-mesa-glx [libgl1]  11.2.2-1
ii  libglc0   0.7.2-5+b3
ii  libglew1.13   1.13.0-2
ii  libglu1-mesa [libglu1]9.0.0-2.1
ii  libminiupnpc101.9.20140610-2.1
ii  libogg0   1.3.2-1
ii  libopenal11:1.17.2-1
ii  libphysfs12.0.3-3
ii  libpng16-16   1.6.24-2
ii  libqt4-network4:4.8.7+dfsg-8
ii  libqt4-script 4:4.8.7+dfsg-8
ii  libqtcore44:4.8.7+dfsg-8
ii  libsdl1.2debian   1.2.15+dfsg1-4
ii  libstdc++66.2.0-1
ii  libtheora01.1.1+dfsg.1-14
ii  libvorbis0a   1.3.5-3
ii  libvorbisfile31.3.5-3
ii  libx11-6  2:1.6.3-1
ii  libxrandr22:1.5.0-1
ii  warzone2100-data  3.1.1-3
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages warzone2100 recommends:
ii  warzone2100-music  3.1.1-3

warzone2100 suggests no packages.

-- no debconf information

Bug#778599: Vulnerabilities in nanohttp

[Russell Coker]

On Thu, 21 Apr 2016 02:58:18 PM Salvatore Bonaccorso wrote:
> Given the package looks unmaintained (last update by maintainer back
> in 20 Jun 2010, I think it is the best option to remove the package as
> well from unstable). It is already gone in testing, so will not be
> included in stretch and neither was in jessie.

OK sounds reasonable.

Sorry I've been having problems maintaining my packages that are more useful 
than that one.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

Bug#805492: /var/lib

[Russell Coker]

On Mon, 29 Feb 2016 02:47:04 AM Laurent Bigonville wrote:
> Le 28/02/16 11:05, Russell Coker a écrit :
> >> the easiest would be to do like fedora and install the modules directly
> >> in the /var/lib/selinux//100 store instead of copying/loading
> >> them at installation time
> > 
> > Do you mean having files in the package under /var/lib?  If so that seems
> > like a FHS violation.  Why not just keep them under /usr/share/selinux
> > and symlink them?
> 
> There are a lot of packages that ships files in /var/lib.

I'm sure that you can find many ways in which there are a lot of broken 
packages in Debian or in any other distribution.  That said if we have a 
strong precedent in Debian for doing things a certain way it is an argument 
for doing more of the same.

> Are you sure you are not thinking about /var/run?

https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

# State information. Persistent data modified by programs as they run, e.g.,
# databases, packaging system metadata, etc.

The above section from the above URL suggests that package maintained files 
aren't suitable.

The description of /usr is:
# Secondary hierarchy for read-only user data; contains the majority of
# (multi-)user utilities and applications.

For /usr/share it says:
# Architecture-independent (shared) data.

I think that /usr/share is the best place for it.  If /var/lib has symlinks 
into /usr/share then files which aren't changed can be replaced by a package 
upgrade while files that are modified by utilities can stay modified.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

Bug#805492: /var/lib

[Russell Coker]

> the easiest would be to do like fedora and install the modules directly in
> the /var/lib/selinux//100 store instead of copying/loading them at
> installation time

Do you mean having files in the package under /var/lib?  If so that seems like 
a FHS violation.  Why not just keep them under /usr/share/selinux and symlink 
them?

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

Bug#815861: mcstrans: doesn't create /var/run/setrans on startup with systemd

[Russell Coker]

Package: mcstrans
Version: 2.4-4
Severity: grave
Justification: renders package unusable

/var/run/setrans 0755 root root - -

I think we need a /usr/lib/tmpfiles.d file with something like the above to 
create it
when systemd is in use.  Currently mcstrans doesn't start on Unstable.

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

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

Versions of packages mcstrans depends on:
ii  init-system-helpers  1.28+nmu1
ii  libc62.21-9
ii  libcap2  1:2.24-12
ii  libpcre3 2:8.38-1
ii  libselinux1  2.4-3
ii  selinux-utils2.4-3

mcstrans recommends no packages.

mcstrans suggests no packages.

-- no debconf information

Bug#756729: I just uploaded a package to fix this

[Russell Coker]

deb http://www.coker.com.au jessie selinux

It's at the above repository if you can't wait for it to get into 
Unstable/Testing.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

Bug#756729: about to close

[Russell Coker]

I'm going to upload a new policy to unstable that closes this bug.  It allows 
udev to restart systemd services (the core problem with allow-hotplug).  The 
policy in question doesn't support all the features of the version of systems 
in unstable (I'll get to that later).

deb http://www.coker.com.au jessie selinux

For people who use Jessie the above APT repository will have the new policy to 
fix these problems.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

Bug#771484: fixed in 2.20140421-8

[Russell Coker]

close 771484
thanks


Version 2.20140421-8 fixed this.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/


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

Bug#756729: Already fixed

[Russell Coker]

close 756729
thanks

This was fixed in testing ages ago.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/


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

Bug#771484: selinux-policy-default: GPG is totally broken

[Russell Coker]

Package: selinux-policy-default
Version: 2:2.20140421-7
Severity: grave
Justification: renders package unusable

"gpg" doesn't work on the command-line, gpg-agent can't be statted, and the
whole X login process that spawns gpg-agent doesn't work for most user roles.

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

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

Versions of packages selinux-policy-default depends on:
ii  libpam-modules   1.1.8-3.1
ii  libselinux1  2.3-2
ii  libsepol12.3-2
ii  policycoreutils  2.3-1
ii  python   2.7.8-2
ii  selinux-utils2.3-2

Versions of packages selinux-policy-default recommends:
ii  checkpolicy  2.3-1
ii  setools  3.3.8-3.1

Versions of packages selinux-policy-default suggests:
pn  logcheck
pn  syslog-summary  

-- Configuration Files:
/etc/selinux/default/modules/active/file_contexts.local [Errno 13] Permission 
denied: u'/etc/selinux/default/modules/active/file_contexts.local'

-- no debconf information


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

Bug#755404: NMU to fix

[Russell Coker]

On Mon, 28 Jul 2014 09:53:25 Emilio Pozuelo Monfort wrote:
> On 28/07/14 09:22, Russell Coker wrote:
> > I've uploaded a NMU to fix this to the 7 day delayed
> > queue.  I made no code changes and just rebuilt it.
> 
> Why not request a binNMU instead?

I didn't realise that was possible.

> Also, goplay depends on libept1.4.12 which ships
> /usr/lib/libept.so.1.0.5.4.12. So how can the linker fail to find
> libept.so.1.0.5.4.12 and how does a rebuild help?

# dpkg -L libept1.4.12 |grep libept.so.1.0.5
/usr/lib/libept.so.1.0.5.4.12
# ls -l /usr/lib/libept.so.1.0.5.4.12
ls: cannot access /usr/lib/libept.so.1.0.5.4.12: No such file or directory

The above happens on 2 systems that are tracking Unstable, and presumably it 
happens the same 
way for the person who reported the bug.  Looks like it might be a libept bug.

But in any case it doesn't seem to be a problem to rebuild goplay.  Maybe it 
would be best to cancel 
my upload and do a binNMU.  What do you think?

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

Bug#755404: NMU to fix

[Russell Coker]

I've uploaded a NMU to fix this to the 7 day delayed 
queue.  I made no code changes and just rebuilt it.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

Bug#752591: Bug#752605: udev: luks/lvm not detected rendering system unbootable

[Russell Coker]

On Wed, 25 Jun 2014 09:02:59 Michael Biebl wrote:
> Russel, can you confirm that that reverting the "kmod load sg" patch
> also fixes your problem?

It seems to.  Booted once since applying it and it worked.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/


signature.asc
Description: This is a digitally signed message part.

Bug#678853: maildir-bulletin: should it be removed? /home/bulletins/removed

[Russell Coker]

On Sat, 25 Aug 2012, Ivo De Decker  wrote:
> Is anybody still interested in maintaining this package in debian? Perhaps
> it makes more sense to remove it.
> 
> - it has very few users (popcon says 16)
> - it is RC buggy (writes in /home)
> - the last upload was in 2008
> - the maintainer put it up for adoption (http://bugs.debian.org/678926)
> - upstream is dead (the maintainer of the debian package is also upstream,
> and doesn't use it anymore, also http://bugs.debian.org/678926)
> 
> Russel, what do you think?

Sounds reasonable to me.

Going forward it's probably best that anyone who needs such things considers 
rewriting it.  The environment today is a lot different than it was when I 
wrote that program.

Probably the best thing to do for someone who needs that sort of thing is to 
have a program which takes a message from stdin or a file and writes it to the 
mail store and have it based around the idea of a mail store owned by one user 
not a user account per mailbox.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/


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

Bug#668954: not a serious bug, just a new feature that doesn't work.

[Russell Coker]

severity 668954 minor
thanks

I can't get the policy for this written for Wheezy.  I've attached a policy 
patch for a work in progress so anyone who is interested can work on it for 
their own purposes.

I'll get this going post-Wheezy with a new policy tree from upstream.  For 
Wheezy I think I'll just remove the sandbox program from policycoreutils as 
there's no way of making it do anything useful.

This isn't an important issue as it's a new feature that has never worked.  
Everything else in policycoreutils has worked well without this and will 
continue to work without it.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/
Description: Add sandbox support for the sandbox utility from policycoreutils
Author: Russell Coker 
Origin: Fedora
Last-Update: 2012-06-26

Index: refpolicy-2.20110726/policy/modules/apps/sandbox.te
===
--- /dev/null   1970-01-01 00:00:00.0 +
+++ refpolicy-2.20110726/policy/modules/apps/sandbox.te 2012-06-26 
15:58:56.353278656 +1000
@@ -0,0 +1,509 @@
+policy_module(sandbox,1.0.0)
+
+dbus_stub()
+attribute sandbox_domain;
+attribute sandbox_x_domain;
+attribute sandbox_web_type;
+attribute sandbox_file_type;
+attribute sandbox_tmpfs_type;
+attribute sandbox_type;
+
+type sandbox_exec_t;
+files_type(sandbox_exec_t)
+
+type sandbox_file_t, sandbox_file_type;
+files_type(sandbox_file_t)
+typealias sandbox_file_t alias { sandbox_x_file_t sandbox_web_file_t 
sandbox_net_file_t sandbox_min_file_t };
+
+
+#
+# Declarations
+#
+
+sandbox_domain_template(sandbox)
+sandbox_x_domain_template(sandbox_min)
+sandbox_x_domain_template(sandbox_x)
+sandbox_x_domain_template(sandbox_web)
+sandbox_x_domain_template(sandbox_net)
+
+type sandbox_xserver_t;
+domain_type(sandbox_xserver_t)
+xserver_user_x_domain_template(sandbox_xserver, sandbox_xserver_t, 
sandbox_xserver_tmpfs_t)
+
+type sandbox_xserver_tmpfs_t;
+files_tmpfs_file(sandbox_xserver_tmpfs_t)
+
+type sandbox_devpts_t;
+term_pty(sandbox_devpts_t)
+files_type(sandbox_devpts_t)
+
+
+#
+# sandbox xserver policy
+#
+allow sandbox_xserver_t self:process { signal_perms execstack };
+
+tunable_policy(`deny_execmem',`',`
+   allow sandbox_xserver_t self:process execmem;
+')
+
+allow sandbox_xserver_t self:fifo_file manage_fifo_file_perms;
+allow sandbox_xserver_t self:shm create_shm_perms;
+allow sandbox_xserver_t self:tcp_socket create_stream_socket_perms;
+
+manage_dirs_pattern(sandbox_xserver_t, sandbox_file_t, sandbox_file_t)
+manage_files_pattern(sandbox_xserver_t, sandbox_file_t, sandbox_file_t)
+manage_sock_files_pattern(sandbox_xserver_t, sandbox_file_t, sandbox_file_t)
+allow sandbox_xserver_t sandbox_file_t:sock_file create_sock_file_perms;
+
+manage_dirs_pattern(sandbox_xserver_t, sandbox_xserver_tmpfs_t, 
sandbox_xserver_tmpfs_t)
+manage_files_pattern(sandbox_xserver_t, sandbox_xserver_tmpfs_t, 
sandbox_xserver_tmpfs_t)
+manage_lnk_files_pattern(sandbox_xserver_t, sandbox_xserver_tmpfs_t, 
sandbox_xserver_tmpfs_t)
+manage_fifo_files_pattern(sandbox_xserver_t, sandbox_xserver_tmpfs_t, 
sandbox_xserver_tmpfs_t)
+manage_sock_files_pattern(sandbox_xserver_t, sandbox_xserver_tmpfs_t, 
sandbox_xserver_tmpfs_t)
+fs_tmpfs_filetrans(sandbox_xserver_t, sandbox_xserver_tmpfs_t, { dir file 
lnk_file sock_file fifo_file })
+
+kernel_dontaudit_request_load_module(sandbox_xserver_t)
+kernel_read_system_state(sandbox_xserver_t)
+
+corecmd_exec_bin(sandbox_xserver_t)
+corecmd_exec_shell(sandbox_xserver_t)
+
+corenet_all_recvfrom_unlabeled(sandbox_xserver_t)
+corenet_all_recvfrom_netlabel(sandbox_xserver_t)
+corenet_tcp_sendrecv_generic_if(sandbox_xserver_t)
+corenet_udp_sendrecv_generic_if(sandbox_xserver_t)
+corenet_tcp_sendrecv_generic_node(sandbox_xserver_t)
+corenet_udp_sendrecv_generic_node(sandbox_xserver_t)
+corenet_tcp_sendrecv_all_ports(sandbox_xserver_t)
+corenet_udp_sendrecv_all_ports(sandbox_xserver_t)
+corenet_tcp_bind_generic_node(sandbox_xserver_t)
+corenet_tcp_bind_xserver_port(sandbox_xserver_t)
+corenet_sendrecv_xserver_server_packets(sandbox_xserver_t)
+corenet_sendrecv_all_client_packets(sandbox_xserver_t)
+
+dev_read_sysfs(sandbox_xserver_t)
+dev_rwx_zero(sandbox_xserver_t)
+dev_read_urand(sandbox_xserver_t)
+
+domain_use_interactive_fds(sandbox_xserver_t)
+
+files_read_config_files(sandbox_xserver_t)
+files_read_usr_files(sandbox_xserver_t)
+files_search_home(sandbox_xserver_t)
+fs_dontaudit_rw_tmpfs_files(sandbox_xserver_t)
+fs_list_inotifyfs(sandbox_xserver_t)
+fs_search_auto_mountpoints(sandbox_xserver_t)
+
+miscfiles_read_fonts(sandbox_xserver_t)
+miscfiles_read_localization(sandbox_xserver_t)
+
+selinux_validate_context(sandbox_xserver_t)
+selinux_compute_access_vector(sandbox_xserver_t)
+selinux_compute_create_context(sandbox_xserver_t)
+
+auth_use_nsswitch(sandbox_xserv

Bug#667664: a fix for this

[Russell Coker]

Bug #667664 is due to the latest versions of the libpcre3 library setting 
reg.re_nsub to an extremely large value and dansguardian trying to allocate 
memory for that many records and having malloc fail.

I've attached a patch for dansguardian which fixes this.  I'll upload a 
delayed NMU tomorrow if there is no response.

I am not certain that libpcre3 is doing the right thing here, but I am certain 
that dansguardian is doing the wrong thing in trying to blindly allocate more 
than 2^50 bytes of RAM.  I've made it allocate no more than 1024 records for 
sub regexes as I find it difficult to imagine anyone needing more than that.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/


dif
Description: application/shellscript

Bug#677759: ok

[Russell Coker]

Fair point Laurent.

As this is a corner case I'll change the mcstransd code to map the line in 
question to something it's happy with.



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

Bug#672695: wordpress: no sane way for security updates in stable releases

[Russell Coker]

On Sun, 13 May 2012, Bernd Zeimetz  wrote:
> Being forced to upgrade to a new major version by a stable security support
> is nothing we should force our users to. Debian stable is known for
> (usually) painfree updates and bugfixes only, not for shipping completely
> new versions with a forced migration. Therefore - in my opinion - we
> should not ship wordpress in Wheezy, at least not until upstream handles
> such issues in a sane way.

Forcing users to manually install and update it or to use a package from 
outside Debian are also options that aren't good for users.

deb http://www.coker.com.au squeeze wordpress

I run my own repository of Wordpress packages at the above APT source.  That 
includes some Wordpress plugins that are licensed suitably for Debian but 
which have the same update issue.

One thing about Wordpress and it's plugins and themes is that you have to 
assume that every new release fixes some security issues.  They just don't 
document things well enough to allow you to assume otherwise.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/



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

Bug#642736: already fixed

[Russell Coker]

close 642736 2:2.20110726-1
thanks

The Squeeze policy is never going to build in Wheezy.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/



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

Bug#626720: policy changes

[Russell Coker]

Martin, using the SE Linux libraries from Unstable I can't make the 
file_contexts.subs file take affect.

I think that the only way to do this is to just have regular expressions that 
deal with this in the file contexts.  It's a bit ugly and slows the relabel 
process down a little (probably no more than about 10%) but it will work.

http://etbe.coker.com.au/2011/07/22/run-se-linux-policy/

I've written the above blog post to summarise my current thoughts on this 
issue.  As the policy package has been broken in Unstable for a while I'll 
wait a day or two before uploading a fix.  I've already got a fixed package 
prepared and it just needs some testing before upload.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/



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

Bug#626720: support in squeeze

[Russell Coker]

What I want to do is to have a policy in squeeze that supports running wheezy 
in a basic configuration.  If a daemon that is in wheezy gets a new feature 
and breaks then I'm not too bothered (I am not aiming for full compatibility).  
But I want to have the basics work for everyone (which includes /run) and have 
most daemons work.

Now for unstable I can have the new selinux-policy-default which works with 
/run depend on the new libselinux1 and everything will be fine.

For a transition from squeeze to wheezy I guess I could patch selinux-policy-
default to support /run but not have it depend on a new libselinux1 so that an 
upgrade from squeeze to wheezy will get the new libselinux1 and then start 
working.

This seems to imply that any package which breaks selinux-policy-default 
should also break libselinux1 to force an upgrade.  Also it means that the 
version of selinux-policy-default should be upgraded in the next squeeze 
update to not be broken.

Does this seem correct?  If so would it be achievable with the release 
process?

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/



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

Bug#626720: sorry for being slack

[Russell Coker]

I'm working on this now.

http://userspace.selinuxproject.org/trac/browser/libselinux/src?order=date&desc=1
http://userspace.selinuxproject.org/trac/wiki/Releases

Firstly please tell me what libraries you used when testing this patch?  It 
seems that the necessary patch to libselinux was first proposed in April but 
there hasn't been a new upstream release since.

Did you test this with a patched libselinux or did you just copy code from 
elsewhere without testing?  NB I'm not criticising you, I don't expect you to 
be doing tests on these things, I just need to know where things are at.

Currently I have to decide whether to maintain my own patch for libselinux1 
for this or to wait for a new official release.  I've just sent a message to 
the list asking what's going on, this sort of message could prompt a new 
upstream release in the very near future (or they could just be really busy - 
no guarantees there).

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/



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

Bug#626720: SELinux refpolicy, initscripts and /run

[Russell Coker]

Looks fine to me if the breaks line does what the changelog says it does.
-- 
My bloghttp://etbe.coker.com.au
Sent from an Xperia X10 Android phone



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

Bug#626720: SELinux refpolicy, initscripts and /run

[Russell Coker]

Sorry for the delay. Yes please make it break the old version of policy. I hope 
to upload a fix on Sunday.
-- 
My bloghttp://etbe.coker.com.au
Sent from an Xperia X10 Android phone



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

Bug#584782: selinux-policy-default: /dev filesystem not labelled

[Russell Coker]

On Fri, 14 Jan 2011, Julien Cristau  wrote:
> Thanks.  I've unblocked refpolicy and selinux-basics, they should get in
> over the weekend.

I've just uploaded selinux-basics version 0.3.8.  The diff is below.  The 
change is that if dkim.pp is loaded then milter.pp (the new dependency of 
dkim.pp for Squeeze) will be loaded.  It would be good if we could get this in 
for Squeeze.

Also Manoj, we will have to change how this works for Squeeze+1.  I think that 
we probably need selinux-policy-upgrade to call a script that is provided by 
the policy that is installed (currently just selinux-policy-default and 
selinux-policy-mls).

diff -ru selinux-basics-0.3.7/selinux-policy-upgrade selinux-
basics-0.3.8/selinux-policy-upgrade
--- selinux-basics-0.3.7/selinux-policy-upgrade 2011-01-07 09:35:07.0 
+1100
+++ selinux-basics-0.3.8/selinux-policy-upgrade 2011-01-23 14:52:04.512740762 
+1100
@@ -20,4 +20,6 @@
   if [ -e $n.pp ]; then
 echo -n " -i $n.pp"
   fi
-done)
+done
+semodule -l|grep -q dkim && echo -n " -i milter.pp"
+)

-- 
russ...@coker.com.au
http://etbe.coker.com.au/  My Main Blog
http://doc.coker.com.au/   My Documents Blog



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

Bug#584782: selinux-policy-default: /dev filesystem not labelled

[Russell Coker]

http://etbe.coker.com.au/2010/04/21/upgrading-se-linux-system-squeez/

At the above URL I have documented what you need to do to upgrade a SE Linux 
system to Squeeze.

Manoj, is it possible to get a Lenny update for the policy?  If not then we 
just have to close this bug.

-- 
russ...@coker.com.au
http://etbe.coker.com.au/  My Main Blog
http://doc.coker.com.au/   My Documents Blog



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

Bug#560633: my workaround

[Russell Coker]

I ran "cp /usr/share/libtool/config/ltmain.sh ." before building the package 
and it worked well.  I don't know whether putting this command in the 
debian/rules would be the right thing to do.

I'm not suggesting that the maintainer do this, merely noting it for other 
people like me who want to work on other aspects of the package without 
having to deal with this issue.

As an aside I back-ported it to Lenny because useradd from the Lenny version 
gives the wrong context to user's home directories.



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

Bug#532740: libdkim0d: Should use strtok_r() not strtok() for thread safety

[Russell Coker]

Package: libdkim0d
Version: 1:1.0.19-3
Severity: grave
Tags: security
Justification: user security hole


The following patch makes libdkim use strtok_r() instead of strtok() for thread
safety.

If a server process has multiple threads operating on behalf of different users
while verifying dkim data (IE receiving mail for multiple users) then data may
be leaked.  Also this may cause a server process to crash and there is a
possibility of it being an exploitable bug.

I don't think that the security concerns are great enough to make a secret
report for a coordinated release, but I do think that they are great enough
to justify a grave bug report.

diff -ru libdkim-1.0.19/src/dkimverify.cpp libdkim-1.0.19-new/src/dkimverify.cpp
--- libdkim-1.0.19/src/dkimverify.cpp   2008-05-12 20:08:06.0 +1000
+++ libdkim-1.0.19-new/src/dkimverify.cpp   2009-06-11 18:28:10.0 
+1000
@@ -855,6 +855,9 @@
 

 int CDKIMVerify::ParseDKIMSignature( const string& sHeader, SignatureInfo &sig 
)
 {
+   // for strtok_r()
+   char *saveptr;
+
// save header for later
sig.Header = sHeader;
 
@@ -1032,7 +1035,7 @@
{
// make sure "dns" is in the list
bool HasDNS = false;
-   char *s = strtok(values[9], ":");
+   char *s = strtok_r(values[9], ":", &saveptr);
while (s != NULL)
{
if (strncmp(s, "dns", 3) == 0 && (s[3] == '\0' || s[3] 
== '/'))
@@ -1040,7 +1043,7 @@
HasDNS = true;
break;
}
-   s = strtok(NULL, ": \t");
+   s = strtok_r(NULL, ": \t", &saveptr);
}
if (!HasDNS)
return DKIM_BAD_SYNTAX; // todo: maybe create a 
new error code for unknown query method
@@ -1080,7 +1083,7 @@
// parse the signed headers list
bool HasFrom = false, HasSubject = false;
RemoveSWSP(values[4]);  // header names shouldn't have 
spaces in them so this should be ok...
-   char *s = strtok(values[4], ":");
+   char *s = strtok_r(values[4], ":", &saveptr);
while (s != NULL)
{
if (_stricmp(s, "From") == 0)
@@ -1090,7 +1093,7 @@
 
sig.SignedHeaders.push_back(s);
 
-   s = strtok(NULL, ":");
+   s = strtok_r(NULL, ":", &saveptr);
}
 
if (!HasFrom)
@@ -1194,6 +1197,9 @@
 

 int SelectorInfo::Parse( char* Buffer )
 {
+   // for strtok_r()
+   char *saveptr;
+
static const char *tags[] = {"v","g","h","k","p","s","t","n",NULL};
char *values[sizeof(tags)/sizeof(tags[0])] = {NULL};
 
@@ -1235,14 +1241,14 @@
else
{
// MUST include "sha1" or "sha256"
-   char *s = strtok(values[2], ":");
+   char *s = strtok_r(values[2], ":", &saveptr);
while (s != NULL)
{
if (strcmp(s, "sha1") == 0)
AllowSHA1 = true;
else if (strcmp(s, "sha256") == 0)
AllowSHA256 = true;
-   s = strtok(NULL, ":");
+   s = strtok_r(NULL, ":", &saveptr);
}
if ( !(AllowSHA1 || AllowSHA256) )
return DKIM_SELECTOR_INVALID;   // todo: maybe create a 
new error code for unsupported hash algorithm
@@ -1261,7 +1267,7 @@
{
// make sure "*" or "email" is in the list
bool ServiceTypeMatch = false;
-   char *s = strtok(values[5], ":");
+   char *s = strtok_r(values[5], ":", &saveptr);
while (s != NULL)
{
if (strcmp(s, "*") == 0 || strcmp(s, "email") == 0)
@@ -1269,7 +1275,7 @@
ServiceTypeMatch = true;
break;
}
-   s = strtok(NULL, ":");
+   s = strtok_r(NULL, ":", &saveptr);
}
if (!ServiceTypeMatch)
return DKIM_SELECTOR_INVALID;
@@ -1278,7 +1284,7 @@
// flags
if (values[6] != NULL)
{
-   char *s = strtok(values[6], ":");
+   char *s = strtok_r(values[6], ":", &saveptr);
while (s != NULL)
{
if (strcmp(s, "y") == 0)
@@ -1289,7 +1295,7 @@
{
SameDomain = true;
}
-   s = strtok(NULL, ":");
+   s = strtok_r(NULL, ":", &saveptr);
}
  

Bug#520724: snmpd: fails to set the group (gid), this will be a security problem in some configurations

[Russell Coker]

Package: snmpd
Version: 5.4.1~dfsg-12
Severity: grave
Tags: security
Justification: user security hole


The following output of "ps" shows that the group is "root":

ps -eo pid,user,euser,suser,fuser,group,egroup,sgroup,fgroup,comm|head -1 ; ps 
-eo pid,user,euser,suser,fuser,group,egroup,sgroup,fgroup,comm|grep snmp
  PID USER EUSERSUSERFUSERGROUPEGROUP   SGROUP   FGROUP   
COMMAND
 4503 snmp snmp snmp snmp root root root root 
snmpd

This means that it can write to /dev/mapper/control, /dev/kmsg, and
/dev/xen/evtchn, as well as probably some files and directories that are
created by the sysadmin.  If for example the /root directory had more 0770
then this would permit the snmpd to take over the root account.

While it would require that the snmpd be compromised to take advantage of this,
I believe that it's a security flaw to run code with GID 0 when there is no
need for it.



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

Bug#498965: further testing

[Russell Coker]

Further testing reveals that policy version 2:0.0.20080702-6 doesn't work 
correctly in this regard either.  However with 2:0.0.20080702-6 the problem 
is less immediately apparent, it doesn't prevent restarting the daemon but 
instead will in some situations prevent correct communication.



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

Bug#468417: sorry

[Russell Coker]

severity 468417 important
thanks

I just realised that the order of the checks seems to make it impossible to 
exploit this (if run as non-root it exits with insufficient privs).



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

Bug#498965: Unable to reproduce

[Russell Coker]

I can't reproduce this.

Do you have the dbus module loaded?  Run "semodule -l|grep dbus".

What AVC messages do you get when you fail to start hal?




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

Bug#499584: cron: Inadequate security checks in SE Linux code path

[Russell Coker]

Package: cron
Version: 3.0pl1-104
Severity: grave

When in enforcing mode it would be a serious security hole if a cron job
was launched without setting the security context - this would be
exactly analogous to forgetting to call setgid() and setuid() before
launching a cron job.

The current version has code in do_command.c to skip the check if for
some reason the security context is not set.

One way that this might happen is if cron is started while the machine
is in permissive mode and the machine is set to enforcing mode while
cron is running.  Of course fixing this issue with cron won't address
the issue of a cron job that is already running.

Also there's the issue of code bugs.  It would be good if a bug in one
section of code which results in a field not being filled in would not
result in inappropriate privileges being granted in another section.

The following patch fixes this.

diff -ru /tmp/cron-3.0pl1.orig/do_command.c ./do_command.c
--- /tmp/cron-3.0pl1.orig/do_command.c  2008-09-19 22:59:45.0 +1000
+++ ./do_command.c  2008-09-20 14:51:21.0 +1000
@@ -331,13 +331,20 @@
fprintf(stdout,"error");
 #endif
 #ifdef WITH_SELINUX
-   if ((is_selinux_enabled() > 0) && (u->scontext != 0L)) {
-if (setexeccon(u->scontext) < 0) {
-if (security_getenforce() > 0) {
-fprintf(stderr, "Could not set exec 
context to %s for user  %s\n", u->scontext,u->name);
-_exit(ERROR_EXIT);
-}
+   if (is_selinux_enabled() > 0) {
+   if (u->scontext != 0L) {
+if (setexeccon(u->scontext) < 0) {
+if (security_getenforce() > 0) {
+fprintf(stderr, "Could not set exec 
context to %s for user  %s\n", u->scontext,u->name);
+_exit(ERROR_EXIT);
+}
+   }
 }
+   else if(security_getenforce() > 0)
+   {
+fprintf(stderr, "Error, must have a security 
context for the cron job when in enforcing mode.\nUser %s.\n", u->name);
+_exit(ERROR_EXIT);
+   }
}
 #endif
 execle(shell, shell, "-c", e->cmd, (char *)0, jobenv);



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

Bug#498333: setools: Does not support the policy in Lenny

[Russell Coker]

Package: setools
Version: 2.4-3
Severity: grave
Justification: renders package unusable

apol in setools does not read the policy in Lenny (version 23).  I
expect that most of the other utilities also fail to operate correctly
in Lenny.

This is a grave bug and the package needs to be updated to setools 3.3.5
for Lenny as currently the main part of it's functionality will only
work on Etch.

If the new version happens to have some bug (which is possible as it's a
few major versions newer), that is not a big deal, as anything is better
than the zero functionality we currently get from apol.



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

Bug#465733: xfs_check in unstable is also broken

[Russell Coker]

http://www.coker.com.au/bug/xfsdump.gz

xfsprogs 2.9.6-1 also has an xfs_check that gives a SEGV.  The above URL has 
the meta-data dump.

At least xfs_repair does it's job in 2.9.6-1, after a repair xfs_check works.



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

Bug#465733: can't fix it

[Russell Coker]

xfs_repair will do some good.  After running xfs_repair the xfs_check script 
will no longer trigger a SEGV of xfs_db.

But xfs_repair will never get the filesystem to a state whereby xfs_check 
finds no errors.  I've run xfs_repair many times and xfs_check always gives 
the following error afterwards:

link count mismatch for inode 37806328 (name ?), nlink 7, counted 6

Also no matter how many times I run it xfs_repair gives me a heap 
of "disconnected inode 62936029, moving to lost+found" messages (with the 
same inode numbers as far as I can tell from a quick visual scan).

I'll give the entire image to people in SGI Melbourne, next week probably.



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

Bug#465733: xfsprogs: xfs_check SEGV

[Russell Coker]

On Friday 15 February 2008 09:16, Nathan Scott <[EMAIL PROTECTED]> wrote:
> On Thu, 2008-02-14 at 22:42 +1100, Russell Coker wrote:
> > Package: xfsprogs
> > Version: 2.8.11-1
> > Severity: critical
> > Justification: breaks the whole system
>
> Heh, er, just a tad extreme?  (its not clear how an xfs_check SEGV
> can "break the whole system"...?)

Not extreme IMHO.  I have a system that IS broken because of XFS corruption 
which xfs_check can't handle due to this SEGV.

> Could you run xfs_metadump(8) on the device, put it somewhere that it
> can be downloaded, and send this mail to [EMAIL PROTECTED] (I can do that
> for you if you prefer the Debian bug tracking system), and someone will
> take a look at it from SGI.

OK.

Also I could just drop by the Melbourne office and deliver an IDE disk if that 
helps.



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

Bug#465733: xfsprogs: xfs_check SEGV

[Russell Coker]

Package: xfsprogs
Version: 2.8.11-1
Severity: critical
Justification: breaks the whole system

I have a filesystem which causes a SEGV when I try to check it.

The problem started when I unexpectedly powered the machine down causing some
data loss.  When I booted it up again the kernel gave errors about corrupted
data structures (which I unfortunately didn't make a note of).  Now when I
try to check it (on another machine) it gives the following.

NB The filesystem has no secret data, I would be happy to give you a copy, I
could put it on a machine on the net that you can access or give you an IDE
disk with a copy if you are in Melbourne.

# xfs_check /dev/sda5
agi unlinked bucket 59 is 891 in ag 2 (inode=8389499)
agi unlinked bucket 6 is 134 in ag 3 (inode=12583046)
agi unlinked bucket 18 is 338 in ag 3 (inode=12583250)
agi unlinked bucket 51 is 179 in ag 3 (inode=12583091)
agi unlinked bucket 8 is 136 in ag 5 (inode=20971656)
agi unlinked bucket 10 is 138 in ag 5 (inode=20971658)
agi unlinked bucket 11 is 139 in ag 5 (inode=20971659)
agi unlinked bucket 14 is 142 in ag 5 (inode=20971662)
agi unlinked bucket 15 is 143 in ag 5 (inode=20971663)
agi unlinked bucket 16 is 144 in ag 5 (inode=20971664)
agi unlinked bucket 17 is 145 in ag 5 (inode=20971665)
agi unlinked bucket 19 is 147 in ag 5 (inode=20971667)
agi unlinked bucket 23 is 151 in ag 5 (inode=20971671)
agi unlinked bucket 27 is 155 in ag 5 (inode=20971675)
can't seek in filesystem at bb 20002504712
can't read btree block 16384/1
extent count for ino 50332175 data fork too low (0) for file format
bad nblocks 12 for inode 50332175, counted 1
bad nextents 9 for inode 50332175, counted 0
no . entry for directory 50332175
no .. entry for directory 50332175
/usr/sbin/xfs_check: line 28:  9686 Segmentation fault  xfs_db$DBOPTS -i -p 
xfs_check -c "check$OPTS" $1


-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-5-686
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C)

Versions of packages xfsprogs depends on:
ii  lib 2.3.6.ds1-13etch4GNU C Library: Shared libraries
ii  lib 5.2-2GNU readline and history libraries
ii  lib 1.39+1.40-WIP-2006.11.14+dfsg-2etch1 universally unique id library

xfsprogs recommends no packages.

-- no debconf information



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

Bug#418672: 5.0.32-7etch1 has this bug

[Russell Coker]

On Thursday 26 April 2007 02:31, sean finney <[EMAIL PROTECTED]> wrote:
> > Empty passwords by default might be OK for a source based install of
> > MySQL, but they are not OK for a Debian install.  Debian packages should
> > be expected to be secure by default!
>
> i think it's fairly common knowledge that this is to be expected when
> installing mysql, as you will find this to be the case for every other
> distribution of unix/linux that includes mysql.

If it was common knowledge then surely I would have known it years ago!

The big advantage of MySQL over all other options is the low level of skill 
needed to administer it.  Oracle requires a dedicated DBA with a six figure 
salary.  PostgreSQL requires a good sys-admin who has experience and knows 
SQL.  MySQL generally works for anyone who wants to turn it on.

> however, in principle i agree with you--hence we went out of our way to
> do the password prompt stuff in the first place.  perhaps we should
> consider raising the priority of the question (currently i believe it's
> medium, which is why you didn't see it maybe?).

I believe that if there is an option to run a system with no administrative 
password then the question about it should be at the highest priority, or the 
password should be set to a random value (from /dev/random) by default.



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

Bug#418672: 5.0.32-7etch1 has this bug

[Russell Coker]

On Wednesday 25 April 2007 16:36, sean finney <[EMAIL PROTECTED]> wrote:
> On Wed, 2007-04-25 at 13:22 +1100, Russell Coker wrote:
> > I just did a fresh install of mysql-server-5.0 on an AMD64 system which
> > had never been used to run any version of MySQL before.  It has root
> > accounts with no passwords.
>
> i believe the bug in question was about an existing installation with a
> password being upgraded in such a way that root could log in afterwards
> without a password.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=418955

My above bug report was closed as a duplicate of this.

> empty passwords are actually the *default* with mysql databases, though
> in debian we've value-added some debconf-based password setting.  still,
> if you don't see the questions or othewrise decline these questions the
> default remains.

Empty passwords by default might be OK for a source based install of MySQL, 
but they are not OK for a Debian install.  Debian packages should be expected 
to be secure by default!

The fact that I was asked no questions on several installs of MySQL in both 
Etch and Unstable is a bug in the MySQL packages.  Should I continue the 
issue here or re-open my other bug report?



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

Bug#418672: 5.0.32-7etch1 has this bug

[Russell Coker]

I just did a fresh install of mysql-server-5.0 on an AMD64 system which had 
never been used to run any version of MySQL before.  It has root accounts 
with no passwords.


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

Bug#390648: FTBFS: will not create hard link

[Russell Coker]

On Monday 02 October 2006 23:06, "Steinar H. Gunderson" 
<[EMAIL PROTECTED]> wrote:
> Shouldn't a bug be filed against ftp.debian.org asking for its removal,
> then?

Yes, but let's get the replacement finished first.


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

Bug#390648: FTBFS: will not create hard link

[Russell Coker]

> Is this package even useful anymore? I hear rumours that it's being
> obsoleted...

Correct.  Please file no more bugs against it as it will either totally 
disappear or be replaced by a package with almost no code in common with it.


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

Bug#320351: Bug#243941: How to help with neglected packages

[Russell Coker]

On Friday 20 January 2006 11:44, Amaya <[EMAIL PROTECTED]> wrote:
> Russell Coker wrote:
> > I don't have the time that this package needs (as is probably
> > obvious).  I welcome a package takeover by someone such as Amaya.
>
> Hi there, Russell. While I am not interested in maintanining it, I will
> be happy to mentor Marcus, and be his sponsor too. If this is fine with
> you, and as no one else seems to be interested, we will start working on
> it, before it gets removed.

That's fine.


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

Bug#320351: Bug#243941: How to help with neglected packages

[Russell Coker]

On Friday 20 January 2006 01:17, Amaya <[EMAIL PROTECTED]> wrote:
> Marcus Better wrote:
> > I am not a DD. Should I ask someone to do an NMU on these packages?
>
> I have not yet carefully looked at your patches, but I would be happy to
> do so, and upload and so on... But finding a long term Maintainer would
> be much better. Would you be willing invest the time and effort to
> become responsible for this package?

I don't have the time that this package needs (as is probably obvious).  I 
welcome a package takeover by someone such as Amaya.



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

Bug#301600: Can't login at 2.6.12-rc1

[Russell Coker]

On Sunday 27 March 2005 12:03, Kyuma Ohta <[EMAIL PROTECTED]> wrote:
> I'm using selinux for debian .
> At kernel 2.6.11.*,kernel accepts to execute programs,
> boot up is okay.
> But, kernel 2.6.12-rc1, after loading policy,all programs
>  can't start excepts sysvinit (and bash?),can't login.
> I checked LKML,I couldn't find this issue.
> Please check policy, and programs for SELinux.

What AVC messages do you get?  Are you using the SE Linux patched version of 
the PAM packages?


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