Want to submit a feature request?

Tell us how we could make the product more useful to you. Feel free to vote existing submitted ideas so we can better understand how useful a feature would be.

SSH Key Support with Automatic SSH Agent Integration (OpenSSH / Pageant)

Request to add native SSH key management with automatic SSH agent integration. This would turn PearPass into a secure, unified hub for SSH authentication, handling key lifecycle safely in the system agent. Proposed Features: πŸ”Ή 1. Entry-Level Key Management Attach private key files directly to vault entries. Auto-decrypt on agent load if the key is password-protected (use credentials from the entry). Display metadata: public key, fingerprints (MD5, SHA256), and key comment. πŸ”Ή 2. Lifecycle & Security Controls Add keys to the SSH agent automatically on vault unlock. Remove keys from the agent on vault lock/close. Optional "require confirmation" flag for key usage. Auto-remove timeout after last use (default: 600s, configurable). πŸ”Ή 3. UI Dedicated tab/window "Active SSH Keys" showing which keys are currently loaded in the agent. "Clear Agent" button to instantly remove all PearPass-managed keys. πŸ”Ή 4. Implementation Notes Integrate with the system OpenSSH agent (Win/Linux/macOS) and/or Pageant (PuTTY). Ensure compatibility with MobaXterm, WinSCP, PuTTY, native OpenSSH, VS Code Remote, etc. Keys must never be written to disk: operate exclusively in memory via the standard SSH agent protocol. Benefits: βœ… Unified password & SSH key manager βœ… Enhanced security: keys reside only in memory, auto-expire, and clear on lock βœ… Seamless workflow with any terminal, IDE, or SSH client Happy to provide feedback or assist with testing. Thanks for your great work! πŸ›‘οΈ

Dotpwnpewpew 16 days ago

1

BUG: Extension loses autofill after Passkey is added to an existing entry

Summary When a Passkey is added to an existing vault entry, the browser extension stops recognizing that entry for autofill β€” showing "No records found" β€” until a new separate entry is created for the same site. Steps to reproduce 1.Create a vault entry with a username + password for a site. 2.Verify the extension autofills credentials correctly. 3.Add a Passkey to the same entry. 4.Navigate to the site's login page and trigger autofill via the extension. Actual Extension shows "No records found" β€” entry is no longer matched to the site. Workaround Creating a new separate entry for the same site restores autofill Root cause hypothesis Adding a Passkey may alter the entry's internal type, URI matching logic, or record structure in a way that causes the extension's site-matching query to exclude entries that contain a Passkey credential. Requested fix Ensure that adding a Passkey to an entry does not break existing username/password autofill matching. Both credential types should coexist in a single entry and be independently discoverable by the extension. I checked on the Dropbox website After creating a new record

Dotpwnpewpew 6 days ago

1

Flexible Word Count for Recovery Phrase Records

1. Overview Pearpass currently supports Recovery Phrase records with a fixed word count of 12 or 24 words (BIP-39 standard). However, various services and platforms use recovery phrases, mnemonic codes, and backup codes with different word counts. This feature request proposes extending the Recovery Phrase record type to support a configurable, user-defined word count. 2. Problem Statement Users who store recovery credentials for services outside the BIP-39 ecosystem (cryptocurrency wallets) are forced to use workaround solutions such as free-text notes, which lack the structured UX, copy-per-word functionality, and validation benefits of the dedicated Recovery Phrase record type. Known services with non-standard word counts: Service Word / Code Count Format Notes Bitcoin / Ethereum wallets (BIP-39) 12 or 24 words Currently supported Steam Guard ~30 words Recovery code list Dropbox 10 words Account recovery phrase GitHub 16 codes Each code is alphanumeric, not a dictionary word Google / Apple (varies) 8–12 words Account recovery Custom enterprise systems Variable Any count per policy Exapmle: Steam Guard - 1A1AA11 Github - aa09f-8cc75 Dropbox - aa1aaaa2 3. Proposed Solution Allow the user to configure the word count (or code count) of a Recovery Phrase record freely, instead of being limited to 12 or 24. 3.1 Word Count Configuration Replace the current fixed selector (12 / 24) with a flexible numeric input or extended selector. Supported range: 1 to 64 words/codes (sufficient for all known real-world cases, extensible later). The input count determines the number of word fields rendered in the record editor. Default value remains 12 or 24. 3.2 Validation BIP-39 dictionary validation applies only when the count is 12 or 24. For all other counts, fields accept arbitrary alphanumeric strings (no dictionary restriction). Empty fields generate a warning, not an error β€” some services allow partial recovery sets.

Dotpwnpewpew 6 days ago