Re: HFS/HFS+ are insecure
On Thu, Jul 20, 2023 at 07:56:12PM +0200, Marco d'Itri wrote: > Package: src:linux > Severity: normal > > You are totally correct. > Kernel team, please blacklist HFS/HFS+ for automounting. Isn't this a userland policy decision? udisks will happily trigger a module load for hfsplus if udev has identified it, and I don't think there's a trivial mechanism for the kernel to disable that. I believe the only way for the kernel to disable automounting would be to disable the drivers entirely (which we don't want to do), so this probably needs to be assigned elsewhere rather than being a linux bug. (Or, alternatively, we could move hfs(+) support to FUSE and provide extremely tight seccomp policies around them, and then drop kernel support, but even though this has been talked about a bunch I haven't seen anyone try to implement it)
Re: HFS/HFS+ are insecure
On Jul 21, Matthew Garrett wrote: > > You are totally correct. > > Kernel team, please blacklist HFS/HFS+ for automounting. > Isn't this a userland policy decision? udisks will happily trigger a > module load for hfsplus if udev has identified it, and I don't think > there's a trivial mechanism for the kernel to disable that. I believe Yes, I was also thinking about this and I believe that you are right. The kernel team did this in the past for some uncommon network protocols, but they could do it themselves because these modules are autoloaded using aliases. Since I happen to be the kmod maintainer it looks like that solving this is on me. :-) Unless somebody has a better idea then then my plan is to ship in the next upload of kmod a file in /etc/modprobe.d/ which uses the blacklist directive to prevent automatically loading some file system modules. By looking at the MAINTAINERS file I have identified these file systems marked as "orphan" and "odd fixes": efs hfs hfaplus qnx6 sysv affs ecryptfs jffs2 jfs And I think that I can also safely add a few more which while actively maintained I believe are only used in a retrocomputing context or are generally uncommon anyway: befs bfs hpfs omfs qnx4 reiserfs spu ufs Did i miss anything? I think that all of these have enough of a niche usage that it would not be an unreasonable burden for the affected users to manually load the modules when needed (ad hoc or using /etc/modules-load.d/). -- ciao, Marco signature.asc Description: PGP signature
Re: HFS/HFS+ are insecure
Looks reasonable. Le vendredi 21 juillet 2023 à 10:55 +0200, Marco d'Itri a écrit : > On Jul 21, Matthew Garrett wrote: > > > > You are totally correct. > > > Kernel team, please blacklist HFS/HFS+ for automounting. > > > > Isn't this a userland policy decision? udisks will happily trigger > > a > > module load for hfsplus if udev has identified it, and I don't > > think > > there's a trivial mechanism for the kernel to disable that. I > > believe > > Yes, I was also thinking about this and I believe that you are right. > The kernel team did this in the past for some uncommon network > protocols, but they could do it themselves because these modules are > autoloaded using aliases. > > Since I happen to be the kmod maintainer it looks like that solving > this > is on me. :-) > > Unless somebody has a better idea then then my plan is to ship in > the > next upload of kmod a file in /etc/modprobe.d/ which uses the > blacklist > directive to prevent automatically loading some file system modules. > > By looking at the MAINTAINERS file I have identified these file > systems > marked as "orphan" and "odd fixes": > > efs > hfs > hfaplus > qnx6 > sysv > > affs > ecryptfs > jffs2 > jfs > > And I think that I can also safely add a few more which while > actively > maintained I believe are only used in a retrocomputing context or > are > generally uncommon anyway: > > befs > bfs > hpfs > omfs > qnx4 > reiserfs > spu > ufs > > Did i miss anything? > > I think that all of these have enough of a niche usage that it would > not > be an unreasonable burden for the affected users to manually load > the > modules when needed (ad hoc or using /etc/modules-load.d/). >
Re: HFS/HFS+ are insecure
If an official procedure to disable the driver completely is documented and hosted from an official debian server it would be, in my opinion, an acceptable solution. Users would have a copy-pastable procedure to disable HFS if the risk is intolerable to them, sysadmin would have an official page to explain why they disabled it and having users disabling a driver might add leverage to potential effort to port this file system support out of kernel with FUSE. Le vendredi 21 juillet 2023 à 09:20 +0100, Matthew Garrett a écrit : > On Thu, Jul 20, 2023 at 07:56:12PM +0200, Marco d'Itri wrote: > > Package: src:linux > > Severity: normal > > > > You are totally correct. > > Kernel team, please blacklist HFS/HFS+ for automounting. > > Isn't this a userland policy decision? udisks will happily trigger a > module load for hfsplus if udev has identified it, and I don't think > there's a trivial mechanism for the kernel to disable that. I > believe > the only way for the kernel to disable automounting would be to > disable > the drivers entirely (which we don't want to do), so this probably > needs > to be assigned elsewhere rather than being a linux bug. > > (Or, alternatively, we could move hfs(+) support to FUSE and provide > extremely tight seccomp policies around them, and then drop kernel > support, but even though this has been talked about a bunch I > haven't > seen anyone try to implement it) >
Re: HFS/HFS+ are insecure
Le vendredi 21 juillet 2023, 08:20:12 UTC Matthew Garrett a écrit : Hi > On Thu, Jul 20, 2023 at 07:56:12PM +0200, Marco d'Itri wrote: > > Package: src:linux > > Severity: normal > > > > You are totally correct. > > Kernel team, please blacklist HFS/HFS+ for automounting. > > Isn't this a userland policy decision? udisks will happily trigger a > module load for hfsplus if udev has identified it, and I don't think > there's a trivial mechanism for the kernel to disable that. I believe > the only way for the kernel to disable automounting would be to disable > the drivers entirely (which we don't want to do), so this probably needs > to be assigned elsewhere rather than being a linux bug. > > (Or, alternatively, we could move hfs(+) support to FUSE and provide > extremely tight seccomp policies around them, and then drop kernel > support, but even though this has been talked about a bunch I haven't > seen anyone try to implement it) I vaguely remember that someone implement a fuse over uml (user space linux) I used it last time to read in user space some crappy filesystem I somebody has better memory than me, it could be an idea Bastien > > signature.asc Description: This is a digitally signed message part.
Re: HFS/HFS+ are insecure
Hi Marco, hi, Marco d'Itri - 21.07.23, 10:55:39 CEST: > On Jul 21, Matthew Garrett wrote: > > > You are totally correct. > > > Kernel team, please blacklist HFS/HFS+ for automounting. > > > > Isn't this a userland policy decision? udisks will happily trigger a > > module load for hfsplus if udev has identified it, and I don't think > > there's a trivial mechanism for the kernel to disable that. I > > believe > > Yes, I was also thinking about this and I believe that you are right. > The kernel team did this in the past for some uncommon network > protocols, but they could do it themselves because these modules are > autoloaded using aliases. > > Since I happen to be the kmod maintainer it looks like that solving > this is on me. :-) > > Unless somebody has a better idea then then my plan is to ship in the > next upload of kmod a file in /etc/modprobe.d/ which uses the > blacklist directive to prevent automatically loading some file system > modules. […] > I think that all of these have enough of a niche usage that it would > not be an unreasonable burden for the affected users to manually load > the modules when needed (ad hoc or using /etc/modules-load.d/). In case you do this, I'd like there to be a NEWS.Debian entry about this, explaining both the justification behind it and how people can work around it. It could go like this: --- Since version xyz of kmod the file /etc/modprobe.d/block-unsafe- filesystems.conf prevents loading of several filesystem modules that are automatically loaded by udev when inserting a medium that contains one of them. These filesystems are either known to be unsafe or are not maintained actively anymore. A deliberately corrupted filesystem structure could trigger the filesystem driver in the module to crash, corrupt memory of other kernel components or to cause other problems. [Adjust to whatever risks are most likely to occur] [Add some links here for the discussion about that] In case you rely on using one or more of these filesystems you can either edit the file /etc/modprobe.d/block-unsafe-filesystems.conf and put a comment sign before the filesystem in question or add the filesystem to a file to a file in /etc/modules-load.d/. [Please clarify here as needed] Please take care not to plug in any device that you do not trust. --- This is just a rough idea it probably needs several iterations to obtain a good wording that balances on assessing the risk correctly (without over or under estimating it). Also the method of circumventing the blocking may need further explanations. I am not using systemd, so I can not describe exactly how modules-load.d works. In case you like to use any of the above wording, feel free to use it under the license of the packaging of kmod. I wonder about other kernel modules in other areas of the kernel that may be automatically loaded when connecting some hardware… especially some random USB device, but… that appears to me like opening a huge can of worms. I bet the Linux kernel has more than several hundreds of specialized USB drivers maybe even more than thousand meanwhile despite all the USB standards out there? Linux is not a micro kernel. It was not designed to run drivers in a restricted and (somewhat) safe environment to begin with. That means ideally you'd have to audit all the drivers for security issues regularly or at least after a certain amount of changes made to it. In case you do not, for some random driver it will be difficult to know for sure whether it is safe or unsafe to use. Maybe some small filesystem driver like affs that still receives a patch every now and then is safer to use than the much more complex BTRFS filesystem driver.¹ Who knows? Of cause some fuzzing may really help. But it is not a guarantee either. And then what about other kernel functionally that is loaded as module on demand that is only rarely used by some people? So I wonder what body of evidence there is to base a policy decision on which driver to load or not to load automatically. Without a reliable body of evidence there is always the risk to either over or under policy the users of Debian and derived distributions (whose maintainers do not decide to change such a policy decision again). So I'd argue against taking the quick route on that to allow the time for a more informed decision. Maybe start with clear-cut cases likely probably HFS/HFS+ instead of just adding all kinds of other filesystems without even know whether there is a known exploit. Of course you could go by maintenance status, however, this can be inaccurate. How to do accurately determine maintenance status, especially as MAINTAINERS file may not be accurate or up-to-date at all times? And how many specialized USB drivers are there that are compiled as modules on Debian kernels that may not
Re: HFS/HFS+ are insecure
Le vendredi 21 juillet 2023, 09:49:48 UTC Bastien Roucariès a écrit : > Le vendredi 21 juillet 2023, 08:20:12 UTC Matthew Garrett a écrit : > Hi > > On Thu, Jul 20, 2023 at 07:56:12PM +0200, Marco d'Itri wrote: > > > Package: src:linux > > > Severity: normal > > > > > > You are totally correct. > > > Kernel team, please blacklist HFS/HFS+ for automounting. > > > > Isn't this a userland policy decision? udisks will happily trigger a > > module load for hfsplus if udev has identified it, and I don't think > > there's a trivial mechanism for the kernel to disable that. I believe > > the only way for the kernel to disable automounting would be to disable > > the drivers entirely (which we don't want to do), so this probably needs > > to be assigned elsewhere rather than being a linux bug. > > > > (Or, alternatively, we could move hfs(+) support to FUSE and provide > > extremely tight seccomp policies around them, and then drop kernel > > support, but even though this has been talked about a bunch I haven't > > seen anyone try to implement it) > I vaguely remember that someone implement a fuse over uml (user space linux) > > I used it last time to read in user space some crappy filesystem > > I somebody has better memory than me, it could be an idea Ok found it call mountlo outdated will need a small patch for linux uml, but may be worthwhile Last version seems to be outdated 0.6 and carried by slitaz distribution. May be time to revive it Bastien > Bastien > > > > > > > signature.asc Description: This is a digitally signed message part.
Re: HFS/HFS+ are insecure
On Jul 21, Bastien Roucariès wrote: > Ok found it call mountlo outdated > will need a small patch for linux uml, but may be worthwhile > Last version seems to be outdated 0.6 and carried by slitaz distribution. > May be time to revive it It looks like a good long term solution, but as long as there are insecure file systems in the kernel they should be disabled by default so these are really different issues. I remember noise from the systemd people about mounting removable media using user space drivers, but I do not think that anybody is working on this. -- ciao, Marco signature.asc Description: PGP signature
Re: HFS/HFS+ are insecure
Le vendredi 21 juillet 2023, 09:49:48 UTC Bastien Roucariès a écrit : > Le vendredi 21 juillet 2023, 08:20:12 UTC Matthew Garrett a écrit : > Hi > > On Thu, Jul 20, 2023 at 07:56:12PM +0200, Marco d'Itri wrote: > > > Package: src:linux > > > Severity: normal > > > > > > You are totally correct. > > > Kernel team, please blacklist HFS/HFS+ for automounting. > > > > Isn't this a userland policy decision? udisks will happily trigger a > > module load for hfsplus if udev has identified it, and I don't think > > there's a trivial mechanism for the kernel to disable that. I believe > > the only way for the kernel to disable automounting would be to disable > > the drivers entirely (which we don't want to do), so this probably needs > > to be assigned elsewhere rather than being a linux bug. > > > > (Or, alternatively, we could move hfs(+) support to FUSE and provide > > extremely tight seccomp policies around them, and then drop kernel > > support, but even though this has been talked about a bunch I haven't > > seen anyone try to implement it) > I vaguely remember that someone implement a fuse over uml (user space linux) > > I used it last time to read in user space some crappy filesystem > > I somebody has better memory than me, it could be an idea Found it! I was mountlo > > Bastien > > > > > > >
Re: HFS/HFS+ are insecure
Le vendredi 21 juillet 2023, 10:17:13 UTC Marco d'Itri a écrit : > On Jul 21, Bastien Roucariès wrote: > > > Ok found it call mountlo outdated > > will need a small patch for linux uml, but may be worthwhile > > Last version seems to be outdated 0.6 and carried by slitaz distribution. > > May be time to revive it > It looks like a good long term solution, but as long as there are > insecure file systems in the kernel they should be disabled by default > so these are really different issues. No it is not a long term solution. Long term solution will be to push under fuse these filesystem. This a (short term)/(medium term band aid) solution. I agree with you about disabling these modules linux uml work on i386/amd64/ppc (by memory) so it could help for some filesystem particularly hfs I do not understand why uml is not part of main kernel build maybe it is time to get it. The plan could be: - build uml along the main kernel (if possible) - try to get merged old mountlo kernel support - push to uml only these insecure filesystem - long term try to push these to pure userspace or drop What do you think ? rouca > > I remember noise from the systemd people about mounting removable media > using user space drivers, but I do not think that anybody is working on > this. > > signature.asc Description: This is a digitally signed message part.
Bug#1041610: ITP: iotas -- Simple mobile-friendly note taking application
Package: wnpp Severity: wishlist Owner: Arnaud Ferraris X-Debbugs-Cc: debian-devel@lists.debian.org, aferra...@debian.org * Package name: iotas Version : 0.2.1 Upstream Contact: Chris Heywood * URL : https://gitlab.gnome.org/cheywood/iotas * License : GPL Programming Lang: Python Description : Simple mobile-friendly note-taking application Iotas is a simple note-taking app with mobile-first design and a focus on sync with a Nextcloud Notes. It can be used offline, and optionally sync with Nextcloud when a connection is available. Iotas also provides advanced features such as basic search, categorization of notes, spell checking, Markdown editing and much more. This software uses GTK4 and libadwaita and, as such, is useful both for desktop and mobile users. It is also well integrated with other GNOME applications and is a good complement to other GNOME/GTK-based PIM applications, especially on mobile devices.
Re: HFS/HFS+ are insecure
Le vendredi 21 juillet 2023, 08:55:39 UTC Marco d'Itri a écrit : > efs https://pypi.org/project/qnxmount/ claim to mount it. Check > hfs https://github.com/0x09/hfsfuse > hfaplus https://github.com/0x09/hfsfuse > qnx6 Fuse ro filesystem https://pypi.org/project/qnxmount/ better support then kernel one > sysv no fuse equivalent may be easier to port from (net)?bsd source to fuse or use the method of qnxmount > > affs no fuse equivalent but a grub filesystem may be ported to fuse > ecryptfs no fuse equivalent > jffs2 no fuse equivalent > jfs no fuse equivalent but a grub filesystem may be ported to fuse > > And I think that I can also safely add a few more which while actively > maintained I believe are only used in a retrocomputing context or are > generally uncommon anyway: > > befs A fuse module seems to be avalaible https://www.haiku-os.org/guides/daily-tasks/access_bfs_with_fuse/ > bfs no fuse equivalent > hpfs no fuse > omfs https://github.com/bcopeland/omfs_fuse/ > qnx4 Maybe Fuse ro filesystem https://pypi.org/project/qnxmount/ > reiserfs so incomplete work using grub filesystem https://github.com/albertz/reiserfs-fuse > spu This one is a virtual fs for powerpc should be dropped of the list > ufs https://github.com/mkatiyar/fuse-ufs2 > signature.asc Description: This is a digitally signed message part.
How do you cause a re-run of autopkgtests?
Hi folks, Regarding: https://tracker.debian.org/pkg/groff ...progress of groff into testing is blocked because autopkgtests went bonkers, failing on every architecture. This was due to a change in a groff diagnostic message not getting scraped away by dgit, which was using a regex to match the message text, and employing one of its own man pages as a model document to, I think, validate correct man/groff operation, or man page rendering. Unfortunately the dgit man page in question was defective. I reported the bug with an explanation and patch, and Ian Jackson promptly fixed and uploaded it. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041317 https://tracker.debian.org/news/1446065/accepted-dgit-111-source-into-unstable/ But I see no mechanism for interacting with autopkgtests to force them to re-run due to the remedy of a defect in the test harness itself. How is this to be done? Should some automated mechanism for achieving this be added, and if so, where? Regards, Branden signature.asc Description: PGP signature
Re: HFS/HFS+ are insecure
Le vendredi 21 juillet 2023, 10:52:17 UTC Bastien Roucariès a écrit : > Le vendredi 21 juillet 2023, 08:55:39 UTC Marco d'Itri a écrit : > > efs > https://pypi.org/project/qnxmount/ claim to mount it. Check > > hfs > https://github.com/0x09/hfsfuse Corrected not supported by this package may be emulated by using user space hfs tools ? > > hfaplus > https://github.com/0x09/hfsfuse > > qnx6 > Fuse ro filesystem https://pypi.org/project/qnxmount/ better support then > kernel one > > sysv > no fuse equivalent may be easier to port from (net)?bsd source to fuse or use > the method of qnxmount > > > > affs > no fuse equivalent but a grub filesystem may be ported to fuse > > ecryptfs > no fuse equivalent > > jffs2 > no fuse equivalent > > jfs > no fuse equivalent but a grub filesystem may be ported to fuse > > > > And I think that I can also safely add a few more which while actively > > maintained I believe are only used in a retrocomputing context or are > > generally uncommon anyway: > > > > befs > A fuse module seems to be avalaible > https://www.haiku-os.org/guides/daily-tasks/access_bfs_with_fuse/ > > bfs > no fuse equivalent > > hpfs > no fuse > > omfs > https://github.com/bcopeland/omfs_fuse/ > > qnx4 > Maybe Fuse ro filesystem https://pypi.org/project/qnxmount/ > > reiserfs > so incomplete work using grub filesystem > https://github.com/albertz/reiserfs-fuse > > spu > This one is a virtual fs for powerpc should be dropped of the list > > ufs > https://github.com/mkatiyar/fuse-ufs2 > > > > signature.asc Description: This is a digitally signed message part.
Re: HFS/HFS+ are insecure
Le vendredi 21 juillet 2023, 10:28:00 UTC Bastien Roucariès a écrit : > Le vendredi 21 juillet 2023, 10:17:13 UTC Marco d'Itri a écrit : > > On Jul 21, Bastien Roucariès wrote: > > > > > Ok found it call mountlo outdated > > > will need a small patch for linux uml, but may be worthwhile > > > Last version seems to be outdated 0.6 and carried by slitaz distribution. > > > May be time to revive it > > It looks like a good long term solution, but as long as there are > > insecure file systems in the kernel they should be disabled by default > > so these are really different issues. > > No it is not a long term solution. Long term solution will be to push under > fuse these filesystem. This a (short term)/(medium term band aid) solution. > > I agree with you about disabling these modules > > linux uml work on i386/amd64/ppc (by memory) so it could help for some > filesystem particularly hfs > > I do not understand why uml is not part of main kernel build maybe it is time > to get it. > > The plan could be: > - build uml along the main kernel (if possible) > - try to get merged old mountlo kernel support > - push to uml only these insecure filesystem > - long term try to push these to pure userspace or drop According to the other thread only these fs should be supported using this method: - hfs (not hfs+) but pure user space tools exist -sysv -affs -ecryptfs - jffs2 - jfs - bfs - reiserfs Rouca > > What do you think ? > > rouca > > > > > I remember noise from the systemd people about mounting removable media > > using user space drivers, but I do not think that anybody is working on > > this. > > > > > > signature.asc Description: This is a digitally signed message part.
Re: How do you cause a re-run of autopkgtests?
On 7/21/23 12:57, G. Branden Robinson wrote: Hi folks, But I see no mechanism for interacting with autopkgtests to force them to re-run due to the remedy of a defect in the test harness itself. How is this to be done? you mean, apart from clicking on the ♻ retry icon? (you probably have to be authenticated in order to even see these icons) Should some automated mechanism for achieving this be added, and if so, where? https://ci.debian.net/api/doc mgfdsar IOhannes
Re: How do you cause a re-run of autopkgtests?
At 2023-07-21T13:43:05+0200, IOhannes m zmölnig (Debian/GNU) wrote: > On 7/21/23 12:57, G. Branden Robinson wrote: > > Hi folks, > > > > But I see no mechanism for interacting with autopkgtests to force > > them to re-run due to the remedy of a defect in the test harness > > itself. > > > > How is this to be done? > > you mean, apart from clicking on the ♻ retry icon? Oh, _that's_ what that means! It had no tooltip, but if I peer at the URL preview it does say "retry", so I must confess blindness as well as ignorance. > (you probably have to be authenticated in order to even see these > icons) I don't have to be authed to _see_ it, but if I click on it, a login is demanded of me. Fair enough (robot/DoS defense). > > Should some automated mechanism for achieving this be added, and if > > so, where? > > https://ci.debian.net/api/doc As a bear of little brain, I can indeed infer from this that a mechanism for prompting retry exists. Thanks for the pointers! Regards, Branden signature.asc Description: PGP signature
Re: How do you cause a re-run of autopkgtests?
On Fri, Jul 21, 2023 at 05:57:23AM -0500, G. Branden Robinson wrote: > But I see no mechanism for interacting with autopkgtests to force them > to re-run due to the remedy of a defect in the test harness itself. > > How is this to be done? Should some automated mechanism for achieving > this be added, and if so, where? You already found the retry button from previous replies, but you don't have to click it to get what you want… See how migrating groff/1.23.0-2 to testing was tested (and failed) every day without you lifting a finger? https://ci.debian.net/packages/d/dgit/testing/amd64/ Triggering a rerun now would be pointless as (a fixed) dgit needs to migrate first before groff can… which should be around ~tomorrow. After all, groff can only migrate if importing it into testing isn't causing a regression and it does as long as a bad dgit is in testing. I guess the day after ~tomorrow groff will migrate as well – assuming dgit was really your only problem. Best regards David Kalnischkies signature.asc Description: PGP signature
Re: How do you cause a re-run of autopkgtests?
Hi, On 21-07-2023 14:20, David Kalnischkies wrote: How is this to be done? Should some automated mechanism for achieving this be added, and if so, where? You already found the retry button from previous replies, but you don't have to click it to get what you want… The migration software of the release team retries failures after 24 hours. Configuration specifying the retry age lives here: [1]. Paul [1] https://salsa.debian.org/release-team/britney2/-/blob/master/etc/britney.conf#L103 OpenPGP_signature Description: OpenPGP digital signature
Re: /usr-merge: continuous archive analysis
Hi, TL;DR: dpkg-statoverride detection cannot be automated, but there are only 5 affected packages. On Wed, Jul 12, 2023 at 03:34:38PM +0200, Helmut Grohne wrote: > * DEP17-P5: dpkg-statoverrides not matching the files shipped. >Possibly, I can extend dumat to cover unconditional statoverrides. In retrospect, this feels like a lie. As usual, the story is more complex than it initially seems. A really big chunk of users just queries a path for a (local) override. We cannot capture these by looking how a chroot was modified during maintainer scripts. Another significant chunk is conditional statoverrides that depend on either debconf answers or failure to apply filesystem capabilities. Observing the intended outcome in these cases is next to impossible. Actually parsing shell scripts and extracting those calls is what I tried for diversions first, but that runs afoul variable interpolation and the halting problem before too long. So really, I don't see a good way to implement the promised detection without a high error rate. Then on the flip side, there's about 1500 maintainer scripts matching dpkg-statoverride found by binarycontrol.d.n. Since most have postinst and prerm and most are in all suites, that's about 250 packages. Of these, the vast majority only ever deals with canonical paths or paths unaffected by the /usr-merge. Checking all of these manually as a one-shot effort definitely sounds more plausible to me. To validate this claim (after having made a wrong one), I actually performed the analysis for unstable and found only five affected packages. I intend to move this forward by supplying the necessary patches. Changes needed: * fuse (queries only, can be duplicated now) * fuse3 (queries only, can be duplicated now) * ntfs-3g (queries only, can be duplicated now) * systemd-cron (needs to be updated when moving files) * yp-tools (needs to be updated when moving files) Nontrivially unaffected: * nfs-common (removes an aliased statoverride) Unaffected: * activemq * amavisd-new * apt-cacher-ng * asterisk * asterisk-config * autofs-ldap * ax25-apps * backuppc * balboa * biboumi * bird * bird2 * boinc-client * boxbackup-server * bucardo * ca-certificates * cado * ceph-base * ceph-common * ceph-mds * ceph-mgr * chrony * clamav-unofficial-sigs * cockpit-ws * corekeeper * coturn * courier-authdaemon * courier-authlib-ldap * courier-authlib-mysql * courier-authlib-postgresql * courier-base * courier-faxmail * courier-imap * courier-ldap * courier-mta * courier-pop * courier-webadmin * cron * cron-daemon-common * cubemap * cups * cups-daemon * cups-tea4cups * cups-x2go * cw * cyrus-common * davfs2 * davmail-server * dbus * deluged * dodgindiamond2 * dokuwiki * dovecot-core * durep * ejabberd * eviacam * exim4-base * exim4-config * fdutils * ferm * forked-daapd * fping * gammu-smsd * ganglia-monitor * ganglia-webfrontend * geki2 * geki3 * geoclue-2.0 * gerbera * glhack * gmetad * gnokii-cli * gnunet * graphite-api * graphite-carbon * graphite-web * gravitywars * groonga-httpd * groonga-server-common * gvmd * gweled * h2o * haserl * hplip * i2p * icinga2-common * icingadb * icingaweb2-common * ilisp * im * inadyn * incron * john * json2file-go * kea-common * kgb-bot * kismet * knot * libvirt-daemon-system * libx2go-server-db-perl * libzeroc-ice3.7 * lldpd * lmarbles * logdata-anomaly-miner * login-duo * lprng * lyskom-server * man-db * mandos * mandos-client * matrix-sydent * matrix-synapse * mgetty-fax * milter-greylist * minidlna * mlocate * mon * monsterz * mpd * mpd-sima * mpdscribble * muse * nagios4-cgi * nagios4-common * nagvis * nbsdgames * netdata-core * nethack-common * netselect * nginx-common * notus-scanner * nsca-ng-server * nsd * onak * open-infrastructure-compute-tools * opendkim * opendmarc * opendnssec-common * opensmtpd * openssh-client * opentracker * openvas-scanner * pacemaker-common * pawserv * pconsole * pdns-ixfrdist * phog * php-common * phpmyadmin * pkexec * plocate * pmount * polkitd * polkitd-pkla * postfix * powermanga * prayer * prometheus * prometheus-alertmanager * prometheus-apache-exporter * prometheus-bind-exporter * prometheus-blackbox-exporter * prometheus-haproxy-exporter * prometheus-ipmi-exporter * prometheus-mysqld-exporter * prometheus-node-exporter * prometheus-postfix-exporter * prometheus-postgres-exporter * prometheus-process-exporter * prometheus-pushgateway * prometheus-redis-exporter * prometheus-smokeping-prober * prosody * puppet-agent * puppetdb * puppetserver * pure-ftpd-common * pyracerz * qpsmtpd * radosgw * radvd * redis-sentinel * redis-server * redis-tools * roundcube-core * rtpengine-daemon * rtpengine-recording-daemon * samba-common * sasl2-bin * sendmail-bin * shibboleth-sp-utils * smstools * smtpprox-loopprevent * snort * softhsm2-common
Bug#1041643: ITP: ktls-utils -- TLS handshake utilities for in-kernel TLS consumers
Package: wnpp Severity: wishlist Owner: Ben Hutchings X-Debbugs-Cc: debian-devel@lists.debian.org, debian-ker...@lists.debian.org, Steve Dickson , Chuck Lever III * Package name: ktls-utils Version : 0.9 Upstream Contact: kernel-tls-handsh...@lists.linux.dev * URL : https://github.com/oracle/ktls-utils * License : GPLv2 Programming Lang: C Description : TLS handshake utilities for in-kernel TLS consumers In-kernel TLS consumers need a mechanism to perform TLS handshakes on a connected socket to negotiate TLS session parameters that can then be programmed into the kernel's TLS record protocol engine. This package of software provides a TLS handshake user agent that listens for kernel requests and then materializes a user space socket endpoint on which to perform these handshakes. The resulting negotiated session parameters are passed back to the kernel via standard kTLS socket options. This will be maintained by the kernel team.
Re: HFS/HFS+ are insecure
On Fri, Jul 21, 2023 at 10:55:39AM +0200, Marco d'Itri wrote:
> Unless somebody has a better idea then then my plan is to ship in the
> next upload of kmod a file in /etc/modprobe.d/ which uses the blacklist
> directive to prevent automatically loading some file system modules.
I think this would break any existing fstab entries that reference hfs
and hfsplus, and the convenient way to integrate Linux boot with x86
Macs is certainly to have an hfsplus EFI partition so this may be a
legitimate use-case. It also means that anyone who has a need to use one
of these filesystems in a static manner is vulnerable to automount
attacks using them.
Completely untested, but I think something along the lines of:
SUBSYSTEM!="block", GOTO="udisks_insecure_fs_end"
ENV{ID_FS_TYPE}=="hfs", ENV{UDISKS_AUTO}="0"
ENV{ID_FS_TYPE}=="hfsplus", ENV{UDISKS_AUTO}="0"
LABEL="udisks_insecure_fs_end"
in a udev fragment should work? Any static fstab or mount units should
still work, but it should disable udisks automounting regardless of the
desktop agent involved, even if the fs modules are already loaded.
Bug#1041668: ITP: hintview -- Program to view HINT files
Package: wnpp Severity: wishlist Owner: Hilmar Preusse X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: hintview Version : 1.3.1 Upstream Contact: Martin Ruckert * URL : https://hint.userweb.mwn.de/ * License : MIT/X Programming Lang: C Description : Program to view HINT files The HINT file format is an alternative to the DVI or PDF format that was designed specifically for on screen reading of documents. Especially on mobile devices, reading DVI or PDF documents can be cumbersome. . Mobile devices are available in a large variety of sizes but are typically not large enough to display documents formated for letter-size paper. To compensate for the limitations of a small screen, users are used to alternate between landscape (few long lines) and portrait (more short lines) mode. The HINT format supports variable and varying screen sizes leveraging the ability of TEX to format a document for (almost) arbitrary values of \hsize and \vsize. Why and how to maintain the package: - Currently the hitex program is included in Debian and one can create hint files. Hence it is highly useful to have a program, to display these kind of files. - I'm a member of the Debian TeX Task force and I'll maintain in the team. I'm a DM, once I got the upload permits I can care of the package myself. -- sigmentation fault signature.asc Description: PGP signature
Re: HFS/HFS+ are insecure
On Fri, Jul 21, 2023 at 09:49:48AM +, Bastien Roucariès wrote: > I vaguely remember that someone implement a fuse over uml (user space linux) A similar tool is libguestfs's guestmount tool: https://www.libguestfs.org/guestfs-faq.1.html#why-don-t-you-do-everything-through-the-fuse-filesystem-interface https://www.libguestfs.org/guestmount.1.html Thanks signature.asc Description: PGP signature
Re: 64-bit time_t: an update
On Thu, Jul 20, 2023 at 12:30:50AM +0100, Simon McVittie wrote: > On Wed, 19 Jul 2023 at 14:27:21 -0700, Steve Langasek wrote: > > to understand the impact that a change to the size of > > time_t will have on a library's ABI, it must be possible to compile the > > headers that expose that API > Would the results of this analysis also be suitable for telling > interested maintainers whether it's safe to opt-in a library to LFS > and/or 64-bit time_t on i386, so that it will use 64-bit-time_t-safe > glibc functions internally? > (For example libdbus is already opted-in to LFS, and I'm reasonably > sure it doesn't break public ABI under 64-bit time_t either, because it > has a policy of avoiding most inclusions of system headers in its own > public API) Yes, there's sufficient information in the analysis to determine this. > > The Ubuntu Foundations team have been putting in effort over the past two > > months, package-by-package, to figure out how to make them compile so that > > we know if their ABI is affected. > Is there a reasonably simple way that interested developers can try this > process for a package that they maintain? Thanks for the PR[0] :) > I realise your analysis has been done on armhf, but i386 would probably be > an easier (and faster!) 32-bit architecture to deal with for many > developers, even though we don't intend to do the 64-bit time_t transition > systematically on i386. Yes, for individual package analysis in Debian, i386 is likely better. If we're not actually doing 64-bit time_t for i386, it's better to use armhf for the list of -dev packages to analyze - second to i386, it's going to have the highest number of arch-specific -dev packages of any 32-bit arch. And in Ubuntu of course, we've already dropped the vast majority of these packages on i386 so there's nothing to analyze against. But in Debian, given a list of -dev packages that are applicable to armhf, it's almost certainly faster for folks to do the analysis against i386. > > The "good" news is that, although there are over 1500 -dev packages yet to > > be analyzed, we have prioritized libraries based on the number of > > reverse-dependencies > Is the list you attached already in descending order by number of rdeps? It was not. I've attached that list now. (And eventually I'll dd-list-ify it if there's agreement on this path forward.) > > libsdl1.2-compat-dev > The source package src:sdl12-compat recently took over libsdl1.2-dev > and libsdl1.2debian from the older src:libsdl1.2, which gives it quite > a lot of rdeps (I know because I did a mass bug filing for them!), > so having an answer for that one might reduce the rebuilds better than > you might think. I suspect it actually won't have time_t in its ABI, > although I could be wrong. Thanks. I didn't mention, but there are definitely some false-negatives in this list, because of e.g. all of the packages actually build-depend on a metapackage -dev which doesn't actually contain the headers. libboost-dev is an example, which is prominent enough that we noticed it and manually prioritized it. I'll have a look at sdl as well for sure. It would probably give us a more precise count if, instead of looking at reverse-build-deps on associated -dev packages, we scanned the archive for all packages shipping .shlibs and/or .symbols files and then looked at reverse-dependencies of the packages named in those control files. That would take rather a bit more effort however since it would involve unpacking the whole archive, and it doesn't matter for the actual transition which will be based on binary package revdeps regardless, it only matters for the question of prioritizing fails-to-compile headers for analysis. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org [0] https://salsa.debian.org/vorlon/armhf-time_t/-/merge_requests/96 7 qtwayland5-private-dev 4 libogre-1.12-dev 4 android-libbase-dev 3 tcl-itcl4-dev 3 libplacebo-dev 3 libosp-dev 3 libopenvdb-dev 3 libkpipewire-dev 3 libini-config-dev 3 libgom-1.0-dev 3 libgnome-bluetooth-dev 3 libgirara-dev 3 libflatbuffers-dev 3 libfftw3-mpi-dev 3 libfcft-dev 3 libdrilbo-dev 3 libdpkg-dev 3 libcec-dev 3 libccp4-dev 3 libc-client2007e-dev 3 libapogee-dev 3 libapache2-mod-perl2-dev 3 libagg2-dev 3 libafflib-dev 3 libadplug-dev 3 iraf-noao-dev 3 guile-2.2-dev 3 gemmi-dev 3 coinor-libcbc-dev 3 casacore-dev 3 android-libziparchive-dev 3 android-libcutils-dev 3 ableton-link-dev 2 xserver-xorg-input-synaptics-dev 2 tao-json-dev 2 signond-dev 2 sfftw-dev 2 samba-dev 2 retroarch-dev 2 qttools5-private-dev 2 python3-cxx-dev 2 pinball-dev 2 pd-flext-dev 2 opencollada-dev 2 ofono-dev 2 nim-hts-dev 2 moarvm-dev 2 mirtest-dev 2 llvm-16-dev 2 libxorg-gtest-dev 2 libxlsxwriter-
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Tue, Jul 11, 2023 at 03:06:57PM -0600, Sam Hartman wrote: > However, there are some significant disadvantages to netplan: > 1) It's an extra layer. You can ignore it when reading the config (at > least if you aren't too surprised by your config ending up in /run). > But it is extra complexity, especially in a situation like " run dhcp on > my ethernet" that is relatively simple. > 2) It's a layer that you cannot ignore when editing the config. Netplan > is one way. It takes in config in its format and spews out either > NetworkManager config or systemd-networkd config. You can generate > extra config on top of what netplan does, but in my experience if you > want to edit the config that netplan controls, you need to either do it > through netplan or remove netplan and generate those config chunks by > hand (possibly after looking at how netplan did it). > It's possible there are some netplan modes I missed and some other ways > of doing things. It's also possible netplan has evolved since I looked > at it. > In the non-wifi case I think d-i's networking is too simple to justify > netplan. > A simple .network unit for systemd-networkd sounds like a better option. I am not unbiased here, but I'd like to offer a counterargument: to a user, there is value in consistency. Yes, netplan is an additional layer. But having a layer that a user can rely on being present on any Debian system, whether it's a cloud instance, a server, or a desktop install with wifi, can be a big help. As someone who learned what a netmask is in 1997 or earlier, I have been surprised to learn over the course of netplan's development just how many people configuring networks on Linux systems - including on servers and routers - don't actually know thing #1 about IPv4 and are trying to configure their networks based on the recipes they find on the Internet. Which also means their lives are made significantly easier when the recipes they find are more broadly applicable across different types of installs, and significantly harder if they have to separately search how to configure networking for clouds, servers, or desktops. The design goal of netplan is that it's a layer that you shouldn't have to peek underneath, because it exposes everything you would need to configure in networkd or NetworkManager. Granted it's not *completely* there yet, but with the work to make NetworkManager use netplan as its config backend (which means: in the next release of Ubuntu you can happily use nmcli, nm-applet, etc. to manage your network connections and get human-editable netplan files out), it's certainly close. And I can say that I am a happy user of netplan across multiple systems, with no need to manage networkd configuration directly. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Bug#1041684: ITP: not-ocamlfind -- front-end to ocamlfind to add a few new commands
Package: wnpp Severity: wishlist Owner: Stéphane Glondu X-Debbugs-Cc: debian-devel@lists.debian.org, debian-ocaml-ma...@lists.debian.org * Package name: not-ocamlfind Version : 0.10 Upstream Contact: Chet Murthy * URL : https://github.com/chetmurthy/not-ocamlfind * License : MIT Programming Lang: OCaml Description : front-end to ocamlfind to add a few new commands The command not-ocamlfind is a pass-thru to ocamlfind, but adds three new commands: preprocess, reinstall-if-diff and package-graph. This package is a new dependency of camlp5. It will be maintained in the OCaml team.
