Repository navigation
Depends: vs Recommends: vs none #169
Description
Activity
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.
Depends:would be inappropriate as per Debian policy.Packaging is done with Debian policy compliance in mind. Packages by Kicksecure, Whonix are already
lintian --pedanticclean as much as feasible.- added a commit that references this issue
on Nov 20, 2023 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 bekicksecure-dependencies-cliand/orkicksecure-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.
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.)
libpam-tmpdirusbguardDo 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: