Bug#1062724: node-cbor: cbor2comment throws exception on decoding null
Package: node-cbor Version: 8.1.0+dfsg+~cs5.2.1-3 Severity: normal File: /usr/bin/cbor2comment cbor2comment can throw an exception when a null is deserialized: $ cat >data <<-EOF AKViaWQAaHNlbGVjdG9yoWRwYXRoTi9tZW1vcnkvdmF1bHQvZ3JlY3Vyc2WhZ2Jvb2xlYW71ZGtp bmRqY3JlZGVudGlhbGRib2R5rGh1c2VybmFtZaFnbGl0ZXJhbENmb29mc2VjcmV0oWNhbnn2aGF1 dGh0eXBloWNhbnn2ZGtpbmShZ2xpdGVyYWxjYXBpaHByb3RvY29soWdsaXRlcmFsZWh0dHBzZGhv c3ShZ2xpdGVyYWxvZ2l0LmV4YW1wbGUuY29tZXRpdGxloWdsaXRlcmFseB1HaXQ6IGh0dHBzOi8v Z2l0LmV4YW1wbGUuY29tL2tkZXNjcmlwdGlvbqFjYW559mRwYXRooWNhbnn2Z3NlcnZpY2WhZ2xp dGVyYWxjZ2l0ZWV4dHJhoGJpZKFnbGl0ZXJhbFiAODhkMmQ3Njc4YzEyNzdmODFiMzhmZWJkOWQ5 M2Y0ZDc0ZGY4OGYyNzIwOTYwMzA4YTFjY2VjZmI1N2QzNjVmNTNiMTAyMjc2YmQ1YjQ0MjcwMjkz ZDQzNDU4M2RkMmVmNmMxZGViODdmYzI5NTA4YTc2YjI3YjA3OTgyNmI3MDYK EOF $ base64 -d data | cbor2comment [Some data...] f6 -- {Val:0}, TypeError: Cannot read properties of null (reading 'Symbol(nodejs.util.inspect.custom)') at Object.cborValueToString (/usr/share/nodejs/cbor/lib/utils.js:246:21) at Commented._on_value (/usr/share/nodejs/cbor/lib/commented.js:336:23) at Decoder.emit (node:events:517:28) at Decoder._parse (/usr/share/nodejs/cbor/lib/decoder.js:555:12) at _parse.next () at Decoder._transform (/usr/share/nodejs/cbor/vendor/binary-parse-stream/index.js:53:29) at Transform._write (node:internal/streams/transform:175:8) at writeOrBuffer (node:internal/streams/writable:392:12) at _write (node:internal/streams/writable:333:10) at Writable.write (node:internal/streams/writable:337:10) I expected cbor2comment to print the data, including the null, without throwing an exception or truncating the dump. I should note that cbor2json works, but because my data structure uses byte strings heavily, the dump is effectively unreadable. I have not found other non-null data that triggers an error. In case it is useful to know, the data structure was serialized using the Rust library serde_cbor. It's test data and is not sensitive, so feel free to share it, add it to the testsuite, etc. I believe this may be fixed with PR #188 upstream (in v9.0.2), but I'm unsure. In any event, I expect it's easy to verify one way or the other with the steps above. -- System Information: Debian Release: trixie/sid APT prefers oldstable-security APT policy: (500, 'oldstable-security'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.6.9-amd64 (SMP w/20 CPU threads; PREEMPT) Kernel taint flags: TAINT_USER, TAINT_WARN Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages node-cbor depends on: ii node-bignumber 9.1.1-1 ii node-commander 9.4.1-1 ii nodejs 18.19.0+dfsg-6 node-cbor recommends no packages. node-cbor suggests no packages. -- no debconf information -- brian m. carlson (he/him or they/them) Toronto, Ontario, CA signature.asc Description: PGP signature
Bug#1054622: im-config: can set GTK_IM_MODULE to xim, which causes GTK 4 to complain
On 2023-10-26 at 22:51:19, Gunnar Hjalmarsson wrote: > On 2023-10-26 23:51, brian m. carlson wrote: > > I have a system with Zoom installed, which necessitates installing > > ibus, which I don't want to use (because it overrides my shortcut > > keys without consent). Thus, the advice I've received is to install > > im-config and use to set the module to "xim". > > That's bad advice. Where did you get it? > > Don't set it to "xim", set it to "none" instead, which means that im-config > does not touch any environment variables (and does not launch ibus-daemon). I believe I got it when I filed a bug report on ibus about some bug where it affected my input in some way. I don't recall, since it's been some time. > > I don't think, given that GTK+ 4 is used for a wide variety of > > software in Debian, that it's safe to set GTK_IM_MODULE to "xim" > > anymore, and im-config needs to not do that. > > Your observation is not a sufficient reason to conclude that "xim" is never > useful and should be removed as an option. im-config does not set that > option automatically, but only if the user chooses it explicitly. In your > case due to a bad advice. ;) > > So I'm inclined to close this bug as a "wontfix", but await possible further > input on the matter. I'd argue that setting any environment variables that make programs scream to the terminal is not okay. I'm fine with im-config setting any value that doesn't do that. -- brian m. carlson (he/him or they/them) Toronto, Ontario, CA signature.asc Description: PGP signature
Bug#1054622: im-config: can set GTK_IM_MODULE to xim, which causes GTK 4 to complain
none -- System Information: Debian Release: trixie/sid APT prefers oldstable-security APT policy: (500, 'oldstable-security'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-1-amd64 (SMP w/20 CPU threads; PREEMPT) Kernel taint flags: TAINT_USER, TAINT_WARN Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages im-config depends on: ii gettext-base 0.21-13+b1 Versions of packages im-config recommends: ii whiptail0.52.23-1+b1 ii x11-common 1:7.7+23 ii zenity 3.44.2-1 im-config suggests no packages. -- no debconf information -- brian m. carlson (he/him or they/them) Toronto, Ontario, CA signature.asc Description: PGP signature
Bug#1021339: Offer to help with some neovim packaging
Hey, I noticed that there's some dependencies that need to be packaged for Debian in order to update to the latest neovim. I'm not a Debian developer, but I'm familiar enough with Debian packaging and such. Is there a way I can contribute to packaging the necessary dependencies or helping in some other way with the upgrade to a newer version of Neovim? (This isn't a long-term commitment, just some help for the immediate upgrade.) I do already have a salsa.debian.org account, so if you give me a little bit of direction as to the tooling you'd like to use and/or an example of how it's done (say, another repo), I can take it from there. -- brian m. carlson (he/him or they/them) Toronto, Ontario, CA signature.asc Description: PGP signature
Bug#1040507: golang-1.21-go: downloads and runs binaries from the Internet without permission
Package: golang-1.21-go Version: 1.21~rc2-2 Severity: grave Tags: security Go 1.21 provides the `GOTOOLCHAIN` environment variable and associated functionality[0]. As part of this code, if go.mod indicates that a newer version of Go is required than the current toolchain supports, it proceeds by default to attempt to download a toolchain from the Internet and runs it without prompting the user. It is unclear what, if any cryptographic verification it performs, especially if the user has disabled GOPROXY and GOSUMDB for privacy reasons. As far as I know, the Go core team does not sign Linux binaries cryptographically, so at best the data would be verified by a hash, which is not sufficient. Debian itself uses a strong cryptographic signature for APT archives. In addition, it's possible that a newer version of the toolchain might contain some vulnerability which is not present in the current toolchain, and therefore might expose the user to new vulnerabilities that are not patched. This is not at all far-fetched, since Go is known to have regressions all the time, so security-based regressions are not at all out of the question. I don't believe this is an appropriate way for software distributed in Debian to behave, especially by default, and I'd like to request that it be patched out for security reasons. Steps to reproduce: 1. Clone a Go project (e.g., Git LFS). 2. Update go.mod to state "go 1.22". 3. Run /usr/lib/go-1.21/bin/go build 4. Notice the following output: go: downloading go1.22 (linux/amd64) go: download go1.22 for linux/amd64: toolchain not available [0] https://tip.golang.org/doc/toolchain -- System Information: Debian Release: trixie/sid APT prefers oldstable-security APT policy: (500, 'oldstable-security'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.3.0-1-amd64 (SMP w/20 CPU threads; PREEMPT) Kernel taint flags: TAINT_USER, TAINT_WARN Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages golang-1.21-go depends on: ii golang-1.21-src 1.21~rc2-2 Versions of packages golang-1.21-go recommends: ii g++ 4:12.3.0-1 ii gcc 4:12.3.0-1 ii libc6-dev 2.37-3 ii pkg-config1.8.1-1 ii pkgconf [pkg-config] 1.8.1-1 Versions of packages golang-1.21-go suggests: pn bzr | brz ii ca-certificates 20230311 ii git 1:2.40.1+next.20230427-1 pn mercurial pn subversion -- no debconf information -- brian m. carlson (he/him or they/them) Toronto, Ontario, CA signature.asc Description: PGP signature
Bug#1039952: alacritty: broken rendering with Source Code Pro
Package: alacritty Version: 0.11.0-4 Severity: normal Tags: upstream fixed-upstream If the user has configured Source Code Pro as the terminal font, then text is rendered very tiny and squashed at the top of the window. To reproduce: 1. Install texlive-fonts-extra. 2. mkdir -p ~/.fonts 3. ln -s /usr/share/texlive/texmf-dist/fonts/opentype/adobe ~/.fonts 4. Run fc-cache. 5. Modify the configuration file to contain this block: font: normal: family: Source Code Pro style: Regular 6. Restart Alacritty if `live_config_reload` isn't specified. 7. Notice that the text is tiny and squashed at the top of the terminal and you can't read anything at all. I believe this is fixed in 0.12.0 and was tracked upstream at https://github.com/alacritty/alacritty/issues/6048. This will probably be fixed simply by updating Alacritty to the latest version, so it would be great if that could happen. -- System Information: Debian Release: trixie/sid APT prefers oldstable-security APT policy: (500, 'oldstable-security'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.3.0-1-amd64 (SMP w/20 CPU threads; PREEMPT) Kernel taint flags: TAINT_USER, TAINT_WARN Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages alacritty depends on: ii libc6 2.36-9 ii libfontconfig1 2.14.1-4 ii libfreetype62.12.1+dfsg-5 ii libgcc-s1 13.1.0-6 ii libxcb1 1.15-1 alacritty recommends no packages. alacritty suggests no packages. -- no debconf information -- brian m. carlson (he/him or they/them) Toronto, Ontario, CA signature.asc Description: PGP signature
Bug#1035679: [Pkg-zsh-devel] Bug#1035679: zsh: can misprocess continue in a loop
On 2023-05-08 at 00:58:24, Axel Beckert wrote: > brian m. carlson wrote: > > This breaks the Git testsuite under zsh's sh mode, > > Hmmm, actually, your example code shows "set" for me even without sh > emulation mode: > > → zsh continue.sh > set > → zsh --emulate sh continue.sh > set Correct. The Git testsuite only runs under sh mode, not zsh mode, but it affects all modes. > > which was formerly passing. > > When was "formerly", i.e. in which package or upstream version? Git 2.25. It may be that Git has changed the testsuite to make use of that syntax between now and then, but as of that revision, it passed. > > since the release cycle tends to be long > > Well, 5.9 is out for quite a while already. So I think we can expect a > new release before the the Debian 13 release. ;-) > > But yeah, I think we can cherry-pick this from upstream after the > Bookworm release. Great, I appreciate that. > > and it prevents the shell from being effectively used as a POSIX sh. > > Well, zsh's POSIX mode is officially declared as being incomplete and > it's IIRC also not recommended to actually use it or at least not rely > on it. zsh should be able to run as a POSIX sh. The reason that we only support sh mode in Git is that we rely on every command in a pipeline being run in a subshell, since we only recently introduced the use of `local` in the shell and otherwise our variables get messed up. -- brian m. carlson (he/him or they/them) Toronto, Ontario, CA signature.asc Description: PGP signature
Bug#1035679: zsh: can misprocess continue in a loop
Package: zsh Version: 5.9-4+b1 Severity: normal Tags: patch If a continue occurs in an && chain inside a loop, the continue is not effective. For example, if you save the following as foo.sh: msg=unset for x in 1 2 3 4 5; do continue && msg=set && print Not executed print Not executed, neither. done echo $msg The output should be "unset", but zsh prints "set": $ bash foo.sh unset $ dash foo.sh unset $ zsh foo.sh set This breaks the Git testsuite under zsh's sh mode, which was formerly passing. There's a patch upstream at https://github.com/zsh-users/zsh/commit/12e5db145b098a62ff11b88eea26f473ea2ecdcf. It would be great if this could be backported to zsh in Debian, since the release cycle tends to be long and it prevents the shell from being effectively used as a POSIX sh. -- Package-specific info: Packages which provide vendor completions: Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-=-===--=== ii alacritty 0.11.0-4amd64Fast, cross-platform, OpenGL terminal emulator ii bubblewrap0.8.0-2 amd64utility for unprivileged chroot and namespace manipulation ii containerd1.6.20~ds1-1+b1 amd64open and reliable container runtime ii curl 7.88.1-9amd64command line tool for transferring data with URL syntax ii docker.io 20.10.24+dfsg1-1+b2 amd64Linux container runtime ii dpkg-dev 1.21.21 all Debian package development tools ii gh2.23.0+dfsg1-1 amd64GitHub CLI, GitHub’s official command line tool ii pulseaudio-utils 16.1+dfsg1-2+b1 amd64Command line tools for the PulseAudio sound server ii qpdf 11.3.0-1amd64tools for transforming and inspecting PDF files ii systemd 252.6-1 amd64system and service manager ii systemd-container 252.6-1 amd64systemd container/nspawn tools ii systemd-resolved 252.6-1 amd64systemd DNS resolver ii tmuxinator3.0.5-1 all Create and manage tmux sessions easily ii udev 252.6-1 amd64/dev/ and hotplug management daemon ii vagrant 2.3.4+dfsg-1all Tool for building and distributing virtualized development environments ii vlc-bin 3.0.18-2amd64binaries from VLC The following files were modified: /etc/systemd/resolved.conf dpkg-query: no path found matching pattern /usr/share/zsh/vendor-functions/ -- System Information: Debian Release: 12.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-6-amd64 (SMP w/20 CPU threads; PREEMPT) Kernel taint flags: TAINT_USER, TAINT_WARN Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages zsh depends on: ii debianutils 5.7-0.4 ii libc62.36-9 ii libcap2 1:2.66-3 ii libtinfo66.4-2 ii zsh-common 5.9-4 Versions of packages zsh recommends: ii libc6 2.36-9 ii libgdbm6 1.23-3 ii libncursesw6 6.4-2 ii libpcre3 2:8.39-15 Versions of packages zsh suggests: pn zsh-doc -- no debconf information -- brian m. carlson (he/him or they/them) Toronto, Ontario, CA signature.asc Description: PGP signature
Bug#1028158: atril: prints messages to the console
Package: atril Version: 1.26.0-2 Severity: normal I typically compose letters, documents, and other things I turn into PDFs with a text editor and convert them at the terminal using Make. Once I've converted them to a PDF, I then open them using "atril FILE-NAME &" from the shell so I can view them while I continue to work on them using the command line. However, atril prints a message like the following when I do so: (atril:454002): EggSMClient-WARNING **: 21:15:31.545: Failed to connect to the session manager: Could not open network socket Such messages are unwanted because they clutter up my terminal and interfere with the prompt and other running programs. I've in the past asked GTK+ and its appurtenant libraries to avoid printing non-user-caused warnings to the console by default, but they've chosen not to, instead preferring to have individual programs address these issues, so I'm filing a bug report here. Note that I am running MATE and have mate-session running, and my sessions are correctly saved with the session manager, so I believe the message to be generally in error. In any event, Atril is fully functional (and I'm otherwise happy with the way it works), so I don't think a diagnostic is needed here. -- System Information: Debian Release: bookworm/sid APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.0.0-2-amd64 (SMP w/20 CPU threads; PREEMPT) Kernel taint flags: TAINT_USER, TAINT_WARN Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages atril depends on: ii atril-common 1.26.0-2 ii dconf-gsettings-backend [gsettings-backend] 0.40.0-4 ii libatk1.0-0 2.46.0-4 ii libatrildocument31.26.0-2 ii libatrilview31.26.0-2 ii libc62.36-7 ii libcaja-extension1 1.26.1-1 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1 ii libglib2.0-0 2.74.4-1 ii libgtk-3-0 3.24.35-3 ii libice6 2:1.0.10-1 ii libsecret-1-00.20.5-3 ii libsm6 2:1.2.3-1 ii libxml2 2.9.14+dfsg-1.1+b2 ii shared-mime-info 2.2-1 Versions of packages atril recommends: ii dbus-user-session [default-dbus-session-bus] 1.14.4-1 ii dbus-x11 [dbus-session-bus] 1.14.4-1 ii gvfs 1.50.2-2 Versions of packages atril suggests: ii caja 1.26.1-1 ii poppler-data 0.4.11-1 pn unrar -- no debconf information -- brian m. carlson (he/him or they/them) Toronto, Ontario, CA signature.asc Description: PGP signature
Bug#1023778: TMPDIR behaviour in maintainer scripts [was: Re: Bug#1023778: mysql-server-8.0: fails to restart on upgrade with libpam-tmpdir]
On 2022-11-10 at 16:37:53, Tollef Fog Heen wrote: > ]] Robie Basak > > > But are you in essence saying that libpam-tmpdir requires that *every > > maintainer script* that runs things as non-root, or starts processes > > that do that, unset TMPDIR first? > > I think it's more wide than that: If you change UID, you need to > sanitise the environment. Your HOME is likely to be wrong. PATH might > very well be pointing at directories which are not appropriate for the > user you're changing the UID to, etc. I believe this is the best practice. For example, sudo typically passes through only a handful of environment variables, such as TERM, to avoid things like insecure PATH entries. For example, if MySQL invoked a binary in PATH and I had a custom script named the same thing that had insecure behaviour when invoked as another user, that would be bad. OpenSSH also sanitizes the environment passed over the connection. Without getting into a debate about systemd, this is one the pieces of functionality it provides, since it runs binaries in a clean environment. You can probably get most of that in a sysvinit script by using `env -i` with a handful of environment variables specifically overridden if necessary. Then it would be very obvious what dependencies the binary had on the outside environment. > > I think the answer to this should probably be established by the > > libpam-tmpdir maintainer and documented first, for fear of someone else > > later coming along and saying that the maintainer script incorrectly > > ignores TMPDIR because we started ignoring it to resolve this bug. So I > > copied debian-devel@ for comment. > > I'm not sure this is libpam-tmpdir specific, but rather a bit more > general: what are the expectations that maintainer scripts can have > about the environment they're running in, and how do we make those > expectations hold? This should probably then be documented in policy. I agree documentation here is helpful. For reference, this was an invocation from `sudo aptitude` as part of a normal package upgrade, which I think is a relatively common situation to be in. Possibly also an initscript helper which enables developers to do the right thing automatically, or a flag to start-stop-daemon, or other tooling would be beneficial to help people easily solve this problem without thinking too much about it. -- brian m. carlson (he/him or they/them) Toronto, Ontario, CA signature.asc Description: PGP signature
Bug#1023778: mysql-server-8.0: fails to restart on upgrade with libpam-tmpdir
f8 Versions of packages mysql-server-8.0 suggests: ii bsd-mailx [mailx] 8.1.2-0.20220412cvs-1 pn tinyca -- brian m. carlson (he/him or they/them) Toronto, Ontario, CA signature.asc Description: PGP signature
Bug#1012026: Confirming #1012026 on Debian sid
I can confirm this bug using an Intel Alder Lake-P Integrated Graphics Controller as well (on a ThinkPad X1 Carbon Gen 10). The backtrace looks like this: [317658.882] (EE) Backtrace: [317658.882] (EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x139) [0x5600e5903bf9] [317658.883] (EE) 1: /lib/x86_64-linux-gnu/libc.so.6 (__sigaction+0x40) [0x7fdf7b847af0] [317658.883] (EE) 2: /lib/x86_64-linux-gnu/libc.so.6 (pthread_key_delete+0x15c) [0x7fdf7b89383c] [317658.883] (EE) 3: /lib/x86_64-linux-gnu/libc.so.6 (raise+0x12) [0x7fdf7b847a52] [317658.883] (EE) 4: /lib/x86_64-linux-gnu/libc.so.6 (abort+0xcf) [0x7fdf7b832469] [317658.883] (EE) unw_get_proc_name failed: no unwind info found [-10] [317658.883] (EE) 5: /lib/x86_64-linux-gnu/libc.so.6 (?+0x0) [0x7fdf7b832395] [317658.883] (EE) 6: /lib/x86_64-linux-gnu/libc.so.6 (__assert_fail+0x42) [0x7fdf7b840b02] [317658.883] (EE) 7: /usr/lib/xorg/Xorg (DRIMoveBuffersHelper+0xc33) [0x5600e58bc113] [317658.884] (EE) 8: /usr/lib/xorg/Xorg (DRI2Authenticate+0xad) [0x5600e58be3ad] [317658.884] (EE) 9: /usr/lib/xorg/Xorg (DRI2GetParam+0x6cb) [0x5600e58bf12b] [317658.884] (EE) 10: /usr/lib/xorg/Xorg (SendErrorToClient+0x3d4) [0x5600e5790724] [317658.884] (EE) 11: /usr/lib/xorg/Xorg (InitFonts+0x3bc) [0x5600e57946bc] [317658.884] (EE) 12: /lib/x86_64-linux-gnu/libc.so.6 (__libc_init_first+0x8a) [0x7fdf7b83320a] [317658.884] (EE) 13: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0x7c) [0x7fdf7b8332bc] [317658.884] (EE) 14: /usr/lib/xorg/Xorg (_start+0x2a) [0x5600e577db6a] [317658.884] (EE) [317658.884] (EE) Fatal server error: [317658.884] (EE) Caught signal 6 (Aborted). Server aborting [317658.884] (EE) [317658.884] (EE) I can reliably reproduce it by invoking picard from the package of the same name under MATE. -- brian m. carlson (he/him or they/them) Toronto, Ontario, CA signature.asc Description: PGP signature
Bug#1010915: mutt: GSSAPI SMTP authentication no longer works
On 2022-05-13 at 22:52:29, Kevin J. McCarthy wrote: > On Fri, 13 May 2022 15:02:38 -0700 "Kevin J. McCarthy" wrote: > > Thanks for the bug report. Yes, it most definitely is. I'll take a > > look to see what I can find. Perhaps I've missed setting up some > > callback information that gsasl needs. > > > > Would you be able to test a patch if/when I create one? If so, please > > make sure you are subscribed to this ticket and I'll work on something > > this weekend. > > Brian and Gábor, I did indeed miss a callback value needed by GSSAPI: > hostname. The Mutt IMAP/GSSAPI auth code is using the server hostname > for this field, contradicting the gsasl documentation which says to > supply the "local host name". I'm trying the server hostname below. Oh, yeah, that would do it. Kerberos definitely wants to have the hostname. > If possible could you try either the git branch > 'kevin/gsasl-gssapi-fixes' on GitLab > <https://gitlab.com/muttmua/mutt/-/commits/kevin/gsasl-gssapi-fixes> or > alternatively try recompiling the source Debian package with the below > patch applied? I built the Debian package with the patch applied below. It didn't quite apply cleanly with patch -p1, but I copied and pasted the change. It does appear to work, and I'm using the patched version to send this. Thanks so much for the fast turnaround time. -- brian m. carlson (he/him or they/them) Toronto, Ontario, CA signature.asc Description: PGP signature
Bug#1006625: pulseaudio-module-bluetooth: A2DP and HSP profiles unavailable after update
On 2022-02-28 at 20:35:06, Claire wrote: > Package: pulseaudio-module-bluetooth > Version: 15.0+dfsg1-4 > Severity: important > X-Debbugs-Cc: claire.dbts-0...@sitedethib.com > > Dear Maintainer, > > Since updating to 15.0+dfsg1-4 from 15.0+dfsg1-3, I am stuck with the > low-quality HFP profile. > > Reinstalling pulseaudio, libpulseaudio0 and pulseaudio-module-bluetooth to > 15.0+dfsg1-3 fixes the issue. > > Rebuilding the pulseaudio packages by changing `-Dbluez5-gstreamer=enabled` to > `-Dbluez5-gstreamer=disabled` also works. I'm able to confirm this. My Pixel Buds A-Series no longer function in A2DP mode with the new version of pulseaudio, but continue to work just fine in HFP mode. Downgrading restores the functionality. -- brian m. carlson (he/him or they/them) Toronto, Ontario, CA signature.asc Description: PGP signature
Bug#1010915: mutt: GSSAPI SMTP authentication no longer works
r/sbin/sendmail" MAILPATH="/var/mail" PKGDATADIR="/usr/share/mutt" SYSCONFDIR="/etc" EXECSHELL="/bin/sh" MIXMASTER="mixmaster" To contact the developers, please mail to . To report a bug, please contact the Mutt maintainers via gitlab: https://gitlab.com/muttmua/mutt/issues -- System Information: Debian Release: bookworm/sid APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.16.0-6-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=fr_FR.UTF-8, LC_CTYPE=en_CA.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 mutt depends on: ii libc6 2.33-7 ii libgnutls30 3.7.4-2 ii libgpg-error0 1.45-2 ii libgpgme111.16.0-1.2 ii libgsasl7 1.10.0-5+b1 ii libgssapi-krb5-2 1.19.2-2+b1 ii libidn2-0 2.3.2-2 ii libncursesw6 6.3+20220423-2 ii libtinfo6 6.3+20220423-2 ii libtokyocabinet9 1.4.48-15 ii zlib1g1:1.2.11.dfsg-4 Versions of packages mutt recommends: ii locales 2.33-7 ii mailcap 3.70+nmu1 ii sensible-utils 0.0.17 Versions of packages mutt suggests: ii aspell0.60.8-4 ii ca-certificates 20211016 ii esmtp-run [mail-transport-agent] 1.2-18 ii gnupg 2.3.1-1 ii ispell3.4.05-1 ii openssl 3.0.0~~alpha4-1 ii urlview 0.9-22 Versions of packages mutt is related to: ii mutt 2.2.4-1 -- no debconf information -- brian m. carlson (he/him or they/them) Toronto, Ontario, CA signature.asc Description: PGP signature
Bug#1009249: groff: preconv misdetects UTF-8 text
Package: groff Version: 1.22.4-8 Severity: normal When using -k on a file which contains a single UTF-8 character, preconv misdetects the text as some other encoding, even though the locale in use is UTF-8. Since UTF-8 is nearly universally used for text files on Unix, this leads to bizarre behaviour and misencodings. For example, given the first file below, groff prints a warning and then proceeds to insert an incorrect character. However, when a second UTF-8 character is included, the file works. My recommendation here is that when detecting character sets, if the data is valid UTF-8, then UTF-8 be used as the encoding. The uchardet detection of "MAC-CENTRALEUROPE" may be acceptable for some web pages, where encoding can be specified explicitly at the HTTP level, but it is not a prudent choice for documents on Debian (which has never supported this as a valid system encoding) in 2022. I very much doubt this would be a prudent encoding on macOS in 2022, either, which, as I understand it, has used UTF-8 exclusively since 10.0, released over two decades ago. Command line: LC_ALL=fr_CA.UTF-8 groff -Tps -dpaper=com10l -P-pcom10 -P-l -k envelope.me >envelope.ps broken .nf .po 0.5c .sp 0.5c .ft P Toronto City Hall 100 Queen Street W Toronto ON M5H 2N2 Canada .sp 2c .in 8.5c New York City Hall 1 City Hall New York NY 10007-1298 États-Unis working .nf .po 0.5c .sp 0.5c .ft P Hôtel de Ville de Toronto 100 Rue Queen O Toronto ON M5H 2N2 Canada .sp 2c .in 8.5c New York City Hall 1 City Hall New York NY 10007-1298 États-Unis -- System Information: Debian Release: bookworm/sid APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-3-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_WARN Locale: LANG=fr_FR.UTF-8, LC_CTYPE=en_CA.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 groff depends on: ii groff-base 1.22.4-8 ii libc6 2.33-7 ii libgcc-s1 12-20220319-1 ii libstdc++6 12-20220319-1 ii libx11-62:1.7.5-1 ii libxaw7 2:1.0.14-1 ii libxmu6 2:1.1.3-3 ii libxt6 1:1.2.1-1 Versions of packages groff recommends: ii ghostscript 9.56.0~dfsg-1 ii imagemagick 8:6.9.11.60+dfsg-1.3+b2 ii imagemagick-6.q16 [imagemagick] 8:6.9.11.60+dfsg-1.3+b2 ii libpaper11.1.28+b1 ii netpbm 2:10.97.00-2 ii perl 5.34.0-3 ii psutils 1.17.dfsg-4 groff suggests no packages. -- no debconf information -- brian m. carlson (he/him or they/them) Toronto, Ontario, CA signature.asc Description: PGP signature
Bug#1009248: groff: gropdf, unlike grops, does not understand com10 paper size
Package: groff Version: 1.22.4-8 Severity: normal If one invokes groff with -Tpdf, it does not understand the com10 paper size used in North American Commercial / Number 10 envelopes, and the paper size used is A4. However, if one uses -Tps, then the same invocation is recognized, and the correct size is used. For example, with the below envelope.me, running the first command below produces a PDF with the wrong paper size, but running the second command below produces a PostScript file with the correct paper size: groff -Tpdf -dpaper=com10l -P-pcom10 -P-l -k -KUTF-8 envelope.me >envelope.pdf groff -Tps -dpaper=com10l -P-pcom10 -P-l -k -KUTF-8 envelope.me >envelope.ps I should point out that the system is not configured to use A4 because that is not generally available here, although I understand that it is a sensible default if the paper type is not understood. The gropdf(1) manual page directs users to groff_font(5), which does indeed document the com10 format. groff_tmac(5) documents the use of the "l" suffix for landscape, which is usual for this form of envelope (and required by local postal authorities), and suggests a command line similar to the above. Ideally, since this is supported in grops and it's documented to work, I could indeed use -Tpdf for envelopes. In the mean time, I've used ps2pdf as a workaround. envelope.me .nf .po 0.5c .sp 0.5c .ft P Hôtel de Ville de Toronto 100 Rue Queen O Toronto ON M5H 2N2 Canada .sp 2c .in 8.5c New York City Hall 1 City Hall New York NY 10007-1298 États-Unis --- -- System Information: Debian Release: bookworm/sid APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-3-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_WARN Locale: LANG=fr_FR.UTF-8, LC_CTYPE=en_CA.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 groff depends on: ii groff-base 1.22.4-8 ii libc6 2.33-7 ii libgcc-s1 12-20220319-1 ii libstdc++6 12-20220319-1 ii libx11-62:1.7.5-1 ii libxaw7 2:1.0.14-1 ii libxmu6 2:1.1.3-3 ii libxt6 1:1.2.1-1 Versions of packages groff recommends: ii ghostscript 9.56.0~dfsg-1 ii imagemagick 8:6.9.11.60+dfsg-1.3+b2 ii imagemagick-6.q16 [imagemagick] 8:6.9.11.60+dfsg-1.3+b2 ii libpaper11.1.28+b1 ii netpbm 2:10.97.00-2 ii perl 5.34.0-3 ii psutils 1.17.dfsg-4 groff suggests no packages. -- no debconf information -- brian m. carlson (he/him or they/them) Toronto, Ontario, CA signature.asc Description: PGP signature
Bug#1004363: ibus: pops up window with accent mark
On 2022-01-26 at 23:47:41, Gunnar Hjalmarsson wrote: > Oh no, not Zoom again. :( Saying that because zoom depending on ibus was the > reason why the reporter of <https://bugs.debian.org/988540> run into > problems. It is unclear to me as well why it's needed, but maybe that's because I don't speak a language for which it's necessary. All the languages I know happen to use the Latin alphabet. > I think you can fix it for yourself by running this command: > > im-config -n none I picked xim here instead, since I think that's what I used to use and it seemed to work. > With that said, and as you rightly point out, this is still a valid bug. So > let's keep it open and see if others run into the same issue and are able to > shed some light on the root cause. Sounds good. -- brian m. carlson (he/him or they/them) Toronto, Ontario, CA signature.asc Description: PGP signature
Bug#1004363: ibus: pops up window with accent mark
On 2022-01-26 at 20:34:09, Gunnar Hjalmarsson wrote: > @Brian: Thanks for additional info. > > I probably tested on Wayland. Now I have tested on Xorg too, and don't see > it there either. > > I have one idea (and this is a long shot): Do you possibly have an > ~/.XCompose file? If you have, can you try to rename it (in order to disable > it), relogin, and try again. The reason I ask is that I have > <https://launchpad.net/bugs/1849399> in mind. It shows that a mistake in > ~/.XCompose might lead to unexpected behavior. I don't have an ~/.XCompose file. I use the standard X compose sequences. The only keyboard configuration I have at all is this in my ~/.Xsessionrc and an ~/.Xmodmap: setxkbmap -option capslock:escape -option compose:lwin \ -option terminate:ctrl_alt_bksp The .Xmodmap looks like this: keycode 166 = Prior keycode 167 = Next I don't believe those do anything anymore; I had an old laptop where those mapped keys to PgUp and PgDown, but the keys in those positions on this laptop are PgUp and PgDown. Otherwise, this is a totally standard, boring U.S. English configuration with a standard U.S. English keyboard. > @Osamu: Unloading ibus somehow would only be a workaround, right? I mean, > you should be able to use a Compose key without issues also when the > ibus-daemon is running. This did previously work just fine. I've had ibus installed for some time and I know it's been running because one of the key mappings changed unexpectedly, as I mentioned. I don't mind if it's installed as long as the behavior is as it used to be. -- brian m. carlson (he/him or they/them) Toronto, Ontario, CA signature.asc Description: PGP signature
Bug#1004363: ibus: pops up window with accent mark
On 2022-01-26 at 07:29:34, Osamu Aoki wrote: > Brian, > > Are you using ibus module for "English (int., with AltGr dead key)". The version I have has "English - English (US)". (Actually, my system is in French, so it says, "Anglais - Anglais (US)", but that's the translation). I definitely don't have dead keys enabled, nor do I have an AltGr key. Besides the standard Shift key, I have Fn (this is a laptop), Ctrl, Windows, and Alt. > Since I use GNOME/Wayland I can't be sure but all non-GNOME system configures > ibus > with "ibus-setup". There may be configuration option there. I have that installed and I don't see an option for this. > What was your intended system configuration. If it is a good old Pure-X way > without > ibus on non-GNOME, then you have to unload ibus. GNOME pull in this if you > installed > it previously. I use MATE with Xorg and have never used GNOME or Wayland on this system. I do not need or want ibus, but I do use the video software Zoom, and it requires it to be installed (it's in Depends). I'm happy to switch to a different input method, but this bug remains valid even if I do so. ibus should refrain from popping up windows in this way or at least provide a way to configure it which defaults to off. Upgrading a system should not result in any changes to the way people input text because that's not expected nor wanted, and ibus has a history of doing exactly that. -- brian m. carlson (he/him or they/them) Toronto, Ontario, CA signature.asc Description: PGP signature
Bug#1004363: ibus: pops up window with accent mark
On 2022-01-26 at 01:04:19, Gunnar Hjalmarsson wrote: > Control: tags -1 moreinfo > > Hi Brian, > > Thanks for your report! > > On 2022-01-25 23:56, brian m. carlson wrote: > > I use a US English keyboard, but use my Compose key to type accented > > letters in Spanish and French. Within the past week, ibus has > > started to pop up a small window when I type Compose + ' to type a > > character with an acute accent, both in my GTK 3 Neovim frontend > > (neovim-gtk) and in MATE Terminal. > > I don't see that on the GNOME desktop (Debian testing) at least. Are you using Wayland? I'm using Xorg, so perhaps that's why we're seeing different behavior. > 1. What makes you think it's an IBus issue? Killing ibus-daemon stops it from happening. All the subsidiary processes exit when that happens as well, so it might be a different IBus process. To help troubleshooting, here's a listing of what's running from IBus when I see it: $ ps ax | grep ibus 1198762 ?Ssl0:00 /usr/bin/ibus-daemon --daemonize --xim 1198776 ?Sl 0:00 /usr/libexec/ibus-dconf 1198778 ?Sl 0:00 /usr/libexec/ibus-ui-gtk3 1198781 ?Sl 0:01 /usr/libexec/ibus-extension-gtk3 1198787 ?Sl 0:00 /usr/libexec/ibus-x11 --kill-daemon 1198790 ?Sl 0:00 /usr/libexec/ibus-portal 1198876 ?Sl 0:00 /usr/libexec/ibus-engine-simple All of those are gone after I send a SIGTERM to ibus-daemon, and the problem disappears as well. > 2. Can you please provide a screenshot, so we can see what it looks >like? Absolutely. I've attached one. It's very small, but distracting when I'm typing a long text in Spanish or French. What I've typed in the screenshot is Compose (that is, Windows) and the apostrophe. > 3. Do you see the small window if you define some other key as the >compose key than the one you currently use? The key I use is the Windows key. Temporarily setting right Ctrl shows the same behavior. -- brian m. carlson (he/him or they/them) Toronto, Ontario, CA signature.asc Description: PGP signature
Bug#1004363: ibus: pops up window with accent mark
me 500 org.freedesktop.ibus.panel follow-input-cursor-when-always-shown false org.freedesktop.ibus.panel x -1 org.freedesktop.ibus.panel.emoji has-partial-match false org.freedesktop.ibus.panel.emoji favorite-annotations @as [] org.freedesktop.ibus.panel.emoji load-unicode-at-startup false org.freedesktop.ibus.panel.emoji partial-match-length 3 org.freedesktop.ibus.panel.emoji favorites @as [] org.freedesktop.ibus.panel.emoji hotkey ['e'] org.freedesktop.ibus.panel.emoji lang 'en' org.freedesktop.ibus.panel.emoji font 'Monospace 16' org.freedesktop.ibus.panel.emoji load-emoji-at-startup true org.freedesktop.ibus.panel.emoji unicode-hotkey ['u'] org.freedesktop.ibus.panel.emoji partial-match-condition 0 === localectl status === System Locale: LANG=fr_FR.UTF-8 VC Keymap: n/a X11 Layout: us X11 Model: pc105 === /etc/X11/default-display-manager === /usr/sbin/lightdm === setxkbmap -print === === ~/.Xmodmap === keycode 166 = Prior keycode 167 = Next -- System Information: Debian Release: bookworm/sid APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-2-amd64 (SMP w/8 CPU threads) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=en_CA.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 ibus depends on: ii adwaita-icon-theme 41.0-1 ii dconf-cli0.40.0-2 ii gir1.2-gtk-3.0 3.24.31-1 ii gir1.2-ibus-1.0 1.5.25-3 ii ibus-data1.5.25-3 ii libatk1.0-0 2.36.0-3 ii libc62.33-3 ii libcairo21.16.0-5 ii libdconf10.40.0-2 ii libgdk-pixbuf-2.0-0 2.42.6+dfsg-2 ii libglib2.0-0 2.70.2-1 ii libgtk-3-0 3.24.31-1 ii libibus-1.0-51.5.25-3 ii libpango-1.0-0 1.50.3+ds1-4 ii libpangocairo-1.0-0 1.50.3+ds1-4 ii libx11-6 2:1.7.2-2+b1 ii libxi6 2:1.8-1 ii python3 3.9.8-1 ii python3-gi 3.42.0-3 ii python3-ibus-1.0 1.5.25-3 Versions of packages ibus recommends: ii ibus-gtk 1.5.25-3 ii ibus-gtk3 1.5.25-3 ii ibus-gtk4 1.5.25-3 ii im-config 0.50-2 Versions of packages ibus suggests: pn ibus-clutter pn ibus-doc -- no debconf information -- brian m. carlson (he/him or they/them) Toronto, Ontario, CA signature.asc Description: PGP signature
Bug#999593: ssh: segfaults when using -Y find-principals
On 2021-11-13 at 00:03:53, brian m. carlson wrote: > Steps to reproduce: > > 1. sudo apt-get build-dep git > 2. sudo apt-get install git build-essential > 3. git clone https://github.com/git/git.git > 4. cd git > 5. make && make test Git has since applied a patch to work around this issue, but you can still reproduce it like so: $ ssh-keygen -Y find-principals -f /dev/null -s /dev/null $ echo $? 139 -- brian m. carlson (he/him or they/them) Toronto, Ontario, CA signature.asc Description: PGP signature
Bug#999593: ssh: segfaults when using -Y find-principals
Package: openssh-client Version: 1:8.7p1-1 Severity: normal OpenSSH 8.7 has a bug where the -Y find-principals command segfaults. This breaks the Git testsuite because the functionality is available but doesn't work. As a result, I'm impeded in doing Git development. I am also not the only person doing Git development on Debian unstable. The bug is fixed in OpenSSH 8.8[0], so the easiest solution is to simply upgrade the package to the new version. I am fully aware that it removes support for ssh-rsa (RSA with SHA-1) signatures by default, and I am also fully aware that many clients and servers are broken by that, including ones using the Go SSH library, and I've read #996391. However, none of this should have been a surprise to those implementations, since it was well announced in advance; all of those implementations have been broken with Fedora for some time, which has a default crypto policy excluding SHA-1 signatures; this is strictly a significant improvement in security, since SHA-1 is known to be weak; and there is a well documented workaround for those for whom functionality is important than security. Thus, I'm not especially partial to the idea that we should wait to upgrade because implementations are broken. However, it would also be acceptable to me if the relevant patch were backported to make OpenSSH not segfault, since my main goal is to make the Git testsuite work (and I fundamentally believe that programs should not segfault). Steps to reproduce: 1. sudo apt-get build-dep git 2. sudo apt-get install git build-essential 3. git clone https://github.com/git/git.git 4. cd git 5. make && make test [0] https://www.openssh.com/txt/release-8.8 -- System Information: Debian Release: bookworm/sid APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.14.0-3-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_WARN Locale: LANG=fr_FR.UTF-8, LC_CTYPE=en_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 openssh-client depends on: ii adduser 3.118 ii dpkg 1.20.9 ii libc6 2.32-4 ii libedit2 3.1-20210910-1 ii libfido2-11.9.0-1 ii libgssapi-krb5-2 1.18.3-7 ii libselinux1 3.3-1 ii libssl1.1 1.1.1l-1 ii passwd1:4.8.1-2 ii zlib1g1:1.2.11.dfsg-2 Versions of packages openssh-client recommends: ii xauth 1:1.1-1 Versions of packages openssh-client suggests: pn keychain pn libpam-ssh pn monkeysphere pn ssh-askpass -- no debconf information -- brian m. carlson (he/him or they/them) Toronto, Ontario, CA signature.asc Description: PGP signature
Bug#991155: neovim: new upstream version
Package: neovim Version: 0.4.4-1 Severity: wishlist neovim 0.5 has come out with some nice new features. It would be great if it could be packaged, if not in unstable due to the freeze, at least in experimental. -- System Information: Debian Release: 11.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=en_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 neovim depends on: ii libc62.31-13 ii libluajit-5.1-2 2.1.0~beta3+dfsg-6 ii libmsgpackc2 3.3.0-4 ii libtermkey1 0.22-1 ii libunibilium42.1.0-1 ii libuv1 1.40.0-2 ii libvterm00.1.4-1 ii lua-luv 1.36.0-0-1 ii neovim-runtime 0.4.4-1 Versions of packages neovim recommends: ii python3-neovim 0.4.2-1 ii python3-pynvim [python3-neovim] 0.4.2-1 ii xclip0.13-2 ii xxd 2:8.2.2434-3 Versions of packages neovim suggests: pn ctags pn vim-scripts -- no debconf information -- brian m. carlson (he/him or they/them) Toronto, Ontario, CA signature.asc Description: PGP signature
Bug#986657: azure-cli: az keyvault throws ModuleNotFound error
Package: azure-cli Version: 2.18.0-1 Severity: important When trying to use az keyvault from this package, an exception is thrown. This prevents the operation from working. $ az keyvault secret show --vault-name VAULTNAME -n KEY --query value --output tsv ERROR: CLIInternalError: The command failed with an unexpected error. Here is the traceback: ERROR: No module named 'azure.keyvault.v7_0' Traceback (most recent call last): File "/usr/lib/python3/dist-packages/knack/cli.py", line 233, in invoke cmd_result = self.invocation.execute(args) File "/usr/lib/python3/dist-packages/azure/cli/core/commands/__init__.py", line 558, in execute self.commands_loader.load_arguments(command) File "/usr/lib/python3/dist-packages/azure/cli/core/__init__.py", line 480, in load_arguments self.command_table[command].load_arguments() # this loads the arguments via reflection File "/usr/lib/python3/dist-packages/azure/cli/core/commands/__init__.py", line 315, in load_arguments super(AzCliCommand, self).load_arguments() File "/usr/lib/python3/dist-packages/knack/commands.py", line 106, in load_arguments cmd_args = self.arguments_loader() File "/usr/lib/python3/dist-packages/azure/cli/command_modules/keyvault/_command_type.py", line 75, in keyvault_arguments_loader op = get_op_handler() File "/usr/lib/python3/dist-packages/azure/cli/command_modules/keyvault/_command_type.py", line 72, in get_op_handler return self.command_loader.get_op_handler(operations_tmpl.format(method_name)) File "/usr/lib/python3/dist-packages/azure/cli/core/__init__.py", line 829, in get_op_handler op = import_module(mod_to_import) File "/usr/lib/python3.9/importlib/__init__.py", line 127, in import_module return _bootstrap._gcd_import(name[level:], package, level) File "", line 1030, in _gcd_import File "", line 1007, in _find_and_load File "", line 972, in _find_and_load_unlocked File "", line 228, in _call_with_frames_removed File "", line 1030, in _gcd_import File "", line 1007, in _find_and_load File "", line 984, in _find_and_load_unlocked ModuleNotFoundError: No module named 'azure.keyvault.v7_0' To open an issue, please run: 'az feedback' -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-5-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_WARN Locale: LANG=fr_FR.UTF-8, LC_CTYPE=en_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 azure-cli depends on: ii python3 3.9.2-3 ii python3-azure-cli 2.18.0-1 azure-cli recommends no packages. azure-cli suggests no packages. -- no debconf information -- brian m. carlson (he/him or they/them) Houston, Texas, US signature.asc Description: PGP signature
Bug#981746: ftp.debian.org: decision to treat OpenSSL as a system library for GPLv2 is not in compliance with copyright holders' wishes
On 2021-02-04 at 13:00:39, Ansgar wrote: > No, as far as I understand it the GNU Runtime Library Exception doesn't > allow distributing the *source code* under terms compatible with the > GPL-2, but that would be a requirement of the GPL-2-licensed software. > > But the GCC Runtime Library Exception cannot remove the requirement > for doing so from GPL-2-licensed software. That's true. I suppose it would be appropriate to ask for an exception from the FSF. It seems that a compiler that can't be used to ship GPLv2 code would have a serious defect. > The GCC runtime libraries are under GPL-3 which is deliberately > incompatible with respect to the GPL-2, see [1]. > > So to me asking Debian to not rely on the system library exceptions > requires to at least: > > (1) Remove all GPL-2-licensed software (GPL-2-or-later would be okay) > that uses any GCC runtime library. And/or replace GCC. > > (2) Remove all GPL-2-licensed software that uses OpenSSL. > > (3) I think there might be more similar cases which would also need to > be dealt with. > > This looks like a very disruptive change. It does indeed look disruptive. But I think the first step would be to ask the FSF for an exception for (1), which would likely solve the problem there. In the case of (2), I think most of that software is already using GnuTLS or Nettle or something else, so mostly it's already in a good state. So I think this might end up being a lot less disruptive than originally thought. Remember, in the case of (2), this was already Debian's position until March 2020, so a lot of this software is already correctly configured. It's also possible that you could ask OpenSSL to reconsider their position on the GPLv2 or add an exception to the Apache License 2.0 like LLVM did, which would avoid the problem for OpenSSL. You could then upgrade to OpenSSL 3.0 when it comes out, which would solve the problem. > On the other side Debian has tolerated (1) forever (or at least since > GPL-3 and this particular problem exist) and even (2) for a far longer > time than it seems as languages that use `dlopen()` instead of linking > information in binary objects, were tolerated. OpenSSL is for example > pretty widely used in Python, including GPL-2-only projects. (Writing > `import something_using_ssl` vs `-lsomething_using_ssl` is a small > technical difference, but both end up instructing the runtime linker to > load some library.) I see case (2) as being a case where Python and OpenSSL need license compatibility, which they have. The problem would be linking a GPLv2 library into Python at the same time as OpenSSL. That's always been my view, at least. > So Debian could also treat OpenSSL the same as GCC runtime libraries and > as it already does for other ways to link OpenSSL. Other distributions > like Fedora seem to do the same. Some distributions do even more > controversial things (ZFS on Ubuntu?) The intent of this passage in the GPLv2 was to explicitly prohibit OS distributors from shipping GPLv2 software linked against incompatible libraries (specifically, proprietary Unix vendors from shipping GNU utilities linking against a proprietary libc). So this was literally the intended interpretation of the text. And unfortunately, I'm seeing people use Debian and Fedora's position to link GPLv2 code to which I've contributed to OpenSSL without permission. People say, "Debian and Fedora do it, therefore so can I," which is a problem. I appreciate that it's not your fault that this came to my attention, but it did, and even if it's inconvenient, I'm asking you to do the right thing by the authors and copyright holders of the software. -- brian m. carlson (he/him or they/them) Houston, Texas, US signature.asc Description: PGP signature
Bug#981746: ftp.debian.org: decision to treat OpenSSL as a system library for GPLv2 is not in compliance with copyright holders' wishes
On 2021-02-03 at 23:13:10, brian m. carlson wrote: > On 2021-02-03 at 15:50:45, Ansgar wrote: > > Hi brian, > > > > On Wed, 2021-02-03 at 14:31 +0000, brian m. carlson wrote: > > [...] > > > Note the phrase "unless that component itself accompanies the > > > executable." It's long been my interpretation, as with other > > > contributors, that this applies to distribution from the same mirror > > > archive. In any event, it's obvious that it applies to the same > > > distribution medium, and Debian ships DVD and disk images from its > > > infrastructure. > > > > I'm curious what you think of GPL-2 software linking libraries that > > cannot be distributed under terms compatible with the GPL-2 such as > > GCC's runtime libraries? > > > > For example the following libraries are licensed under the GPL-3-or- > > later and their source code cannot be distributed under terms of the > > GPL-2 (part of gcc): libgcc, libatomic, libstdc++-v3, libobjc, > > libgfortran? > > > > If you think the system library exception should not apply to any > > library in Debian, would Debian need to stop linking any GPL-2 software > > against any of GCC's runtime libraries? > > Yes, Debian would indeed need to do so. It violates the license to > distribute, on the whole, a GPLv2 program linked against code which is > not compatible with the GPLv2, unless an exception applies (which it > does not here). Actually, it appears that the GCC Runtime Library Exception appears to allow distribution under "terms of your choice", so I'd say that's not a problem. We can convey the result under the GPLv2 and so there's no problem. I think this is qualitatively different than OpenSSL, which has a deliberately incompatible license with respect to the GPLv2. -- brian m. carlson (he/him or they/them) Houston, Texas, US signature.asc Description: PGP signature
Bug#981746: ftp.debian.org: decision to treat OpenSSL as a system library for GPLv2 is not in compliance with copyright holders' wishes
On 2021-02-03 at 15:50:45, Ansgar wrote: > Hi brian, > > On Wed, 2021-02-03 at 14:31 +0000, brian m. carlson wrote: > [...] > > Note the phrase "unless that component itself accompanies the > > executable." It's long been my interpretation, as with other > > contributors, that this applies to distribution from the same mirror > > archive. In any event, it's obvious that it applies to the same > > distribution medium, and Debian ships DVD and disk images from its > > infrastructure. > > I'm curious what you think of GPL-2 software linking libraries that > cannot be distributed under terms compatible with the GPL-2 such as > GCC's runtime libraries? > > For example the following libraries are licensed under the GPL-3-or- > later and their source code cannot be distributed under terms of the > GPL-2 (part of gcc): libgcc, libatomic, libstdc++-v3, libobjc, > libgfortran? > > If you think the system library exception should not apply to any > library in Debian, would Debian need to stop linking any GPL-2 software > against any of GCC's runtime libraries? Yes, Debian would indeed need to do so. It violates the license to distribute, on the whole, a GPLv2 program linked against code which is not compatible with the GPLv2, unless an exception applies (which it does not here). I agree that this is terribly inconvenient, but it's the requirement of the license. Moreover, until last year, it was Debian's position on the matter as well. I believe that in this particular case, clang provides similar libraries that can be used instead, or perhaps the FSF would be willing to add an exception to the license for GPLv2 software. -- brian m. carlson (he/him or they/them) Houston, Texas, US signature.asc Description: PGP signature
Bug#795442: musescore: does not honor /etc/papersize
On 2021-02-03 at 20:36:38, Thorsten Glaser wrote: > brian m. carlson dixit: > > >Moreover, immediately > >after setting it to Letter and printing, attempting to print again makes > >it go right back to A4, so it doesn't remember my settings, unlike every > >other program. > > I think I *might* be able to help with this part of the report, though. > > The paper size is set per document, so you’d need to go to… > > MuseScore 2: L̲ayout → Page Settings… > MuseScore 3: Fo̲rmat → Page Settings… > > … and change the Page Size (for the current document) there. > > People are trying to get upstream to at least implement some > kind of default setting and the templates have been fixed and > broken again several times hardcoding or not the paper size > (ideally they don’t hardcode it so the default is used); if > you create a new score by “choose instruments”, not using one > of the templates, you should get the MuseScore-version-wide > default. Yeah, I'm aware of how to change it, but it ends up being a problem because it doesn't persist across files. Therefore, it needs to be changed again for every file. So I appreciate the update, but I still think this needs to be fixed. -- brian m. carlson (he/him or they/them) Houston, Texas, US signature.asc Description: PGP signature
Bug#981746: ftp.debian.org: decision to treat OpenSSL as a system library for GPLv2 is not in compliance with copyright holders' wishes
Package: ftp.debian.org Severity: important Hey, Someone recently brought to my attention https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972181 and the corresponding meeting notes at http://meetbot.debian.net/debian-ftp/2020/debian-ftp.2020-03-13-20.02.html. These notes claim that OpenSSL can be treated as a system library for the purposes of the GPLv2, like Fedora does. Unfortunately, I believe the license is very clear and it doesn't agree. From the GPL version 2: For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. Note the phrase "unless that component itself accompanies the executable." It's long been my interpretation, as with other contributors, that this applies to distribution from the same mirror archive. In any event, it's obvious that it applies to the same distribution medium, and Debian ships DVD and disk images from its infrastructure. There have been numerous arguments on debian-devel in the past about support for dpkg linked against a Solaris-derived libc for Nextenta OS in which copyright holders have upheld this policy. I'd like to ask you to reconsider this decision at your earliest convenience and update the bug report. I will follow up with Fedora separately and ask them to update their policy as well. I ask this of you not only as an on-and-off contributor to Debian, but also as a copyright holder in numerous pieces of software in Debian, both GPL and non-GPL. One of the things I've long appreciated about Debian has been its focus on doing the right thing with regard to licensing, and I think this misses the mark there. -- brian m. carlson (he/him or they/them) Houston, Texas, US signature.asc Description: PGP signature
Bug#895754: ncurses-term: please add tmux-direct terminal type
On 2020-10-04 at 18:17:57, Sven Joachim wrote: > Despite these reservations, you added tmux-direct in the 20201003 > patchlevel this weekend, not mentioning this bug report but referring to > https://github.com/tmux/tmux/issues/2370. Fantastic, that's great to hear. Thanks to everyone for getting this done. -- brian m. carlson: Houston, Texas, US signature.asc Description: PGP signature
Bug#969563: virt-manager: does not honor X11 keyboard remap of Caps Lock to Escape
Package: virt-manager Version: 1:2.2.1-5 Severity: normal At work, I use Debian unstable on a MacBook Pro with Touch Bar. This particular machine lacks a physical Escape key, which is problematic for a Vim user, so I've remapped Caps Lock to Escape using the standard X11 capslock:escape option (using the MATE configuration settings). When I run a Windows 10 VM in virt-manager using the default Spice UI (as set up by a standard OS installation using virt-manager), this setting is not honored, and hitting Caps Lock toggles letter casing instead of sending the Escape key. This is clearly not what I want, and it leads to a frustrating experience when editing text, which, due to the limited capabilities of Windows to remap keys, is hard to work around. I expect that when I strike a key on the keyboard, virt-manager, Spice, and the rest of the KVM stack honor my X11 keyboard options and send the key to which they have been mapped, not the original key. I did look for an option in the Details section for my VM, but no such configuration to control this was available. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.7.0-3-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_WARN Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 virt-manager depends on: ii dconf-gsettings-backend [gsettings-backend] 0.36.0-1 ii gir1.2-gtk-3.0 3.24.22-1 ii gir1.2-gtk-vnc-2.0 1.0.0-1 ii gir1.2-gtksource-4 4.6.1-1 ii gir1.2-libosinfo-1.0 1.7.1-1 ii gir1.2-libvirt-glib-1.0 3.0.0-1 ii gir1.2-vte-2.91 0.60.3-1 ii librsvg2-common 2.48.8+dfsg-1 ii python3 3.8.2-3 ii python3-dbus 1.2.16-3 ii python3-gi 3.36.1-1 ii python3-gi-cairo 3.36.1-1 ii python3-libvirt 6.1.0-1+b1 ii virtinst 1:2.2.1-5 Versions of packages virt-manager recommends: ii gir1.2-appindicator3-0.10.4.92-8 ii gir1.2-spiceclientglib-2.0 0.38-2 ii gir1.2-spiceclientgtk-3.0 0.38-2 ii libvirt-daemon-system 6.6.0-2 Versions of packages virt-manager suggests: ii gir1.2-secret-1 0.20.3-1 ii gnome-keyring3.36.0-1 pn python3-guestfs pn ssh-askpass ii virt-viewer 7.0-2 -- no debconf information -- brian m. carlson: Houston, Texas, US signature.asc Description: PGP signature
Bug#960734: sensible-utils: does not execute shell in EDITOR and VISUAL
Package: sensible-utils Version: 0.0.12+nmu1 Severity: normal Tags: patch It is generally possible in EDITOR and VISUAL to place arbitrary shell. For example, one can write something like the following: export VISUAL='f(){ if [ -n "$DISPLAY" ]; then gvim -f "$@"; else vim "$@"; fi; };f' This is supported by every program I can find which uses EDITOR and VISUAL, including less, crontab, mutt, and git. It is my understanding that supporting this is intentional, because otherwise it is impossible to place quoted arguments inside a shell value, like so: export VISUAL='vim +"setf perl"' However, sensible-editor does not support that. It does perform shell word splitting, but shell word splitting is not sufficient to handle the cases mentioned above. I've submitted a merge request at https://salsa.debian.org/debian/sensible-utils/-/merge_requests/4 to implement this behavior, add a test, and improve the existing test to be more robust. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.6.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- no debconf information -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#959008: tmuxinator: nags user about new tmux versions
Package: tmuxinator Version: 1.1.4-3 Severity: normal tmuxinator nags the user when the version of tmux is unknown to it. This is a deliberate upstream decision, but it annoys users and is not in their interest. The sole option to disable this requires an explicit version for a specific subcommand which means one cannot just use a shell alias to avoid the warning. If it is really the case that tmuxinator is not functional with newer tmux versions, or it can't be suitably guaranteed by the Debian package, please add a suitable Depends requirement on the versions it supports, such that tmux cannot be upgraded to an unsupported version that causes tmuxinator to nag the user. Otherwise, if it is the case that this is a needless warning, please patch it out. Debian already does this for a variety of other software, including OpenSSL, that has excessively strict version warnings. Note that upgrading tmuxinator here is not sufficient to solve the problem (unless that version removes the warning), since it will reoccur with the next upgrade. The defect being described here is that the user is able to be nagged at all when Debian dependencies are satisfied, not that tmuxinator is out of date. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.6.0-trunk-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages tmuxinator depends on: ii ruby 1:2.7+1 ii ruby-erubis 2.7.0-3 ii ruby-thor0.20.3-2 ii ruby-xdg 2.2.3-1 ii tmux 3.1-1 tmuxinator recommends no packages. tmuxinator suggests no packages. -- no debconf information -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#958737: linux-image-5.5.0-2-amd64: Intel Cannon Point-LP audio controller no longer works
Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: xhci_hcd Kernel modules: xhci_pci ** USB devices: Bus 009 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 010 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 008 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 007 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 006 Device 002: ID 2188:0747 CalDigit Card Reader Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 003 Device 002: ID 2188:6533 CalDigit, Inc. CalDigit Thunderbolt 3 Audio Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 003: ID 06cb:00bd Synaptics, Inc. Bus 001 Device 002: ID 04f2:b67c Chicony Electronics Co., Ltd Integrated Camera Bus 001 Device 004: ID 8087:0aaa Intel Corp. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.5.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages linux-image-5.5.0-2-amd64 depends on: ii initramfs-tools [linux-initramfs-tool] 0.136 ii kmod27+20200310-2 ii linux-base 4.6 Versions of packages linux-image-5.5.0-2-amd64 recommends: ii apparmor 2.13.4-1+b1 ii firmware-linux-free 20200122-1 Versions of packages linux-image-5.5.0-2-amd64 suggests: pn debian-kernel-handbook ii extlinux3:6.04~git20190206.bf6db5b4+dfsg1-2 ii grub-efi-amd64 2.04-6 pn linux-doc-5.5 Versions of packages linux-image-5.5.0-2-amd64 is related to: pn firmware-amd-graphics pn firmware-atheros pn firmware-bnx2 pn firmware-bnx2x ii firmware-brcm8021120190717-2 pn firmware-cavium ii firmware-intel-sound 20190717-2 pn firmware-intelwimax pn firmware-ipw2x00 pn firmware-ivtv ii firmware-iwlwifi 20190717-2 pn firmware-libertas pn firmware-linux-nonfree ii firmware-misc-nonfree 20190717-2 pn firmware-myricom pn firmware-netxen pn firmware-qlogic pn firmware-realtek pn firmware-samsung pn firmware-siano pn firmware-ti-connectivity pn xen-hypervisor -- no debconf information -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#958126: linux-image-5.5.0-2-amd64: Alt-SysRq-x no longer lifts Secure Boot restrictions
On 2020-04-18 at 21:59:35, Ben Hutchings wrote: > Control: tag -1 wontfix > > On Sat, 2020-04-18 at 18:50 +0000, brian m. carlson wrote: > > Package: src:linux > > Version: 5.5.17-1 > > Severity: important > > > > By default, Debian ships kernels such that when booted with Secure Boot, > > that a user cannot hibernate their computer. However, the combination > > Alt-SysRq-x is documented in the wiki (which is linked to from the > > kernel) to lift these restrictions and allow the user to hibernate. > > > > However, in this kernel version that does not work, and the user must > > either disable secure boot or forego hibernation. When pressing > > Alt-SysRq-x, the following is printed: > > > > sysrq: HELP : loglevel(0-9) reboot(b) crash(c) terminate-all-tasks(e) > > memory-full-oom-kill(f) kill-all-tasks(i) thaw-filesystems(j) sak(k) > > show-backtrace-all-active-cpus(l) show-memory-usage(m) nice-all-RT-tasks(n) > > poweroff(o) show-registers(p) show-all-timers(q) unraw(r) sync(s) > > show-task-states(t) unmount(u) force-fb(V) show-blocked-tasks(w) > > dump-ftrace-buffer(z) > [...] > > This was an intentional change listed in the changelog, fixing bug > #947021. Thanks for mentioning the wiki; I'll update that to reflect > current reality. It looks like Ubuntu allows people physically present to use the key still with their proposed patch. Is there a reason that patch can't be applied here? > If you can't live with the restrictions of Secure Boot, you'll have to > turn it off. Can you explain why this restriction is required in the first place? Other operating systems use Secure Boot and allow hibernation, so it can't be that it's an intrinsic limitation. I'd like to have the behavior where I know that my boot process hasn't been tampered with, but I don't need to be locked out of my system or have important features turned off. Surely that's a valid use case that should be supported. -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#958126: linux-image-5.5.0-2-amd64: Alt-SysRq-x no longer lifts Secure Boot restrictions
Kernel modules: xhci_pci 0d:00.0 Ethernet controller [0200]: Intel Corporation I210 Gigabit Network Connection [8086:1533] (rev 03) Subsystem: CalDigit, Inc. I210 Gigabit Network Connection [1ab6:0214] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: igb Kernel modules: igb 2d:00.0 USB controller [0c03]: Intel Corporation JHL6540 Thunderbolt 3 USB Controller (C step) [Alpine Ridge 4C 2016] [8086:15d4] (rev 02) (prog-if 30 [XHCI]) Subsystem: Lenovo JHL6540 Thunderbolt 3 USB Controller (C step) [Alpine Ridge 4C 2016] [17aa:2292] Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: xhci_hcd Kernel modules: xhci_pci ** USB devices: Bus 009 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 010 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 008 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 007 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 006 Device 002: ID 2188:0747 CalDigit Card Reader Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 003 Device 002: ID 2188:6533 CalDigit, Inc. CalDigit Thunderbolt 3 Audio Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 003: ID 06cb:00bd Synaptics, Inc. Bus 001 Device 002: ID 04f2:b67c Chicony Electronics Co., Ltd Integrated Camera Bus 001 Device 004: ID 8087:0aaa Intel Corp. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.5.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages linux-image-5.5.0-2-amd64 depends on: ii initramfs-tools [linux-initramfs-tool] 0.136 ii kmod27-2 ii linux-base 4.6 Versions of packages linux-image-5.5.0-2-amd64 recommends: ii apparmor 2.13.4-1+b1 ii firmware-linux-free 20200122-1 Versions of packages linux-image-5.5.0-2-amd64 suggests: pn debian-kernel-handbook ii extlinux3:6.04~git20190206.bf6db5b4+dfsg1-2 ii grub-efi-amd64 2.04-5 pn linux-doc-5.5 Versions of packages linux-image-5.5.0-2-amd64 is related to: pn firmware-amd-graphics pn firmware-atheros pn firmware-bnx2 pn firmware-bnx2x ii firmware-brcm8021120190717-2 pn firmware-cavium pn firmware-intel-sound pn firmware-intelwimax pn firmware-ipw2x00 pn firmware-ivtv ii firmware-iwlwifi 20190717-2 pn firmware-libertas pn firmware-linux-nonfree ii firmware-misc-nonfree 20190717-2 pn firmware-myricom pn firmware-netxen pn firmware-qlogic pn firmware-realtek pn firmware-samsung pn firmware-siano pn firmware-ti-connectivity pn xen-hypervisor -- no debconf information -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#956045: gnome-keyring: several cryptographic vulnerabilities
On 2020-04-08 at 12:15:22, Daiki Ueno wrote: > "brian m. carlson" writes: > > [2] is an example of a cross-VM cryptographic timing attack, which can > > also be applied across processes. Other timing attacks are known even > > across networks. > > I am not sure why you suddenly mention cross-VM attacks while VMs are a > different beast from containers. The attack I mentioned states that it is possible to simply run on the same processor as the affected process to conduct a side-channel attack. That applies to containers as well as other processes, in addition to VMs. > > It is, in general, not safe to assume that any timing attack is > > unexploitable. > > I would also be concerned with that, if this was reported against crypto > components. However, this was reported against desktop, where > protecting active attacks is not a goal for various reasons: > https://wiki.gnome.org/Projects/GnomeKeyring/SecurityPhilosophy#Active_Attacks gnome-keyring stores data in a cryptographic format and is therefore a cryptographic tool. The standard cryptographic model assumes an active attacker, Mallory, who tampers with the data and monitors the actors. Even if you do not wish to protect against active attacks where an attacker tampers with the data, reasonable users will expect cryptographic tools to do so. Moreover, it is in fact part of the threat model of other password managers, such as 1Password. Moreover, protecting against timing attacks like this is extremely simple. It can be done with three lines of portable C: int x = 0; for (size_t i = 0; i < n; i++) x |= a[i] ^ b[i]; Now x is zero if the values matched, and nonzero if they didn't, and the operation is constant time. There's no reason not to fix this, even if you don't consider it a vulnerability. You have also not mentioned the other attack which I mentioned in which there is information disclosure of metadata. This is in fact trivial to reproduce and is in my opinion the most damning of the vulnerabilities because it is entirely passive and can be done completely offline. An attacker should not be able to determine from my keyring how many GnuPG keys I have stored passphrases for, which wireless network passwords I've saved, or if I have a password for a given username on a given Git hosting site. Right now, all of those are trivial from my login keyring. The fix to issue 1 is a simple, well-known technique which is standard practice among cryptographic tools. The fix to the other issues is to encrypt all the data using a secure AEAD or EtM construction. Since the former is easy to do and the latter is required to fix the most severe of the issues, I'm not sure why we're arguing about the particulars. I should also point our that when someone reports a security issue to you with a disclosure deadline, the right time to discuss the matter or dispute the findings is during the coordination period. If you don't bother to respond then, then the reporter can only assume that you don't care at all. I received no such discussion or feedback about the reports during the 45 day disclosure window, only notification that some bug reports were filed. I would not perform coordinated disclosure with the GNOME Project again. I stand by my bug report that these issues represent security-related defects in the gnome-keyring package and that they need to be fixed. Unless you are specifically disputing that they constitute defects needing fixing, or are reporting on your intention to productively fix them, I ask you not to further respond to this report. -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#956045: gnome-keyring: several cryptographic vulnerabilities
On 2020-04-07 at 13:45:20, Daiki Ueno wrote: > "brian m. carlson" writes: > > > First, the code to verify the integrity hash is done with memcmp. This > > is not safe against timing attacks, so an attacker can tamper with the > > data and determine how much of the hash matches based on the amount of > > time it takes[0]. This comparison should be done in a constant-time > > way. > > > > [0] This can be a problem with an untrusted container with the user's > > home directory mounted in it. There's documentation for VS Code that > > tells people how to do exactly this, so it's clearly a common situation. > > Could you elaborate which document you are referring to? I'm wondering > how it can be a problem provided that VS Code and gnome-keyring-daemon > are running as a separate process. I believe that both snap and flatpak > provide a process isolation mechanism. The document at [0] provides documentation on how to mount your home directory into containers. It is well known that people download containers using Docker that are not audited and may contain malware[1]. [2] is an example of a cross-VM cryptographic timing attack, which can also be applied across processes. Other timing attacks are known even across networks. It is, in general, not safe to assume that any timing attack is unexploitable. > > This was originally reported to the Debian Security Team on February 3, > > but they were unable to issue a CVE, so I reported it to the GNOME > > Security Team on February 4. The response was the gnome-keyring team is > > "aware of those issues" but they "don't think those issues are severe > > enough to urge an immediate fix" and plan to address them at an > > unspecified point in the future. > > It's a bit disappointing that you didn't quote the full response with > the additional context. Here it goes, for reference: I believe my report substantially mentioned the relevant points, which are that * you are aware of the issues; * you don't see the issues as warranting an immediate fix; and * you are working on a plan to address them in gnome-keyring, but the point at which they will be fixed is not presently specified. It was my intention to fairly and accurately present the substance of your comments as relevant to the bug report without quoting the full email. I didn't wish to include the full contents of a private discussion, some of which would not have even made sense without additional email context that was not relevant to the bug report. My response stated my position, which is that letting security vulnerabilities linger unfixed long term is not in the public interest. I appreciate that fixing this may be nontrivial, but a prompt and timely security response is essential. If I discovered the vulnerabilities, others probably have, too, and users deserve secure software. [0] https://code.visualstudio.com/docs/remote/containers [1] https://www.theregister.co.uk/2017/07/28/malware_docker_containers/ [2] https://blog.cryptographyengineering.com/2012/10/27/attack-of-week-cross-vm-timing-attacks/ -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#956045: gnome-keyring: several cryptographic vulnerabilities
Package: gnome-keyring Version: 3.36.0-1 Severity: important Tags: security upstream gnome-keyring has several vulnerabilities with regard to its handling of its encrypted data files. First, the code to verify the integrity hash is done with memcmp. This is not safe against timing attacks, so an attacker can tamper with the data and determine how much of the hash matches based on the amount of time it takes[0]. This comparison should be done in a constant-time way. Second, because the integrity algorithm used is MD5, which is vulnerable to collisions, it doesn't uniquely identify a sequence of bytes. Consequently, the padding must be checked to be zero, and it must be done in constant time with the actual integrity algorithm, such that a failure of either takes exactly the same amount of time. Third, the metadata that occurs unencrypted in the file is hashed with MD5. Since MD5 is cheap to compute, an attacker can guess to see if the items they want to access are in the keyring without needing to decrypt the data. The keys themselves are also stored unencrypted, which makes it easy to determine which types of objects and how many of each type are stored in the keyring. For example, GnuPG stores a "keygrip" attribute. This violates user privacy and leaks a significant amount of data. All of this data should be stored encrypted. Even storing both keys and values as MACs using a secret key would leak which keys and values are repeated, which in many cases would still leak a significant amount of information. Fourth, the metadata stored unencrypted is also stored without any sort of integrity check. As a result, an attacker can modify it at will without any detection whatsoever. All data stored in the file, including version numbers, algorithm identifiers, and other structural content, as well as encrypted data, should be protected either by an AEAD encryption algorithm or a strong MAC (such as HMAC with SHA-2, SHA-3, or BLAKE2). This was originally reported to the Debian Security Team on February 3, but they were unable to issue a CVE, so I reported it to the GNOME Security Team on February 4. The response was the gnome-keyring team is "aware of those issues" but they "don't think those issues are severe enough to urge an immediate fix" and plan to address them at an unspecified point in the future. Since 45 days have elapsed since the initial report and no fix is forthcoming[1], I've opened this bug to disclose this issue publicly. This is probably severity grave, but I don't have a true proof-of-concept demonstrating that it allows access to user accounts, so I opted for important. Feel free to change as you see fit. Please ensure CVEs are issued for these bugs. [0] This can be a problem with an untrusted container with the user's home directory mounted in it. There's documentation for VS Code that tells people how to do exactly this, so it's clearly a common situation. [1] https://github.com/bk2204/dev-practices/tree/master/security-research -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-4-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnome-keyring depends on: ii dbus-user-session [default-dbus-session-bus] 1.12.16-2 ii dbus-x11 [dbus-session-bus] 1.12.16-2 ii dconf-gsettings-backend [gsettings-backend] 0.36.0-1 ii gcr 3.36.0-2 ii libc6 2.30-4 ii libcap-ng00.7.9-2.1+b2 ii libcap2-bin 1:2.33-1 ii libgck-1-03.36.0-2 ii libgcr-base-3-1 3.36.0-2 ii libgcrypt20 1.8.5-5 ii libglib2.0-0 2.64.1-1 ii p11-kit 0.23.20-1 ii pinentry-gnome3 1.1.0-3+b1 Versions of packages gnome-keyring recommends: ii gnome-keyring-pkcs11 3.36.0-1 ii libpam-gnome-keyring 3.36.0-1 gnome-keyring suggests no packages. -- no debconf information -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#946879: git: please build package with libsecret credential helper
On 2019-12-17 at 01:20:15, Jonathan Nieder wrote: > forcemerge 878599 946879 > quit > > Hi, > > brian m. carlson wrote: > > > It would be great if the libsecret credential helper could be built in > > its own package so that folks could easily use it. > > Thanks! I agree. Here's what should be a complete patch that provides a package called "git-credential-libsecret" (in case we would like to support other credential packages in the future), including a commit message. It applies to the debian-sid branch of the upstream repo and the package. I've done a test build and install and verified that a clone works as expected. -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 From 00000000 Mon Sep 17 00:00:00 2001 From: "brian m. carlson" Date: Sun, 15 Mar 2020 23:07:29 + Subject: [PATCH] debian: add libsecret credential helper There's a standard XDG secret service API for D-Bus which can be used to talk to an appropriate credential storage service and Git supports using this with the libsecret credential helper. Shipping this as part of the standard Debian package means that users will be more likely to install it and therefore more likely to store their credentials in an encrypted storage format, which is good for everyone. Build the libsecret credential helper and ship it as its own package. Signed-off-by: brian m. carlson --- debian/control | 22 +- debian/git-credential-libsecret.install | 1 + debian/rules| 8 +++- 3 files changed, 29 insertions(+), 2 deletions(-) create mode 100644 debian/git-credential-libsecret.install diff --git a/debian/control b/debian/control index 4c7face4e9..70fd4d30f2 100644 --- a/debian/control +++ b/debian/control @@ -6,6 +6,7 @@ Uploaders: Anders Kaseorg Build-Depends: libz-dev, gettext, libpcre2-dev | libpcre3-dev, libcurl4-gnutls-dev, libexpat1-dev, + libsecret-1-dev, subversion, libsvn-perl, libyaml-perl, tcl, python3, libhttp-date-perl | libtime-parsedate-perl, @@ -165,6 +166,25 @@ Description: fast, scalable, distributed revision control system (MediaWiki remo remote Git repository, and a 'git mw' command that can show a preview of how wiki markup will be rendered before pushing. +Package: git-credential-libsecret +Architecture: all +Multi-Arch: foreign +Depends: ${misc:Depends}, git (>> ${source:Upstream-Version}), git (<< ${source:Upstream-Version}-.) +Suggests: git-doc +Description: fast, scalable, distributed revision control system (libsecret credential helper) + Git is popular version control system designed to handle very large + projects with speed and efficiency; it is used for many high profile + open source projects, most notably the Linux kernel. + . + Git falls in the category of distributed source code management tools. + Every Git working directory is a full-fledged repository with full + revision tracking capabilities, not dependent on network access or a + central server. + . + This package provides the libsecret credential helper, which can be + used to securely store Git credentials in any secret storage supporting + the D-Bus Secret Service API. + Package: git-email Architecture: all Multi-Arch: foreign @@ -328,7 +348,7 @@ Architecture: all Multi-Arch: foreign Depends: ${misc:Depends}, git (>> ${source:Upstream-Version}), git (<< ${source:Upstream-Version}-.), git-doc, git-el, git-cvs, git-mediawiki, git-svn, - git-email, git-gui, gitk, gitweb + git-email, git-gui, gitk, gitweb, git-credential-libsecret Recommends: git-daemon-run | git-daemon-sysvinit Description: fast, scalable, distributed revision control system (all subpackages) Git is popular version control system designed to handle very large diff --git a/debian/git-credential-libsecret.install b/debian/git-credential-libsecret.install new file mode 100644 index 00..3b9ead831a --- /dev/null +++ b/debian/git-credential-libsecret.install @@ -0,0 +1 @@ +usr/lib/git-core/git-credential-libsecret usr/lib/git-core diff --git a/debian/rules b/debian/rules index de5a084e9c..82dda426b7 100755 --- a/debian/rules +++ b/debian/rules @@ -66,6 +66,8 @@ build-stamp: override_dh_auto_build-arch: build-stamp $(MAKE) -C contrib/subtree all $(OPTS) ln -s contrib/subtree/git-subtree + $(MAKE) -C contrib/credential/libsecret all $(OPTS) + ln -s contrib/credential/libsecret override_dh_auto_test-arch: test -z '$(TEST)' || \ @@ -91,8 +93,9 @@ override_dh_auto_test-indep: override_dh_auto_clean: $(MAKE) -C contrib/mw-to-git clean $(OPTS) $(MAKE) -C contrib/subtree clean $(OPTS) + $(MAKE) -C contrib/credential/libsecret clean $(OPTS) $(MAKE) clean $(OPTS) - rm -f git-subtree + rm -f git-subtree libsecret override_dh_clean: dh_clean -Xmailinfo.c.orig @@ -101,6 +104,9 @@ override_dh_auto_install-arch: # git DESTDIR='$(
Bug#947283: network-manager: fails to connect via Wi-Fi with "selecting lease failed"
On 2019-12-23 at 22:25:52, brian m. carlson wrote: > Package: network-manager > Version: 1.22.0-1 > Severity: important > > When connecting to a Starbucks Wi-Fi network (open Wi-Fi network with > captive portal), Network Manager refuses to get an IPv4 address over > DHCP with a message in the logs that says "selecting lease failed: 12". > This machine has not previously been connected to this network. > Downgrading to 1.20.8-1 causes things to work again, but 1.22.0-1 does > not work even if I reboot and delete all the saved leases from > /var/lib/NetworkManager. > > I don't see the problem on my home network, with uses WPA2-EAP with > EAP-TTLS and PAP. However, I had connected to that network before > installing 1.22.0, so it's possible that the issue is with new networks. I've determined this problem is due to the internal DHCP client. Switching back to dhclient as the DHCP client works, so I've done that. I've been able to reproduce this on two separate sid systems. -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#950295: gnome-keyring: uses MD5
Package: gnome-keyring Version: 3.34.0-1 Severity: normal Tags: security gnome-keyring makes copious use of MD5. It hashes attributes with it and uses it as an integrity check in the encrypted data. Unfortunately, MD5 is, according to CMU, “cryptographically broken and unsuitable for further use.” It has been known to be insecure since at least 2004. While it is true that MD5 is not practically vulnerable to preimage attacks, gnome-keyring cannot make assumptions about the data that it may be asked to store and therefore cannot rule out collisions as an attack vector. Additionally, MD5 is so weak and has been for so long that its use is a major cryptographic red flag. gnome-keyring should transition to algorithms which are not broken. SHA-2, SHA-3, and BLAKE2 are all valid options for secure, robust hash algorithms, and BLAKE2 is faster than MD5, in the unlikely situation upstream feels performance is a concern. Moreover, libgcrypt supports all of these options. While the upgrade is taking place, it may be prudent to consider using a MAC (such as HMAC with a suitably secure algorithm) as an integrity check instead of an encrypted hash. This allows the integrity check to occur before any data is decrypted and is in line with best practices that encourage using encrypt-then-mac. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-3-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnome-keyring depends on: ii dbus-user-session [default-dbus-session-bus] 1.12.16-2 ii dbus-x11 [dbus-session-bus] 1.12.16-2 ii dconf-gsettings-backend [gsettings-backend] 0.34.0-2 ii gcr 3.34.0-1 ii libc6 2.29-9 ii libcap-ng00.7.9-2.1+b1 ii libcap2-bin 1:2.27-1 ii libgck-1-03.34.0-1 ii libgcr-base-3-1 3.34.0-1 ii libgcrypt20 1.8.5-3 ii libglib2.0-0 2.62.4-1+b1 ii p11-kit 0.23.20-1 ii pinentry-gnome3 1.1.0-3+b1 Versions of packages gnome-keyring recommends: ii gnome-keyring-pkcs11 3.34.0-1 ii libpam-gnome-keyring 3.34.0-1 gnome-keyring suggests no packages. -- no debconf information -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#949330: evolution: Google OAuth forces use of internal browser without way to change URL
Source: evolution Version: 3.34.1-2+b1 Severity: important At work, I use a Google Apps service with a single sign-on provider. As a result, I need to use a browser to authenticate to Google so I can use OAuth2. In addition, our company uses Duo Mobile, which restricts access to users with up-to-date software. The version of WebKit which is used is viewed as a too-old version of Safari on macOS[0], and therefore authentication is not permitted. I can actually work around this issue by copying and pasting the URL into Firefox, but I cannot then paste the URL from the sign-in flow back into the URL bar in the internal browser, so I'm stuck and cannot log in. The Google OAuth2 flow, when run in Firefox, does provide me a token I can paste back in, but Evolution cannot accept that token in place of the login flow. In order to be able to use Evolution with Google's OAuth2 flow, I need one of the following to happen: 1. Evolution reports itself as a recent, modern (e.g., patched macOS Catalina-equivalent) version of Safari and continues to update this value. 2. Evolution allows using an external browser, such as Firefox, to log in for OAuth2 flows. 3. Evolution allows pasting into the URL bar so I can paste the proper URL in from Firefox (assuming it otherwise supports doing that). 4. Evolution allows pasting in the token from Google I can use in Firefox instead. [0] Not updating the user-agent appears to be a deliberate decision in WebKit2GTK because "User Agent sniffing is…terrible…." I agree, but I don't make the decisions here. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-3-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#949192: gcc-10: uses regexec without support for REG_STARTEND with -fsanitize=address
Package: libasan6 Version: 10-20200107-1 Severity: normal When gcc-10 compiles with -fsanitize=address, it substitutes any calls to regexec with a version that does not support REG_STARTEND. This makes code that is compiled fail unexpectedly or even produce spurious sanitization errors, since with that option the buffer need not be NUL-terminated. While REG_STARTEND is not in POSIX, it is found on the BSDs and Linux and users may reasonably rely on the fact that it is present on those systems. This issue has caused a bug in the Git testsuite as seen at https://lore.kernel.org/git/20200117174931.ga8...@coredump.intra.peff.net/T/#t. I've attached a testcase. Without -fsanitize=address, it succeeds silently. With -fsanitize=address, it fails and prints an error. Please either fix the regexec implementation such that it is fully functional compared to the version in glibc or disable the sanitization of regexec until it has feature parity. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-3-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libasan6 depends on: ii gcc-10-base 10-20200107-1 ii libc62.29-9 ii libgcc-s110-20200107-1 libasan6 recommends no packages. libasan6 suggests no packages. -- no debconf information -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 #include #include #include int main(void) { regex_t r; const char s[] = "ban\0ana"; regmatch_t pmatch[10]; pmatch[0].rm_so = 0; pmatch[0].rm_eo = sizeof(s); if (regcomp(, "ana", 0)) return 2; if (regexec(, s, sizeof(pmatch)/sizeof(pmatch[0]), pmatch, REG_STARTEND)) { fprintf(stderr, "failed to match\n"); regfree(); return 3; } regfree(); return 0; } signature.asc Description: PGP signature
Bug#949191: clang-8: uses regexec without support for REG_STARTEND with -fsanitize=address
Package: clang-8 Version: 1:8.0.1-4 Severity: normal When clang-8 compiles with -fsanitize=address, it substitutes any calls to regexec with a version that does not support REG_STARTEND. This makes code that is compiled fail unexpectedly or even produce spurious sanitization errors, since with that option the buffer need not be NUL-terminated. While REG_STARTEND is not in POSIX, it is found on the BSDs and Linux and users may reasonably rely on the fact that it is present on those systems. This issue has caused a bug in the Git testsuite as seen at https://lore.kernel.org/git/20200117174931.ga8...@coredump.intra.peff.net/T/#t. I've attached a testcase. Without -fsanitize=address, it succeeds silently. With -fsanitize=address, it fails and prints an error. Please either fix the regexec implementation such that it is fully functional compared to the version in glibc or disable the sanitization of regexec until it has feature parity. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-3-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages clang-8 depends on: ii binutils 2.33.50.20200115-2 ii libc6 2.29-9 ii libc6-dev 2.29-9 ii libclang-common-8-dev 1:8.0.1-4 ii libclang1-81:8.0.1-4 ii libgcc-8-dev 8.3.0-26 ii libgcc-s1 [libgcc1]10-20200107-1 ii libgcc11:9.2.1-23 ii libllvm8 1:8.0.1-4 ii libobjc-8-dev 8.3.0-26 ii libstdc++-8-dev8.3.0-26 ii libstdc++6 9.2.1-23 Versions of packages clang-8 recommends: ii libomp-8-dev 1:8.0.1-4 ii llvm-8-dev1:8.0.1-4 ii python3 3.7.5-3 Versions of packages clang-8 suggests: pn clang-8-doc -- no debconf information -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 #include #include #include int main(void) { regex_t r; const char s[] = "ban\0ana"; regmatch_t pmatch[10]; pmatch[0].rm_so = 0; pmatch[0].rm_eo = sizeof(s); if (regcomp(, "ana", 0)) return 2; if (regexec(, s, sizeof(pmatch)/sizeof(pmatch[0]), pmatch, REG_STARTEND)) { fprintf(stderr, "failed to match\n"); regfree(); return 3; } regfree(); return 0; } signature.asc Description: PGP signature
Bug#947283: network-manager: fails to connect via Wi-Fi with "selecting lease failed"
Package: network-manager Version: 1.22.0-1 Severity: important When connecting to a Starbucks Wi-Fi network (open Wi-Fi network with captive portal), Network Manager refuses to get an IPv4 address over DHCP with a message in the logs that says "selecting lease failed: 12". This machine has not previously been connected to this network. Downgrading to 1.20.8-1 causes things to work again, but 1.22.0-1 does not work even if I reboot and delete all the saved leases from /var/lib/NetworkManager. I don't see the problem on my home network, with uses WPA2-EAP with EAP-TTLS and PAP. However, I had connected to that network before installing 1.22.0, so it's possible that the issue is with new networks. Relevant portions of the logs from 1.22.0-1 and 1.20.8-1 are attached. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-3-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages network-manager depends on: ii adduser3.118 ii dbus 1.12.16-2 ii init-system-helpers1.57 ii libaudit1 1:2.8.5-2+b1 ii libbluetooth3 5.50-1+b1 ii libc6 2.29-6 ii libcurl3-gnutls7.67.0-2 ii libglib2.0-0 2.62.3-2 ii libgnutls303.6.11.1-2 ii libjansson42.12-1 ii libmm-glib01.10.4-0.1 ii libndp01.6-1+b1 ii libnewt0.520.52.21-4 ii libnm0 1.22.0-1 ii libpam-systemd 244-3 ii libpolkit-agent-1-00.105-26 ii libpolkit-gobject-1-0 0.105-26 ii libpsl50.20.2-2 ii libreadline8 8.0-3 ii libselinux13.0-1 ii libsystemd0244-3 ii libteamdctl0 1.29-1 ii libudev1 244-3 ii libuuid1 2.34-0.1 ii policykit-10.105-26 ii udev 244-3 ii wpasupplicant 2:2.9-3+b1 Versions of packages network-manager recommends: ii crda 3.18-1 ii dnsmasq-base [dnsmasq-base] 2.80-1.1 ii iptables 1.8.4-1 ii modemmanager 1.10.4-0.1 ii ppp 2.4.7-2+4.1+b1 Versions of packages network-manager suggests: ii isc-dhcp-client 4.4.1-2 pn libteam-utils -- no debconf information -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 Dec 23 18:19:35 camp NetworkManager[219829]: [1577125175.9758] dhcp4 (wlp0s20f3): state changed bound -> expire Dec 23 18:19:35 camp NetworkManager[219829]: [1577125175.9759] device (wlp0s20f3): DHCPv4: 480 seconds grace period started Dec 23 18:19:35 camp NetworkManager[219829]: [1577125175.9774] sup-iface[0x556830be74c0,wlp0s20f3]: connection disconnected (reason -3) Dec 23 18:19:35 camp NetworkManager[219829]: [1577125175.9798] device (wlp0s20f3): supplicant interface state: completed -> disconnected Dec 23 18:19:36 camp NetworkManager[219829]: [1577125176.5802] manager: sleep: wake requested (sleeping: yes enabled: yes) Dec 23 18:19:36 camp NetworkManager[219829]: [1577125176.5803] device (enp0s31f6): state change: unavailable -> unmanaged (reason 'sleeping', sys-iface-state: 'managed') Dec 23 18:19:36 camp NetworkManager[219829]: [1577125176.6639] device (wlp0s20f3): state change: activated -> unmanaged (reason 'sleeping', sys-iface-state: 'managed') Dec 23 18:19:36 camp NetworkManager[219829]: [1577125176.6640] dhcp4 (wlp0s20f3): canceled DHCP transaction Dec 23 18:19:36 camp NetworkManager[219829]: [1577125176.6640] dhcp4 (wlp0s20f3): state changed expire -> done Dec 23 18:19:36 camp NetworkManager[219829]: [1577125176.6713] manager: NetworkManager state is now CONNECTED_GLOBAL Dec 23 18:19:36 camp NetworkManager[219829]: [1577125176.6916] manager: NetworkManager state is now CONNECTED_LOCAL Dec 23 18:19:36 camp NetworkManager[219829]: [1577125176.6923] device (enp0s31f6): state change: unmanaged -> unavailable (reason 'managed', sys-iface-state: 'managed') Dec 23 18:19:36 camp NetworkManager[219829]: [1577125176.8839] device (wlp0s20f3): state change: unmanaged -> unavailable (reason 'managed', sys-iface-state: 'managed') Dec 23 18:19:37 camp NetworkManager[219829]: [1577125177.1050] device (wlp0s20f3): set-hw-addr: set MAC address to DA:6B:EA:90:07:84 (scanning) Dec 23 18:19:37 camp NetworkManager[219829]: [1577125177.3101] device (F0:5C:77:DA:5B:F8): state change: unmanaged -> unavailable (reason 'managed', sys-iface-state: 'managed') Dec 23 18:19:37 camp NetworkManager[219829]: [1577125177.3125] device (p2p-dev-wlp0s20f3): state change: unmanaged -> unavailabl
Bug#946893: tmuxinator: warns about tmux 3.0a
Package: tmuxinator Version: 1.1.2-1 Severity: normal tmuxinator complains that the version of tmux (3.0a) in use is not supported. While this is fine for upstream, Debian versions of tmuxinator should not warn about Debian versions of tmux. There is an option to suppress this warning, but it cannot be generically applied, since it requires the version number, and it can't be applied in a generic configuration file that ignores the version warning altogether. Debian already patches out warnings about mismatched versions from such things as OpenSSL, so patching this out is not without precedent. Please either do so or provide a generic configuration option that can be used to wholesale ignore this message. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-3-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages tmuxinator depends on: ii ruby 1:2.5.2 ii ruby-erubis 2.7.0-3 ii ruby-thor0.19.4-1 ii ruby-xdg 2.2.3-1 ii tmux 3.0a-1 tmuxinator recommends no packages. tmuxinator suggests no packages. -- no debconf information -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#946879: git: please build package with libsecret credential helper
Package: git Version: 1:2.24.1+next.20191209-1 Severity: wishlist Currently, anyone who wants to store passwords with Git in a secure way must build their own credential helpers from the files in /usr/share/doc. This leads users to use less secure ways of storing passwords, such as using URLs with passwords in them or using the git credential-store helper. It would be great if the libsecret credential helper could be built in its own package so that folks could easily use it. The gnome-keyring one is not required because it implements the libsecret API and so is redundant. If you wanted to create a generic package, you could also add the netrc credential helper, although I believe that's no longer required with recent versions of libcurl. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-3-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages git depends on: ii git-man 1:2.24.1+next.20191209-1 ii libc62.29-6 ii libcurl3-gnutls 7.67.0-2 ii liberror-perl0.17028-1 ii libexpat12.2.9-1 ii libpcre2-8-0 10.34-7 ii perl 5.30.0-9 ii zlib1g 1:1.2.11.dfsg-1+b1 Versions of packages git recommends: ii ca-certificates 20190110 ii less 551-1 ii openssh-client [ssh-client] 1:8.1p1-2 ii patch2.7.6-6 Versions of packages git suggests: ii gettext-base 0.19.8.1-10 pn git-cvs pn git-daemon-run | git-daemon-sysvinit pn git-doc pn git-el ii git-email 1:2.24.1+next.20191209-1 pn git-gui pn git-mediawiki pn git-svn pn gitk pn gitweb -- no debconf information -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#794969: udev: change in network device naming scheme unnecessarily and incorrectly renames WiMAX devices
On 2019-12-02 at 17:04:29, Michael Biebl wrote: > Control: tags -1 + moreinfo > > > Hi > > On Mon, 10 Aug 2015 23:25:36 + "brian m. carlson" > wrote: > > On Sun, Aug 09, 2015 at 05:54:29PM +0200, Marco d'Itri wrote: > > > On Aug 08, "brian m. carlson" wrote: > > > > > > > Previously, my WiMAX device was named something like wmx0. Now, it > > > > appears it's been renamed to enx. First of all, the name > > > > has changed from what it used to be, and now I have to check that it's > > > > not broken anything. There wasn't supposed to be a naming change for > > > > people with the persistent-net rules in place. > > > Indeed: what was the content of your 70-persistent-net.rules file? > > > I suspect that persistent naming just never worked for you for this > > > interface. > > > > The interface is clearly missing: > > > > # PCI device 0x8086:/sys/devices/pci:00/:00:19.0 (e1000e) > > SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", > > ATTR{address}=="f0:de:f1:b8:36:fd", ATTR{dev_id}=="0x0", ATTR{type}=="1", > > KERNEL=="eth*", NAME="eth0" > > > > # PCI device 0x8086:/sys/devices/pci:00/:00:1c.1/:03:00.0 > > (iwlwifi) > > SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", > > ATTR{address}=="64:80:99:4f:73:a0", ATTR{dev_id}=="0x0", ATTR{type}=="1", > > KERNEL=="wlan*", NAME="wlan0" > > > > I suppose the idea was to skip USB devices, thinking that they were all > > removable, but I can't be certain without seeing the generator, which > > has been removed. > > > > > > Secondly, this is not an Ethernet device, so en is not correct (it > > > > should be ww). The device is on the USB bus (using the driver > > > > i2400m-usb). > > > I do not think that such a distinction is relevant here. > > > > If you're going to autogenerate the name, please autogenerate it such > > that it's consistent with the naming scheme. The comment in > > udev-builtin-net_id.c indicates that ww is appropriate here. People > > should be able to predict interface names, such that configuration can > > be autogenerated (e.g. for puppet). Naming some WWAN devices as ww but > > others as en is silly. > > > Is this issue still valid? > I do have an (internal) wimax device which is named wwx02803X, i.e. > has the ww prefix as one would expect. > > If it's still a problem, please attach the output of > udevadm info /sys/class/net/$(iface) I'm unsure. The issue is now four years old and I'm using a different laptop without a WiMAX card. If you're sure that it's been fixed, I'm fine with you closing it. -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#945425: zsh: should run all pipeline elements in subshell in sh mode
Package: zsh Version: 5.7.1-1+b1 Severity: normal POSIX mandates that all elements in a pipeline are run in subshells, but permits extensions that run some or all of those elements in the main shell environment instead. zsh always runs the final element in a pipeline in the normal shell environment, which breaks programs which expect to conform to POSIX. For example, the Git testsuite fails in a variety of ways when zsh is /bin/sh. This behavior is fine as zsh, since in that case it's obvious that extensions are being enabled, but when "emulate sh" is set, the final element in a pipeline should also be run in a subshell for maximum compatibility with POSIX. As an example, the attached program should print "boo", "baz", and "foo", in that order when run under "zsh --emulate sh", but does not: % dash foo.sh boo baz foo % zsh --emulate sh foo.sh boo baz baz -- Package-specific info: Packages which provide vendor completions: Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==-===--=== ii curl 7.66.0-1+b1 amd64command line tool for transferring data with URL syntax ii docker-compose 1.25.0-1all Punctual, lightweight development environments using Docker ii docker.io 19.03.4+dfsg2-2 amd64Linux container runtime ii pulseaudio 13.0-3 amd64PulseAudio sound server ii systemd243-8 amd64system and service manager ii tmuxinator 1.1.2-1 all Create and manage tmux sessions easily ii udev 243-8 amd64/dev/ and hotplug management daemon ii vlc-bin3.0.8-3 amd64binaries from VLC dpkg-query: no path found matching pattern /usr/share/zsh/vendor-functions/ -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-2-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages zsh depends on: ii libc6 2.29-3 ii libcap2 1:2.27-1 ii libtinfo6 6.1+20191019-1 ii zsh-common 5.7.1-1 Versions of packages zsh recommends: ii libc6 2.29-3 ii libncursesw6 6.1+20191019-1 ii libpcre3 2:8.39-12+b1 Versions of packages zsh suggests: pn zsh-doc -- no debconf information -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 foo.sh Description: Bourne shell script signature.asc Description: PGP signature
Bug#942662: libxml2: rejects valid NCName characters
Package: libxml2 Version: 2.9.4+dfsg1-7+b3 Severity: normal XML 1.0 Fifth Edition dramatically increased the range of characters allowed in an NCName, and therefore in an ID (such as an xml:id attribute). However, libxml2 is still using the obsolete fourth edition, which means that it rejects well-formed documents. For example, the following is a well-formed document which is rejected: --- --- Because the document is erroneously considered ill-formed, xsltproc cannot process it, either. The fifth edition came out in 2008, so this is not a new phenomenon. In fact, upstream has a bug open with fixed files at https://bugzilla.gnome.org/show_bug.cgi?id=675373; a suitable patch should be applied to the Debian package. If desired, I can synthesize the files in that bug report into an actual patch, should it be applied. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-trunk-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libxml2 depends on: ii libc6 2.29-2 ii libicu63 63.2-2 ii liblzma5 5.2.4-1+b1 ii zlib1g1:1.2.11.dfsg-1+b1 libxml2 recommends no packages. libxml2 suggests no packages. -- no debconf information -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#942033: muttprofile: allow use of either mutt or neomutt
Package: muttprofile Version: 1.0.1-5 Severity: wishlist Currently, I switched from using mutt to neomutt, although I use the same configuration for both (in the standard mutt location). When I install muttprofile, mutt is automatically installed, even if I have neomutt already present. It would be nice to allow a dependency on either package so folks can choose which version they'd like to use and don't need to have an extra package installed if it's not necessary. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-trunk-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages muttprofile depends on: ii mutt 1.10.1-2.1+b1 ii perl 5.30.0-6 muttprofile recommends no packages. muttprofile suggests no packages. -- no debconf information -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#942008: fwupd: uses SHA-1 for integrity
Package: fwupd Version: 1.3.2-1 Severity: normal When looking at the hashes used to check the integrity of firmware[0], all of them appear to be using SHA-1. In addition, the signatures over the firmware manifests downloaded appear to be using SHA-1 as well. SHA-1 is considered dangerously weak, and other, better alternatives have been available for some time. Fortunately, fwupd supports SHA-256 and SHA-512 as well[1], so it should be easy to switch over. Much like apt, fwupd should stop using or accepting MD5 or SHA-1 both in the manifests and signatures and only accept strong alternatives, such as SHA-2, SHA-3, or BLAKE2. [0] zcat /var/lib/fwupd/remotes.d/lvfs/metadata.xml.gz | grep checksum | perl -pe 's/^.*type="([^"]+)".*$/$1/g' | sort | uniq -c [1] https://github.com/fwupd/fwupd/blob/0917fb6aec177375a2241f57d63e21a71fe19cd6/libfwupd/fwupd-common. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-trunk-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages fwupd depends on: ii libarchive13 3.4.0-1 ii libc6 2.29-2 ii libefiboot137-2 ii libefivar1 37-2 ii libelf10.176-1.1 ii libfwupd2 1.3.2-2 ii libgcab-1.0-0 1.2-5 ii libglib2.0-0 2.62.1-1 ii libgnutls303.6.9-5 ii libgpg-error0 1.36-7 ii libgpgme11 1.13.1-1 ii libgudev-1.0-0 233-1 ii libgusb2 0.3.0-1 ii libjson-glib-1.0-0 1.4.4-2 ii libpolkit-gobject-1-0 0.105-26 ii libsmbios-c2 2.4.1-1 ii libsoup2.4-1 2.68.1-2 ii libsqlite3-0 3.30.0-1 ii libtss2-esys0 2.1.0-4+b1 ii libxmlb1 0.1.8-1+b1 ii shared-mime-info 1.10-1 Versions of packages fwupd recommends: ii bolt 0.8-4 ii fwupd-amd64-signed [fwupd-signed] 1.3.2+1 ii python33.7.5-1 fwupd suggests no packages. -- Configuration Files: /etc/fwupd/remotes.d/lvfs-testing.conf changed: [fwupd Remote] Enabled=false Title=Linux Vendor Firmware Service (testing) Keyring=gpg MetadataURI=https://cdn.fwupd.org/downloads/firmware-testing.xml.gz ReportURI= Username= Password= OrderBefore=lvfs,fwupd ApprovalRequired=false /etc/fwupd/remotes.d/lvfs.conf changed: [fwupd Remote] Enabled=true Title=Linux Vendor Firmware Service Keyring=gpg MetadataURI=https://cdn.fwupd.org/downloads/firmware.xml.gz ReportURI= OrderBefore=fwupd ApprovalRequired=false -- no debconf information -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#941293: postfix: init script falsely detects postfix as not running when in a container
Source: postfix Version: 3.4.5-1 Severity: important postfix uses an init script which tries to read /proc/*/exe to determine whether the process is running. If this file is not readable, or the symlink cannot be dereferenced, then the init script always thinks postfix is not running. Consequently, attempts to restart postfix using the init script fail. This configuration occurs when running in a Docker container, because by default containers lack the SYS_PTRACE capability. Using a Docker container to test Postfix configurations is therefore not possible with the default init script[0]. Using systemd in a container is not a viable approach because (at least as shipped in Debian) it hangs because it cannot mount filesystems (which is also not allowed in containers). Postfix should start, stop, restart, and provide status output correctly when using the default init script in a container. Steps to reproduce: docker run -it --rm debian:buster # (also works with debian:sid) # Inside the container: apt-get update DEBIAN_FRONTEND=noninteractive apt-get -y install postfix procps service postfix start service postfix status # Notice the above printed the following: "postfix is not running." ps ax | grep -v grep | grep postfix # Notice that that statement is clearly false. service postfix restart # Notice that it fails because "the Postfix mail system is already running". [0] My particular use case is testing Postfix configurations with Puppet, which will start and stop services, so the inability to restart the service to apply new configurations is, well, limiting. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-rc5-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#941048: fwupd: provide option to never send report
On 2019-09-25 at 20:09:11, mario.limoncie...@dell.com wrote: > OK, 1.3.2 release of fwupd will have this: > https://github.com/fwupd/fwupd/commit/f1accad201b24565f3e19daa09d26b477c3f4b9c That's great to hear. I'm looking forward to it. -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#941048: fwupd: provide option to never send report
On 2019-09-24 at 02:22:44, mario.limoncie...@dell.com wrote: > Oh it looks like that just stops it from actually going out. To > prevent the prompt you'll need to launch fwupdmgr with > --no-unreported-check. Yes, I appreciate that the command-line option is there. However, the idea is not to need this option every time and to disable the feature globally, which is why I opened this bug report. -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#941048: fwupd: provide option to never send report
On 2019-09-24 at 01:00:01, mario.limoncie...@dell.com wrote: > To accomplish this, I believe you can just comment out ReportURI= in > the LVFS remote and restart the daemon. (IE > /etc/fwupd/remotes.d/lvfs.conf) That doesn't seem to be effective. Running "fwupdmgr get-updates" still prompts, even after restarting the daemon. -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#941048: fwupd: provide option to never send report
Package: fwupd Version: 1.2.10-2 Severity: wishlist There are a wide variety of situations where a user may never want to send a report about successful firmware update. For example, I've worked at a nonprofit dealing with mental health where sending reports to the vendor was forbidden as a blanket policy because they might contain sensitive client data. Other people are concerned about privacy, and yet others may be on a metered or slow connection and wish not to send unneeded data. Currently, every time "fwupd get-updates" runs, it prompts to send a report about the last update. This is bothersome for users who never wish to send an update. It would be beneficial if fwupd learned a configuration option to never send an update for any reason and to avoid prompting to do so. If a configuration option already exists to do this, consider this a request to document the behavior or refer to a manual page for the configuration file in the fwupdmgr(1) manual page so it can be easily discovered. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-rc5-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages fwupd depends on: ii libarchive13 3.4.0-1 ii libc6 2.29-2 ii libefiboot137-2 ii libefivar1 37-2 ii libelf10.176-1.1 ii libfwupd2 1.2.10-2 ii libgcab-1.0-0 1.2-5 ii libglib2.0-0 2.60.6-2 ii libgnutls303.6.9-5 ii libgpg-error0 1.36-7 ii libgpgme11 1.13.1-1 ii libgudev-1.0-0 233-1 ii libgusb2 0.3.0-1 ii libjson-glib-1.0-0 1.4.4-2 ii libpolkit-gobject-1-0 0.105-26 ii libsmbios-c2 2.4.1-1 ii libsoup2.4-1 2.64.2-2 ii libsqlite3-0 3.29.0-2 ii libxmlb1 0.1.8-1+b1 ii shared-mime-info 1.10-1 Versions of packages fwupd recommends: ii bolt 0.8-4 ii fwupd-amd64-signed [fwupd-signed] 1.2.10+2 ii python33.7.3-1 ii tpm2-abrmd 2.1.1-1+b1 ii tpm2-tools 3.1.3-2+b1 fwupd suggests no packages. -- no debconf information -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#935772: libbsd0: lacks strnvisx
Package: libbsd0 Version: 0.10.0-1 Severity: normal libbsd0 seems to have several of the vis(3) functions and documents strnvisx(3), but it isn't in the shared library: $ nm -D /usr/lib/x86_64-linux-gnu/libbsd.so.0 | grep strnvisx This can easily be worked around by using strsnvisx(3) with an empty extra string, but since the function is documented, it probably makes sense to include it. -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_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 libbsd0 depends on: ii libc6 2.28-10 libbsd0 recommends no packages. libbsd0 suggests no packages. -- no debconf information -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#934998: asciidoctor: new upstream version
Package: asciidoctor Version: 1.5.8-1 Severity: wishlist Asciidoctor has released a couple new versions and now has v2.0.10 available. It's also now semantically versioned for fewer headaches in the future. Is it possible that a new version could be packaged? -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_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 asciidoctor depends on: ii ruby1:2.5.1 ii ruby-asciidoctor1.5.8-1 ii ruby2.0 [ruby-interpreter] 2.0.0.484+really457-3 ii ruby2.1 [ruby-interpreter] 2.1.5-4 ii ruby2.2 [ruby-interpreter] 2.2.4-1 asciidoctor recommends no packages. asciidoctor suggests no packages. -- no debconf information -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#934791: libgtk-3-0: complains when attempting to register already registered client
On 2019-08-15 at 07:34:00, Simon McVittie wrote: > Control: tags -1 + moreinfo > > On Wed, 14 Aug 2019 at 23:48:09 +0000, brian m. carlson wrote: > > GTK+ produces the following warning when attempting to register a client > > with the session manager and the client is already registered: > > > > (caja:3729): Gtk-WARNING **: 02:59:57.229: Failed to register client: > > GDBus.Error:org.gnome.SessionManager.AlreadyRegistered: Unable to register > > client > > Under what circumstances does this occur? I see the program in question > is caja. What desktop environment is this in, and how can this bug be > reproduced? This is in MATE with a typical mate-session startup. This message gets logged to ~/.xsession-errors, and it's trivially reproducible by running "killall caja". I believe I've seen it before when running from the command line, but I can't seem to reproduce that now. I unfortunately don't have a fresh session to test against, and MATE isn't likely to run nicely in a Docker container, which is my usual test environment for bugs. > (I assume it's either GNOME, one of the various GNOME forks, or XFCE, > based on the D-Bus APIs used in the function that contains that warning.) > > I don't know the session manager API well enough to know immediately > whether this message indicates a bug in the session manager, the > application, GTK, or something else. I see this much like reporting an ENOENT with unlink(2): what you wanted has already been done, so barring some specific circumstance where you know it will be a problem, there's no reason to report an error. -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#934655: libglib2.0-0: provide environment variable to suppress or redirect logging
On 2019-08-14 at 07:09:19, Philip Withnall wrote: > In every situation where I’ve seen warnings (compile time, or run time) > hidden from developers, those warnings have very rarely been fixed. > Making them visible has increased the number of warnings which have > been fixed. > > Filing bugs against applications, which point out specific warnings > which need fixing is, I feel, a much better use of people’s time than > inventing new and innovative ways to hide those warnings. I've filed bugs #934790 through #934792 for some of the issues I've seen. From what I understand of the situation, #934791 and #934792 are likely bugs in GTK or GDK. As previously mentioned, I'm happy if GLib learns a way to suppress or redirect logging and that will meet my needs adequately. However, if that's not something the GNOME developers want to do, then I'm happy to keep sending any issues I see with GTK or GDK their way. I'm also suggesting to maintainers of relevant bugs that g_return*_if_fail could be patched to not warn to standard error, which would fix the majority of these issues, and would also be a satisfactory solution from the GLib side, although GTK would still need some additional patching. -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#934792: network-manager-gnome: produce GDK drawing warning
Package: network-manager-gnome Version: 1.8.22-2 Severity: minor nm-applet produces the following warning to standard error: (nm-applet:3764): Gdk-CRITICAL **: 02:59:58.580: gdk_window_thaw_toplevel_updates: assertion 'window->update_and_descendants_freeze_count > 0' failed I suspect this is likely a bug in GTK+ unless nm-applet does a lot of low-level drawing itself, so feel free to reassign it there. Other ways to solve this problem could be to compile GDK with G_DISABLE_CHECKS or to fix GLib not to report to standard error in g_return_*_if_fail. -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_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 network-manager-gnome depends on: ii dbus-user-session [default-dbus-session-bus] 1.12.16-1 ii dbus-x11 [dbus-session-bus] 1.12.16-1 ii dconf-gsettings-backend [gsettings-backend] 0.30.1-2 ii libatk1.0-0 2.32.0-2 ii libayatana-appindicator3-10.5.3-4 ii libc6 2.28-10 ii libcairo2 1.16.0-4 ii libgdk-pixbuf2.0-02.38.1+dfsg-1 ii libglib2.0-0 2.60.6-2 ii libgtk-3-03.24.10-1 ii libjansson4 2.12-1 ii libmm-glib0 1.10.0-1 ii libnm01.20.0-1 ii libnma0 1.8.22-2 ii libnotify40.7.7-4 ii libpango-1.0-01.42.4-7 ii libpangocairo-1.0-0 1.42.4-7 ii libsecret-1-0 0.18.7-1 ii libselinux1 2.9-2+b2 ii mate-polkit [polkit-1-auth-agent] 1.22.0-1 ii network-manager 1.20.0-1 ii policykit-1-gnome [polkit-1-auth-agent] 0.105-7 Versions of packages network-manager-gnome recommends: ii gnome-keyring 3.28.2-5 ii iso-codes 4.3-1 ii mate-notification-daemon [notification-daemon] 1.22.0-1 ii mobile-broadband-provider-info 20190618-2 ii notification-daemon 3.20.0-4 Versions of packages network-manager-gnome suggests: ii network-manager-openconnect-gnome 1.2.4-2 ii network-manager-openvpn-gnome 1.8.10-1 ii network-manager-pptp-gnome 1.2.8-2 pn network-manager-vpnc-gnome -- no debconf information -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#934791: libgtk-3-0: complains when attempting to register already registered client
Package: libgtk-3-0 Version: 3.24.10-1 Severity: minor GTK+ produces the following warning when attempting to register a client with the session manager and the client is already registered: (caja:3729): Gtk-WARNING **: 02:59:57.229: Failed to register client: GDBus.Error:org.gnome.SessionManager.AlreadyRegistered: Unable to register client GTK+ should either not attempt to register the client in this case or should detect that it's already registered and not warn about it to standard error. -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_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 libgtk-3-0 depends on: ii adwaita-icon-theme 3.30.1-1 ii hicolor-icon-theme 0.17-2 ii libatk-bridge2.0-0 2.32.0-2 ii libatk1.0-0 2.32.0-2 ii libc62.28-10 ii libcairo-gobject21.16.0-4 ii libcairo21.16.0-4 ii libcolord2 1.4.3-4 ii libcups2 2.2.10-6 ii libepoxy01.5.3-0.1 ii libfontconfig1 2.13.1-2 ii libfreetype6 2.9.1-4 ii libfribidi0 1.0.5-3.1 ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1 ii libglib2.0-0 2.60.6-2 ii libgtk-3-common 3.24.10-1 ii libharfbuzz0b2.5.3-1 ii libjson-glib-1.0-0 1.4.4-2 ii libpango-1.0-0 1.42.4-7 ii libpangocairo-1.0-0 1.42.4-7 ii libpangoft2-1.0-01.42.4-7 ii librest-0.7-00.8.1-1 ii libsoup2.4-1 2.64.2-2 ii libwayland-client0 1.17.0-1 ii libwayland-cursor0 1.17.0-1 ii libwayland-egl1 1.17.0-1 ii libx11-6 2:1.6.7-1 ii libxcomposite1 1:0.4.4-2 ii libxcursor1 1:1.2.0-2 ii libxdamage1 1:1.1.5-1 ii libxext6 2:1.3.3-1+b2 ii libxfixes3 1:5.0.3-1 ii libxi6 2:1.7.9-1 ii libxinerama1 2:1.1.4-2 ii libxkbcommon00.8.2-1 ii libxml2 2.9.4+dfsg1-7+b3 ii libxrandr2 2:1.5.1-1 ii shared-mime-info 1.10-1 Versions of packages libgtk-3-0 recommends: ii libgtk-3-bin 3.24.10-1 Versions of packages libgtk-3-0 suggests: ii gvfs 1.38.1-5 ii librsvg2-common 2.44.14-1 Versions of packages libgtk-3-0 is related to: pn appmenu-gtk3-module pn fcitx-frontend-gtk3 pn gcin-gtk3-immodule pn gtk-vector-screenshot pn gtk3-engines-xfce pn gtk3-im-libthai pn hime-gtk3-immodule ii ibus-gtk3 1.5.19-4+b1 pn imhangul-gtk3 ii libcanberra-gtk3-module 0.30-7 pn libcaribou-gtk3-module pn libgtk3-nocsd0 pn maliit-inputcontext-gtk3 pn packagekit-gtk3-module pn scim-gtk-immodule pn topmenu-gtk3 pn uim-gtk3 pn uim-gtk3-immodule -- no debconf information -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#934790: atril: sometimes prints GLib error message when exiting
Package: atril Version: 1.22.1-1 Severity: minor When running atril from the command line, it sometimes prints the following error message when it exits: (atril:308857): GLib-CRITICAL **: 23:34:21.398: g_source_set_ready_time: assertion 'source->priv != NULL' failed This does not always occur, but occurs most of the time when invoked with a PDF file from the command line. If you don't think this message is worth fixing, you can ask the glib2.0 maintainer to compile with G_DISABLE_CHECKS to suppress this warning, or to patch GLib not to produce warnings to stderr in g_return_*_if_fail. -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_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 atril depends on: ii atril-common 1.22.1-1 ii dconf-gsettings-backend [gsettings-backend] 0.30.1-2 ii libatk1.0-0 2.32.0-2 ii libatrildocument31.22.1-1 ii libatrilview31.22.1-1 ii libc62.28-10 ii libcairo-gobject21.16.0-4 ii libcairo21.16.0-4 ii libcaja-extension1 1.22.1-1 ii libgail-3-0 3.24.10-1 ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1 ii libglib2.0-0 2.60.6-2 ii libgtk-3-0 3.24.10-1 ii libice6 2:1.0.9-2 ii libjavascriptcoregtk-4.0-18 2.24.3-1 ii libpango-1.0-0 1.42.4-7 ii libpangocairo-1.0-0 1.42.4-7 ii libsecret-1-00.18.7-1 ii libsm6 2:1.2.3-1 ii libsoup2.4-1 2.64.2-2 ii libwebkit2gtk-4.0-37 2.24.3-1 ii libx11-6 2:1.6.7-1 ii libxml2 2.9.4+dfsg1-7+b3 ii shared-mime-info 1.10-1 ii zlib1g 1:1.2.11.dfsg-1+b1 Versions of packages atril recommends: ii dbus-user-session [default-dbus-session-bus] 1.12.16-1 ii dbus-x11 [dbus-session-bus] 1.12.16-1 ii gvfs 1.38.1-5 Versions of packages atril suggests: ii caja 1.22.1-1 ii poppler-data 0.4.9-2 pn unrar -- no debconf information -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#934655: libglib2.0-0: provide environment variable to suppress or redirect logging
On 2019-08-14 at 07:09:19, Philip Withnall wrote: > Sorry, I think you’re conflating two different types of programs here. > Command line applications like git have very different output > requirements on stderr/stdout from graphical programs. Command line > programs don’t normally use GTK, so shouldn’t see any of the warnings > you mention above. I would be very surprised if command line programs > using GLib (not GTK) emitted different warnings with different versions > of GLib. If they do, can you please provide me with concrete examples > and I can advise you about how to eliminate them. Lots of people run GTK+ programs from the command line. I do this all the time, and that's why this is an issue. I agree that many people do not, but those people who do are often heavy terminal users and this really bites them. Debian systems also invoke GUI programs from mailcap files and xdg-open, both of which are frequently used from the command line and command line tools. > GTK and GLib are separate libraries. They are indeed separate libraries, but they are developed as a set and are highly intertwined. GTK+ programs use the GLib logging functions for API misuse warning messages. Other libraries that are used with GTK+ also use these logging functions for the same purpose, which necessitates a change in GLib, or an agreement by GTK+ and the other UI libraries about how to honor the user's wishes not to receive these messages. If there were a simple solution where GTK+ and Clutter and all of the other libraries just called something like g_report_api_misuse, then there could be an environment variable or setting just for that, but I don't believe such a function exists. Since it's currently impossible to distinguish between GTK+'s warning messages and other messages, a bigger hammer is required. If you're willing to add such a function and allow users to suppress or redirect the output, I'm happy to reassign this bug to GTK+. > > Ultimately, I think it's most appropriate to let users decide for > > themselves if they would like to see non-user-visible issues on their > > terminal. I'm not even asking for this to be the default, just an > > option > > users can turn on. > > If it’s not on by default, almost all users will never find out about > it. If your argument is that seeing the warnings is only useful for > developers, then such an option should be on by default and developers > would have to explicitly turn it off. I'm not even requesting that they be disabled by default, although I do feel that they should be. I'm requesting an environment variable users can set to disable GLib logging while keeping it on by default. Alternatively, an environment variable directing GLib logging to a file would meet my needs, provided it supported character specials. I'd also be happy with just reporting these errors when developer mode is turned on during the build, or when -Werror is passed as a flag to the compiler. These are settings that will be turned on in development, but will not be enabled for non-development uses. I'm happy to look for solutions that solve the problem for me and all the other users that are acceptable to upstream. > Filing bugs against applications, which point out specific warnings > which need fixing is, I feel, a much better use of people’s time than > inventing new and innovative ways to hide those warnings. You seem to have ignored the part of my previous mail where I stated that this is not an effective solution to the problem. Some projects have a much longer release cycle than GLib, meaning even the latest versions of a release may acquire new warnings as new GLib and GTK+ releases come out. -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#934655: libglib2.0-0: provide environment variable to suppress or redirect logging
On 2019-08-13 at 06:12:30, Philip Withnall wrote: > Hi, > > I can’t speak for the Debian project, but as an upstream GLib developer > I can say such an environment variable would not be welcome upstream. > > Hiding such warnings makes them less likely to be fixed. It’s a way of > sweeping bugs under the carpet which I don’t want to encourage. Each > warning emitted by GTK or GLib indicates a non-trivial bug in the code > which is calling it, which should be fixed. Unfortunately, it's often impossible to write code which works on multiple versions of GTK+ without warnings. I took a version of GVim which worked fine on Debian unstable with GTK+3 but produced copious warnings on CentOS 7. This makes it difficult for folks who would like to upgrade one single component on a system without rebuilding the entire GTK+ stack. In addition, an upgrade of GTK+ can cause previously working programs to produce errors where they did not before, causing problems for users. In addition, Unix programs typically produce output to standard error to reflect a user-relevant error: something that the user has done wrong or that prevents the program from functioning in the way the user requested. These warnings are not user relevant: they reflect a developer error, not a problem that reflects a user-visible failure. From the user perspective, everything is functioning as intended, so output to standard error is not appropriate. And finally, overwhelmingly, developers take a long time to fix warnings like this, if they get fixed at all. Perhaps they don't see the use case of running graphical programs like PDF viewers from the command line. More likely, they are overwhelmed with other issues and consider this low priority. I appreciate that these reflect a defect in the program that should be fixed, but it isn't fair to force users to either fix these defects for themselves or deal with terminal junk. As a Git developer, I can tell you people would be extremely unhappy if libpcre or libcurl produced errors on their terminals when they ran Git, even if those were bugs in Git itself. I'm not sure why GLib should be different in this regard. Ultimately, I think it's most appropriate to let users decide for themselves if they would like to see non-user-visible issues on their terminal. I'm not even asking for this to be the default, just an option users can turn on. -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#934655: libglib2.0-0: provide environment variable to suppress or redirect logging
Package: libglib2.0-0 Version: 2.60.6-1 Severity: normal Currently, GLib and various other GTK+-related software provide logging, which goes to stdout or stderr. Much of this logging is developer focused and basically warns developers that they are doing questionable things that one or another toolkit is unhappy with. While this is great for debugging and developer visibility, it's not great for end users who invoke GTK+-based programs from the terminal, where the messages obscure previous output, sometimes scrolling the screen significantly. In the past, GVim has been bitten by this prominently, but various other software, including atril (a PDF viewer) and other tools commonly run from the command line, have fallen victim to it as well. The most inconvenient part for users is that upgrading one of the shared libraries a piece of software uses can cause it to emit many more warnings than before, with little recourse. Asking individual packages to fix these issues is not effective, because, as is the nature with open source, developers lack the time to effectively fix all issues, and these issues are seen as purely cosmetic. I've asked several packages to do so, and the turnaround time for fixing these issues is usually measured in years, if they are fixed at all. GLib should learn an environment variable to either suppress non-fatal messages (i.e., those that do not cause the program to abort) or redirect them to a file (e.g., /dev/null). Even if upstream does not want this feature, Debian should provide it. This is a common issue with multiple questions online, and would provide a large amount of value to users. -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_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 libglib2.0-0 depends on: ii libc62.28-10 ii libffi6 3.2.1-9 ii libmount12.34-0.1 ii libpcre3 2:8.39-12+b1 ii libselinux1 2.9-2+b2 ii zlib1g 1:1.2.11.dfsg-1+b1 Versions of packages libglib2.0-0 recommends: ii libglib2.0-data 2.60.6-1 ii shared-mime-info 1.10-1 ii xdg-user-dirs 0.17-2 libglib2.0-0 suggests no packages. -- no debconf information -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#481238: host key fingerprints in .ssh/config
On 2008-05-26 at 10:12:49, Colin Watson wrote: > On Wed, May 14, 2008 at 07:13:32PM +0100, martin f krafft wrote: > > Just an idea without having given it much thought: > > > > if there are host key fingerprints in DNS, why not add > > a configuration option to ssh_config so that I could say: > > > > Host foo > > HostKeyFingerprint 99:11:ed:30:03:41:ff:9f:f3:74:bd:7d:e1:8f:04:44 > > > > which would then cause even StrictHostKeyChecking to accept the host > > key into .ssh/known_hosts if the fingerprint matched? > > I'm not sure I understand. Why not just add the fingerprint to > ~/.ssh/known_hosts directly? What does putting it in the configuration > file gain you? One way in which this would be helpful is not in the configuration file, but in scripting. All the options in ".ssh/config" can also be used on the command line. If you can write "ssh -o HostKeyFingerprint=foo", then you can securely connect in a script without needing "-o StrictHostKeyChecking=no". This would be enormously valuable as a way to write secure command-line scripts without having to embed a full public key. It would also match the new OpenSSH feature to allow specifying a fingerprint at the prompt. -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#931966: virt-what: Docker detection is broken
Package: virt-what Version: 1.19-1 Severity: normal When running virt-what inside a Docker container, no output is produced. This is because virt-what uses the presence of /.dockerinit, which is no longer used when running inside a Docker container. It's probably best to do something like "grep docker /proc/1/cgroup" instead. -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_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 virt-what depends on: ii dmidecode 3.2-2 ii libc6 2.28-10 virt-what recommends no packages. virt-what suggests no packages. -- no debconf information -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#930893: augeas-lenses: dovecot lens cannot parse default /etc/dovecot/conf.d/10-mail.conf
Package: augeas-lenses Version: 1.12.0-1 Severity: important Augeas cannot parse the default Dovecot /etc/dovecot/conf.d/10-mail.conf file because it cannot parse the "!" in the "protocol !indexer-worker" block on line 268. This means that Puppet cannot modify this file on a default Debian buster system. This is fixed upstream with https://github.com/hercules-team/augeas/commit/5aede84cbddeee48d2722c5e36b53f2b2b596cf4 and should probably be backported to the version in buster. -- System Information: Debian Release: 10.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled augeas-lenses depends on no packages. augeas-lenses recommends no packages. Versions of packages augeas-lenses suggests: pn augeas-doc -- no debconf information -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#930888: augeas-lenses: postfix master lens cannot parse default /etc/postfix/master.cf
Package: augeas-lenses Version: 1.12.0-1 Severity: important Tags: upstream The default augeas lens for Postfix's master.cf cannot parse the default configuration file. The configuration file contains the following line: postlog unix-dgram n - n - 1 postlogd Augeas does not understand the "unix-dgram" portion, since the lens contains a list of enumerated types and it is not among them. This prevents Puppet from being used to modify this file on a stock Debian buster system. -- System Information: Debian Release: 10.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled augeas-lenses depends on no packages. augeas-lenses recommends no packages. Versions of packages augeas-lenses suggests: pn augeas-doc -- no debconf information -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#921600: closed by "Arnaud Rebillout" ()
On Fri, May 10, 2019 at 02:12:04AM +, Debian Bug Tracking System wrote: > > This bug was fixed upstream already, see: > - https://github.com/docker/libnetwork/pull/2343 > - https://github.com/docker/libnetwork/pull/2339#issuecomment-487207550 Unfortunately, this requires Docker 18.09.4 or newer, and even experimental has only 18.09.3. Without an update or a patch, Docker continues to use iptables-legacy, and as a consequence things still fail to work. Could you please update to a newer version or apply a patch? It's probably better to apply a patch for buster, while uploading a newer version may be appropriate for unstable or experimental. -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#921637: [pkg-go] Bug#921637: FTBFS: /usr/lib/ruby/vendor_ruby/ronn/roff.rb:165:in `block_filter': undefined method
On Sat, Feb 16, 2019 at 09:55:16PM -0500, Andrew Janke wrote: > I've confirmed this is the https://github.com/apjanke/ronn-ng/issues/24 bug > in ronn-ng. > > It looks liike an easy fix and I have pushed a ronn-ng 0.8.1.beta.1 > gem/release with the fix. Are you able to test against a prerelease gem? > > I've tested locally and it fixed the problem for git-lfs man generation. > I've also added an ordered-list example to Ronn-NG's internal test suite. It would be great if we could get this patch into buster. I realize that a new version may not be possible, but applying a patch to fix an FTBFS might be. As an upstream Git LFS maintainer, I'm already seeing people trying to build git-lfs packages on buster and (in Ubuntu) disco and failing to do so because of this bug. It will be difficult for us to build our own packages on buster if this isn't fixed. -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#921600: docker.io: use of iptables-legacy is incompatible with nftables-based iptables
On Thu, Feb 07, 2019 at 11:12:36AM +0700, Arnaud Rebillout wrote: > Hi, > > did you report that issue upstream? I found a related thread at: > > https://github.com/moby/moby/issues/26824 > > This thread mentions a workaround: deactivate the iptables integration > via |--iptables=false| and then set the right rules for nftables by hand. Well, it's already known upstream that the nftables-based implementation doesn't work. The solution they implemented was to use iptables-legacy instead of fixing the code, which is, uh, undesirable. I don't believe that using --iptables=false works. It's broken upstream (see https://github.com/docker/for-linux/issues/136). > I'm not so really familiar with network filtering, but I think we can't > do much here, only upstream can work on that. Feel free to share your > use-case with them :) It could be helpful if someone from Debian pointed out to upstream that in buster, Docker containers will fail to work by default with any secure firewall configuration. Moreover, this package probably needs to conflict with the new iptables package, since it cannot usefully work in conjunction with it. -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#921600: docker.io: use of iptables-legacy is incompatible with nftables-based iptables
Package: docker.io Version: 18.09.1+dfsg1-5 Severity: important I run Docker on my laptop to allow me to test various environments, such as Debian stable. I also use ufw to provide a firewall to restrict access to most ports. However, these two programs are incompatible. ufw uses the nftables-based iptables and restricts forwarding. Docker uses iptables-legacy, but because the nftables-based rules take precedence, forwarding doesn't occur, and hence networking is broken (TCP and UDP don't work). Since programs are going to increasingly use the regular iptables, it's important that Docker function with whatever option is the default. -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_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 docker.io depends on: ii adduser 3.118 ii iptables1.8.2-3 ii libc6 2.28-6 ii libdevmapper1.02.1 2:1.02.155-2 ii libltdl72.4.6-9 ii libnspr42:4.20-1 ii libnss3 2:3.42-1 ii libseccomp2 2.3.3-3 ii libsystemd0 240-5 ii lsb-base10.2018112800 ii runc1.0.0~rc6+dfsg1-1 ii tini0.18.0-1 Versions of packages docker.io recommends: ii ca-certificates 20190110 ii cgroupfs-mount 1.4 ii git 1:2.20.1+next.20190129-1 pn needrestart ii xz-utils 5.2.4-1 Versions of packages docker.io suggests: pn aufs-tools pn btrfs-progs ii debootstrap 1.0.114 pn docker-doc ii e2fsprogs1.44.5-1 ii rinse3.3 pn xfsprogs pn zfs-fuse | zfsutils -- no debconf information -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#913414: [Pkg-rust-maintainers] Bug#913414: Bug#913414: rustc: fails to compile release binaries due to non -fPIC code
On Sat, Nov 17, 2018 at 08:34:25AM +0100, Sylvestre Ledru wrote: > Hello > > > Does it work with 1:7.0.1~+rc2-3? > I tried to reproduce it and I am getting: > error: Edition 2018 is unstable and only available for nightly builds of > rustc. I don't think the version in unstable will build clippy, but I've confirmed that my personal project which was broken by this bug is now fixed, so I think this can be closed now. -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#913271: segfault - broken rust compiling
On Thu, Nov 08, 2018 at 09:29:43PM +0100, Sylvestre Ledru wrote: > Do you have more info than "it segfaults"? I can provide some reproduction steps, if that's helpful. 1. Install rustc and cargo. 2. git clone https://github.com/rust-lang-nursery/rust-clippy.git 3. cd rust-clippy 4. git checkout v0.0.212 5. cargo build --verbose 6. Notice build failures due to SIGSEGV. Note that if instead you compile with "cargo build --verbose --release" in step 5, you get #913414. rustc did work as recently as November 3, since a project of mine that exhibits the same behavior has that as its most recent commit. -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#913414: rustc: fails to compile release binaries due to non -fPIC code
Package: rustc Version: 1.30.0+dfsg1-2 Severity: important If you attempt to build a release binary, rustc fails because of a bad relocation when making a PIE object. Steps to reproduce: 1. git clone https://github.com/rust-lang-nursery/rust-clippy.git 2. cd rust-clippy 3. git checkout v0.0.212 4. cargo build --verbose --release 5. Notice that the build fails. 6. Notice messages like the following: = note: /usr/bin/ld: /home/bmc/checkouts/external/rust-clippy/target/release/build/serde-3ddadc5e75c3de00/build_script_build-3ddadc5e75c3de00.build_script_build.140spq3r-cgu.2.rcgu.o: relocation R_X86_64_32S against `.rodata.cst16' can not be used when making a PIE object; recompile with -fPIC /usr/bin/ld: /home/bmc/checkouts/external/rust-clippy/target/release/build/serde-3ddadc5e75c3de00/build_script_build-3ddadc5e75c3de00.build_script_build.140spq3r-cgu.4.rcgu.o: relocation R_X86_64_32 against symbol `rust_eh_personality' can not be used when making a PIE object; recompile with -fPIC /usr/bin/ld: /home/bmc/checkouts/external/rust-clippy/target/release/build/serde-3ddadc5e75c3de00/build_script_build-3ddadc5e75c3de00.build_script_build.140spq3r-cgu.6.rcgu.o: relocation R_X86_64_32 against symbol `rust_eh_personality' can not be used when making a PIE object; recompile with -fPIC /usr/bin/ld: /home/bmc/checkouts/external/rust-clippy/target/release/build/serde-3ddadc5e75c3de00/build_script_build-3ddadc5e75c3de00.build_script_build.140spq3r-cgu.9.rcgu.o: relocation R_X86_64_32 against symbol `rust_eh_personality' can not be used when making a PIE object; recompile with -fPIC /usr/bin/ld: final link failed: nonrepresentable section on output collect2: error: ld returned 1 exit status I see similar errors on a project of my own which compiled fine on November 3. I also see this failure with rust 1.31.0 beta from experimental. -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_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 rustc depends on: ii binutils 2.31.1-7 ii gcc 4:8.2.0-2 ii libc6 2.27-8 ii libc6-dev [libc-dev] 2.27-8 ii libgcc1 1:8.2.0-9 ii libllvm7 1:7.0.1~+rc2-2 ii libstd-rust-dev 1.30.0+dfsg1-2 ii libstdc++68.2.0-9 Versions of packages rustc recommends: ii cargo 0.31.0-2 ii rust-gdb 1.30.0+dfsg1-2 Versions of packages rustc suggests: ii rust-doc 1.30.0+dfsg1-2 pn rust-src -- no debconf information -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#898969: dnssec-trigger: fails with OpenSSL in experimental due to too-small key
On Mon, Oct 01, 2018 at 08:06:25PM -0700, Diane Trout wrote: > On Mon, 2018-10-01 at 20:23 +0200, Lee Garrett wrote: > > Hi, > > > > Any update on this bug? dnssec-trigger will be autoremoved due to > > this bug > > tomorrow. I'd like to see it in buster, though. > > > > Ooops I forgot, Also does this bug impact unbound? I tried checking the > unbound maintainer scripts and they're not doing anything to handle > this case > > What's > sudo -s openssl x509 \ > -in /etc/dnssec-trigger/dnssec_trigger_control.pem -text | \ > grep 'Public-Key' > > Look like on an effected system? I can't tell you for certain anymore, since I regenerated the key, but I ran a similar command at the time and it was 1536-bit. > On mine is 3072, and I don't seem to be impacted. > > I'm guessing I can use that to determine if I need to regenerate the > key Yes, that would be fine. Anything smaller than 2048 bits would require regeneration. > The other option is to just delete the key and regenerate it on the > specific version upgrade. If you're relying on the keygen target, note that as of the time I filed this bug report, it wrote the keys into the wrong location. I haven't checked if it's been fixed. -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#909338: clang-format: lacks symlink to git-clang-format
Package: clang-format Version: 1:6.0-43 Severity: normal The clang-format package depends on clang-format-6.0, which provides a git-clang-format-6.0. However, the clang-format package doesn't provide an unversioned symlink. This makes using the git clang-format tool from various scripts (such as Git's makefile) much more difficult. Could you please include a git-clang-format symlink as part of the clang-format package? -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.17.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_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 clang-format depends on: ii clang-format-6.0 1:6.0.1-9 clang-format recommends no packages. clang-format suggests no packages. -- no debconf information -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#860052: logcheck MIME encoding
Could we get the patch in this bug report applied? At least once a week I run into problems with bounced messages due to this bug. There are at least two independent pull requests on the salsa.debian.org that implement variants of this patch, and I'm happy to revise mine at any time to improve it if necessary. If there's anything else I can do to help get this bug fixed, please let me know. -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#900717: xserver-xorg-core: upgrade to 1.20 breaks dosbox mouse capture
Package: xserver-xorg-core Version: 2:1.20.0-2 Severity: normal After a recent upgrade and reboot, dosbox is no longer able to capture the mouse in windowed mode, even if explicitly requested (e.g. using Ctrl-F10). This renders any mouse-using games unplayable. During this time, X.org has been upgraded, and it appears[0] that X.org 1.20 is the cause of this issue. Could you please investigate this issue and if appropriate, upload a fixed version? [0] https://bbs.archlinux.org/viewtopic.php?id=237587 Note: the included log file has been truncated because it was 106 MiB. -- Package-specific info: /etc/X11/X does not exist. /etc/X11/X is not a symlink. /etc/X11/X is not executable. VGA-compatible devices on PCI bus: -- 00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 520 [8086:1916] (rev 07) /etc/X11/xorg.conf does not exist. /etc/X11/xorg.conf.d does not exist. /etc/modprobe.d contains no KMS configuration files. Kernel version (/proc/version): --- Linux version 4.16.0-2-amd64 (debian-ker...@lists.debian.org) (gcc version 7.3.0 (Debian 7.3.0-19)) #1 SMP Debian 4.16.12-1 (2018-05-27) Xorg X server log files on system: -- -rw-r--r-- 1 root root 37721 Jan 20 2017 /var/log/Xorg.1.log -rw-r--r-- 1 root root 110316994 Jun 3 22:35 /var/log/Xorg.0.log Contents of most recent Xorg X server log file (/var/log/Xorg.0.log): - [35.994] X.Org X Server 1.20.0 X Protocol Version 11, Revision 0 [35.994] Build Operating System: Linux 4.9.0-6-amd64 x86_64 Debian [35.994] Current Operating System: Linux genre 4.16.0-2-amd64 #1 SMP Debian 4.16.12-1 (2018-05-27) x86_64 [35.994] Kernel command line: BOOT_IMAGE=/vmlinuz-4.16.0-2-amd64 root=/dev/mapper/genre-root ro apparmor=1 security=apparmor verbose [35.995] Build Date: 24 May 2018 04:23:27PM [35.995] xorg-server 2:1.20.0-2 (https://www.debian.org/support) [35.995] Current version of pixman: 0.34.0 [35.995]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [35.995] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [35.995] (==) Log file: "/var/log/Xorg.0.log", Time: Fri Jun 1 19:25:12 2018 [35.997] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [35.998] (==) No Layout section. Using the first Screen section. [35.998] (==) No screen section available. Using defaults. [35.998] (**) |-->Screen "Default Screen Section" (0) [35.998] (**) | |-->Monitor "" [36.000] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [36.000] (==) Automatically adding devices [36.000] (==) Automatically enabling devices [36.000] (==) Automatically adding GPU devices [36.000] (==) Max clients allowed: 256, resource mask: 0x1f [36.003] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. [36.003]Entry deleted from font path. [36.005] (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, built-ins [36.005] (==) ModulePath set to "/usr/lib/xorg/modules" [36.005] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [36.005] (II) Loader magic: 0x558b164edde0 [36.005] (II) Module ABI versions: [36.005]X.Org ANSI C Emulation: 0.4 [36.005]X.Org Video Driver: 24.0 [36.005]X.Org XInput driver : 24.1 [36.005]X.Org Server Extension : 10.0 [36.006] (++) using VT number 7 [36.006] (II) systemd-logind: logind integration requires -keeptty and -keeptty was not provided, disabling logind integration [36.008] (II) xfree86: Adding drm device (/dev/dri/card0) [36.026] (--) PCI:*(0@0:2:0) 8086:1916:17aa:2238 rev 7, Mem @ 0xf000/16777216, 0xe000/268435456, I/O @ 0xe000/64, BIOS @ 0x/131072 [36.026] (II) LoadModule: "glx" [36.038] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so [36.050] (II) Module glx: vendor="X.Org Foundation" [36.050]compiled for 1.20.0, module version = 1.0.0 [36.050]ABI class: X.Org Server Extension, version 10.0 [36.050] (==) Matched modesetting as autoconfigured driver 0 [36.050] (==) Matched fbdev as autoconfigured driver 1 [36.050] (==) Matched vesa as autoconfigured driver 2 [36.050] (==) Assigned the driver to the xf86ConfigLayout [36.050] (II)
Bug#898969: dnssec-trigger: fails with OpenSSL in experimental due to too-small key
Package: dnssec-trigger Version: 0.15+repack-1 Severity: important I have two existing installations of dnssec-trigger that have 1536-bit client and server keys. I'm using the OpenSSL from experimental, which rejects keys of less than 2048 bits in size, as they are presently considered too weak. Consequently, dnssec-trigger fails to start: May 18 01:16:15 genre dnssec-triggerd[721856]: May 18 01:16:15 dnssec-triggerd[721856] error: Error for server-cert-file: /etc/dnssec-trigger/dnssec_trigger_server.pem May 18 01:16:15 genre dnssec-triggerd[721856]: May 18 01:16:15 dnssec-triggerd[721856] error: Error in SSL_CTX use_certificate_file crypto error:140AB18F:SSL routines:SSL_CTX_use_certificate:ee key too small May 18 01:16:15 genre dnssec-triggerd[721856]: May 18 01:16:15 dnssec-triggerd[721856] error: cannot setup SSL context May 18 01:16:15 genre dnssec-triggerd[721856]: May 18 01:16:15 dnssec-triggerd[721856] fatal error: could not init server I noticed the current version of dnssec-trigger uses 3072 bit keys. To ensure upgrades continue to work, dnssec-trigger probably needs to regenerate the keys if they are too small. As a potentially relevant note, I noticed the dnssec-triggerd-keygen.service creates the keys in /etc, not /etc/dnssec-trigger. -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.15.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_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 dnssec-trigger depends on: ii gir1.2-nm-1.0 1.10.8-1 ii libc6 2.27-3 ii libgdk-pixbuf2.0-0 2.36.11-2 ii libglib2.0-02.56.1-2 ii libgtk2.0-0 2.24.32-1 ii libldns21.7.0-3+b1 ii libssl1.1 1.1.1~~pre6-2 ii python3 3.6.5-3 ii python3-gi 3.28.2-1 ii python3-lockfile1:0.12.2-2 ii unbound 1.6.7-1 dnssec-trigger recommends no packages. dnssec-trigger suggests no packages. -- Configuration Files: /etc/dnssec-trigger/dnssec-trigger.conf changed: url: "http://fedoraproject.org/static/hotspot.txt OK" url: "http://ster.nlnetlabs.nl/hotspot.txt OK" tcp80: 185.49.140.67 tcp80: 2a04:b900::10:0:0:67 ssl443: 185.49.140.67 7E:CF:B4:BE:B9:9A:56:0D:F7:3B:40:51:A4:78:E6:A6:FD:66:0F:10:58:DC:A8:2E:C0:43:D4:77:5A:71:8A:CF ssl443: 2a04:b900::10:0:0:67 7E:CF:B4:BE:B9:9A:56:0D:F7:3B:40:51:A4:78:E6:A6:FD:66:0F:10:58:DC:A8:2E:C0:43:D4:77:5A:71:8A:CF -- no debconf information -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#895754: ncurses-term: please add tmux-direct terminal type
On Sun, May 13, 2018 at 10:33:40AM -0400, Thomas Dickey wrote: > I didn't see anything that I could use in ncurses: > > Unlike "screen", which provides a way to relate the inner/outer terminal > descriptions (such as having "screen.xterm-new", to relate to > "xterm-new"), "tmux" doesn't appear to have a comparable approach which > would put the information in the terminal database, and let "tmux" > automatically select the proper customized terminal description. > > To date, all of the discussion in this area seems to have been from the > people who insist on setting TERM to xterm, xterm-256color, etc., so > none of this has been productive. > > One way to address this would be to get the tmux developers to make a > proposal of how they'll fit this feature into the existing system. But > I've only seen recommendations that individuals tweak their ".tmuxrc". > > By the way, the feature being discussed is "direct color", not "true color". From my understanding, tmux does the mapping itself based on what it's attached to. For example, if I start a tmux 2.7 in mate-terminal (which supports 24-bit color) with the color #ff6274, when I attach that tmux session to a linux console, I get light red. In other words, AFAICT, you can always use direct color in newer versions of tmux and tmux will map the colors to whatever the underlying terminal is capable of. -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#895754: ncurses-term: please add tmux-direct terminal type
Package: ncurses-term Version: 6.1+20180210-1 Severity: wishlist tmux has, since version 2.2, supported true color capabilities, but there is no terminal definition (either tmux* or screen*) that handles true color. This means that people who want to use true color-capable programs, like Vim, in tmux must specifically and manually set properties to enable this functionality. Could you add a tmux-direct type to handle the increase in colors and implement true color support? -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.16.0-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- no debconf information -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#895474: Fontconfig errors
On Thu, Apr 12, 2018 at 07:08:23PM +0200, Emilio Pozuelo Monfort wrote: > On 12/04/18 04:01, brian m. carlson wrote: > > I've also seen these errors, except that they're showing up in my tmux > > panes, which is significantly more annoying than .xsession-errors. This > > is probably because vim-gtk3 (gvim) links to libfontconfig1. > > > > libfontconfig definitely shouldn't be producing errors to stdout or > > stderr unless specifically requested by the calling application. > > Have you restarted your applications? AFAICS this is caused by old > libfontconfig > reading the new conf files. If you restart them the warnings should go away. > > (I know this isn't an ideal solution) No, I haven't. I upgraded from within my tmux session and suddenly all my panes had junk in them. I don't normally log out or reboot except for kernel updates. I would appreciate it if you'd work with upstream to get them to remove the code that prints these messages. There's no legitimate reason for a shared library to print anything unless explicitly requested by the calling application . This would be less of an issue if fontconfig didn't reload config files in existing processes. -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#895474: Fontconfig errors
I've also seen these errors, except that they're showing up in my tmux panes, which is significantly more annoying than .xsession-errors. This is probably because vim-gtk3 (gvim) links to libfontconfig1. libfontconfig definitely shouldn't be producing errors to stdout or stderr unless specifically requested by the calling application. -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#894993: patchutils: should restrict input to ed
Package: patchutils Version: 0.3.4-2 Severity: normal Tags: security As mentioned at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894667 and https://rachelbythebay.com/w/2018/04/05/bangpatch/, it's possible for someone to create an ed diff that contains arbitrary commands, which patch will then dutifully execute. This behavior, which FreeBSD and OpenBSD have issued security advisories for, is surprising and not likely to be appreciated by users. POSIX 1003.1-2008[0] restricts the valid commands in an ed diff to a, c, d, i, and s. patch should ensure any input it sends to ed contains only those commands and abort if it does not. [0] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/diff.html -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.16.0-rc6-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_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 patchutils depends on: ii debianutils 4.8.4 ii libc62.27-3 ii patch2.7.6-1 ii perl 5.26.1-5 patchutils recommends no packages. patchutils suggests no packages. -- no debconf information -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#798616: atril: produces useless output to console
On Fri, Sep 11, 2015 at 02:18:35AM +, brian m. carlson wrote: > None of this should be output. If there's an actual problem (e.g. the > file cannot be read), it should produce that to stderr. Otherwise, it > should remain silent, as it currently overwrites my prompt and wastes > space in my terminal. This is a regression, as it used to not do this. > > Please report this upstream and patch out the appropriate code so it no > longer does this. This issue is still happening, although things have much improved: there's much less output than before. I get the following on loading a PDF: (atril:401641): Gtk-WARNING **: Allocating size to EvSidebar 0x55d7d7043ef0 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate? and the following when attempting to print: ** (atril:352267): WARNING **: failed to get find a colord device: The name org.freedesktop.ColorManager was not provided by any .service files I don't have colord installed (nor do I especially need it) and it shouldn't be necessary since this PDF is plain black text. -- brian m. carlson / brian with sandals: Houston, Texas, US https://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#890732: fonts-ebgaramond: please include bold version
Package: fonts-ebgaramond Version: 0.016-1 Severity: wishlist EB Garamond includes a bold version which is not typically built as part of the releases. Similar versions are included as part of the Google Fonts distribution, which is widely used by websites. It would be nice if the bold version were available, even if it is in a preliminary state. -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- no debconf information -- brian m. carlson / brian with sandals: Houston, Texas, US https://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#780005: mate-terminal: reset option does not reset colors to defaults
On Wed, Feb 14, 2018 at 10:41:36AM +, Mike Gabriel wrote: > there has been some work done regarding color palette initialization. > > Please check the above with upcoming mate-terminal 1.20.0-1 and report back > if the issue persists for you. This has indeed been fixed. Many thanks. -- brian m. carlson / brian with sandals: Houston, Texas, US https://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#887326: dnsutils: should include delv
Package: dnsutils Version: 1:9.11.2+dfsg-5 Severity: wishlist The dig(1) manpage indicates that the DNSSEC functionality of dig is deprecated and recommends delv instead. However, delv is not included in the dnsutils package, instead living in the bind9 package. Since most users of dnsutils will not have bind9 installed, this makes it hard to transition use away from dig to delv as recommended. Could you please ship delv in the dnsutils package instead? -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-5-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_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 dnsutils depends on: ii bind9-host [host] 1:9.11.2+dfsg-5 ii libbind9-160 1:9.11.2+dfsg-5 ii libc6 2.26-4 ii libcap21:2.25-1.2 ii libcomerr2 1.43.8-2 ii libdns169 1:9.11.2+dfsg-5 ii libgeoip1 1.6.11-3 ii libgssapi-krb5-2 1.15.2-2 ii libisc166 1:9.11.2+dfsg-5 ii libisccfg160 1:9.11.2+dfsg-5 ii libjson-c3 0.12.1-1.2 ii libk5crypto3 1.15.2-2 ii libkrb5-3 1.15.2-2 ii liblwres1601:9.11.2+dfsg-5 ii libssl1.1 1.1.0g-2 ii libxml22.9.4+dfsg1-6.1 dnsutils recommends no packages. Versions of packages dnsutils suggests: pn rblcheck -- no debconf information -- brian m. carlson / brian with sandals: Houston, Texas, US https://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#696031: simutrans: please allow fullscreen at 1366x768
On Mon, Nov 16, 2015 at 12:33:25PM +0100, Jörg Frings-Fürst wrote: > Hello Brian, > > thank you for spending your time helping to make Debian better with > this bug report. > > > Please can you test it again with the current version from unstable > (120.1.1+repack-1)? Unfortunately, no. I don't have a laptop with a suitably small screen anymore. -- brian m. carlson / brian with sandals: Houston, Texas, US https://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#884650: strongswan-nm: requesting inner IP is IPv4-only
Package: strongswan-nm Version: 5.6.1-2 Severity: important Tags: ipv6 When using the NetworkManager plugin, when the "Request inner IP" option is set, this requests only an IPv4 address. I believe if an IPv6 address were requested, the CPRQ line would include an "ADDR6" entry: Dec 18 02:44:40 genre charon-nm: 07[IKE] establishing CHILD_SA vpn-remote{9} Dec 18 02:44:40 genre charon-nm: 07[ENC] generating IKE_AUTH request 1 [ IDi N(INIT_CONTACT) CERTREQ CPRQ(ADDR DNS NBNS) SA TSi TSr N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_6_ADDR) N(MULT_AUTH) N(EAP_ONLY) N(MSG_ID_SYN_SUP) ] Since the remote side is also strongSwan, no IPv6 address is issued if the client doesn't request one. If the VPN plugin has IPv6 enabled, then strongSwan should request both an IPv4 and an IPv6 address. Not doing so causes IPv6 traffic to leak if the client has other IPv6 connectivity. -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.14.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages strongswan-nm depends on: ii libc6 2.25-4 ii libdbus-glib-1-2 0.108-3 ii libglib2.0-0 2.54.2-1 ii libnm-glib-vpn1 1.10.2-1 ii libnm-util2 1.10.2-1 ii libstrongswan 5.6.1-2 ii strongswan-libcharon 5.6.1-2 Versions of packages strongswan-nm recommends: ii network-manager-strongswan 1.4.2-1 strongswan-nm suggests no packages. -- no debconf information -- brian m. carlson / brian with sandals: Houston, Texas, US https://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#879984: libgcrypt20: copyright does not mention OCB patent license
Package: libgcrypt20 Version: 1.7.9-1 Severity: serious libgcrypt implements OCB, which is patented[0]. The author, Phil Rogaway, provides three licenses. * The first license applies to wholly open-source implementations that do not contain any closed-source components. * The second license applies to non-military software implementations. * The third license applies only to OpenSSL. Only the first license applies here, since libgcrypt is not derived from OpenSSL and the second license violates the DFSG. Because libgcrypt is LGPL and may legally be linked to proprietary code, it must contain a copy of the first patent license, as the patent license imposes further restrictions on the way it can legally be used and distributed. As a consequence, these terms must be listed in the copyright file. Because Debian must avail itself of the first patent license, it is therefore obligatory that libgcrypt20 not link against any proprietary code directly or indirectly, and this should be prominently disclosed as it restricts the text of the LGPL. If it is not possible for practical purposes that libgcrypt not link to proprietary software (say, because libgcrypt20 is linked into Xorg and people might want to use a proprietary graphics driver), then OCB support will need to be removed. [0] http://web.cs.ucdavis.edu/~rogaway/ocb/license.htm -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libgcrypt20 depends on: ii libc6 2.24-17 ii libgpg-error0 1.27-3 libgcrypt20 recommends no packages. Versions of packages libgcrypt20 suggests: pn rng-tools -- no debconf information -- brian m. carlson / brian with sandals: Houston, Texas, US https://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#879542: bind9: contains hard link to /.gz
Source: bind9 Version: 1:9.10.6+dfsg-3 Severity: important I have a system with separate /usr running sid. Upon upgrading from 1:9.10.3.dfsg.P4-12.6 to 1:9.10.6+dfsg-3, I get the following message: (Reading database ... 102957 files and directories currently installed.) Preparing to unpack .../bind9_1%3a9.10.6+dfsg-3_amd64.deb ... Unpacking bind9 (1:9.10.6+dfsg-3) over (1:9.10.3.dfsg.P4-12.6) ... dpkg: error processing archive /var/cache/apt/archives/bind9_1%3a9.10.6+dfsg-3_amd64.deb (--unpack): error creating hard link './usr/share/man/man1/isc-config.sh.1.gz': Invalid cross-device link Errors were encountered while processing: /var/cache/apt/archives/bind9_1%3a9.10.6+dfsg-3_amd64.deb It appears this is because that file is attempting to create a hardlink to /.gz. Obviously one does not want such a hardlink anyway, but this issue causes failures on systems with a separate /usr preventing the package from being installed. Could you fix this by removing that hard link, please? The default information is from a different system and is not applicable, so it has been elided. -- brian m. carlson / brian with sandals: Houston, Texas, US https://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#872516: pristine-tar: add flag to create missing directories
Package: pristine-tar Version: 1.40 Severity: wishlist Tags: patch pristine-tar gentar doesn't have a way to create missing directories like commit and checkout do. This causes problems if one wants to store the pristine-tar directory in a subdirectory of a Git repository instead of in a separate branch at the top level. Attached is a patch to implement a --create-missing option, which simply enables the internal create_missing flag that checkout and commit use, but for gentar. I've verified that it works as expected by using gendelta and gentar in a subdirectory of a Git repository using the git-2.14.1.tar.gz tarball. -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.11.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages pristine-tar depends on: ii libbz2-1.0 1.0.6-8.1 ii libc6 2.24-14 ii perl5.26.0-5 ii tar 1.29b-2 ii xdelta 1.1.3-9.1+b1 ii xdelta3 3.0.11-dfsg-1+b1 ii zlib1g 1:1.2.8.dfsg-5 Versions of packages pristine-tar recommends: ii bzip2 1.0.6-8.1 ii pbzip21.1.9-1+b1 ii xz-utils 5.2.2-1.3 pristine-tar suggests no packages. -- no debconf information -- brian m. carlson / brian with sandals: Houston, Texas, US https://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: https://keybase.io/bk2204 From b42ac744f532baa4c2f8614dc4e4f38a5b27eceb Mon Sep 17 00:00:00 2001 From: "brian m. carlson" <sand...@crustytoothpaste.net> Date: Fri, 18 Aug 2017 00:56:50 + Subject: [PATCH] Add a --create-missing option to gentar pristine-tar handles the automatic recreation of empty directories with the checkout command, since some version control systems, like Git, don't store empty directories. This is done by the internal use of a flag, create_missing. However, some workflows do not use checkout and commit for various reasons, and hence cannot make use of this functionality. Expose the functionality using a flag, --create-missing, that recreates these directories automatically. --- pristine-tar | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/pristine-tar b/pristine-tar index d4f4b0e..9a1c7b1 100755 --- a/pristine-tar +++ b/pristine-tar @@ -8,7 +8,7 @@ pristine-tar - regenerate pristine tarballs B [-vdk] gendelta I I -B [-vdk] gentar I I +B [-vdk] [--create-missing] gentar I I B [-vdk] [-m message] commit I [I] @@ -120,6 +120,10 @@ Don't clean up the temporary directory on exit. Use this option to specify a custom commit message to pristine-tar commit. +=item --create-missing + +When regenerating a tarball, create any missing empty directories. + =back =head1 EXAMPLES @@ -227,6 +231,7 @@ use constant { }; my $message; +my $create_missing; my $genversion = version_from_env(XDELTA3, "xdelta" => XDELTA, "xdelta3" => XDELTA3); @@ -244,6 +249,7 @@ dispatch( }, options => { "m|message=s" => \$message, +"create-missing" => \$create_missing, }, ); @@ -343,7 +349,7 @@ sub recreatetarball { ); $full_sweep = 1; - if ($options{create_missing}) { + if ($create_missing || $options{create_missing}) { # Avoid tar failing on the nonexistent item by # creating a dummy directory. debug("creating missing $unquoted_file"); -- 2.14.1.480.gb18f417b89 signature.asc Description: PGP signature