[Tcllib-bugs] [Tcllib] (juliannoble2) tkt (New): pluginmgr potential collisions with files/folders in cwd

[<no...@tc...>]

Automated mail by fx, on behalf of no...@tc...

Ticket Change [0fbddcd72bd85f658c1d27e95e711fa36672fdb3d43904b19ad4d8a6532e3ec1]
  [pluginmgr potential collisions with files/folders in cwd]
  By      juliannoble2
  For     Tcllib
  On      2025-10-06T04:56:24.960
  Details https://core.tcl-lang.org/tcllib/tinfo?name=0fbddcd72bd85f658c1d27e95e711fa36672fdb3d43904b19ad4d8a6532e3ec1
  Ticket  https://core.tcl-lang.org/tcllib/tktview/1a7976b873c9828c29c5abc0ac90739f196ab783

Changed Fields
  assignee:        nobody
  closer:          nobody
  comment:         The primary mechanism for listing plugins is the package database,  as
                   used in the list method.  The private LoadPlugin method tries to do
                   direct load first, followed by fallback to package require

                   The LoadPlugin method contains the following as the first load
                   mechanism, prior to looking for packages:

                   if {[file exists $name]} {  # Plugin files are loaded directly.

                   $sip invokehidden source $name  return 1  }

                   This check for an unqualified name operates in whatever is the current
                   working directory, without reference to the package/module paths or
                   any of the paths explicitly specified for the pluginmgr object

                   This means that if the cwd happens to contain a file or folder with
                   the same basename as the plugin intended to load - it will either fail
                   in the case of a directory name - or source some unintended file.

                   It's unclear if there was some intention that this direct load
                   mechanism is to support calling something like :

                   plugmgrObject load adhocplugin.tcl

                   from the current directory or perhaps with an absolute path - but in
                   any case such a file wouldn't show in the results of 'plugmgrObject
                   list'  and the collision risk for cwd folders and plugin names is high
                   and quite confusing when it occurs.

                   I am guessing that this should have been wrapped in a while loop over
                   the $paths variable - to restrict it to the paths that have been
                   configured via safe::interpAddToAccessPath  As it stands, the parent
                   interpreter seems to be able to source from a folder that isn't in
                   that list (cwd)

                   Even if this were adjusted to operate on the configured paths,  It
                   seems to me the name would have to contain the extension e.g
                   myplugin.tcl to work, and as there is no check that $name isn't a
                   folder - it could easily collide if the user had a common structure
                   for sub packages e.g

                   myplugin.tcl  myplugin (folder)   subplugin.tcl

                   Taking the aged example at: https://wiki.tcl-lang.org/page/pluginmgr
                   This only works for me if I run it from within the described
                   ~/.example/plugin/ folder  and only then if I use plug load slang.
                   ...((truncated))
  is_private:      0
  login:           juliannoble2
  priority:        5 Medium
  private_contact: 957fdfcd8744611e3fe1f4896c7538b1d9bf47b2
  resolution:      None
  severity:        Minor
  status:          Open
  submitter:       juliannoble2
  subsystem:       (unused)
  title:           pluginmgr potential collisions with files/folders in cwd
  type:            Bug

------------------------------------------------------------
See Tcl/Tk development @ http://core.tcl-lang.org/
------------------------------------------------------------