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.
