Skip to content

docs: Mention Kotlin support - #1

Merged
seqradev merged 2 commits into
seqra:mainfrom
meowcat767:main
Jan 14, 2026
Merged

docs: Mention Kotlin support#1
seqradev merged 2 commits into
seqra:mainfrom
meowcat767:main

Conversation

@meowcat767

@meowcat767 meowcat767 commented Dec 30, 2025

Copy link
Copy Markdown
Contributor

I have added support for the Kotlin language.

Since Kotlin is compatible with Java and the JVM, it's a good next language to add.

@meowcat767 meowcat767 changed the title feat: add kotlin support Feat: add kotlin support Dec 30, 2025
@meowcat767 meowcat767 changed the title Feat: add kotlin support feat: add kotlin support Dec 30, 2025
@seqradev

seqradev commented Jan 12, 2026

Copy link
Copy Markdown
Member

Thanks for the PR! I think we can merge it with a small cleaning.

Seqra already supports Kotlin today. The remaining gap is coroutine-specific handling, which belongs in the analyzer core rather than the CLI repo.

Right now, this PR is mostly docs/help text plus some dead code. Since the added code isn't used, the PR reads like "new support" when it's really clarifying existing support.

If you can:

  • rename the PR to something like "docs: mention Kotlin support" / "docs: update README for Kotlin"
  • remove the unused Kotlin utility/config bits (or wire them up and explain why they're needed)
  • drop the committed binary

…then I'm happy to merge.

@meowcat767

meowcat767 commented Jan 12, 2026

Copy link
Copy Markdown
Contributor Author

Yeah, will do in the coming days.

@meowcat767 meowcat767 changed the title feat: add kotlin support feat: improve Kotlin support Jan 12, 2026
@meowcat767 meowcat767 changed the title feat: improve Kotlin support docs: mention Kotlin support Jan 13, 2026
@seqradev seqradev changed the title docs: mention Kotlin support docs: Mention Kotlin support Jan 14, 2026
seqradev
seqradev requested changes Jan 14, 2026
View reviewed changes
Comment thread internal/utils/project/config.go
@seqradev
seqradev merged commit ed8fef6 into seqra:main Jan 14, 2026
4 of 9 checks passed
seqradev pushed a commit that referenced this pull request Jan 29, 2026
@misonijnik
ci: Add CI (#1)
a0cb387
misonijnik pushed a commit that referenced this pull request Mar 19, 2026
@Saloed
Rule normalization utils (#1)
600d472
misonijnik pushed a commit that referenced this pull request Mar 19, 2026
@Saloed
Remove ap resolver (#1)
6876abf
misonijnik pushed a commit that referenced this pull request Mar 19, 2026
@meowcat767
docs: Mention Kotlin support (#1)
dc8a21d
misonijnik pushed a commit that referenced this pull request Mar 19, 2026
@meowcat767
docs: Mention Kotlin support (#1)
ddf246e
misonijnik added a commit that referenced this pull request Mar 19, 2026
@misonijnik
feat(cli): Bump versions (#1)
8727450
Saloed pushed a commit that referenced this pull request Mar 23, 2026
@misonijnik
feat(cli): Bump versions (#1)
3ca3b93
Saloed added a commit that referenced this pull request May 26, 2026
@Saloed @claude
Capture post-Task-A massive run for issue #1 follow-up
72ae345 
This is the per-sample-notes output produced by GoMassiveSampleTest
after Task A enabled trace resolution. Failures now distinguish
"engine miss" from "trace miss" from "true FP".

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Saloed added a commit that referenced this pull request Jun 1, 2026
@Saloed @claude
Project map/slice range element taint onto next-tuple slots
ffbceb2 
Taint was lost through `for ... range` over a collection holding element
(`[*]`) taint. Go SSA lowers `for k, v := range m` to `next(range m)`,
producing a 3-tuple `(ok, key, value)` consumed by `extract #0/#1/#2`. A
tainted map/slice carries taint under an ElementAccessor (`[*]`). The
`range`/`next` flow functions copied the operand access path verbatim, so
the next register's fact stayed `var(R)[*]![taint]`, while `extract`
refines the tuple register with a tupleFieldAccessor (`tuple$i`). The `[*]`
ElementAccessor never unifies with the `tuple$i` FieldAccessor, so the
key/value extracts read nothing and the loop variable — then the sink —
came back clean.

Root cause was the same tuple/extract accessor-unification family as the
multi-return fix (b3bbf02), but for ELEMENT taint projecting onto tuple
slots rather than whole-value taint. The multi-return `isWholeValueTaint`
read-through already covered whole-value-tainted collections (so
source-driven map ranges like Ctx.Input.Params() already flowed); the gap
was specifically element-level taint built locally via map-update.

Fix:
- GoFlowFunctionUtils.rangeElementTupleSlots: resolve the ranged
  collection's underlying type (through named/pointer wrappers) and return
  the tuple slots the element taint projects onto — map → key slot ($1) and
  value slot ($2) (over-approximate: the whole key+value element is
  tainted); slice/array → value slot ($2) only (the int index stays clean).
- GoMethodSequentFlowFunction.handleNext: keep the original verbatim
  operand copy (preserving the whole-value path) and additionally project
  the iterated collection's `[*]` taint onto those tuple slots so the
  downstream extract's tupleFieldAccessor unifies.
- handleMapUpdate (forward + precondition): a tainted map KEY now also
  taints the map element, matching the key-slot projection above
  (`for k := range m` over a key-tainted map).
- GoMethodSequentPrecondition.handleNextPrecondition: backward counterpart
  for trace reconstruction (verbatim rebase + element-from-slot
  precondition), in lockstep with the forward gen.

Tests (red -> green): un-disabled engine fixtures MapOpsTest.mapIter001T
(range value) and mapKeyTaint001T (range key); new querylang rule sample
SourceBeegoInputParamsRange (map ranged after element/key taint, sinks the
loop var) registered in GoSampleBasedTest. Diagnostic dumps added for the
two fixtures in EngineRoadmapDiagnosticTest.

Regression: 0 new failures across
`org.opentaint.go.sast.dataflow.*` (fully green; MultiReturn intact) and
`:opentaint-go-querylang:test` (23 pre-existing GoMassiveSampleTest
baseline failures, identical set before/after — none new, none recovered).

Bench precision (owasp + sec) is flat: owasp CWE-22 38/44, CWE-78 21/25,
CWE-79 58/66, CWE-89 99/86, TOTAL 216 TP / 221 FP (unchanged); sec 178 TP /
249 FP (unchanged). The benchmark range FNs flow via whole-value taint
(already handled), so this closes a distinct element-taint gap with zero
bench cost — the key over-approximation added zero FP in practice.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Saloed added a commit that referenced this pull request Jun 29, 2026
@Saloed @claude
Add standalone reproducers for Go engine issues to go-querylang
895de23 
New sample packages under samples-go/ wired into GoSampleBasedTest, each
isolating a limitation found while improving the Go ruleset (see issues.md):

- TypedFieldReadSource (#1): typed receiver on a field-read source crashes
  analysis (IllegalStateException "Unsupported field-source position: This").
- InterfaceImplSink (#2): a typed receiver matches only the exact static
  type, not a concrete implementor of the interface.
- TypedArgSink (#3): a type ascription in argument position is ignored.
- FieldReadSink (#4): a field-read sink never fires in taint mode.
- MapValueToReceiver (#5): confirms the core DOES propagate a map value into
  a receiver-position sink, so the full-scan ServeJSON false-negative is an
  unroll-strategy/config issue, not a core bug.

#1-#4 are @disabled with a todo referencing the issue; removing @disabled
reproduces the bug now and the test should pass once it is fixed. #5 is
enabled and passing. Full GoSampleBasedTest: 89 tests, 0 failures, 5 skipped.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Saloed added a commit that referenced this pull request Jun 29, 2026
@Saloed @claude
Go engine + ruleset: fix issues.md #1-#14 (non-delayed set)
0297e42 
Engine (opentaint-go-dataflow):
- #1 typed field-read source no longer crashes: thread GoFieldSignature.receiverType,
  allow This as a field-source condition base (taint target stays Result-only).
- #2 TypeUtils.matchesType matches interface implementations (method-set check,
  pointer/value rules, graceful fallback).
- #7 GoFunctionSignature.pkgName (declared package clause name) + candidates() branch
  so bare rand.* matches math/rand/v2.
- #11 GoConditionResolver.resolveWithType descends a single-element GoIRTupleType
  (single-return result) before a Field/Element modifier, so a result-field source
  taint action (cookie .Value) resolves and seeds field-sensitively. No whole-value taint.
- #12 GoCallExpr peels the receiver for DIRECT concrete pointer-receiver methods from the
  static target signature (fixes *sql.DB.Query arg indexing); no go-ssa-server change.
- #6 GoTaintConfiguration.matchPackage is exact for slash-qualified matchers.

Querylang (opentaint-go-querylang):
- #3 typed metavar in argument position parses to ParamCondition.TypeIs(Argument).
- #6 new GoImportRewriter pre-pass resolves package qualifiers from in-pattern imports.

Ruleset (rules/ruleset/go):
- #6 import-qualified package names across lib/security rules (bare where a local
  test-stub / ambiguous package / typed-receiver method pattern requires it).
- #7 weak-random drops the v2.* block.
- #11 http-sources cookies source taints [$I].Value.

Tooling: #10 restore scan --entry-point flag; re-point fn_investigate.py to
test rule reachability.

Gates: engine units 1300/1300; GoSampleBasedTest 95 (3 intentional skips);
rules/test/go detection harness 197/197.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@seqradev seqradev seqradev approved these changes

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@meowcat767 @seqradev