Megjegyzés: Az eredeti oldalt a legutóbbi fordítás óta módosították.
Mostanában kissé túl gyakran teszik fel nekünk az alábbi kérdéseket, úgyhogy itt foglaljuk össze a rájuk adott válaszokat.
local (remote)[helyi (távoli)]?
file not foundüzenetet kaptam.
K: A megszüntetett biztonsági hibákról szóló jelentésekhez tartozó aláírás nem érvényes!
V: Általában a te oldaladon van a hiba. A debian-security-announce listához egy szűrő is tartozik, ami csak azokat az üzeneteket engedi be, amik a biztonsági csoport valamelyik tagjának érvényes aláírásával rendelkeznek.
Leggyakrabban az a probléma, hogy a levelezőprogramod egy kicsit megváltoztatja az üzenetet, ami tönkreteszi az aláírást. Győződj meg arról, hogy a levelezőprogram nem csinál MIME-kódolást vagy -dekódolást, illetve tab/szóköz konverziót.
Az ismert bűnösök a fetchmail (bekapcsolt mimedecode opcióval), a formail (csak a procmail 3.14-től fölfelé) és az evolution.
K: Hogyan kezeli a biztonsági kérdéseket a Debian?
V: Amint a biztonsági csoport bejelentést kap egy esetről, egy vagy több tag megvizsgálja és megállapítja, hogy milyen hatással van a stabil Debian kiadásra (azaz, hogy biztonsági rés-e vagy nem). Ha a rendszerünk biztonsági rést tartalmaz, akkor dolgozunk a probléma megoldásán. Kapcsolatba lépünk a csomag karbantartójával is, ha még nem kereste a biztonsági csoportot. Végül a javítást teszteljük és elkészítjük az új csomagokat, amiket aztán lefordítunk és feltöltünk minden stabil architektúrára. Ha mindez megtörtént, egy jelentést teszünk közzé az elhárított biztonsági hibáról.
K: Minek vacakoltok ugyanannak a csomagnak a régebbi kiadásaival?
V: Az olyan új csomagok elkészítésekor, amikben egy biztonsági hibát javítunk ki, a legfontosabb vezérelv, hogy a lehető legkevesebbet változtassunk az eredeti csomagon. A felhasználóink és a fejlesztőink a meglévő kiadások már ismert viselkedésére támaszkodnak, így bármilyen változtatástól összeomolhat a rendszerük. Ez különösen igaz a programkönyvtárak esetén: mindig győződj meg róla, hogy nem változtatod meg a forrás szintű alkalmazásinterfészt (Application Program Interface; API) vagy a bináris szintű alkalmazásinterfészt (Application Binary Interface; ABI), akármilyen jelentéktelen is a változtatás.
Ez azt jelenti, hogy egy új, megváltozott viselkedésű verzióra való váltás nem jó megoldás, hanem a lényeges változtatásokat visszamenőleg is meg kell csinálni. Általában az új kiadások karbantartói segítenek ebben, ha a Debian biztonsági csoport tagjai nem tudnak.
Előfordul, hogy a biztonsági hiba javítása valamiért nem kerülhet bele a régebbi verziókba, például amikor túl sok forráskódot kéne megváltoztatni vagy újraírni. Ilyenkor át lehet térni új, megváltozott viselkedésű verzióra, de ezt előzőleg a biztonsági csoporttal egyeztetni kell.
K: Milyen módon jelenhet meg egy kijavított csomag a security.debian.org-on?
V: Ha egy stabil disztribúcióban valamilyen biztonsági hiba van, akkor mindenképpen megjelenik egy csomag a securty.debian.org-on. Semmilyen más esetben nem. Itt nem a biztonsági rés mérete a valódi probléma. Általában a biztonsági csoport a csomag karbantartójával együtt készíti el az új csomagot. Ha viszont valaki (akit megbízhatónak találunk) kijavít egy hibát, újrafordítja az összes szükséges csomagot és továbbítja a biztonsági csoport valamelyik tagjának, akkor ez még akkor is felkerül a security.debian.org-ra, ha a javítás egészen egyszerű. Erről bővebben alább még olvashatsz.
A biztonsági javítások egyetlen célt szolgálnak: megszüntetik a biztonsági hibákat. Nem azért vannak, hogy további változtatásokat lopjanak be a stabil kiadásba anélkül, hogy végigmennének a rendes részkiadási procedúrán.
K: Mit jelent a local (remote)
[helyi (távoli)]?
V: bizonyos tanácsadók nem hozzák nyilvánosságra azokat a biztonsági hibákat,
amik nem illenek a megszokott helyi és távoli kihasználhatóság
sémájába. Vannak olyan hibák, amiket távolról nem lehet kihasználni,
például nem kapcsolódnak hálózati portot figyelő démonhoz. Ha a hibát
olyan speciális fájlok segítségével lehet kihasználni, amik hálózaton
keresztül is a rendszerbe kerülhetnek, de a biztonsági hibát
tartalmazó szolgáltatás nem kapcsolódik állandóan a hálózathoz, akkor
használjuk a local (remote)
[helyi (távoli)] kifejezést.
Az olyan biztonsági hibák, amik valahol félúton vannak a távoli és a helyi között, sokszor olyan archív fájlok, amihez a hálózat segítségével lehet hozzáférni, például levelek csatolmányaként, vagy egy letöltési oldalról.
K: A csomag verziószáma azt mutatja, hogy még mindig biztonsági hibát tartalmazó verziót használok!
V: Ahelyett, hogy új kiadást készítenénk, inkább kijavítjuk a megtalált hibákat azokban a csomagokban, amik bekerültek a stabil kiadásba. Ennek az az oka, hogy szeretnénk elérni azt, hogy a meglévő kiadásokban minél kevesebb dolog változzon, így a dolgok nem fognak megváltozni vagy elromlani attól, hogy egy biztonsági hibát elhárítottunk. Arról, hogy biztonságos verziót futtatsz-e egy csomagból, úgy győződhetsz meg, hogy megnézed a csomag changelogját vagy összehasonlítod a verziószámát a Debian Biztonsági Ajánlásokban (Debian Security Advisory) megadott számmal.
K: Hogy kezelik a biztonság kérdését az unstable disztribúcióban?
V: A rövid válasz ennyi: sehogy. Az unstable gyorsan változik, így a biztonsági csoportnak nincs elég erőforrása, hogy megfelelő támogatást nyújtson hozzájuk. Ha biztonságos (és stabil) szervert szeretnél, akkor erősen ajánljuk, hogy maradj a stable disztribúciónál.
K: Hogy kezelik a biztonság kérdését a testing disztribúcióban?
V: Ha biztonságos (és stabil) szervert szeretnél, akkor erősen ajánljuk,
hogy maradj a stable disztribúciónál. Azonban a testing is rendelkezik
némi biztonsági támogatással: A Debian testing biztonsági csoport kezeli
a nyilvánosságra került problémákat, és biztosítja, hogy a javított
csomagok bekerüljenek a testingbe a szokásos módon, vagy ha az túl hosszú
időt jelent, elérhetővé tegye a bevett http://security.debian.org
infrastruktúrán keresztül. A használatához az alábbi sorra van szükség
a /etc/apt/sources.list fájlban:
deb http://security.debian.org testing/updates main
és futtasd le a szokásos
apt-get update && apt-get upgrade
parancsot.
Megjegyeznénk, hogy ez nem garantálja, hogy minden ismert biztonsági hiba javításra kerül a testingben! Némely javított csomag várakozhat a testingbe kerülése előtt, illetve azokat a hibákat, amelyek nem kerültek nyilvánosságra, a testing biztonsági csoportja sem ismeri. A testing biztonsági infrastruktúrájáról a http://secure-testing-master.debian.net/ címen olvashatsz.
K: Hogyan kerülnek a biztonsági frissítések a testing disztribúcióba?
V: A biztonsági frissítések az unstable disztribúcióból kerülnek a testing disztribúcióba. Általában magasra állítjuk a prioritásukat, mivel így a karanténban töltött idő két napra csökken. Ezután a csomagok automatikusan a testing disztribúcióba kerülnek, feltéve, hogy minden szükséges architektúrára elkészítették őket és a függőségeik is teljesülnek.
A testing biztonsági csoport tagjai elérhetővé teszik a biztonsági frissítéseket a http://security.debian.org webhelyen is, ha a szokásos migrációs eljárás nem lenne elég gyors.
K: Hogyan kezelik a biztonság kérdését a contrib és a non-free csomagokban?
V: A rövid válasz ennyi: sehogy. A contrib és a non-free csomagok nem részei a hivatalos Debian disztribúciónak és nem kapcsolódnak kiadásokhoz, így a biztonsági csoport nem támogatja őket. Egyes non-free csomagok csak forráskód nélkül vagy a módosításra való engedély nélkül terjeszthetők. Ezekben az esetekben nem tudjuk a biztonsági hibákat kijavítani. Amennyiben mégis lehetséges a hiba javítása, és a csomagkarbantartó vagy valaki más elkészíti, akkor a biztonsági csoport általában feldolgozza, és jelentést tesz közzé.
K: Miért nincsenek a security.debian.org-nak hivatalos tükrei?
V: Valójában vannak. Számos hivatalos tükör létezik, amelyek DNS-aliasokkal működnek. A security.debian.org célja, hogy a biztonsági frissítéseket olyan gyorsan és könnyen elérhetővé tegye, amennyire lehetséges.
A nemhivatalos tükrözések támogatása bonyolultabbá tenné a rendszert, és elégedetlenséget okozna az, ha ezek a tükrözések nem lennének naprakészek. Tervezzük azonban, hogy a hivatalos tükrözéseket megvalósítjuk a jövőben.
K: Találkoztam már DSA 100-zal és DSA 102-vel. Hova lett a DSA 101?
V: Számos terjesztő (főleg GNU/Linux terjesztők, de a BSD-leszármazottakéi is) valamilyen eseményhez köti a biztonsági ajánlásokat és egy pontos időkorlátot szab, így minden terjesztő egy időben adhatja ki az egyes ajánlásokat. Azért határoztak így, hogy ne kerüljenek hátrányba azok a terjesztők, akiknek több időre van szükségük (pl. amikor a terjesztőnek minőségbiztosítási ellenőrzést kell végeznie a csomagokkal, vagy több architektúrát vagy bináris disztribúciót kell támogatnia). A saját biztonsági csoportunk is előre elkészíti az ajánlásokat. Időnként egyéb biztonsági kérdésekkel kell foglalkozni, mielőtt a várakozó biztonsági ajánlásokat kiadhatnánk, így ideiglenesen kihagyjuk egy vagy több ajánlás sorszámát.
K: Hogyan érhetem el a biztonsági csoportot?
V: A biztonsággal kapcsolatos információkat a security@debian.org vagy a team@security.debian.org címre lehet küldeni, mindkettőt olvassák a biztonsági csoport tagjai.
Ha valamilyen kényesebb információd van, kérjük, csak a biztonsági csoporttal vedd fel a kapcsolatot a team@security.debian.org címen.
Ha szükséges, a levél titkosítható a Debian Biztonsági Kapcsolat kulccsal (kulcs ID 0xF2E861A3). Lásd még a biztonsági csoport PGP/GPG-kulcsait.
K: Azt hiszem, egy biztonsági hibára akadtam. Mit kellene tennem?
V: Ha biztonsági hibát találsz akár a saját csomagjaidban, akár valaki máséban, kérjük, mindig lépj kapcsolatba a biztonsági csoporttal. Ha a biztonsági csoport megerősíti a sebezhetőséget és ez érinthet más terjesztőket is, akkor általában kapcsolatba lépnek velük is. Ha a biztonsági hiba még nem ismert, akkor megpróbálják egyeztetni a biztonsági ajánlásokat más terjesztőkkel, így minden főbb kiadás szinkronizálva lesz.
Ha a sebezhetőség már közismert, akkor mindenképp tegyél hibabejelentést
a Debian BTS-ben, security
címkével ellátva.
Ha Debian-karbantartó vagy, lásd lejjebb.
K: Mit kell csinálnom, ha biztonsági hiba van valamelyik csomagomban?
V: Ha biztonsági hibát találsz akár egy saját csomagodban, akár valaki máséban, kérjük mindig lépj kapcsolatba a biztonsági csoporttal. E-mailen keresztül a team@security.debian.org címen érhetők el. Követik a kiemelkedő biztonsági problémákat, segíteni tudnak a karbantartóknak, hogy önállóan kijavítsák a biztonsági hibákat, és ők felelősek a biztonsági ajánlások elküldéséért és karbantartásáért a security.debian.org-on.
A Fejlesztői referencia teljes útmutatást ad.
Különösen fontos, hogy ne tölts fel csomagokat az unstable-n kívül más disztribúcióba a biztonsági csoport előzetes beleegyezése nélkül, mert ez zűrzavart okoz, és még több munkát igényel.
V: Amikor egy újabb hibajavítás hatástalanít egy régebbi csomagot a
security.debian.org-on, nagy az esélye annak, hogy a régi
csomagot eltávolítjuk, amikor az újat felrakjuk. Ezért kaphatsz
file not found
hibaüzenetet. Nem akarunk olyan csomagokat
terjeszteni, amikben ismert biztonsági hiba van, ha nem
feltétlenül szükséges.
Kérjük, a legújabb biztonsági ajánlásban megadott csomagokat
használd, amik a debian-security-announce levelezési listán érhetők el. A
legjobb, ha egyszerűen az apt-get update parancsot
futtatod, mielőtt frissíted a csomagot.
K: Kijavítottam egy hibát, küldhetem egyből a security.debian.org-ra?
V: Nem. A security.debian.org-ot a biztonsági csoport tartja karban, aminek minden csomagot jóvá kell hagynia. A javításokat vagy a megfelelő forráscsomagokat a biztonsági csoportnak kell elküldeni a team@security.debian.org címre. A biztonsági csoport ellenőrizni fogja őket, végül feltölti őket módosítva vagy anélkül.
Ha nem szoktál biztonsági feltöltéseket csinálni, és nem vagy 100%-ig biztos abban, hogy a csomagod megbízható, akkor ezt a módszert használd, ne a bejövő könyvtárba töltsd fel. A biztonsági csoportnak csak korlátozott lehetőségei vannak a sérült csomagok kezelésére, főleg ha nem a megfelelő verziószámozást használják. Jelenleg nem lehet csomagokat visszautasítani, és a buildd-t összezavarná, ha mégis lehetne. Ezért kérjük, használj e-mailt és ne nehezítsd a biztonsági csoport munkáját.
A Fejlesztői referencia teljes útmutatást ad.
K: Kijavítottam egy hibát, küldhetem a proposed-updatesbe helyette?
V: Elvileg küldheted. Azonban mégse küldd, mivel ezzel zavarod a biztonsági
csoport munkáját. A csomagok automatikusan át fognak kerülni a
security.debian.org-ról a proposed-updatesbe. Ha egy csomagnak egy ugyanolyan
vagy újabb verziója már el van helyezve az archívumban, a biztonsági frissítést
megtagadja az archiválórendszer. Így a csomag biztonsági frissítése nem
történne meg a stable disztribúcióban, ha a proposed-updates könyvtárban lévő
rossz
csomagokat nem utasítaná vissza a rendszer.
Inkább vedd fel a kapcsolatot a
biztonsági csoporttal, küldd el a biztonsági hiba összes részletét, és
mellékeld a forrásfájlokat (azaz a diff.gz- és dsc-fájlokat) a leveledben.
A Fejlesztői referencia teljes útmutatást ad.
K: Teljesen biztos vagyok abban, hogy a csomagjaim megbízhatóak. Hogyan tölthetem fel őket?
V: Ha egészen biztos vagy abban, hogy a csomagjaid nem rontanak el
semmit, a verziószám helyes (azaz nagyobb, mint a stable és
kisebb, mint a testing/unstable verziója), hogy a szóban forgó
hibán kívül nem változtattad meg a csomag viselkedését, hogy
lefordítottad a megfelelő kiadás számára (ez az
oldstable-security vagy a
stable-security), hogy amennyiben a csomag új a
security.debian.org-on, tartalmazza az eredeti forráskódot, hogy
meggyőződtél arról, hogy a javítás a legújabb verzióhoz képest
világosan látható, és csak a szóban forgó biztonsági problémát
érinti (ellenőrizd az interdiff -z programmal
mindkét .diff.gz fájlt), korrigáltad a javítást
legalább háromszor, és a debdiff nem mutatott
semmilyen változást, akkor feltöltheted a fájlokat a bejövő
könyvtárba (ftp://security-master.debian.org/pub/SecurityUploadQueue),
közvetlenül a security.debian.org-ra. Kérjük, küldj egy részletes
értesítést a team@security.debian.org címre is.
K: Hogyan segíthetek a biztonsági kérdésekben?
V: Kérjük, nézz át minden problémát, mielőtt a security@debian.org-nak jelented. Ha tudsz javítást írni, az felgyorsíthatja a munkát. Ne csak egyszerű hibabejelentő levelet küldj, mivel azt már megkaptuk – küldj további információkat a hibabejelentésben leírt dolgokkal kapcsolatban.
K: Mi található a proposed-updates (javasolt frissítések) könyvtárban?
V: Ez a könyvtár olyan csomagokat tartalmaz, amiket a Debian következő stabil kiadásába akarunk betenni. Amikor egy karbantartó csomagokat tölt föl a stabil disztribúcióhoz, az a proposed-updates könyvtárban köt ki. Mivel a stabil disztribúciónak stabilnak kell lennie, semmilyen automatikus frissítés nem történik. A biztonsági csoport azokat a kijavított csomagokat, amik szerepelnek az ajánlásaikban, feltöltik a stabil disztribúcióba, de először ezek is a proposed-updates könyvtárba kerülnek. Néhány havonta a stabil kiadás koordinátora ellenőrzi a proposed-updates-ben lévő csomagokat és megvitatja, hogy az egyes csomagok megfelelnek-e a stabilnak vagy nem. Ezeket a stabil kiadás egy új átdolgozásába fordítják bele (pl. 2.2r3 vagy 2.2r4). A nem megfelelő csomagok kikerülnek a proposed-updates-ből is.
Ne felejtsd el, hogy a karbantartók (és nem a biztonsági csoport) által a proposed-updates/ könyvtárba feltöltött csomagokat nem támogatja a biztonsági csoport.
K: Hogyan épül fel a biztonsági csoport?
V: A Debian biztonsági csoportnak számos tisztviselője és titkára van. Maga a biztonsági csoport jelöl ki új embereket, hogy csatlakozzanak a csoporthoz.
K: Mennyi ideig biztosítjátok a biztonsági javításokat?
V: A biztonsági csoport az új stabil verzió kiadása után még egy évig próbálja támogatni a megelőző stabil verziót, kivéve, ha ugyanabban az évben egy másik stabil kiadás is megjelenik. Lehetetlen egyszerre három disztribúciót támogatni, kettő támogatása is elég nehéz feladat.
K: Hogyan ellenőrizhetem a csomagok sértetlenségét?
V: A Release fájl aláírását kell ellenőrizni az archívum nyilvános kulcsával. A Release fájl a Packages és a Sources fájlok MD5-ellenőrzőösszegét tartalmazza, azok pedig a bináris és a forráscsomagok MD5-ellenőrzőösszegét tartalmazzák. Az ellenőrzési folyamat részletes leírását a Debian Securing Manual-ben olvashatod.
K: Mit tegyek, ha egy csomag nem működik egy biztonsági frissítés után?
V: Először is, ki kell találnod, miért nem működik a csomag, és az hogyan kapcsolódik a biztonsági frissítéshez, azután vedd fel a kapcsolatot a biztonsági csoporttal, ha komoly a hiba, vagy a stable verzió kiadásmenedzserével, ha kevésbé komoly. Itt olyan csomagokról van szó, amelyek egy másik csomag biztonsági frissítése után romlanak el. Ha nem tudod kitalálni, mi volt a hiba, de van javításod, akkor is a biztonsági csoporttal beszélj. Azonban lehet, hogy átirányítanak a kiadásmenedzserhez.