So, this has taken far longer than I wanted it to, but the time has finally come: fSekrit is going opensource. I don't personally feel comfortable using closed-source security products, so better put my money where my mouth is.
TL;DR:
w00p w00p.
Why has it taken so long - after all, I've mentioned open-sourcing it
as early as 2008, and probably earlier (this was the lazy first result from a quick search)? Well, as mentioned in that post, embarassment of showing your source to the world was one factor. Then there was time and motivation: fSekrit 1.40 does most of what I need, and after getting a full-time development job, doing some fundamentally
boring development (cleanup, documentation, ...) in my spare time didn't seem like a lot of fun.
There were also a number of decisions that had to be made - for various reasons, I didn't feel like dumping the entire Subversion repository (some of the code
was embarassing, but there were also issues like having used hardcoded paths and passphrases during early development, not using a standard repository layout, and stuff I've forgotten by now). It quickly became clear that I wanted to move to Git, and that I wanted a cut-off point for what I shared with the rest of the world - and I
bumped my head on grafting. Furthermore, I wasn't sure which license to release the code under.
So, I've finally made some decisions, in order to be able to move forward:
- I've chosen 1.40 as the public cutoff point.
- I won't muck around with grafting, will suffer subversion if I need history.
- License will be //TODO// - I'm leaning towards something permissive, though.
- The code will be released under my real-name GitHub account, but otherwise the 'f' in fSekrit stays.
- The work-in-progress 2.0 code will be pushed later, but it's currently in a too messy state.
I won't make any guarantees about further progress, but at least this is a step forward. There's some boring grunt work that has to be done before development can properly be resumed.
- The current 2.0 branch basically has to be salvaged; I tried to do too many things at once, and keeping Win9x compatibility means adding proper unicode support resulted in kludgy code.
- Win9x support will be dropped. If there's still people using Win9x, bug fixes might be backported to 1.x.
- Less focus on super-small executables, for instance I'll (at least initially) be using STL containers.
- Builds will be done with a C++11 (or newer) compiler, support for VC2003 toolkit will be dropped - it hasn't been available for download for ages, anyway.
- I need to add unit tests. Any suggestions for a framework? Integration with Visual Studio is a plus, but the core must be cross-platform. Google test? Or Catch?
- I need to do some work on the build system. Is SCons still viable? Or should I just go Gradle?
I don't have SCons installed at the moment, but the current code can be directly checked out of Git, imported into Visual Studio 2013 (with conversion, the solution is VS2008) and built.
Recent Posts
