1. 06 Oct, 2021 2 commits
  2. 05 Oct, 2021 1 commit
  3. 31 Aug, 2021 4 commits
  4. 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
  5. 21 Jun, 2021 1 commit
  6. 26 Apr, 2021 1 commit
  7. 16 Apr, 2021 1 commit
  8. 18 Mar, 2021 2 commits
  9. 16 Mar, 2021 2 commits
  10. 15 Mar, 2021 1 commit
  11. 12 Mar, 2021 4 commits
  12. 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
  13. 03 Feb, 2021 2 commits
  14. 27 Jan, 2021 1 commit
  15. 18 Jan, 2021 1 commit
  16. 14 Jan, 2021 1 commit
  17. 04 Jan, 2021 4 commits
  18. 24 Dec, 2020 2 commits
  19. 19 Oct, 2020 2 commits
  20. 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
  21. 26 Jun, 2020 1 commit
  22. 12 Jun, 2020 1 commit
    • Fix issue #149. · cfd49c04
      This is regression in introduced in #140. When a string in the metadata section contains invalid UTF-8 characters the behavior Python 2 is leave the string exactly as it appears in YARA, in Python 3 however the invalid characters are removed because Python 3 strings are not handled as bytes like in Python 2, they most have a valid encoding. PR #140 was an attempt to homogenize the behavior in both versions of Python, but it introduced this other issue.
      Victor M. Alvarez authored
  23. 15 May, 2020 2 commits