Page MenuHomeFreeBSD

sysutils/ansible: address CVE-2016-9587
ClosedPublic

Authored by lifanov on Jan 12 2017, 6:30 PM.

Details

Summary

vuxml:

Document ansible vulnerabilities.

 Security: CVE-2016-9587
 Security: https://vuxml.FreeBSD.org/freebsd/a93c3287-d8fd-11e6-be5c-001fbc0f280f.html
 Reviewed by: matthew
 Approved by: matthew (mentor)
 Differential Revision: https://reviews.freebsd.org/D9158

port:

sysutils/ansible: address CVE-2016-9587

 MFH: 2017Q1
 Security: CVE-2016-9587
 Security:  https://vuxml.FreeBSD.org/freebsd/a93c3287-d8fd-11e6-be5c-001fbc0f280f.html
 Reviewed by: matthew
 Approved by: matthew (mentor)
 Differential Revision: https://reviews.freebsd.org/D9158
Test Plan

poudriere testport - OK
functionality - OK
vuxml make validate - OK

Diff Detail

Repository
rP FreeBSD ports repository
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 6735
Build 6952: arc lint + arc unit

Event Timeline

lifanov retitled this revision from to sysutils/ansible: address CVE-20169587.
lifanov updated this object.
lifanov edited the test plan for this revision. (Show Details)
lifanov added a reviewer: matthew.
lifanov added a subscriber: koobs.
lifanov retitled this revision from sysutils/ansible: address CVE-20169587 to sysutils/ansible: address CVE-2016-9587.Jan 12 2017, 7:43 PM
lifanov updated this object.
lifanov edited the test plan for this revision. (Show Details)
lifanov edited the test plan for this revision. (Show Details)

add lower bound to affected versions

matthew edited edge metadata.

Otherwise, this looks good.

security/vuxml/vuln.xml
72

Text should be wrapped to 80 columns.

This revision is now accepted and ready to land.Jan 12 2017, 9:55 PM
This revision was automatically updated to reflect the committed changes.

Ah -- I missed a problem with the VuXML entry.

Where you define the affected range:

<package>
  <name>ansible</name>
  <range><gt>1.9.*</gt><lt>2.2.0.0_2</lt></range>
</package>
  • you can't use a wildcard there. That should read: <range><gt>1.9.0</gt><lt>2.2.0.0_2</lt></range>

I found examples of wildcard entries: linux-f10-* and otrs. The wildcard best expresses the range here: 1.9.x branch is not affected. I can change the lower bound to 1.9.6_2 if this is preferable.

I found examples of wildcard entries: linux-f10-* and otrs. The wildcard best expresses the range here: 1.9.x
branch is not affected. I can change the lower bound to 1.9.6_2 if this is preferable.

Fairly sure that using wildcards will defeat the version comparison that pkg audit does.

Yes, using 1.9.6_2 as the lower bound would be good.

I found examples of wildcard entries: linux-f10-* and otrs. The wildcard best expresses the range here: 1.9.x branch is not affected. I can change the lower bound to 1.9.6_2 if this is preferable.

If the 1.9.* branch is not affected, it means that it starts at 1.10, so, <ge>1.10</ge>

The 1.9 "branch" is dead. It predates the concept of stable branches upstream.
There was never a 1.10. The 2.1 and 2.2 branches are still active.

The "ansible1" port, which still exists for the sake of py27-ploy_ansible will probably never be updated and I plan to deprecate/delete it as soon as py27-ploy_ansible moves off of it.

Do you think it still makes sense to switch to <ge>1.10</ge>?