
NeoPG – an opiniated fork of GnuPG 2 - sphinxc0re
https://neopg.io
======
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.

~~~
lambdafu
Hi, I'm "this guy". Thanks for pointing out -fpermissive, which was needed
during the conversion for the legacy code. Since then I fixed all the
warnings, so I can remove the flag ([https://github.com/das-
labor/neopg/commit/5359aab7885628554c...](https://github.com/das-
labor/neopg/commit/5359aab7885628554cd1c4418f574ed5b2d27e71)).

I would love to do code review, but I need a second developer for that!

Thank you for your interest and taking the time to write down your criticism.

------
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.

~~~
beojan
> 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).

------
techwizrd
I'm glad that folks are starting to take an interest into improving GnuPG (and
PGP in general). I've been working on an SKS replacement[0] in Rust and I've
had to dive into the OpenPGP message format, pgpdump, GnuPG, etc. and it's
definitely a bit of a mess.

0: [https://github.com/srct/sks-rs/](https://github.com/srct/sks-rs/)

------
MrBingley
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 community gradually move to something
simpler, like OpenBSD's signify[0].

[0] [https://www.openbsd.org/papers/bsdcan-
signify.html](https://www.openbsd.org/papers/bsdcan-signify.html)

------
pecg
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 mess.

~~~
nerdponx
They explicitly address the "Why C++?" question here:
[https://neopg.io/blog/cplusplus/](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 concern. The Sequoia Project
uses Rust, and I envy that. But the first thing they had to do was to wrap an
existing C crypto library (they choose libnettle), because there is no high
quality crypto library for Rust yet. That is their challenge.

My challenge will be to stay focussed on the parts of C++ that are actually
helpful, and not get bogged down by the rest._

~~~
vvanders
> 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.

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

~~~
adultSwim
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!

------
jancsika
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.

~~~
aparadja
Not exactly related to NeoPG, but GPGME in general: Doesn't GPGME assume that
the user already has GnuPG 2.x installed and running on their system?

This might just be a misconception I have, but I always thought you couldn't
make a batteries-included, self-contained, works-out-of-the-box app if you
used GPGME. You'd first have to tell the user to go get a GnuPG implementation
from somewhere.

I'd be super happy to be wrong on this.

------
agrinman
Glad someone is working on this!

One of the reasons we built PGP signing capabilities into Krypton [0] is to
make it easy for anyone to sign their Git commits/tags. Almost nobody uses
this awesome feature of Git. We even ended up implementing parts of the
OpenPGP spec in Swift [1].

0: [https://krypt.co/docs/start/code-
signing.html](https://krypt.co/docs/start/code-signing.html)

1: [https://github.com/kryptco/swift-pgp](https://github.com/kryptco/swift-
pgp)

------
rcdwealth
[https://github.com/das-
labor/neopg/blob/master/license.txt](https://github.com/das-
labor/neopg/blob/master/license.txt)

It may be opinionated but not well thought of a fork.

How is possible to take GPL 3.0 code, say how it is "more restricted", miss to
mention the point of what would happen if it is not, and to claim that any
additional code to the project shall be licensed under the BSD type of the
license.

The author has some serious misunderstands about licensing issues.

------
etu
I did see this during day 4 of 32C3's Lightning talks. Found the link with
time-index here:
[https://media.ccc.de/v/34c3-9258-lightning_talks_day_4#t=284...](https://media.ccc.de/v/34c3-9258-lightning_talks_day_4#t=2845)

Starts about 47:25 in if the time-index doesn't work for you.

------
vesinisa
Sounds great. I always wondered why GPG was so complex.

~~~
sigsergv
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.

~~~
Shoothe
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? Negotiating algorithms to use?

~~~
zokier
> 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...](https://github.com/keybase/keybase-
issues/issues/2230#issuecomment-239637659) 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.

~~~
JdeBP
Note that, per the blurb at hand, NeoPG is intentionally even more monolithic.

------
exabrial
Nice! I like the idea from the descriptions on the first page

