ffsend icon indicating copy to clipboard operation
ffsend copied to clipboard

ffsend apt package

Open sbrl opened this issue 4 years ago • 4 comments

Hey there! I've completed the packaging process for ffsend. My apt repository is here: https://apt.starbeamrainbowlabs.com/

Once you've setup the apt repository according to the instructions in the header, you can install it with sudo apt install ffsend (though I'm considering changing the package name to python3-ffsend - though I'm unsure).

I've scripted the process too. Every time a new GitHub release is made, I'll get a notification that will let me know that I need to re-run the script - as I do not currently have automation on it yet (though I'm working on this).

I do note a few things however now that I've explored it:

  • It doesn't have an environment variable for the password, which is insecure
  • The TTL is in seconds, which isn't very intuitive. Perhaps supporting things like 24h or 7d would be possible?
  • Do you have to upload a file first before setting the TTL with a separate call?
  • How do I login with a Mozilla account? At send.firefox.com it limits you to 1GiB + 24h if you don't login, and raises this limit to 2.5GiB + 7d if you're logged in

sbrl avatar Jan 14 '20 19:01 sbrl

Cool, thanks for doing that.

  • For the password, AFAIK a password environment variable is used to authenticate (here, for download). I am a little hesitant to use a password environment variable for setting a password because there's a real risk of someone uploading a file and password-protecting it by accident, and if we don't use the environment variable for setting a password then it will feel a little inconsistent. Thoughts?
  • I'd love to. If there's a reasonably standard way to handle this, that'd be best. Happy to take a PR. Info already shows the TTL using h/m/s so we can probably just use that syntax (i.e., [Xd][Xh][Xm][Xs], interpreting as seconds if no units are present).
  • You can specify --set-ttl with an upload, so no separate call is required. (The script calls do_set_params after a successful upload)
  • You can't at the moment. PyFxA exists so I might play with that, but I'm not sure how robust the support is yet. I definitely don't want to roll my own client. Might be worth a try to integrate it?

nneonneo avatar Jan 14 '20 21:01 nneonneo

Amusingly, my ffsend client apparently bypasses the 1GiB limit and allows you to upload up to 2.5GiB as an anonymous user. It might be considered a bug in the Firefox Send implementation (the websocket version that most people use limits to 1GiB, but the /upload endpoint I use uses the full 2.5GiB limit). I've just tested this with a random 1.7GiB file and found that ffsend.py was able to upload it successfully.

However, it is not possible to change the download limit as an anonymous user. I will poke at PyFxA and see if I can integrate that.

nneonneo avatar Jan 14 '20 21:01 nneonneo

Ok, I got FxA support but the new issue is that you can't set a TTL anymore via params - so you can only set a TTL through the initial upload if you use websockets. Blech.

I wonder if maybe I can just get that fixed by filing an issue over at mozilla/send...

nneonneo avatar Jan 15 '20 01:01 nneonneo

Hey, no problem!

For the password, AFAIK a password environment variable is used to authenticate....

Hrm, that is an issue. Perhaps using an environment variable name that is unlikely to be used, like FFSEND_UPLOAD_PW?

I'd love to. If there's a reasonably standard way to handle this, that'd be best

I'm not sure of any standard documents, but I have seen a number of tools use the letters w, d, h, m, and s to specify longer lengths of time more easily.

Info already shows the TTL using h/m/s

Not sure what you mean by this. When do ffsend --help, I see this:

--set-ttl SET_TTL     Set the time to live (in seconds). Must specify
                        -t/--token

Amusingly, my ffsend client apparently bypasses the 1GiB limit and allows you to upload up to 2.5GiB as an anonymous user

Haha, nice! Nothing to worry about then - I wasn't aware of the internal implementation there. Yeah, it might be worth filing a bug over there to ask what's going on with that. It does sound like there are a number of inconsistencies in the protocol they've implemented.

sbrl avatar Jan 15 '20 12:01 sbrl