Conversation
If packet inspection is detected our error message redirects to a dead link: https://docs.keeper.io/secrets-manager/commander-cli/using-commander/troubleshooting-commander-cli#ssl-certificate-errors Changed this to the new link (from keeperpam directory) https://docs.keeper.io/keeperpam/commander-cli/troubleshooting-commander-cli#ssl-certificate-errors
When a v3 typed field has type="password" with a custom label (e.g. "Passphrase" on the built-in "SSH key with strong passphrase" record type), both `keeper get <record>` and the supershell TUI were showing the field as "Password: ********" — the label was discarded during the v3-to-legacy mapping in Record.load() and `display()` printed the hard-coded "Password" string. Capture the label in Record.password_label during load() and use it in display() when set, falling back to "Password" so legacy/un-labeled records are unchanged. Update the supershell so its password-field detection (used for masking, audit-logged copy via ClipboardCommand, and the unmask toggle) matches both "Password" and any custom label set on the underlying type=password field. Without this the field would render correctly but lose unmask/copy semantics. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
#2078 fixed the symptom for type=password fields. The same label-discard pattern exists in Record.load() for login, url, and oneTimeCode fields, and customer vaults already contain records with custom labels on these types — importers from Thycotic and 1Password explicitly create them (see thycotic.py:526/636/680 for login/url/oneTimeCode, one_password.py :154/288 for url/login). Capture each field's label in self.login_label / self.url_label / self.totp_label during load(), and use them in display() with fall-back to the canonical "Login" / "URL" / "TOTP URL" labels so un-labeled and legacy v2 records are unchanged. Update the supershell parallel matchers: - Capture login_label and login_url_label into record_dict so the supershell knows the renamed field is still the canonical login/URL. - Extend the "URL" key matcher so the post-URL display_totp() call still fires when the URL field has a custom label. - "Login" has no special-case branch in the supershell text parser, so no matcher change is needed there — only the label capture. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
prepare_record_add_or_update computes a partial-key hash (type + title +
login + url) for each record in the vault and for each record being
imported, and matches them to decide whether --update should rewrite an
existing record vs. add a new one. For Login type records the hash from
the vault side and from the CSV side diverged on the $url token, so no
match was found and a duplicate was created.
Root cause: convert_keeper_record refused to promote a typed url field
to rec.login_url when the field carried any label. KC-1163 stamps the
schema $ref as a default label on every standard field at write time
(so KSM can resolve them), which means every Commander-imported login
record has label='url' on its URL field. The label='url' default then
blocked URL promotion on the next round-trip, so rec.login_url stayed
None and the partial-hash $url token was empty.
Relax the URL-promotion guard to accept the schema-default label (when
label equals the field type) as canonical. A genuinely-labeled URL
("Backup URL", etc.) is still kept as a typed field so it doesn't
shadow the canonical URL.
Non-Login record types weren't affected because their partial hash
walks rec.fields, where the URL ends up either way — both sides of the
comparison see the same labeled field and hash identically.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* Add sf -roe and lsf --roe-eligible flags * Fix unit test
When importing secrets from Thycotic/Delinea, we may map secret templates to custom record types: - We make a list of all available record types - We check the secret's template type and if it's a match, we import it as that custom record type. However, since custom record type names have a character limit in Keeper, we have an additional logic: 1. Consider template name "This string is 33 characters long" 2. We truncate the name to its first 30 characters: "This string is 33 characters l", then compare with available custom record type names The problem with this logic is that custom record types have a 32-character limit in Keeper, not 30. As such the truncate in (2) is incorrect. Changed truncate action to 32 characters to match true custom record type limit.
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.