]> Cypherpunks repositories - gostls13.git/commitdiff
plugin: add warning
authorAlan Donovan <adonovan@google.com>
Tue, 22 Nov 2022 03:33:43 +0000 (22:33 -0500)
committerGopher Robot <gobot@golang.org>
Wed, 23 Nov 2022 03:37:22 +0000 (03:37 +0000)
The plugin mechanism has a number of serious drawbacks.
This change documents them.

Fixes #56893

Change-Id: I1309ac8520f7471dd9ace5be28a8dc3339fdf2db
Reviewed-on: https://go-review.googlesource.com/c/go/+/452695
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Alan Donovan <adonovan@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Alan Donovan <adonovan@google.com>

src/plugin/plugin.go

index b2a0fbe3ea2f18578a05acb5c6d50217481646c5..a5489e638b9bd60a481a8e56dee70fa4c2a4a6be 100644 (file)
 // already part of the program are called. The main function is not run.
 // A plugin is only initialized once, and cannot be closed.
 //
-// Currently plugins are only supported on Linux, FreeBSD, and macOS.
-// Please report any issues.
+// # Warnings
+//
+// The ability to dynamically load parts of an application during
+// execution, perhaps based on user-defined configuration, may be a
+// useful building block in some designs. In particular, because
+// applications and dynamically loaded functions can share data
+// structures directly, plugins may enable very high-performance
+// integration of separate parts.
+//
+// However, the plugin mechanism has many significant drawbacks that
+// should be considered carefully during the design. For example:
+//
+//   - Plugins are currently supported only on Linux, FreeBSD, and
+//     macOS, making them unsuitable for applications intended to be
+//     portable.
+//
+//   - Applications that use plugins may require careful configuration
+//     to ensure that the various parts of the program be made available
+//     in the correct location in the file system (or container image).
+//     By contrast, deploying an application consisting of a single static
+//     executable is straightforward.
+//
+//   - Reasoning about program initialization is more difficult when
+//     some packages may not be initialized until long after the
+//     application has started running.
+//
+//   - Bugs in applications that load plugins could be exploited by an
+//     an attacker to load dangerous or untrusted libraries.
+//
+//   - Runtime crashes are likely to occur unless all parts of the
+//     program (the application and all its plugins) are compiled
+//     using exactly the same version of the toolchain, the same build
+//     tags, and the same values of certain flags and environment
+//     variables.
+//
+//   - Similar crashing problems are likely to arise unless all common
+//     dependencies of the application and its plugins are built from
+//     exactly the same source code.
+//
+//   - Together, these restrictions mean that, in practice, the
+//     application and its plugins must all be built together by a
+//     single person or component of a system. In that case, it may
+//     be simpler for that person or component to generate Go source
+//     files that blank-import the desired set of plugins and then
+//     compile a static executable in the usual way.
+//
+// For these reasons, many users decide that traditional interprocess
+// communication (IPC) mechanisms such as sockets, pipes, remote
+// procedure call (RPC), shared memory mappings, or file system
+// operations may be more suitable despite the performance overheads.
 package plugin
 
 // Plugin is a loaded Go plugin.