I would not be opposed to accepting an rpm packaging contribution, if anyone is willing. However, since I don't personally run any rpm-based distributions, I is pretty far down on my list of priorities to set up a test environment and figure out how to properly do rpm packaging these days
I would be also strongly interested in, but unfortunatly, this was written in "Rust", and there is a statement: Fedora's packaging guidelines require it to be unbundled to package. Not 100% sure what this means, see also:
I would be also strongly interested in, but unfortunatly, this was written in "Rust", and there is a statement: Fedora's packaging guidelines require it to be unbundled to package. Not 100% sure what this means
Note that the posts you link to were written about https://github.com/z4yx/pam_rssh. It seems to be different implementation of the same idea, both written in Rust.
Ok. I had a brief look at the packaging requirements, and it seems to me like most deps are already packaged (significantly rust-ssh-key), so this should be a pretty straight forward task. The one potential issue I sense from here is that there might be some work that needs to be done to either support old versions of dependencies or update those dependencies in Fedora
For offline mode on F42 (and rawhide) following rust packages are missing
rust-pam-bindings+default-devel
rus-ssh-agent-client-rs+default-devel
I have now an initial spec file created which in online mode build successfully locally (should also work on COPR with Internet access enabled) - functionalwise to be tested still:
Potentially missing rust dependencies need to be bundled in the source RPM until appearing in distro, are there already any hints around in other spec files?
Potentially missing rust dependencies need to be bundled in the source RPM until appearing in distro, are there already any hints around in other spec files?
Are you using rust2rpm? There's a section in a documentation that discusses how to "vendor" the dependencies in the RPM.
Thank you for the contributions! Just a small set of comments on the PR.
When it comes to pam_rssh it does indeed seem like we have two independent implementations of pretty much the same functionality. I am obviously partial in favour of my variation, here are some differences:
pam_rssh leans on openssl and rust to c bindings whereas pam-ssh-agent leans on the ssh-key crate with rust native crypto
There is quite a bit of code that interacts with openssl in sign_verify.rs that doesn't seem to be covered by unit tests in pam_rssh, by contrast pam-ssh-agent is leaning on ssh-key for those interactions, a crate with comprehensive testing and a larger user base
Each of the variants lean on a custom implementation of the ssh-agent binary protocol. ssh-agent-client-rs that pam-ssh-agent uses has API documentation, pretty extensive unit testing and example binaries using the API whereas ssh-agent.rs that pam_rssh uses lacks documentation and examples and has a significantly lower unit test coverage
pam_rssh has some variable extrapolation support in the pam config parametrs that pam-ssh does not yet have. With this push however, I feel keen to finish my half baked implementation that I started a while ago
Since I went through the exercise of comparing pam-ssh-agent to pam_rssh I felt like it would be good to plug the "feature gap" by implementing the little pieces still missing.
If someone following this issue uses variable extrapolation and could review/test my changes that would be most welcome, the PR is #26
Ok, I confess, I got nerd sniped into wrapping my head around how upstream Fedora / EPEL encourages packaging and upstream contributions. These are my preliminary findings:
The 3 crates that are not packaged upstream at all, pam-bindings, ssh-agent-client-rs and pam-ssh-agent can be built with dynamically generated .spec files and minimal rust2rpm.toml configuration. I have created a new git repository containing just the minimal stuff needed to build the .src.rpms for those in https://github.com/nresare/rpm-packaging
For the EPEL Enterprise Linux 10 package build there is a whole tree of packaged crates that are simply unavailable in upstream. Interestingly, with one exception, these can be built by simply uploading the Fedora 42 .src.rpms to a COPR project in the right order and CentOS Stream 10 + EPEL + a COPR repo will provide the needed dependencies
I have done this in the https://copr.fedorainfracloud.org/coprs/noa/rust/ project, so there is a pam-ssh-agent package available by simply running dnf copr enable noa/rust on your Fedora 42 or CentOS Stream 10 + EPEL
I guess the next step now is to find some Fedora packaging sponsor that could review and approve those pacakges. Does anyone on this thread have any contacts in that space?
I guess the next step now is to find some Fedora packaging sponsor that could review and approve those pacakges. Does anyone on this thread have any contacts in that space?
If you would maintain them by yourself, you can file New-Package request to Fedora and EPEL, once approved, you can push them.
I would start first with Fedora 42, once available there, then continue with EPEL. EL10 is rather new, so admins which asap need pam-ssh-agent here can survive with your COPR repo some weeks imho.
pam-ssh-agent leans on the ssh-key crate with rust native crypto
That's unfortunate, because it means this crate cannot be made to use a FIPS-validated implementation of the cryptographic primitives, which therefore means it will likely not be included in RHEL, whereas pam_rssh relying on OpenSSL, could be.
I realize that's not your problem, and it it's probably fine to include it in Fedora anyway, but it can cause problems for distributions downstream of Fedora that have to care about FIPS compliance, such as RHEL or Amazon Linux.
@neverpanic That is a factor I honestly had not thought about.
If that is a requirement, I could definitely write some code that would optionally call out to a different implementation for the signature validation. The needed functionality is a method to verify signatures of three different types.
It is a bit sad that FIPS compliance would force us to use a technically inferior solution. Googling about the topic of FIPS compliance, it seems we might see this for the ring crate at some point, but I do realise that that point is not now: https://briansmith.org/lets-build-a-fips-rust-crypto
@neverpanic there is now #33, a feature that when enabled defers crypto operations to the system native openssl library.
I now feel more convinced than ever that openssl is not nice software 😄
Wow, thank you! You didn't have to do this.
And yes, OpenSSL's API is not nice, that's well-known. It's marginally better with 3.x, but the rust openssl crate doesn't use 3.x APIs.
Is there anyone on this thread that has some friends within the Fedora packaging community that might be able to encourage someone to have a look the review requests?
Is there anyone on this thread that has some friends within the Fedora packaging community that might be able to encourage someone to have a look the review requests?
Activity
nresare commentedon Apr 10, 2025
I would not be opposed to accepting an rpm packaging contribution, if anyone is willing. However, since I don't personally run any rpm-based distributions, I is pretty far down on my list of priorities to set up a test environment and figure out how to properly do rpm packaging these days
pbiering commentedon May 12, 2025
I would be also strongly interested in, but unfortunatly, this was written in "Rust", and there is a statement: Fedora's packaging guidelines require it to be unbundled to package. Not 100% sure what this means, see also:
beldmit commentedon May 12, 2025
I think it means that you have to package each missing crate as a separate package. Don't know how many of them, BTW
neverpanic commentedon May 12, 2025
It means that you will also have to package the dependencies (https://github.com/nresare/pam-ssh-agent/blob/main/Cargo.toml#L16-L24) before you can package this software, if they aren't packaged in Fedora yet.
Note that the posts you link to were written about https://github.com/z4yx/pam_rssh. It seems to be different implementation of the same idea, both written in Rust.
nresare commentedon May 12, 2025
Ok. I had a brief look at the packaging requirements, and it seems to me like most deps are already packaged (significantly rust-ssh-key), so this should be a pretty straight forward task. The one potential issue I sense from here is that there might be some work that needs to be done to either support old versions of dependencies or update those dependencies in Fedora
pbiering commentedon May 13, 2025
For offline mode on F42 (and rawhide) following rust packages are missing
I have now an initial spec file created which in online mode build successfully locally (should also work on COPR with Internet access enabled) - functionalwise to be tested still:
Potentially missing rust dependencies need to be bundled in the source RPM until appearing in distro, are there already any hints around in other spec files?
AdmiralNemo commentedon May 13, 2025
Are you using
rust2rpm? There's a section in a documentation that discusses how to "vendor" the dependencies in the RPM.https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/#_vendored_dependencies
nresare commentedon May 13, 2025
Nice that you are making progress. ssh-agent-client-rs is my code, has a small set of dependencies, so it should be straightforward to package.
Please let me know if there are any changes that would be helpful to simplify packaging
pbiering commentedon May 13, 2025
spec file for F42 is working, EL10 started, but got temporary stucked because of missing
ssh-encoding, sure I found a solution next here...https://github.com/pbiering/pam-ssh-agent/blob/rpm-specfile/contrib/pam_ssh_agent.spec
pbiering commentedon May 14, 2025
Coming from Perl's CPAN "heaven", sucessfully sailed through Python's PyPI "purgatory", now entered the Rust's Crates "hell" :-(
Spec file enhanced, now able to build for F42, F43 and EL10 (ugly workarounds...but no other way to circumvent missing Rust dependencies)
https://github.com/pbiering/pam-ssh-agent/blob/rpm-specfile/contrib/pam_ssh_agent.spec
koji scratch builds for x86_64 are here until regular cleanup run:
successfully tested adding to /etc/pam.d/su and /etc/pam.d/sudo:
auth sufficient libpam_ssh_agent.so file=/root/.ssh/authorized_keysA maintainer is required now for Fedora and EPEL incl. a new-package request.
BTW: what should happen with https://github.com/z4yx/pam_rssh - has one compared the implementation?
pbiering commentedon May 15, 2025
Intermediate RPMs now are available for EL10/F42/F43 in my personal Fedora copr repository, currently based on my fork until this PR is merged.
https://copr.fedorainfracloud.org/coprs/pbiering/InternetServerExtensions/build/9046782/
See also
https://copr.fedorainfracloud.org/coprs/pbiering/InternetServerExtensions/
nresare commentedon May 16, 2025
Thank you for the contributions! Just a small set of comments on the PR.
When it comes to
pam_rsshit does indeed seem like we have two independent implementations of pretty much the same functionality. I am obviously partial in favour of my variation, here are some differences:sign_verify.rsthat doesn't seem to be covered by unit tests inpam_rssh, by contrastpam-ssh-agentis leaning onssh-keyfor those interactions, a crate with comprehensive testing and a larger user basessh-agent-client-rsthatpam-ssh-agentuses has API documentation, pretty extensive unit testing and example binaries using the API whereasssh-agent.rsthatpam_rsshuses lacks documentation and examples and has a significantly lower unit test coveragepam-sshdoes not yet have. With this push however, I feel keen to finish my half baked implementation that I started a while agonresare commentedon May 20, 2025
Since I went through the exercise of comparing
pam-ssh-agenttopam_rsshI felt like it would be good to plug the "feature gap" by implementing the little pieces still missing.If someone following this issue uses variable extrapolation and could review/test my changes that would be most welcome, the PR is #26
nresare commentedon May 24, 2025
Ok, I confess, I got nerd sniped into wrapping my head around how upstream Fedora / EPEL encourages packaging and upstream contributions. These are my preliminary findings:
pam-ssh-agentpackage available by simply runningdnf copr enable noa/ruston your Fedora 42 or CentOS Stream 10 + EPELI guess the next step now is to find some Fedora packaging sponsor that could review and approve those pacakges. Does anyone on this thread have any contacts in that space?
pbiering commentedon May 24, 2025
If you would maintain them by yourself, you can file New-Package request to Fedora and EPEL, once approved, you can push them.
I would start first with Fedora 42, once available there, then continue with EPEL. EL10 is rather new, so admins which asap need pam-ssh-agent here can survive with your COPR repo some weeks imho.
nresare commentedon May 24, 2025
Review request for pam-bindings: https://bugzilla.redhat.com/show_bug.cgi?id=2368361
Review request for ssh-agent-client-rs: https://bugzilla.redhat.com/show_bug.cgi?id=2368362
neverpanic commentedon May 26, 2025
That's unfortunate, because it means this crate cannot be made to use a FIPS-validated implementation of the cryptographic primitives, which therefore means it will likely not be included in RHEL, whereas pam_rssh relying on OpenSSL, could be.
I realize that's not your problem, and it it's probably fine to include it in Fedora anyway, but it can cause problems for distributions downstream of Fedora that have to care about FIPS compliance, such as RHEL or Amazon Linux.
nresare commentedon May 28, 2025
@neverpanic That is a factor I honestly had not thought about.
If that is a requirement, I could definitely write some code that would optionally call out to a different implementation for the signature validation. The needed functionality is a method to verify signatures of three different types.
It is a bit sad that FIPS compliance would force us to use a technically inferior solution. Googling about the topic of FIPS compliance, it seems we might see this for the ring crate at some point, but I do realise that that point is not now: https://briansmith.org/lets-build-a-fips-rust-crypto
nresare commentedon May 31, 2025
@neverpanic there is now #33, a feature that when enabled defers crypto operations to the system native openssl library.
I now feel more convinced than ever that openssl is not nice software 😄
carlos-sarmiento commentedon Jun 1, 2025
Most of the changes happening here go way above my head, but wanted to say thanks @nresare for all your effort on making this happen
neverpanic commentedon Jun 3, 2025
Wow, thank you! You didn't have to do this.
And yes, OpenSSL's API is not nice, that's well-known. It's marginally better with 3.x, but the rust openssl crate doesn't use 3.x APIs.
nresare commentedon Aug 8, 2025
Is there anyone on this thread that has some friends within the Fedora packaging community that might be able to encourage someone to have a look the review requests?
Review request for pam-bindings: https://bugzilla.redhat.com/show_bug.cgi?id=2368361
Review request for ssh-agent-client-rs: https://bugzilla.redhat.com/show_bug.cgi?id=2368362
pbiering commentedon Aug 8, 2025
Me not unfortunately.