Framework for encrypted storage for apps

[Johan Ouwerkerk]

Hi all,

Bhushan asked me to kick off a discussion on frameworks-devel about a
problem we face for otpclient. We are looking for help in deciding how
to best implement storage of the secrets which are needed by the app.
Any insights from people who are more familiar with frameworks would
be much appreciated!

To give a bit of context: otpclient is an app (flatpak) to generate
two factor authentication login codes, similar to Google
Authenticator. One thing the app needs to do is to store the 'secret'
associated with each configured account securely, because the security
of the 2FA relies on it. Effectively, this bit of data is just as
sensitive as the main password to the account.

Right now otpclient does not yet implement this (securely) and one
reason for that is we are still not sure how we should do this in a
KDE context. I suppose from our perspective the main questions are:

 1. What Qt or KDE framework is appropriate for this?
 2. If there is no such framework, then what KDE technology could
possibly serve as the basis for such a library? And should it become
part of frameworks?
 3. How should this work? In particular in the context of apps such as flatpaks?

We are aware that KWallet ant Qt Keychain exist but we have some concerns there:

 1. (On KDE) these libraries wind up calling dbus. We would like to
avoid plain text out-of-process communication of secrets, especially
communication through a 'shared' channel (for obvious reasons).
 2. In particular with KDE Wallet it was suggested that the wallet
itself may, in fact, not be encrypted.

Another possible contender is Plasma Vault, but we don't really know
how that would work in the context of an app, especially a flatpak
app.

Ideally we could use something that offers the following:

 1. Operating on encrypted files, which are encrypted and decrypted on
the fly. This would facilitate an easy import/export scheme for the
app (backups!), and should also work in the context of flatpaks.
 2. Ideally while being unopinionated about what is stored "inside"
the encrypted file
 3. Easy to present to the user in terms of UX. It should not be
necessary to do some kind of local setup first before being able to
use the app, the otpclient should work as secure as we can make it out
of the box.
 4. Consumed as a library which does not need to 'talk' over unsecured
channels. This would help avoid leaking secrets and make it easier for
otpclient to control the lifetime of secrets held in memory. I.e. we
would be able to flush secrets if we detect that the computer is about
to suspend or on idling for too long.

In particular we do not need lots of system integration, and we do not
necessarily have to be super portable yet.

So with all that said: what do you think? How should we tackle this?
Can KDE offer framework level support for this? And if so, what would
be the framework for that?

Re: Framework for encrypted storage for apps

[Johan Ouwerkerk]

Hi all,

Many thanks for the responses so far. To address the various points raised:

It is acceptable for me if the user must type their password. Keychain
integration etc. are optional extras. QCA looks like it might be a
good fit for what I need.
One question I have with regards to keychain integration here is: are
the Windows and MacOS X platforms "properly" secure or at least
properly designed for this? That is: would it be a good addition to
use Qt Keychain for integrating with Keychains optionally on MacOS X
and/or Windows, and wail and gnash teeth for the fact it won't work on
Linux/FreeBSD?

However I feel somewhat intimidated by QCA's lack of proper publicly
accessible documentation. To give an overview of what I have tried
thus far:

 - KDE apidox which appeared to consist of a single overview page,
with a broken image (dead URL) and a dead link to examples (404):
https://api.kde.org/kdesupport-api/qca-apidocs/
 - inqlude (https://inqlude.org/libraries/qca.html) which had a link
that redirects via someone's private site to KDE Userbase which
appears to be about Qt 4.2 times (https://userbase.kde.org/QCA) and
another link that is dead (404)
 - On the advice of tsdegos on Matrix, I tried figuring out via the
headers /include what is was supposed to do. I did not get very far. I
am probably just too unfamiliar with the code structure and especially
how this is supposed to interact with the backing plugins to figure
out by myself how to do e.g. "key derivation", "salting" or
"encryption" by just looking at these headers.
 - However I did find an example on the Internet which at first glance
looks to explain how to do PBKDF#2 with QCA at least:
https://developersarea.wordpress.com/2014/11/27/cryptographic-hashes-in-qt-hmac-sha1-pbkdf2-md5/
(Scroll to the bottom of that blog post for the PBKDF#2 bits) Does
that also look reasonable to you, or are there glaring issues beside
the uses of QStrings for nearly everything?
 - I find it fairly hard to Google for this, because search terms like
"qca qt secure random" simply don't appear to return useful results
here. My background here is mostly some familiarity with JCA, so I'm
looking for things like "key derivation", "pbkdf", "secure random" in
combination with "qca" and "qt". I

So suppose I use QCA, I still have a few questions about how to go about this:

 - How do I obtain a "secure random" primitive in QCA? I can of course
make do by reading bytes from /dev/random on Linux, but it would be
nicer to have a portable primitive -- especially since the OpenSSL
plugin should be able to access such an implementation (OpenSSL).
 - How do I set up padding? I mean, sure I can pad my input manually
until I have a next multiple of #keysize bits/bytes. Is that solid
practice or does QCA already provide proper padding schemes out of the
box like PKCS#7?
  - How do I even construct the encryption itself? I can't seem to
find anything other thant public/private key encryption examples
(using some public key with OAEP), but I would like AES with a
suitable scheme/mode here. Mainly I would like a MAC on the encrypted
data because I want to be able to assert that the ciphertext is not
accidentally corrupted, say. After all if I can store the secrets in
an encrypted and robust fashion, then I can let the user export their
data safely for backup purposes.

So basically I guess that what I am asking: any examples, suggestions
or other pointers which I can use as further starting points/context
to figure this out? Thanks a lot in advance for all your help!

Kind regards,

- Johan Ouwerkerk




 -

On Sat, Oct 5, 2019 at 9:09 AM Ivan Čukić  wrote:
>
> Hi Johan,
>
> One important question here is how do you want the secrets to be unlocked.
> Is the user going to type in some master password every time the otpclient is
> started?
>
> If that is the case, you can use QCA to encrypt and decrypt the data you need
> to store securely.
>
> If that is not the case - if you don't want to always ask the user for the
> password, then you can expect quite a complicated story of how to make
> something like kwallet safe.
>
> >  1. (On KDE) these libraries wind up calling dbus. We would like to
> > avoid plain text out-of-process communication of secrets, especially
> > communication through a 'shared' channel (for obvious reasons).
> >  2. In particular with KDE Wallet it was suggested that the wallet
> > itself may, in fact, not be encrypted.
>
> Another huge problem of kwallet is that it can not authenticate which
> application is asking for the password. I was told that this could be easier
> to do with flatpaks, but it will still need significant changes to how kwallet
> works.
>
> > Another possible contender is Plasma Vault, but we don't really know
> > how that would wor

Re: Banning QNetworkAccessManager

[Johan Ouwerkerk]

On Mon, Feb 3, 2020 at 11:27 AM laurent Montel  wrote:
>
> Le lundi 3 février 2020, 10:49:10 CET David Edmundson a écrit :
> > I updated:
> >
> > https://community.kde.org/Policies/API_to_Avoid
> >
> > Which had no mention of this.
> >
> > David
>
> I think that you made an error
>
> "networkAccessManger->setAttribute(QNetworkRequest::FollowRedirectsAttribute,
> true); "
> Doesn't exist it's a enum from QnetworkRequest::RedirectPolicy
> And  FollowRedirectsAttribute is old value
> It seems that we need to use QnetworkRequest::NoLessSafeRedirectPolicy
> directly no ?
>

Yes, the example code is definitely wrong: in the real world redirects
are an attack vector. A few cases to consider:

 * Loops of redirects (could happen if the site is broken)
 * Leaking sensitive information via e.g. the Referrer header

Regards,

 - Johan

Re: Fixing QNetworkAccessManager use

[Johan Ouwerkerk]

On Wed, Feb 19, 2020 at 2:09 PM Friedrich W. H. Kossebau
 wrote:
>
> Personally I am still unsure what the actual issue is. Why are redirects
> needed at all. Why all the address changes all the time?
>

It is part of the HTTP spec for servers to be able to inform clients
that resource /foo/bar has moved to /bar/baz, either temporarily or
permanently.
This can be used to do things like mapping /retrieve/document/by/alias
-> /documents/actual/document-id, or to redirect to different hosts
entirely, or to inform plain text HTTP clients to upgrade to using
HTTPS instead. (HSTS is a spec describing how a server can then ask
the client to subsequently enforce its policy preference for when to
connect over HTTPS.)

The main difference between temporary and permanent redirects is that
clients are allowed to "remember" when a resource moved in the case of
permanent redirects so they can optimise subsequent calls to the moved
resources (bypassing the redirect entirely). But as you can see, the
temporary redirect is something that could be used to do load
balancing: assume /resource is expensive to compute or retrieve, then
put a proxy in front which load balances to the actual pool of servers
using temporary redirects. (Of course you could argue that in such a
case maybe round-robin DNS is a better solution altogether.)

Regards,

- Johan

Re: Update on Status of Gitlab Migration

[Johan Ouwerkerk]

On Sat, Apr 11, 2020 at 11:36 AM Ben Cooksley  wrote:
>
> Should anyone have any questions on the above, please let us know.
>

Does the migration also mean that `git.kde.org` push URL will be
retired and would need to be remapped to `invent.kde.org`?

In that case, it would be good to have a grace period after the
initial migration to Gitlab so kdesrc-build (etc.) could be updated
before the cut off date to perform this migration automatically for
the user. I expect such a grace period would not need to last very
long because the feature would be trivial to implement.

Regards,

- Johan

Re: Update on Status of Gitlab Migration

[Johan Ouwerkerk]

On Sat, Apr 11, 2020 at 11:36 AM Ben Cooksley  wrote:
>
> To help assist with this, it would be appreciated if all holders of a
> KDE Developer account could please login on our Gitlab instance (at
> https://invent.kde.org/) and ensure they are listed as a 'Developer'
> of the KDE group. You can do this by checking the 'Groups' tab of your
> Profile on Gitlab.
>

This is a more direct URL that goes straight to the members page of
the KDE group: https://invent.kde.org/groups/kde/-/group_members

If you are logged in on invent.kde.org you should be able to use the
search box to find yourself (by identity.kde.org name, in my case).

Regards,

- Johan

Re: KDE CI: Administration » Dependency Build Extragear stable-kf5-qt5 AndroidQt5.14 - Build # 10 - Still Failing!

[Johan Ouwerkerk]

On Thu, Apr 16, 2020 at 10:51 AM Ben Cooksley  wrote:

> Hi all,
>
> Does anyone know why the below would have suddenly started failing a
> little while back?
>
> Thanks,
> Ben
>

Based on the error message I would expect this to be related to the effort
to fix Android pkgs not being generated for both 32bit and 64bit ARM.

Regards,

- Johan

Re: Update on Status of Gitlab Migration

[Johan Ouwerkerk]

On Sat, Apr 11, 2020 at 8:39 PM Ben Cooksley  wrote:
>
> Yes, the hostname git.kde.org will be fully retired as part of this 
> transition.
>
> From my understanding kdesrc-build will automatically pick this up
> once we update sysadmin/repo-metadata to show the new repository
> paths.
> This is something we'll confirm with mpyne though to ensure we can
> make the cutover as smooth as possible.
>

Just to be clear, my understanding based on reading the
`Updated/Git.pm` module is that KDE repo paths are abstracted via
~/.gitconfig URL remapping using `insteadOf`and `pushInsteadOf`.
Currently the code manipulates the user's ~/.gitconfig to bind the
correct mappings to the `kde:` prefix (this happens even before
cloning sysadmin repos for metadata).

So if my understanding of the code is correct, the entire switch over
is transparent provided that kdesrc-build is updated beforehand to set
the updated value for `pushInsteadOf`. We already have the same
mechanism in place in kdesrc-build for ensuring that people use
https://anongit.kde.org instead of git://anongit.kde.org when
cloning/fetching.

>
> Depending on how things look we may also make available a script that
> will update the configuration of a repository to reflect both the
> change in hostname as well as the change in path.
>

A cleanup script could be handy. I think kdesrc-build will
automatically pick up new repo paths from metadata and that should
work transparently, but the old clones may get left behind as well.
People who use the kdesrc-build option to ignore KDE repo structure
shouldn't be affected at all.

Regards,

- Johan

Re: Update on Status of Gitlab Migration

[Johan Ouwerkerk]

On Sat, Apr 11, 2020 at 11:03 PM Michael Pyne  wrote:
>
> On Sat, Apr 11, 2020 at 09:25:11PM +0200, Johan Ouwerkerk wrote:
>
> >
> > A cleanup script could be handy. I think kdesrc-build will
> > automatically pick up new repo paths from metadata and that should
> > work transparently, but the old clones may get left behind as well.
> > People who use the kdesrc-build option to ignore KDE repo structure
> > shouldn't be affected at all.
>
> (...)
>
> All of the kde: repositories use the kde:foo syntax, where the 'foo'
> comes from the 'repopath' parameter of the sysadmin/repo-metadata YAML
> files.
>

Yes the only reason why a cleanup script might be needed is if the
logical path used to express the repo in dependency information
changes at the same time. E.g. suppose a `frameworks/kf5foo` gets
remapped to `frameworks/kf5/foo` or something like that. In that case
unless you use the flat repository layout, kdesrc-build would try to
clone a new `frameworks/kf5/foo` repo, leaving your old
`frameworks/kf5foo` to consume some wasted disk space.

>
> We may need to do on-the-fly conversion of the kde: repo paths if they
> won't be expressible as 'kde:foo' in the future, but we should have the
> information needed to do this in kdesrc-build to make this happen
> on-the-fly.
>

Yes, this should be fairly straight forward: we could do a `git remote
set-url` based on what the repo metadata tells us before updating a
local clone. In fact: we could build this right now and sell it as
"automagically recover your upstream".  :)

I might try to hack something up tomorrow or monday for that.

Regards,

- Johan

Re: Update on Status of Gitlab Migration

[Johan Ouwerkerk]

On Sat, Apr 11, 2020 at 9:01 PM Nicolás Alvarez
 wrote:
>
> How would it work during the "grace period"? Keeping an outdated read-only 
> mirror on the old URL? I have done some research into redirecting or 
> remapping from the old URL to the new one so we can keep it working for a 
> longer period of time, and it's harder than it seems... It can be done but I 
> need to be convinced that it's actually necessary / worth the effort.
>

My idea was that when the button is pushed people could update their
kdesrc-build once, run it once and continue to work as if nothing
happened. If a grace period is not feasible from a sysadmin
perspective, then things could still work if at the same time that
git.kde.org is decommissioned a pre-prepared MR/commit is merged into
kdesrc-build that fixes it. At the very least the code that sets the
pushInsteadOf mapping in the user's ~/.gitconfig would become outdated
and needs to be fixed at that point.

Regards,

- Johan

Re: Update on Status of Gitlab Migration

[Johan Ouwerkerk]

On Sun, Apr 12, 2020 at 12:49 AM Johan Ouwerkerk  wrote:
>
> Yes the only reason why a cleanup script might be needed is if the
> logical path used to express the repo in dependency information
> changes at the same time. E.g. suppose a `frameworks/kf5foo` gets
> remapped to `frameworks/kf5/foo` or something like that. In that case
> unless you use the flat repository layout, kdesrc-build would try to
> clone a new `frameworks/kf5/foo` repo, leaving your old
> `frameworks/kf5foo` to consume some wasted disk space.
>

This is obviously a poor example, but the same problem occurs if
something moves from playground to extragear. Basically if the
`projectpath` YAML key changes.

Regards,

- Johan

Re: Update on Status of Gitlab Migration

[Johan Ouwerkerk]

On Sun, Apr 12, 2020 at 1:06 AM Ben Cooksley  wrote:
>
> On Sun, Apr 12, 2020 at 11:04 AM Johan Ouwerkerk  
> wrote:
> >
> > On Sun, Apr 12, 2020 at 12:49 AM Johan Ouwerkerk  
> > wrote:
> > >
> > > Yes the only reason why a cleanup script might be needed is if the
> > > logical path used to express the repo in dependency information
> > > changes at the same time. E.g. suppose a `frameworks/kf5foo` gets
> > > remapped to `frameworks/kf5/foo` or something like that. In that case
> > > unless you use the flat repository layout, kdesrc-build would try to
> > > clone a new `frameworks/kf5/foo` repo, leaving your old
> > > `frameworks/kf5foo` to consume some wasted disk space.
> > >
> >
> > This is obviously a poor example, but the same problem occurs if
> > something moves from playground to extragear. Basically if the
> > `projectpath` YAML key changes.
>
> I had been considering adding the Gitlab Project ID number to the YAML
> metadata files as a way of allowing us to track projects through their
> whole lifetime.
>

That would be very nice, because then `kdesrc-build` could implement
an `arc patch` type feature in a more straightforward fashion. So
people could type things like `kdesrc-build juk!55` as a shorthand for
checkout remote HEAD of whatever branch MR 55 is for `juk`.

Regards,

- Johan

Re: Update on Status of Gitlab Migration

[Johan Ouwerkerk]

On Sun, Apr 12, 2020 at 12:49 AM Johan Ouwerkerk  wrote:
>
> >
> > We may need to do on-the-fly conversion of the kde: repo paths if they
> > won't be expressible as 'kde:foo' in the future, but we should have the
> > information needed to do this in kdesrc-build to make this happen
> > on-the-fly.
> >
>
> Yes, this should be fairly straight forward: we could do a `git remote
> set-url` based on what the repo metadata tells us before updating a
> local clone. In fact: we could build this right now and sell it as
> "automagically recover your upstream".  :)
>
> I might try to hack something up tomorrow or monday for that.
>

A basic version of this is now available via:
https://invent.kde.org/kde/kdesrc-build/-/merge_requests/27
With this feature sysadmin should now be free to change the repopath
value in the metadata YAML and kdesrc-build will reconfigure the
remote URL appropriately automatically. This works as long as the same
`kde:$path` expression works for both fetch and push, i.e. the layout
on the anongit.kde.org network must match with the layout of
git.kde.org/invent.kde.org. If necessary a simple path prefix change
could still work with a minor update to the pushInsteadOf mapping,
e.g. when repos on invent are mapped to kde/   instead of
/.

You can also experiment with setting invent.kde.org as the push URL by
setting x-invent-kde-push-urls to true in your rc file. The effect
should be visible through git remote -vv afterwards. (Disable the
setting and re-run again afterwards because this will obviously break
your push URLs as long as the Gitlab migration hasn't completed yet).

Regards,

- Johan

Re: Information regarding upcoming Gitlab Migration: clarifications

[Johan Ouwerkerk]

On Fri, May 1, 2020 at 6:38 AM Nate Graham  wrote:
>
> On 4/30/20 5:59 PM, Aleix Pol wrote:
> > El jue., 30 de abr. de 2020 a la(s) 18:15, Albert Astals Cid
> >> Am I the only person that just has all the repos on the same folder? I 
> >> thought it was the common thing to do :?
> >
> > I do too
>
> Same here. kdesrc-build's default settings do this,
>

No, that is not the default. By default the hierarchy is mirrored.

> and download all
> repos into ~/kde/src without any of the levels of hierarchy.
>

But it is sufficiently common that there is a dedicated setting for
it: `ignore-kde-structure`. Kinda does what it says on the tin ;)

> This would
> seem to require unique repo names, no?
>

Yes, it does.

Also whether the hierarchy is preserved locally or not, kdesrc-build
currently requires that the leaf names ($repo.git) be unique. It
cannot fully and consistently distinguish between a maui/dialer and a
plasma-mobile/dialer because at certain points in Perl we map to/from
module names which are mapped onto those leaf names (i.e. both would
be considered "dialer" and it would be anybody's guess at this point
what you'd get if you did a `kdesrc-build dialer`).

Might be fixable, but is definitely not trivial and would require
people to help review and test. Also would require some "cleverness"
to preserve the ability to refer to modules by their leaf names when
possible (i.e. continuing to be able to do `kdesrc-build kate`),
otherwise kdesrc-build becomes a *lot* less user friendly all of a
sudden.

Regards,

- Johan

D29095: New much simpler mouse icon that works in both light and dark breeze

[Johan Ouwerkerk]

ouwerkerk added a comment.


  In D29095#655060 , @saligari wrote:
  
  > > Maybe this is just me but the overall width to height ratio makes it seem 
that the closest "real" mice are quite dated as well.
  >
  > I don't understand what you mean with this, do you think it should be 
slimmer? I kind of followed the old one in this, even if it doesn't seem like 
it. Right now its ratio is ~0,67 while microsoft's standard old mouse is kind 
of close to that (but has a different shape)
  
  
  Right but that shape makes quite a bit of difference here -- especially since 
real mouse design is *all about* shape. You'll also note that the actual mouse 
you took for inspiration has a much more pronounced "hump" (as many modern mice 
do).
  
  > I don't think an icon for its place needs side buttons, fast scrolling 
buttons etc. Being kind of abstract, simple and out of the way I think is a 
plus in its case.
  
  That is an artistic choice.
  
  > The ergonomic mouse shape/ especially existing icon's left side is really 
cool, but unfortunately I don't have the skills to make something like this (I 
hardly know how to use inkscape). I think it takes a lot of skill to be able to 
create something realistic but also manage to strike a balance and I don't even 
have a little skill.
  
  Rght, I wouldn't have much of a clue either on how to make *any* icon. (It's 
just a lot easier to criticise than it is to create...) If on the other hand 
you really like the old mouse icon as well but just want it to work better for 
dark themes then another option might be to recolour the old icon to get better 
contrast out of it against the dark background.

REPOSITORY
  R266 Breeze Icons

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

To: saligari, #vdg
Cc: ouwerkerk, ndavis, ngraham, kde-frameworks-devel, LeGast00n, cblack, 
michaelh, bruns

D29095: New much simpler mouse icon that works in both light and dark breeze

[Johan Ouwerkerk]

ouwerkerk added a comment.


  In D29095#655214 , @ngraham wrote:
  
  > FWIW all the mice in my house have this exact shape, but they're black, not 
gray. So I don't think the shape is too old-fashioned per se. It's the gray 
color that's anacrhonistic part,  since it's a very 90s/early 2000s color and 
modern mice tend to be black: F8254746: Screenshot_20200422_210145.png 

  
  
  Well, one thing you'll also note is that modern mice tend to be narrower 
(and/or have a twist in the shape and/or have a slight inwards curve towards 
the middle (top and bottom are wider than the middle part).
  
  Bruns comment about right-handed mice (gradient) is due to the quite 
asymmetrical shape many modern mice use for ergonomic reasons (RSI).

REPOSITORY
  R266 Breeze Icons

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

To: saligari, #vdg
Cc: bruns, ouwerkerk, ndavis, ngraham, kde-frameworks-devel, LeGast00n, cblack, 
michaelh

D29095: New much simpler mouse icon that works in both light and dark breeze

[Johan Ouwerkerk]

ouwerkerk added a comment.


  One thing I find really striking about the new icon is how closely it 
resembles stress balls:
  
  F8253927: stress-ball-mice.png 
  
  I kinda like that... :)

REPOSITORY
  R266 Breeze Icons

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

To: saligari, #vdg
Cc: ouwerkerk, ndavis, ngraham, kde-frameworks-devel, LeGast00n, cblack, 
michaelh, bruns

D29095: New much simpler mouse icon that works in both light and dark breeze

[Johan Ouwerkerk]

ouwerkerk added a comment.


  Hmm, the old icon also has the virtue of looking more like genuine computer 
mice: it resembles the logi(tech) style of mouse design quite well. This one is 
rather abstract while at the same time somehow not looking like any "real" 
mouse would, in particular in its outline: it misses all the traits of mouse 
design that would make it more ergonomic or smaller. Maybe this is just me but 
the overall width to height ratio makes it seem that the closest "real" mice 
are quite dated as well.
  
  F8253896: so-many-mice.png 
  
  This may be deliberate, but if you complain about it being boring you might 
want to mimic existing mice design a bit closer. For example: why not ditch 
white (which is also a trait of many elderly/ancient mice) and go with a 
different colour (bright colours are quite popular for laptop mice).

REPOSITORY
  R266 Breeze Icons

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

To: saligari, #vdg
Cc: ouwerkerk, ndavis, ngraham, kde-frameworks-devel, LeGast00n, cblack, 
michaelh, bruns

Re: Deprecate KRandomSequence ?

[Johan Ouwerkerk]

On Tue, Jun 30, 2020 at 7:32 PM Albert Astals Cid  wrote:
>
> >
> > If an application was relying on the random application sequence, it
> > probably has bigger problems.
>
> Why? It's exactly what KRandomSequence (and QRandomGenerator) promise to do.
>
> And at least on KPat this is really useful.
>
> You can directly seed the random generator from the "Create new game" UI, so 
> if there's a bug found in say game 1232145345, you can tell me that and then 
> everyone can reproduce that bug since starting game 1232145345 gives everyone 
> the same random numbers.
>
> Cheers,
>   Albert
>

As I read it, the only thing that could change is that KRandomSequence
and QRandomGenerator will produce different outputs for the same seed
value because the underlying PRNG may be different. So that might
introduce a backwards incompatible change if you rely on the output of
the sequence remaining stable between two versions of KPat. However,
seeding it with a fixed value and then consuming the sequence should
remain fully reproducible between two instances of the *same* KPat
version.

Regards,

- Johan

Re: KCGroups in KDEreview

[Johan Ouwerkerk]

On Thu, Dec 3, 2020 at 12:48 PM Kevin Ottens  wrote:
>
> Good point. Got a similar question though, which other unit types would be
> useful to control? Reason being that API wise I'd smell an enum for something
> like this.
>

Well if this library would evolve towards C++ API for interacting with
systemd, then the following could potentially be useful:

- *.timer (cron jobs)
- *.scope (confinement to a cgroup)
- *.slice (resource partitioning between cgroups)
- *.mount (mount options for filesystems)
- *.automount (automatically activating a mount for plug and play
removable storage without too much fsck risk)
- *.service (managing background services)
- *.socket (in case your services do things with socket based
activation, e.g. dbs)

Some of these are obviously already covered, but because I'm not
familiar with the KCGroups code base I just listed them for the sake
of completeness. Covering them all would give you the basic building
block for a GUI for systemd more generally.

Additionally, if the "all the wrappers included" approach is taken it
might eventually also be worth considering systemd-homed (portable
user directories backed by encrypted storage).

Regards,

- Johan Ouwerkerk

Re: RFC: Switching to min Qt version 5.14 for KF on December 14th

[Johan Ouwerkerk]

On Thu, Dec 17, 2020 at 12:21 AM Friedrich W. H. Kossebau
 wrote:
>
> Though please those who want to support Qt 5.13 for some more time, consider
> adding support for KDE CI then.
>

Right, that Qt 5.13 ship has sailed with the recent CI purge by Ben to
clean up the old 5.13 builders. If we want to keep supporting it,
maybe that ship should be recalled to port...

Regards,

- Johan

Re: TableView (QtQuick 2) with alternating row colors (DelegateChooser)

[Johan Ouwerkerk]

On Tue, Oct 13, 2020 at 11:05 AM chiasa.men  wrote:
>
> Thats the example from 
> https://doc.qt.io/qt-5/qml-qt-labs-qmlmodels-tablemodel.html - Using 
> DelegateChooser with TableModel
>
> I wonder how to enable alternating row colors. Usually in all Quick 2 Table
> codes Ive seen so far the background color is determined by a Rectangle in
> delegate.
>

You have a number of options, but importantly you should be able to
use the model index to select the appropriate colour.

>
> Furthermore: I want to use the TableView in a plasmoid configurtation.
> There the hierarchy lacks of an ApplicationWindow with specific height and
> width. Instead the TableView is wrapped by an Item.
> Is there a way to let the TableView fill the whole configuration window?
> At the moment I have to use:
>Layout.preferredWidth:600
>Layout.preferredHeight:400
> in order to show anything.
>
>   Layout.fillHeight: true
>   Layout.fillWidth: true
> Would not show anything
>

Again, you have a number of options here depending on your case some
of the following might work:

 - Instead of using a layout, use anchors.centerIn: parent, anchors.fill: parent
 - Binding an appropriate height/width and/or specifying an
appropriate implicitHeight/implicitWidth.

I would take a look at how other Plasmoids with a similar layout work
to see what works best for your case.

Regards,

- Johan Ouwerkerk