Skip to content

[medium] Fix --show-guesses being silently skipped when --type is given - #34

Open
elhoim wants to merge 1 commit into
MISP:mainfrom
elhoim:fix/11-show-guesses-noop
Open

[medium] Fix --show-guesses being silently skipped when --type is given#34
elhoim wants to merge 1 commit into
MISP:mainfrom
elhoim:fix/11-show-guesses-noop

Conversation

@elhoim

@elhoim elhoim commented Aug 31, 2026

Copy link
Copy Markdown
Member

BLUF — --show-guesses prints nothing and explains nothing when --type is given alongside it.

  • Problem — In main() in bin/cli.py the whole --show-guesses display block sits inside the else branch of the explicit-type check, so a command such as --type ip-src --value 1.2.3.4 --show-guesses prints nothing at all and gives no hint why.
  • Fix — Adds a log() call in the explicit-type branch stating that --show-guesses was skipped because --type was provided, so no guessing ran. Guessing logic and the existing display code are untouched.
  • Effect — The flag combination now explains itself instead of silently doing nothing.

Finding 11 (High) — bin/cli.py:910

Problem

The --show-guesses block is nested inside the else: of 'if args.attr_type:' (:905), so '--type ip-src --value 1.2.3.4 --show-guesses' prints nothing and gives no explanation.

Fix

Fixed finding #11 (show-guesses-noop, high severity). In bin/cli.py's main(), the --show-guesses display block (guess listing/logging) was nested entirely inside the else: branch of if args.attr_type:. This meant running the CLI with both --type and --show-guesses (e.g. --type ip-src --value 1.2.3.4 --show-guesses) silently skipped the guess block with zero output or explanation — a confusing no-op for users who expect --show-guesses to always report something. The fix hoists a minimal log() call into the if args.attr_type: branch so users are told "--show-guesses skipped: --type was explicitly provided, so no guessing was performed." No other behavior was changed; guessing logic and the existing else-branch guess-display code are untouched.

Verification

Reproduced against the unmodified code at 9b8c605, then re-checked after the change.

Before
Ran a throwaway script (bin/cli.py's main() invoked directly with fetch_modules/fetch_describe_types/query_module monkeypatched to avoid network) with sys.argv = ["cli.py", "--type", "ip-src", "--value", "1.2.3.4", "--show-guesses", ...]. Before the fix, stdout/stderr contained NO mention of "guess" at all — the CLI proceeded straight to querying modules for the explicit type with zero feedback that --show-guesses had no effect. Confirmed via the check `any(k in out.lower() for k in ["skip","ignor","guess"])` == False.
After
Same script/args after the fix: log() now emits "--show-guesses skipped: --type was explicitly provided, so no guessing was performed." before the module query section, confirming the flag's effect is no longer a silent no-op.

python bin/cli.py --help exits 0 and the module still imports cleanly. Verification was performed offline against the pure functions — no running misp-modules instance is required.

Branched from 9b8c605. This PR addresses only this finding; the other findings from the same review are in separate PRs, so they will need rebasing against each other as they merge.

🤖 Generated with Claude Code

Finding MISP#11 (show-guesses-noop): the --show-guesses display block was
nested inside the else: branch of 'if args.attr_type:', so passing
--type together with --show-guesses produced no output and no
explanation that guessing was bypassed.

Add an explicit log() message in the args.attr_type branch so users
get feedback that --show-guesses was skipped because --type was
explicitly provided, instead of silent no-op behaviour.
@elhoim elhoim changed the title Fix --show-guesses being silently skipped when --type is given [medium] Fix --show-guesses being silently skipped when --type is given Sep 3, 2026
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.

1 participant