Maximo Pech [mak...@gmail.com] wrote: > > I already knew an answer (not the only one) could be "write it". >
What others did you have in mind? "Thank you for bringing the most important software project of modern time to our attention. We will now begin writing it for you." ??? > > > > > > Do you have any idea how abusrd this is? > > No I don't, if you don't mind please explain why that's absurd. > > That's completely subjective and also it is a problem that has more work > behind than the "problem" I think there is with the non existence of bsd > tools like gnupg on *base* not on ports and not openssl. > It's not subjective. It's history. SSH.COM became the standard for people who need to manage hundreds of thousands of keys with a rolled-out package. OpenSSH became the GOLD standard because EVERYONE ELSE uses it and it has a very high quality track record. I can only imagine that SSH was conceived as telnet + PGP. PGP was its own standard, improved and turned into a commercial product and now nobody even remembers exactly what it does. Do you use PGP? GnuPG? .... This part is subjective. How useful is PGP to you? > What I say is simply that it would be cool if by default on the *base* > system OpenBSD had a tool called opgp, opengp, puffypg or whatever, to > encrypt files like gnupg does and I was wondering why it does not exist if > OpenBSD cares a lot about cryptography. > OpenBSD's push was to more tightly integrate crypto into all parts of the system where it might prove to be useful. One big part of this is the inclusion of the OpenSSL package for userland apps. Another was the creation of OpenSSH. And another was the OCF which allows the kernel to use crypto in all manner of operations. And it does. OpenBSD was really the first full free IPsec stack with a complete free OS and key management all working out of the box with photurisd and later isakmpd. It was more advanced, at the time. Along came OCF, which the framework that other BSDs built on and improved for their kernel crypto subsystems. It was ported to linux as a significant improvement to their prior kernel crypto tools. OCF is no longer the last word. Processors now include direct crypto transforms, so this area is changing again. But nobody had a sane asynchronous framework for crypto performed in the kernel context (for disk, network, memory crypto operations) prior to OCF. These are major things that took lots of time and money, DoD funding even. And it was accomplished under the OpenBSD project, and crypto accelerator support was merged with OpenSSL and benefits everyone now, kernel and userland. That is why OpenBSD is proud of crypto. Not because we care about encrypting files. Although, you can use OpenS! SL+OCF accelerators to do that too, if you wish. > Well, with the information you have given me so far, I think the answer is > something like "nobody has written it because we have more important things > to do and nobody believes there is a real need for that". Am I right? Yeah. Essentially, if you wanted to clean up netpgp and port it over to take full advantage of openssl+OCF, that would fit right in the plan. But otherwise, you're missing the history here. Work done is driven by desire and finances. Just like everything else in life. The absurdity is in not understanding the magnitude at which OpenBSD attempted to integrate crypto into everday computing life, just because the solution you imagined isn't part of the base52.tgz.
