On Wed, 28 Apr 2021 at 18:46, Georg Lukas <ge...@op-co.de> wrote: > Therefore, and after some discussions on the xsf@ MUC, I have prepared a > new XEP element `<cve/>` that allows the XEP author to add a visually > distinctive reference to previous failures of implementing that XEP > properly. The goals of this new element are: > > - provide a clear warning to developers when reading a XEP > > - have a standardized syntax for CVEs that we can later use for > additional benefits > > While the `<cve/>` element can be placed within any section of the XEP > text, later on it becomes much easier to find CVE references, and to add > them e.g. to the XEP header or to some place on our web site. > > I think this is a good idea, and worth doing.
Documenting protocols is what we do, documenting security considerations is an important part of that, and documenting CVEs seems an effective way to do the latter. The rest of this email is largely bike shedding. > This will be rendered as shown here: > https://op-co.de/tmp/xep-0280.html#security > > Questions for bike shedding: > > - Should there be a title and a distinct text block to provide a summary > (who should write that summary then?) > > A title, yes. Generic text block is fine. All by convention, as a subsection of the Security Considerations. In general, I'd say we want: <section1 title="Security Considerations"> <p>...</p> <section2 title='Common Vulnerabilities and Exposures'> <p>The following CVEs might be related to this specification. Following the guidance within this specification is expected to ensure application safety.</p> <cves .../> </section2> </section1> I think many developers will hit the CVEs straight from the contents, so let's make it easy for them. > - Do we need an anchor so that we can link to a CVE reference? > > If we have a section for all CVEs consistently, I'm not sure we need an anchor, but hey, we might as well. > - Should there be more visual cues (a big red warning sign? blink? > marquee?) > > No, if we're rolling them into this section, the visual cue as-is is absolutely fine. > - Will that work across all of our output formats? I only tested HTML. Don't know. :-) Dave.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
