BUG: BinAsciiConverter identifiers collide for different word-selection indices
维护者通常 2 天内回复
评估
调研方向
Start with BinAsciiConverter._build_identifier() and compare its parameters with WordLevelConverter's use of get_identifier_params(); the issue links both files. Run the reproduction on current main, then add regression tests for distinct identifiers and successful registry registration for different indices. Confirm whether the default/all-words identifier remains unchanged, as the issue requests, and run the relevant converter and registry tests.
由索引模型根据 Issue 内容生成。
描述
Describe the bug
BinAsciiConverter instances using WordIndexSelectionStrategy(indices=[0]) and indices=[1] transform different words, but have identical identifier parameters, hashes, and default registry names. Registering both instances without custom names therefore raises a duplicate-name error.
I can reproduce this and would like to take the fix and submit regression tests. Could a maintainer confirm that this is available for me to work on and clarify whether the existing default/all-words identifier must remain unchanged?
This is related to the missing selection configuration reported for StringJoinConverter in #2973. The current #2976 changes only StringJoinConverter and its tests; this report concerns the separate BinAsciiConverter override. If the team prefers a coordinated broader fix, please advise on the scope before I prepare a PR.
Steps/Code to Reproduce
Run on current main at 34cab5c7626ac6e3359aba11526d534896935250. No model, database initialization, network requests, or external data are required.
import asyncio
from pyrit.converter import BinAsciiConverter, WordIndexSelectionStrategy
from pyrit.registry import ConverterRegistry
async def main():
first = BinAsciiConverter(word_selection_strategy=WordIndexSelectionStrategy(indices=[0]))
second = BinAsciiConverter(word_selection_strategy=WordIndexSelectionStrategy(indices=[1]))
for converter in (first, second):
result = await converter.convert_async(prompt="ab cd", input_type="text")
print(result.output_text, converter.get_identifier().unique_name)
print("Equal hashes:", first.get_identifier().hash == second.get_identifier().hash)
registry = ConverterRegistry()
registry.instances.register(first)
registry.instances.register(second)
asyncio.run(main())
Expected Results
The outputs should be 6162 cd and ab 6364, respectively: the independent UTF-8 hex encodings of ab and cd are 6162 and 6364. These are different behavioral configurations, so their identifiers and default registry names should differ and both registrations should succeed.
ComponentIdentifier describes identity as a snapshot of behavioral configuration. WordLevelConverter already includes the selection strategy's get_identifier_params() in its identifier.
Actual Results
The conversion outputs are correct, but both configurations have the same identity:
6162 cd BinAsciiConverter::1b5f7f5d
ab 6364 BinAsciiConverter::1b5f7f5d
Equal hashes: True
ValueError: Instance 'BinAsciiConverter::1b5f7f5d' already exists
Both full hashes are 1b5f7f5de3b280c2738f825b231e04f593136480ebb4dccf15a1ef596dcfda76. Supplying separate custom registry names works around registration, but leaves the configuration hashes identical.
The BinAsciiConverter._build_identifier() override includes the selection strategy's class name, separator, and encoding function, but omits the strategy parameters such as indices. A focused fix would retain those behavior-bearing parameters while respecting the required compatibility of existing default identifiers.
No production code has been changed for this report.
Screenshots
Not applicable; the text output above is the reproduction result.
Versions
Windows 11, Python 3.12.0, PyRIT 1.2.0.dev0 from the source SHA above. pyrit.show_versions() reports:
System:
python: 3.12.0 (tags/v3.12.0:0fb18b0, Oct 2 2023, 13:03:39) [MSC v.1935 64 bit (AMD64)]
executable: E:\OpenSource\ai-contribution-plan\venvs\pyrit\Scripts\python.exe
machine: Windows-11-10.0.26100-SP0
Python dependencies:
pyrit: 1.2.0.dev0
Cython: None
numpy: 2.5.3
openai: 3.24.0
packaging: 26.3
pip: None
scipy: 1.18.1
setuptools: None
sqlite3: None
torch: None
transformers: 5.18.0
AI assistance: Codex wrote this reproducer and report, executed the local reproduction, and assisted with code inspection and duplicate searches.
- 主要语言
- Python
- 星标
- 4.6k
- 派生
- 944
- 平均合并
- 2 天 18 小时
- 30 天内合并 PR
- 358
环境准备
在浏览器里用你自己的 GitHub 账号启动这个项目的开发容器。
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 没有贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
microsoft/PyRIT 的其他 Issue
-
BUG: label queries only return the final conversation of an attack可能已有人在做 @u7k4rs6 于 2 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 85/100
microsoft/PyRIT#3095 · 4 条评论 · 已指派 1 人 ·
维护者通常 2 天内回复
-
BUG Configuration keeps runtime-status errors after polling recovers可能已有人在做 @joeyvictorino 于 6 天前认领。 未关闭Bug: triage GUI help wanted
难度 2/5 1-3 小时 新手友好度 86/100
microsoft/PyRIT#2868 · 6 条评论 ·
维护者通常 2 天内回复
-
FEAT: Support PDF and file inputs via `binary_path` in OpenAI chat and response targets可能已有人在做 @PranavD2905 今天认领。 未关闭feature-request help wanted
难度 4/5 3-5 天 新手友好度 35/100
microsoft/PyRIT#3274 · 1 条评论 ·
维护者通常 2 天内回复
-
feature-request
难度 5/5 一周以上 新手友好度 18/100
维护者通常 2 天内回复
-
难度 3/5 1-2 天 新手友好度 35/100
维护者通常 2 天内回复
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 74/100
cellrishi-code/claude-skills-atlas#165 ·
维护者通常 1 天内回复
-
bug confirmed issue
难度 2/5 1-3 小时 新手友好度 72/100
open-webui/open-webui#32635 · 1 条评论 ·
维护者通常 1 天内回复
-
Filters: ?field:ne=null matches NULL rows instead of non-NULL ones可能已有人在做 @rshdhere 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 72/100
Netflix/metaflow-service#504 ·
-
needs-triage
难度 2/5 1-3 小时 新手友好度 84/100
gke-labs/kube-agents#3394 ·
维护者通常 1 天内回复
-
A2A audit timestamps end in +00:00Z (invalid ISO 8601)可能已有人在做 @O1sumitkumar 今天认领。 未关闭bug good first issue help wanted python
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 1 天内回复