confusion / conflict with main nginx branch ssl_* changes

[peterbowey]

Hi @InfoHunter @PaulYang,

I am trapped by the over-lap / variances of this SEnginx to the main nginx branch.
If you look at trunk nginx changes here:

1. http://hg.nginx.org/nginx/rev/7022564a9e0e
2. http://hg.nginx.org/nginx/rev/060c2e692b96

You can see a overlap on ssl_* handling.
As SEnginx is lagging behind upstream, I am in confusion which 'branch' [SEnginx @ v1.5.13 or mainstream trunk @ V1.7.1

I once could merge the differences between SEnginx and Nginx, but this possible ssl_* over-lap makes such practice tricky.

[peterbowey]

@InfoHunter

I dealt with the above 'issue' this way:
Applied https://github.com/NeusoftSecurity/SEnginx/commit/1bcfa2fd3fde42abeb50f0c04211badf5b5b8d6d.patch as a 'reverse' patch, then let latest nginx trunk process the ssl_* (as merged into SEnginx 'master')

[peterbowey]

Should also mention this one (test): -> reverse patch

https://github.com/NeusoftSecurity/SEnginx/commit/679086863db59a60b27775dd308e3c143e3c18ba.patch

[peterbowey]

I ended up using the full ssl_* functionality in SEnginx, seems more enhanced than trunk nginx :)

[InfoHunter]

Good to hear that : )
But this kind of 'duplicated' feature that both appear in nginx and SEnginx will cause some problems when syncing SEnginx with upstream nginx. I haven't decided a strategy on merging yet ...

[peterbowey]

@InfoHunter

Yes, I had the same struggle / thinking... :)
I 'cherry picked' some of the nginx upstream merges to SEnginx ("carefully" avoiding ssl_* issues)...