Created attachment 150932 [details] Switch libsrtp to today's version from GitHub The current port builds upstream version 1.4.4, which is 7 years old. The proposed update switches to the current version from GitHub (cisco/). Of particular usefulness, this new version allows to enable SRTP-support in net/ortp, which, in turn, provides for ZRTP support there thus enabling encryption in linphone. The update also provides for properly building the libsrtp.so (shared library) and the regression-test target (with some aliases).
Created attachment 150933 [details] Switch libsrtp to today's version from GitHub (no pkgconfig)
Switching from an x.y.z (1.4.4) version to YYYYMMDD (20141224) is likely to cause issues if and when the version convention needs to be switched back in future. The upstream GitHub repository has a v1.5.0 [1] tag which you can use instead. If there are later versions that haven't been tagged, request all release tags to be created in the repository. [1] https://github.com/cisco/libsrtp/tree/v1.5.0 Also: - GH_PROJECT now (recently) defaults to ${PORTNAME} - ${ORIGNAME} should no longer be necessary after the switch to GitHub - Should you provide OPTIONS for syslog, openssl, and generic-aesicm CONFIGURE options? - test runtest check regression-test is overkill, regression-test: is enough - Does the upstream Makefile contain a check: target? Use that for regression-test instead of runtest directly
(In reply to Kubilay Kocak from comment #2) > The upstream GitHub repository has a v1.5.0 [1] tag which you can use instead. Uhm, ortp and linphone need to have this problem resolved: https://github.com/cisco/libsrtp/issues/28 I'm not sure, if it is resolved in 1.5.0 -- the comments there say, the fix was applied to v2.0.0. But, could you post your own patch -- the GH-settings remain a "trial-and-error" for me here -- and I'll test it? Thank you!
Mikhail, The changeset in question looks like it was made after v1.5.0 was tagged. It was also made a few commits after 2_0_0_dev was branched from 1.5.x. Based on that and the fact that a header refactor occurred just after branching, I would be inclined either: a) Grab v1.5.0 tag, and backport the commit you want. (A raw diff in /files should be enough) b) Grab 2_0_0_dev at that commit, and set DISTVERSION accordingly My recommendation would be (a). As far as GH_* variables go, it's better learning how they are used. Jump on #freebsd-ports or #bsdports any time to get help :)
(In reply to Kubilay Kocak from comment #4) > The changeset in question looks like it was made after v1.5.0 was tagged. It > was also made a few commits after 2_0_0_dev was branched from 1.5.x. Since nothing in our ports-tree seems to depend on net/libsrtp at the moment anyway, I'd rather our port offered the very latest from upstream. > a) Grab v1.5.0 tag, and backport the commit you want. (A raw diff in /files > should be enough) > b) Grab 2_0_0_dev at that commit, and set DISTVERSION accordingly The trouble with following such branches is that the version (DISTVERSION) does not change even after the upstream makes another commit. Thus, the timestamp (and the commit tag/hash/id) remains the only way to track the upstream sources in the sortable way. Yes, going from timestamp back to "normal" versions (like N.M.K) will be difficult, but there is not really a good alternative. Would it look better as 2.0.0.20141224 ? > As far as GH_* variables go, it's better learning how they are used. Jump on > #freebsd-ports or #bsdports any time to get help :) Thanks for the offer, but I was hoping, that you'd put an example right here. If you don't feel like it, then let's leave this PR between myself and the port's current maintainer.
Created attachment 151190 [details] alternate patch I'd like to propose this alternate patch. It updates the port to version 1.5.0 instead of using a development version. It also enables the use of some crypto functions from libcrypto (OpenSSL) which eliminates the sha1_update function from the library so it no longer conflicts with the same function from polarssl.
(In reply to Tijl Coosemans from comment #6) > I'd like to propose this alternate patch. It updates the port to version > 1.5.0 instead of using a development version. Considering the sort of "release-management" that GitHub seems to encourage, I doubt, using such a release ("version 1.5.0") will mean, what we usually mean by the term... Because nothing in our ports-tree is really using libsrtp at the moment, we don't need to worry (much) about "legacy" code. I'd say, we may as well offer a snapshot of the current master-branch of the project. > It also enables the use of some crypto functions from libcrypto (OpenSSL) which > eliminates the sha1_update function from the library so it no longer conflicts > with the same function from polarssl. So, we'll now have both OpenSSL and polarssl linked into libsrtp? If polarssl can not be easily replaced by OpenSSL (from base) completely, should we not use polarssl's implementation(s) of digests (like sha1) instead of -lcrypto's?
(In reply to Mikhail T. from comment #7) > (In reply to Tijl Coosemans from comment #6) >> I'd like to propose this alternate patch. It updates the port to version >> 1.5.0 instead of using a development version. > > Considering the sort of "release-management" that GitHub seems to encourage, > I doubt, using such a release ("version 1.5.0") will mean, what we usually > mean by the term... > > Because nothing in our ports-tree is really using libsrtp at the moment, we > don't need to worry (much) about "legacy" code. I'd say, we may as well > offer a snapshot of the current master-branch of the project. The fix for the sha1_update symbol clash went into the 2_0_0_dev branch, not the master branch. The master branch currently contains version 1.5.1-pre. The 2_0_0_dev branch appears to be used for things that aren't backward compatible with the 1.x series. The library has also been renamed to libsrtp2 there. I don't think it's a good idea to start using that. >> It also enables the use of some crypto functions from libcrypto (OpenSSL) which >> eliminates the sha1_update function from the library so it no longer conflicts >> with the same function from polarssl. > > So, we'll now have both OpenSSL and polarssl linked into libsrtp? If > polarssl can not be easily replaced by OpenSSL (from base) completely, > should we not use polarssl's implementation(s) of digests (like sha1) > instead of -lcrypto's? Polarssl isn't used by libsrtp. It is used by net/belle-sip which is another dependency of linphone.
(In reply to Tijl Coosemans from comment #8) > The fix for the sha1_update symbol clash went into the 2_0_0_dev branch, not > the master branch. The master branch currently contains version 1.5.1-pre. > The 2_0_0_dev branch appears to be used for things that aren't backward > compatible with the 1.x series. The library has also been renamed to libsrtp2 > there. I don't think it's a good idea to start using that. Ok, you convinced me. > Polarssl isn't used by libsrtp. It is used by net/belle-sip which is another > dependency of linphone. I see. And libsrtp.so and libzrtpcpp.so (built my way) both use -lcrypto anyway here. So, unless it is easy to convert them both to PolarSSL, we may as well not bother. Go ahead as you wish -- you have given this quite a bit of thought already, and I'll stop second-guessing.
tijl, IIUC, Mikhail blessed your alternative patch. Would you like to commit it?
Committed in r376611.
Tijl, it seems, the patch for libsrtp.pc causes subsequent users of the port to fail, unless OpenSSL from ports is installed. The line "Requires.private: libcrypto" can not be satisfied with base OpenSSL, because base does not provide libcrypto.pc for pkgconfig. Can you comment on why you made it so? Thanks!
This was at a time when WITH_OPENSSL_PORT was going to become the default, but this work seems to have stalled now. I'll see if I can remove the requirement in the next few days.