Hey Bryan, * On 2015-11-19 at 18:41 GMT, Bryan Horstmann-Allen wrote:
> On a 14.4.2 LTS image, running `pkg_admin audit` after a `pkgin full-upgrade` > still reports a number of vulnerable packages. > > Some of the bugs reported by audit are non-trivial: > > https://gist.githubusercontent.com/bdha/e11a3672d96c1a5bdd76/raw/6f39e50130866db58c9b650da13a09936a82d5d0/gistfile1.txt One thing to note about pkg_admin audit is that the vulnerabilities file is constantly being updated, independently of pkgsrc trunk changes and regardless of whether there is a publicly available upstream fix or not. The idea being that we want to give the admin as much information as possible, even if there might not be a fix available, so that they can make the call whether to continue using the software or not. For example, there are multiple vulnerabilities listed for openssl-1.0.1p, yet that is the current release upstream (not that you can really avoid using openssl!). We prefer to wait for upstream to release a new version before upgrading, as chasing patches from mailing lists can often result in more problems. Even running audit on a fresh pkgsrc trunk install will show a lot of vulnerabilities, and there will almost never be a point in time where you won't see some output with a reasonable number of packages installed. > Going through > > https://github.com/joyent/pkgsrc/tree/joyent/release/2014Q4 > > It looks like some packages are getting security and reliability fixes pulled > in from upstream pkgsrc, but not all? > > Is there a procedure for getting security patches from upstream backported > into > LTS? Am I confused (package versions unchanged? If so, leads to auditing > confusion)? We try to backport as much as possible. The general procedure is quite simple: - The issue is fixed in pkgsrc trunk, either by us or a pkgsrc developer, usually by upgrading software to the latest released version. - We backport the change to joyent/feature/backports/2014Q4, merge into joyent/release/2014Q4, and kick off a rebuild. This should always result in a package version bump. However there are a few things working against us that mean we're not always up to date with backports: - pkgsrc trunk is a constantly moving target, e.g. openssl is now on the 1.0.2 series, meaning we will have to manage any future 1.0.1 upgrades ourselves and can't re-use the work done by the wider pkgsrc community. - pkgsrc infrastructure changes over time, so even where versions are similar there can be major hurdles to backporting. A good example would be the recent PHP backports, where the PHP infrastructure in pkgsrc had changed quite a bit, so we had to be very careful integrating the change to ensure we didn't break anything. - Newer versions of upstream software may fix the security issue but may at the same time introduce API/ABI incompatible changes which are at odds with our LTS policy of no major version bumps. The further that pkgsrc-trunk moves away from pkgsrc_2014Q4 the more pronounced these differences become, which is why the rate of backports has slowed over the year. When the LTS branch is first cut and is the most recent branch we can take advantage of the work by the upstream pkgsrc-releng team who maintain backports to the branch, but as soon as the next branch is cut they move onto it and we (myself and Filip) have to pick up that work ourselves. There are also a couple of areas we need to improve internally: - We currently don't have any automated monitoring of vulnerabilities to show which backports may be available, so this is very much a manual process where we prioritise the obvious higher-profile candidates and may miss the smaller updates. - Some updates (e.g. OpenSSL) will trigger a massive rebuild of packages as every dependency is always rebuilt. Transient build failures may then mean that packages which were previously available are now removed from the package archives. In some cases this has meant large numbers of packages disappearing. I've recently put measures in place to prevent this but it isn't yet backported to our LTS branch. - Some updates (hi again OpenSSL!) can introduce subtle bugs in supposedly-stable releases, for example OpenSSL 1.0.1m changed their public headers in a way which broke cmake. On an LTS branch this is unacceptable, and unfortunately we can't know about these issues until we run into them. This ties in with the previous point, and hopefully we can mitigate against these issues better. Those are on us, and I'm looking forward to our next LTS branch in January (15.4.x) improving in these areas. A couple of final points: - It's worth noting that the LTS releases aren't designed to be the most stable or the most secure. The primary users of LTS are intended to be those who are happy with the versions of software available in that LTS release and do not want to see major version changes but who require that we make a reasonable effort to backport important security fixes. This is very much on a best effort basis due to the reasons above, and we're never going to cover all 14,000+ packages, so if your primary concern is ensuring you get the latest software and the most secure releases then you should always run the most recent image releases rather than LTS. - We are more than happy to accept pull requests to the joyent/feature/backports/2014Q4 branch, and issues against joyent/pkgsrc on github notifying us of important (for you) updates that we may have overlooked. - Filip points out that the openssl-1.0.1p entries may actually be bad pattern matching that haven't been noticed as pkgsrc trunk moved on to 1.0.2. We'll take a look into that, as well as the other vulnerabilities you listed. Hopefully that's helpful. Let me know if you want additional information on any of these points. Cheers, -- Jonathan Perkin - Joyent, Inc. - www.joyent.com ------------------------------------------- smartos-discuss Archives: https://www.listbox.com/member/archive/184463/=now RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00 Modify Your Subscription: https://www.listbox.com/member/?member_id=25769125&id_secret=25769125-7688e9fb Powered by Listbox: http://www.listbox.com
