similar to: [nut-commits] svn commit r2809 - branches/ssl-nss-port/server

Citeren Emilien Kia <emilienkia-guest op alioth.debian.org>: > Modified: branches/ssl-nss-port/server/conf.c > ============================================================================== > --- branches/ssl-nss-port/server/conf.c Wed Jan 5 21:12:03 2011 (r2803) > +++ branches/ssl-nss-port/server/conf.c Thu Jan 6 10:27:55 2011 (r2804) > @@ -178,6 +178,22 @@ > return

Hi all, After client's certificate verifications discussion in the mailing-list, I have done some tests with nut trunk and - if my config is not too bad - I think ther is a bug with server certificate verification. With a clean trunk checkout, compile and installation; and with the following config : upsmon.conf: CERTPATH /usr/local/ups/etc/cert/ CERTVERIFY 1 FORCESSL 1 Upsd.conf: CERTFILE

Hi all, on proposal by Arnaud Quette and sponsored by Eaton, I will work on a port on Java of client, discovery and config API. As I have already suggested (mail of 2011-06-14 of this ml), instead of developping another port of nut protocol, I suggest to develop a higher level API in C/C++ uppon existing upsclient, inspirated by existing C-based tools and python and perl rewrites. The second

Hi all, I am pleased to announce that NSS port of NUT is finished. Port is fully functionnal (same functionnalities as openssl, and a not-activated-by-default client certificate validation function) and successfully tested by myself (external tests are pending, Frederic Bohe is planned for) with a test matrix which will be uploaded to the web site soon (by Arnaud), tested functionnality by

Credit goes to "cppcheck". Signed-off-by: Thomas Jarosch <thomas.jarosch at intra2net.com> --- drivers/mge-utalk.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/mge-utalk.c b/drivers/mge-utalk.c index c6114c7..616e2ad 100644 --- a/drivers/mge-utalk.c +++ b/drivers/mge-utalk.c @@ -465,7 +465,8 @@ void upsdrv_shutdown(void) { char

Credit goess to "cppcheck" Signed-off-by: Thomas Jarosch <thomas.jarosch at intra2net.com> --- drivers/usb-common.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/usb-common.c b/drivers/usb-common.c index e51f3cf..e459872 100644 --- a/drivers/usb-common.c +++ b/drivers/usb-common.c @@ -116,7 +116,7 @@ int USBNewExactMatcher(USBDeviceMatcher_t

Credit goes to "cppcheck" Signed-off-by: Thomas Jarosch <thomas.jarosch at intra2net.com> --- common/common.c | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/common/common.c b/common/common.c index f443cb7..e8004d7 100644 --- a/common/common.c +++ b/common/common.c @@ -244,6 +244,7 @@ int sendsignalfn(const char *pidfn, int sig) if (fgets(buf,

2012/10/12 Emilien Kia <kiae.dev at gmail.com> > Hi guys, > Hi Emilien and the list, This is a pull request to finally merge NSS feature in nut trunk: > https://github.com/clepple/nut/pull/3 > I'd like to take a moment to shed some more light on this important development, which lasted 3 years: - the initial

Hello All 2015-03-26 9:03 GMT+01:00 Arnaud Quette <arnaud.quette at gmail.com>: > > > What I will do is to move ssl initializing after usering and forking, > than add key file right checking where ssl was initialized before (before > forking). > > As keys should be owned by nut user, this would not be a problem. > > And moving this code, independently of SSL

If you don't use 'CERTVERIFY 1', then this will at least make sure that nobody can sniff your sessions without a large effort (...) > So, do I misunderstand CERTVERIFY directive ? Or is there a bug ? >> Can you reproduce such behaviour ? >> > > I'm not sure what is going on. Can you try running 'upsmon' with debugging > enabled? The following are

Dear fellows, As you have probably seen, NUT has had a recent boost through the help of Eaton. Frederic Bohe (contractor for Eaton France) has worked on Augeas, and is now working the Windows port. Chetan Agarwal, seconded by Prashi Gandi (both from Eaton India) are working on XCP and quality / validation related projects. I'm now pleased to announce that Emilien Kia (contractor for Eaton

While browsing the sources of the nss-ssl-port sources I noticed that client certificates were added. What is the reason behind this? As far as I can see, using a server certificate and validating it in the upsmon client should provide us with a secure channel. Authorizations for the server will then be handled by the settings in upsd.users by logging into the server with user and

Hi All, Perhaps you have seen, a few weeks ago, a release of jNut-0.2 which introduces nut-scanner capability to jNut java library, see http://networkupstools.org/download.html#_java_packages. With this package have been released jNutWebApi, a java web archive which uses jNut to present some UPSD and nut-scanner data on the form of a web service. This package is a maven-based project

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 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.

Citeren Arjen de Korte <adkorte-guest op alioth.debian.org>: > Log: > Use the 'nss_compat_ossl' compatibility layer to use the Mozilla NSS > library instead of OpenSSL (we might want to include native support > in the future, but this will at least allow a quick migration for > testing purposes) I don't recall that we ever discussed the possibility of

I am unable to get 2.7.4 to work with NSS support as provided by libnss3 2:3.26.2 on Debian stretch. Currently NSS supports two database formats identified by prefixes "sql:" for the new database and "dbm:" for the legacy database. I created the NSS database in directory /etc/nut with command certutil -N -d dbm:NSS_db --empty-password I copied over public key and

2015-03-21 17:06 GMT+01:00 Melkor Lord <melkor.lord at gmail.com>: > > On Fri, Mar 20, 2015 at 4:40 PM, Emilien Kia <kiae.dev at gmail.com> wrote: > > Some precisions: >> >> we are not alone, some projects had similar problem: >> http://bugs.bitlbee.org/bitlbee/ticket/785 >> And the problem is really coming from NSS initialization. Discussion

[I took the liberty of replying on nut-upsdev - not many people are using github yet since the NUT repository native format is still SVN.] On Sep 4, 2012, at 10:17 AM, Emilien Kia wrote: > This is a proposal for a new client library which scopes an higher level than the existing libupsclient. > > It needs less dependencies to be compiled than the libupsclient and can be easier to

2015-03-26 9:03 GMT+01:00 Arnaud Quette <arnaud.quette at gmail.com>: > Hey mister M' > > A first huge thanks for taking care of this, and so late in the night. I > know that it's not easy... > > (sent from my S3... please excuse my brevity) > Le 25 mars 2015 18:49, "Emilien Kia" <kiae.dev at gmail.com> a ?crit : > > > > > >

Some precisions: we are not alone, some projects had similar problem: http://bugs.bitlbee.org/bitlbee/ticket/785 And the problem is really coming from NSS initialization. Discussion about the issue here : http://osdir.com/ml/mozilla.crypto/2002-08/msg00016.html There is a workaround to use NSS with fork but it is more setting a flag to share some resources (primarily sockets) but must