My recommendation is meetup and a website for advertising purposes. Meetup is frustrating, yes, but at the same time it’s where I have found almost all the linux and tech groups near me.

This may sound kind of weird, but do you really need a communication platform for a LUG?

Our local LUG uses meetup and a website for advertising and telling people when we meet (once every two weeks at the same spot). (Okay I guess the one time our spot was closed and we had to track down people’s phone numbers to inform them of the new spot wasn’t that fun).

Anyway, we have a mailing list, an irc, and a matrix chat bridged to the irc, but they are effectively dead and no one uses them. The lack of activity on them makes me wonder if you really need to have a chatroom to run a LUG. We seem to get by just fine, for the most part.

Familiarity instead of compatibility.

This piece of documentation from forgejo, about how their actions are mostly github actions compatible is how I feel about this or similar endeavors.

I really like KDE, because it’s familiar enough to Windows users that they can just kinda use it. Many of the shortcuts are the same. But I’ve had a bad experience with things that try to emulate Windows more completely, because people begin to expect some windows idiosyncracy or some other thing to be there. And then they get frustrated when it’s not the same.

KDE manages to be “close enough”, which results in a better experience.

Yes. My high school used to do this. UDP blocked except for DNS to some specific servers, and probably some other needed things.

Gnome used to much worse when it comes to ram usage, so the inertia of those sentiments still carry.

Kde used to be much worse, using what gnome uses now, but now kde has similar ram usage to xfce last time I tested. CPU wise it’s still much worse though.

I’ve heard of thumbnails being used to deliver malware.

You’ve heard of critical vulnerabilities in media processing applications that mean that thumbnails can theoretically be used to be spread malware. That is not the same as “this issue was being actively exploited in the wild and used to spread malware before it was found and patched”.

These vulnerabilities, (again, cost money), and are fixed rapidly when found. Yes, disabling thumbnails is more secure. But I am of the belief that average users should not worry about any form of costly zero day in their threat model, because they don’t have sensitive information on their computers that makes them a target.

less distro-dependent like a privilege escalation attack

These also are valuable. Less valuable than browser escapes IMO though.

A keylogger is more likely, and it’s just as possible with sudo as it is with run0. They would replace sudo, run0, doas, etc with a fake command (since that only require access to the user), that either keylogs, or inserts a backdoor while it does the other sudo things.

I’ve heard a fair few times about thumbnailer attacks, but no real detail from KDE about what if any mitigations they have in place.

Please ignore the entire cybersecurity hype news cycle about images being used to spread malware. They often like to intentionally muddy the waters, and not clearly explain the difference between a malformed file being used as a vulnerability to exploit a code execution exploit, and an image file being used as a container for a payload (steganography). The former is a big deal, the latter is a non issue because the image is not the issue, whatever means the malware actually used to get onto the systems is.

Here’s a recent example of me calling this BS out. The clickbait title implies that users got pwned by viewing a malicious image, when in actually it was a malicious extension that did the bad things.

Unless you are using windows media player, the microsoft office suite, or adobe acrobat, code execution from loading a media file is a really big deal and fixed extremely quickly. Just stay updated to dodge these kind of issues.

As for zero days, unknown and unpatched vulnerabilities, again, that’s a different threat model because those exploits cost money to execute. Using an existing known (but fixed in updated versions of apps) is free.

If I uninstall sudo and switch to run0 (

Sudo and run0 are both problematic. Sudo is a setuid binary, which is problematic, but run0 is not much better. It works by making calls to systemd/polkit/dbus, services that constantly run as root, and they themselves expose a massive attack surface. Many privilege escalation CVE’s similar to sudo have been released that exploit that attack surface.

When it comes to actually being secure, systemd somewhat screws you over, due to having a massive attack surface, a way to run things as root, and the interesting decision to have polkit parse and run javascript in order to handle authorization logic (parsing is a nightmare to do securely).

The other thing, is that the browser sandbox is much, much stronger than the separation of privileges between users in Linux. Browser sandbox escapes (because they work the same on windows or Linux) are worth immense amounts of cash, and are the kinds of exploits that are used in targeted manners against people who have information on their computer worth that much. If you don’t have information worth millions of dollars on your computer, you shouldn’t worry about browser sandbox escape exploits.

The reality is that any attacker who is willing able able to pierce through a browser escape sandbox, will probably also have a Linux privilege escalation vulnerability on hand. In my opinion, trying to add more layers to security is pointless unless you are adding stronger layers. If your attacker has a stronger “spear”, it doesn’t matter how many weak “shields” you try to put in front to stop it.

If the million dollar industry of browser escapes is in your threat model, I recommend checking out the way that Openbsd’s sandboxing interacts with chromium. Or check out google’s gvisor sandbox and see if you can run a browser in there.

The backdoor of the xz utils program(s) was in the tarball release, but not the main source code:

https://en.wikipedia.org/wiki/XZ_Utils_backdoor

If debian had dodged the upstream tarball, then they wouldn’t have been affected by this.

Is this because of the xz utils thing? The backdoor was included into the tarball, but it wasn’t in the git repo.

By switching away from tarballs they pribably hope to prevent that, although this article doesn’t mention that. It’s possible this shift has been happening since before the xz utils.

Did you post this right as I edited the title? Lol.

Late reply but I also recommend going through flathub for screenwriting apps if you want more. I saw some options that looked pretty good, although many where proprietary.

Not really? From this page, all it looks like you need is a salsa.debian.org account. They call this being a “Debian developer”, but registration on Debian Salsa is open to anybody, and you can just sign up.

Once you have an account, you can use Debian’s Debusine normally. I don’t really see how this is any different from being required to create an Ubuntu/Launchpad account for a PPA. This is really just pedantic terminology, Debian considers anybody who contributes to their distro in any way to be a “Debian Developer”, whereas Ubuntu doesn’t.

If you don’t want to create an account, you can self host debusine — except it looks like you can’t self host the server that powers PPA’s. I consider this to be a win for Debusine.

Make sure you stream with the “linux” tag so thag people who follow that tag around like me can find you!

Proxmox is based on debian, with it’s own virtualization packages and system services that do something very similar to what libvirt does.

Libvirr + virt manager also uses qemu kvm as it’s underlying virtual machine software, meaning performance will be identical.

Although perhaps there will be a tiny difference due to libvirt’s use of the more performant spice for graphics vs proxmox’s novnc but it doesn’t really matter.

The true minimal setup is to just use qemu kvm directly, but the virtual machine performance will be the same as libvirt, in exchange for a very small reduction in overhead.

Idk what to tell you. I linked to sources showing that flathub signs everything, and that flatpak refuses to install unsigned packages by default.

If you have anything contrary feel free to link it.

Also you multi replied to this comment. Sometimes I had this issue with eternity.

https://intronetworks.cs.luc.edu/

I have a similar setup, and even though I am hosting git (forgejo), I use ssh as a git server for the source of truth that k8s reads.

This prevents an ouroboros dependency where flux is using the git repo from forgejo which is deployed by flux…

From flahubs docs: https://docs.flathub.org/blog/app-safety-layered-approach-source-to-user#reproducibility--auditability

The build itself is signed by Flathub’s key, and Flatpak/OSTree verify these signatures when installing and updating apps.

This does not seem to be optional or up to the control of each developer or publisher who is using the flathub repos.

Of course, unless you mean packages via flatpak in general?

Hmmm, this is where my research leads me.

https://docs.flatpak.org/en/latest/flatpak-builder.html#signing

Though it generally isn’t recommended, it is possible not to use GPG verification. In this case, the --no-gpg-verify option should be used when adding the repository. Note that it is necessary to become root in order to update a repository that does not have GPG verification enabled.

Going further, I found a relevant github issue where a user is encountering an issue where flatpak is refusing to install a package that is not signed, and the user is asking for a cli flag to bypass this block.

I don’t really see how this is any different from apt refusing to install unsigned packages by default but allowing a command line flag (--allow-unauthenticated) as an escape hatch.

To be really pedantic, apt key signing is also optional, it’s just that apt is configured to refuse to install unsigned packages by default. So therefor all major repos sign their packages with GPG keys. Flatpak appears to follow this exact same model.

This is not true. Flatpaks from flathub are signed with a gpg key.

Now admittedly, they use a single release key for all their signing, which is much weaker than the traditional distro’s model of having multiple package maintainers sign off on a release.

But the packages are signed.

Edit: snaps are signed in a similar way.