Add records depth check #621

beaufortfrancois · 2021-09-15T08:51:28Z

This PR aims to solve infinite Web IDL loop introduced by #454. It does so by using any for NDEFRecordInit.data and adding a depth-check step.

FIX #620

Preview | Diff

index.html

kenchris · 2021-09-15T12:17:47Z

Want me to merge? Or feel free to do it yourself

beaufortfrancois · 2021-09-15T12:18:31Z

I'll wait for others to chime in before doing so. Thank you!

zolkis · 2021-09-15T12:58:48Z

So the idea is to enforce a depth level hardcoded to 2 when creating NDEF messages from a source.

There is no depth restriction on reads, right?

Coming from there, I was pondering whether is it worth to expose the max depth to developers (up to a hardcoded ceiling bigger than 2), as a depth of 2 seems a good Gaussian value, but there might be use cases for more. I guess if that is the case, we'd get issues and could extend the API later. I am fine with 2.

If all this is intended, LGTM.

reillyeon · 2021-09-15T18:38:54Z

I think it's reasonable to allow a much deeper recursion depth (e.g. 32) on writes. On reads we don't need to worry because the depth is effectively limited by the length of the data received from the device.

reillyeon · 2021-09-15T18:42:56Z

index.html

+                  initiating the function call, these will in practice be
+                  finite, so we work around this by using `any` as the


There are tricky ways that a developer can craft an object that changes as the algorithm processes it. What I would say here instead is that for practical purposes there is only so much room for storing an NDEF message and so we can apply a limit on the depth of nested messages which developers are unlikely to ever hit.

reillyeon · 2021-09-15T18:52:43Z

index.html

-        To <dfn>map empty record to NDEF</dfn> given a |record:NDEFRecordInit|
-        |ndef| and |context:string|, run these steps:
+        To <dfn>map empty record to NDEF</dfn> given |record:NDEFRecordInit|,
+        |ndef|, |context:string|, and |recordsDepth:unsigned short|,


Can we skip passing the depth to algorithms like this which don't use it?

I've done this for recordsDepth and context.

reillyeon · 2021-09-15T18:54:40Z

index.html

            <ol>
              <li>
                Set the |ndef|'s <a>PAYLOAD field</a> to the result of running
                the <a>create NDEF message</a> given |record|'s <a>data</a>


data here is any while the "create NDEF message" record expects NDEFMessageSource. It feels like we need to acknowledge this but maybe not because those steps do try to match on the parameter type and have a default case which will throw a TypeError.

I believe it's okay to leave it as it. As you said, an unmatched type will throw an error in the "create NDEF message" algorithm

beaufortfrancois

I've changed limit to 32.

beaufortfrancois · 2021-09-16T08:04:48Z

index.html

            <ol>
              <li>
                Set the |ndef|'s <a>PAYLOAD field</a> to the result of running
                the <a>create NDEF message</a> given |record|'s <a>data</a>


I believe it's okay to leave it as it. As you said, an unmatched type will throw an error in the "create NDEF message" algorithm

beaufortfrancois · 2021-09-16T08:05:10Z

index.html

-        To <dfn>map empty record to NDEF</dfn> given a |record:NDEFRecordInit|
-        |ndef| and |context:string|, run these steps:
+        To <dfn>map empty record to NDEF</dfn> given |record:NDEFRecordInit|,
+        |ndef|, |context:string|, and |recordsDepth:unsigned short|,


I've done this for recordsDepth and context.

beaufortfrancois · 2021-09-16T08:05:18Z

index.html

+                  initiating the function call, these will in practice be
+                  finite, so we work around this by using `any` as the


reillyeon · 2021-09-16T19:12:07Z

index.html

+              <li>
+                If |recordsDepth| > `32`, [= exception/throw =] a {{TypeError}}
+                and abort these steps.
+                <p class="issue" data-number="620">


Should we be using class="issue" here? Merging this change will resolve the issue so this should probably be a regular note, with reference to the issue that caused the change.

Implement w3c/web-nfc#621, which adds a hard-coded maximum of 32 NDEFMessage objects that can be in the same chain. w3c/web-nfc#454 (and https://chromium-review.googlesource.com/c/chromium/src/+/1941083 on the implementation side) ended up creating a cycle between NDEFRecordInit.data and NDEFMessageInit, as the former can be an NDEFMessage, which could have one or more entries pointing to the same NDEFRecordInit. Recursion in Web IDL dictionaries are disallowed, so this change also fixes some invalid IDL that was present in the spec and our IDL file. This CL attempts to optimize or modify other parts of the code as little as possible, but the the change ended up being a bit big mainly due to two things: - Since NDEFRecordInit.data's type is now `any`, we need to do more type conversions ourselves in NDEFRecord that we used to get for free when using IDL unions. This means attempting to convert a V8 value into one or more C++ types and accounting for conversion failures. - In order to do the above, we need access to v8::Isolate, so several functions in NDEFRecord that used to take an ExecutionContext needed to be changed to take a ScriptState instead. The usage of ScriptState and the need to perform multiple type conversions also caused NDEFReadingEvent's constructor to start passing one to NDEFMessage, which at the end causes the NDEFRecords that may get created to contain a proper `lang` attribute rather than null. This is a user-visible change, but I could not find anything in the spec supporting the previous behavior. Bug: 1242274 Change-Id: Ia4de230ea45f63f903760865bf85594f79da9eb7

Implement w3c/web-nfc#621, which adds a hard-coded maximum of 32 NDEFMessage objects that can be in the same chain. w3c/web-nfc#454 (and https://chromium-review.googlesource.com/c/chromium/src/+/1941083 on the implementation side) ended up creating a cycle between NDEFRecordInit.data and NDEFMessageInit, as the former can be an NDEFMessage, which could have one or more entries pointing to the same NDEFRecordInit. Recursion in Web IDL dictionaries are disallowed, so this change also fixes some invalid IDL that was present in the spec and our IDL file. This CL attempts to optimize or modify other parts of the code as little as possible, but the the change ended up being a bit big mainly due to two things: - Since NDEFRecordInit.data's type is now `any`, we need to do more type conversions ourselves in NDEFRecord that we used to get for free when using IDL unions. This means attempting to convert a V8 value into one or more C++ types and accounting for conversion failures. - In order to do the above, we need access to v8::Isolate, so several functions in NDEFRecord that used to take an ExecutionContext needed to be changed to take a ScriptState instead. The usage of ScriptState and the need to perform multiple type conversions also caused NDEFReadingEvent's constructor to start passing one to NDEFMessage, which at the end causes the NDEFRecords that may get created to contain a proper `lang` attribute rather than null. This is a user-visible change, but I could not find anything in the spec supporting the previous behavior. Bug: 1242274 Change-Id: Ia4de230ea45f63f903760865bf85594f79da9eb7 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3169656 Reviewed-by: Yuki Shiino <[email protected]> Reviewed-by: François Beaufort <[email protected]> Reviewed-by: Reilly Grant <[email protected]> Commit-Queue: Raphael Kubo da Costa <[email protected]> Cr-Commit-Position: refs/heads/main@{#925263}

…at can be nested., a=testonly Automatic update from web-platform-tests nfc: Limit amount NDEFMessage objects that can be nested. Implement w3c/web-nfc#621, which adds a hard-coded maximum of 32 NDEFMessage objects that can be in the same chain. w3c/web-nfc#454 (and https://chromium-review.googlesource.com/c/chromium/src/+/1941083 on the implementation side) ended up creating a cycle between NDEFRecordInit.data and NDEFMessageInit, as the former can be an NDEFMessage, which could have one or more entries pointing to the same NDEFRecordInit. Recursion in Web IDL dictionaries are disallowed, so this change also fixes some invalid IDL that was present in the spec and our IDL file. This CL attempts to optimize or modify other parts of the code as little as possible, but the the change ended up being a bit big mainly due to two things: - Since NDEFRecordInit.data's type is now `any`, we need to do more type conversions ourselves in NDEFRecord that we used to get for free when using IDL unions. This means attempting to convert a V8 value into one or more C++ types and accounting for conversion failures. - In order to do the above, we need access to v8::Isolate, so several functions in NDEFRecord that used to take an ExecutionContext needed to be changed to take a ScriptState instead. The usage of ScriptState and the need to perform multiple type conversions also caused NDEFReadingEvent's constructor to start passing one to NDEFMessage, which at the end causes the NDEFRecords that may get created to contain a proper `lang` attribute rather than null. This is a user-visible change, but I could not find anything in the spec supporting the previous behavior. Bug: 1242274 Change-Id: Ia4de230ea45f63f903760865bf85594f79da9eb7 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3169656 Reviewed-by: Yuki Shiino <[email protected]> Reviewed-by: François Beaufort <[email protected]> Reviewed-by: Reilly Grant <[email protected]> Commit-Queue: Raphael Kubo da Costa <[email protected]> Cr-Commit-Position: refs/heads/main@{#925263} -- wpt-commits: d02695a83d483670b3cef6f2c6e492f698212700 wpt-pr: 30896

Implement w3c/web-nfc#621, which adds a hard-coded maximum of 32 NDEFMessage objects that can be in the same chain. w3c/web-nfc#454 (and https://chromium-review.googlesource.com/c/chromium/src/+/1941083 on the implementation side) ended up creating a cycle between NDEFRecordInit.data and NDEFMessageInit, as the former can be an NDEFMessage, which could have one or more entries pointing to the same NDEFRecordInit. Recursion in Web IDL dictionaries are disallowed, so this change also fixes some invalid IDL that was present in the spec and our IDL file. This CL attempts to optimize or modify other parts of the code as little as possible, but the the change ended up being a bit big mainly due to two things: - Since NDEFRecordInit.data's type is now `any`, we need to do more type conversions ourselves in NDEFRecord that we used to get for free when using IDL unions. This means attempting to convert a V8 value into one or more C++ types and accounting for conversion failures. - In order to do the above, we need access to v8::Isolate, so several functions in NDEFRecord that used to take an ExecutionContext needed to be changed to take a ScriptState instead. The usage of ScriptState and the need to perform multiple type conversions also caused NDEFReadingEvent's constructor to start passing one to NDEFMessage, which at the end causes the NDEFRecords that may get created to contain a proper `lang` attribute rather than null. This is a user-visible change, but I could not find anything in the spec supporting the previous behavior. Bug: 1242274 Change-Id: Ia4de230ea45f63f903760865bf85594f79da9eb7 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3169656 Reviewed-by: Yuki Shiino <[email protected]> Reviewed-by: François Beaufort <[email protected]> Reviewed-by: Reilly Grant <[email protected]> Commit-Queue: Raphael Kubo da Costa <[email protected]> Cr-Commit-Position: refs/heads/main@{#925263}

…at can be nested., a=testonly Automatic update from web-platform-tests nfc: Limit amount NDEFMessage objects that can be nested. Implement w3c/web-nfc#621, which adds a hard-coded maximum of 32 NDEFMessage objects that can be in the same chain. w3c/web-nfc#454 (and https://chromium-review.googlesource.com/c/chromium/src/+/1941083 on the implementation side) ended up creating a cycle between NDEFRecordInit.data and NDEFMessageInit, as the former can be an NDEFMessage, which could have one or more entries pointing to the same NDEFRecordInit. Recursion in Web IDL dictionaries are disallowed, so this change also fixes some invalid IDL that was present in the spec and our IDL file. This CL attempts to optimize or modify other parts of the code as little as possible, but the the change ended up being a bit big mainly due to two things: - Since NDEFRecordInit.data's type is now `any`, we need to do more type conversions ourselves in NDEFRecord that we used to get for free when using IDL unions. This means attempting to convert a V8 value into one or more C++ types and accounting for conversion failures. - In order to do the above, we need access to v8::Isolate, so several functions in NDEFRecord that used to take an ExecutionContext needed to be changed to take a ScriptState instead. The usage of ScriptState and the need to perform multiple type conversions also caused NDEFReadingEvent's constructor to start passing one to NDEFMessage, which at the end causes the NDEFRecords that may get created to contain a proper `lang` attribute rather than null. This is a user-visible change, but I could not find anything in the spec supporting the previous behavior. Bug: 1242274 Change-Id: Ia4de230ea45f63f903760865bf85594f79da9eb7 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3169656 Reviewed-by: Yuki Shiino <[email protected]> Reviewed-by: François Beaufort <[email protected]> Reviewed-by: Reilly Grant <[email protected]> Commit-Queue: Raphael Kubo da Costa <[email protected]> Cr-Commit-Position: refs/heads/main@{#925263} -- wpt-commits: d02695a83d483670b3cef6f2c6e492f698212700 wpt-pr: 30896

Add records depth check

43833e4

beaufortfrancois mentioned this pull request Sep 15, 2021

Invalid Web IDL loop between NDEFRecordInit and NDEFMessageInit #620

Closed

kenchris reviewed Sep 15, 2021

View reviewed changes

index.html Outdated Show resolved Hide resolved

kenchris reviewed Sep 15, 2021

View reviewed changes

index.html Outdated Show resolved Hide resolved

kenchris reviewed Sep 15, 2021

View reviewed changes

index.html Outdated Show resolved Hide resolved

kenchris approved these changes Sep 15, 2021

View reviewed changes

beaufortfrancois added 2 commits September 15, 2021 13:56

Address feedback

f20b480

Address feedback | part 2

7a65991

reillyeon reviewed Sep 15, 2021

View reviewed changes

Address reilly's feedback

34c77e1

beaufortfrancois commented Sep 16, 2021

View reviewed changes

reillyeon approved these changes Sep 16, 2021

View reviewed changes

s/issue/note

2a78694

beaufortfrancois merged commit f912769 into w3c:gh-pages Sep 17, 2021

beaufortfrancois deleted the 620 branch September 17, 2021 09:50

chromium-wpt-export-bot mentioned this pull request Sep 21, 2021

nfc: Limit amount NDEFMessage objects that can be nested. web-platform-tests/wpt#30896

Merged

		initiating the function call, these will in practice be
		finite, so we work around this by using `any` as the

Add records depth check #621

Add records depth check #621

Uh oh!

Conversation

beaufortfrancois commented Sep 15, 2021 • edited by pr-preview bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

kenchris commented Sep 15, 2021

Uh oh!

beaufortfrancois commented Sep 15, 2021

Uh oh!

zolkis commented Sep 15, 2021

Uh oh!

reillyeon commented Sep 15, 2021

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

beaufortfrancois left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

beaufortfrancois commented Sep 15, 2021 •

edited by pr-preview bot

Loading