Considering submitting RPM SPEC file. Is there opposition to EL7/8 of LinOTP 3.x officially maintained?

[michaelsmoody]

Good afternoon!

For various reasons, we (and I'm sure we're not alone in this) would need "officially" maintained RPM sources of LinOTP upstream in order to properly use it. Even though I can successfully build it, our compliance profile really needs us to use an official standard source that requires it to come from the upstream.

I'm therefore considering submitting a PR/merge with an RPM SPEC file for the repository as is, to build its current state on an on-going basis. This should enable relatively easy CI/CD. However, I'd like to understand if there's an opposition to the 3.x series on EL7/8 prior to investing this time? Or if the matter is more practical in nature?

Please let me know, and I'll work on the SPEC file. Creating these RPM artifacts would be incredibly ideal, as we (and I'm sure others) could then use 3.x readily.

THANKS!
Michael S. Moody

(Open for any comments)

[michaelsmoody]

@lukengda @lse-fabian @lse-veronika @lse-omar

I apologize for the direct '@'s, but I'm not sure if anyone saw this issue. I'm (and perhaps "we") are willing to undertake maintenance of the RPMSPEC file for LinOTP 3.x, at least for the foreseeable future. At least, until it's brought stable and under your wing. But can you confirm there's interest in it being supported and RPMs hosted by LinOTP for a viable repository with the necessary toolchain/infrastructure to build and sign the RPMs?

I'm very happy to build it, confirm it's working, and work closely with everyone to make sure it's working, and on as many EL-based distributions as possible (and confirm unit testing). We're looking primarily for RHEL-derivates and of course Amazon Linux 2, both in and out of FIPS mode and with SELinux (preferably ON), so I'm willing to put in the work to make sure that the relevant SElinux contexts, binaries, etc, are all set, and test this on the most restricting system baselines possible (such as CIS and STIG.

So, if there's interest, I'll put in the work to make it work, on RHEL-derivatives, in FIPS mode, with SELinux on, with a reliable RPMSPEC.

You're already mentioned in several pieces of AWS documentation by default, to work with AWS Managed AD as a solution for MFA, and as a competitor to other MFA solutions, so let's get this updated for the 3.x version for RPM-based distributions, rather than just APT-based.

[lse-veronika]

Hi @michaelsmoody,

It is great to see people who want to contribute to open source software.
I am sorry that I can not answer your questions; I have left the company around LinOTP several years ago and am not involved in the development any more.

Best, Veronika

[authprivsec]

Hi @michaelsmoody,

thank you for your interest in our products.

First of all, sorry for the delay in answering. This was on me. The team pressed me to answer almost daily. Sorry it took so long.

As you might know, LinOTP is developed exclusively by a development team at netgo. Several members of the development and support teams are with the product for over 10 years. We really appreciate if somebody is willing to put this level of effort into our product. Thats why the team was happy to see your offer and pressed me to answer.

You might also be aware about LinOTP building the core of our commercial offerings. From a product perspective we have to consider business and legal implications in any external contribution. Copyright and how it is perceived in commercial contracts is not always in agreement with the common sense here. At the current time, we can not accept pull requests on this level. Your offer started some wheels and we are currently reevaluating some of the policies around this, but I can not foresee the final conclusion. This is why I did not answer earlier.

We will provide RHEL8 (and 9) packages to our customers for LinOTP 3 first. For now, we did not declare LinOTP 3 ready for production to our customers, since, after very rigorous internal testing, we still encountered some migration issues from LinOTP2 backups and want this process to be very solid for our LinOTP Virtual Appliance and also RHEL for the final customer release. The published code of LinOTP3 itself is thoroughly QA tested already, and will get a new version 3.2.2 soon(TM). So no issue in using it ATM, but LinOTP is used in very critical environments and we do our best to provide a solid solution and tend to be cautious in migrations.

For our RHEL customers we provide all packages needed in an internal repository. The open repositories will rely on EPEL and others to provide the needed versions as dependencies, so the SPECs might differ. We will be updating our CI/CD and hope we are able to provide open repositories for LinOTP 3 at one point.

Even if we can not accept external pull requests for now, we would be happy to talk with you about your experience while looking into packaging LinOTP and I am sure the team would love to hear your experiences with LinOTP and what we can do to help.

If it is OK with you, our PO and I would contact you in the new year, and see if can find a solution which will also help you in providing RPMs for your systems until we might have open repositories for LinOTP3. I am always interested in feedback about LinOTP and our products.

Merry Christmas and relaxing holidays,

Rainer

(Product Manager LinOTP)

[michaelsmoody]

@authprivsec I was just wanting to check in with you, and see how LinOTP v3 was progressing on this point and how I might be able to assist? I know we're well into Q3'23 at this point, and thought it would be more than prudent to reach out. We're still continuing to "hang in there" using a competitor, but honestly, using LinOTP would be "more than fantastic"!

Please let me know!

Thanks
Michael