Eu não acho que haja uma maneira fácil de remover qualquer informação privada dos logs de travamento, mas seus arquivos devem ser carregados de forma privada, como é bem explicado em Wiki do Ubuntu na Triagem :
Apresentar relatórios
Um número considerável de bugs relatados pelo Apport diz respeito ao programa falhas que são reportadas de forma semi-automática e pré-processadas automaticamente por bots no centro de dados da Canonical. Esses bots tentam gerar um rastreio de pilha totalmente simbólico e verificar se há duplicatas.
No Feisty e no início do Gutsy, esses bugs eram públicos, para que todos podia vê-los. No entanto, isso criou um problema de privacidade despejos e rastreamentos de pilha poderiam conter em formação. Além disso, relatórios de falhas geram muito ruído de e-mail de bug. Com a verificação automática em duplicado, uma quantidade razoável do os bugs são completamente irrelevantes para os triagers.
Desde Gutsy, esses problemas foram atenuados: os erros são arquivados o sinalizador "privado" ativado, i. e. apenas o repórter e os assinantes posso vê-lo. Os bots de reprocessamento vão se inscrever no controle do bug do ubuntu equipe, mas sem enviar email de bug para os membros da equipe.
Assim, os erros de travamento diferem de outros erros em dois aspectos importantes: eles precisam ser verificados quanto a dados sensíveis, e não haverá email de bug inicial para eles até que se tornem públicos. Os triadores devem verifique as seguintes coisas:
Se a falha ainda tiver um anexo CoreDump.gz, não será possível obter automaticamente um rastreamento de pilha totalmente simbólico e verificar se para duplicatas. Nesse caso, o bug será marcado com apport-failed-retrace.
Se o rastreamento da pilha parecer bom o suficiente, o anexo CoreDump.gz deve ser removido com o link (editar) na caixa do anexo. E se o retrace falhou completamente, marque o bug como 'Invalid' e pergunte o repórter para refilar o bug se a falha puder ser reproduzida. Nunca marque um bug contendo um anexo Coredump.gz como público. E se não há nenhum anexo Stacktrace.txt (retratado), então o mais provável razão é que o anexo CoreDump.gz está quebrado.
Por favor, verifique com Martin Pitt (pitti no IRC, [email protected])
sobre o motivo, pois ele pode pesquisar arquivos de log.Verifique se algum dos anexos do stacktrace (stacktrace original, Stacktrace.txt (retraced) e ThreadStacktrace.txt (retraced)) qualquer coisa que pareça dados sensíveis passados como função argumentos. Exemplos são senhas, coisas que se parecem com banco números de contas, chaves CSS, nomes de usuários, nomes de servidores, etc. não encontrar nada, você pode marcar o bug como público ("Este relatório é público / privado "no canto superior direito do relatório de erros). Isto não é exigido, porém, é bom manter o bug privado em todo o seu tempo de vida. Exceto por esses problemas de privacidade, os relatórios de falhas devem ser tratado como bugs normais em termos de busca / marcação duplicada, encaminhamento para upstream, etc.
Se você não quiser enviar nenhuma informação privada, tente relatar o bug manualmente, sem usar a ferramenta ubuntu-bug .
Método mais avançado
Como alternativa, denuncie o bug por meio de um usuário diferente ou da máquina virtual.
Ou verifique os arquivos antes de enviá-los (se você souber onde eles estão) por cat / gzcat e strings , por exemplo
find /var/log -name \*.gz -exec sh -c "gzcat '{}'|strings" \;
find /var/log -name \*.log -exec sh -c "cat '{}'|strings" \;
Onde / var / log é o diretório com registros de falhas compactados, use * .gz para arquivos compactados, use * .log ou o que for para arquivos não compactados. O comando imprimirá todas as sequências armazenadas nesses registros. Você também pode utilizá-los para procurar dados particulares específicos, se souber o que está procurando.
Se você souber qual arquivo é, basta editá-lo ou substituí-lo por sed, por exemplo,
sed -i'.bak' s/private/XXXXXXX/g name_of_the_file.log
Veja também: