MX-21 KDE/plasma beta 2 feedback thread

[TimothySimon]

MX 21 Beta 2 has many keys in /etc/apt/trusted.gpg and /etc/apt/trusted.gpg.d/*.gpg that are (AFAIK) trusted by apt, even for signing packages in the official repo.

There are also many historic keys (like that or Warren Woodford from MEPIS), medibuntu, many individuals' keys (like Christian Marillat, Adam Blackburn, Hendrik Rittich), many companies' keys (Oracle Corporation, innotek GmbH, Opera Software) etc., in these places where (AFAIK) apt trusts them.

These keys are present in /etc/apt/trusted.gpg and /etc/apt/trusted.gpg.d/*.gpg and these are (AFAIK) trusted by apt, even for signing packages in the official repo:

Code: Select all

$ sudo apt-key list | grep '^uid'
Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).
uid           [ expired] Warren Woodford (MEPIS Maintainers) <dev@mepis.org>
uid           [ unknown] Ubuntu Archive Automatic Signing Key <ftpmaster@ubuntu.com>
uid           [ unknown] The Medibuntu Team <medibuntu@sos-sts.com>
uid           [ unknown] Ubuntu CD Image Automatic Signing Key <cdimage@ubuntu.com>
uid           [ unknown] Christian Marillat <marillat@debian.org>
uid           [ unknown] Christian Marillat <marillat@free.fr>
uid           [ unknown] Stefan Lippers-Hollmann (sidux.com) <s.l-h@gmx.de>
uid           [ expired] Opera Software Archive Automatic Signing Key <hostmaster@opera.com>
uid           [ unknown] innotek GmbH (archive signing key) <info@innotek.de>
uid           [ unknown] Adam Blackburn <compwiz18@gmail.com>
uid           [ unknown] Sun Microsystems, Inc. (xVM VirtualBox archive signing key) <info@virtualbox.org>
uid           [ expired] Hendrik Rittich <hendrik.rittich@gmx.de>
uid           [ unknown] Steven Barrett <damentz@gmail.com>
uid           [ unknown] Oracle Corporation (VirtualBox archive signing key) <info@virtualbox.org>
uid           [ expired] Opera Software Archive Automatic Signing Key 2010 <packager@opera.com>
uid           [ unknown] Warren Woodford (MEPIS Maintainers) <dev@mepis.org>
uid           [ unknown] aurelien (Be Free!) <ice.cube@gmx.com>
uid           [ expired] Hendrik Rittich <hendrik.rittich@gmx.de>
uid           [ unknown] Dedinčanov archív balíkov (Debian APT repositary) <dedincan@slavino.sk>
# ^^^^ this is NOT *.debian.org and note that the "repository" is spelt incorrectly
uid           [ expired] David deJong (Dave) <david@daveserver.info>
uid           [ unknown] antiX (this is for the antix repo) <antix@daveserver.info>
uid           [ expired] Opera Software Archive Automatic Signing Key 2012 <packager@opera.com>
uid           [ unknown] aurele (Free your Gnu !) <ice.cube@gmx.com>
uid           [ unknown] MEPIS Community Repository (CR Signing key) <repo@teharris.net>
uid           [ expired] home:gottcode OBS Project <home:gottcode@build.opensuse.org>
uid           [ expired] MX Community Repository <repo@teharris.net>
uid           [ unknown] antiX Linux repo <repo@antixlinux.com>
uid           [ unknown] Debian Archive Automatic Signing Key (11/bullseye) <ftpmaster@debian.org>
uid           [ unknown] Debian Security Archive Automatic Signing Key (11/bullseye) <ftpmaster@debian.org>
uid           [ unknown] Debian Stable Release Key (11/bullseye) <debian-release@lists.debian.org>
uid           [ unknown] Debian Archive Automatic Signing Key (10/buster) <ftpmaster@debian.org>
uid           [ unknown] Debian Security Archive Automatic Signing Key (10/buster) <ftpmaster@debian.org>
uid           [ unknown] Debian Stable Release Key (10/buster) <debian-release@lists.debian.org>
uid           [ unknown] Debian Archive Automatic Signing Key (9/stretch) <ftpmaster@debian.org>
uid           [ unknown] Debian Security Archive Automatic Signing Key (9/stretch) <ftpmaster@debian.org>
uid           [ unknown] Debian Stable Release Key (9/stretch) <debian-release@lists.debian.org>
uid           [ unknown] MX-21 Repository <maintainer@mxrepo.com>

apt-key(8) is deprecated, but keys present in /etc/apt/trusted.gpg and /etc/apt/trusted.gpg.d/*.gpg are (AFAIK) trusted by apt, even for signing packages in the official repo.

I think a lot of these keys should be removed in MX 21 Final, because they may pose a security threat (at least in theory) because these keys can be used to successfully sign packages delivered through the official repo.

[SwampRabbit]

@TimothySimon i think this has already been discussed here on the forums, and a response to that thread was provided, but for sure we should look to see if there is an issue.

If I remember right these keys were being provided externally and by packages themselves

[davemx]

I wonder whether Vivaldi using gtk dialog boxes instead of kdialog (which is, in fact, installed in MX-KDE by default) can only be changed by vivaldi having to be rebuilt to use it? If that's the case, then I think that I'll put up with it how it is. It would be wrong to put it onto the devs. It's inconsistent but hardly a huge issue. I'm not having any problems at all with this beta at the moment.

[TimothySimon]

@TimothySimon i think this has already been discussed here on the forums, and a response to that thread was provided, but for sure we should look to see if there is an issue.

If I remember right these keys were being provided externally and by packages themselves

I think those keys are of no use, but I would wait for the MX team to confirm that.

I'm especially worried that a lot of them use DSA1024 and one even uses RSA1024 -- both of which are NO LONGER CONSIDERED SAFE .

NIST SP 800-57 Part 1 Rev. 5 ( https://doi.org/10.6028/NIST.SP.800-57pt1r5 ) says that RSA1024 and DSA1024 have <=80 bits of security (Ref: Table 2 of NIST SP 800-57 Part 1 Rev. 5)

Also, note that algorithm/key-size combinations that have been estimated at a maximum security
strength of less than 112 bits (i.e., at ≤ 80, as shown in orange above) are no longer approved for
applying cryptographic protection on federal government information (e.g., encrypting data or
generating a digital signature).

- NIST SP 800-57 Part 1 Rev. 5 Section 5.6.1.1

If it were to be broken (which can be anytime in now - it has just 80 bits of security) , just intercepting HTTP would be enough for anyone (not just the real private key holders) to deliver fake packages in the guise of http://deb.debian.org/debian (which uses HTTP).

BTW I think MX 21 should start using RSA4096 , not RSA2048.
Debian has been using RSA4096 from STRETCH (Debian 9) onward.

Even if it is not broken (no, it will be broken soon) , it greatly increases attack surface , by trusting 37 keys which can validly sign packages and may deliver it in the guise of the official repo.

Consider this situation :
1) Any one of the private key holders whose public key is listed (there are 37 of them) makes and validly signs a malicious package.
2) They deliver it by intercepting the insecure HTTP (over which http://deb.debian.org/debian works).

I trust only 13 of these 37 -- the official Debian, MX, antiX and Ubuntu signing keys.
The rest 24 are not trusted at all (at least in my case).

BTW I got the old discussion (after a lot of searching) at viewtopic.php?f=104&t=64322
and I'm really getting worried.

[fehlix]

Consider this situation :
1) Any one of the private key holders whose public key is listed (there are 37 of them) makes and validly signs a malicious package.
2) They deliver it by intercepting the insecure HTTP (over which http://deb.debian.org/debian works).

package signatures are ignored by apt on Debian. One would need take over the whole repository and deliver a malicious signed release file. The verification of those faked release file would fail as the local public-signing keys are expired. To tidy up expired keys is a kind of houskeeping exercise, which IIRC was already initiated. The described scenario, seems to me not a realistic security thread, as far as I can see.

[SwampRabbit]

@TimothySimon First why in the world are we pointing to NIST RMF stuff in this Beta thread. I’m not knocking any NIST SP (I mean someone was part of writing quite a few of them), but any standard or framework should not be blindly blanketed on anything just because.

It’s not like we have known compromised keys … like ummm… any Buntu based Distro, Manjaro, and a few others did (might still) awhile ago.

But I’m not worried and I’ll leave that for what it’s worth.

This discussion and any other should be moved out of this Beta thread and into something else like Chat.

[computerworm01001]

But I've bigger fish to fry right now, like what is with the USB mounting error I cited in my original post? I share my computer with another person, and it is very inconvenient for them to not be able to mount USB flash drives under their user account.

is the drive in question still mounted by the first user?

No, it is not. And the problem is not limited to just one flash drive. I've tried several flash drives, and they all raise the same error. I also created a dummy account to further test the phenomenon, and the results were the same. Only my user can mount removable media. I checked group memberships, and they are identical for all users. I also checked the permissions in the /media folder, and got an identical string for both user folders, so that can't be the issue:

Code: Select all

drwxr-x---+ 2 root root 4096

The only other possibility I can think of is that it's a polkit issue, maybe?

[TimothySimon]

@TimothySimon First why in the world are we pointing to NIST RMF stuff in this Beta thread. I’m not knocking any NIST SP (I mean someone was part of writing quite a few of them), but any standard or framework should not be blindly blanketed on anything just because.

It’s not like we have known compromised keys … like ummm… any Buntu based Distro, Manjaro, and a few others did (might still) awhile ago.

But I’m not worried and I’ll leave that for what it’s worth.

This discussion and any other should be moved out of this Beta thread and into something else like Chat.

I've forked it off to viewtopic.php?f=6&t=66528

BTW I now noticed that DSA1024 generally uses SHA1 , which is ALREADY BROKEN in 2017.
https://en.wikipedia.org/wiki/SHA-1
https://security.googleblog.com/2017/02 ... ision.html
https://shattered.io/

And one DSA1024 key present even now in MX Linux (key id 630239CC130E1A7FD81A27B140976EAF437D05B5) was the matter of a HIGH Importance issue on Ubuntu, fixed back in 2016
( Ref: https://bugs.launchpad.net/ubuntu/+sour ... ug/1363482 )

[Eadwine Rose]

Moderator: Everyone, please continue THIS part of the discussion over here: viewtopic.php?p=654259#p654259 so we can continue on topic (which is the KDE beta) in here, thanks.

[siamhie]

Installation went smooth with no issues. Installed my rtl8814 drivers and emby-server from HDD. Added xscreensaver's extra goodies from MXPI. Added mxfb-quickshot from my Fluxbox installation. (ksnip is nice but I like the simplicity of quickshot)

Boots lightning fast and runs rock solid. Well done.

Code: Select all

System:
  Host: <filter> Kernel: 5.10.0-8-amd64 x86_64 bits: 64 compiler: N/A 
  parameters: BOOT_IMAGE=/boot/vmlinuz-5.10.0-8-amd64 
  root=UUID=<filter> ro quiet splash 
  init=/lib/systemd/systemd 
  Desktop: KDE Plasma 5.20.5 wm: kwin_x11 dm: SDDM 
  Distro: MX-21_KDE_beta2_x64 Wildflower September 4  2021 
  base: Debian GNU/Linux 11 (bullseye) 
Machine:
  Type: Desktop System: ASUSTeK product: K30BF_M32BF_A_F_K31BF_6 v: N/A 
  serial: <filter> 
  Mobo: ASUSTeK model: K30BF_M32BF_A_F_K31BF_6 v: Rev X.0x 
  serial: <filter> UEFI: American Megatrends v: 0401 date: 04/29/2015 
Battery:
  Device-1: hidpp_battery_0 model: Logitech Wireless Mouse 
  serial: <filter> charge: 55% (should be ignored) rechargeable: yes 
  status: Discharging 
  Device-2: hidpp_battery_1 model: Logitech Wireless Keyboard K360 
  serial: <filter> charge: 100% (should be ignored) rechargeable: yes 
  status: Discharging 
CPU:
  Topology: Quad Core 
  model: AMD A10-7800 Radeon R7 12 Compute Cores 4C+8G bits: 64 
  type: MCP arch: Steamroller family: 15 (21) model-id: 30 (48) 
  stepping: 1 microcode: 6003106 L2 cache: 2048 KiB 
  flags: avx lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm 
  bogomips: 27928 
  Speed: 1640 MHz min/max: 1400/3500 MHz boost: enabled 
  Core speeds (MHz): 1: 1640 2: 1654 3: 1870 4: 1571 
  Vulnerabilities: Type: itlb_multihit status: Not affected 
  Type: l1tf status: Not affected 
  Type: mds status: Not affected 
  Type: meltdown status: Not affected 
  Type: spec_store_bypass 
  mitigation: Speculative Store Bypass disabled via prctl and seccomp 
  Type: spectre_v1 
  mitigation: usercopy/swapgs barriers and __user pointer sanitization 
  Type: spectre_v2 
  mitigation: Full AMD retpoline, STIBP: disabled, RSB filling 
  Type: srbds status: Not affected 
  Type: tsx_async_abort status: Not affected 
Graphics:
  Device-1: AMD Kaveri [Radeon R7 Graphics] vendor: ASUSTeK 
  driver: radeon v: kernel bus ID: 00:01.0 chip ID: 1002:130f 
  Device-2: AMD Oland PRO [Radeon R7 240/340] vendor: ASUSTeK 
  driver: radeon v: kernel bus ID: 01:00.0 chip ID: 1002:6613 
  Display: x11 server: X.Org 1.20.13 driver: ati,radeon 
  unloaded: fbdev,modesetting,vesa compositor: kwin_x11 
  resolution: 1920x1080~60Hz 
  OpenGL: renderer: AMD OLAND (DRM 2.50.0 5.10.0-8-amd64 LLVM 12.0.1) 
  v: 4.5 Mesa 21.2.1 direct render: Yes 
Audio:
  Device-1: AMD Kaveri HDMI/DP Audio vendor: ASUSTeK 
  driver: snd_hda_intel v: kernel bus ID: 00:01.1 chip ID: 1002:1308 
  Device-2: AMD FCH Azalia vendor: ASUSTeK driver: snd_hda_intel 
  v: kernel bus ID: 00:14.2 chip ID: 1022:780d 
  Device-3: AMD Oland/Hainan/Cape Verde/Pitcairn HDMI Audio [Radeon HD 
  7000 Series] 
  vendor: ASUSTeK driver: snd_hda_intel v: kernel bus ID: 01:00.1 
  chip ID: 1002:aab0 
  Sound Server: ALSA v: k5.10.0-8-amd64 
Network:
  Device-1: Realtek RTL8821AE 802.11ac PCIe Wireless Network Adapter 
  vendor: AzureWave driver: rtl8821ae v: kernel port: d000 
  bus ID: 04:00.0 chip ID: 10ec:8821 
  IF: wlan0 state: down mac: <filter> 
  Device-2: NetGear Nighthawk A7000 802.11ac Wireless Adapter AC1900 
  [Realtek 8814AU] 
  type: USB driver: 8814au bus ID: 3-2:2 chip ID: 0846:9054 
  serial: <filter> 
  IF: wlan1 state: up mac: <filter> 
Drives:
  Local Storage: total: 1.36 TiB used: 549.35 GiB (39.3%) 
  ID-1: /dev/sda vendor: Samsung model: SSD 870 EVO 500GB 
  size: 465.76 GiB block size: physical: 512 B logical: 512 B 
  speed: 6.0 Gb/s serial: <filter> rev: 1B6Q scheme: GPT 
  ID-2: /dev/sdb vendor: Seagate model: ST1000DM003-1ER162 
  size: 931.51 GiB block size: physical: 4096 B logical: 512 B 
  speed: 6.0 Gb/s rotation: 7200 rpm serial: <filter> rev: CC43 
  scheme: MBR 
Partition:
  ID-1: / raw size: 130.00 GiB size: 126.90 GiB (97.62%) 
  used: 7.96 GiB (6.3%) fs: ext4 dev: /dev/sda5 
  ID-2: /home raw size: 100.00 GiB size: 97.87 GiB (97.87%) 
  used: 1.24 GiB (1.3%) fs: ext4 dev: /dev/sda6 
  ID-3: swap-1 size: 4.00 GiB used: 0 KiB (0.0%) fs: swap 
  swappiness: 15 (default 60) cache pressure: 100 (default) 
  dev: /dev/sda2 
Sensors:
  System Temperatures: cpu: 4.1 C mobo: N/A 
  Fan Speeds (RPM): N/A 
  GPU: device: radeon temp: N/A device: radeon temp: 35 C 
Repos:
  No active apt repos in: /etc/apt/sources.list 
  Active apt repos in: /etc/apt/sources.list.d/debian-stable-updates.list 
  1: deb http://deb.debian.org/debian bullseye-updates main contrib non-free
  Active apt repos in: /etc/apt/sources.list.d/debian.list 
  1: deb http://deb.debian.org/debian bullseye main contrib non-free
  2: deb http://security.debian.org/debian-security bullseye-security main contrib non-free
  Active apt repos in: /etc/apt/sources.list.d/mx.list 
  1: deb http://la.mxrepo.com/mx/repo/ bullseye main non-free
  2: deb http://la.mxrepo.com/mx/repo/ bullseye ahs
Info:
  Processes: 208 Uptime: 56m Memory: 14.60 GiB used: 1.77 GiB (12.1%) 
  Init: systemd v: 247 runlevel: 5 default: 5 Compilers: gcc: 10.2.1 
  alt: 10 Shell: quick-system-in running in: quick-system-in 
  inxi: 3.0.36