1. 23 Apr, 2021 1 commit
  2. 19 Apr, 2021 1 commit
  3. 17 Apr, 2021 1 commit
  4. 15 Apr, 2021 1 commit
    • Stefan Weil's avatar
      Avoid build error caused by conflicting types for INT32 · 691bd67f
      Stefan Weil authored and Frediano Ziglio's avatar Frediano Ziglio committed
      Compiler error for cross builds using mingw-w64:
      
      In file included from /usr/share/mingw-w64/include/winnt.h:150,
                       from /usr/share/mingw-w64/include/minwindef.h:163,
                       from /usr/share/mingw-w64/include/windef.h:9,
                       from /usr/share/mingw-w64/include/windows.h:69,
                       from /usr/share/mingw-w64/include/winsock2.h:23,
                       from ../../../server/spice-core.h:29,
                       from ../../../server/spice.h:24,
                       from ../../../server/spice-wrapped.h:35,
                       from ../../../server/red-common.h:35,
                       from ../../../server/jpeg-encoder.c:22:
      /usr/share/mingw-w64/include/basetsd.h:31:22: error: conflicting types for ‘INT32’
         typedef signed int INT32,*PINT32;
                            ^~~~~
      In file included from /usr/x86_64-w64-mingw32/sys-root/mingw/include/jpeglib.h:31,
                       from ../../../server/jpeg-encoder.c:20:
      /usr/x86_64-w64-mingw...
      691bd67f
  5. 07 Dec, 2020 1 commit
  6. 11 May, 2020 1 commit
    • Gilmar Santos Jr's avatar
      red-stream: WebDAV doesn't work when SASL is active · 15b1e2a3
      Gilmar Santos Jr authored and Frediano Ziglio's avatar Frediano Ziglio committed
      When SASL is active, if a read request is made and SASL buffer contains some
      data (but not enough to fulfill the request), upon return the taken data from
      the buffer is not accounted for and hence part of the message gets discarded.
      
      red_stream_sasl_read function takes available data from sasl buffer and returns
      if it's enough. If it's not, nbyte is decremented and buf pointer is
      incremented to account for the taken data (if any). Then it tries to get more
      data from the socket and decode it.
      
      Suppose there was some data in the sasl buffer, but not enough. Then the socket
      is not readable (EAGAIN, EINTR, whatever) or the new data isn't enough for
      sasl_decode (hence decodedlen == 0). In both cases the function returns as if
      no data was read, but it took some data from sasl buffer. This data is lost and
      from this point on the communication ceases on the channel (eventually new data
      is read, but messages are corrupt without the parts previously discarded).
      
      On the other hand, if some data is read from sasl buffer and everything else
      works fine, the output buffer contains all the data, but the count returned
      only inform the caller about the newly read data (which causes the similar
      effect of discarding part of the message).
      
      Fixes: #40
      
      
      
      Acked-by: Frediano Ziglio's avatarFrediano Ziglio <fziglio@redhat.com>
      15b1e2a3
  7. 29 Apr, 2020 1 commit
  8. 17 Mar, 2020 1 commit
  9. 06 Nov, 2019 1 commit
  10. 03 Jul, 2019 1 commit
  11. 12 Jun, 2019 1 commit
  12. 31 May, 2019 2 commits
  13. 30 Apr, 2019 1 commit
  14. 22 Mar, 2019 1 commit
  15. 18 Mar, 2019 1 commit
  16. 19 Sep, 2018 1 commit
  17. 06 Apr, 2018 1 commit
  18. 06 Mar, 2017 1 commit
  19. 01 Nov, 2016 1 commit
  20. 08 Jan, 2016 1 commit
  21. 19 Oct, 2015 1 commit
  22. 16 Jul, 2013 1 commit
  23. 25 Apr, 2012 1 commit
  24. 13 Jan, 2012 1 commit
  25. 14 Oct, 2009 1 commit