date:20151119


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126101/
---

(Updated Nov. 20, 2015, 12:16 a.m.)


Review request for Plasma, Solid, Àlex Fiestas, Aleix Pol Gonzalez, Daniel 
Vrátil, and Martin Gräßlin.


Changes
---

Thanks for reviewing again, latest changes address the remaining comments.

Most interesting change is that the plugin loading argument has moved from 
ConfigOperation into BackendManager, as suggested.

The code is now a bit more agressive towards switching backends, 
shutdownBackend is run whenever the mode or the backend changes. I've added 
there that in case we get a new backend requested, and the new backend would be 
loaded while the old isn't shut down, we run shutdownBackend() anyway. We know 
it's the right thing to do here, so instead of warning, or bailing out, we 
shutdown first, and then continue loading the new backend freshly.

make test passes entirely, though I get dbus timeouts in testconfigmonitor when 
running it directly from the commandline. It may (or may not) be related to the 
backendlauncher not shutting down correctly, but I haven't figured out if 
that's a new problem, or specific to a certain setup. I'll give this another 
good round of real world testing before pushing.


Repository: libkscreen


Description (updated)
---

This patchset adds in-process operation to libkscreen

purpose:
- allow easier debugging
- for some backends (qscreen, upcoming kwayland) the out of process operation 
is not necessary since these backends are well-shielded

This implementation is backwards compatible and opt-in for running setups.

If the user exports KSCREEN_BACKEND_INPROCESS=1 before running, all operations 
will be done in process. Otherwise, the out-of-process mode is used.

Changes revolve around the ConfigOperations, the BackendManager (which 
"factories" the backends, either in- or out-of-process), and the plugin loading 
logic

Autotests should cover all the cases (and actually a few currently unsupported 
ones, such as using different backends in the same process).

Details on performance, etc.: 
http://vizzzion.org/blog/2015/11/wayland-and-libkscreen-benchmarks/


Diffs (updated)
-

  CMakeLists.txt 86a0965 
  autotests/CMakeLists.txt 69af7f0 
  autotests/testconfigmonitor.cpp a051226 
  autotests/testinprocess.cpp PRE-CREATION 
  autotests/testqscreenbackend.cpp da4dbae 
  autotests/testscreenconfig.cpp ecbcedf 
  autotests/testxrandr.cpp b9b838a 
  backends/fake/fake.cpp 60264dd 
  src/backendlauncher/backendloader.cpp 52051df 
  src/backendmanager.cpp ca9c746 
  src/backendmanager_p.h c6418e2 
  src/config.cpp 75d947d 
  src/configmonitor.h b6f1189 
  src/configmonitor.cpp a14bc70 
  src/configoperation.h 2405d79 
  src/configoperation.cpp 87fe141 
  src/configoperation_p.h afdc462 
  src/getconfigoperation.h c85bfaa 
  src/getconfigoperation.cpp 22f92b4 
  src/output.cpp bd381fa 
  src/setconfigoperation.h 020a990 
  src/setconfigoperation.cpp 6ea944f 

Diff: https://git.reviewboard.kde.org/r/126101/diff/


Testing
---

Added a ton of autotests, made sure all existing ones pass.

tried "KSCREEN_BACKEND_INPROCESS=1 kcmshell5 kscreen", all working as expected.


Thanks,

Sebastian Kügler

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126120: [Widget Explorer] Remove uninstalled applets from containments


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126120/
---

(Updated Nov. 19, 2015, 8:25 p.m.)


Status
--

This change has been marked as submitted.


Review request for Plasma.


Changes
---

Submitted with commit f7279f4463a8dc94f7acbaa58006424290026f4b by Kai Uwe 
Broulik to branch Plasma/5.5.


Repository: plasma-workspace


Description
---

There's no point in leaving them there as they will essentially be broken now.


Diffs
-

  components/shellprivate/widgetexplorer/widgetexplorer.cpp 341c9a5 

Diff: https://git.reviewboard.kde.org/r/126120/diff/


Testing
---

Added an applet to my panel and desktop, triggered uninstall, waited for the 
timeout, both applets disappeared.


Thanks,

Kai Uwe Broulik

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126120: [Widget Explorer] Remove uninstalled applets from containments


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126120/#review88627
---

Ship it!


Ship It!

- Marco Martin


On Nov. 19, 2015, 8:16 p.m., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126120/
> ---
> 
> (Updated Nov. 19, 2015, 8:16 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> There's no point in leaving them there as they will essentially be broken now.
> 
> 
> Diffs
> -
> 
>   components/shellprivate/widgetexplorer/widgetexplorer.cpp 341c9a5 
> 
> Diff: https://git.reviewboard.kde.org/r/126120/diff/
> 
> 
> Testing
> ---
> 
> Added an applet to my panel and desktop, triggered uninstall, waited for the 
> timeout, both applets disappeared.
> 
> 
> Thanks,
> 
> Kai Uwe Broulik
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Review Request 126120: [Widget Explorer] Remove uninstalled applets from containments


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126120/
---

Review request for Plasma.


Repository: plasma-workspace


Description
---

There's no point in leaving them there as they will essentially be broken now.


Diffs
-

  components/shellprivate/widgetexplorer/widgetexplorer.cpp 341c9a5 

Diff: https://git.reviewboard.kde.org/r/126120/diff/


Testing
---

Added an applet to my panel and desktop, triggered uninstall, waited for the 
timeout, both applets disappeared.


Thanks,

Kai Uwe Broulik

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126115: Unset environment variables before starting kwin_wayland



> On Nov. 19, 2015, 5:31 nachm., Matthias Klumpp wrote:
> > Okay, I talked to some GNOME people (thanks!) to find out how they handle 
> > this issue, and the short answer is: Not at all
> > Reason for that is that it is really hard to fully secure the compositor if 
> > we allow apps to arbitrarily write to config files in HOME.
> > For example, one process might start to ptrace kwin, catching all input 
> > sent through it. Or someone might install a malicious KWin script. Or the 
> > bad app might install a .desktop file override in .local/share/applications 
> > overriding e.g. Firefox and then catching all the input. Etc.
> > Also, if the attacker went this far, they already have access to all files 
> > in the home directory and likely have reached their goal already.
> > 
> > So, I think we can get KWin secure by adding some really heavy 
> > countermeasures (restricting it's access to $HOME, using a setgid bit on 
> > it's binary, ...) the question is: Is this effort worth it?
> 
> Martin Gräßlin wrote:
> Thanks for asking.
> 
> > Not at all
> 
> I already feared that this would be the answer
> 
> > if we allow apps to arbitrarily write to config files in HOME.
> 
> I don't think this is an issue in the case of KWin.
> 
> > ptrace kwin
> 
> At least on Ubuntu one needs to be root to e.g. attach gdb to the 
> process. Might be an idea to get this into all distros.
> 
> > Or someone might install a malicious KWin script
> 
> KWin scripts are fine (both QScript based scripts and effects). QML based 
> scripts are problematic at the moment (will be hardened). QML based 
> decorations (and decorations in general) are not a problem. I spent quite 
> some time thinking about what is dangerous in KWin and what isn't ;-)
> 
> > Or the bad app might install a .desktop file override in 
> .local/share/applications overriding e.g. Firefox and then catching all the 
> input.
> 
> That's obvious, but our launcher got hardened against such things years 
> ago (see https://www.purinchu.net/wp/2009/02/21/desktop-file-security/ )
> 
> > they already have access to all files in the home directory and likely 
> have reached their goal already
> 
> I disagree on that. This was the approach on X - hey we don't have to do 
> security, because heck X is broken anyway. I really think we should prevent 
> the keylogger scenario.
> 
> > Is this effort worth it?
> 
> Yes, if it makes it impossible to get a keylogger it's worth it.

> Yes, if it makes it impossible to get a keylogger it's worth it.

I figured you'd say that :-D
So, I think the `env -i` workaround is something reasonable to do - given how 
things look currently, I'd say commit it and we'll see what breaks - changes 
can always be reverted, if they prove to result in more problems than expected.

I bet things like SELinux will prevent ptrace on distros using it as well, if 
they don't already have other countermeasures.
Having looked at KDE/Plasma startup *again*, I am really itching to pursue the 
startup refactoring further (rough idea is to get rid of kwrapper5, kinit, 
ksmserver and the shell scripts and have one service managing the whole 
session). That unfortunately has to wait until I have more time for it...


- Matthias


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126115/#review88620
---


On Nov. 19, 2015, 12:22 nachm., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126115/
> ---
> 
> (Updated Nov. 19, 2015, 12:22 nachm.)
> 
> 
> Review request for Plasma, David Edmundson and Matthias Klumpp.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Any environment variable which can be used to specify a path to a
> binary object to be loaded in the KWin process bears the risk of
> being abused to add code to KWin to perform as a key logger.
> 
> E.g. an env variable pointing QT_PLUGIN_PATH to a location in $HOME
> and adjusting QT_STYLE_OVERRIDE to load a specific QStyle plugin from
> that location would allow to easily log all keys without KWin noticing.
> 
> As env variables can be specified in scripts sourced before the session
> starts there is not much KWin can do about that to protect itself.
> 
> This affects all the LD_* variables and any library KWin uses and
> loads plugins.
> 
> The list here is based on what I could find:
> * LD_* variables as specified in the man page
> * LIBGL_* and EGL_* as specified on mesa page
> * QT_* variables based on "git grep qgetenv" in qtbase and qtdeclarative
>   combined with Qt's documentation
> * "git grep getenv" in vari

Re: Review Request 126115: Unset environment variables before starting kwin_wayland



> On Nov. 19, 2015, 3:08 p.m., Matthias Klumpp wrote:
> > Did you consider running the whole script with `env -i`, or (likely the 
> > better idea) run KWin with `env -i`?
> > That should sanitize the environment (unset all env vars, except for 
> > shell-defaults). You could then set exactly the variables you need, to the 
> > exact values you want, so we don't miss unsetting anything.
> 
> Martin Gräßlin wrote:
> No I didn't consider that, because I wasn't aware that this exists.
> 
> Martin Gräßlin wrote:
> Just tried with changing directly in the wayland session file. That 
> doesn't work at all. I think the main problem is that I lose important env 
> variables related to the logind session/dbus, etc.
> 
> So only way would be for the command to start kwin_wayland. But that as 
> well would require to set quite an amount of env variables, but worth a try.
> 
> Martin Gräßlin wrote:
> Just gave a try - the command looks horrible, but I got the session 
> started and env variables are properly filtered.
> 
> Command looks like this now:
> /usr/bin/env -i KDE_FULL_SESSION=true KDE_SESSION_VERSION=5 
> KDE_SESSION_UID=${KDE_SESSION_UID} XDG_CURRENT_DESKTOP=KDE 
> QT_QPA_PLATFORM=wayland PAM_KWALLET5_LOGIN=${PAM_KWALLET5_LOGIN} USER=${USER} 
> LANGUAGE=${LANGUAGE} XDG_SEAT=${XDG_SEAT} 
> XDG_SESSION_TYPE=${XDG_SESSION_TYPE} XCURSOR_SIZE=${XCURSOR_SIZE} 
> HOME=${HOME} DESKTOP_SESSION=${DESKTOP_SESSION} 
> XDG_SEAT_PATH=${XDG_SEAT_PATH} 
> DBUS_SESSION_BUS_ADDRESS=${DBUS_SESSION_BUS_ADDRESS} LOGNAME=${LOGNAME} 
> XDG_SESSION_CLASS=${XDG_SESSION_CLASS} XDG_SESSION_ID=${XDG_SESSION_ID} 
> PATH=${PATH} XDG_SESSION_PATH=${XDG_SESSION_PATH} 
> XDG_RUNTIME_DIR=${XDG_RUNTIME_DIR} XCURSOR_THEME=${XCURSOR_THEME} 
> LANG=${LANG} XDG_SESSION_DESKTOP=${XDG_SESSION_DESKTOP} 
> XCURSOR_PATH=${XCURSOR_PATH} XDG_VTNR=${XDG_VTNR} PWD=${PWD} 
> XDG_DATA_DIRS=${XDG_DATA_DIRS} XDG_CONFIG_DIRS=${XDG_CONFIG_DIRS} 
> @KWIN_WAYLAND_BIN_PATH@ --xwayland --libinput 
> --exit-with-session=@CMAKE_INSTALL_FULL_LIBEXECDIR@/startplasma
> 
> Matthias Klumpp wrote:
> Urgh, terrible! But I think this might just be the best workaround we can 
> come up with, given the circumstances. It at least protects against someone 
> adding new env vars which load bad code into the compositor. It might be an 
> issue as soon as kwin starts to require another env var which isn't in the 
> list, but that's an issue we can solve.
> I wonder if we can simplify that command somehow, though, e.g. by placing 
> the allowed variables in a file or new variable, to make this easier to read.
> Apart from that, +1 from me (I'll take a look at other DEs though, maybe 
> someone has come up with a bettr solution to this issue).
> 
> Xuetian Weng wrote:
> Woundn't this break user's workflow? Since startplasma is started by 
> kwin, the environment variable for the desktop will be derived from that.
> 
> If distribution has some global configuration under /etc/profile.d (which 
> is really common, e.g. openjdk, mozilla plugin path), they will not be set.
> 
> Martin Gräßlin wrote:
> > Woundn't this break user's workflow?
> 
> Yes, but what do you prefer? Breaking user's workflows or a secure system?
> 
> There is nothing wrong of course with sourcing the env scripts in 
> startplasma again and distributions using things like /etc/profile.d would be 
> advised to do exactly that.
> 
> Alex Richardson wrote:
> I don't see how this adds any security if you still keep $PATH. what if 
> the user prepends `$HOME/my-evil-binaries/` to $PATH?
> Maybe it makes more sense to restrict which scripts are executed before 
> kwin launches?
> 
> Matthias Klumpp wrote:
> Maybe starting a session manager as the first thing makes sense. That one 
> can then spawn KWin and KWin can tell the service to start plasmashell when 
> it's ready.
> Reminds me that I wanted to redesign the KDE startup process a while ago, 
> getting rid of most of the scripts. A `systemd --user` based startup could do 
> the exact same, btw.
> Unsetting most vars will break assumptions, but since this affects only 
> Wayland, it's probably okay for a little bit of breakage to exist, although 
> if we can avoid that we should try to avoid breaking things.
> Generally I agree with Martin: Security >> Breaking Workflows >> 
> Backwards-Compatibility
> 
> Matthias Klumpp wrote:
> @Alex: KWin is started with an absolute path now, which makes $PATH and 
> aliases irrelevant. So that particular issue is solved :)
> 
> Alex Richardson wrote:
> I know it doesn't make a difference for kwin. But I thought kwin will 
> then run startplasma which will start all sorts of other stuff.
> I'm just worried that a terminal (or any other program) that I start from 
> a plasma session will not have all the required environment variables set if 
> everything gets unset by kwin.
> 
> If this only affects the kwin

Re: Review Request 126115: Unset environment variables before starting kwin_wayland



> On Nov. 19, 2015, 6:31 p.m., Matthias Klumpp wrote:
> > Okay, I talked to some GNOME people (thanks!) to find out how they handle 
> > this issue, and the short answer is: Not at all
> > Reason for that is that it is really hard to fully secure the compositor if 
> > we allow apps to arbitrarily write to config files in HOME.
> > For example, one process might start to ptrace kwin, catching all input 
> > sent through it. Or someone might install a malicious KWin script. Or the 
> > bad app might install a .desktop file override in .local/share/applications 
> > overriding e.g. Firefox and then catching all the input. Etc.
> > Also, if the attacker went this far, they already have access to all files 
> > in the home directory and likely have reached their goal already.
> > 
> > So, I think we can get KWin secure by adding some really heavy 
> > countermeasures (restricting it's access to $HOME, using a setgid bit on 
> > it's binary, ...) the question is: Is this effort worth it?

Thanks for asking.

> Not at all

I already feared that this would be the answer

> if we allow apps to arbitrarily write to config files in HOME.

I don't think this is an issue in the case of KWin.

> ptrace kwin

At least on Ubuntu one needs to be root to e.g. attach gdb to the process. 
Might be an idea to get this into all distros.

> Or someone might install a malicious KWin script

KWin scripts are fine (both QScript based scripts and effects). QML based 
scripts are problematic at the moment (will be hardened). QML based decorations 
(and decorations in general) are not a problem. I spent quite some time 
thinking about what is dangerous in KWin and what isn't ;-)

> Or the bad app might install a .desktop file override in 
> .local/share/applications overriding e.g. Firefox and then catching all the 
> input.

That's obvious, but our launcher got hardened against such things years ago 
(see https://www.purinchu.net/wp/2009/02/21/desktop-file-security/ )

> they already have access to all files in the home directory and likely have 
> reached their goal already

I disagree on that. This was the approach on X - hey we don't have to do 
security, because heck X is broken anyway. I really think we should prevent the 
keylogger scenario.

> Is this effort worth it?

Yes, if it makes it impossible to get a keylogger it's worth it.


- Martin


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126115/#review88620
---


On Nov. 19, 2015, 1:22 p.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126115/
> ---
> 
> (Updated Nov. 19, 2015, 1:22 p.m.)
> 
> 
> Review request for Plasma, David Edmundson and Matthias Klumpp.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Any environment variable which can be used to specify a path to a
> binary object to be loaded in the KWin process bears the risk of
> being abused to add code to KWin to perform as a key logger.
> 
> E.g. an env variable pointing QT_PLUGIN_PATH to a location in $HOME
> and adjusting QT_STYLE_OVERRIDE to load a specific QStyle plugin from
> that location would allow to easily log all keys without KWin noticing.
> 
> As env variables can be specified in scripts sourced before the session
> starts there is not much KWin can do about that to protect itself.
> 
> This affects all the LD_* variables and any library KWin uses and
> loads plugins.
> 
> The list here is based on what I could find:
> * LD_* variables as specified in the man page
> * LIBGL_* and EGL_* as specified on mesa page
> * QT_* variables based on "git grep qgetenv" in qtbase and qtdeclarative
>   combined with Qt's documentation
> * "git grep getenv" in various KDE frameworks based on ldd output of KWin
> 
> Unfortunately the list is unlikely to be complete. If one env variable is
> missed, there is a risk. Even more each change in any library might
> introduce new variables.
> 
> The approach is futile, but needed till Linux has a secure way to start
> the session without sourcing env variable scripts from user owned
> locations.
> 
> 
> Diffs
> -
> 
>   startkde/startplasmacompositor.cmake 
> 1e46e5be0a0d733fb01e1a87a34ee3c73a06bf8c 
> 
> Diff: https://git.reviewboard.kde.org/r/126115/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Plasma 5.5 beta is out

2015-11-19 Thread Jonathan Riddell

beta tars are up and with a same day release they're available to all today

https://www.kde.org/announcements/plasma-5.4.95.php

Jonathan
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126113: make event filters static to decrease installed filters on qApp

2015-11-19 Thread David Edmundson


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126113/#review88619
---



src/declarativeimports/core/units.cpp (line 41)


Why not just make this the static object...rather than having the 
SharedAppFilterStatic class which will have one instance of this?



src/declarativeimports/core/units.cpp (line 53)


You only want ApplicationFontChange.

qapplication.cpp:1671

QEvent e(QEvent::ApplicationFontChange);
QApplication::sendEvent(QApplication::instance(), &e);



src/plasma/svg.cpp (line 47)


An SVG with colours will have a Theme object (via 
SvgPrivate::cacheAndColorsTheme())

ThemePrivate already has an (effecively shared) event filter on colours 
changing, can we use directly?


- David Edmundson


On Nov. 19, 2015, 12:08 p.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126113/
> ---
> 
> (Updated Nov. 19, 2015, 12:08 p.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Bugs: 351923
> http://bugs.kde.org/show_bug.cgi?id=351923
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> since seems there are so many event filters installed on the QApplication 
> installed that may give performance issues, try to use separate, singleton 
> watchers for them to decrease the amount of eventfilters called
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/core/units.h fa2256e 
>   src/declarativeimports/core/units.cpp 4e2adae 
>   src/plasma/private/svg_p.h 597465e 
>   src/plasma/svg.cpp bcceaf7 
> 
> Diff: https://git.reviewboard.kde.org/r/126113/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126115: Unset environment variables before starting kwin_wayland

2015-11-19 Thread Xuetian Weng



> On Nov. 19, 2015, 2:08 p.m., Matthias Klumpp wrote:
> > Did you consider running the whole script with `env -i`, or (likely the 
> > better idea) run KWin with `env -i`?
> > That should sanitize the environment (unset all env vars, except for 
> > shell-defaults). You could then set exactly the variables you need, to the 
> > exact values you want, so we don't miss unsetting anything.
> 
> Martin Gräßlin wrote:
> No I didn't consider that, because I wasn't aware that this exists.
> 
> Martin Gräßlin wrote:
> Just tried with changing directly in the wayland session file. That 
> doesn't work at all. I think the main problem is that I lose important env 
> variables related to the logind session/dbus, etc.
> 
> So only way would be for the command to start kwin_wayland. But that as 
> well would require to set quite an amount of env variables, but worth a try.
> 
> Martin Gräßlin wrote:
> Just gave a try - the command looks horrible, but I got the session 
> started and env variables are properly filtered.
> 
> Command looks like this now:
> /usr/bin/env -i KDE_FULL_SESSION=true KDE_SESSION_VERSION=5 
> KDE_SESSION_UID=${KDE_SESSION_UID} XDG_CURRENT_DESKTOP=KDE 
> QT_QPA_PLATFORM=wayland PAM_KWALLET5_LOGIN=${PAM_KWALLET5_LOGIN} USER=${USER} 
> LANGUAGE=${LANGUAGE} XDG_SEAT=${XDG_SEAT} 
> XDG_SESSION_TYPE=${XDG_SESSION_TYPE} XCURSOR_SIZE=${XCURSOR_SIZE} 
> HOME=${HOME} DESKTOP_SESSION=${DESKTOP_SESSION} 
> XDG_SEAT_PATH=${XDG_SEAT_PATH} 
> DBUS_SESSION_BUS_ADDRESS=${DBUS_SESSION_BUS_ADDRESS} LOGNAME=${LOGNAME} 
> XDG_SESSION_CLASS=${XDG_SESSION_CLASS} XDG_SESSION_ID=${XDG_SESSION_ID} 
> PATH=${PATH} XDG_SESSION_PATH=${XDG_SESSION_PATH} 
> XDG_RUNTIME_DIR=${XDG_RUNTIME_DIR} XCURSOR_THEME=${XCURSOR_THEME} 
> LANG=${LANG} XDG_SESSION_DESKTOP=${XDG_SESSION_DESKTOP} 
> XCURSOR_PATH=${XCURSOR_PATH} XDG_VTNR=${XDG_VTNR} PWD=${PWD} 
> XDG_DATA_DIRS=${XDG_DATA_DIRS} XDG_CONFIG_DIRS=${XDG_CONFIG_DIRS} 
> @KWIN_WAYLAND_BIN_PATH@ --xwayland --libinput 
> --exit-with-session=@CMAKE_INSTALL_FULL_LIBEXECDIR@/startplasma
> 
> Matthias Klumpp wrote:
> Urgh, terrible! But I think this might just be the best workaround we can 
> come up with, given the circumstances. It at least protects against someone 
> adding new env vars which load bad code into the compositor. It might be an 
> issue as soon as kwin starts to require another env var which isn't in the 
> list, but that's an issue we can solve.
> I wonder if we can simplify that command somehow, though, e.g. by placing 
> the allowed variables in a file or new variable, to make this easier to read.
> Apart from that, +1 from me (I'll take a look at other DEs though, maybe 
> someone has come up with a bettr solution to this issue).
> 
> Xuetian Weng wrote:
> Woundn't this break user's workflow? Since startplasma is started by 
> kwin, the environment variable for the desktop will be derived from that.
> 
> If distribution has some global configuration under /etc/profile.d (which 
> is really common, e.g. openjdk, mozilla plugin path), they will not be set.
> 
> Martin Gräßlin wrote:
> > Woundn't this break user's workflow?
> 
> Yes, but what do you prefer? Breaking user's workflows or a secure system?
> 
> There is nothing wrong of course with sourcing the env scripts in 
> startplasma again and distributions using things like /etc/profile.d would be 
> advised to do exactly that.
> 
> Alex Richardson wrote:
> I don't see how this adds any security if you still keep $PATH. what if 
> the user prepends `$HOME/my-evil-binaries/` to $PATH?
> Maybe it makes more sense to restrict which scripts are executed before 
> kwin launches?
> 
> Matthias Klumpp wrote:
> Maybe starting a session manager as the first thing makes sense. That one 
> can then spawn KWin and KWin can tell the service to start plasmashell when 
> it's ready.
> Reminds me that I wanted to redesign the KDE startup process a while ago, 
> getting rid of most of the scripts. A `systemd --user` based startup could do 
> the exact same, btw.
> Unsetting most vars will break assumptions, but since this affects only 
> Wayland, it's probably okay for a little bit of breakage to exist, although 
> if we can avoid that we should try to avoid breaking things.
> Generally I agree with Martin: Security >> Breaking Workflows >> 
> Backwards-Compatibility
> 
> Matthias Klumpp wrote:
> @Alex: KWin is started with an absolute path now, which makes $PATH and 
> aliases irrelevant. So that particular issue is solved :)
> 
> Alex Richardson wrote:
> I know it doesn't make a difference for kwin. But I thought kwin will 
> then run startplasma which will start all sorts of other stuff.
> I'm just worried that a terminal (or any other program) that I start from 
> a plasma session will not have all the required environment variables set if 
> everything gets unset by kwin.
> 
> If this only affects the kwin

Re: Review Request 126115: Unset environment variables before starting kwin_wayland


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126115/#review88620
---


Okay, I talked to some GNOME people (thanks!) to find out how they handle this 
issue, and the short answer is: Not at all
Reason for that is that it is really hard to fully secure the compositor if we 
allow apps to arbitrarily write to config files in HOME.
For example, one process might start to ptrace kwin, catching all input sent 
through it. Or someone might install a malicious KWin script. Or the bad app 
might install a .desktop file override in .local/share/applications overriding 
e.g. Firefox and then catching all the input. Etc.
Also, if the attacker went this far, they already have access to all files in 
the home directory and likely have reached their goal already.

So, I think we can get KWin secure by adding some really heavy countermeasures 
(restricting it's access to $HOME, using a setgid bit on it's binary, ...) the 
question is: Is this effort worth it?

- Matthias Klumpp


On Nov. 19, 2015, 12:22 nachm., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126115/
> ---
> 
> (Updated Nov. 19, 2015, 12:22 nachm.)
> 
> 
> Review request for Plasma, David Edmundson and Matthias Klumpp.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Any environment variable which can be used to specify a path to a
> binary object to be loaded in the KWin process bears the risk of
> being abused to add code to KWin to perform as a key logger.
> 
> E.g. an env variable pointing QT_PLUGIN_PATH to a location in $HOME
> and adjusting QT_STYLE_OVERRIDE to load a specific QStyle plugin from
> that location would allow to easily log all keys without KWin noticing.
> 
> As env variables can be specified in scripts sourced before the session
> starts there is not much KWin can do about that to protect itself.
> 
> This affects all the LD_* variables and any library KWin uses and
> loads plugins.
> 
> The list here is based on what I could find:
> * LD_* variables as specified in the man page
> * LIBGL_* and EGL_* as specified on mesa page
> * QT_* variables based on "git grep qgetenv" in qtbase and qtdeclarative
>   combined with Qt's documentation
> * "git grep getenv" in various KDE frameworks based on ldd output of KWin
> 
> Unfortunately the list is unlikely to be complete. If one env variable is
> missed, there is a risk. Even more each change in any library might
> introduce new variables.
> 
> The approach is futile, but needed till Linux has a secure way to start
> the session without sourcing env variable scripts from user owned
> locations.
> 
> 
> Diffs
> -
> 
>   startkde/startplasmacompositor.cmake 
> 1e46e5be0a0d733fb01e1a87a34ee3c73a06bf8c 
> 
> Diff: https://git.reviewboard.kde.org/r/126115/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Updated, 9,642 lines] D502: RFC: start in making plasma deps optional

2015-11-19 Thread mart (Marco Martin)

mart updated this revision to Diff 1329.
mart added a comment.

weekly update of the current status of the branch


REPOSITORY
  rPLASMAMOBILE plasma-mobile

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D502?vs=1178&id=1329

REVISION DETAIL
  https://phabricator.kde.org/D502

AFFECTED FILES
  activeshellpackage/package/contents/explorer/MenuTabBar.qml
  activeshellpackage/package/contents/views/ApplicationList.qml
  components/CMakeLists.txt
  components/mobilecomponents/ActionGroup.qml
  components/mobilecomponents/ApplicationWindow.qml
  components/mobilecomponents/CMakeLists.txt
  components/mobilecomponents/ContextDrawer.qml
  components/mobilecomponents/GlobalDrawer.qml
  components/mobilecomponents/IconGrid.qml
  components/mobilecomponents/OverlayDrawer.qml
  components/mobilecomponents/Page.qml
  components/mobilecomponents/SplitDrawer.qml
  components/mobilecomponents/applicationlistmodel.cpp
  components/mobilecomponents/applicationlistmodel.h
  components/mobilecomponents/examples/ExampleApp.qml
  components/mobilecomponents/examples/MainPage.qml
  components/mobilecomponents/examples/banner.jpg
  components/mobilecomponents/examples/gallery/ButtonGallery.qml
  components/mobilecomponents/examples/gallery/CheckBoxGallery.qml
  components/mobilecomponents/examples/gallery/IconGridGallery.qml
  components/mobilecomponents/examples/gallery/ProgressBarGallery.qml
  components/mobilecomponents/examples/gallery/RadioButtonGallery.qml
  components/mobilecomponents/examples/gallery/SliderGallery.qml
  components/mobilecomponents/examples/gallery/SwitchGallery.qml
  components/mobilecomponents/examples/gallery/TextFieldGallery.qml
  components/mobilecomponents/fallbacktheme/Icon.qml
  components/mobilecomponents/fallbacktheme/Theme.qml
  components/mobilecomponents/fallbacktheme/Units.qml
  components/mobilecomponents/fallbacktheme/qmldir
  components/mobilecomponents/fullscreenpanel.cpp
  components/mobilecomponents/fullscreenpanel.h
  components/mobilecomponents/mobilecomponentsplugin.cpp
  components/mobilecomponents/plasmatheme/Icon.qml
  components/mobilecomponents/plasmatheme/Theme.qml
  components/mobilecomponents/plasmatheme/Units.qml
  components/mobilecomponents/qml/ActionGroup.qml
  components/mobilecomponents/qml/ApplicationWindow.qml
  components/mobilecomponents/qml/ContextDrawer.qml
  components/mobilecomponents/qml/GlobalDrawer.qml
  components/mobilecomponents/qml/Heading.qml
  components/mobilecomponents/qml/IconGrid.qml
  components/mobilecomponents/qml/Label.qml
  components/mobilecomponents/qml/ListItem.qml
  components/mobilecomponents/qml/ListItemWithActions.qml
  components/mobilecomponents/qml/OverlayDrawer.qml
  components/mobilecomponents/qml/Page.qml
  components/mobilecomponents/qml/PageRow.qml
  components/mobilecomponents/qml/SplitDrawer.qml
  components/mobilecomponents/qml/plasmadep.diff
  components/mobilecomponents/qml/private/ActionButton.qml
  components/mobilecomponents/qml/private/PageStack.js
  components/mobilecomponents/qml/qmldir
  components/mobilecomponents/qmldir
  components/mobileshellprivate/CMakeLists.txt
  components/mobileshellprivate/Messages.sh
  components/mobileshellprivate/fullscreenpanel.cpp
  components/mobileshellprivate/fullscreenpanel.h
  components/mobileshellprivate/mobileshellprivateplugin.cpp
  components/mobileshellprivate/mobileshellprivateplugin.h
  components/mobileshellprivate/qmldir

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: mart, Plasma: Mobile
Cc: plasma-devel
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126119: remove unused platformstatus kded


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126119/#review88618
---

Ship it!


Ship It!

- Sebastian Kügler


On Nov. 19, 2015, 4:14 p.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126119/
> ---
> 
> (Updated Nov. 19, 2015, 4:14 p.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Bugs: 348840
> http://bugs.kde.org/show_bug.cgi?id=348840
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> This kded was written at the beginning of the kf5 port cycle, it was supposed 
> to do the runtime shell switching for transformable devices, but then it 
> ended up completely implemented in plasmashell and not much tested anyways 
> due to the lack of drivers.
> this got completely unused, remove it (and eventually add it again in future 
> if when there will be hardware support will be considered a viable approach, 
> but probably not)
> 
> 
> Diffs
> -
> 
>   src/CMakeLists.txt 0ecb348 
>   src/platformstatus/CMakeLists.txt 114d9eb 
>   src/platformstatus/org.kde.platformstatus.xml d5c81bc 
>   src/platformstatus/platformstatus.cpp d38635a 
>   src/platformstatus/platformstatus.desktop 50e25a4 
>   src/platformstatus/platformstatus.h 6c113ab 
> 
> Diff: https://git.reviewboard.kde.org/r/126119/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126115: Unset environment variables before starting kwin_wayland



> On Nov. 19, 2015, 3:08 p.m., Matthias Klumpp wrote:
> > Did you consider running the whole script with `env -i`, or (likely the 
> > better idea) run KWin with `env -i`?
> > That should sanitize the environment (unset all env vars, except for 
> > shell-defaults). You could then set exactly the variables you need, to the 
> > exact values you want, so we don't miss unsetting anything.
> 
> Martin Gräßlin wrote:
> No I didn't consider that, because I wasn't aware that this exists.
> 
> Martin Gräßlin wrote:
> Just tried with changing directly in the wayland session file. That 
> doesn't work at all. I think the main problem is that I lose important env 
> variables related to the logind session/dbus, etc.
> 
> So only way would be for the command to start kwin_wayland. But that as 
> well would require to set quite an amount of env variables, but worth a try.
> 
> Martin Gräßlin wrote:
> Just gave a try - the command looks horrible, but I got the session 
> started and env variables are properly filtered.
> 
> Command looks like this now:
> /usr/bin/env -i KDE_FULL_SESSION=true KDE_SESSION_VERSION=5 
> KDE_SESSION_UID=${KDE_SESSION_UID} XDG_CURRENT_DESKTOP=KDE 
> QT_QPA_PLATFORM=wayland PAM_KWALLET5_LOGIN=${PAM_KWALLET5_LOGIN} USER=${USER} 
> LANGUAGE=${LANGUAGE} XDG_SEAT=${XDG_SEAT} 
> XDG_SESSION_TYPE=${XDG_SESSION_TYPE} XCURSOR_SIZE=${XCURSOR_SIZE} 
> HOME=${HOME} DESKTOP_SESSION=${DESKTOP_SESSION} 
> XDG_SEAT_PATH=${XDG_SEAT_PATH} 
> DBUS_SESSION_BUS_ADDRESS=${DBUS_SESSION_BUS_ADDRESS} LOGNAME=${LOGNAME} 
> XDG_SESSION_CLASS=${XDG_SESSION_CLASS} XDG_SESSION_ID=${XDG_SESSION_ID} 
> PATH=${PATH} XDG_SESSION_PATH=${XDG_SESSION_PATH} 
> XDG_RUNTIME_DIR=${XDG_RUNTIME_DIR} XCURSOR_THEME=${XCURSOR_THEME} 
> LANG=${LANG} XDG_SESSION_DESKTOP=${XDG_SESSION_DESKTOP} 
> XCURSOR_PATH=${XCURSOR_PATH} XDG_VTNR=${XDG_VTNR} PWD=${PWD} 
> XDG_DATA_DIRS=${XDG_DATA_DIRS} XDG_CONFIG_DIRS=${XDG_CONFIG_DIRS} 
> @KWIN_WAYLAND_BIN_PATH@ --xwayland --libinput 
> --exit-with-session=@CMAKE_INSTALL_FULL_LIBEXECDIR@/startplasma
> 
> Matthias Klumpp wrote:
> Urgh, terrible! But I think this might just be the best workaround we can 
> come up with, given the circumstances. It at least protects against someone 
> adding new env vars which load bad code into the compositor. It might be an 
> issue as soon as kwin starts to require another env var which isn't in the 
> list, but that's an issue we can solve.
> I wonder if we can simplify that command somehow, though, e.g. by placing 
> the allowed variables in a file or new variable, to make this easier to read.
> Apart from that, +1 from me (I'll take a look at other DEs though, maybe 
> someone has come up with a bettr solution to this issue).
> 
> Xuetian Weng wrote:
> Woundn't this break user's workflow? Since startplasma is started by 
> kwin, the environment variable for the desktop will be derived from that.
> 
> If distribution has some global configuration under /etc/profile.d (which 
> is really common, e.g. openjdk, mozilla plugin path), they will not be set.
> 
> Martin Gräßlin wrote:
> > Woundn't this break user's workflow?
> 
> Yes, but what do you prefer? Breaking user's workflows or a secure system?
> 
> There is nothing wrong of course with sourcing the env scripts in 
> startplasma again and distributions using things like /etc/profile.d would be 
> advised to do exactly that.
> 
> Alex Richardson wrote:
> I don't see how this adds any security if you still keep $PATH. what if 
> the user prepends `$HOME/my-evil-binaries/` to $PATH?
> Maybe it makes more sense to restrict which scripts are executed before 
> kwin launches?
> 
> Matthias Klumpp wrote:
> Maybe starting a session manager as the first thing makes sense. That one 
> can then spawn KWin and KWin can tell the service to start plasmashell when 
> it's ready.
> Reminds me that I wanted to redesign the KDE startup process a while ago, 
> getting rid of most of the scripts. A `systemd --user` based startup could do 
> the exact same, btw.
> Unsetting most vars will break assumptions, but since this affects only 
> Wayland, it's probably okay for a little bit of breakage to exist, although 
> if we can avoid that we should try to avoid breaking things.
> Generally I agree with Martin: Security >> Breaking Workflows >> 
> Backwards-Compatibility
> 
> Matthias Klumpp wrote:
> @Alex: KWin is started with an absolute path now, which makes $PATH and 
> aliases irrelevant. So that particular issue is solved :)
> 
> Alex Richardson wrote:
> I know it doesn't make a difference for kwin. But I thought kwin will 
> then run startplasma which will start all sorts of other stuff.
> I'm just worried that a terminal (or any other program) that I start from 
> a plasma session will not have all the required environment variables set if 
> everything gets unset by kwin.
> 
> If this only affects the kwin

Re: RFC: plasmoid templates in plasma-sdk

On Thursday 19 November 2015, Sebastian Kügler wrote:
> On Wednesday, November 18, 2015 11:37:16 AM Marco Martin wrote:
> > On Monday 16 November 2015, Sebastian Kügler wrote:
> > > > yes, makes sense, most important is to have them in places harder to
> > > > forget about
> > > 
> > > If in plasma-framework, it would kind of fit in with all the example
> > > plasmoid code. Not sure if that, or plasma-sdk, both make sense to me,
> > > perhaps plasma- sdk a bit more, even.
> > 
> > sooo, plasma-sdk or plasma-framework? is the same for me, i have them
> > ready,  just to push wherever
> > 
> > the argument for plasma-framework to me is *if* other frameworks are
> > going to  have their own templates in their repos as well
> 
> Let's go for plasma-framework.

ok then.
now, another technical question (looking mostly at Aleix as ide-related tools 
master:p) templates right now are installed by a quite complicated cmake macro 
that is in kapptemplate as well (it creates a tarball from the sources and 
then installs the tarball)
so..
since frameworks can't depend from kapptemplate for said cmake macro...

if many frameworks will end up having project templates, that should go in 
extra-cmake-modules? if so and is something of global frameworks interest i 
can try to go for such a global macro before pushing the rest

-- 
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126115: Unset environment variables before starting kwin_wayland

2015-11-19 Thread Alex Richardson



> On Nov. 19, 2015, 2:08 p.m., Matthias Klumpp wrote:
> > Did you consider running the whole script with `env -i`, or (likely the 
> > better idea) run KWin with `env -i`?
> > That should sanitize the environment (unset all env vars, except for 
> > shell-defaults). You could then set exactly the variables you need, to the 
> > exact values you want, so we don't miss unsetting anything.
> 
> Martin Gräßlin wrote:
> No I didn't consider that, because I wasn't aware that this exists.
> 
> Martin Gräßlin wrote:
> Just tried with changing directly in the wayland session file. That 
> doesn't work at all. I think the main problem is that I lose important env 
> variables related to the logind session/dbus, etc.
> 
> So only way would be for the command to start kwin_wayland. But that as 
> well would require to set quite an amount of env variables, but worth a try.
> 
> Martin Gräßlin wrote:
> Just gave a try - the command looks horrible, but I got the session 
> started and env variables are properly filtered.
> 
> Command looks like this now:
> /usr/bin/env -i KDE_FULL_SESSION=true KDE_SESSION_VERSION=5 
> KDE_SESSION_UID=${KDE_SESSION_UID} XDG_CURRENT_DESKTOP=KDE 
> QT_QPA_PLATFORM=wayland PAM_KWALLET5_LOGIN=${PAM_KWALLET5_LOGIN} USER=${USER} 
> LANGUAGE=${LANGUAGE} XDG_SEAT=${XDG_SEAT} 
> XDG_SESSION_TYPE=${XDG_SESSION_TYPE} XCURSOR_SIZE=${XCURSOR_SIZE} 
> HOME=${HOME} DESKTOP_SESSION=${DESKTOP_SESSION} 
> XDG_SEAT_PATH=${XDG_SEAT_PATH} 
> DBUS_SESSION_BUS_ADDRESS=${DBUS_SESSION_BUS_ADDRESS} LOGNAME=${LOGNAME} 
> XDG_SESSION_CLASS=${XDG_SESSION_CLASS} XDG_SESSION_ID=${XDG_SESSION_ID} 
> PATH=${PATH} XDG_SESSION_PATH=${XDG_SESSION_PATH} 
> XDG_RUNTIME_DIR=${XDG_RUNTIME_DIR} XCURSOR_THEME=${XCURSOR_THEME} 
> LANG=${LANG} XDG_SESSION_DESKTOP=${XDG_SESSION_DESKTOP} 
> XCURSOR_PATH=${XCURSOR_PATH} XDG_VTNR=${XDG_VTNR} PWD=${PWD} 
> XDG_DATA_DIRS=${XDG_DATA_DIRS} XDG_CONFIG_DIRS=${XDG_CONFIG_DIRS} 
> @KWIN_WAYLAND_BIN_PATH@ --xwayland --libinput 
> --exit-with-session=@CMAKE_INSTALL_FULL_LIBEXECDIR@/startplasma
> 
> Matthias Klumpp wrote:
> Urgh, terrible! But I think this might just be the best workaround we can 
> come up with, given the circumstances. It at least protects against someone 
> adding new env vars which load bad code into the compositor. It might be an 
> issue as soon as kwin starts to require another env var which isn't in the 
> list, but that's an issue we can solve.
> I wonder if we can simplify that command somehow, though, e.g. by placing 
> the allowed variables in a file or new variable, to make this easier to read.
> Apart from that, +1 from me (I'll take a look at other DEs though, maybe 
> someone has come up with a bettr solution to this issue).
> 
> Xuetian Weng wrote:
> Woundn't this break user's workflow? Since startplasma is started by 
> kwin, the environment variable for the desktop will be derived from that.
> 
> If distribution has some global configuration under /etc/profile.d (which 
> is really common, e.g. openjdk, mozilla plugin path), they will not be set.
> 
> Martin Gräßlin wrote:
> > Woundn't this break user's workflow?
> 
> Yes, but what do you prefer? Breaking user's workflows or a secure system?
> 
> There is nothing wrong of course with sourcing the env scripts in 
> startplasma again and distributions using things like /etc/profile.d would be 
> advised to do exactly that.
> 
> Alex Richardson wrote:
> I don't see how this adds any security if you still keep $PATH. what if 
> the user prepends `$HOME/my-evil-binaries/` to $PATH?
> Maybe it makes more sense to restrict which scripts are executed before 
> kwin launches?
> 
> Matthias Klumpp wrote:
> Maybe starting a session manager as the first thing makes sense. That one 
> can then spawn KWin and KWin can tell the service to start plasmashell when 
> it's ready.
> Reminds me that I wanted to redesign the KDE startup process a while ago, 
> getting rid of most of the scripts. A `systemd --user` based startup could do 
> the exact same, btw.
> Unsetting most vars will break assumptions, but since this affects only 
> Wayland, it's probably okay for a little bit of breakage to exist, although 
> if we can avoid that we should try to avoid breaking things.
> Generally I agree with Martin: Security >> Breaking Workflows >> 
> Backwards-Compatibility
> 
> Matthias Klumpp wrote:
> @Alex: KWin is started with an absolute path now, which makes $PATH and 
> aliases irrelevant. So that particular issue is solved :)

I know it doesn't make a difference for kwin. But I thought kwin will then run 
startplasma which will start all sorts of other stuff.
I'm just worried that a terminal (or any other program) that I start from a 
plasma session will not have all the required environment variables set if 
everything gets unset by kwin.

If this only affects the kwin process then I'm fine with it. Although if kwin 
doesn't

Re: Review Request 126115: Unset environment variables before starting kwin_wayland



> On Nov. 19, 2015, 2:08 nachm., Matthias Klumpp wrote:
> > Did you consider running the whole script with `env -i`, or (likely the 
> > better idea) run KWin with `env -i`?
> > That should sanitize the environment (unset all env vars, except for 
> > shell-defaults). You could then set exactly the variables you need, to the 
> > exact values you want, so we don't miss unsetting anything.
> 
> Martin Gräßlin wrote:
> No I didn't consider that, because I wasn't aware that this exists.
> 
> Martin Gräßlin wrote:
> Just tried with changing directly in the wayland session file. That 
> doesn't work at all. I think the main problem is that I lose important env 
> variables related to the logind session/dbus, etc.
> 
> So only way would be for the command to start kwin_wayland. But that as 
> well would require to set quite an amount of env variables, but worth a try.
> 
> Martin Gräßlin wrote:
> Just gave a try - the command looks horrible, but I got the session 
> started and env variables are properly filtered.
> 
> Command looks like this now:
> /usr/bin/env -i KDE_FULL_SESSION=true KDE_SESSION_VERSION=5 
> KDE_SESSION_UID=${KDE_SESSION_UID} XDG_CURRENT_DESKTOP=KDE 
> QT_QPA_PLATFORM=wayland PAM_KWALLET5_LOGIN=${PAM_KWALLET5_LOGIN} USER=${USER} 
> LANGUAGE=${LANGUAGE} XDG_SEAT=${XDG_SEAT} 
> XDG_SESSION_TYPE=${XDG_SESSION_TYPE} XCURSOR_SIZE=${XCURSOR_SIZE} 
> HOME=${HOME} DESKTOP_SESSION=${DESKTOP_SESSION} 
> XDG_SEAT_PATH=${XDG_SEAT_PATH} 
> DBUS_SESSION_BUS_ADDRESS=${DBUS_SESSION_BUS_ADDRESS} LOGNAME=${LOGNAME} 
> XDG_SESSION_CLASS=${XDG_SESSION_CLASS} XDG_SESSION_ID=${XDG_SESSION_ID} 
> PATH=${PATH} XDG_SESSION_PATH=${XDG_SESSION_PATH} 
> XDG_RUNTIME_DIR=${XDG_RUNTIME_DIR} XCURSOR_THEME=${XCURSOR_THEME} 
> LANG=${LANG} XDG_SESSION_DESKTOP=${XDG_SESSION_DESKTOP} 
> XCURSOR_PATH=${XCURSOR_PATH} XDG_VTNR=${XDG_VTNR} PWD=${PWD} 
> XDG_DATA_DIRS=${XDG_DATA_DIRS} XDG_CONFIG_DIRS=${XDG_CONFIG_DIRS} 
> @KWIN_WAYLAND_BIN_PATH@ --xwayland --libinput 
> --exit-with-session=@CMAKE_INSTALL_FULL_LIBEXECDIR@/startplasma
> 
> Matthias Klumpp wrote:
> Urgh, terrible! But I think this might just be the best workaround we can 
> come up with, given the circumstances. It at least protects against someone 
> adding new env vars which load bad code into the compositor. It might be an 
> issue as soon as kwin starts to require another env var which isn't in the 
> list, but that's an issue we can solve.
> I wonder if we can simplify that command somehow, though, e.g. by placing 
> the allowed variables in a file or new variable, to make this easier to read.
> Apart from that, +1 from me (I'll take a look at other DEs though, maybe 
> someone has come up with a bettr solution to this issue).
> 
> Xuetian Weng wrote:
> Woundn't this break user's workflow? Since startplasma is started by 
> kwin, the environment variable for the desktop will be derived from that.
> 
> If distribution has some global configuration under /etc/profile.d (which 
> is really common, e.g. openjdk, mozilla plugin path), they will not be set.
> 
> Martin Gräßlin wrote:
> > Woundn't this break user's workflow?
> 
> Yes, but what do you prefer? Breaking user's workflows or a secure system?
> 
> There is nothing wrong of course with sourcing the env scripts in 
> startplasma again and distributions using things like /etc/profile.d would be 
> advised to do exactly that.
> 
> Alex Richardson wrote:
> I don't see how this adds any security if you still keep $PATH. what if 
> the user prepends `$HOME/my-evil-binaries/` to $PATH?
> Maybe it makes more sense to restrict which scripts are executed before 
> kwin launches?
> 
> Matthias Klumpp wrote:
> Maybe starting a session manager as the first thing makes sense. That one 
> can then spawn KWin and KWin can tell the service to start plasmashell when 
> it's ready.
> Reminds me that I wanted to redesign the KDE startup process a while ago, 
> getting rid of most of the scripts. A `systemd --user` based startup could do 
> the exact same, btw.
> Unsetting most vars will break assumptions, but since this affects only 
> Wayland, it's probably okay for a little bit of breakage to exist, although 
> if we can avoid that we should try to avoid breaking things.
> Generally I agree with Martin: Security >> Breaking Workflows >> 
> Backwards-Compatibility

@Alex: KWin is started with an absolute path now, which makes $PATH and aliases 
irrelevant. So that particular issue is solved :)


- Matthias


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126115/#review88597
---


On Nov. 19, 2015, 12:22 nachm., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https:

Re: Review Request 126115: Unset environment variables before starting kwin_wayland



> On Nov. 19, 2015, 2:08 nachm., Matthias Klumpp wrote:
> > Did you consider running the whole script with `env -i`, or (likely the 
> > better idea) run KWin with `env -i`?
> > That should sanitize the environment (unset all env vars, except for 
> > shell-defaults). You could then set exactly the variables you need, to the 
> > exact values you want, so we don't miss unsetting anything.
> 
> Martin Gräßlin wrote:
> No I didn't consider that, because I wasn't aware that this exists.
> 
> Martin Gräßlin wrote:
> Just tried with changing directly in the wayland session file. That 
> doesn't work at all. I think the main problem is that I lose important env 
> variables related to the logind session/dbus, etc.
> 
> So only way would be for the command to start kwin_wayland. But that as 
> well would require to set quite an amount of env variables, but worth a try.
> 
> Martin Gräßlin wrote:
> Just gave a try - the command looks horrible, but I got the session 
> started and env variables are properly filtered.
> 
> Command looks like this now:
> /usr/bin/env -i KDE_FULL_SESSION=true KDE_SESSION_VERSION=5 
> KDE_SESSION_UID=${KDE_SESSION_UID} XDG_CURRENT_DESKTOP=KDE 
> QT_QPA_PLATFORM=wayland PAM_KWALLET5_LOGIN=${PAM_KWALLET5_LOGIN} USER=${USER} 
> LANGUAGE=${LANGUAGE} XDG_SEAT=${XDG_SEAT} 
> XDG_SESSION_TYPE=${XDG_SESSION_TYPE} XCURSOR_SIZE=${XCURSOR_SIZE} 
> HOME=${HOME} DESKTOP_SESSION=${DESKTOP_SESSION} 
> XDG_SEAT_PATH=${XDG_SEAT_PATH} 
> DBUS_SESSION_BUS_ADDRESS=${DBUS_SESSION_BUS_ADDRESS} LOGNAME=${LOGNAME} 
> XDG_SESSION_CLASS=${XDG_SESSION_CLASS} XDG_SESSION_ID=${XDG_SESSION_ID} 
> PATH=${PATH} XDG_SESSION_PATH=${XDG_SESSION_PATH} 
> XDG_RUNTIME_DIR=${XDG_RUNTIME_DIR} XCURSOR_THEME=${XCURSOR_THEME} 
> LANG=${LANG} XDG_SESSION_DESKTOP=${XDG_SESSION_DESKTOP} 
> XCURSOR_PATH=${XCURSOR_PATH} XDG_VTNR=${XDG_VTNR} PWD=${PWD} 
> XDG_DATA_DIRS=${XDG_DATA_DIRS} XDG_CONFIG_DIRS=${XDG_CONFIG_DIRS} 
> @KWIN_WAYLAND_BIN_PATH@ --xwayland --libinput 
> --exit-with-session=@CMAKE_INSTALL_FULL_LIBEXECDIR@/startplasma
> 
> Matthias Klumpp wrote:
> Urgh, terrible! But I think this might just be the best workaround we can 
> come up with, given the circumstances. It at least protects against someone 
> adding new env vars which load bad code into the compositor. It might be an 
> issue as soon as kwin starts to require another env var which isn't in the 
> list, but that's an issue we can solve.
> I wonder if we can simplify that command somehow, though, e.g. by placing 
> the allowed variables in a file or new variable, to make this easier to read.
> Apart from that, +1 from me (I'll take a look at other DEs though, maybe 
> someone has come up with a bettr solution to this issue).
> 
> Xuetian Weng wrote:
> Woundn't this break user's workflow? Since startplasma is started by 
> kwin, the environment variable for the desktop will be derived from that.
> 
> If distribution has some global configuration under /etc/profile.d (which 
> is really common, e.g. openjdk, mozilla plugin path), they will not be set.
> 
> Martin Gräßlin wrote:
> > Woundn't this break user's workflow?
> 
> Yes, but what do you prefer? Breaking user's workflows or a secure system?
> 
> There is nothing wrong of course with sourcing the env scripts in 
> startplasma again and distributions using things like /etc/profile.d would be 
> advised to do exactly that.
> 
> Alex Richardson wrote:
> I don't see how this adds any security if you still keep $PATH. what if 
> the user prepends `$HOME/my-evil-binaries/` to $PATH?
> Maybe it makes more sense to restrict which scripts are executed before 
> kwin launches?

Maybe starting a session manager as the first thing makes sense. That one can 
then spawn KWin and KWin can tell the service to start plasmashell when it's 
ready.
Reminds me that I wanted to redesign the KDE startup process a while ago, 
getting rid of most of the scripts. A `systemd --user` based startup could do 
the exact same, btw.
Unsetting most vars will break assumptions, but since this affects only 
Wayland, it's probably okay for a little bit of breakage to exist, although if 
we can avoid that we should try to avoid breaking things.
Generally I agree with Martin: Security >> Breaking Workflows >> 
Backwards-Compatibility


- Matthias


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126115/#review88597
---


On Nov. 19, 2015, 12:22 nachm., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126115/
> ---
> 
> (Updated Nov. 19, 2015, 12:22 nachm.)
> 
> 
> Review request for Plasma, David Edmundson and M

Re: Review Request 126115: Unset environment variables before starting kwin_wayland

2015-11-19 Thread Alex Richardson



> On Nov. 19, 2015, 2:08 p.m., Matthias Klumpp wrote:
> > Did you consider running the whole script with `env -i`, or (likely the 
> > better idea) run KWin with `env -i`?
> > That should sanitize the environment (unset all env vars, except for 
> > shell-defaults). You could then set exactly the variables you need, to the 
> > exact values you want, so we don't miss unsetting anything.
> 
> Martin Gräßlin wrote:
> No I didn't consider that, because I wasn't aware that this exists.
> 
> Martin Gräßlin wrote:
> Just tried with changing directly in the wayland session file. That 
> doesn't work at all. I think the main problem is that I lose important env 
> variables related to the logind session/dbus, etc.
> 
> So only way would be for the command to start kwin_wayland. But that as 
> well would require to set quite an amount of env variables, but worth a try.
> 
> Martin Gräßlin wrote:
> Just gave a try - the command looks horrible, but I got the session 
> started and env variables are properly filtered.
> 
> Command looks like this now:
> /usr/bin/env -i KDE_FULL_SESSION=true KDE_SESSION_VERSION=5 
> KDE_SESSION_UID=${KDE_SESSION_UID} XDG_CURRENT_DESKTOP=KDE 
> QT_QPA_PLATFORM=wayland PAM_KWALLET5_LOGIN=${PAM_KWALLET5_LOGIN} USER=${USER} 
> LANGUAGE=${LANGUAGE} XDG_SEAT=${XDG_SEAT} 
> XDG_SESSION_TYPE=${XDG_SESSION_TYPE} XCURSOR_SIZE=${XCURSOR_SIZE} 
> HOME=${HOME} DESKTOP_SESSION=${DESKTOP_SESSION} 
> XDG_SEAT_PATH=${XDG_SEAT_PATH} 
> DBUS_SESSION_BUS_ADDRESS=${DBUS_SESSION_BUS_ADDRESS} LOGNAME=${LOGNAME} 
> XDG_SESSION_CLASS=${XDG_SESSION_CLASS} XDG_SESSION_ID=${XDG_SESSION_ID} 
> PATH=${PATH} XDG_SESSION_PATH=${XDG_SESSION_PATH} 
> XDG_RUNTIME_DIR=${XDG_RUNTIME_DIR} XCURSOR_THEME=${XCURSOR_THEME} 
> LANG=${LANG} XDG_SESSION_DESKTOP=${XDG_SESSION_DESKTOP} 
> XCURSOR_PATH=${XCURSOR_PATH} XDG_VTNR=${XDG_VTNR} PWD=${PWD} 
> XDG_DATA_DIRS=${XDG_DATA_DIRS} XDG_CONFIG_DIRS=${XDG_CONFIG_DIRS} 
> @KWIN_WAYLAND_BIN_PATH@ --xwayland --libinput 
> --exit-with-session=@CMAKE_INSTALL_FULL_LIBEXECDIR@/startplasma
> 
> Matthias Klumpp wrote:
> Urgh, terrible! But I think this might just be the best workaround we can 
> come up with, given the circumstances. It at least protects against someone 
> adding new env vars which load bad code into the compositor. It might be an 
> issue as soon as kwin starts to require another env var which isn't in the 
> list, but that's an issue we can solve.
> I wonder if we can simplify that command somehow, though, e.g. by placing 
> the allowed variables in a file or new variable, to make this easier to read.
> Apart from that, +1 from me (I'll take a look at other DEs though, maybe 
> someone has come up with a bettr solution to this issue).
> 
> Xuetian Weng wrote:
> Woundn't this break user's workflow? Since startplasma is started by 
> kwin, the environment variable for the desktop will be derived from that.
> 
> If distribution has some global configuration under /etc/profile.d (which 
> is really common, e.g. openjdk, mozilla plugin path), they will not be set.
> 
> Martin Gräßlin wrote:
> > Woundn't this break user's workflow?
> 
> Yes, but what do you prefer? Breaking user's workflows or a secure system?
> 
> There is nothing wrong of course with sourcing the env scripts in 
> startplasma again and distributions using things like /etc/profile.d would be 
> advised to do exactly that.

I don't see how this adds any security if you still keep $PATH. what if the 
user prepends `$HOME/my-evil-binaries/` to $PATH?
Maybe it makes more sense to restrict which scripts are executed before kwin 
launches?


- Alex


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126115/#review88597
---


On Nov. 19, 2015, 12:22 p.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126115/
> ---
> 
> (Updated Nov. 19, 2015, 12:22 p.m.)
> 
> 
> Review request for Plasma, David Edmundson and Matthias Klumpp.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Any environment variable which can be used to specify a path to a
> binary object to be loaded in the KWin process bears the risk of
> being abused to add code to KWin to perform as a key logger.
> 
> E.g. an env variable pointing QT_PLUGIN_PATH to a location in $HOME
> and adjusting QT_STYLE_OVERRIDE to load a specific QStyle plugin from
> that location would allow to easily log all keys without KWin noticing.
> 
> As env variables can be specified in scripts sourced before the session
> starts there is not much KWin can do about that to protect itself.
> 
> This affects all the LD_* variables and

Review Request 126119: remove unused platformstatus kded


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126119/
---

Review request for KDE Frameworks and Plasma.


Bugs: 348840
http://bugs.kde.org/show_bug.cgi?id=348840


Repository: plasma-framework


Description
---

This kded was written at the beginning of the kf5 port cycle, it was supposed 
to do the runtime shell switching for transformable devices, but then it ended 
up completely implemented in plasmashell and not much tested anyways due to the 
lack of drivers.
this got completely unused, remove it (and eventually add it again in future if 
when there will be hardware support will be considered a viable approach, but 
probably not)


Diffs
-

  src/CMakeLists.txt 0ecb348 
  src/platformstatus/CMakeLists.txt 114d9eb 
  src/platformstatus/org.kde.platformstatus.xml d5c81bc 
  src/platformstatus/platformstatus.cpp d38635a 
  src/platformstatus/platformstatus.desktop 50e25a4 
  src/platformstatus/platformstatus.h 6c113ab 

Diff: https://git.reviewboard.kde.org/r/126119/diff/


Testing
---


Thanks,

Marco Martin

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126104: Make networkmanager-qt an optional dependency

2015-11-19 Thread Alex Richardson


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126104/
---

(Updated Nov. 19, 2015, 4:10 p.m.)


Status
--

This change has been marked as submitted.


Review request for Plasma.


Changes
---

Submitted with commit de5ed6c4cdded1f2ba2ce43022be1d1a9b475bf0 by Alex 
Richardson to branch master.


Repository: plasma-workspace


Description
---

I can't compile networkmanager-qt on my current system because the version
of NetworkManager seems to be too old.

Also not every system has NetworkManager (FreeBSD?) so it should be
optional.


Diffs
-

  CMakeLists.txt d21a2b7a7774ac712f905f1db1ee478dca10b45c 
  dataengines/CMakeLists.txt 014da10aac5629be202bd5ad96012f817bf846ef 

Diff: https://git.reviewboard.kde.org/r/126104/diff/


Testing
---

compiles


Thanks,

Alex Richardson

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126115: Unset environment variables before starting kwin_wayland



> On Nov. 19, 2015, 3:08 p.m., Matthias Klumpp wrote:
> > Did you consider running the whole script with `env -i`, or (likely the 
> > better idea) run KWin with `env -i`?
> > That should sanitize the environment (unset all env vars, except for 
> > shell-defaults). You could then set exactly the variables you need, to the 
> > exact values you want, so we don't miss unsetting anything.
> 
> Martin Gräßlin wrote:
> No I didn't consider that, because I wasn't aware that this exists.
> 
> Martin Gräßlin wrote:
> Just tried with changing directly in the wayland session file. That 
> doesn't work at all. I think the main problem is that I lose important env 
> variables related to the logind session/dbus, etc.
> 
> So only way would be for the command to start kwin_wayland. But that as 
> well would require to set quite an amount of env variables, but worth a try.
> 
> Martin Gräßlin wrote:
> Just gave a try - the command looks horrible, but I got the session 
> started and env variables are properly filtered.
> 
> Command looks like this now:
> /usr/bin/env -i KDE_FULL_SESSION=true KDE_SESSION_VERSION=5 
> KDE_SESSION_UID=${KDE_SESSION_UID} XDG_CURRENT_DESKTOP=KDE 
> QT_QPA_PLATFORM=wayland PAM_KWALLET5_LOGIN=${PAM_KWALLET5_LOGIN} USER=${USER} 
> LANGUAGE=${LANGUAGE} XDG_SEAT=${XDG_SEAT} 
> XDG_SESSION_TYPE=${XDG_SESSION_TYPE} XCURSOR_SIZE=${XCURSOR_SIZE} 
> HOME=${HOME} DESKTOP_SESSION=${DESKTOP_SESSION} 
> XDG_SEAT_PATH=${XDG_SEAT_PATH} 
> DBUS_SESSION_BUS_ADDRESS=${DBUS_SESSION_BUS_ADDRESS} LOGNAME=${LOGNAME} 
> XDG_SESSION_CLASS=${XDG_SESSION_CLASS} XDG_SESSION_ID=${XDG_SESSION_ID} 
> PATH=${PATH} XDG_SESSION_PATH=${XDG_SESSION_PATH} 
> XDG_RUNTIME_DIR=${XDG_RUNTIME_DIR} XCURSOR_THEME=${XCURSOR_THEME} 
> LANG=${LANG} XDG_SESSION_DESKTOP=${XDG_SESSION_DESKTOP} 
> XCURSOR_PATH=${XCURSOR_PATH} XDG_VTNR=${XDG_VTNR} PWD=${PWD} 
> XDG_DATA_DIRS=${XDG_DATA_DIRS} XDG_CONFIG_DIRS=${XDG_CONFIG_DIRS} 
> @KWIN_WAYLAND_BIN_PATH@ --xwayland --libinput 
> --exit-with-session=@CMAKE_INSTALL_FULL_LIBEXECDIR@/startplasma
> 
> Matthias Klumpp wrote:
> Urgh, terrible! But I think this might just be the best workaround we can 
> come up with, given the circumstances. It at least protects against someone 
> adding new env vars which load bad code into the compositor. It might be an 
> issue as soon as kwin starts to require another env var which isn't in the 
> list, but that's an issue we can solve.
> I wonder if we can simplify that command somehow, though, e.g. by placing 
> the allowed variables in a file or new variable, to make this easier to read.
> Apart from that, +1 from me (I'll take a look at other DEs though, maybe 
> someone has come up with a bettr solution to this issue).
> 
> Xuetian Weng wrote:
> Woundn't this break user's workflow? Since startplasma is started by 
> kwin, the environment variable for the desktop will be derived from that.
> 
> If distribution has some global configuration under /etc/profile.d (which 
> is really common, e.g. openjdk, mozilla plugin path), they will not be set.

> Woundn't this break user's workflow?

Yes, but what do you prefer? Breaking user's workflows or a secure system?

There is nothing wrong of course with sourcing the env scripts in startplasma 
again and distributions using things like /etc/profile.d would be advised to do 
exactly that.


- Martin


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126115/#review88597
---


On Nov. 19, 2015, 1:22 p.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126115/
> ---
> 
> (Updated Nov. 19, 2015, 1:22 p.m.)
> 
> 
> Review request for Plasma, David Edmundson and Matthias Klumpp.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Any environment variable which can be used to specify a path to a
> binary object to be loaded in the KWin process bears the risk of
> being abused to add code to KWin to perform as a key logger.
> 
> E.g. an env variable pointing QT_PLUGIN_PATH to a location in $HOME
> and adjusting QT_STYLE_OVERRIDE to load a specific QStyle plugin from
> that location would allow to easily log all keys without KWin noticing.
> 
> As env variables can be specified in scripts sourced before the session
> starts there is not much KWin can do about that to protect itself.
> 
> This affects all the LD_* variables and any library KWin uses and
> loads plugins.
> 
> The list here is based on what I could find:
> * LD_* variables as specified in the man page
> * LIBGL_* and EGL_* as specified on mesa page
> * QT_* variables based on "git grep qgetenv" in qtbase and qtdeclarative
>   combined

Re: Review Request 126115: Unset environment variables before starting kwin_wayland

2015-11-19 Thread Xuetian Weng



> On Nov. 19, 2015, 2:08 p.m., Matthias Klumpp wrote:
> > Did you consider running the whole script with `env -i`, or (likely the 
> > better idea) run KWin with `env -i`?
> > That should sanitize the environment (unset all env vars, except for 
> > shell-defaults). You could then set exactly the variables you need, to the 
> > exact values you want, so we don't miss unsetting anything.
> 
> Martin Gräßlin wrote:
> No I didn't consider that, because I wasn't aware that this exists.
> 
> Martin Gräßlin wrote:
> Just tried with changing directly in the wayland session file. That 
> doesn't work at all. I think the main problem is that I lose important env 
> variables related to the logind session/dbus, etc.
> 
> So only way would be for the command to start kwin_wayland. But that as 
> well would require to set quite an amount of env variables, but worth a try.
> 
> Martin Gräßlin wrote:
> Just gave a try - the command looks horrible, but I got the session 
> started and env variables are properly filtered.
> 
> Command looks like this now:
> /usr/bin/env -i KDE_FULL_SESSION=true KDE_SESSION_VERSION=5 
> KDE_SESSION_UID=${KDE_SESSION_UID} XDG_CURRENT_DESKTOP=KDE 
> QT_QPA_PLATFORM=wayland PAM_KWALLET5_LOGIN=${PAM_KWALLET5_LOGIN} USER=${USER} 
> LANGUAGE=${LANGUAGE} XDG_SEAT=${XDG_SEAT} 
> XDG_SESSION_TYPE=${XDG_SESSION_TYPE} XCURSOR_SIZE=${XCURSOR_SIZE} 
> HOME=${HOME} DESKTOP_SESSION=${DESKTOP_SESSION} 
> XDG_SEAT_PATH=${XDG_SEAT_PATH} 
> DBUS_SESSION_BUS_ADDRESS=${DBUS_SESSION_BUS_ADDRESS} LOGNAME=${LOGNAME} 
> XDG_SESSION_CLASS=${XDG_SESSION_CLASS} XDG_SESSION_ID=${XDG_SESSION_ID} 
> PATH=${PATH} XDG_SESSION_PATH=${XDG_SESSION_PATH} 
> XDG_RUNTIME_DIR=${XDG_RUNTIME_DIR} XCURSOR_THEME=${XCURSOR_THEME} 
> LANG=${LANG} XDG_SESSION_DESKTOP=${XDG_SESSION_DESKTOP} 
> XCURSOR_PATH=${XCURSOR_PATH} XDG_VTNR=${XDG_VTNR} PWD=${PWD} 
> XDG_DATA_DIRS=${XDG_DATA_DIRS} XDG_CONFIG_DIRS=${XDG_CONFIG_DIRS} 
> @KWIN_WAYLAND_BIN_PATH@ --xwayland --libinput 
> --exit-with-session=@CMAKE_INSTALL_FULL_LIBEXECDIR@/startplasma
> 
> Matthias Klumpp wrote:
> Urgh, terrible! But I think this might just be the best workaround we can 
> come up with, given the circumstances. It at least protects against someone 
> adding new env vars which load bad code into the compositor. It might be an 
> issue as soon as kwin starts to require another env var which isn't in the 
> list, but that's an issue we can solve.
> I wonder if we can simplify that command somehow, though, e.g. by placing 
> the allowed variables in a file or new variable, to make this easier to read.
> Apart from that, +1 from me (I'll take a look at other DEs though, maybe 
> someone has come up with a bettr solution to this issue).

Woundn't this break user's workflow? Since startplasma is started by kwin, the 
environment variable for the desktop will be derived from that.

If distribution has some global configuration under /etc/profile.d (which is 
really common, e.g. openjdk, mozilla plugin path), they will not be set.


- Xuetian


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126115/#review88597
---


On Nov. 19, 2015, 12:22 p.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126115/
> ---
> 
> (Updated Nov. 19, 2015, 12:22 p.m.)
> 
> 
> Review request for Plasma, David Edmundson and Matthias Klumpp.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Any environment variable which can be used to specify a path to a
> binary object to be loaded in the KWin process bears the risk of
> being abused to add code to KWin to perform as a key logger.
> 
> E.g. an env variable pointing QT_PLUGIN_PATH to a location in $HOME
> and adjusting QT_STYLE_OVERRIDE to load a specific QStyle plugin from
> that location would allow to easily log all keys without KWin noticing.
> 
> As env variables can be specified in scripts sourced before the session
> starts there is not much KWin can do about that to protect itself.
> 
> This affects all the LD_* variables and any library KWin uses and
> loads plugins.
> 
> The list here is based on what I could find:
> * LD_* variables as specified in the man page
> * LIBGL_* and EGL_* as specified on mesa page
> * QT_* variables based on "git grep qgetenv" in qtbase and qtdeclarative
>   combined with Qt's documentation
> * "git grep getenv" in various KDE frameworks based on ldd output of KWin
> 
> Unfortunately the list is unlikely to be complete. If one env variable is
> missed, there is a risk. Even more each change in any library might
> introduce new variables.
> 
> The approach is futile, but needed till Linux has a

Re: Plasma/5.5 is branched

2015-11-19 Thread Aleix Pol

On Thu, Nov 19, 2015 at 3:45 PM, Jonathan Riddell  wrote:
> On Thu, Nov 19, 2015 at 03:29:48PM +0100, Aleix Pol wrote:
>> On Thu, Nov 19, 2015 at 2:16 PM, Jonathan Riddell  wrote:
>> > Plasma/5.5 is branched please but bugfixes in this branch so we can
>> > have a perfect 5.5.0 release.  Any new features are welcome in master.
>>
>> You forgot to branch Discover! :)
>
> Are you sure? I see a Plasma/5.5 branch and I even managed to bribe a
> sysadmin into giving me manager status so I could set the translations
> in projects.kde.org.

I see it now, I don't know what happened.

Thanks!
Aleix
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126115: Unset environment variables before starting kwin_wayland



> On Nov. 19, 2015, 2:08 nachm., Matthias Klumpp wrote:
> > Did you consider running the whole script with `env -i`, or (likely the 
> > better idea) run KWin with `env -i`?
> > That should sanitize the environment (unset all env vars, except for 
> > shell-defaults). You could then set exactly the variables you need, to the 
> > exact values you want, so we don't miss unsetting anything.
> 
> Martin Gräßlin wrote:
> No I didn't consider that, because I wasn't aware that this exists.
> 
> Martin Gräßlin wrote:
> Just tried with changing directly in the wayland session file. That 
> doesn't work at all. I think the main problem is that I lose important env 
> variables related to the logind session/dbus, etc.
> 
> So only way would be for the command to start kwin_wayland. But that as 
> well would require to set quite an amount of env variables, but worth a try.
> 
> Martin Gräßlin wrote:
> Just gave a try - the command looks horrible, but I got the session 
> started and env variables are properly filtered.
> 
> Command looks like this now:
> /usr/bin/env -i KDE_FULL_SESSION=true KDE_SESSION_VERSION=5 
> KDE_SESSION_UID=${KDE_SESSION_UID} XDG_CURRENT_DESKTOP=KDE 
> QT_QPA_PLATFORM=wayland PAM_KWALLET5_LOGIN=${PAM_KWALLET5_LOGIN} USER=${USER} 
> LANGUAGE=${LANGUAGE} XDG_SEAT=${XDG_SEAT} 
> XDG_SESSION_TYPE=${XDG_SESSION_TYPE} XCURSOR_SIZE=${XCURSOR_SIZE} 
> HOME=${HOME} DESKTOP_SESSION=${DESKTOP_SESSION} 
> XDG_SEAT_PATH=${XDG_SEAT_PATH} 
> DBUS_SESSION_BUS_ADDRESS=${DBUS_SESSION_BUS_ADDRESS} LOGNAME=${LOGNAME} 
> XDG_SESSION_CLASS=${XDG_SESSION_CLASS} XDG_SESSION_ID=${XDG_SESSION_ID} 
> PATH=${PATH} XDG_SESSION_PATH=${XDG_SESSION_PATH} 
> XDG_RUNTIME_DIR=${XDG_RUNTIME_DIR} XCURSOR_THEME=${XCURSOR_THEME} 
> LANG=${LANG} XDG_SESSION_DESKTOP=${XDG_SESSION_DESKTOP} 
> XCURSOR_PATH=${XCURSOR_PATH} XDG_VTNR=${XDG_VTNR} PWD=${PWD} 
> XDG_DATA_DIRS=${XDG_DATA_DIRS} XDG_CONFIG_DIRS=${XDG_CONFIG_DIRS} 
> @KWIN_WAYLAND_BIN_PATH@ --xwayland --libinput 
> --exit-with-session=@CMAKE_INSTALL_FULL_LIBEXECDIR@/startplasma

Urgh, terrible! But I think this might just be the best workaround we can come 
up with, given the circumstances. It at least protects against someone adding 
new env vars which load bad code into the compositor. It might be an issue as 
soon as kwin starts to require another env var which isn't in the list, but 
that's an issue we can solve.
I wonder if we can simplify that command somehow, though, e.g. by placing the 
allowed variables in a file or new variable, to make this easier to read.
Apart from that, +1 from me (I'll take a look at other DEs though, maybe 
someone has come up with a bettr solution to this issue).


- Matthias


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126115/#review88597
---


On Nov. 19, 2015, 12:22 nachm., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126115/
> ---
> 
> (Updated Nov. 19, 2015, 12:22 nachm.)
> 
> 
> Review request for Plasma, David Edmundson and Matthias Klumpp.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Any environment variable which can be used to specify a path to a
> binary object to be loaded in the KWin process bears the risk of
> being abused to add code to KWin to perform as a key logger.
> 
> E.g. an env variable pointing QT_PLUGIN_PATH to a location in $HOME
> and adjusting QT_STYLE_OVERRIDE to load a specific QStyle plugin from
> that location would allow to easily log all keys without KWin noticing.
> 
> As env variables can be specified in scripts sourced before the session
> starts there is not much KWin can do about that to protect itself.
> 
> This affects all the LD_* variables and any library KWin uses and
> loads plugins.
> 
> The list here is based on what I could find:
> * LD_* variables as specified in the man page
> * LIBGL_* and EGL_* as specified on mesa page
> * QT_* variables based on "git grep qgetenv" in qtbase and qtdeclarative
>   combined with Qt's documentation
> * "git grep getenv" in various KDE frameworks based on ldd output of KWin
> 
> Unfortunately the list is unlikely to be complete. If one env variable is
> missed, there is a risk. Even more each change in any library might
> introduce new variables.
> 
> The approach is futile, but needed till Linux has a secure way to start
> the session without sourcing env variable scripts from user owned
> locations.
> 
> 
> Diffs
> -
> 
>   startkde/startplasmacompositor.cmake 
> 1e46e5be0a0d733fb01e1a87a34ee3c73a06bf8c 
> 
> Diff: https://git.reviewboard.kde.org/r/126115/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

_

Re: Review Request 126102: [startkde] Move sourceing of env scripts to startplasma



> On Nov. 18, 2015, 3:40 p.m., David Edmundson wrote:
> > won't make a difference, SDDM sources a tonne before we get to you.
> 
> David Edmundson wrote:
> more specifically:
> 
> https://github.com/sddm/sddm/blob/master/data/scripts/wayland-session
> 
> we also have anything loaded from pam_env which can include 
> ~/.pam_environment depending on pam_env config.
> 
> Martin Gräßlin wrote:
> that's not good. Is there a chance we can get this changed in sddm or is 
> that needed?
> 
> David Edmundson wrote:
> The top one, we can do.
> 
> It will break some workflows (otherwise we wouldn't be sourcing them), 
> but speaking purely technically that's possible.
> 
> The second one:
> Getting the env from pam is something we *need* to do, and on almost 
> every distro that includes pam_env with it's hook to load user set things.
> There is an option to pam_env to make it not load envs from the user dir, 
> but that means every distro updating their pam files.
> 
> On arch:
> -required   pam_env.so
> +required   pam_env.so user_env=0
> 
> on the following files:
> system-auth
> system-login
> 
> we can't change that from sddm.
> 
> Martin Gräßlin wrote:
> I see, thanks for explaining. I'll discard this review request then. It's 
> clearly not a solution.
> 
> David Edmundson wrote:
> Just thought of one other thing we need to consider (though is obviously 
> solvable)
> 
> The formats KCM writes a small shell script 
> (.config/plasma-locale-settings.sh ) that gets sourced on startkde.
> You need this to get the right language. Otherwise it will randomly 
> remove the letter "u" in words at random.

ah yeah, that one was already sourced :-(


- Martin


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126102/#review88525
---


On Nov. 18, 2015, 4:36 p.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126102/
> ---
> 
> (Updated Nov. 18, 2015, 4:36 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> This change makes sure that the environment scripts are not sourced
> before KWin is started. No user installed scripts are allowed to modify
> KWin's environment as that opens an attack vector.
> 
> For example any binary plugin loaded into KWin (be it QStyle, QPT plugin,
> etc.) is able to become a key logger. If the env variables were allowed
> to be sourced before KWin is started a malicious application run as user
> (e.g. exploiting browser vulnerability) would be able to install a key
> logger. Required steps:
> 1. install a malicious QStyle plugin somewhere in $HOME
> 2. place a script in env to adjust variables to load the QStyle plugin
> 
> This would be enough to have a key logger on next login.
> 
> Given that the startup of KWin must not be affected by any scripts
> owned by user prior to startup.
> 
> The env scripts are now sourced as first step of startplasma, so
> for applications in the session there is no difference.
> 
> 
> Diffs
> -
> 
>   startkde/startplasma.cmake 8360a636d3f68c957a15158484360a611cfe3ff8 
>   startkde/startplasmacompositor.cmake 
> 8b5db615142455fd360c66504fc5d5a7754a029c 
> 
> Diff: https://git.reviewboard.kde.org/r/126102/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126115: Unset environment variables before starting kwin_wayland



> On Nov. 19, 2015, 3:08 p.m., Matthias Klumpp wrote:
> > Did you consider running the whole script with `env -i`, or (likely the 
> > better idea) run KWin with `env -i`?
> > That should sanitize the environment (unset all env vars, except for 
> > shell-defaults). You could then set exactly the variables you need, to the 
> > exact values you want, so we don't miss unsetting anything.
> 
> Martin Gräßlin wrote:
> No I didn't consider that, because I wasn't aware that this exists.
> 
> Martin Gräßlin wrote:
> Just tried with changing directly in the wayland session file. That 
> doesn't work at all. I think the main problem is that I lose important env 
> variables related to the logind session/dbus, etc.
> 
> So only way would be for the command to start kwin_wayland. But that as 
> well would require to set quite an amount of env variables, but worth a try.

Just gave a try - the command looks horrible, but I got the session started and 
env variables are properly filtered.

Command looks like this now:
/usr/bin/env -i KDE_FULL_SESSION=true KDE_SESSION_VERSION=5 
KDE_SESSION_UID=${KDE_SESSION_UID} XDG_CURRENT_DESKTOP=KDE 
QT_QPA_PLATFORM=wayland PAM_KWALLET5_LOGIN=${PAM_KWALLET5_LOGIN} USER=${USER} 
LANGUAGE=${LANGUAGE} XDG_SEAT=${XDG_SEAT} XDG_SESSION_TYPE=${XDG_SESSION_TYPE} 
XCURSOR_SIZE=${XCURSOR_SIZE} HOME=${HOME} DESKTOP_SESSION=${DESKTOP_SESSION} 
XDG_SEAT_PATH=${XDG_SEAT_PATH} 
DBUS_SESSION_BUS_ADDRESS=${DBUS_SESSION_BUS_ADDRESS} LOGNAME=${LOGNAME} 
XDG_SESSION_CLASS=${XDG_SESSION_CLASS} XDG_SESSION_ID=${XDG_SESSION_ID} 
PATH=${PATH} XDG_SESSION_PATH=${XDG_SESSION_PATH} 
XDG_RUNTIME_DIR=${XDG_RUNTIME_DIR} XCURSOR_THEME=${XCURSOR_THEME} LANG=${LANG} 
XDG_SESSION_DESKTOP=${XDG_SESSION_DESKTOP} XCURSOR_PATH=${XCURSOR_PATH} 
XDG_VTNR=${XDG_VTNR} PWD=${PWD} XDG_DATA_DIRS=${XDG_DATA_DIRS} 
XDG_CONFIG_DIRS=${XDG_CONFIG_DIRS} @KWIN_WAYLAND_BIN_PATH@ --xwayland 
--libinput --exit-with-session=@CMAKE_INSTALL_FULL_LIBEXECDIR@/startplasma


- Martin


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126115/#review88597
---


On Nov. 19, 2015, 1:22 p.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126115/
> ---
> 
> (Updated Nov. 19, 2015, 1:22 p.m.)
> 
> 
> Review request for Plasma, David Edmundson and Matthias Klumpp.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Any environment variable which can be used to specify a path to a
> binary object to be loaded in the KWin process bears the risk of
> being abused to add code to KWin to perform as a key logger.
> 
> E.g. an env variable pointing QT_PLUGIN_PATH to a location in $HOME
> and adjusting QT_STYLE_OVERRIDE to load a specific QStyle plugin from
> that location would allow to easily log all keys without KWin noticing.
> 
> As env variables can be specified in scripts sourced before the session
> starts there is not much KWin can do about that to protect itself.
> 
> This affects all the LD_* variables and any library KWin uses and
> loads plugins.
> 
> The list here is based on what I could find:
> * LD_* variables as specified in the man page
> * LIBGL_* and EGL_* as specified on mesa page
> * QT_* variables based on "git grep qgetenv" in qtbase and qtdeclarative
>   combined with Qt's documentation
> * "git grep getenv" in various KDE frameworks based on ldd output of KWin
> 
> Unfortunately the list is unlikely to be complete. If one env variable is
> missed, there is a risk. Even more each change in any library might
> introduce new variables.
> 
> The approach is futile, but needed till Linux has a secure way to start
> the session without sourcing env variable scripts from user owned
> locations.
> 
> 
> Diffs
> -
> 
>   startkde/startplasmacompositor.cmake 
> 1e46e5be0a0d733fb01e1a87a34ee3c73a06bf8c 
> 
> Diff: https://git.reviewboard.kde.org/r/126115/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126115: Unset environment variables before starting kwin_wayland



> On Nov. 19, 2015, 12:26 nachm., Sebastian Kügler wrote:
> > Possibly naive question: How would I use it with my custom-build setup, 
> > where I need vars like QT_PLUGIN_PATH, etc. set to be able to start the 
> > binaries at all?
> 
> Martin Gräßlin wrote:
> I don't have a solution for it yet and yes it also affects my setup. I 
> hope qt.conf can be used, but I don't know yet.
> 
> Matthias Klumpp wrote:
> A possible solution to that problem is to allow setting this in a 
> system-wide configuration file, or create a special KDE-specific 
> configuration which sets the script to a "debug mode", which doesn't filter 
> env vars.
> The important thing is that you need root access to modify these settings 
> (set it to debug mode or set additional variables).
> 
> Aleix Pol Gonzalez wrote:
> Wouldn't specifying them in /etc/profile.d/ work?
> 
> Currently I use it and it works fine:
> ```
> $ cat /etc/profile.d/kde5.sh 
> source ~kde-devel/kdescripts/deploykde5.sh
> ```

Not having tried this, it *should* work.
For Limba, which had a suid-root helper a while ago which was launched by the 
user, I once wrote a wrapper which filtered the environment and allowed only 
specific env-vars/values to exist. After cleaning up the environment, the 
wrapper execv'ed the real binary, replacing the wrapper process image with the 
real process. This has now been replaced with a much better solution not using 
this hackish approach anymore, but I wonder if it's something like this that we 
actually need, since this gives us full control over the environment of new 
processes.
(I am kind of curious now how GNOME handles this... Maybe I'll ask ^^)


- Matthias


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126115/#review88591
---


On Nov. 19, 2015, 12:22 nachm., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126115/
> ---
> 
> (Updated Nov. 19, 2015, 12:22 nachm.)
> 
> 
> Review request for Plasma, David Edmundson and Matthias Klumpp.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Any environment variable which can be used to specify a path to a
> binary object to be loaded in the KWin process bears the risk of
> being abused to add code to KWin to perform as a key logger.
> 
> E.g. an env variable pointing QT_PLUGIN_PATH to a location in $HOME
> and adjusting QT_STYLE_OVERRIDE to load a specific QStyle plugin from
> that location would allow to easily log all keys without KWin noticing.
> 
> As env variables can be specified in scripts sourced before the session
> starts there is not much KWin can do about that to protect itself.
> 
> This affects all the LD_* variables and any library KWin uses and
> loads plugins.
> 
> The list here is based on what I could find:
> * LD_* variables as specified in the man page
> * LIBGL_* and EGL_* as specified on mesa page
> * QT_* variables based on "git grep qgetenv" in qtbase and qtdeclarative
>   combined with Qt's documentation
> * "git grep getenv" in various KDE frameworks based on ldd output of KWin
> 
> Unfortunately the list is unlikely to be complete. If one env variable is
> missed, there is a risk. Even more each change in any library might
> introduce new variables.
> 
> The approach is futile, but needed till Linux has a secure way to start
> the session without sourcing env variable scripts from user owned
> locations.
> 
> 
> Diffs
> -
> 
>   startkde/startplasmacompositor.cmake 
> 1e46e5be0a0d733fb01e1a87a34ee3c73a06bf8c 
> 
> Diff: https://git.reviewboard.kde.org/r/126115/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasma/5.5 is branched

2015-11-19 Thread Jonathan Riddell

On Thu, Nov 19, 2015 at 03:29:48PM +0100, Aleix Pol wrote:
> On Thu, Nov 19, 2015 at 2:16 PM, Jonathan Riddell  wrote:
> > Plasma/5.5 is branched please but bugfixes in this branch so we can
> > have a perfect 5.5.0 release.  Any new features are welcome in master.
> 
> You forgot to branch Discover! :)

Are you sure? I see a Plasma/5.5 branch and I even managed to bribe a
sysadmin into giving me manager status so I could set the translations
in projects.kde.org.

Jonathan
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126115: Unset environment variables before starting kwin_wayland

2015-11-19 Thread Aleix Pol Gonzalez



> On Nov. 19, 2015, 1:26 p.m., Sebastian Kügler wrote:
> > Possibly naive question: How would I use it with my custom-build setup, 
> > where I need vars like QT_PLUGIN_PATH, etc. set to be able to start the 
> > binaries at all?
> 
> Martin Gräßlin wrote:
> I don't have a solution for it yet and yes it also affects my setup. I 
> hope qt.conf can be used, but I don't know yet.
> 
> Matthias Klumpp wrote:
> A possible solution to that problem is to allow setting this in a 
> system-wide configuration file, or create a special KDE-specific 
> configuration which sets the script to a "debug mode", which doesn't filter 
> env vars.
> The important thing is that you need root access to modify these settings 
> (set it to debug mode or set additional variables).

Wouldn't specifying them in /etc/profile.d/ work?

Currently I use it and it works fine:
```
$ cat /etc/profile.d/kde5.sh 
source ~kde-devel/kdescripts/deploykde5.sh
```


- Aleix


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126115/#review88591
---


On Nov. 19, 2015, 1:22 p.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126115/
> ---
> 
> (Updated Nov. 19, 2015, 1:22 p.m.)
> 
> 
> Review request for Plasma, David Edmundson and Matthias Klumpp.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Any environment variable which can be used to specify a path to a
> binary object to be loaded in the KWin process bears the risk of
> being abused to add code to KWin to perform as a key logger.
> 
> E.g. an env variable pointing QT_PLUGIN_PATH to a location in $HOME
> and adjusting QT_STYLE_OVERRIDE to load a specific QStyle plugin from
> that location would allow to easily log all keys without KWin noticing.
> 
> As env variables can be specified in scripts sourced before the session
> starts there is not much KWin can do about that to protect itself.
> 
> This affects all the LD_* variables and any library KWin uses and
> loads plugins.
> 
> The list here is based on what I could find:
> * LD_* variables as specified in the man page
> * LIBGL_* and EGL_* as specified on mesa page
> * QT_* variables based on "git grep qgetenv" in qtbase and qtdeclarative
>   combined with Qt's documentation
> * "git grep getenv" in various KDE frameworks based on ldd output of KWin
> 
> Unfortunately the list is unlikely to be complete. If one env variable is
> missed, there is a risk. Even more each change in any library might
> introduce new variables.
> 
> The approach is futile, but needed till Linux has a secure way to start
> the session without sourcing env variable scripts from user owned
> locations.
> 
> 
> Diffs
> -
> 
>   startkde/startplasmacompositor.cmake 
> 1e46e5be0a0d733fb01e1a87a34ee3c73a06bf8c 
> 
> Diff: https://git.reviewboard.kde.org/r/126115/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasma/5.5 is branched

2015-11-19 Thread Aleix Pol

On Thu, Nov 19, 2015 at 2:16 PM, Jonathan Riddell  wrote:
> Plasma/5.5 is branched please but bugfixes in this branch so we can
> have a perfect 5.5.0 release.  Any new features are welcome in master.

You forgot to branch Discover! :)

Aleix
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126115: Unset environment variables before starting kwin_wayland



> On Nov. 19, 2015, 3:08 p.m., Matthias Klumpp wrote:
> > Did you consider running the whole script with `env -i`, or (likely the 
> > better idea) run KWin with `env -i`?
> > That should sanitize the environment (unset all env vars, except for 
> > shell-defaults). You could then set exactly the variables you need, to the 
> > exact values you want, so we don't miss unsetting anything.
> 
> Martin Gräßlin wrote:
> No I didn't consider that, because I wasn't aware that this exists.

Just tried with changing directly in the wayland session file. That doesn't 
work at all. I think the main problem is that I lose important env variables 
related to the logind session/dbus, etc.

So only way would be for the command to start kwin_wayland. But that as well 
would require to set quite an amount of env variables, but worth a try.


- Martin


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126115/#review88597
---


On Nov. 19, 2015, 1:22 p.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126115/
> ---
> 
> (Updated Nov. 19, 2015, 1:22 p.m.)
> 
> 
> Review request for Plasma, David Edmundson and Matthias Klumpp.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Any environment variable which can be used to specify a path to a
> binary object to be loaded in the KWin process bears the risk of
> being abused to add code to KWin to perform as a key logger.
> 
> E.g. an env variable pointing QT_PLUGIN_PATH to a location in $HOME
> and adjusting QT_STYLE_OVERRIDE to load a specific QStyle plugin from
> that location would allow to easily log all keys without KWin noticing.
> 
> As env variables can be specified in scripts sourced before the session
> starts there is not much KWin can do about that to protect itself.
> 
> This affects all the LD_* variables and any library KWin uses and
> loads plugins.
> 
> The list here is based on what I could find:
> * LD_* variables as specified in the man page
> * LIBGL_* and EGL_* as specified on mesa page
> * QT_* variables based on "git grep qgetenv" in qtbase and qtdeclarative
>   combined with Qt's documentation
> * "git grep getenv" in various KDE frameworks based on ldd output of KWin
> 
> Unfortunately the list is unlikely to be complete. If one env variable is
> missed, there is a risk. Even more each change in any library might
> introduce new variables.
> 
> The approach is futile, but needed till Linux has a secure way to start
> the session without sourcing env variable scripts from user owned
> locations.
> 
> 
> Diffs
> -
> 
>   startkde/startplasmacompositor.cmake 
> 1e46e5be0a0d733fb01e1a87a34ee3c73a06bf8c 
> 
> Diff: https://git.reviewboard.kde.org/r/126115/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126115: Unset environment variables before starting kwin_wayland



> On Nov. 19, 2015, 3:08 p.m., Matthias Klumpp wrote:
> > Did you consider running the whole script with `env -i`, or (likely the 
> > better idea) run KWin with `env -i`?
> > That should sanitize the environment (unset all env vars, except for 
> > shell-defaults). You could then set exactly the variables you need, to the 
> > exact values you want, so we don't miss unsetting anything.

No I didn't consider that, because I wasn't aware that this exists.


- Martin


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126115/#review88597
---


On Nov. 19, 2015, 1:22 p.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126115/
> ---
> 
> (Updated Nov. 19, 2015, 1:22 p.m.)
> 
> 
> Review request for Plasma, David Edmundson and Matthias Klumpp.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Any environment variable which can be used to specify a path to a
> binary object to be loaded in the KWin process bears the risk of
> being abused to add code to KWin to perform as a key logger.
> 
> E.g. an env variable pointing QT_PLUGIN_PATH to a location in $HOME
> and adjusting QT_STYLE_OVERRIDE to load a specific QStyle plugin from
> that location would allow to easily log all keys without KWin noticing.
> 
> As env variables can be specified in scripts sourced before the session
> starts there is not much KWin can do about that to protect itself.
> 
> This affects all the LD_* variables and any library KWin uses and
> loads plugins.
> 
> The list here is based on what I could find:
> * LD_* variables as specified in the man page
> * LIBGL_* and EGL_* as specified on mesa page
> * QT_* variables based on "git grep qgetenv" in qtbase and qtdeclarative
>   combined with Qt's documentation
> * "git grep getenv" in various KDE frameworks based on ldd output of KWin
> 
> Unfortunately the list is unlikely to be complete. If one env variable is
> missed, there is a risk. Even more each change in any library might
> introduce new variables.
> 
> The approach is futile, but needed till Linux has a secure way to start
> the session without sourcing env variable scripts from user owned
> locations.
> 
> 
> Diffs
> -
> 
>   startkde/startplasmacompositor.cmake 
> 1e46e5be0a0d733fb01e1a87a34ee3c73a06bf8c 
> 
> Diff: https://git.reviewboard.kde.org/r/126115/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126115: Unset environment variables before starting kwin_wayland


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126115/#review88597
---


Did you consider running the whole script with `env -i`, or (likely the better 
idea) run KWin with `env -i`?
That should sanitize the environment (unset all env vars, except for 
shell-defaults). You could then set exactly the variables you need, to the 
exact values you want, so we don't miss unsetting anything.

- Matthias Klumpp


On Nov. 19, 2015, 12:22 nachm., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126115/
> ---
> 
> (Updated Nov. 19, 2015, 12:22 nachm.)
> 
> 
> Review request for Plasma, David Edmundson and Matthias Klumpp.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Any environment variable which can be used to specify a path to a
> binary object to be loaded in the KWin process bears the risk of
> being abused to add code to KWin to perform as a key logger.
> 
> E.g. an env variable pointing QT_PLUGIN_PATH to a location in $HOME
> and adjusting QT_STYLE_OVERRIDE to load a specific QStyle plugin from
> that location would allow to easily log all keys without KWin noticing.
> 
> As env variables can be specified in scripts sourced before the session
> starts there is not much KWin can do about that to protect itself.
> 
> This affects all the LD_* variables and any library KWin uses and
> loads plugins.
> 
> The list here is based on what I could find:
> * LD_* variables as specified in the man page
> * LIBGL_* and EGL_* as specified on mesa page
> * QT_* variables based on "git grep qgetenv" in qtbase and qtdeclarative
>   combined with Qt's documentation
> * "git grep getenv" in various KDE frameworks based on ldd output of KWin
> 
> Unfortunately the list is unlikely to be complete. If one env variable is
> missed, there is a risk. Even more each change in any library might
> introduce new variables.
> 
> The approach is futile, but needed till Linux has a secure way to start
> the session without sourcing env variable scripts from user owned
> locations.
> 
> 
> Diffs
> -
> 
>   startkde/startplasmacompositor.cmake 
> 1e46e5be0a0d733fb01e1a87a34ee3c73a06bf8c 
> 
> Diff: https://git.reviewboard.kde.org/r/126115/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126115: Unset environment variables before starting kwin_wayland



> On Nov. 19, 2015, 12:26 nachm., Sebastian Kügler wrote:
> > Possibly naive question: How would I use it with my custom-build setup, 
> > where I need vars like QT_PLUGIN_PATH, etc. set to be able to start the 
> > binaries at all?
> 
> Martin Gräßlin wrote:
> I don't have a solution for it yet and yes it also affects my setup. I 
> hope qt.conf can be used, but I don't know yet.

A possible solution to that problem is to allow setting this in a system-wide 
configuration file, or create a special KDE-specific configuration which sets 
the script to a "debug mode", which doesn't filter env vars.
The important thing is that you need root access to modify these settings (set 
it to debug mode or set additional variables).


- Matthias


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126115/#review88591
---


On Nov. 19, 2015, 12:22 nachm., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126115/
> ---
> 
> (Updated Nov. 19, 2015, 12:22 nachm.)
> 
> 
> Review request for Plasma, David Edmundson and Matthias Klumpp.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Any environment variable which can be used to specify a path to a
> binary object to be loaded in the KWin process bears the risk of
> being abused to add code to KWin to perform as a key logger.
> 
> E.g. an env variable pointing QT_PLUGIN_PATH to a location in $HOME
> and adjusting QT_STYLE_OVERRIDE to load a specific QStyle plugin from
> that location would allow to easily log all keys without KWin noticing.
> 
> As env variables can be specified in scripts sourced before the session
> starts there is not much KWin can do about that to protect itself.
> 
> This affects all the LD_* variables and any library KWin uses and
> loads plugins.
> 
> The list here is based on what I could find:
> * LD_* variables as specified in the man page
> * LIBGL_* and EGL_* as specified on mesa page
> * QT_* variables based on "git grep qgetenv" in qtbase and qtdeclarative
>   combined with Qt's documentation
> * "git grep getenv" in various KDE frameworks based on ldd output of KWin
> 
> Unfortunately the list is unlikely to be complete. If one env variable is
> missed, there is a risk. Even more each change in any library might
> introduce new variables.
> 
> The approach is futile, but needed till Linux has a secure way to start
> the session without sourcing env variable scripts from user owned
> locations.
> 
> 
> Diffs
> -
> 
>   startkde/startplasmacompositor.cmake 
> 1e46e5be0a0d733fb01e1a87a34ee3c73a06bf8c 
> 
> Diff: https://git.reviewboard.kde.org/r/126115/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126102: [startkde] Move sourceing of env scripts to startplasma

2015-11-19 Thread David Edmundson



> On Nov. 18, 2015, 2:40 p.m., David Edmundson wrote:
> > won't make a difference, SDDM sources a tonne before we get to you.
> 
> David Edmundson wrote:
> more specifically:
> 
> https://github.com/sddm/sddm/blob/master/data/scripts/wayland-session
> 
> we also have anything loaded from pam_env which can include 
> ~/.pam_environment depending on pam_env config.
> 
> Martin Gräßlin wrote:
> that's not good. Is there a chance we can get this changed in sddm or is 
> that needed?
> 
> David Edmundson wrote:
> The top one, we can do.
> 
> It will break some workflows (otherwise we wouldn't be sourcing them), 
> but speaking purely technically that's possible.
> 
> The second one:
> Getting the env from pam is something we *need* to do, and on almost 
> every distro that includes pam_env with it's hook to load user set things.
> There is an option to pam_env to make it not load envs from the user dir, 
> but that means every distro updating their pam files.
> 
> On arch:
> -required   pam_env.so
> +required   pam_env.so user_env=0
> 
> on the following files:
> system-auth
> system-login
> 
> we can't change that from sddm.
> 
> Martin Gräßlin wrote:
> I see, thanks for explaining. I'll discard this review request then. It's 
> clearly not a solution.

Just thought of one other thing we need to consider (though is obviously 
solvable)

The formats KCM writes a small shell script (.config/plasma-locale-settings.sh 
) that gets sourced on startkde.
You need this to get the right language. Otherwise it will randomly remove the 
letter "u" in words at random.


- David


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126102/#review88525
---


On Nov. 18, 2015, 3:36 p.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126102/
> ---
> 
> (Updated Nov. 18, 2015, 3:36 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> This change makes sure that the environment scripts are not sourced
> before KWin is started. No user installed scripts are allowed to modify
> KWin's environment as that opens an attack vector.
> 
> For example any binary plugin loaded into KWin (be it QStyle, QPT plugin,
> etc.) is able to become a key logger. If the env variables were allowed
> to be sourced before KWin is started a malicious application run as user
> (e.g. exploiting browser vulnerability) would be able to install a key
> logger. Required steps:
> 1. install a malicious QStyle plugin somewhere in $HOME
> 2. place a script in env to adjust variables to load the QStyle plugin
> 
> This would be enough to have a key logger on next login.
> 
> Given that the startup of KWin must not be affected by any scripts
> owned by user prior to startup.
> 
> The env scripts are now sourced as first step of startplasma, so
> for applications in the session there is no difference.
> 
> 
> Diffs
> -
> 
>   startkde/startplasma.cmake 8360a636d3f68c957a15158484360a611cfe3ff8 
>   startkde/startplasmacompositor.cmake 
> 8b5db615142455fd360c66504fc5d5a7754a029c 
> 
> Diff: https://git.reviewboard.kde.org/r/126102/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Plasma/5.5 is branched

2015-11-19 Thread Jonathan Riddell

Plasma/5.5 is branched please but bugfixes in this branch so we can
have a perfect 5.5.0 release.  Any new features are welcome in master.

Jonathan
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126091: Remove printscreen.khotkeys from KHotkeys package

2015-11-19 Thread David Edmundson



> On Nov. 16, 2015, 5:16 p.m., Hrvoje Senjan wrote:
> > >assuming, that is, distros push out the updates together
> > 
> > don't assume this ;-) at least send a mail to kde-distro-packagers about 
> > the sideeffects if those 3 are pushed asynchronously
> 
> Boudhayan Gupta wrote:
> 'course, I'll post there as well as add a big fat notice to the 
> kde-apps-announce posting that announces this special release of KSnapshot.
> 
> So ship it?

Lets email them first. Check they're ok with it, before we do it.


- David


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126091/#review88438
---


On Nov. 16, 2015, 5:06 p.m., Boudhayan Gupta wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126091/
> ---
> 
> (Updated Nov. 16, 2015, 5:06 p.m.)
> 
> 
> Review request for KDE Frameworks, Plasma and David Edmundson.
> 
> 
> Repository: khotkeys
> 
> 
> Description
> ---
> 
> After moving KSnapshot to Extragear I've modified it to install its own 
> khotkeys file (which it does correctly). Spectacle already installs its own 
> KHotkeys file, so there's no reason anymore for KHotkeys to include its own 
> PrintScreen hotkey file.
> 
> I'll push out a special release of KSnapshot for distributions to use once 
> the Plasma 5.5 version of KHotkeys is pushed out, so printscreen 
> functionality won't be broken on the desktop (assuming, that is, distros push 
> out the updates together).
> 
> 
> Diffs
> -
> 
>   data/CMakeLists.txt f3bcb57 
>   data/printscreen.khotkeys e583311 
> 
> Diff: https://git.reviewboard.kde.org/r/126091/diff/
> 
> 
> Testing
> ---
> 
> Doesn't install the printscreen.khotkeys file anymore
> 
> 
> Thanks,
> 
> Boudhayan Gupta
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126115: Unset environment variables before starting kwin_wayland



> On Nov. 19, 2015, 1:26 p.m., Sebastian Kügler wrote:
> > Possibly naive question: How would I use it with my custom-build setup, 
> > where I need vars like QT_PLUGIN_PATH, etc. set to be able to start the 
> > binaries at all?

I don't have a solution for it yet and yes it also affects my setup. I hope 
qt.conf can be used, but I don't know yet.


- Martin


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126115/#review88591
---


On Nov. 19, 2015, 1:22 p.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126115/
> ---
> 
> (Updated Nov. 19, 2015, 1:22 p.m.)
> 
> 
> Review request for Plasma, David Edmundson and Matthias Klumpp.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Any environment variable which can be used to specify a path to a
> binary object to be loaded in the KWin process bears the risk of
> being abused to add code to KWin to perform as a key logger.
> 
> E.g. an env variable pointing QT_PLUGIN_PATH to a location in $HOME
> and adjusting QT_STYLE_OVERRIDE to load a specific QStyle plugin from
> that location would allow to easily log all keys without KWin noticing.
> 
> As env variables can be specified in scripts sourced before the session
> starts there is not much KWin can do about that to protect itself.
> 
> This affects all the LD_* variables and any library KWin uses and
> loads plugins.
> 
> The list here is based on what I could find:
> * LD_* variables as specified in the man page
> * LIBGL_* and EGL_* as specified on mesa page
> * QT_* variables based on "git grep qgetenv" in qtbase and qtdeclarative
>   combined with Qt's documentation
> * "git grep getenv" in various KDE frameworks based on ldd output of KWin
> 
> Unfortunately the list is unlikely to be complete. If one env variable is
> missed, there is a risk. Even more each change in any library might
> introduce new variables.
> 
> The approach is futile, but needed till Linux has a secure way to start
> the session without sourcing env variable scripts from user owned
> locations.
> 
> 
> Diffs
> -
> 
>   startkde/startplasmacompositor.cmake 
> 1e46e5be0a0d733fb01e1a87a34ee3c73a06bf8c 
> 
> Diff: https://git.reviewboard.kde.org/r/126115/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126089: Metadata and color edit for plasma theme explorer


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126089/
---

(Updated Nov. 19, 2015, 12:27 p.m.)


Status
--

This change has been marked as submitted.


Review request for Plasma.


Changes
---

Submitted with commit c68db2a257c4ac775ebf28b7d5b6aa00db7c2936 by Marco Martin 
to branch master.


Repository: plasma-sdk


Description
---

* add a metadata editor functionality that allows to create a theme based upon 
the default one and edit some of the metadata afterwards

* add a graphical editor for the color file that has a little preview with fake 
widgets to give an idea how the colors will look


Diffs
-

  themeexplorer/package/contents/ui/ColorButton.qml PRE-CREATION 
  themeexplorer/package/contents/ui/ColorEditor.qml PRE-CREATION 
  themeexplorer/package/contents/ui/FormLabel.qml PRE-CREATION 
  themeexplorer/package/contents/ui/MetadataEditor.qml PRE-CREATION 
  themeexplorer/package/contents/ui/fakecontrols/Button.qml PRE-CREATION 
  themeexplorer/package/contents/ui/fakecontrols/CheckBox.qml PRE-CREATION 
  themeexplorer/package/contents/ui/fakecontrols/LineEdit.qml PRE-CREATION 
  themeexplorer/package/contents/ui/main.qml af61c39 
  themeexplorer/src/CMakeLists.txt c971784 
  themeexplorer/src/coloreditor.h PRE-CREATION 
  themeexplorer/src/coloreditor.cpp PRE-CREATION 
  themeexplorer/src/main.cpp f2ec4a2 
  themeexplorer/src/themelistmodel.h 3ae6eb4 
  themeexplorer/src/themelistmodel.cpp 32a6fd4 
  themeexplorer/src/thememodel.h 18e404d 
  themeexplorer/src/thememodel.cpp 5366a7e 

Diff: https://git.reviewboard.kde.org/r/126089/diff/


Testing
---


File Attachments


snapshot18.png
  
https://git.reviewboard.kde.org/media/uploaded/files/2015/11/16/2ec2a6f6-a9db-4527-b3ce-05c9ac4585a2__snapshot18.png
snapshot17.png
  
https://git.reviewboard.kde.org/media/uploaded/files/2015/11/16/3cba4a35-5bf0-485b-a94e-65e6fd07e778__snapshot17.png


Thanks,

Marco Martin

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126115: Unset environment variables before starting kwin_wayland


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126115/#review88591
---


Possibly naive question: How would I use it with my custom-build setup, where I 
need vars like QT_PLUGIN_PATH, etc. set to be able to start the binaries at all?

- Sebastian Kügler


On Nov. 19, 2015, 12:22 p.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126115/
> ---
> 
> (Updated Nov. 19, 2015, 12:22 p.m.)
> 
> 
> Review request for Plasma, David Edmundson and Matthias Klumpp.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Any environment variable which can be used to specify a path to a
> binary object to be loaded in the KWin process bears the risk of
> being abused to add code to KWin to perform as a key logger.
> 
> E.g. an env variable pointing QT_PLUGIN_PATH to a location in $HOME
> and adjusting QT_STYLE_OVERRIDE to load a specific QStyle plugin from
> that location would allow to easily log all keys without KWin noticing.
> 
> As env variables can be specified in scripts sourced before the session
> starts there is not much KWin can do about that to protect itself.
> 
> This affects all the LD_* variables and any library KWin uses and
> loads plugins.
> 
> The list here is based on what I could find:
> * LD_* variables as specified in the man page
> * LIBGL_* and EGL_* as specified on mesa page
> * QT_* variables based on "git grep qgetenv" in qtbase and qtdeclarative
>   combined with Qt's documentation
> * "git grep getenv" in various KDE frameworks based on ldd output of KWin
> 
> Unfortunately the list is unlikely to be complete. If one env variable is
> missed, there is a risk. Even more each change in any library might
> introduce new variables.
> 
> The approach is futile, but needed till Linux has a secure way to start
> the session without sourcing env variable scripts from user owned
> locations.
> 
> 
> Diffs
> -
> 
>   startkde/startplasmacompositor.cmake 
> 1e46e5be0a0d733fb01e1a87a34ee3c73a06bf8c 
> 
> Diff: https://git.reviewboard.kde.org/r/126115/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Review Request 126115: Unset environment variables before starting kwin_wayland


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126115/
---

Review request for Plasma, David Edmundson and Matthias Klumpp.


Repository: plasma-workspace


Description
---

Any environment variable which can be used to specify a path to a
binary object to be loaded in the KWin process bears the risk of
being abused to add code to KWin to perform as a key logger.

E.g. an env variable pointing QT_PLUGIN_PATH to a location in $HOME
and adjusting QT_STYLE_OVERRIDE to load a specific QStyle plugin from
that location would allow to easily log all keys without KWin noticing.

As env variables can be specified in scripts sourced before the session
starts there is not much KWin can do about that to protect itself.

This affects all the LD_* variables and any library KWin uses and
loads plugins.

The list here is based on what I could find:
* LD_* variables as specified in the man page
* LIBGL_* and EGL_* as specified on mesa page
* QT_* variables based on "git grep qgetenv" in qtbase and qtdeclarative
  combined with Qt's documentation
* "git grep getenv" in various KDE frameworks based on ldd output of KWin

Unfortunately the list is unlikely to be complete. If one env variable is
missed, there is a risk. Even more each change in any library might
introduce new variables.

The approach is futile, but needed till Linux has a secure way to start
the session without sourcing env variable scripts from user owned
locations.


Diffs
-

  startkde/startplasmacompositor.cmake 1e46e5be0a0d733fb01e1a87a34ee3c73a06bf8c 

Diff: https://git.reviewboard.kde.org/r/126115/diff/


Testing
---


Thanks,

Martin Gräßlin

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Review Request 126113: make event filters static to decrease installed filters on qApp


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126113/
---

Review request for KDE Frameworks and Plasma.


Bugs: 351923
http://bugs.kde.org/show_bug.cgi?id=351923


Repository: plasma-framework


Description
---

since seems there are so many event filters installed on the QApplication 
installed that may give performance issues, try to use separate, singleton 
watchers for them to decrease the amount of eventfilters called


Diffs
-

  src/declarativeimports/core/units.h fa2256e 
  src/declarativeimports/core/units.cpp 4e2adae 
  src/plasma/private/svg_p.h 597465e 
  src/plasma/svg.cpp bcceaf7 

Diff: https://git.reviewboard.kde.org/r/126113/diff/


Testing
---


Thanks,

Marco Martin

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Fwd: Organizing [another] cross-desktop meeting on Wayland on the Friday before Fosdem

On Thursday, November 19, 2015 11:12:24 AM Martin Graesslin wrote:
> it would be good if someone from the Plasma team could participate in this
> meeting. I'm unfortunately not available for going to FOSDEM this year due
> to personal reasons.

I won't be going to FOSDEM, either.
-- 
sebas

http://www.kde.org | http://vizZzion.org
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: RFC: plasmoid templates in plasma-sdk

On Wednesday, November 18, 2015 11:37:16 AM Marco Martin wrote:
> On Monday 16 November 2015, Sebastian Kügler wrote:
> > > yes, makes sense, most important is to have them in places harder to
> > > forget about
> >
> > 
> >
> > If in plasma-framework, it would kind of fit in with all the example
> > plasmoid code. Not sure if that, or plasma-sdk, both make sense to me,
> > perhaps plasma- sdk a bit more, even.
> 
> sooo, plasma-sdk or plasma-framework? is the same for me, i have them
> ready,  just to push wherever
> 
> the argument for plasma-framework to me is *if* other frameworks are going
> to  have their own templates in their repos as well

Let's go for plasma-framework.
-- 
sebas

http://www.kde.org | http://vizZzion.org

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126089: Metadata and color edit for plasma theme explorer


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126089/#review88590
---

Ship it!


Ship It!

- Sebastian Kügler


On Nov. 18, 2015, 11:10 a.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126089/
> ---
> 
> (Updated Nov. 18, 2015, 11:10 a.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-sdk
> 
> 
> Description
> ---
> 
> * add a metadata editor functionality that allows to create a theme based 
> upon the default one and edit some of the metadata afterwards
> 
> * add a graphical editor for the color file that has a little preview with 
> fake widgets to give an idea how the colors will look
> 
> 
> Diffs
> -
> 
>   themeexplorer/package/contents/ui/ColorButton.qml PRE-CREATION 
>   themeexplorer/package/contents/ui/ColorEditor.qml PRE-CREATION 
>   themeexplorer/package/contents/ui/FormLabel.qml PRE-CREATION 
>   themeexplorer/package/contents/ui/MetadataEditor.qml PRE-CREATION 
>   themeexplorer/package/contents/ui/fakecontrols/Button.qml PRE-CREATION 
>   themeexplorer/package/contents/ui/fakecontrols/CheckBox.qml PRE-CREATION 
>   themeexplorer/package/contents/ui/fakecontrols/LineEdit.qml PRE-CREATION 
>   themeexplorer/package/contents/ui/main.qml af61c39 
>   themeexplorer/src/CMakeLists.txt c971784 
>   themeexplorer/src/coloreditor.h PRE-CREATION 
>   themeexplorer/src/coloreditor.cpp PRE-CREATION 
>   themeexplorer/src/main.cpp f2ec4a2 
>   themeexplorer/src/themelistmodel.h 3ae6eb4 
>   themeexplorer/src/themelistmodel.cpp 32a6fd4 
>   themeexplorer/src/thememodel.h 18e404d 
>   themeexplorer/src/thememodel.cpp 5366a7e 
> 
> Diff: https://git.reviewboard.kde.org/r/126089/diff/
> 
> 
> Testing
> ---
> 
> 
> File Attachments
> 
> 
> snapshot18.png
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/11/16/2ec2a6f6-a9db-4527-b3ce-05c9ac4585a2__snapshot18.png
> snapshot17.png
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/11/16/3cba4a35-5bf0-485b-a94e-65e6fd07e778__snapshot17.png
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126107: Use absolute path to kwin_wayland


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126107/
---

(Updated Nov. 19, 2015, 11:06 a.m.)


Status
--

This change has been marked as submitted.


Review request for Plasma, David Edmundson and Matthias Klumpp.


Changes
---

Submitted with commit fdd56d1a71d7f3e990de7d458cc8e6930f62c633 by Martin 
Gräßlin to branch master.


Repository: plasma-workspace


Description
---

This prevents possible attacks to replace kwin_wayland through a
sourced env variable script which aliases kwin_wayland to evil tool.


Diffs
-

  startkde/startplasmacompositor.cmake 8b5db615142455fd360c66504fc5d5a7754a029c 

Diff: https://git.reviewboard.kde.org/r/126107/diff/


Testing
---


Thanks,

Martin Gräßlin

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126108: Use --exit-with-session in kwin_wayland start command


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126108/
---

(Updated Nov. 19, 2015, 11:06 a.m.)


Status
--

This change has been marked as submitted.


Review request for Plasma and Bhushan Shah.


Changes
---

Submitted with commit f1f2a44e930f65796f1b019d9f6a1829b28f77c4 by Martin 
Gräßlin to branch master.


Repository: plasma-workspace


Description
---

Ensures that we can log out. When startplasma script ends, KWin will
exit.


Diffs
-

  startkde/startplasmacompositor.cmake 8b5db615142455fd360c66504fc5d5a7754a029c 

Diff: https://git.reviewboard.kde.org/r/126108/diff/


Testing
---

Logout took me back to sddm.


Thanks,

Martin Gräßlin

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 125210: forceActivateWindow Dash's FullScreenWindow


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125210/
---

(Updated Nov. 19, 2015, 10:42 a.m.)


Status
--

This change has been marked as submitted.


Review request for Plasma.


Changes
---

Submitted with commit ad775885e2354b255c6f1a22630c335b86931086 by Kai Uwe 
Broulik to branch master.


Bugs: 352647
https://bugs.kde.org/show_bug.cgi?id=352647


Repository: plasma-desktop


Description
---

Although I find it interesting to complain about windows not bringing 
themselves to the foreground when explicitly enabling high focus stealing 
prevention, the dash should bring itself to the foreground nonetheless.


Diffs
-

  applets/kicker/plugin/fullscreenwindow.cpp b8ddf80 

Diff: https://git.reviewboard.kde.org/r/125210/diff/


Testing
---

Works.


Thanks,

Kai Uwe Broulik

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 125851: [kscreenlocker] Remove KWorkspace dependency


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125851/
---

(Updated Nov. 19, 2015, 10:39 vorm.)


Status
--

This change has been marked as submitted.


Review request for Plasma and Martin Gräßlin.


Repository: plasma-workspace


Description
---

Removes the sessions stuff


Diffs
-

  ksmserver/screenlocker/greeter/CMakeLists.txt e6768f0 
  ksmserver/screenlocker/greeter/greeterapp.cpp a88b61a 
  ksmserver/screenlocker/greeter/sessions.h 8a4c042 
  ksmserver/screenlocker/greeter/sessions.cpp 5f831d5 

Diff: https://git.reviewboard.kde.org/r/125851/diff/


Testing
---


Thanks,

Kai Uwe Broulik

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 125991: [Widget Explorer] Allow uninstalling user-installed applets

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125991/
---

(Updated Nov. 19, 2015, 10:25 a.m.)

Status
--

This change has been marked as submitted.

Review request for Plasma and KDE Usability.

Changes
---

Submitted with commit cc1a9b52119f4fa441dbc08d0188c03688d9768b by Kai Uwe
Broulik to branch master.

Repository: plasma-desktop

Description
---

The no longer enabled tooltip also contained the uninstall button. This
restores the uninstall functionality similar to the wallpaper dialog.

User-installed applets get an uninstall button. I chose to always show it
rather than on hover since only a few applets are likely to be uninstallable
and I don't want to play the guessing-game, perhaps we should introduce a
filter for "User-installed applets" similar to the (less useful) "running"
ones. Clicking the button will queue the uninstallation which can be cancelled
anytime the dialog is still opened. As soon as the dialog closes, the actual
uninstall is executed.

Multiple applets can be enqueued simultaneously.

Diffs
-

desktoppackage/contents/explorer/AppletDelegate.qml 5a81b91
desktoppackage/contents/explorer/WidgetExplorer.qml af27229
desktoppackage/contents/views/Desktop.qml b555fea

Diff: https://git.reviewboard.kde.org/r/125991/diff/

Testing
---

Installed plasmoid through drag and drop, uninstalled after fixing an uninstall
bug (Review 125990)

The tooltip says "Undo uninstall". I just noticed I should probably fade the
applet name too.

File Attachments

Uninstall before

https://git.reviewboard.kde.org/media/uploaded/files/2015/11/08/adcb91e0-a8c2-4481-89f1-139b4e716da3__uninstall1.png
Undo uninstall

https://git.reviewboard.kde.org/media/uploaded/files/2015/11/08/ebdae6ad-28bd-42f0-bb36-bfa6dfd3cc30__uninstall2.png

Thanks,

Kai Uwe Broulik

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 125898: [Clipboard plasmoid] Fade out text where buttons are


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125898/
---

(Updated Nov. 19, 2015, 10:19 a.m.)


Status
--

This change has been marked as submitted.


Review request for Plasma, KDE Usability and Martin Gräßlin.


Changes
---

Submitted with commit 8f8aa215e8314916816ac465b1fc503ed4ac41c7 by Kai Uwe 
Broulik to branch master.


Bugs: 354602
https://bugs.kde.org/show_bug.cgi?id=354602


Repository: plasma-workspace


Description
---

This avoids the buttons from blending in with the text making it look ugly.

This could allow us to use flat ToolButtons again since four round things in a 
row look strange imho.


Diffs
-

  applets/clipboard/contents/ui/ClipboardItemDelegate.qml b263656 

Diff: https://git.reviewboard.kde.org/r/125898/diff/


Testing
---

Works


File Attachments


Hovered item
  
https://git.reviewboard.kde.org/media/uploaded/files/2015/10/31/b4fb7d52-90fe-4954-a1c0-462a86c31f4a__klipperlinebreaks3.png


Thanks,

Kai Uwe Broulik

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126104: Make networkmanager-qt an optional dependency


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126104/#review88581
---

Ship it!


Ship It!

- Marco Martin


On Nov. 18, 2015, 3:55 p.m., Alex Richardson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126104/
> ---
> 
> (Updated Nov. 18, 2015, 3:55 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> I can't compile networkmanager-qt on my current system because the version
> of NetworkManager seems to be too old.
> 
> Also not every system has NetworkManager (FreeBSD?) so it should be
> optional.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt d21a2b7a7774ac712f905f1db1ee478dca10b45c 
>   dataengines/CMakeLists.txt 014da10aac5629be202bd5ad96012f817bf846ef 
> 
> Diff: https://git.reviewboard.kde.org/r/126104/diff/
> 
> 
> Testing
> ---
> 
> compiles
> 
> 
> Thanks,
> 
> Alex Richardson
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Fwd: Organizing [another] cross-desktop meeting on Wayland on the Friday before Fosdem

2015-11-19 Thread Martin Graesslin

Hi all,

it would be good if someone from the Plasma team could participate in this 
meeting. I'm unfortunately not available for going to FOSDEM this year due to 
personal reasons.

Cheers
Martin

--  Forwarded Message  --

Subject: Organizing [another] cross-desktop meeting on Wayland on the Friday 
before Fosdem
Date: Thursday, November 19, 2015, 10:37:53 AM CET
From: Hans de Goede 

Hi,

At LinuxCon I was approached by some Enlightenment people with the request
to organize another pre-fosdem wayland meeting as the last one was deemed
useful and they thought having another one would be good.

I just got a go-ahead from my manager to organize this again, so here we are.

The plan is to start around 10 am (so that people who live nearby can travel
Friday morning) and then use the entire day till we head out for dinner /
the fosdem beer event.

IIRC the main topic the Enlightenment people want to discuss is xdg-shell
extensions for more traditional window management functionality. So that
is one item for the agenda. If other people have other things they
would like to discuss, please do a reply-to-all to this mail and then
we can build a list of things to discuss that way.

Regards,

Hans

-

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 125898: [Clipboard plasmoid] Fade out text where buttons are


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125898/#review88579
---

Ship it!


Ship It!

- Sebastian Kügler


On Nov. 1, 2015, 1:35 p.m., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125898/
> ---
> 
> (Updated Nov. 1, 2015, 1:35 p.m.)
> 
> 
> Review request for Plasma, KDE Usability and Martin Gräßlin.
> 
> 
> Bugs: 354602
> https://bugs.kde.org/show_bug.cgi?id=354602
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> This avoids the buttons from blending in with the text making it look ugly.
> 
> This could allow us to use flat ToolButtons again since four round things in 
> a row look strange imho.
> 
> 
> Diffs
> -
> 
>   applets/clipboard/contents/ui/ClipboardItemDelegate.qml b263656 
> 
> Diff: https://git.reviewboard.kde.org/r/125898/diff/
> 
> 
> Testing
> ---
> 
> Works
> 
> 
> File Attachments
> 
> 
> Hovered item
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/10/31/b4fb7d52-90fe-4954-a1c0-462a86c31f4a__klipperlinebreaks3.png
> 
> 
> Thanks,
> 
> Kai Uwe Broulik
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 125991: [Widget Explorer] Allow uninstalling user-installed applets


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125991/#review88578
---

Ship it!


Ship It!

- Sebastian Kügler


On Nov. 17, 2015, 9:37 p.m., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125991/
> ---
> 
> (Updated Nov. 17, 2015, 9:37 p.m.)
> 
> 
> Review request for Plasma and KDE Usability.
> 
> 
> Repository: plasma-desktop
> 
> 
> Description
> ---
> 
> The no longer enabled tooltip also contained the uninstall button. This 
> restores the uninstall functionality similar to the wallpaper dialog.
> 
> User-installed applets get an uninstall button. I chose to always show it 
> rather than on hover since only a few applets are likely to be uninstallable 
> and I don't want to play the guessing-game, perhaps we should introduce a 
> filter for "User-installed applets" similar to the (less useful) "running" 
> ones. Clicking the button will queue the uninstallation which can be 
> cancelled anytime the dialog is still opened. As soon as the dialog closes, 
> the actual uninstall is executed.
> 
> Multiple applets can be enqueued simultaneously.
> 
> 
> Diffs
> -
> 
>   desktoppackage/contents/explorer/AppletDelegate.qml 5a81b91 
>   desktoppackage/contents/explorer/WidgetExplorer.qml af27229 
>   desktoppackage/contents/views/Desktop.qml b555fea 
> 
> Diff: https://git.reviewboard.kde.org/r/125991/diff/
> 
> 
> Testing
> ---
> 
> Installed plasmoid through drag and drop, uninstalled after fixing an 
> uninstall bug (Review 125990)
> 
> The tooltip says "Undo uninstall". I just noticed I should probably fade the 
> applet name too.
> 
> 
> File Attachments
> 
> 
> Uninstall before
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/11/08/adcb91e0-a8c2-4481-89f1-139b4e716da3__uninstall1.png
> Undo uninstall
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/11/08/ebdae6ad-28bd-42f0-bb36-bfa6dfd3cc30__uninstall2.png
> 
> 
> Thanks,
> 
> Kai Uwe Broulik
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 125898: [Clipboard plasmoid] Fade out text where buttons are


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125898/#review88577
---


>From my side OK, so if nobody from the QML experts gives a shipIt, please 
>consider this comment as a ShipIt.

- Martin Gräßlin


On Nov. 1, 2015, 2:35 p.m., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125898/
> ---
> 
> (Updated Nov. 1, 2015, 2:35 p.m.)
> 
> 
> Review request for Plasma, KDE Usability and Martin Gräßlin.
> 
> 
> Bugs: 354602
> https://bugs.kde.org/show_bug.cgi?id=354602
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> This avoids the buttons from blending in with the text making it look ugly.
> 
> This could allow us to use flat ToolButtons again since four round things in 
> a row look strange imho.
> 
> 
> Diffs
> -
> 
>   applets/clipboard/contents/ui/ClipboardItemDelegate.qml b263656 
> 
> Diff: https://git.reviewboard.kde.org/r/125898/diff/
> 
> 
> Testing
> ---
> 
> Works
> 
> 
> File Attachments
> 
> 
> Hovered item
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/10/31/b4fb7d52-90fe-4954-a1c0-462a86c31f4a__klipperlinebreaks3.png
> 
> 
> Thanks,
> 
> Kai Uwe Broulik
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 125898: [Clipboard plasmoid] Fade out text where buttons are


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125898/#review88576
---


Ping

I try to avoid QtGraphicalEffects items whereever possible (they're quite 
heavy), hence the rotated Rectangle.

- Kai Uwe Broulik


On Nov. 1, 2015, 1:35 nachm., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125898/
> ---
> 
> (Updated Nov. 1, 2015, 1:35 nachm.)
> 
> 
> Review request for Plasma, KDE Usability and Martin Gräßlin.
> 
> 
> Bugs: 354602
> https://bugs.kde.org/show_bug.cgi?id=354602
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> This avoids the buttons from blending in with the text making it look ugly.
> 
> This could allow us to use flat ToolButtons again since four round things in 
> a row look strange imho.
> 
> 
> Diffs
> -
> 
>   applets/clipboard/contents/ui/ClipboardItemDelegate.qml b263656 
> 
> Diff: https://git.reviewboard.kde.org/r/125898/diff/
> 
> 
> Testing
> ---
> 
> Works
> 
> 
> File Attachments
> 
> 
> Hovered item
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/10/31/b4fb7d52-90fe-4954-a1c0-462a86c31f4a__klipperlinebreaks3.png
> 
> 
> Thanks,
> 
> Kai Uwe Broulik
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126100: [KRunner] Forward KRunner switchUser to KSMServer


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126100/
---

(Updated Nov. 19, 2015, 9:26 a.m.)


Status
--

This change has been marked as submitted.


Review request for Plasma and Vishesh Handa.


Changes
---

Submitted with commit 2dcd1e0bd89a63feca1dcac1f0ee30c5844485ff by Kai Uwe 
Broulik to branch master.


Repository: plasma-workspace


Description
---

To maintain compatibility with users of that interface, calling it will forward 
that to KSMServer showing the new user switcher


Diffs
-

  krunner/view.cpp 8841128 

Diff: https://git.reviewboard.kde.org/r/126100/diff/


Testing
---

Works.


Thanks,

Kai Uwe Broulik

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126108: Use --exit-with-session in kwin_wayland start command

2015-11-19 Thread Bhushan Shah


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126108/#review88571
---

Ship it!


Ship It!

- Bhushan Shah


On Nov. 19, 2015, 2:03 p.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126108/
> ---
> 
> (Updated Nov. 19, 2015, 2:03 p.m.)
> 
> 
> Review request for Plasma and Bhushan Shah.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Ensures that we can log out. When startplasma script ends, KWin will
> exit.
> 
> 
> Diffs
> -
> 
>   startkde/startplasmacompositor.cmake 
> 8b5db615142455fd360c66504fc5d5a7754a029c 
> 
> Diff: https://git.reviewboard.kde.org/r/126108/diff/
> 
> 
> Testing
> ---
> 
> Logout took me back to sddm.
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Review Request 126108: Use --exit-with-session in kwin_wayland start command


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126108/
---

Review request for Plasma and Bhushan Shah.


Repository: plasma-workspace


Description
---

Ensures that we can log out. When startplasma script ends, KWin will
exit.


Diffs
-

  startkde/startplasmacompositor.cmake 8b5db615142455fd360c66504fc5d5a7754a029c 

Diff: https://git.reviewboard.kde.org/r/126108/diff/


Testing
---

Logout took me back to sddm.


Thanks,

Martin Gräßlin

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126106: Add path to kwin_wayland binary to KWin's installed CMakeConfig