Migrate Gentoo importer to advisory V2#2090
Migrate Gentoo importer to advisory V2#2090ziadhany wants to merge 12 commits intoaboutcode-org:mainfrom
Conversation
ziadhany
changed the title
ziadhany
force-pushed
the
gentoo-migration
branch
from
77f89b8 to
7ef7684
Compare
|
gentoo importer V2 logs: gentoo importer V1 logs: |
ziadhany
force-pushed
the
gentoo-migration
branch
2 times, most recently
from
76f65a8 to
0bed9dd
Compare
ziadhany
force-pushed
the
gentoo-migration
branch
from
4c5830d to
ca3fc16
Compare
ziadhany
force-pushed
the
gentoo-migration
branch
from
76c1f80 to
a5e7bd4
Compare
keshav-space
left a comment
keshav-space
left a comment
There was a problem hiding this comment.
@ziadhany Thanks, see some feedback below.
| if invert: | ||
| constraint = constraint.invert() |
There was a problem hiding this comment.
@ziadhany why do we invert fixed range, we should report fixed range as is.
There was a problem hiding this comment.
@keshav-space we have two type of package version
- unaffected
- vulnerable
GLSA-201405-01 , CVE-2014-0004
<affected>
<package name="sys-fs/udisks" auto="yes" arch="*">
<unaffected range="rge">1.0.5</unaffected>
<unaffected range="ge">2.1.3</unaffected>
<vulnerable range="lt">2.1.3</vulnerable>
</package>
</affected>
we invert the unaffected (safe_version) to get the affected version if it isn’t specified.
see line: 159, 162
the main question is that does the unaffected mean fixed range, if yes I should update this
There was a problem hiding this comment.
the main question is that does the unaffected mean fixed range, if yes I should update this
@ziadhany Yes, unaffected is fixed range see resolution section here https://security.gentoo.org/glsa/201405-01 so if we get unaffected range it should be treated as fixed range.
Also rge means revision greater than equals and rgt means revision greater than lets mention this in comments.
<unaffected range="ge">2.1.3</unaffected> is pretty straight forward it translates to fixed range vers:ebuild/>=2.1.3. But revision range are bit tricky here <unaffected range="rge">1.0.5</unaffected> translates to vers:ebuild/>=1.0.5|<1.1 see the interpretation here https://security.gentoo.org/glsa/201405-01
similarly for this advisory https://security.gentoo.org/glsa/202004-13 we have these unaffected range
<unaffected range="rge">2.23.3</unaffected>
<unaffected range="rge">2.24.3</unaffected>
<unaffected range="rge">2.25.4</unaffected>
<unaffected range="rge">2.26.2</unaffected>and these would be interpreted as fixed range
vers:ebuild/>=2.23.3|<2.24
vers:ebuild/>=2.24.3|<2.25
vers:ebuild/>=2.25.4|<2.26
vers:ebuild/>=2.26.2|<2.27
There was a problem hiding this comment.
@ziadhany I went through your pr aboutcode-org/univers#181 and I also reviewed the gentoo version documentation https://projects.gentoo.org/pms/8/pms.html#x1-250003.2. It turns out that gentoo packages do not follow any particular versioning standard, so it becomes difficult to create a range from a single version such that the range includes only revisions of that version.
The only reliable way to generate a bounded range for a revisione version is to retrieve all versions of a particular gentoo package and sort them as described here https://projects.gentoo.org/pms/8/pms.html#x1-260003.3 and then select the last revision of that version as the terminating bound. We cannot do that in this pipeline and it should be handled separately in an improver pipeline.
For now we can only capture what we are presented with, in the above example.
<unaffected range="rge">2.23.3</unaffected>
<unaffected range="rge">2.24.3</unaffected>
<unaffected range="rge">2.25.4</unaffected>
<unaffected range="rge">2.26.2</unaffected>we should create impacted package with these fixed version range.
vers:ebuild/>=2.23.3
vers:ebuild/>=2.24.3
vers:ebuild/>=2.25.4
vers:ebuild/>=2.26.2
| { | ||
| "package": { | ||
| "type": "ebuild", | ||
| "namespace": "dev-vcs", | ||
| "name": "subversion", | ||
| "version": "", | ||
| "qualifiers": "", | ||
| "subpath": "" | ||
| }, | ||
| "affected_version_range": "vers:ebuild/<=1.8.18", | ||
| "fixed_version_range": null, | ||
| "introduced_by_commit_patches": [], | ||
| "fixed_by_commit_patches": [] | ||
| } |
There was a problem hiding this comment.
Not right, for the unaffected range <unaffected range="ge">1.9.7</unaffected> and <unaffected range="rgt">1.8.18</unaffected> we should report vers:ebuild/>1.8.18 and vers:ebuild/1.9.7 as fixed version range and do not invert these and report it as affected vers.
|
@keshav-space Is this correct implementation? https://security.gentoo.org/glsa/201709-09 |
ziadhany
force-pushed
the
gentoo-migration
branch
from
3e4b4c6 to
cc9e228
Compare
Signed-off-by: ziad hany <ziadhany2016@gmail.com>
Signed-off-by: ziad hany <ziadhany2016@gmail.com>
Update the Gentoo get_safe_and_affected_versions function in advisory v2 Signed-off-by: ziad hany <ziadhany2016@gmail.com>
Signed-off-by: ziad hany <ziadhany2016@gmail.com>
Signed-off-by: ziad hany <ziadhany2016@gmail.com>
Signed-off-by: ziad hany <ziadhany2016@gmail.com>
Signed-off-by: ziad hany <ziadhany2016@gmail.com>
Signed-off-by: ziad hany <ziadhany2016@gmail.com>
Signed-off-by: ziad hany <ziadhany2016@gmail.com>
… and fixed_version_range for non-revision versions Signed-off-by: ziad hany <ziadhany2016@gmail.com>
Update the pipeline to use the new AdvisoryDataV2 Signed-off-by: ziad hany <ziadhany2016@gmail.com>
ziadhany
force-pushed
the
gentoo-migration
branch
from
cc9e228 to
d73249f
Compare
|
@keshav-space I am also getting an InvalidConstraintsError even after using the new implementation. see: |
Signed-off-by: ziad hany <ziadhany2016@gmail.com>
|
As we discussed in the weekly VulnerableCode meeting, we decided to have an |
2 participants
Issue: