[Nut-upsdev] NSS branch testing.

[Rob Crittenden]

Arnaud Quette wrote:
> Hi Rob
> 
> I'm taking over the answer, since Emilien (the coder) is on vacation...
> Though he kindly took 5 mn to give me the rationales needed.
> 
> 2012/8/10 Rob Crittenden <rcrit at greyoak.com <mailto:rcrit at greyoak.com>>
> 
>     FredericBohe at Eaton.com wrote:
> 
>         Hello all,
> 
>         In order to prepare the merge of the NSS branch to the trunk, I
>         have validated the code in this branch by passing this
>         validation document written by Emilien Kia :
> 
>         http://www.networkupstools.__org/tmp/NUT-NSS_Mini_DVT_Plan-__final.pdf
>         <http://www.networkupstools.org/tmp/NUT-NSS_Mini_DVT_Plan-final.pdf>
> 
>         The testing has been done on rev 3685 of the ssl-nss-port branch.
>         As you can read, I have found no issue.
> 
>         Let me know if you have any comments on this.
> 
> 
>     What is the value of creating two CA's? If you have one
>     infrastructure, why not have one CA and issue all certificates from
>     that one CA?
> 
>  
> there are 2 CA for testing purposes of cascaded certificates and CA.
> Refer to tests 3.3.3.1 to 3.3.3.4 for the end results, you will see that 
> CA2 cause failures (as expected).

Yeah, sorry about that, I didn't read it closely enough.

>     You should also check for the existence of NSPR in NUT_CHECK_LIBNSS,
>     especially since you've hardcoded those libraries as a fallback.
> 
> 
> valid, I've added it to the TODO list, for post merge.
>  
> 
>     It isn't clear, can you have an NSS database with no password set?
> 
> 
> not sure.
> As per Emilien's comment, this passwd may be used to encrypt the DB.
> Thus, no passwd would either mean that the DB is not accessible (if 
> password is mandatory) or not encrypted.

A password should only be mandatory in FIPS mode. My thinking was that 
since you have to put the password into a file, some people may want to 
simply leave the database password-less and rely on file or SELinux 
permissions (similar to an unencrypted private key in OpenSSL).

>  
> 
>     In server/netssl.c::nss_error you use a buffer of size SMALLBUF and
>     in ssl_error 256. Why the difference?
> 
>  
> error on the coder side. I've also added it to the TODO list, for post 
> merge.
> though I'm not yet sure which one is the more suitable (not looked at 
> the code).
> 
>     The NSS code looks good to me.
> 
> 
> thanks, I like to have tons of eyes looking
> 
> @Rob & Michal: side question, what's the NSS status in RedHat? Do you 
> see anything more we can do in NUT to improve the upcoming NSS / NUT 
> integration?

I don't really do much crypto work anymore, just happen to be a fan of 
NUT so threw in my .02. I've seen improvements to the PEM PKCS#11 module 
and there is a relatively new project (maybe a year old), python-nss, 
that is moving along nicely.

One thing I noticed is that there aren't a lot of knobs to turn relative 
to SSL. No way to control the ciphers, or even to limit to TLS. That is 
a bit of a nice-to-have, but tricky since OpenSSL and NSS ciphers are 
handled so differently, getting parity is tough.

regards

rob