Hello dear AUR developers. The mentioned links are broken in my FF. It opens a pop-up with a 'Choose Application' message. You have not mentioned any specific example that would allow anyone to investigate the issue.

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).

Hi all, On 07/03/2022 11:02, Mikhail f. Shiryaev via aur-general wrote:

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. […] https:// click-to-copy links work. ssh:// don't. Looking into `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

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` 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

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....

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

On 02.04.22 03:28, Kevin Morris via aur-general wrote:

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.

Is it enough to have 2FA enabled on my GitHub account? To be honest: Most of this 2FA stuff is even more a pain in the ass as passwords are. I still hope that, one day, there will be "the standard" for "single sign on". For example I would prefer to have a small device that I can put on my key-chain (first factor) and an easy to remember pin that I (best case) enter directly on this dedicated security device (second factor). It would be such a relief if this would be all I need to access **everything** online. And no: A smartphone is not such a device. a) I don't trust them b) what happens if my phone dies? Biggest problem with all 2FA protected stuff: You get this sheet with shitty "keep these for recovery" codes including a note "if you loose these, noone can unlock your account for you". Where to put these? Just save to my PC? Wouldn't this be exactly what everyone suggests *not* to do (save "passwords" unencrypted in a plain text file). Better print it out? But where to store it? Sorry but this is trying to solve a "pain in the ass" (passwords) with even more pain in the ass (even more complicated steps to sign in). Manuel

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? -- Hugo Osvaldo Barrera