Description
Details
- Impact
- Normal
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Resolved | None | T636 enable sdwdate-gui systray by default | ||
| Wontfix | None | T633 Non-Qubes-Whonix KDE plasma 5 fixes |
Event Timeline
echo "$XDG_CONFIG_DIRS" kf5-config --path config
https://userbase.kde.org/KDE_System_Administration/Environment_Variables#XDG_CONFIG_DIRS
Might have found a fix for the config packages.
https://github.com/Whonix/anon-meta-packages/commit/173bac9f22b6bc0e63aecd774cfc3c776ce27497
Doesn't work. Breaks the desktop.
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
Slightly reduced duplication:
if [ -z "$XDG_CONFIG_DIRS" ]; then
XDG_CONFIG_DIRS=/etc/xdg
fi
export XDG_CONFIG_DIRS=/usr/share/kde-dolphin-menubar-enable/:$XDG_CONFIG_DIRSdisable 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.
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.
fix desktop shortcuts - TODO test
Deleted desktop shortcuts, installed package, shortcuts returned.
Same in WS.
These TODO test require a new build of Whonix 14. No testing required
for Whonix 14.0.0.2.6.
TODO test fixes were added after 14.0.0.2.6 but to really test
these, a newer version has to be build and tested.
JasonJAyalaP (Jason J. Ayala P.):
JasonJAyalaP added a comment.
disable screen saver - implemented in
https://github.com/Whonix/power-savings-disable-in-vms - TODO testAfter 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:
https://marc.info/?l=kde&m=141130406809446&w=2
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.
TODO test is currently used for the same as phabircator status review is most times used. It means, when there is a new Whonix build, it needs to be tested if it works there. Perhaps also if it works for upgraded systems.
@Patrick can you confirm what in that list is for the next build? I can edit that list and remove everything with a strikethrough... or moved it to another section (why the strikethrough?). Only the items with the extra words "TODO test", correct?
On https://www.whonix.org/wiki/Dev/KDE#Whonix_14_TODO ...
Generally up to date.
What says
- done - is already done in and tested in 14.0.0.2.6
- TODO test - is done in latest git master, should work, but needs to be tested in next Whonix build
- other comments should be self-explanatory
fix https://github.com/Whonix/kde-konsole-unlim-scrollback broken TODO
Means: No solution for #kde-konsole-unlim-scrollback found yet.
fix "KDE Desktop Settings for Whonix-Workstation. Enables KDE folderview (allows desktop shortcuts) and sets Whonix specific wallpaper."
https://github.com/Whonix/whonix-gw-kde-desktop-conf
https://github.com/Whonix/whonix-ws-kde-desktop-conf
Means: No solution for #whonix-ws-kde-desktop-conf and #whonix-gw-kde-desktop-conf was found yet.
Yes, since that is confusing... Feel free to move all that is done (striked through) to a section saying done. (It's to keep track what was already done.)
https://github.com/Whonix/knetattach-hide - still working? still needed?
In deb 9, /usr/share/applications/kde4/knetattach.desktop still exists, but the updated file is now
/usr/share/applications/org.kde.knetattach.desktop
This package was only meant to hide a link to it from the k menu? Both files have "NoDisplay=True", and I don't see it in the menu. You have to run it manually or through Dolphin -> Network -> Add -> Execute (Why there's a warning asking you if want to cancel or open the file to view its text... is a reason why it still ain't the year of the Linux desktop /rant)
JasonJAyalaP (Jason J. Ayala P.):
JasonJAyalaP added a comment.
This package was only meant to hide a link to it from the k menu?
No, to hide knetattach from the start menu.
Sorry, that's what I meant.
But knetattach isn't in the start menu of debian 9. It's new (and old) .desktop file in /usr/share/applications both have "NoDisplay=true". No need for manipulating the file, correct?
JasonJAyalaP (Jason J. Ayala P.):
JasonJAyalaP added a comment.
Sorry, that's what I meant.
But knetattach isn't in the start menu of debian 9.
Debian 9 with KDE?
It's new (and
old) .desktop file in /usr/share/applications both have
"NoDisplay=true". No need for manipulating the file, correct?
Should be right. As a final test, remove knetattach-hide from
anon-meta-packages for now. Then in the next Whonix build, check if
there are any unwanted start menu entries.
Debian 9 with KDE?
Ok I removed knetattach hide from anon-meta-packages and marked it as TODO test in the wiki.
I ask on kde forums about how to display and confirm settings changed via XDG_CONFIG_DIR
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?
krunnerrc (https://github.com/Whonix/kde-lowfat/blob/master/usr/share/kde-lowfat/krunnerrc) is broken, and all plugins are loaded for krunner. Our config is set to disable a handful of plugins.
Usability: What is the security benefit of disabling these features? There's no additional protection against forensics. Are we worried about the user being shoulder surfed with a camera?
JasonJAyalaP (Jason J. Ayala P.):
JasonJAyalaP added a comment.
our gtkrc
We currently don't modify gtkrc.
Should gtkrc and gtkrc-2.0:
Be changed to?:
Maybe.
But certainly not by writing into /home/user/. There must be a solution
for Linux distributions. It's a good question for slayer on IRC as well.
JasonJAyalaP (Jason J. Ayala P.):
Usability: What is the security benefit of disabling these features?
lowfat refers to to speed up the VM / have more free RAM by disabling
stuff that isn't useful inside VMs.
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
https://www.whonix.org/w/index.php?title=Dev/KDE&stable=0#knotifyrc
Fixing the files inside low fat is on the Whonix 14 KDE TODO, which I've been working extensively on.
https://www.whonix.org/w/index.php?title=Dev/KDE&stable=0#Whonix_14
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
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
https://api.kde.org/frameworks/kded/html/index.html and some search
engine reading about these services. (privacy)
https://github.com/Whonix/kde-lowfat/blob/master/usr/share/kde-lowfat/gtkrc
https://www.whonix.org/w/index.php?title=Dev/KDE&stable=0#knotifyrc
Fixing the files inside low fat is on the Whonix 14 KDE TODO, which
I've been working extensively on.https://www.whonix.org/w/index.php?title=Dev/KDE&stable=0#Whonix_14
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.
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
- 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?
- 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)
I committed the changes to master.
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.
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.
Another thought. In https://marc.info/?l=kde&m=141130406809446&w=2 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.
JasonJAyalaP (Jason J. Ayala P.):
Another thought. In https://marc.info/?l=kde&m=141130406809446&w=2
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.
https://bugs.launchpad.net/linuxmint/+bug/1531505
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.
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.
@Patrick
I've come to a suggestion for all but 2 items in the whonix 14 list. Please review:
https://www.whonix.org/w/index.php?title=Dev/KDE&stable=0#TODO
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 https://github.com/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.
[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.
[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.
/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.
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 kcmkdedFind 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?
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.
Im sumary:
- Whonix 15 / 16: anon-kde-config plus whonix-(gw|ws)-kde-config
- Whonix 14: kderc file in whonix-(gw|ws)-kde-config plus the existing kde config packages
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)
Or do you want to create a new package? We might as well create anon-kde-config now then.
I suggest "anon-kde4-config", btw. Since it's only for kde4 apps.
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.
I instinctively started adding whonix-ws-desktop-shortcuts. But should that package, and similar ones like whonix-ws-start-menu-additions, which depend on the desktop manager (KDE) be part of this package? Oh only the *kde* ones?
Ignore this comment. I forgot about the magic directory. I'll try putting kde4 rc-files in /usr/share/anon-apps-config/share/config. I'm going to assume that XDG won't recursively search (or that it won't matter).
<s>
Should kde4 rc-files (kgpgrc) share the same directory (/usr/share/anon-apps-config) as XDG snippets (dolphinrc)? I'm assuming they just ignore each other. It would be nice to have one folder (not /anon-apps-config-kde4 and /anon-apps-config-xdg), with both xsession.d/50anon-apps-config and /etc/kderc pointing to it.
</s>
JasonJAyalaP (Jason J. Ayala P.):
JasonJAyalaP added a comment.
I instinctively started adding whonix-ws-desktop-shortcuts. But
should that package, and similar ones like
whonix-ws-start-menu-additions,
These no, since Whonix specific.
which depend on the desktop manager
(KDE) be part of this package? Oh only those kde* ones?
Only listed ones. But if I forgot any, feel free to suggest while we are
at it.
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?
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.
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" ?
Yes.
- File a bug report against konsole to be nice. Maybe.
Yes.
- Rename Shell.profile to "UnlimitedScrollback.profile" ?
Vary.
Shell.profile is the default.... Having UnlimitedScrollback.profile could lead to having the default Shell.profile created?
Should be fine since it's in sub folder /usr/share/kde-konsole-unlim-scrollback/[...]?
Might not work since default is Shell.profile, not UnlimitedScrollback.profile, so we might have to configure default to be UnlimitedScrollback.profile? That would be weird.
I guess if it works as is now without disadvantage just call it done.
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
I'm having success with kde4rc. Kgpg settings were sucessfully applied, for example, and user modifications to kgpg settings are written to $HOME
But, with Kgpg, I ran into a wall:
- If the gpg.conf specified in kgpgrc doesn't exist, kgpg refuses to start. We wish it would create a blank file, but it doesn't.
- If I remove the line gpg_config_path[$e]=$HOME/.gnupg/gpg.conf from our kgpgrc, kgpg will complain to the user and confuse the user, asking to run the first-run assistant to fix the problem.
- In other words:
- if kgpgrc exists, expect gpg_config_path ...or complain and offer first run assistant.
- if kgpgrc and gpg_config_path exist, confirm that gpg.conf exists ..or fail.
Why doesn't gpg.conf not exist? It's here:
https://github.com/Whonix/anon-gpg-tweaks/blob/master/etc/skel/.gnupg/gpg.conf
oh! Ok shouldn't be problem then.
anon-apps-config should have anon-gpg-tweaks as a dependency then. Or maybe not. I dunno. Your call.
JasonJAyalaP (Jason J. Ayala P.):
JasonJAyalaP added a comment.
oh! anon-apps-config should have anon-gpg-tweaks as a dependency then.
Not great, but yes, and in Whonix 15, merge anon-gpg-tweaks into
anon-apps-config?
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 ~.
JasonJAyalaP (Jason J. Ayala P.):
Instead, some hardcoded profile named "Default" is used.
We could also provide Default or Default.profile (or all lower case)
- whatever works. No need to keep shell.profile.