Merge remote-tracking branch 'upstream/unstable' into add_version_sup…

…port_for_check_aof

.codespell/requirements.txt

@@ -1 +1 @@
-codespell==2.1.0
+codespell==2.2.5

.codespell/wordlist.txt

@@ -16,3 +16,6 @@ cancelability
 ist
 statics
 filetest
+ro
+exat
+clen

.github/workflows/ci.yml

@@ -17,24 +17,31 @@ jobs:
         sudo apt-get install tcl8.6 tclx
         ./runtest --verbose --tags -slow --dump-logs
     - name: module api test
-      run: ./runtest-moduleapi --verbose --dump-logs
+      run: CFLAGS='-Werror' ./runtest-moduleapi --verbose --dump-logs
+    - name: validate commands.def up to date
+      run: |
+        touch src/commands/ping.json
+        make commands.def
+        dirty=$(git diff)
+        if [[ ! -z  $dirty ]]; then echo $dirty; exit 1; fi
 
   test-sanitizer-address:
     runs-on: ubuntu-latest
     steps:
       - uses: actions/checkout@v3
       - name: make
-        run: make SANITIZER=address REDIS_CFLAGS='-Werror'
+        # build with TLS module just for compilation coverage
+        run: make SANITIZER=address REDIS_CFLAGS='-Werror -DDEBUG_ASSERTIONS' BUILD_TLS=module
       - name: testprep
         run: sudo apt-get install tcl8.6 tclx -y
       - name: test
         run: ./runtest --verbose --tags -slow --dump-logs
       - name: module api test
-        run: ./runtest-moduleapi --verbose --dump-logs
+        run: CFLAGS='-Werror' ./runtest-moduleapi --verbose --dump-logs
 
   build-debian-old:
     runs-on: ubuntu-latest
-    container: debian:oldoldstable
+    container: debian:buster
     steps:
     - uses: actions/checkout@v3
     - name: make
@@ -74,3 +81,4 @@ jobs:
       run: |
         yum -y install gcc make
         make REDIS_CFLAGS='-Werror'
+

.github/workflows/coverity.yml

@@ -0,0 +1,32 @@
+# Creates and uploads a Coverity build on a schedule
+name: Coverity Scan
+on:
+  schedule:
+  # Run once daily, since below 500k LOC can have 21 builds per week, per https://scan.coverity.com/faq#frequency
+  - cron: '0 0 * * *'
+  # Support manual execution
+  workflow_dispatch:
+jobs:
+  coverity:
+    if: github.repository == 'redis/redis'
+    runs-on: ubuntu-latest
+    steps:
+    - uses: actions/checkout@main
+    - name: Download and extract the Coverity Build Tool
+      run: |
+          wget -q https://scan.coverity.com/download/cxx/linux64 --post-data "token=${{ secrets.COVERITY_SCAN_TOKEN }}&project=redis-unstable" -O cov-analysis-linux64.tar.gz
+          mkdir cov-analysis-linux64
+          tar xzf cov-analysis-linux64.tar.gz --strip 1 -C cov-analysis-linux64
+    - name: Install Redis dependencies
+      run: sudo apt install -y gcc tcl8.6 tclx procps libssl-dev
+    - name: Build with cov-build
+      run: cov-analysis-linux64/bin/cov-build --dir cov-int make
+    - name: Upload the result
+      run: |
+          tar czvf cov-int.tgz cov-int
+          curl \
+            --form project=redis-unstable \
+            --form email=${{ secrets.COVERITY_SCAN_EMAIL }} \
+            --form token=${{ secrets.COVERITY_SCAN_TOKEN }} \
+            --form [email protected] \
+            https://scan.coverity.com/builds

.github/workflows/reply-schemas-linter.yml

@@ -0,0 +1,22 @@
+name: Reply-schemas linter
+
+on:
+  push:
+    paths:
+      - 'src/commands/*.json'
+  pull_request:
+    paths:
+      - 'src/commands/*.json'
+
+jobs:
+  reply-schemas-linter:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v3
+      - name: Setup nodejs
+        uses: actions/setup-node@v4
+      - name: Install packages
+        run: npm install ajv
+      - name: linter
+        run: node ./utils/reply_schema_linter.js
+

.gitignore

@@ -29,6 +29,7 @@ deps/lua/src/lua
 deps/lua/src/luac
 deps/lua/src/liblua.a
 deps/hdr_histogram/libhdrhistogram.a
+deps/fpconv/libfpconv.a
 tests/tls/*
 .make-*
 .prerequisites

00-RELEASENOTES

@@ -9,7 +9,7 @@ Usually "unstable" is stable enough for you to use it in development environment
 however you should never use it in production environments. It is possible
 to download the latest stable release here:
 
-    http://download.redis.io/releases/redis-stable.tar.gz
+    https://download.redis.io/redis-stable.tar.gz
 
 More information is available at https://redis.io
 

CONDUCT → CODE_OF_CONDUCT.md

@@ -26,7 +26,7 @@ Examples of unacceptable behavior include:
 advances of any kind
 * Trolling, insulting or derogatory comments, and personal or political attacks
 * Public or private harassment
-* Publishing others’ private information, such as a physical or email
+* Publishing others' private information, such as a physical or email
 address, without their explicit permission
 * Other conduct which could reasonably be considered inappropriate in a
 professional setting
@@ -89,8 +89,8 @@ Attribution
 This Code of Conduct is adapted from the Contributor Covenant,
 version 2.0, available at
 https://www.contributor-covenant.org/version/2/0/code_of_conduct.html.
-Community Impact Guidelines were inspired by Mozilla’s code of conduct
+Community Impact Guidelines were inspired by Mozilla's code of conduct
 enforcement ladder.
 For answers to common questions about this code of conduct, see the FAQ at
 https://www.contributor-covenant.org/faq. Translations are available at
-https://www.contributor-covenant.org/translations.
+https://www.contributor-covenant.org/translations.

README.md

@@ -75,9 +75,9 @@ When you update the source code with `git pull` or when code inside the
 dependencies tree is modified in any other way, make sure to use the following
 command in order to really clean everything and rebuild from scratch:
 
-    make distclean
+    % make distclean
 
-This will clean: jemalloc, lua, hiredis, linenoise.
+This will clean: jemalloc, lua, hiredis, linenoise and other dependencies.
 
 Also if you force certain build options like 32bit target, no C compiler
 optimizations (for debugging purposes), and other similar build time options,
@@ -196,7 +196,7 @@ In order to install Redis binaries into /usr/local/bin, just use:
 You can use `make PREFIX=/some/other/directory install` if you wish to use a
 different destination.
 
-Make install will just install binaries in your system, but will not configure
+`make install` will just install binaries in your system, but will not configure
 init scripts and configuration files in the appropriate place. This is not
 needed if you just want to play a bit with Redis, but if you are installing
 it the proper way for a production system, we have a script that does this
@@ -223,11 +223,11 @@ public discussion groups, you agree to release your code under the terms
 of the BSD license that you can find in the [COPYING][1] file included in the Redis
 source distribution.
 
-Please see the [CONTRIBUTING][2] file in this source distribution for more
+Please see the [CONTRIBUTING.md][2] file in this source distribution for more
 information. For security bugs and vulnerabilities, please see [SECURITY.md][3].
 
 [1]: https://github.com/redis/redis/blob/unstable/COPYING
-[2]: https://github.com/redis/redis/blob/unstable/CONTRIBUTING
+[2]: https://github.com/redis/redis/blob/unstable/CONTRIBUTING.md
 [3]: https://github.com/redis/redis/blob/unstable/SECURITY.md
 
 Redis internals
@@ -313,19 +313,23 @@ The client structure defines a *connected client*:
 * The `fd` field is the client socket file descriptor.
 * `argc` and `argv` are populated with the command the client is executing, so that functions implementing a given Redis command can read the arguments.
 * `querybuf` accumulates the requests from the client, which are parsed by the Redis server according to the Redis protocol and executed by calling the implementations of the commands the client is executing.
-* `reply` and `buf` are dynamic and static buffers that accumulate the replies the server sends to the client. These buffers are incrementally written to the socket as soon as the file descriptor is writeable.
+* `reply` and `buf` are dynamic and static buffers that accumulate the replies the server sends to the client. These buffers are incrementally written to the socket as soon as the file descriptor is writable.
 
 As you can see in the client structure above, arguments in a command
 are described as `robj` structures. The following is the full `robj`
 structure, which defines a *Redis object*:
 
-    typedef struct redisObject {
-        unsigned type:4;
-        unsigned encoding:4;
-        unsigned lru:LRU_BITS; /* lru time (relative to server.lruclock) */
-        int refcount;
-        void *ptr;
-    } robj;
+```c
+struct redisObject {
+    unsigned type:4;
+    unsigned encoding:4;
+    unsigned lru:LRU_BITS; /* LRU time (relative to global lru_clock) or
+                            * LFU data (least significant 8 bits frequency
+                            * and most significant 16 bits access time). */
+    int refcount;
+    void *ptr;
+};
+```
 
 Basically this structure can represent all the basic Redis data types like
 strings, lists, sets, sorted sets and so forth. The interesting thing is that
@@ -366,7 +370,7 @@ commands.c
 ---
 This file is auto generated by utils/generate-command-code.py, the content is based on the JSON files in the src/commands folder.
 These are meant to be the single source of truth about the Redis commands, and all the metadata about them.
-These JSON files are not meant to be used directly by anyone directly, instead that metadata can be obtained via the COMMAND command.
+These JSON files are not meant to be used by anyone directly, instead that metadata can be obtained via the `COMMAND` command.
 
 networking.c
 ---
@@ -375,7 +379,7 @@ This file defines all the I/O functions with clients, masters and replicas
 (which in Redis are just special clients):
 
 * `createClient()` allocates and initializes a new client.
-* the `addReply*()` family of functions are used by command implementations in order to append data to the client structure, that will be transmitted to the client as a reply for a given command executed.
+* The `addReply*()` family of functions are used by command implementations in order to append data to the client structure, that will be transmitted to the client as a reply for a given command executed.
 * `writeToClient()` transmits the data pending in the output buffers to the client and is called by the *writable event handler* `sendReplyToClient()`.
 * `readQueryFromClient()` is the *readable event handler* and accumulates data read from the client into the query buffer.
 * `processInputBuffer()` is the entry point in order to parse the client query buffer according to the Redis protocol. Once commands are ready to be processed, it calls `processCommand()` which is defined inside `server.c` in order to actually execute the command.
@@ -416,7 +420,7 @@ implementations are the following:
 * `lookupKeyRead()` and `lookupKeyWrite()` are used in order to get a pointer to the value associated to a given key, or `NULL` if the key does not exist.
 * `dbAdd()` and its higher level counterpart `setKey()` create a new key in a Redis database.
 * `dbDelete()` removes a key and its associated value.
-* `emptyDb()` removes an entire single database or all the databases defined.
+* `emptyData()` removes an entire single database or all the databases defined.
 
 The rest of the file implements the generic commands exposed to the client.
 
@@ -451,12 +455,13 @@ replicas, or to continue the replication after a disconnection.
 
 Script
 ---
-The script unit is compose of 3 units
-* `script.c` - integration of scripts with Redis (commands execution, set replication/resp, ..)
+
+The script unit is composed of 3 units:
+* `script.c` - integration of scripts with Redis (commands execution, set replication/resp, ...)
 * `script_lua.c` - responsible to execute Lua code, uses script.c to interact with Redis from within the Lua code.
 * `function_lua.c` - contains the Lua engine implementation, uses script_lua.c to execute the Lua code.
-* `functions.c` - Contains Redis Functions implementation (FUNCTION command), uses functions_lua.c if the function it wants to invoke needs the Lua engine.
-* `eval.c` - Contains the `eval` implementation using `script_lua.c` to invoke the Lua code.
+* `functions.c` - contains Redis Functions implementation (FUNCTION command), uses functions_lua.c if the function it wants to invoke needs the Lua engine.
+* `eval.c` - contains the `eval` implementation using `script_lua.c` to invoke the Lua code.
 
 
 Other C files
@@ -476,24 +481,22 @@ Anatomy of a Redis command
 
 All the Redis commands are defined in the following way:
 
-    void foobarCommand(client *c) {
-        printf("%s",c->argv[1]->ptr); /* Do something with the argument. */
-        addReply(c,shared.ok); /* Reply something to the client. */
-    }
-
-The command is then referenced inside `server.c` in the command table:
-
-    {"foobar",foobarCommand,2,"rtF",0,NULL,0,0,0,0,0},
+```c
+void foobarCommand(client *c) {
+    printf("%s",c->argv[1]->ptr); /* Do something with the argument. */
+    addReply(c,shared.ok); /* Reply something to the client. */
+}
+```
 
-In the above example `2` is the number of arguments the command takes,
-while `"rtF"` are the command flags, as documented in the command table
-top comment inside `server.c`.
+The command function is referenced by a JSON file, together with its metadata, see `commands.c` described above for details.
+The command flags are documented in the comment above the `struct redisCommand` in `server.h`.
+For other details, please refer to the `COMMAND` command. https://redis.io/commands/command/
 
 After the command operates in some way, it returns a reply to the client,
 usually using `addReply()` or a similar function defined inside `networking.c`.
 
 There are tons of command implementations inside the Redis source code
-that can serve as examples of actual commands implementations. Writing
+that can serve as examples of actual commands implementations (e.g. pingCommand). Writing
 a few toy commands can be a good exercise to get familiar with the code base.
 
 There are also many other files not described here, but it is useless to

SECURITY.md

@@ -11,17 +11,17 @@ unless this is not possible or feasible with a reasonable effort.
 
 | Version | Supported          |
 | ------- | ------------------ |
+| 7.2.x   | :white_check_mark: |
 | 7.0.x   | :white_check_mark: |
 | 6.2.x   | :white_check_mark: |
-| 6.0.x   | :white_check_mark: |
-| < 6.0   | :x:                |
+| < 6.2   | :x:                |
 
 ## Reporting a Vulnerability
 
-If you believe you’ve discovered a serious vulnerability, please contact the
+If you believe you've discovered a serious vulnerability, please contact the
 Redis core team at [email protected]. We will evaluate your report and if
 necessary issue a fix and an advisory. If the issue was previously undisclosed,
-we’ll also mention your name in the credits.
+we'll also mention your name in the credits.
 
 ## Responsible Disclosure
 
@@ -36,7 +36,7 @@ embargo on public disclosure.
 
 Vendors on the list are individuals or organizations that maintain Redis
 distributions or provide Redis as a service, who have third party users who
-will benefit from the vendor’s ability to prepare for a new version or deploy a
+will benefit from the vendor's ability to prepare for a new version or deploy a
 fix early.
 
 If you believe you should be on the list, please contact us and we will

TLS.md

@@ -9,8 +9,14 @@ Getting Started
 To build with TLS support you'll need OpenSSL development libraries (e.g.
 libssl-dev on Debian/Ubuntu).
 
+To build TLS support as Redis built-in:
 Run `make BUILD_TLS=yes`.
 
+Or to build TLS as Redis module:
+Run `make BUILD_TLS=module`.
+
+Note that sentinel mode does not support TLS module.
+
 ### Tests
 
 To run Redis test suite with TLS, you'll need TLS support for TCL (i.e.
@@ -22,16 +28,27 @@ To run Redis test suite with TLS, you'll need TLS support for TCL (i.e.
 2. Run `./runtest --tls` or `./runtest-cluster --tls` to run Redis and Redis
    Cluster tests in TLS mode.
 
+3. Run `./runtest --tls-module` or `./runtest-cluster --tls-module` to
+   run Redis and Redis cluster tests in TLS mode with Redis module.
+
 ### Running manually
 
 To manually run a Redis server with TLS mode (assuming `gen-test-certs.sh` was
 invoked so sample certificates/keys are available):
 
+For TLS built-in mode:
     ./src/redis-server --tls-port 6379 --port 0 \
         --tls-cert-file ./tests/tls/redis.crt \
         --tls-key-file ./tests/tls/redis.key \
         --tls-ca-cert-file ./tests/tls/ca.crt
 
+For TLS module mode:
+    ./src/redis-server --tls-port 6379 --port 0 \
+        --tls-cert-file ./tests/tls/redis.crt \
+        --tls-key-file ./tests/tls/redis.key \
+        --tls-ca-cert-file ./tests/tls/ca.crt \
+        --loadmodule src/redis-tls.so
+
 To connect to this Redis server with `redis-cli`:
 
     ./src/redis-cli --tls \