pkgsrc-security one year on ...

Talk Overview

Provide a more coordinated approach to monitoring for 3rd party security advisories
Ensure relevant commits make it to pull-up requests for the last pkgsrc stable branch cut
Automated reporting so we know the status of issues in HEAD and the latest stable branch
Keeping pkg-vulnerabilities up to date and accurate
Provide an avenue for users to inform us of security issues that are specific to pkgsrc
Discuss current limitations and future directions

From May 8th 2005 to May 1st 2006
- 4,703 tickets created in the pkgsrc-security queue
- Average of 12-13 tickets per day
- 4,418 from sec-adv@secunia.com (93.94%)
Breakdown based on ticket status:
- New 122 (2.59%)
- Open 26 (0.55%)
- Stalled 0 (0.00%)
- Resolved 1,274 (27.09%)
- Rejected 3,281 (69.77%)

We are short of consistently active people
- We have activity at the moment amongst the current members, but only in bursts
- As security issues are time sensitive we need more consistency when working on the issues
- Without this we will loose creditability as users who are concerned about security will get the impression that security isn't a high priority for us
We need to get a web presence and email pkgsrc-user@ and tech-pkg@ etc. to raise our profile
We need to open up the lines of communication a bit better and stop being just a backend process

Been through some changes in the last year
Grown from 1173 active entries to 1847 active entries
Now has a file format version that gets checked
This means we can add features and handle the associated versioning a lot better
Now supports date ranges which reduce the amount of entries that you have to enter for a single vulnerability (e.g. php>=5.0<5.1.2nb1)

Ignore Vulnerabilities support was added . . . then removed about 6 months later
Unique vulnerability IDs have also come and gone (pkgvulnid)
IMHO the concept of having unique ids was a good one as it provided an absolute way to refer to a single vulnerability in a package
This make support easier as a user can report "Why is id XXX still showing as vulnerable ..." and we'll know exactly what they are talking about
I think it would be a good thing to reintroduce with some thought behind how we are going to use it in the future and document it properly

BUILDLINK_RECOMMENDED was previously used to force dependency bumps but that functionality has now been removed
In place of BUILDLINK_RECOMMENDED we now use BUILDLINK_ABI_DEPENDS which is for ABI changes only and not security changes
This means users are responsible for updates (using audit-packages to know for example)