Very cool, though I find it a little odd. If someone is going the extra mile to store the file encrypted, it stands to reason that trusting the service with the initial unencrypted byte stream is a no-go. The file being uploaded over HTTPS, and your assurance that the stream is piped directly through encryption, is of little consequence if you or an infiltrator to your server were to choose to be malicious.
I understand it's impossible to tool the concept to work with a very simple shell one-liner, and without a further dependency like an openssl binary. I like the concept, but I'd rather have to perform a one-time install of openssl or similar and copy a 10-20 line bash script to have true security rather than your current setup that comes with a technically flawed security model.
Obviously you are aware of this, and chose the path of convenience and "good for most uses". Kudos for a clean tool!
Obviously it comes to personal judgment when people use my tools. I mean they could also do as described in transfer.sh, pipe first the data through gpg. The server accepts any kind of data as long as it doesn't overflow the current set size limit.
But indeed I do agree that I can't guarantee or even prove that I can't access the files on my server. That's why I offer a quick and simple way for people to setup this on their own machine, so they can have this lightweight server and use it as if it was mine just by modifying a line in the configuration file of the client (or changing the URL in the curl commands)
Comments
Very cool, though I find it a little odd. If someone is going the extra mile to store the file encrypted, it stands to reason that trusting the service with the initial unencrypted byte stream is a no-go. The file being uploaded over HTTPS, and your assurance that the stream is piped directly through encryption, is of little consequence if you or an infiltrator to your server were to choose to be malicious.
I understand it's impossible to tool the concept to work with a very simple shell one-liner, and without a further dependency like an openssl binary. I like the concept, but I'd rather have to perform a one-time install of openssl or similar and copy a 10-20 line bash script to have true security rather than your current setup that comes with a technically flawed security model.
Obviously you are aware of this, and chose the path of convenience and "good for most uses". Kudos for a clean tool!
Obviously it comes to personal judgment when people use my tools. I mean they could also do as described in transfer.sh, pipe first the data through gpg. The server accepts any kind of data as long as it doesn't overflow the current set size limit.
But indeed I do agree that I can't guarantee or even prove that I can't access the files on my server. That's why I offer a quick and simple way for people to setup this on their own machine, so they can have this lightweight server and use it as if it was mine just by modifying a line in the configuration file of the client (or changing the URL in the curl commands)
I'm glad you enjoyed the tool though :D