It still kinda works sometimes, though I've no idea what decides when it does or not:

devuan = top four results: devuan.org, wikipedia.org, distrowatch.com, techradar.com
devuan -wikipedia = no wikipedia.org on first page, but distrowatch (which references wikipedia) is 6th
devuan -distrowatch = distrowatch.com promoted to 1st result instead of being removed
devuan -techradar = no techradar.com on first page

-

One way around it would be to write ones own search engine - a lot of times I'm searching it's for specific documentation, and what I'm trying to exclude is non-technical sites and useless crap from Stack Overflow, Quora, etc - so being able to search a specific set of curated sites would be far more useful results than any web-wide search engine.

I have no interest in watching a video.

A malicious PDF means a vulnerability in whatever displays the PDFs - a quick search suggests they were running Google Chrome and/or Microsoft Edge, both of which come with PDF reader embedded.

*shrug*

Since "depends" is the technical term that the package manager uses, it can't not be a right word, even if there might also be other more descriptive ones.

*shrug*

Whatever it's called, it would be nice to have a generalized list of packages to avoid, (along with reasons why, how, what the alternatives are, etc).

So what is result of...

echo "home=$HOME;config=$XDG_CONFIG_HOME;cache=$XDG_CACHE_HOME;"

...when running as root?

Or I guess:

awk -F: '$6~"^/?$"' /etc/passwd

?

Also, have you identified precisely when during boot it gets re-created? i.e. use stat to get the precise time, and compare with files in /var/log to see what happens around the same time.

So the bus address stuff has been a red-herring - that actually gets placed inside the .dbus/session-bus/{uuid} files.

Looking at the relevant source code (dbus-launch-x11.c), it is hard-coded to create .dbus directly in the home directory, with no conditional "place it elsewhere if X" logic.

So basically everything I did yesterday and today was a waste of time, all because of another useless idiot from Red Hat.

Yeah, XDG_RUNTIME_DIR defaults to within /run which is tmpfs, so would solve that.

D-Bus certainly seems to be a convoluted and inflexible mess, for something that should be simple.

There is a different implementation, dbus-broker, which doesn't write to disk at all, however it has a systemd dependency for the launcher part - they're open to alternative launchers, but aren't going to do it themselves:

The current launcher looks to be ~4k non-blank lines across 14 files of C - dunno how much is re-usable: https://github.com/bus1/dbus-broker/tre … src/launch

#270 remove dependency on libsystemd?
#256 Support for other init systems (s6 and runit)
#183 [question] Run dbus-broker without systemd running

-

Anyway, I'll go have lunch then see if I can configure the stupid thing to behave.

So I managed to work out that the socket is created by dbus-daemon which is configured by /usr/share/dbus-1/session.conf, and can be overridden by /etc/dbus-1/session.d/* or /etc/dbus-1/session-local.conf

So creating a config file like so...

egrep -zo '<!DOCTYPE[^>]+>' /usr/share/dbus-1/session.conf > /etc/dbus-1/session-local.conf
echo '
<busconfig>
<listen>unix:path=/run/user/1000/bus</listen>
</busconfig>' >> /etc/dbus-1/session-local.conf

...then logging out all user sessions and back in again.

Now the bus socket is being created, but it's still re-creating the $HOME/.dbus directory too. :@

Checking xsession-errors shows DBUS_SESSION_BUS_ADDRESS has two values, and paying closer attention to the relevant part of the documentation:

FFS!

So I think I need to supply an --address param instead, which I thought was /etc/init.d/dbus and /etc/defaults/dbus but that's the system-wide one, not the per-session one, and I'm out of time for now so I'll try and figure out where that happens later.

It took me a few reads of your message to see that you mentioned cockpit-ws - the part of FreedomBox which is the problem. That information should be more obvious, along with some relevant links for those unfamiliar.

FreedomBox (a home server kit from Eben Moglen that packages a bunch of web-focused software running on Debian), uses the Cockpit server administration tool, which heavily uses systemd - not surprising given it is sponsored by RedHat.

Given that, fixing Cockpit not to use systemd is unlikely to be a viable path - which means providing an alternative.

Does FreedomBox entirely rely on Cockpit? i.e. if one satisfies dependencies with a dummy cockpit package does it fail, or does FreedomBox still install and run, merely without the HTTP based login part?

If the latter, it shouldn't be too difficult to build an alternative login option - the hard part may be convincing the freedombox package maintainers to accept the alternative dependency.

However, if FreedomBox is too tightly coupled to Cockpit, then it probably involves a fair bit more time and effort...

Firstly, an attacker with physical access doesn't need viruses. (A virus is only one type of malware; they may or not use other malware.)

Second, rationalizing that a "normal user" wouldn't look in system folders is the wrong attitude - if that's the limit of your threat level, a simple password would be enough. (Similarly "advanced attacker" or "common attacker" don't mean much - anyone capable of producing a Live USB is already sufficiently advanced to be a potential concern. What matters more is motivation and opportunity.)

-

Theoretically, a determined adversary with enough time and money can break or bypass any security measures you put in place.

You want "enough" to be sufficiently higher than is available to those who want to access your data - which brings it back to the question of who you're trying to be safe from. Why is someone after your data? What opportunities do they have? Do they care about being detected?

If you can't define the threat, how do you know when you've done enough? Security is always a trade-off against usability, so you've got to decide where to draw the line.

-

Your original concern referenced performance, but I'm guessing you don't have the fastest machine available, so it will always be running "slower than it could be" - that isn't a meaningful metric.

If it's too slow that is when you first decide if you can upgrade hardware to resolve that, or if you can install more efficient software, or change the configuration of existing software, etc. If none of that helps, then decide whether the security gained by encryption is worth the cost in reduced usability.

Ah yeah, I misread the / as ~/

It may still be relevant, because their default value is usually $HOME/.config - so if $HOME is not set for root user (from then perspective of pulseaudio or wherever XDG_CONFIG_HOME is being set), and no safety checks are made for that situation, then the result would be those directories being created in the wrong location.

So could still be a bug in pulseaudio, or possibly a mis-configuration.

Pay more attention to the output:

It is removing fuse because it is installing fuse3 to replace it.

Looks like systemd-nspawn is a wrapper around the kernel namespaces feature.

Linux namespaces do NOT require systemd to use.