8 ms·

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 id

by pecg 9y ago

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 9y ago
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.
- nickpsecurity 9y ago
  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.
- vvanders 9y ago
  > 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 9y ago
    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 9y ago
      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!
zerokernel 9y ago
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.
- wyager 9y ago
  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 historically one of the biggest attack vectors out there.
  - hh3k0 9y ago
    Okay, I'll bite. What language would be "a great choice" for complex cryptography applications, in your opinion?
    - xiphias 9y ago
      At this point Rust is the clear winner, as it's providing higher safety for similar run-time speed.
    - wyager 9y ago
      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.
    - nickpsecurity 9y ago
b5 9y ago
What $LANG would you use if you had the time to dedicate to the project and were rewriting it starting today? Why would you choose $LANG? (Not an attack -- a genuine question because I'm interested in your choice and reasoning.)
- qubex 9y ago
  I’m not faulting you at all, but... different people know different tools, place premiums on different features, and of reach different conclusions as to what they wish to use. It's just an opinion, and comparing opinions is such a sterile exercise. Whatever value you assign to $LANG, you will always encounter a denizen on HackerNews that disparages $LANG and would've used $LANG-prime, but by not actually moving first to start a project to achieve that aim with the tool of their choice, they kind-of ceded their right to criticise. That’s my point of view, at least: don't criticise the artist's choice of tools. It's rude.
emmelaich 9y ago
Using C++ by no means implies using OOP. C++ has an excellent C FFI :-)

by pecg 9y ago

nerdponx 9y ago

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.

nickpsecurity 9y ago
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.
vvanders 9y ago
> 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 9y ago
  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 9y ago
    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!

zerokernel 9y ago

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.

wyager 9y ago
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 historically one of the biggest attack vectors out there.
- hh3k0 9y ago
  Okay, I'll bite. What language would be "a great choice" for complex cryptography applications, in your opinion?
  - xiphias 9y ago
    At this point Rust is the clear winner, as it's providing higher safety for similar run-time speed.
  - wyager 9y ago
    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.
  - nickpsecurity 9y ago

b5 9y ago

What $LANG would you use if you had the time to dedicate to the project and were rewriting it starting today? Why would you choose $LANG? (Not an attack -- a genuine question because I'm interested in your choice and reasoning.)

qubex 9y ago
I’m not faulting you at all, but... different people know different tools, place premiums on different features, and of reach different conclusions as to what they wish to use. It's just an opinion, and comparing opinions is such a sterile exercise. Whatever value you assign to $LANG, you will always encounter a denizen on HackerNews that disparages $LANG and would've used $LANG-prime, but by not actually moving first to start a project to achieve that aim with the tool of their choice, they kind-of ceded their right to criticise. That’s my point of view, at least: don't criticise the artist's choice of tools. It's rude.

emmelaich 9y ago

Using C++ by no means implies using OOP. C++ has an excellent C FFI :-)