gyptazy

@gyptazy@gyptazy.ch

Believer in the power of open-source & community-driven innovation.

Former AS20621 NetOp that loves FreeBSD & illumos. Currently mostly in DevOps & developing (Python, Rust). Contributes to & . Evaluating and production usage of hardware/software.

Projects:
* BoxyBSD.com - A free VM hosting service to provide some value back to the community.
* manpageblog.org - A static blog generator in manpage design.
* QualvoSec - A security patch management tool.
Bloghttps://gyptazy.ch
GitHubhttps://github.com/gyptazy
Xhttps://twitter.com/gyptazy
0 ★ 0 ↺
in reply to »

gyptazy »
@gyptazy@gyptazy.ch

Thanks! Within my last internal tech-talk in our company this was also a question and I honestly do not have a real answer for this right now. Also in the talk we couldn't find a real outcome, so I'm happy to hear more feedback and input.

QualvoSec is supposed to be very minimalistic and only to keep the systems up to date on the latest patches given in a used repository. In theory, you could already do this with the whitelist mechanism and defining the package version (https://github.com/gyptazy/QualvoSec/blob/main/src/server/patch.yaml#L20-L21), but in that case you need a utility to include all the packages (sure, you could do this by hand but you probably don't want to do this).

1. This leads us to the first solution. It could be done by the admin tool and generate the patch manifest. Current packages can be requested from the client if the http server is activated (optional, up to everyone to use it).
2. A solution could also lead into freezing the repositories itself but only works when having own repositories (e.g. with aptly, repomgr, etc.). This is independent of QualvoSec.
3. Don't integrate similar solutions

I can clearly see the reasons and needs for patch freezing (especially when having the typical ends for dev, stage and prod). I'm happy to hear more feedback and I will have a look into such an implementation. Thanks!

History