[eichin]

We actually ship a bunch of vetted pubkeys in our developer tools package (in ssh_known_hosts2) . We tried to get a little bit out of the loop and tell our devs that they could use the instructions at https://bitbucket.org/blog/ssh-host-key-changes (confirm it doesn't cert fail, then read the curl https://bitbucket.org/site/ssh bit and see that it also checks certs, so we can leverage "trusted https cert" to "trusted ssh key"... much better than TOFU...

Didn't work, because there's no trailing newline on the output of site/ssh. So even if it works, it corrupts the next addition.

[js2]

Change from this:

  curl https://bitbucket.org/site/ssh >> ~/.ssh/known_hosts

To this:

  (curl https://bitbucket.org/site/ssh; echo) >> ~/.ssh/known_hosts

[eichin]

You may have missed the part about "telling people they can trust the vendor instructions"...

[tjk_]

Thanks for pointing this out, I'll put in a PR to fix that up today.

[eichin]

cool, thanks! I'm sort of surprised it didn't get attention via some other path, but then I never got around to filling a ticket myself :-)

[tjk_]

Optimistically, I like to think that people were just not _quite_ bothered enough to file a bug report. The pessimist in me thinks that people went back to blindly typing "yes" when prompted. Either way, thanks for the feedback, the fix should be live!

[eichin]

Confirmed, with curl. Thanks for closing the loop!

[ahoka]

Umm, why don’t you just use git over HTTPS?

[eichin]

Much worse performance (which might have been idiosyncratic, or might have been improved in recent years, but repeated authentication vs. single stream design hasn't changed.)