Ensure VERSION is NUL-terminated

[suve]

The VERSION variable is referenced in two places inside dumb-init.c: in the print_help() function, and in parse_command(), when the --version option is passed:

void print_help(char *argv[]) {
    fprintf(stderr,
        "dumb-init v%s"
        "Usage: %s [option] command [[arg] ...]\n"
// (snip)
        "Full help is available online at https://github.com/Yelp/dumb-init\n",
        VERSION,
        argv[0]
    );
}

// inside parse_command()
    case 'V':
        fprintf(stderr, "dumb-init v%s", VERSION);
        exit(0);

In both of these cases, VERSION is used as an argument to fprintf(), to be formatted with %s. The man page for fprintf(3) says this about the %s conversion specifier:

The const char * argument is expected to be a pointer to an array of character type (pointer to a string). Characters from the array are written up to (but not including) a terminating null byte ('\0');

However, the way VERSION is currently generated, it does NOT contain the terminating null byte.

unsigned char VERSION[] = {
  0x31, 0x2e, 0x32, 0x2e, 0x32, 0x0a
};

This patch changes the way VERSION.h is generated, to ensure that VERSION is a NUL-terminated string.

[asottile]

a less intrusive patch would be to use VERSION_len:

        fprintf(stderr, "dumb-init v%.*s", VERSION_len, VERSION);

[suve]

It's an interesting idea, though it has one drawback - if someone needs to add a new piece of code that uses VERSION, they'll have to remember that it's not NUL-terminated and requires special handling.

As a third option, how about keeping VERSION as unsigned char[], with an additional 0-byte?

[asottile]

I would prefer the one line patch as I indicated, this tool has had very little maintenance and I doubt that a new use for VERSION will come up

[suve]

Sure. Rewrote the patch and force-pushed the branch.

[asottile]

[chriskuehl]

Thanks for the fix!

I think I won't release a new version just for this fix since as far as I understand this isn't causing issues in practice (due to automatic null byte padding around the constant?) but let me know if I'm misunderstanding the impact.

[suve]

Well, the only reason I spotted and patched this is because it did, in fact, cause issues in practice. ;)

In the Fedora Linux distribution, we had issues with building the dumb-init package. It turned out that on the s390x architecture, while the program built fine, the test suite failed - on this particular arch, the VERSION variable was not immediately followed by a null byte, which in turn caused the "is help message ok?" test to fail. (rhbz1863456)

[chriskuehl]

Thanks for letting me know, I've released a v1.2.3 which contains this fix.