O que o selo realmente registra
Um selo de commit verificado é o resultado de uma checagem de assinatura, não uma referência de caráter. Quando você vê “Verified” ao lado de um commit no GitHub, a plataforma está dizendo uma coisa bem específica: ela checou uma assinatura criptográfica anexada àquele commit e a checagem passou.
O GitHub marca um commit assinado como Verified quando sua assinatura é verificada com sucesso. Fonte
O selo está anexado a um commit, não a uma pessoa. Ele também não é um indicador de segurança ao vivo da conta que você está olhando hoje. O resultado da verificação é um registro histórico de uma checagem que aconteceu em um momento específico.
Depois que a verificação é registrada, o registro pode persistir mesmo após uma chave de assinatura ser revogada ou expirar. Fonte
Essa persistência importa para investigadores. Um selo pode continuar visível em um commit antigo mesmo depois que a chave de assinatura que o produziu foi revogada ou expirou. Uma chave revogada não apaga retroativamente o selo, e uma chave expirada não torna o commit antigo não verificado. Portanto, o selo diz que a assinatura foi checada quando foi registrada, não que a chave ainda é confiável, que a conta ainda está segura ou que o atual titular da conta é a mesma pessoa que assinou.
Passo 1: Separe as três perguntas
Quando alguém aponta um commit verificado como evidência de uma alegação de desenvolvedor, geralmente está misturando três perguntas diferentes. Separe-as antes de avaliar qualquer coisa.
| Pergunta | O que um selo verificado pode mostrar | O que ele não pode mostrar sozinho |
|---|---|---|
| Este commit foi assinado e verificado? | O GitHub registrou uma verificação de assinatura bem-sucedida para aquele commit. | Quem escreveu o código, ou se o código é bom. |
| Quem controla a conta agora? | Nada diretamente. O selo está ligado ao commit, não ao controle de login atual. | Se a mesma pessoa ainda é dona da conta, ou se a conta mudou de mãos. |
| Esta pessoa é quem diz ser, ou trabalha onde diz? | Nada diretamente. | Identidade, emprego ou autorização para falar em nome de uma organização. |
Um selo verificado responde apenas à primeira linha. A segunda e a terceira linhas exigem evidências separadas. É a mesma disciplina descrita no nosso guia sobre o que a busca de perfil público pode e não pode revelar sobre uma pessoa: um artefato público é uma pista, não uma conclusão.
Passo 2: Leia o commit, não apenas o selo
Um selo é um atalho, e atalhos escondem contexto. Abra o commit em si e veja o que cerca o resultado da verificação.
- O campo de autor do commit e o campo de committer. São entradas de metadados, não prova de quem digitou o código. Podem ser definidos como qualquer coisa em muitos fluxos de trabalho.
- A chave de assinatura exibida. O GitHub associa um resultado de verificação a uma chave. Observe se a chave é apresentada como pertencente a uma conta, a uma organização ou a um bot.
- O repositório e o branch. Um commit verificado em um fork pessoal tem menos peso organizacional do que um mesclado em um projeto mantido, mas nenhum dos dois prova emprego.
- A data. Um commit verificado antigo é um dado histórico. Não diz nada sobre a postura de segurança atual da conta.
Nenhum desses campos, sozinho ou em conjunto, estabelece que o titular da conta é a pessoa nomeada em uma biografia ou que a pessoa trabalha onde o perfil diz que trabalha.
Passo 3: Verifique o controle atual da conta separadamente
Um commit verificado é um registro sobre um commit. O controle da conta é uma pergunta separada, e páginas públicas raramente a respondem diretamente. O que você pode fazer é procurar consistência e continuidade.
- Compare o histórico público da conta ao longo do tempo. Um histórico longo e coerente de contribuições é uma pista, não prova.
- Procure o mesmo handle ou nome de exibição em outras plataformas. Handles iguais são uma pista. Não são prova de que as contas pertencem à mesma pessoa, porque handles não são únicos entre plataformas e podem ser reutilizados ou registrados por terceiros.
- Trate texto de perfil, avatares e biografias como alegações do titular da conta, não como fatos verificados.
Se alguém apresenta um selo verificado como prova de que controla uma conta atualmente, isso é um erro de categoria. O selo não mede a segurança de login atual e não confirma que a pessoa falando com você é o titular da conta.
Passo 4: Procure evidências independentes
Evidência independente é qualquer coisa que não se origina da mesma conta que faz a alegação. Exemplos incluem uma lista de membros da equipe publicada pela própria organização, uma listagem de palestra em um site de conferência ou um repositório mantido sob uma conta organizacional com seu próprio registro público. Mesmo esses são corroboração, não prova de identidade. Seu trabalho é decidir quanto peso a combinação merece, não declarar certeza.
Tabela de decisão: quanto peso dar a um selo verificado
| Situação | Leitura razoável | Incerteza restante |
|---|---|---|
| Selo presente, chave ainda associada à conta, commit recente | A assinatura foi verificada e a associação da chave é atual. | Não prova que a pessoa controla a conta ou escreveu o código. |
| Selo presente, chave revogada ou expirada | A verificação foi registrada quando aconteceu. | Não diz nada sobre a confiança atual na chave ou a segurança da conta. |
| Selo presente apenas em commits antigos | Registro histórico de verificação. | Nenhuma implicação sobre atividade ou controle atuais. |
| Selo ausente | Nenhuma assinatura verificada naquele commit. | A ausência não é evidência de irregularidade; muitos fluxos de trabalho legítimos não assinam todos os commits. |
| Selo mais handle igual em outro lugar | Uma pista que vale a pena seguir. | Handles não são únicos; as contas podem pertencer a pessoas diferentes. |
| Selo mais menção em perfil de organização | Corroboração de uma possível afiliação. | Não prova emprego ou autorização para falar em nome da organização. |
Erros comuns
- Tratar o selo como checagem de identidade. É um resultado de assinatura, não uma checagem de antecedentes.
- Presumir que um selo histórico prova a segurança atual da conta. O registro pode persistir após uma chave ser revogada ou expirar, então o selo não é um indicador de status ao vivo.
- Confundir metadados de autor e committer com autoria. Esses campos são alegações no objeto do commit, não fatos verificados sobre quem escreveu o código.
- Tratar handles iguais como prova de uma única pessoa. O mesmo handle em duas plataformas é uma pista. Não é prova de que as contas pertencem ao mesmo indivíduo.
- Ler um selo em um fork como endosso organizacional. Um commit verificado em um fork pessoal não estabelece que uma organização revisou ou endossou o trabalho.
- Presumir que um commit não assinado é suspeito. Muitos contribuidores e fluxos de trabalho legítimos não assinam todos os commits.
Checklist de autorrevisão
Antes de repetir uma alegação de desenvolvedor que se apoia em um selo verificado, passe por este checklist.
- Abri o commit e anotei autor, committer, chave, repositório e data?
- Separei “assinatura verificada” de “controle da conta” e de “identidade ou emprego”?
- Verifiquei se a chave ainda está associada à conta, ou se o registro pode persistir após revogação ou expiração?
- Procurei pelo menos uma fonte que não se origina da mesma conta?
- Descrevi handles iguais como pista, e não como prova de uma única pessoa?
- Evitei afirmar que o selo prova segurança atual, autoria ou emprego?
Protegendo sua própria pegada
Se você assina commits, lembre-se de que um selo verificado é um registro que você deixa para trás. Ele pode durar mais que a chave que o produziu. Antes de revogar ou rotacionar uma chave de assinatura, decida como você quer que commits antigos sejam lidos e mantenha suas próprias notas sobre quais chaves foram usadas quando. Se você mantém perfis públicos, revise os handles que usou ao longo do tempo e verifique se contas antigas ainda apontam para você. Uma busca de nome de usuário como o TraceSeek pode ajudar você a revisar seus próprios handles públicos conhecidos em 3.000+ plataformas; a primeira varredura é gratuita e não exige cadastro nem login, e os resultados costumam ser retornados em 20–30 segundos. Trate a saída como uma lista de pistas para revisar, não como verificação de identidade. O TraceSeek não altera configurações de plataformas, não garante uma correspondência e não verifica a identidade de ninguém. Para saber como enquadramos evidências e limites, consulte nossa metodologia.
Fatos principais
- O GitHub marca um commit assinado como Verified quando sua assinatura é verificada com sucesso.
- Depois que a verificação é registrada, o registro pode persistir mesmo após uma chave de assinatura ser revogada ou expirar.
- Um selo de commit verificado é um resultado de assinatura para um commit específico, não prova de controle atual da conta ou de identidade.
- Identificadores públicos iguais entre plataformas são pistas, não prova de que as contas pertencem à mesma pessoa.
- O TraceSeek cobre 3.000+ plataformas e oferece uma primeira varredura gratuita sem cadastro nem login.