You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To continue where we left off in rpm-software-management/rpm#3341 and to clarify because I'm not sure this was clearly communicated there:
We added a lightweight version of openpgp.cert.d storage to rpm directly, but as this skips the trust root and all that, I see that as more of a fallback option when rpm-sequoia isn't available than something we'd want to default to. I'd like to see the proper Sequoia implementation used for key (well, cert in Sequoia terminology) storage instead when rpm-sequoia is available.
The rpm-side keystore actually has something resembling an API now (internally). I think it'll see a couple of more changes in the nearish future, but we should be in a better position to start at least thinking about what bringing the sequoia-implementation there would need on both sides.
The text was updated successfully, but these errors were encountered:
Hi,
To continue where we left off in rpm-software-management/rpm#3341 and to clarify because I'm not sure this was clearly communicated there:
We added a lightweight version of openpgp.cert.d storage to rpm directly, but as this skips the trust root and all that, I see that as more of a fallback option when rpm-sequoia isn't available than something we'd want to default to. I'd like to see the proper Sequoia implementation used for key (well, cert in Sequoia terminology) storage instead when rpm-sequoia is available.
The rpm-side keystore actually has something resembling an API now (internally). I think it'll see a couple of more changes in the nearish future, but we should be in a better position to start at least thinking about what bringing the sequoia-implementation there would need on both sides.
The text was updated successfully, but these errors were encountered: