Bug#982894:
I have seen exactly the same problem (on AWS EC2 too), so I'm definitely interested in a fix for this. Leaving /etc/resolv.conf unmodified if the disk is full seems perfect as a fix!
Bug#951255: redis-server: TLS not configured in build, some configuration options do not work by default without it
Package: redis-server
Version: 5:6.0~rc1-1
Severity: normal
Dear Maintainer,
So one of the big new features in Redis 6.x is native TLS support, which I'm
pretty excited about! I tried it out with the version of this package in
experimental, and it worked but did need a couple tweaks to the package build
to enable TLS within the build (given in the patch at the bottom).
This was the error previously when the option is specified in the config file
but isn't actually allowed since it isn't compiled with TLS support
(https://github.com/antirez/redis/blob/6.0-rc1/src/config.c#L2259-L2273):
Feb 13 01:53:45 hostname systemd[1]: Starting Advanced key-value store...
Feb 13 01:53:45 hostname redis-server[15510]: *** FATAL CONFIG FILE ERROR ***
Feb 13 01:53:45 hostname redis-server[15510]: Reading the
configuration file, at line 1375
Feb 13 01:53:45 hostname redis-server[15510]: >>> 'tls-port 6378'
Feb 13 01:53:45 hostname redis-server[15510]: Bad directive or wrong
number of arguments
Feb 13 01:53:45 hostname systemd[1]: redis-server.service: Control
process exited, code=exited, status=1/FAILURE
Feb 13 01:53:45 hostname systemd[1]: redis-server.service: Failed with
result 'exit-code'.
Feb 13 01:53:45 hostname systemd[1]: Failed to start Advanced key-value store.
The only config modification I did was to add "tls-port 6378" at the bottom of
/etc/redis/redis.conf, to get redis to fully work I did need to add more
options like tls-cert-file and tls-key-file, but just adding the port was
enough to reproduce the issue.
This is my patch to debian/rules to build with TLS support (adding the variable
to just override_dh_auto_build didn't actually add it properly, my guess is
that it's needed in multiple different targets). I also needed to add
libssl-dev as a build dependency and added the --tls options and tcl-tls as per
the TLS docs (https://github.com/antirez/redis/blob/6.0/TLS.md). I've
also tested this manually by doing a build, making sure all the tests
that are run there pass, and installing redis on a host and setting up
some basic TLS configuration. I did get a few errors within the tests,
but they don't all appear to be related (the TLS ones likely are though):
!!! WARNING The following tests failed:
*** [err]: Active defrag in tests/unit/memefficiency.tcl
defrag not started.
*** [err]: Active defrag big keys in tests/unit/memefficiency.tcl
defrag not started.
*** [err]: TLS: Verify tls-protocols behaves as expected in tests/unit/tls.tcl
Expected 'I/O error reading reply' to match 'PONG' (context: type eval
line 10 cmd {assert_match {PONG} $e} proc ::test)
Here's my patch:
diff --git a/debian/control b/debian/control
index a83d91e..6eff968 100644
--- a/debian/control
+++ b/debian/control
@@ -8,10 +8,12 @@ Build-Depends:
libhiredis-dev (>= 0.14.0),
libjemalloc-dev [linux-any],
liblua5.1-dev,
+ libssl-dev,
lua-bitop-dev,
lua-cjson-dev,
procps ,
tcl ,
+ tcl-tls ,
Standards-Version: 4.4.1
Homepage: https://redis.io/
Vcs-Git: https://salsa.debian.org/lamby/pkg-redis.git
diff --git a/debian/rules b/debian/rules
index 1e7819d..4cbec71 100755
--- a/debian/rules
+++ b/debian/rules
@@ -17,6 +17,7 @@ LUA_LDFLAGS = $(addprefix
-llua5.1-,$(LUA_LIBS_DEBIAN)) $(addprefix ../deps/lua/
export CFLAGS CPPFLAGS LDFLAGS
export DEB_BUILD_MAINT_OPTIONS = hardening=+all
export DEB_LDFLAGS_MAINT_APPEND = -Wl,-no-as-needed -ldl -latomic
$(LUA_LDFLAGS)
+export BUILD_TLS=yes
ifneq (,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
NUMJOBS = $(patsubst parallel=%,%,$(filter
parallel=%,$(DEB_BUILD_OPTIONS)))
@@ -48,9 +49,11 @@ override_dh_auto_build: debian/lua_libs_debian.c
override_dh_auto_test:
ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
- # Avoid race conditions in upstream testsuite.
- ./runtest --clients 1 || true
- ./runtest-cluster || true
+ # Generate a root CA and server certificate for testing
+ ./utils/gen-test-certs.sh
+ # Avoid race conditions in upstream testsuite
+ ./runtest --clients 1 --tls || true
+ ./runtest-cluster --tls || true
./runtest-sentinel || true
endif
Bug#914540: [20181124] mirrors.ocf.berkeley.edu: out of date, ftpsync-version
Hi Peter, Thanks a lot for letting us know we are out of date! We've switched our upstream mirror and are syncing again now. We'll make sure to update our ftpsync version too, it's been on our roadmap for a while now but just hasn't been done yet, so we'll look into that as soon as we can. Cheers, Jason On Sat, Nov 24, 2018 at 7:39 AM Peter Palfrader wrote: > Package: mirrors > User: mirr...@packages.debian.org > Usertags: mirror-problems > > Hi! > > It seems http://mirrors.ocf.berkeley.edu/debian/ > is out of date > > https://mirror-master.debian.org/status/mirror-info/mirrors.ocf.berkeley.edu.html > > Please investigate. > > o If you sync off kernel.org, you might want to pick a different site > (do not use ftp.*.debian.org names, only http is guaranteed at >those names and they do switch around.) > https://mirror-master.debian.org/status/mirror-hierarchy.html might help > you pick. > > o Also, maybe update your ftpsync version. > http://ftp.debian.org/debian/project/ftpsync/ftpsync-current.tar.gz > > Cheers, > -- > | .''`. ** Debian ** > Peter Palfrader | : :' : The universal > https://www.palfrader.org/ | `. `' Operating System > | `-https://www.debian.org/ >
Bug#900612: apache2-suexec-pristine: Packaging steps undo setting of setuid bit
Hi Stefan, You're absolutely right, I was building the package as root inside a docker container, mostly as a one-off kind of build to add some debugging information. I tried using fakeroot instead, and it masked the problem as you mentioned, as the file at the end still has the setuid bit, even though it has changed group (and the same happens if the owner is changed): jvperrin@fireball:~$ fakeroot /bin/bash root@fireball:~# touch test.txt root@fireball:~# ls -l test.txt -rw-r--r-- 1 root root 0 Jun 2 13:08 test.txt root@fireball:~# chmod 4754 test.txt root@fireball:~# ls -l test.txt -rwsr-xr-- 1 root root 0 Jun 2 13:08 test.txt* root@fireball:~# chgrp nogroup test.txt root@fireball:~# ls -l test.txt -rwsr-xr-- 1 root nogroup 0 Jun 2 13:08 test.txt* If I do the same without fakeroot, it loses the setuid bit (as it should): jvperrin@fireball:~$ sudo -i root@fireball:~# touch test.txt root@fireball:~# ls -l test.txt -rw-r--r-- 1 root root 0 Jun 2 13:11 test.txt root@fireball:~# chmod 4754 test.txt root@fireball:~# ls -l test.txt -rwsr-xr-- 1 root root 0 Jun 2 13:11 test.txt* root@fireball:~# chgrp nogroup test.txt root@fireball:~# ls -l test.txt -rwxr-xr-- 1 root nogroup 0 Jun 2 13:11 test.txt* This suggests to me that this is indeed a problem with fakeroot, not with this package, although I do still think the patch I included on this bug report could be helpful as it wouldn't change the behavior when it fakeroot and fixes the issue if anyone else is building manually outside of fakeroot. Looking at fakeroot's bug reports, it's already been reported almost a decade ago (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497109). It hasn't had any activity since then, so that's unfortunate, I'll try and follow up there. Thank you for your help, that was very useful! On Sat, Jun 2, 2018 at 1:35 AM Stefan Fritsch wrote: > > On Saturday, 2 June 2018 02:06:10 CEST Jason Perrin wrote: > > > This appears to be a problem in the source for this package, on the master > > branch, as well as on separate branches for different distros: > > https://salsa.debian.org/apache-team/apache2/blob/master/debian/rules#L148-1 > > 53 I'm not sure how this has worked properly to produce packages, since the > > last change to that section was 6 years ago, so I'm a bit confused on that > > point. > > > That's weird because it seems all distributed packages in the last 6 years > have the correct permissions. Do you build the package as root? Usually > packages are built as non-root user using fakeroot. Maybe fakeroot is not > being faithful to the real kernel behavior and hides the bug. > > Cheers, > Stefan > > >
Bug#900612: apache2-suexec-pristine: Packaging steps undo setting of setuid bit
Package: apache2-suexec-pristine Version: 2.4.25-3+deb9u4 Severity: normal Tags: patch Justification: fails to build from source (but built successfully in the past) Dear Maintainer, When building the apache2-suexec-pristine (and apache2-suexec-custom) packages from source, I expected the built .deb packages to contain setuid binaries (at /usr/lib/apache2/suexec-pristine and /usr/lib/apache2/suexec-custom respectively). However, when packaging was done, the packages contained binaries with the permissions 0754, not 4754, as set in the debian/rules file. Looking into this more, it appears that chgrp (through the chown system call) clears the setuid bit (and all bits in the first octet of permissions) when it is run, so the steps in override_dh_fixperms-arch end up removing the setuid bit when chgrp is run after chmod. This appears to be a problem in the source for this package, on the master branch, as well as on separate branches for different distros: https://salsa.debian.org/apache-team/apache2/blob/master/debian/rules#L148-153 I'm not sure how this has worked properly to produce packages, since the last change to that section was 6 years ago, so I'm a bit confused on that point. Here is a patch to fix the setting of the setuid bit in both packages by just moving the chmod to after chgrp has already run: --- debian/rules +++ debian/rules @@ -146,11 +146,11 @@ override_dh_install: clean-config-vars-stamp \ override_dh_fixperms-arch: # standard suexec - chmod 4754 debian/apache2-suexec-pristine/usr/lib/apache2/suexec-pristine chgrp www-data debian/apache2-suexec-pristine/usr/lib/apache2/suexec-pristine + chmod 4754 debian/apache2-suexec-pristine/usr/lib/apache2/suexec-pristine # configurable suexec - chmod 4754 debian/apache2-suexec-custom/usr/lib/apache2/suexec-custom chgrp www-data debian/apache2-suexec-custom/usr/lib/apache2/suexec-custom + chmod 4754 debian/apache2-suexec-custom/usr/lib/apache2/suexec-custom dh_fixperms -a -Xusr/lib/apache2/suexec-custom -Xusr/lib/apache2/suexec-pristine chown -R www-data:www-data debian/apache2/var/cache/apache2/mod_cache_disk chown root:adm debian/apache2/var/log/apache2 -- System Information: Debian Release: 9.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-6-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#838752: mirror listing update for mirrors.ocf.berkeley.edu
Package: mirrors Severity: minor User: mirr...@packages.debian.org Usertags: mirror-list Submission-Type: update Site: mirrors.ocf.berkeley.edu Type: leaf Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x Archive-ftp: /debian/ Archive-http: /debian/ Archive-rsync: debian/ CDImage-ftp: /debian-cd/ CDImage-http: /debian-cd/ CDImage-rsync: debian-cd/ IPv6: yes Archive-upstream: mirrors.kernel.org CDImage-upstream: mirrors.kernel.org Updates: four Maintainer: Jason Perrin Country: US United States Location: Berkeley, CA Sponsor: Open Computing Facility https://www.ocf.berkeley.edu Comment: Hi, Could you update our listing (mirrors.ocf.berkeley.edu) to include all architectures? Currently we are missing a few that we support: arm64 mips64el ppc64el s390 Also, could you please add us back to the httpredir list? We seem to have been dropped from the list according to http://httpredir.debian.org/report.txt, but we successfully perform a two-step sync and our trace (http://mirrors.ocf.berkeley.edu/debian/project/trace/mirrors.ocf.berkeley.edu) says we are up to date. Thanks as always! Jason
Bug#638699: [Pkg-xfce-devel] Bug#638699: exo-open fails to open a filename with a hash (#)
This has been fixed in release 0.10.7-1 (available in stretch). The core issue here was that exo-open did not properly escape filenames before sending them to gobject/glib, so files with a number sign (#) in their name would get cut off, due to glib removing what it saw as a URI fragment. This was reported in https://bugzilla.xfce.org/show_bug.cgi?id=9912 and fixed with http://git.xfce.org/xfce/exo/commit/?id=6faf134307a8f651c09931ae4f7017ce141f6320, so this issue should be resolved. On Sun, 21 Aug 2011 10:13:50 +0200 Mathias Brodala wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi. > > Baruch Even, 21.08.2011 09:40: > > Package: exo-utils > > This should be blamed on gobject/glib. > > > Trying to open a doc file that is named: /tmp/a#.doc with the command: > > exo-open /tmp/a#.doc > > This fails with the message: > > Failed to open URI "file:///tmp/a#.doc". > > Error stating file '/tmp/a': No such file or directory. > > Most likely related to this one: > > https://bugzilla.gnome.org/show_bug.cgi?id=655194 > (gio.File ignores uri fragments on file:// URIs) > > There’s nothing exo can do here except wait for gobject/glib to fix this > issue. > > > Regards, Mathias > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk5QvjYACgkQYfUFJ3ewsJgOGACfQJ+pzHOMUtbQrkobemF9Nv6K > gCoAoJ61V30cNWYyS4OO9ASgHwz1Fgt3 > =sF7F > -END PGP SIGNATURE- > > >
