There are a few issues found && fixed since 3.0.16. Unless there are major objections, I think we can release 3.0.17 next week. The next step after that would be to add support for multiple kinds of certificates at the same time. e.g. RSA and ECC. This is supported in OpenSSL since 1.0.2. It's starting to get more widely deployed, too. While we do try hard to have 3.0 in a "feature freeze", features can still be added if they are important enough. And I think this counts. Alan DeKok.
there are a couple of little open issues that aren't feature requests or nasties that would be good to close out with 3.0.17 alan
I was thinking eg 2186 - but that actually appears to have been fixed via a commit 2080 would be good to be put to rest alan
On Mar 29, 2018, at 3:24 PM, Alan DeKok <aland@deployingradius.com> wrote:
There are a few issues found && fixed since 3.0.16. Unless there are major objections, I think we can release 3.0.17 next week.
The next step after that would be to add support for multiple kinds of certificates at the same time. e.g. RSA and ECC.
As discussed offline, there are some side effects which makes this difficult to do whilst maintaining backwards compatibility. The big one is that using the 1.0.2 API to do certificate chaining seems to effectively disable auto chaining, as certs are no longer taken from the top level ca_file. The change to how chaining works between OpenSSL < 1.0.2 and >= 1.0.2 is so major I'm tempted to suggest that we have a hard dependency on 1.0.2 in the FreeRADIUS v4.0.x branch to avoid confusion. With FreeRADIUS 4 and < 1.0.2 - When auto_chain = yes (current default) is set, missing certs used to specify the complete certificate chain are take from those specified in ca_file. - Certs specified in certificate_file must be in exactly the right order - Server certificate chain not pre-compiled - Toggle to omit root CA is non-functional - ca_file in the chain {} section is non-functional, which means chains can't be built with DER certs (only one cert allowed per file). - Key agility is non-functional With FreeRADIUS 4 and >= 1.0.2 - Certificates never pass between the stores used for client validation and building the server certificate chain. - OpenSSL will automatically re-order certificates for you within the chain you're building. - OpenSSL verifies that you have a complete chain from RootCA to server cert. - Chain is pre-compiled. Without this the chain is compiled for every new SSL session. - Toggle to omit root CA is functional (and defaults to true). - ca_file in chain sections works, meaning you can build chains with DER certs too, and keep your CAs and intermediaries as separate files on disk. - Key agility works as expected. -Arran
On Mar 29, 2018, at 2:12 PM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
As discussed offline, there are some side effects which makes this difficult to do whilst maintaining backwards compatibility.
The big one is that using the 1.0.2 API to do certificate chaining seems to effectively disable auto chaining, as certs are no longer taken from the top level ca_file.
If it's possible to do *either* the old method or the new one, that may be useful. Once people start using ECC certs.
The change to how chaining works between OpenSSL < 1.0.2 and >= 1.0.2 is so major I'm tempted to suggest that we have a hard dependency on 1.0.2 in the FreeRADIUS v4.0.x branch to avoid confusion.
That sounds like a good idea. There's just no reason to use a version of OpenSSL which is years out of date. Alan DeKok.
On 29 Mar 2018, at 19:12, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
As discussed offline, there are some side effects which makes this difficult to do whilst maintaining backwards compatibility.
v3.2.x? Adam Bishop gpg: E75B 1F92 6407 DFDF 9F1C BF10 C993 2504 6609 D460 jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800. Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under company number 2881024, VAT number GB 197 0632 86. The registered office is: One Castle Park, Tower Hill, Bristol BS2 0JA. T 0203 697 5800.
On Mar 29, 2018, at 5:04 PM, Adam Bishop <Adam.Bishop@jisc.ac.uk> wrote:
On 29 Mar 2018, at 19:12, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
As discussed offline, there are some side effects which makes this difficult to do whilst maintaining backwards compatibility.
v3.2.x?
That may be the thing to do. It might also give us the opportunity to do some minor cleanups in v3, too. Not that I want more work. Alan DeKok.
On Mar 30, 2018, at 12:53 PM, Alan DeKok <aland@deployingradius.com> wrote:
On Mar 29, 2018, at 5:04 PM, Adam Bishop <Adam.Bishop@jisc.ac.uk> wrote:
On 29 Mar 2018, at 19:12, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
As discussed offline, there are some side effects which makes this difficult to do whilst maintaining backwards compatibility.
v3.2.x?
That may be the thing to do. It might also give us the opportunity to do some minor cleanups in v3, too.
We killed v3.1.x because it would confuse people. If we create v3.2.x from the v3.0.x branch the initial reason for killing v3.1.x would be invalid, and it would definitely confuse people who deployed v3.1.x. Lets not fragment the development effort further. v4.0.x is deployed in production environments today, the unlang keywords are now nearly fully async, and we have work arounds for xlat/tmpl expansions that involve yielding which means we can add yield/resume points to all the modules gradually over time (after the initial release of v4.0.x). -Arran
On 30 Mar 2018, at 14:01, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
If we create v3.2.x from the v3.0.x branch the initial reason for killing v3.1.x would be invalid, and it would definitely confuse people who deployed v3.1.x.
What's the current state of v3.1.x? Aren't they missing a whole heap of fairly critical fixes? The main reason I suggest it is that the next Ubuntu LTS is this year, and based on previous timings RHEL8 is almost certainly to be seen this year too or early next. This will drag out the life of the v3 branch considerably. Adam Bishop gpg: E75B 1F92 6407 DFDF 9F1C BF10 C993 2504 6609 D460 jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800. Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under company number 2881024, VAT number GB 197 0632 86. The registered office is: One Castle Park, Tower Hill, Bristol BS2 0JA. T 0203 697 5800.
On Mar 30, 2018, at 9:54 AM, Adam Bishop <Adam.Bishop@jisc.ac.uk> wrote:
What's the current state of v3.1.x? Aren't they missing a whole heap of fairly critical fixes?
v3.1.x is dead, and has been removed from github. It's missing tons of things. Don't use it.
The main reason I suggest it is that the next Ubuntu LTS is this year, and based on previous timings RHEL8 is almost certainly to be seen this year too or early next. This will drag out the life of the v3 branch considerably.
TBH, we should then stick with v3.0.x. Alan DeKok.
On Mar 30, 2018, at 3:01 PM, Alan DeKok <aland@deployingradius.com> wrote:
On Mar 30, 2018, at 9:54 AM, Adam Bishop <Adam.Bishop@jisc.ac.uk> wrote:
What's the current state of v3.1.x? Aren't they missing a whole heap of fairly critical fixes?
v3.1.x is dead, and has been removed from github. It's missing tons of things. Don't use it.
The main reason I suggest it is that the next Ubuntu LTS is this year, and based on previous timings RHEL8 is almost certainly to be seen this year too or early next. This will drag out the life of the v3 branch considerably.
TBH, we should then stick with v3.0.x.
We're getting better at automatically building our own packages too. This makes what RHEL and Ubuntu ship less relevant. If people have a compelling reason to use v4 then they can copy the few commands into a terminal it takes to setup the official package repository. -Arran
Adam, 3.1 is dead. Arran, Alan, thumbs-up to a v3.0.17. Can you just make sure that when you build the official packages, that you don't build against packages that are not available in either CentOS/RHEL 7 or EPEL 7 repos? I had hoped to deploy the official 3.0.16 package but it wanted a package that doesn't exist in any of the repos in question. :-) Stefan Paetow Consultant, Trust and Identity t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net skype: stefan.paetow.janet jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800. On 30/03/2018, 14:54, "Adam Bishop" <Adam.Bishop@jisc.ac.uk> wrote: On 30 Mar 2018, at 14:01, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote: > If we create v3.2.x from the v3.0.x branch the initial reason for killing v3.1.x would be invalid, and it would definitely confuse people who deployed v3.1.x. What's the current state of v3.1.x? Aren't they missing a whole heap of fairly critical fixes? The main reason I suggest it is that the next Ubuntu LTS is this year, and based on previous timings RHEL8 is almost certainly to be seen this year too or early next. This will drag out the life of the v3 branch considerably. Adam Bishop gpg: E75B 1F92 6407 DFDF 9F1C BF10 C993 2504 6609 D460 jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800. Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under company number 2881024, VAT number GB 197 0632 86. The registered office is: One Castle Park, Tower Hill, Bristol BS2 0JA. T 0203 697 5800. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Mar 30, 2018, at 1:22 PM, Stefan Paetow <Stefan.Paetow@jisc.ac.uk> wrote:
Arran, Alan, thumbs-up to a v3.0.17. Can you just make sure that when you build the official packages, that you don't build against packages that are not available in either CentOS/RHEL 7 or EPEL 7 repos? I had hoped to deploy the official 3.0.16 package but it wanted a package that doesn't exist in any of the repos in question.
The main issue is that RH has decided to move from OpenSSL to NSS. They've *partially* done the port. So libldap links to NSS, but other applications such as FreeRADIUS don't. Trying to use libldap+NSS with FreeRADIUS+OpenSSL is a recipe for disaster. NSS has an OpenSSL wrapper / compatibility layer. So that layer ends up "stealing" the OpenSSL functions from FreeRADIUS, and then everything crashes. As a result, we need to have FR link to a version of libldap that uses OpenSSL. Which RH doesn't distribute. If you're not using LDAP, this is mostly moot. Alan DeKok.
Ok, Do you have a location where this alternative can be downloaded (at least we can document this, right?) That way we can point at the Wiki when this question pops up again. :-) Stefan Paetow Consultant, Trust and Identity t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net skype: stefan.paetow.janet jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800. On 30/03/2018, 18:28, "Freeradius-Users on behalf of Alan DeKok" <freeradius-users-bounces+stefan.paetow=jisc.ac.uk@lists.freeradius.org on behalf of aland@deployingradius.com> wrote: On Mar 30, 2018, at 1:22 PM, Stefan Paetow <Stefan.Paetow@jisc.ac.uk> wrote: > > Arran, Alan, thumbs-up to a v3.0.17. Can you just make sure that when you build the official packages, that you don't build against packages that are not available in either CentOS/RHEL 7 or EPEL 7 repos? I had hoped to deploy the official 3.0.16 package but it wanted a package that doesn't exist in any of the repos in question. The main issue is that RH has decided to move from OpenSSL to NSS. They've *partially* done the port. So libldap links to NSS, but other applications such as FreeRADIUS don't. Trying to use libldap+NSS with FreeRADIUS+OpenSSL is a recipe for disaster. NSS has an OpenSSL wrapper / compatibility layer. So that layer ends up "stealing" the OpenSSL functions from FreeRADIUS, and then everything crashes. As a result, we need to have FR link to a version of libldap that uses OpenSSL. Which RH doesn't distribute. If you're not using LDAP, this is mostly moot. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (6)
-
Adam Bishop -
Alan Buxey -
Alan DeKok -
Arran Cudbard-Bell -
Matthew Newton -
Stefan Paetow