See T13612 for followup.

Just want to add a note that with git lfs managed files, arc patch won't work unless one fetch the ref tag and then the lfs blobs from the staging server first. See https://discourse.phabricator-community.org/t/arc-patch-fails-with-git-lfs-files/2447/3

See also PHI1628, which reports that a 4MB blob of test details is slow to render.

Agreed that supporting YubiKey OTP is pointless - it's impractical and basically a dead legacy feature at this point. WebAuthn has emerged as the de-facto standard for hardware tokens.

See D20419 and T13277.

The original request focused on OTP, not U2F, but I think the amount of configuration required by OTP and the lack (?) of a pathway on mobile make it a better candidate for third-party integration than first-party integration. If we were supporting OTP in the upstream I'd want to run a first-party verification service so we aren't dependent on Yubikey's service, but the whole thing seems very messy and very bound to the Yubikey stack. It also looks (?) like Yubikey OTP and Yubikey U2F aren't linked to the same key (I think?) so you can't use U2F on one device and then fall back to OTP on mobile, even if you want to type in 44 characters? You have to enroll OTP and U2F separately.

This browser doesn’t support the FIDO U2F standard yet.

I would like to add another use case where this would be beneficial.

I wrote a patch for this, for both new log prototype and old log viewer here some screenshots for the view. If it is look OK, I will submit it.

See followup in T13105.

I'm going to call this effectively resolved:

I'd love to see support for U2F keys, as well.

i'd like to remark that this ticket is supposed to be about perhaps u2f or other direct hardware security, not saml, and thus i've had to unsubscribe from the recent back and forth :)

In practice, every paying customer who has ever asked us about SAML has wanted to use OneLogin as a SAML provider. OneLogin's breach does not imply SAML is bad; it implies OneLogin is bad. For paying customers who are interested in understanding our stance on SAML support, criticism of OneLogin is materially relevant because they all want to use OneLogin.

@epriestley I'm not saying you didn't do a serious technical evaluation of SAML. I can't see where I might have even vaguely implied that? For all I know you could be an expert on SAML. I've done multiple SAML implementations and frankly I can't blame you for not wanting to do / maintain one.

Why do you believe I haven't performed a serious technical evaluation of SAML?

@epriestley I can see how that last sentence could be perceived as such. I probably should have put a smiley there since it wasn't intended as harsh as you (seem to) perceive it.

Why did you think that a sarcastic, condescending comment was the best way to convince me to reserve judgement?

@epriestley I'm hoping you'll see you shouldn't pass judgement that fast.

@siepkes, what are you hoping to get out of making that comment? How do you believe it benefits you?

@epriestley Onelogin does way more then just SAML. They also do OAuth for example. The screenshot also says to regenerate your Oauth keys. I assume your going to remove all OAuth stuff from Phabricator now?

More on SAML:

In T5698#223992, @chad wrote:

Oh hai Cura uses Phabricator? I have a Lulzbot at home!

Oh hai Cura uses Phabricator? I have a Lulzbot at home!

@Krinkle, @pablocarrillo I second your requests. Great suggestion. I have a large README.md that I would love to split into multiple documentation files, without losing all the formatting.

Recent security issues in GitHub, GitLab, etc., with markdown:

Just dropping this here since it's the first hit for "SAML" and makes it easier for me to contextualize things when I quote $50K for it, which I'm starting to think is too low:

I'm going to probably re-design this page a little.

I think we could even default it to "fancy mode" without a setting, at least to start with. I'm not sure anyone will want to access the plain text mode with enough frequency that we need it to be sticky.

@epriestley this doesn't seem hard to build for a fledgling designer/intern engineer.

In our setup (as an open source project) we often get differentials created with base commits which do not exist in upstream. As a result using arc patch often fails, even worse, in a non-recoverable way as --reject is passed to git apply. In a patch fails to cleanly apply it is hard to continue the work-flow and manually correct the merge conflicts.

No easy way to apply a policy to a group of repos.

In T5000#176440, @epriestley wrote:

Another possibility is that we just build this behavior (intercept and react to ref changes) as an extension point prior to the Herald, and then you can implement whatever magic you want. I suspect very few installs want the default behavior of git push origin mybranch for arbitrarily named branches to be anything except "create a branch".

We are still occasionally running into this problem. A queuing system which ensures some kind of fairness would be really useful for us and others in the situation where demand is much greater than the builder resources. (A similar sentiment to T11153#180635)

Thanks for these suggestions. We only had one CI machine so these kinds of concerns about parallelism are not important for us. I enabled the options that you suggested.

See some discussion starting here:

I think this should be fixed in HEAD now, but you may want to wait a few days to update (e.g., until stable promotes on Friday) since a few bugs related to T11044 have been cropping up since it landed a couple days ago.

Thanks for the lightning response!

Broadly, I think this is better expressed as "Commits in rXYZ on master, including build status" than "Builds of commits in rXYZ on master". Diffusion proper already shows build status in commit lists, although the commit query in Audit currently does not. This probably won't get an update until T10978 happens.

For people who suffer from this: Note that D16483 might have actually made things a little worse, by searching the DB for old messages (Not loading them though); I tested with 1M messages on an SSD drive, and I didn't see any changes, but YMMV.

T11335 talks about a hosting system (gitblit) that adds meta-data to refs/meta/ refs, which show up in phabricator as real commits.

Thanks for listening to my hair-brained schemes. Yeah, the motivation is totally clear to me FWIW, and thinking about it more, I strongly suggest this is related to T9161.

I should add that their plans for mid-2016 is to integrate all of this Windows OpenSSH support into the OpenSSH upstream repository, which is likely to be the time that Microsoft declares it production ready.

In T10203#185542, @thoughtpolice wrote:

In T10203#185476, @hach-que wrote:

Though it's worth pointing out CircleCI only supports 2 concurrent jobs at their highest tier, and 1 concurrent job for every other plan, so it's not suitable for a wide variety of purposes.

Yeah, Appveyor only supports one concurrent build, but that's *more* than OK for us now, at least. Any form of CI on master and our STABLE branches, at least, is better than no CI for Windows.

In T10203#185476, @hach-que wrote:

Though it's worth pointing out CircleCI only supports 2 concurrent jobs at their highest tier, and 1 concurrent job for every other plan, so it's not suitable for a wide variety of purposes.

We could also possibly just drop these commit mails in all cases where no audit triggered. It's easy to write a Herald rule to restore them if you do want them. Possibly involved enough to be adjacent to T10978, though.

A small part of the motivation for this change was to make commits reachable only from Gerrit magic refs (refs/changes/..., similar to refs/pull/...) visible in Diffusion. This didn't really make it into a single upstream task I think, but some of this is scattered across T9726 / T6878. So we have at least one use case where users want these refs to exist and be treated roughly like they were tags/branches.