31–40 of 47 posts
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.
Earlier quoted context omitted.
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?
When I wrote it, though, I was mainly thinking of recent work that converts functional, verified specs into imperative specs that extracts to ML. I think that has a lot of potential for producing a pile of verified data structures with low cost similarly to the COGENT language that was used for ext2 filesystem. Got a link for Imperative/HOL-to-ML below.
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.
A standard without multiple independent implementations is a bit unhealthy..
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.
GPG has a terrible user interface, and it's really hard to script too. It takes a complicated workflow and makes it unbearable.
Just reorganizing existing commands into subcommands like 'gpg encrypt' instead of 'gpg --encrypt' :)
As for key management, keyrings and trust, I think a proper UI with decent explanations would help a lot too. This isn't rocket science, but it's too hard to guess what various abbreviations mean.
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.
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.
Starts about 47:25 in if the time-index doesn't work for you.
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 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 gp…
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.
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…
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.