1. 26 Sep, 2020 1 commit
  2. 20 Sep, 2020 1 commit
  3. 18 Jul, 2020 1 commit
  4. 13 Jul, 2020 1 commit
  5. 26 Jan, 2020 5 commits
  6. 25 Jan, 2020 1 commit
  7. 23 Jan, 2020 1 commit
    • Christoph Cullmann's avatar
      introduce new Kate application icon · 4dfae551
      Christoph Cullmann authored
      this is inspired by the Kate mascot
      Tyson Tan worked on this for us, this is the initial version we
      want to try out
      the icons were renamed here to ensure indenpendent of the
      chosen icon theme one at all gets the new icon
      this is by intent no text block anymore, we want to get
      some recognizable branding
  8. 21 Jan, 2020 1 commit
  9. 04 Jan, 2020 1 commit
  10. 17 Nov, 2019 1 commit
  11. 06 Oct, 2019 1 commit
  12. 28 Sep, 2019 1 commit
  13. 24 Sep, 2019 1 commit
  14. 16 Sep, 2019 1 commit
  15. 07 Sep, 2019 1 commit
  16. 30 May, 2019 1 commit
    • Sergio Martins's avatar
      Fix window activation on Windows · 18b05cb1
      Sergio Martins authored
      Windows doesn't use the dbus stuff and instead uses qtsingleapplication,
      which does support window activation if setActivationWindow is called.
      setActivationWindow wasn't called anywhere.
      Differential Revision: 21485
      CCBUG: 407288
  17. 14 Apr, 2019 1 commit
  18. 08 Jan, 2019 1 commit
  19. 26 Nov, 2018 1 commit
  20. 18 Oct, 2018 1 commit
  21. 28 Sep, 2018 1 commit
  22. 19 Aug, 2018 1 commit
  23. 14 Aug, 2018 1 commit
  24. 12 Aug, 2018 1 commit
  25. 19 Jun, 2018 1 commit
  26. 31 May, 2018 1 commit
    • Nate Graham's avatar
      Re-allow running Kate and KWrite as the actual root user (but still not using sudo) · bf6d5b75
      Nate Graham authored
      The original change (9adcebd3) to prevent sudo usage broke the use case of running KWrite or Kate while logged in as the actual `root` user with a GUI session. This is how the Kali distro is set up by default, so the original change amounted to making Kate and KWrite not launch at all on this KDE distro.
      This patch re-enables running as the actual root user, but keeps blocking usage via `sudo` or `kdesu`. There are no negative security implications associated with re-allowing usage via the root user, since if you're running a GUI session, you were already exposed to the original security threat and Kate and KWrite do not increase the attack surface.
      I have submitted a similar change for Dolphin that has been accepted (D12795), but @elvisangelaccio wants that to go in at the same time as this, to keep them in sync.
      BUG: 387973
      FIXED-IN: 18.08.0
      Test Plan:
      - Log in as normal user and run `sudo kate` or `sudo kwrite`: you get an error message.
      - Log in as normal user and run `kdesu kate` or `kdesu kwrite`: you get an error message.
      - Log in as the root user and run Kate or KWrite normally: it works.
      Reviewers: #kate, dhaumann, cullmann, #ktexteditor
      Reviewed By: #kate, dhaumann, #ktexteditor
      Subscribers: kwrite-devel, elvisangelaccio
      Tags: #kate
      Differential Revision: https://phabricator.kde.org/D13138
  27. 02 Apr, 2018 1 commit
    • Алексей Шилин's avatar
      Don't restart the blocking process on session restore · 0a73e00e
      Алексей Шилин authored
      All blocking Kate processes were restarted on session restore which
      led to launching (possibly) multiple redundant instances.
      This change asks the session manager to not restart such processes.
      Note: QObject::connect() is used here because the session manager
      can't be accessed directly according to the documentation [1]:
          In Qt, session management requests for action are handled by
          the two signals QGuiApplication::commitDataRequest() and
          QGuiApplication::saveStateRequest(). Both provide a reference
          to a QSessionManager object as argument. The session manager
          can only be accessed in slots invoked by these signals.
       [1] http://doc.qt.io/qt-5/qsessionmanager.html#details
      BUG: 360066
      FIXED-IN: 18.04
      Test Plan:
        0. Make sure that Plasma is configured to restore previous session
           on startup.
        1. Open Dolphin and create 'test1' and 'test2' text files.
        2. Open 'test1' in Kate from Dolphin.
        3. Open 'test2' in the already running Kate instance from Dolphin.
        4. Log out and back in. Check that there are no redundant Kate
           instances running.
      Reviewers: #kate, dhaumann
      Reviewed By: #kate, dhaumann
      Subscribers: ngraham, dhaumann
      Tags: #kate
      Differential Revision: https://phabricator.kde.org/D11818
  28. 15 Sep, 2017 1 commit
  29. 08 May, 2017 2 commits
  30. 17 Feb, 2017 1 commit
    • Martin Flöser's avatar
      Disallow executing kate and kwrite as root on Linux · 9adcebd3
      Martin Flöser authored
      Running GUI applications as root is a huge security risk. Especially
      the X server is not secured for that. Non-root applications can easily
      interact with a root running application and thus try to exploit simple
      bugs in either kate/kwrite itself or in the underlying libraries such
      as Qt, XLib or xcb.
      In addition kate can be abused to just open the konsole window and any
      command can be entered using the XTest extension. This was demonstrated
      for dolphin in [1]. The application itself cannot do anything to protect
      against it.
      On Wayland the situation can be considered worse as the compositor is
      running as the normal user and is not protected to handle root windows.
      It can be rather trivial to attack the root running application from the
      compositor through interfaces such as scripting. This is not in the aim
      of the compositors to protect against.
      The common use case why users start editors as root is to edit root
      owned files. This is a valid use case, but there is no need to run the
      application as root. Instead one can use sudoedit to run the application
      as user and still be able to edit as root.
      This change introduces a check whether the application is started as
      root before any interaction with X or Wayland happens, that is prior to
      creating the QApplication. If it is detected that we run as root, we
      exit and print an information about how to properly edit an application
      in kwrite/kate as root. The text is deliberatly not translated to keep
      the threat from running as root as low as possible.
      The output is:
      martin@martin-desktop: ~ $ sudo /opt/kf5/bin/kate
      Executing Kate as root is not possible. To edit files as root use:
      SUDO_EDITOR=kate sudoedit <file>
      martin@martin-desktop: ~ $ sudo /opt/kf5/bin/kwrite
      Executing Kate as root is not possible. To edit files as root use:
      SUDO_EDITOR=kwrite sudoedit <file>
      [1] http://git.net/ml/kwrite-devel/2016-01/msg00011.html
      Test Plan: See output
      Reviewers: #kate
      Subscribers: kwrite-devel
      Differential Revision: https://phabricator.kde.org/D4634
  31. 08 Jan, 2017 1 commit
  32. 22 Nov, 2016 1 commit
  33. 07 Sep, 2016 1 commit
  34. 05 Sep, 2016 1 commit
  35. 16 Aug, 2016 1 commit
    • Harald Sitter's avatar
      explicitly initialize kcrash · 9c260515
      Harald Sitter authored
      To quote the documentation
      > Call this in your main() to ensure that the crash handler is always
      > launched.
      The problem in particular is that cmake will not actually link kcrash even
      if it is in the link list but not used. ::initialize for the most part just
      makes sure that we actually link against kcrash and thus have it
      initialized via qt static init magic.
      Reviewers: dhaumann
      Reviewed By: dhaumann
      Subscribers: dhaumann, kwrite-devel, #kate
      Differential Revision: https://phabricator.kde.org/D2460