Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Requirements gathering for pam_usb alternative #36

Open
andrey-utkin opened this issue Aug 29, 2017 · 1 comment
Open

Requirements gathering for pam_usb alternative #36

andrey-utkin opened this issue Aug 29, 2017 · 1 comment

Comments

@andrey-utkin
Copy link

Hi all, developers and users,

It's pity that pam_usb is unmaintained and nothing else has emerged yet. I used pam_usb for a while a couple of years ago and I have mixed review on it - mainly stability issues. Setup also felt a bit more complex than it could be. Nowadays udisks v1 dependency is another odd issue (while it feels simple udev hook alone would do).

So I wonder if anybody would like to contribute to requirements document for a software fulfilling same purpose, but without baggage of pam_usb project. Would you like basically the same what pam_usb provides, or would you want something more, or would you want to have more stripped-down tool (e.g. no agent process hanging around)? Would you agree to give up "one time pads" and go with static key?

Would really love @aluzzardi feedback on what would he do differently if given a chance to do it anew.

@aluzzardi
Copy link
Owner

@andrey-utkin Why not contribute to pam_usb instead of starting from scratch?

I'd be happy to hand over maintainership to committed individuals.

There have been PRs in the past to move over to udisk2 (/cc @Danesprite @luka-n).

Regarding my feedback, I'd say, in no particular order:

  • Move away from udisks1
  • Reconsider the technologies used. I don't think we necessarily need to switch to udisks2 - maybe udev can be used directly, or maybe systemd? pam_usb went from scanning /dev to using HAL, to relying on udev/udisks and maybe today that's not the best solution anymore
  • Rewrite the tools. The main module is fine the way it is (it doesn't have to do much), but the tools are old. If I had to do this today, I'd probably rewrite the tools in Go (small binaries with tiny memory footprint)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants