sdkconfig.defaults

# lnurl-vault sdkconfig defaults.
#
# Every option here is applied by a real build: CI builds both environments
# on every push and pull request, and both have been flashed to and run on
# real hardware (see docs/HARDWARE-TEST-CHECKLIST.md for what that does and
# does not cover). An earlier version of this comment said the file had been
# authored without a working ESP-IDF install and pointed at a README section
# called "Status: unverified by compilation", neither of which is true any
# more.
#
# Option names have still drifted between ESP-IDF releases before, so if
# `pio run` reports an unknown option on a different installed version,
# reconcile the affected line against `pio run -t menuconfig` rather than
# assuming this file is wrong wholesale. platformio.ini pins the platform
# (espressif32@7.0.1) precisely so that does not happen by surprise.

# --- NVS encryption: deliberately OFF ------------------------------------
# Note storage is NOT encrypted at rest. A physical flash dump recovers every
# secret. Physical possession of the device is the protection model, exactly
# as it is for the on-device browse-and-unveil gesture (see README.md).
#
# This was previously:
#
#     CONFIG_NVS_ENCRYPTION=y
#     CONFIG_NVS_SEC_HMAC_EFUSE_KEY_ID=0
#
# which looks like free hardening and is not. On ESP32-S3 that selects the
# HMAC key-protection scheme, and nvs_flash_init() then generates and burns
# the HMAC key into eFuse key block 0 the first time a device boots with an
# empty block. That write is irreversible, happens per device, and nothing
# in the firmware or the flashing instructions asks anyone to choose it: it
# is a silent side effect of first boot. A device that has burnt block 0 is
# permanently committed, and block 0 is also what Secure Boot V2's default
# provisioning flow claims.
#
# Turning any of this back on is a real option, but it belongs in a
# controlled production flash step with a written eFuse map, not in the
# default development build. Nothing in src/ depends on the setting:
# nvs_storage.c calls plain nvs_flash_init(), which handles whichever scheme
# Kconfig selects (including none).
#
# Prior art for the same call, with the reasoning written out:
# https://github.com/forgesworn/heartwood-esp32/blob/main/firmware/sdkconfig.defaults
CONFIG_NVS_ENCRYPTION=n

# --- No Wi-Fi -------------------------------------------------------------
# The device does no networking of its own (see README.md) — the mint is
# only ever reached through the paired browser session. Leaving the Wi-Fi
# driver out entirely shrinks the attack surface and flash/RAM footprint.
CONFIG_ESP_WIFI_ENABLED=n

# --- Bluetooth (NimBLE) ----------------------------------------------------
# Also required for the ESP32-S3 hardware RNG's documented full-entropy
# guarantee (Wi-Fi or BT must have been active at least once) — see
# secret.c and README.md's security posture section.
CONFIG_BT_ENABLED=y
CONFIG_BT_NIMBLE_ENABLED=y
# One connection at a time. The device is a single-peer vault, and ble_gatt.c
# keeps one reassembly/tx state (g_conn_handle/g_rx/g_tx_buf); a second central
# would interleave framing and could be notified another's response, including
# an export reply. Default was 3.
CONFIG_BT_NIMBLE_MAX_CONNECTIONS=1

# --- Flash size -------------------------------------------------------------
# Both supported boards ship 16MB on the common variants; adjust if yours
# differs (`pio run -t menuconfig` -> Serial flasher config).
CONFIG_ESPTOOLPY_FLASHSIZE_16MB=y

# Host transport and console routing are per-chip and live in
# sdkconfig.defaults.esp32 / sdkconfig.defaults.esp32s3, which ESP-IDF layers
# on top of this file automatically by target name.

# --- Task watchdog --------------------------------------------------------
# 60s against the 30s approval window, so a human taking their time reading
# the screen never trips it. Only ui_task subscribes -- see the reasoning in
# src/ui/ui_task.c, in short: it is the task on the far side of every
# confirmation wait and the one whose wedging IS the deadlock, while the
# transport tasks rest blocked on a queue by design and may legitimately be
# stuck for a minute on purpose.
#
# Panic rather than just log: a vault that has stopped answering is holding
# secrets in RAM, and a reset that leaves a breadcrumb (src/crash_crumb.c
# records the reset reason across the restart) is more useful than a device
# that sits there wedged and silent.
CONFIG_ESP_TASK_WDT_INIT=y
CONFIG_ESP_TASK_WDT_TIMEOUT_S=60
CONFIG_ESP_TASK_WDT_PANIC=y