bolt12: export DecodeOffer

[usefahmed07]

Description

Exports bolt12.decodeOffer as bolt12.DecodeOffer, mirroring the
existing exported decode functions for the other BOLT 12 messages
(DecodeInvoice, DecodeInvoiceRequest, DecodeInvoiceError).

Currently decodeOffer is unexported and only referenced from the
package's own tests, so there is no public entry point to parse a raw
BOLT 12 offer TLV stream from outside the bolt12 package.

Motivation

bitcoinfuzz, a
differential fuzzing project for Bitcoin/Lightning implementations,
has an open issue to add LND to its deserialize_offer fuzz target
(bitcoinfuzz/bitcoinfuzz#586), which references this work
(#10736). That target needs a public decode
function to call from outside the package, exactly like the ones
already exported for Invoice/InvoiceRequest/InvoiceError.

Changes

• bolt12/offer.go: rename decodeOffer -> DecodeOffer (doc comment
  updated accordingly).
• bolt12/offer_test.go, bolt12/invoice_request_test.go: update the
  two internal call-sites to use the new exported name.

No behavioral change - this is a pure rename/export, decoding logic is
untouched. As noted in the function's doc comment, callers that need a
valid offer (not just a syntactically decodable one) should still run
ValidateOfferRead afterwards.

[github-actions]

🟡 PR Severity: MEDIUM

gh pr view | 3 files | 8 lines changed

🟡 Medium (1 file)

• bolt12/offer.go - renames/exports decodeOffer to DecodeOffer (uncategorized package, pure API export, no behavioral change)

🟢 Low (2 files)

• bolt12/offer_test.go - test-only update to use the new exported name
• bolt12/invoice_request_test.go - test-only update to use the new exported name

Analysis

This PR exports bolt12.decodeOffer as bolt12.DecodeOffer, mirroring existing exported decode functions (DecodeInvoice, DecodeInvoiceRequest, DecodeInvoiceError) so external fuzzing tooling (bitcoinfuzz) can call it. It is a pure rename/export with no change to decoding logic, touching only 1 non-test file (bolt12/offer.go) and 2 test files that update call-sites. The bolt12 package isn't explicitly listed in the CRITICAL/HIGH tiers, and the change is small and low-risk, so it's classified as MEDIUM under the "other uncategorized Go files" bucket. No file-count or line-count thresholds for a severity bump are met.

---

_{To override, add a severity-override-{critical,high,medium,low} label.}

[Lrifton92]

The export itself is consistent with DecodeInvoice/DecodeInvoiceRequest, and keeping the permissive-decode doc comment (with the ValidateOfferRead note) is the right call for a fuzz entry point.

One issue though: the rename looks incomplete. After decodeOffer becomes DecodeOffer, there are still call sites referencing the old unexported name, so go test ./bolt12 won't compile (undefined: decodeOffer):

• bolt12/offer_test.go:71
• bolt12/offer_test.go:90
• bolt12/decode_test.go:44
• bolt12/validate_test.go:3027
• bolt12/validate_test.go:3135

The diff only updates offer_test.go:42 and invoice_request_test.go:155. A quick grep -rn 'decodeOffer(' bolt12/ should catch the remaining five. Worth running go build ./... && go test ./bolt12 -run x -count=1 locally before the CI check — since this is test-only code, the compile break is invisible in go build ./... alone.

[usefahmed07]

@Lrifton92 Good catch! Fixed in 74bb3b2, tests pass now.

[Lrifton92]

Marking this as request-changes: as noted in my earlier comment, the rename is incomplete — five call sites still reference the now-removed decodeOffer, so go test ./bolt12 fails to compile (undefined: decodeOffer):

• bolt12/offer_test.go:71
• bolt12/offer_test.go:90
• bolt12/decode_test.go:44
• bolt12/validate_test.go:3027
• bolt12/validate_test.go:3135

grep -rn 'decodeOffer(' bolt12/ catches all of them. Happy to re-approve once the package builds.

[Lrifton92]

Verified on the updated head (74bb3b2): all five call sites now use DecodeOffer, and go test ./bolt12/ -run '^$' -count=1 compiles and links the package cleanly (including the _test.go files where the breakage was), returning ok ... [no tests to run]. The earlier compile break is resolved. Thanks for the quick turnaround — LGTM.

[bitromortac]

This PR (#11191) redefines some of the exports to keep bolt12's package interface minimal (decodeOffer stays non-exported there). Using DecodeOfferString for fuzzing is not an option, right?

[usefahmed07]

Thanks @bitromortac, agreed: DecodeOfferString on master covers the path the fuzz target needs, so decodeOffer doesn't need to be exported. I switched the bitcoinfuzz target to it (bitcoinfuzz/bitcoinfuzz#655), so I'm closing this PR.