Earlier quoted context omitted.
How do they "get burned" by that? Not having a license means you don't get to use it and are violating their copyright if you do so (possibly except the things specified in Github ToS: look at the code on github)
So not having a license means a default one was used? Which licence is that?
X0.at: upload files from cURL
61–70 of 93 posts
Re: X0.at: upload files from cURL
#62Earlier quoted context omitted.
How do they "get burned" by that? Not having a license means you don't get to use it and are violating their copyright if you do so (possibly except the things specified in Github ToS: look at the code on github)
So not having a license means a default one was used? Which licence is that?
Re: X0.at: upload files from cURL
#63Earlier quoted context omitted.
Drive and Dropbox are at least moderated.
Source? ...moderated via automation or human?
> Google Drive scans a file for viruses before the file is downloaded or shared. If a virus is detected, users cannot convert the infected file to a Google Doc, Sheet, or Slide, and they'll receive a warning if they attempt these operations.
So at least some degree of automated moderation is going on. Frankly, I'd be astounded if some amount of scanning isn't being done for illegal content and/or phishing stuff.
Re: X0.at: upload files from cURL
#64Earlier quoted context omitted.
> Uploading files without auth layer - is asking for trouble IMHO. If you make it super user-friendly and advertise it as the next Megaupload, sure. But if you keep a small audience of good-faith users it's not asking for problems. If you can teach me to make my file upload as hacker-friendly as this service while implementing auth, i'd be glad. Here the entire point is you don't need further configuration/credential…
1. How are you blocking someone from uploading millions of files programmatically? 2. How do you know someone is from small audience of good-faith? 3. What if a file has virus and corrupt all the files on your end? If you don't need auth, there are few measures you can take on your end: 1. TTL - Make these files temporary - They will be erased after x hours. Eg. x=1 2. Throttle - Limit number of uploads from a given…
Re: X0.at: upload files from cURL
#65Re: X0.at: upload files from cURL
#66Earlier quoted context omitted.
Drive and Dropbox are at least moderated.
Source? ...moderated via automation or human?
You can't rely on the good faith of users, if your service is easily usable for crime, it will be used for it.
Re: X0.at: upload files from cURL
#67Re: X0.at: upload files from cURL
#68curl -X POST https://content.dropboxapi.com/2/files/upload --header "Authorization: Bearer ACCESSTOKEN" --header "Dropbox-API-Arg: {\"path\": \"/DROPBOXFILEPATH/DROPBOXFILENAME\"}" --header "Content-Type: application/octet-stream" --data-binary @/LOCALFILEPATH/LOCALFILENAME
Re: X0.at: upload files from cURL
#69Also there is a cute alias you can do to easily 'share' files:
alias share='f() { curl --progress-bar --upload-file "$1" https://share.schollz.com | tee /dev/null; echo };f'
Re: X0.at: upload files from cURL
#70Earlier quoted context omitted.
This is incompatible with using curl as your client, but one “hacker-friendly way to do auth” is to use Github’s public SSH keys API. You can stand up an (SCP/SFTP-subprotocol-only) SSH server, and tell the user to log in with their GitHub username + GitHub SSH key. Then configure your SSH server to call[1] a check on GitHub’s API to map the provided username to the GitHub user’s set of public SSH keys. From there, t…
That's a neat idea, but I would try to simplify it a bit. Now, the details are fuzzy as I haven't set up anything like this but I know the theory behind it. You could setup a website which accepts file uploads at username:file_signature@example.com , when a request is accepted you retrieve the public ssh key for "username" and validate that the "file_signature" is valid for the file uploaded. It's a bit unintuitive t…
1. letting you ban bad actors from your system by creating a blacklist of GitHub usernames; and
2. putting a stumbling block in the way of getting around #1 by signing up for 1000 accounts (signing up for a GitHub account takes a while; adding a unique new SSH key[1] to that GitHub account means generating a new SSH keypair, which takes another while; etc. Having a GitHub account with an associated SSH key constitutes a very small proof-of-work, similar to an e-stamp.)
[1] IIRC, a given SSH public key cannot be associated with more than one GitHub account at a time.
Any SSO provider would provide the same guarantees; but GitHub is the only SSO provider that has people's SSH pubkeys on file and accessible through a public API, and so GitHub is the only SSO provider you can use as an SSO provider through SSH.
Also, as a separate "benefit" (though some would argue it's the opposite), GitHub accounts — SSO accounts generally — are more-often-than-not associated with people's personal identities. SSO identity-provider sign-up processes usually collect quite a bit of PII, and often do a bit of KYC with phone verification, etc. This means that requiring sign-in through SSO is an almost-perfect ward against criminal use of your service — since any criminal stupid enough to SSO into your site and then do something illegal, can be quickly-and-easily identified by the police by sending a warrant to the SSO provider.
-----
Besides all that, the point here is to make the process of uploading a file as simple as possible for the end-user (presuming the end-user is a developer familiar with common CLI tools.) The backend complexity isn't really a concern, if it presents a simple and straightforward API.
With GitHub-identity-supported SSH-pubkey-auth, anyone who has a default SSH keypair and a GitHub account (and who has registered their default SSH keypair against their GitHub account) can directly jump to typing `scp ./file mygithubuser@uploader.example.com:` and it'll "just work" — without having to ever even visit uploader.example.com to register an account! Most developers have a GitHub; and most developers have used SCP before at some point. It's a very familiar process. Less confusing, even, than GitHub's own requirement of needing to SSH into github.com as the "git" user.
With your scheme, meanwhile, the user has to figure out how to sign a file using SSH — something I don't think more than a handful of people in the world will have ever had previous experience with. That's not quite "easy" on the level of "just use cURL" or "just use SCP" :)