Non-Qubes-Whonix KDE plasma 5 fixes

phabricator-migrator · February 19, 2024, 5:44pm

Information

ID: 633
PHID: PHID-TASK-flpwr72myuwazdj5tldq
Author: Patrick
Status at Migration Time: wontfix
Priority at Migration Time: Normal

Description

Comments

Patrick

2017-02-15 20:57:45 UTC

echo "$XDG_CONFIG_DIRS"

kf5-config --path config
KDE System Administration/Environment Variables - KDE UserBase Wiki

Might have found a fix for the config packages.

https://github.com/Whonix/Whonix/commit/ad22dbe703870f385d5a55e3fde5369d7b017d9e

https://github.com/Whonix/kde-apper-no-autoupdate/commit/b82e5b6281a13b290bd8338eaa3affcb2075c81c

…

Patrick

2017-02-19 23:00:54 UTC

marmarek

2017-02-19 23:59:36 UTC

Patrick

2017-02-20 00:27:49 UTC

Yay! That fixed it.

Also more path changes will be required. Similar to the following commit.

https://github.com/Whonix/kde-dolphin-menubar-enable/commit/0dd6508f998e7df6df34e2d40a04247bbe1eaf20

Do you think the following /etc/X11/Xsession.d drop-in looks alright?
if [ -z "$XDG_CONFIG_DIRS" ]; then
   export XDG_CONFIG_DIRS=/usr/share/kde-dolphin-menubar-enable/:/etc/xdg
else
   export XDG_CONFIG_DIRS=/usr/share/kde-dolphin-menubar-enable/:$XDG_CONFIG_DIRS
fi

marmarek

2017-02-20 00:38:24 UTC

Patrick

2017-02-21 21:32:30 UTC

Patrick

2017-02-21 23:52:03 UTC

JasonJAyalaP

2017-07-09 02:00:07 UTC

JasonJAyalaP

2017-07-09 02:00:45 UTC

Patrick

2017-07-09 10:43:44 UTC

Patrick

2017-07-09 10:47:24 UTC

JasonJAyalaP (Jason J. Ayala P.):

JasonJAyalaP added a comment.

disable screen saver - implemented in
https://github.com/Whonix/power-savings-disable-in-vms - TODO test

After install of Whonix 14, energy savings is disabled and screen
lock is off.

A new build or Whonix 14.0.0.2.6?

I turned on screen lock and installed the package, but the screen
lock stays on. I’m not sure how to load powerdevil from the command
line.

Installing the package won’t make a difference for already created (and
previously booted) user accounts. This is rather tedious to debug. See:

'[kde] kde settings files / packages - debugging and changing user settings as a distribution' - MARC

Should add for that KDE config package (which other packages have) to
debian/control package description:

This package only takes effect for newly created user accounts. Not
for existing user accounts. This package is most useful to help Linux
distribution maintainers setting divergent defaults.

Patrick

2017-07-09 10:50:15 UTC

JasonJAyalaP

2017-07-11 21:33:10 UTC

Patrick

2017-07-11 22:00:14 UTC

Patrick

2017-07-11 22:01:53 UTC

JasonJAyalaP

2017-07-12 00:00:29 UTC

Patrick

2017-07-12 09:59:56 UTC

JasonJAyalaP

2017-07-12 23:24:26 UTC

Patrick

2017-07-13 12:59:32 UTC

JasonJAyalaP

2017-07-13 18:13:13 UTC

JasonJAyalaP

2017-09-20 17:48:34 UTC

JasonJAyalaP

2017-09-22 22:04:59 UTC

our gtkrc sets the Oxygen theme for gtk applications in plasma 5. However, plasma 5 switched from oxygen to breeze.

Should gtkrc and gtkrc-2.0:
include "/usr/share/themes/oxygen-gtk/gtk-2.0/gtkrc"
gtk-theme-name="oxygen-gtk"
Be changed to?:
include "/usr/share/themes/Breeze/gtk-2.0/gtkrc"
gtk-theme-name="Breeze"
Edit:

I see that
https://github.com/Whonix/kde-lowfat/blob/master/usr/share/kde-lowfat/kdeglobals

Is attempting to change the widget (but not desktop) theme to oxygen (and failing → kcmshell5 style).

Why not change gtk widget to breeze (gtk) and keep both default plasma 5 widget and desktop themes?

JasonJAyalaP

2017-09-22 22:25:26 UTC

Patrick

2017-09-23 12:40:01 UTC

Patrick

2017-09-23 12:43:01 UTC

JasonJAyalaP

2017-09-25 23:37:28 UTC

Our package kde low fat does more than freeing ram. It includes XGD config files like gtkrc which change the widget styles for gtk programs running in kde. It also turns sounds off for privacy. The kded options that disable background service can’t possibly provide a signficant change in performance. At least not enough to be worth the maintenance burden. Is it more about attack surface, then?

https://github.com/Whonix/kde-lowfat/blob/master/usr/share/kde-lowfat/gtkrc
Design Documentation

Fixing the files inside low fat is on the Whonix 14 KDE TODO, which I’ve been working extensively on.

Design Documentation

Shall I remove the files and settings in low fat not related to performance? gtkrc and gtkrc2 count. Inside kdeglobals there’s something for change the widgets too. All needless in my opinion. And broken anyways. And certainly not lowfat.

Should the no-sounds configuration and kdedrc configurations be part of a disable-non-essential-services package?

For kdelowfat, I suggest

(1) remove the theme/widget (kde defaults are fine) files+configurations.
(2) remove the broken krunner stuff (I don’t see the privacy argument for it).
(3) break out the privacy/security stuff into a separate (or move to another?) package

Patrick

2017-09-26 07:24:13 UTC

JasonJAyalaP (Jason J. Ayala P.):

JasonJAyalaP added a comment.

Our package kde low fat does more than freeing ram. It includes XGD
config files like gtkrc which change the widget styles for gtk
programs running in kde.

Maybe that’s not important anymore in KDE plasma (stretch version we’re
using in developers-only version of Whonix 14). Probably not worth
loosing sleep for.

It also turns sounds off for privacy.

That’s actually up to a different package
https://github.com/Whonix/kde-sounds-off.

The
kded options that disable background service can’t possibly provide a
signficant change in performance. At least not enough to be worth the
maintenance burden. Is it more about attack surface, then?

Forget about performance for simplicity if too hard. (performance)

Please check attack surface. (security)

Please check if it confuses users. (usability)

Please check if it causes any unnecessary network traffic by reading
KDED - KDED and some search
engine reading about these services. (privacy)

https://github.com/Whonix/kde-lowfat/blob/master/usr/share/kde-lowfat/gtkrc

Design Documentation

Fixing the files inside low fat is on the Whonix 14 KDE TODO, which
I’ve been working extensively on.

Design Documentation

Shall I remove the files and settings in low fat not related to
performance? gtkrc and gtkrc2 count.

Yes.

Inside kdeglobals there’s
something for change the widgets too. All needless in my opinion. And
broken anyways. And certainly not lowfat.

Ok.

Should the no-sounds configuration and kdedrc configurations be part
of a disable-non-essential-services package?

No, too much work yet another package.

For kdelowfat, I suggest

(1) remove the theme/widget (kde defaults are fine)
files+configurations.

Ok.

(2) remove the broken krunner stuff (I don’t
see the privacy argument for it).

Possibly depending on above list, yes.

(3) break out the privacy/security
stuff into a separate (or move to another?) package

Please tell me what’s left after this exchange in this message.

JasonJAyalaP

2017-09-27 07:15:55 UTC

Patrick

2017-09-27 07:47:54 UTC

! In T633#14584, @JasonJAyalaP wrote:
Removing the useless stuff in kdelowfat, here’s what’s left:

https://github.com/Whonix/kde-lowfat/blob/master/usr/share/kde-lowfat/kdeglobals
** Turns off graphics effects

Useful indeed.

https://github.com/Whonix/kde-lowfat/blob/master/usr/share/kde-lowfat/kdedrc
** Turns off some background services for kde/plasma.
** Someone at some point needs to go through the services loaded on stretch/plasma 5.8 and decide what should be turned off. Whonix 15?

Pretty essential we don’t have privacy violating stuff there or security worsening. So this should be part of this ticket and Whonix 14.

https://github.com/Whonix/kde-lowfat/blob/master/usr/share/kde-lowfat/ksmserverrc
** Turns of desktop resuming feature
** Vaguely a performance thing (forces you to reopen only what you need?)
** Usability issue: We’re going against KDE’s usability decision (default is resume session)

Alright. Resuming the session sounds good.

JasonJAyalaP

2017-09-27 07:56:10 UTC

the kgpgrc file simply has no effect. (https://github.com/Whonix/kde-kgpg-tweaks/blob/master/usr/share/kde-kgpg-tweaks/kgpgrc)

And I don’t see what tools I have to debug it.

I wonder:
We currently don’t make use of /etc/skel/. Any files here are copied to a new user’s account upon creation. (Our configs are only expect to work on new user accounts as well).

How does using /etc/skel to place files like kgpgrc, kdeglobals, …, compare to XDG_DIR? I think the biggest difference: Multiple snippets from multiple packages for the same rc file can be used by XDG. Modularity and cleaner code.

But in the case of kgpgrc? Doesn’t even work with XDG. Can we use skel here? We’d have to make sure it was the only package that adds a kgpgrc file to /etc/skel, correct? There would have to be a monolithic “whonix-ws-skel” package that includes “every config that can’t be done via XDG snippets”. Better than nothing.

JasonJAyalaP

2017-09-27 07:55:00 UTC

Another thought. In '[kde] kde settings files / packages - debugging and changing user settings as a distribution' - MARC you mentioned the limitation:
This package only takes
effect for newly created user accounts. Not for existing user accounts.
This package is most useful to help Linux distribution maintainers
setting divergent defaults.
and wondered if there were a way to override current user settings upon install. My guess: Only via kwriteconfig commands via postinst.

Patrick

2017-09-27 12:08:26 UTC

JasonJAyalaP (Jason J. Ayala P.):
Another thought. In '[kde] kde settings files / packages - debugging and changing user settings as a distribution' - MARC
you mentioned the limitation:
This package only takes
effect for newly created user accounts. Not for existing user
accounts.
This package is most useful to help Linux distribution maintainers
setting divergent defaults.
This is a bad enough limitation. Even worse would be “only works for
user ‘user’”.

the kgpgrc file simply has no effect. (https://github.com/Whonix/kde-kgpg-tweaks/blob/master/usr/share/kde-kgpg-tweaks/kgpgrc)

And I don’t see what tools I have to debug it.

Not sure what you mean. It’s about kgpg. Keep changing kde xdg
settings, restart kde, restart kgpg with no config at all until
pre-configuration changes materialize.

Other options:

contact slayer on irc

contact the kgpg developer

see how other linux distributions do similar stuff
– (T636#13037 or elsewhere)

Linux Mint used to pre-configure kgpg.

Bug #1531505 “Faulty default kgpgrc file” : Bugs : Linux Mint

Dunno if they still do that. If so… How are they doing it in their
current Debian stretch based version?

I wonder:
We currently don’t make use of /etc/skel/. Any files here are copied to a new user’s account upon creation. (Our configs are only expect to work on new user accounts as well).

/etc/skel/ is not suitable. We just change a few settings and leave the
rest implicit up to KDE defaults. If we ship an explicit config file, we
run into follow-up issues such as missing config entries (that KDE by
default had added by default otherwise). Harder to maintain. (Before KDE
switched to xdg this required virtually no maintenance after the initial
development.) Also violates Debian policy since /etc/skel/ is for local
system administrators, not distributions/packages.

and wondered if there were a way to override current user settings
upon install. My guess: Only via kwriteconfig commands via postinst.

Hard.

Has to run as user to change the user settings, not as root.

Limits to user user.

Since stretch, apt-get complains (and even aborts if I remember right)
when sudo -u user something is being used.

Debian hates it. Such packages have never a chance to be accepted in
Debian. This is still a long term goal to reduce maintenance work.

It could run at first boot as user user (to be not part of Debian
maintainer scripts) but that’s still not a canonical/clean solution
since it breaks the xdg hierarchy.

JasonJAyalaP

2017-10-02 22:29:12 UTC

JasonJAyalaP

2017-10-02 22:38:40 UTC

JasonJAyalaP

2017-10-02 22:40:03 UTC

Patrick

2017-10-03 12:03:36 UTC

Patrick

2017-10-03 12:17:09 UTC

! In T633#14592, @JasonJAyalaP wrote:
RE: KGPG
As far as I can tell, from examing how kubuntu does it and asking both in kde forums (https://forum.kde.org/viewtopic.php?f=225&t=141955&p=381843#p381843) and kde-devel, Kgpg is not affected by XDG (plasma 5), only /etc/kde4rc (KDE4)

We would need a package that change’s /etc/kde4rc and adds kgpg-tweaks/ there

It would be a “kde4 apps/config” package that changes kde4rc for all kde4 apps (if there are more than kgpg).

Not modular like xdg and shareable, unfortunately.

Alright. It’s the only doable solution then. Please go ahead and use /etc/kde4rc.

If we only need this on the workstation, then https://github.com/Whonix/whonix-ws-kde-desktop-conf would be the best fit. But I guess we’ll need it sooner or later on the gateway as well. Not for kgpg but for other stuff. In that case we would have to duplicate that file in https://github.com/Whonix/whonix-gw-kde-desktop-conf. If it’s not a complex file… Not a big problem.

Alternatively add that file to GitHub - Whonix/whonix-base-files if the same one should be installed on the workstation and gateway at the same time.

So far about /etc/kde4rc.

If config file is required to be placed in folder /usr/share/anon-kde/kde4-profile/default/share/config/ that however should go into the https://github.com/Whonix/kde-kgpg-tweaks package.

Netrunner is using that method as well.

netrunner-default-settings/etc/kde4rc at master · netrunner-kubuntu-legacy/netrunner-default-settings · GitHub

netrunner-default-settings/usr/share/netrunner-default-settings/kde4-profile/default/share/config at master · netrunner-kubuntu-legacy/netrunner-default-settings · GitHub

Patrick

2017-10-03 12:27:20 UTC

! In T633#14593, @JasonJAyalaP wrote:
@Patrick
I’ve come to a suggestion for all but 2 items in the whonix 14 list. Please review:
Design Documentation

[Suggest: Can’t fix] How to tell KDE to use no arrows and no italic font for symlinked desktop icons? [Suggest: Can’t fix] How to tell KDE to use no arrows and no italic font for symlinked desktop icons?

Yes.

arrow → hackish → rename all the emblem-symbolic-link.* files (inside theme?) .bak or replace with transparent image.

Too hackish.

italics → no leads. Need kde dev to confirm.

Yes.

[Suggest: Review in 15] https://github.com/Whonix/kde-lowfat/tree/master/usr/share/kde-lowfat

Review in next build.

(Works) kdeglobals (https://github.com/Whonix/kde-lowfat/blob/master/usr/share/kde-lowfat/kdeglobals)
(Works) kdedrc (https://github.com/Whonix/kde-lowfat/blob/master/usr/share/kde-lowfat/kdedrc)
No module set to “false” is loaded in in Whonix 14.0.0.5.0
TODO: Review which modules we want loaded

Ok

(Works) ksmserverrc (https://github.com/Whonix/kde-lowfat/blob/master/usr/share/kde-lowfat/ksmserverrc)
Default stretch will “Restore previous session” “on login” under Desktop Session system settings module
Whonix will “Start with empty session”
(TODO Usability) Does KDE’s usability decision not apply to us? Will “accidentally” restoring sensitive applications and files hurt security? Not any protection against forensics.

We can go with stretch default “Restore previous session” “on login”. No change required (besides removing the old broken code).

[Suggest: KDE4RC package for 14 or 15] fix https://github.com/Whonix/kde-kgpg-tweaks

Answered in my previous comment T633#14596.

[Suggest: Find plasma 5 script-person?] fix “KDE Desktop Settings for Whonix-Workstation (TODO: not GS?). Enables KDE folderview (allows desktop shortcuts) and sets Whonix specific wallpaper.”

Find plasma 5 script person is fine. But contents/default also doesn’t sound bad. It’s working with XDG? Just a drop-in folder? Why not?

[Works if “multi user” isn’t supported in Whonix] Desktop shortcuts

Ok.

JasonJAyalaP

2017-10-04 03:34:58 UTC

[Suggest: Review in 15] https://github.com/Whonix/kde-lowfat/tree/master/usr/share/kde-lowfat
review in next build

The review questions are:
(1) Are all the modules we’re disabling giving us performance in return for possible usability and support problems?
(2) Are there any modules that are loaded by plasma 5 right now that should be disabled for performance?

I don’t know how to answer those questions. That’s why I suggested “dealing with it later”. You can view “background services” with:
kcmshell5 kcmkded

Find plasma 5 script person is fine. But contents/default also doesn’t sound bad. It’s working with XDG? Just a drop-in folder? Why not?

contents/default is a non-XDG way. Not a folder. default is a config file and is part of plasma 5, which (we) might break or could change.

JasonJAyalaP

2017-10-04 04:20:25 UTC

/etc/kde4rc

Brainstorming:
ws-desktop-conf places/overwrites /etc/kde4rc with:
[Directories-default]
prefixes=/usr/share/anon-ws-kde4-defaults/
And in kde-kgpg-tweaks (and for any kde4 apps), the app-rc file is placed at
/usr/share/anon-ws-kde4-defaults/share/config/

(It seems that kde4-profile/default/ isn’t magical but share/config is)

But one thing: Are you sure you’d rather have a separate .deb for every kde4 setting instead of one package that has all rc files in? (Instead of kgpg-tweaks, just kde4-defaults). Wouldn’t it be easier, for our own use, to have one .deb file (with both kde4rc and apprc files)?

Even easier: Just put it all in whonix-ws-desktop-conf

Separating the apps lets other distros install the .deb… but only if they setup kde4rc first, either manually or automatically if they install… well, we’d have to make a kde4rc package (instead of ws-desktop-conf, which I assume other people wouldn’t want just to setup kde4rc). But in the case of kde4rc.deb + app1.deb + appN.deb, it really wouldn’t be shareable anyway because it work nuke their existing kde4rc.

Conclusion:
If it’s just for whonix, I suggest a “whonix-ws-kde4-settings” package with both kde4rc and all appfiles. Or put it all in the current whonix-ws/gw-desktop-conf packages. Or if you want to avoid duplication of kde4rc, put that in base and whonix-ws/gw-desktop-conf will depend on that.

If you think other people will install our app1-rc.deb package and then manually edit their /etc/kde4rc, we can put our kde4rc in ws-desktop and separate packages for each app.

(I hate to be pessimistic, but I think option 2 would be another case of “whonix doing it better than every one else, but no one caring”).

Oh, maybe: Separate debs also avoids code duplication if some apps overlap ws and gw and you don’t want unused app-rc files in either:

kde4rc in base
and then ws and gw can include the apprc files they want.

Lots of (pre-mature) optimization there. We will have a huge list of kde4 packages if we every change as many defaults of those other distros do.

Patrick

2017-10-04 17:30:07 UTC

! In T633#14598, @JasonJAyalaP wrote:
[Suggest: Review in 15] https://github.com/Whonix/kde-lowfat/tree/master/usr/share/kde-lowfat
review in next build

The review questions are:
(1) Are all the modules we’re disabling giving us performance in return for possible usability and support problems?
(2) Are there any modules that are loaded by plasma 5 right now that should be disabled for performance?

Alright. Please list which modules after next build.

I don’t know how to answer those questions. That’s why I suggested “dealing with it later”. You can view “background services” with:
kcmshell5 kcmkded

Find plasma 5 script person is fine. But contents/default also doesn’t sound bad. It’s working with XDG? Just a drop-in folder? Why not?

contents/default is a non-XDG way. Not a folder. default is a config file and is part of plasma 5, which (we) might break or could change.

What’s exactly the file location?

Patrick

2017-10-04 17:35:58 UTC

! In T633#14599, @JasonJAyalaP wrote:
/etc/kde4rc

Brainstorming:
ws-desktop-conf places/overwrites /etc/kde4rc with:
[Directories-default]
prefixes=/usr/share/anon-ws-kde4-defaults/
And in kde-kgpg-tweaks (and for any kde4 apps), the app-rc file is placed at
/usr/share/anon-ws-kde4-defaults/share/config/

(It seems that kde4-profile/default/ isn’t magical but share/config is)

But one thing: Are you sure you’d rather have a separate .deb for every kde4 setting instead of one package that has all rc files in? (Instead of kgpg-tweaks, just kde4-defaults). Wouldn’t it be easier, for our own use, to have one .deb file (with both kde4rc and apprc files)?
New package anon-kde-config that deprecates all our packages starting with kde-*. In Whonix 15 or 16.

Even easier: Just put it all in whonix-ws-desktop-conf

Only stuff that is Whonix specific there. Still good enough. Can reduce many packages to three or so.

Separating the apps lets other distros install the .deb… but only if they setup kde4rc first, either manually or automatically if they install… well, we’d have to make a kde4rc package (instead of ws-desktop-conf, which I assume other people wouldn’t want just to setup kde4rc). But in the case of kde4rc.deb + app1.deb + appN.deb, it really wouldn’t be shareable anyway because it work nuke their existing kde4rc.

It’s true. Looks like sharing such packages doesn’t easily fly anyhow. At this point I doubt anyone would reuse it or upload to Debian. So we can as well as pack all the KDE stuff together into one package.

Conclusion:
If it’s just for whonix, I suggest a “whonix-ws-kde4-settings” package with both kde4rc and all appfiles.

call it anon-kde-config

If you think other people will install our app1-rc.deb package and then manually edit their /etc/kde4rc, we can put our kde4rc in ws-desktop and separate packages for each app.

Unlikely indeed.

Oh, maybe: Separate debs also avoids code duplication if some apps overlap ws and gw and you don’t want unused app-rc files in either:

The unused is not so bad. Lets say unused kgpg config on the gateway wouldn’t hurt if it came from anon-kde-config package.

Lots of (pre-mature) optimization there. We will have a huge list of kde4 packages if we every change as many defaults of those other distros do.

Yes. To split it into that many packages originally wasn’t a too good design decision.

Patrick

2017-10-04 17:37:06 UTC

JasonJAyalaP

2017-10-04 20:33:03 UTC

Patrick

2017-10-04 23:00:41 UTC

JasonJAyalaP (Jason J. Ayala P.):

JasonJAyalaP added a comment.

contents/default is a non-XDG way. Not a folder. default is a config file and is part of plasma 5, which (we) might break or could change.

/usr/share/plasma/shells/org.kde.plasma.desktop/contents/defaults

Whonix 14: kderc file in whonix-(gw|ws)-kde-config plus the existing kde config packages

Do you mean https://github.com/Whonix/whonix-ws-kde-desktop-conf ? (Which is currently broken)

I meant whonix-ws-kde-desktop-conf, yes. (And whonix-gw-kde-desktop-conf
when needed.)

Or do you want to create a new package? We might as well create anon-kde-config now then.

I was going to say, too much work, Whonix 15 / 16… On the other hand,
handing /etc/kderc from whonix-ws-kde-desktop-conf to anon-kde-config
could be cumbersome later on. This is because the two packages may not
own the same file or apt-get will break. And anon-kde-config also
couldn’t say Replaces: whonix-ws-kde-desktop-conf, because that
package isn’t to be totally deprecated.

anon-kde-config… Actually… Why not anon-apps-config.

Why? Like anon-gpg-conf… Such small packages have no chance to make it
into Debian. They say the effort/overhead is too big.

So yes, please for #Whonix_14:

move all files from all packages starting with kde-* and
anon-kde-streamiso to a new package anon-apps-config

add a commit message - migrating from … and link to this ticket

migrate all debian/control files descriptions, build dependencies,
dependencies, recommends and whatnot from kde-* packages and create a
combined debian/control file

add etc/kderc to anon-apps-config

remove all kde-* packages from #anon-meta-packages 's debian/control.

in separate commit, add anon-apps-config to #anon-meta-packages 's
debian/control

finally git rm the kde-* from the Whonix/Whonix folder packages

I suggest “anon-kde4-config”, btw. Since it’s only for kde4 apps.

I don’t like too specific package names. It’s a lot hassle to rename a
package and not breaking the packaging system on major upgrades. I
wouldn’t want a separate anon-kde5-config package.

JasonJAyalaP

2017-10-06 21:28:27 UTC

JasonJAyalaP

2017-10-06 22:46:04 UTC

Patrick

2017-10-07 14:48:28 UTC

JasonJAyalaP

2017-10-08 02:34:26 UTC

kde-privacy “Deactivates klipper autostart”, in inside klipperrc is
[General]
KeepClipboardContents=false
#AutoStart=false

#[Notification Messages]
#StartAutomatically=false
Why was it commented out? Broken? Did it ever work? Does disabling clipboard history improve privacy/forensics enough to be worth the usability loss?

Patrick

2017-10-08 09:05:15 UTC

JasonJAyalaP (Jason J. Ayala P.):
JasonJAyalaP added a comment.

kde-privacy “Deactivates klipper autostart”, in inside klipperrc is
[General]
KeepClipboardContents=false
#AutoStart=false

#[Notification Messages]
#StartAutomatically=false
Why was it commented out? Broken?
Was decided to keep the default to autostart it. Otherwise the clipboard
is deleted once an application it was copied from has been closed.

Did it ever work?

Clipboard history disabling is functional in Whonix 13.

Does disabling clipboard history improve privacy/forensics enough to be worth the usability loss?

There was a discussion about this. Long time ago. Somewhere. It stores
passwords to the disk that otherwise not necessarily would have been stored.

JasonJAyalaP

2017-10-19 00:09:28 UTC

RE: kde-konsole-unlim scrollback

The big problem was in the Xsessions file:
https://github.com/Whonix/kde-konsole-unlim-scrollback/commit/36492df59602f2e4a0fd714b7f8e05fb3e2b5ba2

#export XDG_DATA_HOME=/usr/share/kde-konsole-unlim-scrollback/share:$XDG_DATA_HOME
You can NOT add to xdg_data_home. It has to one single directory, and there’s no practical reason to change it. The “multi-folder”-search-path is XDG_DATA_DIRS, which is used after xdg_data_home is searched. (note: $XDG_CONFIG_DIRS is the multi-folder search path after $XDG_CONFIG_HOME)

https://specifications.freedesktop.org/basedir-spec/basedir-spec-0.6.html#basics

With the above commit, it works. Our konsole/ folder is searched, and Shell.profile is found and used, since there is no other profile.

…Except for a bug in konsole:
After not finding konsolerc in XDG_CONFIG_HOME, it should search XDG_CONFIG_DIRS for konsolerc. It does not. Instead, it creates a default konsolerc in XDG_CONFIG_HOME.

…However, our konsolerc does nothing except say “use shell.profile as default”. This isn’t necessary because konsole will find shell.profile and use it since it’s the only profile it finds on a default install.

Suggestion:

Simply git rm konsolerc. Package works with the above fixes.

File a bug report against konsole to be nice. Maybe.

Rename Shell.profile to “UnlimitedScrollback.profile” ?

Patrick

2017-10-19 07:03:25 UTC

Patrick

2017-10-23 15:02:16 UTC

What I could gather from the KDE meetup…

there is no repository of KDE plasma 5 that targets maintenance of Debian stretch, so we’re stuck with the version currently in Debian stretch or asking for trouble

/etc/kde4rc - there is really no .d folder

/etc/kde4rc - deprecated in plasma 5

/etc/kde4rc - no one of KDE can help with this since they’re all full plasma 5 now

how to know what rc files for kde/plasma are valid in xdg and kde4rc?
** In plasma 5 everything is XDG.
** For kde4 there is no answer.

How to view current applied settings?
** use kreadconfig

Is there in-memory caching of configuration files?

There is no in-memory configuration files memory caching without running application.

is there a joint config file? how to view it? is it only in memory?

How to quickly/easily debug? Kill app, new user account?
** Just restart the application.

How to use arrows in .desktop files?
** Use Type=application in desktop files.

plasma 5 scripting to set desktop image and enable folderview (for desktop shortcuts)

https://github.com/Whonix/whonix-ws-kde-desktop-conf

folderview is the default once KDE 5.10

enable sdwdate-gui systray in KDE plasma 5 by default T636

requires a look and feel packages
** look an feel packages support inheritance
** we only need one look and feel package (we use anon-apps-config for that?)
**** How to know what to write into that? Change the setting manually. Look how the initialization script looks inside the home folder. Copy it and use it as the look and feel package’s initialization script.
**** see example here https://github.com/netrunner-artwork/artwork-lnf-netrunner-core/tree/master/usr/share/plasma/look-and-feel
** for questions e-mail kde-devel and cc hein@kde.org

clock widget should show seconds by default
** may or may not have a ticket yet
** was and old idea to show users that the clock differs in gateway, workstation and host
** requires a look and feel package
*** requires an initialization script

JasonJAyalaP

2017-10-26 01:20:37 UTC

Patrick

2017-10-26 15:00:17 UTC

JasonJAyalaP

2017-10-27 00:49:46 UTC

Patrick

2017-10-27 12:04:27 UTC

JasonJAyalaP

2017-11-11 01:13:51 UTC

https://forum.kde.org/viewtopic.php?f=227&t=142821

[Bug] Konsole doesn’t search $XDG_CONFIG_DIRS for konsolerc

Konsole successfully searches $XDG_DATA_HOME (~/.local/) then $XDG_DATA_DIRS (~/usr/share/my-distro-package/) for its konsole/ data directory, finding my Shell.profile, which is for my distro’s users (Whonix).

The problem is .konsolerc. Konsole searches $XDG_CONFIG_HOME (~/.config/) for .konsolerc. If it doesn’t find it there (which it won’t upon first use), it should then search $XDG_CONFIG_DIRS. However, it does not. Instead it creates a default .konsolerc in $XDG_CONFIG_HOME. I even did chmod -rw .konsolerc. This makes Konsole complain, but it will never find my distro’s .konsolerc via $XDG_CONFIG_DIRS.

There’s more strangeness: There seems to be a “hidden” config file somewhere for Konsole. If I go into Konsole settings, I can see that Shell.profile is listed. Despite being the only profile, it is not used by default. Instead, some hardcoded profile named “Default” is used. The weirdness? If I set Shell.profile to be the active and default profile, I can see that this change is written to ~/.config/konsolerc. If I then delete ~/.config/konsolerc and restart Konsole, Shell.profile is still active! (Quite misleading for me while debugging)!

Note: Shell.profile simply enables unlimited scrollback. I want this to be the default upon bootup for our users, configured via XDG and not /etc/skel or by changing files in ~.

Patrick

2017-11-11 10:49:25 UTC

Patrick

2018-11-20 15:57:49 UTC