Contributing Workflow about apparmor-profiles

[mk-fg]

Probably not.
If there's a bug, would be happy to merge a patch, but don't see much point in adding profiles or permissions for e.g. stuff that I don't use myself, as it's a kind of "customized dotfiles" repo, not something that's intended to cover everyone's apps and use-cases.

[mk-fg]

It might be a good thing to have some apparmor central indeed, but don't think I can be the one maintaining it, as I only use apparmor on a relatively few complex or potentially vulnerable apps, not for everything in the system, and I don't really have time or desire to test things I don't use, probably also on different systems and layouts... it actually sounds like a lot of work, which probably should be done by someone more security-savvy and inclined to work on it in some way too.

Another thing is that I use this repo in an ad-hoc "works for me" fashion - some features I don't use can be blocked (and I want them to stay that way for my usage) and such, paths are restricted to the way I use them, etc, so it's more of a personal "my configuration" repo, which makes more sense as an examples, basis or reference for actual stuff useful for other people.

Hopefully this gives a clearer picture of why this repo is really bad match for anything that extensive, and why I don't want to make it into anything more useful for anyone but me and not really inclined to start a separate "unified apparmor units repo" either.

Will probably add something like this description to the readme, if it's not there yet, to avoid confusion.

[mk-fg]

Updated readme to clarify this point.
Thanks for bringing it up and sorry for the thing being quite unsuitable for that purpose.

[mk-fg]

And I'm actually confused why I had the word "generic" in the description, as these never could've been such, this is clearly a bug.

[bbhtt]

@mk-fg Do you accept profile PRs for this repo?