Hello dear AUR developers. The mentioned links are broken in my FF. It opens a pop-up with a 'Choose Application' message.
Best regards, Mikhail f. Shiryaev
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).
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
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 anyoneto 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%60:
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); }) );
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
Every package page I checked is affected by the issue, but let's take https://aur.archlinux.org/packages/zoom specifically.
It took me a moment to realize that this refers to options available to logged-in users. For guests the SSH link is not even sent for some reason, so I was unable to locate the affected feature. Forgive me the noise.
Since audeoudh has already found the cause, I do not find my assistance needed. I believe this is a genuine bug and a report should be opened at https://bugs.archlinux.org/index.php?project=2. Note that the project should be “AUR web interface”; selection just under the login box.
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 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
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
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
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 Sun, 3 Apr 2022, at 12:07, Ben Denhartog via aur-general wrote:
- 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.
- 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?
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:
- 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.
- 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]
aur-general@lists.archlinux.org