[Swan-dev] issues based on last night's laptop run that need to be fixed / explained before release

Andrew Cagney andrew.cagney at gmail.com
Wed Oct 3 00:28:18 UTC 2018


On Tue, 2 Oct 2018 at 19:50, Paul Wouters <paul at nohats.ca> wrote:
>
> On Mon, 1 Oct 2018, Andrew Cagney wrote:
>
> > I'm not seeing these FIPS falures?
>
> Odd.
>
> I see:
>
> [root at west ~]# /usr/bin/fipscheck /usr/local/libexec/ipsec/pluto
> [root at west ~]# echo $?
> 1
>
> According to the man page this means:        1 Checksum mismatch
>
> [root at west ~]# ls -l /usr/local/libexec/ipsec/pluto /usr/local/libexec/ipsec/.pluto.hmac
> -rwxr-xr-x. 1 root root 8424104 Oct  1 19:46 /usr/local/libexec/ipsec/pluto
> -rw-r--r--. 1 root root      65 Aug 23 19:41 /usr/local/libexec/ipsec/.pluto.hmac
>
> Hmm, First I blamed 'make install-base' but 'make install' also didn't
> write the file there. I also don't see the .hmac file for pluto in /usr/lib64/fipscheck
>
> It seems 'make install-fipshmac' installs it.
>
> I guess that makes sense since we do this manually in the spec file for
> rpm and otherwise the two would clash. So I think we should remove the
> handling in the spec file and have install-fipsmac called when invoking
> 'install' or 'install-base'. Although depending on the fipscheck
> version, we want the hmac file in a different location. Perhaps a
> variable we can set in make/rpm ?

Yea, it was a quick hack.  It could test USE_FIPSCHECK and just 'dtrt'.

Except, for RPMs, running fipshmac may not be the right thing.  RPMs
want the program installed un-stripped, so that they can first wave
magic at it (creating things like separate debug info), and only after
that run fipshmac.

However, it probably wouldn't hurt and would be more intuitive.


More information about the Swan-dev mailing list