[Openswan dev] nss/nspr4 warning and PLUTO_SENDS_VENDORID vs HAVE_LIBNSS

Avesh Agarwal avagarwa at redhat.com
Tue Jan 5 09:49:00 EST 2010

On 01/04/2010 09:49 AM, Avesh Agarwal wrote:
> On 12/27/2009 08:56 PM, Paul Wouters wrote:
>> Hi Avesh,
>> I was looking at a bug reported that we do not compile with
>> USE_VENDORID=false. I disentangled some ifdef's around a
>> check with Pluto_IsFIPS() to resolve this issue.
>> It looks like you had wanted to log (or do?) something different when
>> running in fips mode, but actually did not log the fips mode.  This got
>> interweaved with PLUTO_SENDS_VENDORID.
>> Can you verify that I am not missing some hidden assumption.  For
>> instance, it might be possible you actualy do not want to initiate the
>> sending vendorid code on purpose in fips mode, but if so, it was not
>> clear to me if this was done by accident or on purpose. I repaired it
>> to honour PLUTO_SENDS_VENDORID regardless of the HAVE_LIBNSS setting.
>> If you actually wanted to not send the vendorid in fips mode, I'd rather
>> set PLUTO_SENDS_VENDORID based on USE_FIPSCHECK, instead of through some
>> undocumented/uncommented nested ifdef clause.

Hi Paul,

I looked into this, and the reason for not to send vendorid during FIPS 
mode is that it computes MD5 hashes on the vendorid, and MD5 should not 
be allowed in FIPS mode. As FIPS or non-FIPS mode can be setup at "run 
time", I coded it in the way so at run time, the sending of vendor id 
can be enabled and disabled depending upon non-FIPS mode or FIPS mode.

If you do it at compile time like you did above then, even during 
non-FIPS mode, it is not possible to send vendor id which should be allowed.

And the reason that it does not compile with USE_VENDORID=false is not 
due to HAVE_LIBNSS. The problem is there even if you do not have 
HAVE_LIBNSS enabled.

Thanks and Regards
>> Paul

More information about the Dev mailing list