1. 09 Aug, 2018 4 commits
  2. 08 Aug, 2018 1 commit
    • Ævar Arnfjörð Bjarmason's avatar
      Fix two regressions in SSH certificate support · c4b5a076
      Ævar Arnfjörð Bjarmason authored
      Fix two regressions in my 2e8b6702 ("Add support for SSH certificate
      authentication", 2018-06-14) merged in gitlab-org/gitlab-shell!207.
      
      This fixes the issue noted in gitlab-org/gitlab-shell#145 where the
      command-line contains things other than the key/user/username, and
      also a regression where SSH certificates are being used, and the
      username presented in the key is unknown to GitLab.
      
      In that case, we should log the user in as "Anonymous" (on an instance
      that allows public access), but because of how the error checking
      around api.discover() was implemented we ended up erroring out
      instead.
      c4b5a076
  3. 01 Aug, 2018 6 commits
  4. 31 Jul, 2018 3 commits
  5. 27 Jul, 2018 3 commits
  6. 26 Jul, 2018 1 commit
    • Ævar Arnfjörð Bjarmason's avatar
      Add support for SSH certificate authentication · 2e8b6702
      Ævar Arnfjörð Bjarmason authored
      This along with the code submitted to gitlab-ce in the
      gitlab-org/gitlab-ce! MR implements SSH certificate
      authentication. See the docs added to gitlab-ce for why and how to
      enable this. This, along with that MR, closes
      gitlab-org/gitlab-ce#3457
      
      Implementation notes:
      
       - Because it's easy to do, and because an earlier nascent version of
         this would pass user-ID to gitlab-shell, that's now supported, even
         though the SSH certificate authentication uses username-USERNAME.
      
       - The astute reader will notice that not all the API calls in
         gitlab-ce's lib/api/internal.rb support a "username" argument, some
         only support "user_id".
      
         There's a few reasons for this:
      
           a) For this to be efficient, I am bending over backwards to avoid
              extra API calls when using SSH certificates.
      
              Therefore the /allowed API call will now return a "user id" to
              us if we're allowed to proceed further. This is then fed to
              existing APIs that would only be called after a successful
              call to /allowed.
      
           b) Not all of the git-shell codepaths go through
              /internal/allowed, or ever deal with a repository, e.g. the
              argument-less "Welcome to GitLab", and
              /internal/2fa_recovery_codes. These need to use
              /internal/discover to figure out details about the user, so
              support looking that up by username.
      
           c) Once we have the "user id", the GL_ID gets passed down to
              e.g. user-authored hooks. I don't want to have those all break
              by having to handle a third GL_ID mode of "username" in
              addition to the current "key id" and "user id".
      2e8b6702
  7. 24 Jul, 2018 2 commits
  8. 23 Jul, 2018 1 commit
  9. 20 Jul, 2018 8 commits
  10. 11 Jul, 2018 1 commit
  11. 20 Jun, 2018 2 commits
  12. 13 Jun, 2018 1 commit
  13. 12 Jun, 2018 1 commit
  14. 11 Jun, 2018 2 commits
  15. 04 Jun, 2018 1 commit
  16. 01 Jun, 2018 1 commit
  17. 28 May, 2018 1 commit
  18. 24 May, 2018 1 commit