keyring-style dart installation rather than holding keys

[desmonddak]

Description & Motivation

The key we have is old and a solution is to use a keyring approach to install dart.

Related Issue(s)

#666

Testing

I tested as part of PR #652 but cherry-picking this change for review and will be needed for all PRs to pass CI.

Backwards-compatibility

Is this a breaking change that will not be backwards-compatible? If yes, how so?

No

Documentation

Does the change require any updates to documentation? If so, where? Are they included?

None needed. This is an infrastructure scripting change.

[Copilot]

Pull request overview

Updates the GitHub Codespaces Dart installation flow to use a keyring-based apt repository setup (avoiding the previously checked-in public key), resolving CI/codespaces failures due to the old key mechanism (Issue #666). Also includes a small cleanup in a tutorial answer.

Changes:

• Switch tool/gh_codespaces/install_dart.sh to fetch and install the Google Linux signing key into /usr/share/keyrings and configure the Dart apt repo using signed-by.
• Remove the previously vendored tool/gh_codespaces/pubkeys/dart.pub key file.
• Remove an incorrect @override annotation on a constructor in a tutorial answer file.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
tool/gh_codespaces/pubkeys/dart.pub	Removes the vendored Dart/Google public key from the repo.
tool/gh_codespaces/install_dart.sh	Installs Dart via apt using a keyring-based repo configuration.
doc/tutorials/chapter_6/answers/exercise_2_n_bit_subtractor.dart	Removes an incorrect @override annotation on the constructor.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[mkorbel1]

In #256 it was indicated that Dart team recommended saving the key locally. From some quick search it seems like this can help mitigate man-in-the-middle attacks and reduce reliance on more servers as part of CI. Practically speaking, the occasional work this causes seems maybe to outweigh the risks here. I.e. I'm inclined to accept this solution. Thoughts?

[desmonddak]

Respecting #256, I put back the local key cache with fallback to wget upon failure when the key is stale with a loud warning in the logs. That way, we do not have a failing CI when the key changes.