Hi All,
I am not real conformable using Google software.
Anyone know of a substitute for google-authenticator
Many thanks, -T
I'm happy with TOTP Authenticator for Android by binaryboot.
Best, Clifford
On Sun, Apr 13, 2025 at 4:20 PM ToddAndMargo via users < users@lists.fedoraproject.org> wrote:
Hi All,
I am not real conformable using Google software.
Anyone know of a substitute for google-authenticator
Many thanks, -T
-- _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Sun, Apr 13, 2025 at 4:20 PM ToddAndMargo via users <users@lists.fedoraproject.org mailto:users@lists.fedoraproject.org> wrote:
Hi All, I am not real conformable using Google software. Anyone know of a substitute for google-authenticator Many thanks, -T
On 4/13/25 4:48 PM, Clifford Snow wrote:
I'm happy with TOTP Authenticator for Android by binaryboot.
Best, Clifford
On Android and IOs I like Red Hat's Free OP. I was referring to
$ dnf info google-authenticator Updating and loading repositories: Repositories loaded. Available packages Name : google-authenticator Epoch : 0 Version : 1.09 Release : 10.fc41 Architecture : x86_64 Download size : 55.3 KiB Installed size : 118.1 KiB Source : google-authenticator-1.09-10.fc41.src.rpm Repository : fedora Summary : One-time pass-code support using open standards URL : https://github.com/google/google-authenticator-libpam/ License : ASL 2.0 Description : The Google Authenticator package contains a plug-able authentic : ation : module (PAM) which allows login using one-time pass-codes confo : rming to : the open standards developed by the Initiative for Open Authent : ication : (OATH) (which is unrelated to OAuth). : : Pass-code generators are available (separately) for several mob : ile : platforms. : : These implementations support the HMAC-Based One-time Password : (HOTP) : algorithm specified in RFC 4226 and the Time-based One-time Pas : sword : (TOTP) algorithm currently in draft. Vendor : Fedora Project
ToddAndMargo:
Vendor : Fedora Project
By chance, does this mean it is not a Google product?
Sam Varshavchik:
Nope. Every package you get from Fedora's repos will have this. Including stuff like Apache, Postgres, etc…
That does seem a bit of a misuse of the field. Clearly Apache is not a Fedora project, for instance. RPM.org's only site says this about an example it provides:
"The Vendor tag is used to define the name of the organization producing the package. The data in this example is "White Socks Software, Inc.". Therefore, RPM will store White Socks Software, Inc. as the vendor of the package." http://ftp.rpm.org/max-rpm/s1-rpm-inside-tags.html
It really ought to identify the producer of a project, not the compiler of the source code. There's other fields for that (packager).
On Apr 14, 2025, at 00:35, Tim via users users@lists.fedoraproject.org wrote:
That does seem a bit of a misuse of the field. Clearly Apache is not a Fedora project, for instance. RPM.org's only site says this about an example it provides:
"The Vendor tag is used to define the name of the organization producing the package. The data in this example is "White Socks Software, Inc.". Therefore, RPM will store White Socks Software, Inc. as the vendor of the package." http://ftp.rpm.org/max-rpm/s1-rpm-inside-tags.html
It really ought to identify the producer of a project, not the compiler of the source code. There's other fields for that (packager).
I think you are misreading the documentation.
The Apache project is not writing the spec file for the package built in The Fedora repos. It is not building the package, testing it, and tracking updates. They should not receive bug reports on issues with how httpd is packaged in Fedora.
Perhaps if they were to do all of the above, and you were getting those packages from an Apache Project yum repository, you would expect to see the vendor tag set to the Apache Project.
On 4/14/25 10:37, Jonathan Billings wrote:
On Apr 14, 2025, at 00:35, Tim via users users@lists.fedoraproject.org wrote:
That does seem a bit of a misuse of the field. Clearly Apache is not a Fedora project, for instance. RPM.org's only site says this about an example it provides:
"The Vendor tag is used to define the name of the organization producing the package. The data in this example is "White Socks Software, Inc.". Therefore, RPM will store White Socks Software, Inc.
White Socks is clearly (to me) a play on Red Hat indicating that White Socks (Red Hat) is producing the package and is therefore the Vendor.
as the vendor of the package." http://ftp.rpm.org/max-rpm/s1-rpm-inside-tags.html
It really ought to identify the producer of a project, not the compiler of the source code. There's other fields for that (packager).
I think you are misreading the documentation.
The Apache project is not writing the spec file for the package built in The Fedora repos. It is not building the package, testing it, and tracking updates. They should not receive bug reports on issues with how httpd is packaged in Fedora.
Perhaps if they were to do all of the above, and you were getting those packages from an Apache Project yum repository, you would expect to see the vendor tag set to the Apache Project.
Tim:
That does seem a bit of a misuse of the field. Clearly Apache is not a Fedora project, for instance. RPM.org's own site says this about an example it provides:
"The Vendor tag is used to define the name of the organization producing the package. The data in this example is "White Socks Software, Inc.". Therefore, RPM will store White Socks Software, Inc. as the vendor of the package." http://ftp.rpm.org/max-rpm/s1-rpm-inside-tags.html
It really ought to identify the producer of a project, not the compiler of the source code. There's other fields for that (packager).
Jonathan Billings:
I think you are misreading the documentation.
I don't really think so. "Packager" makes sense for the one building the package. Having only a URL pointing to the Apache website is a bit lame. And "Distribution" makes sense for a Red Hat / Fedora metadata.
Looking at the description. Is "package" merely the RPM to install it, are they being that pedantic with the word, or do they mean the overall project (i.e. Apache)?
Apache isn't just a binary, it's several of them, its the libraries, the documentation, etc., and *that* package of things was produced and assembled by them.
If I compile someone else's project, doing nothing other than compile it, or assemble precompiled bits into some kind of tarball kind of thing, or crack apart someone else's tarball to make it a RPM. I'm hardly the producer of it, I just put it in a new box. And I probably can't fix bugs in their code, either.
Anyway, it's far from a coherent use of the tag. And we wouldn't be having this conversation if it was straight-forward. Nor the preceding questions from Todd and Margo about whether something was Google or Fedora. Somewhere their should be a tag making it clear the project is Apache (or whatever other thing we're looking at that Fedora hasn't created), and not just a URL.
The Apache project is not writing the spec file for the package built in The Fedora repos. It is not building the package, testing it, and tracking updates. They should not receive bug reports on issues with how httpd is packaged in Fedora.
Not all bug reports are about the packaging. If Apache crashes while loading some very normal web content, for example, that's an Apache bug.
On Apr 14, 2025, at 22:07, Tim via users users@lists.fedoraproject.org wrote:
Not all bug reports are about the packaging. If Apache crashes while loading some very normal web content, for example, that's an Apache bug.
I can guarantee that the Apache HTTPd devs want Fedora to filter out all the packaging bugs and send any real bugs on to upstream, rather than try to figure out any packaging bugs themselves.
ToddAndMargo via users writes:
On Android and IOs I like Red Hat's Free OP. I was referring to
$ dnf info google-authenticator Updating and loading repositories: Repositories loaded. Available packages Name : google-authenticator Epoch : 0
The fact that it's available in Fedora means that it is free and open source software.
You said that you "not real conformable using Google software". If that only means that you are not comfortable using anything that's authored, owned or controlled by Google, or has their name on it, then that's certainly your right to do that.
But if you were concerned about using software that's irrevocably tied with, and requires using Google services, and wouldn't work without them, then I strongly doubt that this is the case here. Even if this is a full-blown TOTP implementation, then Google services will have absolutely no involvement, whatsoever, except when it's used to authenticate a Google account. The way that TOTP works, authenticating involves communications directly between the two involved parties, with no third party involvement.
But that's not even the case here. The Fedora package includes a helpful URL to the github repo, with a loud READMEs that "this project is not about logging in to Google, Facebook, or other TOTP/HOTP second factor systems, even if they recommend using the Google Authenticator apps". It's a PAM plug- in.
I have not browsed the pitiful little amount of source code in that github repo. The compiled code is about a 100kb runtime, according to dnf. Which by modern standards is just a little bit more than random padding. A five minute browse shows it to be just an implementation of a couple of public algorithms, and that's about it. I see hmac.c, sha1.c, and base32.c. I coded my very own version of two of them more than thirty years ago, plus base64 instead of base32. Me, and probably a countless other hacker-wanna-bes. That looks like about half the source code. If Google tried to covertly slip in some code in there, that uploaded the secret keys to the mothership, the resulting sh1tstorm would …not be worth it.
And their warez gets used to set up the keys, those keys can be used with any TOTP app, not just Google Authenticator. It's an open standard. Give me a QR code from this thing, I'll scan it with Authy, and use it to generate all the codes I need.
So: if you don't like using anything with a Google name on it, then don't use it. Otherwise, I would try using keywords like "totp pam module" with your favorite search engine and then trying one's luck to see if any result is also a Fedora package.
On 4/13/25 6:36 PM, Sam Varshavchik wrote:
ToddAndMargo via users writes:
On Android and IOs I like Red Hat's Free OP. I was referring to
$ dnf info google-authenticator Updating and loading repositories: Repositories loaded. Available packages Name : google-authenticator Epoch : 0
The fact that it's available in Fedora means that it is free and open source software.
You said that you "not real conformable using Google software". If that only means that you are not comfortable using anything that's authored, owned or controlled by Google, or has their name on it, then that's certainly your right to do that.
But if you were concerned about using software that's irrevocably tied with, and requires using Google services, and wouldn't work without them, then I strongly doubt that this is the case here. Even if this is a full-blown TOTP implementation, then Google services will have absolutely no involvement, whatsoever, except when it's used to authenticate a Google account. The way that TOTP works, authenticating involves communications directly between the two involved parties, with no third party involvement.
But that's not even the case here. The Fedora package includes a helpful URL to the github repo, with a loud READMEs that "this project is not about logging in to Google, Facebook, or other TOTP/HOTP second factor systems, even if they recommend using the Google Authenticator apps". It's a PAM plug-in.
I have not browsed the pitiful little amount of source code in that github repo. The compiled code is about a 100kb runtime, according to dnf. Which by modern standards is just a little bit more than random padding. A five minute browse shows it to be just an implementation of a couple of public algorithms, and that's about it. I see hmac.c, sha1.c, and base32.c. I coded my very own version of two of them more than thirty years ago, plus base64 instead of base32. Me, and probably a countless other hacker-wanna-bes. That looks like about half the source code. If Google tried to covertly slip in some code in there, that uploaded the secret keys to the mothership, the resulting sh1tstorm would …not be worth it.
And their warez gets used to set up the keys, those keys can be used with any TOTP app, not just Google Authenticator. It's an open standard. Give me a QR code from this thing, I'll scan it with Authy, and use it to generate all the codes I need.
So: if you don't like using anything with a Google name on it, then don't use it. Otherwise, I would try using keywords like "totp pam module" with your favorite search engine and then trying one's luck to see if any result is also a Fedora package.
Hi Sam,
I feel much more comfortable after your wonderful explanation.
But if you were concerned about using software that's irrevocably tied with, and requires using Google services, and wouldn't work without them, then I strongly doubt that this is the case here.
This is why I asked:
Using Authy or Google Authenticator for 2FA with XRDP:
https://github.com/neutrinolabs/xrdp/wiki/Using-Authy-or-Google-Authenticato...
The article is not clear or I am missing if I can only limit the 2FA to xRDP. If the console gets included, I will be writing you guys to see if you know of an easy to remove tar and feathers.
-T
On 4/13/25 6:19 PM, ToddAndMargo via users wrote:
Hi All,
I am not real conformable using Google software.
Anyone know of a substitute for google-authenticator
Many thanks, -T
FreeOTP Authenticator is made by Red Hat, the same folks who make Fedora Linux. Find it on your favorite app store.
On 4/14/25 8:54 AM, Thomas Cameron wrote:
On 4/13/25 6:19 PM, ToddAndMargo via users wrote:
Hi All,
I am not real conformable using Google software.
Anyone know of a substitute for google-authenticator
Many thanks, -T
FreeOTP Authenticator is made by Red Hat, the same folks who make Fedora Linux. Find it on your favorite app store.
Ah, disregard, I thought you were talking about for your phone. I didn't realize you meant for your PC until I read your next message.
On 4/14/25 6:57 AM, Thomas Cameron wrote:
On 4/14/25 8:54 AM, Thomas Cameron wrote:
On 4/13/25 6:19 PM, ToddAndMargo via users wrote:
Hi All,
I am not real conformable using Google software.
Anyone know of a substitute for google-authenticator
Many thanks, -T
FreeOTP Authenticator is made by Red Hat, the same folks who make Fedora Linux. Find it on your favorite app store.
Ah, disregard, I thought you were talking about for your phone. I didn't realize you meant for your PC until I read your next message.
No problem. I do use Red Hat's Free OTP on my customer's cell phones. I am happy with it.
-
Clifford Snow -
Jonathan Billings -
Mike Wright -
Sam Varshavchik -
Thomas Cameron -
Tim -
ToddAndMargo