internal/rpm: accept every type in a tag's class when loading package info - #2022
Open
arpitjain099 wants to merge 1 commit into
Open
arpitjain099 wants to merge 1 commit into
arpitjain099 wants to merge 1 commit into
Conversation
… info Info.Load asserted one concrete Go type per tag, but the header verifier deliberately accepts an entry whose type merely shares a class with the type named in the tag table. checkTagType says so directly: "Some versions of string are typed incorrectly in a compatible way". ReadData returns the type the entry declared, not the one the tag table expects, so a header that verifyInfo has just accepted could reach an assertion that does not hold. A Name tag declared as an i18n string or a string array yields a []string, and the assertion to string panics. The same gap exists for every numeric tag, and for BDB headers, where the region is absent and checkTagType is skipped altogether. A panic here is not confined to the offending package: nothing on the path recovers, while the caller of Load already handles an error by reporting it and moving on to the next package in the database. Accept any member of the tag's class and report anything outside it. Signed-off-by: Arpit Jain <arpitjain099@gmail.com>
Member
|
I'm disinclined to accept this without evidence of this happening in the wild. Rpm tags have documented types, which are the ones used in the code. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Info.Loadasserts one concrete Go type per tag, but the header verifier does not guarantee one.verifyInfoaccepts an entry whoseTypemerely shares a class with the type named in the tag table, andcheckTagTypesays why:TypeString,TypeStringArrayandTypeI18nStringare allclassString.ReadDataswitches on the type the entry declared rather than on the tag, so aNameentry declared as an i18n string or a string array comes back as a[]stringwhileLoaddoesv.(string). The result is a panic on a header the verifier has just accepted:The same gap covers every numeric tag, since
TypeChar,TypeInt8,TypeInt16,TypeInt32andTypeInt64shareclassNumericand yield five different slice types against a singlev.([]int32). It is wider still for BDB headers, where there is no region,typecheckis false andcheckTagTypeis skipped entirely.Worth noting that this is not contained to the one bad package. Nothing on the path recovers, whereas
Loadreturning an error is already handled: the iterator indatabase.goyields it and continues to the next package in the database. So a header like this currently takes down more than it needs to.This adds small helpers that accept any member of the tag's class, widening the numeric variants to
int32, and report anything genuinely outside the class.Verification: a new test in
internal/rpmrewrites the type field of an entry inrpmdb/testdata/package.headerand runs the result through the realParseHeader, so the header goes throughverifyInfoon the way in. It panics on main and passes here, recoveringname="crypto-policies" version="20210213"in all three cases.go test ./internal/... ./rpm/...is unchanged against main, 17 packages, no failures either side.