[PM-25818] Migrate Basic Cipher Create, Edit, and Get Operations to SDK

[gbubemismith]

🎟️ Tracking

https://bitwarden.atlassian.net/browse/PM-25818

📔 Objective

⏰ Reminders before review

• Contributor guidelines followed
• All formatters and local linters executed and passed
• Written new unit and / or integration tests where applicable
• Protected functional changes with optionality (feature flags)
• Used internationalization (i18n) for all UI strings
• CI builds passed
• Communicated to DevOps any deployment requirements
• Updated any necessary documentation (Confluence, contributing docs) or informed the documentation
  team

🦮 Reviewer guidelines

• 👍 (:+1:) or similar for great changes
• 📝 (:memo:) or ℹ️ (:information_source:) for notes or general info
• ❓ (:question:) for questions
• 🤔 (:thinking:) or 💭 (:thought_balloon:) for more open inquiry that's not quite a confirmed
  issue and could potentially benefit from discussion
• 🎨 (:art:) for suggestions / improvements
• ❌ (:x:) or ⚠️ (:warning:) for more significant problems or concerns needing attention
• 🌱 (:seedling:) or ♻️ (:recycle:) for future improvements or indications of technical debt
• ⛏ (:pick:) for minor or nitpick changes

[github-actions]

Checkmarx One – Scan Summary & Details – 9499221c-d540-46b8-aba6-53d452380fd8

Great job! No new security vulnerabilities introduced in this pull request

[nick-livefront]

Just a handful of questions from me. I'm following this and the implementation but I would say that my rust experience is a little lack luster on if there are improvements to be made on that thread. I will hold off on approving to hopefully solicit some more impactful feedback, but I can if I'm the gateway between moving this forward.

[nick-livefront]

❓ Probably an edge case, the current CipherView defaults these values to false rather than true. Should this logic follow suit or is the deviation intentional?

[nick-livefront]

I did not know you could link to other entities in a comment with [...], TIL!

[nikwithak]

Would it be better to use decrypt_list_failures here to avoid blocking when only some of them fail to decrypt?

[nikwithak]

Thanks for adding list_ciphers_with_failures! Do you think we still need the list_ciphers for any use cases, or could we remove it altogether?

[codecov]

Codecov Report

❌ Patch coverage is 76.34855% with 285 lines in your changes missing coverage. Please review.
✅ Project coverage is 78.48%. Comparing base (d7ce769) to head (2b57bcf).
⚠️ Report is 2 commits behind head on main.

Files with missing lines	Patch %	Lines
...bitwarden-vault/src/cipher/cipher_client/create.rs	85.00%	45 Missing ⚠️
...tes/bitwarden-vault/src/cipher/cipher_view_type.rs	51.68%	43 Missing ⚠️
...s/bitwarden-vault/src/cipher/cipher_client/edit.rs	92.63%	41 Missing ⚠️
crates/bitwarden-vault/src/cipher/login.rs	47.05%	36 Missing ⚠️
...es/bitwarden-vault/src/cipher/cipher_client/get.rs	0.00%	33 Missing ⚠️
crates/bitwarden-vault/src/cipher/identity.rs	0.00%	22 Missing ⚠️
crates/bitwarden-vault/src/cipher/field.rs	0.00%	15 Missing ⚠️
crates/bitwarden-vault/src/cipher/card.rs	0.00%	10 Missing ⚠️
crates/bitwarden-vault/src/cipher/cipher.rs	84.12%	10 Missing ⚠️
crates/bitwarden-vault/src/cipher/secure_note.rs	0.00%	10 Missing ⚠️
... and 3 more

Additional details and impacted files

@@            Coverage Diff            @@
##             main     #455     +/-   ##
=========================================
  Coverage   78.48%   78.48%             
=========================================
  Files         276      280      +4     
  Lines       27435    28631   +1196     
=========================================
+ Hits        21531    22472    +941     
- Misses       5904     6159    +255     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Hinton]

Overall good, there are a couple of things we should consider.

[Hinton]

Messy, but I suppose we're stuck with it until the cipher is just a blob and we can serialize this manually somehow.

[Hinton]

question: Should we document this? "INTERNAL, do not set from clients."

[nikwithak]

I added a comment - I tried setting it as non-pub, but that doesn't affect the TS types that are generated, and didn't seem to add much benefit in this particular use case.

[Hinton]

question: Since we're creating a cipher key will never exist right?

[nikwithak]

It shouldn't, in which case decrypt_cipher_key will return the existing key. I included this just in case we do get a CipherCreateRequest that already has a key, which would imply the Fido2 credentials were already encrypted with that key. Happy to remove if we're making the assumption that won't happen.

[Hinton]

thought: This raises a good question, how would we create a new cipher with a passkey? They are intentionally encrypted but would that even be viable generally?

I think temporarily we can pass in already encrypted data in the web clients, but this might not work on mobile. Long term having a different flow for creating items with passkeys might be required? CC @coroiu since you have more insight into our sdk passkey flows.

[coroiu]

On clients we don't create ciphers with passkeys. The cipher is created first by the popout, which returns the new cipherId to background which then reads out the cipher and attaches a new passkey to it. It's a bad way of doing it but I think it saves us from having to worry about creation with passkeys in this PR.

mobile on the other hand does create ciphers with passkeys but creation and encryption is encapsulated in the SDK and could use the Repository<Cipher> instead of going through the CipherClient

[Hinton]

question: Do we need both type and type_data?

[nikwithak]

Not anymore - removed type and now pull this data from CipherViewType

[Hinton]

question: It seems a bit weird going from CipherView to CipherEditRequest?

[nikwithak]

The intent here was that a client will have a CipherView locally, make changes to it, and then go to save those changes by converting it into an Edit request.

Something along the lines of:

// Start with a decrypted cipher
let cipher_view: CipherView = ciphers_client.decrypt(cipher)?;

// Make some local changes to the CipherView
cipher_view.name = "New Cipher Name";
cipher_view.login = Some(LoginView {
    username: Some("new_login".to_string()),
    password: Some("password".to_string()),
    ..Default::default(),
});

// Send the changes upstream
ciphers_client.edit(cipher_view.into());

[Hinton]

suggestion: Use a slice rather than a reference to a vector. It's more generic.

Suggested change

	fn extract_hidden_fields(fields: &Vec<FieldView>) -> HashMap<String, String> {
	fn extract_hidden_fields(fields: &[FieldView]) -> HashMap<String, String> {

[Hinton]

suggestion: I think returning vec![] explicitly improves clarity. (same for the other instances in this function)

[Hinton]

With the change to accept a slice you can update this to use default.

Suggested change

	Self::extract_hidden_fields(original_cipher.fields.as_ref().unwrap_or(&vec![]));
	Self::extract_hidden_fields(original_cipher.fields.as_ref().unwrap_or_default();

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
3.3% Duplication on New Code

See analysis details on SonarQube Cloud