Bug#978931: gssproxy: CVE-2020-12658
Package: gssproxy Followup-For: Bug #978931 Control: tags -1 - security
Bug#968060: axi-cache: string/bytes confusion in display
Package: apt-xapian-index
Version: 0.51
Severity: minor
Tags: patch
Dear Maintainer,
In rdepends output:
rharwood@eesha:~$ axi-cache rdepends apt-xapian-index
apt-xapian-index
Reverse Depends:
b'muon'
b'packagesearch'
b'synaptic'
b'aptitude'
b'python3-apt'
rharwood@eesha:~$
When print() is called on a `bytes` object in python3, it formats it like that
(with the leading 'b' etc.). The smallest fix is probably to change the
print() in do_rdepends() (on line 701) from
print(" ", pkg)
to
print(" ", pkg.decode("utf-8"))
However, this probably shows up other places as well and a more invasive fix
might be better.
Thanks,
--Robbie
-- System Information:
Debian Release: bullseye/sid
APT prefers testing-debug
APT policy: (700, 'testing-debug'), (700, 'testing'), (500,
'unstable-debug'), (500, 'unstable'), (300, 'experimental-debug'), (300,
'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 5.7.0-2-amd64 (SMP w/12 CPU threads)
Locale: LANG=es_US.UTF-8, LC_CTYPE=es_US.UTF-8 (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 apt-xapian-index depends on:
ii python3 3.8.2-3
ii python3-apt 2.1.3
ii python3-debian 0.1.37
ii python3-xapian 1.4.15-1+b1
apt-xapian-index recommends no packages.
Versions of packages apt-xapian-index suggests:
ii python3-xdg 0.26-3
-- no debconf information
Bug#920555: xmobar: compile flag with_alsa to support Volume command
Package: xmobar
Version: 0.33-1
Followup-For: Bug #920555
Users looking for a non-polling solution to ALSA volume may be able to adapt
my script for it:
#!/usr/bin/python3
import re
import subprocess
import sys
r = re.compile(r"\[(\d+)%\].*\[(on|off)\]$")
args = "stdbuf -oL alsactl monitor".split()
p = subprocess.Popen(args, stdout=subprocess.PIPE, stderr=subprocess.STDOUT)
while True:
data = subprocess.check_output(["amixer", "get", "Master"])
vline = data.rsplit(b"\n", 2)[-2].decode("utf-8")
m = r.search(vline)
assert(m)
vol = m.group(1)
onoff = m.group(2)
muted = "%" if onoff == "on" else "M"
sys.stdout.write(f"({vol}{muted})\n")
sys.stdout.flush()
p.stdout.readline() # type: ignore
Thanks,
--Robbie
Bug#966640: build-depends: debhelper-compat (= 13) cannot be satisfied
Source: krb5 Followup-For: Bug #966640 > 13 is the current compatibility level and is provided by the debhelper > package. I think there's something missing from your environment. Could it > be Debian stable instead of unstable, for example? If so, you'll need to > enable backports to get a current debhelper if you want to build the > unstable version of krb5. Hi, no, my system information is as reportbug put it in the footer - testing with unstable and experimental available. Some more information: rharwood@eesha:~$ aptitude versions debhelper i A 13.2 testing,unstable 700 rharwood@eesha:~$ aptitude show debhelper-compat No candidate version found for debhelper-compat Package: debhelper-compat State: not a real package Provided by: debhelper (13.2), debhelper (13.2), debhelper (13.2), debhelper (13.2), debhelper (13.2) rharwood@eesha:~$ sudo aptitude install debhelper=13 Unable to find a version "13" for the package "debhelper" Unable to apply some actions, aborting rharwood@eesha:~$ sudo aptitude install debhelper=13.2 debhelper is already installed at the requested version (13.2) debhelper is already installed at the requested version (13.2) No packages will be installed, upgraded, or removed. 0 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 0 B of archives. After unpacking 0 B will be used. rharwood@eesha:~$ In debian/control, you list the dependency as: Build-Depends: debhelper-compat (= 13) Could it be because 13 != 13.2 ? Thanks, --Robbie
Bug#932298: krb5-admin-server: Confusing error if DES encryption types are enabled
Package: krb5-admin-server Version: 1.17-10 Followup-For: Bug #932298 Control: tags -1 + patch Hi, I believe I fixed this upstream in https://github.com/krb5/krb5/pull/1094 Thanks, --Robbie
Bug#966640: build-depends: debhelper-compat (= 13) cannot be satisfied
Source: krb5 Severity: normal Hi Sam, Ben, Russ, I think the debhelper-compat version is out of date: rharwood@eesha:~$ sudo aptitude build-dep krb5 [sudo] password for rharwood: Unable to satisfy the build-depends: Build-Depends: debhelper-compat (= 13) Unable to apply some actions, aborting rharwood@eesha:~$ Thanks, --Robbie -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (700, 'testing-debug'), (700, 'testing'), (500, 'unstable-debug'), (500, 'unstable'), (300, 'experimental-debug'), (300, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.7.0-1-amd64 (SMP w/12 CPU threads) Locale: LANG=es_US.UTF-8, LC_CTYPE=es_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#966093: Error: default OCI runtime "runc" not found: invalid argument
Package: podman Followup-For: Bug #966093 Dear Maintainer, Nothing in that file is related to the issue. I have reviewed policy.json, and swapaccount has nothing to do with runc/crun nor user namespaces. If this is working as intended, then "Docker-compatible CLI" and "daemon-less alternative to docker" are false advertising. I will note further that here's what happens on Fedora: $ sudo dnf install podman $ podman run -it debian:sid Trying to pull registry.fedoraproject.org/debian:sid... manifest unknown: manifest unknown Trying to pull registry.access.redhat.com/debian:sid... name unknown: Repo not found Trying to pull registry.centos.org/debian:sid... manifest unknown: manifest unknown Trying to pull docker.io/library/debian:sid... Getting image source signatures Copying blob babaea2ea26e done Copying config eeb0ab1eaa done Writing manifest to image destination Storing signatures root@6a791277d543:/# uname -a Linux 6a791277d543 5.6.6-300.fc32.x86_64 #1 SMP Tue Apr 21 13:44:19 UTC 2020 x86_64 GNU/Linux root@6a791277d543:/# Notice how it just works, no configuration or troubleshooting necessary? This is how it should be in Debian too. Thanks, --Robbie
Bug#966093: Error: default OCI runtime "runc" not found: invalid argument
Package: podman Version: 2.0.2+dfsg1-3 Severity: grave Justification: renders package unusable Dear Maintainer, After installing podman, I get: $ podman run -it debian:sid Error: default OCI runtime "runc" not found: invalid argument $ Inspecting the dependencies, I see a dependency on 'crun | runc', and so crun has been picked. Trying to debug further: $ podman --runtime=/usr/bin/crun run -it debian:sid cannot clone: Operation not permitted user namespaces are not enabled in /proc/sys/kernel/unprivileged_userns_clone Error: cannot re-exec process $ (The same result is achieved if I subsequently install runc and remove the --runtime=/usr/bin/crun argument.) It feels like I'm doing something wrong, but reading docs and man pages I am at a loss as to what. Thanks, --Robbie -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (700, 'testing-debug'), (700, 'testing'), (500, 'unstable-debug'), (500, 'unstable'), (300, 'experimental-debug'), (300, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.7.0-1-amd64 (SMP w/12 CPU threads) Locale: LANG=es_US.UTF-8, LC_CTYPE=es_US.UTF-8 (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 podman depends on: ii conmon 2.0.9-1 ii containernetworking-plugins 0.8.6-2 ii crun 0.14.1+dfsg-1 ii libc62.31-1 ii libdevmapper1.02.1 2:1.02.167-1+b1 ii libgpgme11 1.13.1-9 ii libseccomp2 2.4.3-1+b1 Versions of packages podman recommends: ii buildah 1.11.6-2 pn fuse-overlayfs ii slirp4netns 1.0.1-1 ii tini0.18.0-1+b1 ii uidmap 1:4.8.1-1 Versions of packages podman suggests: pn containers-storage -- no debconf information
Bug#959186: gssproxy: kerberos credentials not looked into the classical file
Package: gssproxy Followup-For: Bug #959186 Control: Close -1
Bug#958492: xfonts-terminus: Provide gtk-compatible fonts
Package: xfonts-terminus Version: 4.40-2 Severity: grave Justification: renders package unusable Dear Maintainer, With pango 1.44, bitmap fonts are no longer supported: https://gitlab.gnome.org/GNOME/pango/issues/386 This means that trying to render Terminus in gtk applications looks like... well, this: https://rharwood.fedorapeople.org/screenshots/2020-04-22-162841_1920x1080_scrot.png The Fedora maintainer has adapted the terminus-fonts package to provide .otb files in more recent versions, using the approach described there and in https://bugzilla.redhat.com/show_bug.cgi?id=1753295 Thanks, --Robbie -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (700, 'testing-debug'), (700, 'testing'), (500, 'unstable-debug'), (500, 'unstable'), (300, 'experimental-debug'), (300, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.6.0-trunk-rt-amd64 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=es_US.UTF-8, LC_CTYPE=es_US.UTF-8 (charmap=UTF-8), LANGUAGE=es_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages xfonts-terminus depends on: ii xfonts-utils 1:7.7+6 xfonts-terminus recommends no packages. Versions of packages xfonts-terminus suggests: ii xfonts-terminus-oblique 4.40-2 ii xserver-xorg [xserver] 1:7.7+20 -- no debconf information
Bug#952757: mypy(1): build errors in man page
Package: mypy Version: 0.761-1 Severity: minor Dear Maintainer, The mypy man page (mypy(1)) has a lot of what appar to be build errors from tranlation from rst to nroff. Here's the first one: ``` The directories are checked recursively to find Python source files. System Message: ERROR/3 (debian/mypy_options.rst:, line 3) Unknown directive type "program". .. program:: mypy OPTIONS ``` Thanks, --Robbie -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (700, 'testing-debug'), (700, 'testing'), (500, 'unstable-debug'), (500, 'unstable'), (300, 'experimental-debug'), (300, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-4-rt-amd64 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=es_US.UTF-8, LC_CTYPE=es_US.UTF-8 (charmap=UTF-8), LANGUAGE=es_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mypy depends on: ii python3 3.7.5-3 ii python3-mypy 0.761-1 mypy recommends no packages. Versions of packages mypy suggests: pn mypy-doc -- no debconf information
Bug#942399: rxvt-unicode: server lockup making all clients unresponsive
Package: rxvt-unicode Version: 9.22-6+b2 Followup-For: Bug #942399 Dear Maintainer, I've gotten a few more of these lockups (two today). They all look about the same. Here's one of the tracebacks: (gdb) thread apply all bt Thread 1 (Thread 0x7f7a8ee7f880 (LWP 11279)): #0 0x7f7a8fd6328e in __libc_read (fd=4, buf=buf@entry=0x7ffc5bc2ff20, nbytes=nbytes@entry=536) at ../sysdeps/unix/sysv/linux/read.c:26 #1 0x55a8bdabcd63 in read (__nbytes=536, __buf=0x7ffc5bc2ff20, __fd=) at /usr/include/x86_64-linux-gnu/bits/unistd.h:44 #2 0x55a8bdabcd63 in serve() () at ./../libptytty/src/proxy.C:158 #3 0x55a8bdabd0a7 in ptytty::use_helper() () at ./../libptytty/src/proxy.C:268 #4 0x55a8bdabd111 in ptytty::use_helper() () at ./../libptytty/src/proxy.C:318 #5 0x55a8bdabd111 in ptytty::init() () at ./../libptytty/src/proxy.C:318 #6 0x55a8bda99349 in main(int, char**) (argc=3, argv=0x7ffc5bc30328) at rxvtd.C:230 (gdb) Causing the read call to immediately return launches us back into an epoll_wait (still on fd=4). Unsurprisingly, close(4) then caused the daemon to crash, terminating all clients. Thanks, --Robbie -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (700, 'testing-debug'), (700, 'testing'), (500, 'unstable-debug'), (500, 'unstable'), (300, 'experimental-debug'), (300, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.2.0-3-rt-amd64 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=es_US.UTF-8, LC_CTYPE=es_US.UTF-8 (charmap=UTF-8), LANGUAGE=es_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages rxvt-unicode depends on: ii base-passwd 3.5.46 ii libc6 2.29-2 ii libfontconfig12.13.1-2+b1 ii libgcc1 1:9.2.1-8 ii libgdk-pixbuf2.0-02.40.0+dfsg-1 ii libglib2.0-0 2.62.1-1 ii libperl5.30 5.30.0-8 ii libstartup-notification0 0.12-6 ii libx11-6 2:1.6.8-1 ii libxft2 2.3.2-2 ii libxrender1 1:0.9.10-1 ii ncurses-base 6.1+20190803-1 ii ncurses-term 6.1+20190803-1 Versions of packages rxvt-unicode recommends: ii fonts-dejavu2.37-1 ii fonts-ipaexfont-gothic [fonts-japanese-gothic] 00401-1 ii fonts-ipafont-gothic [fonts-japanese-gothic]00303-19 ii fonts-vlgothic [fonts-japanese-gothic] 20141206-5 Versions of packages rxvt-unicode suggests: ii sensible-utils 0.0.12 -- no debconf information
Bug#942399: rxvt-unicode: server lockup making all clients unresponsive
Package: rxvt-unicode Version: 9.22-6+b2 Severity: important Dear Maintainer, Occasionally, I will see urxvtc process become unresponsive to keyboard input. It seems like processes may still be able to update their panes - my mosh session keeps updating the screen, for instance. Here's a backgrace, for whatever it's worth: (gdb) thread apply all bt Thread 1 (Thread 0x7fde1b89a880 (LWP 11263)): #0 0x7fde1c77b28e in __libc_read (fd=4, buf=buf@entry=0x7ffc76da48c0, nbytes=nbytes@entry=536) at ../sysdeps/unix/sysv/linux/read.c:26 #1 0x560eae378d63 in read (__nbytes=536, __buf=0x7ffc76da48c0, __fd=) at /usr/include/x86_64-linux-gnu/bits/unistd.h:44 #2 0x560eae378d63 in serve() () at ./../libptytty/src/proxy.C:158 #3 0x560eae3790a7 in ptytty::use_helper() () at ./../libptytty/src/proxy.C:268 #4 0x560eae379111 in ptytty::use_helper() () at ./../libptytty/src/proxy.C:318 #5 0x560eae379111 in ptytty::init() () at ./../libptytty/src/proxy.C:318 #6 0x560eae355349 in main(int, char**) (argc=3, argv=0x7ffc76da4cc8) at rxvtd.C:230 (gdb) I can spawn new urxvtc processes (using urxvtcd); they display the shell prompt but do nothing further. (Had to use a different emulator to run reportbug.) Thanks, --Robbie -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (700, 'testing-debug'), (700, 'testing'), (500, 'unstable-debug'), (500, 'unstable'), (300, 'experimental-debug'), (300, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.2.0-3-rt-amd64 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=es_US.UTF-8, LC_CTYPE=es_US.UTF-8 (charmap=UTF-8), LANGUAGE=es_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages rxvt-unicode depends on: ii base-passwd 3.5.46 ii libc6 2.29-2 ii libfontconfig12.13.1-2+b1 ii libgcc1 1:9.2.1-8 ii libgdk-pixbuf2.0-02.40.0+dfsg-1 ii libglib2.0-0 2.62.1-1 ii libperl5.30 5.30.0-6 ii libstartup-notification0 0.12-6 ii libx11-6 2:1.6.8-1 ii libxft2 2.3.2-2 ii libxrender1 1:0.9.10-1 ii ncurses-base 6.1+20190803-1 ii ncurses-term 6.1+20190803-1 Versions of packages rxvt-unicode recommends: ii fonts-dejavu2.37-1 ii fonts-ipaexfont-gothic [fonts-japanese-gothic] 00401-1 ii fonts-ipafont-gothic [fonts-japanese-gothic]00303-19 ii fonts-vlgothic [fonts-japanese-gothic] 20141206-5 Versions of packages rxvt-unicode suggests: ii sensible-utils 0.0.12 -- no debconf information
Bug#941751: mlterm requires additional keypress to exit
Package: mlterm Version: 3.8.8-3 Severity: normal Dear Maintainer, When mlterm is running a shell (e.g., mlterm -e /bin/bash), and the shell terminates (e.g., exit, C-d), mlterm requires another keypress before it exits. (Any keypress, as far as I can tell.) This is true for both bash and zsh, though it may not be true for dash. (Other terminal emulators such as xterm and urxvt do not have this behavior.) Thanks, --Robbie -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (700, 'testing-debug'), (700, 'testing'), (500, 'unstable-debug'), (500, 'unstable'), (300, 'experimental-debug'), (300, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.2.0-3-rt-amd64 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=es_US.UTF-8, LC_CTYPE=es_US.UTF-8 (charmap=UTF-8), LANGUAGE=es_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mlterm depends on: ii libc6 2.29-2 ii libfreetype62.9.1-4 ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1 ii libglib2.0-02.60.6-2 ii libx11-62:1.6.8-1 ii mlterm-common 3.8.8-3 Versions of packages mlterm recommends: ii mlterm-tools 3.8.8-3 Versions of packages mlterm suggests: ii fonts-arphic-bsmi00lp 2.10-18 ii fonts-arphic-gbsn00lp 2.11-16 ii fonts-freefont-ttf 20120503-9 ii fonts-ipaexfont-gothic [fonts-japanese-gothic] 00401-1 ii fonts-ipafont-gothic [fonts-japanese-gothic]00303-19 ii fonts-noto-cjk 1:20190410+repack1-1 ii fonts-vlgothic [fonts-japanese-gothic] 20141206-5 pn mlterm-im-m17nlib pn mlterm-im-scim pn mlterm-im-uim pn t1-cyrillic pn unifont pn xfonts-efont-unicode -- no debconf information
Bug#932854: initramfs-tools-core: Please depend on logsave
Package: initramfs-tools Version: 0.133 Followup-For: Bug #932854 Control: severity -1 critical Raising severity of this since it renders the machine unbootable. -- Package-specific info: -- initramfs sizes -rw-r--r-- 1 root root 45M Jul 24 12:59 /boot/initrd.img-4.19.0-5-amd64 -rw-r--r-- 1 root root 45M Jul 24 13:00 /boot/initrd.img-4.19.0-5-rt-amd64 -- /proc/cmdline BOOT_IMAGE=/vmlinuz-4.19.0-5-rt-amd64 root=/dev/mapper/seton-root ro -- resume RESUME=none -- /proc/filesystems btrfs ext3 ext2 ext4 -- lsmod Module Size Used by cmac 16384 1 uvcvideo 118784 0 videobuf2_vmalloc 16384 1 uvcvideo videobuf2_memops 16384 1 videobuf2_vmalloc videobuf2_v4l2 28672 1 uvcvideo videobuf2_common 53248 2 videobuf2_v4l2,uvcvideo videodev 212992 3 videobuf2_v4l2,uvcvideo,videobuf2_common media 45056 2 videodev,uvcvideo ctr16384 4 ccm20480 6 nft_chain_route_ipv416384 1 xt_CHECKSUM16384 1 nft_chain_nat_ipv4 16384 4 ipt_MASQUERADE 16384 1 nf_nat_ipv416384 2 ipt_MASQUERADE,nft_chain_nat_ipv4 nf_nat 81920 1 nf_nat_ipv4 bnep 24576 2 xt_conntrack 16384 1 nf_conntrack 217088 4 xt_conntrack,nf_nat,ipt_MASQUERADE,nf_nat_ipv4 nf_defrag_ipv6 20480 1 nf_conntrack nf_defrag_ipv4 16384 1 nf_conntrack ipt_REJECT 16384 1 nf_reject_ipv4 16384 1 ipt_REJECT btusb 53248 0 btrtl 16384 1 btusb btbcm 16384 1 btusb btintel24576 1 btusb bluetooth 647168 26 btrtl,btintel,btbcm,bnep,btusb nft_counter16384 16 drbg 28672 1 ansi_cprng 16384 0 ecdh_generic 24576 2 bluetooth xt_tcpudp 16384 2 nft_compat 20480 13 tun49152 1 bridge192512 0 stp16384 1 bridge llc16384 2 bridge,stp devlink77824 0 nf_tables 143360 90 nft_chain_route_ipv4,nft_compat,nft_chain_nat_ipv4,nft_counter nfnetlink 16384 2 nft_compat,nf_tables binfmt_misc20480 1 intel_rapl 24576 0 snd_hda_codec_hdmi 57344 1 intel_powerclamp 16384 0 mei_wdt16384 0 coretemp 16384 0 arc4 16384 2 kvm_intel 245760 0 iwlmvm299008 0 kvm 737280 1 kvm_intel mac80211 843776 1 iwlmvm irqbypass 16384 1 kvm snd_soc_skl 114688 0 snd_hda_codec_realtek 122880 1 intel_cstate 16384 0 joydev 24576 0 snd_soc_skl_ipc73728 1 snd_soc_skl snd_hda_codec_generic86016 1 snd_hda_codec_realtek snd_soc_sst_ipc16384 1 snd_soc_skl_ipc snd_soc_sst_dsp36864 1 snd_soc_skl_ipc snd_hda_ext_core 28672 1 snd_soc_skl snd_soc_acpi_intel_match24576 1 snd_soc_skl intel_uncore 139264 0 snd_soc_acpi 16384 2 snd_soc_acpi_intel_match,snd_soc_skl iwlwifi 241664 1 iwlmvm sg 36864 0 wmi_bmof 16384 0 intel_rapl_perf16384 0 serio_raw 16384 0 snd_soc_core 253952 1 snd_soc_skl pcspkr 16384 0 rtsx_pci_ms20480 0 snd_compress 24576 1 snd_soc_core thinkpad_acpi 106496 1 cfg80211 782336 3 iwlmvm,iwlwifi,mac80211 memstick 16384 1 rtsx_pci_ms nvram 16384 1 thinkpad_acpi battery20480 1 thinkpad_acpi ac 16384 0 snd_hda_intel 45056 3 iTCO_wdt 16384 0 rfkill 28672 7 bluetooth,thinkpad_acpi,cfg80211 iTCO_vendor_support16384 1 iTCO_wdt snd_hda_codec 151552 4 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec_realtek snd_hda_core 94208 7 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_ext_core,snd_hda_codec,snd_hda_codec_realtek,snd_soc_skl snd_hwdep 20480 1 snd_hda_codec snd_pcm 114688 7 snd_hda_codec_hdmi,snd_hda_intel,snd_hda_ext_core,snd_hda_codec,snd_soc_core,snd_soc_skl,snd_hda_core tpm_tis16384 0 evdev 28672 31 tpm_tis_core 20480 1 tpm_tis snd_timer 36864 1 snd_pcm tpm65536 2 tpm_tis,tpm_tis_core snd98304 17 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hwdep,snd_hda_intel,snd_hda_codec,snd_hda_codec_realtek,snd_timer,snd_compress,thinkpad_acpi,snd_soc_core,snd_pcm pcc_cpufreq16384 0 rng_core 16384 1 tpm mei_me 49152 1 soundcore 16384 1 snd mei 118784 3
Bug#932132: libkrb5-3: Don't require all enctypes in a keytab to be valid
Package: libkrb5-3 Version: 1.17-4 Severity: normal Tags: patch upstream Hi Sam, Ben, Russ, I really appreciate your assistance in backporting the 1DES-removal patchset. I wanted to make sure you were aware of [1]: this fixes a bug where having an invalid enctype in a keytab would cause credential acquisition from the keytab to fail. This becomes a problem because the 1DES enctypes are considered "invalid" after their removal. Hopefully this doesn't actually affect anyone. (I only found it because I removed 3DES as well in Fedora, which seems to be more common.) Thanks, --Robbie 1: https://github.com/krb5/krb5/pull/952/commits/38be1a0a31a6104cdf8c8d72828905775f6d6636
