Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

NeoPG – an opiniated fork of GnuPG 2

neopg.io

Post reply on HN
Print view View original

21–30 of 47 posts

Re: NeoPG – an opiniated fork of GnuPG 2

#21

Post by zokier »

Shoothe wrote: post #9
sigsergv wrote: post #5

Earlier quoted context omitted.

GPG is not that complex, but PGP concept, keys structures and workflows - they are really hard. And this project has to implement all those hard elements too.

OpenPGP is kind of like git - if you understand the underlying concepts (in case of OpenPGP this is RFC 4880) then it is simple. GPG is very old and created in different times so it has many quirks at the implementation and UI level but I find the encoding and structures quite simple (there are some weird choices of course). I wonder what do you think is complex? Trust model maybe? Different kinds of signatures? Nego…

> I wonder what do you think is complex?

For me it culminates in the way gpg feels really opinionated about key management (with keyrings). Way too often (in relative terms) I end up creating a temp dir, setting GPGHOME, then setting some permissions to quiet up gpg, then importing the keys, then actually doing the thing I wanted, and finally cleaning up[1]. I have no doubt the keyring design works wonderfully for gpgs author(s), but for a tool that should really be more generic than that it feels less ideal.

gpg being as monolithic as it is probably is the fundamental problem here which, in addition to making it unnecessarily cumbersome to use in some cases, also makes it more difficult to learn piecewise (imo).

[1] For one example, see my comment here: https://github.com/keybase/keybase-issues/issues/2230#issuec... That operation should be basically "curl ..|gpg-key --to-ssh", but instead it exploded into 10 line bash script, complete with parsing gpg output with grep/awk.

Re: NeoPG – an opiniated fork of GnuPG 2

#23

Post by wyager »

hh3k0 wrote: post #13
wyager wrote: post #12

Earlier quoted context omitted.

The fact that C++ is so widely used reflects the fact that it’s both old and acceptably designed. It does not even remotely indicate that it’s universally a good tool choice. I think C++ is not a great choice for complex crypto software because it doesn’t have very good safety-by-construction properties and it has to deal with (extremely) untrusted and probably malicious input. Parsers written in C or C++ are histori…

Okay, I'll bite. What language would be "a great choice" for complex cryptography applications, in your opinion?

Depends on the application. I would personally use Rust for embedded applications (since it’s low-overhead and ADTs are basically a requirement for safe parsers) and Haskell for non-embedded. But if neither of those float your boat, there are other safe-by-construction parser-friendly languages available, mostly from the ML family.

Re: NeoPG – an opiniated fork of GnuPG 2

#24

Post by nickpsecurity »

nerdponx wrote: post #6
pecg wrote: post #3

Writing a competent, simple replacement for GnuPG, yet PGP fully compatible, is one of the things I plan to do on the long road, thus I think neopg is a good idea, except the fact that they decided to use C++. I know that type safety is one of the considerations, but OOP always results in ambiguous unnecessarily complex code, and for me that defeats the purpose of simplicity. Nevertheless, the GnuPG codebase is a mes…

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…

Is using a C library or crypto library that hard in Rust? That's first Ive heard of it being a problem. In high-assurance, it was standard to limit unsafety to the stuff behind interfaces of unsafe modules (incl FFI) in otherwise memory-safe, systems language. We didn't see this as a detriment esp if was C with its wide support.

Re: NeoPG – an opiniated fork of GnuPG 2

#25

Post by vvanders »

nerdponx wrote: post #6
pecg wrote: post #3

Writing a competent, simple replacement for GnuPG, yet PGP fully compatible, is one of the things I plan to do on the long road, thus I think neopg is a good idea, except the fact that they decided to use C++. I know that type safety is one of the considerations, but OOP always results in ambiguous unnecessarily complex code, and for me that defeats the purpose of simplicity. Nevertheless, the GnuPG codebase is a mes…

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 about a cross-platform library.

Re: NeoPG – an opiniated fork of GnuPG 2

#26

Post by nickpsecurity »

hh3k0 wrote: post #13
wyager wrote: post #12

Earlier quoted context omitted.

The fact that C++ is so widely used reflects the fact that it’s both old and acceptably designed. It does not even remotely indicate that it’s universally a good tool choice. I think C++ is not a great choice for complex crypto software because it doesn’t have very good safety-by-construction properties and it has to deal with (extremely) untrusted and probably malicious input. Parsers written in C or C++ are histori…

Okay, I'll bite. What language would be "a great choice" for complex cryptography applications, in your opinion?

Ada with SPARK Ada variant and careful refcounting wouldve been my baseline given it's all safe by default before Rust came along. D also had potential. Now Rust with SPARK. Im keepimg SPARK in for semi-automated verification. Just rewriting Skein's C code in SPARK automatically found an error thanks to prover. If affording specialists, then something like F star used in miTLS verified stack, Isabelle/HOL, Jasmin language, and/or imperative ML. All core, trusted functionality done that way.

I choose languages with tight control on memory for crypto-related stuff since you want to prevent leaks. You'll follow with a covert-channel analysis to be sure. If not crypto and stopping code injection, then a memory-safe language with interface checks and input validation will cover most problems. Those have been around since one was deployed in first, business mainframe: Burroughs B5000.

Re: NeoPG – an opiniated fork of GnuPG 2

#27

Post by hiq »

nickpsecurity wrote: post #26
hh3k0 wrote: post #13

Earlier quoted context omitted.

Okay, I'll bite. What language would be "a great choice" for complex cryptography applications, in your opinion?

Ada with SPARK Ada variant and careful refcounting wouldve been my baseline given it's all safe by default before Rust came along. D also had potential. Now Rust with SPARK. Im keepimg SPARK in for semi-automated verification. Just rewriting Skein's C code in SPARK automatically found an error thanks to prover. If affording specialists, then something like F star used in miTLS verified stack, Isabelle/HOL, Jasmin lan…

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

Re: NeoPG – an opiniated fork of GnuPG 2

#28

Post by Sir_Cmpwn »

The switch to C++ is incredibly poorly justified. I don't care how much safer you think it is (and it really isn't), the language is way more complicated and error-prone and rewriting the code is ALWAYS going to introduce many, many bugs than would be found by simply maintaining the code. This guy also switched on -fpermissive as part of the process, which disables warnings which are there for a reason! This guy has also done a lot of lovely things like committing half-assed changes to master (the build breaks more often than it passes!) which have clearly undergone no review.

Anyone this person convinces to use and contribute his fork are going to take time and money (yes, money - the guy put up a Patreon campaign and BountySource page) away from GnuPG, which sorely needs it, as we all hopefully remember. Please do not use this, and I hope the authors give it up.

Re: NeoPG – an opiniated fork of GnuPG 2

#29

Post by emmelaich »

pecg wrote: post #3

Writing a competent, simple replacement for GnuPG, yet PGP fully compatible, is one of the things I plan to do on the long road, thus I think neopg is a good idea, except the fact that they decided to use C++. I know that type safety is one of the considerations, but OOP always results in ambiguous unnecessarily complex code, and for me that defeats the purpose of simplicity. Nevertheless, the GnuPG codebase is a mes…

Using C++ by no means implies using OOP.

C++ has an excellent C FFI :-)

Re: NeoPG – an opiniated fork of GnuPG 2

#30

Post by outworlder »

> 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 like, sure. But it introduces its own set of issues.

>Many of these issues are well-known or can be easily researched. They have been documented many times, and can be avoided.

Right. The issues can be avoided. You just need to not make mistakes, right?

Also, this is worrying:

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

So we are good? The fact that it compiles (and maybe even works) doesn't automatically validates it as a secure rewrite (and it is a rewrite, no matter how similar the common language set is). The stakes are just much higher for something like GPG.

I do wish this project good luck, though.

Post reply on HN