repo: gemini-site
action: commit
revision: 
path_from: 
revision_from: ea5a3a9820e0ecf227d25a5bb9f38762f31026f6:
path_to: 
revision_to: 

commit ea5a3a9820e0ecf227d25a5bb9f38762f31026f6
Author: Paulo Pinto 
Date:   Fri Feb 26 13:11:00 2021 +0100

    Portugues translation of Resources for beginners

    Signed-off-by: Solderpunk 

diff --git a/docs/pt-PT/cheatsheet.gmi b/docs/pt-PT/cheatsheet.gmi
new file mode 100644
index 0000000000000000000000000000000000000000..f12ea9d47d10c93168d8dac2aa1abafd985cdde1
--- /dev/null
+++ b/docs/pt-PT/cheatsheet.gmi
@@ -0,0 +1,35 @@
+# Cheatsheet do Gemtext
+
+Eis os princípios básicos que devem ser conhecidos para entender o Gemtext:
+
+* As linhas longas são agrupadas pelo cliente, de forma a caberem no ecrã
+* As linhas curtas *não* se juntam
+* Para escrever um parágrafo devem usar-se linhas longas simples
+* As linhas em branco são renderizadas de forma literal
+
+
+Existem três níveis de título (heading):
+
+```
+# Título de nível 1
+
+## Título de nível 2
+
+### Título de nível 3
+```
+
+Existe um tipo único de lista e esta não pode ser hierarquizada:
+
+```
+* Mercury
+* Gemini
+* Apollo
+```
+
+Eis uma citação de Maciej Cegłowski:
+
+```
+> I contend that text-based websites should not exceed in size the major works of Russian literature.
+```
+
+As linhas começadas por ``` fazem com que os clientes ativem ou desativem o modo de pré-formação, o que serve para alternar entre este e o modo normal.  No modo de pré-formatação, a sintaxe Gemtext é ignorada, de modo que quaisquer símbolos de formatação, como links ou outros, não serão renderizados, e o texto será apresentado com uma fonte de largura fixa (monospace).
diff --git a/docs/pt-PT/gemtext.gmi b/docs/pt-PT/gemtext.gmi
new file mode 100644
index 0000000000000000000000000000000000000000..6c51d8fcd5d70357368429de78c9acf72443169e
--- /dev/null
+++ b/docs/pt-PT/gemtext.gmi
@@ -0,0 +1,98 @@
+# Uma rápida introdução à formatação "gemtext"
+
+A forma mais comum de disponibilizar conteúdo textual no Gemini não se processa como no Gopher, onde se usa apenas texto simples. O Gemini usa uma linguagem de formatação simplificada (markup) chamada "Gemtext" (que é codificada com o tipo MIME não oficial text/gemini). Este documento pretende ser uma introdução básica a essa linguagem de formatação, que tem algumas semelhanças, ainda que superficiais, com o Markdown. Quem já conhecer o Markdown terá a sua aprendizagem mais facilitada, ainda que o Gemtext seja um pouco diferente em alguns aspetos.
+
+Depois de ter lido este documento, poderá refrescar a sua memória consultando:
+
+=> gemini://gemini.circumlunar.space/docs/cheatsheet.gmi Cheatsheet do Gemtext
+
+## Texto
+
+Nos documentos Gemtext, o texto escreve-se com "linhas longas". O seu editor (ou você) não deve inserir carateres de nova linha, mesmo que a linha exceda 80 carateres de comprimento. Essa tarefa de quebra de linha é deixada para o cliente Gemini, que as quebrará de acordo com o tamanho disponível no ecrã do dispositivo e de acordo com a preferência do utilizador. Desta forma, o conteúdo do Gemtext terá sempre uma boa aparência, sendo facilmente lido em monitores de desktop, ecrãs de laptop, tablets e smartphones.
+
+Note que, embora os clientes Gemini dividam as linhas de texto longas de forma a caberem no ecrã, as linhas mais curtas não são unidas, contrariamente ao que acontece com Markdown, HTML ou LaTeX. Isso significa que, por exemplo, listas bullet ou poemas com linhas deliberadamente curtas sejam exibidas corretamente, sem que o autor tenha que fazer qualquer trabalho extra ou sem que o cliente tenha necessidade de reconhecer e lidar corretamente com esse tipo de conteúdo.
+
+Na maior parte dos casos que configuram uma escrita puramente descritiva, a chamada escrita do "dia-a-dia", usar-se-á uma linha por parágrafo.
+
+Note que as linhas em branco são reproduzidas de forma literal pelos clientes, ou seja, se existirem duas ou três linhas em branco entre os parágrafos, o leitor verá no ecrã essas mesmas duas ou três linhas em branco.
+
+## Links
+
+Como acontece no Gopher (e ao contrário do Markdown ou do HTML), no Gemtext os links para outros documentos devem ser colocados numa linha própria. Significa que não é possível transformar, no meio de uma frase, uma palavra ou um conjunto de palavras num link. Levará algum tempo até que este conceito seja interiorizado, mas, em contrapartida, os links serão extremamente fáceis de encontrar no documento. Outra vantagem é o facto dos clientes poderem estilizá-los de forma diferente (para, por exemplo, evidenciar o protocolo usado, ou para exibir o nome de domínio, ajudando os utilizadores na hora de decidir se desejam ou não seguir os links), sem que isso signifique interferir na legibilidade do conteúdo textual real.
+
+As linhas de link têm o seguinte aspeto:
+
+```
+=> https://example.com    A cool website
+=> gopher://example.com   An even cooler gopherhole
+=> gemini://example.com   A supremely cool Gemini capsule
+=> sftp://example.com
+```
+
+Ou seja:
+
+* As linhas começam com os dois carateres =>,
+* ao que se segue um espaço em branco opcional (espaços ou tabulações, tantos quantos desejar),
+* e um URL (de qualquer protocolo).
+* Elas podem terminar no URL, se desejar, conforme o exemplo sftp acima!
+* Ou podem ter, a seguir, pelo menos um espaço ou guia,
+* E depois, uma descrição amigável, que pode ter o tamanho que desejar
+
+Nos exemplos acima mostrados, todos os URLs e descrições estão bem alinhados, porque o autor foi zeloso. Mas o Gemini não se importa com esse facto, e isso também pode ser o pretendido:
+
+```
+=>https://example.com A cool website
+=>gopher://example.com      An even cooler gopherhole
+=> gemini://example.com A supremely cool Gemini capsule
+=>   sftp://example.com
+```
+
+## Títulos (Headings)
+
+O Gemtext suporta três níveis de títulos (headings). Os títulos estão limitados a uma única linha e começam com um, dois ou três símbolos #, seguidos por um espaço obrigatório:
+
+```
+# Título de nível 1
+
+## Título de nível 2
+
+### Título de nível 3
+```
+
+Esta é a única sintaxe de título suportada. Sublinhar os títulos usando os símbolos - ou =, como no Markdown, não terá nenhuma consequência.
+
+Apresentar os títulos de uma forma especial é algo que os clientes podem fazer opcionalmente. Muitos clientes, ao reconhecê-los, usarão uma fonte maior ou uma cor diferente, ou algum outro tipo de estilo. Outros há que os tratarão apenas como linhas de texto normais, exibindo-os desse modo. Esse comportamento é desejável, uma vez que os títulos não devem ser usados para controlar a aparência do conteúdo do documento. A sua função é a de fornecer informações semânticas importantes sobre a estrutura do conteúdo. Alguns clientes usarão os títulos para gerar automaticamente um índice analítico que apresentarão ao utiizador, o que pode ser útil para navegar em documentos extensos. O software de geraração de feeds Atom ou RSS pode usar os títulos para nomear os posts do gemlog.
+
+## Listas
+
+O Gemtext tem suporte para listas não ordenadas. Os items numa lista escrevem-se numa única linha longa, que começa com o símbolo *, seguido por um caratere de espaço obrigatório:
+
+```
+* Mercury
+* Gemini
+* Apollo
+```
+
+Esta é a única sintaxe de lista suportada. Usar - em vez de *, como no Markdown, não terá nenhum efeito. Listas hierarquizadas não são suportadas.
+
+Apresentar os items de uma lista de uma forma especial é algo que os clientes podem fazer opcionalmente. Alguns clientes vão tratá-los como qualquer outra linha de texto. A única razão pela qual eles são definidos, é para que os clientes mais avançados possam substituir o * por um símbolo de marcador de aparência mais agradável e, no caso dos items da lista serem muito longos, quebrá-los em várias linhas, de forma a que caibam no ecrã do dispositivo. As linhas posteriores à primeira podem ser indentadas usando o mesmo espaço do símbolo de marcador. Contudo, esta é apenas uma subtileza tipográfica.
+
+## Blocos de citação
+
+O Gemtext suporta blocos de citação. O conteúdo citado é escrito numa única linha longa, que começa com o caractere >:
+
+```
+> Gemtext supports blockquotes.  The quoted content is written as a single long line, which begins with a single > character
+```
+
+Apresentar os blocos de citação de uma forma especial é algo que os clientes podem fazer opcionalmente. Alguns clientes tratá-los-ão como qualquer outra linha de texto. A exemplo do que acontece com os items de uma lista, os blocos de citação são definidos estritamente para permitir uma tipografia mais agradável em clientes com mais potencialidades.
+
+## Texto pré-formatado
+
+O Gemtext foi projetado de forma a poder ser facilmente analisado e renderizado. Ele é processado pelos clientes através da análise e renderização de uma linha de cada vez, independentemente de quaisquer linhas que estejam antes ou depois. Os clientes inspecionam os primeiros carateres da linha para verificar se encontram os símbolos =>, #, *, ou outros.
+
+Uma linha começada por ```(ou seja, com três acentos graves de crase) indica ao cliente que ele deve alternar entre o modo de análise normal e o "modo pré-formatado". No modo pré-formatado, os clientes não ligam aos símbolos de formatação que normalmente identificam links, títulos ou quaisquer outras formatações. As linhas são exibidas exatamente como estão escritas. Outra diferença reside no facto dos clientes, no modo pré-formatado, usarem uma fonte de largura fixa, ao passo que no texto comum usam fontes de largura variável. Assim, um par de linhas ``` apresenta um resultado visual muito semelhante às tags 
 e 
 em HTML.
+
+O texto pré-formatado pode ser usado para incluir arte ASCII, código-fonte ou conteúdo semelhante num documento Gemtext, evitando-se, dessa forma, que os clientes interpretem as linhas como contendo títulos, itens de lista, entre outros. O texto pré-formatado pode também ser usado para escrever documentos como este, que contém exemplos de sintaxe Gemtext - os exemplos de sintaxe acima mostrados não são interpretados pelo cliente, como normalmente aconteceria, uma vez que eles estão renderizados no modo pré-formatado.
+
+Qualquer conteúdo que exista após os carateres ``` de uma linha, que colocam o modo de linha pré-formatada a *on* (ou seja, a primeira, terceira, quinta, etc., linhas alternadas num documento), pode ser tratado como "texto alternativo" para o conteúdo pré-formatado. Normalmente, esse conteúdo não é visível para o utilizador, mas ele pode ser indexado pelos motores de pesquisa e pode ser lido pelos leitores de ecrã, de modo a que o utilizador decida se deve ser lido em voz alta (no caso da arte ASCII provavelmente não, mas no caso do código-fonte talvez deva ser). De momento, não existem convenções estabelecidas para a formatção de texto alternativo.
diff --git a/docs/pt-PT/index.gmi b/docs/pt-PT/index.gmi

--- a/docs/pt-PT/index.gmi
+++ b/docs/pt-PT/index.gmi
@@ -7,6 +7,12 @@
 => boas-praticas.gmi Boas práticas para implementações Gemini
 => ./complementar/index.gmi Especificações complementares

+## Recursos para iniciados
+
+=> gemtext.gmi Uma breve introdução à formatação "gemtext"
+=> cheatsheet.gmi Cheatsheet do Gemtext
+=> tutorial-tls.gmi Como funcionam os certificados TLS? (foco no Gemini) 
+
 ## Traduções

 => traducoes.gmi Traduções da documentação efetuada por voluntários
diff --git a/docs/pt-PT/tutorial-tls.gmi b/docs/pt-PT/tutorial-tls.gmi
new file mode 100644
index 0000000000000000000000000000000000000000..e592fe05cfc15f18da0e6bb014782436db92f132
--- /dev/null
+++ b/docs/pt-PT/tutorial-tls.gmi
@@ -0,0 +1,77 @@
+# TLS, certificados de cliente, TOFU, e coisas similares
+
+Este documento está em construção!
+
+## Introdução
+
+O Gemini obriga a que todas as conexões sejam protegidas por TLS. Ele também oferece suporte para o uso de certificados de cliente e esquemas alternativos de validação de certificados, um tema que não é muito familiar para muitas pessoas. Para muitos aspirantes a desenvolvedores Gemini, esta é a parte mais complicada. Daí que este documento vise fornecer uma introdução básica aos conceitos relevantes. Não sendo demasiado detalhado nem preciso, cumpre o objetivo de permitir que as pessoas entendam como tudo funciona, ainda que de forma abstrata, antes de quaisquer detalhes criptográficos.
+
+Contudo, esta não é uma explicação a partir "do zero". Presume-se que você esteja já familiarizado com alguns conceitos básicos de criptografia assimétrica (ou de "chave pública"); não uma matemática que explique como tudo e porque tudo funciona, mas que explique o panorama conceitual. Basicamente, você deverá sentir-se à vontade com as seguintes ideias:
+
+* Pares de chaves, ou seja, chaves públicas e privadas, cujo princípio de funcionamento faz com que tudo que seja criptografado com a primeira só possa ser descriptografado com a segunda
+* Assinaturas digitais, ou seja, um método que permite que as pessoas possam usar a sua chave privada para "assinar" conteúdo digital, de forma a que outros possam validá-lo usando a sua chave pública, fazendo com que essas assinaturas não possam ser falsificadas. Dessa forma, o conteúdo é assinado e fica protegido contra modificação
+
+## Noções básicas de certificados
+
+### O que é um certificado TLS?
+
+Para os nossos propósitos, pense-se um certificado TLS como sendo uma combinação dos seguintes componentes:
+
+* Uma chave pública
+* Alguns metadados sobre a parte que supostamente detem essa chave pública - o chamado "subject" (sujeito) do certificado
+* Uma assinatura digital em todo o certificado
+* Alguns metadados sobre a parte que assinou o certificado - o chamado "issuer" (emissor) do certificado
+* Uma data de validade
+
+Os metadados do subjet e do issuer possuem a mesma estrutura. O que há de sofisticado é que um certificado contém o "Distinguished Name" (DN) do subject e do issuer. Um DN possui vários campos, mas o mais importante é o chamado "Common Name" (CN). Não tendo que ser obrigatoriamente assim, o uso típico no mundo real dita que o CN do subject é quase sempre um nome de host, como `paypal.com`.
+
+Num certificado há, geralmente, mais do que estas informações, mas, para já, esta informação é a suficiente para que se entenda o restante conteúdo deste artigo. A maior parte das vezes podemos esquecer a data de validade do certificado e apenas pensar no certificado como o conjunto de informações constituído por uma chave pública, o nome de alguém que afirma ser o seu proprietário, e o nome e a assinatura de alguém que certifica (daí o nome certificado!) essa reivindicação como sendo verdadeira.
+
+### Como são tipicamente usados os certificados TLS?
+
+Suponha que você é o admnistrador legítimo do servidor denominado `example.com`. A forma "normal" de usar o TLS é contactar um terceiro confiável, a que chamamos "Certificate Authority" (CA), e dizer "Olá, CA, o meu DN é bla, bla, bla e o meu CN é example.com. Este conjunto de bytes é a minha chave pública". Por seu lado, a CA "fará algo" para ter a certeza de que você é, de facto, o administrador legítimo de example.com, e então usará a sua chave privada para assinar um certificado que apresenta o seu DN (como subject),o DN da CA (como issuer) e mais uma data de validade. A partir desse momento, poderá configurar o seu servidor web ou o seu servidor de e-mail, ou qualquer outra aplicação que o necessite, para que seja usado o seu certificado sempre que os clientes necessitarem de TLS para funcionar.
+
+Do lado do cliente, os navegadores da web e/ou os sistemas operativos vêm geralmente com uma grande pilha pré-instalada de chaves públicas para CAs reconhecidas. Quando uma pessoa se conecta ao seu servidor web e obtém o seu certificado, pode usar o DN do seu CA para encontrar a chave pública na sua pilha, de forma a poder validar a assinatura no seu certificado. Se a assinatura for válida, ela sabe que, de facto, aquela CA fidedigna está convencida de que a chave pública naquele certificado pertence realmente a example.com. Uma vez que o cliente confia na CA, a chave pública é validada como genuína e (assumindo que a data de validade não tenha caducado) está tudo pronto: o cliente e o servidor usam a chave pública autenticada para inicializar um canal seguro, através de um processo complicado que na verdade tem muito pouco a ver com o certificado.
+
+### Isto tudo é necessário?
+
+Usemos um caso prático. Suponha que um cliente se conecta a example.com e o servidor envia uma chave pública vazia em vez de um certificado. Ainda assim, o cliente pode usar essa chave para criptografar as informações enviadas para o servidor, e essas informações estariam protegidas de bisbilhoteiros. O risco é que alguém mal intencionado pode não apenas espionar a conexão, mas também interferir ativamente - como o ISP do cliente ou servidor, ou alguém que enganou o provedor de DNS do cliente para direcionar o domínio example.com para o seu próprio servidor -, agindo como "Man in the Middle" (MitM). Quando o cliente se tenta conectar ao servidor, o atacante envia a sua *própria* chave pública de volta ao cliente. Ao mesmo tempo, eles se conectam ao servidor pretendido, recebendo a chave pública real do servidor. O atacante usa a sua própria chave privada para descriptografar tudo o que obtém do cliente e, em seguida, criptografa novamente usando a chave pública do servidor, antes de enviá-la ao servidor - e vice-versa, na outra direção. O cliente e o servidor ainda podem comunicar entre si e tudo parece funcionar, mas o atacante pode ler tudo, mesmo que seja criptografado pelo cliente e pelo servidor.
+
+Para evitar os problemas atrás descritos, o cliente precisa de saber que qualquer que seja a chave pública que seja enviada através do canal de comunicação ela pertence realmente a example.com, e não a algum atacante que intercetou a conexão e substituiu a chave. Não haja ilusões, pois este é um problema complicado. Existem muitas soluções possíveis, todas com diferentes prós e contras. A solução principal na Internet de hoje é usar certificados assinados por CAs. Basicamente, envolve terceirizar o difícil trabalho de garantir que quem diz possuir uma chave pública é realmente quem a possui, e quem está em melhores condições de o fazer é um pequeno número (em relação ao número de computadores na Internet) de partes confiáveis ​​(os CAs), que efetivamente fazem um bom trabalho.
+
+Assim, se deixarmos de parte os detalhes técnicos contidos *num* certificado TLS e o que os computadores fazem com eles, e pensarmos apenas em termos da *função* que desempenham, os certificados TLS são uma forma de uma parte (issuer) garantir a validade do que é reclamado pela outra parte (a reclamação do subject de que "esta chave é minha") de uma forma fidedigna, que seja capaz de promover relações de confiança com quem precisa de acreditar nesse trabalho (por quem tem a chave pública do issuer e, desse modo, ser capaz de validar a sua assinatura digital).
+
+### Ok! Então isso significa que com um sistema de CA temos o problema do MitM resolvido?
+
+Ora bem, sim e não.
+
+Há pessoas que não estão muito satisfeitas com a segurança oferecida pelo sistema CA. A menos que você empilhe um monte de extras em cima do procedimento de validação atrás descrito, *qualquer* CA cuja chave pública esteja pré-instalada no seu navegador ou sistema operativo pode assinar um certificado para *qualquer* nome de host, fazendo com que o seu sistema o aceite sem duvidar. Podemos estar a falar de uma lista de literalmente centenas de CAs, propriedade de empresas ou governos de todo o mundo, nas quais você pode depositar níveis diferenciados de confiança (realisticamente, você nunca ouviu falar ou interagiu anteriormente com a maioria deles). Se o seu sistema aceitar um certificado de qualquer CA, a segurança máxima do sistema será o equivalente à segurança oferecida pela CA menos confiável: a CA que faz a verificação menos cuidadosa das reivindicações de uma chave pública, ou a CA com a pior segurança da Internet, que obtém a sua chave privada roubada, ou a CA com os funcionários mais facilmente subornados, ou a CA cujo governo tem o poder para os obrigar a assinar um certificado falso, sob ameaça de prisão, ou pior. A CA mais fraca pode ser, de facto, muito fraca, e se se descobrir que uma certa CA "se tornou ela própria de pouca confiança", pode ser muito trabalhoso, e demorar muito tempo, remover a sua chave pública de cada dispositivo que a tem instalada.
+
+Há pessoas menos preocupadas com a segurança fornecida pelo sistema CA e mais insatisfeitas por razões políticas ou filosóficas. O motivo é o facto de todo o sistema se basear num número relativamente pequeno de empresas privadas, com fins lucrativos, que administram uma infraestrutura centralizada cara e que cobra dinheiro aos utilizadores finais (às vezes muito dinheiro) para certificados.
+
+### O que são certificados auto-emitidos e auto-assinados?
+
+Um certificado é "auto-emitido" se o subject e o issuer forem a mesma entidade e "auto-assinado" se for assinado com uma chave privada correspondente à chave pública nele contida. Um certificado pode ser auto-emitido sem ser auto-assinado, e vice-versa, mas o caso mais comum (e aquele em que a maioria das pessoas pensa quando se fala em "certificados auto-assinados") é um certificado possuir ambas as propriedades.
+
+Os certificados auto-assinados não se enquadram no uso típico de certificados: eles não funcionam como forma de proporcionar confiança quanto à propriedade de uma chave pública, porque não há terceiros envolvidos, como uma CA, na qual o cliente já confia e para a qual o servidor se autenticou. Qualquer pessoa pode emitir um certificado auto-assinado com qualquer CN de subject. Se você usar um certificado auto-assinado para o seu servidor, não há forma de um cliente o distinguir de um certificado que tenha sido emitido por um hacker, para um ataque MitM - pelo menos não apenas através da análise do certificado e da validação da assinatura. Esse é o motivo pelo qual os certificados auto-assinados são geralmente considerados inseguros.
+
+Este não é um problema menor, mas importa entender que a diferença entre um certificado auto-assinado e um certificado assinado por uma CA é tão somente uma questão de saber se você pode garantir, apenas através da análise do próprio certificado, que a chave pública nele contida pertence realmente ao nome do host indicado. A chave pública contida num certificado auto-assinado não é diferente, nem inferior, à chave pública contida num certificado assinado por uma CA, e não existe nenhuma diferença na força da criptografia resultante do uso dessa chave. Isso significa que, em situações em que:
+
+* você é capaz de validar que a chave realmente pertence ao nome do host, através de algum outro meio, ou
+* você chega à conclusão que saber a quem pertence a chave não é realmente importante
+
+os certificados auto-assinados são perfeitamente válidos para serem usados.
+
+Neste momento, é provável que pergunte: qual é a vantagem em usar um certificado auto-assinado por oposição ao uso de apenas uma chave pública? Na verdade, a resposta é muito pouca vantagem. Há muitos protocolos seguros que usam chaves públicas vazias, sem certificados. Mas o TLS é construído com base no conceito de certificados assinados por CA e não possibilita a utilização de chaves públicas de forma isolada. Pensemos nos certificados auto-assinados como um hack para contornar esse constrangimento: eles permitem-nos usar a pilha de tecnologia TLS pré-existente, optando por prescindir do sistema de CA.
+
+## Certificados de cliente
+
+Brevemente.
+
+## TOFU
+
+Brevemente.
+
+## Questões práticas
+
+Brevemente.

-----END OF PAGE-----