I reviewed libgssglue 0.9-1 as checked into testing.  This shouldn't be
considered a full audit but rather a quick gauge of maintainability.

According to upstream libgssglue is a library that "provides a GSS-API library,
but does not implement any mechanisms itself; instead it calls routines in
other libraries, depending on the mechanism and system configuration."

- CVE History
  - CVE-2011-2709
  This was code execution through an environment variable.
  The patch is simple to review and makes sense, it seems to be the simplest way
  to fix the issue that caused the CVE.
- Build-Depends
  - none
- pre/post inst/rm scripts
  - none
- init scripts
  - none
- systemd units
  - none
- dbus services
  - none
- setuid binaries
  - none
- binaries in PATH
  - none
- sudo fragments
  - none
- polkit files
  - none
- udev rules
  - none
- unit tests / autopkgtests
  Needed to install 'iproute2' in schroot for tests to pass, this can be assumed
  to be always present in the testing environment but being explicit about the 
  dependency would be better.
- filesystem 
  A file is added to /etc/gssapi_mech.conf, which is the default configuration.
  Also a number of hidden files are added to /usr/lib/debug that need to be
  reviewed to ensure both their presence is required and they need to be hidden.
- cron jobs
  - none
- Build logs
  - none
- VCS
  Most of the open issues seem to be related to the developer tracking pending 
  work.
  There are also two open MRs which seem to be stale.
  The more recent work was done in response to some comments related to our 
  review.
- Debian bugs
  Currently only a single bug is present in the Debian tracker, a fix has been 
  proposed and applied by the maintainer.

  References:
  - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061499
  - https://tracker.debian.org/pkg/libgssglue

- Processes spawned
  - none
- Memory management
  There is an allocation that is not checked and should be:
  - g_dsp_name - malloc:79
- File IO
  The library is configured through a config file whose path is provided by an
  environment variable.
  The format is assumed to be correct, but the code fails gracefully if there
  are any issues parsing this (expected) format.

  Shared objects are loaded to allow calling multiple external mechanisms (hence 
  the "glue" in the package's name). However, the package does not close them 
  correctly.
  If the configured symbol is correctly loaded, the handle for the shared object
  is lost.
- Logging
  - none
- Environment variable usage
  Only used to set the config file, the previous CVE was related to this use of 
  environment variables and their use is now correct.
- Use of privileged functions
  - none
- Use of cryptography / random number sources etc
  - none
- Use of temp files
  - none
- Use of networking
  - none
- Use of WebKit
  - none
- Use of PolicyKit
  - none

- Any significant cppcheck results
  - none
- Any significant Coverity results
  Upstream was contacted with our analysis of the results and they fixed a
  number of issues reported.
  dlhandles are lost and thus leaked. This has been discussed with upstream
  and we agree that this is not a blocker.
- Any significant Shellcheck results
  Not significant.
  There are multiple TPs in the scan, but they are all relative to the scripts 
  present in the debian/tests folder.
- Any significant bandit results
  - none
- Any significant govulncheck results
  - none
- Any significant Semgrep results
  - none

Upstream was easy to reach and quick to fix our comments. 

Security team ACK for promoting libgssglue to main.