Create a CMake-importable library for creating/parsing SEXP

[ronaldtse]

The reference implementation is at: https://people.csail.mit.edu/rivest/sexp.html

We must also wrap this with tests as provided:

Here are some sample inputs and outputs (warning: while these look like SDSI/SPKI files, they are only approximations).

canonical transport advanced

[ronaldtse]

The specification is available here: https://people.csail.mit.edu/rivest/Sexp.txt

[maxirmx]

@ronaldtse @ni4 Do you have any idea what interface would be convinient for rnp ? This project is not really structured as "library" and application on top of it and it gives a freedom to create whatever is convinient.

[ni4]

@maxirmx Please take a look at key_store_g10.cpp and g10_sexp.hpp from the RNP project. I added some basic C++ interface for s_exps there on top of C functions, so you may reuse it.

[maxirmx]

There are several C++ libraries that implement S-expressions:

• https://github.com/BitPuffin/sexpresso
• https://github.com/mjsottile/sfsexp
• https://rosettacode.org/wiki/S-expressions

Unfortunately, all of them lack systematic tests.

I think I will start with creation of a generic test site and also with tests that will ensure compatibility with this implementation: https://www.gnupg.org/documentation/manuals/gcrypt/S_002dexpressions.html

[maxirmx]

I pushed a version 0.1.0 that is:

• fully compatible with all encoding methods from original code
• have reasonable number of tests (Ubuntu only)
• have reasonable memory management that was missing in the origibal code
• is CMake importable

Plan:

1. apply clang formatting and naming conventions (to some extent) from core rnp projects
2. add ASAN tests
3. add tests for other platforms
4. implement rnp bindings (https://github.com/rnpgp/sexp/issues/1#issuecomment-1286707854)
5. implement GnuPG parser on top of SEXP since newer version of GnuPG does not use SEXP. They use some custom key-value format that may have mangled SEXP as a value field.

For items 4,5 I need an advise. Do we want this code to be a part of sexp library (a kind of out-of-context) or to have a separate module (adds support burden). I do not like either so I am open for suggestions

[ni4]

@ronaldtse Do we need to have GnuPG g10-g21 keyring parser anywhere else than RNP? I don't think this gets much of use without the OpenPGP parser. My suggestion would be to just include these code into the RNP code (adding some CI to check whether it is up-to date) to avoid complexity of additional dependency, and update key_store_g10.cpp and g10_sexp.hpp/.cpp to use it instead of already existing one.

[ronaldtse]

Agree with @ni4 -- OpenPGP related code, such as GnuPG compatibility code should be done outside of this particular repository. This should be done in RNP (or a sub-library of RNP, same or separate repository).

implement GnuPG parser on top of SEXP since newer version of GnuPG does not use SEXP. They use some custom key-value format that may have mangled SEXP as a value field.

It should likely be a separate library?

[maxirmx]

@ronaldtse @ni4

It should likely be a separate library?

Let it be "gpg keystore module". It will be isolated enough to easily become a separate (albeit small) library. I would make it a library if we expect there to be any format changes that require periodic maintenance. (I'm sorry, my experience is very far from pgp and its lifecycle)