It’s Cybersecurity Awareness Month! Join our interactive training session, or learn about security and AI from 1Password experts.
Severe slowdown in Chrome with 1Password extension 8.11.12.27 on pages with many inputs
Since updating to 1Password extension 8.11.12.27 in Chrome, pages with forms containing thousands of inputs freeze on load. The problem also occurs with many hidden inputs, which should not be processed by the extension. We run an application that makes heavy use of hidden inputs. With earlier versions of the extension this was not a problem. Profiling shows high CPU use in openOrClosedShadowRoot(), especially when called on the form element containing many inputs. After load, the function runs instantly, so the slowdown is tied to the extension’s initial DOM scan. Steps to Reproduce: Install 1Password extension v8.11.12.27 in Chrome. Open a form with thousands of inputs, including hidden ones. Example: https://inputs-1password.netlify.app/ On load, clicking buttons or opening the context menu is impossible. Chrome stays frozen until the extension finishes scanning. Expected Result: Pages should load normally, regardless of number or type of inputs. Actual Result: Pages freeze during load due to heavy time spent in openOrClosedShadowRoot(). Impact: Severe slowdown in apps with large forms. Users blocked from working with affected pages. Disabling Autofill options does not help. Using "Hide on this page" does not help. Adding data-1p-ignore to every input is not feasible for us. Rolling back the extension is not practical. Workarounds: None viable for production. Proposed fixes: Optimize DOM traversal or revert to the previous methods. Support a parent-level attribute to exclude all children from scanning. Ensure that when the extension is disabled for a page, it truly does not inject or process elements on that page.
Passkey algorithm support
Recently I began a passkey integration and I'm using 1password to test things out. There are a great deal of passkey algorithms that exist: https://www.iana.org/assignments/cose/cose.xhtml#algorithms Unfortunately it seems like if I remove all the "Recommended: No" and "Recommended: Deprecated" ones, I am unable to get 1password to generate a passkey. It gives me a somewhat opaque "1password encountered a problem" in the passkey dialogue after I click Save, and it seems to fall back to the browser which prompts me for a security key. I see this in the console log: PortOpener: passkey-save-prompt/XXXXXX received error: "create-passkey-failed" The algorithms I chose in order to be more secure based on the recommendations on that page and what I'm able to support in my server: PS384 PS512 RS256 RS384 RS512 The "deprecated" algorithm I added to make the error go away, and allow 1password to correctly function: ES256 Is there anywhere to find the full list of passkey algorithms 1password supports so I can try to come up with a good list to use on the server-side? Ideally it wouldn't contain deprecated ones.
'op read' mistreats binary content
I wanted to write a command for git crypt unlock <FILE>, but since the command requires file as input and I was figuring out how to get content of attachment, I first tried it with op read 'op://<my-vault>//git-crypt.key' > git-crypt.key. Then, trying to unlock with now stored key, I was met with error "not a valid git-crypt key file". After some investigation, I found out that the stored key is slightly modified. This seem to happen when: The content is at least partially binary The content contains some invalid Unicode sequences or certain control characters The content is directly redirected into a file using > operator It seems that ascii-only content isn't affected. The binary content is also not affected when it's being piped into another process (e.g. op read 'op://<my-vault>/<my-item>/git-crypt.key' | cat > git-crypt.key - extra cat in the pipeline helps op store the contents correctly). What also works correctly is git crypt unlock <(op read -n ...) as it also creates a inter-process pipe. Since there's quite glaring occurrence of ef bf bd, which is a Unicode replacement character (�), and sequence 594f 7f63 is transformed to just 594f 63.. (7f being a DELETE control character), it seems that the content undergoes some UTF-8 decoding/processing. This is bit confusing as it's neither documented, nor is there any -b | --binary option to control this behavior. # Create a binary file and upload it to 1Password > dd if=/dev/urandom of=binary-data bs=1 count=32 # Fetch the attachment from 1Password using CLI > op read -n 'op://<my-vault>/Test/binary-data' > binary-data-redirected-to-file > op read -n 'op://<my-vault>/Test/binary-data' | cat > binary-data-piped-through-cat # Print content > hexxy -n binary-data 0000000: 00c6 773b 1963 95f1 6dc5 1bb6 bdde 4946 ..w;.c..m.....IF 0000010: 9f0e 594f 7f63 b6ed 2392 f9e1 91b3 abfc ..YO.c..#....... > hexxy -n binary-data-redirected-to-file 0000000: efbf bd77 3b63 efbf bdef bfbd 6def bfbd ...w;c......m... 0000010: efbf bdef bfbd efbf bd49 46ef bfbd 594f .........IF...YO 0000020: 63ef bfbd efbf bd23 efbf bdef bfbd e191 c......#........ 0000030: b3ef bfbd efbf bd ....... > hexxy -n binary-data-piped-through-cat 0000000: 00c6 773b 1963 95f1 6dc5 1bb6 bdde 4946 ..w;.c..m.....IF 0000010: 9f0e 594f 7f63 b6ed 2392 f9e1 91b3 abfc ..YO.c..#....... Rant on the side: Not being able to use <code> tag on forum is bit dumb.
Connection reset when `podman login` runs `op`
I've set up a https://linuskarlsson.se/blog/podman-credential-helpers/ which runs `op read 'op://[redacted]'` internally. When I run the helper program in a terminal it works fine, prompts for the password if necessary, and prints the credentials. But when running `podman login` in the same terminal it fails with the following error: [ERROR] 2025/07/23 16:22:20 could not read secret 'op://[redacted]': error initializing client: connecting to desktop app: read: connection reset, make sure 1Password CLI is installed correctly, then open the 1Password app, select 1Password > Settings > Developer and make sure the 'Integrate with 1Password CLI' setting is turned on. If you're still having trouble connecting, visit https://developer.1password.com/docs/cli/app-integration#troubleshooting for more help. I've verified that the setting is turned on (running the helper program directly wouldn't work otherwise). I'm running `op` version 2.31.0.
