Bug#1053596: ecryptfs-utils: Please add the walkaround from archlinux wiki to avoid repetitive mount
Package: ecryptfs-utils Version: 111-6 Severity: wishlist Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** To resolve issue like https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=967056 , a walkaround documented on https://wiki.archlinux.org/title/ECryptfs#Auto- mounting could be used, and it could even be applied via a modification to /usr/share/pam-configs/ecryptfs-utils as done in the attached patch. Could this be included? -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (900, 'testing'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-1-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=zh_CN.utf8, LC_CTYPE=zh_CN.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ecryptfs-utils depends on: ii gettext-base 0.21-13+b1 ii keyutils 1.6.3-2 ii libc6 2.37-12 ii libecryptfs1 111-6 ii libgpgme11 1.18.0-3+b1 ii libkeyutils1 1.6.3-2 ii libpam-runtime 1.5.2-7 ii libpam0g 1.5.2-7 ii libtspi1 0.3.15-0.3 ecryptfs-utils recommends no packages. Versions of packages ecryptfs-utils suggests: ii cryptsetup 2:2.6.1-5 ii rsync 3.2.7-1 -- debconf-show failed -- debsums errors found: debsums: changed file /usr/share/pam-configs/ecryptfs-utils (from ecryptfs-utils package) --- /usr/share/pam-configs/ecryptfs-utils.orig 2023-10-07 15:15:52.830703449 +0800 +++ /usr/share/pam-configs/ecryptfs-utils 2023-10-07 15:16:43.147178744 +0800 @@ -3,9 +3,11 @@ Default: yes Priority: 0 Auth-Type: Additional Auth-Final: + [success=1 default=ignore] pam_succeed_if.so service = systemd-user quiet requiredpam_ecryptfs.so unwrap Session-Type: Additional Session-Final: + [success=1 default=ignore] pam_succeed_if.so service = systemd-user quiet optionalpam_ecryptfs.so unwrap Password-Type: Additional Password-Final:
Bug#1019426: openssh-client: ssh-agent can leave zombie ssh-pkcs11-help
Confirmed on openssh-client 1:9.4p1-1, ssh-agent seems not going to pick its dead children processes with wait(), no matter how they die. For example, running `ssh-add -s /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so` with a smart card present will make ssh-agent spawn a ssh-pkcs11-helper to handle it, but the child will always become a zombie without being wait(2)ed after it dies, either terminating gracefully after running `ssh-add -e /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so`, or being kill(2)ed.
Bug#1051671: gdm3 no longer respects /etc/gdm3/greeter.dconf-defaults or its dconf settings, especially those for power
Package: gdm3 Version: 45~beta-1 Severity: normal Dear Maintainer, As suggested in https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/22 I have been setting /org/gnome/settings-daemon/plugins/power/sleep-inactive- ac-timeout to 0 for gdm3 to prevent it from suspending the computer when no one is logging in, either from /etc/gdm3/greeter.dconf-defaults, or via `dbus- launch dconf write /org/gnome/settings-daemon/plugins/power/sleep-inactive-ac- timeout 0` running as Debian-gdm, but after gdm3 is upgraded to 45~beta-1, this setting is no longer effective, and I have no idea how to prevent my computer from suspending 20 minutes after the last user logs out. Downgrading gdm3 to 44.1-2 can temporary fix this issue: On gdm3 44.1-2, setting /org/gnome/settings-daemon/plugins/power/sleep-inactive-ac-timeout to 60 from either way can make the computer suspended 1 minute later, but on gdm3 45~beta-1, it will always be suspended 20 minute later, regardless of the setting. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (900, 'testing'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.4.0-4-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=zh_CN.utf8, LC_CTYPE=zh_CN.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gdm3 depends on: ii accountsservice 23.13.9-4 ii adduser 3.137 ii cdebconf [debconf-2.0] 0.270 ii dbus [default-dbus-system-bus] 1.14.10-1 ii dbus-bin 1.14.10-1 ii dbus-daemon 1.14.10-1 ii dconf-cli 0.40.0-4 ii dconf-gsettings-backend 0.40.0-4 ii debconf [debconf-2.0] 1.5.82 ii gir1.2-gdm-1.0 45~beta-1 ii gnome-session [x-session-manager] 44.0-3 ii gnome-session-bin 44.0-3 ii gnome-session-common 44.0-3 ii gnome-session-flashback [x-session-manager] 3.49.1-1 ii gnome-settings-daemon 45~beta-1 ii gnome-shell 44.4-1 ii gnome-terminal [x-terminal-emulator] 3.49.99-1 ii gsettings-desktop-schemas 44.0-2 ii libaccountsservice0 23.13.9-4 ii libaudit1 1:3.1.1-1 ii libc6 2.37-7 ii libcanberra-gtk3-0 0.30-10 ii libcanberra0 0.30-10 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1 ii libgdm1 45~beta-1 ii libglib2.0-0 2.77.3-1 ii libglib2.0-bin 2.77.3-1 ii libgtk-3-0 3.24.38-4 ii libgudev-1.0-0 237-2 ii libkeyutils1 1.6.3-2 ii libpam-modules 1.5.2-7 ii libpam-runtime 1.5.2-7 ii libpam-systemd [logind] 254.1-2 ii libpam0g 1.5.2-7 ii librsvg2-common 2.54.7+dfsg-2 ii libselinux1 3.5-1 ii libsystemd0 254.1-2 ii libx11-6 2:1.8.6-1 ii libxau6 1:1.0.9-1 ii libxcb1 1.15-1 ii libxdmcp6 1:1.1.2-3 ii lxterminal [x-terminal-emulator] 0.4.0-2 ii metacity [x-window-manager] 1:3.49.1-1 ii mlterm [x-terminal-emulator] 3.9.3-1 ii mutter [x-window-manager] 44.4-2 ii polkitd 123-1 ii procps 2:4.0.3-1 ii systemd-sysv 254.1-2 ii tilix [x-terminal-emulator] 1.9.5-2 ii ucf 3.0043+nmu1 ii x11-common 1:7.7+23 ii x11-xserver-utils 7.7+9+b1 ii xterm [x-terminal-emulator] 384-1 Versions of packages gdm3 recommends: ii at-spi2-core 2.49.91-2 ii desktop-base 12.0.6+nmu1 ii gnome-session [x-session-manager] 44.0-3 ii gnome-session-flashback [x-session-manager] 3.49.1-1 ii x11-xkb-utils 7.7+7 ii xserver-xephyr 2:21.1.8-1 ii xserver-xorg 1:7.7+23 ii zenity 3.44.2-1 Versions of packages gdm3 suggests: ii libpam-fprintd 1.94.2-2 ii libpam-gnome-keyring 42.1-1+b2 ii libpam-pkcs11 0.6.12-1 pn libpam-sss ii orca 44.1-2 -- debconf information: gdm3/daemon_name: /usr/sbin/gdm3 * shared/default-x-display-manager: gdm3
Bug#1042517: Fixed in 6.4.13-1
The fix https://patchwork.freedesktop.org/patch/msgid/20230804084600.1005818-1-jani.nik...@intel.com has been merged to upstream and backported to 6.4.13, so it is available in linux-image-6.4.0-4-amd64_6.4.13-1, and I have confirmed that this bug is fixed on this version.
Bug#1042517:
> Control: tags -1 + moreinfo > > Hi > > On Wed, Aug 09, 2023 at 11:26:01AM +0800, Mad Horse wrote: >> The bug has been reported to upstream ( >> https://gitlab.freedesktop.org/drm/intel/-/issues/8991 ), and a fix >> is available there, though it may need backport. > Were you able to confirm that the upstream mentioned patch fixes the > issue? > > Regards, > Salvatore > Yes. After building and installing a linux 6.5~rc4-1~exp1a~test with this patch applied to, the i915 does never shout oops on an IVB D GT2 server any more.
Bug#1042517:
The bug has been reported to upstream ( https://gitlab.freedesktop.org/drm/intel/-/issues/8991 ), and a fix is available there, though it may need backport.
Bug#1042517: Info received (Bug#1042517: Acknowledgement (i915: oops for NULL pointer dereference on Intel HD Graphics P4000))
Further inspection shows that this oops is caused by
intel_display_device_probe() returning NULL in
intel_device_info_driver_create() when Intel HD Graphics P4000
(PCI:8086:016a) is probed, which is further caused by
INTEL_IVB_Q_IDS(NULL) (struct { u32 devid; const struct
intel_display_device_info *info;}{ 0x16a, NULL}) in
drivers/gpu/drm/i915/display/intel_display_device.c being erroneously
matched against Intel HD Graphics P4000.
Bug#1042517: Acknowledgement (i915: oops for NULL pointer dereference on Intel HD Graphics P4000)
The kernel log in the first report seems to be truncated. Here is a full log: [ 0.00] Linux version 6.4.0-1-amd64 (debian-ker...@lists.debian.org) (gcc-13 (Debian 13.1.0-9) 13.1.0, GNU ld (GNU Binutils for Debian) 2.40.90.20230720) #1 SMP PREEMPT_DYNAMIC Debian 6.4.4-1 (2023-07-23) [ 0.00] Command line: root=/dev/mapper/vgs-root ro intel_iommu=on intel_iommu=on [ 0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' [ 0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' [ 0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' [ 0.00] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 [ 0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format. [ 0.00] signal: max sigframe size: 1776 [ 0.00] BIOS-provided physical RAM map: [ 0.00] BIOS-e820: [mem 0x1000-0x0009] usable [ 0.00] BIOS-e820: [mem 0x000a-0x000f] reserved [ 0.00] BIOS-e820: [mem 0x0010-0x7ff0efff] usable [ 0.00] BIOS-e820: [mem 0x8000-0x829f] reserved [ 0.00] BIOS-e820: [mem 0xf000-0xf3ff] reserved [ 0.00] BIOS-e820: [mem 0xfed4-0xfed44fff] reserved [ 0.00] BIOS-e820: [mem 0xfed9-0xfed91fff] reserved [ 0.00] BIOS-e820: [mem 0x0001-0x00047d5f] usable [ 0.00] NX (Execute Disable) protection: active [ 0.00] SMBIOS 3.0 present. [ 0.00] DMI: HP HP Z220 SFF Workstation/HP Z220 SFF Workstation, BIOS 4.19-218-gb184e6e0a1 02/02/2023 [ 0.00] tsc: Fast TSC calibration using PIT [ 0.00] tsc: Detected 3192.575 MHz processor [ 0.10] e820: update [mem 0x-0x0fff] usable ==> reserved [ 0.16] e820: remove [mem 0x000a-0x000f] usable [ 0.24] last_pfn = 0x47d600 max_arch_pfn = 0x4 [ 0.32] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WP UC- WT [ 0.000402] last_pfn = 0x7ff0f max_arch_pfn = 0x4 [ 0.019298] RAMDISK: [mem 0x4760dc000-0x4797f] [ 0.019302] ACPI: Early table checksum verification disabled [ 0.019307] ACPI: RSDP 0x000F 24 (v02 COREv4) [ 0.019314] ACPI: XSDT 0x7FF270E0 5C (v01 COREv4 COREBOOT CORE 20200925) [ 0.019324] ACPI: FACP 0x7FF296E0 000114 (v06 COREv4 COREBOOT CORE 20200925) [ 0.019333] ACPI: DSDT 0x7FF27280 002455 (v02 COREv4 COREBOOT 20141018 INTL 20200925) [ 0.019339] ACPI: FACS 0x7FF27240 40 [ 0.019344] ACPI: FACS 0x7FF27240 40 [ 0.019349] ACPI: SSDT 0x7FF29800 00284A (v02 COREv4 COREBOOT 002A CORE 20200925) [ 0.019355] ACPI: MCFG 0x7FF2C050 3C (v01 COREv4 COREBOOT CORE 20200925) [ 0.019361] ACPI: TCPA 0x7FF2C090 32 (v02 COREv4 COREBOOT CORE 20200925) [ 0.019366] ACPI: APIC 0x7FF2C0D0 7E (v03 COREv4 COREBOOT CORE 20200925) [ 0.019372] ACPI: DMAR 0x7FF2C150 C0 (v01 COREv4 COREBOOT CORE 20200925) [ 0.019377] ACPI: HPET 0x7FF2C210 38 (v01 COREv4 COREBOOT CORE 20200925) [ 0.019382] ACPI: Reserving FACP table memory at [mem 0x7ff296e0-0x7ff297f3] [ 0.019385] ACPI: Reserving DSDT table memory at [mem 0x7ff27280-0x7ff296d4] [ 0.019387] ACPI: Reserving FACS table memory at [mem 0x7ff27240-0x7ff2727f] [ 0.019388] ACPI: Reserving FACS table memory at [mem 0x7ff27240-0x7ff2727f] [ 0.019390] ACPI: Reserving SSDT table memory at [mem 0x7ff29800-0x7ff2c049] [ 0.019392] ACPI: Reserving MCFG table memory at [mem 0x7ff2c050-0x7ff2c08b] [ 0.019393] ACPI: Reserving TCPA table memory at [mem 0x7ff2c090-0x7ff2c0c1] [ 0.019395] ACPI: Reserving APIC table memory at [mem 0x7ff2c0d0-0x7ff2c14d] [ 0.019396] ACPI: Reserving DMAR table memory at [mem 0x7ff2c150-0x7ff2c20f] [ 0.019398] ACPI: Reserving HPET table memory at [mem 0x7ff2c210-0x7ff2c247] [ 0.019484] No NUMA configuration found [ 0.019486] Faking a node at [mem 0x-0x00047d5f] [ 0.019502] NODE_DATA(0) allocated [mem 0x47d5c8000-0x47d5f2fff] [ 0.019979] Zone ranges: [ 0.019981] DMA [mem 0x1000-0x00ff] [ 0.019984] DMA32 [mem 0x0100-0x] [ 0.019987] Normal [mem 0x0001-0x00047d5f] [ 0.019990] Device empty [ 0.019992] Movable zone start for each node [ 0.019997] Early memory node ranges [ 0.019998] node 0: [mem 0x1000-0x0009] [ 0.020001] node 0: [mem 0x0010-0x7ff0efff] [ 0.020003] node 0: [mem 0x0001-0x00047d5f] [ 0.020008] Initmem setup node 0 [mem 0x1000-0x00047d5f] [ 0.020016] On node 0, zone DMA:
Bug#1042517: i915: oops for NULL pointer dereference on Intel HD Graphics P4000
Package: src:linux Version: 6.4.4-1 Severity: important Dear Maintainer, i915 used to work well on my Intel HD Graphics P4000 in an Intel(R) Xeon(R) CPU E3-1225 V2 when running Linux kernel 6.3.0-1 (6.3.7-1) and older, but on 6.4.4-1, it will oops for NULL pointer dereference as the attached kernel log shows. This also hangs the sound card and holds the system from reboot. i915 of linux 6.4.4-1 will neither oops on Intel GMA 4500MHD in GM45, nor on an ordinary Intel HD Graphics 4000 in an Intel(R) Core(TM) i5-3427U CPU. -- Package-specific info: ** Version: Linux version 6.4.0-1-amd64 (debian-ker...@lists.debian.org) (gcc-13 (Debian 13.1.0-9) 13.1.0, GNU ld (GNU Binutils for Debian) 2.40.90.20230720) #1 SMP PREEMPT_DYNAMIC Debian 6.4.4-1 (2023-07-23) ** Command line: root=/dev/mapper/vgs-root ro intel_iommu=on intel_iommu=on ** Tainted: D (128) * kernel died recently, i.e. there was an OOPS or BUG ** Kernel log: [ 8.763418] systemd[1]: Mounting sys-fs-fuse-connections.mount - FUSE Control File System... [ 8.764411] systemd[1]: Mounting sys-kernel-config.mount - Kernel Configuration File System... [ 8.764596] systemd[1]: systemd-firstboot.service - First Boot Wizard was skipped because of an unmet condition check (ConditionFirstBoot=yes). [ 8.764707] systemd[1]: systemd-repart.service - Repartition Root Disk was skipped because no trigger condition checks were met. [ 8.765773] systemd[1]: Starting systemd-sysusers.service - Create System Users... [ 8.765933] ppdev: user-space parallel port driver [ 8.768736] systemd[1]: Mounted sys-fs-fuse-connections.mount - FUSE Control File System. [ 8.768892] parport_pc 00:04: reported by Plug and Play ACPI [ 8.769418] parport0: PC-style at 0x378, irq 7 [PCSPP] [ 8.770159] systemd[1]: Mounted sys-kernel-config.mount - Kernel Configuration File System. [ 8.790829] systemd[1]: Finished lvm2-monitor.service - Monitoring of LVM2 mirrors, snapshots etc. using dmeventd or progress polling. [ 8.796058] systemd[1]: Finished systemd-sysusers.service - Create System Users. [ 8.821265] systemd[1]: Starting systemd-tmpfiles-setup-dev.service - Create Static Device Nodes in /dev... [ 8.821479] systemd[1]: Started systemd-journald.service - Journal Service. [ 8.865221] lp0: using parport0 (interrupt-driven). [ 9.004135] sd 0:0:0:0: Attached scsi generic sg0 type 0 [ 9.009846] sr 2:0:0:0: Attached scsi generic sg1 type 5 [ 9.048838] EDAC MC0: Giving out device to module ie31200_edac controller IE31200: DEV :00:00.0 (POLLED) [ 9.129202] iTCO_vendor_support: vendor-support=0 [ 9.134408] input: PC Speaker as /devices/platform/pcspkr/input/input12 [ 9.137872] iTCO_wdt iTCO_wdt.1.auto: Found a Panther Point TCO device (Version=2, TCOBASE=0x0560) [ 9.141787] at24 0-0050: supply vcc not found, using dummy regulator [ 9.154175] iTCO_wdt iTCO_wdt.1.auto: initialized. heartbeat=30 sec (nowayout=0) [ 9.154624] at24 0-0050: 256 byte spd EEPROM, read-only [ 9.161769] usbcore: registered new device driver apple-mfi-fastcharge [ 9.234467] RAPL PMU: API unit is 2^-32 Joules, 3 fixed counters, 163840 ms ovfl timer [ 9.234475] RAPL PMU: hw unit of domain pp0-core 2^-16 Joules [ 9.234477] RAPL PMU: hw unit of domain package 2^-16 Joules [ 9.234479] RAPL PMU: hw unit of domain pp1-gpu 2^-16 Joules [ 9.235718] cfg80211: Loading compiled-in X.509 certificates for regulatory database [ 9.235903] Loaded X.509 cert 'b...@debian.org: 577e021cb980e0e820821ba7b54b4961b8b4fadf' [ 9.236083] Loaded X.509 cert 'romain.per...@gmail.com: 3abbc6ec146e09d1b6016ab9d6cf71dd233f0328' [ 9.236251] Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7' [ 9.238123] platform regulatory.0: firmware: direct-loading firmware regulatory.db [ 9.238323] platform regulatory.0: firmware: direct-loading firmware regulatory.db.p7s [ 9.273677] alg: No test for fips(ansi_cprng) (fips_ansi_cprng) [ 9.286133] gsmi: no gsmi handler in firmware [ 9.513229] intel_rapl_common: Found RAPL domain package [ 9.513238] intel_rapl_common: Found RAPL domain core [ 9.513240] intel_rapl_common: Found RAPL domain uncore [ 9.566492] Bluetooth: Core ver 2.22 [ 9.566539] NET: Registered PF_BLUETOOTH protocol family [ 9.566542] Bluetooth: HCI device and connection manager initialized [ 9.566548] Bluetooth: HCI socket layer initialized [ 9.566551] Bluetooth: L2CAP socket layer initialized [ 9.566556] Bluetooth: SCO socket layer initialized [ 9.580540] usbcore: registered new interface driver btusb [ 9.690063] Bluetooth: hci0: BCM: chip id 102 build 0695 [ 9.691041] Bluetooth: hci0: BCM: product 05ac:8290 [ 9.693120] Bluetooth: hci0: BCM: features 0x2f [ 9.709018] Bluetooth: hci0: BCM20703A1 Generic USB UHE Apple 20Mhz fcbga_X87 [ 9.785188] EXT4-fs (dm-2): mounting with "discard" option, but the device does not support discard [ 9.785201] EXT4-fs (dm-2): mounted filesystem 1438d07e-fadf-4596-9087-4938ff89d449 r/w with ordered data mode. Quota mode: none. [ 9.790465] EXT4-fs (nvme0n1p3): mounted filesystem
Bug#1032655: psi-plus segfaults
This issue seems to only occur when running psi-plus under wayland. It will not occur when only X (either Xorg, Xwayland by running `WAYLAND_DISPLAY="" psi-plus` or ssh-forwarded X) is available.
Bug#1012734: firejail-profiles: Debian-patched transmission programs cannot run inside firejail with shipped profiles
Package: firejail-profiles Version: 0.9.70-1 Severity: normal Dear Maintainer, Debian have patched the current transmission to fit OpenSSL 3.0, but in order to use the legacy RC4 algorithm, ossl-modules/legacy.so should be able to load at runtime, otherwise Debian-patched transmission programs will be terminated with SIGSEGV when trying to set up an EVP_CIPHER_CTX for RC4, as in the attached backtrace. (against a /usr/local/bin/transmission-daemon built from Debian-patched source with the same config, but with debug symbols retained) This dependency has rendered the current Debian-patched transmission programs cannot run inside firejail with shipped profiles. To walk this issue around, "private-lib /ossl-modules,legacy.so" should be added into the (included) profile snippet of the transmission program. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (900, 'testing'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.17.0-1-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=zh_CN.utf8, LC_CTYPE=zh_CN.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages firejail-profiles depends on: ii firejail 0.9.70-1 firejail-profiles recommends no packages. firejail-profiles suggests no packages. -- no debconf information #0 0x563113cb4c0f in tr_rc4_set_key (h=0x0, key=key@entry=0x7f5ee6068170 "D\333O\357m\020F\260\213\r\216\320u\310\330Vs\273>\272", key_length=key_length@entry=20) at crypto-utils-openssl.c:255 255 if (!check_result(EVP_CIPHER_CTX_set_key_length(handle->cipher_ctx, key_length))) [Current thread is 1 (Thread 0x7f5ee606a640 (LWP 55))] #1 0x563113cdad31 in initRC4 (crypto=crypto@entry=0x7f5ee38f69b0, setme=setme@entry=0x7f5ee38f69b8, key=) at crypto.c:106 #2 0x563113cdb040 in tr_cryptoEncryptInit (crypto=0x7f5ee38f69b0) at crypto.c:140 #3 0x563113cdbaba in readYb (inbuf=0x7f5ee376dba0, handshake=0x7f5ee3699190) at handshake.c:460 #4 canRead (io=, arg=0x7f5ee3699190, piece=) at handshake.c:1060 #5 0x563113cc5c5b in canReadWrapper (io=0x7f5ee38f65f0) at peer-io.c:211 #6 0x563113ced542 in UTP_ProcessIncoming (conn=conn@entry=0x7f5ee376d050, packet=packet@entry=0x7f5ee6068a50 "\001", len=len@entry=363, syn=syn@entry=false) at utp.cpp:2158 #7 0x563113cee380 in UTP_IsIncomingUTP (incoming_proc=incoming_proc@entry=0x563113ca78e0 , send_to_proc=send_to_proc@entry=0x563113ca7a30 , send_to_userdata=send_to_userdata@entry=0x563114b0ac00, buffer=buffer@entry=0x7f5ee6068a50 "\001", len=len@entry=363, to=, tolen=16) at utp.cpp:2587 #8 0x563113ca7aba in tr_utpPacket (buf=buf@entry=0x7f5ee6068a50 "\001", buflen=buflen@entry=363, from=from@entry=0x7f5ee60689d0, fromlen=16, ss=ss@entry=0x563114b0ac00) at tr-utp.c:181 #9 0x563113ca71f5 in event_callback (s=, type=, sv=0x563114b0ac00) at tr-udp.c:285 #10 0x7f5ee7d25428 in ?? () from /usr/lib/x86_64-linux-gnu/libevent-2.1.so.7 #11 0x7f5ee7d25b77 in event_base_loop () from /usr/lib/x86_64-linux-gnu/libevent-2.1.so.7 #12 0x563113ca84d8 in libeventThreadFunc (veh=0x563114b0b170) at trevent.c:263 #13 0x563113c96d38 in ThreadFunc (_t=0x563114af5570) at platform.c:104 #14 0x7f5ee762ad80 in start_thread (arg=0x7f5ee606a640) at pthread_create.c:481 #15 0x7f5ee754476f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Bug#1011449: Info received (Bug#1011449: Acknowledgement (pidgin cannot resume interrupted XMPP connection if no srv_rec available.))
This bug should have been fixed in pidgin 2.14.10-1 since it should contain https://keep.imfreedom.org/pidgin/pidgin/rev/ea52fcc50e50 , as shown in https://keep.imfreedom.org/pidgin/pidgin/graph/594d72369304 .
Bug#1012430: Acknowledgement (firefox-esr: Permanent certificate exceptions do not work in private windows.)
This bug has been forwarded to mozilla as https://bugzilla.mozilla.org/show_bug.cgi?id=1772976 , which needs approval to be publicly accessible.
Bug#1012430: firefox-esr: Permanent certificate exceptions do not work in private windows.
Package: firefox-esr Version: 91.10.0esr-1 Severity: normal Dear Maintainer, Although permanent certificate exceptions cannot be added from private windows, existing permanent certificate exceptions once added from normal mode used to be effective in private windows under the same profile in previous version, but that is not the case in the current version. Now, even if a permanent certificate exceptions had been added for an HTTPS site from normal mode, if one opens a private window and tries to access the very same site with the private window, the warning for untrusted certificate will be generated. To suppress the warning, they should add the same certificate in the private window as a temporary certificate exception (because only temporary certificate exceptions can be added in private windows) over and over, when they access the site from a private window for the first time after they launch firefox-esr. At least, there should be an option (even in about:config) to control whether existing permanent certificate exceptions are effective in private windows, rather than rejecting them unconditionally. -- Package-specific info: -- Addons package information -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (900, 'testing'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.17.0-1-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=zh_CN.utf8, LC_CTYPE=zh_CN.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages firefox-esr depends on: ii debianutils 5.7-0.2 ii fontconfig 2.13.1-4.4 ii libatk1.0-0 2.38.0-1 ii libc6 2.33-7 ii libcairo-gobject2 1.16.0-5 ii libcairo2 1.16.0-5 ii libdbus-1-3 1.14.0-1 ii libdbus-glib-1-2 0.112-2 ii libevent-2.1-7 2.1.12-stable-5 ii libffi8 3.4.2-4 ii libfontconfig1 2.13.1-4.4 ii libfreetype6 2.12.1+dfsg-2 ii libgcc-s1 12.1.0-2 ii libgdk-pixbuf-2.0-0 2.42.8+dfsg-1 ii libglib2.0-0 2.72.1-1 ii libgtk-3-0 3.24.34-1 ii libnspr4 2:4.34-1 ii libnss3 2:3.79-1 ii libpango-1.0-0 1.50.7+ds-1 ii libstdc++6 12.1.0-2 ii libvpx7 1.11.0-2 ii libx11-6 2:1.7.5-1 ii libx11-xcb1 2:1.7.5-1 ii libxcb-shm0 1.14-3 ii libxcb1 1.14-3 ii libxcomposite1 1:0.4.5-1 ii libxdamage1 1:1.1.5-2 ii libxext6 2:1.3.4-1 ii libxfixes3 1:6.0.0-1 ii libxrender1 1:0.9.10-1 ii procps 2:3.3.17-7+b1 ii zlib1g 1:1.2.11.dfsg-4 Versions of packages firefox-esr recommends: ii libavcodec57 7:3.4.3-1 ii libavcodec58 7:4.4.2-1+b1 Versions of packages firefox-esr suggests: ii fonts-lmodern 2.005-1 ii fonts-stix [otf-stix] 1.1.1-4.1 ii libcanberra0 0.30-10 ii libgssapi-krb5-2 1.19.2-2+b1 ii pulseaudio 15.0+dfsg1-4 -- no debconf information
Bug#1011449: Acknowledgement (pidgin cannot resume interrupted XMPP connection if no srv_rec available.)
There is already a fix ( https://keep.imfreedom.org/pidgin/pidgin/rev/ea52fcc50e50 ) on pidgin's repository, although the approach is different.
Bug#1011449: Acknowledgement (pidgin cannot resume interrupted XMPP connection if no srv_rec available.)
The temporary walkaround could be using "old-ssl" or bosh on XMPP accounts, because their early error-handlings avoid (js->srv_rec).
Bug#1011449: Acknowledgement (pidgin cannot resume interrupted XMPP connection if no srv_rec available.)
This issue should occur when jabber_login_connect() fails and calls jabber_login_callback() with an error. 在 2022/5/23 16:00, Mad Horse 写道: This is because in jabber_login_callback(), when an error occurs (source < 0), if (js->srv_rec != NULL), it will report the error and call try_srv_connect() to try another SRV record, and return, but if (js->srv_rec == NULL), it will return directly without reporting the error, nor any further process. It makes things worse that because now the state of affected connection is not PURPLE_DISCONNECTED, further calls of _purple_connection_new() will return early, making the connection unable to resume. The only way to connect the corresponding account is to disable it first, (set its state to PURPLE_DISCONNECTED) and enable it again, manually.
Bug#1011449: pidgin cannot resume interrupted XMPP connection if no srv_rec available.
Package: pidgin
Version: 2.14.9-2
Severity: normal
Dear Maintainer,
The current pidgin cannot resume interrupted XMPP connection if no srv_rec
available (e.g. when using tor as proxy so no srv_rec will be obtained
from DNS
in the first place).
This is because in jabber_login_callback(), when an error occurs (source
< 0),
if (js->srv_rec != NULL), it will report the error and call
try_srv_connect()
to try another SRV record, and return, but if (js->srv_rec == NULL), it will
return directly without reporting the error, nor any further process.
Since try_srv_connect() can handle the scenario that (js->srv_rec ==
NULL) and
resume the interrupted XMPP connection, I suggest to call try_srv_connect()
when an error occurs, regardless whether (js->srv_rec == NULL), like the
attached patch.
-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (900, 'testing'), (500, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.17.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=zh_CN.utf8, LC_CTYPE=zh_CN.utf8 (charmap=UTF-8), LANGUAGE
not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages pidgin depends on:
ii libatk1.0-0 2.38.0-1
ii libc6 2.33-7
ii libcairo2 1.16.0-5
ii libdbus-1-3 1.14.0-1
ii libgdk-pixbuf-2.0-0 2.42.8+dfsg-1
ii libglib2.0-0 2.72.1-1
ii libgstreamer-plugins-base1.0-0 1.20.2-2
ii libgstreamer1.0-0 1.20.2-1
ii libgtk2.0-0 2.24.33-2
ii libgtkspell0 2.0.16-1.3
ii libice6 2:1.0.10-1
ii libpango-1.0-0 1.50.7+ds-1
ii libpurple0 2.14.9-2
ii libsm6 2:1.2.3-1
ii libx11-6 2:1.7.5-1
ii libxss1 1:1.2.3-1
ii perl-base [perlapi-5.34.0] 5.34.0-4
ii pidgin-data 2.14.9-2
Versions of packages pidgin recommends:
ii gstreamer1.0-libav 1.20.2-1
ii gstreamer1.0-plugins-base 1.20.2-2
ii gstreamer1.0-plugins-good 1.20.2-1
ii gstreamer1.0-pulseaudio 1.20.2-1
ii sensible-utils 0.0.17
Versions of packages pidgin suggests:
ii libsqlite3-0 3.38.5-1
-- no debconf information
--- a/libpurple/protocols/jabber/jabber.c 2022-05-23 15:50:49.475173171
+0800
+++ b/libpurple/protocols/jabber/jabber.c 2022-05-23 15:51:17.491467914
+0800
@@ -804,10 +804,8 @@ jabber_login_callback(gpointer data, gin
JabberStream *js = purple_connection_get_protocol_data(gc);
if (source < 0) {
- if (js->srv_rec != NULL) {
- purple_debug_error("jabber", "Unable to connect to
server: %s. Trying next SRV record or connecting directly.\n", error);
- try_srv_connect(js);
- }
+ purple_debug_error("jabber", "Unable to connect to server: %s.
Trying next SRV record or connecting directly.\n", error);
+ try_srv_connect(js);
return;
}
Bug#1008137: Acknowledgement (firejail-profiles: Profiles for most web browser blocks mDNS resolution)
Currently I walk around this issue by adding "whitelist /run/avahi-daemon/" to my ~/.config/firejail/whitelist-run-common.local, but I doubt whether it is appropriate to fix this issue by adding a similar rule to /etc/firejail/whitelist-run-common.inc
Bug#1008137: firejail-profiles: Profiles for most web browser blocks mDNS resolution
Package: firejail-profiles Version: 0.9.68-3 Severity: normal Dear Maintainer, I find that I cannot access a web server running in my local lan with its mDNS domain name with firefox-esr running inside firejail while I can with firefox-esr running without firejail. This problem also applies to falkon, chromium, when running inside firejail, but epiphany (gnome web) is not affected. I manage to run bash in firejail with profiles of these affected browsers, and find that /run/avahi-daemon/ does not present in their jailed file system, so it seems that some rules blacklist, or fail to whitelist this path in these profiles or included rulesets. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (900, 'testing'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.16.0-4-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=zh_CN.utf8, LC_CTYPE=zh_CN.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages firejail-profiles depends on: ii firejail 0.9.68-3 firejail-profiles recommends no packages. firejail-profiles suggests no packages. -- no debconf information
Bug#1006271: Info received (Bug#1006271: Acknowledgement (network-manager: crashes if DHCPv6 server sends multiple IPv6 addresses))
Upstream issue https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/907 is related to this bug, and it is fixed with https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/5402a7217964205aa6041324fa0fd393bfbb4838
Bug#1006271: Acknowledgement (network-manager: crashes if DHCPv6 server sends multiple IPv6 addresses)
A patch like the attached one should be able to fix this problem.diff -Nrup src/core/dhcp/nm-dhcp-utils.c.orig src/core/dhcp/nm-dhcp-utils.c --- "src/core/dhcp/nm-dhcp-utils.c.orig" 2022-03-03 13:44:26 +++ "src/core/dhcp/nm-dhcp-utils.c" 2022-03-03 13:44:56 @@ -876,7 +876,7 @@ nm_dhcp_utils_merge_new_dhcp6_lease(cons * addresses from the same transaction into a single configuration. **/ -l3cd_merged = nm_l3_config_data_new_clone(l3cd_old, -1); +l3cd_merged = nm_l3_config_data_new_clone(l3cd_old, 0); nm_l3_config_data_iter_ip6_address_for_each (, l3cd_new, ) nm_l3_config_data_add_address_6(l3cd_merged, addr);
Bug#1006271: network-manager: crashes if DHCPv6 server sends multiple IPv6 addresses
Package: network-manager Version: 1.35.91-1 Severity: important Dear Maintainer, network-manager 1.35.91-1 and 1.35.92-1 will abort if DHCPv6 server sends multiple IPv6 addresses,( as under a default-configured openwrt router ) because in this case, nm_dhcp_utils_merge_new_dhcp6_lease() would call nm_l3_config_data_new_clone() with ifindex=-1, which may originally result ifindex = src->ifindex; but now in order to make such effect, ifindex should be set to 0 instead a negative value, otherwise such call will abort network-manager for violating the assertion nm_assert(ifindex >= 0) in nm_l3_config_data_new_clone(). -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (900, 'testing'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.16.0-1-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=zh_CN.utf8, LC_CTYPE=zh_CN.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages network-manager depends on: ii adduser 3.118 ii dbus 1.12.20-3 ii libaudit1 1:3.0.7-1 ii libbluetooth3 5.62-2 ii libc6 2.33-6 ii libcurl3-gnutls 7.81.0-1 ii libglib2.0-0 2.70.4-1 ii libgnutls30 3.7.3-4+b1 ii libjansson4 2.13.1-1.1 ii libmm-glib0 1.18.6-1 ii libndp0 1.6-1+b1 ii libnewt0.52 0.52.21-5+b1 ii libnm0 1.35.91-1 ii libpsl5 0.21.0-1.2 ii libreadline8 8.1.2-1 ii libselinux1 3.3-1+b1 ii libsystemd0 250.3-2 ii libteamdctl0 1.31-1 ii libudev1 250.3-2 ii policykit-1 0.105-32 ii udev 250.3-2 Versions of packages network-manager recommends: ii dnsmasq-base [dnsmasq-base] 2.86-1.1 ii iptables 1.8.7-1 ii libpam-systemd 250.3-2 ii modemmanager 1.18.6-1 ii ppp 2.4.9-1+1 ii wireless-regdb 2021.08.28-1 ii wpasupplicant 2:2.9.0-23 Versions of packages network-manager suggests: ii libteam-utils 1.31-1 Versions of packages network-manager is related to: ii isc-dhcp-client 4.4.1-2.3 -- no debconf information
Bug#1006270: network-manager: crashes if DHCPv6 server sends multiple IPv6 addresses
Package: . Version: 1.35.91-1 Severity: important Dear Maintainer, network-manager 1.35.91-1 and 1.35.92-1 will abort if DHCPv6 server sends multiple IPv6 addresses,( as under a default-configured openwrt router ) because in this case, nm_dhcp_utils_merge_new_dhcp6_lease() would call nm_l3_config_data_new_clone() with ifindex=-1, which may originally result ifindex = src->ifindex; but now in order to make such effect, ifindex should be set to 0 instead a negative value, otherwise such call will abort network-manager for violating the assertion nm_assert(ifindex >= 0) in nm_l3_config_data_new_clone(). -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (900, 'testing'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.16.0-1-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=zh_CN.utf8, LC_CTYPE=zh_CN.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages network-manager depends on: ii adduser 3.118 ii dbus 1.12.20-3 ii libaudit1 1:3.0.7-1 ii libbluetooth3 5.62-2 ii libc6 2.33-6 ii libcurl3-gnutls 7.81.0-1 ii libglib2.0-0 2.70.4-1 ii libgnutls30 3.7.3-4+b1 ii libjansson4 2.13.1-1.1 ii libmm-glib0 1.18.6-1 ii libndp0 1.6-1+b1 ii libnewt0.52 0.52.21-5+b1 ii libnm0 1.35.91-1 ii libpsl5 0.21.0-1.2 ii libreadline8 8.1.2-1 ii libselinux1 3.3-1+b1 ii libsystemd0 250.3-2 ii libteamdctl0 1.31-1 ii libudev1 250.3-2 ii policykit-1 0.105-32 ii udev 250.3-2 Versions of packages network-manager recommends: ii dnsmasq-base [dnsmasq-base] 2.86-1.1 ii iptables 1.8.7-1 ii libpam-systemd 250.3-2 ii modemmanager 1.18.6-1 ii ppp 2.4.9-1+1 ii wireless-regdb 2021.08.28-1 ii wpasupplicant 2:2.9.0-23 Versions of packages network-manager suggests: ii libteam-utils 1.31-1 Versions of packages network-manager is related to: ii isc-dhcp-client 4.4.1-2.3 -- no debconf information
Bug#1003650: firejail-profiles: Chromium running under the current profile cannot play sound
Hi Reine,
I do not have any custom setup on my pipewire, nor custom firejail
profile for chromium.
Started within firejail, chromium reported:
[10:46:0115/104317.720203:ERROR:bus.cc(397)] Failed to connect to the
bus: Failed to connect to socket /run/firejail/mnt/dbus/system:
Permission denied
libva error: /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so init failed
[56:56:0115/104317.772250:ERROR:sandbox_linux.cc(378)]
InitializeSandbox() called with multiple threads in process gpu-process.
[10:85:0115/104317.887055:ERROR:bus.cc(397)] Failed to connect to the
bus: Failed to connect to socket /run/firejail/mnt/dbus/system:
Permission denied
[10:85:0115/104317.887112:ERROR:bus.cc(397)] Failed to connect to the
bus: Failed to connect to socket /run/firejail/mnt/dbus/system:
Permission denied
[10:85:0115/104317.887169:ERROR:bus.cc(397)] Failed to connect to the
bus: Failed to connect to socket /run/firejail/mnt/dbus/system:
Permission denied
[10:85:0115/104317.887206:ERROR:bus.cc(397)] Failed to connect to the
bus: Failed to connect to socket /run/firejail/mnt/dbus/system:
Permission denied
[10:85:0115/104317.887235:ERROR:bus.cc(397)] Failed to connect to the
bus: Failed to connect to socket /run/firejail/mnt/dbus/system:
Permission denied
/run/firejail/mnt/dbus/system do have permission 600, owned by root.
When trying to play sound, chromium in firejail reported:
Failed to create secure directory (/run/user/1000/pulse): Operation
not permitted
ALSA lib dlmisc.c:337:(snd_dlobj_cache_get0) Cannot open shared
library libasound_module_pcm_pulse.so
(/usr/lib/x86_64-linux-gnu/alsa-lib/libasound_module_pcm_pulse.so:
cannot open shared object file: Permission denied)
[307:307:0115/104404.402900:ERROR:alsa_util.cc(204)] PcmOpen:
default,No such device or address
ALSA lib dlmisc.c:337:(snd_dlobj_cache_get0) Cannot open shared
library libasound_module_pcm_pulse.so
(/usr/lib/x86_64-linux-gnu/alsa-lib/libasound_module_pcm_pulse.so:
cannot open shared object file: Permission denied)
[307:307:0115/104404.404678:ERROR:alsa_util.cc(204)] PcmOpen:
plug:default,No such device or address
but there is a unix domain socket /run/user/1000/pulse/native, owned by
UID 1000, with permission 666,
and the permission of
/usr/lib/x86_64-linux-gnu/alsa-lib/libasound_module_pcm_pulse.so is
root,644.
Both were inspected inside firejail for chromium.
Do you have any idea about these?
Kind regards,
Mad Horse
On 2022/1/15 04:47, Reiner Herrmann wrote:
Hi Mad Horse,
On Thu, Jan 13, 2022 at 05:07:38PM +0800, Mad Horse wrote:
After upgraded to 97.0.4692.71-0.1, Chromium running inside firejail can no
longer play sound (e.g. when playing an online video), while bare Chromium
can. It is shown with PulseAudio Manager that the Chromium running inside
firejail cannot connect to the sound server while the bare Chromium can.
I had a similar issue initially as well. But it turned out to be related
to my custom sound setup (using pipewire with run directory in ~/pipewire).
There are also no sound-related Chromium issue known in the upstream
firejail bug tracker.
So I think it also has to be related to your setup.
It might be related to some whitelist in the chromium{-common}.profile,
as this causes the parent directory to get blocked.
Can you please try to figure out which path needs to be whitelisted
on your system to get it working again?
Kind regards,
Reiner
Bug#1003650: firejail-profiles: Chromium running under the current profile cannot play sound
Package: firejail-profiles Version: 0.9.66-2 Severity: normal Dear Maintainer, After upgraded to 97.0.4692.71-0.1, Chromium running inside firejail can no longer play sound (e.g. when playing an online video), while bare Chromium can. It is shown with PulseAudio Manager that the Chromium running inside firejail cannot connect to the sound server while the bare Chromium can. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (900, 'testing'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-2-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_WARN, TAINT_FIRMWARE_WORKAROUND Locale: LANG=zh_CN.utf8, LC_CTYPE=zh_CN.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages firejail-profiles depends on: ii firejail 0.9.66-2 firejail-profiles recommends no packages. firejail-profiles suggests no packages. -- no debconf information
Bug#1001695: dpkg.postinst fails to handle /var/lib/dpkg/lost+found
On 2021/12/14 21:28, Guillem Jover wrote: Hi! On Tue, 2021-12-14 at 21:00:40 +0800, Mad Horse wrote: Package: dpkg Version: 1.21.1 Severity: important On my system, /var/lib/dpkg is an dedicated file system mounted there, so there is an directory /var/lib/dpkg/lost+found, and fixup_misplaced_alternatives() within dpkg.postinst will try to "fix" it up, causing upgrade from dpkg 1.16.1 failed. Currently I walk this problem around by adding "lost+found" to the "known file list" in fixup_misplaced_alternatives(), but this function should only work on files, not directories, so we had better add some check to see whether this assumed target is a file, in the first place. Ouch, indeed. Thanks, I've fixed this locally now, and will be included in the next upcoming release. Thanks, Guillem Since this bug breaks upgradability, could you release a "hotfix" for this?
Bug#1001695: dpkg.postinst fails to handle /var/lib/dpkg/lost+found
Package: dpkg Version: 1.21.1 Severity: important Dear Maintainer, On my system, /var/lib/dpkg is an dedicated file system mounted there, so there is an directory /var/lib/dpkg/lost+found, and fixup_misplaced_alternatives() within dpkg.postinst will try to "fix" it up, causing upgrade from dpkg 1.16.1 failed. Currently I walk this problem around by adding "lost+found" to the "known file list" in fixup_misplaced_alternatives(), but this function should only work on files, not directories, so we had better add some check to see whether this assumed target is a file, in the first place. -- Package-specific info: -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (900, 'testing'), (500, 'testing-proposed-updates'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-2-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=zh_CN.utf8, LC_CTYPE=zh_CN.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dpkg depends on: ii libbz2-1.0 1.0.8-5 ii libc6 2.32-5 ii liblzma5 5.2.5-2 ii libselinux1 3.3-1+b1 ii tar 1.34+dfsg-1 ii zlib1g 1:1.2.11.dfsg-2 dpkg recommends no packages. Versions of packages dpkg suggests: ii apt 2.3.13 ii debsig-verify 0.25 -- debconf-show failed
Bug#995370: pidgin: segmentation fault on malloc/free
Package: pidgin
Followup-For: Bug #995370
Dear Maintainer,
This bug may be due to another related issue which need to be fixed in
the same
time but not. The way to fix it is attached.
With the old logic prior to
https://keep.imfreedom.org/pidgin/pidgin/rev/f25ce9376564 ,
the bug may not break out, because jbr->thread_id tends to keep NULL,
but after
the
commit above, if jbr->thread_id is not NULL, it would be released along with
jm, causing
a double free when releasing the jbr, so jm->thread_id should be duplicated
from
jbr->thread_id instead of pointed to it.
-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (900, 'testing'), (500, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.14.0-1-amd64 (SMP w/2 CPU threads)
Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=UTF-8), LANGUAGE not
set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages pidgin depends on:
ii libatk1.0-0 2.36.0-2
ii libc6 2.32-4
ii libcairo2 1.16.0-5
ii libdbus-1-3 1.12.20-2
ii libgdk-pixbuf-2.0-0 2.42.6+dfsg-2
ii libglib2.0-0 2.70.0-1+b1
ii libgstreamer-plugins-base1.0-0 1.18.5-1
ii libgstreamer1.0-0 1.18.5-1
ii libgtk2.0-0 2.24.33-2
ii libgtkspell0 2.0.16-1.3
ii libice6 2:1.0.10-1
ii libpango-1.0-0 1.48.10+ds1-1
ii libpurple0 2.14.1-1
ii libsm6 2:1.2.3-1
ii libx11-6 2:1.7.2-2+b1
ii libxss1 1:1.2.3-1
ii perl-base [perlapi-5.32.1] 5.32.1-6
ii pidgin-data 2.14.1-1
Versions of packages pidgin recommends:
ii gstreamer1.0-libav 1.18.5-1
ii gstreamer1.0-plugins-base 1.18.5-1
ii gstreamer1.0-plugins-good 1.18.5-1
ii gstreamer1.0-pulseaudio 1.18.5-1
ii sensible-utils 0.0.17
Versions of packages pidgin suggests:
ii libsqlite3-0 3.36.0-2
--- a/libpurple/protocols/jabber/message.c 2021-06-01 22:34:44.0 +
+++ b/libpurple/protocols/jabber/message.c 2021-10-02 09:30:02.0 +
@@ -1180,7 +1180,7 @@ int jabber_message_send_im(PurpleConnect
if(jbr) {
if(jbr->thread_id)
- jm->thread_id = jbr->thread_id;
+ jm->thread_id = g_strdup(jbr->thread_id);
if (jbr->chat_states == JABBER_CHAT_STATES_UNSUPPORTED)
jm->chat_state = JM_STATE_NONE;
Bug#973756: Acknowledgement (firejail: fcopy fails to load libpcre2-8.so.0 when running transmission-daemon)
Currently transmission-gtk could be run with firejail, and I can use
transmission-gtk's profile to run transmission-daemon, customized with
such transmission-gtk.local:
private-bin transmission-daemon
noblacklist ${HOME}/.config/transmission-daemon
whitelist ${HOME}/.config/transmission-daemon
Bug#973756: firejail: fcopy fails to load libpcre2-8.so.0 when running transmission-daemon
Package: firejail Version: 0.9.64-1 Severity: normal Dear Maintainer, Executing transmission-cli or transmission-daemon with firejail results following error: /run/firejail/lib/fcopy: error while loading shared libraries: libpcre2-8.so.0: cannot open shared object file: No such file or directory Error: failed to run /run/firejail/lib/fcopy -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (900, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-1-amd64 (SMP w/4 CPU threads) Locale: LANG=zh_CN.utf8, LC_CTYPE=zh_CN.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages firejail depends on: ii libapparmor1 2.13.5-1 ii libc6 2.31-4 ii libselinux1 3.1-2+b1 Versions of packages firejail recommends: ii firejail-profiles 0.9.64-1 ii iproute2 5.9.0-1 ii iptables 1.8.5-3 ii xauth 1:1.0.10-1 ii xdg-dbus-proxy 0.1.2-1 ii xpra 3.0.9+dfsg1-1+b3 ii xserver-xephyr 2:1.20.8-2 firejail suggests no packages. -- no debconf information
Bug#966198: Acknowledgement (gdm3: Defunct gdm-session-worker processes occationally remains unhandled.)
These defunct gdm-session-worker processes are in fact for [pam/gdm-launch-environment].
Bug#969314: ncat discards reply from target server attached to socks CONNECT response
Package: ncat Version: 7.80+dfsg1-5 Severity: normal Dear Maintainer, When using ncat to connect a target server via an intermediate SOCKS server (either 4 or 5), If the initial replies from the target server (e.g. the banner line sent by an ssh server) is occasionally attached after the response packet of SOCKS CONNECT (it should be legal and may be done by many SOCKS server implementations, since TCP on which SOCKS is based is stream oriented), ncat is unable to return these replies. Only the initial replies from the target server sent as a separate packet after the response of SOCKS CONNECT by the SOCKS proxy can be correctly returned. This bug breaks the SSH protocol when ncat is used in the ProxyCommand option of OpenSSH to use a SOCKS proxy, because server's banner line may get lost. Other netcat implementations like netcat-openbsd can handle replies attached to the response packet of SOCKS CONNECT and work fine with OpenSSH. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (900, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.7.0-2-amd64 (SMP w/4 CPU threads) Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ncat depends on: ii libc6 2.31-3 ii liblua5.3-0 5.3.3-1.1+b1 ii libpcap0.8 1.9.1-4 ii libssl1.1 1.1.1g-1 ncat recommends no packages. ncat suggests no packages. -- no debconf information
Bug#967056: ecryptfs-utils: The first login with password after boot will increment the mount count by two.
Package: ecryptfs-utils Version: 111-5 Severity: important Dear Maintainer, 0) Use ecryptfs-setup-private to setup a Private directory in a user account. 1) After a fresh boot, the first login authenticated with the password to that user account (either via gdm3, via console, or via ssh), increments the mount count in /dev/shm/ecryptfs-$USER-private by 2 instead of 1, and logging out will only decrement it by 1. Currently I handle it by manually executing $ ecryptfs-umount-private (to decrement the mount count by 1) before logout, otherwise it will leave the Private directory accessible after logout. 2) After this, all subsequent logins with password (either via gdm3, via console, or via ssh) will only increment the mount count by 1. (Besides, logins without password, such as via ssh authenticated with a public key, will not increment mount count. Accessing Private in such situation should be done by manually executing $ ecryptfs-mount-private and providing password, and mount count will be decremented by one when logging out from this session.) 3) No matter how many logins without password, during which manually mounting Private may or may not occur, precede it, only "the first login with password" increments the mount count by 2. I suspect this issue appears because "session optional pam_ecryptfs.so unwrap" is present both in /etc/pam.d/common-session-noninteractive and in /etc/pam.d/common-session. The former acts on the first login, (via "systemd --user") while the latter acts on every interactive login. If password is available when they act, mount count will all increment by 1 each time. Further inspection shows that "systemd --user" is launched by the first login, either with or without password, and continue to run after logout, but in "the first login with password", the process tree with "systemd --user" as its root launched by the first login without password will be replaced with a new launch of "systemd --user", which will never be replaced any more during all subsequent logins. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (900, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.7.0-2-amd64 (SMP w/4 CPU threads) Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ecryptfs-utils depends on: ii gettext-base 0.19.8.1-10 ii keyutils 1.6.1-2 ii libc6 2.31-2 ii libecryptfs1 111-5 ii libgpgme11 1.13.1-9 ii libkeyutils1 1.6.1-2 ii libpam-runtime 1.3.1-5 ii libpam0g 1.3.1-5 ii libtspi1 0.3.14+fixed1-1+b1 ecryptfs-utils recommends no packages. Versions of packages ecryptfs-utils suggests: ii cryptsetup 2:2.3.3-1+b1 ii rsync 3.2.2-2 -- no debconf information
Bug#966198: gdm3: Defunct gdm-session-worker processes occationally remains unhandled.
Package: gdm3 Version: 3.36.2-1 Severity: normal Dear Maintainer, Sometimes defunct gdm-session-worker processes may appear after logging out from a gnome session, which usually lasts several hours, but sometimes logging out from a gnome session lasting only one minute can trigger this phenomenon. These defunct gdm-session-worker processes are owned by the user "Debian-gdm", and their cpu time last only several seconds. These defunct processes do not clearly impact the functionality of gdm3, but they occupy available process slots, and cannot be manually cleared unless I restart gdm3 with no gnome session active (via console or ssh). -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (900, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.7.0-1-amd64 (SMP w/4 CPU threads) Locale: LANG=zh_CN.utf8, LC_CTYPE=zh_CN.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gdm3 depends on: ii accountsservice 0.6.55-2 ii adduser 3.118 ii cdebconf [debconf-2.0] 0.253 ii dbus 1.12.20-1 ii dconf-cli 0.36.0-1 ii dconf-gsettings-backend 0.36.0-1 ii debconf [debconf-2.0] 1.5.74 ii gir1.2-gdm-1.0 3.36.2-1 ii gnome-session [x-session-manager] 3.36.0-2 ii gnome-session-bin 3.36.0-2+b1 ii gnome-session-flashback [x-session-manager] 3.36.3-1 ii gnome-settings-daemon 3.36.1-1 ii gnome-shell 3.36.3-1 ii gnome-terminal [x-terminal-emulator] 3.36.2-1 ii gsettings-desktop-schemas 3.36.1-1 ii libaccountsservice0 0.6.55-2 ii libaudit1 1:2.8.5-3+b1 ii libc6 2.31-1 ii libcanberra-gtk3-0 0.30-7 ii libcanberra0 0.30-7 ii libgdk-pixbuf2.0-0 2.40.0+dfsg-5 ii libgdm1 3.36.2-1 ii libglib2.0-0 2.64.4-1 ii libglib2.0-bin 2.64.4-1 ii libgtk-3-0 3.24.20-1 ii libkeyutils1 1.6.1-2 ii libpam-modules 1.3.1-5 ii libpam-runtime 1.3.1-5 ii libpam-systemd 245.6-2 ii libpam0g 1.3.1-5 ii librsvg2-common 2.48.7-1 ii libselinux1 3.0-1+b3 ii libsystemd0 245.6-2 ii libwrap0 7.6.q-30 ii libx11-6 2:1.6.9-2+b1 ii libxau6 1:1.0.8-1+b2 ii libxcb1 1.14-2 ii libxdmcp6 1:1.1.2-3 ii lsb-base 11.1.0 ii metacity [x-window-manager] 1:3.36.1-1 ii mutter [x-window-manager] 3.36.3-1 ii policykit-1 0.105-28 ii procps 2:3.3.16-5 ii tilix [x-terminal-emulator] 1.9.3-4+b2 ii ucf 3.0043 ii x11-common 1:7.7+20 ii x11-xserver-utils 7.7+8 ii xterm [x-terminal-emulator] 358-1 Versions of packages gdm3 recommends: ii at-spi2-core 2.36.0-2 ii desktop-base 10.0.3 ii x11-xkb-utils 7.7+5 ii xserver-xephyr 2:1.20.8-2 ii xserver-xorg 1:7.7+20 ii zenity 3.32.0-5 Versions of packages gdm3 suggests: pn gnome-orca pn libpam-fprintd ii libpam-gnome-keyring 3.36.0-1 -- debconf information: gdm3/daemon_name: /usr/sbin/gdm3 * shared/default-x-display-manager: gdm3
Bug#960474: fcitx-rime: fcitx crashes when switching to fcitx-rime
Package: fcitx-rime Version: 0.3.2-7 Severity: important Dear Maintainer, When switching to fcitx-rime, fcitx crashes. Trace can be retrieved by running with $ fcitx -D: (ERROR-2559744 ime.c:432) fcitx-keyboard-in-tel-kagapa already exists (ERROR-2559744 ime.c:432) fcitx-keyboard-cm-mmuock already exists = FCITX 4.2.9.7 -- Get Signal No.: 11 Date: try "date -d @1589341159" if you are using GNU date *** ProcessID: 2559744 fcitx(+0x1927)[0x55c60af5e927] /lib/x86_64-linux-gnu/libc.so.6(+0x3b7e0)[0x7f677938d7e0] /usr/lib/x86_64-linux- gnu/librime.so.1(_ZNK4YAML4Node4TypeEv+0x30)[0x7f676dc8c020] /usr/lib/x86_64-linux- gnu/librime.so.1(_ZN4rime10ConfigData15ConvertFromYamlERKN4YAML4NodeEPNS_14ConfigCompilerE+0x35)[0x7f676dc87425] /usr/lib/x86_64-linux- gnu/librime.so.1(_ZN4rime10ConfigData12LoadFromFileERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEPNS_14ConfigCompilerE+0x1a2)[0x7f676dc88712] /usr/lib/x86_64-linux- gnu/librime.so.1(_ZN4rime18InstallationUpdate3RunEPNS_8DeployerE+0x3cd)[0x7f676dd6c7dd] /usr/lib/x86_64-linux- gnu/librime.so.1(_ZN4rime8Deployer7RunTaskERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEN5boost3anyE+0xb3)[0x7f676dc44c83] /usr/lib/x86_64-linux- gnu/librime.so.1(RimeStartMaintenance+0xb6)[0x7f676dc25286] /usr/lib/x86_64-linux-gnu/fcitx/fcitx-rime.so(+0x2e16)[0x7f676f46fe16] /usr/lib/x86_64-linux-gnu/fcitx/fcitx-rime.so(+0x34ac)[0x7f676f4704ac] /usr/lib/x86_64-linux-gnu/libfcitx-core.so.0(+0x111ea)[0x7f67795771ea] /usr/lib/x86_64-linux-gnu/libfcitx-core.so.0(+0x14388)[0x7f677957a388] /usr/lib/x86_64-linux-gnu/libfcitx- core.so.0(FcitxInstanceSwitchIMByIndex+0x95)[0x7f677957afb5] /usr/lib/x86_64-linux-gnu/libfcitx-core.so.0(+0x15083)[0x7f677957b083] /usr/lib/x86_64-linux-gnu/libfcitx- core.so.0(FcitxInstanceProcessKey+0x956)[0x7f677957bf36] /usr/lib/x86_64-linux-gnu/fcitx/fcitx-ipc.so(+0x6a70)[0x7f677409ca70] /lib/x86_64-linux-gnu/libdbus-1.so.3(+0x26c8d)[0x7f67781e5c8d] /lib/x86_64-linux- gnu/libdbus-1.so.3(dbus_connection_dispatch+0x334)[0x7f67781d67e4] /usr/lib/x86_64-linux-gnu/fcitx/fcitx-dbus.so(+0x28b8)[0x7f67795b18b8] /usr/lib/x86_64-linux-gnu/fcitx/fcitx-dbus.so(+0x29d1)[0x7f67795b19d1] /usr/lib/x86_64-linux-gnu/libfcitx-core.so.0(+0xa38a)[0x7f677957038a] /usr/lib/x86_64-linux-gnu/libfcitx- core.so.0(FcitxInstanceRun+0x57)[0x7f6779570b27] fcitx(+0x12bf)[0x55c60af5e2bf] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb)[0x7f6779378e0b] fcitx(+0x133a)[0x55c60af5e33a] -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (900, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.6.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=zh_CN.utf8, LC_CTYPE=zh_CN.utf8 (charmap=UTF-8), LANGUAGE=zh_CN.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages fcitx-rime depends on: ii fcitx-bin 1:4.2.9.7-3 ii fcitx-data 1:4.2.9.7-3 ii fcitx-modules 1:4.2.9.7-3 ii libc6 2.30-7 ii libfcitx-config4 1:4.2.9.7-3 ii libfcitx-qt5-1 1.2.4-1 ii libgcc-s1 10.1.0-1 ii libqt5core5a 5.12.5+dfsg-10 ii libqt5gui5 5.12.5+dfsg-10 ii libqt5widgets5 5.12.5+dfsg-10 ii librime-data 0.38.20180515-3 ii librime1 1.5.3+dfsg1-5 ii libstdc++6 10.1.0-1 Versions of packages fcitx-rime recommends: ii fcitx 1:4.2.9.7-3 fcitx-rime suggests no packages. -- no debconf information
Bug#949469: firejail: files and directories in separate /home encrypted with fscrypt inaccessible inside firejail
Furthermore, with --private=/foo/bar, how can I access the encrypted directories
under the real ${HOME}, which is even not introduced into jail anymore with
--private=/foo/bar ?
在 2020/1/31 下午2:08, Mad Horse 写道:
> With --private=/foo/bar, configurations store under real ${HOME} becomes
> inaccessible,
>
> e.g.
>
>> $ firejail --allusers --private=/tmp/home/
>> --profile=/etc/firejail/firefox.profile /bin/bash
> so it is impractical (Please consider I am running profiled
> applications, rather than shell
>
> with default profile).
>
> Besides, although /home/.fscrypt appears inside jail, a tmpfs is mounted
>
> atop it, and --whitelist cannot be used to mount the real /home/.fscrypt
> there, for /home is
>
> not permitted top directory.
>
>
> 在 2020/1/31 上午7:55, Reiner Herrmann 写道:
>> On Sat, Jan 25, 2020 at 10:45:08PM +0800, Mad Horse wrote:
>>> I have not remembered that because --private is used so widely in
>>> officially shipped profiles, so I have to inspect them with command like
>>>
>>>> $ firejail --profile=/etc/firejail/firefox.profile /bin/bash
>> Hm, I couldn't find "private" in the firefox(-common) profile.
>> Does it work if you start it by giving it a location where it can store
>> the private home directory?
>> Like: firejail --allusers --private=/foo/bar
>> (see also:
>> https://github.com/netblue30/firejail/issues/3185#issuecomment-578413651 )
>>
>> Regards,
>> Reiner
>
Bug#949469: firejail: files and directories in separate /home encrypted with fscrypt inaccessible inside firejail
Sorry, it is --whitelist which also conflict with --allusers that appears in most shipped profiles. 在 2020/1/25 下午10:39, Reiner Herrmann 写道: > On Sat, Jan 25, 2020 at 10:30:50PM +0800, Mad Horse wrote: >>> Warning: allusers option disabled by private or whitelist option >> Because of this, inside jails started with private or whitelist options, >> /home remains masked, so files encrypted with fscrypt remain inaccessible. > Ok, so I assume that you are using --private (because whitelisting your > home directory would not be needed)?
Bug#949469: firejail: files and directories in separate /home encrypted with fscrypt inaccessible inside firejail
With --private=/foo/bar, configurations store under real ${HOME} becomes
inaccessible,
e.g.
> $ firejail --allusers --private=/tmp/home/
> --profile=/etc/firejail/firefox.profile /bin/bash
so it is impractical (Please consider I am running profiled
applications, rather than shell
with default profile).
Besides, although /home/.fscrypt appears inside jail, a tmpfs is mounted
atop it, and --whitelist cannot be used to mount the real /home/.fscrypt
there, for /home is
not permitted top directory.
在 2020/1/31 上午7:55, Reiner Herrmann 写道:
> On Sat, Jan 25, 2020 at 10:45:08PM +0800, Mad Horse wrote:
>> I have not remembered that because --private is used so widely in
>> officially shipped profiles, so I have to inspect them with command like
>>
>>> $ firejail --profile=/etc/firejail/firefox.profile /bin/bash
> Hm, I couldn't find "private" in the firefox(-common) profile.
> Does it work if you start it by giving it a location where it can store
> the private home directory?
> Like: firejail --allusers --private=/foo/bar
> (see also:
> https://github.com/netblue30/firejail/issues/3185#issuecomment-578413651 )
>
> Regards,
> Reiner
Bug#949469: firejail: files and directories in separate /home encrypted with fscrypt inaccessible inside firejail
> Ok, so I assume that you are using --private (because whitelisting your > home directory would not be needed)? > Please mention such details in the initial report, it saves some > roundtrips of asking about your specific use-case. I have not remembered that because --private is used so widely in officially shipped profiles, so I have to inspect them with command like > $ firejail --profile=/etc/firejail/firefox.profile /bin/bash 在 2020/1/25 下午10:39, Reiner Herrmann 写道: > On Sat, Jan 25, 2020 at 10:30:50PM +0800, Mad Horse wrote: >>> Warning: allusers option disabled by private or whitelist option >> Because of this, inside jails started with private or whitelist options, >> /home remains masked, so files encrypted with fscrypt remain inaccessible. > Ok, so I assume that you are using --private (because whitelisting your > home directory would not be needed)? > Please mention such details in the initial report, it saves some > roundtrips of asking about your specific use-case. > It sounds like this is currently not supported, but I'll ask upstream > if they know about a workaround.
Bug#949469: firejail: files and directories in separate /home encrypted with fscrypt inaccessible inside firejail
Hi,
> Warning: allusers option disabled by private or whitelist option
Because of this, inside jails started with private or whitelist options,
/home remains masked, so files encrypted with fscrypt remain inaccessible.
在 2020/1/25 下午8:48, Reiner Herrmann 写道:
> On Sat, Jan 25, 2020 at 08:15:11PM +0800, Mad Horse wrote:
>> Sadly they have no effect, because a tmpfs is mounted on /home, masked
>> over /home/.fscrypt .
>> A case like this can usually be resolved by adding
>>> mkdir
>>> whitelist
>> in profiles, but unfortunately, "mkdir" only works in ${HOME} and /tmp, so
>> it seems to be still unsolvable under current version of firejail.
> I just asked on the upstream tracker about it [0] and already got a
> suggestion by rusty-snake that could help.
> Can you please try the "--allusers" option?
> (It can also be put into profiles)
>
> At least during my test all files/directories from /home
> were than available inside the jail.
>
> [0] https://github.com/netblue30/firejail/issues/3185
Bug#949469: firejail: files and directories in separate /home encrypted with fscrypt inaccessible inside firejail
Hi,
Sadly they have no effect, because a tmpfs is mounted on /home, masked
over /home/.fscrypt .
A case like this can usually be resolved by adding
> mkdir
> whitelist
in profiles, but unfortunately, "mkdir" only works in ${HOME} and /tmp, so
it seems to be still unsolvable under current version of firejail.
在 2020/1/25 下午7:48, Reiner Herrmann 写道:
> Hi,
>
> On Tue, Jan 21, 2020 at 04:42:16PM +0800, Mad Horse wrote:
>> In order to access unlocked files and directories encrypted with
>> fscrypt, their
>> protectors. which lies under /.fscrypt of root and each FS with this feature
>> deployed, should also be accessible.
>>
>> Inside firejail, /.fscrypt could be made accessible with "noblacklist"
>> statement in profile, but there seems no way to introduce /home/.fscrypt
>> into firejail, which cause all file and directory in separate /home
>> encrypted
>> with fscrypt inaccessible inside it.
> the fscrypt files are currently blocked via disable-common.inc:
>
> blacklist ${HOME}/.fscrypt
> blacklist /.fscrypt
> blacklist /home/.fscrypt
>
> (and also via the AppArmor firejail profile, if you use it)
>
> Can you add to your local override disable-common.local that
> these should be removed from the blacklist?
>
> noblacklist ${HOME}/.fscrypt
> noblacklist /.fscrypt
> noblacklist /home/.fscrypt
>
> Kind regards,
> Reiner
Bug#949469: firejail: files and directories in separate /home encrypted with fscrypt inaccessible inside firejail
Package: firejail Version: 0.9.62-2 Severity: normal Dear Maintainer, In order to access unlocked files and directories encrypted with fscrypt, their protectors. which lies under /.fscrypt of root and each FS with this feature deployed, should also be accessible. Inside firejail, /.fscrypt could be made accessible with "noblacklist" statement in profile, but there seems no way to introduce /home/.fscrypt into firejail, which cause all file and directory in separate /home encrypted with fscrypt inaccessible inside it. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (900, 'testing'), (500, 'testing-proposed-updates'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=UTF-8), LANGUAGE=zh_CN:zh (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages firejail depends on: ii libapparmor1 2.13.3-7 ii libc6 2.29-7 Versions of packages firejail recommends: ii firejail-profiles 0.9.62-2 ii iproute2 5.4.0-1 ii iptables 1.8.3-2 ii xauth 1:1.0.10-1 ii xpra 3.0.5+dfsg1-1 ii xserver-xephyr 2:1.20.6-1 firejail suggests no packages. -- no debconf information
Bug#948993: firejail-profiles: profile for transmission-daemon does not whitelist ~/.config/transmission-daemon
Package: firejail-profiles Version: 0.9.62-2 Severity: normal Dear Maintainer, On Debian GNU/Linux, the configuration of transmission-daemon lies in ~/.config/transmission-daemon instead of ~/.config/transmission, which means ~/.config/transmission-daemon should be whitelisted in the profile for transmission-daemon, while in current profile, only ~/.config/transmission is whitelisted, causing the configuration of transmission-daemon is not accessible inside the jail. Currently I walkaround this via transmission-daemon.local. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (900, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=zh_CN.utf8, LC_CTYPE=zh_CN.utf8 (charmap=UTF-8), LANGUAGE=zh_CN.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages firejail-profiles depends on: ii firejail 0.9.62-2 firejail-profiles recommends no packages. firejail-profiles suggests no packages. -- no debconf information
Bug#948558: firejail-profiles: firefox running under firejail cannot load system-wide add-ons
Package: firejail-profiles Version: 0.9.62-2 Severity: normal Dear Maintainer, In current profiles for firefox (maybe for other browsers, too), /usr/share/webext/ is not whitelisted, causing system-wide add-ons installed via apt and dpkg cannot get loaded by firefox running under firejail. A 'whitelist /usr/share/webext/' might be added to profiles for browsers using webext in order to fix this, as I walkaround it by putting this in my ~/.config/firejail/firefox.local . -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (900, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=UTF-8), LANGUAGE=zh_CN.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages firejail-profiles depends on: ii firejail 0.9.62-2 firejail-profiles recommends no packages. firejail-profiles suggests no packages. -- no debconf information
Bug#945000: systemd: Umask set in /etc/login.defs is not honored by systemd user units even if pam_umask is enabled.
Package: systemd Version: 243-5 Severity: important Dear Maintainer, The traditional way to change the default umask (change /etc/login.defs with pam_umask enabled in /etc/pam.d/... ) is broken, for on my does not honor it in user units. This is a bug known by the upstream ( https://github.com/systemd/systemd/issues/6077 ), and currently the only possible walkaround is to override umask for every user unit, as discussed in https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/1685754/comments/21 , which is hard to apply. I may be unable to fix this issue with my own knowledge and resource, but I can report it to you experts at least. -- Package-specific info: -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (900, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.2.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=UTF-8), LANGUAGE=zh_CN.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages systemd depends on: ii adduser 3.118 ii libacl1 2.2.53-5 ii libapparmor1 2.13.3-6 ii libaudit1 1:2.8.5-2 ii libblkid1 2.34-0.1 ii libc6 2.29-3 ii libcap2 1:2.27-1 ii libcryptsetup12 2:2.2.1-1 ii libgcrypt20 1.8.5-3 ii libgnutls30 3.6.10-4 ii libgpg-error0 1.36-7 ii libidn2-0 2.2.0-2 ii libip4tc2 1.8.3-2 ii libkmod2 26-3 ii liblz4-1 1.9.2-2 ii liblzma5 5.2.4-1+b1 ii libmount1 2.34-0.1 ii libpam0g 1.3.1-5 ii libpcre2-8-0 10.32-5+b1 ii libseccomp2 2.4.1-2 ii libselinux1 2.9-3+b1 ii libsystemd0 243-5 ii mount 2.34-0.1 ii util-linux 2.34-0.1 Versions of packages systemd recommends: ii dbus 1.12.16-2 ii libpam-systemd 243-5 Versions of packages systemd suggests: ii policykit-1 0.105-26 pn systemd-container Versions of packages systemd is related to: pn dracut ii initramfs-tools 0.135 ii udev 243-5 -- Configuration Files: /etc/pam.d/systemd-user changed: @include common-account session required pam_selinux.so close session required pam_selinux.so nottys open session required pam_loginuid.so session required pam_limits.so @include common-session-noninteractive session optional pam_systemd.so session optional pam_umask.so -- no debconf information [OVERRIDDEN] /etc/tmpfiles.d/screen-cleanup.conf -> /usr/lib/tmpfiles.d/screen-cleanup.conf --- /usr/lib/tmpfiles.d/screen-cleanup.conf 2017-06-19 06:31:56.0 +0800 +++ /etc/tmpfiles.d/screen-cleanup.conf 2017-06-30 08:33:17.091685640 +0800 @@ -1 +1 @@ -d /run/screen 0777 root utmp +d /run/screen 1777 root utmp [EXTENDED] /etc/systemd/system/display-manager.service -> /etc/systemd/system/display-manager.service.d/umask.conf [EQUIVALENT] /etc/systemd/system/nfdump.service -> /lib/systemd/system/nfdump.service [MASKED] /etc/systemd/system/systemd-rfkill.service -> /lib/systemd/system/systemd-rfkill.service [MASKED] /etc/systemd/system/systemd-rfkill.socket -> /lib/systemd/system/systemd-rfkill.socket [MASKED] /etc/systemd/system/transmission-daemon.service -> /lib/systemd/system/transmission-daemon.service [EXTENDED] /lib/systemd/system/rc-local.service -> /lib/systemd/system/rc-local.service.d/debian.conf [EXTENDED] /lib/systemd/system/systemd-resolved.service -> /lib/systemd/system/systemd-resolved.service.d/resolvconf.conf [EXTENDED] /lib/systemd/system/systemd-timesyncd.service -> /lib/systemd/system/systemd-timesyncd.service.d/disable-with-time-daemon.conf [EXTENDED] /usr/lib/systemd/user/at-spi-dbus-bus.service -> /etc/systemd/user/at-spi-dbus-bus.service.d/umask.conf [EXTENDED] /usr/lib/systemd/user/blueman-applet.service -> /etc/systemd/user/blueman-applet.service.d/umask.conf [EXTENDED] /usr/lib/systemd/user/colord-session.service -> /etc/systemd/user/colord-session.service.d/umask.conf [EXTENDED] /usr/lib/systemd/user/dbus.service -> /etc/systemd/user/dbus.service.d/umask.conf [EXTENDED] /usr/lib/systemd/user/evolution-addressbook-factory.service -> /etc/systemd/user/evolution-addressbook-factory.service.d/umask.conf [EXTENDED] /usr/lib/systemd/user/evolution-calendar-factory.service -> /etc/systemd/user/evolution-calendar-factory.service.d/umask.conf [EXTENDED] /usr/lib/systemd/user/evolution-source-registry.service -> /etc/systemd/user/evolution-source-registry.service.d/umask.conf [EXTENDED] /usr/lib/systemd/user/evolution-user-prompter.service -> /etc/systemd/user/evolution-user-prompter.service.d/umask.conf [EXTENDED] /usr/lib/systemd/user/glib-pacrunner.service -> /etc/systemd/user/glib-pacrunner.service.d/umask.conf [EXTENDED] /usr/lib/systemd/user/gnome-terminal-server.service -> /etc/systemd/user/gnome-terminal-server.service.d/umask.conf [EXTENDED] /usr/lib/systemd/user/gvfs-afc-volume-monitor.service -> /etc/systemd/user/gvfs-afc-volume-monitor.service.d/umask.conf [EXTENDED] /usr/lib/systemd/user/gvfs-daemon.service -> /etc/systemd/user/gvfs-daemon.service.d/umask.conf [EXTENDED]
Bug#943416: linux: Missing modules for newly appeared hardware
Source: linux Version: 5.3.0-1 Severity: wishlist Dear Maintainer, A lot of device drivers introduced after Linux 5 is not built even in 5.3.7-1, including > # CONFIG_MISC_ALCOR_PCI is not set > # CONFIG_USB_NET_AQC111 is not set I wish much newly introduced drivers could be built along with the new upstream kernel release, or is there any policy preventing these new drivers being enabled? -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (900, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=zh_CN.utf8, LC_CTYPE=zh_CN.utf8 (charmap=UTF-8), LANGUAGE=zh_CN.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#942126: gvfs-fuse: /run/user/ID/gvfs/ empty after upgrade
Hello Cesare,
If I try to invoke $ /usr/lib/gvfs/gvfsd-fuse /run/user/${myuid}/gvfs , it
reports:
> fuse: failed to exec fusermount3: No such file or directory
So, the real problem is that gvfs-fuse is hardcoded to call fusermount3 instead
fusermount.
It may be walked around by creating an alternative with
> # update-alternatives --install /bin/fusermount3 fusermount3 /bin/fusermount
> 10
which may means it had better use the alternative system to provide
/bin/fusermount
between fuse"2" and fuse3, and let gvfsd-fuse and other fuse mounters call
/bin/fusermount directly.
Best regard,
Mad Horse
Bug#935973: Acknowledgement (debian-installer: cryptsetup-initramfs will not be installed even when using full-disk encryption.)
This issue is confirmed to exist in the testing weekly build generated on Sep. 2nd 2019.
Bug#935973: debian-installer: cryptsetup-initramfs will not be installed even when using full-disk encryption.
Package: debian-installer Severity: important Dear Maintainer, The package "cryptsetup-initramfs" will not be installed even root file system is configured to be on a logical volume on an LVM PV inside a LUKS, making the installed system stuck in initramfs, unless we manually install cryptsetup- initramfs with rescue mode, or possibly before rebooting from debian-installer when installation is "finished". -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (900, 'testing'), (500, 'testing-proposed-updates'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=zh_CN.utf8, LC_CTYPE=zh_CN.utf8 (charmap=UTF-8), LANGUAGE=zh_CN.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#935972: debian-installer: Package "fuse" installation failed in debian-installer
Package: debian-installer Severity: important Dear Maintainer, The package "fuse" installation failed on postinst when installing with the weekly build testing installer generated on Aug. 26th, after the "tasksel" step, and installation can hardly continue, unless we fix it manually, by chrooting into /target , and running "# apt-get install fuse" on free PTYs. Interestingly, this will succeed while complaining about some module lists is not available. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (900, 'testing'), (500, 'testing-proposed-updates'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=zh_CN.utf8, LC_CTYPE=zh_CN.utf8 (charmap=UTF-8), LANGUAGE=zh_CN.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
