M2D.2 introduced StructuralCbor.encodeUint(int,...) and call sites
in DeviceResponseBuilder that pass int literals. The JC converter
rejected this without an explicit ints="true" attribute, breaking
both j3r180 and j3r452 CAP builds since 9879668.
ant-javacard's <cap ints="true"> opts the package into JCRE int
support. The CBOR encoders need it to handle uint values up to
2^32-1 per RFC 8949.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Drops gpapi-globalplatform 1.7 and gpapi-upgrade 1.1 (AMD-H Amendment H
v1.1) under applet/build-tools/gp-amdh/, sourced from
OpenJavaCard/globalplatform-exports (master snapshot 2020-09-30).
- dt-mvn.sh mounts exports/org/ into the converter's api_export_files/.
- pom.xml adds the .jar files as system-scope deps under the j3r452
profile so javac on j3r452 builds resolves org.globalplatform.upgrade
symbols (j3r180 builds don't see them on classpath).
- .gitignore: narrow build-tools/ exclusion to top-level only so the new
applet/build-tools/gp-amdh/ tree is trackable while the top-level
build-tools/jcardsim/ vendor fork stays out of the repo.
This commit alone produces zero CAP bytecode change because no current
source imports org.globalplatform.*. The infra is provably inert until
the Task 3.1+ source on feat/amd-h-epic-3-wip is merged. Verified by
diffing CAP zip components for both profiles: only the embedded
Java-Card-CAP-Creation-Time timestamp in META-INF/MANIFEST.MF differs.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Code review of 750f570 flagged three Important issues:
- Stale 'Output: target/aliro-applet.cap' comment in pom.xml antrun
plugin block.
- applet/INSTALL.md referenced the old single-CAP filename in three
places, breaking the documented gp.jar --load command.
- No safeguard or hint that -Pj3r180 and -Pj3r452 are mutually exclusive.
Updates the comments and the INSTALL.md filenames to point at
aliro-applet-j3r180.cap as the default. Adds mutual-exclusion notes
to both profile blocks.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Both profiles currently produce identical CAP bytecode, differing only
in ELF AID so they can coexist on a card during bench testing. The
j3r452 profile becomes meaningfully different in a later epic when it
adds the OnUpgradeListener bridge.
Three components, all bench-validated to varying depths:
- applet/: CSA Aliro v1.0 Java Card applet for J3R180. AUTH0 + AUTH1
expedited-standard flow end-to-end green via PC/SC bench reader
(aliro-bench-test). Userland AES-256-GCM and HMAC-SHA-256 layered
on top of J3R180's primitives because the card lacks both natively.
P-256 curve params seeded explicitly per J3R180's quirk.
- harness/: Python orchestrator (aliro-trustgen, aliro-personalize,
aliro-bench-test) for trust-bundle generation, card personalization
via PersonalizationApplet, and PC/SC AUTH0+AUTH1 transactions. 126
pytest cases passing.
- reader/STM32CubeExpansion_ALIRO_V1_0_0/: ST X-CUBE-ALIRO V1.0.0
with our NFC10A1 port (NUCLEO-U545RE-Q + X-NUCLEO-NFC10A1, ST25R200
shared with NFC09A1). nfc10-only/ project, NFC10A1 BSP shim,
ALIRO_TRUST_OVERRIDE include into vendor's provisioning.c, and an
ALIRO_APDU_TRACE wrapper around demoTransceiveBlocking. Boots,
detects the J3R180, completes SELECT + AUTH0; AUTH1 currently fails
with RFAL ERR_PROTO (0xB) — under investigation, see
docs/plans/2026-04-20-nucleo-nfc10a1-port.md and bench-notes/.
Excluded: x-cube-aliro.zip vendor archive, harness/.venv, build dirs,
generated aliro_trust.h (contains private reader scalar), all PEMs.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
