Erick λ
Erick λ
> That means the first byte needs to be 0xfd and then the next two bytes need to be a `uint16` in the correct range. Choosing randomly, the fuzzer has...
I added your idea to the custom mutator, as well as another that mutates the bytes within the BigSize range to increase the likelihood of generating a valid TLV. After...
> Maybe we should also change `DecodeHopPayload` to enforce the correct size, rather than `UINT16_MAX`. Updated! `DecodeHopPayload` now validates that the payload size does not exceed `MaxHopPayloadSize` (1265 bytes) rather...
> IIUC it still results in the malformed packet being rejected? Or which inconsistencies are you referring to here? As you said, the packet would be forwarded to the next...
> > The fix doesn't require peeking or changing `DecodeHopPayload`. It simply limits the input reader: > > Yeah, I understood that. My comment was on @Roasbeef earlier comment. Sorry...
> @erickcestari I vaguely recall that you were having issues with fuzzing CLN invoice requests, due to validation being scattered throughout the codebase. Is this still the case? Yes, this...
> Thanks for the report! I don't know if we care though, since `eclair` only supports paying invoices using lightning and will never use the fallback address. We've also mentioned...
Thanks for the review @MPins, I'll address those suggestions soon!
Ready for review again!
> Thanks for the PR! Now pending a rebase 💾 Rebased! 🫡