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

11–20 of 47 posts

Re: NeoPG – an opiniated fork of GnuPG 2

#11

Post by b5 »

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…

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

Re: NeoPG – an opiniated fork of GnuPG 2

#12

Post by wyager »

zerokernel wrote: post #7
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…

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…

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.

Re: NeoPG – an opiniated fork of GnuPG 2

#13

Post by hh3k0 »

wyager wrote: post #12
zerokernel wrote: post #7

Earlier quoted context omitted.

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…

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?

Re: NeoPG – an opiniated fork of GnuPG 2

#14

Post by qubex »

b5 wrote: post #11
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…

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

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.

Re: NeoPG – an opiniated fork of GnuPG 2

#15

Post by eximius »

zerokernel wrote: post #7
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…

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…

Comments like these bore me, to be honest.

We all know C++ is a valid design decision. We all know more hip languages have underdeveloped ecosystems. Yet opinions on which language to choose are not devoid of value because it indicates interest, sparks conversations, and may initiate development of the tools needed to make them less 'underdeveloped'.

The only thing we don't need is people saying another person's opinion is boring.

EDIT: Also, they said they were disappointed they used C++. Maybe they wished they stuck with C?

Re: NeoPG – an opiniated fork of GnuPG 2

#16

Post by xiphias »

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?

At this point Rust is the clear winner, as it's providing higher safety for similar run-time speed.

Re: NeoPG – an opiniated fork of GnuPG 2

#17

Post by heavenlyblue »

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 think while I probably understand the underlying concepts better (cryptography-wise), there isn't much _practical_ infromation about GPG in the wild.

Just as much as knowing how git works under the hood doesn't necessarily make you great at managing branches in git. More often than not it's way easier to just go with a sort of ready-made recipe, so that your workflow would be easily accepted by the industry; rather than read the doc.

Re: NeoPG – an opiniated fork of GnuPG 2

#18

Post by 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

1: https://github.com/kryptco/swift-pgp

Re: NeoPG – an opiniated fork of GnuPG 2

#19

Post by akvadrako »

sigsergv wrote: post #5
vesinisa wrote: post #4

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

GPG has a terrible user interface, and it's really hard to script too. It takes a complicated workflow and makes it unbearable.

Re: NeoPG – an opiniated fork of GnuPG 2

#20

Post by Promarged »

heavenlyblue wrote: post #17
Shoothe wrote: post #9

Earlier quoted context omitted.

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 think while I probably understand the underlying concepts better (cryptography-wise), there isn't much _practical_ infromation about GPG in the wild. Just as much as knowing how git works under the hood doesn't necessarily make you great at managing branches in git. More often than not it's way easier to just go with a sort of ready-made recipe, so that your workflow would be easily accepted by the industry; rather…

I think except the cryptography there is just trust calculations and encoding.

These two articles describe trust in detail:

https://www.linux.com/learn/pgp-web-trust-core-concepts-behi...

https://www.linuxfoundation.org/blog/pgp-web-of-trust-delega...

GPG esoteric options is also a good read:

https://www.gnupg.org/documentation/manuals/gnupg/GPG-Esoter...

Besides that... the RFC itself I suppose:

https://tools.ietf.org/html/rfc4880

Post reply on HN