On Sep 29, 2008, Francois Marier wrote:
> On 2008-09-25 at 21:27:05, Michael Rash wrote:
> > In most GnuPG installations that I've seen, the beginning of
> > gpg-encrypted data begins with 0x8502, and even the file 'magic'
> > database uses this to identify such data. May I ask which version of
> > GnuPG you have installed on your client system, and which Linux/other
> > distro it is?
Hi Francois -
Here is a link to fwknop-1.9.8-pre3:
I've made a few changes that should help with the issues that you are
seeing. First, I've added a few features to the access.conf file that
allow the path to the gpg binary to be specified on a per-SOURCE basis,
so if you want to use gpg2 for some incoming SPA packets vs. gpg for
others, you can express this. The gpg path is explicitly set via a new
GPG_PATH variable in access.conf, but defaults to the gpgCmd setting in
fwknop.conf (or your system path as usual if this is not set in
fwknop.conf). There is also a new variable GPG_NO_REQUIRE_PREFIX to
skip the expected prefix requirement before sending SPA packets to the
gnupg decryption routine after base64 decoding. Finally, the prefix
can be manually set to whatever you like with a new variable GPG_PREFIX,
but I wouldn't recommend this - we should try to get things working
without it. The previous options are now documented in the fwknopd.8
man page as well.
Most importantly, I've removed the strict requirement for the decoded
0x8502 prefix since the base64 encoded version is enough (and is now
There are also several new tests in the test suite to test gpg2 and a
few other things.
I believe that Franck Joncourt may be able to create a new Debian
package from the -pre3 release (-pre2 is also available at the expected
path if necessary).
> Alright, I re-generated 1024 bit keys on GPG 1.4 and re-ran this test with
> fwknopd --debug --verbose
> I still got the same thing:
> Mon Sep 29 14:39:41 2008 [-] base64-decoded data does not begin with 0x8502
> Mon Sep 29 14:39:41 2008 [-] Failed decrypt for SOURCE block ANY
> So it looks like it's not limited to GPG 2.x.
> Also, I have never been able to use 2048 keys with fwknop client, I always
> get packets which are too big. Is it even possible? Even using
> --gpg-no-options, I could not do it. Maybe the documentation should state
> that we have to use 1024 bit keys?
In my experience, fwknop does work with 2048-bit keys, and with both gpg
and gpg2. For example, the keys bundled with the test suite are 2048 bits,
and I believe those tests ran fine on your system. Now that the test suite
also includes tests for gpg2, it would be interesting to run the following
to run the GnuPG tests on your system once again:
# cd fwknop-1.9.8-pre3/test
# ./fwknop_test.pl --test-include "GnuPG"
I know that using the "encrypt-to" option can result in an SPA packet
encrypted with a 2048-bit key to be longer than expected (as reported by
Mike Holzman), but the --gpg-no-options arg should have taken care of
this I would have thought.
Can you try running the fwknop client against -pre3 with the following
--Include-gpg-prefix --Include-equals --gpg-no-options
This will cause the fwknop client to alter the outgoing SPA packets to
the minimum degree. I may make this behavior the default.
On your system, did you install a normal gnupg package? No special
compile options, etc.?
If you create a new user on your fwknop client system and then execute
the fwknop client, are there any differences? (So the .gnupg directory
will be brand new, etc.) We'll get to the bottom of this...
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> Fwknop-discuss mailing list