Limited User Field Lengths

[Luiserebii]

gitid, up until the current release (and latest commit), has assumed a 1000 character limit on the user, email, and signing key fields. To protect against overwriting the buffers, safestrcpy and safestrcat have been written to define a hard limit. Even runcmd, a function intended to retrieve output from a command, follows this philosophy:

gitid/src/util.c

Lines 33 to 53 in df1e97d

	void runcmd(const char* command, int maxline, char* out) {
	FILE* proc;
	//Process logic in case of failure
	if((proc = popen(command, "r")) == NULL) {
	perror("popen");
	exit(1);
	}
	//Copy all output to string out
	int c;
	for(int i = 0; (c = getc(proc)) != EOF && i < maxline - 1; ++i) {
	*out++ = c;
	}
	//Close out
	*out = '\0';
	//Close process and return
	if(pclose(proc) == -1) {
	perror("pclose");
	exit(1);
	}
	}

Although the application is prepared to handle these scenarios, they are assumed as accidents, as I had not investigated how long git actually allowed the configurations to be. After building and running the program through gdb, I can safely say that it reads into a kind of dynamically-sized string buffer. The core function is the static get_value: https://github.com/git/git/blob/v2.26.0/config.c#L597 which reads into a string buffer of size_t: https://github.com/git/git/blob/v2.26.0/strbuf.h#L66

The solution here, is to migrate our stack buffers to a dynamically-sized one. There is a string type in C-STL we can use and integrate, although it needs some more work to make it complete.

The best next course of action is to identify the substitutions, get a general idea of the functions needed, develop them, test them, and implement. Success should result in a minor version bump to v0.3.0.

[Luiserebii]

Tackling in string branch.

[Luiserebii]

Fixed as of 1aa0e3f.