topbanner_forum
  *

avatar image

Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
  • Friday December 6, 2024, 1:56 pm
  • Proudly celebrating 15+ years online.
  • Donate now to become a lifetime supporting member of the site and get a non-expiring license key for all of our programs.
  • donate

Author Topic: Open-sourcing fSekrit  (Read 18925 times)

f0dder

  • Moderator
  • Joined in 2005
  • *****
  • Posts: 9,153
  • [Well, THAT escalated quickly!]
    • View Profile
    • f0dder's place
    • Read more about this member.
    • Donate to Member
Open-sourcing fSekrit
« on: February 08, 2016, 05:13 PM »
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.
- carpe noctem

mouser

  • First Author
  • Administrator
  • Joined in 2005
  • *****
  • Posts: 40,913
    • View Profile
    • Mouser's Software Zone on DonationCoder.com
    • Read more about this member.
    • Donate to Member
Re: Open-sourcing fSekrit
« Reply #1 on: February 08, 2016, 05:38 PM »
Cool!!

mwb1100

  • Supporting Member
  • Joined in 2006
  • **
  • Posts: 1,645
    • View Profile
    • Donate to Member
Re: Open-sourcing fSekrit
« Reply #2 on: February 09, 2016, 12:10 AM »
Very nice!

doing some fundamentally boring development (cleanup, documentation, ...) in my spare time didn't seem like a lot of fun.

I can only imagine how big of a hurdle that step is to doing something like this.

phitsc

  • Honorary Member
  • Joined in 2008
  • **
  • Posts: 1,198
    • View Profile
    • Donate to Member
Re: Open-sourcing fSekrit
« Reply #3 on: February 09, 2016, 01:05 AM »
concerning what to use for unit tests: I don't know Google test. I've used both Boost.Test and Catch though. I'd currently go for Catch. It's very easy to use, has no dependencies and is header-only. It also features a single generic assertion macro (REQUIRE), something which Boost.Test has implemented now as well (since v. 1.59).

AbteriX

  • Charter Honorary Member
  • Joined in 2005
  • ***
  • Posts: 1,149
    • View Profile
    • Donate to Member
Re: Open-sourcing fSekrit
« Reply #4 on: February 09, 2016, 01:52 AM »
Kudos for going open source  :up:


I can imaging what a big step that is. ( showingmycode? )


That's for you :>



  

Stoic Joker

  • Honorary Member
  • Joined in 2008
  • **
  • Posts: 6,649
    • View Profile
    • Donate to Member
Re: Open-sourcing fSekrit
« Reply #5 on: February 09, 2016, 07:27 AM »
Wow, Thanks man!

Release build converted, compiled, and ran fine with VS13 Community for me.

Jibz

  • Developer
  • Joined in 2005
  • ***
  • Posts: 1,187
    • View Profile
    • Donate to Member
Re: Open-sourcing fSekrit
« Reply #6 on: February 09, 2016, 10:14 AM »
Great to see :Thmbsup:.

Catch looks interesting. I would definitely pick something lightweight and portable. Also, if you run the tests on CI it is important they are reproducible.

40hz

  • Supporting Member
  • Joined in 2007
  • **
  • Posts: 11,859
    • View Profile
    • Donate to Member
Re: Open-sourcing fSekrit
« Reply #7 on: February 09, 2016, 02:31 PM »
respect.jpg

@f0dder - That took some thought, and possibly a little courage too. My hat's off to you.   8)

And it is true, closed source security-related products are sometimes far more dangerous and less trustworthy because of that.

Post-Snowden, I think we're all coming to realize (reluctantly or otherwise) that the only hope for "trusty enough" security is to put it all out in the open.

Brave new world we're living in. Adapting to it is bound to be hard. Either way - Onward!  :Thmbsup:

(Note: you might want to know it runs really well on Linux under WINE in its present form. On a modern distro like Mint you just need to double click and it works just like it does under Windows. Stick it in a Dropbox or similar online storage bin and you can get to it from anywhere too!)
« Last Edit: February 09, 2016, 02:39 PM by 40hz »

f0dder

  • Moderator
  • Joined in 2005
  • *****
  • Posts: 9,153
  • [Well, THAT escalated quickly!]
    • View Profile
    • f0dder's place
    • Read more about this member.
    • Donate to Member
Re: Open-sourcing fSekrit
« Reply #8 on: February 10, 2016, 07:10 AM »
@phitsc: no dependencies is nice - my requirements for a Unit testing framework is that it's easy to use, cross-platform and doesn't add a lot of compilation time overhead.

I'd really like something that has some form of integration with Visual Studio too, though. I don't need ability to re-run a single failed test (might be hard to get that kind of tooling for a native language without reflection), but having a report with click-on-error-to-go-to-source would be nice.

@Jibz: CI would be kinda overkill for fSekrit, but yes - lightweight, repeatable tests. I want something that's fast enough that it won't be a nuisance running it for every build.

@40hz: yep, applications that deal with this kind of security really should be open - both to show that there aren't any backdoors, but of course also for a chance to be scrutinized. There's a couple of things in 1.40 that definitely aren't perfect, like using a bad random source for the iv and using direct hash of passphrase for key material instead of using, say, PBKDF-2.

Oh, by the way, release tags are GPG signed (yes, that's what this thread was for). They key fingerprints are:
Primary key fingerprint: BBC6 1F55 8A3D 3C4D A049  3F03 FEA5 85DE 0DC2 1B1D
Subkey fingerprint:      1989 142F B3C7 C76D 5D34  A25D 3FA3 6A64 E415 CF97
- carpe noctem

Lintalist

  • Participant
  • Joined in 2015
  • *
  • Posts: 122
    • View Profile
    • Lintalist
    • Donate to Member
Re: Open-sourcing fSekrit
« Reply #9 on: February 12, 2016, 05:16 PM »
 :Thmbsup:

webfork

  • Participant
  • Joined in 2010
  • *
  • default avatar
  • Posts: 3
    • View Profile
    • Donate to Member
Re: Open-sourcing fSekrit
« Reply #10 on: February 12, 2016, 06:55 PM »
fSekrit is going opensource
-f0dder

Great news, thanks.  This is a great way to develop software that's going to be around in 10 - 20 years; the original BSD was born almost 38 years ago (3/9/1978) and no doubt some of the original code is still present.

License will be //TODO// - I'm leaning towards something permissive, though.
-f0dder

I know I don't have any reputation here but I'd like to argue on behalf of a license that specifically calls out patent usage, as patent law just gets weirder over the years.

  • Infoworld has an article on why you might want to avoid older permissive licenses like BSD and MIT.
  • For a more of a hands-on view, read the "Exclusions From License Grant" section of the OSL 3.0 and ask yourself: why is that section necessary?  It's because some programs under a very permissive license can still get patented in spite of the original author.

In terms of recommendations, the much of the reason for a version 3 of the GPL was wacky patent law stuff, but on the permissive side of course the lesser GPL (LGPL) and Apache 2.0 is loved by both huge companies and individuals.  Both are of course compatible with other GPL and Apache code, which may see your tools integrated or enhanced with other code.

Hope that helps.