1. 12 Feb, 2016 1 commit
  2. 11 Feb, 2016 1 commit
  3. 03 Nov, 2015 1 commit
    • Ralf Habacker's avatar
      Test system bus config files on Unix only · 34d0c73f
      Ralf Habacker authored
      Previously, we didn't consistently test parsing of every file in
      valid-config-files-system/ everywhere that we tested valid-config-files/.
      We now test it on Unix.
      
      The system bus is not supported on Windows, so we do not test
      valid-config-files-system/ there.
      
      valid-config-files/many-rules.conf contains <user> and <group> rules
      which are not applicable to Windows. Copy the original many-rules.conf
      to valid-config-files-system/ so that it will be tested on Unix, and
      remove the non-portable rules from valid-config-files/many-rules.conf.
      
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92721Reviewed-by: default avatarSimon McVittie <simon.mcvittie@collabora.co.uk>
      [rh:base patch came from Simon]
      34d0c73f
  4. 22 Oct, 2015 1 commit
  5. 25 Aug, 2015 1 commit
  6. 17 Jun, 2015 1 commit
  7. 27 May, 2015 1 commit
  8. 16 Apr, 2015 6 commits
  9. 15 Apr, 2015 1 commit
  10. 24 Feb, 2015 1 commit
  11. 23 Feb, 2015 1 commit
  12. 20 Feb, 2015 3 commits
  13. 16 Feb, 2015 1 commit
  14. 05 Feb, 2015 3 commits
  15. 04 Feb, 2015 2 commits
    • Simon McVittie's avatar
    • Simon McVittie's avatar
      Add a regression test for being a new-style monitor · a650bd05
      Simon McVittie authored
      This includes most of the situations I could think of:
      
      * method call on dbus-daemon and response
      * NameOwnerChanged
      * NameAcquired, NameLost (although I'm not 100% sure these should
        get captured, since they're redundant with NameOwnerChanged)
      * unicast message is allowed through
      * unicast message is rejected by no-sending or no-receiving policy
      * broadcast is allowed through
      * broadcast is rejected by no-sending policy (the error reply
        is also captured)
      * broadcast is rejected by no-receiving policy (there is no error
        reply)
      * message causing service activation, and the message telling systemd
        to do the actual activation
      * systemd reporting that activation failed
      
      It does not cover:
      
      * sending a message to dbus-daemon, then provoking a reply, then
        dbus-daemon does not allow itself to send the reply due to its
        own security policy
      
      This is such an obscure corner case that I'm not even convinced it's
      testable without dropping down into lower-level socket manipulation:
      dbus-daemon's replies are always assumed to be requested replies,
      and replies contain so little other metadata that I think we can
      only forbid them by forbidding all method replies. If we do that,
      the reply to Hello() won't arrive and the client-side connection will
      not become active.
      
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=46787Reviewed-by: Philip Withnall's avatarPhilip Withnall <philip.withnall@collabora.co.uk>
      a650bd05
  16. 03 Feb, 2015 5 commits
  17. 30 Jan, 2015 1 commit
  18. 29 Oct, 2014 1 commit
  19. 15 Sep, 2014 1 commit
  20. 08 Sep, 2014 1 commit
  21. 17 Jan, 2014 6 commits