engineering/java-topology
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
java-topology/defects/rails/patch/CLEAN.md
russell@unturf.com 4d4c256673 diamond-scan: cpython/django O(2^D) hierarchy traversal; flask/rails/ruby/phoenix CLEAN 
cpython-0001: pydoc.allmethods unconditional __bases__ recursion, no visited guard
cpython-0002: turtle.__methodDict unconditional __bases__ recursion, fires at import
cpython-0003: idlelib.rpc._getmethods unconditional __bases__ recursion, IDLE debug path
django-0006: migrations.state.flatten_bases abstract model diamond traversal (comment in source acknowledges duplicates)
flask/rails/ruby/phoenix: CLEAN
2026-03-29 20:16:12 -04:00

955 B
Raw Permalink Blame History

Rails — CWE-407 Diamond Traversal Scan: CLEAN

Scanned: 2026-03-30

Files examined

  • activesupport/lib/active_support/concern.rb — append_features/prepend_features use base < self guard before processing dependencies; prevents re-inclusion
  • railties/lib/rails/initializable.rb — ancestors.reverse_each iterates Ruby's linearized MRO (C3, no duplicates); not recursive
  • activemodel/lib/active_model/translation.rb — lookup_ancestors calls ancestors.select {...} which is a flat MRO traversal
  • activerecord/lib/arel/visitors/visitor.rb — object.class.ancestors.find {...} is a flat MRO traversal

Result

No diamond recursion defects found. Rails uses Ruby's built-in ancestors (which returns the C3-linearized MRO with no duplicates) rather than manually recursing through __bases__ equivalents. ActiveSupport::Concern is properly guarded against diamond re-inclusion via the base < self subclass check.