profiles: gnome-keyring: harden & add gnome-keyring-daemon

[glitsj16]

We were missing a profile for gnome-keyring-daemon. Let's bring that in.
Also slightly hardened gnome-keyring.profile.

[kmk3]

Rebased to make the changes clearer.

Please make sure to use a normal merge rather than squash to keep the hardening
and refactor commits separate.

[glitsj16]

@kmk3

Please make sure to use a normal merge rather than squash to keep the hardening
and refactor commits separate.

Didn't realize the default I have on GH is still 'squash'. Changing that now!

[kmk3]

@glitsj16 on Feb 8:

Please make sure to use a normal merge rather than squash to keep the hardening
and refactor commits separate.

Didn't realize the default I have on GH is still 'squash'. Changing that now!

It depends, I'd avoid squashing if it looks like the author intended for the
commits to be separate, especially if there are multiple logical changes.

And I'd be inclined to organize the branch and/or squash it when there are
amend/fixup commits.

Also, when there is a single commit/single logical change it seems helpful to
squash to avoid the extra noise of a merge commit.

So it depends on whether the author already intentionally split them and
whether squashing would make the end result more or less clear.

[glitsj16]

Heh, the good old it depends... situation. Thanks again for explaining! I do realize my contributions via GH aren't always 'clean' (understating it). On a side-note I wish to convey my appreciation for the recent landlock work you've been doing. I can start to grasp it all now and am impressed by the speed of it. Interesting times ahead! Have fun.

[kmk3]

@glitsj16 on Feb 8:

Heh, the good old it depends... situation. Thanks again for explaining! I
do realize my contributions via GH aren't always 'clean' (understating it).

It's alright, usually the changes are related and localized enough that
squashing is workable.

In the case of profiles, it's mostly when moving code/renaming files that
keeping such a change in its own separate commit makes any other changes much
clearer.

On a side-note I wish to convey my appreciation for the recent landlock work
you've been doing. I can start to grasp it all now and am impressed by the
speed of it. Interesting times ahead! Have fun.

Glad to hear it! I'm not sure how recent you mean, but the refactoring in
#6078 was indeed a bit mind-bending, as there was a lot of cleanup to do, the
changes had different authors and some changes were instructive enough to
warrant ensuring that they had their own commits.

For example, the following commits show how to add a linked list for a new
path-related command and how to process it all at once at a specific time
(instead of applying each command at parse time):

• b94cc75 ("landlock: apply rules in sandbox before app start", 2023-10-26)
• 520508d ("landlock: avoid parsing landlock commands twice", 2023-11-02)

Which is what made it easy to make the application of all landlock commands
conditional in #6125 (in sandbox.c):

• 760f50f ("landlock: move commands into profile and add landlock.enforce",
  2023-11-17)

In #6200 I was just lucky that my first guess was correct :)