naviserver-devel — Developer discussion

Re: [naviserver-devel] Problem with a Tcl extension and NaviServer

[Gustaf N. <ne...@wu...>]

Dear Mathew,

The answer for your this problem is probably in the call of 
blink1_openById(devid);

Without looking into this call, I would suspect first from my experience 
with NaviServer IoT projects a permission problem when accessing the 
hardware interface.
For security reasons, NaviServer switches to a nonprivileged user ...

all the best -g

On 25.06.24 16:18, Matthew Burke wrote:
> Hello!
>
> I am writing a Tcl extension in C to wrap a driver for a USB LED 
> status light. The extension runs fine from tclsh but there are issues 
> running it from a Tcl  page under NaviServer.
>
> The extension implements one command via Tcl_CreateObjCommand. The 
> command proc implements a number of sub-commands broken into two 
> categories: device-independent functionality, e.g. count the number of 
> status lights that are plugged in, and device-dependent functionality, 
> e.g. attach to a status light, display a particular color, etc
>
> The device-independent sub-commands work when run in a Tcl page. For 
> example, this page runs fine when served from NaviServer:
>
>
> package require blink
>
> set n [blink enumerate]
>
> ns_return 200 text/html "
> There are <strong>$n</strong> devices plugged in.
> "
>
>
> In order to have a device display a color, etc., you first have to run 
> the "open" command. And that's not working. So here's an example Tcl page:
>
>
> package require blink
>
> set d [blink open 0]
> set q [ns_conn query]
> set s [ns_parsequery $q]
>
> set red [ns_set get $s red 255]
> set green [ns_set get $s green 0]
> set blue [ns_set get $s blue 0]
>
> blink set $d $red $green $blue
>
> ns_return 200 text/html "
>     <p>Query: [ns_conn query]</p>
>
>     <ul>
>     <li>Red: $red</li>
>     <li>Green: $green</li>
>     <li>Blue: $blue</li>
>     </ul>
> "
>
>
> When this page is served, I get an error in the line: set d [blink 
> open 0].
>
> There is a C struct, Blinker,  that contains data about the attached 
> device. My C code first allocates
> memory for the struct
>
>
> blinkPtr = (Blinker *)Tcl_Alloc(sizeof(Blinker));
>
>
> and this seems to work -- blinkPtr is non-NULL after the assignment. 
> Then there is a function from the driver library that actually 
> attaches to the device:
>
> blinkPtr->device = blink1_openById(devid);
>
> It should return the memory address of an allocated structure that's 
> part of the USB library. But the function returns NULL. (Just to 
> reiterate, this works fine when run from tclsh and returns a non-NULL 
> value.)
>
> I'm assuming there is some sort of memory protection or similar that I 
> need to take into account. Any suggestions on what to look at would be 
> greatly appreciated.
>
> Thanks,
>
> Matt
>
> P.S. This is on macOS 14.3. I'm compiling the extension as follows:
>
> clang -dynamiclib -DUSE_TCL_STUBS -I/usr/local/ns/include 
> -L/usr/local/ns/lib -ltclstub8.6 -o blink.dylib blink.c 
> -L/usr/local/lib -lBlink1
>
>
>
>
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel

[naviserver-devel] Problem with a Tcl extension and NaviServer

[Matthew B. <mm...@gm...>]

Hello!

I am writing a Tcl extension in C to wrap a driver for a USB LED status
light. The extension runs fine from tclsh but there are issues running it
from a Tcl  page under NaviServer.

The extension implements one command via Tcl_CreateObjCommand. The command
proc implements a number of sub-commands broken into two categories:
device-independent functionality, e.g. count the number of status lights
that are plugged in, and device-dependent functionality, e.g. attach to a
status light, display a particular color, etc

The device-independent sub-commands work when run in a Tcl page. For
example, this page runs fine when served from NaviServer:


package require blink

set n [blink enumerate]

ns_return 200 text/html "
There are <strong>$n</strong> devices plugged in.
"


In order to have a device display a color, etc., you first have to run the
"open" command. And that's not working. So here's an example Tcl page:


package require blink

set d [blink open 0]
set q [ns_conn query]
set s [ns_parsequery $q]

set red [ns_set get $s red 255]
set green [ns_set get $s green 0]
set blue [ns_set get $s blue 0]

blink set $d $red $green $blue

ns_return 200 text/html "
    <p>Query: [ns_conn query]</p>

    <ul>
    <li>Red: $red</li>
    <li>Green: $green</li>
    <li>Blue: $blue</li>
    </ul>
"


When this page is served, I get an error in the line: set d [blink open 0].

There is a C struct, Blinker,  that contains data about the attached
device. My C code first allocates
memory for the struct


blinkPtr = (Blinker *)Tcl_Alloc(sizeof(Blinker));


and this seems to work -- blinkPtr is non-NULL after the assignment. Then
there is a function from the driver library that actually attaches to the
device:

blinkPtr->device = blink1_openById(devid);

It should return the memory address of an allocated structure that's part
of the USB library. But the function returns NULL. (Just to reiterate, this
works fine when run from tclsh and returns a non-NULL value.)

I'm assuming there is some sort of memory protection or similar that I need
to take into account. Any suggestions on what to look at would be greatly
appreciated.

Thanks,

Matt

P.S. This is on macOS 14.3. I'm compiling the extension as follows:

clang -dynamiclib -DUSE_TCL_STUBS -I/usr/local/ns/include
-L/usr/local/ns/lib -ltclstub8.6 -o blink.dylib blink.c -L/usr/local/lib
-lBlink1

[naviserver-devel] Improvement for file uploads

[Gustaf N. <ne...@wu...>]

Dear all, I've committed the following change to the GitHub repository 
of NaviServer, that adds significant improvements for FORM uploads of 
large files. It makes it now possible to handle files uploads via 
multipart/form-data (usual format) larger than 4GB without crashing. The 
support is just for NaviServer, applications (e.g. OpenACS) might still 
try to read such large files into Tcl_Objs leading to crashes with Tcl 
8. Although, loading huge data into memory is not a good practice and 
leads to memory bloats. However, this should work with Tcl9.
The code replaces an implementation that has not changed for the last 17 
years.
I am planing to backport this change also to the 4.99 branch.
All the best
-g


Added experimental command "ns_fseekchars" and use it in form.tcl for parsing multipart/form-data

As a consequence,
(a) the file-based parser of multipart/form-data is able to read files >4GB,
(b) leads to less memory bloat and
(c) is more than a factor of 10 faster

        file size        old  ns_fseekchars  factor
           65,517       4,471           151   29.61
          124,523       1,139            94   12.12
       74,006,378     682,375        54,752   12.46
    2,104,408,064  18,916,496     1,564,472   12.09
    3,992,977,408  35,942,768     3,061,061   11.74
    5,368,709,120                 3,817,896	

The problem with the old file-based parser was that it was searching for boundary
strings using the Tcl "gets" command:

		if { [string match $boundary* [string trim [gets $fp]]] } {
                 ...
                 }

Since "gets" reads a line (i.e., all character until the next new
line) Tcl can crash, when the next new line is more than 4GB
away. Even with e.g. 2GB, it will temporarily create a Tcl_Obj with
2GB content, which is stripped etc. leading therefore to a potential
memory bloat keeping multiple huge Tcl_Objs in memory.

The new code avoids all this by performing the search for the boundary
in C.

TODO: add documentation page

[naviserver-devel] supporting relative redirects in NaviServer

[Gustaf N. (sslmail) <ne...@wu...>]

Dear all,

RFC 2616 requires an absolute URI in the "Location" header field. So if someone calls "ns_returnredirect /", NaviServer transforms it on the fly into an absolute URL by prefixing it with the location (e.g. https://openacs.org/). NaviServer (and OpenACS) has some complex code to compute the location value, especially when virtual servers are involved (or for "host-node mapped" subsites in OpenACS). The situation is further complicated when running behind a reverse proxy and/or in a containerized environment. In such cases, the location is computed from the "host" request header field, which must be validated, otherwise an attacker could hijack a session and redirect it to a spoofed site. 

The situation changed 10 years ago (June 2014) with the introduction of RFC 7231, which allows relative redirects (see https://www.rfc-editor.org/rfc/rfc7231#section-7.1.2). Using relative redirects greatly simplifies configuration and closes the attack vector using the host header field. RFC 7231 has been superseded by RFC 9110 (June 2022), which also supports relative redirects via the "location" response header field (see https://www.rfc-editor.org/rfc/rfc9110#field.location).

The latest version of NaviServer (already running on OpenACS.org) now implements relative redirects as supported by the newer RFCs. Only if a location proc has been registered "ns_locationproc", the URL will be prefixed with it for better backwards compatibility.

The change to support relative redirects should simplify many configurations. There have been many questions about redirects where people have struggled to set them up. I've only added this change to the main branch of NaviServer. I have no intention of backporting it to the 4.99 series at this time.

If you have any objections or suggestions, please let me know.

Re: [naviserver-devel] Order of URL processing

[Gustaf N. (sslmail) <ne...@wu...>]

There are multiple processing steps involved in your example. One thing is how to use the URLspace mappings (responsible for all kinds of requests, but not only), where the URL ordering plays a rule, and the another thing are request filters, which are fully independent of the URLspace.

Given the lifecycle of requests, the resolving of the requests happens in the step “process request” below:


Once a connection thread is selected, the server runs filters (pre-auth and post-auth) and then it runs the request procs.  




There might be multiple of these filters, where the registration order is relevant. A filter might decide to continue to the next filter or send a reply to the client. This is singled via the result of the filter procs. A filter should return one of the three values “filter_ok”, “filter_break” or “filter_return” (for details, check the man page of ns_register)

https://naviserver.sourceforge.io/n/naviserver/files/ns_register.html#3

In your case, the reverse proxy is registered via a match-all post-auth filter (/*) ending with a “filter-return” which has the consequence no request-proc (such as fastpath) will be involved. So registering additional request procs won’t make a difference.

In your example, one could either register an additional filter at the beginning of the filter change that lets the static requests through (ending with filter_break),, or one could consider moving the handling of the reverse proxy to the URLspace, by registering the handlers via ns_register_proc instead of using ns_register_filter.

Hope this explains,

all the best
-g

> On 02.05.2024, at 16:33, Georg Lehner <jor...@ma...> wrote:
> I am trying to configure Naviserver as reverse proxy for a Django project.
> 
> Django features deployment of static assests like css, js etc. into a separate URL, typically /static,  which can then be served directly by the webserver.  Everything else has to be reverse-proxied to the wsgi server which serves the Django app via http.
> 
> My revproxy setup is:
> 
> ns_section ns/server/default {
>     ns_param enabletclpages     false
>     ns_param minthreads         10
> }
> ns_section ns/server/default/fastpath {
>     ns_param pagedir            www
>     ns_param serverdir          $serverroot/default
>     ns_param directoryproc      ns_returnnotfound
>     ns_param directoryfile      index.html
> }
> ns_section ns/server/default/modules {
>     ns_param revproxy           tcl
>     ns_param nssock             nssock
> }
> ns_section ns/server/default/module/revproxy {
>     ns_param filters {
>         ns_register_filter postauth GET  /* ::revproxy::upstream -target http://localhost:65193 <http://localhost:65193/>
>         ns_register_filter postauth POST /* ::revproxy::upstream -target http://localhost:65193 <http://localhost:65193/>
>     }
> }
> ns_section ns/server/default/module/nssock {
>     ns_param port               0
> }
> I have made several attempts to register the /static/* URL to be handled by fastpath and map it to a directory have failed. The server always sends the requests to the revproxy backend.
> Is it possible to "override" this, and if yes then how?
> 
> Best Regards,
> 
>   Georg
> 

[naviserver-devel] Order of URL processing

[Georg L. <jor...@ma...>]

Hello,

I am trying to configure Naviserver as reverse proxy for a Django project.

Django features deployment of static assests like css, js etc. into a 
separate URL, typically /static,  which can then be served directly by 
the webserver.  Everything else has to be reverse-proxied to the wsgi 
server which serves the Django app via http.

My revproxy setup is:

ns_section ns/server/default {
     ns_param enabletclpages     false
     ns_param minthreads         10
}
ns_section ns/server/default/fastpath {
     ns_param pagedir            www
     ns_param serverdir          $serverroot/default
     ns_param directoryproc      ns_returnnotfound
     ns_param directoryfile      index.html
}
ns_section ns/server/default/modules {
     ns_param revproxy           tcl
     ns_param nssock             nssock
}
ns_section ns/server/default/module/revproxy {
     ns_param filters {
         ns_register_filter postauth GET  /* ::revproxy::upstream -targethttp://localhost:65193
         ns_register_filter postauth POST /* ::revproxy::upstream -targethttp://localhost:65193
     }
}
ns_section ns/server/default/module/nssock {
     ns_param port               0
}

I have made several attempts to register the /static/* URL to be handled 
by fastpath and map it to a directory have failed. The server always 
sends the requests to the revproxy backend.

Is it possible to "override" this, and if yes then how?

Best Regards,

   Georg

Re: [naviserver-devel] reverseproxymode with multiple X-Forwarded-For values

[David O. <da...@qc...>]

Thanks again Gustaf.
I've been running some tests and it's looking good.

There's one case I'm not sure this can cater for, and this is probably more
of an issue in development environments...
When the trusted cidr is a subnet which also contains the client.

Say
ns_section ns/parameters/reverseproxymode {
        ns_param enabled        on
        ns_param trustedservers {192.168.0.0/16}
        ns_param skipnonpublic  false
}
And Client IP = 192.168.0.10 with a proxy on 192.168.0.200

I think NaviServer will skip all addresses which appear in the trusted
subnet:

Do you think it would be appropriate to have this behaviour as configurable?

Option 1. Strict.
If the header is from a peer on the trusted list - return only the entry
our trusted peer added (regardless of whether that entry is, in turn, also
in the trusted subnet).
ff {192.168.0.11,192.168.0.10} key 0-1 peer 192.168.0.200 forwarded
{192.168.0.10}

Option 2. Greedy.
If the header is from a peer on the trusted list - return the first
untrusted entry searching from the right
ff {192.168.0.11,192.168.0.10} key 0-1 peer 192.168.0.200 forwarded {}

(I think this is why Nginx introduced the "real_ip_recursive" option on
their real_ip module for instance.)
https://nginx.org/en/docs/http/ngx_http_realip_module.html

Re: [naviserver-devel] refproxy module/ns_connchan: no driver for protocol 'https' found

[Georg L. <jor...@ma...>]

On 2024-05-01 13:56, Gustaf Neumann (sslmail) wrote:
>
>
>> On 30.04.2024, at 20:53, Georg Lehner <jor...@ma...> wrote:
>>
>> Hello,
>>
>> I am trying to set up the revproxy module on a current naviserver git 
>> checkout.
>>
>> Upon connection to the frontend I get:
>>
>>     Request Error
>>     Error during opening connection to backend
>>     http://localhost:65193/ failed.
>>     Error message: no driver for protocol 'http' found
>>
>>     NaviServer/5.0.0a
>>
>
> Probably, you have no nssock module installed. ns_sock uses the 
> network drivers installed, and in case, your configuration network 
> does not include it, it is not available. If you want to use a driver 
> module, but you do not want to listen on a port, configure the port 
> with the value 0
> ...

Thank you, this worked out. In fact I had only configured nsssl on this 
server.

Best Regards,

   Georg

-- 

MagmaSoft e.U. (FN 601643w)
Inhaber: Ing. Georg Lehner
Kolpingstraße 15, A-4020 Linz
https://magma-soft.at/
mailto:jo...@ma...

Re: [naviserver-devel] refproxy module/ns_connchan: no driver for protocol 'https' found

[Gustaf N. (sslmail) <ne...@wu...>]

> On 30.04.2024, at 20:53, Georg Lehner <jor...@ma...> wrote:
> 
> Hello,
> 
> I am trying to set up the revproxy module on a current naviserver git checkout.
> 
> Upon connection to the frontend I get:
> 
> Request Error
> Error during opening connection to backend http://localhost:65193/ failed.
> Error message: no driver for protocol 'http' found
> 
> NaviServer/5.0.0a
> 

Probably, you have no nssock module installed. ns_sock uses the network drivers installed, and in case, your configuration network does not include it, it is not available. If you want to use a driver module, but you do not want to listen on a port, configure the port with the value 0

> The same message I get when starting 'nsd -c' and running either of
> 
>     ns_connchan open http://example.com <http://example.com/> -> no driver for protocol 'http' found
> 
>     ns_connchan open https://example.com <https://example.com/> -> no driver for protocol 'https' found
> 
Same as above. When “nsd -c” is called, no network drivers are loaded

-g

[naviserver-devel] refproxy module/ns_connchan: no driver for protocol 'https' found

[Georg L. <jor...@ma...>]

Hello,

I am trying to set up the revproxy module on a current naviserver git 
checkout.

Upon connection to the frontend I get:

    Request Error
    Error during opening connection to backend http://localhost:65193/
    failed.
    Error message: no driver for protocol 'http' found

    NaviServer/5.0.0a

The same message I get when starting 'nsd -c' and running either of

     ns_connchan open http://example.com -> no driver for protocol 
'http' found

     ns_connchan open https://example.com -> no driver for protocol 
'https' found

I'm puzzled, because some months ago I tested revproxy successfully.

Can you give me hints on how to get going?

Best Regards,

   Georg

Re: [naviserver-devel] reverseproxymode with multiple X-Forwarded-For values

[Gustaf N. (sslmail) <ne...@wu...>]

Dear David & all,

i’ve committed now a version to the main branch of NaviServer on GitHub.
In addition of my last writeup, i’ve further increased the configurability to make ignoring of non-public servers configurable, no matter whether trusted severs are configured or not. To ease configuration, there is now an own section (instead of use ever-growing variable names).


OLD:
    ns_section ns/parameters {
       ...
       ns_param reverseproxymode true
       ...
    }

NEW:
    ns_section ns/parameters/reverseproxymode {
        ns_param enabled        on
        ns_param trustedservers {192.168.0.0/16 137.208.89.213}
        ns_param skipnonpublic  true
    }

The detailed commit message is 
https://github.com/naviserver-project/naviserver/commit/ab23158ece6fcbec4f740a41140592c910de64f3
"x-forwarded-for" reform (part 1) · naviserver-project/naviserver@ab23158
github.com


below are the test-cases, where the key $X-$Y 
- X: stands for skipnonpublic, and
- Y: stands for trustedservers configured (and trusted servers are "192.168.0.0/16 127.0.0.1”)

documentation updates will follow.

all the best
-g



    # just one XFF entry non-trusted (must be client)
    lappend cases {ff {1.1.1.1} key 0-0 peer 1.1.1.1 forwarded 1.1.1.1}
    lappend cases {ff {1.1.1.1} key 0-1 peer 1.1.1.1 forwarded 1.1.1.1}
    lappend cases {ff {1.1.1.1} key 1-0 peer 1.1.1.1 forwarded 1.1.1.1}
    lappend cases {ff {1.1.1.1} key 1-1 peer 1.1.1.1 forwarded 1.1.1.1}

    # just one entry trusted (i.e. must be proxy server)
    lappend cases {ff {192.168.1.10} key 0-0 peer 192.168.1.10 forwarded 192.168.1.10}
    lappend cases {ff {192.168.1.10} key 0-1 peer 127.0.0.1 forwarded {}}
    lappend cases {ff {192.168.1.10} key 1-0 peer 127.0.0.1 forwarded {}}
    lappend cases {ff {192.168.1.10} key 1-1 peer 127.0.0.1 forwarded {}}

    # just one entry local
    lappend cases {ff {127.0.0.3} key 0-0 peer 127.0.0.3 forwarded 127.0.0.3}
    lappend cases {ff {127.0.0.3} key 0-1 peer 127.0.0.3 forwarded 127.0.0.3}
    lappend cases {ff {127.0.0.3} key 1-0 peer 127.0.0.1 forwarded {}}    
    lappend cases {ff {127.0.0.3} key 1-1 peer 127.0.0.1 forwarded {}}

    # two entries, both untrusted
    lappend cases {ff {1.1.1.1, 2.2.2.2} key 0-0 peer 1.1.1.1 forwarded 1.1.1.1}
    lappend cases {ff {1.1.1.1, 2.2.2.2} key 0-1 peer 2.2.2.2 forwarded 2.2.2.2}
    lappend cases {ff {1.1.1.1, 2.2.2.2} key 1-0 peer 1.1.1.1 forwarded 1.1.1.1}
    lappend cases {ff {1.1.1.1, 2.2.2.2} key 1-1 peer 2.2.2.2 forwarded 2.2.2.2}

    # two entries, second trusted
    lappend cases {ff {1.1.1.1, 192.168.1.10} key 0-0 peer 1.1.1.1 forwarded 1.1.1.1}
    lappend cases {ff {1.1.1.1, 192.168.1.10} key 0-1 peer 1.1.1.1 forwarded 1.1.1.1}
    lappend cases {ff {1.1.1.1, 192.168.1.10} key 1-0 peer 1.1.1.1 forwarded 1.1.1.1}
    lappend cases {ff {1.1.1.1, 192.168.1.10} key 1-1 peer 1.1.1.1 forwarded 1.1.1.1}

    # two entries, both trusted
    lappend cases {ff {192.168.1.11, 192.168.1.10} key 0-0 peer 192.168.1.11 forwarded 192.168.1.11}
    lappend cases {ff {192.168.1.11, 192.168.1.10} key 0-1 peer 127.0.0.1 forwarded {}}
    lappend cases {ff {192.168.1.11, 192.168.1.10} key 1-0 peer 127.0.0.1 forwarded {}}
    lappend cases {ff {192.168.1.11, 192.168.1.10} key 1-1 peer 127.0.0.1 forwarded {}}

    # two entries, both local
    lappend cases {ff {127.0.0.2, 127.0.0.3} key 0-0 peer 127.0.0.2 forwarded 127.0.0.2}
    lappend cases {ff {127.0.0.2, 127.0.0.3} key 0-1 peer 127.0.0.3 forwarded 127.0.0.3}
    lappend cases {ff {127.0.0.2, 127.0.0.3} key 1-0 peer 127.0.0.1 forwarded {}}
    lappend cases {ff {127.0.0.2, 127.0.0.3} key 1-1 peer 127.0.0.1 forwarded {}}

    # empty entry
    lappend cases {ff {} key 0-0 peer 127.0.0.1 forwarded {}}
    lappend cases {ff {} key 0-1 peer 127.0.0.1 forwarded {}}
    lappend cases {ff {} key 1-0 peer 127.0.0.1 forwarded {}}
    lappend cases {ff {} key 1-1 peer 127.0.0.1 forwarded {}}

    # wrong entry
    lappend cases {ff {x} key 0-0 peer 127.0.0.1 forwarded {}}
    lappend cases {ff {x} key 0-1 peer 127.0.0.1 forwarded {}}
    lappend cases {ff {x} key 1-0 peer 127.0.0.1 forwarded {}}
    lappend cases {ff {x} key 1-1 peer 127.0.0.1 forwarded {}}

    # wrong entry on the right
    lappend cases {ff {137.208.116.31, x} key 0-0 peer 137.208.116.31 forwarded 137.208.116.31}
    lappend cases {ff {137.208.116.31, x} key 0-1 peer 127.0.0.1 forwarded {}}
    lappend cases {ff {137.208.116.31, x} key 1-0 peer 137.208.116.31 forwarded 137.208.116.31}
    lappend cases {ff {137.208.116.31, x} key 1-1 peer 127.0.0.1 forwarded {}}

    # wrong entry on the left
    lappend cases {ff {y, 137.208.116.31} key 0-0 peer 127.0.0.1 forwarded {}}
    lappend cases {ff {y, 137.208.116.31} key 0-1 peer 137.208.116.31 forwarded 137.208.116.31}
    lappend cases {ff {y, 137.208.116.31} key 1-0 peer 127.0.0.1 forwarded {}}
    lappend cases {ff {y, 137.208.116.31} key 1-1 peer 137.208.116.31 forwarded 137.208.116.31}



> On 29.04.2024, at 10:47, David Osborne <da...@qc...> wrote:
> 
> Hi Gustaf,
> 
> From your description it sounds like we could certainly work round our issue using the ReverseProxyTrustedServers config.
> Thank you very much for your time on this.
> 
> On Fri, 26 Apr 2024 at 14:09, Gustaf Neumann (sslmail) <ne...@wu... <mailto:ne...@wu...>> wrote:
>> Hi David,
>> 
>> I have now implemented the following (but not yet committed,
>> since i was side-tracked by some tcl9 issues and i am running out of
>> time.
>> 
>> From my understanding, this should address your problems now, 
>> and when “proxy 2” is removed.
>> 
>> An easy extension of this would be to let the site-admin configure
>> an alternative header field (like x-real-ip), which could bypass
>> the search through the list of candidate addresses.
>> 
>> all the best
>> -gn
>> 
> 
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel

Re: [naviserver-devel] reverseproxymode with multiple X-Forwarded-For values

[David O. <da...@qc...>]

Hi Gustaf,

>From your description it sounds like we could certainly work round our
issue using the ReverseProxyTrustedServers config.
Thank you very much for your time on this.

On Fri, 26 Apr 2024 at 14:09, Gustaf Neumann (sslmail) <ne...@wu...>
wrote:

> Hi David,
>
> I have now implemented the following (but not yet committed,
> since i was side-tracked by some tcl9 issues and i am running out of
> time.
>
> From my understanding, this should address your problems now,
> and when “proxy 2” is removed.
>
> An easy extension of this would be to let the site-admin configure
> an alternative header field (like x-real-ip), which could bypass
> the search through the list of candidate addresses.
>
> all the best
> -gn
>
>

Re: [naviserver-devel] reverseproxymode with multiple X-Forwarded-For values

[Gustaf N. (sslmail) <ne...@wu...>]

Hi David,

I have now implemented the following (but not yet committed,
since i was side-tracked by some tcl9 issues and i am running out of
time.

From my understanding, this should address your problems now, 
and when “proxy 2” is removed.

An easy extension of this would be to let the site-admin configure
an alternative header field (like x-real-ip), which could bypass
the search through the list of candidate addresses.

all the best
-gn

=========================================================

Traditionally, NaviServer has implemented x-forwarded-for handling in
the simplest way, by treating the first value in the x-forwarded-for
header as the client (see also [1] for a brief description). This
works well for the most part in many production environments.

There are two potential problems with this:

a) If the client is connecting from a private network through
   potentially multiple proxy servers, the private address
   (e.g. 192.168.1.100) may end up as the peer (and also e.g. in the
   access.log), which is not useful for any kind of analysis.

b) If the client itself sends a (faked) "X-Forwarded-For" header, it
   can privide whatever it wants as header value.

One measure is for a reverse proxy to only accept X-Forwarded-For
headers from trusted sources, or to always treat its peer as a client
(providing the peer address in the header field).

This can lead to some loss of information if there are multiple proxy
servers in the chain, and sometimes, it is not possible for an
application to influence the proxy server configuration.

The new version now has two modes, the first being an extension of the
classic mode, and the second being better for untrusted header
content.

The default mode processes the address list from left to right,
skipping private addresses.  If the received "x-forwarded-for header
contains, for example, "192.168.1.100 1.1.1.1 2.2.2.2", then "1.1.1.1"
will be used as the client IP address.

Alternatively, when the NaviServer site admin configures trusted
reverse proxy servers in the configuration file (either by IP address
or in CDIR notation)

    ReverseProxyTrustedServers {192.168.0.0/16 137.208.89.213}

then the "x-forwarded-for" header will only be accepted from trusted
servers (otherwise the header will be ignored). In addition, the
address list is processed from right to left, skipping known trusted
reverse proxies. This reduces the problem of spoofed addresses. In the
address list "142.251.208.110 1.1.1.1 192.168.2.10", the trusted
reverse proxy "192.168.2.10" is skipped and "1.1.1.1" is used (instead
of the spoofed Google IP).

Note: Only when NaviServer receives multiple entries in the
"x-forwarded-for" header is there a difference between these two
modes.

[1] https://en.wikipedia.org/wiki/X-Forwarded-For

Re: [naviserver-devel] FreeBSD 14 - TCL 9.0 - NaviServer GIT Latest - error: incompatible function pointer - log.c

[Not S. <un...@cr...>]

Many thanks Gustaf for creating the patch, I can confirm this works.
I also saw the fix has been applied to TCL core too.

Regards,
David F


-----Original Message-----
From: Gustaf <ne...@wu...>
To: naviserver-devel <nav...@li...>
Date: Monday, 22 April 2024 6:08 PM GMT
Subject: Re: [naviserver-devel] FreeBSD 14 - TCL 9.0 - NaviServer GIT Latest - error: incompatible function pointer - log.c


Dear David,

I installed freebsd14 and could reproduce the issue. The issue is that Tcl_PanicProc is defined in Tcl9 with the attribute declaration TCL_NORETURN1, but it seems, this attribute definition has to be provided as well for the  prototype. It would be certainly better, if this attribute definition would be part of the type declaration of Tcl_PanicProc in Tcl9. Not very long ago, the same code worked fine, so something has changed in Tcl9.

The patch below addresses this issue, but this is not nice. Maybe, the tcl-core people have a suggestion, since this will effect as well other applications requiring the use of Tcl_SetPanicProc().

Please update your checkout of NaviServer from git, since i have fixed one more small issues unrelated to this.

all the best
-g


--- a/nsd/log.c
+++ b/nsd/log.c
@@ -96,7 +96,11 @@ static void LogEntriesFree(void *arg);
  */
 
 static Ns_TlsCleanup FreeCache;
-static Tcl_PanicProc Panic;
+static
+#ifndef NS_TCL_PRE9
+ TCL_NORETURN1
+#endif
+ Tcl_PanicProc Panic;
 
 static Ns_LogFilter LogToFile;
 static Ns_LogFilter LogToTcl;




> On 21.04.2024, at 16:18, Not Spam <un...@cr...> wrote:
> 
> Good afternoon,
> I'm currently rebuilding my machine and I am having some issues with NaviServer (4.99-main #defd765) compiling on FreeBSD 14, with TCL 9.0b2 or TCL 9.0b1
>  
> TCL 9.0b1
> ===
> cc  -O2 -Wall -fPIC  -pipe -finput-charset=UTF-8  -DNDEBUG -DSYSTEM_MALLOC -std=c99 -I../include -I"/usr/local/include"   -DHAVE_CONFIG_H   -c -o log.o log.c
> log.c:262:22: error: incompatible function pointer types passing 'Tcl_PanicProc' (aka 'void (const char *, ...)') to parameter of type 'void (*)(const char *, ...) __attribute__((noreturn))' [-Wincompatible-function-pointer-types]
>     Tcl_SetPanicProc(Panic);
>                      ^~~~~
> /usr/local/include/tcl.h:2366:37: note: passing argument to parameter 'panicProc' here
>                             TCL_NORETURN1 Tcl_PanicProc *panicProc);
>                                                                                      ^
>  
> TCL 9.0b2
> ===
> cc  -O2 -Wall -fPIC  -pipe -finput-charset=UTF-8  -DNDEBUG -DSYSTEM_MALLOC -std=c99 -I../include -I"/usr/local/include"   -DHAVE_CONFIG_H   -c -o log.o log.c
> log.c:262:22: error: incompatible function pointer types passing 'Tcl_PanicProc' (aka 'void (const char *, ...)') to parameter of type 'void (*)(const char *, ...) __attribute__((noreturn))' [-Wincompatible-function-pointer-types]
>     Tcl_SetPanicProc(Panic);
>                      ^~~~~
> /usr/local/include/tcl.h:2366:37: note: passing argument to parameter 'panicProc' here
>                             TCL_NORETURN1 Tcl_PanicProc *panicProc);
>                                                                                      ^
> 1 error generated.
>  
> I'm using the latest GIT repo version.
> Any advice would be nice, I wish to use the ZIPFS that TCL9 brings.
>  
> Regards,
> David F
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel

_______________________________________________
naviserver-devel mailing list
nav...@li...
https://lists.sourceforge.net/lists/listinfo/naviserver-devel

Re: [naviserver-devel] reverseproxymode with multiple X-Forwarded-For values

[David O. <da...@qc...>]

On Wed, 24 Apr 2024 at 18:53, Gustaf Neumann (sslmail) <ne...@wu...>
wrote:

> This is the case where proxy 1 should not accept the x-forwarded-for
> header from an untrusted upstream server. In case, proxy1 is a nginx
> server, it should use
> proxy_set_header X-Forwarded-For $remote_addr;
> for untrusted upstream requests. Therefore, proxy 2 will receive
> x-forwarded-for with 1.1.1.1, 2.2.2.2 etc. and everything is fine.


Agreed - however without a formal standard for X-Forwarded-For, proxies
don't always provide this level of control. In our case, to preserve the
client IP, appending to any existing X-Forwarded-For is the only option
offered. (I have raised this with the suppliers of "proxy1"). I'm not sure
that this is actually wrong behaviour - but definitely unhelpful - yes!


> However, without the massaging in proxy2, you would end up with
>
>     X-Forwarded-For: 1.2.3.4,1.1.1.1,2.2.2.2
>
> where the rightmost address is as well incorrect. So, even by the search
> from the right, one should skip the known proxy servers from the list (here
> 2.2.2.2).  Also, one should aim for a configuration that works also, when
> one more different proxy is added.
>

Yes exactly. When the X-Forwarded-For header is just passed downstream
while appending peer addresses, the backend server must have knowledge of
its networking "situation" to make a judgement.
Possibly a list of the IPs of trusted proxies ("from right-to-left, use the
first IP which isn't a trusted proxy")

set reverseproxytrust [list 2.2.2.2/32 3.3.3.3/32]

Or, the backend would need knowledge of HOW MANY trusted proxies are
upstream. ("from right-to-left, use $count-1 on the list")

set reverseproxytrustedcount 2

This feels brittle though and does not take into account multiple routes
into the backend.

As I mentioned, we *can* write a wrapper to [ns_conn peeraddr -source
forwarded] which would return the value we want by inspecting the headers.
However this would still leave the access log logging the wrong IP - can
this be controlled via config?


> Does your proxy1 set something like the x-real-ip header?
>
>
It does not - I've raised the question with the developers.

Re: [naviserver-devel] reverseproxymode with multiple X-Forwarded-For values

[Gustaf N. (sslmail) <ne...@wu...>]

> On 23.04.2024, at 18:07, David Osborne <da...@qc...> wrote:
> 
> But the Client can initiate requests which have X-Forwarded-For Headers already present, then we run into difficulties
> 
> Client: IP 1.1.1.1 : sends X-Forwarded-For: 1.2.3.4
> |
> Proxy 1: sends X-Forwarded-For: 1.2.3.4,1.1.1.1
> Proxy 2: sends X-Forwarded-For: 1.2.3.4,1.1.1.1,2.2.2.2
> Naviserver: peeraddr -source forwarded = 1.2.3.4

This is the case where proxy 1 should not accept the x-forwarded-for header from an untrusted upstream server. In case, proxy1 is a nginx server, it should use  
      proxy_set_header X-Forwarded-For $remote_addr;
for untrusted upstream requests. Therefore, proxy 2 will receive x-forwarded-for with 1.1.1.1, 2.2.2.2 etc. and everything is fine.

> 
> We have got around this by using proxy2 to clobber the X-Forwared-For header using the Nginx real_ip module which has the logic that it will use the rightmost IP if from a trusted peer.
> 
> Client: IP 1.1.1.1 : sends X-Forwarded-For: 1.2.3.4
> |
> Proxy 1: sends X-Forwarded-For: 1.2.3.4,1.1.1.1
> Proxy 2: sends X-Forwarded-For: 1.1.1.1 (as calculated by real_ip  <https://nginx.org/en/docs/http/ngx_http_realip_module.html>logic - we trust proxy1, so use the most recent IP - the rightmost)
> |
> Naviserver: peeraddr -source forwarded = 1.1.1.1

by this “trick” one can skip in your configuration the “untrusted”  X-Forwarded-For: 1.2.3.4

However, without the massaging in proxy2, you would end up with 

    X-Forwarded-For: 1.2.3.4,1.1.1.1,2.2.2.2

where the rightmost address is as well incorrect. So, even by the search from the right, one should skip the known proxy servers from the list (here 2.2.2.2).  Also, one should aim for a configuration that works also, when one more different proxy is added. 

> However, we are looking into dropping proxy2. Unfortunately proxy1 does not have the flexibility to manipulate headers in such a way

Does your proxy1 set something like the x-real-ip header?

-g

Re: [naviserver-devel] reverseproxymode with multiple X-Forwarded-For values

[David O. <da...@qc...>]

Thanks,

The situation we were looking at is where NaviServer is behind 2 proxies.

Client: IP 1.1.1.1
|
Proxy 1: sends X-Forwarded-For: 1.1.1.1
|
Proxy 2: sends X-Forwarded-For: 1.1.1.1,2.2.2.2
|
Naviserver: peeraddr -source forwarded = 1.1.1.1

Which is fine.

But the Client can initiate requests which have X-Forwarded-For Headers
already present, then we run into difficulties

Client: IP 1.1.1.1 : sends X-Forwarded-For: 1.2.3.4
|
Proxy 1: sends X-Forwarded-For: 1.2.3.4,1.1.1.1
|
Proxy 2: sends X-Forwarded-For: 1.2.3.4,1.1.1.1,2.2.2.2
|
Naviserver: peeraddr -source forwarded = 1.2.3.4

We have got around this by using proxy2 to clobber the X-Forwared-For
header using the Nginx real_ip module which has the logic that it will use
the rightmost IP if from a trusted peer.

Client: IP 1.1.1.1 : sends X-Forwarded-For: 1.2.3.4
|
Proxy 1: sends X-Forwarded-For: 1.2.3.4,1.1.1.1
|
Proxy 2: sends X-Forwarded-For: 1.1.1.1 (as calculated by real_ip
<https://nginx.org/en/docs/http/ngx_http_realip_module.html>logic - we
trust proxy1, so use the most recent IP - the rightmost)
|
Naviserver: peeraddr -source forwarded = 1.1.1.1

However, we are looking into dropping proxy2. Unfortunately proxy1 does not
have the flexibility to manipulate headers in such a way so we are back to:

Client: IP 1.1.1.1 : sends X-Forwarded-For: 1.2.3.4
|
Proxy 1: sends X-Forwarded-For: 1.2.3.4,1.1.1.1
|
Naviserver: peeraddr -source forwarded = 1.2.3.4

This leaves, I think, a situation in which the client can send any IP in
the X-Forwarded-For header then we'd use it and throw away the peer IP seen
by proxy1.


On Tue, 23 Apr 2024 at 10:39, Gustaf Neumann (sslmail) <ne...@wu...>
wrote:

>
> Why are you looking into the issue? Would the filtering of private
> addresses help you?
>
> -gn
>
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>

Re: [naviserver-devel] reverseproxymode with multiple X-Forwarded-For values

[Gustaf N. (sslmail) <ne...@wu...>]

> On 22.04.2024, at 11:01, David Osborne <da...@qc...> wrote:
> 
> In reverseproxymode, when there is a list of IPs in X-Forwarded-For header, it's always the leftmost IP which is chosen by NaviServer for accesslogs (and ns_conn peeraddr):
> 
> X-Forwarded-For 1.1.1.1,2.2.2.2
> ns_conn peeraddr -source forwarded = 1.1.1.1
> 
> Is there any mechanism by which we can resolve to the rightmost IP for the access logs instead?


In case, there is only one forwarded-for entry received by NaviServer, everything is fine in all situations. In case x-forwarded-for has multiple values and gets its content from trusted and well-configured proxies, the leftmost value is the original value of the client
     X-Forwarded-For: client, proxy1, proxy2
The rightmost value is from is the last proxy. 

From a security point of view, if there is no trust in the proxies, it is certainly easy for an attacker to inject a wrong IP-address of the client to the forwarded-for header. Therefore, various reverse proxy server have mechanisms to define trusted upstream proxies, from which these values are accepted. So, probably the right approach is to accept in nginx configuration only  incoming x-forwarded-for headers from trusted sources (or drop all, if there are no trusted upstream servers). nginx-rule for replacing incoming x-forwarded-for headers with the remote address:
      proxy_set_header X-Forwarded-For $remote_addr;
Note that it is possible that a request can contain multiple x-forwarded-for headers, which should be logically concatenated. NaviServer just takes the first one (corresponding the leftmost value) and shows therefore a consistent behaviour.

However, the implementation in NaviServer is certainly not perfect. When handling of multiple proxy servers is required (larger network of proxies) and e.g. a client and a proxy are from a private network (having non-routable addresses), and these requests are routed over proxies in public networks, the internal addresses would not be informative for most purposes (geo-location, etc.) and should not be used. Instead, the first routable, valid address from the left should be taken.

As another improvement, NaviServer should support the standardised “Forwarded” header, but its content can't be trusted as well. So, i am not sure, this would help.

Why are you looking into the issue? Would the filtering of private addresses help you?

-gn

Re: [naviserver-devel] FreeBSD 14 - TCL 9.0 - NaviServer GIT Latest - error: incompatible function pointer - log.c

[Gustaf N. (sslmail) <ne...@wu...>]

Dear David,

I installed freebsd14 and could reproduce the issue. The issue is that Tcl_PanicProc is defined in Tcl9 with the attribute declaration TCL_NORETURN1, but it seems, this attribute definition has to be provided as well for the  prototype. It would be certainly better, if this attribute definition would be part of the type declaration of Tcl_PanicProc in Tcl9. Not very long ago, the same code worked fine, so something has changed in Tcl9.

The patch below addresses this issue, but this is not nice. Maybe, the tcl-core people have a suggestion, since this will effect as well other applications requiring the use of Tcl_SetPanicProc().

Please update your checkout of NaviServer from git, since i have fixed one more small issues unrelated to this.

all the best
-g


--- a/nsd/log.c
+++ b/nsd/log.c
@@ -96,7 +96,11 @@ static void LogEntriesFree(void *arg);
  */
 
 static Ns_TlsCleanup FreeCache;
-static Tcl_PanicProc Panic;
+static
+#ifndef NS_TCL_PRE9
+ TCL_NORETURN1
+#endif
+ Tcl_PanicProc Panic;
 
 static Ns_LogFilter LogToFile;
 static Ns_LogFilter LogToTcl;




> On 21.04.2024, at 16:18, Not Spam <un...@cr...> wrote:
> 
> Good afternoon,
> I'm currently rebuilding my machine and I am having some issues with NaviServer (4.99-main #defd765) compiling on FreeBSD 14, with TCL 9.0b2 or TCL 9.0b1
>  
> TCL 9.0b1
> ===
> cc  -O2 -Wall -fPIC  -pipe -finput-charset=UTF-8  -DNDEBUG -DSYSTEM_MALLOC -std=c99 -I../include -I"/usr/local/include"   -DHAVE_CONFIG_H   -c -o log.o log.c
> log.c:262:22: error: incompatible function pointer types passing 'Tcl_PanicProc' (aka 'void (const char *, ...)') to parameter of type 'void (*)(const char *, ...) __attribute__((noreturn))' [-Wincompatible-function-pointer-types]
>     Tcl_SetPanicProc(Panic);
>                      ^~~~~
> /usr/local/include/tcl.h:2366:37: note: passing argument to parameter 'panicProc' here
>                             TCL_NORETURN1 Tcl_PanicProc *panicProc);
>                                                                                      ^
>  
> TCL 9.0b2
> ===
> cc  -O2 -Wall -fPIC  -pipe -finput-charset=UTF-8  -DNDEBUG -DSYSTEM_MALLOC -std=c99 -I../include -I"/usr/local/include"   -DHAVE_CONFIG_H   -c -o log.o log.c
> log.c:262:22: error: incompatible function pointer types passing 'Tcl_PanicProc' (aka 'void (const char *, ...)') to parameter of type 'void (*)(const char *, ...) __attribute__((noreturn))' [-Wincompatible-function-pointer-types]
>     Tcl_SetPanicProc(Panic);
>                      ^~~~~
> /usr/local/include/tcl.h:2366:37: note: passing argument to parameter 'panicProc' here
>                             TCL_NORETURN1 Tcl_PanicProc *panicProc);
>                                                                                      ^
> 1 error generated.
>  
> I'm using the latest GIT repo version.
> Any advice would be nice, I wish to use the ZIPFS that TCL9 brings.
>  
> Regards,
> David F
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel

[naviserver-devel] reverseproxymode with multiple X-Forwarded-For values

[David O. <da...@qc...>]

Hi,

In reverseproxymode, when there is a list of IPs in X-Forwarded-For header,
it's always the leftmost IP which is chosen by NaviServer for
accesslogs (and ns_conn peeraddr):

X-Forwarded-For 1.1.1.1,2.2.2.2
ns_conn peeraddr -source forwarded = 1.1.1.1

Is there any mechanism by which we can resolve to the rightmost IP for the
access logs instead?

X-Forwarded-For 1.1.1.1,2.2.2.2
ns_conn peeraddr -source forwarded = 2.2.2.2

The use case is, if we are behind a single reverse proxy, if X-Forwarded-For
already exists when hitting that proxy, the proxy will often append the
client IP to the contents of the header.

In these cases, we don't want to trust the original contents of the header,
only what was added by our trusted proxy - eg. the rightmost value.

The algorithm could be something like:

if { [llength $x-forwarded-for] > 1} {
   if { [ns_conn peeraddr -source direct] in $trusted_subnet } {
      set client_ip [lindex $x-forwarded-for end]
   }
}

We can currently do this programmatically by inspecting the headers
themselves, but the IP in the access logs would, I think, still be the
untrusted IP.

(This is really a limitation of the X-Forwarded-For mechanism itself, hence
why it is being superseded by the Forwarded header.)

Nginx have a config mechanism to try to express this which includes
specifying the subnets or IP addresses you trust:
https://nginx.org/en/docs/http/ngx_http_realip_module.html

In NaviServer, it could be something like:
ns_param    reverseproxymode "true"
ns_param    reverseproxytrust [list 192.168.1.21 192.168.2.0/24]

Any suggestions on what is best to do here?

-- 

*David Osborne | Software Engineer*
Qcode Software
*Email:* da...@qc... | *Phone:* 01463 896 484
www.qcode.co.uk

Re: [naviserver-devel] FreeBSD 14 - TCL 9.0 - NaviServer GIT Latest - error: incompatible function pointer - log.c

[Not S. <un...@cr...>]

Apologies for the spam, It just occurred to me I could just do a backtrace. 
Reading symbols from nsd... 
[New LWP 109631] 
Core was generated by `./nsd'. 
Program terminated with signal SIGSEGV, Segmentation fault. 
Address not mapped to object. 
#0 0x0000000821d3fb93 in LogFlush () from /srv/.forest./lib/libnsd.so 
(gdb) bt 
#0 0x0000000821d3fb93 in LogFlush () from /srv/.forest./lib/libnsd.so 
#1 0x0000000821d3f8bb in Ns_Log () from /srv/.forest./lib/libnsd.so 
#2 0x0000000821d7ef61 in NsInitOpenSSL () from /srv/.forest./lib/libnsd.so 
#3 0x0000000821d3db29 in Nsd_LibInit () from /srv/.forest./lib/libnsd.so 
#4 0x0000000821d4273e in Ns_Main () from /srv/.forest./lib/libnsd.so 
#5 0x000000082854aafa in __libc_start1 () from /lib/libc.so.7 
#6 0x0000000000201710 in _start () at /usr/src/lib/csu/amd64/crt1_s.S:83 

If any further information is required. let me know 
Regards 
David F 

Re: [naviserver-devel] FreeBSD 14 - TCL 9.0 - NaviServer GIT Latest - error: incompatible function pointer - log.c

[Not S. <un...@cr...>]

 
Well my tinkering failed. 
  
 
./nsd 
Segmentation fault (core dumped) 
  
Can email core if required? 
  
Regards 
David F  

Re: [naviserver-devel] FreeBSD 14 - TCL 9.0 - NaviServer GIT Latest - error: incompatible function pointer - log.c

[Not S. <un...@cr...>]

 
Ah, well, I found workaround to get it to compile is to 
modifiy log.c on line 263 
  
From: 
 
  
  Tcl_SetPanicProc(Panic); 
  Ns_AddLogFilter(LogToFile, INT2PTR(STDERR_FILENO), NULL); 
  
To 
   
 
  Tcl_PanicProc(Panic); 
  Ns_AddLogFilter(LogToFile, INT2PTR(STDERR_FILENO), NULL); 
   
Results in completed compile, but does throw the warning: 
  
 
log.c:952:1: warning: unused function 'Panic' [-Wunused-function] 
Panic(const char *fmt, ...) 
^ 
  
So, I've probably broken something somewhere, but good enough for me. 
  
Regards, 
David F  
 
 
 
 

-----Original Message-----

From: Not <un...@cr...>
To: naviserver-devel <nav...@li...>
Date: Sunday, 21 April 2024 2:18 PM GMT
Subject: FreeBSD 14 - TCL 9.0 - NaviServer GIT Latest - error: incompatible function pointer - log.c

 
 
Good afternoon, 
I'm currently rebuilding my machine and I am having some issues with NaviServer (4.99-main #defd765) compiling on FreeBSD 14, with TCL 9.0b2 or TCL 9.0b1 
  
TCL 9.0b1 
=== 
 
cc  -O2 -Wall -fPIC  -pipe -finput-charset=UTF-8  -DNDEBUG -DSYSTEM_MALLOC -std=c99 -I../include -I"/usr/local/include"   -DHAVE_CONFIG_H   -c -o log.o log.c 
log.c:262:22: error: incompatible function pointer types passing 'Tcl_PanicProc' (aka 'void (const char *, ...)') to parameter of type 'void (*)(const char *, ...) __attribute__((noreturn))' [-Wincompatible-function-pointer-types] 
    Tcl_SetPanicProc(Panic); 
                     ^~~~~ 
/usr/local/include/tcl.h:2366:37: note: passing argument to parameter 'panicProc' here 
                            TCL_NORETURN1 Tcl_PanicProc *panicProc); 
                                                                                     ^ 
   
TCL 9.0b2 
=== 
 
cc  -O2 -Wall -fPIC  -pipe -finput-charset=UTF-8  -DNDEBUG -DSYSTEM_MALLOC -std=c99 -I../include -I"/usr/local/include"   -DHAVE_CONFIG_H   -c -o log.o log.c 
log.c:262:22: error: incompatible function pointer types passing 'Tcl_PanicProc' (aka 'void (const char *, ...)') to parameter of type 'void (*)(const char *, ...) __attribute__((noreturn))' [-Wincompatible-function-pointer-types] 
    Tcl_SetPanicProc(Panic); 
                     ^~~~~ 
/usr/local/include/tcl.h:2366:37: note: passing argument to parameter 'panicProc' here 
                            TCL_NORETURN1 Tcl_PanicProc *panicProc); 
                                                                                     ^ 
1 error generated. 
 
  
I'm using the latest GIT repo version. 
Any advice would be nice, I wish to use the ZIPFS that TCL9 brings. 
  
Regards, 
David F   
      

[naviserver-devel] FreeBSD 14 - TCL 9.0 - NaviServer GIT Latest - error: incompatible function pointer - log.c

[Not S. <un...@cr...>]

 
Good afternoon, 
I'm currently rebuilding my machine and I am having some issues with NaviServer (4.99-main #defd765) compiling on FreeBSD 14, with TCL 9.0b2 or TCL 9.0b1 
  
TCL 9.0b1 
=== 
 
cc  -O2 -Wall -fPIC  -pipe -finput-charset=UTF-8  -DNDEBUG -DSYSTEM_MALLOC -std=c99 -I../include -I"/usr/local/include"   -DHAVE_CONFIG_H   -c -o log.o log.c 
log.c:262:22: error: incompatible function pointer types passing 'Tcl_PanicProc' (aka 'void (const char *, ...)') to parameter of type 'void (*)(const char *, ...) __attribute__((noreturn))' [-Wincompatible-function-pointer-types] 
    Tcl_SetPanicProc(Panic); 
                     ^~~~~ 
/usr/local/include/tcl.h:2366:37: note: passing argument to parameter 'panicProc' here 
                            TCL_NORETURN1 Tcl_PanicProc *panicProc); 
                                                                                     ^ 
   
TCL 9.0b2 
=== 
 
cc  -O2 -Wall -fPIC  -pipe -finput-charset=UTF-8  -DNDEBUG -DSYSTEM_MALLOC -std=c99 -I../include -I"/usr/local/include"   -DHAVE_CONFIG_H   -c -o log.o log.c 
log.c:262:22: error: incompatible function pointer types passing 'Tcl_PanicProc' (aka 'void (const char *, ...)') to parameter of type 'void (*)(const char *, ...) __attribute__((noreturn))' [-Wincompatible-function-pointer-types] 
    Tcl_SetPanicProc(Panic); 
                     ^~~~~ 
/usr/local/include/tcl.h:2366:37: note: passing argument to parameter 'panicProc' here 
                            TCL_NORETURN1 Tcl_PanicProc *panicProc); 
                                                                                     ^ 
1 error generated. 
 
  
I'm using the latest GIT repo version. 
Any advice would be nice, I wish to use the ZIPFS that TCL9 brings. 
  
Regards, 
David F   
 

Re: [naviserver-devel] Error on startup

[Maksym Z. <siq...@gm...>]

Dear Gustaf, my naviserver and modules are compiled and installed in the
docker container, using the same image, so I assume there's no problem with
different versions of tcl. This error happens when I'm trying to start a
container, after a few retries it works fine.

On Tue, Mar 19, 2024 at 8:21 AM Gustaf Neumann (sslmail) <ne...@wu...>
wrote:

> The error indicates inconsistent usage of memory allocation/deallocation
> functions. Typical reasons are inconsistent usage of library functions
> (e.g. different tcl versions during compilation and runtime of nsd or some
> of the c modules) or inconsistent usage of memory allocator options (e.g.
> malloc libraries in use).
>
> One can obtain details what happened via debugging options during
> compilation.
>
> -gn
>
> > On 18.03.2024, at 18:39, Maksym Zinchenko <siq...@gm...> wrote:
> >
> > Hello, what can cause this errors, how can I get more information about,
> debug:
> >
> > Fatal: alloc: invalid block: 0x7fd5285e5670: 0 0
> > Fatal: received fatal signal 11
> >
> > Thank you
> > _______________________________________________
> > naviserver-devel mailing list
> > nav...@li...
> > https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>
>
>
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>