feat(ubuntu): add eol date for 20.04-ESM

[DmitriyLewen]

Description

Add EOL date for ubuntu 20.04-ESM - https://ubuntu.com/about/release-cycle#:~:text=Apr%202034-,20.04%20LTS%20(Focal%20Fossa),Apr%202032,-18.04%20LTS%20(Bionic

Blockers

Merge only after aquasecurity/trivy-db/pull/540

Related issues

• Close bug(ubuntu): Trivy doesn't support Ubuntu 20.04-ESM #8978

Related PRs

• feat(ubuntu): add support 20.04-ESM trivy-db#540

Checklist

• I've read the guidelines for contributing to this repository.
• I've followed the conventions in the PR title.
• I've added tests that prove my fix is effective or that my feature works.
• I've updated the documentation with the relevant information (if needed).
• I've added usage information (if the PR introduces new options)
• I've included a "before" and "after" example to the description (if the PR is a user interface change).

[knqyf263]

The time is fixed in the tests. Do we need to change the OS version?

[DmitriyLewen]

time doesnэt help for ubuntu 20.04-ESM. 20.04 is not outdated test.
We should take vulnerabilities from 20.04 for 20.04-ESM, and we did it before 20.04-ESM was added.
But now we take vulnerabilities from 20.04-ESM directly (because map contains 20.04-ESM)

trivy/pkg/detector/ospkg/ubuntu/ubuntu.go

Lines 140 to 155 in 312649c

	func (s *Scanner) versionFromEolDates(ctx context.Context, osVer string) string {
	if _, ok := eolDates[osVer]; ok {
	return osVer
	}
	// if base version (not ESM) is still actual
	// we need to use this version
	// e.g. Ubuntu doesn't have vulnerabilities for `18.04-ESM`, because `18.04` is not outdated
	// then we need to get vulnerabilities for `18.04`
	// if `18.04` is outdated - we need to use `18.04-ESM` (we will return error until we add `18.04-ESM` to eolDates)
	ver := strings.TrimRight(osVer, "-ESM")
	if eol, ok := eolDates[ver]; ok && clock.Now(ctx).Before(eol) {
	return ver
	}
	return osVer
	}

[knqyf263]

Thanks for your explanation. I missed that there is an early return if the version is in the EOL list.

Since this only happens once every two years, it’s not a major burden. However, it might be a bit confusing that updating the EOL list causes tests to fail, especially since we (or only I) tend to forget the details over two years.
Is there a way to add new entries without modifying the existing tests? Maybe passing a custom eolDates?

[DmitriyLewen]

hm.. It looks asgood idea.
Added in 07f066f

[knqyf263]

LGTM. I left a small comment, and it's up to you whether you want to incorporate that feedback.

[knqyf263]

nit: Since there is only one field, defining a new struct may be too much. We may want to add the field directly rather than embedding.

Suggested change

	*options
	eolDates map[string]time.Time

[DmitriyLewen]

Looks simpler, thanks!
updated in dd44435

[knqyf263]

Suggested change

	type Option func(*options)
	// WithEOLDates takes eol dates for testability
	func WithEOLDates(dates map[string]time.Time) Option {
	return func(opts *options) {
	opts.eolDates = dates
	}
	}
	type Option func(*Scanner)
	// WithEOLDates takes eol dates for testability
	func WithEOLDates(dates map[string]time.Time) Option {
	return func(s *Scanner) {
	s.eolDates = dates
	}
	}

[knqyf263]

Suggested change

	o := &options{
	eolDates: eolDates,
	}
	for _, opt := range opts {
	opt(o)
	}
	s := &Scanner{
	eolDates: eolDates,
	vs: ubuntu.NewVulnSrc(),
	}
	for _, opt := range opts {
	opt(s)
	}
	return s