Hello mpan.

You have not mentioned any specific example that would allow anyone to investigate the issue.

Every package page I checked is affected by the issue, but let's take https://aur.archlinux.org/packages/zoom specifically.

From what I am guessing you observe: that’s an interactive feature that requires JavaScript code to be run on client side. Perhaps you did not permitted it to run (which I fully understand and support, but nonetheless this would explain the observed behavior).

https:// click-to-copy links work. ssh:// don't. I believe it's not JS. I don't use JS blockers

Best regards, Mikhail f. Shiryaev

On Mon, Mar 7, 2022 at 9:28 AM Henry-Joseph Audéoud via aur-general < aur-general@lists.archlinux.org> wrote:

Looking into `https://aur.archlinux.org/static/js/copy.js%60 https://aur.archlinux.org/static/js/copy.js:

  document.querySelector('.copy').addEventListener( [...]

This only applies to the first element with class "copy", so only the HTTP link. My firefox inspector confirms that SSH link does not have an event recorded on it.

Manually issuing that command in the browser console makes both links working:

  document.querySelectorAll('.copy').forEach(
      element => element.addEventListener('click', function(e) {
          e.preventDefault();
          navigator.clipboard.writeText(event.target.text);
      })
  );

-- Henry-Joseph Audéoud audeoudh

Thanks for finding and solving the issue Henry-Joseph. I created a merge request to have this fixed: https://gitlab.archlinux.org/archlinux/aurweb/-/merge_requests/476

-- Matt Harrison

I believe this is a genuine bug and a report should be opened at https://bugs.archlinux.org/index.php?project=2.

As a correction for whoever would come across that later: currently one is supposed to report aurweb issues through the GitLab application: https://gitlab.archlinux.org/archlinux/aurweb/-/issues/new?issuable_template=Bug.

On Tue, Mar 08, 2022 at 07:12:24PM +0100, Manuel Reimer via aur-general wrote:

On 07.03.22 20:59, mpan via aur-general wrote:

...

...

I believe this is a genuine bug and a report should be opened at https://bugs.archlinux.org/index.php?project=2.

As a correction for whoever would come across that later: currently one is supposed to report aurweb issues through the GitLab application: https://gitlab.archlinux.org/archlinux/aurweb/-/issues/new?issuable_template=Bug.

Which is a bit unfortunate.

At least my try to "just log in with my GitHub" ended in silly steps where I was expected to install some stupid app to my smartphone.

Sorry but no...

Manuel

GitLab requires that you create an account with Arch Linux Keycloak at accounts.archlinux.org and use that to gain access. It takes about five minutes to complete, and OTPs are pretty common these days so you likely would need your OTP app for other two-factors as well.

Highly recommend this for folks interacting with the development of the project, as its much more centralized and connected.

Thanks to the folks who brought this up and MR'd it, much appreciated.

Regards, Kevin

1) OTP _is_ the standard MFA. You have the choice between software and hardware solutions. Complain to companies still using SMS/Email/etc for second factor. Loudly, please.

2) Use a proper password manager to store your OTPURI and generate the tokens, as well as for storing your recovery codes. I'd recommend gopass if GPG, self management, and VCS sounds appealing, and 1Password if you'd rather have someone else handle the technicals.

3) WEB3 aims to provide such decentralized login based on some device you control as you are saying you want. Whether or not it replaces the current authentication model is another matter entirely.

On 04/04/2022 10:21, Hugo Osvaldo Barrera via aur-general wrote:

On Sun, 3 Apr 2022, at 12:07, Ben Denhartog via aur-general wrote:

...

2. Use a proper password manager to store your OTPURI and generate the

tokens, as well as for storing your recovery codes. I'd recommend gopass if GPG, self management, and VCS sounds appealing, and 1Password if you'd rather have someone else handle the technicals.

Storing the password and the TOTP secret in the same password manager moves both factors into the same store, kinda negating the point of using two-factor.

...

3. WEB3 aims to provide such decentralized login based on some device

you control as you are saying you want. Whether or not it replaces the current authentication model is another matter entirely.

So, something like a Yubikey using WebAuthN/FIDO? This is not uncommon online, and very handy since the second factory is a fully-offline device which requires a physical tap to log in. I see keycloak DOES support this; maybe it's a matter of enabling it?

Our keycloak supports webauthn and TOTP and you can add multiple two factors. I myself have my both yubikeys (one backup) and phone configured (aegis). Keycloak is getting support for authenticaton codes which can be stored on paper (or encrypted usb stick). [1]

https://github.com/keycloak/keycloak/discussions/8518