Warning: Boring naming scheme discussion ahead. And as if that wasn't enough I'm going to propose that we become more boring, not less.
## What I would like for us to move away from "pet names" for stable Sigsum services, including log instances. Or if we decide to keep them, choose them in a way that provides some context.
## 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 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.
Yet another, useful in cases where we know that there is an upcoming incompatible protocol change, would be to include a version number.
## 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.
Hi Linus,
Thanks for typing up your thoughts -- comments inline!
-Rasmus
On Wed, Jan 29, 2025 at 05:07:45PM +0100, Sigsum General wrote:
Warning: Boring naming scheme discussion ahead. And as if that wasn't enough I'm going to propose that we become more boring, not less.
## What I would like for us to move away from "pet names" for stable Sigsum services, including log instances. Or if we decide to keep them, choose them in a way that provides some context.
What context do you want to provide?
## 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.
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
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
Thanks for the input -- what do you think should be the pattern when foo.com operates more than one stable Sigsum log?
-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
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?
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.
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.
/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
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
Rasmus Dahlberg rgdd@glasklarteknik.se wrote Wed, 29 Jan 2025 19:35:59 +0100:
## What I would like for us to move away from "pet names" for stable Sigsum services, including log instances. Or if we decide to keep them, choose them in a way that provides some context.
What context do you want to provide?
As much as seem practically possible. Three ideas were outlined in the "why" section ("sigsum", type of service, protocol version). A fourth would be one that indicates when in time the service was deployed.
## 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 should perhaps have clarified that when I say "pet names" I mean names which have no meaning themselves. By that definition a name like "sigsum/log/stable/2024/seasalp" would *not* be a pet name even if it contains one.
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.
Thinking of the name as a combination of a base URL and a pet name adds context, and maybe that is enough for logs. As for witnesses, they do have a URL but in the case of a witness using a bastion host, not one that gives any context.
This discussion might need more well defined terminology, especially what we mean when we say "name". I will make an attempt at that below.
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...
I still think it makes sense to not *require* that a version string is included in the address of a service. That doesn't mean that for certain deployments it can be useful to include a version string in the *name* of a service. But again, what is a name?
## 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.
Maybe context is not a good word for describing what I think is needed.
I think that Sigsum services need at least the following attributes, each of them unique to an instance: - an identity, typically a hash of a signing key - an internet address, typically a URL - a name useful for humans
The identity and address are used by machines, while the name is used by humans.
In order to be unique among all Sigsum services a name should probably contain - name of operator ("Glasklar", "Debian") - service type ("log", "witness") - uniqueifier ("stable", "seasalp", "001")
If we want to be unique outside of the scope of Sigsum, we would need to include that somewhere. Could be part of service type, so "log" would become "sigsum log".
On Thu, Jan 30, 2025 at 09:25:39AM +0100, Linus Nordberg wrote:
Rasmus Dahlberg rgdd@glasklarteknik.se wrote Wed, 29 Jan 2025 19:35:59 +0100:
## What I would like for us to move away from "pet names" for stable Sigsum services, including log instances. Or if we decide to keep them, choose them in a way that provides some context.
What context do you want to provide?
As much as seem practically possible. Three ideas were outlined in the "why" section ("sigsum", type of service, protocol version). A fourth would be one that indicates when in time the service was deployed.
## 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 should perhaps have clarified that when I say "pet names" I mean names which have no meaning themselves. By that definition a name like "sigsum/log/stable/2024/seasalp" would *not* be a pet name even if it contains one.
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.
Thinking of the name as a combination of a base URL and a pet name adds context, and maybe that is enough for logs. As for witnesses, they do have a URL but in the case of a witness using a bastion host, not one that gives any context.
Rallying around signed-note, a witness does have a name:
And it's recommended it is a schema-less URL (need not be reachable). So I would expect that a foo witness has a name that contains "foo.tld", possibly with other context before and/or after.
When you're thinking about naming and context. Also think about where these names will appear. The most obvious place is in trust policies; and the second most obvious place I can think of is where the self-selected name is discovered from the operator (e.g., about page).
This discussion might need more well defined terminology, especially what we mean when we say "name". I will make an attempt at that below.
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...
I still think it makes sense to not *require* that a version string is included in the address of a service. That doesn't mean that for certain deployments it can be useful to include a version string in the *name*
Agreed.
of a service. But again, what is a name?
## 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.
Maybe context is not a good word for describing what I think is needed.
I think that Sigsum services need at least the following attributes, each of them unique to an instance:
- an identity, typically a hash of a signing key
- an internet address, typically a URL
- a name useful for humans
The identity and address are used by machines, while the name is used by humans.
In order to be unique among all Sigsum services a name should probably contain
- name of operator ("Glasklar", "Debian")
- service type ("log", "witness")
- uniqueifier ("stable", "seasalp", "001")
Sounds reasonable. I'd prefer if the uniqueifier is easy for humans.
-Rasmus
If we want to be unique outside of the scope of Sigsum, we would need to include that somewhere. Could be part of service type, so "log" would become "sigsum log".
Linus Nordberg via Sigsum-general sigsum-general@lists.sigsum.org writes:
I think that Sigsum services need at least the following attributes, each of them unique to an instance:
- an identity, typically a hash of a signing key
- an internet address, typically a URL
- a name useful for humans
Would it make sense to encourage a naming scheme that include the key?
I'm thinking a Sigsum policy file like this:
log https://stable-2024-seasalp-0ec7e16843119b120377a73913ac6acbc2d03d82432e2c36... witness https://witness-stable-2024-stockholm-28c92a5a3a054d317c86fc2eeb6a7ab2054d62...
Use base32 to compress the key part if size is a factor.
/Simon
On Thu, Jan 30, 2025 at 10:22:51AM +0100, Simon Josefsson wrote:
Linus Nordberg via Sigsum-general sigsum-general@lists.sigsum.org writes:
I think that Sigsum services need at least the following attributes, each of them unique to an instance:
- an identity, typically a hash of a signing key
- an internet address, typically a URL
- a name useful for humans
Would it make sense to encourage a naming scheme that include the key?
I'm thinking a Sigsum policy file like this:
log https://stable-2024-seasalp-0ec7e16843119b120377a73913ac6acbc2d03d82432e2c36... witness https://witness-stable-2024-stockholm-28c92a5a3a054d317c86fc2eeb6a7ab2054d62...
Use base32 to compress the key part if size is a factor.
It makes sense, yes. What you're describing is pretty much a "vkey":
witness.example.org/fooname+33f20420+AR...qC
Which most notably includes a name and the key in base64.
https://git.glasklar.is/sigsum/project/documentation/-/blob/main/proposals/2...
There's some momentum on using this format for, e.g., witness keys; and I suspect that our trust policy format will eventually use it instead of
witness <NAME> <HEX-KEY>
lines for specifying witnesses. So basically:
witness witness.example.org/fooname+33f20420+AR...qC
This is by the way my bias towards not specifying "witness" in the name, because I think it is mostly evident from the context where it's used.
That said, I'd be +1 for overly clear names since I don't have a good argument for why the context will always be "clear from the context".
-Rasmus
/Simon
Linus Nordberg via Sigsum-general sigsum-general@lists.sigsum.org writes:
## 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.
We have some context in the name for stuff operated under sigsum.org, but lost it when we (for good reasons, I think) placed seasalp under glasklar.is.
I'd be ok with boring names like sigsum-log-X.glasklar.is.
On operating multiple logs, what are CT operators doing, since they typically operate several logs in parallel?
## Going forward Happy to turn this into a proposal if there's any support for this position.
I think it would be useful with a recommended naming scheme, also for others.
Regarsd, /Niels
On Thu, Jan 30, 2025 at 07:37:44AM +0100, Sigsum General wrote:
Linus Nordberg via Sigsum-general sigsum-general@lists.sigsum.org writes:
## 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.
We have some context in the name for stuff operated under sigsum.org, but lost it when we (for good reasons, I think) placed seasalp under glasklar.is.
I'd be ok with boring names like sigsum-log-X.glasklar.is.
On operating multiple logs, what are CT operators doing, since they typically operate several logs in parallel?
They typically have pet names, and also some context. E.g., Google's logs have a location; and most of them have a shard context in the URL.
https://www.gstatic.com/ct/log_list/v3/log_list.json
I never talked to anyone about if they like the pet names or not, but I find them helpful. But that might not mean much since I'm not a normal user in some regards. I do remember finding it difficult when having to conversate about foo's "petname" and "petname-2" simultaneously.
-Rasmus
## Going forward Happy to turn this into a proposal if there's any support for this position.
I think it would be useful with a recommended naming scheme, also for others.
Regarsd, /Niels _______________________________________________ Sigsum-general mailing list -- sigsum-general@lists.sigsum.org To unsubscribe send an email to sigsum-general-leave@lists.sigsum.org
sigsum-general@lists.sigsum.org
-
Linus Nordberg -
Niels Möller -
Rasmus Dahlberg -
Simon Josefsson