1. 23 Jul, 2018 1 commit
  2. 13 Jul, 2018 1 commit
  3. 02 Jul, 2018 1 commit
  4. 27 Jun, 2018 1 commit
  5. 13 Jun, 2018 1 commit
  6. 12 Jun, 2018 1 commit
  7. 09 Jun, 2018 2 commits
  8. 07 Jun, 2018 2 commits
  9. 24 May, 2018 1 commit
  10. 15 Mar, 2018 1 commit
  11. 14 Mar, 2018 1 commit
    • antirez's avatar
      Cluster: ability to prevent slaves from failing over their masters. · 432bf477
      antirez authored
      This commit, in some parts derived from PR #3041 which is no longer
      possible to merge (because the user deleted the original branch),
      implements the ability of slaves to have a special configuration
      preventing that they try to start a failover when the master is failing.
      
      There are multiple reasons for wanting this, and the feautre was
      requested in issue #3021 time ago.
      
      The differences between this patch and the original PR are the
      following:
      
      1. The flag is saved/loaded on the nodes configuration.
      2. The 'myself' node is now flag-aware, the flag is updated as needed
         when the configuration is changed via CONFIG SET.
      3. The flag name uses NOFAILOVER instead of NO_FAILOVER to be consistent
         with existing NOADDR.
      4. The redis.conf documentation was rewritten.
      
      Thanks to @deep011 for the original patch.
      432bf477
  12. 12 Mar, 2018 1 commit
    • Oran Agra's avatar
      active defrag v2 · be1b4aa9
      Oran Agra authored
      - big keys are not defragged in one go from within the dict scan
        instead they are scanned in parts after the main dict hash bucket is done.
      - add latency monitor sample for defrag
      - change default active-defrag-cycle-min to induce lower latency
      - make active defrag start a new scan right away if needed, so it's easier
        (for the test suite) to detect when it's done
      - make active defrag quick the current cycle after each db / big key
      - defrag  some non key long term global allocations
      - some refactoring for smaller functions and more reusable code
      - during dict rehashing, one scan iteration of the dict, can end up scanning
        one bucket in the smaller dict and many many buckets in the larger dict.
        so waiting for 16 scan iterations before checking the time, may be much too long.
      be1b4aa9
  13. 26 Jan, 2018 1 commit
  14. 11 Jan, 2018 2 commits
  15. 29 Dec, 2017 1 commit
  16. 06 Dec, 2017 1 commit
    • antirez's avatar
      Change indentation and other minor details of PR #4489. · 522760fa
      antirez authored
      The main change introduced by this commit is pretending that help
      arrays are more text than code, thus indenting them at level 0. This
      improves readability, and is an old practice when defining arrays of
      C strings describing text.
      
      Additionally a few useless return statements are removed, and the HELP
      subcommand capitalized when printed to the user.
      522760fa
  17. 03 Dec, 2017 1 commit
  18. 27 Nov, 2017 1 commit
  19. 15 Jul, 2017 1 commit
  20. 20 Feb, 2017 1 commit
    • antirez's avatar
      Use SipHash hash function to mitigate HashDos attempts. · adeed29a
      antirez authored
      This change attempts to switch to an hash function which mitigates
      the effects of the HashDoS attack (denial of service attack trying
      to force data structures to worst case behavior) while at the same time
      providing Redis with an hash function that does not expect the input
      data to be word aligned, a condition no longer true now that sds.c
      strings have a varialbe length header.
      
      Note that it is possible sometimes that even using an hash function
      for which collisions cannot be generated without knowing the seed,
      special implementation details or the exposure of the seed in an
      indirect way (for example the ability to add elements to a Set and
      check the return in which Redis returns them with SMEMBERS) may
      make the attacker's life simpler in the process of trying to guess
      the correct seed, however the next step would be to switch to a
      log(N) data structure when too many items in a single bucket are
      detected: this seems like an overkill in the case of Redis.
      
      SPEED REGRESION TESTS:
      
      In order to verify that switching from MurmurHash to SipHash had
      no impact on speed, a set of benchmarks involving fast insertion
      of 5 million of keys were performed.
      
      The result shows Redis with SipHash in high pipelining conditions
      to be about 4% slower compared to using the previous hash function.
      However this could partially be related to the fact that the current
      implementation does not attempt to hash whole words at a time but
      reads single bytes, in order to have an output which is endian-netural
      and at the same time working on systems where unaligned memory accesses
      are a problem.
      
      Further X86 specific optimizations should be tested, the function
      may easily get at the same level of MurMurHash2 if a few optimizations
      are performed.
      adeed29a
  21. 11 Jan, 2017 1 commit
  22. 30 Dec, 2016 1 commit
  23. 19 Dec, 2016 1 commit
    • antirez's avatar
      Only show Redis logo if logging to stdout / TTY. · 06bfeb48
      antirez authored
      You can still force the logo in the normal logs.
      For motivations, check issue #3112. For me the reason is that actually
      the logo is nice to have in interactive sessions, but inside the logs
      kinda loses its usefulness, but for the ability of users to recognize
      restarts easily: for this reason the new startup sequence shows a one
      liner ASCII "wave" so that there is still a bit of visual clue.
      
      Startup logging was modified in order to log events in more obvious
      ways, and to log more events. Also certain important informations are
      now more easy to parse/grep since they are printed in field=value style.
      
      The option --always-show-logo in redis.conf was added, defaulting to no.
      06bfeb48
  24. 16 Dec, 2016 2 commits
    • antirez's avatar
      Switch PFCOUNT to LogLog-Beta algorithm. · 87538cb7
      antirez authored
      The new algorithm provides the same speed with a smaller error for
      cardinalities in the range 0-100k. Before switching, the new and old
      algorithm behavior was studied in details in the context of
      issue #3677. You can find a few graphs and motivations there.
      87538cb7
    • Harish Murthy's avatar
      LogLog-Beta Algorithm support within HLL · c55e3fba
      Harish Murthy authored
      Config option to use LogLog-Beta Algorithm for Cardinality
      c55e3fba
  25. 26 Sep, 2016 1 commit
    • antirez's avatar
      Security: CONFIG SET client-output-buffer-limit overflow fixed. · 6d9f8e24
      antirez authored
      This commit fixes a vunlerability reported by Cory Duplantis
      of Cisco Talos, see TALOS-2016-0206 for reference.
      
      CONFIG SET client-output-buffer-limit accepts as client class "master"
      which is actually only used to implement CLIENT KILL. The "master" class
      has ID 3. What happens is that the global structure:
      
          server.client_obuf_limits[class]
      
      Is accessed with class = 3. However it is a 3 elements array, so writing
      the 4th element means to write up to 24 bytes of memory *after* the end
      of the array, since the structure is defined as:
      
          typedef struct clientBufferLimitsConfig {
              unsigned long long hard_limit_bytes;
              unsigned long long soft_limit_bytes;
              time_t soft_limit_seconds;
          } clientBufferLimitsConfig;
      
      EVALUATION OF IMPACT:
      
      Checking what's past the boundaries of the array in the global
      'server' structure, we find AOF state fields:
      
          clientBufferLimitsConfig client_obuf_limits[CLIENT_TYPE_OBUF_COUNT];
          /* AOF persistence */
          int aof_state;                  /* AOF_(ON|OFF|WAIT_REWRITE) */
          int aof_fsync;                  /* Kind of fsync() policy */
          char *aof_filename;             /* Name of the AOF file */
          int aof_no_fsync_on_rewrite;    /* Don't fsync if a rewrite is in prog. */
          int aof_rewrite_perc;           /* Rewrite AOF if % growth is > M and... */
          off_t aof_rewrite_min_size;     /* the AOF file is at least N bytes. */
          off_t aof_rewrite_base_size;    /* AOF size on latest startup or rewrite. */
          off_t aof_current_size;         /* AOF current size. */
      
      Writing to most of these fields should be harmless and only cause problems in
      Redis persistence that should not escalate to security problems.
      However unfortunately writing to "aof_filename" could be potentially a
      security issue depending on the access pattern.
      
      Searching for "aof.filename" accesses in the source code returns many different
      usages of the field, including using it as input for open(), logging to the
      Redis log file or syslog, and calling the rename() syscall.
      
      It looks possible that attacks could lead at least to informations
      disclosure of the state and data inside Redis. However note that the
      attacker must already have access to the server. But, worse than that,
      it looks possible that being able to change the AOF filename can be used
      to mount more powerful attacks: like overwriting random files with AOF
      data (easily a potential security issue as demostrated here:
      http://antirez.com/news/96), or even more subtle attacks where the
      AOF filename is changed to a path were a malicious AOF file is loaded
      in order to exploit other potential issues when the AOF parser is fed
      with untrusted input (no known issue known currently).
      
      The fix checks the places where the 'master' class is specifiedf in
      order to access configuration data structures, and return an error in
      this cases.
      
      WHO IS AT RISK?
      
      The "master" client class was introduced in Redis in Jul 28 2015.
      Every Redis instance released past this date is not vulnerable
      while all the releases after this date are. Notably:
      
          Redis 3.0.x is NOT vunlerable.
          Redis 3.2.x IS vulnerable.
          Redis unstable is vulnerable.
      
      In order for the instance to be at risk, at least one of the following
      conditions must be true:
      
          1. The attacker can access Redis remotely and is able to send
             the CONFIG SET command (often banned in managed Redis instances).
      
          2. The attacker is able to control the "redis.conf" file and
             can wait or trigger a server restart.
      
      The problem was fixed 26th September 2016 in all the releases affected.
      6d9f8e24
  26. 09 Aug, 2016 1 commit
  27. 27 Jul, 2016 1 commit
    • antirez's avatar
      Ability of slave to announce arbitrary ip/port to master. · 55385f99
      antirez authored
      This feature is useful, especially in deployments using Sentinel in
      order to setup Redis HA, where the slave is executed with NAT or port
      forwarding, so that the auto-detected port/ip addresses, as listed in
      the "INFO replication" output of the master, or as provided by the
      "ROLE" command, don't match the real addresses at which the slave is
      reachable for connections.
      55385f99
  28. 20 Jul, 2016 1 commit
  29. 15 Jul, 2016 1 commit
  30. 04 Jul, 2016 1 commit
  31. 13 Jun, 2016 3 commits
  32. 05 Jun, 2016 2 commits
  33. 22 May, 2016 1 commit