Live data from Hacker News

NeoPG – an opiniated fork of GnuPG 2

neopg.io

41–47 of 47 posts

Re: NeoPG – an opiniated fork of GnuPG 2

#41

Hmmm, I don't think converting a 500k codebase in C to C++ has a meaningful cost/benefit ratio, especially for security critical code like this. It might be justified to do in something like Rust, but at that point I think it's better to move on from GPG entirely. The OpenPGP standard itself is showing its age (eg. no perfect forward secrecy) and is extremely complicated. I think GPG should be left as-is, and the com…

You might want to check out https://sequoia-pgp.org - a new OpenPGP implementation written from scratch in Rust within the PEP project.

Re: NeoPG – an opiniated fork of GnuPG 2

#42

Should the NeoPG project mention why GPGME wasn't a suitable compromise? I understand the author wants to clean up the core and the API, but if there's already a project that cleans up the API isn't that good enough? Especially considering the standard it implements-- PGP-- is still quite complicated.

Yes, I should document that. GPGME only exposes a high-level API, and application developers often want more control. For example, you can't inspect key material before importing it, but importing a key is not a reversible operation - so applications sometimes use a temporary HOMEDIR for GPGME/GnuPG to import the key there and inspect it with a keylisting. It can be very cumbersome.

Re: NeoPG – an opiniated fork of GnuPG 2

#43

> C++ is the better C Oh no it isn't. It does have more features, and for some fields, sure it is better (user interfaces, simulations). However, this is security software we are talking about. C++ introduces more complexity as the spec is an order of magnitude bigger than, say, C99. More complex language spec, more complex tooling, lots of places for bugs to hide. It can help with classic buffer overflows and the li…

> Converting the legacy code base (490,000 lines of code) to C++ was a straightforward, mechanical task that took only a couple of hours

That sounds like they haven't actually converted it to C++ so much as compiled it as C++.

That means they're probably still using raw owning pointers and no RAII, which means you get none of the safety benefits of C++ (which do exist, so long as you use modern C++ practices like smart pointers, and containers instead of C-style arrays).

Re: NeoPG – an opiniated fork of GnuPG 2

#44
post #43

> C++ is the better C Oh no it isn't. It does have more features, and for some fields, sure it is better (user interfaces, simulations). However, this is security software we are talking about. C++ introduces more complexity as the spec is an order of magnitude bigger than, say, C99. More complex language spec, more complex tooling, lots of places for bugs to hide. It can help with classic buffer overflows and the li…

> Converting the legacy code base (490,000 lines of code) to C++ was a straightforward, mechanical task that took only a couple of hours That sounds like they haven't actually converted it to C++ so much as compiled it as C++. That means they're probably still using raw owning pointers and no RAII, which means you get none of the safety benefits of C++ (which do exist, so long as you use modern C++ practices like sma…

This is true. But it is a necessary first step and some refactoring has already been done. It's a long way.

Many comments here are missing the main inspiration of using C++, which is the Botan crypto library.

Re: NeoPG – an opiniated fork of GnuPG 2

#45
post #6

Earlier quoted context omitted.

They explicitly address the "Why C++?" question here: https://neopg.io/blog/cplusplus/ Choice quote: There are many programming languages, and I believe in picking the right tool for the job. In the case of NeoPG, the priorities were: - Support for strong cryptography. - Compatibility with C application developers. - Convert legacy code quickly. - Tool support for QA. Everything else is, at this point, a secondary co…

> wrap an existing C crypto library I know it's mostly semantics but calling C from C++ still requires some wrapping(extern "C", integrating build system, etc). I've found with bindgen unless there's some crazy macro shenanigans going on it's actually quicker for me to integrate C libraries into Rust then wrangling CMake/Make/etc. The C FFI is very much a first-class citizen in Rust. Even doubly so if we're talking a…

NeoPG uses Botan, which is a crypto library written in C++. I recommend reading its source code and comparing it with, for example, libgcrypt.

Re: NeoPG – an opiniated fork of GnuPG 2

#46
post #27

Earlier quoted context omitted.

What do you mean by imperative ML? Using a language from the ML family, but mostly its imperative features? Can you expand on that?

Yeah, I should have. There's been prior work porting linear types and other stuff (think Rust safety) like that to ML since that's an easy-to-analyze language academics like to work in. Tolmach et al actually made a converter for it to Ada one time. ML is also the language that most formal verification extracts to by default. CakeML is a verified compiler for ML. There's flow analysis and concurrent variants for it.…

I didn't expect anything interesting to come up as replies, but here we are - thanks for those insights.

Re: NeoPG – an opiniated fork of GnuPG 2

#47

Earlier quoted context omitted.

> wrap an existing C crypto library I know it's mostly semantics but calling C from C++ still requires some wrapping(extern "C", integrating build system, etc). I've found with bindgen unless there's some crazy macro shenanigans going on it's actually quicker for me to integrate C libraries into Rust then wrangling CMake/Make/etc. The C FFI is very much a first-class citizen in Rust. Even doubly so if we're talking a…

NeoPG uses Botan, which is a crypto library written in C++. I recommend reading its source code and comparing it with, for example, libgcrypt.

Is most of the removed code functionality that is now in the crypto library used, Botan?

A blog post on the decision to use an external library might be good. Is there a reason to think that the library will be better maintained than code with similar functionality in GPG?

Great work by the way! Thank you!

Post reply on HN