Re: Putting OPIE to rest (was: Re: cant login after make installworld: pam_opie.so.6 not found)
On 1/5/23, Graham Perrin wrote:
> I recall the original email
Orthagonal as it, and some notes since neither consider any
potential gap issue or/of any perhaps whimful removal process,
nor moves forward on any of potential better alternatives to that
which were hint (port) a bit in posts even before the removal was taken.
Opie is not some hi-maint lo-api-compat legacy driver holding back
kernel dev, it's a tiny stable user app plugin that just works for decades.
Now users are posting locked out, punted to deploy non-replacements,
and can't even compile it back because code gone from trees in use.
There was hardly reason to remove it (lots of other things could be
considered "outlived usefulness" but don't get removed), and even
if so (as perhaps part of say some larger discuss on pam), there
was zero reason for the removal team not to portify it given
FreeBSD has already set good example of moving even
large/complex user apps from base to ports.
That should have, and still should be done, with opie.
Consider on that process for future,
rather than whatever is thought of some app.
Cheers.
Cc: ports, as the lo-maint hi-api-compat opie could also be
used to +1 their competitive 35k count :)
See also compat{M}x-{arch} packages.
> https://lists.freebsd.org/archives/freebsd-current/2022-September/002565.html
> https://lists.freebsd.org/archives/freebsd-hackers/2022-September/001479.html
> https://lists.freebsd.org/archives/freebsd-security/2022-September/81.html
Re: Putting OPIE to rest
On 9/15/22, Dag-Erling Smørgrav wrote: > Neither HOTP nor TOTP require dedicated devices. > HOTP codes are sequential and can be pre-generated... Those aren't really their intended or advertised usage models, nor do common implementations support those modes. Is FreeBSD contributing and supplying ones that do? OPIE's model already intends for and supports no-device and printout. To emphasize and extend... https://lists.freebsd.org/archives/freebsd-current/2022-September/002573.html It should also be noted that the affected scope here is not just 'FreeBSD users logging into FreeBSD shell', there are also applications out there that compile against and use FreeBSD's libopie, some of which are in ports some are not. OPIE does not exist as a port+package, thus re POLA for users, it should not be removed until such time as one is provided. Where is discussion on these. And why isn't every other 'old, outlived, non-hipster' pam authentication plugin being arbitrarily removed and non-portified, such as say tacacs, radius, krb, rhosts, etc. And if those pam are there, why then are hip OAUTH HOTP TOTP etc type things not added, lib-ified, etc.
Re: Putting OPIE to rest
grarpamp writes: > OPIE is the only PAM that allows printing out the future > secure tokens. Old school, secure, it just works. > > HOTP requires hardware, TOTP requires time, > neither are printable, both of those require some other > [hackable] hw/sw device that costs $$$ money, and > those devices all have different threat/failure/admin models > than simple paper. Neither HOTP nor TOTP require dedicated devices. HOTP codes are sequential and can be pre-generated and printed if that's what you prefer. DES -- Dag-Erling Smørgrav - d...@des.no
Re: Putting OPIE to rest
On 9/15/22, Dag-Erling Smørgrav wrote: > I will be removing OPIE from the main branch within the next few days. > It has long outlived its usefulness. Anyone still using it should look > into OATH HOTP / TOTP instead (cf. security/pam_google_authenticator). > https://reviews.freebsd.org/D36592 At least so long as PAM remains available, OPIE should be maintained as a PAM option, and be updated. OPIE is the only PAM that allows printing out the future secure tokens. Old school, secure, it just works. HOTP requires hardware, TOTP requires time, neither are printable, both of those require some other [hackable] hw/sw device that costs $$$ money, and those devices all have different threat/failure/admin models than simple paper. If people don't like... - The hash algo, a volunteer committer can update it to sha256. - The list of words, a volunteer committer can update it to read from a list of admin supplied words in: /etc/opie_words.txt - The number of words, a volunteer committer can add an option to the config for that. - The writeable state breaking in a read-only root, a volunteer committer can add a config option to point that elsewhere. - The randomness, a volunteer committer can update it to modern randomness. And if people still don't like it, then commit those simple updates, and push it out to ports, instead of killing users use of it.
Re: Putting OPIE to rest
Condolences to OPIE & his family of devs ! 🥀🥀🥀 ;) > On Sep 15, 2022, at 08:45, Dag-Erling Smørgrav wrote: > > I will be removing OPIE from the main branch within the next few days. > It has long outlived its usefulness. Anyone still using it should look > into OATH HOTP / TOTP instead (cf. security/pam_google_authenticator). > > https://reviews.freebsd.org/D36592 > > DES > -- > Dag-Erling Smørgrav - d...@des.no > -- J. Hellenthal The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume.
