import type { CreateFetchFromRegistryOptions, RetryTimeoutOptions } from '@pnpm/network.fetch';
import type { Registries, RegistryConfig } from '@pnpm/types';
export interface VerifyPacquetIdentityOptions extends CreateFetchFromRegistryOptions {
    lockfileDir: string;
    rootDir: string;
    registries: Registries;
    configByUri?: Record<string, RegistryConfig>;
    retry?: RetryTimeoutOptions;
    timeout?: number;
    networkConcurrency?: number;
}
/**
 * Decides whether pnpm may spawn the pacquet binary installed under
 * `node_modules/.pnpm-config/<packageName>` as an install engine.
 *
 * A repository declares pacquet in its `pnpm-workspace.yaml`
 * `configDependencies` and controls the lockfile integrity and the registry
 * the bytes came from — so the declaration alone cannot authorize running a
 * native binary. This verifies that the exact bytes installed on disk (the
 * `pacquet` shim and the host's `@pacquet/<platform>-<arch>` binary, which is
 * what actually executes) carry a valid npm registry signature for that
 * `name@version`, checked against npm's embedded public keys. The signature is
 * verified over the *installed* integrity, so substituted or tampered bytes
 * fail — and because the keys are embedded rather than fetched, a repository
 * pointing the registry at a server it controls cannot supply its own key pair.
 *
 * Fails closed: if a declared pacquet's signature does not verify, or it cannot
 * be verified (e.g. the registry is unreachable), this throws rather than
 * silently running pnpm's own engine — a verification failure should be loud.
 * The one exception is when pacquet simply has no binary for this platform: that
 * is unavailability, not tampering, so it returns `false` and the caller uses
 * pnpm's own install engine.
 */
export declare function verifyPacquetIdentity(packageName: 'pacquet' | '@pnpm/pacquet', opts: VerifyPacquetIdentityOptions): Promise<boolean>;