Please support GCRYSEXP_FMT_BASE64
Open, NormalPublic

Description

The gcry_sexp_sprint function in libgcrypt doesn't work as expected when the
specified format is GCRYSEXP_FMT_BASE64. I ran into this issue using the fink-
installed version of libgcrypt-1.4.4 on Mac OS X 10.6.5, but I also looked at
the code for libgcrypt-1.4.6 and it seems like it was just never implemented.
The sexp_sscan function also doesn't accept base64-encoded input, looks like
that was also never implemented.

I've attached a test case that demonstrates the problem; the output should be
base64-encoded but instead binary is dumped. I was able to compile on my
machine using "gcc -arch i386 -I/sw/include -L/sw/lib -lgcrypt test.c";
presumably you can get it to compile in your environment without much trouble.

Details

Version
1.4.4

Related Objects

StatusAssignedTask
OpenNone
OpenNone
staktrace set Version to 1.4.4.Dec 3 2010, 8:00 AM
staktrace added projects: libgcrypt, Bug Report.
staktrace added a subscriber: staktrace.

werner added a subscriber: werner.Feb 21 2011, 2:38 PM

The manual clearly states:

@item GCRYSEXP_FMT_BASE64
Not currently supported.

Thus I lower the priority. Do you have a real use case for this?

werner removed a project: Bug Report.

We should address this in 1.6

werner renamed this task from libgcrypt - base64 output format doesn't work to Please support GCRYSEXP_FMT_BASE64.Dec 10 2013, 3:08 PM
justus added a subscriber: justus.Dec 7 2015, 2:45 PM

I'd be happy to implement this, but it is not clear to me how. Merely base64
encode the default representation? Or the canonical representation?

In sexp.c we use suitable_encoding to decide on how to print the value: Either
as token, as an escaped string or as a hex-string. This is only done when using
FMT_ADVANCED. We could come up with some heuristics on how to print in base64
instead of hex (i.e. |YWJj| instead of #616263#) but that has the drawback that
the output would not be readable by older versions of libgcrypt.

Hwoever, what can be done is to make do_vsexp_sscan work with base64 encoding -
as of now such a value is simply ignored.