(In reply to Brian Lane from comment #0)
Hi Brian,

> Hardened: /usr/bin/composer-cli: FAIL: only-go test because combining GO and
> non-GO object files on x86 systems is not safe - it disables CET 
> 
> Hardened: /usr/libexec/tests/composer-cli/composer-cli-tests: FAIL:
> cf-protection test because CET enabling note missing

Short answer: please feel free to waive these results.


Long answer:

> weldr-client isn't mixing object files, there is only Go code in the
> project. 

Actually it does mix C and GO, because it is linking with code from the
glibc library.  (Including some thread functions by the look of it).


> And I have no idea what CET is, 

CET is a new feature from Intel that is present in the very latest chips.
It stands for "Control Flow Enforcement Technology" and the idea is that
it stops certain kinds of attacks on compiled programs.  (JOP and ROP 
attacks if that means anything to you).

The problem with the feature is that it is an all or nothing type of thing.
Either all of the code in a program must be compiled to support it or else
it will not work.  Currently the GO compiler does not support generating
CET-aware code on x86/x86_64 machines, and hence annocheck is producing
these FAIL messages.

Since this is a known problem with the GO compiler, and nothing at all
to do with your package's code, there is no need for you to be concerened
and you can just waive the result.  Ideally a future release of the GO
compiler will fix this problem.


> In a previous run, with annocheck 9.86, these failures didn't appear at all:

Which is odd because the FAILs should have been there.

> http://artifacts.osci.redhat.com/testing-farm/8e4ed956-7b91-4039-a7d6-ce566c3809e4/work-rpminspectmj034O/rpminspect/execute/data/annocheck/output.txt

Looking at this output there are no tests of the x86_64 binaries, which is why
you did not encounter any FAIL results.  I have no idea why the x86_64 tests
were omitted however.


Given all of this, are you happy if I CLOSE this BZ ?

Cheers
  Nick

(In reply to Nick Clifton from comment #1)
> (In reply to Brian Lane from comment #0)
> Hi Brian,
> 
> > Hardened: /usr/bin/composer-cli: FAIL: only-go test because combining GO and
> > non-GO object files on x86 systems is not safe - it disables CET 
> > 
> > Hardened: /usr/libexec/tests/composer-cli/composer-cli-tests: FAIL:
> > cf-protection test because CET enabling note missing
> 
> Short answer: please feel free to waive these results.
> 
> 
> Long answer:
> 
> > weldr-client isn't mixing object files, there is only Go code in the
> > project. 
> 
> Actually it does mix C and GO, because it is linking with code from the
> glibc library.  (Including some thread functions by the look of it).
> 
> 
> > And I have no idea what CET is, 
> 
> CET is a new feature from Intel that is present in the very latest chips.
> It stands for "Control Flow Enforcement Technology" and the idea is that
> it stops certain kinds of attacks on compiled programs.  (JOP and ROP 
> attacks if that means anything to you).
> 
> The problem with the feature is that it is an all or nothing type of thing.
> Either all of the code in a program must be compiled to support it or else
> it will not work.  Currently the GO compiler does not support generating
> CET-aware code on x86/x86_64 machines, and hence annocheck is producing
> these FAIL messages.
> 
> Since this is a known problem with the GO compiler, and nothing at all
> to do with your package's code, there is no need for you to be concerened
> and you can just waive the result.  Ideally a future release of the GO
> compiler will fix this problem.

Given that this is a known problem with the GO compiler, this is going to be an ongoing finding by annocheck that developers will be able to do nothing about.  Can an option be passed to annocheck to at least crank this down from FAIL in the interim?  Waiving as proper procedure is a bad workflow, so if this is to be ignored for now then we should invoke annocheck in a way that does not report this as FAIL for now.

annocheck options used by rpminspect are defined in /usr/share/rpminspect/redhat.yaml in the rpminspect-data-redhat package which lives at https://gitlab.cee.redhat.com/osci/rpminspect-data-redhat

> > In a previous run, with annocheck 9.86, these failures didn't appear at all:
> 
> Which is odd because the FAILs should have been there.
> 
> > http://artifacts.osci.redhat.com/testing-farm/8e4ed956-7b91-4039-a7d6-ce566c3809e4/work-rpminspectmj034O/rpminspect/execute/data/annocheck/output.txt
> 
> Looking at this output there are no tests of the x86_64 binaries, which is
> why
> you did not encounter any FAIL results.  I have no idea why the x86_64 tests
> were omitted however.
> 
> 
> Given all of this, are you happy if I CLOSE this BZ ?
> 
> Cheers
>   Nick

(In reply to David Cantrell from comment #2)


> Can an option be passed to annocheck to at least crank this down
> from FAIL in the interim? 

There already is such an option.  Or rather two options, because two tests
are failing:  --skip-only-go and --skip-cf-protection.  Using the latter 
would be a bad idea however as the cf-protection test is important for non-GO
binaries.  Plus these options would have to be added to the script used by
rpminsect that invokes annocheck.

A better solution, I would suggest, is to have annocheck SKIP these tests
if it detects that it is examining a GO compiled binary.  Then when the GO
compiler is updated to add CET support, the tests can be reinstated.  I 
have a local patch to annocheck that does this, but given the fact that 
changes to RHEL-9-beta now need exception+ status, I have pushed this BZ
out to RHEL-9.0 instead.

(In reply to Nick Clifton from comment #3)
> (In reply to David Cantrell from comment #2)
> 
> 
> > Can an option be passed to annocheck to at least crank this down
> > from FAIL in the interim? 
> 
> There already is such an option.  Or rather two options, because two tests
> are failing:  --skip-only-go and --skip-cf-protection.  Using the latter 
> would be a bad idea however as the cf-protection test is important for non-GO
> binaries.  Plus these options would have to be added to the script used by
> rpminsect that invokes annocheck.

rpminspect doesn't run a script to run annocheck.  It just uses popen() with a command line built starting with the options defined in the config file.  In rpminspect-data-redhat (https://gitlab.cee.redhat.com/osci/rpminspect-data-redhat) the main program configuration file is redhat.yaml.  In the annocheck section, you can define any number of annocheck "runs" you want rpminspect to perform.  A run has an arbitrary name, a colon, then the command line options that should be used with annocheck.  By default there is one run defined and in rpminspect-data-redhat it's called "rhel-policy".  In rpminspect-data-fedora, we spell it "hardened".

https://gitlab.cee.redhat.com/osci/rpminspect-data-redhat/-/blob/master/redhat.yaml#L478

Changing these options does not require modification to rpminspect, so we can restructure the product config files as we see fit.

Also, the config file for rpminspect is YAML, which I apologize for.  A down the road item is to migrate away from YAML because it's just too frustrating to deal with.  Since it's YAML syntax, the format for the entries in the annocheck section is:

HYPHEN WHITESPACE NAME COLON WHITESPACE OPTIONS

> A better solution, I would suggest, is to have annocheck SKIP these tests
> if it detects that it is examining a GO compiled binary.  Then when the GO
> compiler is updated to add CET support, the tests can be reinstated.  I 
> have a local patch to annocheck that does this, but given the fact that 
> changes to RHEL-9-beta now need exception+ status, I have pushed this BZ
> out to RHEL-9.0 instead.

That's reasonable, though it would be nice to have a solution for the time between 9 beta and GA.

Fixed in annobin-10.06-1.el9

Right, please try: annobin-10.09-1.el9

verified: annobin-10.10-1.el9

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (new packages: annobin), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2022:2342