search

TritonDataCenter / pkgsrc-legacy

Automatically updated conversion of the "pkgsrc" module from anoncvs.netbsd.org
http://www.pkgsrc.org
127 stars 64 forks source link

Backport freetype2 from trunk #527

Closed stevenwilliamson closed 6 years ago

stevenwilliamson commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

Done for 2015Q4.