Rasmus Dahlberg via Sigsum-general sigsum-general@lists.sigsum.org writes:
On Wed, Jan 08, 2025 at 02:33:28PM +0100, Simon Josefsson wrote:
Rasmus Dahlberg via Sigsum-general sigsum-general@lists.sigsum.org writes:
What you have in the current template looks as good as it gets right now!
Thank you!
Avoiding the ugly Unix-specific 'cat<<EOF>' garbage was the primary thing I was thinking about. Maybe the public key can be taken on the command line as strings?
That's a question for nisse -- can you file an issue and tag him?
I opened this one:
https://git.glasklar.is/sigsum/core/sigsum-go/-/issues/90
Please don't hard wire magic crypto values into the binary, it smells of TPM's.
The argument for having the option of using a builtin default-policy is that a user *somehow* got sigsum-verify installed and must trust the tool. By embedding a default policy, a separate trusted channel for getting it installed is avoided (so there are fewer moving parts).
It's still in the idea phase though, so if you have more arguments for why it's a terrible idea now is a great time to elaborate on them!
My argument would be to draw an analogy with hard-coding the content of the /etc/ssl ca-certificates into binaries. Or hard-coding the public keys of the DNSSEC root trust anchors.
I believe you can still provide a builtin default-policy, if you want to, by including a default trust policy together with sigsum-verify, and have the installation process put that in the right place so the tool finds it automatically.
Yes, I believe you still can make a reasonable argument why hard-coding things in the binary is better, but I think for the majority of distribution-like use-cases it is better not to do this. It is a trade-off of different requirements.
/Simon