Repository navigation
BUG: BinAsciiConverter identifiers collide for different word-selection indices #2995
Description
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.
Activity
LE0-Lin commentedon Oct 6, 2026
Follow-up after #2976 merged: I checked the 13 direct
WordLevelConvertersubclasses on unmodifiedmainatd0367ab4d7f6bb16baca2d27a975b8f0e7dc6052. I ran offline conversion, identifier, and default-registration checks for 12;RandomTranslationConverterwas not executed because it requires an LLM target.With
WordIndexSelectionStrategy(indices=[0])versus[1]and inputalpha beta, these six converters produced different outputs but identical hashes, and the second default registration raised a duplicate-nameValueError:BinAsciiConverter(this issue)CharSwapConverterFirstLetterConverterLeetspeakConverterUnicodeReplacementConverterZalgoConverterFor example,
FirstLetterConverterreturnsa betaversusalpha bwith the following configuration:BinaryConverter,EmojiConverter,NatoConverter,ROT13Converter, the fixedStringJoinConverter, andSuperscriptConverterpassed this particular check. This is a bounded selection-identity audit, not a claim that all configurations or downstream effects have been tested. Component searches and all 64 current open PR file lists showed no overlapping changes to the five additional converter overrides.I would like to continue the fix in the existing draft #3000. Would the team prefer to keep it scoped to BinAscii, or include the other five overrides with regression coverage for legacy default identities? I have not expanded the production patch while this scope and compatibility decision is pending.
AI assistance: Codex inspected the code and executed this local audit and reproducer.
romanlutz commentedon Oct 9, 2026
Nice find! Yes, please continue in #3000. A nice number for a great bugfix! 🙂 Please remove "DRAFT" from the title and @mention me when you want it reviewed. So far it looks great.