The original filezilla project has been adding some kind of unwanted extra nonfree software to the releases. For this reason we have created a fork which is committed to plain and simple releases with no extra rubbish.
The original filezilla project has been adding some kind of unwanted extra nonfree software to the releases. For this reason we have created a fork which is committed to plain and simple releases with no extra rubbish.
You’d save yourself a lot of trouble upfront not borrowing the filezilla name - it’s trademarked. Already there’s an argument for whether “-ng” postfix constitutes a new mark, why bother even having it. Just completely rename it
Hilariously their trademark policy seems to prohibit their use of their own name
Oh, great point. We will need to think of a new name.
How about godzilla-ftp.
How about filemander? It’s still in the same vein as “zilla,” but far more modest. The fact that you’re refusing cruft, provides a sense of modesty.
Also, “mander” and “minder” — minder maybe isn’t exactly right for an FTP client, but it’s not completely wrong…
Great name! A quick ddg search does not show any existing projects using it.
And it sounds a bit like “fire mander”, which ties in well with the mythological connections between salamanders and fire.
Yeah, the intention was to have a cute salamander logo–way more modest a lizard than a “SOMETHINGzilla!”
You’d be inviting lawsuits over the term “godzilla” instead.
Just remember to make sure it’s easy for random people to remember and spell. They’ll be Googling it at some point.
Nice. If you distribute pre-compiled binaries, please gpg-sign them and perhaps provide sha512 checksums of them as well.
Thank you. I was planning on GPG signing and using SHA256. Is that OK?
I also hope to make the build reproducible on linux, using debian’s reproducible build tools.
Reproducible builds would be awesome.
As for SHA256 vs. SHA512, from a performance point of view, SHA512 seems to perform ~1.5x faster than SHA256 on 64-bit platforms. Not that that matters much in a case like this, where we’re calculating it for a very small file, and very infrequently. Just thought I’d put it out there. So, yeah, SHA256 works too if you want to go with that :)
Also remember defaulting on SHA-1 or SHA-256 means hardware acceleration might be possible for some users.
SHA-1 has been on the way out for a while, and browsers refuse SHA-1 certificates these days. It might be a good idea to just skip SHA-1 entirely and rely on the SHA-2 family.
True. I was just noting there’s accelerators for it in many chips.
Isn’t SHA-512 faster on most modern hardware? ZFS uses SHA-512 cut down to SHA-256 for this reason, AFAIK.
A benchmark: https://crypto.stackexchange.com/questions/26336/sha512-faster-than-sha256
Oh idk. I havent looked at the numbers in a while. I recall some systems, esp cost- or performance-sensitive, stuck with SHA-1 over SHA-256 years ago when I was doing comparisons. It was fine if basic collisions weren’t an issue in thd use case.
Anecdotal, but I just timed running sha 512 and 256 10 times each, on a largeish (512MB) file. Made sure to run them a couple of times before starting the timer to make sure it was in cache. Results for sha-512 were:
And 256:
So it looks like sha-512 pretty clearly wins. (CPU is an i3-5005u).
Cool stuff. Modern chips handle good algorithms pretty well. What I might look up later is where the dirt-cheap chips are on offload performance and if they’ve upgraded algorithms yet. That will be important for IoT applications as hackers focus on them more.
You should probably be sure to have your facts straight before giving security advice.
I said there’s hardware accelerators for SHA-1 and SHA-2. Both are in use in new deployments with one used sometimes for weak-CPU devices or legacy support. Others added more points to the discussion with current, performance stats something I couldnt comment on.
Now, which of my two claims do you think is wrong?
Ideally, OP would also get a code signing certificate from Microsoft to decrease the amount of warnings Windows spouts about the executable.
Great idea!
I think being more explicit about what “fresh and clean” means in the README would be helpful. I was unaware of the nonfree software part until I clicked into this thread, and assumed it was about code quality.
It would also be reassuring to see some comments around strategy for keeping this up-to-date with new features, bugfixes etc. from the main filezilla repo (if that is the plan).
It was always my favorite FTP client. Good job on the fork.
So that’s what it is. @rain1: can you add a sentence to the top of the Readme saying that it’s an FTP client? The description should also say, “A fresh and clean fork of the FTP client filezilla”.
excellent suggestion. Done.
Can you be more specific about what exactly? It would probably also be good to state the motivation for the fork at the beginning of the README.
+1. I get frustrated with forks that don’t provide a straight forward reason for their existence. I mean, it’s open source so that’s your right, but there’s a certain amount of harm that happens to the original project when a fork happens and takes off, and I feel like it’s important to at least be super clear about what you’re doing and why.
Bring back LeechFTP!
WS_FTP!
LLNL XFTP!