Details
- Reviewers
delphij emaste - Commits
- rG0aa2700123e2: Put OPIE to rest.
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Passed - Unit
No Test Coverage - Build Status
Buildable 47410 Build 44297: arc lint + arc unit
Event Timeline
Can we start by adding deprecation notices to opie.4 and the opie-related section 1 commands and MFC that
what will happen if pam.d/ files still reference pam_opie.so or pam_opieaccess.so - i.e., if the user fails to update /etc somehow?
If they run make delete-old-libs without first updating their PAM policies, they will lock themselves out of everything except the single-user shell.
I don't think we have this documented, but I found an example of one I did in b218441ac074d9cb9417e284980bf87f79a89585
We also had some cases where tools printed the deprecation notice upon invocation, I'll see if I can find an example of one of those
97303f37f81110cfa6c7a9a4a723398d547ce78f and 86d0c432a6cf281711887f115fe8b62cc840c157 are some depreciation notices I added on program invocation/startup
I agree with doing this but I think we need to be very careful so that, as much as possible, users (even those who don't consistently read warnings, release notes, etc.) don't get tripped up by the PAM modules disappearing while they still have entries in /etc/pam.d/*.
What do you think about starting by removing them from lib/libpam/pam.d/? We could have freebsd-update emit a warning/error if we are going to remove the modules if they are still referenced - I can take a look at that, if you agree it's a decent idea.