chromeos_smart_card_connector icon indicating copy to clipboard operation
chromeos_smart_card_connector copied to clipboard

Published 20 hours ago • verified publisher icon GoogleChromeLabs

Switch Smart Card Connector to Extensions Manifest V3

Open emaxx-google opened this issue 1 year ago • 6 comments

Currently, Smart Card Connector is a Chrome App. A couple of years ago we started the work on migrating it an Extension (https://github.com/GoogleChromeLabs/chromeos_smart_card_connector/projects/3), however originally this was targeting Manifest V2 Extensions.

With the new deprecation timelines (https://developer.chrome.com/docs/extensions/develop/migrate/mv2-deprecation-timeline), we should switch to Extensions Manifest V3 instead.

emaxx-google avatar Feb 06 '24 15:02 emaxx-google

Is it possible that this could this be an issue for us, considering the fact that we use a chrome kiosk app with manifest version 2 and also using smart card connector reader chrome app, or does this only apply for extension of smart card connector?

Test18415 avatar May 08 '24 14:05 Test18415

Is it possible that this could this be an issue for us, considering the fact that we use a chrome kiosk app with manifest version 2 and also using smart card connector reader chrome app, or does this only apply for extension of smart card connector?

The latter is correct, so the timelines aren't pressuring as long as one stays on ChromeOS Apps.

emaxx-google avatar May 08 '24 14:05 emaxx-google

Okay, thank you, that is good news.

Test18415 avatar May 10 '24 07:05 Test18415

Capturing one thought: probably #1152 should be enhanced in a way similar to the code touched in #1155. In other words, when we await on an incoming port, the port should initially freeze incoming messages until it's marked as "ready". Otherwise we risk the following race condition:

  1. receiver: creates PortMessageChannelWaiter, and starts awaiting on it
  2. sender: port = chrome.runtime.connect(...)
  3. receiver: chrome.runtime.onConnect received by PortMessageChannelWaiter, and the Port is created
  4. receiver: the awaited promise starts being resolved
  5. sender: port.postMessage(...)
  6. receiver: the Port receives the message, and discards it because there's been no service registered for incoming messages yet
  7. receiver: the awaited promise gets resolved, and the code registers services, but the message that has been sent is already lost

So the fix would be to move the message handling to happen at a later step ("8") instead of step 6.

emaxx-google avatar May 21 '24 11:05 emaxx-google