1. 30 Jan, 2023 1 commit
  2. 25 Jan, 2023 2 commits
  3. 21 Jan, 2023 1 commit
  4. 20 Jan, 2023 2 commits
  5. 19 Jan, 2023 2 commits
    • Ray Strode's avatar
      goakerberosidentity: Fall back to stale credentials if active credentials get destroyed · e869642b
      Ray Strode authored
      At the moment, the identity service doesn't recognize when a credentials
      cache gets kdestroy'd explicitly by the user. It knows when a principal
      is purged from all credential caches, but it doesn't know when a
      specific cache is removed.
      
      This means it doesn't fall back properly to an older credential crash if
      the active cache gets destroyed.
      
      This commit addresses that problem by reachitecting things a bit.
      
      Previously, cache updates were processed by creating a new transient
      GoaKerberosIdentity and then merging it into an existing identity using
      goa_kerberos_identity_update. Using a full blown GoaKerberosIdentity
      object as a wrapper around a lone credentials cache is kind of a weird
      pattern and doesn't facillate processing cache removal, since we can't
      create a transient identity for what's not there.
      
      This commit exports goa_kerberos_identity_add_credentials_cache as
      public api as an alternative to the merging transi...
      e869642b
    • Ray Strode's avatar
      goakerberosidentity: Fix automatic reinitialization · 9091df07
      Ray Strode authored
      The identity service has the ability to automatically fetch a new ticket
      granting ticket from the KDC when the existing one expires, provided the
      user keeps their kerberos password in GNOME keyring.
      
      Unfortunately, commit aca400799c225a84e5d0fc90efb206c8f1d48bc3
      inadvertently broke this feature in some cases.
      
      When deciding whether or not to make a new credentials cache for a
      principal the active one it looks at various characteristics of the
      competing credentials to decide which cache is better.
      
      For instance, if one credentials cache has a ticket that's valid and
      signed in, but the other credentials cache only has an expired ticket,
      then obviously the one that's valid and signed in gets picked to be
      active.
      
      Likewise, if one is expiring in 10 minutes and one is expiring in
      24 hours, the one that expires in 24 hours will be treated as better.
      
      This comparison, only makes sense, though when looking at two different
      credentials caches.  If we're updating a preexisting credentials cache,
      then we're actually just comparing up to date data with out of date
      data.  In that case, we need to proceed even if new newer view of the
      credentials look worse than the older view of those credentials.
      Unfortunately, the buggy commit neglected to account for that.
      
      This commit fixes that problem and related problems, by more
      thoroughly and systematically checking all the permutations of
      credentials in the old credentials cache for the identity, the
      new credentials cache for the identity, and the default credentials
      cache. It also adds a lot more logging for clarity.
      9091df07
  6. 11 Jan, 2023 1 commit
  7. 27 Dec, 2022 1 commit
  8. 24 Dec, 2022 1 commit
  9. 18 Dec, 2022 1 commit
  10. 17 Dec, 2022 2 commits
    • Ray Strode's avatar
      goakerberosidentity: Explicitly switch to credentials cache when needed · 35622795
      Ray Strode authored
      If we're updating a credentials cache and decide
      it should be the new default for an identity, and
      the old credentials cache was the default cache
      for the cache collection then we should make the
      new credential cache the default cache for the
      collection, too.
      
      This commit adds that. It also makes the new
      credentials cache the default if there wasn't a
      valid default set already. This brings consistency
      to differences in behavior from different kerberos
      ccache types.
      35622795
    • Ray Strode's avatar
      goakerberosidentity: Fix crash when erasing credentials · 0907502a
      Ray Strode authored
      Right now when erasing an identity we erase the
      active credentials first and then the inactive
      ones.
      
      We neglect to take the active one out of the hash
      table, though, so it gets destroyed twice.
      
      This commit fixes that.
      0907502a
  11. 15 Dec, 2022 3 commits
    • Michael Catanzaro's avatar
      Merge branch 'fix-fresh-initialization' into 'master' · d3f3e2ce
      Michael Catanzaro authored
      kerberos-identity: Unbreak handling of fresh caches
      
      See merge request !115
      d3f3e2ce
    • Ray Strode's avatar
      kerberos-identity: Fix buglet in update_identity · 8c5b6306
      Ray Strode authored
      The update_identity function is supposed to transfer the identity
      form one object to another.
      
      In practice, this is currently always a noop because only objects
      with the same identities get copied to each other.
      
      Nevertheless, there is a bug in the function. It grabs the identity
      from the target object instead of from the source object.
      
      This commit fixes that.
      8c5b6306
    • Ray Strode's avatar
      kerberos-identity: Unbreak handling of fresh caches · 10df58d8
      Ray Strode authored
      commit 4acfcc32 attempted to
      avoid an error variable getting stomped all over by returning
      FALSE when encountering the error.
      
      Unfortunately, it's actual legitimate for an error to happen
      in that path and we should proceed anyway.
      
      That can happen when a credential cache is new and not yet
      initialized, so it won't have a principal associated with it
      yet.
      
      This commit changes the problematic code to just pass NULL
      for the error variable, since we don't need it.
      10df58d8
  12. 30 Nov, 2022 3 commits
  13. 29 Nov, 2022 2 commits
  14. 28 Nov, 2022 3 commits
    • Ray Strode's avatar
      kerberos-identity: Clear alarms on temporary identity · 3e80e12c
      Ray Strode authored
      When the identity service does a refresh, it creates a new temporary
      identity object to check the credentials, then it merges that
      temporary identity into the preexisting identity object (so the
      pointers don't change).
      
      This has the unfortunate side-effect of arming expiration alarms in
      the temporary object, that can then fire immediately before the object
      is thrown out.
      
      This commit disarms those alarms so they don't fire needlessly.
      3e80e12c
    • Ray Strode's avatar
      kerberos-identity: Attempt to cope with multiple credential caches per identity · c492cbfd
      Ray Strode authored
      At the moment the identity service assumes there will just be one
      credential cache collection for any given prinicipal.
      
      This isn't necessarily true though, and the service gets quite
      confused when that assumption doesn't hold up.
      
      This commit attempts to make it cope with the situation better, by
      maintaining a hash table of collections per identity.  It deems
      one of the collections the "active" one and relegates the rest to
      be backup if the active one expires and can't be renewed.
      
      Closes: #79
      c492cbfd
    • Aleksandr Melman's avatar
      Update Russian translation · 61efab77
      Aleksandr Melman authored and Administrator's avatar Administrator committed
      61efab77
  15. 16 Nov, 2022 1 commit
  16. 15 Nov, 2022 2 commits
  17. 06 Nov, 2022 1 commit
  18. 05 Nov, 2022 1 commit
  19. 03 Nov, 2022 1 commit
    • Milan Crha's avatar
      owncloud: Update CalDAV/CardDAV endpoints · 1e50849f
      Milan Crha authored
      The new endpoints are "/dav/" for both. Adapt to it, as the "/caldav/" and
      "/carddav/" endpoints do not offer the same features and they might be
      possibly dropped in the future.
      
      Closes #67
      1e50849f
  20. 31 Oct, 2022 2 commits
    • Ray Strode's avatar
      kerberos-identity: Ensure idles queued to main thread are property synchronized · 709e1db8
      Ray Strode authored
      Kerberos identities are refreshed on a helper thread, and the state of
      those identities are exported over the user bus on the main thread.
      
      Since the main consumer of an identity's properties is the bus service
      running on the main thread, to simplify things, property notifications
      are dispatched from the main thread as well (even though the underlying
      state is changed on a worker thread).
      
      The mechanism to dispatch property notifies to the main thread is an
      idle handler. The logic for doing the dispatch has a concurrency
      bug however. In order to coaelsce multiple notifies that happen in
      quick succession, the dispatch code checks for a preexisting idle id
      associated with the given property. That idle id is set from the worker
      thread when the idle is queued, and it's cleared from the main thread
      when the idle is dispatched. The bug is that the main thread could in
      theory clear the idle id immediately after the worker thread decided
      there was already a notify queued, leading to a notify getting
      completely dropped.
      
      This commit addresses the bug by adding appropriate locking.
      
      Closes #160
      709e1db8
    • Michael Catanzaro's avatar
  21. 27 Oct, 2022 2 commits
    • Michael Catanzaro's avatar
      Merge branch 'fix-dropped-notify' into 'master' · 07acae07
      Michael Catanzaro authored
      kerberos-identity: Ensure idles queued to main thread are property synchronized
      
      Closes #160
      
      See merge request !108
      07acae07
    • Ray Strode's avatar
      kerberos-identity: Ensure idles queued to main thread are property synchronized · e30df2e4
      Ray Strode authored
      Kerberos identities are refreshed on a helper thread, and the state of
      those identities are exported over the user bus on the main thread.
      
      Since the main consumer of an identity's properties is the bus service
      running on the main thread, to simplify things, property notifications
      are dispatched from the main thread as well (even though the underlying
      state is changed on a worker thread).
      
      The mechanism to dispatch property notifies to the main thread is an
      idle handler. The logic for doing the dispatch has a concurrency
      bug however. In order to coaelsce multiple notifies that happen in
      quick succession, the dispatch code checks for a preexisting idle id
      associated with the given property. That idle id is set from the worker
      thread when the idle is queued, and it's cleared from the main thread
      when the idle is dispatched. The bug is that the main thread could in
      theory clear the idle id immediately after the worker thread decided
      there was already a notify queued, leading to a notify getting
      completely dropped.
      
      This commit addresses the bug by adding appropriate locking.
      
      Closes #160
      e30df2e4
  22. 13 Oct, 2022 5 commits