Re: [ANNOUNCE] haproxy-1.8.14 - Security Update
Am 20.09.2018 um 14:31 schrieb Willy Tarreau: > Subject: [ANNOUNCE] haproxy-1.8.14 > To: haproxy@formilux.org > > Hi, > > HAProxy 1.8.14 was released on 2018/09/20. It added 44 new commits > after version 1.8.13. Image on docker hub was updated to. https://hub.docker.com/r/me2digital/haproxy18/ Regards Aleks > The most important one fixes a security issue reported by Tim Düsterhus > and which was assigned CVE-2018-14645. There is an integer signedness > issue in the HPACK decoder used in HTTP/2 which theorically makes it > possible to remotely crash an haproxy instance where HTTP/2 is in use. > I want to thank Tim for his responsible reporting and Ryan O'Hara for > quickly providing us with a CVE ID. > > The only workaround for those who for various reasons can't immediately > update, is to disable HTTP/2. But distros will provide an updated package > soon. If some distro maintainers need a way to test if their version is > properly fixed, please contact me privately, I'll explain how to proceed. > > Two other major issues are fixed in this version, one of them related to > how SSL is initialized in Lua, apparently it didn't properly consider > the presence of threads, leading to random behaviours. The second only > affects kqueue, I don't have the details in memory, I suspect it was > causing some delays in connection processing there. > > The rest is the regular list of problematic but not critical issues that > need to be fixed but for which there is no emergency. > > Please find the usual URLs below : >Site index : http://www.haproxy.org/ >Discourse: http://discourse.haproxy.org/ >Sources : http://www.haproxy.org/download/1.8/src/ >Git repository : http://git.haproxy.org/git/haproxy-1.8.git/ >Git Web browsing : http://git.haproxy.org/?p=haproxy-1.8.git >Changelog: http://www.haproxy.org/download/1.8/src/CHANGELOG >Cyril's HTML doc : http://cbonte.github.io/haproxy-dconv/ > > Willy > --- > Complete changelog : > Baptiste Assmann (4): > MINOR: dns: fix wrong score computation in dns_get_ip_from_response > MINOR: dns: new DNS options to allow/prevent IP address duplication > BUG/MEDIUM: dns/server: fix incomatibility between SRV resolution and > server state file > BUG/MINOR: dns: check and link servers' resolvers right after config > parsing > > Bertrand Jacquin (2): > DOC: ssl: Use consistent naming for TLS protocols > DOC: Fix typos in lua documentation > > Cyril Bonté (1): > BUG/MEDIUM: lua: socket timeouts are not applied > > Dragan Dosen (1): > BUG/MEDIUM: patterns: fix possible double free when reloading a pattern > list > > Emeric Brun (4): > BUG/MINOR: ssl: empty connections reported as errors. > BUG/MEDIUM: ssl: fix missing error loading a keytype cert from a bundle. > BUG/MEDIUM: ssl: loading dh param from certifile causes unpredictable > error. > BUG/MINOR: map: fix map_regm with backref > > Emmanuel Hocdet (1): > BUG/MEDIUM: ECC cert should work with TLS < v1.2 and openssl >= 1.1.1 > > Frédéric Lécaille (3): > BUG/MINOR: lua: Bad HTTP client request duration. > BUG/MAJOR: thread: lua: Wrong SSL context initialization. > BUG/MINOR: server: Crash when setting FQDN via CLI. > > Jens Bissinger (1): > DOC: Fix spelling error in configuration doc > > Lukas Tribus (1): > DOC: dns: explain set server ... fqdn requires resolver > > Olivier Houchard (4): > MINOR: threads: Introduce double-width CAS on x86_64 and arm. > BUG/MEDIUM: hlua: Make sure we drain the output buffer when done. > BUG/MEDIUM: hlua: Don't call RESET_SAFE_LJMP if SET_SAFE_LJMP returns 0. > BUG/MAJOR: kqueue: Don't reset the changes number by accident. > > Patrick Hemmer (1): > BUG/MEDIUM: lua: reset lua transaction between http requests > > Thierry FOURNIER (1): > BUG/MEDIUM: lua: possible CLOSE-WAIT state with '\n' headers > > Willy Tarreau (20): > BUG/MEDIUM: servers: check the queues once enabling a server > BUG/MEDIUM: queue: prevent a backup server from draining the proxy's > connections > BUG/MEDIUM: threads: fix the double CAS implementation for ARMv7 > MINOR: threads: add more consistency between certain variables in > no-thread case > BUG/MEDIUM: threads: fix the no-thread case after the change to the > sync point > MEDIUM: hathreads: implement a more flexible rendez-vous point > BUG/MEDIUM: cli: make "show fd" thread-safe > BUG/MEDIUM: cli/threads: protect all "proxy" commands against > concurrent updates > BUG/MEDIUM: cli/threads: protect some server commands against > concurrent operations > BUG/MEDIUM: unix: provide a ->drain() function > BUG/MEDIUM: mux_pt: dereference the connection with care in > mux_pt_wake() > MINOR: thread: implement HA_ATOMIC_XADD() > BUG/MINOR: stream: use atomic increments for the re
Re: [PATCH] REGTEST/MINOR: loadtest: add a test for connection counters
Hi Willy, Op 20-9-2018 om 13:56 schreef Willy Tarreau: For me the test produces like 345 lines of output as attached. which seems not to bad (if the test succeeds). It's already far too much for a user. Well those 345 lines are if it succeeds while in 'verbose' mode, in 'normal' mode it only produces 1 line of output when successful. Pretty much all tests produce 100+ lines of 'logging' if they fail for some reason. From what ive seen varnishtest either produces a bulk of logging on a failure, or it only logs the failures. There isn't much in between. As for all the rest of the email, thanks for your elaborate response :). Regards, PiBa-NL (Pieter)
[ANNOUNCE] haproxy-1.8.14 - Security Update
Subject: [ANNOUNCE] haproxy-1.8.14 To: haproxy@formilux.org Hi, HAProxy 1.8.14 was released on 2018/09/20. It added 44 new commits after version 1.8.13. The most important one fixes a security issue reported by Tim Düsterhus and which was assigned CVE-2018-14645. There is an integer signedness issue in the HPACK decoder used in HTTP/2 which theorically makes it possible to remotely crash an haproxy instance where HTTP/2 is in use. I want to thank Tim for his responsible reporting and Ryan O'Hara for quickly providing us with a CVE ID. The only workaround for those who for various reasons can't immediately update, is to disable HTTP/2. But distros will provide an updated package soon. If some distro maintainers need a way to test if their version is properly fixed, please contact me privately, I'll explain how to proceed. Two other major issues are fixed in this version, one of them related to how SSL is initialized in Lua, apparently it didn't properly consider the presence of threads, leading to random behaviours. The second only affects kqueue, I don't have the details in memory, I suspect it was causing some delays in connection processing there. The rest is the regular list of problematic but not critical issues that need to be fixed but for which there is no emergency. Please find the usual URLs below : Site index : http://www.haproxy.org/ Discourse: http://discourse.haproxy.org/ Sources : http://www.haproxy.org/download/1.8/src/ Git repository : http://git.haproxy.org/git/haproxy-1.8.git/ Git Web browsing : http://git.haproxy.org/?p=haproxy-1.8.git Changelog: http://www.haproxy.org/download/1.8/src/CHANGELOG Cyril's HTML doc : http://cbonte.github.io/haproxy-dconv/ Willy --- Complete changelog : Baptiste Assmann (4): MINOR: dns: fix wrong score computation in dns_get_ip_from_response MINOR: dns: new DNS options to allow/prevent IP address duplication BUG/MEDIUM: dns/server: fix incomatibility between SRV resolution and server state file BUG/MINOR: dns: check and link servers' resolvers right after config parsing Bertrand Jacquin (2): DOC: ssl: Use consistent naming for TLS protocols DOC: Fix typos in lua documentation Cyril Bonté (1): BUG/MEDIUM: lua: socket timeouts are not applied Dragan Dosen (1): BUG/MEDIUM: patterns: fix possible double free when reloading a pattern list Emeric Brun (4): BUG/MINOR: ssl: empty connections reported as errors. BUG/MEDIUM: ssl: fix missing error loading a keytype cert from a bundle. BUG/MEDIUM: ssl: loading dh param from certifile causes unpredictable error. BUG/MINOR: map: fix map_regm with backref Emmanuel Hocdet (1): BUG/MEDIUM: ECC cert should work with TLS < v1.2 and openssl >= 1.1.1 Frédéric Lécaille (3): BUG/MINOR: lua: Bad HTTP client request duration. BUG/MAJOR: thread: lua: Wrong SSL context initialization. BUG/MINOR: server: Crash when setting FQDN via CLI. Jens Bissinger (1): DOC: Fix spelling error in configuration doc Lukas Tribus (1): DOC: dns: explain set server ... fqdn requires resolver Olivier Houchard (4): MINOR: threads: Introduce double-width CAS on x86_64 and arm. BUG/MEDIUM: hlua: Make sure we drain the output buffer when done. BUG/MEDIUM: hlua: Don't call RESET_SAFE_LJMP if SET_SAFE_LJMP returns 0. BUG/MAJOR: kqueue: Don't reset the changes number by accident. Patrick Hemmer (1): BUG/MEDIUM: lua: reset lua transaction between http requests Thierry FOURNIER (1): BUG/MEDIUM: lua: possible CLOSE-WAIT state with '\n' headers Willy Tarreau (20): BUG/MEDIUM: servers: check the queues once enabling a server BUG/MEDIUM: queue: prevent a backup server from draining the proxy's connections BUG/MEDIUM: threads: fix the double CAS implementation for ARMv7 MINOR: threads: add more consistency between certain variables in no-thread case BUG/MEDIUM: threads: fix the no-thread case after the change to the sync point MEDIUM: hathreads: implement a more flexible rendez-vous point BUG/MEDIUM: cli: make "show fd" thread-safe BUG/MEDIUM: cli/threads: protect all "proxy" commands against concurrent updates BUG/MEDIUM: cli/threads: protect some server commands against concurrent operations BUG/MEDIUM: unix: provide a ->drain() function BUG/MEDIUM: mux_pt: dereference the connection with care in mux_pt_wake() MINOR: thread: implement HA_ATOMIC_XADD() BUG/MINOR: stream: use atomic increments for the request counter BUG/MEDIUM: session: fix reporting of handshake processing time in the logs BUG/MEDIUM: h2: fix risk of memory leak on malformated wrapped frames BUG/MINOR: http/threads: atomically increment the error snapshot ID BUG/MEDIUM: snapshot: take the proxy's lock while dumping errors BUG/MINOR: tools: fix set_net_port() / set_host
Re: [PATCH] REGTEST/MINOR: loadtest: add a test for connection counters
Hi Pieter, On Thu, Sep 20, 2018 at 12:48:35AM +0200, PiBa-NL wrote: > Test takes like 5 seconds to run here, and while that is a bit long if you > get a hundred more similar tests and want to continue tweaking developments > while running tests in between. It wouldn't hurt to run such a (series) of > longer tests before creating a patch and submitting it for inclusion on the > official git repository in my opinion, or before a release. Definitely, however those run before a release should be almost 100% system-agnostic. Having to prepare the system and tune it properly for the test not to fail is going to cause a headache every time there is a failure because it will mean fixing the root cause and re-run the whole suite, which precisely is what will make all this suite not to be used at all anymore. This is why I'm really picky on the reliability and the speed of these tests. It should be stupid-proof, with me being the stupid (and believe me when it comes to doing repetitive stuff, I'm among the stupidest persons you have ever met). > My attempt was > to test a bit differently than just looking for regressions of known fixed > bugs, and putting a little load on haproxy so that threads and simultaneous > actions 'might' get into conflicts/locks/stuff which might by chance, show > up, which is why i choose to go a little higher on the number of round-trips > with ever slightly increasing payload.. I really understand the point and I think it is valid to a certain extent. But that's really not a thing to run by default. And I want to encourage us (including me) to run reg tests from time to time. If you know that some of them will take too long, you'll quickly end up avoiding all the ones you can easily avoid using a single command (eg: playing with the LEVEL variable, or not running it at all). > For me the test produces like 345 lines of output as attached. which seems > not to bad (if the test succeeds). It's already far too much for a user. I should only know if it works or not, otherwise it hides the output of all other ones (which is what happened). We must not have to parse the output to know if we didn't break anything, we just have to check that it looks normal. Here's what make reg-tests gives me on 1.8 : willy@wtap:haproxy$ time sh make-reg-tests-1.8 #top TEST reg-tests/lua/b2.vtc passed (0.159) #top TEST reg-tests/lua/b1.vtc passed (0.122) #top TEST reg-tests/lua/b0.vtc passed (0.110) #top TEST reg-tests/lua/b3.vtc passed (0.137) #top TEST reg-tests/connection/b0.vtc passed (0.172) #top TEST reg-tests/server/b0.vtc passed (0.110) #top TEST reg-tests/spoe/b0.vtc passed (0.008) #top TEST reg-tests/ssl/b0.vtc passed (0.139) #top TEST reg-tests/stick-table/b1.vtc passed (0.110) #top TEST reg-tests/stick-table/b0.vtc passed (0.110) #top TEST reg-tests/log/b0.vtc passed (0.125) #top TEST reg-tests/seamless-reload/b0.vtc passed (0.123) real0m1.713s user0m0.316s sys 0m0.068s As you can see there's no output to parse, it *visually* looks correct. > Besides the 2 instances of cli output > for stats, its seems not that much different from other tests.. > And with 1.8.13 on FreeBSD (without qkueue) it succeeds: # top TEST > ./test/b0-loadtest.vtc passed (4.800 OK then you get a valid output there. It's here that it's ugly. But we spend enough time analysing bugs, I really refuse to spend extra time fixing bugs in tests supposed to help detect bugs, otherwise it becomes recursive... > Taking into account conntrack and ulimit, would that mean we can never > 'reg-test' if haproxy can really handle like 1 connections without > issue? 10k conns definitely is way beyond what you can expect from a non-root user on a regular shell. I run most of my configs with "maxconn 400" because that's less than 1024 FDs once you add the extra FDs for listeners and checks. Anything beyond that will depend on the users' setup and becomes tricky. And in this case it's more a matter of stress-testing the system, and we can have stress-test procedures or tools (just like we all do on our respective setups with different tools). It's just that one has to know in advance that some preparation is needed (typically killing a possible browser, unloading some modules, checking that there's still memory left, maybe adding some addresses to the loopback, etc). So it's a different approach and it definitely is out of the scope of automatizing detection of potential regressions during development. > Or should the environment be configured by the test?? ,that seems > very tricky at least and probably would be undesirable.. No definitely it would be even worse. For sure those used to run "curl | sudo bash" will have no problem letting it configure their system, but I'm not among such people and I appreciate a lot that my machine works every morning when I want to wo
RE: Excellent European & Asian languages translation(Chinese/Japanese/Thai/Korean/Vietnamese and more) CCJK
Dear partner, I hope you are having a wonderful day!! I apologize for the blunt nature of my email, but I sincerely hope you can find it helpful or worth saving for future reference.Please feel free to contact me if you do need a reliable partner for translation/localization. It's my great honor to introduce our company to you - CCJK is a professional translation company. We aim for Chinese (Simplified and Traditional), Japanese, Thai and Korean translation services! As an ISO certified company and a member of American Translators Association (ATA), we strictly follow the quality guidelines of ISO and ATA. If there is any possibility to get some translation jobs from your esteemed company? Looking forward to hearing from you soon!!! Best regards Melody Please get back to me at melody@ccjk.com if you are interested in our services, if not, please just let me know and i will remove your contact.
