Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Session event emits the customer's MAC address in the p tag — spec-invalid value on every payment response

Chiusa Adatta ai principianti
#949 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@Amperstrand ci sta già lavorando.

Dal 16/10/2026.

  • #951 di @Amperstrand — aperta

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
70/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
go
Ambito
backend

Direzione di ricerca

Inizia da createSessionEvent in src/merchant/merchant.go, dove l'evento kind-1022 inserisce customerPubkey nel tag p, e dal suo unico chiamante in PurchaseSession, che passa l'indirizzo MAC. Rimuovi il tag p dall'evento di sessione e lascia device-identifier com'è. Prima di modificare, esegui grep nelle suite di conformità di portal e PRTA per cercare qualsiasi lettore del tag p, dato che l'issue dice che è visibile sul wire. Il lavoro è completato quando l'evento di sessione non ha il tag p e i test del package merchant passano ancora.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Found while resolving the spec divergence tollgate#16 (spec PR: tollgate#26).

Evidence

createSessionEvent in src/merchant/merchant.go declares a customerPubkey parameter and puts it straight into the kind-1022 session event's p tag:

func (m *Merchant) createSessionEvent(session *CustomerSession, customerPubkey string) (*nostr.Event, error) {
    deviceIdentifier := session.MacAddress
    ...
    Tags: nostr.Tags{
        {"p", customerPubkey},
        {"device-identifier", "mac", deviceIdentifier},

Its only call site passes the MAC address (src/merchant/merchant.go, PurchaseSession):

sessionEvent, err := m.createSessionEvent(session, macAddress)

So every payment response carries the customer's MAC in p — a value that is not a Nostr pubkey. Consequences: #p relay-side filtering of session events can never match anything; any spec-conformant consumer validating p as a pubkey rejects our session events; and the MAC — which device-identifier already carries — is duplicated into a field whose contract says pubkey.

Why it happens

Pre-March-2026 the payment was a signed kind=21000 event, so a customer pubkey existed. The raw-token rework removed the identity source; the parameter was never revisited.

Suggested fix

In the raw-token flow there is no customer Nostr identity, so the spec-conformant behavior is to omit the p tag (the spec PR above makes p conditional and forbids non-pubkey values in it). If the legacy kind=21000 envelope ever carries a verified customer pubkey, that is the one case where p could be filled.

Note the change is wire-visible on every successful payment response (the shipped portal and PRTA conformance suites should be checked for anything reading the p tag — grep suggests the portal keys on allotment/metric, but that is worth confirming in review, not assuming).

Also noted there

The same function emits a start-time tag TIP-01 does not document — flagged on the spec PR as a separate documentation proposal, not part of this fix.

Lingua principale
Go
Stelle
12
Fork
14
Merge medio
3g 18h
PR unite (30g)
284

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di OpenTollGate/tollgate-module-basic-go

Tutte le issue di OpenTollGate/tollgate-module-basic-go

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.