Allow customizing semgrep configurations; correct rule matching glob #21126

purajit · 2024-07-03T20:19:06Z

Three things:

Allow configuring the config location; because of how the digest is
built, running semgrep via pants doesn't actually allow you to
configure this by passing --config, like the tool does. There is now
a config_name option which will be auto-discovered and hierarchically
applied to each relevant partition. This will potentially evolve into
a config_paths option which will allow users to specify a list of globs.

semgrep searches for rules recursively within a rules directory, so
reflect that in the globs. This isn't obvious in the documentation, but
it's the way it behaves, and also is explicit in the code.
https://github.com/semgrep/semgrep/blob/45699ace83dd61f19d6ea1e7452f32a0c1996735/cli/src/semgrep/config_resolver.py#L402

Finally, I flattened the glob for .semgrepignore. Currently, the glob
recursively matches all matching file names, but ultimately semgrep
just reads only what's in the current dir. In my testing of pants+semgrep
I did indeed notice the same behavior, that the .semgrepignores in lower
dirs were not being respected. An integration test confirmed the same.[1]
Supporting multi-level .semgrepignores is going to be
a significant effort, since it would involve actually parsing and interpreting
the config files, and also navigating the pitfalls of managing overlays of
ignore patterns. Instead, I chose to force it to being a singular file
path.

Here're some historical discussions about .semgrepignore: huonw#1, #18593 (comment)
https://github.com/semgrep/semgrep/blob/45699ace83dd61f19d6ea1e7452f32a0c1996735/src/targeting/Semgrepignore.ml#L124
https://semgrep.dev/docs/ignoring-files-folders-code#reference-summary

[1] The integration test which proves hierarchical semgrepignore doesn't work:

def test_semgrepignore_not_partitioned(rule_runner: RuleRunner) -> None:
    rule_runner.write_files({
        f"{DIR}/BUILD": "",
        f"{DIR}/.semgrep.yml": RULES,
        f"{DIR}/.semgrepignore": FILE,
        
        f"{DIR}/a/.semgrepignore": FILE,
        f"{DIR}/a/BUILD": SINGLE_FILE_BUILD,
        f"{DIR}/a/{FILE}": BAD_FILE,
    })
    tgt = rule_runner.get_target(Address(f"{DIR}/a", target_name="f"))

    # run with these two semgrepignores in place
    results = run_semgrep(rule_runner, [tgt])
    assert len(results) == 1
    result = results[0]
    # doesn't get ignored
    assert "Ran 1 rule on 1 file: 1 finding" in result.stderr

    # run with a root semgrepignore
    rule_runner.write_files({
        ".semgrepignore": FILE,
    })
    results = run_semgrep(rule_runner, [tgt])
    assert len(results) == 1
    result = results[0]
    # finally, it's ignored
    assert "Ran 1 rule on 0 files: 0 findings" in result.stderr

purajit · 2024-07-04T07:59:38Z

Thoughts on working towards deprecating all default values for the
config globs?

The default values were deprecated in 1.38.0, which is coming up on 1
year now (Aug 2023). When I run the semgrep CLI for these versions I
even get the message

Versions prior to 1.43.0 will cease to work with Semgrep.dev after March 11th 2024, please upgrade.

Newer versions even actively warn against it.
https://github.com/semgrep/semgrep/blob/45699ace83dd61f19d6ea1e7452f32a0c1996735/CHANGELOG.md?plain=1#L2400-L2402
https://github.com/semgrep/semgrep/blob/45699ace83dd61f19d6ea1e7452f32a0c1996735/src/osemgrep/core/Migration.ml#L12-L14

The main argument to keeping it would be that the issue brought up in
the changelog doesn't apply here - people are only running semgrep
through pants within repos. However, I don't think pants should be
adding too much magic on top of a tool; it should mostly just help
integrate the system together and leave everything else up to the
underlying tool.

Would definitely require an actual deprecation process, though I dunno
how strict that is given semgrep is experimental. Definitely out of scope
of this PR, but I'm willing to do a follow-up.

purajit · 2024-07-04T08:14:56Z

And a second thought:

We might want to entirely do away with the multi-level config setup. It's
adds complexity purely because the pants backend defines this config
differently from semgrep.

semgrep doesn't behave hierarchically by nature; the pants backend works
because it calculates and injects the explicit --config params as needed.
It's also going to make the future of this backend more complicated for
two reasons:

Multiple config paths can be provided, and they can be directories or files. Currently we don't support files; the hierarchical nature adds a few steps to this process.
It can even be a URL, or name of a registry, which is currently unsupported in
the pants backend, and it would make it increasingly confusing if we said "files and dirs automatically get grouped hierarchically, but not URLs or registries", and we'd just be diverging from the main tool.

Some of the complexity can already be seen in this PR with the glob management.

kaos

Nice. I don't know this tool, but the changes look sane to me.

Being a experimental backend, we don't need deprecation cycles to change defaults etc.

docs/notes/2.23.x.md

purajit · 2024-07-04T09:21:56Z

Nice. I don't know this tool, but the changes look sane to me.

Being a experimental backend, we don't need deprecation cycles to change defaults etc.

Gotcha, will work on that next PR!

huonw · 2024-07-04T10:46:46Z

src/python/pants/backend/tools/semgrep/subsystem.py

@@ -51,6 +57,20 @@ class SemgrepSubsystem(PythonToolBase):
    register_lockfile = True
    default_lockfile_resource = ("pants.backend.tools.semgrep", "semgrep.lock")

+    config_paths = StrListOption(
+        default=[".semgrep"],


I like where this is going, but I wonder if we should go a bit further!

It feels weird to (a) just use this as a directory name, and (b) not allow customising the single-file search.

I see three options:

old code: no customisation, just attempt to hard-code the now-deprecated auto-search rules that semgrep has (**/.semgrep.yml,**/.semgrep.yaml, **/.semgrep/*.yml,**/.semgrep/*.yaml, with the magic around .semgrep/ directories)

this PR: partial customisation, allow changing the name of the directory in the last two globs there (and fix the recursive search within the folder, but that's not the thrust of the topic here)

proposal: put all the glob definitions into pants.toml

Suggested change

default=[".semgrep"],

default=["**/.semgrep.yml", "**/.semgrep.yaml", "**/.semgrep"],

And have the code append "", "**/*.yml" and "**/*.yaml" when expanding globs.

That is, run something equivalent to: PathGlobs(["**/.semgrep.yml", "**/.semgrep.yaml", "**/.semgrep", "**/.semgrep.yml/**/*.yml", "**/.semgrep.yaml/**/*.yml", "**/.semgrep/**/*.yml", "**/.semgrep.yml/**/*.yaml", "**/.semgrep.yaml/**/*.yaml", "**/.semgrep/**/*.yaml"])

(The fact this includes entries like **/.semgrep and "**/.semgrep.yml/**/*.yml" is a bit weird, but I think it's okay? They'll generally just be ignored.)

What do you think?

Haha, I was going to mention this in the pr but must've overwritten it.

I didn't do that precisely for the same reason you mentioned - didn't want to add too much at once and then deal with the globs. I was thinking of first just allowing customizing the dir, and then allowing files in the next pr.

I even had this named config_dir at first, and then changed the name so that allowing files could just be a simple release note rather than a breaking change.

I can add it to this pr itself.

Updated the way this config works

Thanks for updating this; this looks like a good incremental improvement, and I'm definitely sympathic to trying to keep the changes smaller.

didn't want to add too much at once

For the next steps, if you keep working on this, I'd still be interested in moving most of the path/globbing logic into the option in pants.toml.

For example, evolving to config_paths that takes a list of paths/globs (or maybe inspired by root_patterns https://www.pantsbuild.org/2.21/docs/using-pants/key-concepts/source-roots), instead of the single config_name.

Not necessarily a big deal, but I wanted to keep it restricted to config_name since it allows us to treat the repo structure more uniformly. I also wonder how many people configure semgrep in completely different ways for each project.

I don't mind following up with that though. Probably at the same time as deprecating defaults, since that'll make things easier too.

huonw · 2024-07-04T11:05:42Z

src/python/pants/backend/tools/semgrep/subsystem.py

+    ignore_config_path = StrOption(
+        default=".semgrepignore",


Ah... sorry about forcing you to re-investigate everything about these ignore files. This was known in the original addition of the backend, and cut out of scope: #18593 (comment)

I even referenced huonw#1 "so I don't forget about it", but look how far that's gone. 🙈

In any case, I think these two things are true, and still true as of this PR:

pants runs semgrep in the sandbox root (i.e. working directory is the root of the repository)

semgrep only looks for .semgrepignore in its working directory

Given this, running semgrep via pants will only ever successfully read //.semgrepignore. Thus, someone who sets ignore_config_path = "some/sub/directory/.semgrepignore will just have semgrep not using the ignore. It'll be included in the sandbox, but not used!

(The thinking behind the globbing behaviour was "future proofing": if a new version of semgrep started reading the nested .semgrepignores, it'll automatically work with Pants, because Pants is including them in the sandboxes.)

Two questions:

Are you changing the old behaviour (of including all files called .semgrepignore) because it was causing problems? Can you be specific about what the problems are?

Do you have an example of how someone would customise this path (and why)?

Ah gotcha, I'm on my phone right now but I'll look at those PRs later.

No, it wasn't causing problems. Basically when I was adding the description for the semgrepignore customization, I initially had a note that it was hierarchical. That got me curious, so I tried to use it, and realized it did not work as expected. Probably should've done a git blame to see why it was done, but I decided to mention explicitly that it had to be at the root-based path (since this is different from the rules dir behavior), and remove the relevant code.

Shall I add it back with a note about context? Though I do think as it stands pants taking this on will be a huge burden in taking over tool responsibility stuff. The simplest way I can think to get it done would be to to inject :includes into the root semgrepignore during the pants run. Is there any precedent to alter file digests like that?

And yeah, just realized semgrepignore is not actually customizable, so should just remove this and go back to the hard-coded value.

😂 hilarious that we ended up with nearly the same integration tests for showing this behavior

removed this configurability

Though I do think as it stands pants taking this on will be a huge burden in taking over tool responsibility stuff. The simplest way I can think to get it done would be to to inject :includes into the root semgrepignore during the pants run. Is there any precedent to alter file digests like that?

Yes, I agree that Pants should try to avoid having too much "smarts" tailored to each tool.

My thinking with the continuing work related to .semgrepignore (i.e. huonw#1) was just to make it more obvious when something is ignored, to reduce confusion. Not "invent" a new file.

huonw · 2024-07-04T11:19:16Z

src/python/pants/backend/tools/semgrep/rules.py

+        # Rules like foo/bar/.semgrep/baz.yaml and foo/bar/.semgrep/baz/qux.yaml should apply to the
+        # project at foo/bar
+        config_directory = path.parent
+        for config_path in config_paths:
+            if config_path not in path.parts:
+                continue
+            config_directory = PurePath(*path.parts[: path.parts.index(config_path)])
+            break


This nested loop jumps out to me as a bit concerning, due to performance:

this loop was previously approximately O(len(all_paths))

I think it's now O(len(all_paths) * average number of parts of each path * len(config_paths)) = O(sum(len(path.parts) for path in all_paths) * len(config_paths))

That is, after this PR, it's proportional to the number of config files and the number of parts (e.g. a, b etc. in a/b/...) of all files in the whole repository. I imagine the number of config files is often 1, but could easily be more (with a .semgrep directory)... but the number of path components could be very much higher than len(all_paths), depending how deeply nested the repo is!

I haven't yet thought of any alternatives, and how much effort to spend here will be guided by the top-level conversation about globbing etc.

Good point.

I'm comfortable forcing just one configuration option here.

For the iteration, I was really hoping for glob utils that could give me paths as match groups based on the nature of your glob, in which case this would be 0 work and would go back to an O(1) loop. I didn't see any, did I miss anything?

If not, I could improve it by doing files and dirs separately. This fn can take those two as separate args and

for config files, just use the parent

for config dirs, walk through the ancestry line. That would make it O(semgrep dir depth). I'm assuming that semgrep directories are not deeply nested, and that there are fewer path parts after the config dir than before. That should typically be a non-factor and amortize out to be constant. In the case of our monorepo, we just have a single dir level to store vendored rules.

All right, did a bit of restructure based on the above.

This loop will be much simpler once we deprecate the default option and stop supporting a mix of file configs and folder configs.

Currently, the only issue is that in the default case, I have two separate globs for files and dirs, which would result in two separate glob expansions. Once we deprecate the default case, that goes away. And a lot of other bits of logic will get easier too.

huonw · 2024-07-04T11:21:05Z

Woohoo, thanks for taking the time to contribute!

semgrep searches for rules recursively within a rules directory, so
reflect that in the globs. This isn't obvious in the documentation, but
it's the way it behaves, and also is explicit in the code.

Nice catch 👍

Thoughts on working towards deprecating all default values for the
config globs?

Sounds good, given your research with semgrep itself moving away from the conventions 👍

Being a experimental backend, we don't need deprecation cycles to change defaults etc.

If it's easy to deprecate for a release and thus make it easier for people to upgrade, that'd be good, even with the experimental tag. If it's not easy, that's okay.

I'm not at a "real" computer to be able to find the details to help you, but #18390 is an example where we deprecated the default value for an option and then removed it (#18627).

In any case, doing it as follow-up sounds good.

We might want to entirely do away with the multi-level config setup. It's
adds complexity purely because the pants backend defines this config
differently from semgrep.

Do you have thoughts on what would be better to do?

For instance, ignoring the details of Pants for now, what semgrep invocations should happen for a repo like?

a/.semgrep.yml
a/x.py
b/.semgrep.yml
b/y.py

It can even be a URL, or name of a registry, which is currently unsupported in
the pants backend

This is somewhat explicitly not supported, because reading external non-versioned resources interacts badly with caching: see discussion on the force option.

purajit · 2024-07-04T16:51:02Z

For instance, ignoring the details of Pants for now, what semgrep invocations should happen for a repo like?

I think this gets a bit complicated - depending on how people organize their repos there could be a few answers. And I admit I'm making a lot of assumptions here and potentially projecting my opinions onto others.

In a world without pants, I'd say people are probably chdir'ing to each subproject root and running semgrep, and that people likely do not have nested semgrep configs. Since semgrep natively does not support this nesting, it would be quite a bit of effort for people to write tools/queries/wrappers to fetch nested rule dirs and add then as CLI arguments.

Also given the nature of semgrep, I would assume people have a consistent set of rules they're universally applying, and ignoring files/dirs when needed needed, rather than having configs residing in specific directories, and that at most this will apply to high-level subprojects and no deeper.

I would personally prefer to enforce that people continue using semgrep in the "expected" way, and that they handle the cases where the merge repos and manage it as part of the migration. Supporting the subproject-specific runs feels like supporting an anti-pattern, but I'm not sure if there's already been a broader discussion about this general circumstance (tools meant to be run on a monolith that that may be run in different contexts or directories depending on specific repo setups).

This is somewhat explicitly not supported, because reading external non-versioned resources interacts badly with caching

Will check that discussion out. Not important to me to allow them since I don't use them for the same reason (even without caching, I don't want to be pulling random files from the internet); I just noticed the gap and found it interesting and wondered what the future plans are. In other tools that have something similar, is the explicit decision to always leave it unsupported? Or to try to enforce things with explicit known checksums, like with known_versions?

huonw · 2024-07-08T05:54:02Z

(Thanks for waiting. I haven't forgotten about this, but just a bit busy at work for a few days. Please feel free to ping me if I haven't re-reviewed by Thursday (any timezone 😄 ).)

purajit · 2024-07-08T06:58:05Z

(Thanks for waiting. I haven't forgotten about this, but just a bit busy at work for a few days. Please feel free to ping me if I haven't re-reviewed by Thursday (any timezone 😄 ).)

No worries! It was the weekend, and I anyway have a couple changes to work on. And also realized I had a bunch of typos because I was half-awake on my phone while leaving some of the comments, fixed those :P

…-dir matching

huonw · 2024-07-10T07:37:07Z

Also given the nature of semgrep, I would assume people have a consistent set of rules they're universally applying, and ignoring files/dirs when needed needed, rather than having configs residing in specific directories, and that at most this will apply to high-level subprojects and no deeper.

I agree that this is likely the default and most common (it's certainly how I use it in my work repo)... but...

I would personally prefer to enforce that people continue using semgrep in the "expected" way, and that they handle the cases where the merge repos and manage it as part of the migration. Supporting the subproject-specific runs feels like supporting an anti-pattern, but I'm not sure if there's already been a broader discussion about this general circumstance (tools meant to be run on a monolith that that may be run in different contexts or directories depending on specific repo setups).

... my learning from other tools (e.g. black) is that "partitioning by config" is desirable. For instance:

making merging repos easier, as you say. Based on my experience on slack, this is a very path for adopting pants, going from many-repo -> mono-repo for existing code, and so keeping this smooth/easy will make it easier for people to put their Pants on.
We can/should partition more tools by config (black, flake8, etc...) #17739 (with related issues like black reformatting can ignore configuration in nested directory, depending on sandbox contents #20589).

Thus, I'm pretty reticent about removing existing partitioning logic.

I just noticed the gap and found it interesting and wondered what the future plans are. In other tools that have something similar, is the explicit decision to always leave it unsupported? Or to try to enforce things with explicit known checksums, like with known_versions?

Yeah, some sort of checksum/content-addressing. I don't know of any other tools similar to semgrep that pants already supports. Arguably installing dependencies from PyPI is like this, but we encourage people to use a lockfile that encodes checksums etc, to be reproducible. I don't know of a lockfile for semgrep configs (i.e. "I want this semgrep.dev rule-set of this particular version")?

huonw

The code is looking better now too!

docs/notes/2.23.x.md

huonw · 2024-07-10T10:18:38Z

src/python/pants/backend/tools/semgrep/subsystem.py

+    ignore_config_path = StrOption(
+        default=".semgrepignore",


Though I do think as it stands pants taking this on will be a huge burden in taking over tool responsibility stuff. The simplest way I can think to get it done would be to to inject :includes into the root semgrepignore during the pants run. Is there any precedent to alter file digests like that?

Yes, I agree that Pants should try to avoid having too much "smarts" tailored to each tool.

My thinking with the continuing work related to .semgrepignore (i.e. huonw#1) was just to make it more obvious when something is ignored, to reduce confusion. Not "invent" a new file.

huonw · 2024-07-10T10:24:20Z

src/python/pants/backend/tools/semgrep/rules.py

-async def find_all_semgrep_configs() -> AllSemgrepConfigs:
-    all_paths = await path_globs_to_paths(
-        PathGlobs([f"**/{file_glob}" for file_glob in _RULES_FILES_GLOBS])
+async def find_all_semgrep_configs(semgrep: SemgrepSubsystem) -> AllSemgrepConfigs:


I like this new approach a lot more! Thanks.

huonw · 2024-07-10T10:33:27Z

src/python/pants/backend/tools/semgrep/subsystem.py

@@ -51,6 +57,20 @@ class SemgrepSubsystem(PythonToolBase):
    register_lockfile = True
    default_lockfile_resource = ("pants.backend.tools.semgrep", "semgrep.lock")

+    config_paths = StrListOption(
+        default=[".semgrep"],


Thanks for updating this; this looks like a good incremental improvement, and I'm definitely sympathic to trying to keep the changes smaller.

didn't want to add too much at once

For the next steps, if you keep working on this, I'd still be interested in moving most of the path/globbing logic into the option in pants.toml.

For example, evolving to config_paths that takes a list of paths/globs (or maybe inspired by root_patterns https://www.pantsbuild.org/2.21/docs/using-pants/key-concepts/source-roots), instead of the single config_name.

Co-authored-by: Huon Wilson <[email protected]>

purajit · 2024-07-11T17:36:39Z

Yeah, I ditched the idea of undoing the config-by-partition.

I don't know of a lockfile for semgrep configs (i.e. "I want this semgrep.dev rule-set of this particular version")?

Nothing like that really exists today; at work we just vendor out all the rules we want. rules typically don't need
updates or bug fixes so we're comfortable just leaving them in that state until we explicitly refresh them.

Do you have any other comments you want me to address in this PR? Or are we good now? I'll follow up with
two PRs - one for deprecating the default values, and one for expanding config_name.

huonw

I think this is very close, other than the test.

Also, the pull request description becomes the final commit message. It looks like the current description may be out of date with where this PR ended up (with .semgrepignore especially). Could you update it? Thanks

huonw · 2024-07-15T09:59:49Z

src/python/pants/backend/tools/semgrep/subsystem.py

@@ -51,6 +51,18 @@ class SemgrepSubsystem(PythonToolBase):
    register_lockfile = True
    default_lockfile_resource = ("pants.backend.tools.semgrep", "semgrep.lock")

+    config_name = StrOption(


Ah, one more thing. I think there's no test that currently exercises this option and its new code-path. Could you expand src/python/pants/backend/tools/semgrep/rules_integration_test.py to include one? Let me know if you'd like some assistance choosing where to add it.

working on it

purajit · 2024-07-15T18:20:09Z

The .semgrepignore part should still be accurate - the glob is flattened (https://github.com/pantsbuild/pants/pull/21126/files#diff-543817713d41666b0c246395e84c35bdb1a60facbf4c1f9948b444c24d274265R183 only captures the root-level file). I can update it with the links to your PR to maintain the trail?

…rajit/pants into 20240703-semgrep-configurable

huonw

Sweet! thanks for waiting

purajit force-pushed the 20240703-semgrep-configurable branch from a8b06ff to f1f0e3c Compare July 3, 2024 23:03

purajit added 2 commits July 4, 2024 00:36

Allow customizing semgrep configurations; correct rule matching glob

f092630

release notes

c55500a

purajit force-pushed the 20240703-semgrep-configurable branch from f1f0e3c to c55500a Compare July 4, 2024 07:54

fmt

24b5d51

kaos reviewed Jul 4, 2024

View reviewed changes

docs/notes/2.23.x.md Outdated Show resolved Hide resolved

kaos requested a review from huonw July 4, 2024 08:25

purajit added 2 commits July 4, 2024 02:15

change to config_paths list

bb4842c

make release note more obvious

1e1a899

purajit marked this pull request as ready for review July 4, 2024 09:43

huonw reviewed Jul 4, 2024

View reviewed changes

purajit added 4 commits July 9, 2024 11:11

don't allow customizing semgrepignore; better management of config-to…

71e477a

…-dir matching

Merge branch 'main' into 20240703-semgrep-configurable

c9e985f

lint

3e47476

update

8f38d51

huonw reviewed Jul 10, 2024

View reviewed changes

Update docs/notes/2.23.x.md

582cf7b

Co-authored-by: Huon Wilson <[email protected]>

purajit requested a review from huonw July 10, 2024 23:47

Merge branch 'main' into 20240703-semgrep-configurable

e3a961c

huonw added the category:new feature label Jul 15, 2024

huonw reviewed Jul 15, 2024

View reviewed changes

purajit added 2 commits July 15, 2024 14:52

added config_name tests

ed06049

Merge branch '20240703-semgrep-configurable' of https://github.com/pu…

7579179

…rajit/pants into 20240703-semgrep-configurable

purajit requested a review from huonw July 18, 2024 07:29

huonw approved these changes Jul 23, 2024

View reviewed changes

huonw merged commit 71749c0 into pantsbuild:main Jul 23, 2024
25 checks passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Allow customizing semgrep configurations; correct rule matching glob #21126

Allow customizing semgrep configurations; correct rule matching glob #21126

purajit commented Jul 3, 2024 •

edited

Loading

purajit commented Jul 4, 2024 •

edited

Loading

purajit commented Jul 4, 2024 •

edited

Loading

kaos left a comment

purajit commented Jul 4, 2024 •

edited

Loading

huonw Jul 4, 2024

purajit Jul 4, 2024

purajit Jul 9, 2024

huonw Jul 10, 2024

purajit Jul 10, 2024

huonw Jul 4, 2024 •

edited

Loading

purajit Jul 4, 2024 •

edited

Loading

purajit Jul 4, 2024

purajit Jul 8, 2024

purajit Jul 9, 2024

huonw Jul 10, 2024

huonw Jul 4, 2024 •

edited

Loading

purajit Jul 4, 2024 •

edited

Loading

purajit Jul 9, 2024 •

edited

Loading

huonw commented Jul 4, 2024 •

edited

Loading

purajit commented Jul 4, 2024 •

edited

Loading

huonw commented Jul 8, 2024

purajit commented Jul 8, 2024

huonw commented Jul 10, 2024 •

edited

Loading

huonw left a comment

huonw Jul 10, 2024

huonw Jul 10, 2024

huonw Jul 10, 2024

purajit commented Jul 11, 2024 •

edited

Loading

huonw left a comment

huonw Jul 15, 2024

purajit Jul 15, 2024

purajit commented Jul 15, 2024

huonw left a comment

	default=[".semgrep"],
	default=["/.semgrep.yml", "/.semgrep.yaml", "**/.semgrep"],

Allow customizing semgrep configurations; correct rule matching glob #21126

Allow customizing semgrep configurations; correct rule matching glob #21126

Conversation

purajit commented Jul 3, 2024 • edited Loading

purajit commented Jul 4, 2024 • edited Loading

purajit commented Jul 4, 2024 • edited Loading

kaos left a comment

Choose a reason for hiding this comment

purajit commented Jul 4, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

huonw Jul 4, 2024 • edited Loading

Choose a reason for hiding this comment

purajit Jul 4, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

huonw Jul 4, 2024 • edited Loading

Choose a reason for hiding this comment

purajit Jul 4, 2024 • edited Loading

Choose a reason for hiding this comment

purajit Jul 9, 2024 • edited Loading

Choose a reason for hiding this comment

huonw commented Jul 4, 2024 • edited Loading

purajit commented Jul 4, 2024 • edited Loading

huonw commented Jul 8, 2024

purajit commented Jul 8, 2024

huonw commented Jul 10, 2024 • edited Loading

huonw left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

purajit commented Jul 11, 2024 • edited Loading

huonw left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

purajit commented Jul 15, 2024

huonw left a comment

Choose a reason for hiding this comment

purajit commented Jul 3, 2024 •

edited

Loading

purajit commented Jul 4, 2024 •

edited

Loading

purajit commented Jul 4, 2024 •

edited

Loading

purajit commented Jul 4, 2024 •

edited

Loading

huonw Jul 4, 2024 •

edited

Loading

purajit Jul 4, 2024 •

edited

Loading

huonw Jul 4, 2024 •

edited

Loading

purajit Jul 4, 2024 •

edited

Loading

purajit Jul 9, 2024 •

edited

Loading

huonw commented Jul 4, 2024 •

edited

Loading

purajit commented Jul 4, 2024 •

edited

Loading

huonw commented Jul 10, 2024 •

edited

Loading

purajit commented Jul 11, 2024 •

edited

Loading