On Wed, Jan 29, 2025 at 10:28:52PM +0100, Simon Josefsson wrote:
Rasmus Dahlberg via Sigsum-general sigsum-general@lists.sigsum.org writes:
Thanks for the input -- what do you think should be the pattern when foo.com operates more than one stable Sigsum log?
What reasons are there to operate multiple stable logs?
It's a good question. That's why it's not obvious to me what the context labels should be. Here are a few examples I can think of:
- Scale the setup by factor 2 (one more identical setup). - Operate from a different vantage point (less prone to outages), possibly with other software/architecture for more independence. - The current stable log is growing increasingly large, let's make it read-only and get new entries sequenced into a newly setup log. - Different SLAs for different logs (basically what you're sketching on with rate limits, but could be other things as well like how quickly issues are tended to or who is allowed to add to the logs). - ...
Let's assume one reason is to cater for two different purposes, let's say one is for low-volume software release tracking (~10 entries per month) and one is high-volume CI/CD artifact signing (~10 entries per minute). I'm not sure if that is a realistic use-case. My question above isn't only retorical; I'm curious about log deployment considerations.
Then how about 'sigsum-stable-releases.foo.com', 'sigsum-test-releases.foo.com', 'sigsum-stable-artifacts.foo.com' and 'sigsum-test-artifacts.foo.com'. Or something.
It seems fine to me to use aliases like 'sigsum-stable.glasklar.is. CNAME seasalp.glasklar.is.' for internal network design.
My main point is to name things that make sense for end-users who will consume these instructions, rather than for the sysadmins who sets things up.
It's a good point.
Sorry for hijacking Linus' thread a bit here; I am not certain but I hope we had similar concerns wrt the pet names, but I may have read my own issues into his complaint.
Don't worry, you're on topic!
-Rasmus
/Simon
-Rasmus
On Wed, Jan 29, 2025 at 08:32:33PM +0100, Simon Josefsson wrote:
Rasmus Dahlberg via Sigsum-general sigsum-general@lists.sigsum.org writes:
## Why Pet names without any context requires everybody to memorise a token and connect it to a Sigsum service. While this might be ok for those who work
The alternatives I see without pet names are:
- We talk about "foo's sigsum log"
- We talk about a Sigsum log with <pub key / key hash>
The first option doesn't work well if foo operates >1 log or witness, unless they have their own unique contexts of course. Hence my question above (and further down below) about what context you want to provide.
The second option doesn't work well in conversation, and is the main reason why we have names like jellyfish, seasalp, etc., for our logs.
I find these pet names confusing and believe they look ugly in announcement or end-user instructions.
How about encoding the meaning of a log into the name, rather than picking arbitrary pet names and through READMEs or webpages associate a purpose with them?
If Sigsum as an organization is operating a stable and a test log, how about calling them 'stable.sigsum.org' and 'test.sigsum.org'?
However it look like it is actually Glasklar Teknik who is operating the logs, so in that case, how about 'stable.glasklar.is' and 'test.glasklar.is' respectively?
Or 'stable-log.glasklar.is' and 'test-log.glasklar.is'?
I think there is some point in encoding the operator name in the log rather than the Sigsum project who is publishing the software, so I'm happy there is no official *.sigsum.org log. There is enough overload of terms already. OTOH, if you do plan Sigsum to provide a canonical central preferred log, then using *.sigsum.org seems better than *.glasklar.is which is hard to understand what it has to do with Sigsum for a new user.
You may want to encourage deployments to pick recognizable names, so maybe you instead could use
sigsum-stable.glasklar.is sigsum-test.glasklar.is
and encourage people who deploy logs to use a simiular pattern:
sigsum-stable.foo.com sigsum-test.foo.com
/Simon
with them a lot, I find it a bit presumptuous to ask everyone else to do that. Compare Debian release names.
## How One kind of context that would have particular value for all but the few of us who work with Sigsum daily would be a connection to Sigsum. Prefixing names with "sigsum-" would be one way of doing this.
Another type of context could be provided by including in the name the type of service provided. "log" and "witness", "wit" or "wtn" come to mind. It could be argued that the cleverly chosen families of animals currently used provide such context but I don't think that is helpful.
FWIW I don't view "seasalp" and "jellyfish" as clever sigsum aliases. It might have been better if seasalp had actually had this base URL:
https://sigsum.glasklar.is/seasalp/
But I still think it is helpful that "seasalp" is included. It's a way to refer to a particular Sigsum log that is operated by Glasklar.
Yet another, useful in cases where we know that there is an upcoming incompatible protocol change, would be to include a version number.
Related:
https://git.glasklar.is/sigsum/project/documentation/-/blob/main/archive/202... https://git.glasklar.is/sigsum/project/documentation/-/blob/main/proposals/2...
## Random, minor Non stable services, like current test log "jellyfish", are presumably used by fewer and more involved people and can keep being named like pets.
## Going forward Happy to turn this into a proposal if there's any support for this position.
If you have a suggestion for a context that's helpful I think that would be much better than pet names. But I'm not sure what that context is.
Sigsum-general mailing list -- sigsum-general@lists.sigsum.org To unsubscribe send an email to sigsum-general-leave@lists.sigsum.org
Sigsum-general mailing list -- sigsum-general@lists.sigsum.org To unsubscribe send an email to sigsum-general-leave@lists.sigsum.org
Sigsum-general mailing list -- sigsum-general@lists.sigsum.org To unsubscribe send an email to sigsum-general-leave@lists.sigsum.org