Daiki Ueno
Daiki Ueno
does pinentry-curses work if you run gpg2 from the command line? anyway, if you are using GnuPG 2.1, you can try loopback pinentry: ``` shell $ echo allow-loopback-pinentry >> ~/.gnupg/gpg-agent.conf...
Thanks, I have pushed a fix for that as 535673d188da06c6cdbd80a69cc67e09387ef2ae, which fallbacks to ASCII-8BIT if there is any invalid character. Would it make sense, or it would be better to...
It seems to be failing in the Qt binding. Maybe the bundled gpgme should be compiled with ```--disable-languages```.
I'm afraid ruby-gpgme can't do much about that, since the error comes from the gpgme C library itself. you might want to try running the script with `GPGME_DEBUG=9 ruby test.rb`...
hm, actually I missed the NEWS entry of gpgme 1.6.0: ``` - More precise error codes are returned if GnuPG >= 2.1.8 is used. ``` so I guess you might...
@fa-cruzfernandez it doesn't look like the same error as the log contains: ``` GPGME 2018-03-22 00:26:49 gpgme_op_sign_result: check: ctx=0x7f89c410c1b0, result: invalid signer: fpr=(null), reason=No secret key ``` the error seems...
If I remember correctly, it should be already possible. All crypto functions in ruby-gpgme internally use [Callback based data buffers](https://www.gnupg.org/documentation/manuals/gpgme/Callback-Based-Data-Buffers.html#Callback-Based-Data-Buffers), which can be accessed through [Data object](http://www.rubydoc.info/gems/gpgme/GPGME/Data).
I personally am happy with that. My concern is how it affects our development workflow. We currently accept patches from anyone through pull requests, but if the code were hosted...
it seems like an oversight, thanks for the reporting that. would you mind proposing a patch?
While the error message looks interesting, I don't get what you want to achieve. In [public key cryptography](https://en.wikipedia.org/wiki/Public-key_cryptography), you can't decrypt message with a public key.