Posts by steve_v

steve_v · Desktop and Multimedia

Fun fact, synaptic (2001) predates the introduction of the 'apt' command (2014). Also: mouse? where? *meow* I see no mouse (any more).

steve_v · Desktop and Multimedia

Sure:

root@apollo-slink:~# apt install apt-transport-https
bash: apt: command not found

'apt-get' does exist, but as it's name implies it only works when "getting" packages from the repositories.

steve_v · Desktop and Multimedia

aluma wrote:

This is not a new technology, it’s just not documented anywhere. I started installing packages this way many years ago when I switched to Debian.

Well it doesn't work on my Slink box, therefore it doesn't exist

steve_v · Desktop and Multimedia

aluma wrote:

Or I'm wrong?

Yes. The wget and apt commands share CWD, so an intervening 'cd' is redundant unless you explicitly tell wget to drop the file somewhere else.

Also what fsmithred said. Installing from a local file with apt is relatively new and may not be available everywhere. Dpkg will be.

steve_v · Off-topic

bilhook wrote:

where the settings are stored

about:config, or about:support -> Profile Directory -> Open Directory -> screw about with user.js
Also see arkenfox and the like, for a wide range of tweaks you might want to implement.

Ed.

bilhook wrote:

scrollbar is in settings, pity it's narrow

about:config, play with 'widget.gtk.overlay-scrollbars.enabled', 'layout.css.scrollbar-width-thin.disabled', and 'widget.non-native-theme.scrollbar.size.override'
I don't recall exactly which get you always-visible scrollbars of a usable size right now, but some combination will.

steve_v · Off-topic

Zapper wrote:

Even with an openwrt based router?
I have one of those, hence my question.
It also uses ath9k wifi card.

Uhh, what on earth does your router OS or wireless chipset have to do with any of this?
If you think a router or firewall is going to do anything useful about the data harvesting that goes on on the modern ~~garbage fire~~ internet, think again.
Blocking advertisements (whether at the router, on the client machine, or in your browser), does exactly what it says on the tin and no more. Ads are indeed a privacy concern, but they're only one of many.

steve_v · Other Issues

let's say that I have read something to the Buddhist sutras and want to present a picture downloaded from the Internet of the Buddha with a text of a mantra.

AKA a "meme generator" (many examples online), or something that can be done locally with pretty much any image editor.

is there a program
to add a image to the screen other than add it to
the wallpaper

Depends which desktop environment or window manager you're using. KDE Plasma for example has a "Media Frame" desktop widget that places resizeable images (or slideshows) on the desktop, on top of the wallpaper.
A similar DE agnostic result could be achieved with conky (read the docs wrt the "image" object) or a small shell script manipulating the window of [insert image viewer of choice here] with wmctrl and xprop to remove borders, set always below, and pin it to a specific position.

rolfie wrote:

You can put images into /usr/share/backgrounds and then use them as background image for your desktop.

AFAICT, the OP wants to pin pictures (with captions) on top of the wallpaper, not replace it. Something akin to the old "desktop sticky notes" but with images.
The use of "icon" all over the place is thoroughly confusing.

steve_v · Devuan Derivatives

Really? We need to drag ~~brain-rot~~ politics in here too?

anyone whining about politics on their mailing list gets the boot.

Careful, whining about whining about politics is still whining about politics.

OTOH, maybe if we derail this thread hard enough it will spontaneously combust. Once the stinky smoke clears, I expect that'll be a relief for everyone involved.

For my part, proud gate-goblin since 1999. Somebody gotta keep the riff-raff at bay, or we'll be up to our necks in idiots and activists 'afore the week is out.

steve_v · Devuan Derivatives

that is not doing FOSS a favor in anyway shape or form

Dunno about FOSS in general, but it'd definitely improve the SNR on this board, and good riddance.

Not at all surprised if fsmithred was a bit short with this one, I would be even shorter... Likely "go away troll" followed by a resounding *plonk*.

And no, this is not just a language barrier. English not being your first language might explain the aggressive and hyperbolic word choice to some extent, but the pattern of trash-talk, shouting and multiple exclamation marks is 100% intentional flamebait.

steve_v · Off-topic

its speed and video resolution are one step ahead of all Linux.

LOL, ChromeOS is Linux... Just with more cloud/CaaS bullshit.

steve_v · Installation

Assuming elogind (pretty sure that's the default these days): Here, here, here and here.
Also websearch keywords: elogind thaw hook

steve_v · Documentation

nixer wrote:

where did you put these commands and how did you "autostart" them?

In my case they're just desktop files in /etc/xdg/autostart. Actually running them is up to an XDG compliant DE.
Anywhere else that has them start after session login should work just as well though.

I still get the "No named daemons are running" output from the terminal.

Probably can't find any pidfiles, '--list' also needs the same '--pidfiles' argument you used when starting them, or a default set in /etc/daemon.conf

mweishaar wrote:

"unrecognized option '--bind'"

Yeah, elogind hooks need a version from unstable. >=0.8.2 IIRC.
See the "simple backport creation" debian wiki entry for an easy guide.

steve_v · Other Issues

FWIW, I've been running unattended-upgrades on several machines for over a decade, and have no significant borkage (aside from a recent Devuan identity-crisis SNAFU with unattended-upgrades itself) to report.
Then again, the only machines I don't have convenient physical access to have IMPI. If SSH was the only way I could administer a box, I'd likely be doing updates manually... Or at least restricting unattended-upgrades so it doesn't touch anything critical.

steve_v · Other Issues

libelogind-compat provides libsystemd0 (by symlinking libsystemd to libelogind), so they can't be installed simultaneously.
Without seeing full output (and please use code tags for such), I can only speculate that either:
* apt wants to replace libsystemd0 with libelogind-compat or vice-versa, but it can't because 'apt upgrade' won't remove already installed packages. A 'full-upgrade' or 'dist-upgrade' will.
* Something you are trying to install or upgrade depends on libsystemd0 specifically. There shouldn't be any of that in Devuan stable, but with unstable such things may well slip through from time to time.
That's why it's called unstable, and not recommended unless you are capable of and willing to deal with occasional borkage.

If you do in fact want to switch to libsystemd0 (the implications of which are up to you to research), try installing it explicitly with aptitude. It'll give you several possible solutions, one of which will likely be removing libelogind-compat and replacing it with libsystemd0.
Aside, aptitude's dependency resolver is often smarter than apt in situations like this and is usually worth a try, but it's probably not wise to use it for e.g. a full dist-upgrade on a stable sytem as it's solutions can be a bit... odd at times.

steve_v · Other Issues

The only thing I can really do is try to open eyes
...
saying all this here probably won't change much. Its futility unless enough people wake up though in general.

AKA, lots of preaching with very little doing.

The bare minimum line should be making all libraries optional for those dependencies I mentioed

In many cases these frameworks are already optional, via compile-time flags... Something which, for reasons that apparently escape me, you seem completely unwilling to consider.
Where they are not optional at compile-time, patches to upstream code would be required.

There is no standard facilty for making dynamic-linked library dependencies optional at runtime, because that's not how any of this works. The thing that is becoming most tedious of all is your insistence that there shouid be such a feature, and somebody other than you should see to it.

If you want everything built for you and served up in convenient packages, you get whatever the packagers decided on when they built them (or engage in constructive discussion where you disagree).
If you want control over compile-time options and patches, you run Gentoo or some other source-based distro.

Anything else is just blowing smoke. The tools to build a system the way you want already exist, if you're willing to put in the effort to use them.
Have you actually built and used a system without dbus and policykit, or is this all just idological bikeshedding?

All that said, if you want to be taken even remotely seriously on the idea of making such dependencies optional at the package management level (which would entail binary distros maintaining multiple variants of each affected package):
* What is your convincing technical argument for such a change?
* What do you propose replacing the projects on your "evil" list with? You want to drop dbus for example, so how should we do IPC?
* And, how is your proposed replacement (functionally) superior?
* How do you propose convincing 1000 upstream projects to drop features dependent on $evil_library or switch to your replacement?
* Who is going to do all this work, and does the benefit justify it? If upstreams aren't on board, who is going to write and test patches?

steve_v · Devuan

The only thing that's "hard" about modern Gentoo is the manual chroot-and-tarball install method, and that's no more difficult than Arch.
After that it's really just a CPU-time tax in return for the flexibility of building software the way you want it.

steve_v · Devuan

zapper wrote:

If I want a minimalistic system I have two choices...
OpenBSD or Hyperbola.

... Or NixOS, Gentoo, CRUX, Gobo, FreeBSD, or any other system that provides tooling to build packages locally with the configuration you want.
Were you motivated enough to do so, this can also be achieved with Debian/Devuan... It's just a bunch more work as the packaging tools don't really cater to global feature switches the way e.g. Gentoo USE flags or the nixpkg declarative build system do.

What you're really asking for appears to be a binary distribution where all the configuration and packaging work is done for you, yet the choices the maintainers make are precisely aligned with your preferences... That's not going to happen, regardless of how much you complain about it.

You want the Devuan developers and maintainers to fork and rebuild everything to run without $things_you_dislike, yet you're not even willing to properly define what you want or what would be needed to achieve it?
Not to put too fine a point on things: Get off the grass.

steve_v · Other Issues

kaiyel wrote:

how does Devuan avert attack surface expansion while the upstream becomes more dependency permissive to accommodate systemd? Could it even be done without forking packages expressly for that purpose?

IMO (at least as a general problem), it doesn't and it can't. Most dependencies are decided on at compile-time, and changing them means forking (or at least rebuilding) packages.
Frankly I don't see where Devuan is going to get the manpower for that. It might be feasible to fork some particularly important packages where all that is required is a simple configure flag change or dropping a patch, but deciding where to draw the line is well beyond my pay grade.

IMO the better approach is probably working on projects like elogind, i.e. forking parts of systemd itself, keeping the good bits and replacing all the crap we don't want with ABI-compatible stub functions.
That's something that is and can continue to be a common effort between distros, and so long as it keeps up with systemd changes it should allow most packages from e.g. upstream Debian to be used as-is in Devuan.

The downside of course is that we'll have to keep fending off nutters grinding the "Why does Devuan have libsystemd0" axe without bothering to check where that lib actually comes from or what it does.

zapper wrote:

polkit, systemd, avahi, dbus, networkmanager, pulseaudio, pipewire, wayland, java and their libraries
...
devuan cannot be used minimally and still have what i consider to be the correct functionality

You won't get both minimal dependencies and "correct" functionality with any binary distribution that in any way targets mainstream desktop use cases.

Desktop users want, at least for the most part, low-effort GUI support for things like wireless hotspots, VPNs, bluetooth / hotplug audio devices, network discovery, and prompt-free permission elevation for common tasks. In the current ecosystem that means using some or all of the "evil" frameworks you list.
This has nothing to do with "corporate influencers", it's simply the result of trying to cater to end-user expectations without massive code duplication or packaging workload.

That leaves either distributions that cater to minimalism specifically (which discounts most Debian derivatives and general-purpose distros right away) or building from source (i.e. Gentoo and derivatives).

Bitching about "bs corporate" whatever at every opportunity achieves exactly nothing. The only realistic way to have your cake and eat it (aka have only the features and dependencies you want) is to either rebuild all the affected packages yourself or switch to a source-based meta-distro.

zapper wrote:

They need to be told to suck it and force them to gag on it.

So why don't you go do that then. Ranting here is utterly futile, and serves only to bloat the thread with unproductive noise.
If you must vent your non-specific anti-corporate rage, I suggest you write your $government_representative.

steve_v · Other Issues

Personally I have no problem with library dependencies and dynamic linking, where it adds legitimately useful functionality and reduces code duplication.

But that's not what this is. Supporting sd_notify is little more than sending a simple datagram to a unix socket, and pulling in libsystemd0 for that one function is just about the definition of gratuitous attack surface.
But hey, why not double down, ignore the fact upstream has already said no because they don't want the dependency bloat, and go and patch it in regardless. The "systemd exists, so everything should use it somehow" bandwagon must grind ever onward.

Then there's that other obvious elephant of course: why does init need an LZMA (de)compressor anyway? Init's job is managing daemons, nothing more... Right?

IMO far too many projects pull in dependencies because it's the easy way to implement a feature, with precious little regard for whether it's a good way... or whether that feature is even worth having to begin with.
That includes distro packagers turning on every optional build-time dependency flag they can find, which is a long-time gripe of mine WRT Debian. Patching upstream sources for even more dependencies is just taking this trend to its (il)logical conclusion.

steve_v · Devuan

I'm well aware of ldd potentially executing code, however in this case:
This is stable install, with supposedly clean copy of liblzma & co.
It's also a disposable VM, because I'm not a complete idiot.
The point here is not to run ldd against compromised xz libs (everybody should have downgraded already on real systems), but to explain how liblzma is loaded into sshd and clear up the "devuan == safe" thing (which IMO is somewhat misleading).

liblzma is an indirect dependency here, so using objdump and friends instead is awkward.

steve_v · Other Issues

64bit time transition.
Now is not a particularly good time to volunteer your main rig as a testing/unstable guinea pig, at least not if you want to get anything (besides being a guinea pig) done.

steve_v · Devuan

It's pretty trivial to just go check what /usr/sbin/sshd links against for yourself, is it not?

e.g.
with libsystemd0:

$ ldd /usr/sbin/sshd | egrep 'systemd|lzma'
        libsystemd.so.0 => /usr/lib/x86_64-linux-gnu/libsystemd.so.0 (0x00007f27a6649000)
        liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f27a5ca9000)

and with libelogind0 + libelogind-compat:

$ ldd /usr/sbin/sshd | egrep 'systemd|lzma'
        libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 (0x00007f8dfc5b8000)

ldd is not the be all and end all, but in this case it's fairly obvious whether or not liblzma (and a bunch of other extraneous crap systemd needs) is going to be loaded by sshd.

IOW:
Stable: Never shipped compromised xz packages.
Unstable/testing with libsystemd0: Probably as vulnerable as Debian.
Unstable/testing with elogind: Probably not vulnerable (but you should absolutely roll back to a pre-compromise xz anyway).

Aside, this is all assuming that sshd is the only target. It does look that way at the moment, but investigation is still underway.

steve_v · Devuan

libsystemd0 is not installed in Devuan - at least in Daedalus

sshd in daedalus depends on libsystemd0, which may be satisfied by either the real libsystemd0 or by libelogind0 and libelogind-compat.
The former results in sshd being indirectly linked against liblzma as it is in Debian (though I'm not sure if that alone is enough to allow the exploit), the latter does not...

So effectively, both comments are correct depending on the exact set of packages you have installed. Devuan does pull sshd from Debian, so it does link against libsystemd. However the stripped-down copy of that library provided by elogind doesn't load liblzma, because its systemd-notify functionality is a stub.

In any case this is largely academic, as daedalus never shipped the compromised xz versions.

steve_v · DIY

My 486 runs KDE in <32MB...
To be fair that's KDE 1.1 on Slackware, but it is a full-featured DE.

Then again, RAM is cheap these days. So long as it's being used to good purpose, there's little sense in fussing over numbers.

steve_v · Other Issues

targeting deb and rpm via systemd?

More accurately, targeting sshd (so far, anyway) via a vulnerable understaffed/funded project which just happens to provide attack surface because certain distros patched a security-critical package to add gratuitous linkage to systemd.

This is not about diversity, or even systemd specifically. It's about dependency bloat.

There is zero reason sshd needs to link against anything in systemd, let alone pull in liblzma just to support systemd-notify (and linking a full blown compression lib just to say "sshd is up" to systemd is another level of insane to begin with). Doing this kind of thing opens it up not only to vulnerabilities in such direct dependencies, but also the 9000 other frivolous things those in turn link to.

This is a perfect example of why anyone serious about security resists bloat and feature-creep. Without the ridiculous "because it's there" attitude of the distros involved (particularly WRT systemd integration), this exploit would not have been possible.
If sshd really needed systemd-notify support (and it doesn't), it should have been via a minimal implementation in sshd itself, not pulling in a bunch of bloat and a compression library essentially maintained by one dude.
Distros patching this kind of stuff in downstream is, frankly, pretty irresponsible.

For a quick illumination of just how out of hand this is getting in Debian/Devuan...

$ cat /etc/os-release; ldd /usr/sbin/sshd 
PRETTY_NAME="Devuan GNU/Linux 5 (daedalus)"
NAME="Devuan GNU/Linux"
VERSION_ID="5"
VERSION="5 (daedalus)"
VERSION_CODENAME="daedalus"
ID=devuan
ID_LIKE=debian
HOME_URL="https://www.devuan.org/"
SUPPORT_URL="https://devuan.org/os/community"
BUG_REPORT_URL="https://bugs.devuan.org/"
        linux-vdso.so.1 (0x00007ffc96fde000)
        libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007f27a6768000)
        libwrap.so.0 => /usr/lib/x86_64-linux-gnu/libwrap.so.0 (0x00007f27a675c000)
        libaudit.so.1 => /lib/x86_64-linux-gnu/libaudit.so.1 (0x00007f27a672b000)
        libpam.so.0 => /lib/x86_64-linux-gnu/libpam.so.0 (0x00007f27a6719000)
        libsystemd.so.0 => /usr/lib/x86_64-linux-gnu/libsystemd.so.0 (0x00007f27a6649000)
        libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f27a6619000)
        libgssapi_krb5.so.2 => /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x00007f27a65c7000)
        libkrb5.so.3 => /usr/lib/x86_64-linux-gnu/libkrb5.so.3 (0x00007f27a64ed000)
        libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x00007f27a64e7000)
        libcrypto.so.3 => /usr/lib/x86_64-linux-gnu/libcrypto.so.3 (0x00007f27a6000000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f27a64c8000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f27a5e1f000)
        libnsl.so.2 => /usr/lib/x86_64-linux-gnu/libnsl.so.2 (0x00007f27a64ab000)
        libcap-ng.so.0 => /lib/x86_64-linux-gnu/libcap-ng.so.0 (0x00007f27a64a3000)
        libcap.so.2 => /lib/x86_64-linux-gnu/libcap.so.2 (0x00007f27a6497000)
        libgcrypt.so.20 => /usr/lib/x86_64-linux-gnu/libgcrypt.so.20 (0x00007f27a5cd8000)
        liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f27a5ca9000)
        libzstd.so.1 => /usr/lib/x86_64-linux-gnu/libzstd.so.1 (0x00007f27a5bed000)
        liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 (0x00007f27a5bc7000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f27a68ec000)
        libpcre2-8.so.0 => /usr/lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x00007f27a5b2d000)
        libk5crypto.so.3 => /usr/lib/x86_64-linux-gnu/libk5crypto.so.3 (0x00007f27a5b00000)
        libkrb5support.so.0 => /usr/lib/x86_64-linux-gnu/libkrb5support.so.0 (0x00007f27a6487000)
        libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 (0x00007f27a5af9000)
        libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f27a5ae8000)
        libtirpc.so.3 => /lib/x86_64-linux-gnu/libtirpc.so.3 (0x00007f27a5aba000)
        libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007f27a5a92000)

$ cat /etc/os-release; ldd /usr/sbin/sshd 
NAME=Gentoo
ID=gentoo
PRETTY_NAME="Gentoo Linux"
ANSI_COLOR="1;32"
HOME_URL="https://www.gentoo.org/"
SUPPORT_URL="https://www.gentoo.org/support/"
BUG_REPORT_URL="https://bugs.gentoo.org/"
VERSION_ID="2.14"
        linux-vdso.so.1 (0x00007ffd3cde1000)
        libcrypt.so.2 => /usr/lib64/libcrypt.so.2 (0x00007f18fdd74000)
        libpam.so.0 => /usr/lib64/libpam.so.0 (0x00007f18fdd63000)
        libcrypto.so.3 => /usr/lib64/libcrypto.so.3 (0x00007f18fd800000)
        libz.so.1 => /usr/lib64/libz.so.1 (0x00007f18fdd47000)
        libc.so.6 => /usr/lib64/libc.so.6 (0x00007f18fd62f000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f18fdec5000)

Which of these do you think has the larger attack surface, or more vulnerable supply-chain? I'm not even trying with that Gentoo build, and I could easily drop pam if I did.

The officially official Devuan Forum!

#1 Re: Desktop and Multimedia » Skype, snap and how to run on Devuan? » Today 12:47:13

#2 Re: Desktop and Multimedia » Skype, snap and how to run on Devuan? » Today 11:44:16

#3 Re: Desktop and Multimedia » Skype, snap and how to run on Devuan? » Today 09:26:34

#4 Re: Desktop and Multimedia » Skype, snap and how to run on Devuan? » Yesterday 13:45:51

#5 Re: Off-topic » Firefox is becoming too chrome like. » Yesterday 13:27:53

#6 Re: Off-topic » Firefox is becoming too chrome like. » Yesterday 05:59:25

#7 Re: Other Issues » desktop dress-up » 2024-05-28 12:44:32

#8 Re: Devuan Derivatives » Devuan est à la traîne (google: Devuan is lagging behind) ! » 2024-05-24 07:50:36

#9 Re: Devuan Derivatives » Devuan est à la traîne (google: Devuan is lagging behind) ! » 2024-05-24 07:20:03

#10 Re: Off-topic » Firefox is becoming too chrome like. » 2024-05-24 05:02:47

#11 Re: Installation » Question regarding devuan and hibernate » 2024-05-24 04:54:48

#12 Re: Documentation » How to: Devuan 5 Daedalus an pipewire » 2024-04-20 10:03:53

#13 Re: Other Issues » should I use unattended-upgrades? » 2024-04-15 12:15:39

#14 Re: Other Issues » [SOLVED] libelogind-compat : Conflicts: libsystemd0 » 2024-04-14 10:47:06

#15 Re: Other Issues » backdoor targeting deb and rpm via systemd? » 2024-04-14 06:08:55

#16 Re: Devuan » liblzma CVE-2024-3094 » 2024-04-14 05:36:49

#17 Re: Devuan » liblzma CVE-2024-3094 » 2024-04-13 09:13:57

#18 Re: Other Issues » backdoor targeting deb and rpm via systemd? » 2024-04-13 08:05:10

#19 Re: Other Issues » backdoor targeting deb and rpm via systemd? » 2024-04-11 06:43:21

#20 Re: Devuan » liblzma CVE-2024-3094 » 2024-04-02 03:25:18

#21 Re: Other Issues » [SOLVED] Package name extension "t64" in excalibur » 2024-03-31 17:04:53

#22 Re: Devuan » liblzma CVE-2024-3094 » 2024-03-31 16:34:14

#23 Re: Devuan » liblzma CVE-2024-3094 » 2024-03-31 14:51:34

#24 Re: DIY » Lowest memory footprint obtained. » 2024-03-30 11:27:47

#25 Re: Other Issues » backdoor targeting deb and rpm via systemd? » 2024-03-30 10:37:53

Board footer