Kill net/tacacs+ ?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Kill net/tacacs+ ?

Jeremie Courreges-Anglas-2

Hi,

net/tacacs+ shows its age, the md5 code uses "long" as if it was 32
bits, which probably doesn't fly on amd64.  DES supports relies on
crypt(3), which our libc doesn't support.  End result: I was not able to
perform a single successful auth with Authen::TacacsPlus.  Also the
logging code suffers from at least one stack overflow.  So afaics the
current port is unusable.

Our current port already needs patches to build with clang, along with
getpwnam_shadow & LP64 stuff (not all of them are fixed).  Quite
a maintenance burden.

So I propose to just delete this port for now.  If people are actually
interested in tacacs+ support, they can still propose a new port based
on the newer, much cleaner releases published by the folks at
shrubbery.net.

ok to kill it?

--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

Reply | Threaded
Open this post in threaded view
|

Re: Kill net/tacacs+ ?

Stuart Henderson
On 2017/12/07 20:26, Jeremie Courreges-Anglas wrote:

>
> Hi,
>
> net/tacacs+ shows its age, the md5 code uses "long" as if it was 32
> bits, which probably doesn't fly on amd64.  DES supports relies on
> crypt(3), which our libc doesn't support.  End result: I was not able to
> perform a single successful auth with Authen::TacacsPlus.  Also the
> logging code suffers from at least one stack overflow.  So afaics the
> current port is unusable.
>
> Our current port already needs patches to build with clang, along with
> getpwnam_shadow & LP64 stuff (not all of them are fixed).  Quite
> a maintenance burden.
>
> So I propose to just delete this port for now.  If people are actually
> interested in tacacs+ support, they can still propose a new port based
> on the newer, much cleaner releases published by the folks at
> shrubbery.net.
>
> ok to kill it?

Your research is convincing. OK!

Reply | Threaded
Open this post in threaded view
|

Re: Kill net/tacacs+ ?

Renaud Allard-2
On 12/07/2017 11:20 PM, Stuart Henderson wrote:

> On 2017/12/07 20:26, Jeremie Courreges-Anglas wrote:
>>
>> Hi,
>>
>> net/tacacs+ shows its age, the md5 code uses "long" as if it was 32
>> bits, which probably doesn't fly on amd64.  DES supports relies on
>> crypt(3), which our libc doesn't support.  End result: I was not able to
>> perform a single successful auth with Authen::TacacsPlus.  Also the
>> logging code suffers from at least one stack overflow.  So afaics the
>> current port is unusable.
>>
>> Our current port already needs patches to build with clang, along with
>> getpwnam_shadow & LP64 stuff (not all of them are fixed).  Quite
>> a maintenance burden.
>>
>> So I propose to just delete this port for now.  If people are actually
>> interested in tacacs+ support, they can still propose a new port based
>> on the newer, much cleaner releases published by the folks at
>> shrubbery.net.
>>
>> ok to kill it?
>
> Your research is convincing. OK!
>
>
I can confirm the current port is unusable as I am trying to implement
it right now to replace an aging server. Using code from shrubbery.net
works fine with almost only one patch for getpwnam_shadow().
Unfortunately, the DES code needs to be reimported into the port for DES
to be usable. Maybe a cleaner approach would be to implement blowfish
instead of DES in the configuration file, but that won't allow to reuse
old config file passwords without knowing them.


smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Kill net/tacacs+ ?

Jeremie Courreges-Anglas-2
On Fri, Dec 08 2017, Renaud Allard <[hidden email]> wrote:

> On 12/07/2017 11:20 PM, Stuart Henderson wrote:
>> On 2017/12/07 20:26, Jeremie Courreges-Anglas wrote:
>>>
>>> Hi,
>>>
>>> net/tacacs+ shows its age, the md5 code uses "long" as if it was 32
>>> bits, which probably doesn't fly on amd64.  DES supports relies on
>>> crypt(3), which our libc doesn't support.  End result: I was not able to
>>> perform a single successful auth with Authen::TacacsPlus.  Also the
>>> logging code suffers from at least one stack overflow.  So afaics the
>>> current port is unusable.
>>>
>>> Our current port already needs patches to build with clang, along with
>>> getpwnam_shadow & LP64 stuff (not all of them are fixed).  Quite
>>> a maintenance burden.
>>>
>>> So I propose to just delete this port for now.  If people are actually
>>> interested in tacacs+ support, they can still propose a new port based
>>> on the newer, much cleaner releases published by the folks at
>>> shrubbery.net.
>>>
>>> ok to kill it?
>>
>> Your research is convincing. OK!
>>
>>
>
> I can confirm the current port is unusable as I am trying to implement
> it right now to replace an aging server. Using code from shrubbery.net
> works fine with almost only one patch for getpwnam_shadow().

Probably because that version doesn't drop to an unprivileged user, for
which getpwnam_shadow() cannot work.

> Unfortunately, the DES code needs to be reimported into the port for DES
> to be usable. Maybe a cleaner approach would be to implement blowfish
> instead of DES in the configuration file, but that won't allow to reuse
> old config file passwords without knowing them.

No idea about DES.  We don't have support for this in crypt(3) any more.

As discussed with Renaud, we might see a more recent port in the near
future.  For now, I'll just remove the port.

Thanks for the feedback!

--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE