1. 23 Jun, 2021 2 commits
  2. 21 Jun, 2021 9 commits
  3. 16 Jun, 2021 16 commits
  4. 15 Jun, 2021 12 commits
    • Michael Catanzaro's avatar
    • Michael Catanzaro's avatar
      gtlscertificate: make private key properties readable · c50e543e
      Michael Catanzaro authored
      WebKit wants these private key properties to be readable in order to
      implement a deserialization function. Currently they are read-only
      because at the time GTlsCertificate was originally designed, the plan
      was to support PKCS#11-backed private keys: private keys that are stored
      on a smartcard, where the private key is completely unreadable. The
      design goal was to support both memory-backed and smartcard-backed
      private keys with the same GTlsCertificate API, abstracting away the
      implementation differences such that code using GTlsCertificate doesn't
      need to know the difference.
      The original PKCS#11 implementation was never fully baked and at some
      point in the past I deleted it all. It has since been replaced with a
      new implementation, including a GTlsCertificate:private-key-pkcs11-uri
      property, which is readable. So our current API already exposes the
      differences between normal private keys and PKCS#11-backed private keys.
      The point of making the private-key and private-key-pem properties
      write-only was to avoid exposing this difference.
      Do we have to make this API function readable? No, because WebKit could
      be just as well served if we were to expose serialize and deserialize
      functions instead. But WebKit needs to support serializing and
      deserializing the non-private portion of GTlsCertificate with older
      versions of GLib anyway, so we can do whatever is nicest for GLib. And I
      think making this property readable is nicest, since the original design
      reason for it to not be readable is now obsolete. The disadvantage to
      this approach is that it's now possible for an application to read the
      private-key or private-key-pem property, receive NULL, and think "this
      certificate must not have a private key," which would be incorrect if
      the private-key-pkcs11-uri property is set. That seems like a minor
      risk, but it should be documented.
    • André Apitzsch's avatar
    • Philip Withnall's avatar
      Merge branch 'wip/wait-status' into 'main' · 00feb4d5
      Philip Withnall authored
      Distinguish more clearly between wait status and exit status
      See merge request !1967
    • Ondrej Holy's avatar
      Merge branch 'unix-mount-for-docs' into 'main' · 757cc935
      Ondrej Holy authored
      gunixmounts: Document NULL return value for g_unix_mount_for()
      See merge request !2145
    • Simon McVittie's avatar
      spawn: Clarify the most common non-exit reason for process termination · b483013d
      Simon McVittie authored
      A reader might think "how would a process terminate without an exit
      status?", or equivalently, "what harm would it do if I assume every
      termination has an exit status?" without this reminder that termination
      with a signal is also reasonably common.
      Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
    • Simon McVittie's avatar
      Distinguish more clearly between wait status and exit status · e0b6b803
      Simon McVittie authored
      On Unix platforms, wait() and friends yield an integer that encodes
      how the process exited. Confusingly, this is usually not the same as
      the integer passed to exit() or returned from main(): conceptually it's
      an integer encoding of this tagged union:
          enum { EXITED, SIGNALLED, ... } tag;
          union {
              int exit_status;         /* if EXITED */
              struct {
                  int terminating_signal;
                  bool core_dumped;
              } terminating_signal;    /* if SIGNALLED */
          } detail;
      Meanwhile, on Windows, wait statuses and exit statuses are
      I find that it's clearer what is going on if we are consistent about
      referring to the result of wait() as a "wait status", and the value
      passed to exit() as an "exit status".
      GSubprocess already gets this right: g_subprocess_get_status() returns
      the wait status, while g_subprocess_get_exit_status() genuinely returns
      the exit status. However, the GSpawn family of ...
    • Simon McVittie's avatar
      subprocess test: Check wait status correctly · f2be22ca
      Simon McVittie authored
      Confusingly, g_spawn_check_exit_status() takes a wait status, not an
      exit status, so passing g_subprocess_get_exit_status() to it is
      incorrect (although both encodings happen to use 0 to encode success
      and a nonzero value to encode failure, so in practice this probably
      had the desired effect).
      Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
    • Philip Withnall's avatar
      Merge branch 'wip/pwithnall/local-file-monitor-deadlock' into 'main' · 031e5020
      Philip Withnall authored
      glocalfilemonitor: Avoid a deadlock on finalization
      See merge request !2155
    • Philip Withnall's avatar
      Merge branch 'range-checked' into 'main' · 7b6ccc8b
      Philip Withnall authored
      GBytes: add range-checked pointer getter
      Closes #1098
      See merge request !2147
    • Nitin Wartkar's avatar
      GBytes: add range-checked pointer getter · e3452ea0
      Nitin Wartkar authored
      Updated and improved by Nitin Wartkar.
      Fixes: #1098
    • Philip Withnall's avatar
      Merge branch 'g_obj_take_ref' into 'main' · b95d9d1d
      Philip Withnall authored
      GObject: add g_object_take_ref()
      Closes #1112
      See merge request !2146
  5. 14 Jun, 2021 1 commit