On Thu, 28 Jan 2016 20:15, r...@sixdemonbag.org said:
> Really? I thought GPGME had a dependency on libgpg-error, and the
> COPYING file for that is clearly GPLv2.
That is just a file. COPYING describes the licence used for the manual
and the tools. COPYING.LIB describes the license for the li
> That is right for GnuPG but not for GPGME. From gpgme/AUTHORS:
Really? I thought GPGME had a dependency on libgpg-error, and the
COPYING file for that is clearly GPLv2.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailma
On 1/28/2016 4:32 AM, Robert J. Hansen wrote:
...
>
> Antony Prince was the guy updating Guardian Project's code. See the
> thread at:
>
> http://www.gossamer-threads.com/lists/gnupg/users/73146
>
> According to Antony, you can grab his updates from:
>
> ftp://blazrsoft.com/gnupg-f
On Thu, 28 Jan 2016 11:54, r...@sixdemonbag.org said:
> The GnuPG developers have historically been unwilling to provide GPGME
> under any terms except the GPL. If you need an LGPLed GPGME, you're out
> of luck.
That is right for GnuPG but not for GPGME. From gpgme/AUTHORS:
License (software)
> Moreover the license is GPL and we would need LGPG. Maybe this point
> could be solved with separate license negotiations.
The GnuPG developers have historically been unwilling to provide GPGME
under any terms except the GPL. If you need an LGPLed GPGME, you're out
of luck.
If you can't/won't
>> But we decided to not use the existing wrapper, because it is old,
>> (seems) unmaintained and we would like to have simpler interfaces and
>> one solution for both, the C++ and Java world. Means: we just want to
>> provide the simple and small interface in C++ and wrap this with JNI
>> for Jav
> According to Antony, you can grab his updates from:
>
> ftp://blazrsoft.com/gnupg-for-java/
>
> It wasn't responding for me just now, though.
His webserver, though, is still going strong. Try:
https://www.blazrsoft.com/gnupg-for-java/
_
> I guess I'm in real trouble now.
Maybe less than you think!
> But we decided to not use the existing wrapper, because it is old,
> (seems) unmaintained and we would like to have simpler interfaces and
> one solution for both, the C++ and Java world. Means: we just want to
> provide the simple a
>From Werner: "gpg2 can't use [custom passphrase handlers] as [using
>gpg-]agent is a hard requirement. The only reason for keeping the
>passphrase callback is for symmetric encryption."
I guess I'm in real trouble now. The reason for this is a bit complex. My
encprytion
class is part of a fram
> Thank you for this encouraging words. In fact I got solved another problem.
Woot!
> The only problem remaining is that the application still ignores my
> own password callback and uses the GnuPG default:
This is actually expected behavior. See:
https://bugs.gnupg.org/gnupg/issue767
>Don't give up!
>So far we've cleared two major problems: the first was GnuPG taking ~15
>minutes to generate a certificate, and the second was GPGME not working
>with your callback. Two major problems solved in two days. Imagine
>what we can get solved by the end of the week.
>Programming is
>I can't get that work. I copy pasted you code in my project and executed your
>main,
>but I still get a 'general error'. In the meanwhile I upgraded my system from
>jesse to
>debian 'testing'. I'm now using GnuPG 2.0.28 and GPGME 1.6 but the problem
>stays the
>same. I build the application wit
I don't have a solution for you, but --
> static gpgme_error_t passphrase_cb(void *hook, const char *uid_hint, const
> char *passphrase_info,
>int prev_was_bad, int fd){
>
> std::string passphraseString;
> std::cout<< "Enter your password:";
> std:
> If your problem is merely lack of entropy on a VM, then I'd recommend
> installing haveged, available in Jessie. It
> broadens the sources used by the kernel for the entropy pool.
Yes, that was the problem. I installed haveged and it worked. But it seems
that the key generation in my C++ appli
> On 27 Jan 2016, at 10:06, Robert J. Hansen wrote:
>
> It compiled and ran just fine. This makes me think the problem is in
> GnuPG's entropy collection and/or key generation -- not your code.
If your problem is merely lack of entropy on a VM, then I'd recommend
installing haveged, available
For the record -- I used the code you provided with three minor changes:
(a) in lieu of CONFIG_DIR, I used nullptr, (b) I released the context at
the end of the code, and (c) I used C++14isms like nullptr, auto, and so
on.
It compiled and ran just fine. This makes me think the problem is in
GnuPG
Von: Daniel Kahn Gillmor [d...@fifthhorseman.net]
Gesendet: Dienstag, 26. Januar 2016 19:30
An: Sandra Schreiner; Robert J. Hansen; gnupg-users@gnupg.org
Betreff: Re: AW: Key generation with GPGME and GnuPG hangs at gpgme_op_genkey
On Tue 2016-01-26 06:02:09 -0500, Sandra Schreiner wrote
On Tue 2016-01-26 06:02:09 -0500, Sandra Schreiner wrote:
[ Robert J. Hansen wrote: ]
>> Are you getting periodic messages about "Not enough random bytes
>> available. Please do some other work to give the OS a chance to
>> collect more entropy! (Need 167 more bytes)" or something like that?
>
>
Von: Gnupg-users [gnupg-users-boun...@gnupg.org]" im Auftrag von
"Robert J. Hansen [r...@sixdemonbag.org]
Gesendet: Dienstag, 26. Januar 2016 11:43
An: gnupg-users@gnupg.org
Betreff: Re: Key generation with GPGME and GnuPG hangs at gpgme_op_genkey
> This
19 matches
Mail list logo
