Yes that would resolve my DISCUSS Sent using a virtual keyboard on a phone
> On Sep 20, 2022, at 11:48, Russ Housley <[email protected]> wrote: > > Paul: > > I propose adding this information reference: > > [CBORDIAG] Bormann, C., "CBOR diagnostic utilities", > <https://github.com/cabo/cbor-diag>. > > Then, the text at the front of the examples would say: > > This appendix includes a set of examples that show the different > features and message types that have been defined in this document. > To make the examples easier to read, they are presented using the > extended CBOR diagnostic notation (defined in [RFC8610]) rather than > as a binary dump. > > The examples are presented using the CBOR's diagnostic notation. A > Ruby-based tool exists [CBORDIAG] that can convert between the > diagnostic notation and binary. The referenced webpage includes > installation instructions. > > The diagnostic notation can be converted into binary files using the > following command line: > > diag2cbor.rb < inputfile > outputfile > > The examples can be extracted from the XML version of this document > via an XPath expression as all of the sourcecode is tagged with the > attribute type="CBORdiag". (Depending on the XPath evaluator one is > using, it may be necessary to deal with > as an entity.) > > //sourcecode[@type='CDDL']/text() > > Does this resolve your DISCUSS position? > > Russ > > >> On Sep 20, 2022, at 10:58 AM, Russ Housley <[email protected]> wrote: >> >> Carsten: >> >> Do you have a webpage anywhere that can be pointed to by this document? >> >> Russ >> >>> On Sep 8, 2022, at 8:36 PM, Paul Wouters <[email protected]> wrote: >>> >>> I am fine with a pointer to a downloadable source which can also contain >>> the commands to install the software. Upon compromise, the pointer can be >>> updated to protect the immutable RFC text. Wether it points to GitHub or >>> IETF or elsewhere doesn’t matter to me. >>> >>> Paul >>> >>> Sent using a virtual keyboard on a phone >>> >>>>> On Sep 8, 2022, at 16:04, Russ Housley <[email protected]> wrote: >>>>> >>>> >>>> >>>>> On Sep 8, 2022, at 1:47 AM, Carsten Bormann <[email protected]> wrote: >>>>> >>>>>> On 2022-09-08, at 04:14, Paul Wouters via Datatracker <[email protected]> >>>>>> wrote: >>>>>> >>>>>> ---------------------------------------------------------------------- >>>>>> DISCUSS: >>>>>> ---------------------------------------------------------------------- >>>>>> >>>>>> gem install cbor-diag >>>>>> >>>>>> I am concerned about adding install commands for "programs from the >>>>>> internet" >>>>>> within an RFC. If the rubygem for some reason becomes malicious, we >>>>>> cannot >>>>>> pull it from the RFC (even if we pull it from the datatracker link, it >>>>>> would >>>>>> still live on in copies of the RFC elsewhere and malicious people could >>>>>> point >>>>>> to copies of those original RFCs to point people to downlod the >>>>>> malicious rubygem. >>>>>> >>>>>> I would be okay with an iet.org download location of a ruby gem. >>>>> >>>>> “gem install” is the appropriate way to install rubygems software, not a >>>>> “location of a rubygem”. >>>>> >>>>> What you seem to be asking for is some indirection so we can swap out the >>>>> name of the gem in case cbor-diag becomes rogue. That does make some >>>>> sense to me, but we’d need to install that indirection somewhere in a >>>>> place maintained by the IETF. >>>>> >>>>> ➔ “Please consult https://www.ietf.org/software/cbor-diag for the way to >>>>> install this software”. >>>>> And that page would contain instructions including “gem install >>>>> cbor-diag” until that goes rogue. >>>>> >>>>> Can we get such a infrastructure of pages recommending software up and >>>>> running? Do we mire ourselves in process issues (who gets change control >>>>> etc.)? >>>>> >>>>> Data point from a quick search: >>>>> The RFCs that already suggest installing rubygems via a direct “gem >>>>> install” include RFC 8152, RFC 8610, RFC 9052. >>>>> >>>>> (In reality, I’d expect the rubygems organization to act more quickly on >>>>> a report of cbor-diag going rogue than the IETF would.) >>>>> >>>>> Grüße, Carsten >>>> >>>> >>>> Paul: >>>> >>>> Are you satisfied with this explanation? Or, would you prefer the pointer >>>> to https://www.ietf.org/software/cbor-diag >>>> >>>> Russ >>>> >> >
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
