Authenticate use of offer blinded paths #3139

jkczyz · 2024-06-20T16:56:09Z

Invoice requests are authenticated by checking the metadata in the corresponding offer. For offers using blinded paths, this will simply be a 128-bit nonce. Elided this metadata from the offer directly and instead include it in the offer's blinded paths. This prevents de-anonymization attacks by ensuring the blinded paths are used in the right context.

Fixes #3117

jkczyz · 2024-07-02T22:58:24Z

lightning/src/ln/channelmanager.rs

 			OffersMessage::Invoice(invoice) => {
+				let expected_payment_id = match context {
+					OffersContext::OutboundPayment { payment_id } => payment_id,
+					_ => return ResponseInstruction::NoResponse,
+				};
+
 				let result = match invoice.verify(expanded_key, secp_ctx) {
 					Ok(payment_id) => {
+						if payment_id != expected_payment_id {
+							return ResponseInstruction::NoResponse;
+						}


@TheBlueMatt If we receive an invoice for a refund without blinded paths, can we actually authenticate it? With this change, we'd see OffersContext::Unknown and so would return ResponseInstruction::NoResponse.

But if we skip the check in that case, someone could send us an invoice for a refund using an unrelated blinded path created before this PR (i.e., one where we'd get OffersContext::Unknown here). While this wouldn't de-anonymize us -- the refund contains our pubkey -- it could tie us to an old offer (or refund) that uses a transient pubkey.

I suppose this is also the case for an offer without blinded paths. Although in that case we can authenticate, but it could tie us to an older offer that uses a transient pubkey.

IMO if we break refunds issued by old LDK that's okay at this point. Offers less so.

codecov-commenter · 2024-07-03T23:18:19Z

Codecov Report

Attention: Patch coverage is 95.57823% with 26 lines in your changes missing coverage. Please review.

Project coverage is 89.78%. Comparing base (3733103) to head (825bda0).

Files	Patch %	Lines
lightning/src/offers/signer.rs	54.54%	15 Missing ⚠️
lightning/src/events/mod.rs	0.00%	4 Missing ⚠️
lightning/src/ln/channelmanager.rs	93.75%	2 Missing and 2 partials ⚠️
lightning/src/offers/nonce.rs	93.10%	1 Missing and 1 partial ⚠️
lightning/src/offers/invoice.rs	97.22%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3139      +/-   ##
==========================================
+ Coverage   89.71%   89.78%   +0.06%     
==========================================
  Files         121      122       +1     
  Lines      101074   101493     +419     
  Branches   101074   101493     +419     
==========================================
+ Hits        90680    91126     +446     
+ Misses       7701     7684      -17     
+ Partials     2693     2683      -10

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

TheBlueMatt

Basically LGTM, I think.

lightning/src/ln/channelmanager.rs

lightning/src/offers/signer.rs

TheBlueMatt · 2024-07-11T15:49:25Z

lightning/src/offers/signer.rs

@@ -74,6 +80,7 @@ impl Metadata {
 			// derived, as wouldn't be the case if a Metadata::Bytes with length PaymentId::LENGTH +
 			// Nonce::LENGTH had been set explicitly.
 			Metadata::Bytes(bytes) => bytes.len() == PaymentId::LENGTH + Nonce::LENGTH,
+			Metadata::Nonce(_) => false,


Should we not switch the payer keys to being derived in the same way?

Possibly, yes. It's a little more complicated as the context would also need the Nonce and we'd need another variant here that wraps a 48-byte array (so it could be used with as_ref) containing the encrypted payment id and nonce. It would avoid increasing the size of a Refund with a path. Though for an InvoiceRequest the size savings isn't necessary.

It's a little more complicated as the context would also need the Nonce

Why?

Mostly for the reasons given in the rest of the sentence. :) Though, originally I thought the whole change would be more complicated until I switched to the additional enum variant approach.

Another consideration is we actually do need to set the payer metadata to something for both the InvoiceRequest and Refund cases according to the spec.

The writer: - MUST set `invreq_metadata` to an unpredictable series of bytes. The reader: - MUST fail the request if `invreq_payer_id` or `invreq_metadata` are not present.

For the case where we include blinded paths, we could set only the 16-byte Nonce instead? Or maybe the first 16 bytes of the encrypted PaymentId to avoid allocating another Vec? We wouldn't need it for anything ourself, as both the PaymentId and Nonce would come back in the BlindedPath. But the spec wants it because:

- if `offer_node_id` is present, and `invreq_metadata` is identical to a previous `invoice_request`: - MAY simply reply with the previous invoice.

And:

Note: the `invreq_metadata` is numbered 0 (not in the 80-159 range for other invreq fields) as this is the first TLV element, which ensures payer-provided entropy is used in hashing for [Signature Calculation](#signature-calculation).

Ok, I made this change except I've left the payer_metadata as is for now. When trying to change it to only include the nonce, ln::offers_tests::pays_bolt12_invoice_asynchronously fails. Presumably because the code is trying to re-verify the invoice using payer_metadata. I'll need to put some thought in if we could do this.

Right, I was confused about the rest of the sentence :)

Ok, I made this change except I've left the payer_metadata as is for now.

Doesn't this break our protection? We put the nonce in the blinded path so that no one but us knows it but then we copy it into the payer_metadata?

Not in this situation because the payment_id is encrypted in the payer_metadata. So an attacker wouldn't be able to include the unencrypted payment_id in any blinded path that they composed unless they learned of it by some other means.

I think the solution for asynchronous handling is to either include the OfferContext in Event::InvoiceReceived or drop the verification check from ChannelManager::send_payment_for_bolt12_invoice. Then we could remove the encrypted payment_id from the payer_metadata to save those 32 bytes, which is more important for a Refund. We'd still need to include some random data as per the spec, so we'd leave the nonce.

Not in this situation because the payment_id is encrypted in the payer_metadata. So an attacker wouldn't be able to include the unencrypted payment_id in any blinded path that they composed unless they learned of it by some other means.

Discussed offline. Ended up dropping the nonce from the payer metadata when including blinded paths.

I think the solution for asynchronous handling is to either include the OfferContext in Event::InvoiceReceived or drop the verification check from ChannelManager::send_payment_for_bolt12_invoice. Then we could remove the encrypted payment_id from the payer_metadata to save those 32 bytes, which is more important for a Refund. We'd still need to include some random data as per the spec, so we'd leave the nonce.

Included the OffersContext in Event::InvoiceReceived.

valentinewallace

Basically LGTM mod outstanding feedback!

lightning/src/ln/inbound_payment.rs

lightning/src/ln/peer_handler.rs

lightning/src/ln/offers_tests.rs

jkczyz

Still need to address Val's comments.

jkczyz · 2024-07-12T23:49:49Z

lightning/src/offers/signer.rs

@@ -74,6 +80,7 @@ impl Metadata {
 			// derived, as wouldn't be the case if a Metadata::Bytes with length PaymentId::LENGTH +
 			// Nonce::LENGTH had been set explicitly.
 			Metadata::Bytes(bytes) => bytes.len() == PaymentId::LENGTH + Nonce::LENGTH,
+			Metadata::Nonce(_) => false,


Ok, I made this change except I've left the payer_metadata as is for now. When trying to change it to only include the nonce, ln::offers_tests::pays_bolt12_invoice_asynchronously fails. Presumably because the code is trying to re-verify the invoice using payer_metadata. I'll need to put some thought in if we could do this.

shaavan

Looks Great To Me modulo some nits! 🚀

shaavan · 2024-07-16T13:59:45Z

lightning/src/blinded_path/message.rs

 	Unknown {},
-	/// Represents an outbound BOLT12 payment context.
+	/// Context used by a [`BlindedPath`] within an [`Offer`] for sending an [`InvoiceRequest`].


nit: I think we can improve this comment a bit to make the purpose of this more clear.

Maybe something like:

Suggested change

/// Context used by a [`BlindedPath`] within an [`Offer`] for sending an [`InvoiceRequest`].

/// Context used by a [`BlindedPath`] within an [`Offer`] to be received with an [`InvoiceRequest`].

Yeah, good call. I was trying to cram too much in one sentence. Re-worded into two sentences where one describes which messages use the variant in their blinded paths and another on which messages are intended to be received with the context.

shaavan · 2024-07-16T14:07:29Z

lightning/src/blinded_path/message.rs

+	///
+	/// [`Bolt12Invoice`]: crate::offers::invoice::Bolt12Invoice
+	/// [`InvoiceError`]: crate::offers::invoice_error::InvoiceError
+	InboundPayment {


Pointer for myself:

Looks like this variant is unused in this PR but will be used by #3163 when we start adding reply_path with the sent BOLT12Invoice

shaavan · 2024-07-16T14:09:07Z

lightning/src/offers/offer.rs

@@ -667,9 +665,9 @@ impl Offer {

 	#[cfg(async_payments)]
 	pub(super) fn verify<T: secp256k1::Signing>(


nit: Since we are touching this function, shall we also add it's documentation?

shaavan · 2024-07-16T14:20:47Z

lightning/src/blinded_path/message.rs

+	/// Context used by a [`BlindedPath`] for replying to a [`Bolt12Invoice`] with an
+	/// [`InvoiceError`].


nit: I think we can reword it a bit for better clarity!

Suggested change

/// Context used by a [`BlindedPath`] for replying to a [`Bolt12Invoice`] with an

/// [`InvoiceError`].

/// Context used by a [`BlindedPath`] as a reply path for a [`Bolt12Invoice`].

Also updated this to align with the other variants, for consistency.

TheBlueMatt · 2024-07-16T15:30:11Z

Chatted for a while offline, it looks like we need to remove the nonce from the metadata in invoice_requests.

lightning/src/ln/offers_tests.rs

jkczyz · 2024-07-16T16:12:50Z

Chatted for a while offline, it looks like we need to remove the nonce from the metadata in invoice_requests.

Yup, it was removed directly from derive_metadata_and_keys in 9f7fd0d. It doesn't affect the offer metadata case since we already ignore the returned value there and set the metadata to None. With the change in that commit, the returned bytes is now the empty vec (since there is no payment id for offer metadata) instead of allocating a vec with the nonce bytes. And when used for payer metadata it is the encrypted payment id, as is desired.

TheBlueMatt · 2024-07-16T17:52:47Z

lightning/src/offers/offer.rs

-					$self.offer.signing_pubkey = Some(keys.public_key());
+				match keys {
+					Some(keys) => $self.offer.signing_pubkey = Some(keys.public_key()),
+					None => $self.offer.metadata = Some(derived_metadata),


Don't we need to elide the nonce even when we're using non-random keys?

Hmm... None here implies not only did we not derive keys but also that we did not include any blinded paths. So we need the nonce in the metadata in order to authenticate as we'll get OffersContext::Unknown in the handler.

Ah, okay, sorry, missed the "no blinded paths" implication, can you comment that? Also is that enforced by the builder? Should it be?

Added a few comments throughout this method explaining. Currently, the builder requires giving a node id / signing pubkey upon construction. Then here when building the offer we override it if any blinded paths are set. It happens when Metadata transitions from DerivedSigningPubkey to Derived when calling Metadata::without_keys above, and thus Metadata::derive_from returns None for the keys here.

TheBlueMatt · 2024-07-16T18:00:04Z

lightning/src/ln/channelmanager.rs

-							let error = Bolt12SemanticError::InvalidMetadata;
-							return responder.respond(OffersMessage::InvoiceError(error.into()));
-						},
+						Err(()) => return ResponseInstruction::NoResponse,


FWIW I don't think there's anything wrong with ignoring the BOLTs here - as long as we handle "unsolicited invoice_request that is for an offer we didnt built" and "invoice_request that we received over the wrong path" the same we're fine. Not sure it matters much if we think this case isn't going to be a common one that we need to worry about making sure we get good errors back, but if we think it'd be helpful we should just do it.

Currently, this will only be triggered for older offers. When we add support for producing offers without blinded paths (i.e. with a public node id), it will also be hit. So at that point someone could de-anonymize the older offer by sending an invoice request for it to the node id given in the newer offer.

Hmm? Not sure I understand the scenario you're describing - are you saying if we issue two offers, one with a blinded path and one that publishes our node, someone can use the one with the blinded path and the one that publishes our node somehow to get different behavior?

Ah, no, I was saying they could determine that they came from the same issuer. Though, that is actually a different problem than what you are asking about and one we probably can't solve.

Sorry, think I was confused about your comment. Were you saying we should continue to send an InvoiceError with Bolt12SemanticError::InvalidMetadata for both verification paths?

I think so? Like, if we think it doesn't matter if we pass back an error then no need, but if we think we may hit those cases and we should pass back an error then we should ignore the BOLTs here.

Yeah, probably not useful to send an InvoiceError. The only time those should ever fail is if we are given an invoice request for an invalid offer or an invalid path id used. Older offers should still work.

TheBlueMatt · 2024-07-16T18:03:06Z

lightning/src/ln/channelmanager.rs

@@ -10682,8 +10682,14 @@ where
 				}
 			},
 			OffersMessage::InvoiceError(invoice_error) => {
+				let payment_hash = match context {
+					OffersContext::InboundPayment { payment_hash } => Some(payment_hash),


I'm really confused. We never actually build this context, so how could we be expecting to receive it?

Right, we will only start creating invoice reply paths #3163. See #3163 (comment).

I can leave these commits to a follow-up if you'd prefer. I'll have another PR that authenticates the path for outbound payments. But for inbound payments, it's mostly to improve logging.

Yea, lets leave this commit for there cause its very confusing here.

Dropped from this PR.

TheBlueMatt · 2024-07-16T18:12:46Z

lightning/src/offers/invoice.rs

-			InvoiceContents::ForRefund { refund, .. } => refund.derives_keys(),
-		}
+		signer::verify_payer_metadata(
+			metadata.as_ref(), key, iv_bytes, payer_id, tlv_stream, secp_ctx,


We need a pending release note that upgrades will break any pending Refunds or, in rare cases, pending BOLT 12 payments depending on their exact state, right?

Yup, good call. Will add after I finish addressing @shaavan's comments on updating the tests.

TheBlueMatt · 2024-07-17T13:54:00Z

Needs rebase, it seems.

To authenticate that an InvoiceRequest is for a valid Offer, include the nonce from the Offer::metadata in the Offer::paths. This can be used to prevent de-anonymization attacks where an attacker sends requests using self-constructed paths to nodes near the Offer::paths' introduction nodes.

When an InvoiceRequest is handled with an OfferContext, use the containing nonce to verify that it is for a valid Offer. Otherwise, fall back to using Offer::metadata, which also contains the nonce. The latter is useful for supporting offers without blinded paths or those created prior to including an OffersContext in their blinded paths.

When an Offer uses blinded paths, its metadata consists of a nonce used to derive its signing keys. Now that the blinded paths contain this nonce, elide the metadata as it is now redundant. This saves space and also makes it impossible to derive the signing keys if an invoice request is received with the incorrect nonce. The nonce shouldn't be revealed in this case either to prevent de-anonymization attacks.

When a Bolt12Invoice is handled with an OfferContext, use the containing payment_id to verify that it is for a pending outbound payment. Only invoices for refunds without any blinded paths can be verified without an OfferContext.

When an invoice or invoice request cannot be authenticated from an OffersContext, simply do not respond instead of sending an InvoiceError message. According to BOLT4, messages sent over a blinded path not intended for its use MUST be ignored.

When using InvoiceRequestBuilder::deriving_payer_id, the nonce generated needs to be the same one included in any reply path. This is because the nonce is used along with the invoice request TLVs to derive a payer id. While this data is also included in the payer_metadata, including it in the blinded path would allow reducing the amount of data needed there to just enough to provide entropy (i.e., 16 bytes). This is more important for Refund because it can be transmitted via a QR code. But using the same payer_metadata structure for both InvoiceRequest and Refund would be beneficial to avoid more code.

When using RefundBuilder::deriving_payer_id, the nonce generated needs to be the same one included in any RefundBuilder::paths. This is because the nonce is used along with the refund TLVs to derive a payer id and will soon be used to authenticate any invoices.

Invoices are authenticated by checking the payer metadata in the corresponding invoice request or refund. For all invoices requests and for refunds using blinded paths, this will be the encrypted payment id and a 128-bit nonce. Allows checking the unencrypted payment id and nonce explicitly instead of the payer metadata. This will be used by an upcoming change that includes the payment id and nonce in the invoice request's reply path and the refund's blinded paths instead of completely in the payer metadata, which mitigates de-anonymization attacks.

To authenticate that a Bolt12Invoice is for a valid InvoiceRequest or Refund, include the nonce from the payer_metadata in the InvoiceRequest reply path or Refund::paths, respectively. This can be used to prevent de-anonymization attacks where an attacker sends invoices using self-constructed paths to nodes near the blinded paths' introduction nodes.

When a Bolt12Invoice is handled with an OfferContext, use both the containing payment_id and nonce to verify that it is for a pending outbound payment. Previously, the nonce the payment_id were taken from the payer_metadata and the latter was compared against the payment_id in the OfferContext. The payer_metadata thus no longer needs to include either when a blinded path is used. However, some payer_metadata will still be needed as per the spec.

When authenticating that an invoice is for a valid invoice request, the payer metadata is needed. Some of this data will be removed in the next commit and instead be included in the message context of the request's reply path. Add this data to Event::InvoiceReceived so that asynchronous invoice handling can verify properly.

InvoiceRequest and Refund have payer_metadata which consists of an encrypted payment id and a nonce used to derive its signing keys and authenticate any corresponding invoices. Now that the blinded paths include this data in their OffersContext, remove the nonce as it is now redundant. Keep the encrypted payment id as some data is needed in the payer metadata according to the spec. This saves space and prevents de-anonymization attacks as along as the nonce isn't revealed.

jkczyz · 2024-07-22T16:39:29Z

Squashed and rebased.

TheBlueMatt

Two quick followups, but otherwise LGTM. I do find the metadata code to be quite a maze, I think in large part due to the metadata field being both "dumb bytes" on the wire and post-read as well as carrying state (in additional to the "dumb bytes") tracking the type of metadata during creation/signing.

TheBlueMatt · 2024-07-22T20:49:36Z

lightning/src/offers/offer.rs

+	}
+
+	/// Verifies that the offer metadata was produced from the offer in the TLV stream.
+	fn verify_using_metadata<T: secp256k1::Signing>(


I'd feel much better if the two verification methods used different IVs. I know it shouldn't matter cause the offer can't be changed, but I'd feel better about it.

TheBlueMatt · 2024-07-22T21:23:15Z

lightning/src/offers/invoice.rs

+	/// sent through.
+	pub fn verify_using_payer_data<T: secp256k1::Signing>(
+		&self, payment_id: PaymentId, nonce: Nonce, key: &ExpandedKey, secp_ctx: &Secp256k1<T>
+	) -> bool {


Verification functions really need to return a Result to get the warnings if the response is ignored. I know we haven't always been 100% on this but we should be going forward.

Follow-ups to #3139

jkczyz marked this pull request as draft June 20, 2024 17:05

jkczyz mentioned this pull request Jun 21, 2024

BOLT12 Offers Tracking Issue #1970

Open

60 tasks

TheBlueMatt mentioned this pull request Jun 28, 2024

Introduce MessageContext and use it to allow abandon failed payments #3085

Merged

jkczyz force-pushed the 2024-06-blinded-path-auth branch from cd9a904 to e0fcca0 Compare July 2, 2024 22:28

jkczyz commented Jul 2, 2024

View reviewed changes

jkczyz force-pushed the 2024-06-blinded-path-auth branch from e0fcca0 to ea192d7 Compare July 3, 2024 23:10

jkczyz force-pushed the 2024-06-blinded-path-auth branch 3 times, most recently from fdb819e to 5cfad02 Compare July 9, 2024 22:02

jkczyz marked this pull request as ready for review July 9, 2024 22:48

jkczyz requested review from TheBlueMatt and valentinewallace July 9, 2024 22:48

jkczyz mentioned this pull request Jul 10, 2024

Support paying static invoices #3140

Merged

TheBlueMatt mentioned this pull request Jul 11, 2024

Dont abandon payments based on the payment_id in an unauthenticated InvoiceError message (or any other unauthenticated msg) #3166

Closed

TheBlueMatt reviewed Jul 11, 2024

View reviewed changes

valentinewallace added this to the 0.0.124 milestone Jul 11, 2024

valentinewallace reviewed Jul 12, 2024

View reviewed changes

lightning/src/ln/inbound_payment.rs Outdated Show resolved Hide resolved

lightning/src/ln/peer_handler.rs Outdated Show resolved Hide resolved

lightning/src/ln/offers_tests.rs Outdated Show resolved Hide resolved

jkczyz force-pushed the 2024-06-blinded-path-auth branch from 5cfad02 to 46bee8c Compare July 12, 2024 23:45

jkczyz commented Jul 12, 2024

View reviewed changes

jkczyz force-pushed the 2024-06-blinded-path-auth branch 2 times, most recently from c61e16d to 9f7fd0d Compare July 15, 2024 23:59

shaavan reviewed Jul 16, 2024

View reviewed changes

lightning/src/ln/offers_tests.rs Show resolved Hide resolved

lightning/src/ln/offers_tests.rs Show resolved Hide resolved

TheBlueMatt reviewed Jul 16, 2024

View reviewed changes

jkczyz force-pushed the 2024-06-blinded-path-auth branch from 9f7fd0d to 97c567c Compare July 17, 2024 00:47

jkczyz force-pushed the 2024-06-blinded-path-auth branch from 97c567c to d751845 Compare July 17, 2024 18:04

jkczyz added 22 commits July 22, 2024 11:34

Wrap docs at 100 characters

7904e3c

Expand OffersContext::OutboundPayment docs

f546aad

Fix grammar

1ff8c8d

Fix OffersContext::Unknown docs

a5145e4

Rename InvoiceRequest::verify

9d46340

Add docs to Metadata::without_keys

f537abd

Authenticate Bolt12Invoice using OfferContext

c2a120e

When a Bolt12Invoice is handled with an OfferContext, use the containing payment_id to verify that it is for a pending outbound payment. Only invoices for refunds without any blinded paths can be verified without an OfferContext.

Add failure tests for offer message authentication

bdf3330

Correct docs

4ed37d8

Rename Bolt12Invoice::verify

718bc47

Add pending changelog for BOLT12 authentication

825bda0

jkczyz force-pushed the 2024-06-blinded-path-auth branch from 41ef097 to 825bda0 Compare July 22, 2024 16:39

valentinewallace approved these changes Jul 22, 2024

View reviewed changes

TheBlueMatt approved these changes Jul 22, 2024

View reviewed changes

TheBlueMatt merged commit b049a7d into lightningdevkit:main Jul 22, 2024
16 of 19 checks passed

jkczyz mentioned this pull request Jul 23, 2024

Follow-ups to #3139 #3202

Merged

shaavan mentioned this pull request Jul 26, 2024

Introduce Retry InvoiceRequest Flow #3010

Merged

TheBlueMatt added a commit that referenced this pull request Aug 5, 2024

Merge pull request #3202 from jkczyz/2024-07-blinded-path-auth-follow-up

85e5e6a

Follow-ups to #3139

	/// Context used by a [`BlindedPath`] within an [`Offer`] for sending an [`InvoiceRequest`].
	/// Context used by a [`BlindedPath`] within an [`Offer`] to be received with an [`InvoiceRequest`].

		@@ -667,9 +665,9 @@ impl Offer {

		#[cfg(async_payments)]
		pub(super) fn verify<T: secp256k1::Signing>(

		/// Context used by a [`BlindedPath`] for replying to a [`Bolt12Invoice`] with an
		/// [`InvoiceError`].

	/// Context used by a [`BlindedPath`] for replying to a [`Bolt12Invoice`] with an
	/// [`InvoiceError`].
	/// Context used by a [`BlindedPath`] as a reply path for a [`Bolt12Invoice`].

Authenticate use of offer blinded paths #3139

Authenticate use of offer blinded paths #3139

Conversation

jkczyz commented Jun 20, 2024 • edited Loading

jkczyz Jul 2, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

codecov-commenter commented Jul 3, 2024 • edited by codecov bot Loading

Codecov Report

TheBlueMatt left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

valentinewallace left a comment

Choose a reason for hiding this comment

jkczyz left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

shaavan left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

TheBlueMatt commented Jul 16, 2024

jkczyz commented Jul 16, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

TheBlueMatt commented Jul 17, 2024

jkczyz commented Jul 22, 2024

TheBlueMatt left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jkczyz commented Jun 20, 2024 •

edited

Loading

jkczyz Jul 2, 2024 •

edited

Loading

codecov-commenter commented Jul 3, 2024 •

edited by codecov bot

Loading