Hi everyone,
> An important reason to release the SSL feature set as is could be for > the potential to release timely security fixes when vulnerabilities or > exploits are discovered. Security problems are fixed in both 1.5 and 1.4 branches at the same time with new releases, see 1.4.24/1.5-dev19 and 1.4.23/1.5-dev18. Willy is very well aware that 1.5 is widely used in production. > Unfortunately we don't have the resources to maintain a branch to > which we could backport relevant fixes, not to mention the overhead of > managing any security related fixes. Willy is very transparent with security issues and its fixes are usually just a small patches, so the "backport" is really only a question of downloading a single patch and applying it. Also, in contrast to other projects, Willy and the mailing list do provide full support for 1.5 and appreciate bug reports for it. So if you have troubles backporting a security relevant fix, I think the mailing list will help without hesitation. I do completely understand your worries about using a development version in production. Like I said, if this is a showstopper for deploying HAproxy, then you need commercial support: >> If you don't have the time and need those bleeding edge features >> today, then you should probably stick to a commercial solution, >> like those from exceliance.fr or loadbalancer.org. > > I'm not sure if either of these offer websocket+SSL support, but > certainly worth investigating. I should've made it clear: Exceliance products are based on HAProxy *1.5-dev* and Willy is actually an employee (or even a founder). So if your configuration does work with haproxy 1.5, Exceliance will get the job done (and the fees will probably fund further development of HAProxy in one way or another). Given the code contributions of loadbalancer.org I highly suspect they have some HAproxy based products as well. > With the knowledge that server-side keep-alives aren't currently > supported together with SSL we could plan our production deployment to > take this into account until a future release does support the > combination. Documentation could very well reflect these limitations > and serve to manage users expectations. A single OSS product will never cover all the aspects and requirements all the different users have, but it doesn't need to, imho. Thats why we (in the IT industry) have commercial products, paid 24/7 support, SLAs and features requests with business cases behind it, even if the actual source code is open. Have CentOs, but want to sleep better? Get RHEL with commercial support. Regards, Lukas
