Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add PT-BR automatic translation pkg_security.pt.Rmd #823

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
86 changes: 86 additions & 0 deletions pkg_security.pt.Rmd
Original file line number Diff line number Diff line change
@@ -0,0 +1,86 @@

# Práticas recomendadas de segurança no desenvolvimento de pacotes {#package-development-security-best-practices}

```{block, type="summaryblock"}
Este capítulo em desenvolvimento inclui [orientações sobre o gerenciamento de credenciais em pacotes] (#pkgsecrets), além de [links para leituras complementares] (#furthersecreading).
```

## Diversos {#miscellaneous}

Recomendamos a leitura do artigo [Dez dicas rápidas para você se manter seguro on-line](https://journals.plos.org/ploscompbiol/article?id=10.1371/journal.pcbi.1008563), de Danielle Smalls e Greg Wilson.

## Segurança no acesso ao GitHub {#git-hub-access-security}

- Recomendamos que você [proteja sua conta do GitHub com uma autenticação 2FA (autenticação de dois fatores)](https://help.github.com/articles/securing-your-account-with-two-factor-authentication-2fa/). Essa medida é *obrigatória* para todos os membros da organização ropensci e colaboradores externos que usam GitHub, portanto, certifique-se de ativá-la antes que seu pacote seja aprovado.

- Também recomendamos que você verifique regularmente quem tem acesso ao repositório do seu pacote e remova qualquer acesso não utilizado (como o de antigos colaboradores).

## https {#https}

- Se o serviço Web que seu pacote utiliza oferecer tanto https quanto http, opte por https.

## Segredos em pacotes {#pkgsecrets}

Esta seção oferece orientações para quando você desenvolve pacotes que interagem com recursos da Web que exigem credenciais (como chaves de API, tokens, etc.). Consulte também [a vignette do pacote `httr` sobre compartilhamento de credenciais](https://httr.r-lib.org/articles/secrets.html).

### Credenciais em pacotes e proteção do usuário {#secrets-in-packages-and-user-protection}

Digamos que seu pacote precise de uma chave de API para fazer solicitações em nome dos(as) usuários(as) do seu pacote.

- Na documentação do seu pacote, oriente o(a) usuário(a) para que a chave de API não seja registrada no arquivo .Rhistory ou no script dos(as) usuários(as) do seu pacote.

- Incentive o uso de variáveis de ambiente para armazenar a chave da API (ou até mesmo remova a possibilidade de passá-la como um argumento para as funções). Você pode, na documentação, fazer referência a [introdução aos arquivos de inicialização](https://rstats.wtf/r-startup.html) e a função [`usethis::edit_r_environ()`](https://usethis.r-lib.org/reference/edit.html).

- Ou seu pacote pode depender ou incentivar o uso de [`keyring` para ajudar o(a) usuário(a) a armazenar variáveis](https://github.com/r-lib/keyring#readme) nos gerenciadores de credenciais específicos do sistema operacional (mais seguro do que .Renviron), ou seja, você criaria uma função para definir a chave e teria outra para recuperá-la; ou o(a) usuário(a) escreveria `Sys.setenv(SUPERSECRETKEY = keyring::key_get("myservice"))` no início de seu script.

- Não imprima a chave da API, nem mesmo no modo verbose, em nenhuma mensagem, aviso ou erro.

- No modelo de issues do GitHub, deve ser declarado que nenhuma credencial deve ser compartilhada. Se um(a) usuário(a) do seu pacote compartilhar acidentalmente as credenciais em uma issue, certifique-se de que ele(a) esteja ciente disso para que possa revogar a chave (ou seja, pergunte explicitamente, em uma resposta, se ele percebeu que compartilhou a chave).

### Credenciais em pacotes e desenvolvimento {#secrets-in-packages-and-development}

Você precisará proteger suas credenciais da mesma forma que protege as credenciais dos(as) usuários(as), mas há mais aspectos a serem considerados e mantidas em mente.

#### Credenciais e solicitações registradas em testes {#secrets-and-recorded-requests-in-tests}

Se você utiliza [`vcr`](https://docs.ropensci.org/vcr/) ou [`httptest`](https://enpiar.com/r/httptest/) em testes para armazenar as respostas da API em cache, é importante garantir que as requisições ou configurações registradas não contenham credenciais. Consulte [o guia de segurança do pacote `vcr`](https://books.ropensci.org/http-testing/security-chapter.html) e [o guia do pacote `httptest` "Redigindo e modificando requisições registradas"](https://enpiar.com/r/httptest/articles/redacting.html). Além disso, inspecione suas requisições gravadas ou configurações antes de realizar o primeiro commit para garantir que você fez a configuração correta.

Como o `vcr` é um pacote da rOpenSci, você pode postar qualquer dúvida que tiver no [Fórum da rOpenSci](https://discuss.ropensci.org/).

#### Compartilhe credenciais com os serviços de CI {#share-secrets-with-ci-services}

Agora, você pode precisar compartilhar credenciais com [serviços de integração contínua](#ci).

Você pode armazenar as chaves de API como variáveis de ambiente ou credenciais, consultando a documentação do serviço de CI.

Para obter mais detalhes e orientações sobre o fluxo de trabalho, consulte [o artigo do pacote gargle - "Gerenciando tokens com segurança"](https://gargle.r-lib.org/articles/articles/managing-tokens-securely.html) e o [capítulo sobre segurança do livro HTTP testing in R](https://books.ropensci.org/http-testing/security-chapter.html).

Documente as etapas que você fez em [CONTRIBUINDO.md](#friendlyfiles) para que você, ou um novo mantenedor, possa se lembrar como proceder da próxima vez.

#### Credenciais e colaborações {#secrets-and-collaborations}

E quanto a pull requests de colaboradores externos?
No GitHub, por exemplo, as credenciais só estão disponíveis para GitHub Actions em pull requests iniciados a partir do próprio repositório, e não a partir de um fork.
Os testes que usam suas credenciais falharão, a menos que você use algum tipo de resposta simulada ou em cache, portanto, pode ser interessante ignorá-los dependendo do contexto.
Por exemplo, na sua conta de CI, você poderia criar uma variável de ambiente chamada `THIS_IS_ME` e, então, ignorar os testes com base na presença dessa variável.
Isso significa, portanto, que as verificações de PR feitas pela CI não serão exaustivas e, como consequência, você precisará verificar o PR localmente para executar todos os testes.

Documente o comportamento do seu pacote em relação a PRs externos no arquivo [CONTRIBUTING.md](#friendlyfiles). Isso será útil tanto para quem faz PRs quanto para quem os revisa, seja você no futuro ou outros mantenedores do pacote.

### Credenciais e CRAN {#secrets-and-cran}

No CRAN, ignore quaisquer testes (`skip_on_cran()`) e exemplos (`dontrun`) que exijam credenciais.

[Gere previamente as vignettes](https://ropensci.org/technotes/2019/12/08/precompute-vignettes/) que requerem credenciais.

## Leitura adicional {#furthersecreading}

Materiais úteis sobre segurança:

- [a sessão da comunidade rOpenSci "Segurança para R"](https://ropensci.org/commcalls/2019-05-07/) (veja a gravação, slides, etc. e, em particular, [a lista de recursos](https://ropensci.org/blog/2019/04/09/commcall-may2019/#resources));

- [os projetos relacionados à segurança do unconf18](https://ropensci.org/blog/2018/06/06/unconf18_recap_2/);

- [artigo do pacote `gargle` "Gerenciando tokens de forma segura"](gargle.r-lib.org/articles/articles/managing-tokens-securely.html)


Loading