I publish ComfyUI-OCIO, registry id comfyui-ocio, under the publisher slavasexton. It provides nine Nuke-style OpenColorIO nodes for ComfyUI: Read, Write, Player, ColorSpace, LogConvert, Display, CDLTransform, FileTransform, and LookTransform. It reads stills, image sequences, and video, grades in ACES, and writes EXR, TIFF, PNG, JPEG, ProRes, DNxHR, h264, and hevc with color management.
1. Flagged status on 1.2.3
Could you review the Flagged status on versions 1.2.3 and 1.2.4? The status reason can be reproduced through the registry API request for either version with include_status_reason=true. Because the scanner matches the source code, publishing another version with the same ffmpeg calls would be flagged in the same way, which is why I am asking rather than simply republishing.
curl -s "https://api.comfy.org/versions?nodeId=comfyui-ocio&include_status_reason=true&pageSize=10"
The response contains 11 YARA findings, all with severity info. There are no medium, high, or critical findings.
Nine findings are python_command_injection_risk. Each is a subprocess.run call using an argument list such as [binary, "-v", "error", ...] for ffmpeg or ffprobe. None uses shell=True, and none builds a command string. The rule description says it detects all os.system and subprocess usage, so these appear to be false positives for these specific calls.
One python_environment_manipulation finding is from reading os.environ["OCIO"]. OpenColorIO uses that variable to tell an application where to locate the active OCIO configuration. The code reads the variable and does not write it.
One python_network_operations finding is in web/ocio_io.js, matching .connect( in lines such as source.connect(splitter) and gain.connect(ctx.destination). Those lines build a Web Audio API audio graph in the browser for the Player node volume meter. They are not network operations, and this appears to be a Python network rule matching a JavaScript file.
As a neutral comparison, comfyui-videohelpersuite calls ffmpeg through subprocess in several files, and its recent registry versions are Active. That suggests the subprocess pattern can be accepted when the usage is reviewed in context.
2. Node extraction has not run
Could the node-list extraction also be run for this pack? Both 1.2.3 and 1.2.4 show comfy_node_extract_status as pending, so ComfyUI-Manager displays "No nodes found." I built the registry-backend node-pack-extract container and ran it against the published 1.2.4 CDN archive. It returned {"success": true} and extracted all nine nodes.
My reading of the backend is that publishing sends notifications only. Extraction runs when TriggerComfyNodesBackfill is called, whose only caller is the admin ComfyNodesBackfill endpoint. I cannot trigger that by republishing. I am not asking for special treatment, only for comfyui-ocio to be included when the next extraction backfill runs.
There appear to be related cases in registry-web issue 265, open since May, and registry-backend issue 185, open since June. This looks like a recurring situation rather than a one-off. Because ComfyUI-Manager requests only Active and Pending versions, the pack currently resolves to zero installable registry versions.
3. Thank you
Thank you as well to the people at Comfy-Org who noticed these tools on LinkedIn. I plan to keep publishing and maintaining tools officially on the registry regularly, and would like to establish a working path for future packs.
I publish ComfyUI-OCIO, registry id comfyui-ocio, under the publisher slavasexton. It provides nine Nuke-style OpenColorIO nodes for ComfyUI: Read, Write, Player, ColorSpace, LogConvert, Display, CDLTransform, FileTransform, and LookTransform. It reads stills, image sequences, and video, grades in ACES, and writes EXR, TIFF, PNG, JPEG, ProRes, DNxHR, h264, and hevc with color management.
1. Flagged status on 1.2.3
Could you review the Flagged status on versions 1.2.3 and 1.2.4? The status reason can be reproduced through the registry API request for either version with
include_status_reason=true. Because the scanner matches the source code, publishing another version with the same ffmpeg calls would be flagged in the same way, which is why I am asking rather than simply republishing.The response contains 11 YARA findings, all with severity
info. There are no medium, high, or critical findings.Nine findings are
python_command_injection_risk. Each is asubprocess.runcall using an argument list such as[binary, "-v", "error", ...]for ffmpeg or ffprobe. None usesshell=True, and none builds a command string. The rule description says it detects allos.systemandsubprocessusage, so these appear to be false positives for these specific calls.One
python_environment_manipulationfinding is from readingos.environ["OCIO"]. OpenColorIO uses that variable to tell an application where to locate the active OCIO configuration. The code reads the variable and does not write it.One
python_network_operationsfinding is inweb/ocio_io.js, matching.connect(in lines such assource.connect(splitter)andgain.connect(ctx.destination). Those lines build a Web Audio API audio graph in the browser for the Player node volume meter. They are not network operations, and this appears to be a Python network rule matching a JavaScript file.As a neutral comparison, comfyui-videohelpersuite calls ffmpeg through subprocess in several files, and its recent registry versions are Active. That suggests the subprocess pattern can be accepted when the usage is reviewed in context.
2. Node extraction has not run
Could the node-list extraction also be run for this pack? Both 1.2.3 and 1.2.4 show
comfy_node_extract_statusas pending, so ComfyUI-Manager displays "No nodes found." I built the registry-backendnode-pack-extractcontainer and ran it against the published 1.2.4 CDN archive. It returned{"success": true}and extracted all nine nodes.My reading of the backend is that publishing sends notifications only. Extraction runs when
TriggerComfyNodesBackfillis called, whose only caller is the adminComfyNodesBackfillendpoint. I cannot trigger that by republishing. I am not asking for special treatment, only for comfyui-ocio to be included when the next extraction backfill runs.There appear to be related cases in registry-web issue 265, open since May, and registry-backend issue 185, open since June. This looks like a recurring situation rather than a one-off. Because ComfyUI-Manager requests only Active and Pending versions, the pack currently resolves to zero installable registry versions.
3. Thank you
Thank you as well to the people at Comfy-Org who noticed these tools on LinkedIn. I plan to keep publishing and maintaining tools officially on the registry regularly, and would like to establish a working path for future packs.