Repository navigation
PHPAY-167: apontar os canais do projeto para canais que existem - #168
Merged
Merged
Conversation
phpay.io does not resolve - NXDOMAIN on the root and on the subdomain, with no MX - and every channel of the project pointed there: the security report, the code of conduct, support, commercial licensing, and the homepage of both the repository and Packagist. In a payments library a security channel that promises and does not deliver is worse than none: it discourages responsible disclosure and sends whoever found the flaw nowhere. The channels now use GitHub's own, which need no domain: - security: the private vulnerability report, enabled on the repository. SECURITY.md, config.yml and bug_report.yml point at the form. - code of conduct: the same private channel. - support: Issues, which already exist. - composer.json gains homepage and the support block, which is what Packagist renders as Issues, Source and Docs. Both were absent. - the README footer no longer carries the dead address; it links Issues and the security policy next to the author's profile. Left alone on purpose: the commercial licensing invitation in LICENSE.md and in the README. It asks the reader to write about alternative terms, and that needs an address someone reads, not a vulnerability form. It stays as it is until one is decided. A caveat recorded with the change: GitHub's private report is labelled for vulnerabilities. Using it for a harassment report works technically - it is a private channel to the maintainers - but it is neither obvious nor welcoming for someone who needs to report, and whoever can see security advisories can see the report. An address would serve better; until there is one, a private channel beats an address that does not exist.
The last place the dead domain remained. LICENSE.md invites the reader to write about alternative terms and the README repeats it, and both pointed at a domain with no DNS - so the one path a company has to license this commercially reached nobody. A vulnerability form could not stand in for it, which is why it was left until an address was decided. Two lines, the address only; nothing else in the licence text was touched.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #167.
phpay.ionão existe no DNS — NXDOMAIN na raiz e no subdomínio, sem MX. Etodo canal do projeto apontava para lá: relato de vulnerabilidade, conduta,
suporte, licenciamento comercial, e a homepage do repositório e do Packagist.
Numa biblioteca de pagamentos, um canal de segurança que promete e não entrega é
pior que não ter: ele desencoraja o relato responsável e manda quem encontrou a
falha para o vazio.
Para onde foram
sec@phpay.iofale@phpay.iofale@phpay.iodoc.phpay.iodocs/fale@phpay.ioO
composer.jsonganhouhomepagee o blocosupport— que é o que o Packagistrenderiza como Issues, Source e Docs. Os dois estavam ausentes.
Fora deste PR, porque é configuração: liguei o relato privado de
vulnerabilidade (estava desligado) e troquei a homepage do repositório.
O licenciamento comercial também entrou
Era o último lugar com o domínio morto, e ficou de fora até haver endereço
decidido — um formulário de vulnerabilidade não substitui o convite a tratar de
termos alternativos. Agora o
LICENSE.mde o README apontam paramariolucasdev@gmail.com.Duas linhas, só o endereço: nada mais do texto da licença foi tocado.
Com isso o domínio morto não sobra em canal nenhum. As únicas ocorrências que
restam estão no
smoke.php, como chave Pix de exemplo — valor falso defixture, não canal.
Uma ressalva que vai junto
O relato privado do GitHub é rotulado para vulnerabilidade. Usá-lo para
denúncia de assédio funciona tecnicamente — é canal privado para os mantenedores
—, mas para quem precisa denunciar não é óbvio nem acolhedor, e quem tem acesso a
advisories de segurança passa a ver o relato.
Um e-mail resolveria melhor. Enquanto não houver, canal privado é melhor que
endereço que não existe. Troca de uma linha quando você decidir o endereço.
Verificação
composer test: lint, 770 testes, PHPStan nível 9, 113 links. Ocomposer.jsonsegue válido e com os acentos intactos — conferi, porque já estraguei isso hoje
usando
json.dumps.