Skip to content

C
Cvat

疯人忠 / Cvat

通知 1
Star 0
Fork 0
C
Cvat

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 25 8月, 2023 1 次提交
  3. 18 8月, 2023 1 次提交
  5. 11 8月, 2023 2 次提交
  7. 09 8月, 2023 1 次提交
  9. 27 7月, 2023 1 次提交
  11. 25 7月, 2023 2 次提交
  13. 20 7月, 2023 1 次提交
  15. 05 7月, 2023 1 次提交
  17. 29 6月, 2023 2 次提交
    • R
      Implement more comprehensive SSRF mitigation (#6362) · 16d03aac
      由 Roman Donchenko 提交于 
      The current mitigation approach (resolving the IP address and checking
if it's in the private range) is insufficient for a few reasons:

* It is susceptible to DNS rebinding (an attacker-controlled DNS name
resolving to a public IP address when queried during the check, and to a
private IP address afterwards).

* It is susceptible to redirect-based attacks (a server with a public
address redirecting to a server with a private address).

* It is only applied when downloading remote files of tasks (and is not
easily reusable).

Replace it with an approach based on smokescreen, a proxy that blocks
connections to private IP addresses. In addition, use this proxy for
webhooks, since they also make requests to untrusted URLs.

The benefits of smokescreen are as follows:

* It's not susceptible to the problems listed above.

* It's configurable, so system administrators can allow certain private
IP ranges if necessary. This configurability is exposed via the
`SMOKESCREEN_OPTS` environment variable.

* It doesn't require much code to use.

The drawbacks of smokescreen are:

* It's not as clear when the request fails due to smokescreen (compared
to manual IP validation). To compensate, make the error message in
`_download_data` more verbose.

* The smokescreen project seems to be in early development (judging by
the 0.0.x version numbers). Still, Stripe itself uses it, so it should
be good enough. It's also not very convenient to set up (on account of
not providing binaries), so disable it in development environments.

Keep the scheme check from `_validate_url`. I don't think this check
prevents any attacks (as requests only supports http/https to begin
with), but it provides a friendly error message in case the user tries
to use an unsupported scheme.
      16d03aac
    • A
      Bump version to 2.4.9 · 75c1e6ff
      由 Andrey Zhavoronkov 提交于
      75c1e6ff
  19. 22 6月, 2023 1 次提交
  21. 16 6月, 2023 3 次提交
  23. 12 6月, 2023 2 次提交
  25. 09 6月, 2023 1 次提交
  27. 05 6月, 2023 1 次提交
  29. 03 6月, 2023 1 次提交
  31. 02 6月, 2023 3 次提交
  33. 30 5月, 2023 1 次提交
  35. 27 5月, 2023 1 次提交
  37. 18 5月, 2023 1 次提交
  39. 15 5月, 2023 1 次提交
    • R
      Modernize OpenVINO-based Nuclio functions and allow them to run on Kubernetes (#6129) · 98616c72
      由 Roman Donchenko 提交于 
      Currently, OpenVINO-based functions assume that a local directory will
be mounted into the container. In Kubernetes, that isn't possible, so
implement an alternate approach: create a separate base image and
inherit the function image from it.

In addition, implement some modernizations:

* Upgrade the version of OpenVINO to the latest (2022.3). Make the
necessary updates to the code. Note that 2022.1 introduced an entirely
new inference API, but I haven't switched to it yet to minimize changes.

* Use the runtime version of the Docker image as the base instead of the
dev version. This significantly reduces the size of the final image (by
~3GB).

* Replace the `faster_rcnn_inception_v2_coco` model with
`faster_rcnn_inception_resnet_v2_atrous_coco`, as the former has been
  removed from OMZ.

* Ditto with `person-reidentification-retail-0300` -> `0277`.

* The IRs used in the DEXTR function are not supported by OpenVINO
anymore (format too old), so rewrite the build process to create them
from the original code/weights instead.
      98616c72
  41. 25 4月, 2023 1 次提交
  43. 14 4月, 2023 1 次提交
  45. 06 4月, 2023 1 次提交
  47. 24 3月, 2023 1 次提交
    • R
      Fix Nuclio function invocations when deployed via the Helm chart (#5917) · 7b7b5b4e
      由 Roman Donchenko 提交于 
      The `CVAT_NUCLIO_FUNCTION_NAMESPACE` needs to be defined consistently in
order for Nuclio integration to work. Currently, it's set to `cvat` for
the main CVAT server process, but not for any other CVAT process (which
means it defaults to `nuclio` in those processes). Since it's the
annotation worker process that actually invokes the Nuclio functions,
the invocation fails.

Fix it by synchronizing the Nuclio environment variables across all
backend deployments. Technically, I think only the server and annotation
worker deployments need these variables, but since they're accessed by
`cvat/settings/base.py` in every process that loads Django, define them
everywhere to be sure.

Fixes #5626.
      7b7b5b4e
  49. 18 3月, 2023 1 次提交
  51. 16 3月, 2023 2 次提交
  53. 10 3月, 2023 1 次提交
  55. 06 3月, 2023 1 次提交
  57. 28 2月, 2023 1 次提交
  59. 23 2月, 2023 1 次提交
  61. 14 2月, 2023 1 次提交