2017-12-11 12:05 GMT+01:00 Stefan Krah stefan@bytereef.org:

https://en.wikipedia.org/wiki/RSA_SecurID#March_2011_system_compromise https://gist.github.com/peternixey/1978249

I'm pretty sure my long GitHub-only password is more secure than several key-gen algorithms on smart cards ...

I wouldn't comment the attack on RSA SecurID, but I disagree that a single password is stronger than password + OTP.

The principle of the 2-factor auth is that the attacker has to break two auths rather than only one. So even if you break RSA SecurID, the hacker still has to break your ultra secure GitHub-only password ;-)

Victor

2017-12-11 13:29 GMT+01:00 Stefan Krah stefan@bytereef.org:

Ssh isn't available everywhere, I don't want to install an app or give out my phone number to half of Silicon Valley [1].

SMS and FreeOTP are just a few options that you have to generate/get OTP.

I suggest to use Yubikey. It doesn't need to install an app or to give your phone number, but it costs 50$. The advantage is that you can use it to store your SSH and GPG keys.

See also https://www.u2fzero.com/ "A secure and open source 2 factor authentication token. Designed to be affordable and reliable."

Victor

2017-12-11 13:51 GMT+01:00 Antoine Pitrou antoine@python.org:

Before recommending anything you/we should first give guidelines and best practices for backup etc.

If you lose your 2FA device and don't have some kind of fallback your accounts may be screwed. As usual, security can conflict with usability and the long-term availability of data.

Hum, in my first email I wrote:

"""

• Enable 2-factor auth on GitHub and Bitbucket using Yubikey
• Print two-step recovery codes on paper and keep it safe somewhere """

Using multiple tokens reduces the risk of losing access to your account.

Victor

Antoine Pitrou antoine@python.org:

I don't know what security experts think, but the idea of having to print and keep around recovery codes (for each and every website I enable 2FA on!) sounds completely braindead to me. Do you expect to be able to find back a random piece of paper in 5 years? I certainly don't.

The basic idea of 2FA is to cumulate something you know and something you have.

Recovery codes are on the "something you have" side, they are not a secret, they are a possession, so it's completly OK to keep your recovery codes in your wallet.

It's even a good practice to keep them in your wallet: You know where they are and they're accessible. If you break the "thing you have" you can still identify yourself even if you're out of your house.

If you loose your wallet, (got it stolen, dropped in the ocean, whatever), it's no big deal: just regenerate the codes, nobody know your password, your security is not broken.

In other words, the thief stealing a wallet is not the guy stealing password, so everything's good, and you have to regereate your recovery codes faster than they can meet (should be easy).

To reply to you other answer, it's not really OK to store your password and your 2FA generating program on the same hardware, it breaks the "something you know and something you have" separation, it's reduced to something you have, it does no longer need two clearly separated steps to be broken.

​--  Julien Palard https://mdk.fr

On Mon, 11 Dec 2017 at 10:56 Antoine Pitrou antoine@python.org wrote:

Hi Julien,

(and welcome on this list)

Le 11/12/2017 à 19:53, Julien Palard a écrit :

...

Recovery codes are on the "something you have" side, they are not a

secret,

...

they are a possession, so it's completly OK to keep your recovery codes in your wallet.

A random piece of paper in my wallet may not have an extremely long lifetime (paper is fragile). And *one* piece of paper might be ok, but what if I need one for every 2FA-enabled Web site?

I print them out, trim the paper to just the codes to keep it small, and keep the codes with my passport since I'm not about to lose track of that important document. And there are only so many web sites that support 2FA so the number of pieces of paper isn't massive.

On 11 December 2017 at 20:15, Julien Palard via python-committers python-committers@python.org wrote:

Antoine Pitrou antoine@python.org:

...

A random piece of paper in my wallet may not have an extremely long lifetime (paper is fragile). And one piece of paper might be ok, but what if I need one for every 2FA-enabled Web site?

It's a legitimate question, so I'm taking mine out right now to check.

Here's a question (disclaimer: I'm *not* saying I disagree with 2FA, or strong security, or anything like that, I'm genuinely curious about the usability trade-offs based on my experience). I have a piece of paper with some Google account recovery keys on it. I think it's in my wallet (it was last time I looked but that's literally years ago). So, what if I've lost it? As I understand it, if I lose my access for any reason (phone broke irrecoverably is the example that happened to me a few months ago), I need those keys to get access, but I don't know any longer if I have them. And if I don't, I'm screwed. So surely there's an additional requirement that I keep track of my recovery keys, so I *know* if they get lost?

Password/identity management is a *huge* burden in these days of every website under the sun needing a unique login. Even just classifying your accounts as "critical", "important", "useful", "minor" and "throwaway" takes significant effort. Password managers are basically the only scalable solution I know of, and they have their own problems (online ones can be compromised themselves, personal ones don't always work on all devices, and sharing the password database is a non-trivial issue). I already need to know one thing (the password DB passphrase) and have another (the DB itself). 2FA essentially adds a third factor, not a second (yes, I know that's not precisely correct).

Anyway, I've said enough - you get my point. People should be allowed to make their own judgments on risk vs usability. IMO, we should focus on:

1. If we grant core dev status, we should factor in whether we think the prospective candidate understands the responsibility in terms of security (I'd be surprised if anyone thought we didn't already do that).
2. Because we're on a shared infrastructure (github) we can't mandate how developer accounts are configured without considering how that affects a user's *other* activities [1].

Paul

[1] I can expand on this, but it's somewhat off-topic and also not something I'd want to discuss on a public list, so ask me privately if you're interested in my specific case.

It's possible to generate a key on a regular computer and transfer it to a YubiKey if you prefer. (It's not like software key generation has been flawless either; [OpenSSL/Debian fiasco]. Oh well, such is life).

Even if you're not going to put your SSH keys on a YubiKey, I _strongly_ encourage folks to get a Security Key (aka U2F device), of which YubiKeys are one brand, and use it for 2FA with Google/Github/Facebook/etc. In addition to (IMO) being more usable than Google Authenticator, Security Keys are resistant to phishing, which is a huge win.

Alex

On Mon, Dec 11, 2017 at 7:57 AM, Stefan Krah stefan@bytereef.org wrote:

On Mon, Dec 11, 2017 at 01:47:50PM +0100, Victor Stinner wrote:

...

2017-12-11 13:29 GMT+01:00 Stefan Krah stefan@bytereef.org:

...

Ssh isn't available everywhere, I don't want to install an app or give out my phone number to half of Silicon Valley [1].

SMS and FreeOTP are just a few options that you have to generate/get OTP.

I suggest to use Yubikey. It doesn't need to install an app or to give your phone number, but it costs 50$. The advantage is that you can use it to store your SSH and GPG keys.

I'm not a fan of hardware key generation. :-)

https://en.wikipedia.org/wiki/YubiKey

"In October 2017, security researchers found a vulnerability (known as ROCA) in the implementation of RSA keypair generation in a cryptographic library used by a large number of Infineon security chips. The vulnerability allows an attacker to reconstruct the private key by using the public key.[18][19] All YubiKey 4, YubiKey 4C, and YubiKey 4 nano within the revisions 4.2.6 to 4.3.4 are affected by this vulnerability.[20] Yubico publicized a tool to check if a Yubikey is affected and replaces affected tokens for free.[21]"

---

python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/

-- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero GPG Key fingerprint: D1B3 ADC0 E023 8CA6

Le 11/12/2017 à 14:00, Alex Gaynor a écrit :

It's possible to generate a key on a regular computer and transfer it to a YubiKey if you prefer. (It's not like software key generation has been flawless either; [OpenSSL/Debian fiasco]. Oh well, such is life).

If I have my 2FA key on a regular computer (the same that runs my password manager), is it still 2FA?

Regards

Antoine.

2017-12-11 13:57 GMT+01:00 Stefan Krah stefan@bytereef.org:

I'm not a fan of hardware key generation. :-)

https://en.wikipedia.org/wiki/YubiKey

"In October 2017, security researchers found a vulnerability (known as ROCA) in the implementation of RSA keypair generation in a cryptographic library used by a large number of Infineon security chips. The vulnerability allows an attacker to reconstruct the private key by using the public key.[18][19] All YubiKey 4, YubiKey 4C, and YubiKey 4 nano within the revisions 4.2.6 to 4.3.4 are affected by this vulnerability.[20] Yubico publicized a tool to check if a Yubikey is affected and replaces affected tokens for free.[21]"

FYI it seems like only RSA private key generated by old Yubikey keys are vulnerable to the ROCA attack. OTP authentication is not affected. See https://www.yubico.com/keycheck/ for more information.

"ROCA: Return Of the Coppersmith Attack": https://lwn.net/Articles/738896/

As I wrote, I chose to use ed25519 for my new SSH key. Maybe it was a good idea :-)

Victor

On Mon, Dec 11, 2017 at 4:44 PM, Paul Moore p.f.moore@gmail.com wrote:

On 11 December 2017 at 10:16, Kushal Das kushaldas@gmail.com wrote:

...

On a related note, we should ask all committers to enable 2FA and then make the organization to 2FA only on github. That is a standard policy of many organizations on github.

Before making such a requirement, we should ensure that doing so doesn't harm usability. For example, I have no idea how 2FA would work in conjunction with the command line git client on Windows, particularly in terms of *not* prompting on every single activity, but caching authentication appropriately. Also we should ensure that there are viable 2FA options for people in places where mobile phone signals are unreliable or unavailable (I come into that category :-()

Basically, before making such a change, let's ensure it doesn't do more harm than good.

Understood, the git command line tools work based on your ssh authentication. 2FA will only take place in case of user login using username/password.

Even before we get into long discussions about 2FA and other things, the first step should be using a nice long passphrase (not password, but passphrase) which one can remember. And if possible, use a local password manager to store it.

To create the passphrases, one can use the diceware tool ($ pip install diceware ). It is packaged for Debian, and I am working on the Fedora packaging (on review state).

Kushal

CPython Core Developer Director, Python Software Foundation https://kushaldas.in

On Dec 11, 2017, at 7:03 AM, Paul Moore p.f.moore@gmail.com wrote:

Um, I use https not ssh, as for at least some of the time I'm behind a firewall that only allows https, not ssh traffic. (I know, I'm sorry - I can probably be the worst possible corner case for *any* suggestion that gets made :-))

https://help.github.com/articles/providing-your-2fa-authentication-code/#thr... https://help.github.com/articles/providing-your-2fa-authentication-code/#thr...

On Dec 11, 2017, at 8:04 AM, Paul Moore p.f.moore@gmail.com wrote:

...

On 11 December 2017 at 12:29, Donald Stufft donald@stufft.io wrote:

On Dec 11, 2017, at 7:03 AM, Paul Moore p.f.moore@gmail.com wrote:

Um, I use https not ssh, as for at least some of the time I'm behind a firewall that only allows https, not ssh traffic. (I know, I'm sorry - I can probably be the worst possible corner case for *any* suggestion that gets made :-))

https://help.github.com/articles/providing-your-2fa-authentication-code/#thr...

I use username and password and git credential manager. Uses the OS password store. I don't know of any way that 2FA integrates with that. If someone can tell me how it does (and it's as unobtrusive as, say gMail which only prompts me if I log on via a previously unused machine) then that's fine. Otherwise not so much.

Paul

Did you read the linked section? You generate a limited scope access token and use that in place of your password for command line usage via https.

On Dec 11, 2017, at 9:35 AM, Paul Moore p.f.moore@gmail.com wrote:

Maybe I didn't understand it. Doesn't that leave me in precisely the same situation as a username/password, in that I have a single set of credentials I can use? Or is the fact that it's tied to the specific machine the point here? If so, then thanks, I can certainly use that should someone decide that mandating 2FA is a good idea (I still maintain that recommended but not mandatory is better, as my GH account is not used solely for CPython development, so making such a change has wider effects than just for this project).

It is true that this weakens the guarantees of 2fa (as does allowing authentication using a SSH key!). In general this trade off is worth it because the authority granted by those credentials is limited (in this case, I believe you can only push/pull with them, you can’t do anything else on the account) and they’re typically only used in contexts where leaking the credential is far far harder. As a bonus, they’re not going to be shared between multiple services.

So yea, it’s not as good as 2FA only everywhere, but the specific circumstances around these specific credentials makes it a reasonable usability trade off to allow them.

On Mon, 11 Dec 2017 18:14:41 +0000, Paul Moore p.f.moore@gmail.com wrote:

On 11 December 2017 at 18:03, Donald Stufft donald@stufft.io wrote:

...

So yea, it’s not as good as 2FA only everywhere, but the specific circumstances around these specific credentials makes it a reasonable usability trade off to allow them.

Cool. Security is always a usability vs security trade-off, and the main thing here is not to push the balance too far - we need to consider the potential issue of putting people off from contributing as well as the risk of security compromises. (Open source is a hobby activity for me - when it starts to feel too much like the day job, I start getting twitchy :-))

Indeed. If 2fa is required for contribution to CPython, I'll stop contributing. Granted, I haven't done many merges lately, but a few is a bigger number than zero :)

--David

Whatever happens I don't want to lose core devs over this. (That said I have 2fa on myself -- Dropbox pretty requires this -- and it's painless for me. But I can totally understand that it's not the same experience for everyone.)

On Mon, Dec 11, 2017 at 11:56 AM, Donald Stufft donald@stufft.io wrote:

On Dec 11, 2017, at 2:52 PM, R. David Murray rdmurray@bitdance.com wrote:

If 2fa is required for contribution to CPython, I'll stop contributing.

I’m curious why? I have it on and 99% of the time you don’t even notice because you’re already logged into GitHub and pushes/pulls don’t require it.

---

python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/

-- --Guido van Rossum (python.org/~guido)

On Mon, Dec 11, 2017 at 12:26 PM R. David Murray rdmurray@bitdance.com wrote:

On Mon, 11 Dec 2017 14:56:21 -0500, Donald Stufft donald@stufft.io wrote:

...

...

On Dec 11, 2017, at 2:52 PM, R. David Murray rdmurray@bitdance.com

wrote:

...

...

If 2fa is required for contribution to CPython, I'll stop contributing.

I’m curious why? I have it on and 99% of the time you don’t even notice because you’re already logged into GitHub and pushes/pulls don’t require it.

I had to use 2FA when working for a corporate client, and it was very annoying. The fact that pushes and pulls don't require it helps, but also makes it considerably less important.

Please Don't let *that* experience color your 2FA opinion. Not everyone $random_corp does a good job of it.

It does not have to be annoying. Github's and Google's are examples of 2FA done right that is not annoying (using U2F).

But I suppose that fundamentally I do not want my security tied to a

possession.

*2FA doesn't need to be tied to a single possession.* You are not limited to a single second factor thing. You can have plentiful different two factor methods set up at once. This is normal. ex: A printed recovery code at the very least as a second second factor. Have multiple U2F USB tokens tied to your account? Yes. I do that all the time on all accounts.

Heck, a photo/scan/screenshot of backup one time codes stored as a public image somewhere with no password authentication for the world to see on an http server still counts. As laughable as that is, it is *still* much better than not having 2FA enabled at all. Because it isn't going to be an automated attack at that point.

*Any* 2FA is much better than no 2FA.

When (not if) your login/password is compromised, it is rarely your own fault. But your account and all of your data can be gone in a heartbeat as soon as anyone or anything malicious chooses to make it so on whatever selection of accounts they choose to victimize. Often irrecoverably. With 2FA enabled, that is much less likely to happen to you.

Try it. You will remain happy.

I recommend the https://www.yubico.com/product/yubikey-neo/ as a primary U2F token because it even works with Chrome on Android phones via NFC when you need to re-auth there. That is a more expensive one, there are $10-20 alternative vanilla U2F USB tokens. I have some of those as backups. The "nano" style keys that you just leave in the USB port of all computers you use regularly are also a nice solution. no need to find and pull out the key, it is just present in your computers (it requires a physical touch to prevent remote access).

Which 2FA methods to choose is an individual choice, but in my experience since the U2F keys came out, I'm less inclined to use any service that doesn't support them as all other solutions are a worse user experience for me.

IMNSHO, the PSF *should* be able to buy one or two U2F tokens for any committer who needs them. This should not depend on a policy of 2FA use, it would just be a way to promote good security practices among committers to make us all better off.

-Greg

On Tue, Dec 12, 2017 at 02:04:42PM +0100, Christian Heimes wrote:

If you don't the trust closed-source Yubico hardware, there is plenty of other hardware out. https://www.nitrokey.com/ is good German engineering with fully open-sourced hardware and software.

Adam has compiled a nice list of U2F and 2FA tokens, too. https://www.imperialviolet.org/2017/10/08/securitykeytest.html

The PSF then also must provide developer laptops along with the usb thingy.

I would assume that in extremely security conscious enviroments plugging *anything* into an USB port is forbidden (if there are USB ports at all).

Stefan Krah

And I'm not even sure it's possible to push directly without opening a PR...

All the arguments have been heard now and it would be nice if this thread could die.

Le 12/12/2017 à 14:07, M.-A. Lemburg a écrit :

I'm with David on this one. 2FA is good for admin accounts, but doesn't add much protection for regular committers. Think of what you're trying to protect against: git checkins are all audited and can easily be undone.

On Tue, Dec 12, 2017, 05:07 M.-A. Lemburg, mal@egenix.com wrote:

I'm with David on this one. 2FA is good for admin accounts, but doesn't add much protection for regular committers. Think of what you're trying to protect against: git checkins are all audited and can easily be undone.

But David has an admin account for the repo. 😉 Anyway, it sounds like we're not going to force this in anyone, but perhaps it might be worth considering for admin accounts since they control whether force pushes are possible.

-brett

-- Marc-Andre Lemburg eGenix.com

Professional Python Services directly from the Experts (#1, Dec 12 2017)

...

...

...

Python Projects, Coaching and Consulting ... http://www.egenix.com/ Python Database Interfaces ... http://products.egenix.com/ Plone/Zope Database Interfaces ... http://zope.egenix.com/

---

::: We implement business ideas - efficiently in both time and costs :::

eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/

---

python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/

They require a preference to be enabled, but yeah, Security Keys in Firefox Quantum 🎉 https://mobile.twitter.com/jamespugjones/status/912314952232267777

Alex

On Tue, Dec 12, 2017 at 11:21 AM, Antoine Pitrou antoine@python.org wrote:

If some people are inclined to push for 2FA, I think it would be more productive to write some kind of document giving advice and suggestions and addressing all potential issues (such as backups, cross-platform compatibility, software integration with various tools, etc.). For example I have 2FA enabled on Github but I just learned that U2F keys are supposed to work with Firefox 57.0.

Regards

Antoine.

Le 12/12/2017 à 17:12, Brett Cannon a écrit :

...

On Tue, Dec 12, 2017, 05:07 M.-A. Lemburg, mailto:mal@egenix.com> wrote:

I'm with David on this one. 2FA is good for admin accounts, but
doesn't add much protection for regular committers. Think of what
you're trying to protect against: git checkins are all audited and
can easily be undone.

But David has an admin account for the repo. 😉 Anyway, it sounds like we're not going to force this in anyone, but perhaps it might be worth considering for admin accounts since they control whether force pushes are possible.

-brett

--
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Dec 12

...

>>> Python Projects, Coaching and Consulting ...

http://www.egenix.com/

...

>>> Python Database Interfaces ...

http://products.egenix.com/

...

>>> Plone/Zope Database Interfaces ...

http://zope.egenix.com/

...

____________________________________________________________

---

...

::: We implement business ideas - efficiently in both time and costs

:::

...

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/
                      http://www.malemburg.com/

_______________________________________________
python-committers mailing list
python-committers@python.org <mailto:python-committers@python.org>
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

---

python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/

---

python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/

-- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero GPG Key fingerprint: D1B3 ADC0 E023 8CA6

The reason for the username-then-a-new-page-for-password flow in many cases is that the sites have multiple flows depending on your username! The GMail login page for example can send you to either the password page since you're a consumer account, the password page because you're a GSuite account using Google login, an off-site page since you're a GSuite using SAML. (This is ignoring the need to choose 2FA flows -- TOTP vs SMS vs Security Key!)

Alex

On Mon, Dec 11, 2017 at 3:11 PM, R. David Murray rdmurray@bitdance.com wrote:

On Mon, 11 Dec 2017 14:52:54 -0500, "R. David Murray" < rdmurray@bitdance.com> wrote:

...

Indeed. If 2fa is required for contribution to CPython, I'll stop contributing. Granted, I haven't done many merges lately, but a few is a bigger number than zero :)

And in case you think this means I don't consider security important: I have been using strong, unique-per-site passwords (and in many cases unique usernames/emails) for many years, and I run my own email server.

--David

Aside: something I have never understood is the relatively recent craze for enter-username-first-then-go-to-password-screen. Most of the implementations I have encountered tell you if the username is unknown. That reduces the cracker's search space by a considerable amount. Using your email address as the account id has the same problem, magnified. I had already started using unique usernames/emails before that trend happened, to battle spam, but it certainly reinforced my motivation for doing so. I unfortunately haven't gotten around to backfilling a lot of the sites I did sign up to using my primary email address :(

---

python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/

-- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero GPG Key fingerprint: D1B3 ADC0 E023 8CA6

2017-12-11 11:16 GMT+01:00 Kushal Das kushaldas@gmail.com:

On a related note, we should ask all committers to enable 2FA and then make the organization to 2FA only on github. That is a standard policy of many organizations on github.

The first step for that would be to have an idea of how many core developers are using 2-factor auth. Administrators of the Python organization on GitHub are allowed to see that.

Victor

2017-12-11 17:19 GMT+01:00 Chris Jerdonek chris.jerdonek@gmail.com:

Why do you say this? Can't this only be true for accounts that allow password recovery / reset via email?

--Chris

While I didn't check, but I'm quite sure that the email quickly enters into the play when you want to recover your GitHub account when you lost everything (password, 2FA key, recovery code).

At least, the email was the key to break the security in one "I have been hacked" article. Hum, I think that it was this article: https://www.wired.com/2012/08/apple-amazon-mat-honan-hacking/

The story is related to "password reset": Google (Gmail), Apple, Twitter, Amazon, etc.

Victor

Hey Antoine,

Assuming you're on Firefox57, it requires a pref -- once the WebAuthn spec is finalized we'll drop the pref -- https://mobile.twitter.com/jamespugjones/status/912314952232267777

Alex

On Sat, Jan 6, 2018 at 1:59 PM, Antoine Pitrou antoine@python.org wrote:

Hi,

So, for the record (even though this discussion has petered out), I've just bought a U2F key and it doesn't work on Ubuntu Firefox (though it works on Chromium). So it's pretty much unusable for me.

Regards

Antoine.

---

python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/

-- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero GPG Key fingerprint: D1B3 ADC0 E023 8CA6

Le 06/01/2018 à 20:04, Antoine Pitrou a écrit :

I have AppArmor enabled on Firefox, I may try to disable it.

... Nothing changed unfortunately.

Regards

Antoine.

It turns out that is a bug with Ubuntu's package for Firefox. It works fine with the upstream build... :-(

https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1741768

Regards

Antoine.

Le 06/01/2018 à 20:42, Barry Warsaw a écrit :

On Jan 6, 2018, at 14:00, Alex Gaynor alex.gaynor@gmail.com wrote:

...

Hey Antoine,

Assuming you're on Firefox57, it requires a pref -- once the WebAuthn spec is finalized we'll drop the pref -- https://mobile.twitter.com/jamespugjones/status/912314952232267777

Oh wow, this is exciting! I’ve been annoyed by the lack of support for my Yubikey in FF57, but I just enabled these and quick check by logging into GH seems to show that it works, at least for some sites. Thanks for the link.

-Barry

On Sun, Jan 7, 2018 at 12:29 AM, Antoine Pitrou antoine@python.org wrote:

Hi,

So, for the record (even though this discussion has petered out), I've just bought a U2F key and it doesn't work on Ubuntu Firefox (though it works on Chromium). So it's pretty much unusable for me.

You need the latest version of the Firefox, I guess that is 57.

Kushal

Staff, Freedom of the Press Foundation CPython Core Developer Director, Python Software Foundation https://kushaldas.in