Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: add mandatory test 6.1.37 #218

Open
wants to merge 1 commit into
base: 196-csaf-2.1
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions csaf_2_1/mandatoryTests.js
Original file line number Diff line number Diff line change
Expand Up @@ -43,3 +43,4 @@ export {
mandatoryTest_6_1_32,
mandatoryTest_6_1_33,
} from '../mandatoryTests.js'
export { mandatoryTest_6_1_37 } from './mandatoryTests/mandatoryTest_6_1_37.js'
191 changes: 191 additions & 0 deletions csaf_2_1/mandatoryTests/mandatoryTest_6_1_37.js
Original file line number Diff line number Diff line change
@@ -0,0 +1,191 @@
import Ajv from 'ajv/dist/jtd.js'

const ajv = new Ajv()

/*
This is the jtd schema that needs to match the input document so that the
test is activated. If this schema doesn't match it normally means that the input
document does not validate against the csaf json schema or optional fields that
the test checks are not present.
*/
const inputSchema = /** @type {const} */ ({
additionalProperties: true,
optionalProperties: {
document: {
additionalProperties: true,
optionalProperties: {
tracking: {
additionalProperties: true,
optionalProperties: {
generator: {
additionalProperties: true,
optionalProperties: {
date: { type: 'string' },
},
},
initial_release_date: { type: 'string' },
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Missing the current_release_date

current_release_date: { type: 'string' },
revision_history: {
elements: {
additionalProperties: true,
optionalProperties: {
date: { type: 'string' },
},
},
},
},
},
},
},
vulnerabilities: {
elements: {
additionalProperties: true,
optionalProperties: {
disclosure_date: { type: 'string' },
discovery_date: { type: 'string' },
flags: {
elements: {
additionalProperties: true,
optionalProperties: {
date: { type: 'string' },
},
},
},
involvements: {
elements: {
additionalProperties: true,
optionalProperties: {
date: { type: 'string' },
},
},
},
remediations: {
elements: {
additionalProperties: true,
optionalProperties: {
date: { type: 'string' },
},
},
},
threats: {
elements: {
additionalProperties: true,
optionalProperties: {
date: { type: 'string' },
},
},
},
},
},
},
},
})

const validate = ajv.compile(inputSchema)

/**
* This regex validates a date against RFC 3339 section 5.6.
* See: https://datatracker.ietf.org/doc/html/rfc3339#section-5.6
*/
export const dateRegex =
/^\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(\.\d+)?(Z|[+-]\d{2}:\d{2})$/

/**
* Validates the given date against RFC 3339 section 5.6.
*
* @param {string} date The date to validate
*/
export const isValidDate = (date) => {
/*
Here we first check the string against the regex which catches format errors.
But since this is not enough we convert it using the `Date` constructor.
The `.getTime()` method of a JS date returns `NaN` in case of an
invalid date (e.g. days, hours out of range etc.)
*/
return (
Boolean(dateRegex.exec(date)) && !Number.isNaN(new Date(date).getTime())
)
}

/**
* This implements the mandatory test 6.1.37 of the CSAF 2.1 standard.
*
* @param {any} doc
*/
export function mandatoryTest_6_1_37(doc) {
/*
The `ctx` variable holds the state that is accumulated during the test ran and is
finally returned by the function.
*/
const ctx = {
errors:
/** @type {Array<{ instancePath: string; message: string }>} */ ([]),
isValid: true,
}

if (!validate(doc)) return ctx

/**
* This function validates the given date and generates and error on
* `ctx` if it is not valid.
*
* @param {string | undefined} date The date to validate
* @param {string} path The json path to the date
*/
const validateDate = (date, path) => {
if (date === undefined) return

if (!isValidDate(date)) {
ctx.errors.push({
instancePath: path,
message: `invalid date`,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we be more specific and tell what exactly was wrong with the date?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mhm, we could divide into two errors. One where the date does not match specified format and one where the date is invalid.

})
ctx.isValid = false
}
}

validateDate(
doc.document?.tracking?.generator?.date,
'/document/tracking/generator/date'
)
validateDate(
doc.document?.tracking?.initial_release_date,
'/document/tracking/initial_release_date'
)
Comment on lines +151 to +154
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Missing current_release_date

validateDate(
doc.document?.tracking?.current_release_date,
'/document/tracking/current_release_date'
)

doc.document?.tracking?.revision_history?.forEach((history, index) => {
validateDate(
history.date,
`/document/tracking/revision_history/${index}/date`
)
})

doc.vulnerabilities?.forEach((vulnerabiltiy, vulnerabilityIndex) => {
const prefix = `/vulnerabilities/${vulnerabilityIndex}`

validateDate(vulnerabiltiy.disclosure_date, `${prefix}/disclosure_date`)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
validateDate(vulnerabiltiy.disclosure_date, `${prefix}/disclosure_date`)
validateDate(vulnerabiltiy.disclosure_date, `/${prefix}/disclosure_date`)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah interesting, do you have a test case where this fails? In my understanding, this would end up in two forward slashes.

validateDate(vulnerabiltiy.discovery_date, `/${prefix}/discovery_date`)

vulnerabiltiy.flags?.forEach((flag, index) => {
validateDate(flag.date, `${prefix}/flags/${index}/date`)
})

vulnerabiltiy.involvements?.forEach((involvement, index) => {
validateDate(involvement.date, `${prefix}/involvements/${index}/date`)
})

vulnerabiltiy.remediations?.forEach((remediation, index) => {
validateDate(remediation.date, `${prefix}/remediations/${index}/date`)
})

vulnerabiltiy.threats?.forEach((threat, index) => {
validateDate(threat.date, `${prefix}/threats/${index}/date`)
})
})

return ctx
}
38 changes: 38 additions & 0 deletions tests/csaf_2_1/mandatoryTest_6_1_37.js
Original file line number Diff line number Diff line change
@@ -0,0 +1,38 @@
import assert from 'node:assert/strict'
import {
isValidDate,
mandatoryTest_6_1_37,
} from '../../csaf_2_1/mandatoryTests/mandatoryTest_6_1_37.js'

describe('mandatoryTest_6_1_37', function () {
it('only runs on relevant documents', function () {
assert.equal(mandatoryTest_6_1_37({ document: 'mydoc' }).isValid, true)
})

describe('isValidDate', function () {
/*
A list of test cases to validate against the function. The `string` is the
date to check and the `boolean` marks if the date is expected to be valid or
invalid.
- `true` means the date is expected to be VALID
- `false` means the date is expected to be INVALID
*/
const testCases = /** @type {Array<[string, boolean]>} */ ([
['2024-01-01T00:00:00Z', true],
['2024-01-01T00:00:00.000Z', true],
['2024-01-01T00:00:00.0Z', true],
['2024-01-01T00:00:00.11111111Z', true],
['2024-01-01T00:00:00+01:00', true],
['2024-01-01T00:00:00.111111+01:00', true],
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would like to add a few more things here:

Suggested change
['2024-01-01T00:00:00.111111+01:00', true],
['2024-01-01T00:00:00.111111+01:00', true],
['2024-02-29T00:00:00.987564+01:00', true],
['2015-06-30T10:29:60-13:30', true],
['2015-06-30T23:59:60+00:00', true],
['2015-07-01T06:59:60+07:00', true],
['2016-12-31T00:00:60+23:59', true],
['2016-12-31T23:59:60+00:00', true],
['2017-01-01T02:59:60+03:00', true],
['2017-01-01T02:59:60+04:00', false],
['2024-02-30T00:00:00+01:00', false],
['2024-04-31T00:00:00+01:00', false],
['2024-13-31T00:00:00+01:00', false],

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mhm, I'm not sure if just the boolean was flipped but many of these cases fail for me:

These dates are invalid, but marked as valid in the sample

  • 2015-06-30T10:29:60-13:30
  • 2015-06-30T10:29:60-13:30
  • 2015-06-30T23:59:60+00:00
  • 2015-07-01T06:59:60+07:00
  • 2016-12-31T00:00:60+23:59
  • 2016-12-31T23:59:60+00:00
  • 2017-01-01T02:59:60+03:00
  • 2017-01-01T02:59:60+04:00

These dates are valid, but marked as invalid in the sample

  • 2024-02-30T00:00:00+01:00
  • 2024-04-31T00:00:00+01:00

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mhm, I'm not sure if just the boolean was flipped but many of these cases fail for me:

These dates are invalid, but marked as valid in the sample

  • 2015-06-30T10:29:60-13:30
  • 2015-06-30T10:29:60-13:30
  • 2015-06-30T23:59:60+00:00
  • 2015-07-01T06:59:60+07:00
  • 2016-12-31T00:00:60+23:59
  • 2016-12-31T23:59:60+00:00
  • 2017-01-01T02:59:60+03:00
  • 2017-01-01T02:59:60+04:00

These dates are valid, but marked as invalid in the sample

  • 2024-02-30T00:00:00+01:00
  • 2024-04-31T00:00:00+01:00

I'm pretty sure the boolean is right. The dates covered in the valid part refer to leap seconds.

For the invalid part: According to my count the February 2024 just had 29 days, not 30 and the April 30, not 31.

Am I missing something?

Copy link
Contributor Author

@domachine domachine Mar 6, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think, the dates covered in the valid part have 60 seconds which is invalid IMHO. I think in RFC 3339, 10:29:60 is expressed as 10:30:00 e.g.

For the invalid part: 2024-02-30T00:00:00+01:00 is marked with timezone offset +01:00 which converts to the following UTC date: 2024-02-29T23:00:00Z which is valid, since (as you noted) february had 29 days.

I hope, my understanding here is correct 🙈

['2024-01-01T:00:00+01:00', false],
['2024-01-01T25:00:00+01:00', false],
])

testCases.forEach((testCase) => {
it(`${testCase[0]} -> ${testCase[1]}`, () => {
assert.equal(isValidDate(testCase[0]), testCase[1])
})
})
})
})
1 change: 0 additions & 1 deletion tests/csaf_2_1/oasis.js
Original file line number Diff line number Diff line change
Expand Up @@ -21,7 +21,6 @@ const excluded = [
'6.1.34',
'6.1.35',
'6.1.36',
'6.1.37',
'6.1.38',
'6.1.39',
'6.1.40',
Expand Down