there could be info in saved searches

Is this really a case of information being useful to an attacker?

To address two things immediately:

I added the error from Google and Bitbucket to the Mockup.

I would say that :

• twitter implement the Oauth 1.0 protocol https://dev.twitter.com/oauth
• phabricator can use the Oauth 2 only

@epriestley Is there an ETA on this? It's been 7 days since I cleared out failing Git parser tasks and there's another 20 I need to clear out now. This issue has a significant impact on our background processing because commits without UTF8 data in them effectively block the queue.

Custom logos are experimental and not for general use (we note that it's incomplete on the field when you set it). See T4214.

Thankfully clicking the notifications opens a dropdown with "undefined" in it. Maybe tagging with Security was overzealous but every MFA screen I've ever encountered showed no data from the underlying system. At worst it just looks sloppy since half of the features don't return useful data, the custom logo disappears (it's not accessible, therefore doesn't return), etc. Also, like @Lavoaster points out, there could be info in saved searches. This isn't huge, just something that should be fixed eventually.

Is this really a case of information being useful to an attacker? Task titles, shown in notifications, can reveal the private tasks that lye within.

Can you construct a plausible scenario where this information is substantially useful to an attacker?

I confirm this to be solved. Thank you @chad ! :)

No ideas, but regenerating the files again fixes it.

I can't reproduce anything here. Have you cleared cache/etc on browser?

If a product intended to cleanse the human body does not meet all the criteria for soap, as listed above, it is either a cosmetic or a drug. For example:

thank you, I fix it!

In T8872#126717, @epriestley wrote:

This report doesn't have enough information for us to reproduce the issue. See the documentation here:

https://secure.phabricator.com/book/phabcontrib/article/bug_reports/#unreproducible-problems

The source code for my extension is available here: https://github.com/thoughtpolice/libphutil-yubikey

I'd also like to voice my support for this. We have Yubikeys here for MFA and I do use Passphrase quite a lot as well. Right now I've set up the Yubikey to be a Mobile TOTP-provider instead so I can just get a standard Mobile TOTP code to input via a keyboard command. This is rather specific to OSX/Linux and Android, though as it requires an Android phone with an NFC reader to read the shared secret up to give you the TOTP codes if you do not have a computer handy and the keyboard shortcut has a high technical skill level requirement because it means you must be able to grab terminal output and put it on your clip board. The native app does not make it much better than a Mobile TOTP, hence the implementation I've deviced for myself.

I'll also note that my perspective is probably somewhat skewed, because I sometimes often jump into high security mode because I use things like Passphrase a lot to manage credentials - so cutting down the time from "take out phone and fiddle with application" to "touch my USB port" is a nice win for me. (For mobile apps, I actually prefer Duo Security since it takes it from "fiddling" to "push notification I confirm from lock screen".)

You do need an API key to talk with their servers - but you can get an API key for free with your Yubikey that allows use of their service as you need. So, the administrator just needs to have a registered Yubikey on their service and request an API token, then configure Phabricator to use it (the extension also adds configuration options into /config to do this properly.) Users don't need to configure anything; they just need a registered key (which it comes with out of the box).

It looks like you have to configure an application key -- is that right? Did you just hard-code yours? That might be a possible technical hurdle, since other OTP auth doesn't require configuration so we don't have anywhere convenient to store it. Or I might just be misunderstanding how the verification works.

bin/storage status shows both patches as applied.

FreeBSD has very strong interest in this sort of API call. It would permit us to integrate better with certain systems that are not part of phabricator. It also makes writing a migration script entirely against conduit feasable.

Also note that 20140218.passwords.2.prefix.sql is not idempotent, so re-running it if it already ran could break things.

The expectation is that 20140722.renameauth.php renamed provider classes, and 20140218.passwords.2.prefix.sql reformatted the passwords.

Yes I found T4463 while I was searching for the issue. Here's log of issues I faced during upgrade;

T4463 is the only other related task I can find mentioning your error, is that the task you are referring to?

We need the specific errors you ran into, the commands you ran next, everything. We have no means of reproducing the issue as you're currently describing it. Without knowing the specifics, we can't provide you with help or see if there is even something in the upstream to fix.

I ran upgrade on very old install of phabricator, hadn't been updated for as long as 9 months. I ran into few issues during upgrade, but eventually managed to complete storage upgrade.

What is your upgrade process, specifically? Did you restart apache/php-fpm?

thank you ~

I have updated auth_providerconfig in phabricator_auth.auth_providerconfig table to something else and added new Google provider from web interface. Not sure if this is the correct way but it worked.

Presuming this is resolved since we found a reasonable explanation for the case above. Let me know if anyone is still seeing issues.

You can likely work around it in the meantime by setting isEmailVerified to 1 in that table. (I expect D13239 will land in the next few hours.)

Sorry, bad at reading. Yeah, that's the issue. D13239 will fix things.

Yes, it is.

Oh, is auth.email-domains set?

Some more useful data:

• Last week (before we upgraded Phabricator), I needed to create a user for something. I created a user from /people/, used ./bin/auth recover to log in as that user, and then the web UI immediately presented me with a "you must verify your email to use the website" screen.
• Today, I just went through the same steps -- and instead of seeing "you must verify your email," I see the "login failure" page.
• I checked our database to find a full list of all users with isEmailVerified=0. It's a bunch of really old test accounts, and then new accounts created this week. Every other account on our install is email verified.
• I double-checked our settings. auth.reuqire-email-verification displays as "false" in the list of all config settings, but when I click into it, it says "Value (Use Default)" and then further clarifies "By default, verification is optional unless auth.email-domains is nonempty." Our auth.email-domains setting is non-empty, so I think we do require email verification.

D13239 will fix this in some cases.

auth.require-approval is false
auth.require-email-verification is false

Maybe. Do you have approval queues on, or email verification on?

Do any of the details I provided in T8504 (like the mention of the gray circle) help you understand what's going on here?

I can't reproduce this locally.

See also T8504, which uses Google for auth source.

fwiw, as expected, this is an issue on prod

I believe T7879 is the root issue here, which will be resolved shortly in connection with T7707.

A related request is to enable it, but require passphrases.

Yeah that's what we were doing actually, but given our environment and arcanist's checks regarding the file permissions (that it's 600, etc.) it was messy due to shell restrictions and other stuff where our scripts are running. This will be great for build agents posting back Harbormaster statuses.

As a goofy workaround you can probably write some dummy file

Great, thanks. It appears that it does still need the certificate in a .arcrc file somewhere, as we removed that file as part of the above test and received the certificate prompt.

I'd expect it to work on relatively up-to-date Phabricator. You may still need to have some valid-ish ~/.arcrc file, which we might be reading and then ignoring. I'll check that and fix it if it's the case -- we shouldn't require a ~/.arcrc if you specify --conduit-token.

Is the above commit able to be used or are there a few steps to go? Gave it a quick try and it still wanted my bot user to install a certificate despite providing an API token with the above parameter.