Bug#1076703: amd64-microcode: Please clarify how to check if I'm running the latest microcode
their system when there isn't one (since AMD only updates selectively within families) The decoder table they maintain there is helpful, as are some of the tables on wikipedia. Rather than put anything like that in the debian package, maybe just link to those as long as they are being maintained. 2) that prompted me to look at the arch wiki and found this general microcode page https://wiki.archlinux.org/title/Microcode which suggests looking for "CPU0" in the boot messages to get the smpboot line (with family/model/stepping) and microcode (with patch_level). That might be the easiest way for the user to do it, no converting dec->hex, and doesn't depend on extra packages like cpuid 3) bonus points if this stuff could be made more consistent between amd64-microcode and intel-microcode, lots of people have to deal with both and it sucks to have to figure out two systems. Intel's format is even worse than AMDs.... Sorry for the giant brain dump, this has been collecting in my brain for a while. Let me know what you think and if you want any help crafting or reviewing documentation to add. Thanks, -- Matt Taggart m...@lackof.org
Bug#1074600: openarc: abandoned upstream
Package: openarc Version: 1.0.0~beta3+dfsg-1~exp4 * The upstream openarc project has not had a commit to master branch since Sept 21, 2018. (there is a develop branch last Oct 16, 2020) * There are many unresolved issues in it's issue tracker * It seems this implementation was mainly just experimental * Debian updates are just packaging or policy related * popcon shows only 20 installs It's only in experimental currently, so maybe that's ok that it stay there if someone cares enough, but otherwise I think it could be removed from Debian. Possible alternatives: * fastmail's implementation https://github.com/fastmail/authentication_milter RFP #1036235 * opendkim gained some ARC support in 1.4.0 (2021-01-28) * rspamd has an ARC module, config is here https://github.com/rspamd/rspamd/blob/master/conf/modules.d/arc.conf Thanks, -- Matt Taggart m...@lackof.org
Bug#1071970: usertag for pcre3
Hi, It looks like Matthew Vernon helpfully created a usertag to track the remaining pcre3 package bugs: https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=obsolete-pcre3;users=matthew-pcre...@debian.org Currently: - 11 Serious, patch available - 8 Serious, unclassified - 1 Normal, unclassified - 9 Serious, forwarded and a whole lot of Resolved, yay! -- Matt Taggart m...@lackof.org
Bug#1073087: pcre2: update homepage
Package: pcre2 Version: 10.43-1 Severity: wishlist The https://pcre.org/ page is 1) pretty out of date, it lists 10.39 as the latest release, uses old URLs, etc 2) it's not clear if it's maintained by the project or someone else. At the bottom it says: "Please note that neither this website nor the SourceForge download repositories are maintained by Philip." 3) The Sourceforge page it points to is also out of date 4) Several of the links on the page point to https://github.com/PhilipHazel/pcre2 which now redirects to https://github.com/PCRE2Project/pcre2 I think the package homepage in debian/control and other places should be updated to the https://github.com/PCRE2Project/pcre2 URL. I started looking into this due to this issue: Long-term maintenance of PCRE2 https://github.com/PCRE2Project/pcre2/issues/426 I suspect whoever takes it over will also take over that github project and the URL should remain stable. Thanks, -- Matt Taggart m...@lackof.org
Bug#1072182: delta: upstream location and 2020-06-22 release
Package: delta Version: 2006.08.03-13 Maybe the upstream for delta is now https://github.com/dsw/delta There was a release on 2020-06-22 which is newer than what the package is using, although looking at the commits it's mostly just documentation changes. popcon doesn't show many people using this, but if you care about it please adopt it! -- Matt Taggart m...@lackof.org
Bug#1070270: riseup-vpn: client no longer works due to cert verification problem
On 5/10/24 07:26, Nilesh Patra wrote: Going for an upload to unstable followed by an s-p-u. [2]: https://people.debian.org/~nilesh/riseup-vpn-stable/ I was finally able to install 0.21.11+ds1-5+deb12u1 from the above on my bookworm test system and it fixed things and the vpn is working again! An upload to s-p-u would be great. Thanks, -- Matt Taggart m...@lackof.org
Bug#1070270: riseup-vpn: client no longer works due to cert verification problem
Package: riseup-vpn Version: 0.21.11+ds1-5+b1 Severity: grave When attempting to run the bookworm riseup-vpn package, it fails to connect to riseup's servers and gives the following output: 2024/05/01 18:21:23 Error fetching eip v3 json:https://api.black.riseup.net/3/config/eip-service.json My understanding is that this is due to the package failing to be able to verify the current LetsEncrypt cert that host is using. More details at https://0xacab.org/leap/bitmask-vpn/-/issues/768 (supposedly the current upstream snap has this fixed, but I haven't tried it) As this breaks what the package is supposed to do (at least when using riseup as provider, maybe there is a way to point it elsewhere?) I think this is grave. Also I think it might be a good candidate for being fixed in a stable release update. Thanks, -- Matt Taggart m...@lackof.org
Bug#945203: fwupd: Cannot update firmware
I also ran into this "No space left on device" error, but in a different situation. I knew that a particular Dell laptop I was working on had firmware available via fwupd, so I had the bright idea to boot Debian Live and install fwupd to update it. But I realized some firmware images (maybe _all_ system BIOS images?) actually work by writing things into the EFI partition, to be updated upon reboot (like how MS Windows also does it). So my bright idea didn't work, since I didn't yet have a drive installed with an EFI partition. But due to the error being about "No space" I wasted some time trying to resolve that, before realizing the real issue. After I had a proper Debian install with EFI it worked fine. So I think part of the issue here is that fwupd should better detect when it's completely missing things it needs to be successful and give an improved error and maybe point to documentation about how it works. In my case it was "no EFI partition", but others in this bug report have alluded to things like efivars, the BIOS locking things down, etc. So some additional sanity checks of these things would be nice. Thanks, -- Matt Taggart m...@lackof.org
Bug#966288: [Pkg-puppet-devel] Bug#966288: mcollective - RM for bullseye?
The last mcollective release was v.3.1.2 tagged on Oct 14, 2018, and zero commits after that, so is effectively dead upstream. Here are the popcon stats https://qa.debian.org/popcon.php?package=mcollective I think it could probably be removed from debian now. This bug mentioned "bolt" as a possible replacement, that seems to be this: https://www.puppet.com/docs/bolt/latest/bolt.html https://github.com/puppetlabs/bolt That project has recent commits and releases. I searched in debian and found: bolt - system daemon to manage thunderbolt 3 devices bolt-lmm - Efficient large cohorts genome-wide Bayesian mixed-model association testing bolt-16 - Post-link optimizer golang-github-boltdb-bolt-dev - low-level key/value database for Go So it's a popular name it seems. WNPP doesn't list anything related. -- Matt Taggart m...@lackof.org
Bug#1068201: mcollective: Homepage out of date
Package: mcollective Version: 2.12.5+dfsg-1.1 Severity: minor The listed Homepage of http://projects.puppetlabs.com/projects/mcollective currently redirects to https://tickets-archive.ops.puppetlabs.net/projects/mcollective which doesn't resolve. A search for "mcollective" finds https://forge.puppet.com/modules/puppet/mcollective https://github.com/voxpupuli/puppet-mcollective Also in the README.md in that github project there are links to things like https://www.puppet.com/docs/mcollective/deploy/standard.html that are broken. But the link https://www.puppet.com/docs/mcollective redirects to the above forge link. I guess they moved stuff around but didn't setup all the needed redirects. So I guess the debian package should update Homepage, but also look for any broken links and fix them (in upstream would be ok I think, no need for debian patch IMO). Thanks, -- Matt Taggart m...@lackof.org
Bug#238687: popularity-contest: popularity contest should provide subarch info.
It's been quite a while since this bug was discussed, but I have another use case where it might be interesting... There has been some recent discussion about "Architecture Variants" and in particular amd64 variants. Fedora and Ubuntu are both working on experiments with the goal of being able to optimize for newer versions of the amd64 architecture (and potentially dropping older variants at some point as well). Here is a page that gathers info on this idea for Debian https://wiki.debian.org/ArchitectureVariants Knowing information about which variants our installed base is using would help make these decisions easier. The past i386 decisions were a little easier because there were particular packages we could look at to get those numbers. Side note In addition to this bug, it seems there are some other cases where people would like to press popcon into service to gather other things: kernel modules https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=202675 report arch only https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=545000 report foreign architectures https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931764 Package versions https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=97045 aptitude auto flag https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=313194 package config file data https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=816281 We can understand why it is tempting to want to do so. But there are also privacy and scope implications. So maybe the first step is a clear policy of what is appropriate for popcon to do, and the things that aren't should be WONTFIX. Thanks, -- Matt Taggart m...@lackof.org
Bug#912725: virtinst: Please demote virtinst recommends on virt-viewer to suggests
Hi, This bug was opened 5 years ago, but it is still the case as of version 1:4.1.0-3 that virtinst Recommends virt-viewer and pulls in tons of packages that are unneeded in many cases. On my currently freshly installed bookworm system (with libvirt already installed): 0 upgraded, 350 newly installed, 0 to remove and 0 not upgraded. Need to get 243 MB of archives. After this operation, 854 MB of additional disk space will be used. vs 0 upgraded, 45 newly installed, 0 to remove and 0 not upgraded. Need to get 12.4 MB of archives. After this operation, 52.6 MB of additional disk space will be used. It's definitely a common use case to use virtinst without virt-viewer and it would be nice if this was fixed. Interestingly, the virt-manager package only Suggests virt-viewer but, if anything, I would think the dependency would be stronger there? So maybe Recommends or even Depends? But I guess it's possible to use virt-manager to manage VMs without ever needing to launch virt-viewer, so maybe Suggests is correct there as well. For those running into this, the work around is to use '--no-install-recommends' as Karl mentioned in the original report. Thanks, -- Matt Taggart m...@lackof.org
Bug#1059499: libguestfs-tools: mention tools in description
Package: libguestfs-tools Severity: wishlist Version: 1:1.50.1-4+b3 This is only a wishlist suggestion and you are free to ignore/modify/etc... It might be nice if the libguestfs-tools package description included a list of the more popular tools in this package so running things like 'apt-cache search virt-builder' find it. But I guess I would not list them _all_, so maybe the ones that are often mentioned in documentation and maybe a generic catch-all like "contains many virt-* utilities for interacting with and manipulating VM disk images". Thanks, -- Matt Taggart m...@lackof.org
Bug#1053180: openssl: Make RSA decryption API safe to use with PKCS#1 v1.5 padding (Marvin/Bleichenbacher)
Package: openssl Version: 3.0.11-1 Recently "The Marvin Attack" aka Bleichenbacher timing attack has been in the news again: https://people.redhat.com/~hkario/marvin/ CVE-2022-4304 was already fixed in all but buster: https://security-tracker.debian.org/tracker/CVE-2022-4304 But the page references an API level pull request upstream: https://github.com/openssl/openssl/pull/13817 and there is also this corresponding issue: https://github.com/openssl/openssl/issues/13421 The history on that issue is long and complicated and it's not clear to me if this has been fixed and if so on what releases? Maybe someone with more knowledge of this can make more sense of it? If it hasn't been fixed this bug can track it. If it has been fixed it would be nice to have something in changelog or NEWS mentioning it. But separate from that, it would be good to move away from this old potentially hazardous method. Is there some way of determining what software in Debian might be using this (via openssl API) so those things could get fixed as well? Not much can be done about non-Debian software running on Debian, but we want old software to continue to function (at least for a while, eventually some sort of logged warning might be nice). Thanks, -- Matt Taggart m...@lackof.org
Bug#973411: spectre-meltdown-checker: Inconsistent output compared to Debian's security tracker
Hi Patrick, spectre-meltdown-checker has had some updates in this detection code since you filed this bug. If you still have access to the hardware you generated that report on, could you run a newer version and see if it fixes your issue? (also it might be interesting to test with the old microcode if that is still installed, and then newer) Please report back what you find and also lscpu output so we know what CPU this is in particular. Thanks, -- Matt Taggart m...@lackof.org
Bug#1043321: spectre-meltdown-checker: support for downfall, inception
Package: spectre-meltdown-checker Version: 0.45-2 Severity: wishlist There is an upstream issue requesting support for the new Downfall architecture vulnerability: https://downfall.page/ https://github.com/speed47/spectre-meltdown-checker/issues/465 and also AMD Inception https://comsec.ethz.ch/research/microarch/inception/ https://github.com/speed47/spectre-meltdown-checker/issues/466 -- Matt Taggart m...@lackof.org
Bug#1042111: chromium: Web Environment Integrity
Package: chromium Version: 115.0.5790.102-2 Engineers working for Google have proposed a standard named Web Environment Integrity details available at https://github.com/RupertBenWiser/Web-Environment-Integrity/blob/main/explainer.md There have been hundreds of articles, social media posts, etc discussing this, here is a page that gives a good summary of the events so far: https://interpeer.io/blog/2023/07/google-vs-the-open-web/ Initially it was a standards proposal, but now it looks that it's already implemented https://github.com/chromium/chromium/commit/6f47a22906b2899412e79a2727355efa9cc8f5bd Debian needs to figure out if this is something we want in chromium (at all, disabled at build time, disabled at runtime, etc). Thanks, -- Matt Taggart m...@lackof.org
Bug#952411: chromium: coming ScrollToTextFragment in Chrome 80
I just rediscovered #952411 which I filed on 23 Feb 2020. Here's an update. This "ScrollToTextFragment" feature seems to have been added. Currently on 115.0.5790.98-1~deb11u1 if I go to the following example https://en.wikipedia.org/w/index.php?title=Cat&oldid=916388819#:~:text=Claws-,Like%20almost,the%20Felidae%2C,-cats it does scroll to the targeted text and highlight it. That example is taken from the draft of the spec at https://github.com/WICG/scroll-to-text-fragment Here is a simplified example: https://www.debian.org/#:~:text=Additional-,information,Debian,-Community It's also easy to generate similar by selecting some text on a page, right-click and "Copy link to highlight". Notes: * these URLs seem to do nothing on current firefox-esr * it looks like Brave disabled it by default * maybe going into HTML? https://github.com/whatwg/html/issues/8282 Here is the upstream spec issue discussing the privacy implications of this https://github.com/WICG/scroll-to-text-fragment/issues/76 and discussion about creating ways to disable https://github.com/WICG/scroll-to-text-fragment/issues/122 Since there is currently no easy way to disable, this lead to someone making an extension to disable. "disable-google-search-text-highlights" I have not attempted to determine if the privacy concerns have been addressed or the level of potential threat, someone more familiar with this area should do that. Thanks, -- Matt Taggart m...@lackof.org
Bug#1034814: debian-installer: bootable flag not toggling
On 4/25/23 01:59, Pascal Hambourg wrote: On 25/04/2023 at 03:24, Matt Taggart wrote: When in the partitioning and editing a partition, if I am on the "bootable" option and select, it does not toggle but remains "no". The screen flashes, bot no change. I have not yet checked what ends up in the partition table after the install. Is it a GPT partition table ? Yes, GPT and EFI, 512gb nvme drive. GPT is the default partition table type with EFI boot or disk size above 2 TiB. In GPT, "boot" and "esp" parted flags are equivalent and both represent the "EFI system partition" type (IMO this is a big mess). Being used to doing non-GPT/EFI installs for so long, I did what I have always done and toggled the bootable flag on the /boot partition. When it didn't change, I tried again and it still didn't change. So it was less a bug of it not functioning that it was confusing for the user. If this should be fixed, not sure how. - Set/unset the "esp" flag at the same time as the "boot" flag if GPT ? - Hide the "bootable" option if GPT > - Map the "bootable" option to the "legacy_boot" parted flag instead of "boot" if GPT ? (AFAIK only syslinux/extlinux uses this flag) IMO "hide the bootable option if GPT" (but maybe that is non-trivial). Alternatively the value could be displayed as "GPT" and not change when toggled. Thanks, -- Matt Taggart m...@lackof.org
Bug#999811: HAVEGED is obsolete starting from linux kernel 5.6
On 4/26/23 06:16, Cyril Brulebois wrote: Control: severity -1 important Matt Taggart (2023-04-25): As reported in #999811 the haveged package is obsolete starting in linux 5.6 and newer, as the kernel adopted a similar algorithm and also stopped blocking /dev/random reads. I am upgrading severity to serious because I believe this is release critical for bookworm. No, thanks. OK. There may still be reasons to keep haveged in Debian, I do not know. (do all archs have these >5.6 features? is it still needed in addition?) https://bugs.debian.org/1034361#12 1+ month into the hard freeze isn't when you suddenly want to remove a dependency of the installer. Sorry, I hadn't seen that bug :( Post-bookworm I guess... Thanks, -- Matt Taggart m...@lackof.org
Bug#999811: HAVEGED is obsolete starting from linux kernel 5.6
severity 999811 serious thanks As reported in #999811 the haveged package is obsolete starting in linux 5.6 and newer, as the kernel adopted a similar algorithm and also stopped blocking /dev/random reads. I am upgrading severity to serious because I believe this is release critical for bookworm. There may still be reasons to keep haveged in Debian, I do not know. (do all archs have these >5.6 features? is it still needed in addition?) If so: * sid has 1.9.14, upstream is 1.9.18, several existing debian bugs are fixed * debian should adopt/implement something like the contrib/Fedora/haveged.service unit file mentioned that checks the kernel version before deciding to run. * the vast majority of debian systems with haveged installed probably no longer need it on bullseye or newer. If the package will remain, the README.Debian should be updated and/or NEWS.Debian to let people know. If it's going to be removed from Debian, I'm not sure if it's better to have one last version that informs the user, to silently go away, or maybe something in the release notes? Thanks, -- Matt Taggart m...@lackof.org
Bug#792456: encrypted swap broken in last several debian releases
The last few debian releases (buster and bullseye at least) configuring encrypted swap has been broken for me. I don't know if it's the same as what the user in #792456 is seeing, but likely. I have most recently tested it in Bookworm RC1 and here is what I did: * run by hand partitioning * create 3 partitions: boot, swap, lvm * configure encryption: enable encryption for swap and lvm partitions * configure swap to use serpent and random passphrase * configure lvm partition to use serpent and key * finish * mark lvm encrypted partition to be used for lvm, configure lvm, setup root and var partition * configure boot partition to be ext4 mounted at /boot * finish partitioning * receive error about failure to setup swap Sorry for the short report, I will try to redo it and capture logs, but I wanted to report this ASAP. My workaround has been to allocate the partition but mark it do not use and then finish the setup by hand after install. Thanks, -- Matt Taggart m...@lackof.org
Bug#1034814: debian-installer: bootable flag not toggling
Package: debian-installer Version: bookworm-DI-rc1 When in the partitioning and editing a partition, if I am on the "bootable" option and select, it does not toggle but remains "no". The screen flashes, bot no change. I have not yet checked what ends up in the partition table after the install. Sorry for the crappy report, I will try to provide more details when I get a chance to repeat it. -- Matt Taggart m...@lackof.org
Bug#1034418: util-linux: fstrim.timer not enabled for upgraded systems
On 4/15/23 15:35, Chris Hofstaedtler wrote: This behavior might follow the principle of least surprise, but I think for SSD based systems it is losing out on the benefits of TRIM/discard (improved i/o latency, flash wear). Yes. Also it is - to the best of my knowledge - the only way of not destroying possible admin configuration on upgrades. I can think of a few situations: A) installed system pre-bullseye, so not enabled by default. System does not have a /etc/systemd/system/timers.target.wants/fstrim.timer symlink. 1) admin unaware of it, would benefit from it, might want it 2) admin aware of it, chose not to not have it enabled B) installed system bullseye or later, enabled by default. If the system is lacking the symlink, that means it was explicitly disabled by admin. My guess is A1 vastly outnumbers A2 and B, but that those may be non-zero. Does the differentiation between "disabled" and "masked" make any difference here? Would an admin that doesn't want it have explicitly masked it? I thought of another case where it would be good to have it enabled by default: for virtual machines that use a copy on write filesystem and set discard=unmap to tell the virtualization that those blocks can be dropped on discard, potentially saving a lot of disk space. fstrim.timer not being enabled in the Debian VM hurts the virtualization host(even those not running Debian). I guess it's already documented in README.Debian. Maybe it would be interesting to have something in the Bookworm release notes? -- Matt Taggart m...@lackof.org
Bug#1034418: util-linux: fstrim.timer not enabled for upgraded systems
Package: util-linux Version: 2.36.1-8+deb11u1 I recently noticed on my existing bullseye systems that fstrim.timer is not enabled by default: === # systemctl status fstrim.timer ● fstrim.timer - Discard unused blocks once a week Loaded: loaded (/lib/systemd/system/fstrim.timer; disabled; vendor preset: enabled) Active: inactive (dead) Trigger: n/a Triggers: ● fstrim.service Docs: man:fstrim # systemctl list-timers fstrim.timer NEXT LEFT LAST PASSED UNIT ACTIVATES 0 timers listed. Pass --all to see loaded but inactive timers, too. === Here's what it looks like when I enable it: === # systemctl enable --now fstrim.timer Created symlink /etc/systemd/system/timers.target.wants/fstrim.timer → /lib/systemd/system/fstrim.timer # systemctl status fstrim.timer ● fstrim.timer - Discard unused blocks once a week Loaded: loaded (/lib/systemd/system/fstrim.timer; enabled; vendor preset: enabled) Active: active (waiting) since Fri 2023-04-14 16:39:49 UTC; 19s ago Trigger: Mon 2023-04-17 00:23:13 UTC; 2 days left Triggers: ● fstrim.service Docs: man:fstrim Apr 14 16:39:49 foo systemd[1]: Started Discard unused blocks once a week. # systemctl list-timers fstrim.timer NEXTLEFTLAST PASSED UNIT ACTIVATES Mon 2023-04-17 00:23:13 UTC 2 days left n/a n/afstrim.timer fstrim.service 1 timers listed. Pass --all to see loaded but inactive timers, too. === It looks this way on all my bullseye systems that were older and dist-upgraded to bullseye. I only have one system that was installed directly with bullseye and it appeared to be running there (but maybe I enabled it by hand at some point and forgot?). I have not checked on testing/unstable (fresh install or dist-upgrade). Looking in the Debian changelog I see in the 2.35.1-2 entry: "* Enable fstrim.timer by default" and that seems to correspond to this commit: https://salsa.debian.org/debian/util-linux/-/commit/b0f405a45b6ea0608ecb51e8b8d68ec1715a83e7 which adds: dh_installsystemd --package=util-linux fstrim.timer Here is the generated section from postinst: === # End automatically added section # Automatically added by dh_installsystemd/13.3.4 if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" = "abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then # This will only remove masks created by d-s-h on package removal. deb-systemd-helper unmask 'fstrim.timer' >/dev/null || true # was-enabled defaults to true, so new installations run enable. if deb-systemd-helper --quiet was-enabled 'fstrim.timer'; then # Enables the unit on first installation, creates new # symlinks on upgrades if the unit file has changed. deb-systemd-helper enable 'fstrim.timer' >/dev/null || true else # Update the statefile to add new symlinks (if any), which need to be # cleaned up on purge. Also remove old symlinks. deb-systemd-helper update-state 'fstrim.timer' >/dev/null || true fi fi === So I guess if fstrim.timer was installed at some point but not enabled, upgrades would "update-state" but not enable the service? Was fstrim.timer delivered in buster but not enabled? This behavior might follow the principle of least surprise, but I think for SSD based systems it is losing out on the benefits of TRIM/discard (improved i/o latency, flash wear). Given that it only runs once a week, I think also there is minimal risk (but it might cause a multiple seconds decrease in i/o speed depending on drive). Can you think of a way this could be enabled for upgraded systems as well? Thanks, -- Matt Taggart m...@lackof.org
Bug#1023205: request to backport memtest86
Fabio Fantoni writes... > I didn't think about that. I thought new upstream releases are only > done for special packages which otherwise have no security support > like Firefox or PHP > > But I'll do that now. This bug is #1023205 but I note there has been no response so far. I would like to be able to use the new 6.00-1 version in stable as the existing version there does not work on many systems, modern but also even those 5+ years old. I think there is a good argument for including in a stable update, but either way can we get a decision and have it available in stable proposed updates or backports soon? Thanks, -- Matt Taggart m...@lackof.org
Bug#1024186: linux: consider deprecating unprivileged_userns_clone
Package: linux Version: 6.0.8-1 Severity: wishlist In #898446 the decision was made to enable unprivileged_userns_clone by default and this shipped in bullseye. In the course of discussion bwh suggested: So I think we should do something like this: * Document user.max_user_namespaces in procps's shipped /etc/sysctl.conf * Set kernel.unprivileged_userns_clone to 1 by default, and deprecate it (log a warning if it's changed) * Document the change in bullseye release notes The default did get changed, but the other things haven't been done yet. FYI: I do not know the current state of the upstream patch but I do still see it in debian/patches/debian/add-sysctl-to-disallow-unprivileged-CLONE_NEWUSER-by-default.patch Assuming Debian will not keep it, I propose: * bookworm should warn users still setting it that's it deprecated * bookworm should still properly disable it for users setting it to 0 * bookworm release notes should document it going away and the alternative * bookworm procps should include an example in the default sysctl.conf and ps(1) proc(5) manpages * trixie should remove it and release notes document * it might also be useful to document in the above which common cases require that unpriv userns is enabled, maybe to avoid some footguns How does that sound? As a side note: * desktop machines seem pretty dependent on unpriv userns by now so the default should remain enabled * there are still recent CVEs enabled by unpriv userns, disabling it on systems that don't need it is still worthwhile Thanks, -- Matt Taggart m...@lackof.org
Bug#673004: does not connect to HP iLO 2
tags 673004 wontfix close 673004 thanks This bug is from 2012. I'm not sure what the problem was at the time, but by now any such old HP iLO device identifying as version "mpSSH_0.1.0" is unlikely to support a set of ciphers/Kex/MACs/etc to allow a recent version of openssh in debian to be able to connect to it, even with work-arounds. The world has moved on. If you are on a current version of debian and encounter problems connecting to such a device, first ensure that your devices firmware is the latest version and then open a new bug with detailed debugging info (and know that the answer still might be "sorry, the manufacturer stopped updating it and we can't support connecting to it"). Good luck, -- Matt Taggart m...@lackof.org
Bug#774711: openssh-server: insecure algorithms reported by ssh-audit
Thanks for the ssh-audit report output!
There has been a very long discussion of default settings in #774711
(which now includes ssh-audit's recommendations)
Since you generated this report the following has happened:
* 1:8.8p1-1:
"This release disables RSA signatures using the SHA-1 hash algorithm
by default. (Existing RSA keys may still be used and do not need
to be replaced; see NEWS.Debian if you have problems connecting to
old SSH servers.)"
* 1:8.9p1-1:
"ssh(1): stricter UpdateHostkey signature verification logic on the
client-side. Require RSA/SHA2 signatures for RSA hostkeys except when
RSA/SHA1 was explicitly negotiated during initial KEX.
ssh(1), sshd(8): fix signature algorithm selection logic for
UpdateHostkeys on the server side. The previous code tried to prefer
RSA/SHA2 for hostkey proofs of RSA keys, but missed some cases. This
will use RSA/SHA2 signatures for RSA keys if the client proposed
these algorithms in initial KEX."
* 1:9.0p1-1:
"use the hybrid Streamlined NTRU Prime + x25519 key exchange method
by default ("sntrup761x25519-sha...@openssh.com"). The NTRU algorithm
is believed to resist attacks enabled by future quantum computers and
is paired with the X25519 ECDH key exchange (the previous default) as
a backstop against any weaknesses in NTRU Prime that may be
discovered in the future. The combination ensures that the hybrid
exchange offers at least as good security as the status quo."
* sk-ssh-ed25...@openssh.com is the defaults lists now
The rest of ssh-audit's recommendations from your report are still
valid, see #774711 for more info
--
Matt Taggart
m...@lackof.org
Bug#774711: update of debian openssh crypto defaults
'-','*' syntax, it is possible to specify configuration changes relative to the default, in a way that future-proofs the config for additions/removals in future upstream versions. Right now that might look something like == Ciphers -3des-cbc,aes*-cbc,rijndael-...@lysator.liu.se KexAlgorithms -ecdh-sha2-nistp*,, diffie-hellman-group14-*,diffie-hellman-group1-sha1 MACs -umac-64*,hmac-sha1*,umac-...@openssh.com, hmac-sha2-256,hmac-sha2-512 HostKeyAlgorithms -ecdsa-sha2-nistp*, sk-ecdsa-sha2-nistp*, ssh-rsa-cert-...@openssh.com,ssh-rsa == But one might choose to explicitly list the things to enable to prevent surprises (at the risk of continuing to support something that upstream drops from the default). When I set out to write this, I was hoping everything in the original report had been dealt with by now, there has been a lot of progress upstream. But it seems there are still a few things left, let push to get this done! Thanks, -- Matt Taggart m...@lackof.org
Bug#1020385: sysdig: upstream site
Package: sysdig Version: 0.29.3-1 Severity: minor Homepage: It appears the http server for the domain sysdig.org now redirects to sysdig.com. That host is not listening on https, so browsers attempting to go direct to https won't get the redirect. Also the page https://sysdig.com/opensource/ points to the following: https://github.com/draios/sysdig So maybe: * update the Homepage in debian/control to https://sysdig.com * adjust Source in debian/copyright to https://github.com/draios/sysdig Thanks, -- Matt Taggart m...@lackof.org
Bug#774711: OpenSSH settings hardening
Hi, Some updates on OpenSSH config hardening 1) The ssh-audit tool that Mathew Binkley pointed out has been forked and updated and lives at https://github.com/jtesta/ssh-audit 2) The sshaudit.com site now uses the above version. 3) The sshaudit.com site also now provides a hardening guide https://www.ssh-audit.com/hardening_guides.html that was inspired by the original stribika.github.io page mentioned here. I like Mathew's idea of aiming for a config that scores well, with commented out configs for enabling compatibility for older clients. -- Matt Taggart m...@lackof.org
Bug#526469: manpage missing for sysfs.conf
On 8/3/22 16:28, Guillem Jover wrote: What about something like the attached page? Looks great! I guess "These file" in the second paragraph should be "These files" to be consistent with the first. It's a little confusing since you might be talking about sysfs.conf or files in /etc/sysfs.d/... I checked to see what sysctl does and they have separate manpages for sysctl.conf and sysctl.d, so I guess that's an option too. Thanks, -- Matt Taggart m...@lackof.org
Bug#750425: libsysfs2: memory leaks detected in libsysfs
This bug is from 2014, but I did just notice these commits to upstream https://github.com/linux-ras/sysfsutils/commit/085bba6bab1ccaa89041639a7e070390fdea440a that look like they probably fix this. However it looks like they happened _after_ the 2.1.1 release. It would be good to confirm those commits fix the leaks (and maybe confirm there aren't any others introduced since 2014) and then also for upstream to release a new version with the fixes. Thanks, -- Matt Taggart m...@lackof.org
Bug#1016610: sysfsutils: systemd service
Package: sysfsutils Version: 2.1.1-1 Severity: wishlist It might be nice if sysfsutils provided a systemd service file. I guess it would be a simple oneshot service. I was thinking maybe the existing systemd-sysctl.service file would be a useful starting point, but then I realized that systemd seems to provide that itself (rather than procps): $ dpkg -L systemd |grep sysctl /etc/sysctl.d /lib/systemd/system/systemd-sysctl.service /lib/systemd/systemd-sysctl /usr/lib/sysctl.d /usr/lib/sysctl.d/50-pid-max.conf /usr/share/man/man5/sysctl.d.5.gz /usr/share/man/man8/systemd-sysctl.service.8.gz /etc/sysctl.d/99-sysctl.conf /lib/systemd/system/sysinit.target.wants/systemd-sysctl.service /usr/share/man/man8/systemd-sysctl.8.gz So having systemd do it is another option I guess. But procps is Priority: important and sysfsutils is Priority: optional, so sysfs isn't necessarily installed on all systems with systemd like procps is. So now I am unsure which is the best way to implement. What do you think? Thanks, -- Matt Taggart m...@lackof.org
Bug#473413: sysfsutils and events
The sysfsutils bugs #562939 and #473413 are sort of similar, both
involve what sysfs should do upon particular dynamic (not at boot) events.
I think this is maybe something better handled by udev? It already knows
how to do things by matching keys in sysfs. But I don't know about
modifying sysfs attribs triggered by udev events.
I guess an argument could be made that sysfs is at a lower level than
udev and that maybe a better analogy is modprobe. But modprobe is a
userspace utility that loads the module and can check for module
parameters before doing so. In the sysfs case we're expecting that once
a new /sys/ interface shows up, if there exist things in
/etc/sysfs.{conf,d/*} that match it should apply them? I'm not sure how
that should be implemented.
--
Matt Taggart
m...@lackof.org
Bug#526469: manpage missing for sysfs.conf
Here are some notes about documenting sysfs.conf * sysfs(2) is about the syscall and isn't helpful in this context * sysfs(5) (in manpages package) explains a little about sysfs, but not how to interact with it. * The kernel documentation https://www.kernel.org/doc/Documentation/filesystems/sysfs.txt is targetted at people writing sysfs interfaces and mostly not useful, but mentions that interfaces need to be documented in ABI https://www.kernel.org/doc/Documentation/ABI/stable/ and that might be useful to mention as a place where users can read about how to interact with various parts. * The default delivered sysfs.conf file has some comments at the top about general syntax and examples. * should document /etc/sysfs.d/ and how to use it (load order, etc) * should maybe explain the difference between sysfs and sysctl So I think a sysfs.conf manpage could be pretty simple, mostly the comments already in the default file and some pointers to the other places. -- Matt Taggart m...@lackof.org
Bug#527397: [approx] Please add IPv6 support by default (inetd.conf change)
Here's an update on approx and IPv6: * approx 5.4-1 (08 Dec 2013) first added the systemd socket files, but the postinst was still using update-inetd. This release also added an example xinetd conffile * approx 5.7-3 removed the use of update-inetd in the postinst to enable the service. The patch included in this bug (and blocked by #24043) is no longer relevant. * Users still using /etc/inetd.conf style inetd servers can add the tcp6 entry themselves and that will work. * (Most) users using the systemd socket files which use "ListenStream" will get IPv4 and IPv6 (unless BindIPv6Only is set) * I don't know how xinetd will handle it (how does the provided example specify what port to listen on?) So I think the spirit of the original wishlist bug "Please add IPv6 support by default" is met by systemd doing that by default, and there are ways for enabling support on the other inetd servers. So I think this can be closed, yay! -- Matt Taggart m...@lackof.org
Bug#943752: memtest86+: Please switch source tree
The coreboot fork of memtest86+ at https://review.coreboot.org/q/project:memtest86plus has commits as recently as Aug 31 2020 (although I don't see those if I clone https://review.coreboot.org/memtest86plus directly). I don't know if that project is related to or coordinating with the recent upstream 5.31b changes. I can't find an upstream source code repo or bug tracker. It would be good if people could collaborate on these things... There is a suggestion on the coreboot project ideas page to take the memtest86+ suite and make it more generic payload that could run on non-x86 platforms as well https://doc.coreboot.org/contributing/project_ideas.html#libpayload-based-memtest-payload That would be a great goal (but maybe just getting a common working code base would be a good start). -- Matt Taggart tagg...@debian.org
Bug#780174: memtest86 nonfree
Is it time for memtest86 (not memtest86+) to either: a) fork from the last free version b) move to nonfree (if allowed) c) be removed from debian in favor of memtest86+ ? memtest86+ has recently been seeing some updates (although the new stuff is still in beta and buggy). Also while searching I found this idea in the coreboot wiki to make a memory tester payload that wasn't x86 specific (well, might still have x86 specific support, but would also work elsewhere) https://doc.coreboot.org/contributing/project_ideas.html#libpayload-based-memtest-payload Thanks, -- Matt Taggart tagg...@debian.org
Bug#123150: bb audio still causes video to stop iff pulseaudio is installed
On 1/16/21 10:25 AM, Axel Beckert wrote: Matt: You said, you had the issue also on the console. Could you check if that "pasuspender -- env PULSE_SERVER= bb" command workarounds the issue for you on the virtual console, too? Maybe there's more virtual console support from pulseaudio nowadays… When I run that on a vc I get a brief error flash by about not being able to open an audio device and then BB runs, but no audio (even though I selected it). But at least it doesn't hang. -- Matt Taggart tagg...@debian.org
Bug#974533: new upstream (20201110 ) for RAPL/Platypus fixes
When will this get fixed in buster? I had thought it might go into the buster stable release update but I don't see it (but also it's non-free so weird). -- Matt Taggart tagg...@debian.org
Bug#976792: libwireshark11: library is huge
Package: libwireshark11 Version: 2.6.8-1.1 Severity: normal Is it normal for libwireshark.so.11.1.8 to be almost 80MB? It's by far the largest library on my system. The next largest is libLLVM-7.so.1 at 58MB, and then some other toolkit and compiler libs below 50MB and then it drops off quickly with 99% of system libraries being under 1MB. strip(1) doesn't seem to reduce it, but maybe there is some bloat in there that's not supposed to be? Thanks, -- Matt Taggart tagg...@debian.org
Bug#917128: udev 240 breaks network interface naming
I am seeing this bug on buster, currently udev 241-7~deb10u4. Somehow I wound up with /etc/systemd/network/*.link files that I did not create (maybe a postinst migration script did?). To get my old working config working again I did: * rm /etc/systemd/network/* * rm /etc/udev/rules.d/70-* * add net.ifnames=0 to cmdline and now I'm not getting the renamed interfaces and my vlans work as they did in stretch. It would be nice if this could be fixed in buster. Also... I'd be willing to move to the new systemd way of setting up vlans, but I can't find a good tutorial of how to do so in Debian. The best docs I've found so far was this Arch wiki link https://wiki.archlinux.org/index.php/VLAN but that seems like maybe it's more complicated than it needs to be. So this is also a wishlist for better docs of the "right" way to be doing this in buster and newer. Thanks, -- Matt Taggart tagg...@debian.org
Bug#958883: unattended-upgrades pegs CPU at 100% for an extended period
I am also seeing unattended upgrade consume 100% CPU. Attached is a
image of the cpu usage that started upon upgrade to buster. Each time uu
runs the system has 30-40mins of 100% cpu spinning.
The system is running the current buster version, 1.11.2.
I see:
#958883 (this bug) - fixed in 2.4, might be the same issue?
#899366 - fixed in 1.4
#960966 - still open but strace seems different
The last things I see in strace -f are:
recvmsg(5, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base=NULL,
iov_len=0}], msg_iovlen=1, msg_controllen=0,
msg_flags=MSG_CTRUNC|MSG_TRUNC|MSG_CMSG_CLOEXEC},
MSG_PEEK|MSG_TRUNC|MSG_CMSG_CLOEXEC) = 20
recvmsg(5, {msg_name={sa_family=AF_NETLINK, nl_pid=0,
nl_groups=}, msg_namelen=128->12, msg_iov=[{iov_base={{len=20,
type=NLMSG_DONE, flags=NLM_F_MULTI, seq=0, pid=31505}, 0}, iov_len=20}],
msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CTRUNC|MSG_CMSG_CLOEXEC},
MSG_CMSG_CLOEXEC) = 20
brk(0x79c5000) = 0x79c5000
brk(0x7a1f000) = 0x7a1f000
mmap(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x7f257770d000
mremap(0x7f257770d000, 1052672, 2101248, MREMAP_MAYMOVE) = 0x7f257750c000
mremap(0x7f257750c000, 2101248, 4198400, MREMAP_MAYMOVE) = 0x7f257710b000
I considered trying 2.5 from testing but it wants to pull in newer apt
and some other things.
Is a backport of 2.5 to buster possible for testing?
Let me know if you want me to try anything.
This seems important enough to fix in a stable update.
--
Matt Taggart
tagg...@debian.org
Bug#890343: default qdisc
Regarding the default qdisc setting, here's an interesting article in Phoronix about fq_pie Linux 5.9 To Allow Defaulting To FQ-PIE Queuing Discipline For Fighting Bufferbloat https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.9-FQ-PIE-QDISC I think this only means it's possible for it to be set as the default in 5.9, I don't know what the upstream kernel will ship with as a default. The Debian default needs to be updated, fq_codel would be a good choice, maybe fq_pie is a good choice starting in 5.9 as well. Any comments on this or my previous questions from April? What needs to happen for this to change? Thanks, -- Matt Taggart tagg...@debian.org
Bug#964488: UDD: browse upstream versions
Package: qa.debian.org User: qa.debian@packages.debian.org Usertags: udd Version: 20200707 Severity: wishlist I would like a way to browse upstream versions in different ways. I don't know how much is already in the database but here are some fields I've thought of. For packages with a newer upstream: * time since latest debian upload to present. (aka how much newer in time is upstream) * time since upstream with a greater version than debian latest (aka how long the package could have been updated, would need to know when uscan detected versions) * how many new upstream versions have happened since the current debian latest (this might require info about multiple uscan results?). * delta from debian version to upstream version (arbitrary and can't be compared package to package, but might still be interesting) Maybe there are more? Thanks, -- Matt Taggart tagg...@debian.org
Bug#890343: linux: make fq_codel default for default_qdisc
On 4/23/20 4:24 PM, Noah Meyerhans wrote: On Thu, Apr 23, 2020 at 03:34:06PM -0700, Matt Taggart wrote: fq_codel is better in every way than pfifo_fast and I am unaware of any reason why it would not be a better default. (but don't trust me, ask the kernel networking experts) Isn't CAKE supposed to be even better than fq_codel, including better handling of both large numbers of flows (e.g. busy routers) and small systems with limited resources. https://www.bufferbloat.net/projects/codel/wiki/Cake/ If we consider a change (which I think we should), is there a reason we wouldn't go with CAKE? In net/sched/Kconfig, the options for NET_SCH_DEFAULT are: fq, codel, fq_codel, sfq, pfifo_fast Also Documentation/admin-guide/sysctl/net.rst explains: default_qdisc - The default queuing discipline to use for network devices. This allows overriding the default of pfifo_fast with an alternative. Since the default queuing discipline is created without additional parameters so is best suited to queuing disciplines that work well without configuration like stochastic fair queue (sfq), CoDel (codel) or fair queue CoDel (fq_codel). Don't use queuing disciplines like Hierarchical Token Bucket or Deficit Round Robin which require setting up classes and bandwidths. Note that physical multiqueue interfaces still use mq as root qdisc, which in turn uses this default for its leaves. Virtual devices (like e.g. lo or veth) ignore this setting and instead default to noqueue. CAKE, while better for AQM, requires interface specific parameters and so won't work for a default (and also is generally used in conjunction with fq_codel) -- Matt Taggart tagg...@debian.org
Bug#890343: linux: make fq_codel default for default_qdisc
#890343 was originally opened against systemd asking to install the upstream systemd sysctl.d/50-default.conf file that sets: net.core.default_qdisc = fq_codel As explained in #950701 (and the systemd debian changelog) the debian systemd maintainers felt that systemd in debian should not be changing kernel policies (and I agree). So #890343 was reassigned to linux to consider changing the default. fq_codel is better in every way than pfifo_fast and I am unaware of any reason why it would not be a better default. (but don't trust me, ask the kernel networking experts) Can we change it? Related thoughts: * ubuntu issue, looks like maybe they already switched by default due to the systemd change? https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1773157 * another ubuntu issue that might help https://bugs.launchpad.net/ubuntu/+bug/940541 * are there other related defaults that should change too? like tcp_ecn, syncookies, BBR, etc * what are upstream kernel defaults and why? -- Matt Taggart tagg...@debian.org
Bug#123150: bb audio still causes video to stop
I am still seeing the problem with bb audio causing video to stop. The audio keeps playing but the video freezes. Answering no to the initial music prompt allows the video to work the whole way through. Same problem both under X and in virtual console. Running: buster bb: 1.3rc1-11 libmikmod3: 3.3.11.1-4 -- Matt Taggart tagg...@debian.org
Bug#952411: chromium: coming ScrollToTextFragment in Chrome 80
Package: chromium Version: 80.0.3987.106-1 I just saw this article about a new feature coming in Chrome 80, https://www.forbes.com/sites/gordonkelly/2020/02/23/google-chrome-80-upgrade-deep-linking-update-chrome-browser/ That seems like something we want to not include in debian chromium. I ran a grep on the current unstable source and this is what it found. $ rgrep ScrollToTextFr third_party/blink/renderer/core/page/scrolling/text_fragment_anchor.cc: // https://wicg.github.io/ScrollToTextFragment/#should-allow-text-fragment third_party/blink/renderer/core/frame/fragment_directive.idl:// https://github.com/WICG/ScrollToTextFragment Based on those I then searched for "TextFragment" which found a lot more (but I don't know which are relevent). Maybe someone who understands the chromium source can investigate further. Thanks, -- Matt Taggart tagg...@debian.org
Bug#951232: smokeping: document apache setup
Package: smokeping Version: 2.7.3-2 Severity: wishlist smokeping upstream doesn't really provide much documentation on how to setup smokeping in apache. The debian package at least provides the /etc/apache2/conf-available/smokeping.conf file which helps a lot. In addition to that, here are some things I had to do: * install alias module so that ScriptAlias and Alias work * install mpm_prefork and cgi modules (is there a way to use event or worker?) * setup SSL with letsencrypt - install the ssl module, and also the mime module since ssl uses AddType and socache_shmcb module - if you are doing this and using the webserver itself to provide proof of controlling the host you might need to exclude the .well-known dir with something like: RedirectMatch ^/(?!.well-known.*)$ https://example.com/smokeping/smokeping.cgi * install authz_core module since "Require all granted" is used * I also password protected mine which required: auth_basic, authn_core, authn_file The webserver section of the upstream install document at https://oss.oetiker.ch/smokeping/doc/smokeping_install.en.html mentions: The important thing is, to have a webserver which allows you to run CGI and preferably FastCGI scripts. If you are using Apache I strongly recommend using the suexec system for running CGI scripts as a particular user. See http://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html and http://httpd.apache.org/docs/2.2/mod/mod_suexec.html for more information on this. It would be nice to document how to do this and maybe switch the conf-available to use that method. Maybe these things could be made into a README.apache that could be included. It could start with "The smokeping package includes an apache config at /etc/apache2/conf-available/smokeping.conf that is enabled by default." and the talk about the needed modules and maybe how to a2disconf it and Include it in another conf instead, etc. Thanks, -- Matt Taggart tagg...@debian.org
Bug#948844: debmake: option for git maintained packages
On 1/25/20 9:31 AM, Sean Whitton wrote: Hello Matt, others, On Mon 13 Jan 2020 at 02:05PM -08, Matt Taggart wrote: I am working on creating a new package and I have chosen use the 'dgit-maint-merge' method of packaging (see dgit-maint-merge(7) in the dgit package). This method (and some of the other dgit(1) recommended methods) generates the initial packaging out of a checked out git repository, rather than an unpacked upstream tarball in a versioned directory and orig tarball. I have only ever used debmake to generate the contents of debian/, after I've already got the upstream source into git myself. Are you asking for debmake to do that for you if you provide it with an upstream git repo clone URI? I am following the the "When upstream tags releases in git" section of dgit-maint-merge(7) and when I get to the "Now go ahead and Debianise..." section I'd like to be able to run debmake, but it's expecting the source dir to have a particular name and the orig tarball to exist. s/debhelper/debmake/ right? Yes, sorry. 1) don't create debian/patches/ 2) don't create debian/source/local-options 3) I'm not sure if watch is needed 4) create debian/source/options containing: single-debian-patch auto-commit 5) create debian/source/patch-header with a description of how to get changes to the upstream source. I guess this should be a template that fills in package name and git repo? For #3 and #4 see the dgit-maint-merge(7) manpage for examples and explanation. I think that debmake might not be the right place for (2), (4) and (5). Instead, I think a 'maintmerge' script in the dgit package should do that setup, so that non-debmake users can take advantage. See #852226. debmake is already creating a template for (2). I like the idea of putting these steps in a dgit script though and having the dgit-maint-merge(7) manpage explain how to use it. Then maybe debmake could add a basic mode to handle the other remaining things. -- Matt Taggart tagg...@debian.org
Bug#949456: vmdb2: grub failure with mklabel gpt
Package: vmdb2 Version: 0.13.2+git20191220-1 When I use the example yaml config at https://vmdb2-manual.liw.fi/#getting-started I get the following error: Exec: ['chroot', '/tmp/tmpyacmp7io', 'grub-install', '--target=i386-pc', '--no-nvram', '--force-extra-removable', '--no-floppy', '--modules=part_msdos part_gpt', '--grub-mkdevicemap=/boot/grub/device.map', '/dev/loop0'] ERROR: Command failed: chroot /tmp/tmpyacmp7io grub-install --target=i386-pc --no-nvram --force-extra-removable --no-floppy --modules=part_msdos part_gpt --grub-mkdevicemap=/boot/grub/device.map /dev/loop0 b'' b"Installing for i386-pc platform.\ngrub-install: warning: this GPT partition label contains no BIOS Boot Partition; embedding won't be possible.\ngrub-install: warning: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and their use is discouraged..\ngrub-install: error: will not proceed with blocklists.\n" Something went wrong, cleaning up! If I change the mklabel step to use msdos instead of gpt then it works. From IRC: ...It is, of course, missing a magic number in the device... But, yes, it makes sense that the generated image is not listed in /boot/grub/device.map Thanks, -- Matt Taggart tagg...@debian.org
Bug#949455: vmdb2: new copy-file step
Package: vmdb2 Version: 0.13.2+git20191220-1 Severity: wishlist I would like to be able to use the new copy-file step listed at https://vmdb2-manual.liw.fi/#step-copy-file It looks like it was added here http://git.liw.fi/vmdb2/commit/?id=eabf1e8fc87fa581db997f2506a9ad708f1420e3 but that it didn't make it in the current version in unstable. So when it makes sense, please consider a new version in unstable (and maybe a buster backport when it goes into testing). Thanks, -- Matt Taggart tagg...@debian.org
Bug#948844: debmake: option for git maintained packages
I also realized for dgit-maint-merge debhelper might want to do the following differently: 1) don't create debian/patches/ 2) don't create debian/source/local-options 3) I'm not sure if watch is needed 4) create debian/source/options containing: single-debian-patch auto-commit 5) create debian/source/patch-header with a description of how to get changes to the upstream source. I guess this should be a template that fills in package name and git repo? For #3 and #4 see the dgit-maint-merge(7) manpage for examples and explanation. -- Matt Taggart tagg...@debian.org
Bug#948844: debmake: option for git maintained packages
Package: debmake Version: 4.3.1-1 Severity: wishlist I am working on creating a new package and I have chosen use the 'dgit-maint-merge' method of packaging (see dgit-maint-merge(7) in the dgit package). This method (and some of the other dgit(1) recommended methods) generates the initial packaging out of a checked out git repository, rather than an unpacked upstream tarball in a versioned directory and orig tarball. I would like debmake to have an option to support this method and just setup the debian directory with the templates filled in. Maybe such an option would require -p and -u to get the package name and version since it might not be able to determine them from the directory/tarball, that would be OK I think. It might also not be able to distinguish between debian native and upstream packages either, so might default to upstream unless -n is specified. What do you think? Thanks, -- Matt Taggart tagg...@debian.org
Bug#944686: spectre-meltdown-checker: support for new TAA CVE-2019-11135
Package: spectre-meltdown-checker Version: 0.42-2 Severity: wishlist It looks like upstream added some changes for the new TAA vulnerability CVE-2019-11135, made some other fixes since 0.42, updated the mcedb, etc. but hasn't yet issued a new release. It looks like maybe they are still working on solving #314 first? Anyway hopefully a new upstream is coming soon and it would be good to make available for stretch/buster. Thanks, -- Matt Taggart tagg...@debian.org
Bug#933217: RM: check-mk -- RoQA, RC-Buggy, unmaintained, no reverse dependency
On 10/8/19 2:06 PM, Moritz Mühlenhoff wrote: > On Mon, Sep 30, 2019 at 09:34:46AM -0700, Matt Taggart wrote: >> Hi, >> >> >> I think it's fine for check-mk to be removed from unstable, if it does >> end up in Debian again it will be repackaged and should go through NEW >> again anyway. > > Ack, I've just filed a removal bug. I suppose the version from > experimental should be removed as well? Yes. Thanks, -- Matt Taggart tagg...@debian.org
Bug#933217: RM: check-mk -- RoQA, RC-Buggy, unmaintained, no reverse dependency
Hi, Thanks for opening this bug, this should have been discussed a while ago. check-mk in debian was originally packaged and uploaded for Debian when it was a pretty basic nagios add-on. Since then upstream has both continued to add features and automation layers above that basic functionality (OMD, BI, etc) and also at the same time made a commercial business out of selling support and added non-FOSS components. It is now very difficult to support the check-mk core functionality as it's packaged in Debian. I began packaging the 1.4.0 stable release and realized that the levels of integration of the core functionality and the higher layers were going to make it nearly impossible to untangle. For check-mk to continue in Debian we'd need to either: 1) fork the "Checkmk Raw Edition (CRE)" and work to remove the dependencies and non-FOSS integration, maintaining the fork over time and merging changes made to the core agents. 2) repackage the FOSS components, adopting all of upstream's levels of automation and integration as a monolithic package and no longer just be an add-on for other monitoring system. My own use of check-mk involved using a puppet module to automatically configure checks for new systems as they were added, by automatically editing config files. This does not work well with the "full stack" model where the administrator is expected to do things via a UI. So option #2 is not interesting to me, and option #1 sounds like a lot of work. What I need to do next is investigate icinga2's equivalent functionality and see if that's a good replacement option. I think it's fine for check-mk to be removed from unstable, if it does end up in Debian again it will be repackaged and should go through NEW again anyway. Thanks, -- Matt Taggart tagg...@debian.org
Bug#695873: memtest86+: Serial console does not work
I have also confirmed the patch to fix serial console that was sent to #695873 works. I was applying it to 5.01-3, building on buster, installed and booted fine. Please apply. Thanks, -- Matt Taggart tagg...@debian.org
Bug#931866: debirf: dpkg-divert warnings
Package: debirf Version: 0.38 Severity: minor I noticed some warnings when running debirf on buster dpkg-divert: warning: please specify --no-rename explicitly, the default will change to --rename in 1.20.x Removing 'diversion of /sbin/ldconfig to /sbin/ldconfig.REAL by fakechroot' dpkg-divert: warning: please specify --no-rename explicitly, the default will change to --rename in 1.20.x Removing 'diversion of /usr/bin/ldd to /usr/bin/ldd.REAL by fakechroot' Buster released with dpkg 1.19.7, so probably this will break once dpkg development resumes in testing. Thanks, -- Matt Taggart tagg...@debian.org
Bug#931863: debirf: buster build fails to create initrd
Package: debirf
Version: 0.38
When running a debirf build on a buster machine, building a stable
(buster) rescue image, everything works up until creating the initrd
...
debirf> modules complete
debirf> creating debirf initrd ('nested')...
cp: cannot stat '/home/taggart/debirf/rescue/root/lib/klibc-*': No such
file or directory
--
Matt Taggart
tagg...@debian.org
Bug#930966: RFP: pwnat -- allows clients behind NATs to communicate
Package: wnpp Severity: wishlist * Package name: pwnat Version : 0.3 Upstream Author : Samy Kamkar * URL : https://samy.pl/pwnat/ * License : GPL Programming Lang: C Description : allows clients behind NATs to communicate Pronounced "poe-nat", a tool that allows any number of clients behind NATs to communicate with a server behind a separate NAT with *no* port forwarding *no* DMZ setup, and *no* 3rd party involvement. The server does not need to know anything about the clients trying to connect. The same author wrote a similar tool, chownat https://samy.pl/chownat/ , which might make sense for whomever packages this to also package. -- Matt Taggart tagg...@debian.org
Bug#576359: usb bootdrive utilities in Debian
Today I was looking for utilities to create bootable USB drives. In WNPP I discovered quite a few ITP/RFPs for these types of tools: https://bugs.debian.org/cgi-bin/bugreport.cgi?915458 multibootusb -- A cross platform utility to create multi boot live Linux on a removable USB disk https://bugs.debian.org/cgi-bin/bugreport.cgi?576359 usb-creator-to-be-renamed -- startup disk creator#718301 fedora-liveusb-creator -- Cross-platform tool for installing live operating systems on to USB flash drives https://bugs.debian.org/cgi-bin/bugreport.cgi?732647 mintstick -- USB stick formatter and ISO image writer https://bugs.debian.org/cgi-bin/bugreport.cgi?831981 mkusb - Tool to make boot drives. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718301 fedora-liveusb-creator -- Cross-platform tool for installing live operating systems on to USB flash drives (now MediaWriter) https://bugs.debian.org/cgi-bin/bugreport.cgi?869875 woeusb -- Bootable USB Storage Creator for Windows Installer/PE And already in debian there is debootstick and some other efi/iso tools. Some of these are old and may not be supported/useful any more. Some of these may be distro/OS specific, But hopefully there is one that is being maintained and is generic enough to replace what the others do so we don't need to maintain all these things. Submitters/participants, please reply to your bugs (trim cc list accordingly) and let us know what's going on with these. -- Matt Taggart tagg...@debian.org
Bug#869875: ITP: woeusb
I was looking at #869875 since I was looking for something like woeusb. The upstream packaging was able to produce a debian package with some minor modifications (to follow normal debian process rather than upstream's package build process and mk-build-deps/gdebi stuff). I was looking at how it works and discovered in the source that it does a wget from a github url in order to grab a raw uefi-ntfs image file https://github.com/slacka/WoeUSB/blob/master/src/woeusb#L1167 that repository in turn gets it from the uefi-ntfs project https://github.com/pbatard/uefi-ntfs which also depends on EfiFS https://github.com/pbatard/efifs Obviously this is bad for security/Free Software/reliability reasons. But all of the above appear to be Free Software, so it might be possible to package them and have that image file available via a binary package at runtime when woeusb needs it. Thanks, -- Matt Taggart tagg...@debian.org signature.asc Description: OpenPGP digital signature
Bug#920766: postfix: support for client TLS connection reuse coming in 3.4
Package: postfix Version: 3.3.2-1 Severity: wishlist According to http://www.postfix.org/TLS_README.html#client_tls_reuse postfix version 3.4 gains support for doing Client-side TLS connection reuse. I was attempting to setup a "slow" transport for a domain(I'm looking at you orange.fr) that tuned connection settings and then realized it wasn't effective because the connections were TLS and not getting reused. It looks like 3.4 is still in development upstream currently. Consider this a wishlist request to get it in unstable and eventually buster-backports once it's possible. Thanks! -- Matt Taggart tagg...@debian.org
Bug#919725: cryptsetup: switch to LUKS2 by default for new installs
Package: cryptsetup Version: 2:2.0.6-1 Severity: wishlist LUKS2 format was introduced in 2:2.0.0~rc0-1 which went into debian on 03 Oct 2017. There was some discussion on the debian-boot list during the libcryptsetup transition about the format https://lists.debian.org/debian-boot/2017/12/msg00231.html including a comment, "feel free to poke us again for partman-crypto when the new format looks mature enough so that we see about adding support for it." Is it ready to become the default for new installs yet? I started thinking about this when I saw that Fedora is planning on moving to it by default https://www.phoronix.com/scan.php?page=news_item&px=Fedora-30-LUKS2-Default Thanks, -- Matt Taggart tagg...@debian.org
Bug#870094: problems with stretch gqrx-sdr
=> /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1 (0x7f1970bad000) libdrm.so.2 => /usr/lib/x86_64-linux-gnu/libdrm.so.2 (0x7f197099d000) libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x7f197072a000) libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x7f1970709000) libboost_timer.so.1.62.0 => /usr/lib/x86_64-linux-gnu/libboost_timer.so.1.62.0 (0x7f1970502000) libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x7f19702fe000) libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x7f19700f8000) libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x7f196fee2000) libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7f196fcdd000) libXi.so.6 => /usr/lib/x86_64-linux-gnu/libXi.so.6 (0x7f196facd000) libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x7f196f8a3000) liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7f196f67d000) liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 (0x7f196f46b000) libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 (0x7f196f15b000) libFLAC.so.8 => /usr/lib/x86_64-linux-gnu/libFLAC.so.8 (0x7f196eee4000) libogg.so.0 => /usr/lib/x86_64-linux-gnu/libogg.so.0 (0x7f196ecdb000) libvorbis.so.0 => /usr/lib/x86_64-linux-gnu/libvorbis.so.0 (0x7f196eaad000) libvorbisenc.so.2 => /usr/lib/x86_64-linux-gnu/libvorbisenc.so.2 (0x7f196e804000) libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x7f196e5ed000) libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x7f196e3d9000) === So it seems to be using 1.62 boost libraries (rather than the 1.67 also provided in stretch). -- Matt Taggart tagg...@debian.org
Bug#916736: debirf: rescue could include stress-ng
Package: debirf Version: 0.38 Severity: wishlist It would be nice if the rescue image could include the stress-ng package for system load testing. (PS there is also the stressapptest package, but at brief glance stress-ng seems to have more features) (PPS the stressant package, which is built on debirf, includes stress-ng and some other good tools. that might be a reason for/against debirf doing so) Thanks, -- Matt Taggart tagg...@debian.org
Bug#910111: RFP: solid -- set of conventions and tools for building decentralized social applications based on Linked Data principles
Package: wnpp Severity: wishlist * Package name: solid Version : varies Upstream Author : varies * URL : https://solid.mit.edu/ * License : MIT Programming Lang: node.js, etc Description : set of conventions and tools for building decentralized social applications based on Linked Data principles Solid (derived from "social linked data") is a proposed set of conventions and tools for building decentralized social applications based on Linked Data principles. Solid is modular and extensible and it relies as much as possible on existing W3C standards and protocols. At a glance, here is what Solid offers... * True data ownership: Users should have the freedom to choose where their data resides and who is allowed to access it. By decoupling content from the application itself, users are now able to do so. * Modular design: Because applications are decoupled from the data they produce, users will be able to avoid vendor lock-in, seamlessly switching between apps and personal data storage servers, without losing any data or social connections. * Reusing existing data: Developers will be able to easily innovate by creating new apps or improving current apps, all while reusing existing data that was created by other apps. In addition to the main Solid webpage, Inrupt(a startup company created to work on Solid) has some good pages https://solid.inrupt.com/ Solid has server implementations, tools, apps, etc. The main repository is https://github.com/solid * node-solid-server is the server reference implementation * there are various libraries for doing things like authorization, ACLs, OpenID, etc * There are some apps listed at https://github.com/solid/solid-apps Whomever takes this on will need to determine which components make sense to include in debian in order to provide a reasonable support for developing and deploying Solid applications. On https://solid.inrupt.com/community under "Packaging" they state they would like to get distro packages created. -- Matt Taggart tagg...@debian.org
Bug#910109: Subject: RFP: faircoin -- a digital currency that is powered by a cooperative grassroots movement
Package: wnpp Severity: wishlist * Package name: faircoin Version : 2.0.1 Upstream Author : Thomas König * URL : https://fair-coin.org/ * License : MIT/X Programming Lang: C Description : a digital currency that is powered by a cooperative grassroots movement FairCoin implements fair value exchange on a global level. Our innovative Proof-of-Cooperation (PoC) blockchain mechanism is the unique consensus algorithm developed for FairCoin. It requires much less energy than other blockchains but also enables faster transactions. https://github.com/faircoin/faircoin -- Matt Taggart tagg...@debian.org
Bug#907892: libcache-memcached-fast-perl: upstream URL update
Package: libcache-memcached-fast-perl Version: 0.25-1 Hi, The upstream URLs listed in control (and also the upstream README) are out of date. The page in control: http://openhack.ru/Cache-Memcached-Fast doesn't seem to work anymore. In README: http://search.cpan.org/dist/Cache-Memcached-Fast/ now redirects to https://metacpan.org/release/Cache-Memcached-Fast https://github.com/kroki/Cache-Memcached-Fast now now redirects to https://github.com/JRaspass/Cache-Memcached-Fast For Homepage I guess use the metacpan page? Thanks, -- Matt Taggart tagg...@debian.org signature.asc Description: OpenPGP digital signature
Bug#901083: lxmusic: something causes system to go OOM
Package: lxmusic Version: 0.4.7-1 Up front I apologize that this bug report is vague and mostly anecdotal. Maybe I will have more luck tracking it down later or maybe others will. I discovered that if I have lxmusic running and also do video/audio a lot in my browser, the system will go OOM and become totally unresponsive for 10-15mins until the OOM killer manages to kill the right things. I'm not sure if the bug is in lxmusic or if it's just tickling a bug in pulseaudio or the particular drivers for my system or what. I just know that if I don't run lxmusic then the problem doesn't happen. To repeat the problem: have lxmusic running, audio paused, and then watch a bunch of youtube videos in chromium. I hope to have time to try narrowing down the problem, but as this is my main work desktop that is fairly disruptive. In case it matters, my audio devices are: 00:03.0 Audio device [0403]: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller [8086:0c0c] (rev 06) 00:1b.0 Audio device [0403]: Intel Corporation 8 Series/C220 Series Chipset High Definition Audio Controller [8086:8c20] (rev 04) -- Matt Taggart tagg...@debian.org
Bug#898358: sympa: dependency differences from upstream
Package: sympa Version: 6.2.32~dfsg-1 I was reviewing upstream src/lib/Sympa/ModDef.pm, and comparing with the package Depends and found the following differences in dependencies in debian/control that I didn't understand. Maybe there are reasons for them or maybe they need to be added? Missing Depends: ModDef.pm debian package name Clone libclone-perl (but pulled in via libdbd* -> libdbi-perl -> libclone-perl) Crypt::Eksblowfish libcrypt-eksblowfish-perl Data::Password libdata-password-perl DateTime::TimeZone libdatetime-timezone-perl (but pulled in via libdatetime-format-mail-perl -> libdatetime-perl -> libdatetime-timezone-perl ) Encode::Locale libencode-locale-perl List::Util::XS N/A, ModDef.pm says: # The pure-perl version of Scalar::Util::looks_like_number() was unstable. # To force using XS version, check existence of List::Util::XS. URI::Escape liburi-perl Depends but not in ModDef.pm: libmsgcat-perl libcrypt-ciphersaber-perl is in recommends, the text in ModDef.pm says: Crypt::CipherSaber this module provides reversible encryption of user passwords in the database. Useful when updating from old version with password reversible encryption, or if secure session cookies in non-SSL environments are required. Is that always used or optional? -- Matt Taggart tagg...@debian.org
Bug#897931: preseed: add tests for additional url= bare host cases
Package: preseed Version: 20180504 Severity: wishlist The preseed file I have been using (for quite a few releases now) relies on the behavior documented at https://www.debian.org/releases/stable/i386/apbs02.html.en#preseed-auto where if url= does not list a protocol then http is assumed, and does not end in / then default path is added. I was trying to debug something and was looking through the preseed source and realized that package/preseed/01-auto-install.t could use a couple more test cases: 1) url= with a bare hostname like "url=server.example.org" 2) url= with a bare IP like "url=10.0.0.5" 3) I guess IPv6 is possible too? "url=fd00:9:152:48:1822::162:199" (or maybe it's "url=[fd00:9:152:48:1822:ffff:162:199]"?) Thanks, -- Matt Taggart tagg...@debian.org
Bug#896508: ganeti-instance-debootstrap: provide config files for various debian releases
Package: ganeti-instance-debootstrap Version: 0.16-5 Severity: wishlist Currently ganeti-instance-debootstrap, in variants.list, only lists a 'default' variant (and provides the variants/default.conf for it). Could it also provide support for specific releases by name. I think the current stable, oldstable, and maybe testing and unstable release names. I don't know if it works but maybe the generic names work too? So variants.list could contain default jessie stretch buster sid oldstable stable testing unstable and the variants/ dir contain conf files for them (or symlinks). Then with 'gnt-instance add -o ' one could use debootstrap+whatever to get the various things. The only downside I can think of is having to maintain that list over time. What do you think? Thanks, -- Matt Taggart tagg...@debian.org
Bug#774711: openssh 7.6 changes
Hi, Just a quick update on #774711. As pre-announced in earlier releases, OpenSSH 7.6 did drop support for some old unsafe crypto options: * dropped SSHv1 protocol support * removed hmac-ripemd160 MAC * removed arcfour, blowfish and CAST ciphers * refuses RSA keys <1024 bits in length * does not offer CBC ciphers by default As far as I know, the following potentially unsafe things are still supported in 7.7: Keys: * NIST curves Kex: * NIST curves * diffie-hellman-group14-sha1 * diffie-hellman-group-exchange-sha1 (min 2048 now at least) MACs: * sha1 * umac-64 Debian users wanting to drop support for the legacy crypto options mentioned previously in this bug can use the following: === HostKeyAlgorithms ssh-ed25519-cert-...@openssh.com, ssh-ed25519,\ ssh-rsa-cert-...@openssh.com, ssh-rsa-cert-...@openssh.com,ssh-rsa KexAlgorithms curve25519-sha...@libssh.org,\ diffie-hellman-group-exchange-sha256 Ciphers chacha20-poly1...@openssh.com,aes256-...@openssh.com, aes128-...@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr MACs hmac-sha2-512-...@openssh.com,hmac-sha2-256-...@openssh.com,\ umac-128-...@openssh.com,hmac-sha2-512,hmac-sha2-256,\ umac-...@openssh.com === -- Matt Taggart tagg...@debian.org
Bug#892803: di-netboot-assistant: unsigned daily images
On 03/13/2018 10:28 PM, Cyril Brulebois wrote: What extra security would signing images bring here? For me, assurance that nobody had interfered with the daily image that I will use to install a system. Many systems I install with a daily are for testing and get thrown away rather quickly (although often I don't know in advance which ones will end up sticking around longer). One reason in the past I have installed systems with a daily build that I know will stick around is due to needing support for new hardware at install time, where I couldn't just get an older install on the system with a stable d-i and then upgrade the kernel post-install. Usually things like drivers for a disk controller, newish filesystem features, or network drivers for doing a network install. The testing alpha/beta/rc releases _do_ get signed right? Maybe that's a better solution for the above case where I need something newer than stable, but testing would in most cases be "new enough". But still thinking about daily... d-i.d.o does use https and has it's own Let's Encrypt issued cert, I think I could verify the cert and then check that the netboot.tar.gz matches the one published in https://d-i.debian.org/daily-images/amd64/daily/SHA256SUMS Looking at the code, it looks like d-n-a already does the latter part I guess to prevent cases of download corruption, broken mirrors, etc. The default di-sources.list uses https for the daily images. And the code uses either wget or curl, both of which default to verifying certs via the normal system ca list. So it's already doing quite a bit to verify even the daily image sources. That's good, but if I was an attacker trying to mitm, I'd just need to find the weakest link in the CA cartel to issue me a d-i.d.o cert I could use for my mitm mirror. This is a corner case for sure and if there is no reasonable way to solve it I think that's OK. I think if I wanted to prove to myself the daily image came from debian, I could verify the cert used for d-i.d.o was indeed the known debian owned one, download the netboot.tar.gz/SHA256SUMS and stick them in the cache, and then use the --offline flag. -- Matt Taggart tagg...@debian.org
Bug#892803: di-netboot-assistant: unsigned daily images
Package: di-netboot-assistant Version: 0.51 Severity: minor When attempting to install a daily image I get the following # di-netboot-assistant install daily --arch=amd64 I: Processing daily/amd64. I: Downloading 'SHA256SUMS'. E: Could not download 'https://d-i.debian.org/daily-images/amd64/daily/../../../../Release' and/or 'Release.gpg'. * * * * * * * * * * * * WARNING * * * * * * * * * * * * * * * * Could not verify/find the signature of the release. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Download and install the image anyway? [y|N]: In the package provided di-sources.list file, in the daily section, there are the following comments, ## Daily netboot DI images (not signed?!?). Read: # https://d-i.debian.org/daily-images/build-logs.html # http://wiki.debian.org/DebianInstaller/Today which is a hint that this is likely to fail. It would be nice if the d-i daily's were signed, even if they had to use a different key that I would then need to install on the system so that this di-netboot-assistant check could use. Is there already a bug open requesting daily image signing? If not then maybe this one can be cloned and reassigned to the right place. But until something like that is possible I suggest a couple things: * add something to the error message detecting when installing daily and explaining it's known that daily images currently aren't signed * add some sort of override option for daily images to skip the check, printing a warning. This would allow for calling di-netboot-assistant from other tools (scripts, puppet, etc) * update the comments in di-sources.list explaining dailys aren't signed and will result in the warning prompt * the 'Today' URL in the comments no longer exists, I couldn't find a good replacement -- Matt Taggart m...@lackof.org
Bug#892800: di-netboot-assistant: errors when $HOME not set
Package: di-netboot-assistant Version: 0.51 Severity: minor I have a puppet module that calls di-netboot-assistant to setup d-i images. When puppet runs the command, $HOME is not set. Because di-netboot-assistant uses "set -u" (line 3) when it attempts to use $HOME (line 56), the script exist with an error /usr/bin/di-netboot-assistant: line 56: HOME: unbound variable It's easy to repeat, just 'unset HOME'. Removing the -u from the set allows it to work fine (since the if on line 56 is just false when $HOME isn't set). -- Matt Taggart tagg...@debian.org
Bug#789247: di-netboot-assistant: broken deb.d.o urls
On 03/10/2018 04:22 AM, Andreas B. Mundt wrote: Hm, the /debian/ should be inserted by the following in '/etc/di-netboot-assistant/di-netboot-assistant.conf' [1]: #Download Mirror # The variable MIRROR_REGEXPS contain a list of space separated sed # regular expression, to rewrite di-sources.list URLs, to match your # prefered mirror. For example: MIRROR_REGEXPS="s=://deb.debian.org/=://deb.debian.org/debian/=" I was already wondering why not to use the correct URL in 'di-sources.list', but kept that as it works fine for me. Can you check if you have the line in 'di-netboot-assistant.conf'? Perhaps it's there for historical reasons and we can/should remove it. Oh... I had just grabbed the latest di-sources.list to use on an older version of the package, I didn't know about that regexp thing in the config file... It's sort of a nice feature, it makes using a local mirror/proxy easier (assuming you know you can use that). But I suspect most mirrors would have a debian/ dir and if a user had one that _didn't_ then the regexp could be setup the other way to strip it out. So my vote would be fix the URLs in di-sources.list, comment out MIRROR_REGEXP in the conf, change it's regexps to provide an example of how it could be used. I guess the only concern is the existing conffiles that are out there and if that would break existing installs. If you changed both sources and conf at the same time, hopefully it would be clear. I guess if you go that route, wait until one of them needs another change anyway? -- Matt Taggart tagg...@debian.org
Bug#789247: di-netboot-assistant: broken deb.d.o urls
It looks like the deb.debian.org URLs in di-sources.list need to be updated E: Can't download 'stretch' for 'amd64' (http://deb.debian.org/dists/stretch/main/installer-amd64/current/images/MD5SUMS). The URL should have a leading 'debian/' in the path, ie http://deb.debian.org/dists/stretch/main/installer... I don't know if this is just some mirrors or everywhere, but not having it resulted in an error for me (it resolved to cdn-aws.deb.debian.org) Thanks, -- Matt Taggart tagg...@debian.org
Bug#888804: iproute2: some upstream URLs broken
Package: iproute2 Version: 4.14.1-2 Severity: wishlist The Homepage header in debian/control lists https://wiki.linuxfoundation.org/networking/iproute2 but that page is 404. It's probably not supposed to be, there is a link to the same thing on https://wiki.linuxfoundation.org/networking/start In the source package README it also lists http://www.linuxfoundation.org/collaborate/workgroups/networking/iproute2 but that seems to redirect to the same 404 URL as well. The source README also lists this url for git: git://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.git which I was able to clone and has updates as of today so must be up to date... but I don't see it listed at https://git.kernel.org/. There is https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/ which seems to be just as up to date, but I'm not sure which is considered canonical. The Download URL listed in the source README is http://www.kernel.org/pub/linux/utils/net/iproute2/ and that works and appears to be up to date. FYI- The wikipedia page also has the same broken links https://en.wikipedia.org/wiki/Iproute2 Probably upstream needs to fix things? -- Matt Taggart tagg...@debian.org
Bug#886367: intel-microcode: more meltdown/spectre info
I read that RHEL is already issuing microcode updates for RHEL7. I read it second hand at https://lists.bufferbloat.net/pipermail/cerowrt-devel/2018-January/08.html But maybe there is an official URL somewhere? I found the following pages https://access.redhat.com/security/vulnerabilities/speculativeexecution https://access.redhat.com/articles/3311301 But I couldn't find any reference to microcode versions. -- Matt Taggart tagg...@debian.org
Bug#886368: intel-microcode: copyright URLs out of date
Package: intel-microcode Version: 3.20171117.1 Severity: wishlist The two upstream download URLs listed in the copyright file no longer work (and are also http URLs). Searching I found the following https://downloadcenter.intel.com/download/27337/Linux-Processor-Microcode-Data-File but I suspect that URL might be specific to the 20171117 version. Hopefully you can find a more generic URL for the latest version. Thanks, -- Matt Taggart tagg...@debian.org
Bug#886367: intel-microcode: coming updates for meltdown/spectre
Package: intel-microcode Version: 3.20171117.1 Severity: grave It's been rumored that Intel will be releasing microcode updates to (partially?) mitigate some of the effects of meltdown and spectre. It appears that the latest version on the website is still 20171117. Any news of what this will be and when it will happen? Thanks, -- Matt Taggart tagg...@debian.org
Bug#764636: Badblocks does not support large disks
There is a similar bug in Red Hat Bugzilla, https://bugzilla.redhat.com/show_bug.cgi?id=1306522 which is "CLOSED WONTFIX" and indicates that upstream doesn't support badblocks on large devices (maybe doesn't support badblocks at all?) Maybe #76636 should do the same? -- Matt Taggart tagg...@debian.org
Bug#882797: samba: time machine support
Package: samba Version: 2:4.7.3+dfsg-1 Severity: wishlist I was searching for support for using Apple's (proprietary) Time Machine MacOS backup system over the network to a Debian system. In the past Time Machine used Apple's AFP and people were successful using the netatalk software (with some tweaks on the client) to make this work. But I just found this forum post that indicated that Apple is moving away from AFP and to SMB instead, https://discussions.apple.com/message/30723500#message30723500 The thread indicates that Apple has talked to the samba project about what is needed to support this. I searched and I found this upstream bug, https://bugzilla.samba.org/show_bug.cgi?id=12380 So it's coming in 4.8! This is a wishlist bug to help others that might be looking for the same info. I'd love to help test this once 4.8 goes into experimental/unstable, maintainers please let us know when people can help test. Thanks, -- Matt Taggart tagg...@debian.org
Bug#685878: netatalk 3 and time machine support
I did some more reading about netatalk support for Apple Time Machine backups. I found this post that mentions apple plans to phase out AFP in favor of SMB over the long term. https://discussions.apple.com/message/30723500#message30723500 AFP will continue to be supported for quite a while due to it's use in older versions of MacOS, and devices like Time Capsule, etc. But the future will be SMB. It's would still be useful to have the newer netatalk3 in debian (and derivatives) to quickly be able to support the existing things out there, the SMB stuff isn't ready yet and I predict netatalk will still be useful for many years. The above post mentions that Apple has talked to the samba project about what things will be needed in order to support Time Machine via SMB. I found this bug in the samba bug tracker https://bugzilla.samba.org/show_bug.cgi?id=12380 which mentions it should become available in samba 4.8 (currently not yet released or in Debian). -- Matt Taggart tagg...@debian.org
Bug#685878: netatalk 3
Hi, Any update on netatalk 3? Upstream appears to be 3.1.11 now. Regarding Joseph's comment about support for DDP, while it would be nice to maintain that, I don't think it should hold up getting version 3 in the archive. I think the number of people that need version 4 is many times greater than those that need DDP. If needed another netatalk 2 source package could be created later. But I would worry about upstream security support, whoever wants to take on such a task would need to own supporting it. Upstream _did_ do a 2.2.6 release on 30 Jun 2017, so maybe they are still providing _some_ support? BTW when poking around I found references to this github page https://github.com/Netatalk/Netatalk Did upstream move there? Or is it a fork/clone? There are issues in the issue tracker there too. Thanks, -- Matt Taggart tagg...@debian.org
Bug#879166: knot-resolver: update Homepage
Package: knot-resolver
Version: 1.3.3-1
Severity: wishlist
Hi,
It looks like knot-resolver has it's own Homepage now
https://www.knot-resolver.cz/
Please consider updating debian/{control,copyright}
Thanks,
--
Matt Taggart
tagg...@debian.org
Bug#879162: getdns: new upstream available
Package: getdns Version: 1.1.0-2 Severity: wishlist Hi, It looks like there is a new getdns upstream version 1.2.0 with some cool new features https://getdnsapi.net/releases/ Please consider updating, and also backporting to stretch once it enters testing. Thanks! -- Matt Taggart tagg...@debian.org
Bug#865497: CVE-2017-9781 not yet fixed in 1.2.8p26-1?
On 10/06/2017 02:28 PM, Salvatore Bonaccorso wrote: Control: notfixed -1 1.2.8p26-1 Hi! On Fri, Oct 06, 2017 at 09:09:03PM +, Debian Bug Tracking System wrote: This is an automatic notification regarding your Bug report which was filed against the src:check-mk package: #865497: check-mk: CVE-2017-9781: reflected XSS in webapi.py I looked up the source for 1.2.8p26-1. The fix for CVE-2017-9781 is http://git.mathias-kettner.de/git/?p=check_mk.git;a=commitdiff;h=c248f0b6ff7b15ced9f07a3df8a80fad656ea5b1 which does not yet seem to be applied to 1.2.8p26-1? Can you please double-check? Note, there is a second CVE now for check-mk, that one got addressed in 1.2.8p26, but it's not clear yet in which version in was introduced. Hi, You are right, the fix for CVE-2017-9781, which upstream calls "werk #4757" is _not_ in 1.2.8p26. I was confused with upstream #5208 when I wrote the changelog that closed the bug. Upstream lists the following security related fixes for 1.2.8 == #5208 http://mathias-kettner.com/check_mk_werks.php?werk_id=5208&HTML=yes http://git.mathias-kettner.de/git/?p=check_mk.git;a=commitdiff;h=673360408b90f99bd54cf936091cff08d979a057 #4902 http://mathias-kettner.com/check_mk_werks.php?werk_id=4902&HTML=yes http://git.mathias-kettner.de/git/?p=check_mk.git;a=commit;h=96e39a0f024d9b2b521576c1eb71aca7fb3e818d #7661 (fixed in 1.4.0p8, supposedly fixed in 1.2.8p25?) http://mathias-kettner.com/check_mk_werks.php?werk_id=7661&HTML=yes #7631 http://mathias-kettner.com/check_mk_werks.php?werk_id=7631&HTML=yes #3970 (fixed in 1.2.8p14) http://mathias-kettner.com/check_mk_werks.php?werk_id=3970&HTML=yes #3855 (fixed in 1.2.8p11) http://mathias-kettner.com/check_mk_werks.php?werk_id=3855&HTML=yes #3743 (fixed in 1.2.8p10) http://mathias-kettner.com/check_mk_werks.php?werk_id=3743&HTML=yes Full list of changes for 1.2.8p26 = http://mathias-kettner.com/check_mk_werks.php?edition_id=raw&branch=1.2.8&version=1.2.8p26&HTML=yes Full list of changes for 1.4.0p14 = http://mathias-kettner.com/check_mk_werks.php?edition_id=raw&branch=1.4.0&version=1.4.0p14&HTML=yes which additionally lists #4757 (as you mentioned above, fixed in 1.4.0p6) http://mathias-kettner.com/check_mk_werks.php?werk_id=4757&HTML=yes http://git.mathias-kettner.de/git/?p=check_mk.git;a=commit;h=14a5b79c6f549502244a60146ed6831dc3473f2a #7643 (only in 1.4 and newer) http://mathias-kettner.com/check_mk_werks.php?werk_id=7643&HTML=yes So I think the Debian 1.2.8p16 package is only missing #4757. I will ask upstream if they intend to fix #4757 in the 1.2.8 series. Unfortunately due to how the upstream tarball/build works, it is tricky to patch upstream files. If upstream doesn't intend to include this fix I can generate a patch to make it work. I had started working on packaging 1.4.0 as a way to fix these security bugs (and even did an upload to experimental) but I recently learned from upstream that: "The use of Check_MK without OMD environment and customization of paths is explicitly not supported anymore." ie you can't use check-mk stand-alone, you have to use OMD (and livestatus/WATO/multisite, the whole stack) and you have to use upstream's installer to upstream's paths. It's very much the "network appliance" model (or flatpak, docker image, etc) I don't know if we'll be able to make this work in Debian. (not to mention that nagios is gone and icinga1 will go away at some point) That prompted me to go back to 1.2.8 and package the latest release there in order to at least have something working without the security bugs. -- Matt Taggart tagg...@debian.org
Bug#721190: debirf: additional rescue packages
Just an update on #721190, The following mentioned in this bug have been added: dmidecode ethtool fancontrol flashrom initramfs-tools-core inteltool lm-sensors memtester msrtool ntfs-3g nvramtool rsync socat squashfs-tools superiotool usbutils wget also added and useful: btrfs-progs removed, but can maybe be readded: scsitools (#686881) I would still like to see: cpuburn cramfsprogs hwclock ssh (#834476) maybe interesting contrib/non-free: intel-microcode (non-free) iucode-tool (contrib) other firmware stuff to make NICs work Also mentioned in this bug were bz2 or xz support; support for creating xz images got added but maybe it's useful to have the utilities available in rescue too? Since p7zip has support for various formats, maybe p7zip (or p7zip-full)? I don't think this bug should live forever as the place for rescue suggestions, maybe we should decide on these remaining things and close it, opening another if needed. Thanks, -- Matt Taggart tagg...@riseup.net signature.asc Description: PGP signature
Bug#865820: vim-common: Change of behaviour for default value of mouse is annoying
I am also annoyed by the new default of mouse=a, but the proposed workaround of 'touch ~/.vimrc' isn't enough for a couple reasons: 1) I want to be able to turn it off system wide, not just per user 2) By creating an empty .vimrc I'm potentially losing out on upstream defaults that I _do_ want. Is there another way to accomplish those things? Adding 'set mouse=' to /etc/vim/vimrc doesn't seem to work. -- Matt Taggart tagg...@debian.org
Bug#554794: badblocks -c and -n
Theodore Ts'o writes: > I have to ask --- ***why*** are you (and other people) running > badblocks in 2017? Badblocks as a thing started becoming irrelevant > for e2fsprogs's purpose sometime around 2003-2005, when SATA was > introduced, and drive electronics were smart enough that they could be > largely counted upon to do automatic bad block redirection in the > drive. Personally I use it for a few things: 1) as a way of forcing the drive to test every block and force to to internally reallocate any sectors that are marginal _before_ the drive is in production. The SMART tests are supposed to do this, but they are opaque and up to the vendor to implement correctly. If I use badblocks -w I know each (O/S visible) block gets tested 5 times. 2) as a way of exercising/burning-in the mechanism to avoid deploying a drive that is likely to fail. I time the badblock run and if the time diverges significantly from other drives of the same model, I know something is wrong. As a side benefit it exercises other components in the path, io controller, ram, cpu. The SMART tests should also work for this, but again it's hard to measure. (side note, I remember ~2000 someone (VA Linux Systems? joeyh? cerberus?) having a tool that did burn-in on their servers by running cpuburn in parallel with a bunch of copies of badblocks running on the (then SCSI) drives.) 3) as a cheap and easy way to wipe data from drives. Using -w with it's 5 different patterns is a good way of ensuring the data is unrecoverable before reusing/recycling the drive. If you know of better options for these tasks I'm happy to switch to something other than badblocks. Thanks, -- Matt Taggart tagg...@debian.org
Bug#554794: badblocks -c and -n
#554794 concerns the time it takes to run badblocks for any particular value of the -c option (count of blocks to do at once). At the time (2009) it wasn't clear if larger values of -c improved runtime, although one user (in 2011) reports 10% improvement. The current -c (block count) default is 64 blocks. The current -b (block size) default is 1024 bytes. AFAICT the last time they were increased was 2004 (#232240, -c from 16 to 64). A related bug (#764636) when running badblocks on a 14tb device was solved by switching to -b 4096. Given the device size increases and RAM/CPU improvements since all these things occurred, is there any value to increasing the defaults? Does anyone have any data? If not then what tests would be valuable? I often run many badblocks instances at once on separate SATA devices (so no bus contention), what are the optimal settings for that case? Thanks, -- Matt Taggart tagg...@debian.org pgp0xF0cpiIyb.pgp Description: PGP signature
Bug#865497: Wheezy update of check-mk?
Hi Raphael! Raphael Hertzog writes: > Hello Matt, > > The Debian LTS team would like to fix the security issues which are > currently open in the Wheezy version of check-mk: > https://security-tracker.debian.org/tracker/CVE-2017-9781 > > Would you like to take care of this yourself? > > The code in wheezy is different from the 1.4.x version which has been > patched upstream but I believe that a similar issue must exist since > I have seen no HTML escaping in any code showing errors. The commit message explicitly references the 1.4 branch, but I also see that the code exists in 1.2.8p16 (buster/sid). For buster/sid I will update to new 1.4 based upstream with the patch. The 1.2.6p12-1 based versions in wheezy-backports-sloppy and jessie-backports are different still, but we should push to make those go away by getting buster fixed and backporting that to w-b-s, j-b-s, and w-b. I agree that the code is pretty different in 1.1.12p7-1 (wheezy). I would appreciate help generating a patch for that that version. > That said it really depends on whether user input ends > up in the error message associated to the various exceptions > and it's hard to tell from a quick look at the code without trying. > > The traceback itself seems to be output in %s but that doesn't > prevent XSS. > > In any case, if you mant to handle this yourself, please follow the > workflow we have defined here: > https://wiki.debian.org/LTS/Development > > If that workflow is a burden to you, feel free to just prepare an > updated source package and send it to debian-...@lists.debian.org > (via a debdiff, or with an URL pointing to the source package, > or even with a pointer to your packaging repository), and the members > of the LTS team will take care of the rest. Indicate clearly whether you > have tested the updated package or not. > > If you don't want to take care of this update, it's not a problem, we > will do our best with your package. Just let us know whether you would > like to review and/or test the updated package before it gets released. > > You can also opt-out from receiving future similar emails in your > answer and then the LTS Team will take care of check-mk updates > for the LTS releases. The check-mk source package is sort of weird, it uses tarballs within the orig.tar.gz, so using a normal debian package diff, or even patching at configure time doesn't work, it has to happen after the install step runs setup.sh. I am happy for the LTS team to prepare the wheezy update and I can help with testing. I will work on uploading a fixed 1.4 version to sid in the next day. Sound OK? -- Matt Taggart tagg...@debian.org
Bug#202675: popularity-contest: Should collect and report kernel modules used
Having popcon gather information about used kernel modules would be very helpful for a wishlist bug I just filed, #860570 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860570 (in addition to the other reasons previously mentioned) Thanks, -- Matt Taggart tagg...@debian.org
