1. 08 Feb, 2022 1 commit
  2. 22 Oct, 2021 2 commits
  3. 06 Oct, 2021 2 commits
  4. 05 Oct, 2021 1 commit
  5. 31 Aug, 2021 4 commits
  6. 30 Jun, 2021 1 commit
    • Release GIL while compiling Yara rules (#183) · 46f7e1ff
      * Release GIL when compiling rules.
      
      The compilation is a blocking operation and can be potentially CPU
      intensive. There is no reason to hold GIL.
      
      * Lock the GIL in callback to prevent segmentation fault.
      
      To be uniform with other callbacks and to prevent the SIGSEGV we have to
      lock the GIL while we want to interact with python objects. The callback
      is called from a C code releases GIL. Other callback functions use the same
      locking strategy.
      Oliver Nemček authored
  7. 21 Jun, 2021 1 commit
  8. 26 Apr, 2021 1 commit
  9. 16 Apr, 2021 1 commit
  10. 18 Mar, 2021 2 commits
  11. 16 Mar, 2021 2 commits
  12. 15 Mar, 2021 1 commit
  13. 12 Mar, 2021 4 commits
  14. 23 Feb, 2021 2 commits
    • Add support for exposing runtime warnings via a callback. (#160) · d20e6f16
      Add support for a "warnings_callback" argument to Rules.match(). If provided the
      function definition needs to be:
      
      def warnings_callback(warning_type, message)
      
      The callback will be called with a warning type of yara.WARNING_TOO_MANY_MATCHES
      and the message will be a string indicating which rule caused the warning. I
      think a warning type and a message is reasonably flexible in case we introduce
      other runtime warnings in the future.
      
      If a callback is not provided we print a warning on stderr using the normal
      python warning system. It's worth noting the function I'm using was introduced
      in python 3.2. I can switch it to something more portable if you don't want to
      pull support for 2.x yet.
      
      While I'm here, also chase the renaming of rules_list_head and other list
      variables so that it can compile with latest yara master.
      Wesley Shields authored
    • Added check for stdbool.h header and forcing its use (#159) · a7e5627b
      When compiling YARA without Python bindings, stdbool.h is actually used
      if it can be used. However Python bindings completely ignore it resulting
      in YARA defining its own bool type with sizeof(bool) == sizeof(int).
      However before [#1377](https://github.com/VirusTotal/yara/pull/1377), this
      can result in different compilation units using different sizes of
      bool type and chaos ensues.
      Marek Milkovič authored
  15. 03 Feb, 2021 2 commits
  16. 27 Jan, 2021 1 commit
  17. 18 Jan, 2021 1 commit
  18. 14 Jan, 2021 1 commit
  19. 04 Jan, 2021 4 commits
  20. 24 Dec, 2020 2 commits
  21. 19 Oct, 2020 2 commits
  22. 02 Sep, 2020 1 commit
    • Allow a Py_buffer as data for Rules_match (#152) · fa3795f9
      * Allow a Py_buffer as data for Rules_match
      
      This makes rules matching compatible with data objects
      `PyArg_ParseTuple` does not consider read-only (even though they might
      actually be), such a memoryviews. The main change is replacing the `s#`
      formatter with `s*` and replacing the `(pointer, length)` pair with a
      `Py_buffer` object accordingly. Additional care must be taken to release
      the `Py_buffer` on every error path.
      
      * Rules_match: zero-initialize data
      
      PyArg_ParseTupleAndKeywords does not initialize optional fields unless
      they are passed, which means we need to zero-initialize the data buffer
      to be sure the later NULL checks always work.
      
      This commit also gets rid of the unneeded has_data flag.
      
      * Add test for matching on a memoryview
      Jan Teske authored
  23. 26 Jun, 2020 1 commit