Release 0.10.3

[nervo]

Do you plan to sync your code with sourceforge, and release a 0.10.3 version on github ?

[blysik]

I'd love to see a 0.10.3 release also! Thanks.

[torarnv]

From what I can tell ce3515b matches the exact content of pam_ssh_agent_auth-0.10.3.tar.bz2.

Running git status after copying the contents of that file into the repository checked out at that revision shows "nothing to commit, working tree clean".

Perhaps ce3515b can be tagged as v0.10.3, and a release cut from that, so that it's clear that the state of the master branch is further along (0.10.4)?

[lizthegrey]

+1 that tagging 7ff7858 as v0.10.4 would be helpful.

[wmertens]

I think the holdup is all those package descriptions that need updating

[cavokz]

Is there a plan to make any release actually? I see quite some interest around this module but no activity on the branch for the past year. I'd like to help bringing this forward, co-maintain, test, add CI etc but I don't want to be alone, I would definitively share the commit rights with some other volunteer. Any thought?

[oxr463]

@jbeverly ping

[jbeverly]

The biggest holdup is that I never have time in my life! @cavokz I'd be curious to speak with you a little about your co-maintainer offer. (and anybody else).

I'd need to restructure the project a little bit to aid with collab development; and I'd like to talk about my (seemingly ancient) plans of migrating this "2.0" repository. And, as this is a security component, we'll need a vetting strategy to ensure contributions remain safe and good-willed.

[cavokz]

Same here, free time is scarce resource. The only way is to reduce the maintenance burden and be deadly efficient.

About plan for "2.0", would you consider contributing this module to the openssh-portable project, if they are interested?

This would help with all points you made:

1. safe and good-willed contribs (e.g. good implementation of the crypto basics)
2. maintenance (reusing everything openssh already provides would reduce the module to a bare minimal implementation)
3. relevance (new ssh-agent keys schemes, e.g. PKCS#11 and *-sk for security tokens)

What do you think?

[cavokz]

I started a new implementation based on openssh-portable. It's quite minimal, it just supports the file= option and only one public key in said file.

The PAM module itself is quite contained, it reuses everything from openssh-portable and already supports ecdsa-sk and ed25519-sk ssh keys. I also hooked up the testing code, based on pam_wrapper (see https://lwn.net/Articles/671094/ and https://cwrap.org/pam_wrapper.html).

I'll soon ask on openssh-unix-dev if the approach is sound and if there is any chance to get it merged once it's matured enough.

Feel free to look at the code and try it: https://github.com/cavokz/pam-ssh-agent

[jbeverly]

Somewhat ironically, https://github.com/jbeverly/pam_ssh_agent_auth-2.0/tree/jamie.2.0_wip was essentially exactly this; a minimal diff from openbsd portable with the goal being to make it an ongoing rebased patch to upstream (and setup CI to run that rebase and test cycle and alert me when it breaks) but I haven't had time to finish the build env; nor get CI setup for it.

I'd be very happy if this was incorporated in upstream and primary dev moved there. The only reason I've held off with that is because that patch is now ~2 years old now; and needs to be caught back up to current.

[cavokz]

I eventually submitted the patch for review, it sparked interesting comments.

[lizthegrey]

What about discussing the use case for performing allowlist authentication for initial auth (to allow being more specific about which SSH keys are allowed to bypass other parts of the PAM stack?

[cavokz]

I can only invite you to join the thread on the openssh mailing list. It's a pity to fork the discussion here.

[jbeverly]

It's a bit similar to the conversation this sparked in IRC 10ish years ago.

I should also note, there is also the patch that redhat maintains for the version they ship in RHEL; and there's an ubuntu version as well in universe. I think the redhat version is closer to upstream openssh-portable.

As evidenced in the openssh conversation; there's some push that this be somewhere other than openssh-portable due to the PAM-centric nature of it. (thus the reason I had intended for the future of this project to look more like RHEL has done; but make that and other maintainers' jobs much easier by keeping that patch current)

I do wish instead of making a completely new implementation we could have worked on getting this long tested and well adopted solution better aligned with the community's use-cases. So many of the things coming up in the openssh-portable list have already been addressed here well over a decade ago, and so that makes the conversation more challenging.

[cavokz]

Looking for the RHEL patch was the first thing I did but I really could not find it. Do you have any link to it?

I waited for two weeks for your reply to my message above, then I started the coding on my own. As I said, I don't have much free time and I needed to bootstrap it right now or never. The situation is now rather under control, the tests are very effective and development can continue very efficiently.

Yesterday evening I implemented the permission checks on the auth file (and along the way I added the support for multiple public keys in it), the easy one, and the tests caught everything very well. I extended them to verify the new changes. The agent socket is a different story, the tests cases are in place and indeed fail due to the different nature of the socket.

That said, my needs are actually totally covered by the sshd solution and it's for me very tempting to just turn the page. On the other hand, I see that this need has been around for a while and the solutions adopted are quite fragmented, everybody on his own, which I think is quite dangerous.

I think I'm in a good position for a fresh start, easily auditable code and strict testing. If eventually I'll go preparing releases, they would be in form of patches applied on top of openssh-portable releases (with some aid to make the build & install process easier).

The three points I mentioned above are still holding.