1. 22 Jun, 2017 1 commit
  2. 08 Apr, 2017 1 commit
  3. 30 Jan, 2017 1 commit
    • antirez's avatar
      Security: Cross Protocol Scripting protection. · 874804da
      antirez authored
      This is an attempt at mitigating problems due to cross protocol
      scripting, an attack targeting services using line oriented protocols
      like Redis that can accept HTTP requests as valid protocol, by
      discarding the invalid parts and accepting the payloads sent, for
      example, via a POST request.
      
      For this to be effective, when we detect POST and Host: and terminate
      the connection asynchronously, the networking code was modified in order
      to never process further input. It was later verified that in a
      pipelined request containing a POST command, the successive commands are
      not executed.
      874804da
  4. 28 Jul, 2016 1 commit
    • antirez's avatar
      Ability of slave to announce arbitrary ip/port to master. · 0a45fbc3
      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.
      0a45fbc3
  5. 27 Jul, 2016 1 commit
    • antirez's avatar
      Avoid simultaneous RDB and AOF child process. · 21cffc26
      antirez authored
      This patch, written in collaboration with Oran Agra (@oranagra) is a companion
      to 780a8b1d. Together the two patches should avoid that the AOF and RDB saving
      processes can be spawned at the same time. Previously conditions that
      could lead to two saving processes at the same time were:
      
      1. When AOF is enabled via CONFIG SET and an RDB saving process is
         already active.
      
      2. When the SYNC command decides to start an RDB saving process ASAP in
         order to serve a new slave that cannot partially resynchronize (but
         only if we have a disk target for replication, for diskless
         replication there is not such a problem).
      
      Condition "1" is not very severe but "2" can happen often and is
      definitely good at degrading Redis performances in an unexpected way.
      
      The two commits have the effect of always spawning RDB savings for
      replication in replicationCron() instead of attempting to start an RDB
      save synchronously. Moreover when a BGSAVE or AOF rewrite must be
      performed, they are instead just postponed using flags that will try to
      perform such operations ASAP.
      
      Finally the BGSAVE command was modified in order to accept a SCHEDULE
      option so that if an AOF rewrite is in progress, when this option is
      given, the command no longer returns an error, but instead schedules an
      RDB rewrite operation for when it will be possible to start it.
      21cffc26
  6. 04 Jul, 2016 2 commits
  7. 15 Jun, 2016 1 commit
  8. 18 May, 2016 2 commits
  9. 05 May, 2016 1 commit
    • therealbill's avatar
      fix for #3187 · 3a481067
      therealbill authored
      I've renamed maxmemoryToString to evictPolicyToString since that is
      more accurate (and easier to mentally connect with the correct data), as
      well as updated the function to user server.maxmemory_policy rather than
      server.maxmemory. Now with a default config it is actually returning
      the correct policy rather than volatile-lru.
      3a481067
  10. 04 May, 2016 1 commit
  11. 02 May, 2016 1 commit
    • antirez's avatar
      BITFIELD command initial implementation. · 761a7728
      antirez authored
      The new bitfield command is an extension to the Redis bit operations,
      where not just single bit operations are performed, but the array of
      bits composing a string, can be addressed at random, not aligned
      offsets, with any width unsigned and signed integers like u8, s5, u10
      (up to 64 bit signed integers and 63 bit unsigned integers).
      
      The BITFIELD command supports subcommands that can SET, GET, or INCRBY
      those arbitrary bit counters, with multiple overflow semantics.
      
      Trivial and credits:
      
      A similar command was imagined a few times in the past, but for
      some reason looked a bit far fetched or not well specified.
      Finally the command was proposed again in a clear form by
      Yoav Steinberg from Redis Labs, that proposed a set of commands on
      arbitrary sized integers stored at bit offsets.
      
      Starting from this proposal I wrote an initial specification of a single
      command with sub-commands similar to what Yoav envisioned, using short
      names for types definitions, and adding control on the overflow.
      
      This commit is the resulting implementation.
      
      Examples:
      
          BITFIELD mykey OVERFLOW wrap INCRBY i2 10 -1 GET i2 10
      761a7728
  12. 18 Feb, 2016 2 commits
  13. 29 Jan, 2016 1 commit
  14. 08 Jan, 2016 1 commit
    • antirez's avatar
      New security feature: Redis protected mode. · 273c49e7
      antirez authored
      An exposed Redis instance on the internet can be cause of serious
      issues. Since Redis, by default, binds to all the interfaces, it is easy
      to forget an instance without any protection layer, for error.
      
      Protected mode try to address this feature in a soft way, providing a
      layer of protection, but giving clues to Redis users about why the
      server is not accepting connections.
      
      When protected mode is enabeld (the default), and if there are no
      minumum hints about the fact the server is properly configured (no
      "bind" directive is used in order to restrict the server to certain
      interfaces, nor a password is set), clients connecting from external
      intefaces are refused with an error explaining what to do in order to
      fix the issue.
      
      Clients connecting from the IPv4 and IPv6 lookback interfaces are still
      accepted normally, similarly Unix domain socket connections are not
      restricted in any way.
      273c49e7
  15. 17 Dec, 2015 2 commits
    • antirez's avatar
      Hopefully better memory test on crash. · fc00042e
      antirez authored
      The old test, designed to do a transformation on the bits that was
      invertible, in order to avoid touching the original memory content, was
      not effective as it was redis-server --test-memory. The former often
      reported OK while the latter was able to spot the error.
      
      So the test was substituted with one that may perform better, however
      the new one must backup the memory tested, so it tests memory in small
      pieces. This limits the effectiveness because of the CPU caches. However
      some attempt is made in order to trash the CPU cache between the fill
      and the check stages, but not for the addressing test unfortunately.
      
      We'll see if this test will be able to find errors where the old failed.
      fc00042e
    • antirez's avatar
      4fee3903
  16. 13 Dec, 2015 1 commit
  17. 19 Nov, 2015 3 commits
  18. 05 Nov, 2015 2 commits
  19. 30 Oct, 2015 6 commits
    • antirez's avatar
      Scripting: ability to turn on Lua commands style replication globally. · 8695d960
      antirez authored
      Currently this feature is only accessible via DEBUG for testing, since
      otherwise depending on the instance configuration a given script works
      or is broken, which is against the Redis philosophy.
      8695d960
    • antirez's avatar
      Lua script selective replication fixes. · dfe7f797
      antirez authored
      dfe7f797
    • antirez's avatar
      Lua script selective replication WIP. · a1d1ca14
      antirez authored
      a1d1ca14
    • antirez's avatar
      Scripting: single commands replication mode implemented. · cbbfaf6a
      antirez authored
      By calling redis.replicate_commands(), the scripting engine of Redis
      switches to commands replication instead of replicating whole scripts.
      This is useful when the script execution is costly but only results in a
      few writes performed to the dataset.
      
      Morover, in this mode, it is possible to call functions with side
      effects freely, since the script execution does not need to be
      deterministic: anyway we'll capture the outcome from the point of view
      of changes to the dataset.
      
      In this mode math.random() returns different sequences at every call.
      
      If redis.replicate_commnads() is not called before any other write, the
      command returns false and sticks to whole scripts replication instead.
      cbbfaf6a
    • antirez's avatar
    • antirez's avatar
      CLIENT REPLY command implemented: ON, OFF and SKIP modes. · de4d6caf
      antirez authored
      Sometimes it can be useful for clients to completely disable replies
      from the Redis server. For example when the client sends fire and forget
      commands or performs a mass loading of data, or in caching contexts
      where new data is streamed constantly. In such contexts to use server
      time and bandwidth in order to send back replies to clients, which are
      going to be ignored, is a shame.
      
      Multiple mechanisms are possible to implement such a feature. For
      example it could be a feature of MULTI/EXEC, or a command prefix
      such as "NOREPLY SADD myset foo", or a different mechanism that allows
      to switch on/off requests using the CLIENT command.
      
      The MULTI/EXEC approach has the problem that transactions are not
      strictly part of the no-reply semantics, and if we want to insert a lot
      of data in a bulk way, creating a huge MULTI/EXEC transaction in the
      server memory is bad.
      
      The prefix is the best in this specific use case since it does not allow
      desynchronizations, and is pretty clear semantically. However Redis
      internals and client libraries are not prepared to handle this
      currently.
      
      So the implementation uses the CLIENT command, providing a new REPLY
      subcommand with three options:
      
          CLIENT REPLY OFF disables the replies, and does not reply itself.
          CLIENT REPLY ON re-enables the replies, replying +OK.
          CLIENT REPLY SKIP only discards the reply of the next command, and
                            like OFF does not reply anything itself.
      
      The reason to add the SKIP command is that it allows to have an easy
      way to send conceptually "single" commands that don't need a reply
      as the sum of two pipelined commands:
      
          CLIENT REPLY SKIP
          SET key value
      
      Note that CLIENT REPLY ON replies with +OK so it should be used when
      sending multiple commands that don't need a reply. However since it
      replies with +OK the client can check that the connection is still
      active and all the previous commands were received.
      
      This is currently just into Redis "unstable" so the proposal can be
      modified or abandoned based on users inputs.
      de4d6caf
  20. 15 Oct, 2015 2 commits
  21. 01 Oct, 2015 5 commits
  22. 06 Aug, 2015 2 commits