Created attachment 184386 [details]
patch against head
Suricata 3.2.3 requires this update. Since the two are intermingled, I would also like to ask the issue of reassigning maintainership to make upgrades atomic and/or avoid potential timeouts.
In this update, the library version was bumped to 2, I also reordered pkg-plist alphabetically.
Created attachment 184387 [details]
poudriere build log
The matching suricata update is here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220758
Created attachment 184390 [details]
Updated patch drops obsoleted PLIST_SUB and CONFLICTS_INSTALL, tab alignment for INSTALL_TARGET and TEST_TARGET
(In reply to Franco Fichtner from comment #0)
I think I recall reading in previous releases that suri has a libhtp dependency type of 'greater than or equal to X'. If this is still the case, then ensuring that libhtp is at that minimum version prior to committing an update of suricata is all that's needed, precluding combining two ports updates in a single commit.
The changelog also looks like fixes only:
- underscore in htp_validate_hostname [#149]
- fix SONAME issue [#151]
- remove unrelated docbook code from tree [#153]
That aside, since the library name and (major) version has been changed, the diff should include a PORTREVISION bump of dependent ports (in this case, only security/suricata), and any LIB_DEPENDS name changes that are needed.
Can you confirm whether or not QA of the suricata update in bug 220758 includes this change or not? If not, I'd suggest QA again with the change to ensure the library name/version changes are picked up OK by the suricata port.
Suricata 3.2.3 includes this libhtp bump. I mostly worry about security implications from not upgrading libhtp along with suricata, as any bug will cause issues in the Suricata binary. Whether or not an update has security implications is harder to assess, but shouldn't keep us from updating.
In OPNsense, we've moved away from separating libhtp from suricata, as it's harder to test upgrades from the user end plus the upgrade is more precise.
Maybe we should start bundling libhtp in a way that does not clash with the libhtp port? I mean this is the standard Suricata way so it cannot be that wrong?
(In reply to Franco Fichtner from comment #5)
The same worry/reason is why downstream OS's unbundle library dependencies in their packages.
Otherwise, one would have to wait for N dependent statically-compiled consumers of that library to provide updates in order to resolve the security issue for your users.
See Also: https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/book.html#bundled-libs
We don't need to go into upstream vs downstream perspectives and how their value propositions and operational characteristics differ here.
@Franco, as per comment 4 (and so I dont forget), could you please update the patch to include a security/suricata: PORTREVISION bump
Ok, currently waiting for verify of suricata 3.2.3 build + libhtp 0.5.24 just to be sure.
(In reply to Franco Fichtner from comment #8)
Created attachment 184392 [details]
revised patch with revision bump for suricata
So the SONAME change / version bump was purely to unbreak SONAME from changing its name, but building against < 0.5.25 from Suricata 3.2.3 is fine.
A commit references this bug:
Date: Mon Jul 17 05:52:20 UTC 2017
New revision: 446052
devel/libhtp: Update to 0.5.25
* Remove CONFLICTS_INSTALL (libhtp-suricata port deleted)
* Remove unecessary PLIST_SUB
* Update and sort pkg-plist
* Bump security/suricata PORTREVISION, library name/version change
Submitted by: Franco Fichtner (franco opnsense org)
Committed, thank you Franco
Hmm, revision does not include suricata revision bump despite the message?
A commit references this bug:
Date: Mon Jul 17 05:58:05 UTC 2017
New revision: 446053
security/suricata: Bump PORTREVISION
Actually bump PORTREVISION mentioned but not committed in ports r446052