NotAnArdvark

Here's the situation: I use the Obsidian Flatpak with Plasma on openSUSE Tumbleweed. For a long time the Obsidian file picker was the Plasma version, and life was good. After an update of openSUSE and my Obsidian Flatpak, I'm now getting the Gnome file picker. Life now makes less sense.

I've confirmed that other Flatpaks are still using the Plasma file picker. I've also been investigating my xdg-desktop-portal configuration based off of what I've been reading here, but it all looks correct to me.

I can't decide whether this change was because of Obsidian, the Flatpak packaging of Obsidian, or an openSUSE change. Does anyone have tips on tracking this down?

The following command works even though I really don't think I should have permission to the key file:
$ openssl aes-256-cbc -d -pbkdf2 -in etc_backup.tar.xz.enc -out etc_backup.tar.xz -k /etc/ssl/private/etcBackup.key

I'm unable to even ascertain the existence of the key file under my normal user. I'm a member of only two groups, my own group and vboxusers.

The permissions leading up to that file:

drwxr-xr-x   1 root root 4010 Jul 31 08:01 etc
...
drwxr-xr-x 1 root root      206 Jul 14 23:52 ssl
...
drwx------ 1 root root    26 Jul 31 14:07 private
...
-rw------- 1 root root 256 Jul 31 14:07 etcBackup.key

OpenSSL isn't setuid:

> ls -la $(which openssl)
-rwxr-xr-x 1 root root 1004768 Jul 14 23:52 /usr/bin/openssl

There don't appear to be any ACLs related to that key file:

> sudo getfacl /etc/ssl/private/etcBackup.key
[sudo] password for root: 
getfacl: Removing leading '/' from absolute path names
# file: etc/ssl/private/etcBackup.key
# owner: root
# group: root
user::rw-
group::---
other::---

> sudo lsattr  /etc/ssl/private/etcBackup.key
---------------------- /etc/ssl/private/etcBackup.key

Finally, it's not just the case that the original file was encrypted with an empty file:

> openssl aes-256-cbc -d -pbkdf2 -in etc_backup.tar.xz.enc -out etc_backup.tar.xz -k /etc/ssl/private/abc.key
bad decrypt
4047F634B67F0000:error:1C800064:Provider routines:ossl_cipher_unpadblock:bad decrypt:providers/implementations/ciphers/ciphercommon_block.c:124

Does anyone know what I've missed here?

Zoom is vital to my job this month and prior to an update last week I had the openSUSE version of Zoom's RPM installed and working fine.

I updated my Tumbleweed installation to openSUSE-20240704-0 last week, after which Zoom started crashing when sharing a screen. There was a message in the logs about the library libqt5qml.so and I thought I could fix this by backing out either the update for the libQtQuick5 package in particular, or just booting from the pre-update snapshot.

To make a long story short, I ultimately installed the Zoom Flatpak and resolved to get back to this when I had a bit more time.

My question - Can people suggest the right way in openSUSE Tumbleweed to handle the situation where an update breaks something on the system?

Assuming libQtQuick5 was the updated package that was at fault here, is there a way I could have downgraded just that package? Would booting from the pre-update snapshot and then just carrying on with my week have been a reasonable way to proceed?

To be clear - I'm not so much concerned about Zoom, I'm more curious about how to use the openSUSE Tumbleweed tools to recover from updates that cause problems.

Thank you!

I have a very specific questions about Linux Traffic control and u32 filters in particular. However, I don't know where the right place is to ask such a question as it's fairly niche.

The Linux Advanced Routing & Traffic Control site says it has a mailing list for questions, but the last post was from 2019. There is also the incredibly busy 'linux-netdev' mailing list, but, the traffic there looks like strictly source changes.

Any ideas?

The question I'm trying to find an answer to is: The u32 tc filter seems to support negative byte offsets which allows you to examine the Ethernet frame header (I don't think I even found documentation on this, this is thanks to ChatGPT). However, when using u32 values to examine 8 bytes I can only use offsets in increments of 4 - like "at -8" or "at -12", with any other increment giving me the error Illegal "match".

This seems like only a curiosity, but, I've been struggling to get my bit-matching to match the way I expect, and I'm wondering if this suggests that matching doesn't function the way I think.