On 01/22/2010 04:24 PM, Przemek Klosowski wrote:
On 01/22/2010 07:53 AM, Ralf Corsepius wrote:
On 01/22/2010 01:22 PM, Tomas Mraz wrote:
These are checksums required by FIPS-140-2 integrity verification checks of the fipscheck and ssh binaries.
I.e. package data.
=> These packages are non-FHS compliant and qualify as broken.
I don't believe so---it's not my line of business but I understand that
I do ... and as a member of the FPC, I do have a strong opinion on this.
- in some circumstances (government, regulated companies) encryption must be certified to the FIPS 140-2 standard
I don't know this "standard".
on Linux encryption (https, ssh) is handled by OpenSSL, which went through the FIPS certification process
one of the conditions of FIPS certification is a capability for run-time consistency checks, hence the fipscheck package
the fipscheck package checks against the checksums stored in the .XXX.hmac files, therefore those files are required if a system needs to be FIPS-compliant.
Having said that, I don't understand how does this scheme prevent someone from subverting the executable and creating a matching .hmac file, so that the fipscheck fails to see the problem.
May-be this "fips standard" collides with the FHS, may-be this standard is defective?
Do you have a pointer/reference to this "standard"? Does it really mandate pollution /usr/bin and thus $PATH?
I expect it's handled properly but I don't know how.
According to the FHS, such files belong somewhere below /usr/share, /usr/lib, /var or even /etc - /usr/bin is reserved for executables.
Package data, package metadata etc. belongs outside of /usr/bin etc.
Ralf