cwrap 1.0.0 – testing your full software stack …

on one single machine!

FOSDEM/Brussels, February 2nd, I gave a talk about cwrap. I announced and released version 1.0.0 of cwrap, a set of tools to create a fully isolated network environment to test client/server components on a single host.
It provides synthetic account information, hostname resolution and privilege separation support. The heart of cwrap consists of three libraries you can preload to any executable.
The libc wrapper project does not require virtualization and can be used to build environments on different operating systems. The project
consists of a socket wrapper, NSS module wrapper (users, groups, hosts), and a (s)uid wrapper with support for GNU/Linux, BSD and Solaris.

The origin of these wrappers is the Samba project, where the wrappers are in use since many years to successfully test their protocol implementations. Now it is possible to use them outside of the Samba project. The wrappers have been improved and are loaded with new features.

Learn more at

libssh 0.6.0 released

After another development cycle, this time of 2,5 years, the libssh Team is proud to announce version 0.6.0 of libssh.

The most important functionality which has been added is a new callback-based server API. Also we added ECDSA support and a new algorithm called gro.h1506262302ssbil1506262302@652a1506262302hs-911506262302552ev1506262302ruc1506262302 for key exchange to have something better than the NIST curves. OpenSSH also uses gro.h1506262302ssbil1506262302@652a1506262302hs-911506262302552ev1506262302ruc1506262302 as the default for key exchange. For ECDSA there is a complete new API for public key management available. Also a big improvement is Kerberos support which has been tested by Red Hat engineers with FreeIPA and gssproxy.

Thanks to all contributors!

Curve25519-SHA256 is the default KEX in openSSH too now!

Since some hours txt.g1506262302ro.hs1506262302sbil@1506262302652ah1506262302s-915150626230252evr1506262302uc1506262302"> gro.h1506262302ssbil1506262302@652a1506262302hs-911506262302552ev1506262302ruc1506262302 is the default KEX in OpenSSH!


Several weeks ago Aris added a new Elliptic Curve algorithm for key exchange using Curve25519. After he wrote some kind of a RFC and implemented it in libssh he started to suggest a patch for OpenSSH which finally has been integrated.

Curve25519 and SSH with ECDSA

For the SSH Library we try to keep up with OpenSSH features and implement the most important stuff. After what we read about the NSA and NIST it became clear that the new ECDSA support we added in libssh 0.6.0rc1 needs new curves. So Aris implemented gro.h1506262302ssbil1506262302@652a1506262302hs-911506262302552ev1506262302ruc1506262302 and txt.g1506262302ro.hs1506262302sbil@1506262302652ah1506262302s-915150626230252evr1506262302uc1506262302?h=curve25519">wrote a draft. At the same time he implemented the first draft and you can find the code in his private wip branch, here.

Currently he is working on a patch for OpenSSH. If you have comments or want to discuss patches please subscribe to our mailing list.

Update: Aris sent a patch to the OpenSSH mailing list, in this post.

A new release of csync

Finally after 3 years there is a new version of csync available. csync is a file synchronizer especially designed for you, the normal user. About two years ago, Klaas started to use csync as the backend for the owncloud sync client. The last years we added a lot of features, improved our test framework and fixed several bugs. I have to thank Klaas for all the work he did on csync. Improving it, porting features back to csync master and cleaning up his working tree over and over again 🙂 Also thanks to all the contributers for bugs and patches!

We relicensed libcsync to LGPL and hope for broader use and more patches to come!

Unit testing with mock objects in C

The article Jakub Hrozek and I wrote for Linux Weekly News ( about CMocka and using mock objects is available to the public now. You can find it here:

Unit testing with mock objects in C

cmocka is a unit testing framework for C with support for mock objects. It is used by several Free Software projects like libssh, csync, SSSD or Elasto Cloud.

If you don’t have a subscription you should consider getting one 😉

Writing and reading code

You’ve probably heard that a developer of an established software project writes an average of 100 lines of code (loc) a day. I can say that this applies to me. So if you write 100 loc per day, how many do you read? I would estimate that the amount of time you spend on reading and understanding code is significantly more than on writing code. You probably also spend quite some time debugging code.

If you spend so much more time on reading and debugging code than writing code, shouldn’t you put more effort in writing clean and debuggable code? The Samba codebase is pretty old, more than 15 years now. I would say we have some experience with bad code and we have started to write much better and cleaner code, because we have wasted so much time trying to understand and debug code. However there is still room for improvement. Lets take a look at the following C code snippet.

if (!a) {

if (!b) {

if (!c) {

if (!*d) {

Can you guess from the code above what types of variables a, b, c and d are? The answer is no? Ok, lets take a look at the following code:

if (a == NULL) {

if (b == 0) {

if (c == false) {

if (d[0] == '\0') {

If you look at the code now, you can probably guess what types they are. Well not exactly which type, but in which superset they are. ‘a’ is a pointer, ‘b’ is an integer type, ‘c’ is a bool and ‘d’ is a string (char array). If you write code the way shown above, you don’t have to scroll up to find out as which type the variable is defined. Most of the time it is enough to know what type of superset you are checking and why.

Think about this: If you spend just a bit more time on writing clean code now, you will spend less time on reading, understanding and debugging the code later if you have to find a bug.

Lets look at some more best practices we do in the Samba code:

bool ok;
int rc;

 * bool return codes should always have the name 'ok' or
 * start with 'is_' or 'do_'
ok = fn_returning_a_bool();
if (!ok) {

/* We use rc or ret for an integer return code */
rc = do_something();
if (rc < 0) {

You can see that we have variables for the return codes and check them with an if-clause. The reason is that it is easy on the eyes and in a debugger you can simply print the return code variable. If you write it like this: if (do_something() < 0) You have a hard time in the debugger to find out the actual return code. You have to step into and through the function to get it. We allow the !ok syntax for bool types, cause ok is by definition in our code a bool.

To be continued ...

vim modelines in git config

I’m working on different Open Source projects and most of them have different coding style guidelines. Mostly spaces or tabs or different tabwidth. The easiest thing would be to store these information in the git config of the project. So here is a easy and secure way to have modelines in the git config.

So first I set the modelines (here for the Samba project):
git config --add vim.modeline "tabstop=8 shiftwidth=8 noexpandtab cindent"

or for a specific language:
git config --add vim.modeline-python "tabstop=4 shiftwidth=4 expandtab"

Then copy this plugin into ~/.vim/plugin folder.

The modeline you defined in your git config will be appended to the :setlocal command of vim. It only allows a limited set of setlocal commands to be used. It will not execute any arbitrary code and you probably are the only person modifying the git config. You can change the allowed commands by adding the following to your ~/.vimrc file

    let g:git_modelines_allowed_items = [
                \ "textwidth",   "tw",
                \ "softtabstop", "sts",
                \ "tabstop",     "ts",
                \ "shiftwidth",  "sw",
                \ "expandtab",   "et",   "noexpandtab", "noet",
                \ "filetype",    "ft",
                \ "foldmethod",  "fdm",
                \ "readonly",    "ro",   "noreadonly", "noro",
                \ "rightleft",   "rl",   "norightleft", "norl",
                \ "cindent",     "cin",  "nocindent", "nocin",
                \ "smartindent", "si",   "nosmartindent", "nosi",
                \ "autoindent",  "ai",   "noautoindent", "noai",
                \ "spell",
                \ "spelllang"
                \ ]

* New script which only allows a specified list
* Use sandbox command for set
* Added git repository
* Set only locally when reading the buffer

cmocka – a unit testing framework for C

I’m a big fan of unit testing frameworks. When I developed csync, a bidirectional file synchronizer, I used check to write unit tests from the start. check was ok, but it were running valgrind on your testcases to find memleaks in your code the mode reports were about check. So I needed to add valgrind suppressions to get rid of them. When I started to work on libssh, a library implementing the SSH protocol, I wrote unit tests with check too. libssh is multi platform and also works on Windows and with Visual Studio. So we needed a new unit testing framework which is platform independent and has better code quality. I stumbled upon cmockery, a unit testing framework from Google. It was easy to use, the code looked good and it worked with Visual Studio. The build system sucked, so I added CMake support to produce a NSIS installer for Windows. I sent all my patches upstream but nothing happened. I fixed more bugs and added all patches people posted in their bug tracking system. I tried to talk with friends at Google, but in the end I needed to fork it.

cmocka is a fork and the successor of cmockery. I started to fix a lot of bugs, got all examples working and wrote API documentation with doxygen. The result is this first release version 0.2.0.

cmocka is a great unit testing framework with support for mock objects. Mock objects are simulated objects that mimic the behavior of real objects in a controlled way. Instead of calling the real objects, the tested object calls a mock object that merely asserts that the correct methods were called, with the expected parameters, in the correct order. It is really easy to write a unit test, take a look at the API an get started.


#include <stdarg.h>
#include <stddef.h>
#include <setjmp.h>
#include <cmocka.h>

/* A test case that does nothing and succeeds. */
static void null_test_success(void **state) {
(void) state; /* unused */
int main(void) {
const UnitTest tests[] = {
return run_tests(tests);