> ## Documentation Index
> Fetch the complete documentation index at: https://docs.scanoss.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Download cryptography detection ruleset as a tarball.

> Downloads a compressed tarball containing cryptographic detection rules for various
programming languages. Rulesets can be used with tools like SCANOSS Crypto Finder for
cryptographic algorithm detection in source code.

Supported ruleset types:
- dca: Deep Code Analysis rules (for SCANOSS Crypto Finder)
- keywords: Keyword-based detection rules

Version can be:
- "latest": Most recent version
- Specific version: e.g., "v1.2.3"

Response headers (via grpc-gateway):
- Content-Type: application/gzip
- Content-Disposition: attachment; filename="scanoss-crypto-{ruleset_name}-{version}.tar.gz"
- SCANOSS-Ruleset-Name: Name of the ruleset
- SCANOSS-Ruleset-Version: Resolved version number
- X-Checksum-SHA256: SHA256 checksum of the tarball

See: https://github.com/scanoss/papi/blob/main/protobuf/scanoss/api/cryptography/v2/README.md#downloadruleset



## OpenAPI

````yaml /api-reference/cryptography-openapi.json get /v2/cryptography/rulesets/{ruleset_name}/{version}/download
openapi: 3.0.0
info:
  title: SCANOSS Cryptography Service
  description: >-
    Cryptography service provides cryptographic intelligence for software
    components including algorithm detection and encryption analysis.
  version: '2.0'
  contact:
    name: scanoss-cryptography
    url: https://github.com/scanoss/cryptography
    email: support@scanoss.com
servers:
  - url: http://api.scanoss.com
  - url: https://api.scanoss.com
security: []
tags:
  - name: Cryptography
paths:
  /v2/cryptography/rulesets/{ruleset_name}/{version}/download:
    get:
      tags:
        - Cryptography
      summary: Download cryptography detection ruleset as a tarball.
      description: >-
        Downloads a compressed tarball containing cryptographic detection rules
        for various

        programming languages. Rulesets can be used with tools like SCANOSS
        Crypto Finder for

        cryptographic algorithm detection in source code.


        Supported ruleset types:

        - dca: Deep Code Analysis rules (for SCANOSS Crypto Finder)

        - keywords: Keyword-based detection rules


        Version can be:

        - "latest": Most recent version

        - Specific version: e.g., "v1.2.3"


        Response headers (via grpc-gateway):

        - Content-Type: application/gzip

        - Content-Disposition: attachment;
        filename="scanoss-crypto-{ruleset_name}-{version}.tar.gz"

        - SCANOSS-Ruleset-Name: Name of the ruleset

        - SCANOSS-Ruleset-Version: Resolved version number

        - X-Checksum-SHA256: SHA256 checksum of the tarball


        See:
        https://github.com/scanoss/papi/blob/main/protobuf/scanoss/api/cryptography/v2/README.md#downloadruleset
      operationId: Cryptography_DownloadRuleset
      parameters:
        - name: ruleset_name
          description: >-
            Name of ruleset to download (e.g., "dca", "keywords")

            - "dca": Deep Code Analysis rules for using with SCANOSS Crypto
            Finder

            - "keywords": Keyword-based detection rules
          in: path
          required: true
          schema:
            type: string
        - name: version
          description: >-
            Version of the ruleset to download

            Use "latest" for the most recent version, or specify a version like
            "v1.2.3"
          in: path
          required: true
          schema:
            type: string
      responses:
        '200':
          description: A successful response.
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/apiHttpBody'
        '404':
          description: Returned when the resource does not exist.
          content:
            application/json:
              schema:
                type: string
                format: string
        default:
          description: An unexpected error response.
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/rpcStatus'
components:
  schemas:
    apiHttpBody:
      type: object
      properties:
        content_type:
          type: string
          description: >-
            The HTTP Content-Type header value specifying the content type of
            the body.
        data:
          type: string
          format: byte
          description: The HTTP request/response body as raw binary.
        extensions:
          type: array
          items:
            $ref: '#/components/schemas/protobufAny'
          description: >-
            Application specific response metadata. Must be set in the first
            response

            for streaming APIs.
      description: >-
        Message that represents an arbitrary HTTP body. It should only be used
        for

        payload formats that can't be represented as JSON, such as raw binary or

        an HTML page.



        This message can be used both in streaming and non-streaming API methods
        in

        the request as well as the response.


        It can be used as a top-level request field, which is convenient if one

        wants to extract parameters from either the URL or HTTP template into
        the

        request fields and also want access to the raw HTTP body.


        Example:

            message GetResourceRequest {
              // A unique request id.
              string request_id = 1;

              // The raw HTTP body is bound to this field.
              google.api.HttpBody http_body = 2;

            }

            service ResourceService {
              rpc GetResource(GetResourceRequest)
                returns (google.api.HttpBody);
              rpc UpdateResource(google.api.HttpBody)
                returns (google.protobuf.Empty);

            }

        Example with streaming methods:

            service CaldavService {
              rpc GetCalendar(stream google.api.HttpBody)
                returns (stream google.api.HttpBody);
              rpc UpdateCalendar(stream google.api.HttpBody)
                returns (stream google.api.HttpBody);

            }

        Use of this type only changes how the request and response bodies are

        handled, all other features will continue to work unchanged.
    rpcStatus:
      type: object
      properties:
        code:
          type: integer
          format: int32
        message:
          type: string
        details:
          type: array
          items:
            $ref: '#/components/schemas/protobufAny'
    protobufAny:
      type: object
      properties:
        '@type':
          type: string
          description: >-
            A URL/resource name that uniquely identifies the type of the
            serialized

            protocol buffer message. This string must contain at least

            one "/" character. The last segment of the URL's path must represent

            the fully qualified name of the type (as in

            `path/google.protobuf.Duration`). The name should be in a canonical
            form

            (e.g., leading "." is not accepted).


            In practice, teams usually precompile into the binary all types that
            they

            expect it to use in the context of Any. However, for URLs which use
            the

            scheme `http`, `https`, or no scheme, one can optionally set up a
            type

            server that maps type URLs to message definitions as follows:


            * If no scheme is provided, `https` is assumed.

            * An HTTP GET on the URL must yield a [google.protobuf.Type][]
              value in binary format, or produce an error.
            * Applications are allowed to cache lookup results based on the
              URL, or have them precompiled into a binary to avoid any
              lookup. Therefore, binary compatibility needs to be preserved
              on changes to types. (Use versioned type names to manage
              breaking changes.)

            Note: this functionality is not currently available in the official

            protobuf release, and it is not used for type URLs beginning with

            type.googleapis.com. As of May 2023, there are no widely used type
            server

            implementations and no plans to implement one.


            Schemes other than `http`, `https` (or the empty scheme) might be

            used with implementation specific semantics.
      additionalProperties: {}
      description: >-
        `Any` contains an arbitrary serialized protocol buffer message along
        with a

        URL that describes the type of the serialized message.


        Protobuf library provides support to pack/unpack Any values in the form

        of utility functions or additional generated methods of the Any type.


        Example 1: Pack and unpack a message in C++.

            Foo foo = ...;
            Any any;
            any.PackFrom(foo);
            ...
            if (any.UnpackTo(&foo)) {
              ...
            }

        Example 2: Pack and unpack a message in Java.

            Foo foo = ...;
            Any any = Any.pack(foo);
            ...
            if (any.is(Foo.class)) {
              foo = any.unpack(Foo.class);
            }
            // or ...
            if (any.isSameTypeAs(Foo.getDefaultInstance())) {
              foo = any.unpack(Foo.getDefaultInstance());
            }

         Example 3: Pack and unpack a message in Python.

            foo = Foo(...)
            any = Any()
            any.Pack(foo)
            ...
            if any.Is(Foo.DESCRIPTOR):
              any.Unpack(foo)
              ...

         Example 4: Pack and unpack a message in Go

             foo := &pb.Foo{...}
             any, err := anypb.New(foo)
             if err != nil {
               ...
             }
             ...
             foo := &pb.Foo{}
             if err := any.UnmarshalTo(foo); err != nil {
               ...
             }

        The pack methods provided by protobuf library will by default use

        'type.googleapis.com/full.type.name' as the type URL and the unpack

        methods only use the fully qualified type name after the last '/'

        in the type URL, for example "foo.bar.com/x/y.z" will yield type

        name "y.z".


        JSON

        ====

        The JSON representation of an `Any` value uses the regular

        representation of the deserialized, embedded message, with an

        additional field `@type` which contains the type URL. Example:

            package google.profile;
            message Person {
              string first_name = 1;
              string last_name = 2;
            }

            {
              "@type": "type.googleapis.com/google.profile.Person",
              "firstName": <string>,
              "lastName": <string>
            }

        If the embedded message type is well-known and has a custom JSON

        representation, that representation will be embedded adding a field

        `value` which holds the custom JSON in addition to the `@type`

        field. Example (for message [google.protobuf.Duration][]):

            {
              "@type": "type.googleapis.com/google.protobuf.Duration",
              "value": "1.212s"
            }

````