I just released vsftpd-3.0.3, as noted on the vsftpd home page. It's actually been almost three years(!) since vsftpd-3.0.2, so things do seem to be getting very stable and calming down.
The exception to things getting very stable and calming down seems to be SSL over FTP, which has been a constant source of, uh, joy, for some time now. Some issues fixed relate to security and warrant describing here because I think they are interesting.
Cross-protocol MITM SSL connection rewiring to effect XSS
If this description sounds like a crazy weird vulnerability, you're right. The best public description is probably in this ProFTPd bug. Pretty awesome work by Jann Horn. It's a sufficiently involved issue that it's hard to pin down a root cause, but my primary take away would be: use different SSL certificates for different protocols. It's hard to predict what other cross-protocol confusions might be possible and different certificates for different protocols helps protect against the unknown.
That all said, vsftpd-3.0.3 drops the FTP connection if it sees HTTP command verbs, thus avoiding one known trouble for anyone who has an unfortunate certificate and server setup.
SSL session re-use workaround can be thwarted
Back in 2008, I blogged about a simple yet powerful attack which permitted stealing of in-progress FTP SSL data transfers. In the 2008 post, I seem to blame FTP clients but I don't think that's correct: the FTP protocol itself is broken for SSL transfers. (That was 7 years ago so perhaps I could have driven an RFC to fix the protocol by now; mea culpa.) In the face of a broken protocol, I've been working with Tim Kosse (of FileZilla fame) to try and kludge around the situation for years. The most solid solution is client certificate matching but that is not something that FTP clients do by default, and we wanted better security by default. Accordingly, vsftpd started to authenticate SSL data connections by requiring session re-use on SSL data connections. This did seem to work by default in many FTP clients.
Unfortunately, you can now go and read how Tim Kosse broke this defense. The kludge piled on top of existing kludges is to terminate the full FTP session in the event of an SSL session re-use failure on the data channel. Are we done with kludge stacking? We hope so but it's hard to be sure.
SSL upload data connections now must be shutdown correctly at the SSL layer
vsftpd-3.0.3 flipped a default setting so that SSL upload data connections must now be shutdown correctly at the SSL layer. Absent this setting, the FTP server can't tell whether the upload connection was closed with a TCP FIN (which any MITM can inject) vs. a proper shutdown over the SSL channel (secure). To put it in plainer terms, without this setting, the FTP server can't tell if a network attacker deliberately truncated the upload or not. I documented this area in 2008 (proposed root cause: the OpenSSL API is bad). At the time, FTP clients and servers were universally rubbish at SSL connection shutdown integrity. Since then, things are better, so I've flipped the default. Again, if you're using FileZilla as the FTP client, it goes to pains to do SSL well.
ECDHE support
Thanks again to Tim Kosse (this guy is on fire!), there's ECDHE support in vsftpd-3.0.3. It turns out that you need to incant a few magic lines of OpenSSL API in order to enable ECDHE. Also, just to make the point, vsftpd's default cipher list now consists of the single cipher ECDHE-RSA-AES256-GCM-SHA384. This is a modern TLSv1.2 cipher that is believed pretty solid. People needing interoperability with older clients may need to change or disable the cipher list.
FTP SSL data security is kind of tricky, and probably isn't 100% dealt with yet, but the combination of the latest FileZilla + latest vsftpd should be a reasonable start, if you really must use SSL over FTP.