Hi Shawn, thanks again for your feedback and support! Kind regards, R. On Tue, 9 May 2023 at 08:18, Shawn M Emery <shawn.emery@xxxxxxxxx> wrote: > > Hi Roberto, > > Thank you for the updates, they address my review comments. Just one nit: > > OLD: > implementers might prefer validating and processing all the > NEW: > implementers may prefer to validate and process all > > Regards, > > Shawn. > -- > On 5/8/23 9:19 AM, Roberto Polli wrote: > > Dear Shawn, > > > > Thanks for all your feedback. The latest I-D includes your suggestions. > > https://www.ietf.org/archive/id/draft-ietf-httpapi-yaml-mediatypes-06.html > > Further details inline. > > > > On Fri, 14 Apr 2023 at 05:20, Shawn M Emery <shawn.emery@xxxxxxxxx> wrote: > >> <noreply@xxxxxxxx> wrote: > >> > >> The security considerations section refers to section 4.6 of RFC 6838 and > >> possible exploits regarding arbitrary code execution from YAML tags, DoS > >> through infinite or high recursion, and DoS through the partial processing of > >> YAML streams. > >> > >> Ok. If you envision further issues, please let us know. > >> > >> I do agree with each of the mitigations prescribed for the > >> aforementioned exploits, but it does seem counterintuitive to me to validate > >> all the documents in the stream before processing. Does this defeat the > >> purpose of streaming? > >> > >> Before answering, I have to clarify that the term "YAML stream" designates > >> zero or more serialized YAML documents, independently of how they are processed > >> (see https://yaml.org/spec/1.2.2/#streams). > >> This means that a short, serialized YAML document stored in a > >> filesystem is a "YAML stream". > >> This is the reason why Section 4.3 uses the term "incremental", and we > >> never use the term > >> "streaming" in this document. > >> > >> Your question is appropriate. The general idea is that if an > >> implementer is fine in processing > >> each document in a stream independently (e.g. he knows that the > >> documents in the stream > >> are not part of a sort of "transaction", or that broken documents can > >> be referenced in some way and retransmitted later on), > >> there is no need to validate all the stream beforehand. > >> > >> Do you think that the current wording does not convey this concept? Do > >> you have any editorial suggestions? > >> Moreover, if you think that the section can be improved, I'm happy to > >> get your feedback. > >> > >> SME: Ah, yes I think I understand now. Perhaps rewording as follows?: > >> > >> Incremental parsing and processing of a YAML stream can produce partial results and later indicate failure to parse the remainder of the stream; to prevent partial processing, implementers might prefer validating all known interdependent documents in a stream beforehand. > > Here you can find the PR featuring your suggestion with minor edits by > > Eemeli from the YAML team. > > https://github.com/ietf-wg-httpapi/mediatypes/pull/89/files > > > >> Editorial Comments: > >> > >> s/Security considerations: See Section 2.1/Security considerations: See Section > >> 4/ > >> > >> This should be "Same as application/yaml", without references to this document. > >> > >> SME: OK, I can accept the redirect ;) > > The above PR addresses this too. > > > > Thanks for all your support, > > Roberto. > > -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
