Warning: Permanently added '3.81.84.115' (ED25519) to the list of known hosts. You can reproduce this build on your computer by running: sudo dnf install copr-rpmbuild /usr/bin/copr-rpmbuild --verbose --drop-resultdir --srpm --task-url https://copr.fedorainfracloud.org/backend/get-srpm-build-task/11185565 Version: 1.10 PID: 11859 Logging PID: 11861 Task: {'appstream': False, 'background': False, 'build_id': 11185565, 'chroot': None, 'distributions_in_build': [], 'distributions_in_project': ['alma-kitten+epel-10', 'epel-10', 'epel-9', 'fedora-43', 'fedora-44', 'fedora-45'], 'package_name': None, 'project_dirname': 'daily', 'project_name': 'daily', 'project_owner': '@meshtastic', 'repos': [], 'sandbox': '@meshtastic/daily--vidplace7', 'source_json': {'clone_url': 'https://github.com/meshtastic/firmware.git', 'committish': '34cb8d5828be71fc7d55498e415953eea8a27821', 'spec': '', 'srpm_build_method': 'rpkg', 'subdirectory': '', 'type': 'git'}, 'source_type': 8, 'submitter': 'vidplace7', 'task_id': '11185565'} Running: git clone https://github.com/meshtastic/firmware.git /var/lib/copr-rpmbuild/workspace/workdir-cxo710gm/firmware --depth 500 --no-single-branch --recursive cmd: ['git', 'clone', 'https://github.com/meshtastic/firmware.git', '/var/lib/copr-rpmbuild/workspace/workdir-cxo710gm/firmware', '--depth', '500', '--no-single-branch', '--recursive'] cwd: . rc: 0 stdout: Submodule path 'meshtestic': checked out 'dcac7e5673005f4d8a2b1f0f6e06877b689d7519' Submodule path 'protobufs': checked out '8d0ed0c135f91ad1d6f9c60bc341277d64946bce' stderr: Cloning into '/var/lib/copr-rpmbuild/workspace/workdir-cxo710gm/firmware'... Submodule 'meshtestic' (https://github.com/meshtastic/meshTestic) registered for path 'meshtestic' Submodule 'protobufs' (https://github.com/meshtastic/protobufs.git) registered for path 'protobufs' Cloning into '/var/lib/copr-rpmbuild/workspace/workdir-cxo710gm/firmware/meshtestic'... Cloning into '/var/lib/copr-rpmbuild/workspace/workdir-cxo710gm/firmware/protobufs'... Running: git checkout 34cb8d5828be71fc7d55498e415953eea8a27821 -- cmd: ['git', 'checkout', '34cb8d5828be71fc7d55498e415953eea8a27821', '--'] cwd: /var/lib/copr-rpmbuild/workspace/workdir-cxo710gm/firmware rc: 0 stdout: stderr: Note: switching to '34cb8d5828be71fc7d55498e415953eea8a27821'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by switching back to a branch. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -c with the switch command. Example: git switch -c Or undo this operation with: git switch - Turn off this advice by setting config variable advice.detachedHead to false HEAD is now at 34cb8d582 Rework XEdDSA signing policy: Compatible stops signing, AES-CCM overrides, Strict exemptions (#12191) Generated rpkg config: [rpkg] preprocess_spec = True [git] anon_clone_url = https://github.com/%(repo_path)s [lookaside] download_url = https://${git_props:remote_netloc}/repo/pkgs/%(repo_path)s/%(filename)s/%(hashtype)s/%(hash)s/%(filename)s Writing config into /var/lib/copr-rpmbuild/workspace/workdir-cxo710gm/.config/rpkg.conf Running: rpkg srpm --outdir /var/lib/copr-rpmbuild/results --spec /var/lib/copr-rpmbuild/workspace/workdir-cxo710gm/firmware cmd: ['rpkg', 'srpm', '--outdir', '/var/lib/copr-rpmbuild/results', '--spec', '/var/lib/copr-rpmbuild/workspace/workdir-cxo710gm/firmware'] cwd: /var/lib/copr-rpmbuild/workspace/workdir-cxo710gm/firmware rc: 0 stdout: Wrote: /var/lib/copr-rpmbuild/results/meshtasticd.spec setting SOURCE_DATE_EPOCH=1792627200 Wrote: /var/lib/copr-rpmbuild/results/meshtasticd-2.8.2-14880.daily.git34cb8d582.src.rpm RPM build warnings: stderr: git_dir_pack: archiving /var/lib/copr-rpmbuild/workspace/workdir-cxo710gm/firmware: commit 34cb8d5828be71fc7d55498e415953eea8a27821 (HEAD, origin/develop, origin/HEAD, develop) Author: Jonathan Bennett Date: Thu Oct 22 01:08:36 2026 +0000 Rework XEdDSA signing policy: Compatible stops signing, AES-CCM overrides, Strict exemptions (#12191) * Rework XEdDSA signing policy: Compatible stops signing, AES-CCM overrides Signing costs 66 bytes per packet. On a crowded mesh that matters, and packets on an AES-CCM channel were paying it on top of the CCM tag. Sending (perhapsEncode): - Compatible, the default, no longer signs. Balanced and Strict sign broadcasts as before; licensed (ham) nodes also sign unicasts, but now only under Balanced or Strict. - Packets on an AES-CCM (use_aead) channel are never signed. This also removes the case where a signed CCM packet passed signedDataFits() but then failed the CCM size check with TOO_LARGE. Receiving (checkXeddsaReceivePolicy): - Only Strict drops a packet for lacking a signature. Balanced no longer drops unsigned broadcasts from known signers; that downgrade rule and its canonical-sizing helper are removed. - An AES-CCM channel overrides Strict: its unsigned or unverifiable packets are accepted, since the CCM tag authenticates them. - A malformed or failing signature still drops the packet in every mode. Identity (new NodeDB::refusesUnsignedIdentity, used by updateUser, NodeInfoModule and TrafficManagementModule): - Balanced and Strict still refuse an unsigned NodeInfo that would change a known signer's identity, except on an AES-CCM channel. - Compatible accepts it, since firmware before 2.8 strips signatures when relaying. Channels::isAEADEnabled() now returns false for an out-of-range index instead of logging, since receive paths pass a packet's index unchecked. XEDDSA_SIGNATURE_FIELD_BYTES lost its only user and is removed. Tests: test_packet_signing drops the cases that pinned the removed downgrade sizing (A7-A9, A18-A19, E5, E10-E13, D1), flips A4 and E1 to acceptance, and adds AES-CCM, Compatible and ham cases (A18-A20, B18-B20, N12-N13). test_mqtt and test_traffic_management pin the same rules on the plaintext-MQTT and NodeInfo-cache paths. Co-Authored-By: Claude Opus 5.5 Claude-Session: https://claude.ai/code/session_011DjtCrF8NLMGs9DtEVQkUK * Sign NodeInfo unicasts, forward signed requests, check signed NodeInfo keys A NodeInfo request or reply carries the key a peer will use for PKI direct messages, but off ham mode only broadcasts were signed. A Strict node therefore dropped every NodeInfo reply and could only learn a new peer's key from a signed broadcast, hours apart. - perhapsEncode: under Balanced and Strict, NodeInfo is signed even when unicast (still never on an AES-CCM channel, never in Compatible). - TrafficManagementModule: a NodeInfo request that carries a signature is forwarded instead of answered from the cache. Its sender may need a signed reply, and a reply sent on the target's behalf can never be signed. - checkXeddsaReceivePolicy: a signed NodeInfo verified against a stored key must advertise that same key, and the key must hash to the sender's node number, as first contact already requires. Otherwise it is dropped. This stops a valid signature vouching for another key, and stops a key planted on trust under the wrong node number proving itself with fresh signatures. Tests: B7 now expects NodeInfo unicasts signed; B21 pins signing per policy; A21-A23 pin the key-consistency check; a traffic-management case pins that a signed request is forwarded while the same request unsigned is answered. Co-Authored-By: Claude Opus 5.5 Claude-Session: https://claude.ai/code/session_011DjtCrF8NLMGs9DtEVQkUK * Strict: accept unsigned acks and traceroutes; never sign traceroutes Strict dropped every unsigned packet that was not PKI-encrypted. Acks and traceroutes are never signed, so a Strict node saw no acks, retransmitted every reliable packet to exhaustion, and could not take part in traceroutes. - checkXeddsaReceivePolicy: Strict no longer drops an unsigned ROUTING_APP packet; an ack carries its own proof (AckProof.h). Traceroutes are accepted in every mode, and any signature on one is ignored rather than verified. - perhapsEncode: a traceroute is never signed, including in ham mode, which signs other unicasts. Every relay rewrites the route, so a signature fails verification from the second hop on, and a bad signature drops the packet in every mode. - TraceRouteModule::alterReceivedProtobuf: strip any signature when rewriting the route, so a traceroute signed by older firmware is not dropped by older receivers further along. Tests: A24-A26 (Strict accepts unsigned acks and traceroutes; a traceroute signature is ignored), B22 (traceroutes never signed), B7 updated, and test_traceroute_nexthop pins the signature strip on rewrite. Co-Authored-By: Claude Opus 5.5 Claude-Session: https://claude.ai/code/session_011DjtCrF8NLMGs9DtEVQkUK * Drop the traceroute signature strip Only 2.8.0 and 2.8.1 pre-release nodes ever signed a traceroute: ham mode, which signs every unicast, and client-sent broadcast traceroutes. Stripping the signature on rewrite only helped those pre-releases interoperate, which does not justify the code. Receivers still ignore a traceroute signature, and traceroutes are still never signed. Co-Authored-By: Claude Opus 5.5 Claude-Session: https://claude.ai/code/session_011DjtCrF8NLMGs9DtEVQkUK * Sign unicast positions under Balanced and Strict A position request or reply is PKI-excluded, so a signature is its only authentication, but off ham mode only broadcasts were signed. Strict dropped every position request and reply, and under Balanced any channel member could fake another node's location with an unsigned reply. perhapsEncode now signs POSITION_APP unicasts under Balanced and Strict, as it does NodeInfo. Nothing rewrites a position in flight - precision is applied by the originator before signing - so the signature survives relaying, and it binds request_id so a reply cannot be retargeted. Compatible and AES-CCM channels still sign nothing. Tests: B23 pins position unicast signing per policy and Strict acceptance; B7 expects position unicasts signed; B2 and B5 use PRIVATE_APP as their unsigned unicast now that position is signed. Co-Authored-By: Claude Opus 5.5 Claude-Session: https://claude.ai/code/session_011DjtCrF8NLMGs9DtEVQkUK * Strict: accept unsigned key verification messages Key verification's bootstrap messages (M1, M2) go out channel-encrypted because the peer's key is not known yet, so they cannot carry a signature the receiver could verify. Strict dropped them, so two Strict nodes that did not already hold each other's keys could never run key verification. The handshake does not rely on the transport: hash1 binds both public keys to the security number the users exchange, and a key is only stored after the numbers match and the user accepts. A forged request can at most raise a verification prompt, bounded by the single session slot and the 60 s remote cooldown - as it already can under Balanced. Test: A27 pins that Strict accepts an unsigned key verification message. Co-Authored-By: Claude Opus 5.5 Claude-Session: https://claude.ai/code/session_011DjtCrF8NLMGs9DtEVQkUK * test_nodedb_identity_hygiene: pin the identity refusal to Balanced Two cases expected updateUser() to refuse an unsigned update from a known signer under a zeroed config. Zeroed is Compatible, which now accepts it, so they failed in CI. Run them under Balanced, and add the Compatible counterpart so both halves of the rule are pinned at the updateUser level. Co-Authored-By: Claude Opus 5.5 Claude-Session: https://claude.ai/code/session_011DjtCrF8NLMGs9DtEVQkUK * Ham mode: sign in place of PKI, authenticate acks with the ack proof (#12200) Ham mode signed every unicast under Balanced and Strict, acks included. A signed ack from a node whose key a Strict receiver lacks is dropped, so the sender retransmits to exhaustion, and the signature costs 66 bytes where the ack proof costs about 10. Ham mode now signs the unicasts PKI would cover in regular mode, plus broadcasts, NodeInfo and position as before. Acks are no longer signed; they carry the ack proof, which needs only the two nodes' keys, not PKI. Strict already accepts unsigned acks. Claude-Session: https://claude.ai/code/session_011DjtCrF8NLMGs9DtEVQkUK Co-authored-by: Claude * Notify the client when an unsigned identity update is refused Balanced and Strict refuse an unsigned NodeInfo that would change a known signer's name or role, but the refusal only reached the device log, so the user saw a stale name with no reason. Send a ClientNotification naming the node (by the name already held, never the refused claim) and how to accept its updates again: remove the node. Rate limited to once per node per boot, over the last 8 nodes, and to one notice per minute overall, so a signer relayed through pre-2.8 firmware or a burst of them cannot flood the client. Co-Authored-By: Claude Opus 5.5 Claude-Session: https://claude.ai/code/session_011DjtCrF8NLMGs9DtEVQkUK * Refused identity notice: only for a name or role change, drop the warnings Notify only when the refused NodeInfo would have changed the stored long name, short name or role, compared through CopyUserToNodeInfoLite so truncation and sanitizing cannot read as a change. A signer held only in the warm tier has no stored name to compare and is not reported. Remove the two LOG_WARNs at the refusal sites; the notice replaces them. Co-Authored-By: Claude Opus 5.5 Claude-Session: https://claude.ai/code/session_011DjtCrF8NLMGs9DtEVQkUK * Refused identity notice: name the security setting that refused it Co-Authored-By: Claude Opus 5.5 Claude-Session: https://claude.ai/code/session_011DjtCrF8NLMGs9DtEVQkUK * Refused identity notice: one global hourly throttle, no per-node tracking Co-Authored-By: Claude Opus 5.5 Claude-Session: https://claude.ai/code/session_011DjtCrF8NLMGs9DtEVQkUK --------- Co-authored-by: Claude git_dir_pack: Wrote: /var/lib/copr-rpmbuild/results/firmware-34cb8d58.tar.gz warning: Downloading https://github.com/meshtastic/web/releases/download/v2.6.7/build.tar to /var/lib/copr-rpmbuild/results/build.tar Downloading https://github.com/meshtastic/web/releases/download/v2.6.7/build.tar to /var/lib/copr-rpmbuild/results/build.tar Output: ['build.tar', 'meshtasticd.spec', 'meshtasticd-2.8.2-14880.daily.git34cb8d582.src.rpm', 'firmware-34cb8d58.tar.gz'] Running SRPMResults tool Using distributions_in_project for this build. Extracting arch-specific tags for alma-kitten+epel-10 Extracting arch-specific tags for epel-10 Extracting arch-specific tags for epel-9 Extracting arch-specific tags for fedora-43 Extracting arch-specific tags for fedora-44 Extracting arch-specific tags for fedora-45 Package info: { "architecture_specific_tags": { "alma-kitten+epel-10": {}, "epel-10": {}, "epel-9": {}, "fedora-43": {}, "fedora-44": {}, "fedora-45": {} }, "name": "meshtasticd", "epoch": null, "version": "2.8.2", "release": "14880.daily.git34cb8d582" } SRPMResults finished