Leaderboard

ENVIRONMENT - Enpass 6.12.7 (2786), Mac App Store build - macOS 27.0.1 (26A434), MacBookPro18,2, Apple silicon - Vault: local only (previously iCloud-synced; removed from iCloud while troubleshooting) SYMPTOM After launching and unlocking, Enpass sits with one core at ~100% for several minutes (one run took about 8 minutes, then CPU dropped on its own). The UI is sluggish. WHAT I TRIED THAT DID NOT FIX IT - Removing the vault from iCloud sync - Cutting the vault from ~2500 items to ~500 (spin was still several minutes) WHAT FIXED IT Disabling Enpass as an AutoFill provider in System Settings eliminated the 100% CPU, tested on multiple restarts of the app. LOGS from sample and fs_usage during the spin using these commands: sample Enpass 60 10 -file /tmp/enpass.hang60.txt sudo fs_usage -w -f filesys Enpass > /tmp/enpass.fsu.txt 1. The busy thread is not the UI and not the network. The main thread is idle in mach_msg; no CFNetwork/NSURLSession frames appear in any thread. lsof shows only two localhost LISTEN sockets and no outbound connections. 2. Two threads run the same Enpass routine at the same time: - the XPC reply thread, called from -[ASCredentialIdentityStore removeAllCredentialIdentitiesWithCompletion:] (5033/5033 samples in Enpass code) - a pooled worker thread (reaches the same routine via +0x6797d4 -> +0x95d74c -> +0x95e254 -> +0x95eb9c) 3. They contend on one std::recursive_mutex (call site +0x4887c): 2856 of 5033 samples (57%) blocked on the worker, 2085 of 5033 (41%) blocked on the AutoFill thread. 4. fs_usage over ~28 s shows ~990,000 pread calls (all 4 KB, sequential, served from cache, 1-2 us each), ~14,000 pwrite, 1,216 fsync, 304 unlink. The pattern is ~11 journal-delete transactions per second, each preceded by a ~3,250-page scan. 5. The path-bearing calls all go to Documents/.settings/securesettings.db and its -journal and -wal files, not to the vault database. (The pread lines show only a file descriptor, F=34, so the link to that file is inferred.) 6. The crash on quit is in the same code path as the spin: the MasterCommandWorker frames in the crash report match the sample's frames (same build UUID 7f26ae3c-f9ab-396e-b9b9-7bf6d8e5e859), including the crashing function near +0xc87400. MY HYPOTHESIS The AutoFill credential-identity refresh scans securesettings.db repeatedly, with two threads serializing on one lock. That cost would not depend on vault size, which fits the 2500 -> 500 result.

I have a device on my local network that I regularly log into and every time I try to autofill with Enpass I get a popup that says "You're trying to autofill credentials saved for a secure (HTTPS) site on an unsecured (HTTP) site. Only continue if you trust this site. For your security, we recommend avoiding autofill on unsecured websites." First of all, the saved website in Enpass is just a "192.168" address, it's not HTTPS, so it's not a secure site. Is this popup erroneously triggering for all regular sites? But regardless, can we please have the option to disable the popup on individual password entries? I tried attaching a screenshot but your forum is producing a "upload failed" every time I try. Thank you.