Really nice! PDF editing is super underserved relative to its usage IRL, it’s always great to see new tools.
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.
Ah sure, this alternate implementation assumes that the BlogPost class is final and never subclassed.
If you plan to subclass BlogPost, the translation is not identical, as the alternate implementation would not keep track of a global count of posts across all subclasses, only of `BlogPost` instances exactly.
The Financial Times recently changed their abbreviation for million from “m” to “mn” to help screen readers. They would typically read an m suffix as metres; I guess the FT chose mn rather than mm so that screen readers would not say millimetres instead of million.
I’ve seen that use for sure. Perhaps a little telling we’re talking about blockchain tech and that’s what people are using. Is it really about a fast distributed transaction log, or… is it about the money first.
DOS is a bit of a misleading term here. You're not actually denying them service at all. You're just tricking the service provider into potentially mis-identifying them as a different user, depending on how their SSH is configured, and it's easily solved by a small SSH config change on their end. And it only works against someone who has multiple keys anyway.
> A simple solution would be to avoid the single user login [email protected], and use that as identification, for example [email protected].
Except this completely ignores the reason why services use [email protected]. It's not because they're lazy. It's because the URL is supposed to identify the project, not the user. If the URL included the user's own username, 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), and removes the ability for people to copy&paste a `git clone` command from a README (or blog post or wherever else).
So yes, there is a theoretical annoyance attack here, but nobody really cares because it's never going to happen accidentally, it can't be used against most people, and it's so trivially bypassed nobody's going to bother doing it except as a PoC. The benefits of using [email protected] greatly outweigh the downsides.
> and it's easily solved by a small SSH config change on their end
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.
> It doesn't explain why Heroku uses it. Do you really push different submodules to Heroku?
I don't use Heroku, but, sure, why not? If I push a repo to Heroku that includes submodules, presumably Heroku then fetches those submodules (I'm assuming it supports submodules at all, which seems like an obvious thing to support). Therefore, those submodules must be specified by a URL that works for everyone, not just you.
> For Github et. al, that's easily solved by project-level or organization-level identity.
How does that solve anything? You're no longer identifying the user whose key is supposed to be used, which means this no longer solves your problem. 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@.
> And using `git@` doesn't work if you use multiple accounts because you'd specify the IdentityFile by host.
Sure it does. IdentityFile is explicitly allowed to be specified multiple times for a single host, and the files will be tried in turn. So you can specify all your keys that way.
> Those service providers often get contacted because this happens BY ACCIDENT.
Someone uploads a private key that doesn't belong to them by accident, that screws up other innocent people? I'm rather skeptical. What's your source on this? And no, your own anecdotes do not constitute proof that providers often have to deal with this.
> 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.
Your work is handing out a shared public/private keypair and encouraging people to set this up as a default identity in SSH? That sounds awful, and it's entirely a problem you created and not even remotely the burden of GitHub or Heroku to care about.
> If I push a repo to Heroku that includes submodules, presumably Heroku then fetches those submodules
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 [email protected]: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.
> You may use submodules hosted on github with Heroku, but you don't use Heroku to host that repo.
Ah, I see what you mean. But is that actually true? If you push a repo to Heroku, are you still expecting to host the canonical version of that repo elsewhere, instead of just using Heroku as the canonical version? Because if it's the latter, and you're working with other people, then it's still useful to have a single URL that identifies the repo.
> Do you want to clone a public module as a subrepo, or allow commit access? Public repos can be cloned without identification.
But you're going over SSH, so you have to negotiate the connection before the server knows what action you're taking. So the SSH connection will be the same whether you're pushing or pulling. You can't negotiate different identities for pushing vs pulling, so whatever identity you settle on has to work for both.
> 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.
Ah, I see.
It sounds to me like using username@ is still completely useless regarding your proposed "attack", but does have some small utility for people who have multiple accounts. But I still think the obvious general utility of having a single URL that works for everyone is more important.
As an aside, it looks to me like you could try using the `Match` keyword in your ssh_config and have it run an external command that determines which account you should be using. This could be controlled with an environment var, or maybe it could look at $PWD. If you can come up with some suitable command, then you can use that to control which identity file to use.
> If you're not going to believe anything I say, I got nothing.
I believe your personal, anecdotes, but you can't just make a broad claim about providers with no evidence and expect me to believe that it really is as widespread an issue as you claim.
"It's because the URL is supposed to identify the project, not the user. If the URL included the user's own username, that URL wouldn't work for anyone else."
Couldn't the URL just not include a username, though? Then when git tries to establish an ssh connection, it could try the local username (like ssh does by default), or a username specified somewhere in a config file.
You can dos someone just by knowing their ip or how to get a hold of them. You can also sign up magazines to be delivered to their office address and DOS their workplace.
