Review Request 122382: [klipper] Sync history to disk after each change

[Martin Gräßlin]

> On Feb. 3, 2015, 8:36 a.m., Martin Gräßlin wrote:
> > David E. just pointed out that this could become quite heavy for the system as the history size can be large (up to 2048 items).
> 
> Martin Gräßlin wrote:
>     Unfortunately I couldn't find out why we support up to 2048 items. Commit message is just:
>     
>     commit da8394ce42a24726392265436c3808f1ac9389aa
>     Author: Esben Mose Hansen <kde at mosehansen.dk>
>     Date:   Fri Nov 19 22:28:55 2004 +0000
>     
>         Introduced support for large clipboard histories up to 2048 items.
>         
>         svn path=/trunk/kdebase/klipper/; revision=364353
> 
> Martin Klapetek wrote:
>     I think 2048 is insane. Can we make it like 32 by default and have it configurable with big fat warning when you choose more than say 100? 
>     
>     Btw. does klipper store things encrypted or something? There's also a security concern, especially if your klipper contains passwords, that saving those to disk unecrypted after each copy is insecure (all you need is a watcher on the history file).
> 
> Martin Gräßlin wrote:
>     > I think 2048 is insane. Can we make it like 32 by default and have it configurable with big fat warning when you choose more than say 100? 
>     
>     The default is 7. Adding a warning is certainly possible.
>     
>     > Btw. does klipper store things encrypted or something? There's also a security concern, especially if your klipper contains passwords, that saving those to disk unecrypted after each copy is insecure (all you need is a watcher on the history file).
>     
>     If you are able to watch the file you are also able to connect to the X11 Display and just do a passive keyboard grab. So caring about that probably doesn't matter (on Wayland this might get more important - maybe we can skip passwords). But setting the file to 600 is certainly a good idea.

> But setting the file to 600 is certainly a good idea.

this seems already to be the case (though I don't find the code for it)


- Martin


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


On Feb. 2, 2015, 4:12 p.m., Martin Gräßlin wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122382/
> -----------------------------------------------------------
> 
> (Updated Feb. 2, 2015, 4:12 p.m.)
> 
> 
> Review request for Plasma and Eike Hein.
> 
> 
> Bugs: 343333
>     https://bugs.kde.org/show_bug.cgi?id=343333
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> -------
> 
> By invoking saveHistory after each change we ensure that the clipboard
> doesn't lose data in case klipper (or in dataengine mode plasmashell)
> crashes.
> 
> To not cause stalls, the saving is performed in a thread using
> QtConcurrentRun. As klipper itself is not thread save a Mutex is
> used to lock changes in the HistoryModel.
> 
> BUG: 343333
> FIXED-IN: 5.3.0
> 
> 
> Diffs
> -----
> 
>   klipper/klipper.cpp d49c165759f8171931167687c3b36b3a9d7dee07 
>   klipper/CMakeLists.txt a08f062480b15f32f049e2d0d0e311dbe2964c02 
>   klipper/historymodel.h 78f955f0ec4b8f27dbca0573b68691be6a30e3be 
>   klipper/historymodel.cpp 51860f6c3aca1022a2b721c27c859fc721915353 
> 
> Diff: https://git.reviewboard.kde.org/r/122382/diff/
> 
> 
> Testing
> -------
> 
> looked at ~/.local/share/klipper/history2.lst in Okteta, changed clipboard and pressed F5 in Okteta. Repeated these steps multiple times.
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20150203/2c299810/attachment-0001.html>