Enforce content-length validation on sender and size limits on payjoin-cli

[GideonBature]

This PR follows up on #770 and addresses the remaining improvements in comment. It implements stricter content-length validation and removes MAX_CONTENT_LENGTH from the sender side, moving it to payjoin-cli.

Summary of changes

1. Sender-side validation

   • Mirrors the receiver-side logic by removing MAX_CONTENT_LENGTH and validating that the actual body length matches the Content-Length header.

2. payjoin-cli receiver

   • Adds a size limit when collecting the body using .collect(), to avoid unbounded memory allocations from a potentially malicious counterparty.

3. payjoin-cli sender

   • Enforces a similar limit when handling response bodies using response.bytes() from reqwest.

Ref: #770
Closes: #756

[coveralls]

Coverage Report for CI Build 24911698278

Coverage increased (+0.07%) to 85.021%

Details

• Coverage increased (+0.07%) from the base build.
• Patch coverage: 9 uncovered changes across 2 files (65 of 74 lines covered, 87.84%).
• No coverage regressions found.

Uncovered Changes

File	Changed	Covered	%
payjoin-cli/src/app/v1.rs	20	12	60.0%
payjoin-cli/src/app/mod.rs	14	13	92.86%

Coverage Regressions

No coverage regressions found.

---

Coverage Stats

Relevant Lines:	13412
Covered Lines:	11403
Line Coverage:	85.02%
Coverage Strength:	399.55 hits per line

---

💛 - Coveralls

[GideonBature]

I have implemented the changes suggested. However, I had to introduce about two dependencies, which are:

• futures
• bytes

as a result of that I attempted to update the lock files using the update-lock-files.sh script. However, I kept getting can't find crate for serde`` for bitcoin-0.32.5 and for `rustls-0.22.4`.

I want you to review what I have thus far, let me know if I am going in the right direction, as I find a solution to the error I am having.

[nothingmuch]

This is looking great. Thank you!

The new dependencies are fine IMO, because they are already in our dependency chain if I'm not mistaken, and also because payjoin-cli can be more flexible about new dependencies than the payjoin crate.

The buffering code is very clear. I think a Vec<u8> can replace Bytes, since they are more or less the same on the inside, the main difference is Bytes support cheap clone(), which we don't need, for the cost of slightly more indirection.

Instead of duplicating it in the sender and receiver, a utility function can be added to payjoin-cli's app module.

Finally, as a nitpick, I find additional whitespace to be helpful when reading, but please try to commit such trivial changes in their own commits, that makes it easier to review commit by commit, github's files view uses lexicographical order for files and combines all the changes of all commits, both of which make it harder to spot important changes in between trivial ones.

[GideonBature]

I implemented the suggestions you gave, however, for the utility function, putting it in mod.rs of app, I am encountering a challenge where I am unable to access the hyper dependencies, I really don't know why. And I will be needing it, since I will need to make use of Bytes from it for the utility function.

[nothingmuch]

I didn't quite understand your last comment about hyper & bytes, but i think the read_limited_body function is in the right place?

similar limiting for app/v2.rs can be added in a separate PR, with a fixed response size, and reusing this function, but moving it to the top level mod.rs should be straightforward (just making it pub(crate) and bringing in the necessary imports, namely hyper::body::Bytes)

anyway this is getting close, i only have some fairly small cleanup suggestions

[GideonBature]

Lint is failing with this:

error[E0599]: no variant or associated item named `Parse` found for enum `core::send::error::InternalValidationError` in the current scope
   --> payjoin/src/core/send/mod.rs:699:90
    |
699 |         let res_str = std::str::from_utf8(response).map_err(|_| InternalValidationError::Parse)?;
    |                                                                                          ^^^^^ variant or associated item not found in `core::send::error::InternalValidationError`
    |
   ::: payjoin/src/core/send/error.rs:94:1
    |
 94 | pub(crate) enum InternalValidationError {
    | --------------------------------------- variant or associated item `Parse` not found for this enum

error[E0599]: no variant or associated item named `parse` found for enum `core::send::error::ResponseError` in the current scope
   --> payjoin/src/core/send/mod.rs:700:75
    |
700 |         let proposal = Psbt::from_str(res_str).map_err(|_| ResponseError::parse(res_str))?;
    |                                                                           ^^^^^ variant or associated item not found in `core::send::error::ResponseError`
    |
   ::: payjoin/src/core/send/error.rs:250:1
    |
250 | pub enum ResponseError {
    | ---------------------- variant or associated item `parse` not found for this enum

I don't really know, I observed that the Parse is actually present, but it was feature gated to v1, I don't know if that is what is causing the lint to fail here? Same thing with the parse too in the ResponseError.

[GideonBature]

Resolved merge conflict.

[nothingmuch]

I appear to have compeltely forgotten about this PR, I'm really sorry about this...

there appear to be unrelated changes, likely the result of an incorrect rebase? the changes having to do with the length enforcement seem correct to me but i'm not sure why some things like V1Context are there

[GideonBature]

Oh, I will do a check and fix that the push for your review.