Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Plans for supporting reading and verification #100

Open
8W9aG opened this issue Nov 5, 2021 · 3 comments
Open

Plans for supporting reading and verification #100

8W9aG opened this issue Nov 5, 2021 · 3 comments

Comments

@8W9aG
Copy link
Contributor

8W9aG commented Nov 5, 2021

Is there any work being planned to support reading and verification of the SXG format using libsxg?

@twifkak
Copy link
Collaborator

twifkak commented Nov 5, 2021

Google has no short term plans, but it's definitely of interest for the long term.

  • Our implementation is in C++ and uses several internal libs in our monorepo, so it's hard to extract.
  • I'd like to release a reference implementation for an SXG cache (including verification), but am leaning towards Rust for memory safety. Let me know if you have compelling reasons for a C implementation first.
  • In the meantime, I'd welcome external contributions. (With a "things may break" disclaimer until the design is stabilized and behavior well-tested.)
  • Alternatively, it may be possible to libify chromium's parser, though I don't know how easy. It has a lot of deps on other parts of chromium.

@8W9aG
Copy link
Contributor Author

8W9aG commented Nov 5, 2021

I don't really have a compelling reason for a C implementation first, my project uses C++ so I guess it would suit me to have it that way but that sounds more like a me problem. Would you welcome contributions made to this repo, first by adding a parser for the format, and after that adding verification methods?

Thanks for the links to chromiums parser, its a great reference.

@twifkak
Copy link
Collaborator

twifkak commented Nov 5, 2021

Yeah, that plan sounds great. Some recommendations (but I'm flexible):

  • If the new feature dramatically increases the binary size or adds new dependencies, put it behind a cmake option.
  • If possible, avoid OpenSSL functions that aren't also available in BoringSSL. (We made that mistake, and had to add some ifdefs and cmake options to address that retroactively.)

As an aside, it seems like you can embed Rust in C. AFAIK it has a minimal runtime but I'm not an expert.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants