RPM packaging

[adrelanos]

How much work would it require to package this source as an .rpm? I would really like to test this on opensuse. I can also a tool like alien, but a native solution would be better, like if this package supported building as an rpm. Would this be merged if I implement it?

Originally posted by @monsieuremre in #136 (comment)

[adrelanos]

I have no idea about rpm packaging or how well alien works.

However, a contribution to genmkfile implementing rpm support would be awesome. I might even be able to host a rpm repository one day but I'd need a lot support for that one. Namely genmkfile and after that the repository creation tools. But that is optional.

There was an unfinished attempt at rpm:
https://github.com/Kicksecure/security-misc/tree/master/rpm_spec

It's outdated. Might never have been finished.

It's list of files is now certainly outdated. I think listing each file by hand is quickly going to be outdated. Therefore if there is no generic way to implement this (similar to how genmkfile install does it) then then would probably forever always be outdated and have bugs due to missing files.

So patches welcome as long as these are not too massive in scope (unlikely) to review for being security harmful (unlikely).

related:

• Package security-misc from Whonix to Qubes QubesOS/qubes-issues#1885

[adrelanos]

How much work? For somebody who doesn't speak RPM like me... A lot...

[monsieuremre]

Can I suggest Open Build Service from openSUSE (free software, in both meanings). It makes reproducable builds and makes building automation very easy. Turns out many many other projects use this service. Apparently, it can build rpm's and deb's and pretty much anything in between by just defining details in a file. I am not educated in the topic but the superficial research I made suggests Kicksecure can use this and it would make a lot of stuff easy to build/reproduce/automate/sign/anything packaging.

[adrelanos]

RPM: We're not there for needing OBS yet. Because we don't have the prequisite yet. We lack the "packaging". That is to create (and maintain) the RPM specfile. This is the "core", difficult (for non-RPM speaking people), laborious part of this ticket.

DEB: https://forums.whonix.org/t/open-build-service/679

[monsieuremre]

I have concluded that packaging this project directly as rpm is not productive. There are many things that are tied directly to debian and many things that can be handled much more easily on Tumbleweed. If anything, it can be 'ported' into another branch or repository, to work on Tumbleweed, but it isn't possible within reason to have two build targets, in my opinion.

[adrelanos]

RPM isn't only needed for Tumbleweed. Needed for QubesOS/qubes-issues#1885

There's a stalled attempt here:
https://github.com/Kicksecure/security-misc/tree/master/rpm_spec

[monsieuremre]

The two implementations will differ. Qubes is based on some ancient fedora thing. Fedora does not have the good stuff that tumbleweed has, like setting file permissions and other stuff with config files. The daemon is needed in fedora, not needed in tumbleweed. Also the rpm package in either case will differ from this one to a significant enough degree. Fedora uses selinux, tumbleweed and debian use apparmor. Fedora has dnf, debian apt, tumbleweed zypper. An rpm package that will run on federa will also not run on qubes. Qubes is in many ways different. These may seem little differences, but they can't be handled in the same repository, especially when we are not using makefiles and we don't want spec files and stuff.

One can definetely create an rpm package, but it won't be in the same repo, and such a thing has to use makefiles and there has to be different targets for qubes, fedora and tumbleweed.

This really not that maintainable. The only scenario where it would make sense is, if kicksecure somehow magically decides to change its base from debian, IMO.

[adrelanos]

monsieuremre:

The two implementations will differ. Qubes is based on some ancient fedora thing.

Fedora 38 and 39 templates exist for Qubes which would benefit from this.

Fedora does not have the good stuff that tumbleweed has,

Qubes is highly unlikely to port to tumbleweed. Qubes Fedora templates are not going to go away. tumbleweed seems off-topic.

One can definetely create an rpm package, but it won't be in the same repo, and such a thing has to use makefiles and there has to be different targets for qubes, fedora and tumbleweed.

Exponentially more weird, complex packages have been packaged for RPM. security-misc, without any compiled code, being a collection of configuration files and scripts, is one of the simpler ones to package. At the same time, the same upstream software is available as DEB. A ton of software was packaged as both, RPM and DEB, though probably often by different packagers. Makesfiles are mostly useful for compiled code if provided by upstream. If there is nothing to compile and upstream (security-misc) does not provide, need a makefile, then packagers (DEB, RPM) usually do not invent makefiles either just for the packaging.

This really not that maintainable.

Only if contributed. Hopefully the prior attempt will come back to life one day.

[monsieuremre]

By not maintainable, I mean by choice. You want to follow a very specific structure for packaging, which is for easy maintainability, but complying with that while supporting rpm targets also can ironicaly be more difficult to maintain.

For a good example take look at apparmor.d's makefile.

[adrelanos]

The makefile part of that seems actually quite nice and minimal.

dpkg:
	@bash dists/build.sh dpkg
	@sudo dpkg -i ${PKGNAME}_*.deb

rpm:
	@bash dists/build.sh rpm
	@sudo rpm -i ${PKGNAME}-*.rpm

Which runs a shell script, which is nice.

https://github.com/roddhjav/apparmor.d/blob/main/dists/build.sh

And that script also doesn't show much dpkg vs rpm differences, complexity.

That makefile's install target seems to be applied to both, DEB and RPM, which is nice. That's a similar design to what I would like.

[monsieuremre]

This package cannot reasonably be ported to an rpm. I think you can close the issue. It is tied too much to debian. Most importantly it heavily depends on pam-auth-config, has apt hooks, uses dpkg stat-override (which we do not need to use for anything outside of /usr/bin but we still do for some reason) among other things.

The package already tries to be unnecessarily universal as it is now, which limits the amount of real hardening heavily.

I plan on creating a repo soon, that does hardening and produces rpm and deb targets, a universal desktop hardening so to say. But this package can't be that package, that I can say with ease.

[adrelanos]

Taking care of all of this would be part of this issue. The too Debain specific things would need to be moved to separate repositories/packages or ported.