Skip to content

c64-https v0.5.1

Latest
Latest

Choose a tag to compare

View all tags
@JC-000 JC-000 released this 15 Oct 13:34
v0.5.1
ded2247
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

c64-https v0.5.1

For demonstration and educational purposes only. It is not cryptographically secure.

Built from ded2247. Submodule pins (tools/check_upstream_pins.py):

  • libs/nistcurves v0.15.0 (was v0.14.0);
  • libs/x25519 v0.16.0 (unchanged);
  • ip65 25a9c5a (untagged, unchanged).

This release covers 11 merged PRs since v0.5.0 (#287, #289-#294, #296, #298-#300). The main changes:

  • UCI fetches are faster;
  • the UCI images are smaller and no longer load into the I/O page;
  • only P-256 certificates are verified now;
  • the M3 demo disk is validated on public firmware.

Assets

image for PRG sha256
c64-https-ip65-onchip stock C64 + RR-Net, no REU, no turbo 810f115800ffb643b455a253ab6b2565e5f5543759ef2bc5c740c2fdd0489bdc
c64-https-uci-onchip U64E / C64 Ultimate, turbo, no REU ffa47fc32e43a16b995faee0d85d3d9312e1791a568820fedf7c0446bd27dfa6
c64-https-uci-comb U64E / C64 Ultimate, turbo + REU (fastest) 67cb00488543cf3d39051c5035768e482d71e15c254b8db1099b4ef478fdb7ae
c64-https-uci-m3-demo U64E with the TLS-socket (ESP32) firmware, see below 916d41628a17b9436bbf58a71f7350c721a06e459cf5c33e5baeb1ad61af9a24
disk sha256
c64-https-ip65-onchip.d64 3120210381634aabc7222c95b9ec2fccc193ad9ff4e3f2e4b0d86848f1db68eb
c64-https-uci-onchip.d64 21d953473003d55b897b008e60ade9e85a3aafca0d54cb85301f392181153fec
c64-https-uci-comb.d64 9cc97157a4749b924d06c6438a783d15fed160ec3f3602af887d92ec297c2f74
c64-https-uci-m3-demo.d64 ae2cc5b7d40190ddfc911cb40e7a7d62e406c134f304b3fe9e2f04ea540ff498

Each image ships as a .prg and as a bootable .d64. The release also carries MANIFEST.txt, build-info.txt, c64-https-listener.py, the M3 demo's c64-https-uci-m3-demo-README.txt and c64-https-uci-m3-demo-SHA256SUMS, and a top-level SHA256SUMS covering every other asset. The M3 demo's own checksum file names its README README.txt, the name inside the demo package; rename the asset to that before running shasum -c on it.

Faster UCI fetches

  • The UCI images no longer pace register reads (#299). Only register writes are paced now. The PR measured the Wikipedia C64 article on the U64E at 48 MHz:

    • uci-onchip: 375 s → 175 s;
    • uci-comb: 364 s → 163 s.

    UCI_READ_FENCE=1 restores the old behaviour.

  • The same change in the M3 adapter (#296). Per the PR, a large fetch is 11.6x faster. M3_READ_FENCE=1 restores the old client.

Smaller images

  • The UCI PRGs no longer load into $D000-$DFFF (#298, fixing #288; a re-land of #295). The trailing zero pad is dropped. Together with the P-384 retirement (#294, below), the UCI images shrink:

    • in v0.5.0 both were 62,977 B;
    • #294 removed the P-384 staging area at $E000-$FDFF, giving 55,297 B;
    • #298 removed the pad: uci-onchip is now 47,105 B and uci-comb 51,201 B.

    A KERNAL LOAD no longer writes into the I/O registers. tools/test_prg_io_range.py checks this, and make package-verify checks every image's load range.

  • P-384 is retired; only P-256 is verified (#294). P-384, RSA and Ed25519 leaves, and any CertificateVerify scheme other than 0x0403, are refused. One exception is documented in the README: the key extractor scans rather than parses, so a leaf that also carries a P-256 key pattern has that key extracted. The knobs that built P-384 are retired.

  • Layout passes:

    • SHA-256's add_to_hash is rolled into a loop, saving 250 B on every image (#290).
    • On UCI, the P-256 scratch is shared with cert_buf, with a test proving their lifetimes do not overlap (#292).
    • tools/measure_margins.py measures the two shipped UCI products (#289).

M3 demo

  • The demo README now names the PRG its figures were measured with (#300). A rebuild after an unrelated change cannot inherit the claim.
  • Validated on public firmware: JC-000/1541ultimate commit f3df8261 (ESP32 module 1.8), on branch pr/3-tls-r1. The branch has since moved on, with no protocol change. The prebuilt image, built from f3df8261, is in the fork prerelease tls-preview-f3df8261 (update_tls_f3df8261.u64, sha256 15e9ff7cd8a11daf1f4698d574480381d475db7754e1d276d9aa95e8013ded3c).
  • Not upstream: the TLS-socket commands are proposed on GideonZ/1541ultimate#952. Since this release they are open upstream as issue GideonZ/1541ultimate#995 and draft PR GideonZ/1541ultimate#997 (branch pr/3-tls-r1), which builds on draft PR #996 (ESP-IDF 6.0.3, issue #994). None of them is merged. (The demo's own README, frozen in the assets, was written before these existed.)
  • The in-C64 6510 TLS images remain the main product.

Build, test and rigs

  • Every contract sibling must sit exactly on a semver tag (#291), and nistcurves moves to v0.15.0.
  • The trust-store rigs use c64-test-harness's storage API (#293).
  • The README points at v0.5.0, and its #211 caveats are removed (#287).

Validated

Built from ded2247 on macOS 27.0.1, with GNU Make 3.81 (/usr/bin/make), ca65/ld65 V2.18 (as the tools report it; Homebrew's cc65 2.19 package) and LANG=en_US.UTF-8. make package-verify passed 14/14. The M3 demo package rebuilds to the same bytes (two clean builds and a .d64 read-back, in make package-m3-demo).

Rebuilding under a different locale (for example env -i, which gives the C locale) currently produces a different link order, and so different bytes, for the ip65, uci-onchip and uci-comb images. The M3 demo is not affected. Tracked in #301. The hashes above reproduce under LANG=en_US.UTF-8.

Hardware runs, 2026-10-15, with the exact bytes of the released PRG unless stated otherwise:

U64E, fw 3.15 git 3a1ff9ff, FPGA 126, core 1.50, 48 MHz. rig_https_banner.py drives the menu and checks completeness by the response's own framing.

image target result
uci-onchip en.wikipedia.org /wiki/Commodore_64 HTTP 200, 759,171 B == Content-Length
uci-onchip github.com /robots.txt HTTP 200, 16,739 B == Content-Length
uci-comb en.wikipedia.org /wiki/Commodore_64 HTTP 200, 759,171 B == Content-Length
uci-comb github.com /robots.txt HTTP 200, 16,739 B == Content-Length

Trust store (rig_trust_store.py): all phases passed, 24 checks with 0 failures, on /USB1 of the U64E. Phase 13 runs only at 1 MHz and was not run. The rig refuses any store directory but /<volume>/c64https-test, so it cannot run the released bytes, whose store is /USB1. It ran uci-onchip built with exactly the release arguments plus TRUST_STORE_DIR=/USB1/c64https-test (PRG 1ed6318d88d2daf986576eb57f68d80f68c8fe29553be20d70e1870c7a1346b8). The released uci-onchip also used its own store on /USB1 in its two banner runs above, recording first-use keys for en.wikipedia.org (KEY RECORDED ce88c808) and github.com (ff088be6). The uci-comb run logs do not show the store's line.

M3 demo, U64E on firmware f3df8261 (image sha256 above), ESP module 1.8, 48 MHz, REU disabled. The .d64 was loaded from drive 8:

  • Wikipedia C64 article: HTTP 200, 759,171 B == Content-Length, 20 s from G.
  • github.com/robots.txt: HTTP 200, 16,739 B, 5 s.
  • A name-mismatch host: refused with 94,CERTIFICATE NAME MISMATCH.
  • badssl.com (TLS 1.2 only): refused with 14,TLS ALERT RECEIVED: 40. This one used the same PRG written over REST.

ip65-onchip boots to the RR-Net banner in VICE (package-verify). The VICE network rig was not set up for this release, so there was no fetch run.

C64 Ultimate: one run of uci-onchip did not complete. See the next section.

Suites, at ded2247:

  • BACKEND=uci run_all_tests.py: 440/440. The net suite is an accounted skip, because it tests the ip65 adapter.
  • test_trust_release_guard: 24/24.
  • check_m3_client: 54/54, on the M3 sink build.
  • A bare pytest after a uci build: 483 passed, 1 failed. The failure is test_ip65_hw_checks_unit.py::test_the_build_exports_every_symbol_the_rig_reads, which needs an ip65 build and counts an involuntary skip as a failure. It is a test-layout issue, not a product defect, tracked in #302.

What this release does NOT do

  • No certificate chain validation on the three 6510 images. The released UCI images pin by trust-on-first-use (TRUST.A / TRUST.B); a build-time pin or a signed bundle needs a custom build. If the store cannot be used, they offer to continue unpinned. The ip65 image accepts any certificate whose signature verifies. On the M3 demo, the ESP32 verifies certificates against its own Mozilla CA store.
  • Server name validation is UCI-only.
  • Entropy is weak. The boot seed comes from SID voice 3 and CIA1 timer A. Both run off the system clock, so the seed has far less entropy than its 32 bytes suggest.
  • ip65-onchip was checked only by a VICE boot for this release.
  • The C64 Ultimate was not validated for this release. One run of uci-onchip against Wikipedia at 64 MHz did not reach a connection:
    • Its trust store could not be used, so the image printed TRUST FAIL 02 and asked CONTINUE UNPINNED? Y/N. The UCI images keep their trust store (TRUST.A / TRUST.B) on /USB1, and that C64 Ultimate has no /USB1 volume. That fits, but the cause was not investigated.
    • The path the rig typed arrived as /wiki/.ommodore_64.
    • No socket was opened ("NOT DIALLED").
Assets 16
Loading