All: Add new encryption methods based on native crypto libraries #10696

wh201906 · 2024-07-07T12:39:26Z

This PR adds some new encryption methods for improved performance and security. Users need to turn on Use beta encryption in the sync settings to enable this feature.

Code Changes:

Dependency: Added react-native-quick-crypto to the app-mobile package.
Code: Introduced crypto module, including its type definition and implementations for both Node.js and React Native.
Code: Introduced some new encryption methods(StringV1, FileV1 and KeyV1) with AES-256-GCM cipher and better performance.
Code: Added a featureFlag in the sync settings for the new methods.
Code: Increased encryption chunk size from 5000 to 65536 for string and 131072 for files.
Code: Add chunk size map to apply different size to different encryption methods.
Code: Added defaultFileEncryptionMethod_ to handle JS strings and base64 file content separately.
Code: Updated the handlers in EncryptionService.encrypt() to support async functions.
Test: Modified EncryptionService.test.ts and Synchronizer.e2ee.test.ts to test the new encryption methods in some test cases.
Test: Added integration tests for testing encryption/decryption on different devices.
Test: Added performance tests in the integration tests.
Test: Added unit tests for the nonce generation and increasement.

personalizedrefrigerator

Thank you for working on this!

I've left a few comments.

packages/app-mobile/utils/shim-init-react.js

packages/app-mobile/services/e2ee/NativeEncryption.react-native.ts

laurent22 · 2024-07-07T18:08:28Z

packages/lib/services/e2ee/NativeEncryption.node.ts

+import { promisify } from 'util';
+import crypto = require('crypto');
+
+class NativeEncryption implements NativeEncryptionInterface {


I'm not sure the use of a class makes sense here. Is it just to group these functions together? In that case a file crypto.ts might be preferable with plain functions inside.

Also the fact that it is "native" doesn't really matter, so it should not appear in the name.

Also the fact that it is "native" doesn't really matter, so it should not appear in the name.

I will remove it.

Is it just to group these functions together? In that case a file crypto.ts might be preferable with plain functions inside.

I guess this is the grouped plain functions, right? If so I can rewrite these functions in that way.
https://github.com/laurent22/joplin/blob/v3.0.1/packages/lib/services/e2ee/RSA.node.ts#L11

I have removed the Native in the name and renamed these modules to Crypto in commit a2be9f1.
However, I just noticed that the name Crypto has been used in the Web Crypto API. I guess it's better to use a different name.

I have removed the class definition in commit 17aa0fd.

As @tessus suggested, I've replaced the name to Krypto

wh201906 · 2024-07-14T04:19:37Z

@laurent22 @personalizedrefrigerator I thinks it's ready to be merged.

laurent22

Thanks for the pull request. I understand this is preparation work, but have you been able to use this for E2EE?

laurent22 · 2024-07-16T18:09:47Z

packages/app-mobile/services/e2ee/Krypto.react-native.ts

+import crypto from 'react-native-quick-crypto';
+import { HashAlgorithm } from 'react-native-quick-crypto/lib/typescript/keys';
+
+const Krypto: KryptoInterface = {


In general we don't "brand" filenames to go around naming conflicts. TypeScript provides ways to deal with this when importing.

The name should be all lowercase because it's a library of functions (see coding style guide) and should be "crypto.ts"

It should default-export this constant. Name it cryptoLib if you want, and then export default cryptoLib)

The Krypto was my suggestion, since I didn't know whether ts/js had namespaces. Sorry about that.

OK I will rename them.

laurent22 · 2024-07-16T18:10:19Z

packages/app-mobile/services/e2ee/Krypto.react-native.ts

+		return crypto.getHashes();
+	},
+
+	// eslint-disable-next-line @typescript-eslint/no-explicit-any -- TODO: remove the type "any" here


You mentioned that the pull request is ready to be merged but surely we can't merge this. You're correct that all "any" should be replaced by proper types.

I wonder if it's good to add react-native-quick-crypto(or craftzdog/react-native-buffer) in the dependencies of the whole project, so I can import the Buffer type in it as RNBuffer and make a new type NodeBuffer | RNBuffer for the interface.

and make a new type NodeBuffer | RNBuffer for the interface.

Ideally the interface would not mention any RN-specific type because it's going to be shared with non-RN code. Don't NodeBuffer and RNBuffer share the same interface? Are there differences? If it's the same, maybe create a new interface that declares just the methods and properties that you need

I've created type CryptoBuffer for it.

laurent22 · 2024-07-16T18:12:47Z

packages/app-mobile/utils/shim-init-react.js

@@ -26,6 +26,8 @@ function shimInit() {
 	shim.Geolocation = GeolocationReact;
 	shim.sjclModule = require('@joplin/lib/vendor/sjcl-rn.js');

+	shim.Krypto = require('../services/e2ee/Krypto.react-native').default;


For new code, all import statements should be at the top.

laurent22 · 2024-07-16T18:17:03Z

packages/lib/services/e2ee/types.ts

@@ -25,3 +25,14 @@ export interface RSA {
 	publicKey(rsaKeyPair: RSAKeyPair): string;
 	privateKey(rsaKeyPair: RSAKeyPair): string;
 }
+
+export interface KryptoInterface {


Please name it "Crypto". We know from the type that it's an interface so it's not necessary to append this.

wh201906 · 2024-07-19T16:02:33Z

@laurent22 @tessus @personalizedrefrigerator Please help review the changes. Thanks!

packages/app-mobile/services/e2ee/crypto.ts

laurent22 · 2024-07-21T09:24:31Z

packages/app-mobile/services/e2ee/crypto.ts

+	},
+
+	pbkdf2Raw: async (password: string, salt: CryptoBuffer, iterations: number, keylen: number, digest: string): Promise<CryptoBuffer> => {
+		const digestMap: { [key: string]: HashAlgorithm } = {


Again please read the coding style guide, we explicitly ask not to set types this way. See https://joplinapp.org/help/dev/coding_style#avoid-inline-types

I really shouldn't have to keep reminding you to read it. It's understandable to miss a few details here and there but for this PR that's what, the third or fourth time that I remind you to read it?

Sorry I only checked the method declaration. I will change it later.

laurent22 · 2024-07-21T09:27:40Z

packages/app-mobile/services/e2ee/crypto.ts

+			'sha512': 'SHA-512',
+			'ripemd160': 'RIPEMD-160',
+		};
+		const digestAlgorithm: string = digestMap[digest.toLowerCase()] || digest;


Also not recommended. See https://joplinapp.org/help/dev/coding_style#dont-set-the-type-when-it-can-be-inferred

laurent22 · 2024-07-21T09:31:05Z

packages/lib/services/e2ee/crypto.ts

+		const digestMap: { [key: string]: string } = {
+			'sha-1': 'sha1',
+			'sha-224': 'sha224',
+			'sha-256': 'sha256',
+			'sha-384': 'sha384',
+			'sha-512': 'sha512',
+			'ripemd-160': 'ripemd160',
+		};
+		const digestAlgorithm: string = digestMap[digest.toLowerCase()] || digest;


I don't really get this part - are the digestMap the list of supported digests? In that case shouldn't that be exposed to the library user? In other words, it seems there should be an enum that tells the list of supported digests.

And digest should probably have this type.

Also please don't use toLowerCase() for this - the input digest should be strictly correct and checked at compile time using a type.

The digestMap of pbkdf2Raw() is for mapping the name according to the implementations. For Node.js, the hash algorithms are named like sha1, sha256 while for react-native-quick-crypto they are named like SHA-1, SHA-256. I planned to use the string type for the name, just like how Node.js does. But now I will change it to a enum because react-native-quick-crypto only supports a limited set of them.

Remove the return value type in the implementation Rename some variables

laurent22

Sorry, still a few details but we're getting there. In general please try to use consistent names for things.

For example a map of Cars is a CarMap, not a VehicleMap or an AutomobileMap. OR else you rename car to Vehicle or Automobile too.

Consistent names help with reading the code and searching for strings.

laurent22 · 2024-07-23T11:58:15Z

packages/lib/services/e2ee/types.ts

+export type HashAlgorithm =
+  | 'SHA-1'
+  | 'SHA-224'
+  | 'SHA-256'
+  | 'SHA-384'
+  | 'SHA-512'
+  | 'RIPEMD-160';


Would you mind using an actual enum for this?

I want to use enum but the enum member name cannot contain -.

Here are the enum member name styles I tried:
SHA-512: The style used in react-native-quick-crypto, but the enum member name cannot contain -.
sha512: The style used in node:crypto, but it is not PascalCase so the linter fails.
Sha512: Valid enum member name and follows linter rules, but not used by node:crypto or react-native-quick-crypto and looks strange.

Just use the type used in node:crypto and add the exceptions to eslintrc.js, in the "ENUM" section

Finished in commit f2ed473.

laurent22 · 2024-07-23T12:00:16Z

packages/lib/services/e2ee/crypto.ts

+	pbkdf2 as nodePbkdf2,
+} from 'crypto';
+
+type NodeDigestNameMap = Record<HashAlgorithm, string>;


What is it actually? A digest or a hash algorithm? Please pick one name. Also everything is "NodeSomething" in this file but that doesn't mean we should prefix all types and variables. It's implied that it's NodeSomething.

What is it actually? A digest or a hash algorithm? Please pick one name.

They are almost identical in this context. For node:crypto and react-native-quick-crypto, the argument name in pbkdf2() is digest but the type of it is HashAlgorithm. Considering the digest is the result of a hash algorithm I will use hashxx for all cases except the argument name in pbkdf2Raw() (to match the argument name in node:crypto and react-native-quick-crypto). I will use digest for all.

Also everything is "NodeSomething" in this file but that doesn't mean we should prefix all types and variables. It's implied that it's NodeSomething.

I use the prefix node to indicate the function is from the node:crypto rather than my own implementation. If I remove the prefix, the name getCiphers could refers to the one in node:crypto and the one in my interface Crypto. In the upcoming draft I didn't add the node prefix to functions like createCipheriv because I won't implement a wrapper of it in the interface Crypto.
Is this acceptable?

Finished in commit e4eb58c.

wh201906 · 2024-07-23T16:22:20Z

but have you been able to use this for E2EE?

Yes I did.

packages/lib/services/e2ee/types.ts

Fix description in crypto.test.ts Remove featureFlag.useBetaEncryptionMethod.advanced because it is set to true elsewhere

wh201906 · 2024-09-06T13:14:06Z

@laurent22 I think we have shown that these new encryption methods (StringV1, FileV1 and KeyV1) can be implemented by Web Crypto API, node:crypto or react-native-quick-crypto. Would you consider putting the new methods to the dev branch now so users can try them? If we proved the Web Crypto API implementation with IPC is better on mobile platforms, we can switch to it without modifying any existing ciphertext encrypted with StringV1/FileV1/KeyV1.

wh201906 · 2024-09-09T12:49:49Z

@personalizedrefrigerator Hi. I just found that I cannot build the project after merging the current dev branch (commit ec36847). It shows some errors like this:

➤ YN0000: [@joplin/app-mobile]: ../lib/services/e2ee/crypto.ts(12,30): error TS2339: Property 'subtle' does not exist on type 'typeof webcrypto'.
➤ YN0000: [@joplin/app-mobile]: ../lib/services/e2ee/crypto.ts(15,19): error TS2339: Property 'subtle' does not exist on type 'typeof webcrypto'.
➤ YN0000: [@joplin/app-mobile]: ../lib/services/e2ee/crypto.ts(21,37): error TS2339: Property 'subtle' does not exist on type 'typeof webcrypto'.
➤ YN0000: [@joplin/app-mobile]: ../lib/services/e2ee/crypto.ts(30,37): error TS2339: Property 'subtle' does not exist on type 'typeof webcrypto'.
➤ YN0000: [@joplin/app-mobile]: ../lib/services/e2ee/crypto.ts(46,14): error TS2339: Property 'getRandomValues' does not exist on type 'typeof webcrypto'.
➤ YN0000: [@joplin/app-mobile]: ../lib/services/e2ee/crypto.ts(53,15): error TS2339: Property 'getRandomValues' does not exist on type 'typeof webcrypto'.
➤ YN0000: [@joplin/app-mobile]: ../lib/services/e2ee/crypto.ts(58,33): error TS2339: Property 'getRandomValues' does not exist on type 'typeof webcrypto'.
➤ YN0000: [@joplin/app-mobile]: ../lib/services/e2ee/crypto.ts(66,38): error TS2339: Property 'subtle' does not exist on type 'typeof webcrypto'.

I tried merging several commits in the dev branch and it seems to be caused by commit 7e9c7d7. I guess it's something wrong about the Web Crypto API in the Node.js but I have no idea how to resolve it. Could you please take a look when you have time?

personalizedrefrigerator · 2024-09-10T23:34:38Z

I tried merging several commits in the dev branch and it seems to be caused by commit 7e9c7d7. I guess it's something wrong about the Web Crypto API in the Node.js but I have no idea how to resolve it. Could you please take a look when you have time?

The error seems to be coming from the buildInjectedJs step of the mobile app build. I notice that 7e9c7d7 causes @types/node:^18.0.0 to resolve to a different version than is used by @joplin/lib...

Does changing these lines in yarn.lock from

"@types/node@npm:^18.0.0":
  version: 18.19.33
  resolution: "@types/node@npm:18.19.33"

to

"@types/node@npm:^18.0.0":
  version: 18.19.34
  resolution: "@types/node@npm:18.19.34"

then re-running yarn install help?

Co-authored-by: Henry Heino <[email protected]>

wh201906 · 2024-09-11T03:47:13Z

Does changing these lines in yarn.lock from

"@types/node@npm:^18.0.0":
  version: 18.19.33
  resolution: "@types/node@npm:18.19.33"

to

"@types/node@npm:^18.0.0":
  version: 18.19.34
  resolution: "@types/node@npm:18.19.34"

then re-running yarn install help?

It works. Thanks

wh201906 · 2024-09-12T15:51:20Z

Do tests exist for or would it make sense to add tests for the following cases?

Using the Synchronizer with EncryptionService with the new encryption methods (a full sync):

Notes with resources.

Plain text notes.

Empty notes.

Multiple master keys.

Invalid data (checking that Synchronizer and related logic handles exceptions correctly).

Android/iOS: Encrypting/decrypting data that contains null characters (\0).

In the past, we've had trouble with null characters and SQLite storage due to how a library was sending information to native code.

I think for Case 1~4 they have nothing to do with a specific encryption method. They might be tested elsewhere, but I'm not sure about it.
For Case 5, I added some unit test cases in commit b329c0c, and the Synchronizer related logic test is added in commit edd2a9002a.
For Case 6, I didn't test it with the Synchronizer, but the null characters test is added in commit 26faf260cf. This test case covers plaintext with null character in it and it's working. As for the ciphertext, it is always base64 encoded so a null character won't appear in it.

@personalizedrefrigerator I guess I've checked the cases you mentioned.

wh201906 · 2024-09-22T07:54:00Z

@laurent22 @personalizedrefrigerator I thinks it's ready to be merged.

ahxxm · 2024-10-03T11:20:33Z

packages/lib/services/e2ee/EncryptionService.ts

+			[EncryptionMethod.SJCL4]: 5000,
+			[EncryptionMethod.Custom]: 5000,
+			[EncryptionMethod.KeyV1]: 5000, // Master key is not encrypted by chunks so this value will not be used.
+			[EncryptionMethod.FileV1]: 131072, // 128k


(comment because of #9852, my joplin-desktop now contains 4G data + 8G encrypted data, feel free to ignore!)

for such large chunk size, do you think the encrypted bytes might benefit from a quick zstd compression? i.e. tentatively compress the plaintext before encryptRaw then set result.compressed = true; result.ct = encryptedCompressed if smaller, the same for decrypt

I'm not sure if the extra compression step will slow down the encryption/decryption speed. The E2EE on mobile platform is not very fast, so the speed should be taken into consideration.
With that said, even if we don't use compression now, the encrypted file size is decreased in the new encryption methods. (report).

zstd can reach around 500mb/s with default compression level on desktop, while I can't find a benchmark on mobile, its overhead(a slight regression over huge improvements you brought) should remain manageable

I'm still reading the full report, overhead decrease in file size and master key are promising, thank you!

The speed overhead could be much greater than expected.
For example, the raw AES encryption speed on desktop is over a few GB/s
https://discourse.joplinapp.org/t/performance-test-of-node-js/38762#aes-encryptiondecryption-performance-2
But in the final implementation, the encryption speed is less than 100MB/s
https://discourse.joplinapp.org/t/final-report-of-the-native-encryption-project/40171#p-128759-based-on-commit-edd2a9002a31b0fee4f11ded0a37951543e289ab-release-build-7

Things could be worse on React Native. The raw AES encryption speed could reach 100MB/s. But in the final implementation, the encryption speed is less than 2MB/s
https://discourse.joplinapp.org/t/performance-test-of-react-native-quick-crypto/38622#aes-encryptiondecryption-performance-2

I see, I almost never edit notes on my phone, but the decryption slowness on first sync was already ~~concerningly~~ impressive..

laurent22 · 2024-10-26T20:16:15Z

Ok I think we can merge this then. Many thanks @wh201906 for implementing this important feature, and thanks @personalizedrefrigerator for reviewing and providing support!

laurent22 · 2024-11-13T13:57:51Z

@wh201906, we're getting this random test error on CI:

➤ YN0000: [@joplin/lib]: FAIL services/e2ee/crypto.test.js
➤ YN0000: [@joplin/lib]:   ● e2ee/crypto › should generate new nonce if counter overflow
➤ YN0000: [@joplin/lib]: 
➤ YN0000: [@joplin/lib]:     expect(received).toBe(expected) // Object.is equality
➤ YN0000: [@joplin/lib]: 
➤ YN0000: [@joplin/lib]:     Expected: 257
➤ YN0000: [@joplin/lib]:     Received: 1
➤ YN0000: [@joplin/lib]: 
➤ YN0000: [@joplin/lib]:        97 | 		expect(nonce.subarray(0, 21)).not.toEqual(randomPart);
➤ YN0000: [@joplin/lib]:        98 | 		// Timestamp part should have expected value
➤ YN0000: [@joplin/lib]:     >  99 | 		expect(nonce[21]).toBe(timestampPart[0] + 2);
➤ YN0000: [@joplin/lib]:           | 		                  ^
➤ YN0000: [@joplin/lib]:       100 | 		expect(nonce.subarray(22, 28)).toEqual(timestampPart.subarray(1));
➤ YN0000: [@joplin/lib]:       101 | 	}));
➤ YN0000: [@joplin/lib]:       102 |
➤ YN0000: [@joplin/lib]: 
➤ YN0000: [@joplin/lib]:       at Object.toBe (services/e2ee/crypto.test.ts:99:21)

Do you know what could be the reason? It certainly looks like a value somewhere is stored as a byte, but it's checked here as if it was something else, an integer maybe.

What I'm wondering though is could it mean that encryption is faulty due to an integer overflow error? Or is that just the test that is not correct? And I wonder in terms of security if there could be a flaw - for example a number is expected to be a large integer, but it's in fact just a byte.

wh201906 · 2024-11-13T14:12:25Z

@laurent22 I will check it right away.

wh201906 · 2024-11-13T17:00:12Z

Do you know what could be the reason? It certainly looks like a value somewhere is stored as a byte, but it's checked here as if it was something else, an integer maybe.

The implementation of crypto.increaseNonce() is correct, but my test code is wrong. I only checked the least significant byte of the timestamp part in the nonce, which can overflow after adding 1 to 255, causing a carry-over to the next byte. I mistakenly thought the least significant byte should always increase and wrote the wrong code in the test cases. This issue can only occur when the test is running with timestamps ending in 0xFE or 0xFF, so it has a 2/256 chance of being triggered.

What I'm wondering though is could it mean that encryption is faulty due to an integer overflow error? Or is that just the test that is not correct?

It’s just an issue with the test. I'll submit a PR to fix it and add test cases for specific timestamps.

And I wonder in terms of security if there could be a flaw - for example a number is expected to be a large integer, but it's in fact just a byte.

This could happen when dealing with TypedArray because elements in it have a fixed range. For the implementations of new crypto methods I think they should be fine because I did consider the type and overflow for the nonce.

~~With that said, even in the worst case — the counter part and the timestamp part in the nonce are set to a constant value, the 21 bytes (168 bits) of random number still make the nonce quite unique.~~ I just realized the random number part is updated only when the counter part overflows, so a fixed counter would result in a fixed nonce (salt) there. But we still have a 96 bits random IV which is updated for each chunk. Plus, the worst case I mentioned there is almost impossible to happen unless the Joplin app itself is malformed. Just forget about it.

Add basic framework for native encryption

71f0204

personalizedrefrigerator reviewed Jul 7, 2024

View reviewed changes

packages/app-mobile/utils/shim-init-react.js Outdated Show resolved Hide resolved

packages/app-mobile/services/e2ee/NativeEncryption.react-native.ts Outdated Show resolved Hide resolved

wh201906 marked this pull request as draft July 7, 2024 16:25

laurent22 reviewed Jul 7, 2024

View reviewed changes

wh201906 added 2 commits July 8, 2024 19:43

Remove class

17aa0fd

Rename to Crypto

a2be9f1

personalizedrefrigerator mentioned this pull request Jul 10, 2024

Chore: Mobile: Migrate shim-init-react to TypeScript #10731

Merged

Rename to Krypto

17badd5

wh201906 marked this pull request as ready for review July 14, 2024 03:54

laurent22 reviewed Jul 16, 2024

View reviewed changes

wh201906 added 4 commits July 19, 2024 23:49

Merge branch 'dev' into wh201906/native_encryption

80a764b

Rename

4c8c2f3

Remove type any

8387c96

Add common interface for the Buffer in Node.js and react-native-buffer

0276041

laurent22 reviewed Jul 19, 2024

View reviewed changes

packages/app-mobile/services/e2ee/crypto.ts Outdated Show resolved Hide resolved

Clean up

832e589

wh201906 force-pushed the wh201906/native_encryption branch from 7788bc0 to 832e589 Compare July 20, 2024 05:59

laurent22 reviewed Jul 21, 2024

View reviewed changes

wh201906 added 2 commits July 21, 2024 19:12

Fix the type of digest

373ecac

Clean up

d3bd657

Remove the return value type in the implementation Rename some variables

laurent22 reviewed Jul 23, 2024

View reviewed changes

wh201906 added 2 commits July 23, 2024 21:50

Rename

e4eb58c

Use enum for Digest

f2ed473

laurent22 reviewed Jul 26, 2024

View reviewed changes

packages/lib/services/e2ee/types.ts Outdated Show resolved Hide resolved

wh201906 added 3 commits July 26, 2024 21:23

Merge branch 'dev' into wh201906/native_encryption

0182cce

Add a linter ignore rule for crypto terms

48b54ec

Add encryption core and string wrapper

70db354

Clean up

bf0d512

Fix description in crypto.test.ts Remove featureFlag.useBetaEncryptionMethod.advanced because it is set to true elsewhere

wh201906 and others added 2 commits September 11, 2024 11:34

Merge branch 'dev' to resolve conflicts

8def1be

Fix yarn.lock

115b502

Co-authored-by: Henry Heino <[email protected]>

wh201906 added 2 commits September 12, 2024 21:43

Use it.each to make test cases independent of each other

8fcc8ee

Add test cases for new encryption methods in Synchronizer.e2ee.test.ts

edd2a90

wh201906 changed the title ~~All: Replace sjcl with native crypto implementations~~ All: Add new encryption methods based on native crypto libraries Sep 14, 2024

wh201906 added 5 commits September 17, 2024 00:14

Merge branch 'dev' to resolve conflicts

a786478

Merge branch 'dev' to resolve conflicts

d8f243a

Merge branch 'dev' to resolve conflicts

e78cc10

Merge branch 'dev' to resolve conflicts

5934ccb

Merge branch 'dev' to resolve conflicts

9e22379

wh201906 requested review from laurent22 and personalizedrefrigerator September 22, 2024 07:50

wh201906 requested a review from tessus September 22, 2024 07:59

ahxxm reviewed Oct 3, 2024

View reviewed changes

wh201906 added 2 commits October 16, 2024 03:49

Merge branch 'dev' to resolve conflicts

002f7de

Merge branch 'dev' to resolve conflicts

98acc2a

laurent22 merged commit aa6348c into laurent22:dev Oct 26, 2024
10 checks passed

wh201906 deleted the wh201906/native_encryption branch October 27, 2024 03:38

wh201906 mentioned this pull request Nov 13, 2024

All: Fix a flaky test case in crypto.test.ts #11389

Merged

All: Add new encryption methods based on native crypto libraries #10696

All: Add new encryption methods based on native crypto libraries #10696

Conversation

wh201906 commented Jul 7, 2024 • edited Loading

personalizedrefrigerator left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

wh201906 Jul 7, 2024 • edited Loading

Choose a reason for hiding this comment

wh201906 Jul 8, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

wh201906 commented Jul 14, 2024

laurent22 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

wh201906 Jul 21, 2024 • edited 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

Choose a reason for hiding this comment

wh201906 commented Jul 19, 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

laurent22 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

wh201906 Jul 23, 2024 • edited 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

wh201906 Jul 23, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

wh201906 commented Jul 23, 2024

wh201906 commented Sep 6, 2024

wh201906 commented Sep 9, 2024

personalizedrefrigerator commented Sep 10, 2024 • edited Loading

wh201906 commented Sep 11, 2024

wh201906 commented Sep 12, 2024 • edited Loading

wh201906 commented Sep 22, 2024

ahxxm Oct 3, 2024 • edited 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

Choose a reason for hiding this comment

laurent22 commented Oct 26, 2024

laurent22 commented Nov 13, 2024 • edited Loading

wh201906 commented Nov 13, 2024 • edited Loading

wh201906 commented Nov 13, 2024 • edited Loading

wh201906 commented Jul 7, 2024 •

edited

Loading

wh201906 Jul 7, 2024 •

edited

Loading

wh201906 Jul 8, 2024 •

edited

Loading

wh201906 Jul 21, 2024 •

edited

Loading

wh201906 Jul 23, 2024 •

edited

Loading

wh201906 Jul 23, 2024 •

edited

Loading

personalizedrefrigerator commented Sep 10, 2024 •

edited

Loading

wh201906 commented Sep 12, 2024 •

edited

Loading

ahxxm Oct 3, 2024 •

edited

Loading

laurent22 commented Nov 13, 2024 •

edited

Loading

wh201906 commented Nov 13, 2024 •

edited

Loading

wh201906 commented Nov 13, 2024 •

edited

Loading