feat: simplify the import / export API for the Keybase

[zivkovicmilos]

Description

This PR greatly simplifies the Keybase interface in regards to key imports / exports, by removing redundant methods.

The goal of the PR is to put the application-level key armor management outside the keybase (not including storage), towards the caller. In fact, this is the reason why the Keybase has a chaotic API for imports / exports.

I've preserved existing gnokey functionality -- this is unchanged.
I will update gnokey imports / exports in a separate PR, to make the flag usage make more sense.

BREAKING CHANGE:

• Removed 9 Keybase methods, and added 2 new ones (that replace them)

cc @jefft0

Contributors' checklist...

• Added new tests, or not needed, or not feasible
• Provided an example (e.g. screenshot) to aid review or the PR is self-explanatory
• Updated the official documentation or not needed
• No breaking changes were made, or a BREAKING CHANGE: xxx message was included in the description
• Added references to related issues and PRs
• Provided any useful hints for running manual tests

[codecov]

Codecov Report

Attention: Patch coverage is 68.08511% with 15 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
tm2/pkg/crypto/keys/client/import.go	71.42%	5 Missing and 1 partial ⚠️
tm2/pkg/crypto/keys/lazy_keybase.go	0.00%	4 Missing ⚠️
tm2/pkg/crypto/keys/client/export.go	75.00%	2 Missing and 1 partial ⚠️
tm2/pkg/crypto/keys/keybase.go	80.00%	2 Missing ⚠️

📢 Thoughts on this report? Let us know!

[aeddi]

Two small details, but apart from that, looks good to me 👍

[moul]

As someone using this package, I prefer this new API. But I would like to summon a few people:

• @piux2, as I recall he was using this package for hiring purposes and may have insights that I don't.
• @tbruyelle, for his broader experience in other cosmos chains.

[Gno2D2]

🛠 PR Checks Summary

All Automated Checks passed. ✅

Manual Checks (for Reviewers):

• IGNORE the bot requirements for this PR (force green CI check)

Read More

🤖 This bot helps streamline PR reviews by verifying automated checks and providing guidance for contributors and reviewers.

✅ Automated Checks (for Contributors):

No automated checks match this pull request.

☑️ Contributor Actions:

1. Fix any issues flagged by automated checks.
2. Follow the Contributor Checklist to ensure your PR is ready for review.
   • Add new tests, or document why they are unnecessary.
   • Provide clear examples/screenshots, if necessary.
   • Update documentation, if required.
   • Ensure no breaking changes, or include BREAKING CHANGE notes.
   • Link related issues/PRs, where applicable.

☑️ Reviewer Actions:

1. Complete manual checks for the PR, including the guidelines and additional checks if applicable.

📚 Resources:

• Report a bug with the bot.
• View the bot’s configuration file.

Debug

Manual Checks

**IGNORE** the bot requirements for this PR (force green CI check)

If

🟢 Condition met
└── 🟢 On every pull request

Can be checked by

• Any user with comment edit permission

[tbruyelle]

The SDK equivalent Keyring struct exposes a similar API to the actual Keybase of this repo (see 1 2 3) (before this PR), without the method that returns the unencrypted private key (namely ExportPrivateKeyObject()). This method is not part of the public interface, so it's a bit harder to call (example from the CLI export command: 4).

However, I see no reason why the API couldn't be simplified. Methods like Export/ImportPubkey() are not used anywhere in the SDK, yet they have been around for years.

Now about the "obfuscation" of unsafe ExportPrivateKeyObject(), the current change makes a clear difference with the SDK keyring, which only exposes safe methods, while here only the unsafe method is exposed. That said, since ExportPrivateKeyObject() was already part of the public API, this may not really matter.

[kristovatlas]

I spent about an hour reviewing, and this all looks good to me to improving the interface and code clarity.