Re: [ANNOUNCE] haproxy-1.8.14 - Security Update

2018-09-20 Thread Aleksandar Lazic
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: [PATCH] REGTEST/MINOR: loadtest: add a test for connection counters

2018-09-20 Thread PiBa-NL

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

2018-09-20 Thread 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.

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() / 

Re: [PATCH] REGTEST/MINOR: loadtest: add a test for connection counters

2018-09-20 Thread Willy Tarreau
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 

RE: Excellent European & Asian languages translation(Chinese/Japanese/Thai/Korean/Vietnamese and more) CCJK

2018-09-20 Thread melody
 

 

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.