Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

Make it impossible to accidentally define a nonfunctional secret extension

Aberta
  • Algo errado?
#1,729 1 comentário 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 2 dias

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
38/100
Tipo de issue
Funcionalidade
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
rust
Domínio
backend, cli

Direção de pesquisa

Start by inspecting the JSON Schema rules for extension manifests and the process_secret_args function. Compare enforcing one name argument with appending the secret name at runtime, including the optional vault argument. Done means non-functional secret definitions are prevented or clearly handled, with the limitation surfaced through dsc extension list or trace messages.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

Issue-Enhancement
Summary of the new feature / enhancement

As an extension developer,
I want a clear contract for defining a secret extension that prevents defining a non-functional extension,
so that I can correctly define my extension without reading the implementation code in the DSC engine library.

In the current implementation:

  1. The secret.args field for an extension manifest is optional.
  2. The secret.args field doesn't require exactly one instance of the name argument (like {"nameArg": "--secret-name"}). This makes it possible to define an extension that can't lookup specific secrets. Presumably, it will always return the same secret regardless of name, which seems counter to the spirit of the secret(<name>[, <vault>]) function.
  3. The secret.args field doesn't limit the inclusion of name and vault arguments to a single instance.
  4. The process_secret_args function doesn't have any way to pass the secret name to an extension except with the name argument - no handling for if name wasn't processed in args.
  5. The implementation doesn't signal to the user that no name can be provided. There's no surfacing of this information either in the representation for dsc extension list or through trace messages.
Proposed technical implementation details (optional)

There are two different paths we can take:

  1. Update the JSON Schema to explicitly require args and to require a single name argument and optionally allow a single vault argument.
  2. Update the implementation to append the secret name as the final argument to the executable when args isn't defined or is defined without a name argument.

The current implementation allows for non-functional extension manifest definitions. While it could be considered a breaking change to make the schema modifications, since they only exclude non-functional definitions this may be acceptable.

Linguagem predominante
Rust
Estrelas
526
Forks
76
Merge médio
4d 20h
PRs com merge (30d)
24

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de PowerShell/DSC

Todas as issues de PowerShell/DSC

Issues semelhantes

Mais issues de Rust

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.