path: root/polish/security/faq.wml

#use wml::debian::template title="Najczęściej zadawane pytania nt. bezpieczeństwa Debiana"
#include "$(ENGLISHDIR)/security/faq.inc"
#use wml::debian::translation-check translation="9a27273be95f6e5924bc26329458a358643507e2"

<p>Poniższe pytania pojawiają się najczęściej, dlatego odpowiedzi na nie
postanowiliśmy umieścić tutaj.</p>

<maketoc>

<toc-add-entry name=signature>Sygnatura w wiadomościach nie przechodzi 
poprawnie procedury sprawdzania!</toc-add-entry>
<p>A: Jest to najwyraźniej problem po stronie użytkownika. Lista
   <a href="https://lists.debian.org/debian-security-announce/">\
   debian-security-announce</a>
   posiada filtr dopuszczający jedynie wiadomości z poprawną sygnaturą
   należącą do członków grupy ds. bezpieczeństwa.</p>


<p>Najprawdopodobniej oprogramowanie pocztowe użytkownika 
   zmienia wiadomość, przez co sygnatura nie jest już poprawna. 
   Należy się upewnić, że oprogramowanie nie koduje lub dekoduje MIME 
   jak również, że nie zamienia znaków tab na spację i vice versa.</p>

<p>Znanymi winowajcami są fetchamil (z włączoną opcją mimedecode),
   formail (tylko z procmail 3.14) i evolution.</p>

<toc-add-entry name="handling">Jak obsługiwane są sprawy związane z bezpieczeństwem w Debianie?</toc-add-entry>
<p>A: Po otrzymaniu przez grupę ds. bezpieczeństwa zgłoszenia naruszenia
   bezpieczeństwa, jeden lub więcej członków przeanalizuje je i rozważy
   wpływ zdarzenia na stabilne wydanie Debiana (tj. czy jest na to zdarzenie
   odporne czy nie). Jeżli system nie jest odporny, rozpoczynamy prace
   nad poprawką do tego problemu. Kontaktujemy się także z opiekunem pakietu, o ile
   on nie skontaktował się pierwszy z grupą ds. bezpieczeństwa. Następnie poprawka
   jest testowana i przygotowywane są pakiety, które zostaną później
   skompilowane na wszystkie stabilne architektury i umieszczone na
   serwerach. Po dokonaniu powyższych kroków wydawana jest informacja
   nt. bezpieczeństwa dotycząca danego pakietu.</p>

<toc-add-entry name=oldversion>Dlaczego trzymacie się starej wersji danego
   pakietu?</toc-add-entry>

<p>Najważniejszą zasadą podczas tworzenia nowej wersji pakietu rozwiązującej
   dany problem bezpieczeństwa jest dokonanie jak najmniejszej ilości zmian.
   Nasi użytkownicy i deweloperzy oczekują niezmiennego zachowania się pakietu
   po jego wydaniu, więc każda zmiana może zniszczyć czyjś system.
   Ma to miejsce szczególnie w przypadku bibliotek: niezależnie od tego, 
   jak mała jest zmiana należy się upewnić, że nie zmienia się Application 
   Program Interface (API) lub Application Binary Interface (ABI).</p>

<p>To oznacza, że przejście na najnowszą wersję nie jest dobrym rozwiązaniem.
   Zamiast tego, odpowiednie zmiany są nanoszone na starsze wersje znajdujące
   się w dystrybucji stabilnej. Zazwyczaj autorzy programu są chętni do pomocy,
   jeśli zachodzi taka potrzeba. Grupa ds. bezpieczeństwa również może być
   w stanie pomóc.</p>

<p>W niektórych przypadkach nie jest możliwe naniesienie łatki na starszą
   wersję. Jest tak wtedy, gdy wymagałoby to przepisania lub zmodyfikowania
   dużej ilości kodu. W takim przypadku może być konieczne przejście na
   najnowszą wersję, ale musi to być zrobione we współpracy z grupą ds.
   bezpieczeństwa.</p>

<toc-add-entry name=policy>Kiedy dany pakiet pojawi się na
   security.debian.org?</toc-add-entry>

   <p>A: Naruszenie bezpieczeństwa w dystrybucji stabilnej sprawia, że
   pakiet z poprawką pojawia się na security.debian.org. Żaden inny 
   powód nie wchodzi w grę. Rozmiar naruszenia bezpieczeństwa nie stanowi 
   tutaj problemu. Zazwyczaj grupa ds. bezpieczeństwa przygotowuje pakiety 
   razem z opiekunami pakietów. Pakiet znajdzie się na security.debian.org
   pod warunkiem, że ktoś (zaufany) rozwiąże problem, skompiluje
   wszystkie wymagane pakiety i wyśle je do grupy ds. bezpieczeństwa. 
   Nawet najbardziej oczywiste poprawki są ważne.</p>

<p>Uaktualnienia bezpieczeństwa służą jednemu: dostarczeniu poprawki dla
   problemu bezpieczeństwa. Nie są one sposobem na przemycenie dodatkowych
   zmian do wydania stabilnego bez przejścia przez normalną procedurę
   wydawniczą.</p>

<toc-add-entry name=localremote>Co oznacza <q>local (remote)</q>?</toc-add-entry>
<p>A: Zgłoszenia opisujące luki, których sposób wykorzystania nie można określić 
   jednoznacznie wg schematu lokalny czy zdalny. Z niektórych błędów nie da się 
   skorzystać zdalnie, np. nie są one powiązane z demonem nasłuchującym 
   na danym porcie. Jeżeli jednak można je wykorzystać poprzez specjalny plik 
   dostarczony przez sieć w przypadku gdy podatna usługa nie jest stale podłączona 
   do sieci, w takim przypadku piszemy <q>local (remote)</q>.</p>

<p>Tego typu luki znajdują się gdzieś pomiędzy lukami lokalnymi a zdalnymi. 
   Często dotyczą one np. załączników, które można przesłać przez sieć, np. 
   załącznik do wiadomości pocztowej lub archiwum pobrane ze strony internetowej.</p>

<toc-add-entry name=version>Numer wersji pakietu wskazuje na to, że nadal
   posiadam podatną na błędy wersję!</toc-add-entry>
<p>A: Zamiast uaktualniać pakiet do najnowszej wersji, nanosimy poprawki
   do wersji pakietu, która została dostarczona razem z dystrybucją stabilną.
   Powodem takiego działania jest zapewnienie, by wydana dystrybucja zmieniła
   się w jak najmniejszym stopniu, dzięki czemu nic się niespodziewanie nie
   zmieni czy też przestanie działać w wyniku zaaplikowania łatki.
   Możesz sprawdzić, czy posiadasz bezpieczną wersję pakietu przez przejrzenie
   pliku zmian danego pakietu lub porównując jego dokładną wersję z wersją
   podaną w informacji Debiana na temat bezpieczeństwa danego pakietu.</p>

<toc-add-entry name=archismissing>Otrzymłem powiadomienie dotyczące bezpieczeństwa, 
   ale brakuje zbudowanej paczki dla jednej architektury.</toc-add-entry>
<p>A: Zazwyczaj Zespół ds. Bezpieczeństwa wydaje informację z poprawionymi 
   pakietami dla wszystkich wspieranych przez Debiana architektur. Jednak niektóre 
   z nich są wolniejsze od pozostałych i może się zdarzyć, że poprawiony pakiet 
   jest dostępny tylko dla części architektur. Mniej popularne architektury 
   reprezentują niewielki ułamek naszych użytkowników. W zależności od potrzeb 
   wydawniczych możemy zdecydować o natychmiastowej publikacji powiadomienia. 
   Brakujące pakiety będą udostępnione jak tylko będą dostępne, ale nie będzie 
   osobnego powiadomienia o tym fakcie. Oczywiście nigdy nie wydajemy powiadomień 
   jeżeli nie są dostępne pakiety dla architektur i386 oraz amd64.</p>
   
<toc-add-entry name=unstable>Jak obsługiwane są sprawy związane z bezpieczeństwem w edycji <tt>unstable</tt>?</toc-add-entry>
<p>A: Sprawy związane z bezpieczeństwem w edycji niestabilnej (unstable) 
   są obsługiwane głównie przez opiekunów pakietów, a nie przez Zespół ds. 
   Bezpieczeństwa Debiana. Mimo że członkowie zespołu mogą wysyłać poprawki
   dotyczące bezpieczeństwa, gdy zauważą brak aktywności ze strony opiekunów, 
   wsparcie dla edycji stabilnej będzie zawsze na pierwszym miejscu. Jeżeli 
   potrzebny jest bezpieczny (i stabilny) serwer, mocno zachęcamy do 
   pozostania przy edycji stabilnej.</p>
   
<toc-add-entry name=testing>Jak obsługiwane są sprawy związane z 
bezpieczeństwem w edycji <tt>testing</tt>?</toc-add-entry>
<p>A: Edycja testowa, jeżeli chodzi o sprawy związane z bezpieczeństem, 
   korzysta z całego projektu dla edycji niestabilnej. Jednak występuje 
   tutaj minimum dwudniowy poślizg przy migracji, a czasami poprawki 
   mogą być wstrzymane przy przejściu pakietu do edycji testowej. 
   Zespół ds. Bezpieczeństwa stara się obsłużyć takie wstrzymane migracje, 
   aby wysłane poprawki przeszły do edycji testowej, ale nie zawsze 
   jest to możliwe i mogą pojawić się opóźnienia w migracji. Zwłaszcza 
   miesiące po wydaniu nowej edycji stabilnej, kiedy to wiele nowych 
   wersji zostało wysłanych do edycji niestabilnej, poprawki bezpieczeństwa 
   do edycji testowej mogą pozostać w tyle. Jeżeli potrzebny jest bezpieczny 
   (i stabilny) serwer, mocno zachęcamy do pozostania przy edycji stabilnej.</p>


   
<toc-add-entry name=contrib>Jak obsługiwane są sprawy związane z bezpieczeństwem 
w <tt>contrib</tt> i <tt>non-free</tt>?</toc-add-entry>
<p>A: Odpowiedź jest krótka: nie są obsługiwane. Contrib i non-free nie są
   oficjalnymi częściami dystrybucji Debiana, nie są one wydawane i z tego powodu
   nie są obsługiwane przez grupę ds. bezpieczeństwa. Niektóre pakiety non-free
   są dystrybuowane bez źródeł lub licencji zezwalającej na dystrybucję
   zmodyfikowanych wersji. W takich przypadkach nie ma nawet możliwości, by
   pisać poprawki bezpieczeństwa. Jeżeli jest możliwe naprawienie błędu, a opiekun 
   pakietu lub ktoś inny dostarczy odpowiednio zaktualizowane pakiety, 
   wtedy zespół ds. bezpieczeństwa zajmie się tym i wyda odpowiednie zalecenia.</p>

<toc-add-entry name=sidversionisold>W zaleceniach jest informacja, że w 
unstable błąd został poprawiony w wersji 1.2.3-1, ale w unstable jest wersja 
1.2.5-1, dlaczego?</toc-add-entry>

<p>A: Staramy się podać pierwszą wersję w unstable, która ma poprawiony dany 
   błąd. Czasami, w międzyczasie, opiekun zamieści nowszą wersję. Należy 
   porównać wersję z unstable z wersją podaną przez zespół. Jeżeli jest ona 
   taka sama lub wyższa, wtedy program jest wolny od podanego błędu.</p>

<toc-add-entry name=mirror>Dlaczego nie ma oficjalnych serwerów lustrzanych
   security.debian.org?</toc-add-entry>

<p>A: Prawdę mówiąc są. Istnieje kilka oficjalnych serwerów lustrzanych, 
   skonfigurowanych poprzez aliasy DNS. Celem security.debian.org jest 
   dostarczenie poprawek bezpieczeństwa tak szybko i prosto jak to tylko 
   jest możliwe. </p>

<p>Zachęcanie do używania nieoficjalnych serwerów lustrzanych 
   skomplikowałoby sprawę, co zazwyczaj nie jest potrzebne, a mogłoby 
   powodować frustrację w przypadku, gdyby serwery lustrzane nie były 
   aktualne.</p>

<toc-add-entry name=missing>Widziałem DSA 100 i DSA 102, a gdzie się podziało
   DSA 101?</toc-add-entry>
<p>A: Wielu dystrybutorów (głównie GNU/Linux, ale też pochodne BSD)
   koordynuje informacje na temat bezpieczeństwa dla pewnych zagrożeń
   i ustalają pewien przedział czasowy, aby wszyscy dostawcy mogli
   wydać te informacje w jednym czasie. Umówiono się tak, aby nie dyskryminować
   dostawców, którzy potrzebują więcej czasu (np. gdy dostawca musi
   przeprowadzić pakiety przez długi proces testów QA lub obsługuje
   wiele architektur czy binarnych dystrybucji). Nasza grupa ds. bezpieczeństwa
   również przygotowuje zawczasu informacje na temat bezpieczeństwa.
   Czasami inne zdarzenie muszą być obsłużone zanim te informacje
   zostaną wydane. Stąd zdarzają się luki w numerach informacji.</p>

<toc-add-entry name=contact>W jaki sposób mogę się skontaktować z grupą ds. bezpieczeństwa?</toc-add-entry>

<p>A: Informacje na temat bezpieczeństwa mogą być wysyłane na adres
   security@debian.org, lub na team@security.debian.org. Obie listy dyskusyjne
   są czytane przez członków grupy ds. bezpieczeństwa.
</p>

<p>Jeśli jest taka potrzeba, list może być zaszyfrowany przy użyciu klucza 
   Debian Security Contact (key ID <a
   href="http://pgp.surfnet.nl/pks/lookup?op=vindex&amp;search=0x0D59D2B15144766A14D241C66BAF400B05C3E651">\
   0x0D59D2B15144766A14D241C66BAF400B05C3E651</a>). Klucze PGP/GPG poszczególnych członków grupy są dostępne 
   na serwerze <a href="https://keyring.debian.org/">keyring.debian.org</a>.</p>

<toc-add-entry name=discover>Wydaje mi się, że znalazłem problem związany 
   z bezpieczeństwem. Co mam robić?</toc-add-entry>

<p>A: Jeśli wiesz o istnieniu problemu związanego z bezpieczeństwem w dowolnym pakiecie
   zawsze skontaktuj się z odpowiednią grupą ds. bezpieczeństwa. Jeśli
   debianowa grupa potwierdzi podatność na dany błąd, i wydaje się, że
   inni dostawcy też mogą być nim dotknięci, grupa kontaktuje się
   z tymi dostawcami. Jeśli znaleziony błąd nie został jeszcze upubliczniony,
   grupa ds. bezpieczeństwa stara się skoordynować informacje na temat
   bezpieczeństwa z innymi dostawcami, by wszystkie znaczące dystrybucje
   wydały je w tym samym czasie.</p>

<p>Jeżeli znaleziony błąd został już upubliczniony, prosimy o przesłanie 
   raportu do Debian BTS i oznaczenie go tagiem <q>security</q>.</p>

<p>Jeśli jesteś deweloperem Debiana, <a href="#care">patrz niżej</a>.</p>

<toc-add-entry name=care>Co powinienem zrobić z problemem dotyczącym 
   bezpieczeństwa w jednym z moich pakietów?</toc-add-entry>

<p>A: Jeśli dowiesz się o problemie dotyczącym bezpieczeństwa w pakiecie Twoim lub 
   innej osoby zawsze skontaktuj się z grupą ds. bezpieczeństwa,  
   dostępną pod adresem team@security.debian.org. Grupa śledzi
   zaległe problemy bezpieczeństwa, może pomóc opiekunom z problemami lub
   też sama naprawi dany problem. Grupa jest też odpowiedzialna za
   wysyłanie informacji na temat bezpieczeństwa i zarządzanie
   security.debian.org.</p>
   
<p><a href="$(DOC)/developers-reference/pkgs.html#bug-security">\
   Developer's Reference</a> zawiera kompletne instrukcje co i jak 
   w takim przypadku robić.</p>

<p>Ważne jest, żebyś nie umieszczał pakietu w innej dystrybucji niż
   niestabilna bez wcześniejszej zgody grupy ds. bezpieczeństwa, ponieważ
   ominięcie jej spowoduje zamieszanie i więcej pracy.</p>

<toc-add-entry name=enofile>Próbowałem ściągnąć pakiet podany w jednej
   z informacji nt. bezpieczeństwa, ale otrzymałem błąd 
   <q>plik nie odnaleziony</q>.</toc-add-entry>

<p>A: Gdy tylko nowa wersja pakietu zastępuje starszą na security.debian.org,
   zazwyczaj stary pakiet jest usuwany zanim nowy zostaje tam umieszczony.
   Stąd ten błąd. Nie chcemy dystrybuować pakietów ze znanymi błędami
   bezpieczeństwa dłużej niż jest to wymagane.</p>

<p>Używaj pakietów z najnowszych informacji nt. bezpieczeństwa,
   które są rozsyłane za pomocą listy dyskusyjnej <a
   href="https://lists.debian.org/debian-security-announce/">\
   debian-security-announce</a>. Najlepiej uruchomić
   <code>apt-get update</code> przed aktualizacją pakietu.</p>

<toc-add-entry name=upload>Posiadam łatkę, czy mogę umieścić ją bezpośrednio na
   security.debian.org?</toc-add-entry>

<p>A:  Nie, nie możesz. Archiwum na security.debian.org jest zarządzane przez
   grupę ds. bezpieczeństwa, która musi zatwierdzić wszystkie pakiety. 
   Zamiast tego powinieneś wysyłać łatki lub odpowiednie pakiety źródłowe 
   do grupy ds. bezpieczeństwa na adres team@security.debina.org. 
   Przesłane pliki zostaną przejrzane i 
   prawdopodobnie umieszczone na serwerze z pewnymi zmianami lub bez.</p>

<p><a href="$(DOC)/developers-reference/pkgs.html#bug-security">\
   Developer's Reference</a> zawiera kompletne instrukcje co i jak 
   w takim przypadku robić.</p>

<toc-add-entry name=ppu>Posiadam łatkę, czy mogę w takim razie umieścić ją
   w katalogu proposed-updates?</toc-add-entry>

<p>A: Technicznie możesz, ale nie powinieneś, ponieważ kłóci się to z pracą
   grupy ds. bezpieczeństwa. Pakiety z security.debian.org są automatycznie
   kopiowane do katalogu proposed-updates. Jeśli pakiet z tym samym lub wyższym
   numerem wersji znajduje się już w tym archiwum, uaktualnienie bezpieczeństwa
   zostanie odrzucone przez system obsługi archiwum. W ten sposób dystrybucja
   stabilna zostaje pozbawiona uaktualnienia bezpieczeństwa dla tego pakietu,
   chyba że "zły" pakiet zostanie odrzucony z katalogu proposed-updates.
   Dlatego zamiast powyższego, skontaktuj się z grupą ds. bezpieczeństwa
   i dołącz wszelkie szczegóły dotyczące błędu lub dziury w bezpieczeństwie. 
   Do listu dołącz również pliki źródłowe (tj. pliki diff.gz i dsc).</p>

<p><a href="$(DOC)/developers-reference/pkgs.html#bug-security">\
   Developer's Reference</a> zawiera kompletne instrukcje co i jak 
   w takim przypadku robić.</p>

<toc-add-entry name=SecurityUploadQueue>Jestem pewien, że moje pakiety są
   w porządku. Jak mogę je umieścić na serwerze?</toc-add-entry>

<p>A: Jeśli jesteś całkowicie pewien, że Twoje pakiety niczego nie zepsują,
   że nadany numer wersji jest rozsądny (tj. większy od wersji
   w dystrybucji stabilnej i mniejszy niż w dystrybucji testowej/niestabilnej),
   że nie zmieniłeś zachowania się pakietu, poza częścią związaną z problemem
   bezpieczeństwa, że skompilowałeś go dla odpowiedniej dystrybucji
   (tj. dla <code>oldstable-security</code> lub <code>stable-security</code>),
   że pakiet zawiera oryginalne źródła w przypadku gdy jest on nowy na
   security.debian.org, że możesz stwierdzić, że łatka względem najnowszej
   wersji pakietu jest poprawna i zmienia tylko dany problem z bezpieczeństwem
   (sprawdź to przy użyciu <code>interdiff -z</code> i dwóch plików
   <code>.diff.gz</code>), że sprawdziłeś łatkę przynajmniej trzy razy
   oraz że <code>debdiff</code> nie znajduje żadnych zmian, to wtedy możesz
   umieścić pliki bezpośrednio w katalogu incoming w
   <code>ftp://ftp.security.upload.debian.org/pub/SecurityUploadQueue</code> na serwerze
   security.debian.org. Wyślij również zawiadomienie ze wszystkimi szczegółami
   i odnośnikami na adres team@security.debian.org.</p>

<toc-add-entry name=help>W jaki sposób mogę pomóc przy obsłudze
   bezpieczeństwa?</toc-add-entry>
<p>A: Przyjrzyj się dobrze każdemu problemowi przed jego zgłoszeniem
   na security@debian.org. Jeśli jesteś w stanie dostarczyć łatki, to znacznie
   to przyspieszy cały proces. Nie przekazuj po prostu listów z bugtraq,
   ponieważ my też je otrzymaliśmy &mdash; ale za to wysyłaj nam dodatkowe
   informacje o zgłoszonych na bugtraq problemach.</p>

<p>Dobrym sposobem na rozpoczęcie prac związanych z bezpieczeństem jest 
   pomoc przy Debian Security Tracker (<a
   href="https://security-tracker.debian.org/tracker/data/report">instrukcje</a>).</p>

<toc-add-entry name=proposed-updates>Jaki jest zakres proposed-updates?</toc-add-entry>
<p>A: Ten katalog zawiera pakiety, które mają wejść do następnej rewizji
   dystrybucji stabilnej. Za każdym razem, gdy opiekun umieszcza na serwerze
   pakiety dla dystrybucji stabilnej, lądują one w katalogu proposed-updates.
   Ponieważ dystrybucja stabilna ma być stabilna, nie ma żadnych automatycznych
   uaktualnień. Grupa ds. bezpieczeństwa umieści na serwerze poprawione pakiety
   wspomniane w informacjach nt. bezpieczeństwa dla dystrybucji stabilnej,
   ale najpierw znajdą się one w katalogu proposed-updates. Co kilka miesięcy
   Menedżer Wydań Stabilnych sprawdza listę pakietów w katalogu
   proposed-updates i decyduje czy pakiet nadaje się do dystrybucji stabilnej
   czy nie. Są one zestawiane w następną rewizję stabilną (np. 2.2r3 czy 2.2r4).
   Pakiety, które nie pasują, prawdopodobnie będę odrzucone i usunięte
   w katalogu proposed-updates.
</p>

<p>Zauważ, że pakiety umieszczone przez opiekunów (a nie przez grupę
   ds. bezpieczeństwa) w proposed-updates/ nie są obsługiwane przez
   grupę ds. bezpieczeństwa.</p>

<toc-add-entry name=composing>W jaki sposób jest formowana grupa ds.
   bezpieczeństwa?</toc-add-entry>
<p>A: W grupach ds. bezpieczeństwa Debiana znajduje się
   <a href="../intro/organization">kilku oficerów i sekretarzy</a>.
   Sama grupa ds. bezpieczeństwa powołuje ludzi do wstąpienia do grupy.</p>

<toc-add-entry name=lifespan>Jak długo będą dostarczane poprawki związane z 
bezpieczeństwem?</toc-add-entry>
<p>A: Grupa ds. bezpieczeństwa stara się dostarczać poprawki do stabilnej
   dystrybucji przez rok po wydaniu następnej, poza sytuacjami gdy inna
   dystrybucja jest wydana w tym samym roku. Jest praktycznie niemożliwe,
   by dostarczać poprawki dla trzech dystrybucji; obsługa dwóch
   jednocześnie jest już wystarczająco trudna.
</p>

<toc-add-entry name=check>Jak mogę sprawdzić integralność pakietów?
</toc-add-entry>
<p>A: Proces ten wymaga porównania sygnatury pliku Release 
   z <a href="https://ftp-master.debian.org/keys.html">\
   kluczem publicznym</a> użytym do archiwizacji. Plik Release zawiera 
   sumy kontrolne do plików Packages and Sources, które zawierają sumy 
   kontrolne plików binarnych i źródeł. Szczegółowe informacje o tym jak 
   sprawdzić integralność pakietów można znaleźć na stronie 
   <a
   href="$(HOME)/doc/manuals/securing-debian-howto/ch7#s-deb-pack-sign">\
   Debian Securing Manual</a>.</p>

<toc-add-entry name=break>Co mam zrobić jeżeli jakiś inny pakiet przestał
działać poprawnie po zainstalowaniu poprawek bezpieczeństwa?</toc-add-entry>
<p>A: Po pierwsze należy sprawdzić dlaczego pakiet jest uszkodzony i jaki to ma 
   związek z aktualizacją dotyczącą bezpieczeństwa. Następnie należy 
   skontaktować się z grupą ds. bezpieczeństwa (jeżeli jest to poważny problem),
   lub z menedżerem wydań stabilnych (jeżeli jest to mniej ważny problem). 
   Mówimy tutaj o różnych pakietach, które przestały działać po zainstalowaniu 
   aktualizacji dotyczącej bezpieczeństwa innego pakietu. Jeżeli nie wiesz co
   poszło źle, ale masz rozwiązanie - również skontaktuj się z
   grupą ds. bezpieczeństwa. Możesz zostać przekierowany do menedżera wydania
   stabilnego. </p>

<toc-add-entry name=cvewhat>Czym jest identyfikator CVE?</toc-add-entry>
<p>A: Projekt "The Common Vulnerabilities and Exposures" przypisuje unikalne
   nazwy, zwane identyfikatorami CVE, do konkretnych błędów związanych z 
   bezpieczeństwem, aby ułatwić jednoznaczne odniesienie się to konkretnego 
   błędu. Więcej informacji znajduje się na stronie <a 
   href="https://en.wikipedia.org/wiki/Common_Vulnerabilities_and_Exposures">\
   Wikipedii</a>.</p>

<toc-add-entry name=cvedsa>Czy Debian wydaje komunikaty DSA dla każdego wpisu CVE?
</toc-add-entry>

<p>A: Zespół ds. Bezpieczeństwa Debiana śledzi wszystkie wpisy CVE, sprawdza 
   czy są one powiązane z pakietami i szacuje ich wpływ w kontekście Debiana - 
   fakt, że jakiejś sprawie został przypisany identyfikator CVE nie musi 
   oznaczać, że dany problem jest poważnym zagrożeniem w systemie Debian. 
   Informacje są śledzone przy użyciu 
   <a href="https://security-tracker.debian.org">Debian Security Tracker</a>,
   a dla problemów, które zostaną uznane za poważne, zostanie wydany
   odpowiedni komunikat DSA (Debian Security Advisory).</p>

<p>Problemy o niskiej ważności, które nie kwalifikują się do ogłoszenia 
   DSA, mogą być poprawione w następnym wydaniu Debiana, w następnej 
   aktualizacji bieżącej stabilnej lub przestarzałej dystrybucji lub 
   być włączone do DSA, kiedy zostanie ono opublikowane dla poważniejszych 
   zgłoszeń.</p>

<toc-add-entry name=cveget>Czy Debian może tworzyć identyfikatory CVE?</toc-add-entry>
<p>A: Ponieważ Debian ma status CVE Numbering Authority, może tworzyć 
   identyfikatory które, zgodnie z plityką CVE, mogą dotyczyć tylko błędów 
   jeszcze nieznanych. Aby otrzymać identyfikator do nieopisanego jeszcze 
   błędu w oprogramowaniu w Debianie, należy skontaktować się z Zespołem 
   ds. Bezpieczeństwa Debiana. W przypadku, gdy dany błąd został już 
   opublikowany, zalecamy skorzystać z procedury opisanej w <a
   href="https://github.com/RedHatProductSecurity/CVE-HOWTO">\
   CVE OpenSource Request HOWTO</a>.</p>