Backport freetype2 from trunk

[stevenwilliamson]

Fixes several CVE's

http://secunia.com/advisories/57291/
https://nvd.nist.gov/vuln/detail/CVE-2017-8105
https://nvd.nist.gov/vuln/detail/CVE-2017-8287
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-10328
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2017-7857
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2017-7858
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2017-7864
https://nvd.nist.gov/vuln/detail/CVE-2017-8105
https://nvd.nist.gov/vuln/detail/CVE-2017-8287
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-10328
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2017-7857
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2017-7858
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2017-7864

[mamash]

Thanks for all the PRs, Steven. I'll get through these eventually.

Please note that these need to be made against the respective joyent/feature/backports/* branch, not /release/, otherwise you're erasing functionality from other feature branches. Also, functionality changes should be avoided - ideally the backports should be limited to security related patches and fixes. Simple diffs against trunk are often not desired.

[stevenwilliamson]

@mamash No problem!. Apologies did not realise they should be against the backports branch noted!

Re the LTS release then yes the main driving factor for these pulls is to resolve open CVE's.

I think generally given the resources available it's safest to backport packages as long as it dosen't break binary ABI's rather than trying to manually patch the existing versions with security patches diverging the package from upstream ?

For example the tiff packages I think it would be quite difficult to cherry pick and backport the security only fixes and apply sufficient testing to ensure we didn't introduce an issue in our version of the patches.

Though I am interested in discussing the approach to security patches to LTS releases if there are differing opinions. As there are numerous outstanding security issues in the LTS releases. I for sure understand the dilemma of changes to fix security issues balanced against trying to not introduce any change of behaviour.

[mamash]

I'm sorry, I wasn't clear. I meant "avoid pkgsrc functionality changes" - there may have been pkgsrc infrastructure changes committed since that may not exist in the LTS branches. When making a diff against trunk, you may end up with references to frameworks and helpers that do not exist yet (in general, anything under mk/).

[stevenwilliamson]

@mamash Ah OK that makes sense. For reference, I have run a build for each of these pulls in the respective pkgbuild environment to confirm the build is fine. I guess the thing to watch out for is makefile variables set that has no effect on an older branch so could cause confusion.

Iv'e got quite a few more todo as I intend to make some headway in to closing down CVE's that affect at least packges we use. As im going to be doing the work anyway it makes sense to upstream them so let me know if you spot any such cases where the mk infrastructure does not exist.

Please do let me know if there is anything else i can do to lessen the work / make your job of merging these in any easier!

[mamash]

Done for 2015Q4.