search

jstedfast / gmime

A C/C++ MIME creation and parser library with support for S/MIME, PGP, and Unix mbox spools.
GNU Lesser General Public License v2.1
111 stars 36 forks source link

A suggestion for a new crypto callback system #147

Open dagle opened 1 year ago

dagle commented 1 year ago

This pr is more of discussion and trying to fix some of the issues in gmime regarding crypto towards 4.0

This suggestion tries to fix the following problems with the current implementation.

  1. It's not introspectable. A user can't change what engine to use with crypto.
  2. You can't get why the key was created. As mention in #74 this can be a problem. Maybe the flags should be bitflags.
  3. Callback data. Some crypto engines can require additional data or you just want to save some state.
dagle commented 1 year ago

The idea spawned with me wanting to try different cryptoengines, I implemented a gmime-sq which kinda is (or was, glib-rs broke it last week) swap in replacement for gpg. It's a bit naive and doesn't use the latest features of sq but it works and it can use every function of cryptocontext. Personally I would like to choose the crypto engine easily without needing to wrap a lot of C.

The reason for trigger is not only do you might need to know why a cryptocontext should be created. I want this for being able to use it with my autocrypt-storage: sequioa-autocrypt (glib/gmime bindings coming soon), rather than using a gpg keyring to store my peers and keys. This way an implementation of decryption of an autoencrypted email could be engine agnostic.

jstedfast commented 1 year ago

I'm open to having the crypto APIs be redesigned to allow for other drop-in crypto implementations.

jstedfast commented 1 year ago

I don't understand why the password callback was made global - I think it should probably remain per-context.

dagle commented 1 year ago

Moved it back the password function. It's now introspectable. Dunno how to rerun checks, seems to be something wrong with github atm.