Closed ronaldtse closed 5 years ago
@r10s Hi Bjoern, The codebase changed dramatically since of NetPGP, and now most likely you will not find direct mapping of the functions. So feel free to ask :-)
All pgp data processing functionality goes down to stream-parse.h/stream-write.h, see functions process_pgp_source
and rnp_encrypt_src
, rnp_sign_src
, rnp_encrypt_sign_src
.
Code from rnp.cpp uses these functions (and there you could see example implementation of pgp_write_handler_t and pgp_parse_handler_t), however before calling you should populate rnp_ctx_t
as well. Basically, it is where you specify recipients/signers.
Example could be found in rnp.cpp from CLI (src/rnp/rnp.cpp
), in function setup_ctx
.
Another thing you need is to specify key_provider, which will fetch keys by id/username. Example is also available at src/rnp/rnp.cpp
(it uses rnp_t top-level object which keeps loaded keyrings).
@ni4 I think this is a good chance to fix our documentation, since these cases are the most common use cases. Can you help put them in the README and @strogonoff can put it on rnpgp.com?
@ronaldtse Ok, sure. I think it's a good time to have some tutorials on most common usage scenarios.
@ni4 @ronaldtse thanks, this is very helpful and helps a lot. wrt further questions, well i am sure, they will come up :)
I think the API @ni4 described is more internal and prone to change than the FFI API in rnp2.h
. We haven't officially supported anything but the rnp2.h
API in the past (it is the only installed header). (Of course, if you want to maintain your own internal version of rnp then this is mostly irrelevant)
@dewyatt Yeah, but it could be more usable then FFI if you need it to integrate in C project. And adjust code once some breaking changes occurs.
@ronaldtse
@ni4 I think this is a good chance to fix our documentation, since these cases are the most common use cases. Can you help put them in the README and @strogonoff can put it on rnpgp.com?
How about it’s also a good opportunity to do a focused blog post—get the information out there quicker for a well-defined target audience. Easier for us to write, likely easier for the user to Google up.
@dewyatt we should obviously try to limit access through the supported API, and that means we should fully cover the necessary use cases that people want to use.
It’s tough enough to maintain the API but we don’t want our hands tied to an internal API where users are accessing them directly.
I think we need to do three things at least:
Thoughts and how we can divvy this up? I think @strogonoff can help interview you guys to extract some information for starters.
Cc: @randombit
@ronaldtse I want to do some simple code examples for main operations - key generate, load, encrypt, decrypt, sign and verify. This would cover 95% of usage scenarios, and we could update those examples once internal APIs change. This would not take much time.
@ni4 this would be really great :)
@ni4 please go ahead, our README is horrendously out of date :wink:
i tested out the rnp2.h
-interface a bit, in fact, it is very different from netpgp, however, this is not really bad :)
all in all, it looks very good to me and you've done a great job :) i've tested out the key generation using json and this looks very convenient to me :)
so, as @dewyatt suggested, i'd like to stay in the range of the "supported" api and leave this only when there is no other option.
while src/tests/ffi.cpp
is currently very useful to me, i did not found a method to encrypt against random keys i have as gpg-"blobs" already in by database
rnp_op_encrypt_t op = NULL;
rnp_input_t input = ...
rnp_output_t output = ...
rnp_op_encrypt_create(&op, ffi, input, output);
// this takes a rnp_key_handle_t (that is converted to pgp_key_t internally)
// however, i'd like to specify key-data directly here, if possible
rnp_op_encrypt_add_recipient(op, ...);
rnp_op_encrypt_execute(op);
rnp_op_encrypt_destroy(op);
what would be the easiest way to achieve this? i am sure, i've not understood all concepts, so, please forgive stupid questions :)
@r10s There's currently no option in this API to use a key without first loading it, so you would have to use rnp_load_keys
and then rnp_locate_key
to obtain the key handle. (As you've found, src/tests/ffi.cpp
is likely the best source of info).
If you're familiar with Ruby, ruby-rnp may also be useful to look at.
@r10s I'm finishing examples set, which will use lower-layer API, and show how to load keys by demand. Hope to post a PR later today.
@r10s PR with FFI API examples was merged to master. Do you have any further questions?
@r10s @ronaldtse Could we close this now when FFI examples are available?
Yes we can and should.
However, can you help add the documentation on how to use them? Maybe a separate ticket / PR?
@ronaldtse I added src/examples/README.md
and section For developers
to main README.md which points to it. Is this enough, or some more details needed?
On Thu, Dec 20, 2018 at 13:57 +0000, Nickolay Olshevsky wrote:
@r10s @ronaldtse Could we close this now when FFI examples are available?
Sure, you can close this. Thanks for your work also on the examples!
We went a bit silent because we are trying to get major new DeltaChat Android and dev releases out before 35c3 (the 15K independent hackers event in Leipzig next week). Is anyone from RNP around by chance?
I got this message from @r10s about using RNP in https://github.com/deltachat/deltachat-core .
(Thanks @r10s! )
Could someone help him with this? Thanks!
ping @ni4 @dewyatt