On Mon, Mar 09, 2020 at 11:49:42AM -0400, David Cantrell wrote:
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.
So the reporting for this would look like this is you ran it from the shell
today (this is just an example containing some of the output):
--------------------------
elf-object-properties:
----------------------
1) /usr/lib/systemd/tests/test-dhcp-client may use functions unsuitable
for IPv6 support on ppc64le
Result: VERIFY
Waiver Authorization: Anyone
Screendump:
IPv4-only symbols used:
inet_makeaddr
inet_netof
Suggested Remedy: Please review all usages of IPv4-only functions and
ensure IPv6 compliance.
2) /usr/lib/systemd/tests/test-dnssec may use functions unsuitable for
IPv6 support on ppc64le
Result: VERIFY
Waiver Authorization: Anyone
Screendump:
IPv4-only symbols used:
inet_addr
Suggested Remedy: Please review all usages of IPv4-only functions and
ensure IPv6 compliance.
--------------------------
This information is present in the output reported through Bodhi. The gating
system runs rpminspect and tells it to output JSON instead of the default
text output. When looking at the JSON data, it looks like it gets collapsed
down. At the shell, I get this when I run "rpminspect -F json
systemd-245-1.fc33":
"elf-object-properties": [
{
"result": "VERIFY",
"waiver authorization": "Anyone",
"message": "\/usr\/lib\/systemd\/tests\/test-dhcp-client may use
functions unsuitable for IPv6 support on ppc64le",
"screendump": "IPv4-only symbols
used:\n\tinet_makeaddr\n\tinet_netof\n",
"remedy": "Please review all usages of IPv4-only functions and ensure
IPv6 compliance."
},
{
"result": "VERIFY",
"waiver authorization": "Anyone",
"message": "\/usr\/lib\/systemd\/tests\/test-dnssec may use functions
unsuitable for IPv6 support on ppc64le",
"screendump": "IPv4-only symbols used:\n\tinet_addr\n",
"remedy": "Please review all usages of IPv4-only functions and ensure
IPv6 compliance."
},
(Again, just a sample). So the output is there, but could use some formatting
improvements. I've CC'ed Tim Flink who has been working on this integration
to see what input he has.
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
--
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
