Comment puis-je supprimer des informations privées dans un rapport de bogue?
Si je signale un bogue au tableau de bord à l'aide de ubuntu-bug il ajoute généralement un tas de fichiers sur mon système au bogue, il ajoute également un résumé de bogue généré automatiquement à mon texte de rapport de bogue. Le résumé et les fichiers joints peuvent potentiellement contenir des informations privées telles que mon nom d'utilisateur, le nom d'hôte, etc. Je n'ai trouvé aucune option pour modifier le résumé ou les fichiers. Je sais juste comment supprimer la pièce jointe.
Alors, comment puis-je supprimer ou modifier les informations privées dans le résumé et les fichiers joints?
Je ne pense pas qu'il y ait un moyen facile de supprimer toute information privée des journaux de plantage, mais vos fichiers doivent être téléchargés en privé comme cela est bien expliqué dans buntu Wiki at Triage :
Rapports Apport
Un nombre considérable de bogues signalés par Apport concernent des plantages du programme qui sont signalés semi-automatiquement et sont prétraités automatiquement par les bots dans le centre de données Canonical. Ces robots essaient de générer une trace de pile entièrement symbolique et recherchent les doublons.
À Feisty et au début de Gutsy, ces bugs étaient publics, afin que tout le monde puisse les voir. Cependant, cela a créé un problème de confidentialité car les vidages de mémoire et les traces de pile pouvaient potentiellement contenir des informations sensibles. En outre, les rapports d'erreur génèrent beaucoup de bruit de courrier de bogue. Avec la vérification automatique des doublons, une bonne partie des bogues signalés sont complètement hors de propos pour les trieurs.
Depuis Gutsy, ces problèmes ont été atténués: les bogues sont déposés avec le drapeau "privé" activé, i. e. seuls le journaliste et les abonnés peuvent le voir. Les robots de retraitement abonneront l'équipe ubuntu-bugcontrol, mais sans envoyer d'e-mail de bogue aux membres de l'équipe.
Ainsi, les bogues de crash diffèrent des autres bogues sur deux aspects importants: ils doivent être vérifiés pour les données sensibles, et il n'y aura pas de courrier de bogue initial jusqu'à ce qu'ils deviennent publics. Les trieurs doivent vérifier les éléments suivants:
Si l'accident a toujours une pièce jointe CoreDump.gz, il n'a pas été possible d'obtenir automatiquement une trace de pile entièrement symbolique et de vérifier
pour les doublons. Dans ce cas, le bogue sera marqué avec répart-failed-retrace.Si la trace de la pile semble suffisamment bonne, la pièce jointe CoreDump.gz doit être supprimée avec le lien (modifier) dans la zone de pièce jointe. Si le suivi a échoué complètement, marquez le bogue comme "non valide" et demandez au reporter de refiler le bogue si le plantage peut être reproduit. Ne marquez jamais un bogue contenant une pièce jointe Coredump.gz comme public. S'il n'y a pas de pièce jointe Stacktrace.txt (retracée), la raison la plus probable est que la pièce jointe CoreDump.gz est rompue.
Veuillez vérifier avec Martin Pitt (pitti en IRC, [email protected])
sur la raison car il peut consulter les fichiers journaux.Vérifiez si l'une des pièces jointes stacktrace (stacktraces d'origine, Stacktrace.txt (retracé) et ThreadStacktrace.txt (retracé)) contient quelque chose qui ressemble à des données sensibles transmises comme arguments de fonction. Les exemples sont les mots de passe, des choses qui ressemblent à des numéros de compte bancaire, des clés CSS, des noms d'utilisateur, des noms de serveur, etc. Si vous ne trouvez rien, vous pouvez marquer le bogue comme public ("Ce rapport est public/privé" en haut à droite du rapport de bogue). Ce n'est pas obligatoire cependant, il est bien de garder le bogue privé pendant toute sa durée de vie. À l'exception de ces problèmes de confidentialité, les rapports d'erreur doivent être traités comme des bogues normaux en termes de recherche/marquage en double, de transfert en amont, etc.
Si vous ne souhaitez pas envoyer d'informations privées, essayez de signaler le bogue manuellement, sans utiliser ubuntu-bug outil.
Méthode plus avancée
Vous pouvez également signaler le bogue en vous connectant à un autre utilisateur ou à partir de la machine virtuelle.
Ou scannez les fichiers avant de les envoyer (si vous savez où ils se trouvent) par cat/gzcat et strings, par ex.
find /var/log -name \*.gz -exec sh -c "gzcat '{}'|strings" \;
find /var/log -name \*.log -exec sh -c "cat '{}'|strings" \;
Où/var/log est le répertoire avec les journaux de plantage compressés, utilisez * .gz pour les fichiers compressés, utilisez * .log ou autre pour les fichiers non compressés. La commande affichera chaque chaîne stockée dans ces journaux. Vous pouvez également les solliciter pour rechercher des données privées spécifiques, si vous savez ce que vous recherchez.
Si vous savez de quel fichier il s'agit, modifiez-le ou remplacez-le par sed, par ex.
sed -i'.bak' s/private/XXXXXXX/g name_of_the_file.log
Voir également: