You are not logged in.
That's the wrong page. When you search for firefox-esr you will see:
102.9.0esr-2
http://deb.devuan.org/merged ceres/main amd64
http://deb.devuan.org/merged daedalus/main amd64
102.9.0esr-1~deb11u1
http://deb.devuan.org/merged chimaera-security/main amd64
http://deb.devuan.org/merged chimaera-proposed-updates/main amd64
102.9.0esr-1~deb10u1
http://deb.devuan.org/merged beowulf-security/main amd64
91.13.0esr-1~deb11u1
http://deb.devuan.org/merged chimaera/main amd64
...
i.e if you have v91 you're only using chimaera repo, without chimaera-security repo enabled.
According to this page, chimaera-security should be enabled by default, so perhaps it was inadvertently deselected at some point?
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.
There was a topic called "Devuan: Existential issues." where a person had legitimate issues but was met with unfriendly responses.
It looks like they raised legitimate issues in XFCE, but blamed Devuan for those issues, and had a generally poor attitude.
I was surprised there is no way to change your password or add and remove new users and groups.
You should report this at https://bugzilla.xfce.org
The "Users and Groups" program has a setting called "Don't ask for password on login" but it's not functional.
The place to report this one would be https://github.com/LStranger/gnome-system-tools
I had issues with package managers accepting the .iso as a source for packages.
Did you try mounting it first?
mount -o loop,ro -t iso9660 '/some/path/devuan_chimaera_4.0.0_amd64_desktop.iso' /media/cdrom
After that, you probably just need to uncomment the existing "cdrom" entry in sources.list (or add one if it doesn't exist), including the allow-insecure option, something like:
deb [ allow-insecure=yes ] cdrom:[Devuan GNU/Linux 4.0 chimaera amd64 - desktop 20211012]/ chimaera main
No need to extract files from the ISO or worry about filenames (usual shell quoting rules apply for the mount command).
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).
All those "won't fix because it is harmless" issues, warnings and/or bug reports which end up being swept under the rug will are not healthy.
I see it as lousy coding and may (eventually) end up causing issues somewhere in the system.
Yep, just because there's no obvious harm at the moment doesn't mean there isn't some hidden/future problem.
-
I've just remembered inotify, which can monitor filesystem use - so inotifywait --daemon -e create / should log when a directory is created in root, and inotifywait --daemon -r /.cache will monitor all events within that directory, to see if it's being used - although it doesn't look like inotifywait reports pid/uid information, so the first one probably isn't useful, but if files are being created/removed the names may give a clue as to what it is doing it.
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.
Ok, so after a bunch of faff dealing with dbus's convoluted build process, I get it to output a dbus-launch binary.
Then I update the start of get_homedir in dbus-launch-x11.c to do:
home = getenv ("DBUS_HOME");
if ( home != null )
return home;
Swap the executables over (because some things use absolute path):
mv /usr/bin/dbus-launch{,.orig}
cp /path/to/custom/dbus-launch /usr/local/bin/dbus-launch
cd /usr/bin && ln -vsiT /usr/local/bin/dbus-launch dbus-launch
And finally, reset /etc/X11/Xsession.d/75dbus_dbus-launch to default, before adding:
DBUS_HOME="$XDG_RUNTIME_DIR"
export DBUS_HOME
And now I don't get .dbus in my home directory, because it creates /run/user/1000/.dbus instead.
It is going to mean re-patching each time a relevant D-Bus release happens, but looks like there was only one security update with Chimaera so hopefully wont be too common.
-
One other change I made was to /etc/X11/Xsession.d/95dbus_update-activation-env - removing the --systemd argument stops a pointless warning being output to xsession-errors.
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.
Ok, so I reverted all previous changes, then modified /etc/X11/Xsession.d/75dbus_dbus-launch with:
if [ -n "$XDG_RUNTIME_DIR "]; then
SESSION_CONF="/usr/share/dbus-1/session.conf"
USER_CONF="$XDG_RUNTIME_DIR/dbus_user_session.conf"
sed -r 's|<listen>[^<]+|<listen>unix:path='"$XDG_RUNTIME_DIR"'/bus|' "$SESSION_CONF" > "$USER_CONF"
eval $($DBUSLAUNCH --exit-with-session --sh-syntax --config-file="$USER_CONF")
else
eval $($DBUSLAUNCH --exit-with-session --sh-syntax)
fi
This creates the socket at /run/user/1000/bus and results in the expected single DBUS_SESSION_BUS_ADDRESS, but is still re-creating the ~/.dbus directory. :@
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:
However, please note that you do need to write a considerable amount of code to write a replacement launcher and integrate the broker into your alternative system.
If you have a particular question regarding implementing a launcher, please feel free to contact us with further questions! But we do not intend to work on such replacements ourself.
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.
Ok, so setting DBUS_SESSION_BUS_ADDRESS isn't the answer - that seems to be more of an informational variable and flag of whether the daemon is already running.
What I think I need to do is duplicate the whole /usr/share/dbus-1/session.conf file, edit the address, then modify /etc/X11/Xsession.d/75dbus_dbus-launch to pass --config-file=FILENAME to dbus-launch which should start the dbus-daemon with that config file only, and thus a single address.
Of course, since the D-Bus config files don't appear to support variables, it'll probably also require a mechanism to create a new config file per user.
Anyway, it's too late to try all that now, so I'll test it out tomorrow.
Tempting to just ditch Mousepad instead, but no doubt some other package is going to depend on dconf/dbus-x11 and have the same issue.
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:
Add an address that the bus should listen on
...
If there are multiple <listen> elements, then the bus listens on multiple addresses.
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.
Installing Mousepad text editor resulted in a .dbus directory being added to my home directory.
This seems to be the fault of dbus-x11 which on Devuan is the only provider for "dbus-session-bus" (required by dconf, one of Mousepad's dependencies), and based on a 2011 dbus bug report I think I need to ensure DBUS_SESSION_BUS_ADDRESS is set correctly - specifically to unix:path=$XDG_RUNTIME_DIR/bus by a file in /etc/X11/Xsession.d/
I tried using 20dbus_xdg-runtime config file (from Debian's dbus-user-session package), but that fails because of [ -S "$XDG_RUNTIME_DIR/bus" ], (where "-S" checks that a file is a socket), but there is no such file/socket.
XDG_RUNTIME_DIR is set at login (to /run/user/1000), and is used by other things - there's even a dbus-1 directory in it, so if I can get the socket created I suspect the Debian config script will work.
But my searches are failing to reveal what is supposed to be creating the bus socket...?
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...
No mention in this thread of other packages that come from PulseAudio's source package, e.g. libpulse0, pulseaudio-utils, and others.
Blocking/pinning pulseaudio* and libpulse* would handle them all, but there appears to be a lot of software that depends on libpulse0 package... :/
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.
Safe from who?
If your root filesystem is unencrypted, someone with physical access can read and modify files, and thus manually install whatever they like - including a script to rsync your home partition to a remote server after you've unlocked it.
If you read the OP, you'll notice that there are no home directories involved at all
Ah yeah, I misread the / as ~/
so XDG_HOME_WHATEVER has nothing to do with anything.
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.
Is this a Devuan issue or Debian?
Neither.
It's part of the XDG Base Directory Specification - a bit like the FHS but for user-specific application data.
(It's far from a new thing - Wayback Machine says 2010 for v0.6 - so a little odd you've not noticed it until now.)
The idea is, instead of having a million dotfiles polluting your home directory, you get (by default) three top-level dirs in $HOME (.config, .cache, and .local, each of which you can choose to relocate with environment variables), and within which applications place appropriate config/cache/etc. Makes it easy to backup configuration without also carrying around cache or history or whatever.
More info on Arch wiki's XDG Base Directory page - including the depressingly long list of applications who's developers refuse to support it. :(
-
However, there may be a bug with PulseAudio, because f3270dcda2b340e98a9808d3dcb611c5-runtime -> /tmp/pulse-PKdhtXMmr18n does not look like config, and should probably be using either $XDG_STATE_HOME or $XDG_RUNTIME_DIR instead.
Pay more attention to the output:
The following additional packages will be installed:
attr fuse3 ibverbs-providers libcephfs2 libfuse3-3 libgfapi0 libgfrpc0
libgfxdr0 libglusterfs0 libibverbs1 librados2 librdmacm1 liburing1
python3-samba python3-tdb samba-common samba-common-bin samba-dsdb-modules
samba-vfs-modules tdb-tools
It is removing fuse because it is installing fuse3 to replace it.
Goto pkginfo.devuan.org and search for the appropriate package, then select the deb download link next to "Filename".
You can then try to install the deb with dpkg --install FILENAME, if you can't boot or dpkg doesn't work, you can manually copy the appropriate file into the right location - you can get the file by opening the deb with any archive tool that supports "ar" format, then looking inside data.tar for the relevant file. (If you're using a Live USB to do this, make sure you've mounted the appropriate filesystem in a suitable location, and are not copying into the Live OS's filesystem.)
Also worth pointing out that, if you didn't also know the package name (e.g. if apt-file isn't installed or dpkg-query -S FILENAME fails), pkginfo.devuan.org allows search by file by changing "Package pattern" to "File pattern" - despite looking like text it is a drop-down.
Looks like systemd-nspawn is a wrapper around the kernel namespaces feature.
Linux namespaces do NOT require systemd to use.
However, today *none* of the files contain '3040s', which is why in the abbreviated results (there are *far* more records after the last one above) I used 'amazon' as the search term.
Ok, so you've not determined those files are related to the search results HTML response, and they may well be other things - scripts, styles, images, etc.
Unless the files are encrypted, a failure to find "3040s" probably means they have since expired and been removed (especially if it was returning results earlier).
Have you looked at any of the files to determine contents?
Try replacing the ls command for file (perhaps with -z), and then grep the results for "HTML" or "text"?