On Tue, Jan 07, 2025 at 03:37:31PM +0100, Sigsum General wrote:
Simon Josefsson simon@josefsson.org writes:
- Suggest a filename extension
It seems some people use *.proof although *.sigsum-proof may be more advertizy. Or just *.sigsum?
Naming is somewhat hard... On one hand, I like the very explicit .sigsum-proof, but it would also be nice with something shorter.
Maybe canonical name *.sigsum-proof and a short form like *.ssp (SigSum Proof), *.prf (sigsum PRooF), *.spf (Sigsum ProoF), *.sps (Sigsum Proof Signature), *.sis (SIgsum Signature), *.ssi (Sigsum SIgnature), ...?
Of the three-letter extension, I like .prf, which seems easy to read out like "proof". Might cause some confusion with PReFerences files or PRoFile files, but I guess that's inevitable with a three letter acronym.
I also think .ssi is good -- easy to say with three syllables S-S-I.
I think a three character extension would be nice.
Do you think it still matters? I'm thinking of usecases like transferring files on a USB device with a FAT file system, would you get less problems with "foo-1.1.tar.gz.prf" than with "foo-1.1.tar.gz.proof"? Or are there other usecases where it could matter?
We might also want to think about if we want to stress "proof" as "proof of Sigsum logging", or if we want to frame it as a kind of extended aka "spicy" signature.
I think stressing ".sigsum" is nice from this perspective, i.e., it's a SIGned checkSUM that happens to be transparent thanks to sigsum.
-Rasmus
I realize now that the sigsum-submit --help is already fairly clear:
I think the current (and documented) behavior makes sense. But we could discuss if .proof is the best extension.
- Add a ABNF grammar describing the format.
What concrete utility do you see? If we adopt ABNF, we should consider adding that also to https://git.glasklar.is/sigsum/project/documentation/-/blob/main/log.md.
My primary utility of doing that is to lock down the format so we won't have ten slightly different variants of it. And alignment with the MIME/IETF registration process.
I don't object to that. And I hope it should be fairly easy to get the ABNF right, since the format is rather simple.
https://datatracker.ietf.org/doc/html/rfc2046#section-4.1.1 says
The canonical form of any MIME "text" subtype MUST always represent a line break as a CRLF sequence.
Apparently this doesn't prevent using text/plain on LF-delimited files, and that seems better than using application/sigsum-proof for what is essentially text anyway.
If that appears acceptable, then I'd be happy with "text/sigsum-proof" (ascii-only, but no explicit charset parameter), and mandated LF line endings, even though that violates RFC 2046 as you quote above.
An Informational RFC would be nice, although strictly not required. Instead you could prepare a *.md file specifying things and then fill out this form:
We discussed this briefly at today's Sigsum weekly. I think the next step is to move the spec to https://git.glasklar.is/sigsum/project/documentation, next to log.md, and apply another round of polish.
Okay - having versioning in the format specification is fine, it could simply say that anything except 'version=2' is undefined behaviour.
And I take it it would be acceptable, at a later time, to update the reference for the MIME type to assign meaning to contents that don't start with the literal line "version=2" ?
I believe most formats specify one MIME type once and then do version rolling inside the format specifications. Introducing new MIME types for each new format version is more fragile, and usually doesn't give any advantages.
Agree a new MIME type seems excessive. I was thinking of something like "image/jpeg; coding=arithmetic" expressing that support for arithmetic coding ("not yet widely implemented" according to the cjpeg man page) is required to be able to process the contents. Or in an Accept: header, it would advertise that you do have that ability. But I'm not aware of anything like that used in practice.
Regards, /Niels _______________________________________________ Sigsum-general mailing list -- sigsum-general@lists.sigsum.org To unsubscribe send an email to sigsum-general-leave@lists.sigsum.org