Look into Bunny the sheepadoodle https://www.instagram.com/whataboutbunny?igsh=cHNtZTk0Y3dsND.... She makes consistent phrases like “look look outside squirrel” or “dad upstairs poop”.
37 karma · joined November 2, 2013
My partner needed one that has total data residency (can’t upload it) so I ended up building one as an app. It doesn’t have half the features of QuicklyPDF tho.
Jez!
You're missing the point. You may use submodules hosted on github with Heroku, but you don't use Heroku to host that repo. You're not going to `git submodule add git@heroku.com:project`. So for the sake of argument, if we pretend that git repo hosts do need to use `git@`, I don't see a single reason why Heroku would.
> And if you're going to suggest that it should only consult users who have access to the repo, for a public project that's everybody, which makes it functionally identical to git@
Now you're confusing two things. Do you want to clone a public module as a subrepo, or allow commit access? Public repos can be cloned without identification. If you want commit access, why would project-level not work?
> Sure it does. IdentityFile is explicitly allowed to be specified multiple times for a single host, and the files will be tried in turn
Again, missing the point. If you don't specify a different host, you'll always be identified and authenticated as the first key that matches, therefore you'll only use a single account. That's why you have to use different hosts.
> And no, your own anecdotes do not constitute proof that providers often have to deal with this.
If you're not going to believe anything I say, I got nothing. Otherwise, 2 things
- I opened an issue and the response was basically "Ooooo that explains some of those tickets". They specifically mentioned issues with vagrant. - I presented this at a local meetup and someone else had put themselves in this position.
> Your work is handing out a shared public/private keypair and encouraging people to set this up as a default identity in SSH?
No. As I said, it was meant to setup the vagrant box and then not be used. By default vagrant connects using an insecure keypair.
The article does mention it. The issue is not fixing the problem, it's actually finding it.
> [...] that URL wouldn't work for anyone else, which breaks git-submodules, breaks any kind of config file that specifies repositories (e.g. for use by a CI server)
It doesn't explain why Heroku uses it. Do you really push different submodules to Heroku?
For Github et. al, that's easily solved by project-level or organization-level identity.
> that URL wouldn't work for anyone else
And using `git@` doesn't work if you use multiple accounts because you'd specify the IdentityFile by host.
> nobody really cares because it's never going to happen accidentally
Except it does. Those service providers often get contacted because this happens BY ACCIDENT.
I've done it to myself by adding my public key to my work account. I couldn't access my personal stuff without changing my SSH config.
A while ago at work, we were using a shared key that was used to setup the initial vagrant config. New hires often added that key to their github or heroku account.
I've heard similar stories elsewhere too.