The developer of Picocrypt is archiving the project:
Since it won’t be getting any more security updates, Picocrypt should be removed from the site.
PR: update!: Remove Picocrypt by friadev · Pull Request #3086 · privacyguides/privacyguides.org · GitHub
Key kicker here is MacOS support.
While it won’t magically become useless in the future for Linux and Windows users , the lost of cross-platform support is a clear violation of the criteria we established.
Even if MacOS support wasn’t an issue, wouldn’t it be kind of odd to have an archived project remain recommended?
You may want to read his statement on the forum and draw your own opinions on whether that is true or not. I am generally against the inclusion of archived projects.
Is there any actual proof that macOS is going to drop openGL soon™?
No, but it is marked as deprecated so it’s very likely it’ll be removed at some point. Especially with the last few Intel macs hitting end of software support, I’d expect Apple to clean up old stuff like OpenGL within the next 3 macOS releases. I would be happy to be proven otherwise, of course.
Some side info: even though OpenGL is deprecated, credit where it’s due, Apple did still pay some care to maintain compatibility… the OpenGL “driver” in the latest macOS releases are actually a translation layer to Metal, not directly running on hardware like in older macOS. Technically, Apple should have no problem keeping OpenGL support forever if it’s just depending on Metal, but that would be uncharacteristic of typical Apple. There is also MoltenGL which is a sort of OpenGL → Metal translator but first, it’s paid, and second, only supports up to GL ES 2.0, not the full GL 3.2 Picocrypt needs. There is a potential way to get around all of this but it’s hacky and error prone: replace the current GUI library fork with upstream GitHub - AllenDang/giu: Cross platform rapid GUI framework for golang based on Dear ImGui. , patch giu to use ebitengine as the backend instead of GLFW+OpenGL, then tell ebitengine to use Metal natively on macOS. Then do a bunch of patches to get drag and drop, system file selection dialogs, etc. working again. In theory this works, but I haven’t tried because it sounds like a pain. But if anyone wants to get Picocrypt working on macOS when it breaks, this might be a path forward. Or at this point, just rewrite the GUI entirely in ebitengine which from what I can tell, is the best choice for native Metal on macOS support going forward.
I wouldn’t remove Picocrypt just yet, since the future of OpenGL on macOS is unknown and might only become a problem much later than expected.
I would add a disclaimer under macOS stating that OpenGL has been deprecated since 2018 and may be removed in any future macOS version. Alongside that, include a link to the CLI version as an alternative if and when support disappears.
Since the cryptography in Picocrypt is solid—and unless something dramatic changes, allowing the encryption to be broken within a non-trivial timeframe—its current lack of updates shouldn’t significantly impact its security.
Its hard for me to see how keeping this on after its archived isn’t against the Active Development criteria.
Active Development: The tools that we recommend should be actively developed. Unmaintained projects will be removed in most cases.
There’s so many options for encryption on macOS that I don’t really see why it’s needed anyway, you can just use the built-in encryption tools or any number of other ones listed on the site.
I second it that we cannot recommend software that is no longer being maintained.
Between this and the other thread I think we have a majority approval so I’ll go ahead and mark it approved then.
I’d like to change the requirement from ‘actively developed’ to ‘basically maintained’. Tools that are stable and already secure do not require ACTIVE development.
I am currently writing a new GUI for PicoCrypt that should work on almost all desktop hardware made after 2012 (excluding MacBooks made before 2015, and possibly Android, iOS, and web). Since this is my first time working with Go, I’m not entirely sure about support on Android, iOS, and web. I will try to get a working build out as soon as possible, but depending on my schedule and the fact that I’m still learning Go, it might take a bit longer.
@any1, can you link me to the GUI library being used? I’m a bit concerned it still depends on OpenGL by the looks of it.
Nice! FYI, a former major Picocrypt contributor is also working on a fork, called Picocrypt-NG.
@overdrawn98901 you may be interested in the post I’m replying to, as well as my reply
Yes, I’ve created Picocrypt-NG · GitHub where I’ve invited trusted contributors to continue the project.
Don’t worry—it can compile as OpenGL 4.3 or OpenGL ES 3.0 for Linux, OpenGL 4.3 or D3D11 for Windows, and OpenGL 4.1 or Metal 2 for macOS.
I worked a bit more on it today, finished the GUI, and started removing the existing GUI calls. If you’ve already found more trusted or capable people to take over PicoCrypt and don’t need my work, let me know.
Here’s a pic of the finished GUI (ignore the weird colors at the bottom—I was testing something)
Edit: by finished I mean a working gui not a pretty one
I could definitely still use your help! The GUI is still a problem and the new org doesn’t solve that on its own.
What is this magical GUI library that I couldn’t find after years of searching lol?
Also, your GitHub username?
It’s a great single-header C library called sokol_gfx.h (with nuklear.h for the GUI). I’ve been keeping an eye on it for the past few years, and I recently started using it for a personal 3d graphics project, so it wasn’t too hard to get something running quickly.
I’ll make a GitHub account tomorrow since my old one is deleted.
