[prismatic7]

Summary

package.json declares "adm-zip": "^0.6.0", so the range already permits 0.6.1. Only
package-lock.json was holding the tree on 0.6.0, which carries seven published advisories.
This changes one line in the lockfile and nothing else.

Advisory	Issue
GHSA-vwc7-r8mq-g2x9	extraction follows destination symlinks → arbitrary file overwrite
GHSA-7q85-xj36-vmfc	uncontrolled memory allocation via declared uncompressed size
GHSA-rcw4-f5rp-g42v	decompression-bomb protection bypassed by declaring uncompressed size as 0
GHSA-j5f4-cc29-5x44	extraction preserves SUID/SGID bits
GHSA-p634-w6r4-rjp2	duplicate entry names resolve differently in getEntry() and extractAllTo()
GHSA-c6fg-446q-cg94	getDataAsync() bypasses the maxOutputLength guard
GHSA-8238-w5pm-2374	unhandled error event in async DEFLATE crashes the process

     "node_modules/adm-zip": {
-      "version": "0.6.0",
+      "version": "0.6.1",

I did not run a bare npm update adm-zip: it rewrites ~300 lines of unrelated optional peer entries
(@lezer/common, encoding, …) in this lockfile and would bury the change. The edit is surgical
and npm ci accepts it.

Related issue

Closes #1301

Type of change

• Refactor or maintenance

Validation

• npm ci --dry-run --include=dev — exit 0 with the edited lockfile, so the lock and
  package.json agree.
• npm audit before: 29 total (1 critical, 15 high, 9 moderate, 4 low), adm-zip listed.
  After: 28 total (1 critical, 14 high, 9 moderate, 4 low), adm-zip absent.
• Behaviour compared, not just version. extractPluginArchive from
  electron/capabilities/packageArchive.ts was called directly against 0.6.0 and 0.6.1 with the
  same four archives. Output was identical in every case: a normal package accepted with the same
  entry count and byte count, getEntry() / header.size / getData() unchanged, and traversal
  and absolute-path entries resolving to the same in-destination paths.
• Zip-path suites: test-capability-plugin-store, test-capability-updates,
  test-library-attachment-html-sanitize, test-library-extraction-progress-cancel — 33/33 pass.

Two suites in that area (test-research-attachments, test-primary-sources-archive) fail to start
in this environment at requireElectronRuntime (scripts/lib/tsRuntimeHooks.mjs:121), before any
zip code runs. I installed 0.6.0 back and re-ran them: they fail identically, so the failure is
pre-existing and environmental rather than caused by this change.

Lint, typecheck and build are unaffected — no source file is touched. CI's quality job covers
them regardless.

Screenshots

Not applicable: a lockfile version change with no interface effect.

Privacy and data review

• No secrets, credentials, private vault content, personal data, student data, or confidential documents are included.
• No new network access.
• The change does not send rosters, grades, student answers, or other protected data to AI providers.
• The change does not use AI to grade, rank, profile, or evaluate students.
• No database, backup, synchronization, or migration effects.

Contributor checklist

• Written in English and references an existing issue.
• Screenshots not applicable — see above.
• CLA already accepted through the CLA / signature check.
• No new tests: no behaviour changes, and the version-level comparison above is the evidence a
  unit test would give.
• No documentation describes the pinned patch version.
• No new static UI text, so no language table changes.
• Local-first behaviour and privacy boundaries preserved.
• Read CONTRIBUTING.md and CODE_OF_CONDUCT.md.

Two observations, unrelated to this bump

Both are identical on 0.6.0 and 0.6.1, so neither is a reason to hold this change. Recording
them because I found them while verifying, and they may be intentional:

1. extractPluginArchive refuses any archive that contains an explicit directory entry — assets/ [dir] fails with "Unsafe plugin archive entry: assets/", because safeEntryPath treats the
   trailing slash as an empty segment. Many zip writers emit directory entries by default.
2. A crafted ../../escaped.txt entry is stored by adm-zip as escaped.txt, so it lands inside the
   destination and safeEntryPath is never consulted. The outcome is safe; it just comes from
   adm-zip's normalisation rather than from the guard.

[github-actions]

@jorgepb96 @prismatic7, all required checks have passed for the latest revision of this PR. It is ready for maintainer review and merge consideration.

Latest revision: 257981a4d6bc.