NeoPG – an opiniated fork of GnuPG 2
1–10 of 47 posts
Re: NeoPG – an opiniated fork of GnuPG 2
#2[deleted]
Re: NeoPG – an opiniated fork of GnuPG 2
#3Writing 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.
Re: NeoPG – an opiniated fork of GnuPG 2
#4Sounds great. I always wondered why GPG was so complex.
Re: NeoPG – an opiniated fork of GnuPG 2
#5Sounds great. I always wondered why GPG was so complex.
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.
Re: NeoPG – an opiniated fork of GnuPG 2
#6Writing 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 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.
Re: NeoPG – an opiniated fork of GnuPG 2
#7Writing 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…
C++ has a long and successful history of application development, regardless of project size (from 0 to >100 MLOC; from 1 guy sitting in his attic to thousands of engineers). Much like Java it isn't "hip". Instead people like to use "hip" languages with an underdeveloped ecosystem. Typical example: analysis tools, e.g. code analysers, performance and profiling tools.
Comments like "couldn't they have used $niche-lang.org instead of [C++/Java/...]" bore me, to be honest.
Re: NeoPG – an opiniated fork of GnuPG 2
#8Sounds great. I always wondered why GPG was so complex.
Don't confuse arcane and complex. Although PGP is a 90s crypto standard, so it's more than likely a nightmare to implement.
Re: NeoPG – an opiniated fork of GnuPG 2
#9Sounds great. I always wondered why GPG was so complex.
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? Negotiating algorithms to use?
Re: NeoPG – an opiniated fork of GnuPG 2
#10I'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.