Skip to content

F
Fenrir_Project

Development

Last edited by Luker
Page history

Development

The Fenrir project is made of 3 different subprojects:

  • libFenrir
  • Fenrir (not yet started)
  • Fenrird (not yet started)

Plus the libRaptorQ library, which could be considered a separate project.

Choose the one you want to contribute to, sign the CLA (one for all of them) and start coding :)
As soon as I understand how, I'll make it simpler to accept the CLA.

Contacts

Use the gitlab tools or mailing lists dedicated to each subproject to discuss everything.

I am also on IRC at #fenrirproject on Freenode if you need me.

Mail me @ luker at fenrirproject.org if you want.

Copyright & License

For now If you want to send any code you need to sign a CLA (the CLA is the same for all subprojects).

This will grant me full control over the code, leaving you the copyright and the possibility to use it elsewhere.

The CLA assigns all the right to me.
In a couple of months I will start a foundation, technical committee or something, and that will be the one that gets all the rights on the code.
If you sign now, you won't have to sign it again, I will simply sign the document myself and all my rights will be transferred to the foundation/commitee.

I will never make this project close source, but this is why I need this CLA:

The project will be split in three parts:

  • libFenrir, LGPL3 license, dual-licensing for those who need it.
  • Fenrird, GPL3 in dual-licensing for those who need it.
  • Fenrir, GPL3 in dual-licensing for those who need it.

The CLA comprehends also the libRaptorQ library, so you won't need to sign too many things.

The rationale is simple:

  • libFenrir: LGPL3 grants us linking flexibility, and maintains the core of this project free-software.
  • Fenrird: this can be GPL3. I still have to think to a scenario where GPL3 is a bad idea. Remember, this is the main authentication server. You won't run it on your computer.
  • Fenrir: This will be a qt5 client in GPL3 that you can install on your computer to easily manage all the accounting information.

Dual-licensing will be available for all 3 parts, libfenrir, Fenrird, Fenrir and for libRaptorQ, so if you really need it, convince me and I can grant a license.

Why dual licensing?

I don't plan on making money from dual-licensing, and won't make this closed source.

My main objective is to keep this software free. But a lot of people do not like the LGPL3 and much less the GPL3.

Their reasons aside, I still want them to be able to use this project. The other licenses will need to be defined, but what I am aiming towards is a new license that

  • protects from patents litigations.
  • grants usage on closed source projects, optionally with static/dynamic linking for libfenrir/libRatporQ, without "tivoization" clauses.
  • makes it so the one who gets the license can not modify the source code (their contributions must be LGPL3)
  • deterministic builds must be used and the data to reproduce them must be public

Such a license does not seem to exist today, so I will need help to design it, especially from lawyers. The whole process will be public, I hope a bit more open than the GPL3 discussions. If needed, there could be discussions of making the availability of such a license something permanent (I'd like to, don't know how at the moment).

This seems to restrict the development a lot for those who receive the license. I am willing to dedicate new git-branches on the main project and assign to them the maintainer the company will require.

I am trying to do this to avoid code-duplication between projects, forks of bsd-like projects that become closed, and to still maintain a single-point of development, even with differences of maintainers and platform.

One of the thing that pushed me to do this is that the Apple market and products seem to really dislike including GPL and LGPL software, and their two reasons seems to be the tivoization clause and the fact that the need to modify binaries to add signatures to cryptographically-verify the provenience of that software.

I don't care that much about tivoization. I just want to be sure everyone is running a safe version of what I hope will be a widespread security protocol. If a vendor stops updating a platform, you won't get much out of it anyway. If your problem is having a free platform, this is the wrong place to enforce it.

All of this should be handled by more than a single person, so a foundation or something similar will probably be created.

Coding Style

This is not well defined yet. I am aiming on something in between LLVM coding style and the Linux kernel coding style, for now a few things are decided:

  • C++11 is the standard.
  • no exceptions: I know, it kinda sucks for you, but error management is still easy and we might speed up things a little.
  • no garbage collectors: I don't even want to hear about this things.
  • no struct: just use classes with public methods. For the compiler it's the same anyway.
  • comments are fine in both C89 and C++ style. But please use the '//'
  • no standard types: that is, do NOT use "int". Use "int32_t". It's better for portability.
  • 80 colums: This way I can keep 4 files on one screen, thankyouverymuch.
  • 4-space tabs: use spaces, not tabs, 4-space equivalent. Rationale: portability between editors.

In the future we might start to use clang-format.

In general I'm trying to write C++11 code. But I've just started learning the C++11 variant, and I usually code in C, so I might be missing lots of things. Please point them out :)

Sending a patch:

First of all, sign the CLA.

Then you can use your github account to login on fenrirproject.org, and do bug reporting/forking/merging there.

Or just email me @ luker _at fenrirproject.org.

Or better, write to the mailing list of the project you are contributing to:

You can use the "git format-patch" to generate the required patch from your local repository.

In the future I will set up a github repository automatically synced with my main one, and you can use those platform to send me pull requests. Still, use this website for error reporting. Login with github accounts is already active.

I always generate my commits with "git commit -sS", so that its always signed. All tags are signed. The master branch can only have signed merges. Please check those.

General

The environment

Everything is developed under GNU/Linux. Currently I'm using qtcreator for its C++ support, clang as a compiler.

Since I work under ArchLinux I might have a newer version of some packages, but I'll try not to be too bleeding-edge on the requirements. The project won't be considered complete for a while, so for now: the newer, the better.

Compatibility with the latest red-hat/contos 7 is required, though. No unsupported versions of old distros will be considered.

Linking

If you contribute new features, please don't link to too many libraries. Try to avoid it. We already have the libunbound, libevent, and will have to link libRaptorQ, openssl/gnuTLS for some crypto algorithms.

That's already enough. If you have to link to something, please try to be sure it is something portable, as later in the development we will have to port this project to **BSD and Windows

Windows porting

I have no experience of programming under windows, but I'm using standard libraries and calls, so it shouldn't be too difficult.

Aside from that, it should only be a different socket API.

All the code is under the C++11 standard, so as long as the compiler supports it, it should be fine (meaning no visualc++ support?).