Turris OS packages issueshttps://gitlab.nic.cz/turris/os/packages/-/issues2022-01-04T14:57:18+01:00https://gitlab.nic.cz/turris/os/packages/-/issues/577Improve certgen hooks directory manipulation2022-01-04T14:57:18+01:00Vojtech MyslivecImprove certgen hooks directory manipulationFollow-up from https://gitlab.nic.cz/turris/diagnostics/-/merge_requests/6#note_147685
@vmyslivec:
> * Certgen itself is installed on base system due to `mailpass` feature
> * *hooks dir* is created and used by `sentinel-proxy` package
...Follow-up from https://gitlab.nic.cz/turris/diagnostics/-/merge_requests/6#note_147685
@vmyslivec:
> * Certgen itself is installed on base system due to `mailpass` feature
> * *hooks dir* is created and used by `sentinel-proxy` package
> * Hooks dir is possibly optional (you can issue a certificate without a proxy) and Certgen does not have a default value hardcoded
>
> This approach was introduced in turris/turris-os-packages!86
@kkoci:
> I think that is is just too complicated. That hook dir is not essential and default should be hardcodded.
>
> The point of hook directory is that program itself runs those hooks but won't fail if there is no such directory and or if hook fails. Both users and programs should be sure that when program is run that hook dir is used not just in case hooks are specified. This is at least how I see hooks.
>
> This means that:
>
> * hooks dir can be created by `certgen` package by putting file `.keep` in it or it doesn't have to be but then it should not fail if it is missing
> * hooks should always be called from expected location unless option is used to not call hooks (reverse implicit rule against current state)
>
> I know that I was reviewing that code but now when I see it used I see that it is flawed in this case. Hooks should be reliable in some sense and not some adhock thing. I feel like this implementation now has almost no difference over `certgen && for f in /hook/*; $f; done` in sense that user chooses what is executed and if he knows little then it breaks a lot potentially.