[Nut-upsdev] NSS branch testing.
rcrit at greyoak.com
Tue Aug 14 13:01:38 UTC 2012
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 :
> 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 22.214.171.124 to 126.96.36.199 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
> 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
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.
More information about the Nut-upsdev