`Depends:` vs `Recommends:` vs none

[adrelanos]

• libpam-tmpdir
  • Depend on libpam-tmpdir for very solid extra security #147
• usbguard
  • USB Guard | Depend on it and configure rules #166

Do we really need Depends:? This makes it difficult to remove the package for users.

Perhaps Recommends: is sufficient? Not ideal.

Or nothing.

Why? Because security-misc shouldn't be attempting to be a Linux distribution such as Kicksecure that installs by a number of pre-installed applications.

references:

• https://github.com/Kicksecure/kicksecure-meta-packages
• https://github.com/Kicksecure/kicksecure-meta-packages/debian/control

[monsieuremre]

I am for depends.

Recommends is too weak and we configure the config files. Security-misc does not try to be a distribution in my opinion. If it becomes a vital component of kicksecure, that is still ok. I see no problem. I also think these packages are relatively minimalistic.

[adrelanos]

Depends in security-misc would result in usbguard being installed by default in Kicksecure for VirtualBox VM images and these don't come with USB enabled by default so that would be a superfluous package. Everybody without USB couldn't remove this package without getting trouble with security-misc.

The usbguard config suggestion seems suitable here but the depends can go to kicksecure-meta-packages.

Maybe in

• kicksecure-recommended-cli (libpam-tmpdir, usbguard) or
• non-qubes-vm-enhancements-cli (usbguard)

not sure yet.

[adrelanos]

Depends: would be inappropriate as per Debian policy.

Packaging is done with Debian policy compliance in mind. Packages by Kicksecure, Whonix are already lintian --pedantic clean as much as feasible.

[monsieuremre]

At least recommend them. I don't support moving them to another package. Everything that is security-misc should be handled here. This provides platform indepence. It shoud be kept possible to install this on debian and have a hardened system.

[adrelanos]

I exactly don't want to replicate Kicksecure in security-misc. There's a structure.

If starting to add security enhancing recommended packages which then would become candidates for Recommends:.

• LKRG
• tirdad
• amd64-microcode / intel-microcode
• swap-file-creator (encrypted swap file)
• ... others, see kicksecure-meta-packages debian/control

This is just security-misc. Part of the Kicksecure project. Other major, complex code bases (examples like LKRG, tirdad) will stay in their own code repositories. This is to avoid code duplication.

As for platform independence, security-misc currently depends on apparmor-profile-dist, a package by Kicksecure, which isn't a great dependency and maybe avoidable.

Maybe the whole apparmor-profile-dist could be avoided. (roddhjav/apparmor.d#251)

Even genmkfile is no longer a build dependency.

security-misc also depends on helper-scripts, another package by Kicksecure. If a Debian (or other distribution) maintainer wanted to add security-misc to their distribution then both packages would need to be uploaded. If there is an actual distribution maintainer interested in this, and this being a major obstacle then maybe this dependency could also be avoided.

Uploading to Debian or a Debian derivative might be relatively simple in theory because the Debian packaging files already exist, are used and tested for years in Kicksecure, Whonix and maybe only minor changes required to adhere with Debian policy. To be found upon the review of an actual distribution maintainer.

An acceptable Recommends: could be kicksecure-dependencies-cli and/or kicksecure-recommended-cli.

The scope is somewhat hard to define for security-misc. Ideally, security-misc which tends to get a bit messy, wouldn't need to exist.

Settings such as https://github.com/Kicksecure/security-misc/blob/master/etc/default/grub.d/40_distrust_cpu.cfg would ideally be the upstream default but as long as they're not, it's not feasible to have a dedicated package for all of these small security tweaks. (Debian FTP masters won't accept lots of single file content packages. So that's not a good packaging style.)

If any scope defining / restricting readme edits are suggested, happy to have a look at a PR.

[monsieuremre]

As for platform independence, security-misc currently depends on apparmor-profile-dist, a package by Kicksecure, which isn't a great dependency and maybe avoidable.

Yes. This please. Whenever I build it in a debian vm, I also have to enable the kicksecure repos because it wants to install those packages too.

I think depending on libpam-tmpdir or usbguard is way more acceptable tho. I think it is better in fact. Because they are standard debian packages that should be in theory available in any debian system and derivatives.

[adrelanos]

As for platform independence, security-misc currently depends on apparmor-profile-dist, a package by Kicksecure, which isn't a great dependency and maybe avoidable.

Yes. This please. Whenever I build it in a debian vm, I also have to enable the kicksecure repos because it wants to install those packages too.

That is roddhjav/apparmor.d#251 and also suitable for contributions to speed this task up. (Merging apparmor-profile-dist stuff elsewhere so that package can be deprecated.)

[adrelanos]

https://github.com/Kicksecure/security-misc#project-scope-of-application-specific-hardening