| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When `GNUNET_OS_init' is called to change the application project data,
lazy-loading plugins will fail as it will not find the requested files.
The function will temporarily swap the project data with the argument value
and will search for plugins, within the installation directory tree inferred
from that structure.
Applications can still use `GNUNET_PLUGIN_load_all' to load their plugins from
within their own installation directory tree, though services are recommended
to use the `in_context' version to avoid falling in the same pit.
Signed-off-by: Martin Schanzenbach <mschanzenbach@posteo.de>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Hi,
find attach the patch which makes all 3 test cases work with Ed25519.
There are some minor hacks in the test cases to allow enabling of
Libgcrypt debugging and also some minor output style changes.
There is one FIXME in the code:
/* FIXME: mpi_print creates an unsigned integer - is that intended
or should we convert it to a signed integer (2-compl)? */
mpi_print (xbuf, sizeof (xbuf), result_x);
X may be positive or negative but GCRYMPI_FMT_USG ignores the sign.
Thus this is not what we actually want. Should we change it to 2-comp
(GCRYMPI_FMT_STD) so that we have a proper value? Given that the curve
is 255 bit this should alwas fit int the 256 bit buffer. Another option
would be to use the EdDSA method for the sign but that is optimized to
easily recover x and would be more work. Or we store the sign in the
high bit. t all depends on what you want to write into the protocol
specs.
I would also like to revert the way we distinguish between Ed25519 with
and without ECDSA: The way we do it right now is by assuming the
Ed25519 is always used with EdDSA unless a flag has been set. This is a
bit surprising and requiring the "(flags eddsa)" would be a less
surprising interface.
Salam-Shalom,
Werner
|
