4
With the newly revamped ubuntu-cve-tracker, it is much more like Debian's
5
kernel-sec list where you have these directories:
7
active/ (CVEs that need attention)
8
ignored/ (CVEs to be ignored, but want to track with special status/notes)
9
retired/ (CVEs that have been addressed)
11
ignored/ also has the file 'not-for-us.txt'.
13
check-cves pulls down the CVE list from MITRE, cross-references it with
14
ignored/, ignored/not-for-us.txt and retired/, then adds the new CVEs to
17
check-cves can also be used to import Debian DSAs and CVEs that are missing in
18
Ubuntu (requires secure_testing_path to be properly set up):
19
./scripts/check-cves --import-missing-debian
21
Sometimes MITRE and NVD are out of date. The locate_cves.py command can read
22
an mbox file and output a list of CVEs that are referenced in the mbox emails
23
that are not included in Ubuntu yet. This output can then be given to
25
./scripts/check-cves --untriaged <path to locate_cves.py output>
28
$ w3m -dump_source https://www.redhat.com/archives/rhsa-announce/<year>-<Month>.txt.gz > ~/<year>-<Month>.txt.gz
29
$ gzip -d ~/<year>-<Month>.txt.gz
30
$ ./scripts/locate_cves.py ~/<year>-<Month>.txt > ~/redhat.mbox
31
$ ./scripts/check-cves --untriaged ~/redhat.mbox
34
<save last month to mbox file, ~/oss-sec_raw.mbox>
35
$ ./scripts/locate_cves.py ~/oss-sec_raw.mbox > ~/oss-sec.mbox
36
$ ./scripts/check-cves --untriaged ~/oss-sec.mbox
38
Be sure to apt-get the following:
39
apt-get install python-configobj python-yaml python-genshi realpath python-progressbar python-pychart subversion
41
You might also be interested in $UST/utilities/maildir2mbox.py (though
42
locate_cves.py has maildir support).
46
The following values need to be configured in ~/.ubuntu-cve-tracker.conf:
48
- plb_authentication: path to Firefox LP cookies, used to authenticate
49
to LP in various tools that need it (sis-changes).
51
- secure_testing_path: path to Debian "secure-testing" GIT tree,
52
so that CVEs known to Debian can be shown while triaging
53
CVEs (check-cves). (get read-only access with:
54
'git clone https://salsa.debian.org/security-tracker-team/security-tracker.git')
55
- packages_mirror: path to archive-layout mirror of supported archs'
56
Release and Packages files (used by sis-generate-usn, with the mirror
57
created by a tool like packages-mirror).
58
- usn_tool: path to usn-tool bzr tree, used to manipulate USN databases
59
and for templates (sis-generate-usn).
60
- usn_storage: path to individual USN pickle database output when
61
generating a single USN database before merging into the master USN
62
database (sis-generate-usn).
63
- usn_db_copy: path to copy of master USN database, used when creating
64
a template for a USN where "N" != 1 (sis-generate-usn).
65
- usn_website: path to the USN website git tree:
66
https://git.launchpad.net/usn.ubuntu.com/
67
- partner_mirror: same as packages_mirror, but for the partner repo.
68
- debian_mirror: same as packages_mirror, but for Debian testing repo.
69
- mitre_loc: where to download the MITRE CVE database
70
- nvd_loc: where to download the NVD database
71
- kernel_team_tools_path: path to Ubuntu Kernel Team Tools git tree:
72
git://kernel.ubuntu.com/ubuntu/kteam-tools.git
74
Checkout the following branch:
75
$ bzr branch lp:ubuntu-qa-tools
77
Then add a sylink from UQT/common/lpl_common.py to UCT/scripts/lpl_common.py:
78
$ ln -s <path to>/ubuntu-qa-tools/common/lpl_common.py ./scripts/lpl_common.py
86
./scripts/check-cves http://cve.mitre.org/data/downloads/allitems.xml
87
./scripts/check-cves <file>
90
wget -N http://cve.mitre.org/data/downloads/allitems.xml
91
./scripts/check-cves ./allitems.xml
92
for i in $(seq 2004 $(date +%Y)) recent; do wget --quiet -N http://nvd.nist.gov/download/nvdcve-$i.xml; done
93
./scripts/check-cves ./nvdcve-2*.xml
95
When running check-cves:
96
'a'dd to add to active/ (see Triaging, below)
97
'i'gnore to add to ignored/not-for-us.txt (see Triaging, below)
98
's'kip don't do anything (will come up next time)
100
* Note: it may take a few seconds before prompts, as allitems.xml is a large
108
ubuntu-cve is PUBLIC. All comments should be professional, and there should be
109
no embargoed items in ubuntu-cve (until they are made public that is).
114
1. adjust the Candidate field
116
2. Add the Description from Mitre
118
3. Set the Priority, if you can at this time. Should be one of 'negligible',
119
'low', 'medium', 'high' or 'critical'. You can also override the Priority
120
field on a per package basis, by using 'Priority_<source package>: ...'
122
4. for each release, adjust PKG to be the source package for the software.
123
Note that for the kernel, upstream_PKG becomes 'upstream_linux-2.6' and the
124
releases should be 'dapper_linux-source-2.6.15', 'edgy_linux-source-2.6.17',
125
'feisty_linux-source-2.6.20', 'gutsy_linux-source-2.6.22', ...)
127
5. for each release, assign a status of (after the release_<source-package>
128
line): 'DNE', 'ignored', 'not-affected', 'needs-triage', 'needed', 'active',
129
'deferred', 'pending', 'released'
131
6. for each piece of software that is affected by this CVE, add extra
132
'$release_<source-package>' fields. An 'upstream_<source-package>' line
133
should also be included for each package (excepting special situations like
136
7. fill in any extra fields as needed (eg notes, references to patches,
137
Assigned-to, discoverer, etc). If there are patches available, then use:
145
Eg, for source package 'foo' that has a debdiff in launchpad, use:
148
debdiff: https://bugs.launchpad.net/ubuntu/+source/foo/+bug/XXXXXX
150
If a CVE only affects a binary in universe (from a source in main),
151
this can be marked using a Tag field. E.g:
153
Tags_foo: universe-binary
155
A package may not be supported by the Ubuntu Security team, but might be by
156
another Canonical team (eg linux-armadaxp is in main, but not officially
157
supported by the security team). This can be marked like so:
160
If a package has been protected by some sort of pro-active security measures,
161
mark from the list of "apparmor", "stack-protector", "fortify-source",
162
"symlink-restriction", "hardlink-restriction", "heap-protector", "pie" etc:
164
Tags_bar: stack-protector
165
Tags_baz_trusty: stack-protector
167
Use the above tags if the protection will be mentioned in the USN and/or the
168
protection mechanism is shown to protect against the vulnerability. Also note
169
that the tag is per release only, so you must say each release that is
170
protected (ie, in the above example, baz on trusty is protected, but not
171
lucid or precise). Valid tags are in 'valid_tags' in cve_lib.py.
173
8. Check Debian's secure-testing data/embedded-code-copies to see if any
174
other software is to be included in this CVE
179
Be sure list why and what piece of software it is. Eg:
180
Unpackaged software (Does Not Exist): 'DNE - PhpNuke'
181
Totally alien stuff (Not For Us): 'NFU - Cisco IOS'
183
CVEs that affect Ubuntu releases can also be ignored. This is most often done
184
for packages that exist in a previous release, but that release has reached End
187
upstream_foo: released (1.2.3)
188
lucid_foo: ignored (reached end-of-life)
189
precise_foo: released (1.2.2-1ubuntu1.2)
190
trusty_foo: not-affected (1.2.3-1)
191
utopic_foo: not-affected (1.3.0-1)
197
These are very similar to the Debian priorities, but with some differences.
198
Priorities can be roughly mapped as:
200
negligible Something that is technically a security problem, but is
201
only theoretical in nature, requires a very special
202
situation, has almost no install base, or does no real
203
damage. These tend not to get backport from upstreams,
204
and will likely not be included in security updates unless
205
there is an easy fix and some other issue causes an update.
207
low Something that is a security problem, but is hard to
208
exploit due to environment, requires a user-assisted
209
attack, a small install base, or does very little damage.
210
These tend to be included in security updates only when
211
higher priority issues require an update, or if many
212
low priority issues have built up.
214
medium Something is a real security problem, and is exploitable
215
for many people. Includes network daemon denial of service
216
attacks, cross-site scripting, and gaining user privileges.
217
Updates should be made soon for this priority of issue.
219
high A real problem, exploitable for many people in a default
220
installation. Includes serious remote denial of services,
221
local root privilege escalations, or data loss.
223
critical A world-burning problem, exploitable for nearly all people
224
in a default installation of Ubuntu. Includes remote root
225
privilege escalations, or massive data loss.
230
For a given CVE, the package and release with status is encoded as:
232
<release>_<source-package>: <status> (<version/notes>)
234
DNE The package (for the given release) does not exist in the
237
needs-triage The vulnerability of this package (for the given release)
238
is not known. It needs to be evaluated. (No version/notes)
240
not-affected This package (for the given release), while related to the
241
CVE in some way, is not affected by the issue. Notes
242
should contain further information, if needed. For example,
243
if a given source package is vulnerable to a CVE, but the
244
compiled binary is not (for example, linked to use a
245
system copy instead of an internal-to-source copy of a
246
library, and the CVE is about the internal copy). For
247
such a situation, the note should include the research
248
about why the binary is not affected by the CVE. Another
249
example is when an earlier or later version of the package was
250
affected, but the current version is not. If a package
251
was fixed during a devel release by someone outside of the
252
security team, it is appropriate to put the version that
253
fixed the issue in the note. If a note is too long,
254
it can be moved to the top-level "Notes" section. Examples
255
of common notes used with not-affected:
257
linked against (poppler|system libraries|etc...)
258
(MacOS X|Windows|Redhat) only
259
not included in package
260
register_globals not supported
261
network listening disabled by default
264
needed This package (for the given release) is vulnerable to the
265
CVE and needs fixing. (Notes are valid.)
267
active The package (for the given release) is vulnerable to the
268
CVE, needs fixing, and is actively being worked on by
269
the person belonging to the IRC nick in the "Assigned-to"
270
field. (Notes are valid.)
272
ignored This package (for the given release), while related to the
273
CVE in some way, is being ignored for some reason. The
274
"notes" should detail why. This is generally used when
275
a given CVE's priority is "negligible", and a firm
276
determination has been made to not fix a given release.
278
pending This package (for the given release) is vulnerable, and
279
an update is pending, usually waiting for upload or
280
publication. The "version" should be the version containing
283
deferred The package (for the given release) is vulnerable, the problem
284
is understood, but has been deferred for some reason. The
285
"notes" need to explain further. If a date was specified eg
286
"deferred (2012-01-01)" the date indicates the date the CVE
287
was put in the deferred state.
289
released The package (for the given release) was vulnerable, but
290
an update has been uploaded and published. The "version"
291
should be the version where the fix first appeared. This
292
status should also be used for when the 'devel' release is
293
fixed due to Ubuntu contributed changes (not-affected should be
294
used when a non-Ubuntu contributed sync from Debian fixes the
298
Community Supported Packages
299
----------------------------
300
To most accurately reflect reality in community supported packages in the
301
archive, the following guidelines should be used when triaging community
304
1. CVEs in community supported packages for EOL released should follow the EOL
305
for the release (ie desktop/universe is 18 months for non-LTS, 3 years for LTS,
306
5 years for server). If based on the above the release is EOL, then the status
307
of the CVE should be 'ignored (reached end-of-life). See 'End of Life' section
308
for more information. Eg:
309
upstream_foo: released (1.2.3)
310
lucid_foo: ignored (reached end-of-life)
313
2. Look carefully at MITRE versions. If it has a 'fixed in' or 'less than',
314
adjust 'upstream' field accordingly to use this. Mark later versions as
315
'not-affected' and earlier as 'needed. be careful and leave as 'needs-triage'
316
if status is not clear for multiple branches (ie 1.2 vs 1.4). The 'upstream'
317
field may contain multiple versions, eg 'upstream_foo: released (1.0.1, 1.2).
319
3. If Debian has a fix in its development releases (unstable or testing),
320
prefer upstream version to Debian version in 'upstream' field, except where it
321
is fixed in Debian in an earlier version than upstream or no info on upstream
322
version is available.
327
When a CVE fix is released, must manually update the CVE file in active/
328
with the appropriate information. Then 'check-syntax' (see below)
329
and 'bzr mv' it to retired/.
334
Useful commands are (all are run from within the top-level directory):
336
Verify syntax of CVE-* files
337
./scripts/check-syntax
339
To commit, use this command:
340
./scripts/check-syntax && bzr ci
343
./scripts/ubuntu-table
345
Full listing, flagging packages in main:
346
./scripts/ubuntu-table --supported
348
Show all active CVEs for supported (main) packages:
349
./scripts/ubuntu-table --supported 2>/dev/null | grep SUPPORTED
351
Number of active CVEs that are in main:
352
./scripts/ubuntu-table --supported 2>/dev/null | grep SUPPORTED | wc -l
354
Show all active CVEs for partner packages:
355
./scripts/ubuntu-table --supported 2>/dev/null | grep PARTNER
357
Show all out-of-sync CVEs for the devel release:
358
./scripts/ubuntu-table --supported | grep 'out of sync' | awk '{if ($8 == "needed*" || $8 == "needs-triage*") { print $0 }}'
360
Show open CVEs for a particular source package:
361
./scripts/pkg_status pkgname1 pkgname2 ...
362
./scripts/pkg_status -f pkgname1 pkgname 2 ... (full listing)
364
Show CVE history for a particular source package:
365
./scripts/pkg_history pkgname1 pkgname2 ...
366
./scripts/pkg_history -f pkgname1 pkgname 2 ... (full listing)
368
Show CVEs with undefined priorities (ie untriaged):
369
./scripts/ubuntu-table --untriaged
371
Create/edit a new CVE (eg if don't want to wait for check-cves):
372
./scripts/active_edit -p package -c CVE-YYYY-XXXX
374
Create a new CVE that does not have a CVE identifier yet:
375
./scripts/active_edit -p package -c CVE-YYYY-NNN1
376
./scripts/active_edit -e -p package -c CVE-YYYY-NNN1
378
See the status of specific CVEs:
379
./scripts/cve_status CVE-2006-4519 CVE-2007-2949 CVE-2007-3741
381
See the status of specific CVEs without viewing the full entry:
382
./scripts/cve_status -s CVE-2006-4519 CVE-2007-2949 CVE-2007-3741
384
See all bugs with priority of medium or higher:
385
./scripts/ubuntu-table --supported | egrep -v '[[:space:]]+(untriaged|negligible|low)$'
387
See a listing of packages with number of CVEs attached to them, weighted by
389
./scripts/cve_packages
390
./scripts/cve_packages -m (just supported (main, restricted and partner))
391
./scripts/cve_packages -u (just unsupported (universe and multiverse))
392
./scripts/cve_packages -t (just totals)
393
./scripts/cve_packages -a (with assignees)
395
See ordering of SUPPORTED packages that need updates:
396
./scripts/cve_packages -m | grep '^[0-9]' | sort -n
397
./scripts/cve_packages -m -S | grep '^[0-9]' | sort -n (skip devel)
398
./scripts/report-date.py -S -m (skip devel)
400
See all CVE assignments:
401
./scripts/cve_packages --by-assignee
403
See CVE assignments by individual:
404
./scripts/cve_packages --by-assignee --assignee=...
405
./scripts/cve_packages -a --assignee=...
407
Pull ubuntu-security bugs from Launchpad marked as 'In Progress':
408
./scripts/pull-in-progress.py
409
./scripts/pull-in-progress.py -u (updates active CVEs with patch information)
411
See CVEs with patches:
412
./scripts/cve_patches
413
./scripts/cve_patches -s (only supported)
415
Show items needing to be retired:
416
./scripts/ubuntu-table > /dev/null
417
./scripts/cve_need_retire
418
./scripts/cve_need_retire -f (full listing)
419
./scripts/cve_need_retire -p (list path to CVE)
422
bzr mv $(./scripts/cve_need_retire -p) ./retired/
424
Ignore open CVEs for a certain release:
425
./scripts/pkg_status webkit | cut -f1 -d' ' | xargs -I{} ./scripts/mass-cve-edit -p webkit -r trusty -s ignored -v 'reached end-of-life' {}
427
Mark CVEs as "released" from known USNs:
428
wget -N http://usn.ubuntu.com/usn-db/database.pickle
430
or use rsync if you have access:
431
rsync -v --progress -e ssh people:~ubuntu-security/public_html/usn/database.pickle ./database.pickle
433
or pull through bzip2:
434
curl -s http://usn.ubuntu.com/usn-db/database.pickle.bz2 | bzcat > ./database.pickle
436
./scripts/sync-from-usns.py database.pickle -u
438
Check syntax without regard to new (USN'd) packages:
439
CVE_ALLOW_NEWER_PKGS=1 ./scripts/check-syntax
441
Check for releases in devel that are higher than upstream fixed versions:
442
./scripts/sync-from-versions.py -u
444
Check for releases in 'precise' that are higher than upstream fixed versions
445
for chromium-browser:
446
./scripts/sync-from-versions.py -u -r precise -p chromium-browser
448
Refresh descriptions from Mitre:
449
./scripts/check-cves --refresh
451
Refresh descriptions and publication dates from NVD:
452
wget -N http://nvd.nist.gov/download/nvdcve-200{5,6,7,8}.xml
453
./scripts/check-cves --refresh nvdcve-200*.xml
455
Update state for a bunch of CVEs for a particular package and release:
456
./scripts/mass-cve-edit -p <package> -r <release> -v <version> -s <state> CVE...
458
./scripts/mass-cve-edit -p seamonkey -r karmic -s released -v 1.1.17+nobinonly-0ubuntu1 CVE-2009-1841 CVE-2009-1838 CVE-2009-1836 CVE-2009-1835 CVE-2009-1392 CVE-2009-1832 CVE-2009-1833 CVE-2009-1311 CVE-2009-1307
462
./scripts/report-todo
463
./scripts/report-todo -S (don't include devel)
464
./scripts/report-todo-numbers
465
./scripts/report-todo-numbers -S (don't include devel)
467
./scripts/html-report
468
./scripts/html-report -S (don't include devel)
470
./scripts/monthly-report
472
All CVEs fixed in USNs for 10.04, with priorities:
473
./scripts/report-updates.py --with-eol | grep lucid
475
Kernel Report Example:
476
./scripts/ubuntu-table -p linux -P linux -S | cut -c1-14,36-95
481
Embargoed items are supported in the following scripts in all the scripts
482
except sync-from-usns.py. If no CVE has been assigned yet, an embargoed item
483
should be prefixed with 'EMB-', followed by any combination of alphanumerics
488
To include embargoed items simply create a symlink from 'embargoed' to
489
the directory holding embargoed items. ubuntu-cve-tracker will not
490
use 'embargoed' unless it is a symlink.
493
Non-CVE Vulnerabilties
494
----------------------
495
If find a non-CVE assigned vulnerability, then:
497
1. report the bug to Debian
498
2. in ubuntu-cve, use 00boilterplate and create CVE-NEED-0001
499
3. if desired, email vendor-sec@lst.de and Cc cve@mitre.org asking for a CVE
500
4. file a bug in LP (assign to security-team if main, motu-swat if universe
502
Doing '1' may be enough if its in universe and not high priority, as
503
it will eventually find its way back to Ubuntu.
506
Stable Release Actions
507
----------------------
508
When a stable release is published, the active CVEs need to be adjusted to
509
reflect the new stable release. e.g. when trusty was published:
510
perl -pi -e 's/^((#?)devel_(.*))/$2trusty_$3\n$1/g' active/{CVE-,00boilerplate}*
511
The script tools will need to be adjusted as well. There is usually some
512
lag time between the new devel archive opening and the stable release
513
getting published. This means that "devel" will disappear from ubuntu-table
515
scripts/cve_lib.py should have the new release timestamp (in UTC) added
517
scripts/cve_lib.py should have an empty 'devel_release'.
519
Move all active CVEs and boilerplates from "devel" to release state:
520
./scripts/release-cycle-released $RELEASE
523
Development Release Actions
524
---------------------------
525
Fill in releases and devel_release in ubuntu-cve-tools/scripts/cve_lib.py
527
Move all active CVEs and boilerplates from latest release to devel state:
528
./scripts/release-cycle-devel-opens $LATEST_STABLE_RELEASE
530
Add release to non-ports and ports section of
531
ubuntu-cve-tools/scripts/packages-mirror
535
When a releases is end-of-lifed, all CVEs for that release must be updated.
538
1. add the release to the list of releases in 'eol_releases' in
542
$ sed -i 's/^<release>_\(.*\): \(needed\|needs\-triage\)/<release>_\1: \2 (reached end-of-life)/g' ./active/CVE-*
543
$ sed -i '/^<release>_\(.*\): /d' ./active/00boilerplate*
545
3. retire the CVEs (see 'Retiring items', above)
547
This should generally be done as 1 commit with no other changes, for easier
551
Ubuntu variants with PPA overlays
552
---------------------------------
553
Ubuntu Touch and Ubuntu Core use a ppa overlay on top of an Ubuntu base
554
release. cve_lib.py will list these as '<base>/<ppa name>' in all_releases
555
and release_names. The <base>-<ppa name>-supported.txt files list the source
556
packages that comprise these variant releases. CVEs will use '<base>/<ppa
557
name>' as the release name for CVE tracking purposes.
559
Variants where the Ubuntu base release is EOL are possible, as with Ubuntu
560
Touch 15.04. In these instances, the base release is marked end of life while
561
the variant release is still active and updates will only be provided to the
562
variant release via its ppa overlay.
564
Currently used variant overlay PPAs:
565
* Ubuntu Touch: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay/+packages
566
* Ubuntu Core 15.04: https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages
568
Images built from these PPAs employ batched OTA (over the air) updates. As
569
such, when a package is uploaded to the PPA (or the base release distro version
570
if before the EOL) it should be marked as 'pending (<version>)' and only after
571
the stable image (ie, the one users use) has the package should the CVE be
572
marked as 'released'. The following will report CVEs in this pending state for
574
$ ./scripts/cve-alert.sh ubuntu-core
575
$ ./scripts/cve-alert.sh ubuntu-touch
577
Once the stable images have been updated, use the mass-cve-edit tool to mark
578
the CVEs as 'released (<version>)'.
583
When a new backport kernel is added, update scripts/cve_lib.py's
584
kernel_srcs and description_overrides.
586
Then update the 00boilerplate.linux with its entry, add that entry to each
587
CVE with an entry for the LTS the kernel was added to, and update all the
588
statuses for the newly added kernel, based off the version it will be
589
branched from. For example, to add a new kernel backported from Vivid to
590
the Trusty LTS release, run the following command:
592
./scripts/add-backport-kernel -l trusty -b vivid
594
You must also add the new backport kernel to the end of the
595
$UQT/security-tools/kernel-abi-check script.
599
During the week between a new release and when devel opens, the pre-filled
600
CVE templates from ./scripts/process_cves will give devel_foo: DNE without
601
actually knowing if the package exists or not. Change DNE to the proper
602
value for what the new devel release will need once it is opened.
607
scripts/cve_lib.py should have new release added to 'releases',
608
'devel_release', and 'release_names'.
611
Vim syntax highlighting/checking
612
--------------------------------
613
$UCT/scripts/cve.vim can perform rudimentary syntax checking for CVEs. To use:
614
$ mkdir -p ~/.vim/syntax
615
$ ln -s $UCT/scripts/cve.vim ~/.vim/syntax/cve.vim
617
Then add to ~/.vimrc something like:
618
autocmd BufNewFile,BufRead CVE-[0-9][0-9][0-9][0-9]-[0-9][0-9][0-9][0-9] set syntax=cve
620
You can also option turn it on within vim using:
623
Pre-commit Syntax Checking
624
--------------------------
625
To perform pre-commit syntax checking on only the files that have been
626
modified in the Bazaar tree, the following hook can be used. If an error is
627
discovered, the check-syntax output will be printed and then you'll have the
628
opportunity to ignore the errors or to exit immediately. To preemptively
629
avoid running check-syntax, you can set UCT_IGNORE_CHECK_SYNTAX=1 in the
632
(Please see $UST/bzr-tools/plugins/uct-check_syntax.py for the latest
633
version of this plugin.)
635
mkdir -p ~/.bazaar/plugins/hooks
636
cat > ~/.bazaar/plugins/hooks/__init__.py <<EOM
638
from bzrlib.branch import Branch
640
def run_tests(local, master, old_revno, old_revid, new_revno, new_revid, tree_delta, new_tree):
641
#print local, master, old_revno, old_revid, new_revno, new_revid, tree_delta, new_tree
643
if 'ubuntu-cve-tracker' in master.base and not os.environ.has_key('UCT_IGNORE_CHECK_SYNTAX'):
647
if local is not None:
650
local_branch = master
651
old_tree = local_branch.basis_tree()
659
iterator = new_tree.iter_changes(old_tree)
660
for (file_id, paths, changed_content, versioned, parent,
661
name, kind, executable) in iterator:
662
if (changed_content and paths[1] is not None):
663
changed_files.append(paths[1])
669
if len(changed_files) > 0:
671
(fd, filename) = tempfile.mkstemp(prefix="ucthook-")
673
handle = os.fdopen(fd, 'w')
674
handle.write('\n'.join(changed_files))
678
rc = subprocess.call(['./scripts/check-syntax', '--verbose',
679
'--filelist', filename])
681
if os.path.exists(filename):
687
sys.stdout.write('Found syntax errors. Enter "ignore" to continue or anything else to exit: ')
688
if raw_input() != 'ignore':
691
Branch.hooks.install_named_hook('pre_commit', run_tests, 'CVE Tracker tests')
696
Packages that share a codebase or are rebranded share the same vulnerabilities.
699
firefox-3.0 and xulrunner 1.9 share codebase
700
iceweasel = rebranded firefox
702
Mass-update kernel team "released" tags to use correct rc versions:
704
sed -i -e 's/^\(upstream_linux.*: released (2\.6\...\)-\(rc.*)\)/\1~\2/g' active/CVE-*
709
It is important to run check-cves on a regular basis. A suggested schedule is:
711
Monday: check-cves nvdcve-2*.xml ; check-cves --import-missing-debian
712
Wednesday: check-cves allitems.xml ; check-cves --refresh nvdcve-*.xml
713
Friday: check-cves nvdcve-recent.xml
715
MITRE is the definitive CVE database, but NVD contains the same information,
716
updates their database more frequently and also lists the PublicDate. Using the
717
above schedule allows our database to stay up-to-date with the NVD, and ensure
718
that our descriptions are also up to date. For CVEs where the PublicDate is
719
wrong, we can override the value using the "CRD" field instead.
721
Since we want to keep a record of what the PublicDate was when the
722
USN published, USN publication should include the addition of the
723
"PublicDateAtUSN" field, which duplicates PublicDate, in case it changes
724
later. When answering the question "When did a CVE go public?" the
725
scripts will use CRD over PublicDateAtUSN over PublicDate. Times should
726
include the timezone; UTC is preferred. If no time is specified during
727
coordination, 14:00:00 UTC is recommended.
729
Eg: PublicDateAtUSN: 2009-03-27 23:45:00 UTC
731
Individual CVEs not in the databases yet can also be added with
732
scripts/active_edit. Be sure to use the '--embargoed' flag when adding CVEs
733
that are not public yet (and double check that it wasn't accidentally added
734
to the public tracker).
736
If you setup mitre_loc and nvd_loc in ~/.ubuntu-cve-tracker.conf, then this
737
can all be taken care of for you with:
738
$ ./scripts/process_cves
739
$ ./scripts/process_cves [Mon|Wed|Fri]
741
Specifying anything other than Mon, Wed, or Fri simply runs check-cves on
744
Example ~/.ubuntu-cve-tracker.conf setup for the security team:
745
mitre_loc="people.canonical.com:/home/ubuntu-security/cache"
746
nvd_loc="people.canonical.com:/home/ubuntu-security/cache"
748
Sometimes MITRE is behind in getting CVEs into the database. It is recommended
749
that http://www.openwall.com/lists/oss-security/ also be reviewed for new CVE
750
assignments for packages in main.
755
For stable releases, "scripts/sync-from-usns.py" should flip statuses to
756
"released". "scripts/sync-from-versions.py" can also be used for stable
757
releases when specifying '-r <release>', which might be useful for things
758
that are in universe but get new upstream versions.
760
For the devel release, only "scripts/sync-from-versions.py" should flip
761
statuses to "released". (The "--stable-pending" option will break this rule
764
The version (status comment) on a "pending" or "released" is considered
765
canonical. The USN database, however, will show when a fix was first
766
published to the -security pocket, and may have a later version.
768
Notes about what to do with kernel bugs and the tracker:
772
bug -> lp (and if it's a dup, update to master)
774
When description has "Placeholder" only (i.e. new bug):
775
DNE -> (New) -> Invalid
776
not-affected -> (New) -> Invalid
777
pending -> (New) -> Fix Committed
778
released -> (New) -> Fix Released
779
Patches:...upstream: -> "Break-Fix: BROKEN_SHA FIXED_SHA" (multiple)
784
pending -> (Invalid,New,Confirmed,Triaged,In Progress)->Fix Committed
785
released -> Fix Released
786
not-affected -> (New)->Invalid
787
ignored -> (New)->Invalid
788
[priority] -> Importance
789
deferred skipped (ie no processing)
791
needed <- Confirmed/Triaged/In Progress
793
not-affected <- Invalid (double-check with DNE)
794
Patches:...upstream: <- "Add-Break-Fix: SHA SHA" (multiple)
795
Patches:...upstream: <- "Del-Break-Fix: SHA SHA" (multiple)
796
deferred skipped (ie no processing)
799
Description: -> Description with shas...
800
Patches:...upstream: -> "Break-Fix: BROKEN_SHA FIXED_SHA" (multiple)
802
Closed bug that needs a SHA change:
804
- dup old bug to new bug
807
- sha1 introduced CVE, sha1 fixes it (if one sha1, needs another)
808
- "Patches_linux" new identifier "break-fix" with introduced/fixed-by shas
809
- "introduced-by" can be either sha or rc1 tag ("v2.6.35-rc1") or "-" (infinity)
added
removed
README
