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 <[email protected] <mailto:[email protected]>>
[email protected] 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
_______________________________________________
Nut-upsdev mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
