Add standard BNF for 256-bit primary key. #26

michaelcfanning · 2025-01-10T17:19:20Z

This change adds a spare markdown standard BNF specification for CASK keys.

The markdown additionally describes how to dereference/decompose an encoded form of a key or its bytewise (decoded) form to obtain constituent elements.

This change also adds a naive test helper that breaks down a 3-byte sequence into 4 easily obtained 6-bit values (rendered as bytes). It is not clear this code should be productized. This code is tested by a brute force unit tests that takes over 30 seconds on .NET framework to run (will be updated tomorrow to resolve this issue).

KalleOlaviNiemitalo · 2025-01-11T05:56:07Z

docs/PrimaryKey.md

+|-|-|-|-|-|
+|key[0] - key[31]|0 - 256|0x0 - 0xFF|00000000b - 11111111b|256 bits of random data produced by a cryptographically secure RNG|
+|key[32]|0d|0xFF|00000000b| A reserved byte to enforce 3-byte alignment.
+|[optional 3-bye sequences]|0 - 256|0x0 - 0xFF|00000000b - 11111111b|Provider-defined data of arbitrary form.


byte

0 - ~~256~~255 #Resolved

docs/PrimaryKey.md

KalleOlaviNiemitalo · 2025-01-11T06:03:08Z

docs/PrimaryKey.md

+<key-type> ::= <256-bit-key> | 
+
+<256-bit-key> ::= 'A' | <256-bit-hash> | <384-bit-hash>


Should <256-bit-hash> and <384-bit-hash> be alternatives in the <key-type> definition rather than in <256-bit-key>? #Resolved

Oops, yes, thanks.

Why does hash feature in the definition of primary keys?

Oops, yes, missed this, the hash stuff would only be relevant in an uber BNF. And maybe we should just have that? I think so. The only distinction between the key scenario and HMAC is that for the HMAC we have 12 bytes of c3id that immediately follow the randomized data. That's it. If we split the definitions, we'll have lots of duplication and have to make trivial fixes in two places, always a recipe for disaster.

docs/PrimaryKey.md

KalleOlaviNiemitalo · 2025-01-11T06:16:24Z

docs/PrimaryKey.md

+|key[32]|0d|0xFF|00000000b| A reserved byte to enforce 3-byte alignment.
+|[optional 3-bye sequences]|0 - 256|0x0 - 0xFF|00000000b - 11111111b|Provider-defined data of arbitrary form.
+|key[keyLength - 6]|0|0xFF|00000000b - 11111100b| (KeyKind)key[keyLength - 6] >> 2 (leading 6 bits comprises kind enum + two bits of version number). Currently, [keyLength - 6] & 0xFC == 0 (as these bits are undefined in the version data)
+|key[key.Length - 5]|0|0xFF|00000000b - 11110000b| (CaskVersion)([key.Length - 6] & 0xFC << 4) & key[key.Length - 5] >> 4) (leading 4 bits comprise final 4 bits of version + 4 bits of zero padding).


Numbers in different bases don't match.

key[key.Length - 6] & 0xFC << 4 2

Choose either keyLength or key.Length, and use it consistently. #Resolved

KalleOlaviNiemitalo · 2025-01-11T06:24:57Z

docs/PrimaryKey.md

+|[optional 3-bye sequences]|0 - 256|0x0 - 0xFF|00000000b - 11111111b|Provider-defined data of arbitrary form.
+|key[keyLength - 6]|0|0xFF|00000000b - 11111100b| (KeyKind)key[keyLength - 6] >> 2 (leading 6 bits comprises kind enum + two bits of version number). Currently, [keyLength - 6] & 0xFC == 0 (as these bits are undefined in the version data)
+|key[key.Length - 5]|0|0xFF|00000000b - 11110000b| (CaskVersion)([key.Length - 6] & 0xFC << 4) & key[key.Length - 5] >> 4) (leading 4 bits comprise final 4 bits of version + 4 bits of zero padding).
+|key[keyLength - 4] - key[keyLength - 1]|0 - 256|0x0 - 0xFF|00000000b - 11111111b|CRC32(key[0] - key[key.Length - 5])


255 again.

Using - for subtraction and for ranges is confusing. Consider ellipsis … for ranges. #Resolved

Good catch and a good note re: ellipses. Thanks.

nguerrera · 2025-01-13T17:19:21Z

docs/PrimaryKey.md

+
+<payload-data> ::= <random-data> <reserved> [<optional-fields>] <cask-signature> <provider-id> <timestamp> <key-type> <version>
+
+<random-data> ::= 42 * <base64url> <base64-two-zeros-suffix>; The total random data comprises 256 bits encoded as 42


nit: space before comment. #Resolved

yes good eye

nguerrera · 2025-01-13T17:19:31Z

docs/PrimaryKey.md

+<payload-data> ::= <random-data> <reserved> [<optional-fields>] <cask-signature> <provider-id> <timestamp> <key-type> <version>
+
+<random-data> ::= 42 * <base64url> <base64-two-zeros-suffix>; The total random data comprises 256 bits encoded as 42
+                                                                 ; characters x 6 bit bits of random data = 252 bits and


nit: line up semicolons. #Resolved

nguerrera · 2025-01-13T17:19:58Z

docs/PrimaryKey.md

+<optional-fields> ::= { <optional-field> } ; Zero or more 4-character (24 bit) sequences of optional data.
+
+<optional-field> ::= 4 * <base64url> ; Each optional field is 4 characters (24 bits). This keeps
+                                          ; data cleanly aligned along 3-byte/4-encoded character boundaries


nit: line up semicolons. #Resolved

nguerrera · 2025-01-13T17:23:31Z

docs/PrimaryKey.md

+<key-type> ::= <256-bit-key> | 
+
+<256-bit-key> ::= 'A' | <256-bit-hash> | <384-bit-hash>


Why does hash feature in the definition of primary keys?

nguerrera · 2025-01-13T17:37:52Z

src/Cask/KeyKind.cs

+    /// Specifies a CASK hashed signature that incorporates a Keyed Hash
+    /// Message Authenticode of a derivation input generated by SHA-256
+    /// (HMAC-SHA-256) along with other CASK data such as the generated
+    /// C3ID of the CASK key used to initialize the HMAC instance.


Avoid referring to HMAC 'instance'. I think this is an implementation detail of legacy .NET crypto API. #Resolved

Deleted this text in preference of your concise suggestion.

nguerrera · 2025-01-13T17:38:56Z

src/Cask/ThreeByteSequence.cs

+        Bytes = bytes.ToArray();
+    }
+
+    public byte[] Bytes { get; }


The backing storage here could be int so that the data is inlined into the struct and this bit twiddling can be done without heap allocation. #Pending

Yes, this had occurred to me. The int conversion is pesky since the byte-wise ordering (if the value is manipulated and needs to be reflected again as bytes) differs according to endianness. But with this as they are here, the data is immutable.

I took this initial approach as well because I want to see just how hard it is to dig around in the bytes if you are a key producer who is trying to leverage the readability of the encoded key (which is a primary value we're encouraging).

nguerrera · 2025-01-13T17:41:17Z

src/Cask/ThreeByteSequence.cs

+
+    public byte[] Bytes { get; }
+
+    public string Encoded => Base64Url.EncodeToString(Bytes);


Avoid properties that allocate on every call. I suggest string Encode() method. The core API shouldn't use this and only allocate a single, complete key/hash string at the very end. If it's not a property, it will stick out more as an expense that can be avoided. #Pending

Let's talk about this one some more, want to get your thoughts. For now, I just made us accept the cost of generating this on struct creation.

nguerrera · 2025-01-13T17:44:03Z

src/Cask/KeyKind.cs

+    /// </summary>
+    OneZeroZero,
+
+    Reserved = 0xfe,


Reserved should usually be avoided in enums. Is this API meant to stay internal?

We might consider putting these masks in separate constants if the enums will be made public. #Pending

yes, next PR>

nguerrera · 2025-01-13T17:45:52Z

docs/PrimaryKey.md

+|Byte Range|Decimal|Hex|Binary|Description|
+|-|-|-|-|-|
+|key[0] - key[31]|0 - 256|0x0 - 0xFF|00000000b - 11111111b|256 bits of random data produced by a cryptographically secure RNG|
+|key[32]|0d|0xFF|00000000b| A reserved byte to enforce 3-byte alignment.


We had said we'd fill the padding byte with random, I think, on our last call. I am just curious, did you change your mind? #Pending

Let's talk, relates to a necessary conversation around how to specify optional bytes. So, I was thinking, perhaps we allow for a single API that specifies your optional arguments. This data would be expressed as bytes. If you passed a single byte, and we had a free byte at the end of your random data, we'd use it. If you passed two bytes, and there were two free bytes of padding at the end of the random component (as there are for 16 and 64 byte allocations), we'd stuff your data there. In cases where the length of your optional data did not permit stuffing it in padding, and in cases where the user simply requested at least 3 bytes, we'd allocate a full 3-byte optional chunk. Any padding that might exist at the end of randomized data region for these cases could be zeroed out or could contain additional entropy.

Just thinking aloud. This is all contrary to our current API which requires specifying the optional data a string, which has advantages (in that it emphasizes we are looking for the encoded interpretability of this data). Following that model, if users provided a single character, and we had a single padding byte, we'd use that space. If the user provided a 2-char value and we had at least two bytes padding, we'd take that slot. If a user provided 3-chars, we'd pad this data with a leading 'A' and use a 3-byte sequence. For 4-byte char, a standard 3-byte sequence.

nguerrera · 2025-01-13T17:47:32Z

docs/PrimaryKey.md

+
+<cask-signature> ::= 'JQQJ' ; Fixed signature identifying the CASK key
+
+<provider-id> ::= 4 * <base64url> ; Provider identifier (24 bits)


This is called provider providerSignature in the API, should we change that to providerId or this to provider-signature? #ByDesign

what do you think? one reminder as we declare a formal naming discussion, this data is likely to be decomposed into two smaller components, a reserved company id and a per-company provider id. MS would likely reserve MS and AZ and require all these identifiers to be prefixed with this company reserved component. this is why i switched to id mentally but honestly that leap was a very tenuous one.

Yes, id is better.

nguerrera · 2025-01-13T18:38:01Z

docs/PrimaryKey.md

+|Byte Range|Decimal|Hex|Binary|Description|
+|-|-|-|-|-|
+|decodedKey[0] - key[31]|0..255|0x0..0xFF|00000000b..11111111b|256 bits of random data produced by a cryptographically secure RNG|
+|decodedKey[32]|0|0xFF|00000000b| A reserved byte to enforce 3-byte alignment. This data can be repurposed by providers (particularly the final base64 encoded character).


I'd prefer not to have "this data can be repurposed" in the spec.

#Resolved

let's talk about this tomorrow. we have this spare data here which allows a provider to inject a sub-key kind or some other data, possible to encode 64 values. i have observed in other applications of this technique that it is very common that this is all that a provider needs of optional data. if we give them this free space, they don't need to commit to a full 3-byte optional sequence.

note that we can play the same trick with a 16 byte or 64-byte key, each of which will carry along 2 bytes of free padding. A 384 bit key falls on a clean 3-byte boundary and there can be no cuteness for this key length: you'd need to commit to a full 3 additional bytes.

Sure, let's talk. Writing down my thoughts in advance so I don't forget.

If something is unused now, I would like the spec to be maximally conservative and say only that it is reserved and must be zeroed out. If we have ideas on how me might use the area in the future, I'd track them elsewhere.

We can also explore and fully commit to this idea now. I think we would have to remove the alignment requirement on providerData arg and instead pad it as necessary. I don't think we can expose callers to choosing the storage for two reasons. 1. It would make the API more complex. 2. We need to know how to copy providerData from a 256-bit key into a 384-bit hash.

OK, so see my complex note elsewhere on how the API could function. The behavior is easily described but is it clean/simple/desirable? Dunno. For now, I am going to take your advice and required this padding to be zeroed out unless/until we decide otherwise. I think we certainly need more clarity on our handling of optional data in the API (currently required as an optional string, which I do tend to think is a good idea).

KalleOlaviNiemitalo · 2025-01-13T18:50:14Z

docs/PrimaryKey.md

+|encodedKey[43] | 'A'..'_' | 6 bits of provider reserved data. This character should be reserved for stable, readable information, e.g., a provider-specific key kind.
+|encodedKey[^20..^16]|'JQQJ'| Fixed CASK signature.
+|encodedKey[^16]|'A'..'Z'\|'a'..'z'| The first character of the provider signature which must be alphabetic (upper-case indicating a customer-managed as opposed to service managed secret).
+|encodedKey[^15..^12]|('A'..'Z-\_)\|('a'..'z-\_)| | The remaining three encoded characters. Any alphabetic characters must be consistently upper- or lower-case (to distinguish customer- vs. service-managed secrets).


Quotation marks don't seem to pair up. #Resolved

yes, thanks. not sure how best to render this, using regex format which is non-obvious. lots of syntax conventions mixed in here between the C# range stuff, some BNF conventions and regex char ranges. all suggestions for making this more consistent are welcome.

KalleOlaviNiemitalo · 2025-01-13T18:50:51Z

docs/PrimaryKey.md

+|encodedKey[^15..^12]|('A'..'Z-\_)\|('a'..'z-\_)| | The remaining three encoded characters. Any alphabetic characters must be consistently upper- or lower-case (to distinguish customer- vs. service-managed secrets).
+|encodedKey[^12]|'A'..'_'|Represents the year of key allocation, 'A' (2024) to '_' (2087)|
+|encodedKey[^13]|'A'..'L'|Represents the month of key allocation, 'A' (January) to 'L' (December)|
+|encodedKey[^14]|'A'..'Z'\|'a'..'e'|Represents the day of key allocation, 'A' (0) to 'f' (31)|


'e' or 'f'? #Resolved

Nuts, incomplete bug fix from previous incorrectness, thank you.

KalleOlaviNiemitalo · 2025-01-13T18:53:18Z

docs/PrimaryKey.md

+|decodedKey[^15..^12]| 37, 4, 9  |0x25, 0x04, 0x09| 00100101b, 00000100b, 00001001b | Decoded 'JQQJ' signature.
+|decodedKey[^12..^9]|0..255|0x0..0xFF|00000000b..11111111b| Provider identifier, e.g. , '0x4c', '0x44', '0x93' (base64 encoded as 'TEST')


It's confusing that .. means a half-open range in decodedKey[^12..^9] but a closed range in 0..255. #Resolved

Yes I tend to agree, I switched to three dots for the ranges. I wonder if we should embed the actual ellipsis character.

I note that I'm not using the C# syntax for binary literals will do that in a follow-on change.

nguerrera · 2025-01-13T18:56:12Z

docs/PrimaryKey.md

+|decodedKey[^9..^]||||Time stamp data encoded in 4 six-bit blocks for YMDH.
+|decodedKey[^6] >> 2|0, 7, or 8|0xFF|00000000b..11111100b| Leading 6 bits comprises kind enum followed by 2 bits of reserved padding. key[key.Length - 6] & 0xFC == 0.
+|decodedKey[^5] >> 4]|0|0xFF|00000000b..11110000b| Leading 4 bits comprise 4 bits of reserved version information + 4 bits of zero padding (to preserve consistent rendering of the subsequence checksum data).
+|decodedKey[..^4]|0 - 255|0x0..0xFF|00000000b..11111111b|CRC32(key[0] - key[key.Length - 5])


nuts, thanks.

nguerrera · 2025-01-13T18:58:27Z

docs/PrimaryKey.md

+|[optional 3-byte sequences]|0..255|0x0..0xFF|00000000b..11111111b|Provider-defined data of arbitrary interpretation.
+|decodedKey[^15..^12]| 37, 4, 9  |0x25, 0x04, 0x09| 00100101b, 00000100b, 00001001b | Decoded 'JQQJ' signature.
+|decodedKey[^12..^9]|0..255|0x0..0xFF|00000000b..11111111b| Provider identifier, e.g. , '0x4c', '0x44', '0x93' (base64 encoded as 'TEST')
+|decodedKey[^9..^]||||Time stamp data encoded in 4 six-bit blocks for YMDH.


Suggested change

|decodedKey[^9..^]||||Time stamp data encoded in 4 six-bit blocks for YMDH.

|decodedKey[^9..^6]||||Time stamp data encoded in 4 six-bit blocks for YMDH.

``` #Resolved

…r refinements to the primary key doc.

nguerrera

As discussed, any remaining issues will be handled in follow-up, so feel free to merge when green.

michaelcfanning · 2025-01-14T17:31:21Z

At this point, I've done enough tinkering that we definitely should reset and scan the end result in detail. HMAC coming next. btw - does this stuff live in devdocs? or docs?

In reply to: 2550418565

nguerrera · 2025-01-14T18:10:38Z

docs/PrimaryKey.md

+|encodedKey[^12]|'A'...'_'|Represents the year of key allocation, 'A' (2024) to '_' (2087)|
+|encodedKey[^13]|'A'...'L'|Represents the month of key allocation, 'A' (January) to 'L' (December)|
+|encodedKey[^14]|'A'...'Z'\|'a'..'e'|Represents the day of key allocation, 'A' (0) to 'e' (31)|
+|encodedKey[^15]|'A'...'X'|Represents the hour of key allocation, 'A' (hour 0 or midnight) to 'X' (hour 23). [TBD: This value could be used for half hour increments instead].


This is still missing things after timestamp. Also, the indices look off ^15..^12 is both part of the provider signature and the timestamp.

KalleOlaviNiemitalo · 2025-01-14T19:10:28Z

does this stuff live in devdocs? or docs?

I expect docs if it is a specification for the CASK formats so that they can be implemented without using your libraries; devdocs if it's only useful for maintaining your libraries.

nguerrera · 2025-01-14T20:18:25Z

Yes, definitely docs for this change. devdocs for stuff about working in this repo, and TODOs, etc.

michaelcfanning · 2025-01-14T20:22:12Z

Shouldn't the pseudocode for generating the keys/hmacs be in docs by this definition? this information relates directly to our standard, not anything specific to working in this repo.

In reply to: 2590905374

nguerrera · 2025-01-14T20:47:23Z

Probably, yes. But it needs to be cleaned up. There are things out-of-date and I don't want any mentions of objects/instances that were specific to the first implementation and not part of any abstract description of the algorithms.

Add standard BNF for 256-bit primary key.

27ce84b

michaelcfanning requested review from nguerrera, rwoll and suvamM as code owners January 10, 2025 17:19

michaelcfanning added 4 commits January 10, 2025 09:21

Add BNF description of primary key.

47bb92c

Merge from main

1a5945b

Delete stale/moved SLN file.

629a39e

Add some tests, doc updates, a three byte sequence helper class.

83b8c9e

KalleOlaviNiemitalo suggested changes Jan 11, 2025

View reviewed changes

nguerrera reviewed Jan 13, 2025

View reviewed changes

Further updates to primary key documentation.

a9ff6aa

nguerrera reviewed Jan 13, 2025

View reviewed changes

KalleOlaviNiemitalo reviewed Jan 13, 2025

View reviewed changes

nguerrera reviewed Jan 13, 2025

View reviewed changes

michaelcfanning added 2 commits January 13, 2025 17:14

Move 3 byte sequence helper tos test code. Add optional data and othe…

b8a1b9d

…r refinements to the primary key doc.

PR feedback.

5e490ff

nguerrera approved these changes Jan 14, 2025

View reviewed changes

michaelcfanning added 2 commits January 14, 2025 09:14

More PR changes.

2f9d096

More PR feedback.

4ef6332

Add missing files.

425218d

nguerrera reviewed Jan 14, 2025

View reviewed changes

michaelcfanning added 4 commits January 14, 2025 10:15

More encoded table changes.

1a1c168

PR feedback

4554131

Typo in entropy

301f118

Typof in HMAC384 expression

62967a1

michaelcfanning added 2 commits January 14, 2025 11:54

Update BNF for encoded checksum

632a2ac

Style issues

b5c74cd

michaelcfanning merged commit 01ac458 into main Jan 14, 2025
8 checks passed

michaelcfanning deleted the primary-key-standard-bnf branch January 14, 2025 20:18

		<key-type> ::= <256-bit-key> \|

		<256-bit-key> ::= 'A' \| <256-bit-hash> \| <384-bit-hash>


		<payload-data> ::= <random-data> <reserved> [<optional-fields>] <cask-signature> <provider-id> <timestamp> <key-type> <version>

		<random-data> ::= 42 * <base64url> <base64-two-zeros-suffix>; The total random data comprises 256 bits encoded as 42


		public byte[] Bytes { get; }

		public string Encoded => Base64Url.EncodeToString(Bytes);


		<cask-signature> ::= 'JQQJ' ; Fixed signature identifying the CASK key

		<provider-id> ::= 4 * <base64url> ; Provider identifier (24 bits)

		\|decodedKey[^15..^12]\| 37, 4, 9 \|0x25, 0x04, 0x09\| 00100101b, 00000100b, 00001001b \| Decoded 'JQQJ' signature.
		\|decodedKey[^12..^9]\|0..255\|0x0..0xFF\|00000000b..11111111b\| Provider identifier, e.g. , '0x4c', '0x44', '0x93' (base64 encoded as 'TEST')

	\|decodedKey[..^4]\|0 - 255\|0x0..0xFF\|00000000b..11111111b\|CRC32(key[0] - key[key.Length - 5])
	\|decodedKey[^4..]\|0 - 255\|0x0..0xFF\|00000000b..11111111b\|CRC32(key[..^4])
	``` #Resolved

	\|decodedKey[^9..^]\|\|\|\|Time stamp data encoded in 4 six-bit blocks for YMDH.
	\|decodedKey[^9..^6]\|\|\|\|Time stamp data encoded in 4 six-bit blocks for YMDH.
	``` #Resolved

Add standard BNF for 256-bit primary key. #26

Add standard BNF for 256-bit primary key. #26

Conversation

michaelcfanning commented Jan 10, 2025 • edited Loading

KalleOlaviNiemitalo Jan 11, 2025 • edited by michaelcfanning Loading

Choose a reason for hiding this comment

KalleOlaviNiemitalo Jan 11, 2025 • edited by michaelcfanning Loading

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

KalleOlaviNiemitalo Jan 11, 2025 • edited by michaelcfanning Loading

Choose a reason for hiding this comment

KalleOlaviNiemitalo Jan 11, 2025 • edited by michaelcfanning Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nguerrera Jan 13, 2025 • edited by michaelcfanning Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nguerrera Jan 13, 2025 • edited by michaelcfanning Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nguerrera Jan 13, 2025 • edited by michaelcfanning Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nguerrera Jan 13, 2025 • edited by michaelcfanning Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nguerrera Jan 13, 2025 • edited by michaelcfanning Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nguerrera Jan 13, 2025 • edited by michaelcfanning Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nguerrera Jan 13, 2025 • edited by michaelcfanning Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nguerrera Jan 13, 2025 • edited by michaelcfanning Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nguerrera Jan 13, 2025 • edited by michaelcfanning Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nguerrera Jan 13, 2025 • edited by michaelcfanning Loading

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

KalleOlaviNiemitalo Jan 13, 2025 • edited by michaelcfanning Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

KalleOlaviNiemitalo Jan 13, 2025 • edited by michaelcfanning Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

KalleOlaviNiemitalo Jan 13, 2025 • edited by michaelcfanning Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nguerrera Jan 13, 2025 • edited by michaelcfanning Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nguerrera Jan 13, 2025 • edited by michaelcfanning Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nguerrera left a comment

Choose a reason for hiding this comment

michaelcfanning commented Jan 14, 2025

Choose a reason for hiding this comment

KalleOlaviNiemitalo commented Jan 14, 2025

nguerrera commented Jan 14, 2025

michaelcfanning commented Jan 14, 2025

nguerrera commented Jan 14, 2025

michaelcfanning commented Jan 10, 2025 •

edited

Loading

KalleOlaviNiemitalo Jan 11, 2025 •

edited by michaelcfanning

Loading

KalleOlaviNiemitalo Jan 11, 2025 •

edited by michaelcfanning

Loading

KalleOlaviNiemitalo Jan 11, 2025 •

edited by michaelcfanning

Loading

KalleOlaviNiemitalo Jan 11, 2025 •

edited by michaelcfanning

Loading

nguerrera Jan 13, 2025 •

edited by michaelcfanning

Loading

nguerrera Jan 13, 2025 •

edited by michaelcfanning

Loading

nguerrera Jan 13, 2025 •

edited by michaelcfanning

Loading

nguerrera Jan 13, 2025 •

edited by michaelcfanning

Loading

nguerrera Jan 13, 2025 •

edited by michaelcfanning

Loading

nguerrera Jan 13, 2025 •

edited by michaelcfanning

Loading

nguerrera Jan 13, 2025 •

edited by michaelcfanning

Loading

nguerrera Jan 13, 2025 •

edited by michaelcfanning

Loading

nguerrera Jan 13, 2025 •

edited by michaelcfanning

Loading

nguerrera Jan 13, 2025 •

edited by michaelcfanning

Loading

KalleOlaviNiemitalo Jan 13, 2025 •

edited by michaelcfanning

Loading

KalleOlaviNiemitalo Jan 13, 2025 •

edited by michaelcfanning

Loading

KalleOlaviNiemitalo Jan 13, 2025 •

edited by michaelcfanning

Loading

nguerrera Jan 13, 2025 •

edited by michaelcfanning

Loading

nguerrera Jan 13, 2025 •

edited by michaelcfanning

Loading