fanout / condure Goto Github PK

I am having the above error while running fanout/pushpin docker image (latest version). The container fails at boot.

Here is the full stack trace:

docker-entrypoint.sh: unable to write to /usr/lib/pushpin/internal.conf, readonly
docker-entrypoint.sh: unable to write to /etc/pushpin/pushpin.conf, readonly
[INFO] 2023-05-17 12:19:37.594 starting...
[INFO] 2023-05-17 12:19:37.595 using config: /etc/pushpin/pushpin.conf
[INFO] 2023-05-17 12:19:37.601 [condure] [condure] starting...
[INFO] 2023-05-17 12:19:37.602 started
[INFO] 2023-05-17 12:19:37.604 [proxy] starting...
QThread::start: Thread creation error (Operation not permitted)
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 1, kind: PermissionDenied, message: "Operation not permitted" }', src/zhttpsocket.rs:707:14
stack backtrace:
   0:     0x5614b405ba2c - <unknown>
   1:     0x5614b407944e - <unknown>
   2:     0x5614b4045051 - <unknown>
   3:     0x5614b4047e15 - <unknown>
   4:     0x5614b4047ac9 - <unknown>
   5:     0x5614b404845f - <unknown>
   6:     0x5614b405bd67 - <unknown>
   7:     0x5614b405bb44 - <unknown>
   8:     0x5614b4047f72 - <unknown>
   9:     0x5614b3f09ac3 - <unknown>
  10:     0x5614b3f09ba3 - <unknown>
  11:     0x5614b3fc636a - <unknown>
  12:     0x5614b3fa66ba - <unknown>
  13:     0x5614b3f20039 - <unknown>
  14:     0x5614b3f13723 - <unknown>
  15:     0x5614b3f14ad3 - <unknown>
  16:     0x5614b3f14ff9 - <unknown>
[INFO] 2023-05-17 12:19:37.610 [handler] starting...
Operation not permitted (src/thread.cpp:269)
[ERR] 2023-05-17 12:19:37.754 condure: Exited unexpectedly
[ERR] 2023-05-17 12:19:37.754 handler: Exited uncleanly
[WARN] 2023-05-17 12:19:41.957 proxy taking too long, forcing quit
[INFO] 2023-05-17 12:19:41.959 stopped

Here is my Dockerfile:

FROM fanout/pushpin:1.36.0

ENV RUST_BACKTRACE=full

COPY ./routes.prod /etc/pushpin/routes

Thanks in advance for the help.

While working on updating the base64 crate in Debian I prepared a patch to make condure build with the new base64. There were a couple of changes in the API of base64.

1. Rather than passing a config to encode_config_slice one now has to call encode_slice on an engine.
2. encode_slice now returns a result instead of panicing on error.

Patch is at https://salsa.debian.org/rust-team/debcargo-conf/-/blob/7f22f126538a2c811d44d05e6e7f770417fd59ab/src/condure/debian/patches/base64-0.21.diff

After updating condure in Debian to 1.10, it failed to build on architectures where char in c is unsigned (e.g. arm*, powerpc*, s390x). The fix was pretty trivial, just replacing i8 with libc::c_char in a couple of pointer typecasts.

Patch is available at https://salsa.debian.org/rust-team/debcargo-conf/-/blob/171ebbf31695774186bd7d279031906c7f179082/src/condure/debian/patches/fix-build-unsigned-char.diff

I'm using Let's encrypt with pushpin on port 4430.

I've symlinked the certs to /etc/pushpin/runner/certs/default_4430.key and /etc/pushpin/runner/certs/default_4430.crt from /etc/letsencrypt/live/domain.xyz/fullchain.pem and /etc/letsencrypt/live/domain.xyz/privkey.pem and confirmed the files are symlinked.

But I get the error ERR_SSL_UNRECOGNIZED_NAME_ALERT in browser or tlsv1 unrecognized name in curl.
Tried to find information about condure, but none available.

I don't see any errors in either pushpin nor Condure logs.

Update: I've tried both with wildcard and without wildcard, result is the same.
Update2: Tried with just chain instead of fullchain, same result.

Hey, while scrolling through your code I noticed, that you provide your own WriteVectored trait, while the std Write does in fact provide write_buffered method
https://doc.rust-lang.org/std/io/trait.Write.html#method.write_vectored

This is just sharing the results of a discussion that occurred elsewhere for others to potentially view in the future. Also, we can track the final result of this issue here.

While using pushpin, which uses condure, I observed that pushpin was closing some connections due to error. The specific error message was this:
[DEBUG] 2022-04-11 08:19:38.945 [condure] [condure::connection] conn 0-2-76c: error: Http(ParseError(TooManyHeaders))

From this message, the error appears to be coming from a max header limit that is set in condure's code.

Here, the number of headers allowed in an HTTP request is limited to 32:

Here the number of headers in the HTTP response is also limited to 32:

I propose that we increase the limit. I believe 32 headers is relatively easy to reach because in my testing I found that Firefox on my computer was sending 16 headers by itself, and applications using CloudFlare (such as mine) will have a few more added by CloudFlare, and then finally custom headers added in nginx or other places will easily push it past 32.

I also had a couple other potential ideas, although, I do not know if these fit into the design of condure:

1. The arrays holding the headers are set to be exactly of size 32, but it may be worth converting the headers to a dynamically sized array so that any HTTP request is supported.
2. Maybe condure could allow users to pass in a configuration param that specifies the max number of headers and let users override a default of 32. This means only users who need the increase can increase it.

When the downstream client is connected over HTTP/2, Envoy sends upstream requests to Condure that are not fully compliant with RFC 6455. Specifically, Envoy sends Content-Length: 0 and does not send a Sec-WebSocket-Key, which causes Condure to (correctly) deny the request.

Clearly this is a problem with Envoy and not Condure, but I'm posting an issue here to document the incompatibility and provide a workaround for anyone who needs it. Here's a small patch that has solved the problem for me:

diff --git a/src/connection.rs b/src/connection.rs
index b98f513..c601537 100644
--- a/src/connection.rs
+++ b/src/connection.rs
@@ -2636,7 +2636,7 @@ where
         let req = handler.request(&mut scratch);
 
         let mut websocket = false;
-        let mut ws_key = None;
+        let mut ws_key: Option<&[u8]> = Some(&[]);
 
         for h in req.headers.iter() {
             if h.name.eq_ignore_ascii_case("Upgrade") {
@@ -2674,7 +2674,7 @@ where
         );
 
         let ws_accept: Option<ArrayString<[u8; WS_ACCEPT_MAX]>> = if websocket {
-            if req.method != "GET" || req.body_size != http1::BodySize::NoBody || ws_key.is_none() {
+            if req.method != "GET" {
                 return Err(ServerError::InvalidWebSocketRequest);
             }

As there's no plan to address this in Envoy, but it is popular and otherwise compatible with Condure, it would be nice to have a setting to enable this relaxed behavior in Condure. I don't think this would necessarily cause a security regression because Sec-WebSocket-Key is only used to prevent unintended requests, and that problem can be addressed by enabling CORS in Envoy.

Further background:

• envoyproxy/envoy#15464 (comment)
• envoyproxy/envoy#8547

% mypy --ignore-missing-imports --install-types --non-interactive .

examples/streamhandler.py:45: error: Incompatible types in assignment (expression has type "int", target has type "bytes")
examples/streamhandler.py:46: error: Incompatible types in assignment (expression has type "int", target has type "bytes")
examples/streamhandler.py:48: error: Incompatible types in assignment (expression has type "int", target has type "bytes")
examples/streamhandler.py:56: error: Incompatible types in assignment (expression has type "int", target has type "bytes")
examples/streamhandler.py:65: error: Incompatible types in assignment (expression has type "int", target has type "bytes")
examples/streamhandler.py:74: error: Incompatible types in assignment (expression has type "int", target has type "bytes")
examples/streamhandler.py:75: error: Incompatible types in assignment (expression has type "int", target has type "bytes")
examples/streamhandler.py:77: error: Incompatible types in assignment (expression has type "List[List[bytes]]", target has type "bytes")
examples/streamhandler.py:78: error: Incompatible types in assignment (expression has type "bool", target has type "bytes")
examples/streamhandler.py:79: error: Incompatible types in assignment (expression has type "int", target has type "bytes")
examples/streamhandler.py:87: error: Incompatible types in assignment (expression has type "int", target has type "bytes")
examples/sendresp.py:23: error: Incompatible types in assignment (expression has type "int", target has type "bytes")
examples/sendresp.py:25: error: Incompatible types in assignment (expression has type "List[List[bytes]]", target has type "bytes")
examples/basichandler.py:28: error: Incompatible types in assignment (expression has type "int", target has type "bytes")
examples/basichandler.py:30: error: Incompatible types in assignment (expression has type "List[List[bytes]]", target has type "bytes")
examples/holdhandler.py:75: error: Need type annotation for "conns" (hint: "conns: Dict[<type>, <type>] = ...")
Found 16 errors in 4 files (checked 6 source files)