Skip to content

Added confidential checker - #6981

Open
iywang2016 wants to merge 278 commits into
typetools:masterfrom
iywang2016:iywang
Open

Added confidential checker#6981
iywang2016 wants to merge 278 commits into
typetools:masterfrom
iywang2016:iywang

Conversation

@iywang2016

@iywang2016 iywang2016 commented Mar 3, 2025

Copy link
Copy Markdown
Contributor

Associated with JDK pull request #224

iywang2016 and others added 30 commits July 12, 2024 15:54
…bined SqlQuoteless and SqlEvenQuotes; revised documentations

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 3

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)
prek.toml (1)

29-48: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick win

Whitespace hooks were broadened over byte-exact test fixtures. Both exclude lists lost an entry protecting golden files that tests compare literally, so the hooks will now rewrite fixture content and break expected-output comparisons.

  • prek.toml#L29-L48: re-add "**/*.goal" to the end-of-file-fixer exclude globs.
  • prek.toml#L55-L68: re-add "**/expected*" to the trailing-whitespace exclude globs.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@prek.toml` around lines 29 - 48, Restore the missing fixture exclusions in
prek.toml: add "**/*.goal" to the end-of-file-fixer exclude globs at prek.toml
lines 29-48, and add "**/expected*" to the trailing-whitespace exclude globs at
prek.toml lines 55-68.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In @.circleci/config.yml:
- Around line 14-17: The workflows.build configuration currently runs only prek;
restore the removed build/test job matrix and its dependencies alongside prek.
Ensure the workflow again compiles the framework and executes the
checker/tests/confidential tests, preserving the existing job dependency
relationships.
- Around line 8-13: Update the CircleCI steps around “Install prek” and “Run
prek hooks” to persist uv’s tool binary directory, ~/.local/bin, in $BASH_ENV
after installing prek so later isolated run shells can resolve the prek command.
Keep the existing uv installation and hook invocation unchanged.

In @.pmd-ruleset.xml:
- Around line 26-28: Update the PMD ruleset properties near logLevels and
guardsMethods by removing only the duplicate info entry from logLevels. Keep
both properties enabled and preserve the existing guard method configuration.

---

Outside diff comments:
In `@prek.toml`:
- Around line 29-48: Restore the missing fixture exclusions in prek.toml: add
"**/*.goal" to the end-of-file-fixer exclude globs at prek.toml lines 29-48, and
add "**/expected*" to the trailing-whitespace exclude globs at prek.toml lines
55-68.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 17c7b2d1-4f30-4f8d-88ab-1fdb9b0815cd

📥 Commits

Reviewing files that changed from the base of the PR and between 6e9ec3a and 9a01544.

📒 Files selected for processing (3)
  • .circleci/config.yml
  • .pmd-ruleset.xml
  • prek.toml

Comment thread .circleci/config.yml Outdated
Comment thread .circleci/config.yml Outdated
Comment thread .pmd-ruleset.xml
Comment on lines +26 to +28
<property name="logLevels" value="trace,debug,info,warn,error,log,finest,finer,fine,info,warning,severe" />
<!-- Adds "isEnabled" to the default list. -->
<property name="guardsMethods" value="isTraceEnabled,isDebugEnabled,isInfoEnabled,isWarnEnabled,isErrorEnabled,isLoggable,isEnabled" />

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low value

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Find the pinned PMD version to validate the property names.
rg -n 'pmd' -i build.gradle | head -50
fd -t f 'gradle.properties|versions.gradle' -H | xargs -r rg -n -i pmd

Repository: typetools/checker-framework

Length of output: 270


🏁 Script executed:

#!/bin/bash
set -u

echo "== PMD occurrences =="
git ls-files | xargs rg -n -i 'pmd' || true

echo
echo "== build.gradle relevant section =="
sed -n '130,260p' build.gradle

echo
echo "== PMD ruleset =="
cat -n .pmd-ruleset.xml

echo
echo "== gradle files candidates =="
git ls-files | rg '(^|/)(settings\.gradle|build\.gradle|gradle\.properties|versions\.gradle|libs\.versions\.toml)$' || true

Repository: typetools/checker-framework

Length of output: 34623


🌐 Web query:

PMD GuardLogStatement property names logLevels guardsMethods version

💡 Result:

The GuardLogStatement rule in PMD is a best-practice rule designed to ensure that log statements (such as trace, debug, or error) are guarded by an appropriate condition check (e.g., isDebugEnabled) to avoid unnecessary object creation and method calls [1][2]. Rule Properties The rule uses two primary multi-valued properties to define which log methods require guarding [1][2]: 1. logLevels: A list of log method names to be guarded. By default, these include: trace, debug, info, warn, error, log, finest, finer, fine, info, warning, and severe [1][2]. 2. guardsMethods: A list of corresponding guard method names. By default, these include: isTraceEnabled, isDebugEnabled, isInfoEnabled, isWarnEnabled, isErrorEnabled, and isLoggable [1][2]. Implementation Requirements The rule maintains a mapping between these two lists. When configuring these properties, the number of log levels must correspond to the number of guard methods [3][4]. Specifically: - For every logLevel, a guardMethod must be specified [3]. - If the number of provided logLevels exceeds the number of provided guardsMethods, the last guard method provided is reused for the remaining log levels [3]. - It is not possible to specify logLevels without also specifying guardMethods [3]. Version History The GuardLogStatement rule was introduced in PMD 5.1.0 [5][6]. It remains a standard rule in modern versions of PMD, categorized under Best Practices [1][2]. Configuration of these properties is typically handled within a ruleset XML file [1][2]. Example Configuration

Citations:


Keep the PMD properties enabled and deduplicate only info.

logLevels/guardsMethods are valid GuardLogStatement properties, and the commented-out PMD config still pins 7.25.0. Remove the duplicate info in the logLevels value for clarity, but leave these properties configured unless PMD is intentionally disabled.

♻️ Proposed cleanup
-            <property name="logLevels" value="trace,debug,info,warn,error,log,finest,finer,fine,info,warning,severe" />
+            <property name="logLevels" value="trace,debug,info,warn,error,log,finest,finer,fine,warning,severe" />
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
<property name="logLevels" value="trace,debug,info,warn,error,log,finest,finer,fine,info,warning,severe" />
<!-- Adds "isEnabled" to the default list. -->
<property name="guardsMethods" value="isTraceEnabled,isDebugEnabled,isInfoEnabled,isWarnEnabled,isErrorEnabled,isLoggable,isEnabled" />
<property name="logLevels" value="trace,debug,info,warn,error,log,finest,finer,fine,warning,severe" />
<!-- Adds "isEnabled" to the default list. -->
<property name="guardsMethods" value="isTraceEnabled,isDebugEnabled,isInfoEnabled,isWarnEnabled,isErrorEnabled,isLoggable,isEnabled" />
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.pmd-ruleset.xml around lines 26 - 28, Update the PMD ruleset properties
near logLevels and guardsMethods by removing only the duplicate info entry from
logLevels. Keep both properties enabled and preserve the existing guard method
configuration.

import org.checkerframework.framework.qual.TypeUseLocation;

/**
* Represents a value that might or might not be confidential. This is the top of the Confidential

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"the top of the" => "the top qualifier in the"

@hannahpotter

Copy link
Copy Markdown

This is essentially ready to merge. I have just a few comments.

Since \code{@NonConfidential} is the default annotation, if a programmer
forgets to annotate a sensitive source as \<@Confidential>, then there will
be an information leak that the Confidential Checker cannot warn about.
Once sources and sinks are annotated, the Confidential Checker guarantees

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@smillst

Is this saying that annotations aren't need elsewhere? I would assume that you still need to annotate method signatures.

indicates a value whose confidentiality is unknown.
\code{@UnknownConfidential} is a supertype of \code{@Confidential}
and \code{@NonConfidential}.
\item[\refqualclass{checker/confidential/qual}{PolyConfidential}]

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest putting @PolyConfidential last, after the real type qualifiers, even though it is used more often than @BottomConfidential.

\end{figure}

The Confidential Checker's \code{@Confidential} qualifier has similarities
to the Taint Checker's \code{@Tainted} qualifier. One difference is that

@hannahpotter hannahpotter Jul 29, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@smillst

Suggested change
to the Taint Checker's \code{@Tainted} qualifier. One difference is that
to the Tainting Checker's \code{@Tainted} qualifier. One difference is that

The Confidential Checker's \code{@Confidential} qualifier has similarities
to the Taint Checker's \code{@Tainted} qualifier. One difference is that
there is no subtyping relationship between \code{@Confidential} and
\code{@NonConfidential}. However, the external behavior of these annotations

@hannahpotter hannahpotter Jul 29, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@smillst

I don't understand what you mean by external behavior here.

* A TreeAnnotator to enforce certain toString return type rules:
*
* <ul>
* <li>toString(@NonConfidential this) can return @NonConfidential or @Confidential String

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@smillst

This comment does not match the implemenation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants