Co zrobić z prywatnymi zgłoszeniami błędów w starterze?


9

Z biegiem czasu zebrałem ponad 10 zgłoszeń błędów startera, które zostały zgłoszone za pomocą apport, początkowo oznaczone jako prywatne i nigdy nie odpowiedziały.

Był też taki, o którym dyskutowałem dodatkowo na IRC i tylko to pamiętam, że zostało przetworzone.

Co mam z nimi zrobić? Jak mogę się upewnić, że nie zawierają niczego naprawdę prywatnego przed upublicznieniem tych błędów?


1
int_ua, jako członek Bug Control, podałem tu wytyczne. Usunąłem również listę błędów, które określiłeś jako „prywatne”, ponieważ dopóki błędy te nie będą publiczne, numery błędów powinny być omawiane tylko z kontrolerami błędów lub osobami, które mogą je zobaczyć. Skopiowałem listę błędów do mojego schowka, a jeśli chcesz, żebym pomógł ci spojrzeć na te błędy (zakładając, że je widzę), dołącz do mnie na czacie, abyśmy mogli omówić je. Lub na IRC, w zależności od tego, co wolisz.
Thomas Ward

1
Wolałbym jednak współpracować z tobą nad prywatnymi błędami nad IRC, ponieważ możemy koordynować z innymi kontrolerami błędów, ale mogę spróbować odpowiedzieć na wszelkie inne pytania za pośrednictwem kanału czatu, który podałem w poprzednim komentarzu. :)
Thomas Ward

Odpowiedzi:


6

Jako członek Bug Control musiałem czasami pracować z tymi prywatnymi błędami. Istnieją specjalne zasady postępowania z prywatnymi błędami i sprawdzania konkretnych informacji.

W przypadku błędów związanych z awariami ogólną rzeczą, której należy szukać w błędach prywatnych, są zrzuty pamięci i wszelkie ślady stosu, które mogą znajdować się w błędzie. Jeśli dołączony jest zrzut rdzenia, usuń go. Jeśli dołączone są ślady stosu, przejrzyj je i zidentyfikuj ewentualne prywatne dane w śladzie stosu. Jeśli wyglądają na prywatne dane, musisz pobrać plik stacktrace, edytować prywatne dane, przesłać edytowaną wersję, a następnie usunąć starą wersję.

Ponadto znajdź wszelkie inne dane osobowe lub informacje prywatne, takie jak numery ubezpieczenia społecznego, numery kont, hasła itp., A także spróbuj je edytować.

W przypadku innych błędów prywatnych jest to zależne, ponieważ istnieją osobne zasady dotyczące błędów związanych z prywatnymi zabezpieczeniami, których nie jestem wtajemniczony, ponieważ są one obsługiwane przez zespół ds. Bezpieczeństwa, i prawdopodobnie oznaczałoby to „Prywatne bezpieczeństwo” tylko wtedy, gdy błąd był uzasadniony ryzyko, że nie będą w stanie opublikować informacji.

Mogą również występować prywatne błędy, które nie są przeciwko pakietom Ubuntu, ale przeciwko innym projektom na Launchpad (tj. Nie projektowi Ubuntu ani pakietowi Ubuntu). W przypadku tych błędów menedżerowie tego projektu określą zasady dotyczące tych błędów.


Dodatkowe informacje na temat segregowania raportów o awariach Apport i innych prywatnych błędów w Ubuntu można znaleźć na Wiki Ubuntu, w przewodniku How to Triage, jako część bazy wiedzy Bug Squad . Link automatycznie przekieruje Cię do sekcji „Raporty Apport”, jednak w celu uzyskania najbardziej aktualnych informacji na temat wytycznych dotyczących segregacji należy odnieść się do tego dokumentu wiki.


1
Niezła odpowiedź. Zakładka
23 93 26 35 19 57 3 89

Jaki jest zalecany okres, po którym sam powinienem opublikować zgłoszenie błędu? Tydzień? Miesiąc?
int_ua

2
@int_ua O ile mi wiadomo, nie ma określonego zalecanego okresu czasu, w którym powinieneś upublicznić prywatny błąd.
Thomas Ward
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.