[Sensitive Information] US Passport Number - #58
Conversation
| string key = 2; // OAuth Application Secret (prefix: sq0csp-) | ||
| } | ||
|
|
||
| message USPassportNumber { |
There was a problem hiding this comment.
I don't think you need to create a proto type for these, since the type is always sensitiveinformation.SensitiveInformation
There was a problem hiding this comment.
oversight from the merge. i'll remove it now
|
Yes it does, beside the .proto looks ready to be merged |
There was a problem hiding this comment.
Why are the proto changes required?
There was a problem hiding this comment.
there was a letf-over proto object that was not needed, but compiled in. the new version contains the up-to-date compiled proto objects
There was a problem hiding this comment.
Given that proto objects are not modified by the PR after all, can't we just leave them as-is?
There was a problem hiding this comment.
i had a wrong assumption about this. reverted the file to the version in main,
| FromMatch: func(blob []byte, keywordMatch bool) (sensitiveinformation.SensitiveInformation, bool) { | ||
| likelihood := sensitiveinformation.LikelihoodUnlikely | ||
| if keywordMatch { | ||
| likelihood = sensitiveinformation.LikelihoodVeryLikely |
There was a problem hiding this comment.
I am willing to bet they'll want to downgrade it to LikelihoodLikely. VeryLikely is rather for stuff we were able to verify checksum, or something similar.
|
|
||
| var ( | ||
| keywordsRe = simpleregex.KeywordsRe([]string{ | ||
| `\b\w*passport\w*\b`, |
There was a problem hiding this comment.
How is \b\w*passport\w*\b different from just passport ?
There was a problem hiding this comment.
the basic idea is to match passport within a boundary with an arbitrary prefix and/or suffix. for example, that regex will match all of these:
passportpassport_nous_passportus_passport_num
There was a problem hiding this comment.
Makes sense. But isn't the same achieved by just using passport?
In other words: can you point out what is filtered out by this construction?
There was a problem hiding this comment.
technically yes, with the exception that i'd need to remove the boundary (\b). let me see if there's any space for some optimization
There was a problem hiding this comment.
@SzymonDrosdzol made some updates. i'd appreciate a look when you get the chance
7bd9574 to
0274912
Compare
… in extracted packages. PiperOrigin-RevId: 945701840
…nges in working directory instead of based on HEAD. Effectively, this change uses the programmatic equivalent of `git ls-tree HEAD` to determine the submodule SHA instead of the current `git submodule status`. A good explanation of the difference can be found here: https://stackoverflow.com/a/54238999 Falls back to using `git submodule status` when the SHA cannot be determined with the other method. PiperOrigin-RevId: 945863104
PiperOrigin-RevId: 948082439
Extractor was updated to parse package information & line number in a single-pass with a line-by-line scan, vs. using common MIME parsing library that doesn't have line number tracking. PiperOrigin-RevId: 948472912
The regex used to match per-requirement option was too aggressive, causing "-C" inside valid package names to be matched and trimmed into the wrong package names. Adding leading whitespace or new-line to the regex to prevent this issue PiperOrigin-RevId: 950622262
…libr. PiperOrigin-RevId: 950637626
PiperOrigin-RevId: 951144571
…PURL ID=sles now emits SUSE ecosystem and pkg:rpm/suse/ namespace. ID=azurelinux and ID=mariner now emit Azure Linux ecosystem and pkg:rpm/azurelinux/ namespace. Alpaquita (ID=alpaquita, APK) was already correctly routed. Fixes silent false-negative on OSV.dev for 20,561 SUSE advisories, 12,016 Azure Linux advisories, and 9,157 Alpaquita advisories. Routing table added: ID=sles → SUSE ecosystem, pkg:rpm/suse/ ID=azurelinux → Azure Linux ecosystem, pkg:rpm/azurelinux/ ID=mariner → Azure Linux ecosystem, pkg:rpm/azurelinux/
- Added sorting to transitivedependency (pomxml, requirements) enrichers for deterministic inventory ordering. - Add sorting to grpc queries to make it consistently snapshotable - Updated package name resolution in vulnmatch (osvdev, osvlocal) to handle GIT repo names, Go stdlib, and source/origin names for dpkg/apk packages. - Updated package version resolution to take into account redhat epochs. - Added support for purl TypeBrew and "git" ecosystem conversion in extractor. - Updated SPDX extractor to set package version from PURL and updated spdx_test.go. - Add support for the GIT ecosystem PiperOrigin-RevId: 951216522
ID=opensuse-leap from /etc/os-release fell through the rpmmeta.Metadata
switch with no case, producing an empty ecosystem string and making all
12,954 openSUSE OSV advisories unreachable.
Add a dedicated branch that constructs the suffix as "Leap " + VERSION_ID,
matching the format used by OSV.dev (e.g. "openSUSE:Leap 15.5").
Using VERSION_ID alone ("15.5") does not match any advisory.
The EcosystemOpenSUSE constant was already defined in
inventory/osvecosystem/parsed.go but never referenced in ecosystem.go.
Fixes: google#2203
Updated package comment to include PEP 621 compliance and details about parsing specific tables.
PiperOrigin-RevId: 956018290
PiperOrigin-RevId: 958255624
… a common directory for use in other language extractors. PiperOrigin-RevId: 959048498
…ctly instead of strings. PiperOrigin-RevId: 959257339
PiperOrigin-RevId: 960018336
PiperOrigin-RevId: 960018484
PiperOrigin-RevId: 960034856
PiperOrigin-RevId: 960740927
PiperOrigin-RevId: 960888732
…kages in SCALIBR PiperOrigin-RevId: 960924505
PiperOrigin-RevId: 960924547
PiperOrigin-RevId: 962124218
PiperOrigin-RevId: 962213017
PiperOrigin-RevId: 962613611
…fests optional. PiperOrigin-RevId: 962662583
…tracted from Java manifests. PiperOrigin-RevId: 962743048
Related to #57
I merged the behavior of both branches. Once this one is reviewed, the other PR/branch can be removed.