Adding upstream version 4.4.0.upstream/4.4.0upstream

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

34 files changed, 332 insertions, 144 deletions

diff --git a/docbook/wsdg_src/developer-guide-docinfo.xml b/doc/wsdg_src/developer-guide-docinfo.xml
index 90f36d11..341b061b 100644
--- a/docbook/wsdg_src/developer-guide-docinfo.xml
+++ b/doc/wsdg_src/developer-guide-docinfo.xml
@@ -1,7 +1,7 @@
 <!-- Document information for the Developer's Guide. -->
 
 <!-- Updated by tools/make-version.py -->
-<subtitle>For Wireshark 4.2</subtitle>
+<subtitle>For Wireshark 4.4</subtitle>
 
   <!-- <title><inlinegraphic entityref="WiresharkLogo" valign="middle" format="PNG"/> &DocumentTitle;</title> -->
 
diff --git a/docbook/wsdg_src/developer-guide.adoc b/doc/wsdg_src/developer-guide.adoc
index cc1c0bd5..8f4bcbbe 100644
--- a/docbook/wsdg_src/developer-guide.adoc
+++ b/doc/wsdg_src/developer-guide.adoc
@@ -16,7 +16,7 @@ endif::[]
 // XXX This should be surrounded by single quotes in the text. It’s
 // currently surrounded by plus signs for AsciiDoc compatibility.
 :dlt-glob: DLT_*
-:qt6-lts-version: 6.2.4
+:qt6-lts-version: 6.5.3
 :source-highlighter: coderay
 
 include::wsdg_preface.adoc[]
diff --git a/docbook/wsdg_src/images/caution.svg b/doc/wsdg_src/images/caution.svg
index 793c6020..793c6020 100644
--- a/docbook/wsdg_src/images/caution.svg
+++ b/doc/wsdg_src/images/caution.svg
diff --git a/docbook/wsdg_src/images/git-triangular-workflow.gv b/doc/wsdg_src/images/git-triangular-workflow.gv
index 809877a8..cb4fb174 100644
--- a/docbook/wsdg_src/images/git-triangular-workflow.gv
+++ b/doc/wsdg_src/images/git-triangular-workflow.gv
@@ -1,4 +1,4 @@
-// dot -Tsvg -o docbook/wsdg_graphics/git-triangular-workflow.svg docbook/wsdg_graphics/git-triangular-workflow.gv
+// dot -Tsvg -o doc/wsdg_graphics/git-triangular-workflow.svg doc/wsdg_graphics/git-triangular-workflow.gv
 
 digraph G {
     // XXX Integrate ws.css. Match it manually for now.
diff --git a/docbook/wsdg_src/images/git-triangular-workflow.svg b/doc/wsdg_src/images/git-triangular-workflow.svg
index 1f8ae3ac..1f8ae3ac 100644
--- a/docbook/wsdg_src/images/git-triangular-workflow.svg
+++ b/doc/wsdg_src/images/git-triangular-workflow.svg
diff --git a/docbook/wsdg_src/images/important.svg b/doc/wsdg_src/images/important.svg
index a2ee7012..a2ee7012 100644
--- a/docbook/wsdg_src/images/important.svg
+++ b/doc/wsdg_src/images/important.svg
diff --git a/docbook/wsdg_src/images/note.svg b/doc/wsdg_src/images/note.svg
index 803dc13e..803dc13e 100644
--- a/docbook/wsdg_src/images/note.svg
+++ b/doc/wsdg_src/images/note.svg
diff --git a/docbook/wsdg_src/images/tip.svg b/doc/wsdg_src/images/tip.svg
index 1a60b74a..1a60b74a 100644
--- a/docbook/wsdg_src/images/tip.svg
+++ b/doc/wsdg_src/images/tip.svg
diff --git a/docbook/wsdg_src/images/warning.svg b/doc/wsdg_src/images/warning.svg
index 80c0ba5c..80c0ba5c 100644
--- a/docbook/wsdg_src/images/warning.svg
+++ b/doc/wsdg_src/images/warning.svg
diff --git a/docbook/wsdg_src/images/ws-capture-sync.dia b/doc/wsdg_src/images/ws-capture-sync.dia
index 00ba9cf8..00ba9cf8 100644
--- a/docbook/wsdg_src/images/ws-capture-sync.dia
+++ b/doc/wsdg_src/images/ws-capture-sync.dia
diff --git a/docbook/wsdg_src/images/ws-capture-sync.png b/doc/wsdg_src/images/ws-capture-sync.png
index d46e1e94..d46e1e94 100644
--- a/docbook/wsdg_src/images/ws-capture-sync.png
+++ b/doc/wsdg_src/images/ws-capture-sync.png
diff --git a/docbook/wsdg_src/images/ws-capture_internals.dia b/doc/wsdg_src/images/ws-capture_internals.dia
index 0eae20e5..0eae20e5 100644
--- a/docbook/wsdg_src/images/ws-capture_internals.dia
+++ b/doc/wsdg_src/images/ws-capture_internals.dia
diff --git a/docbook/wsdg_src/images/ws-capture_internals.png b/doc/wsdg_src/images/ws-capture_internals.png
index 6d110af3..6d110af3 100644
--- a/docbook/wsdg_src/images/ws-capture_internals.png
+++ b/doc/wsdg_src/images/ws-capture_internals.png
diff --git a/docbook/wsdg_src/images/ws-dev-guide-cover.png b/doc/wsdg_src/images/ws-dev-guide-cover.png
index 8134d2d0..8134d2d0 100644
--- a/docbook/wsdg_src/images/ws-dev-guide-cover.png
+++ b/doc/wsdg_src/images/ws-dev-guide-cover.png
diff --git a/docbook/wsdg_src/images/ws-logo.png b/doc/wsdg_src/images/ws-logo.png
index 04226f39..04226f39 100644
--- a/docbook/wsdg_src/images/ws-logo.png
+++ b/doc/wsdg_src/images/ws-logo.png
diff --git a/docbook/wsdg_src/images/wslua-new-dialog.png b/doc/wsdg_src/images/wslua-new-dialog.png
index 9de7e4a9..9de7e4a9 100644
--- a/docbook/wsdg_src/images/wslua-new-dialog.png
+++ b/doc/wsdg_src/images/wslua-new-dialog.png
diff --git a/docbook/wsdg_src/images/wslua-progdlg.png b/doc/wsdg_src/images/wslua-progdlg.png
index d8d95101..d8d95101 100644
--- a/docbook/wsdg_src/images/wslua-progdlg.png
+++ b/doc/wsdg_src/images/wslua-progdlg.png
diff --git a/docbook/wsdg_src/images/wslua-textwindow.png b/doc/wsdg_src/images/wslua-textwindow.png
index 7defd0fa..7defd0fa 100644
--- a/docbook/wsdg_src/images/wslua-textwindow.png
+++ b/doc/wsdg_src/images/wslua-textwindow.png
diff --git a/docbook/wsdg_src/wsdg_asn2wrs.adoc b/doc/wsdg_src/wsdg_asn2wrs.adoc
index e7e021ee..a5add171 100644
--- a/docbook/wsdg_src/wsdg_asn2wrs.adoc
+++ b/doc/wsdg_src/wsdg_asn2wrs.adoc
@@ -64,7 +64,7 @@ Reasons one might _not_ want to build as a plugin:
 * The CMakeFile is quite a bit more complex.
 * Building under the asn1 subtree keeps all such dissectors together.
 
-If you still think you'd like to build your module as a plugin, see https://gitlab.com/wireshark/wireshark/-/wikis/ASN1_plugin[Building ASN1 Plugins].
+If you still think you'd like to build your module as a plugin, see {wireshark-wiki-url}ASN1_plugin[Building ASN1 Plugins].
 
 [#UnderstandingErrorMessages]
 === Understanding Error Messages
@@ -432,7 +432,7 @@ Time TYPE = FT_STRING  DISPLAY = BASE_NONE  STRING = NULL BITMASK = 0
 [#SimpleASN1BasedDissector]
 === Simple ASN.1-Based Dissector
 
-// https://gitlab.com/wireshark/wireshark/-/wikis/uploads/__moin_import__/attachments/ASN1_sample/foo.tar.gz
+// {wireshark-wiki-moin-import-url}ASN1_sample/foo.tar.gz
 // all seven files as gzipped foo directory (suitable for unzipping in
 // wireshark/asn1 directory)
 
@@ -566,19 +566,19 @@ FOO-MESSAGE
 #define PSNAME "FOO"
 #define PFNAME "foo"
 #define FOO_PORT 5001    /* UDP port */
-static dissector_handle_t foo_handle=NULL;
+static dissector_handle_t foo_handle;
 
 void proto_reg_handoff_foo(void);
 void proto_register_foo(void);
 
 /* Initialize the protocol and registered fields */
-static int proto_foo = -1;
+static int proto_foo;
 static int global_foo_port = FOO_PORT;
 
 #include "packet-foo-hf.c"
 
 /* Initialize the subtree pointers */
-static int ett_foo = -1;
+static int ett_foo;
 
 #include "packet-foo-ett.c"
 
@@ -893,7 +893,7 @@ Replace all PROTOCOL/protocol references with the name of your protocol.
 #define PFNAME "protocol"
 
 /* Initialize the protocol and registered fields */
-int proto_protocol = -1;
+int proto_protocol;
 #include "packet-protocol-hf.c"
 
 /* Initialize the subtree pointers */
diff --git a/docbook/wsdg_src/wsdg_build_intro.adoc b/doc/wsdg_src/wsdg_build_intro.adoc
index d4ededb1..d4ededb1 100644
--- a/docbook/wsdg_src/wsdg_build_intro.adoc
+++ b/doc/wsdg_src/wsdg_build_intro.adoc
diff --git a/docbook/wsdg_src/wsdg_capture.adoc b/doc/wsdg_src/wsdg_capture.adoc
index 868f2a0f..868f2a0f 100644
--- a/docbook/wsdg_src/wsdg_capture.adoc
+++ b/doc/wsdg_src/wsdg_capture.adoc
diff --git a/docbook/wsdg_src/wsdg_dissection.adoc b/doc/wsdg_src/wsdg_dissection.adoc
index efc0a71a..0717a045 100644
--- a/docbook/wsdg_src/wsdg_dissection.adoc
+++ b/doc/wsdg_src/wsdg_dissection.adoc
@@ -70,7 +70,7 @@ With a little care, the plugin can be converted into a built-in dissector.
 
 #define FOO_PORT 1234
 
-static int proto_foo = -1;
+static int proto_foo;
 
 void
 proto_register_foo(void)
@@ -187,7 +187,7 @@ Here is the dissector's complete code:
 
 #define FOO_PORT 1234
 
-static int proto_foo = -1;
+static int proto_foo;
 
 static int
 dissect_foo(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree _U_, void *data _U_)
@@ -296,8 +296,8 @@ and `proto_register_subtree_array()`:
 .Registering data structures.
 [source,c]
 ----
-static int hf_foo_pdu_type = -1;
-static int ett_foo = -1;
+static int hf_foo_pdu_type;
+static int ett_foo;
 
 /* ... */
 
@@ -402,9 +402,9 @@ more variables to the hfarray, and a couple more procedure calls.
 [source,c]
 ----
 ...
-static int hf_foo_flags = -1;
-static int hf_foo_sequenceno = -1;
-static int hf_foo_initialip = -1;
+static int hf_foo_flags;
+static int hf_foo_sequenceno;
+static int hf_foo_initialip;
 ...
 
 static int
@@ -506,9 +506,9 @@ flags structure. For this we need to add some more data to the table though.
 #define FOO_END_FLAG        0x02
 #define FOO_PRIORITY_FLAG   0x04
 
-static int hf_foo_startflag = -1;
-static int hf_foo_endflag = -1;
-static int hf_foo_priorityflag = -1;
+static int hf_foo_startflag;
+static int hf_foo_endflag;
+static int hf_foo_priorityflag;
 
 static int
 dissect_foo(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree, void *data _U_)
@@ -569,7 +569,7 @@ other things we can do to make things look even more pretty. At the moment our
 dissection shows the packets as "Foo Protocol" which whilst correct is a little
 uninformative. We can enhance this by adding a little more detail. First, let’s
 get hold of the actual value of the protocol type. We can use the handy function
-`tvb_get_guint8()` to do this. With this value in hand, there are a couple of
+`tvb_get_uint8()` to do this. With this value in hand, there are a couple of
 things we can do. First we can set the INFO column of the non-detailed view to
 show what sort of PDU it is - which is extremely helpful when looking at
 protocol traces. Second, we can also display this information in the dissection
@@ -582,7 +582,7 @@ static int
 dissect_foo(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree, void *data _U_)
 {
     int offset = 0;
-    uint8_t packet_type = tvb_get_guint8(tvb, 0);
+    uint8_t packet_type = tvb_get_uint8(tvb, 0);
 
     col_set_str(pinfo->cinfo, COL_PROTOCOL, "FOO");
     /* Clear out stuff in the info column */
@@ -625,7 +625,7 @@ number being zero (assuming that's a noteworthy thing for this protocol).
 ----
 #include <epan/expert.h>
 
-static expert_field ei_foo_seqn_zero = EI_INIT;
+static expert_field ei_foo_seqn_zero;
 
 /* ... */
 
@@ -749,7 +749,7 @@ effect.
 .Decompressing data packets for dissection.
 [source,c]
 ----
-    uint8_t flags = tvb_get_guint8(tvb, offset);
+    uint8_t flags = tvb_get_uint8(tvb, offset);
     offset ++;
     if (flags & FLAG_COMPRESSED) { /* the remainder of the packet is compressed */
         uint16_t orig_size = tvb_get_ntohs(tvb, offset);
@@ -851,7 +851,7 @@ msg_pkt ::= SEQUENCE {
 #include <epan/reassemble.h>
    ...
 save_fragmented = pinfo->fragmented;
-flags = tvb_get_guint8(tvb, offset); offset++;
+flags = tvb_get_uint8(tvb, offset); offset++;
 if (flags & FL_FRAGMENT) { /* fragmented */
     tvbuff_t* new_tvb = NULL;
     fragment_data *frag_msg = NULL;
@@ -967,19 +967,19 @@ like the following. Of course the names may need to be adjusted.
 [source,c]
 ----
 ...
-static int hf_msg_fragments = -1;
-static int hf_msg_fragment = -1;
-static int hf_msg_fragment_overlap = -1;
-static int hf_msg_fragment_overlap_conflicts = -1;
-static int hf_msg_fragment_multiple_tails = -1;
-static int hf_msg_fragment_too_long_fragment = -1;
-static int hf_msg_fragment_error = -1;
-static int hf_msg_fragment_count = -1;
-static int hf_msg_reassembled_in = -1;
-static int hf_msg_reassembled_length = -1;
+static int hf_msg_fragments;
+static int hf_msg_fragment;
+static int hf_msg_fragment_overlap;
+static int hf_msg_fragment_overlap_conflicts;
+static int hf_msg_fragment_multiple_tails;
+static int hf_msg_fragment_too_long_fragment;
+static int hf_msg_fragment_error;
+static int hf_msg_fragment_count;
+static int hf_msg_reassembled_in;
+static int hf_msg_reassembled_length;
 ...
-static int ett_msg_fragment = -1;
-static int ett_msg_fragments = -1;
+static int ett_msg_fragment;
+static int ett_msg_fragments;
 ...
 static const fragment_items msg_frag_items = {
     /* Fragment subtrees */
@@ -1154,13 +1154,7 @@ string name with which to find it again.
 #include <epan/packet.h>
 #include <epan/tap.h>
 
-static int foo_tap = -1;
-
-struct FooTap {
-    int packet_type;
-    int priority;
-       ...
-};
+static int foo_tap;
 
 void proto_register_foo(void)
 {
@@ -1170,7 +1164,7 @@ void proto_register_foo(void)
 
 Whilst you can program a tap without protocol specific data, it is generally not
 very useful. Therefore it’s a good idea to declare a structure that can be
-passed through the tap. This needs to be a static structure as it will be used
+passed through the tap. This needs to be allocated in packet scope as it will be used
 after the dissection routine has returned. It’s generally best to pick out some
 generic parts of the protocol you are dissecting into the tap data. A packet
 type, a priority or a status code maybe. The structure really needs to be
@@ -1184,12 +1178,18 @@ of the dissector.
 .Calling a protocol tap
 [source,c]
 ----
+struct FooTap {
+    int packet_type;
+    int priority;
+       ...
+};
+
 static int
 dissect_foo(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree, void *data _U_)
 {
        ...
-    fooinfo = wmem_alloc(pinfo->pool, sizeof(struct FooTap));
-    fooinfo->packet_type = tvb_get_guint8(tvb, 0);
+    struct FooTap *fooinfo = wmem_new0(pinfo->pool, struct FooTap);
+    fooinfo->packet_type = tvb_get_uint8(tvb, 0);
     fooinfo->priority = tvb_get_ntohs(tvb, 8);
        ...
     tap_queue_packet(foo_tap, pinfo, fooinfo);
@@ -1198,12 +1198,19 @@ dissect_foo(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree, void *data _U_)
 }
 ----
 
+[TIP]
+====
+Allocate your structure using `wmem_new0()`, so it sets all values of your structure
+to zero. This way, if you add members later but forget to initialize them, they will
+have a consistent value, making troubleshooting easier.
+====
+
 This now enables those interested parties to listen in on the details
 of this protocol conversation.
 
 [#ChDissectStats]
 
-=== How to produce protocol stats
+=== How to produce protocol statistics (stats)
 
 Given that you have a tap interface for the protocol, you can use this
 to produce some interesting statistics (well presumably interesting!) from
@@ -1221,32 +1228,24 @@ Here is a mechanism to produce statistics from the above TAP interface.
 ----
 #include <epan/stats_tree.h>
 
-/* register all http trees */
-static void register_foo_stat_trees(void) {
-    stats_tree_register_plugin("foo", "foo", "Foo/Packet Types", 0,
+void proto_reg_handoff_foo(void) {
+       ...
+    stats_tree_register("foo", "foo", "Foo" STATS_TREE_MENU_SEPARATOR "Packet Types", 0,
         foo_stats_tree_packet, foo_stats_tree_init, NULL);
 }
-
-WS_DLL_PUBLIC_DEF void plugin_register_tap_listener(void)
-{
-    register_foo_stat_trees();
-}
 ----
 
-Working from the bottom up, first the plugin interface entry point is defined,
-`plugin_register_tap_listener()`. This simply calls the initialisation function
-`register_foo_stat_trees()`.
-
-This in turn calls the `stats_tree_register_plugin()` function, which takes three
-strings, an integer, and three callback functions.
+The interface entry point, `proto_reg_handoff_foo()`,
+calls the `stats_tree_register()` function, which takes three
+strings, an integer, and three callback functions:
 
-. This is the tap name that is registered.
+. This is the tap name that was registered using `register_tap()`.
 
 . An abbreviation of the stats name.
 
-. The name of the stats module. A “/” character can be used to make sub menus.
+. The name of the stats module. `STATS_TREE_MENU_SEPARATOR` can be used to make sub menus.
 
-. Flags for per-packet callback
+. Flags for per-packet callback, taken from `epan/stats_tree.h`.
 
 . The function that will called to generate the stats.
 
@@ -1256,6 +1255,13 @@ strings, an integer, and three callback functions.
 
 In this case we only need the first two functions, as there is nothing specific to clean up.
 
+[NOTE]
+====
+If you are registering statistics from a plugin, then your plugin should have
+a plugin interface entry point called `plugin_register_tap_listener()`,
+which should call `stats_tree_register_plugin()` instead of `stats_tree_register()`.
+====
+
 .Initialising a stats session
 [source,c]
 ----
@@ -1294,6 +1300,13 @@ In this case the processing of the stats is quite simple. First we call the
 call to `stats_tree_tick_pivot()` on the `st_node_packet_types` subtree allows
 us to record statistics by packet type.
 
+[NOTE]
+====
+Notice that stats trees and pivots are identified by their name string,
+_not_ by the identifier returned by
+`stats_tree_create_node()`/`stats_tree_create_pivot()`.
+====
+
 [#ChDissectConversation]
 
 === How to use conversations
diff --git a/docbook/wsdg_src/wsdg_env_intro.adoc b/doc/wsdg_src/wsdg_env_intro.adoc
index 91d51eaf..2bf6a922 100644
--- a/docbook/wsdg_src/wsdg_env_intro.adoc
+++ b/doc/wsdg_src/wsdg_env_intro.adoc
@@ -237,7 +237,7 @@ The Wireshark development team uses GitLab’s continuous integration (CI) syste
 Automated builds provide several useful services:
 
 * Cross-platform testing.
-  Inbound merge requests and commits can be tested on each of our supported plaforms, which ensures that a developer on one platform doesn’t break the build on other platforms.
+  Inbound merge requests and commits can be tested on each of our supported platforms, which ensures that a developer on one platform doesn’t break the build on other platforms.
 
 * A health indicator for the source code.
   The CI badges at {wireshark-gitlab-project-url} can quickly tell you how healthy the latest code is.
@@ -268,23 +268,24 @@ Jobs provide a link to the corresponding console logfile which provides addition
 
 Release packages are built on the following platforms:
 
-* Windows Server 2019 x86-64 (Win64, little endian, Visual Studio 2022)
+* Windows Server 2022 x64, Visual Studio 2022
 
-* Ubuntu 18.04 x86-64 (Linux, little endian, gcc, Clang)
+* Windows 11 Arm64, Visual Studio 2022
 
-* macOS 10.14 x86-64 (BSD, little endian, Clang)
+* Ubuntu 22.04 x64, gcc
 
-Static code analysis and fuzz tests are run on the following platforms:
+* macOS x64, clang
+
+* macOS Arm64, clang
 
-* Visual Studio Code Analysis (Win64, little endian, VS 2022)
+Static code analysis and fuzz tests are run on the following platforms:
 
-* Clang Code Analysis, Coverity Scan, and fuzz tests (Linux, little endian, Clang)
+* Visual Studio Code Analysis, Visual Studio 2022
 
-Each platform is represented at the status page by a single column, the most recent entries are at the top.
+* Clang Code Analysis, Coverity Scan, and fuzz tests, clang
 
 [#ChIntroHelp]
 
-
 === Reporting problems and getting help
 
 If you have problems, or need help with Wireshark, there are several
diff --git a/docbook/wsdg_src/wsdg_libraries.adoc b/doc/wsdg_src/wsdg_libraries.adoc
index d0f5f1d0..28bc52d5 100644
--- a/docbook/wsdg_src/wsdg_libraries.adoc
+++ b/doc/wsdg_src/wsdg_libraries.adoc
@@ -21,6 +21,7 @@ See <<ChSetupUNIXBuildEnvironmentSetup>> for details.
 On macOS, you can install pre-built packages using a third party package manager such as Homebrew or MacPorts.
 As with Linux, we provide `tools/macos-setup-brew.sh`, which will install the required Homebrew packages.
 We also provide `tools/macos-setup.sh`, which will download, build, and install required packages.
+Note that `tools/macos-setup.sh` installs into _/usr/local_ by default; you can change this with the `-p` flag.
 
 Windows doesn't have a good library package manager at the present time, so we provide our own pre-built libraries.
 They can be installed using `tools/win-setup.ps1` and are automatically installed when you run CMake.
@@ -299,6 +300,9 @@ https://dev-libs.wireshark.org/windows/packages/[].
 === Lua (Optional)
 
 The Lua library is used to add scripting support to Wireshark.
+Wireshark 4.2.x and earlier support Lua versions 5.1 and 5.2.
+Recent versions of Wireshark have added support for Lua 5.3 and 5.4
+as well.
 
 [#ChLibsUnixLua]
 
@@ -314,7 +318,7 @@ https://www.lua.org/download.html[].
 [discrete]
 ==== Windows
 
-We provide copies of the official packages at
+We provide packages for Windows, patched for UTF-8 support, at
 https://dev-libs.wireshark.org/windows/packages/[].
 
 [#ChLibsMaxMindDB]
diff --git a/docbook/wsdg_src/wsdg_lua_support.adoc b/doc/wsdg_src/wsdg_lua_support.adoc
index 8f7314bf..26c3849d 100644
--- a/docbook/wsdg_src/wsdg_lua_support.adoc
+++ b/doc/wsdg_src/wsdg_lua_support.adoc
@@ -10,17 +10,22 @@
 === Introduction
 
 Lua is a powerful light-weight programming language designed for extending
-applications. Wireshark contains an embedded Lua 5.2 interpreter which
-can be used to write dissectors, taps, and capture file readers
-and writers.
+applications. Wireshark contains an embedded Lua interpreter which can
+be used to write dissectors, taps, and capture file readers and writers.
+Wireshark versions 4.2.x and earlier support Lua 5.1 and 5.2, and newer
+versions support Lua 5.3 and 5.4. The Lua BitOp library is bundled with
+all version of Wireshark; Lua 5.3 and later also have native support for
+https://www.lua.org/manual/5.4/manual.html#3.4.2[bitwise operators].
 
 If Lua is enabled, Wireshark will first try to load a file named `init.lua`
 from the global link:{wireshark-users-guide-url}ChPluginFolders.html[_plugins directory_].
 and then from the user’s
 link:{wireshark-users-guide-url}ChAppFilesConfigurationSection.html[_personal plugins directory_].
 Then all files ending with _.lua_ are loaded from the global plugins
-directory. Then all files ending with _.lua_ in the personal Lua plugin's
-directory.
+directory and its subdirectories. Then all files ending with _.lua_ in the
+personal Lua plugins directory and its subdirectories are loaded. The
+files are processed in ASCIIbetical order (compared byte-by-byte, as `strcmp`),
+descending into each subdirectory depth-first in order.
 
 Whether or not Lua scripts are enabled can be controlled via the
 _$$enable_lua$$_ variable. Lua scripts are enabled by
@@ -48,10 +53,37 @@ run_user_scripts_when_superuser = true
 ----
 
 The command line option _$$-X lua_script:$$++file.lua++_ can also be used to load
-specific Lua scripts.
-
-The Lua code is executed after all protocol dissectors are
-initialized and before reading any file.
+specific Lua scripts. Arguments can be given to a script loaded at the command
+line with the option _$$-X lua_scriptN:$$++arg++_, where _N_ is the ordinal
+index of the script on the command line. For example, if two scripts were loaded
+on the command line with _$$-X lua_script:$$++my.lua++_ and
+_$$-X lua_script:$$++other.lua++_ in that order, then _$$-X lua_script1:$$++foo++_
+would pass _foo_ to _my.lua_ and _$$-X lua_script2:$$++bar++_ would pass _bar_ to
+_other.lua_. Multiple command line options could be passed to _my.lua_ by
+repeating the option _$$-X lua_script1:$$_.  Arguments are available in a script in
+a global table called _arg_, similar to when
+link:https://www.lua.org/manual/5.4/manual.html#7[running Lua standalone].
+
+[IMPORTANT]
+.Loading order matters
+====
+Lua dissectors, unlike <<ChapterDissection,compiled protocol dissectors>>, do
+not have separate <<ChDissectSetup,registration and handoff>> stages yet
+(see wsbuglink:15907[]). Each Lua dissector's registration and handoff is
+completed before moving to the next Lua file in turn.
+That means that the order in which Lua files are read is quite important;
+in order for a Lua dissector to register in a dissector table set up by another
+dissector, the latter dissector must have been already processed. The easiest
+way to ensure this is to put Lua dissectors that need to be registered first
+in files whose name is earlier in ASCIIbetical order (the name of the script
+does not necessarily need to relate to the name of the dissector.)
+
+The Lua code is executed after all compiled dissectors, both built-in and plugin,
+are initialized and before reading any file.
+This means that Lua dissectors can add themselves to tables registered by compiled
+dissectors, but not vice versa; compiled dissectors cannot add themselves to
+dissector tables registered by Lua dissectors.
+====
 
 Wireshark for Windows uses a modified Lua runtime
 (link:https://github.com/Lekensteyn/lua-unicode[lua-unicode]) to
@@ -223,6 +255,134 @@ end
 register_menu("Test/Packets", menuable_tap, MENU_TOOLS_UNSORTED)
 ----
 
+[#wslua_require_example]
+
+=== Example: Lua scripts with shared modules
+
+Lua plugins that depend on protocols, dissectors, dissector tables, and other
+items registered with Wireshark by other Lua scripts can access those through
+the Wireshark Lua API. The key is ensuring that the providing script is
+read first, as previously mentioned.
+
+It is also possible to depend on Lua functions defined in other Lua scripts.
+The recommended method is to load those scripts as
+link:https://www.lua.org/manual/5.4/manual.html#6.3[modules] via
+link:https://www.lua.org/manual/5.4/manual.html#pdf-require[require].
+Modules preferably should avoid defining globals, and should return a
+table containing functions indexed by name. Globals defined in modules will
+leak into the global namespace when `require()` is used, and name collisions
+can cause unexpected results. (As an aside, local variables are faster in
+Lua because global variables require extra table lookups.) Directories
+containing loaded Lua scripts (including those specified on the command line
+with _$$-X lua_script:$$++my.lua++_) are automatically added to the `require()`
+search path.
+
+For example, suppose there is a Lua script in the personal plugins directory
+named _bar.lua_ as follows:
+
+[source,lua]
+----
+-- bar.lua
+-- Converts an integer representing an IPv4 address into its dotted quad
+-- string representation.
+
+-- This is the module object, which will be returned at the end of this file.
+local M = {
+}
+
+M.GetIPAddressString = function(ip)
+    -- Lua BitOp library, included in all versions of Wireshark
+    --local octet1 = bit.rshift(bit.band(0xFF000000, ip), 24)
+    --local octet2 = bit.rshift(bit.band(0x00FF0000, ip), 16)
+    --local octet3 = bit.rshift(bit.band(0x0000FF00, ip), 8)
+    --local octet4 = bit.band(0x000000FF, ip)
+
+    -- Lua >= 5.3 native bit operators, supported in Wireshark >= 4.4
+    local octet1 = ip >> 24
+    local octet2 = ip >> 16 & 0xFF
+    local octet3 = ip >> 8 & 0xFF
+    local octet4 = ip & 0xFF
+
+    return octet1 .. "." .. octet2 .. "." .. octet3 .. "." .. octet4
+end
+
+-- Return the table we've created, which will be accessible as the return
+-- value of require() or dofile(), and at the global package.loaded["bar"]
+return M
+----
+
+Other Lua plugins that wish to use the module can then `require()` it
+(note that the _.lua_ extension is not used in `require()`, unlike the
+similar `dofile()`):
+
+[source,lua]
+----
+-- Foo dissector
+local p_foo = Proto("foo", "Foo")
+
+local bar = require("bar")
+
+local f_ip = ProtoField.ipv4("foo.ip", "IP")
+local f_ipint = ProtoField.uint32("foo.ipint", "IP as Uint32")
+local f_ipstr = ProtoField.string("foo.ipstr", "IP as String")
+
+p_foo.fields = { f_ip, f_ipint, f_ipstr }
+
+function p_foo.dissector(tvbuf, pktinfo, tree)
+
+    -- Set the protocol column to show this name
+    pktinfo.cols.protocol:set("FooMessage")
+
+    local pktlen = tvbuf:reported_length_remaining()
+
+    local subtree = tree:add(p_foo, tvbuf:range(0,pktlen))
+
+    local child, ipaddr = subtree:add_packet_field(f_ip, tvbuf(8, 4), ENC_BIG_ENDIAN)
+    local child, ipint = subtree:add_packet_field(f_ipint, tvbuf(8, 4), ENC_BIG_ENDIAN)
+
+    -- These two are the same string
+    subtree:add(f_ipstr, tvbuf(8,4), bar.GetIPAddressString(ipint))
+    subtree:add(f_ipstr, tvbuf(8,4), tostring(ipaddr))
+
+    return pktlen
+end
+
+DissectorTable.get("udp.port"):add(2012, p_foo)
+----
+
+Using `require()` is another way to control the order in which files are loaded.
+Lua `require()` ensures that a module is only executed once. Subsequent calls
+will return the same table already loaded.
+
+[IMPORTANT]
+.Avoid duplicate registration
+====
+In versions of Wireshark before 4.4, the initial loading of Lua plugins in the
+plugins directory does not register them in the table of already loaded modules
+used by `require()`. This means that Lua script in the plugins directory that
+are initially loaded can be executed a second time by `require()`. For scripts
+that register dissectors or tables with Wireshark, this will result in errors like
+`Proto new: there cannot be two protocols with the same description`. It is
+safer to `require()` only Lua scripts that define common functions but do not
+call the Wireshark Lua API to register protocols, dissectors, etc.
+
+In 4.4 and later, scripts in the plugin directories are loaded using the same
+internal methods as `require()`, which eliminates duplicate registration errors
+from loading of files in the plugin directory and using `require()`. This also
+means that the order in which plugins are loaded can be adjusted by using
+`require()` in addition to changing file names. However, duplicate registration
+errors can still happen with other methods of executing a file that do
+not check if it has already been loaded, like `dofile()`.
+====
+
+Lua scripts loaded on the command line are sandboxed into their own environment
+and globals defined in them do not leak in the general global environment.
+Modules loaded via `require()` within those scripts can escape that sandboxing,
+however. Plugins in the personal (but not global) directory had similar
+sandboxing prior to Wireshark 4.4, but now globals defined in plugins in the
+personal directory will enter the global namespace for other plugins, as has
+always been the case for plugins in the global plugin directory.
+
 [#wsluarm_modules]
 
 == Wireshark’s Lua API Reference Manual
diff --git a/docbook/wsdg_src/wsdg_preface.adoc b/doc/wsdg_src/wsdg_preface.adoc
index 6b20969c..6b20969c 100644
--- a/docbook/wsdg_src/wsdg_preface.adoc
+++ b/doc/wsdg_src/wsdg_preface.adoc
diff --git a/docbook/wsdg_src/wsdg_quick_setup.adoc b/doc/wsdg_src/wsdg_quick_setup.adoc
index 15458bea..7cfc636b 100644
--- a/docbook/wsdg_src/wsdg_quick_setup.adoc
+++ b/doc/wsdg_src/wsdg_quick_setup.adoc
@@ -224,7 +224,7 @@ to run it by entering `wireshark`.
 To build the Wireshark User's Guide and the Wireshark Developer's Guide,
 build the `all_guides` target, e.g.  `make all_guides` or `ninja
 all_guides`.  Detailed information to build these guides can be found in
-the file _docbook/README.adoc_ in the Wireshark sources.
+the file _doc/README.documentation.adoc_ in the Wireshark sources.
 
 ==== Optional: Create an installable or source code package
 
@@ -234,7 +234,7 @@ Source code tarball::
   Build the `dist` target.
 
 deb (Debian) package::
-  Create a symlink in the top-level source directory to _packaging/debian_, then run `dpkg-buildpackage`.
+  Create a symlink named _debian_ in the top-level source directory to _packaging/debian_, then run `dpkg-buildpackage`.
 
 RPM package::
   Build the `wireshark_rpm` target.
@@ -270,10 +270,13 @@ _wireshark-dev_ mailing list explaining your problem. Include the output from
 
 // Retain ChSetupWin32 for backward compatibility
 [#ChSetupWindows]
-=== Windows: Using Microsoft Visual Studio[[ChSetupWin32]]
+=== Windows
 
 A quick setup guide for Windows development with recommended configurations.
 
+[#ChSetupWindowsMSVC]
+==== Using Microsoft Visual Studio[[ChSetupWin32]]
+
 [WARNING]
 ====
 Unless you know exactly what you are doing, you
@@ -292,7 +295,7 @@ Known traps are:
 
 [#ChSetupChocolatey]
 
-==== Recommended: Install Chocolatey
+===== Recommended: Install Chocolatey
 
 https://chocolatey.org/[Chocolatey] is a native package manager for
 Windows. There are https://chocolatey.org/packages[packages] for most of
@@ -314,7 +317,7 @@ choco install -y git cmake python3
 
 [#ChSetupMSVC]
 
-==== Install Microsoft Visual Studio
+===== Install Microsoft Visual Studio
 
 Download and install https://visualstudio.microsoft.com/thank-you-downloading-visual-studio/?sku=Community&rel=17[“Microsoft Visual Studio 2022 Community Edition”].
 If you prefer you can instead download and install https://visualstudio.microsoft.com/thank-you-downloading-visual-studio/?sku=Community&rel=16[“Microsoft Visual Studio 2019 Community Edition”].
@@ -326,7 +329,8 @@ all the optional components other than
 
 * “MSVC ... VS 2022 {cpp}” item with the “... build tools (Latest)”
 * “Windows 11 SDK”
-* “{cpp} CMake tools for Windows"
+* “{cpp} CMake tools for Windows”
+* “MSVC ... Spectre-mitigated libs” (optional)
 
 (unless you want to use them for purposes other than Wireshark).
 
@@ -341,17 +345,15 @@ choco install -y visualstudio2022community visualstudio2022-workload-nativedeskt
 // https://github.com/microsoft/winget-pkgs/tree/master/manifests/m/Microsoft/VisualStudio
 
 You can use other Microsoft C compiler variants, but VS2022 is used to
-build the development releases and is the preferred option. It’s
-possible to compile Wireshark with a wide range of Microsoft C compiler
-variants. For details see <<ChToolsMSChain>>.
+build the development releases for Windows and is the preferred option
+on Windows.  It’s possible to compile Wireshark with a wide range of
+Microsoft C compiler variants.  For details see <<ChToolsMSChain>>.
 
 You may have to do this as Administrator.
 
-Compiling with gcc or Clang is not recommended and will
-certainly not work (at least not without a lot of advanced
-tweaking). For further details on this topic, see
-<<ChToolsGNUChain>>. This may change in future as releases
-of Visual Studio add more cross-platform support.
+It might be possible to build Wireshark using https://clang.llvm.org/docs/MSVCCompatibility.html[clang-cl], but this has not been tested.
+Compiling with plain gcc or Clang is not recommended and will certainly not work (at least not without a lot of advanced tweaking).
+For further details on this topic, see <<ChToolsGNUChain>>. This may change in future as releases of Visual Studio add more cross-platform support.
 
 // XXX - mention the compiler and PSDK web installers -
 // which significantly reduce download size - and find out the
@@ -359,11 +361,11 @@ of Visual Studio add more cross-platform support.
 
 Why is this recommended?
 While this is a huge download, the Community Editions of Visual Studio are free (as in beer) and include the Visual Studio integrated debugger.
-Visual Studio 2022 is also used to create official Wireshark builds, so it will likely have fewer development-related problems.
+Visual Studio 2022 is also used to create official Wireshark builds for Windows, so it will likely have fewer development-related problems.
 
 [#ChSetupQt]
 
-==== Install Qt
+===== Install Qt
 
 The main Wireshark application uses the Qt windowing toolkit. To install
 Qt, go to the https://www.qt.io/download[“Download Qt” page], select
@@ -391,7 +393,7 @@ to cmake.
 
 [#ChSetupPython]
 
-==== Install Python
+===== Install Python
 
 Get a Python 3 installer from https://python.org/download/[] and install Python.
 Its installation location varies depending on the options selected in the installer and on the version of Python that you are installing.
@@ -413,7 +415,7 @@ Chocolatey will likely install Python in one of the locations above, or possibly
 
 [#ChSetupGit]
 
-==== Install Git
+===== Install Git
 
 Please note that the following is not required to build Wireshark but can be
 quite helpful when working with the sources.
@@ -433,23 +435,23 @@ _Use Git from the Windows Command Prompt_ (in chocolatey the _/GitOnlyOnPath_
 option). Do *not* select the _Use Git and optional Unix tools from the Windows Command Prompt_
 option (in chocolatey the _/GitAndUnixToolsOnPath_ option).
 
-===== The Official Windows Installer
+====== The Official Windows Installer
 
 The official command-line installer is available at https://git-scm.com/download/win.
 
-===== Git Extensions
+====== Git Extensions
 
 Git Extensions is a native Windows graphical Git client for
 Windows. You can download the installer from
 https://github.com/gitextensions/gitextensions/releases/latest.
 
-===== TortoiseGit
+====== TortoiseGit
 
 TortoiseGit is a native Windows graphical Git
 similar to TortoiseSVN. You can download the installer from
 https://tortoisegit.org/download/.
 
-===== Command Line client via Chocolatey
+====== Command Line client via Chocolatey
 
 The command line client can be installed (and updated) using Chocolatey:
 ----
@@ -459,7 +461,7 @@ choco install -y git
 // winget has git.
 // https://github.com/microsoft/winget-pkgs/tree/master/manifests/g/Git/Git
 
-===== Others
+====== Others
 
 A list of other GUI interfaces for Git can be found at
 https://git-scm.com/downloads/guis
@@ -467,7 +469,7 @@ https://git-scm.com/downloads/guis
 
 [#ChSetupCMake]
 
-==== Install CMake
+===== Install CMake
 
 While CMake is required to build Wireshark, it might have been installed as a component of either Visual Studio or Qt.
 If that’s the case you can skip this step.
@@ -488,7 +490,7 @@ Chocolatey ensures cmake.exe is on your path.
 
 [#ChSetupAsciidoctor]
 
-==== Install Asciidoctor, Xsltproc, And DocBook
+===== Install Asciidoctor, Xsltproc, And DocBook
 
 https://asciidoctor.org/[Asciidoctor] can be run directly as a Ruby script or via a Java wrapper (AsciidoctorJ).
 The JavaScript flavor (Asciidoctor.js) isn’t yet supported.
@@ -509,7 +511,7 @@ path and that xsltproc uses the DocBook catalog.
 
 // winget has no Asciidoctor, xsltproc, or DocBook packages.
 
-==== Install winflexbison
+===== Install winflexbison
 
 Get the winFlexBison installer from
 https://sourceforge.net/projects/winflexbison/
@@ -526,7 +528,7 @@ Chocolatey ensures win_flex.exe is on your path.
 
 // winget has no bison package.
 
-==== Optional: Install Perl
+===== Optional: Install Perl
 
 If needed you can get a Perl installer from
 http://strawberryperl.com/
@@ -545,7 +547,7 @@ choco install -y activeperl
 // winget has StrawberryPerl.
 // https://github.com/microsoft/winget-pkgs/tree/master/manifests/s/StrawberryPerl/StrawberryPerl
 
-==== Install and Prepare Sources
+===== Install and Prepare Sources
 
 [TIP]
 .Make sure everything works
@@ -591,7 +593,7 @@ Make sure your repository path doesn't contain spaces.
 
 [#ChSetupPrepareCommandCom]
 
-==== Open a Visual Studio Command Prompt
+===== Open a Visual Studio Command Prompt
 
 From the Start Menu (or Start Screen), navigate to the “Visual Studio 2022” folder and choose the https://docs.microsoft.com/en-us/cpp/build/building-on-the-command-line?view=msvc-170#developer_command_prompt_shortcuts[Command Prompt] appropriate for the build you wish to make, e.g. “x64 Native Tools Command Prompt for VS 2022” for a 64-bit version.
 Depending on your version of Windows the Command Prompt list might be directly under “Visual Studio 2022” or you might have to dig for it under multiple folders, e.g. menu:Visual Studio 2022[Visual Studio Tools,Windows Desktop Command Prompts].
@@ -655,7 +657,7 @@ The build directory can be deleted at any time and the build files regenerated a
 
 [#ChWindowsGenerate]
 
-==== Generate the build files
+===== Generate the build files
 
 CMake is used to process the CMakeLists.txt files in the source tree and produce build files appropriate
 for your system.
@@ -694,7 +696,7 @@ the environment variables `WIRESHARK_BASE_DIR` and `CMAKE_PREFIX_PATH`.
 
 [#ChWindowsBuild]
 
-==== Build Wireshark
+===== Build Wireshark
 
 Now it’s time to build Wireshark!
 
@@ -725,19 +727,19 @@ and then building the solution again.
 
 The build files produced by CMake will regenerate themselves if required by changes in the source tree.
 
-==== Debug Environment Setup
+===== Debug Environment Setup
 
 You can debug using the Visual Studio Debugger or WinDbg. See the section
 on using the <<ChToolsDebugger, Debugger Tools>>.
 
-==== Optional: Create User’s and Developer’s Guide
+===== Optional: Create User’s and Developer’s Guide
 
 To build the Wireshark User's Guide and the Wireshark Developer's Guide,
 build the `all_guides` target, e.g.  `msbuild all_guides.vcxproj`.
 Detailed information to build these guides can be found in the file
-_docbook\README.adoc_ in the Wireshark sources.
+_doc\README.documentation.adoc_ in the Wireshark sources.
 
-==== Optional: Create a Wireshark Installer
+===== Optional: Create a Wireshark Installer
 
 Note: You should have successfully built Wireshark
 before doing the following.
@@ -772,14 +774,14 @@ It’s a good idea to test on a different machine than the developer machine.
 
 [#ChSetupMSYS2]
 
-=== Windows: Using MinGW-w64 with MSYS2
+==== Using MinGW-w64 with MSYS2
 
 MSYS2 comes with different environments/subsystems and the first thing you
 have to decide is which one to use. The differences among the environments
 are mainly environment variables, default compilers/linkers, architecture,
 system libraries used etc. If you are unsure, go with UCRT64.
 
-==== Building from source
+===== Building from source
 
 . Open the shell for the selected 64-bit environment.
 
@@ -801,7 +803,7 @@ system libraries used etc. If you are unsure, go with UCRT64.
 
 The application should be launched using the same shell.
 
-==== Building an .exe installer
+===== Building an .exe installer
 
 . Follow the instructions above to compile Wireshark from source.
 
@@ -816,7 +818,7 @@ Alternatively you can also use the PKGBUILD included in the Wireshark
 source distribution to compile Wireshark into a binary package that can be
 https://www.msys2.org/wiki/Creating-Packages/[installed using pacman].
 
-==== Comparison with MSVC toolchain
+===== Comparison with MSVC toolchain
 
 The official Wireshark Windows installer is compiled using Microsoft Visual
 Studio (MSVC). Currently the MSYS2 build has the following limitations compared to
@@ -832,7 +834,7 @@ the build using MSVC:
 
 [#ChSetupCross]
 
-=== Windows: Cross-compilation using Linux
+==== Cross-compilation using Linux
 
 It is possible to compile Wireshark for Microsoft Windows using Linux and MinGW.
 This way developers can deploy Wireshark on Windows systems without requiring
@@ -840,7 +842,7 @@ a Windows host machine. Building for Windows using a Linux host is also
 easier for devs already familiar with Linux, the build itself is faster and it
 uses a very mature C/C++ compiler (GCC) and debugger (GDB).
 
-==== Using Fedora Linux
+===== Using Fedora Linux
 
 https://fedoraproject.org/[Fedora Linux] provides the best out-of-the-box
 support for MinGW cross-compilation. Fedora is what the project uses to test
@@ -851,7 +853,7 @@ involve some trial and error to setup.
 The build instructions on Fedora follow the familiar recipe for building Wireshark
 using Linux.
 
-===== Building from source
+====== Building from source
 
 . Install needed dependencies:
 
@@ -872,7 +874,7 @@ Note that currently it is not possible to run the test-suite when cross-compilin
 
 If successful the installer can be found in `$CMAKE_BINARY_DIR/packaging/nsis`.
 
-===== Notes and comparison with MSVC builds
+====== Notes and comparison with MSVC builds
 
 * Only the MSVCRT C library for Microsoft Windows can be used. Support for the
   UCRT (Universal C Runtime) library on Fedora Linux is in the initial stages of
@@ -890,7 +892,7 @@ If successful the installer can be found in `$CMAKE_BINARY_DIR/packaging/nsis`.
 
 * AirPcap is not supported.
 
-==== Using Arch Linux
+===== Using Arch Linux
 
 https://archlinux.org/[Arch Linux] has good support for MinGW using packages
 from the https://aur.archlinux.org/[AUR]. Note that the mingw-w64 AUR packages
diff --git a/docbook/wsdg_src/wsdg_sources.adoc b/doc/wsdg_src/wsdg_sources.adoc
index 9e2a3c10..38078f37 100644
--- a/docbook/wsdg_src/wsdg_sources.adoc
+++ b/doc/wsdg_src/wsdg_sources.adoc
@@ -25,7 +25,7 @@ such as where to find specific functionality. This is done in
 
 https://git-scm.com/[Git] is used to keep track of the changes made to the Wireshark source code.
 The official repository is hosted at {wireshark-gitlab-project-url}[GitLab], and incoming changes are evaluated and reviewed there.
-For more information on GitLab see https://docs.gitlab.com/ce/gitlab-basics/[their documentation].
+For more information on GitLab see https://docs.gitlab.com/ee/[their documentation].
 
 .Why Git?
 
@@ -38,6 +38,7 @@ GitLab makes it easy to contribute.
 You can make changes locally and push them to your own work area at gitlab.com, or if your change is minor you can make changes entirely within your web browser.
 
 .Historical trivia: GitLab is the *fourth* iteration of our source code repository and code review system.
+// Five if you include "sending patches to Gerald."
 
 Wireshark originally used https://www.nongnu.org/cvs/[Concurrent Versions System] (CVS) and migrated to https://subversion.apache.org/[Subversion] in July 2004.
 We migrated from Subversion to Git and https://www.gerritcodereview.com/[Gerrit] in January 2014, and from Gerrit to GitLab in August 2020.
@@ -68,6 +69,11 @@ Stable release maintenance. For example, release-3.4 is used to manage the 3.4.x
 Tags for major releases and release candidates consist of a “v” followed by a version number such as “v3.2.1” or “v3.2.3rc0”.
 Major releases additionally have a tag prefixed with “wireshark-” followed by a version number, such as “wireshark-3.2.0”.
 
+Tags created after August 1, 2024 are signed using SSH. This includes the tags for versions 4.4.0rc1, 4.4.0, 4.2.7, and 4.0.17. If you wish to verify these tags, you must have the following entry in __~/.ssh/allowed_signers__:
+
+    gerald@wireshark.org namespaces="git" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIBHe1qOxwBietT54lZ3qawTc8B9unWP+T3JVR9l2rQaP
+
+Tags were signed using GPG prior to August 2024.
 
 [#ChSrcGitWeb]
 === Browsing And Searching The Source Code
@@ -233,14 +239,13 @@ CMake can compile Wireshark for several different build types:
 |Type |Compiler Flags |Description
 
 |`RelWithDebInfo`
-|`-O2 -g`
-|Default, build with default optimizations and generate debug symbols.
-Enables assertions and disables debug level logs
+|`-O2 -g -DNDEBUG`
+|Build with optimizations and generate debug symbols.
+Disables assertions and disables debug level logs
 
 |`Debug`
-|`-O0 -g -DWS_DEBUG -DWS_DEBUG_UTF_8`
-|For development, no optimization. Enables assertions
-and debug level logs
+|`-g -DWS_DEBUG`
+|For development, no optimization. Enables assertions and debug level logs
 
 |`Release`
 |`-O3 -DNDEBUG`
@@ -381,7 +386,7 @@ all log output generated at or above this level is sent to the log output.
 Note that if the <<ChSrcBuildType,build type>> is not set to `Debug`
 then by default all log output for the logging levels "debug" and
 "noisy" will be optimized away by the compiler and cannot be emitted to the log
-output, regardless of the logging setings. To enable debug logging for all build
+output, regardless of the logging settings. To enable debug logging for all build
 types, set the CMake variable `-DENABLE_DEBUG=ON`.
 
 There is also a special "echo" logging level used exclusively for temporary debugging print outs (usually
@@ -637,7 +642,7 @@ For the steps below we’ll pretend that your username is “henry.perry”.
 
 . Sign in to {wireshark-gitlab-project-url} by clicking “Sign in / Register” in the upper right corner of the web page and following the login instructions.
 
-. https://docs.gitlab.com/ce/ssh/[Add an SSH key to your account] as described in the GitLab documentation.
+. https://docs.gitlab.com/ee/user/ssh.html[Add an SSH key to your account] as described in the GitLab documentation.
 
 . Make sure you have a clone of the main repository as described in <<ChSrcGit>>.
 
@@ -875,7 +880,6 @@ If that is not possible, it *must* use a compatible license.
 The following licenses are currently allowed:
 
 * BSD {spdx-license-url}BSD-1-Clause.html[1], {spdx-license-url}BSD-2-Clause.html[2], {spdx-license-url}BSD-3-Clause.html[3] clause
-* {spdx-license-url}GPL-3.0-or-later.html[GPL version 3 or later] *with* the https://www.gnu.org/software/bison/manual/html_node/Conditions.html[Bison parser exception]
 * {spdx-license-url}ISC.html[ISC]
 * {spdx-license-url}LGPL-2.0-or-later.html[LGPL v2 or later], including {spdx-license-url}LGPL-2.1-or-later.html[v2.1]
 * {spdx-license-url}MIT.html[MIT] / {spdx-license-url}X11.html[X11]
@@ -960,8 +964,8 @@ $ git cherry-pick -x 1ab2c3d4
 $ ninja
 $ ...
 
-# OPTIONAL: Add entries to docbook/release-notes.adoc.
-$EDITOR docbook/release-notes.adoc
+# OPTIONAL: Add entries to doc/release-notes.adoc.
+$EDITOR doc/release-notes.adoc
 
 # If you made any changes, update your commit.
 git commit --amend -a
@@ -1086,6 +1090,12 @@ instead of
 https://1.na.dl.wireshark.org/download/src/wireshark-{wireshark-version}.tar.xz
 
 [discrete]
+===== Staying Current
+
+Wireshark releases are announced on the link:{wireshark-mailing-lists-url}[wireshark-announce] mailing list.
+A https://appvisor.com/pad/[PAD] file is also published at https://www.wireshark.org/wireshark-pad.xml which contains the current stable version and release date.
+
+[discrete]
 ===== Artwork
 
 Logo and icon artwork can be found in the _image_ directory in the
diff --git a/docbook/wsdg_src/wsdg_tests.adoc b/doc/wsdg_src/wsdg_tests.adoc
index a9435ca7..a9435ca7 100644
--- a/docbook/wsdg_src/wsdg_tests.adoc
+++ b/doc/wsdg_src/wsdg_tests.adoc
diff --git a/docbook/wsdg_src/wsdg_tools.adoc b/doc/wsdg_src/wsdg_tools.adoc
index f1d99e94..09f1b576 100644
--- a/docbook/wsdg_src/wsdg_tools.adoc
+++ b/doc/wsdg_src/wsdg_tools.adoc
@@ -131,7 +131,7 @@ after the cmake run. To only view the current cache, add option `-N`.
 
 Depending on your needs, it might be useful to save your CMake configuration options in a file outside your build directory.
 CMake supports this via its https://cmake.org/cmake/help/v3.23/manual/cmake-presets.7.html[presets] option.
-For example, adding the follwing to `CMakeUserPresets.json` would let you build using Ninja in the `build` directory, enable ccache, and set a custom Qt directory by running `cmake --preset mydev`:
+For example, adding the following to `CMakeUserPresets.json` would let you build using Ninja in the `build` directory, enable ccache, and set a custom Qt directory by running `cmake --preset mydev`:
 
 [source,json]
 ----
@@ -487,9 +487,7 @@ Edition, it will include an SDK.
 === Documentation Toolchain
 
 Wireshark’s documentation is split across two directories.
-The `doc` directory contains man pages written in Asciidoctor markup.
-The `docbook` directory contains the User’s Guide, Developer’s Guide, and the release notes, which are also written in Asciidoctor markup.
-The split is for historical reasons (described below), and the documentation will likely be consolidated into one directory in the future.
+The `doc` directory contains man pages, User’s Guide, Developer’s Guide, and the release notes, which are written in Asciidoctor markup.
 
 Our various output formats are generated using the following tools.
 Intermediate formats are in _italics_.
diff --git a/docbook/wsdg_src/wsdg_userinterface.adoc b/doc/wsdg_src/wsdg_userinterface.adoc
index a4fe17a3..a4fe17a3 100644
--- a/docbook/wsdg_src/wsdg_userinterface.adoc
+++ b/doc/wsdg_src/wsdg_userinterface.adoc
diff --git a/docbook/wsdg_src/wsdg_works.adoc b/doc/wsdg_src/wsdg_works.adoc
index baa75403..88c2f7a5 100644
--- a/docbook/wsdg_src/wsdg_works.adoc
+++ b/doc/wsdg_src/wsdg_works.adoc
@@ -19,7 +19,7 @@ The following will give you a simplified overview of Wireshark’s function bloc
 [#ChWorksFigOverview]
 
 .Wireshark function blocks
-image::images/ws-function-blocks.png[{pdf-scaledwidth}]
+image::images/ws-function-blocks.svg[{pdf-scaledwidth}]
 
 The function blocks in more detail:
 
diff --git a/docbook/wsdg_src/images/ws-function-blocks.dia b/docbook/wsdg_src/images/ws-function-blocks.dia
deleted file mode 100644
index cc857810..00000000
--- a/docbook/wsdg_src/images/ws-function-blocks.dia
+++ /dev/null
diff --git a/docbook/wsdg_src/images/ws-function-blocks.png b/docbook/wsdg_src/images/ws-function-blocks.png
deleted file mode 100644
index 169e19e5..00000000
--- a/docbook/wsdg_src/images/ws-function-blocks.png
+++ /dev/null