Comment 7 for bug 1953173

I reviewed python-asgiref 3.5.0-1 as checked into jammy. This shouldn't be
considered a full audit but rather a quick gauge of maintainability.

python-asgiref is part of the django framework. It is an interface between
async-capable Python web servers, frameworks, and applications. The package
has ASGI (Asynchronous Server Gateway Interface) base libraries that can be
extended.

- CVE History:
  - None
- Build-Depends?
  - debhelper-compat (= 13)
    dh-python
    python3-async-timeout
    python3-all
    python3-pytest
    python3-pytest-asyncio
    python3-setuptools
    python3-six
- pre/post inst/rm scripts?
  - dh_python3 added
- 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?
    Unit tests are executed in build time in python3.9 and python3.10,
    using pytest, which seems good and it is easible executable.
    It has a good integration with the code as the most part of the code
    has its own test routines.
    The same test routine is executed for autopkgtests.

    Every test is passing, including one that is expected to fail at the moment:
      tests/test_sync.py::test_sync_to_async_with_blocker_thread_sensitive

    Things to note:
      In both test versions (3.9 and 3.10) there is a warning:
        PytestConfigWarning: Unknown config option: asyncio_mode
      In test version 3.10 there is a DeprecationWarning:
         DeprecationWarning: There is no current event loop
    event_loop = asyncio.get_event_loop()
- cron jobs?
  - None
- Build logs:
  - No Errors, one warning on setup.py deprecation:
      /usr/lib/python3/dist-packages/setuptools/command/install.py:34:
          SetuptoolsDeprecationWarning: setup.py install is deprecated.
          Use build and pip and other standards-based tools.
  - Lintian is passing.
- Processes spawned?
  - None
- Memory management?
  - None
- File IO?
  - None
- Logging?
  - Everything looks OK.
- Environment variable usage?
  - Yes. ASGI interface with WSGI (wsgi.py) has the WSGI environment variables
    defined. Some are encoded to utf-8 and decoded to latin1, that could bring
    concerns over exploitations because they are not sanitized.
    Also, sync.py is using one enviroment variable from the OS that is not
    sanitized before being converted to integer.
    handled with upstream: https://github.com/django/asgiref/issues/317
- Use of privileged functions?
  - None
- Use of cryptography / random number sources etc?
  - None
- Use of temp files?
  - None
- Use of networking?
  - Yes. There is no defensive code to filter/sanitize untrusted inputs.
- Use of WebKit?
  - None
- Use of PolicyKit?
  - None
- Any significant cppcheck results?
  - None
- Any significant Coverity results?
  - Just one report that is not significant.
- Any significant shellcheck results?
  - None
- Any significant bandit results?
  - None

From a security perspective, the package itself is simple, some security
guards could be extended, like validation of environment variables, but
as already discussed with upstream and here, we should take into account
that it would be deployed around other guards, django for example.
And, as it is closely related with django, that is already part of main
pocket, and so far it is reliable, the reliability of this package
is increased.
Bonus: The interaction with upstream was satisfatory.

Security team ACK for promoting python-asgiref to main.