Re: OpenSSL PKCS#11 Engine cannot be reused in child process, worker SSL sessions fail

[Nikos Mavrogiannopoulos]

On Sun, 2015-07-26 at 00:20 +0800, Anthony Alba wrote:
> Hi developers,
> 
> I am using nginx with an OpenSSL engine (Safenet Luna) which is a
> wrapper over PKCS#11.
> 
> The handles return by ENGINE_load_private_key cannot be used in child
> processes, aka, workers due to PKCS#11, thus causing SSL connection
> errors.
> The private key seems to be loaded in ngx_ssl_certificate(); is there
> a way to tell nginx to call this function per child process?

nginx should work transparently with the newest libp11 (0.3.0) and
engine_pkcs11 (0.2.0). Let me know, if not.

regards,
Nikos


___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Re: Debugging nginx quiet ugrade

[Maxim Dounin]

Hello!

On Fri, Oct 16, 2015 at 11:32:42AM +0530, Ruchika Luthra wrote:

> Hi Everyone,
> 
> Can anyone please help me how to debug the failure the nginx quietpgrade?
> Also I am unable to locate nginx.pid.oldbin. Could this be one of the
> reason?

You are using the wrong mailing list for the question.  This one is 
for development discussions.  Please use ng...@nginx.org mailing 
list instead, see http://nginx.org/en/support.html.

-- 
Maxim Dounin
http://nginx.org/

___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Re: Error handling from filter modules

[Maxim Dounin]

Hello!

On Fri, Oct 16, 2015 at 03:16:23PM +0300, Roman Arutyunyan wrote:

> > So the question is do filters have to manually call
> > ngx_http_finalize_request(r, NGX_HTTP_INTERNAL_SERVER_ERROR); or is it
> > expected that the upper layers should actually do the right thing and
> > ensure the client doesn't get a bad response generated from the current
> > state of r with no indication an error occurred?
> 
> Calling ngx_http_finalize_request() is the most correct way to return an
> error from a filter handler.  It does some additional cleanup, which can
> make sense in certain cases.

Huh?  The ngx_http_finalize_request() shouldn't be called from 
filters at all, this will cause incorrect reference counting and 
a segmentation fault as a most likely result.

-- 
Maxim Dounin
http://nginx.org/

___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Re: [PATCH] Support FreeBSD jails for testing

[Maxim Dounin]

Hello!

On Fri, Oct 16, 2015 at 12:09:49AM +, Steven Hartland wrote:

> # HG changeset patch
> # User Steven Hartland 
> # Date 1444954080 0
> #  Fri Oct 16 00:08:00 2015 +
> # Node ID c22d8299e7040e0de6f85b4e96d0dd953f7af644
> # Parent  78b4e12e6efe642aff591234db0f0b040cae9b5e
> Support FreeBSD jails for testing
> 
> Ensure the test directory is read and writable to the test user.
> 
> If you request 127.0.0.1 in a FreeBSD jail without specific access
> to 127.0.0.1 then the socket binds to the interface address to
> maintain compatibility. This results in the log entries being
> from the bound interface address. To prevent failure compare
> with the bound IP when requesting 127.0.0.1 in combined test.

This jails behaviour is known to cause many problems, in 
particular, it makes impossible nginx binary upgrades unless all 
listen sockets are explicitly bound to jail's IP address.

Fortunately, this was resolved several years ago by introduction 
of multi-IP jails.  You may try to use them for tests instead.

Adding quirks everywhere to support this brain-damaged "no 
127.0.0.1" case looks like a wrong way to go for me.  Especially 
given the fact that simple solution exists for years.

[...]

-- 
Maxim Dounin
http://nginx.org/

___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Re: Error handling from filter modules

[Roman Arutyunyan]

Hello Steve,

> On 16 Oct 2015, at 04:36, Steven Hartland  
> wrote:
> 
> I'm making changes to a filter module

Header filter or body filter?

> and when it detected an error it
> returned NGX_ERROR however the response generated to the client isn't
> the expected 500 internal server error I would have expected given said
> return.

If you return NGX_ERROR from a filter handler, your request will be terminated
without sending any response to client.  If you want a certain error code
to be sent to client, you can either return it from your header filter handler
directly or call ngx_http_finalize_request().

> So the question is do filters have to manually call
> ngx_http_finalize_request(r, NGX_HTTP_INTERNAL_SERVER_ERROR); or is it
> expected that the upper layers should actually do the right thing and
> ensure the client doesn't get a bad response generated from the current
> state of r with no indication an error occurred?

Calling ngx_http_finalize_request() is the most correct way to return an
error from a filter handler.  It does some additional cleanup, which can
make sense in certain cases.

--
Roman Arutyunyan



___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel