tjk_ · HackerTrans

3 ปีที่แล้วdiscuss

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!

tjk_

3 ปีที่แล้วdiscuss

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

tjk_

3 ปีที่แล้วdiscuss

Bitbucket dev here. Firstly, thanks for the post, this topic is too often skimmed and as someone who worked directly on the host key rotation here, it was shocking to find how many devs had zero idea what "that prompt from git on a new computer" was.

Secondly, I just wanted to say that there is an interesting side-effect to everything covered in that blog that effectively leads to a gap in most people's mental models (or maybe just mine). Because of the way these systems were defined/the way people interact with them, there are several conundrums when a large centralized host needs to deprecate an old key.

If a key were suspected of being compromised, it seems obvious that you could just stop serving the old key and tell all of your users to be prepared to re-TOFU. However, since _most_ devs blindly type "yes" when interacting with a large git host, this effectively primes the pumps for any bad actor that have MITM control but have not actually stolen the keys. This gives them a relatively long (if not infinitely long) window of time where a user will not be surprised to see "the prompt" and blindly accept trust of a host that could be controlled by the bad actor. If a key was completely successfully compromised by a bad actor, and said bad actor had MITM control of the victim network, then requests with the _old_ key would never actually reach the correct host and just quietly continue working (assuming the bad actor was savy enough to setup a remote system to properly behave as a git host without a prior copy of the target repository).

Damned if you do, damned if you don't, so always carefully TOFU.

Also,not sure why the author linked off to a Bitbucket Cloud blog post for the SSH keys, they are documented here[1] along with our recommended best practices WRT TOFU.

1 - https://support.atlassian.com/bitbucket-cloud/docs/configure...

tjk_

4 ปีที่แล้วdiscuss

Mind if I ask if you're having this issue on Bitbucket Cloud (bitbucket.org) or Bitbucket Server (self-hosted)?

tjk_

5 ปีที่แล้วdiscuss

I work for a large provider in the VCS/CI space. While I appreciate the varied opinions in the comments here on the perceived usefulness of Crypto, I think folks outside of the space simply do not understand how much time is being spent combating the issue.

If we, for example, had a team of 20 working on our CI offering, we would have re-allocated at least 50% of them to work full-time on combating the miners. And this trend is not slowing, it is only accelerating.

One week, we may have a breakthrough and find some common heuristic in running binaries that identify _this weeks_ miners, but next week they will have figured out that we have figured it out and make the requisite changes. It's something akin to the early days of anti-virus software, but given the 2021 scale of the internet, the iterations are moving at warp speed in comparison.

If you care nothing of the environmental impact (IMO you should), then take a second and ask yourself what your life as a creator of _things_ be like with no free access to CI tooling? I guaranty you that changes to the free tier of ALL CI services are on the way, and I heavily suspect that when that happens, the miners will take over any service offering paid CI where the return outweighs the price. This will lead to an escalation of pricing such that side-project, FOSS, and anything less than large profitable software will be priced out of hosted CI and be forced into a different model.

Stake: No crypto stake of any kind