JWT authorization header based on LNURL Auth #26

wvanlint · 2024-02-09T20:29:40Z

Introduces a HeaderProvider trait that will provide headers for each VSS call.
Implements a specific HeaderProvider that will provide a JWT authorization header based on LNURL Auth.
- LUD-05 will be used for key derivation instead of LUD-13.
- A token field will be expected in a successful LUD-04 verification response, containing the JWT token.
- JWT tokens will be cached according to their expiry.

tnull

Did a really high-level pass, mostly questions about the design choices and introduced dependencies.

tnull · 2024-02-12T14:58:09Z

Cargo.toml

+async-trait = "0.1.77"
+futures = "0.3.30"
+url = "2.5.0"
+hmac = "0.12.1"


Let's use bitcoin::hashes crate here rather than the extra hmac/sha2 dependencies.

tnull · 2024-02-12T15:04:50Z

Cargo.lock

As this is a library, checking in Cargo.lock should be avoided.

Ah accidentally added this, added to .gitignore.

tnull · 2024-02-12T15:10:20Z

Cargo.toml


 [target.'cfg(genproto)'.build-dependencies]
 prost-build = { version = "0.11.3" }
 reqwest =  { version = "0.11.13", features = ["blocking"] }

 [dev-dependencies]
+axum = { version = "0.7.4", features = ["ws"] }
+mockall = "0.12.1"


Is there a reason we need yet another mocking library? Why can't we use the mockito dependency we already have available?

The mockito library is a specific mocking library for HTTP calls. The mockall library allows more general mocking of Rust traits.

Removed this as Websockets were removed in favor of simple HTTP calls by depending on a token field in the LNURL Auth response.

tnull · 2024-02-12T15:19:02Z

Cargo.toml

+tungstenite = "0.21.0"
+async-trait = "0.1.77"
+futures = "0.3.30"
+url = "2.5.0"


I'm not convinced that we need to introduce a dependency just to check whether a URL is invalid.

We also use this library to handle parsing the domain name, parsing the query parameters, and adding additional sig and key query parameters. We can implement this functionality, but it would be nice to use the library here.

We have tried to minimize dependencies in this crate,
it might make sense to feature-gate these additional deps to "lnurl-auth" ?

Put the LNURL Auth JWT implementation and relevant dependencies under a feature.

tnull · 2024-02-12T15:22:44Z

src/headers/mod.rs

+#[async_trait]
+pub trait HeaderProvider {
+	/// Error type when returning headers.
+	type Error: std::error::Error;


We should probably define a clear error type here rather than using type Error: std::error::Error;.

What do you have in mind here? I added the associated type with a trait bound because each implementation might run into different kinds of errors. Returning fixed headers is infallible, but LNURL Auth might run into protocol-specific errors.

Hm, yeah, I guess. I'd generally still prefer to clearly define the possible error cases as this kind of pattern would often result in using dyn Error which is a mess to reliably/predictably handle by the user (and also comes with a bunch of overhead, such as heap allocations).

Simplified these into some basic error cases, but let me know if using String or std::io::Error would be better.

tnull · 2024-02-12T15:26:12Z

Cargo.toml

@@ -16,11 +16,25 @@ prost = "0.11.6"
 reqwest = { version = "0.11.13", features = ["rustls-tls"] }
 tokio = { version = "1", default-features = false, features = ["time"] }
 rand = "0.8.5"
+bitcoin = "0.31.1"
+tokio-tungstenite = "0.21.0"
+tungstenite = "0.21.0"


Could you expand on why this needs to use websockets rather than, e.g., just HTTPS requests?

AFAIU, the LNURL Auth spec defines a flow that "side-loads" authentication: a call providing a signature will be made by the client to the server, but the server can only return success/failure: https://github.com/lnurl/luds/blob/luds/04.md#wallet-to-service-interaction-flow. The server is responsible for correlating that call to the original challenge and continuing the user's intent there. In this case, the Websocket connection is used to maintain the context between providing the challenge and issuing the JWT token and allows the server to push the JWT token without the client having to poll.

Discussed offline. Although leveraging Websockets can support multiple devices e.g. with a QR scanning flow and it is used in Mutiny wallet, it is not relevant to our use case. We confirmed a token field can be added to the LNURL Auth response, and the simplification is definitely worthwhile. Changed this to only use HTTP(S) requests and returning a token field.

tnull · 2024-02-13T12:56:48Z

Cargo.toml

@@ -16,11 +16,23 @@ prost = "0.11.6"
 reqwest = { version = "0.11.13", features = ["rustls-tls"] }
 tokio = { version = "1", default-features = false, features = ["time"] }
 rand = "0.8.5"
+bitcoin = "0.31.1"


LDK/LDK Node are currently on bitcoin v0.30.2. While we'll upgrade soon, it might be best to keep it compatible here for the time being.

Changed this to use 0.30.2.

tnull

Thanks for removing the websocket requirement, this scheme is much simpler!

Generally LGTM, just a few questions and comments.

tnull · 2024-03-20T11:37:35Z

src/headers/mod.rs

+
+/// Defines a trait around how headers are provided for each VSS request.
+#[async_trait]
+pub trait HeaderProvider {


Usually I'm no fan of using variable prefixes. However, in this case we'll want to expose this trait in other interfaces, e.g., in LDK Node (if we ever wanted to expose the trait there), where HeaderProvider would suggest that it's a general interface. Unfortunately, trait aliases are not supported by Rust yet, so we can't expose the trait under a different name downstream. Could we therefore rename it (and the corresponding error type) to VssHeaderProvider?

Added prefixes.

tnull · 2024-03-20T11:38:54Z

src/headers/mod.rs

+pub trait HeaderProvider {
+	/// Returns the HTTP headers to be used for a VSS request.
+	/// This method is called on each request, and should likely perform some form of caching.
+	async fn get_headers(&self) -> Result<HeaderMap, HeaderProviderError>;


Can we have this return a core::collections::HashMap rather than the reqwest-specific HeaderMap?

I think headers can be a multimap, changed this to Vec<(String, String)>.

Ah, I usually would prefer Vec<(String, String)>, too, however, in this case I'm afraid that UniFFI doesn't support tuples (see https://mozilla.github.io/uniffi-rs/udl/builtin_types.html), so using HashMap would be appreciated in this instance.

tnull · 2024-03-20T11:56:51Z

src/headers/lnurl_auth_jwt.rs

+	url: String,
+	headers: HeaderMap,
+	client: reqwest::Client,
+	jwt_token: Mutex<Option<String>>,


Should we introduce a JwtToken type that holds both the token string and the expiry? This would avoid the possibility that both fields are updated independently. We could also hold an RwLock<JwtToken>, which would avoid us having to lock the Mutex just to check the expiry.

tnull · 2024-03-20T11:59:37Z

src/headers/lnurl_auth_jwt.rs

+	engine: Secp256k1<All>,
+	parent_key: ExtendedPrivKey,
+	url: String,
+	headers: HeaderMap,


Should this field be called default_headers to disambiguate it from the headers actually sent?

tnull · 2024-03-20T12:15:16Z

src/headers/lnurl_auth_jwt.rs

+	let children: Vec<ChildNumber> = (0..4)
+		.map(|i| u32::from_be_bytes(result[(i * 4)..((i + 1) * 4)].try_into().unwrap()))
+		.map(ChildNumber::from)
+		.collect::<Vec<_>>();


We should be able to avoid this allocation by using DerivationPath::from_iter.

tnull · 2024-03-20T12:23:18Z

src/headers/lnurl_auth_jwt.rs

+	Ok(lnurl.to_string())
+}
+
+#[derive(Deserialize)]


nit: Could always derive Debug, possibly also Clone, as they might come handy eventually.

tnull · 2024-03-20T12:24:50Z

src/headers/lnurl_auth_jwt.rs

+
+fn parse_expiry(jwt_token: &str) -> Result<Option<u64>, HeaderProviderError> {
+	let parts: Vec<&str> = jwt_token.split('.').collect();
+	let invalid = || HeaderProviderError::InvalidData(format!("invalid JWT token: {}", jwt_token));


Same question regarding string sanitization as above.

Changed to using UntrustedString.

tnull · 2024-03-20T12:29:12Z

src/headers/mod.rs

+#[derive(Debug)]
+pub enum HeaderProviderError {
+	/// Invalid data was encountered.
+	InvalidData(String),


Could we make these variants InvalidData { error: String }, etc?

(Unfortunately, the UniFFI bindings generator doesn't support tuple structs generally, so it would help us to expose the trait in LDK Node, if we'd ever want to go this way)

tnull · 2024-03-20T12:32:33Z

src/lib.rs

@@ -25,3 +25,6 @@ pub mod util;

 // Encryption-Decryption related crate-only helpers.
 pub(crate) mod crypto;
+
+/// A collection of (authentication-related) header providers.
+pub mod headers;


Hmm, should this module be called auth or header_auth rather than just headers?

There might be other use cases for headers, so I left it open ended. Can remove or reword the reference to authentication though.

But for other use cases we might want to introduce another module, no? What would be a non-auth use case that would reuse exactly the types introduced here?

I think the VssHeaderProvider trait and FixedHeaders type are both generic, they can be used to set various HTTP headers, maybe User-Agent for example?

Yeah, possibly, although I doubt this would ever happen without any additional refactoring becoming necessary. In any case, the module naming isn't that important, so feel free to leave as is if you prefer.

tnull · 2024-03-20T12:34:53Z

src/headers/lnurl_auth_jwt.rs

+	// Parse k1 parameter to sign.
+	let invalid_lnurl = || HeaderProviderError::InvalidData(format!("invalid lnurl: {}", lnurl_str));
+	let mut lnurl = Url::parse(lnurl_str).map_err(|_| invalid_lnurl())?;
+	let domain = lnurl.domain().ok_or(invalid_lnurl())?;


Want to note that this means that we're only supporting LNURL servers with FQDNs, i.e., no IP-only webservers. Fine I guess and also inline with LUD-05, but previously I wasn't aware of this limitation.

Yes, exactly, the key derivation and signature will depend on it, likely to avoid certain attacks. I wonder if we should enforce HTTPS as well.

@G8XSU @tnull Were there remaining questions here from the LDK sync?

From my understanding, the domain name is used for isolation so that a signature for a LNURL Auth-based todo app for example cannot be used to access the LNURL Auth-based VSS server. HTTPS also protects against man-in-the-middle attacks.

Not from my side, I think requiring a FQDN is 'okay' even though it restricts self-hosting to a degree.

tnull

Cool, thanks for addressing the feedback!

Basically LGTM from my side, mod the outstanding comments/nits (use HashMap in trait, improve UntrustedString, possibly rename module).

Probably @G8XSU wants to have a look also.

tnull · 2024-03-21T07:04:58Z

src/headers/lnurl_auth_jwt.rs

+				SystemTime::now().duration_since(SystemTime::UNIX_EPOCH).unwrap().as_secs() + EXPIRY_BUFFER_SECS
+					> expiry
+			})
+			.unwrap_or(false)


Should this be true? If we don't have a token/expiry set, wouldn't it mean we'd consider it expired?

If we have a token, it's possible it does not have an expiry (not a good idea, but that's up to the JWT signer). However, if the token is not present, we would need to fetch it. Moved the is_expired method to the JWT token to make these cases clearer.

Ah, alright.

tnull · 2024-03-21T07:06:58Z

src/headers/lnurl_auth_jwt.rs

+		if !self.is_expired() && !force_refresh {
+			let jwt_token = self.jwt_token.read().unwrap();
+			if let Some(jwt_token) = jwt_token.deref() {
+				return Ok(jwt_token.token_str.clone());


nit: Could make this a simple if/else rather than using an early-return pattern.

tnull

LGTM from my side, I think.

wvanlint · 2024-04-02T18:05:06Z

@G8XSU Could you write down what you mentioned during the LDK dev sync for anything that needs to be addressed?

G8XSU · 2024-04-22T20:45:42Z

src/headers/mod.rs

+pub trait VssHeaderProvider {
+	/// Returns the HTTP headers to be used for a VSS request.
+	/// This method is called on each request, and should likely perform some form of caching.
+	async fn get_headers(&self) -> Result<HashMap<String, String>, VssHeaderProviderError>;


Imo, we should also provide request as input to this trait.
This can enable adding headers for request-signing etc.

I was adding this, but the trait does need to remain object-safe since we use dyn VssHeaderProvider, so we can't use generics here to provide the structured request. The binary serialization of the body can be provided though specifically for request signing. Shall I add that?

Yes i think we can add serialized request, that should be enough for request signing.

src/headers/mod.rs

G8XSU · 2024-04-22T20:51:39Z

src/headers/mod.rs

+
+/// Errors around providing headers for each VSS request.
+#[derive(Debug)]
+pub enum VssHeaderProviderError {


Was planning to re-use the existing defined VssError here.

1 additional variant needs to be added i.e. VssError::AuthError (let me make this proto change)
apart from that we should re-use InvalidRequestError and InternalError.

Sounds good! This will be a change in https://github.com/lightningdevkit/vss-server/blob/main/app/src/main/proto/vss.proto right? Would you like to make the change or shall I open a PR?

I can do that.

Using the AuthError and InternalError now.

G8XSU · 2024-04-22T21:07:57Z

src/headers/lnurl_auth_jwt.rs

+impl LnurlAuthJwt {
+	/// Creates a new JWT provider based on LNURL Auth.
+	///
+	/// The LNURL Auth keys are derived based on the wallet seed according to LUD-05.


is this mandatory?
Are we good if we derive the key from vss-seed/vss-secret?
This is because i don't expect this headerProvider to have access to wallet seed.

Yes, I think this is useful for portability following the LNURL Auth spec. I believe we can have access similar to here: https://github.com/lightningdevkit/ldk-node/blob/640a1fdb7833ad9c74ede0926f990d85ac1b3bca/src/builder.rs#L342 ?

We discussed this a little bit on Slack (https://cash.slack.com/archives/C03Q9S7K99R/p1707986857336199?thread_ts=1706544261.279069&cid=C03Q9S7K99R) whether to go with LUD-05 or LUD-13 (based on a node signature), but LUD-05 seemed more straight-forward.

Ideally, this auth provider shouldn't have access to wallet seed, we can derive the parent key for auth and provide to auth-provider.

now that parent key can either be derived from wallet seed directly or from vss-secret.

i preferred the later because both data-encryption and request-signing keys would be derived from vss-secret but i see your point about benefit of deriving from wallet seed to follow spec. (but i thought the spec is just "derive a key by some path")

I am ok with both the options here depending on if ldk-node plans on using lnurl auth at other places.

Would we provide a helper for the parent key derivation to avoid user error? If so, the exposure might be similar? Overall, I felt like giving the wallet seed directly is less error prone and should be safe if the repo is well-reviewed.

It isn't just about this authorizer, imo this pattern of passing around wallet seed to code(potentially implemented by non-ldk-node) should be avoided, even if we maintain this repo directly.

we can just send the hardened derived parent key.

@tnull , any thoughts around seed derivation here?

Hm, I agree that handing around the wallet seed is a bit unfortunate. Given that we already deviate from the LNURL spec (and hence basically run a custom protocol), I assume it's fine to use a (seed derived from a) hardened child key as input here, preferably the VSS secret or even one derived from that? At least I currently don't see why it would make a difference?

Is the deviation you mentioned the return of a JWT token from the LNURL Auth server?

The only reason to use the specification would be to get to a point where Lightning wallets can be portable between implementations with just a wallet seed, and have a well-defined derivation from the wallet seed to the linking key to access the protected data on the VSS server side. That might be out of scope right now though, and things will work either way for a single implementation. It just might be difficult to migrate existing VSS data to a different linking key, other things like using JWT are easier to change I think.

Is the deviation you mentioned the return of a JWT token from the LNURL Auth server?

Yes. And that generally we're implementing a protocol that is not specified anywhere but in code. This is fine, but it means we're currently rolling something pretty custom and if interoperability with other protocols should be ascertained in the future, I expect to be further changes necessary anyways?

The only reason to use the specification would be to get to a point where Lightning wallets can be portable between implementations with just a wallet seed, and have a well-defined derivation from the wallet seed to the linking key to access the protected data on the VSS server side. That might be out of scope right now though, and things will work either way for a single implementation. It just > might be difficult to migrate existing VSS data to a different linking key, other things like using JWT are easier to > change I think.

Right, but it's ambiguous as it is: I think we expect the seed to be the seed of the onchain wallet, but we also have the seed for the Lightning wallet, which may or may not be derived from the former (usually is, e.g., in LDK Node). Some nodes might not even have an onchain wallet readily available, so they'd need to use something different. All that is to say: if we want to define a standard, we should do exactly that: clearly define which derivation path is expected (e.g., '877' for 'VSS'?).

We don't expect ldk-node specific storage to be interoperable with other wallets.
This only needs to be interoperable within ldk-node, and for that deriving from any path of master should be fine.

G8XSU · 2024-04-22T21:16:38Z

src/headers/lnurl_auth_jwt.rs

+	url: String,
+	default_headers: HashMap<String, String>,
+	client: reqwest::Client,
+	jwt_token: RwLock<Option<JwtToken>>,


could be renamed to "cached_jwt_token"

src/headers/lnurl_auth_jwt.rs

G8XSU · 2024-04-23T23:03:08Z

src/headers/lnurl_auth_jwt.rs

+		.derive_priv(engine, &linking_key_path)
+		.map_err(VssHeaderProviderError::from)?
+		.to_priv();
+	let public_key = private_key.public_key(engine);


should we rename public_key -> linking_key and private_key ->linking_key_xpriv?

G8XSU · 2024-04-23T23:20:21Z

src/headers/lnurl_auth_jwt.rs

+	}
+	let _ = URL_SAFE_NO_PAD.decode(parts[0]).map_err(|_| invalid())?;
+	let bytes = URL_SAFE_NO_PAD.decode(parts[1]).map_err(|_| invalid())?;
+	let _ = URL_SAFE_NO_PAD.decode(parts[2]).map_err(|_| invalid())?;


do we need to verify something here? will we get jwt signature ?

Hmm, we can do more extensive validation (which might require additional dependencies), but I think it's okay to consider the JWT token as opaque as possible as validation will always occur at the consuming service. We also can't always verify the signature, e.g. the JWT token is signed by a symmetric key known by a joint LNURL Auth / VSS provider.

iiuc, we expect claim.subject==linkingKey, maybe we could just verify that in claim?

G8XSU · 2024-04-23T23:25:10Z

Cargo.toml

+tungstenite = "0.21.0"
+async-trait = "0.1.77"
+futures = "0.3.30"
+url = "2.5.0"


We have tried to minimize dependencies in this crate,
it might make sense to feature-gate these additional deps to "lnurl-auth" ?

G8XSU · 2024-05-01T21:31:37Z

src/headers/lnurl_auth_jwt.rs

+
+	// Sign k1 parameter with linking private key.
+	let hashing_private_key = hashing_key(engine, parent_key)?;
+	let linking_key_path = linking_key_path(&hashing_private_key, domain)?;


How does hosted service provider map/link node's identity with linking_key for authorization purpose ?
will we expose some get method in ldk-node interface?

As backend would be using linking-key as user-identity, we have established authentication, but how does service provide correlate with their actual paid-user etc?

We're currently aiming to keep authentication and authorization separate, using an API key is sufficient for our authorization purposes for now. We discussed this briefly offline here https://square.enterprise.slack.com/archives/C03Q9S7K99R/p1710885872464219?thread_ts=1706544261.279069&channel=C03Q9S7K99R&message_ts=1710885872.464219

We can verify a node id signature in the future or do something more complex like https://github.com/ZmnSCPxj-jr/lsptoken. The latter aims to reduce the conflict of interest when the VSS provider is also the LSP of the user. The LSP token implementation could prove that a VSS request is coming from a LSP user without the LSP being able to determine exactly which counterparty it is.

I understand for that usecase it is sufficient to have fixed header based api-key authorization,
I wanted to understand if other users might need access to linkingKey for user-identification for authorization purpose,
if yes, then ldk-node will need access to it and somehow might need to expose it in future?

(whether to expose linkingKey or not can be tackled separately and doesn't block this pr)

cc: @tnull

Yeah, I agree we can just leave it for now. If we ever find a use case that would want to reuse the linking key, we can reconsider if it's worth it. Possibly at that point it might even make sense to run a separate auth round, at least if there is no hard requirement to reuse exactly the same linking key.

wvanlint · 2024-05-15T21:55:23Z

@G8XSU Split off the header provider trait in #31 as requested.

G8XSU · 2024-05-15T17:09:50Z

src/client.rs

+			.get_headers()
+			.await
+			.map_err(|e| VssError::InternalError(e.to_string()))?;
+		let headermap = get_headermap(&headers).map_err(VssError::InternalError)?;


imo, if creating a map from provided headers failed, it could be InvalidRequestError

G8XSU · 2024-05-15T17:11:01Z

src/headers/lnurl_auth_jwt.rs

+// The key of the LNURL key query parameter.
+const KEY_QUERY_PARAM: &str = "key";
+// The authorization header name.
+const AUTHORIZATION: &str = "authorization";


'A' should be capital for 'Authorization' header

G8XSU · 2024-05-15T17:14:19Z

src/headers/lnurl_auth_jwt.rs

+impl LnurlAuthJwt {
+	/// Creates a new JWT provider based on LNURL Auth.
+	///
+	/// The LNURL Auth keys are derived based on the wallet seed according to LUD-05.


It isn't just about this authorizer, imo this pattern of passing around wallet seed to code(potentially implemented by non-ldk-node) should be avoided, even if we maintain this repo directly.

we can just send the hardened derived parent key.

@tnull , any thoughts around seed derivation here?

G8XSU · 2024-05-15T17:48:04Z

src/headers/lnurl_auth_jwt.rs

+	}
+	let _ = URL_SAFE_NO_PAD.decode(parts[0]).map_err(|_| invalid())?;
+	let bytes = URL_SAFE_NO_PAD.decode(parts[1]).map_err(|_| invalid())?;
+	let _ = URL_SAFE_NO_PAD.decode(parts[2]).map_err(|_| invalid())?;


iiuc, we expect claim.subject==linkingKey, maybe we could just verify that in claim?

G8XSU · 2024-05-15T17:52:07Z

src/headers/lnurl_auth_jwt.rs

+
+	// Sign k1 parameter with linking private key.
+	let hashing_private_key = hashing_key(engine, parent_key)?;
+	let linking_key_path = linking_key_path(&hashing_private_key, domain)?;


I understand for that usecase it is sufficient to have fixed header based api-key authorization,
I wanted to understand if other users might need access to linkingKey for user-identification for authorization purpose,
if yes, then ldk-node will need access to it and somehow might need to expose it in future?

(whether to expose linkingKey or not can be tackled separately and doesn't block this pr)

cc: @tnull

wvanlint force-pushed the lnurl_auth branch from 5570c77 to b79d1e7 Compare February 9, 2024 20:50

tnull reviewed Feb 12, 2024

View reviewed changes

tnull reviewed Feb 13, 2024

View reviewed changes

wvanlint force-pushed the lnurl_auth branch 2 times, most recently from 4a26989 to 95cce65 Compare March 19, 2024 18:30

wvanlint marked this pull request as ready for review March 19, 2024 21:26

wvanlint force-pushed the lnurl_auth branch 2 times, most recently from 3b83e76 to 35a9bc9 Compare March 19, 2024 22:03

tnull reviewed Mar 20, 2024

View reviewed changes

wvanlint force-pushed the lnurl_auth branch 3 times, most recently from 865e15a to 438a41b Compare March 21, 2024 00:12

wvanlint requested a review from tnull March 21, 2024 00:18

tnull reviewed Mar 21, 2024

View reviewed changes

wvanlint requested a review from tnull March 22, 2024 21:35

tnull reviewed Mar 25, 2024

View reviewed changes

G8XSU reviewed Apr 23, 2024

View reviewed changes

wvanlint requested a review from G8XSU April 25, 2024 23:06

G8XSU reviewed May 1, 2024

View reviewed changes

wvanlint added 10 commits May 13, 2024 09:53

JWT authorization header based on LNURL Auth

49c100b

Comments

9779c00

Use JwtToken::is_expired without early return

5780a23

Use HashMap for headers

9099441

Use escape_debug

8bacaed

Describe headers module generally

2096e35

cargo fmt

157c79d

Rename variables

3d24916

Use feature for LNURL Auth JWT headers

bf1c8d0

Reuse VssError

23eddd6

wvanlint force-pushed the lnurl_auth branch from ddb2795 to 23eddd6 Compare May 14, 2024 18:23

wvanlint requested a review from G8XSU May 14, 2024 18:28

Include request in get_headers

e93c4bc

wvanlint mentioned this pull request May 15, 2024

Introduce header provider trait #31

Open

G8XSU reviewed May 15, 2024

View reviewed changes

JWT authorization header based on LNURL Auth #26

Are you sure you want to change the base?

JWT authorization header based on LNURL Auth #26

Conversation

wvanlint commented Feb 9, 2024 • edited

tnull 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

tnull Feb 12, 2024 • edited

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

tnull 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

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

Choose a reason for hiding this comment

wvanlint Apr 2, 2024 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tnull left a comment • edited

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

tnull left a comment

Choose a reason for hiding this comment

wvanlint commented Apr 2, 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

G8XSU May 1, 2024 • edited

Choose a reason for hiding this comment

wvanlint commented Feb 9, 2024 •

edited

tnull Feb 12, 2024 •

edited

wvanlint Apr 2, 2024 •

edited

tnull left a comment •

edited

G8XSU May 1, 2024 •

edited