On Mon, Mar 09, 2020 at 02:54:27PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
On Mon, Mar 09, 2020 at 10:12:26AM -0400, David Cantrell wrote:
In this case, the blacklisted functions are listed in
/etc/rpminspect/rpminspect.conf as the value of the elf_ipv6_blacklist. That
looks like this in rpminspect-data-fedora:
elf_ipv6_blacklist = "gethostbyname gethostbyname2 gethostbyaddr inet_addr
inet_aton inet_nsap_addr inet_ntoa inet_nsap_ntoa inet_makeaddr inet_netof
inet_network inet_neta inet_net_ntop inet_net_pton rcmd rexec rresvport"
Thanks. I'd suggest to be very specific in the report, and always including
the name of the offending function. Something like
"message: /usr/lib/systemd/tests/test-dhcp-client uses function inet_addr() which
is unsuitable for IPv6".
So it seems rpminspect doesn't like the following code:
src/network/test-network.c:63: assert_se(routes[0].dst_addr.s_addr == inet_addr("192.168.0.0"));
src/network/test-network.c:64: assert_se(routes[0].gw_addr.s_addr == inet_addr("192.168.0.1"));
src/network/test-network.c:67: assert_se(routes[1].dst_addr.s_addr == inet_addr("10.1.2.0"));
src/network/test-network.c:68: assert_se(routes[1].gw_addr.s_addr == inet_addr("10.1.2.1"));
src/network/test-network.c:71: assert_se(routes[2].dst_addr.s_addr == inet_addr("0.0.0.0"));
src/network/test-network.c:72: assert_se(routes[2].gw_addr.s_addr == inet_addr("10.0.1.1"));
src/network/test-network.c:84: assert_se(routes[0].dst_addr.s_addr == inet_addr("192.168.0.0"));
src/network/test-network.c:85: assert_se(routes[0].gw_addr.s_addr == inet_addr("192.168.0.1"));
src/network/test-network.c:88: assert_se(routes[1].dst_addr.s_addr == inet_addr("0.0.0.0"));
src/network/test-network.c:89: assert_se(routes[1].gw_addr.s_addr == inet_addr("10.0.1.1"));
src/resolve/test-dnssec.c:327: a->a.in_addr.s_addr = inet_addr("52.0.14.116");
src/resolve/test-resolved-etc-hosts.c:81: assert_se(address_equal_4(bn->addresses[0], inet_addr("1.2.3.4")));
src/resolve/test-resolved-etc-hosts.c:82: assert_se(address_equal_4(bn->addresses[1], inet_addr("1.2.3.5")));
src/resolve/test-resolved-etc-hosts.c:88: assert_se(address_equal_4(bn->addresses[0], inet_addr("1.2.3.6")));
src/resolve/test-resolved-etc-hosts.c:93: assert_se(address_equal_4(bn->addresses[0], inet_addr("1.2.3.6")));
src/resolve/test-resolved-etc-hosts.c:102: assert_se(address_equal_4(bn->addresses[0], inet_addr("1.2.3.9")));
src/resolve/test-resolved-etc-hosts.c:103: assert_se(address_equal_4(bn->addresses[1], inet_addr("1.2.3.10")));
src/resolve/test-resolved-etc-hosts.c:104: assert_se(address_equal_4(bn->addresses[2], inet_addr("1.2.3.11")));
src/resolve/test-resolved-etc-hosts.c:105:
assert_se(address_equal_4(bn->addresses[3], inet_addr("1.2.3.12")));
That should be easy to adjust. I'll work on that today.
The code is OK as is, it's just doing resolution of fixed addresses for testing purposes.
RFE: filter out reports for anything with "test" in the name.
That'd cut down on various false positives a lot.
Filtering out arbitrary things like files with "test" in the names leads down
the path of very difficult to maintain code. That's what I've been working to
move away from as rpminspect's ancestor grew a lot of things like that.
What I have in progress right now is the ability to add filespecs using
glob(3) syntax that you want to ignore per test. That gets configured put
package (or if the vendor decides to configure it globally, sure) in a
.rpminspectrc file. I haven't pushed those changes yet, but that's my
preferred method to silence the above.
/etc/rpminspect/rpminspect.conf
So that is a global config file...
RFE: move it under /usr, and only look for overrides in /etc.
99% of users should not modify that, and it shouldn't be in /etc.
I disagree. Users are allowed to edit configuration files in /etc.
As for the location, I could put it with the rest of the vendor-specific data
in /usr/share/rpminspect and allow for the location in /etc to override it as
you suggest. So it would become:
/usr/share/rpminspect/rpminspect.conf (if it exists)
/etc/rpminspect/rpminspect.conf (if it exists)
As stated above, I have a pending patch set that will add .rpminspectrc as the
last one in this list. That would be read from the directory you invoke
rpminspect in. The intent here is to allow package maintainers to add it to
dist-git for further control of how rpminspect runs in gating.
Then if you specify a profile, it would search dirs in this order:
/usr/share/rpminspect/profiles
/etc/rpminspect/profiles
The vendor data package would stop providing the /etc files. I'm not opposed
to this layout. Is this along the lines of what you're thinking?
I certainly don't want to modify global rpminspect config. How do
I silence those results just for the systemd package?
A couple of ways. You can create an rpminspect profile in
/etc/rpminspect/profiles which overrides rpminspect.conf except the [common]
section and then run rpminspect with that profile (-p).
Alternatively, just copy rpminspect.conf somewhere, edit it, pass it via the
-c option.
Thanks,
--
David Cantrell <dcantrell@xxxxxxxxxx>
Red Hat, Inc. | Boston, MA | EST5EDT
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
