These are patches that make abrt-server usable for passing more information to it. So we can patch e.g. pyhook to provide additional information.
At least two of them deserve additional comments:
10/12 -- this is the biggest patch and I really recommend to look at whole patched file attached to a reply to this mail
11/12 -- this one is closely related to the previous one and it contains two shell scripts and .txt files (input for the scripts)
libreport -- I know that the FILENAME_BASENAME is not an ideal name for this value, but it fits in the rest of
them and is related to filenames, so I see it as the least confusing name
Rationale for the whole patch set:
1.) We need to have abrt-server more versatile to be able to provide more information in bugreports. Some of them are Python/Ruby/whatever specific or at least can be obtained from the running interpret environment in an easier way then from abrtd's perspective.
2.) Using GLib adds no additional dependencies.
3.) Using regular expressions makes parsing (and thus whole abrt-server) more versatile, better readable and maintable.
4.) Values checking should be done in one function and easily maintable so that we would be able to add more restrictions easily. If you see the ".txt files -> scripts -> .c files" flow as unnecessary, try to think again about maintainability a security. I mean, this way we have these restrictions hardcoded from the user's point of view (so that he cannot accidentaly modify it), but still easily editable from the maintainer's point of view. But there is one thing missing -- add "parse_checks.sh check_rules.txt > rules.c" to the Makefile. This is something I don't know how to do with Autotools. Can somebody help?
5.) I've tried to preserve the behaviour of the abrt-server including restrictions, but I see length checks as unnecessary. What is the reason for checking length of e.g. ANALYZER? We check the length of the whole communication, so there shouldn't be any security issues after removing it. And if the length causes a system call failure (e.g. creating new file) there still will be an error reported. And we believe that clients won't provide nonsense information (there's no way to check this) so I see no difference in believing that the info is "reasonably short".
So I've tried to explain the reasons of my steps, but of course feel free to ask me to explain anything that's not clear.
Anaconda Rider | Red Hat, Inc. | Brno -- Czech Republic