Mailing List Archive

2008/4/10, Rainer Gerhards <rgerhards at hq.adiscon.com>:
> Hi folks,
>
> I just wanted to give you an update on my native TLS plans. I've been
> searching around and trying things the past days. As it looks now, I
> will use a wrapper class to cover nss and gnutls. Contrary to what I
> initially thought, I'll now probably start with GNUTls. The reason is
> that it seems to be much easier to start with it. For some insight,
> please follow this discussion on the NSS newsgroup:
>
> http://groups.google.com/group/mozilla.dev.tech.crypto/browse_frm/thread
> /45e418ca0a556a42
>
> That doesn't mean I settle for just GNUTls. Even if I start with it, NSS
> support will follow. I hope it will be easier to implement when I can
> check the NSS manuals for specific functionality.
>
> I thought I let you know.

Is it technically necessary to implement the layer via a separate
library (libsci), or could the layer also be implemented directly
within rsyslog as (libtool) convenience lib?

The point is, that a separate library means more works for packagers
and people who want to compile rsyslog themselves.

If you think, that libsci might be useful for other projects, then
implementing it as a system library makes sense (or due to licensing
matters).
If libsci will only be used within rsyslog though, I think
implementing it as a libtool convenience lib within rsyslog makes more
sense.

Just my 2?
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

Michael,

I fully agree, but licensing is the culprit. I think it'll be either LGPL or BSD. I'd really prefer to plug it directly into librelp and rsyslog, but that will create license conflicts.

Depending on how it works out, it may be useful for others, too. But that's not the primary focus.

Rainer

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Michael Biebl
> Sent: Thursday, April 10, 2008 3:29 PM
> To: rsyslog-users
> Subject: Re: [rsyslog] Status of TLS development
>
> 2008/4/10, Rainer Gerhards <rgerhards at hq.adiscon.com>:
> > Hi folks,
> >
> > I just wanted to give you an update on my native TLS plans. I've
> been
> > searching around and trying things the past days. As it looks now, I
> > will use a wrapper class to cover nss and gnutls. Contrary to what I
> > initially thought, I'll now probably start with GNUTls. The reason
> is
> > that it seems to be much easier to start with it. For some insight,
> > please follow this discussion on the NSS newsgroup:
> >
> >
> http://groups.google.com/group/mozilla.dev.tech.crypto/browse_frm/threa
> d
> > /45e418ca0a556a42
> >
> > That doesn't mean I settle for just GNUTls. Even if I start with it,
> NSS
> > support will follow. I hope it will be easier to implement when I
> can
> > check the NSS manuals for specific functionality.
> >
> > I thought I let you know.
>
> Is it technically necessary to implement the layer via a separate
> library (libsci), or could the layer also be implemented directly
> within rsyslog as (libtool) convenience lib?
>
> The point is, that a separate library means more works for packagers
> and people who want to compile rsyslog themselves.
>
> If you think, that libsci might be useful for other projects, then
> implementing it as a system library makes sense (or due to licensing
> matters).
> If libsci will only be used within rsyslog though, I think
> implementing it as a libtool convenience lib within rsyslog makes more
> sense.
>
> Just my 2?
> Michael
> --
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog

2008/4/10, Rainer Gerhards <rgerhards at hq.adiscon.com>:
> Michael,
>
> I fully agree, but licensing is the culprit. I think it'll be either LGPL or BSD. I'd really prefer to plug it directly into librelp and rsyslog, but that will create license conflicts.

Where do you see the conflict? GnuTLS is LGPLv2.1+ (compatible with
GPLv3) and NSS is either MPL1.1, GPLv2+ or LGPLv2.1+ (which should be
fine with rsyslogs GPLv3).

Cheers,
Michael


--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

librelp is dual-licensed - GPLv2 + commercial license. So it is a no-go
to link to GPLv3. Sorry...

Rainer

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Michael Biebl
> Sent: Thursday, April 10, 2008 3:38 PM
> To: rsyslog-users
> Subject: Re: [rsyslog] Status of TLS development
>
> 2008/4/10, Rainer Gerhards <rgerhards at hq.adiscon.com>:
> > Michael,
> >
> > I fully agree, but licensing is the culprit. I think it'll be
either
> LGPL or BSD. I'd really prefer to plug it directly into librelp and
> rsyslog, but that will create license conflicts.
>
> Where do you see the conflict? GnuTLS is LGPLv2.1+ (compatible with
> GPLv3) and NSS is either MPL1.1, GPLv2+ or LGPLv2.1+ (which should be
> fine with rsyslogs GPLv3).
>
> Cheers,
> Michael
>
>
> --
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog

Bad typo. Should have been:

librelp is dual-licensed - GPLv3 + commercial license. So it is a no-go
to link to GPLv3. Sorry...

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards
> Sent: Thursday, April 10, 2008 3:40 PM
> To: rsyslog-users
> Subject: Re: [rsyslog] Status of TLS development
>
> librelp is dual-licensed - GPLv2 + commercial license. So it is a
no-go
> to link to GPLv3. Sorry...
>
> Rainer
>
> > -----Original Message-----
> > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> > bounces at lists.adiscon.com] On Behalf Of Michael Biebl
> > Sent: Thursday, April 10, 2008 3:38 PM
> > To: rsyslog-users
> > Subject: Re: [rsyslog] Status of TLS development
> >
> > 2008/4/10, Rainer Gerhards <rgerhards at hq.adiscon.com>:
> > > Michael,
> > >
> > > I fully agree, but licensing is the culprit. I think it'll be
> either
> > LGPL or BSD. I'd really prefer to plug it directly into librelp and
> > rsyslog, but that will create license conflicts.
> >
> > Where do you see the conflict? GnuTLS is LGPLv2.1+ (compatible with
> > GPLv3) and NSS is either MPL1.1, GPLv2+ or LGPLv2.1+ (which should
be
> > fine with rsyslogs GPLv3).
> >
> > Cheers,
> > Michael
> >
> >
> > --
> > Why is it that all of the instruments seeking intelligent life in
the
> > universe are pointed away from Earth?
> > _______________________________________________
> > rsyslog mailing list
> > http://lists.adiscon.net/mailman/listinfo/rsyslog
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog

2008/4/10, Rainer Gerhards <rgerhards at hq.adiscon.com>:
> Bad typo. Should have been:
>
> librelp is dual-licensed - GPLv3 + commercial license. So it is a no-go
>
> to link to GPLv3. Sorry...


GPLv3+/commercial is not incompatible with LGPLv2.1+

Am I missing something?

Michael


--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

2008/4/10, Michael Biebl <mbiebl at gmail.com>:
> 2008/4/10, Rainer Gerhards <rgerhards at hq.adiscon.com>:
>
> > Bad typo. Should have been:
> >
> > librelp is dual-licensed - GPLv3 + commercial license. So it is a no-go
> >
> > to link to GPLv3. Sorry...
>
>
>
> GPLv3+/commercial is not incompatible with LGPLv2.1+
>
> Am I missing something?

The whole point of the LGPL is, to be useful for commercial/closed
source applications.

And GPLv3+ and LGPLv2.1+ is no problem either.

I'm not a lawyer though, so take this with a grain of salt.

Michael

--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

On Thu, 2008-04-10 at 15:50 +0200, Michael Biebl wrote:
> 2008/4/10, Rainer Gerhards <rgerhards at hq.adiscon.com>:
> > Bad typo. Should have been:
> >
> > librelp is dual-licensed - GPLv3 + commercial license. So it is a no-go
> >
> > to link to GPLv3. Sorry...
>
>
> GPLv3+/commercial is not incompatible with LGPLv2.1+

If I put the crypto wrapper (code named so far libsci) into *rsyslog*
the crypto wrapper will be under GPLv3.

If librelp needs TLS functionality, it must link to the crypto-wrapper
*inside* rsyslog, which is GPLv3. librelp can not do that if it is not
used inside a GPLv3 program (because, in essence, I would need to
detouch those parts from rsyslog that are needed by librelp and then add
that to the non-GPLv3 application).

Or am I overlooking something?

A prominent example of what will use librelp functionality and is not
under GPLv3 is Adiscon's MonitorWare products under Windows (and keep in
mind that they currently sponsor rsyslog development ;)).

Rainer

2008/4/10, Rainer Gerhards <rgerhards at hq.adiscon.com>:
>
> On Thu, 2008-04-10 at 15:50 +0200, Michael Biebl wrote:
> > 2008/4/10, Rainer Gerhards <rgerhards at hq.adiscon.com>:
> > > Bad typo. Should have been:
> > >
> > > librelp is dual-licensed - GPLv3 + commercial license. So it is a no-go
> > >
> > > to link to GPLv3. Sorry...
> >
> >
> > GPLv3+/commercial is not incompatible with LGPLv2.1+
>
>
> If I put the crypto wrapper (code named so far libsci) into *rsyslog*
> the crypto wrapper will be under GPLv3.
>
> If librelp needs TLS functionality, it must link to the crypto-wrapper

Ok, this was probably my misconception.
I thought, only rsyslog would need the TLS functionality.
It wasn't clear to me, that *both* rsyslog and librelp would link
against libsci.

Cheers,
Michael

--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

On Thu, 2008-04-10 at 16:01 +0200, Michael Biebl wrote:
> Ok, this was probably my misconception.
> I thought, only rsyslog would need the TLS functionality.
> It wasn't clear to me, that *both* rsyslog and librelp would link
> against libsci.

Sorry, probably I've been to brief. Let me sort out things at least now:

Both rsyslog and librelp need native TLS functionality. For rsyslog,
this is to support plain TCP syslog via TLS (hopefully compatible with
the like syslog-ng and MonitorWare feature) as well as the upcoming IETF
syslog-transport-tls standard.

Librelps needs to do native TLS because it can not rely on an external
entity (like stunnel) and claim to be reliable and pretty tamperproof.
So it must talk to the remote peer directly. In RELP protocol, there
will be a STARTTLS command verb, just like in SMTP. Negotiation on the
availability of this verb is similar to SMTP's EHLO message or BEEP's
greeting message. Both the RELP protocol as well as librelp already
contain the necessary provisioning.

My intention is to make libsci available to anyone who may have a need
for it, but it will be focused on what I actually need. Please note that
I have intentionally called it libsci - simple *crypto* interface - and
not something like libsti - simple *tls* interface - because I intend to
place all crypto functions into a single library (thus relieving at
least a bit of the burden from an extra library). Other than TLS,
rsyslog will need to support digital signatures as well as generic
hashes (not only for cryptographic needs, but also for some other nice
things). If JF finally convinces me to implement some of the advanced
output plugin functionality as completely separate projects [he is
seeding that thought quite well ;)], these projects will most probably
also need to link to it. My intention is to put libsci under a very
liberal license, probably either a BSD style one or at least LGPL.

I have no idea yet when we will see any of libsci functionality in
practice ;)

I hope this finally clarifies. Sorry for the confusion. Please drop me
any questions that are still around.

Rainer