path: root/danish/security/faq.wml

#use wml::debian::template title="Debians sikkerheds-OSS"
#use wml::debian::translation-check translation="1fe91e1ee0d4350b235e726f3f93da47d0639b19"
#include "$(ENGLISHDIR)/security/faq.inc"

<maketoc>

<toc-add-entry name=buthow>Jeg modtog en DSA-mail via debian-security-announce, hvordan opgraderer jeg de sårbare pakker?</toc-add-entry>

<p>Sv: Som DSA-mailen siger, bør du opgradere de pakker, som er påvirket af den 
   offentliggjorte sårbarhed.  Det kan du gøre ved blot at opgradere (efter at 
   have opdateret listen over tilgængelige pakker med <tt>apt-get update</tt>) 
   alle pakker på dit system med <tt>apt-get upgrade</tt> eller ved at opgradere 
   kun en bestemt pakke med <tt>apt-get install <em>pakkenavn</em></tt>.</p>

<p>Annonceringsmailen nævner kildekodepakken, hvori sårbarheden blev fundet. 
   Derfor bør du opgradere alle de binære pakker, som dannes ud fra den 
   pågældende kildekodepakke.  For at finde ud af hvilke binære pakker, der skal 
   opdateres, kan du besøge 
   <tt>https://packages.debian.org/src:<em>kildekodepakkenavn</em></tt> og dér 
   vælge <em>[show ... binary packages]</em> (<em>[vis ... binære pakker]</em>) 
   ud for den distribution, du opdaterer.</p>

<p>Det kan også være nødvendigt at genstarte en tjeneste eller kørende proces. 
   Kommandoen <a href="https://manpages.debian.org/checkrestart">\
   <tt>checkrestart</tt></a>, som installeres via pakken
   <a href="https://packages.debian.org/debian-goodies">debian-goodies</a>, kan
   være en hjælp til at finde ud af hvilke, det drejer sig om.</p>


<toc-add-entry name=signature>Signaturen på jeres bulletiner kan ikke verificeres korrekt!</toc-add-entry>

<p>Sv: Dette skyldes højst sandsynligt et problem hos dig. Der er et filter på 
   postlisten <a href="https://lists.debian.org/debian-security-announce/">\
   debian-security-announce</a>, der gør at kun breve med en korrekt signatur 
   fra medlemmerne af sikkerhedsteamet kan udsendes.</p>

   <p>Sandsynligvis ændrer et postprogram hos dig brevene en smule og ødelægger 
   dermed signaturen. Sørg for at dit postprogram ikke foretager nogen form for 
   ind- eller udpakning med MIME, eller konverterer tabulerings- eller 
   mellemrumstegn.</p>

   <p>Kendte syndere er fetchmail (med mimedecode-indstillingen slået til) og 
   formail (kun fra procmail 3.14) og evolution.</p>


<toc-add-entry name="handling">Hvordan håndteres sikkerhed i Debian?</toc-add-entry>

<p>Sv: Når sikkerhedsteamet har modtaget besked om en hændelse, kigger et eller 
   flere medlemmer den igennem og overvejer hvad det betyder for den stabile
   udgivelse af Debian (med andre ord om den er sårbar eller ej).
   Hvis vores system er sårbart, vil vi gå i gang med at fremstille en 
   rettelse til problemet.  Pakkevedligeholderen kontaktes også, hvis 
   vedkommende ikke allerede har kontaktet sikkerhedsteamet.  Slutteligt testes 
   rettelsen og der forberedes nye pakker, som kompiles på alle stabile 
   arkitekturer og dernæst uploades.  Når alt det er gjort udsendes et 
   sikkerhedsbulletin.</p>


<toc-add-entry name=oldversion>Hvorfor roder i med en gammel version af den pakke?</toc-add-entry>

<p>Sv: Den vigtigste retningslinie når man laver en ny pakker som retter et 
   sikkerhedsproblem, er at foretage så få ændringer som muligt.  Vore brugere
   og udviklere er afhængige af at en udgave opfører sig på en bestemt måde,
   når den er udgivet, så enhver ændring vi foretager kan måske få en eller 
   andens system til at holde op med at virke.  Dette især noget som sker i
   forbindelse med biblioteker: sørg for aldrig at ændre et biblioteks 
   Application Program Interface (API) eller dets Application Binary Interface 
   (ABI), uanset hvor lille ændringen end måtte være.</p>

   <p>Dette betyder at et skifte til en ny opstrømsversion ikke er en god 
   løsning, i stedet bør de relevante ændringer føres tilbage.  Generelt er 
   opstrømsvedligeholdere villige til at hjælpe om nødvendigt, hvis ikke kan
   Debians sikkerhedsteam måske hjælpe.</p>

   <p>I nogle tilfælde er det ikke muligt at tilbageføre en sikkerhedsrettelse,
   for eksempel når store mængder kildekode skal ændres eller omskrives.  Hvis
   det sker, er det måske nødvendigt at skifte til en ny opstrømsversion, men
   det skal koordineres med sikkerhedsteamet på forhånd.</p>


<toc-add-entry name=version>En pakkes versionsnummer indikerer at jeg stadig kører med den sårbare version!</toc-add-entry>

<p>Sv: I stedet for at opgradere til en ny version, fører vi fejlrettelser
   tilbage til den version som var indeholdt i den stabile udgivelse. Vi gør
   det for at sikre os at en ny version ændrer så lidt som muligt, så ting ikke
   uventet ændrer sig eller holder op med at virke på grund af en 
   sikkerhedsrettelse. Du kan finde ud af om du kører en sikker version af en 
   pakke, ved at kigge i pakkens ændringslog (changelog), eller ved at 
   sammenligne dens præcise versionsnummer med den version som er angivet i 
   Debians sikkerhedsbulletin.</p>


<toc-add-entry name=archismissing>Jeg har modtaget en bulletin, men der lader til at mangle en opbygning til en processorarkitektur.</toc-add-entry>

<p>Sv: Generelt udgiver Sikkerhedsholdet en bulletin med opbygninger af de 
   opdaterede pakker til alle arkitekturer, som Debian understøtter.  Dog er 
   nogle arkitekturer langsommere end andre og der kan forekomme situationer
   hvor opbygningerne til de fleste arkitekturer er klar, mens nogle stadig 
   mangler.  Disse mindre arkitekturer repræsenterer en lille del af alle vores
   brugere.  Afhængigt af et problems vigtighed, kan vi beslutte at frigive en 
   bulletin med det samme.  De manglende opbygninger vil blive stillet til 
   rådighed så snart de bliver tilgængelige, men der vil ikke blive informeret 
   yderligere herom.  Selvfølgelig vil vi aldrig udgive en bulletin, hvor 
   opbygningerne til i386 eller amd64 ikke er til stede.</p>


<toc-add-entry name=unstable>Hvordan håndteres sikkerhed i <tt>unstable</tt>?</toc-add-entry>
<p>Sv: Sikkerhed i unstable håndteres primært af pakkevedligeholderne, ikke af 
   Debian Security Team.  Dog kan sikkerhedsholdet uploade meget vigtige 
   opdateringer kun indholdende sikkerhedsrettelser, når der bemærkes at en 
   vedligeholder ikke er aktiv, men understøttelse af stable har altid den 
   højeste prioritet.  Ønsker man have have en sikker (og stabil) server, 
   opfordres man kraftigt til at benytte stable.</p>


<toc-add-entry name=testing>Hvordan håndteres sikkerhed i <tt>testing</tt>?</toc-add-entry>
<p>Sv: Sikkerhed i testing drager nytte af hele projektets sikkerhedsarbejde i 
   unstable.  Dog vil der som minimum være en migreringsforsinkelse på to dage, 
   og nogle gange kan sikkerhedsrettelser blive forsinket af transitioner.  
   Security Team hjælper med at få fremdrift i de transitioner, som forsinker 
   vigtige sikkerhedsuploads, men det er ikke altid muligt og forsinkelser kan 
   opstå.  Særligt i månederne efter en ny udgivelse af stable, hvor mange nye 
   versioner uploades til unstable, kan sikkerhedsrettelser til testing halte 
   bagefter.  Ønsker man have have en sikker (og stabil) server, opfordres man 
   kraftigt til at benytte stable.</p>


<toc-add-entry name=contrib>Hvordan håndteres sikkerhed vedr. <tt>contrib</tt> og <tt>non-free</tt>?</toc-add-entry>

<p>Sv: Det korte svar er: Det håndteres ikke.  Contrib og non-free er ikke
   officielle dele af Debian-distributionen og udgives ikke, og derfor understøttes
   de ikke af sikkerhedsteamet.  Nogle pakker i non-free distribueres uden
   kildekode eller uden en licens, der tillader distribution af ændrede udgaver.
   I disse tilfælde kan der slet ikke foretages sikkerhedsrettelser.  Hvis det er 
   muligt at rette problemet og pakkevedligeholderen eller en anden leverer 
   korrekt opdaterede pakker, så vil sikkerhedsteamet generelt behandler dem og
   udsende en bulletin.</p>


<toc-add-entry name=sidversionisold>Bulletinen siger at unstable er rettet i version 1.2.3-1, men unstable har 1.2.5-1, hvorfor?</toc-add-entry>

<p>Sv: Vi forsøger at angive den første version i unstable, hvor problemet var 
   løst.  Nogle gange har vedligeholderen i mellemtiden uploadet en endnu nyere
   version.  Sammenlign versionen i unstable med det nummer, vi angiver.  Hvis 
   det er det samme eller højere, skulle du være beskyttet mod den pågældende
   sårbarhed.  Hvis du vil være sikker, kan du kontrollere pakkens changelog med
   <tt>apt-get changelog pakkenavn</tt> og kigge efter den forekomst, som 
   fortæller om rettelsen.</p>


<toc-add-entry name=mirror>Hvorfor har security.debian.org ingen officielle filspejle?</toc-add-entry>

<p>Sv: Det er der faktisk.  Der er flere officielle filspejle implementeret
   gennem DNS-aliaser.  Formålet med security.debian.org er at gøre 
   sikkerhedsopdateringer tilgængelige så hurtigt og nemt som muligt.</p> 

   <p>Opfordring til anvendelse af uofficielle filspejle vil medføre ekstra
   kompleksitet som normalt ikke er nødvendig og kan give frustrationer hvis
   disse filspejle ikke holdes ajour.</p>


<toc-add-entry name=missing>Jeg har set DSA 100 og DSA 102, men hvor er DSA 101?</toc-add-entry>

<p>Sv: Flere leverandører (primært af GNU/Linux, men også af BSD-varianter) 
   koordinerer sikkerhedsbulletiner i forbindelse med visse hændelser og er 
   blevet enige om en bestemt tidsplan, så alle leverandørne er i stand til 
   samtidig at udsende et bulletin.  Det har man besluttet for ikke at 
   diskriminere nogle leverandører, som har brug for mere tid (for eksempel 
   hvis leverandøren først skal have pakkerne igennem nogle længere 
   kvalitetskontroller eller hvis der understøttes flere arkitekturer eller 
   binære distributioner).  Vores eget sikkerhedsteam gør også bulletiner klar 
   på forhånd.  Ind i mellem er andre sikkerhedsproblemer blevet løst før det 
   afventende bulletin kan udsendes, og dermed opstår der midlertidigt huller i 
   rækkefølgen.</p>


<toc-add-entry name=contact>Hvordan kontakter jeg sikkerhedsteamet?</toc-add-entry>

<p>Sv: Sikkerhedsoplysninger kan sendes til 
   <a href="mailto:security@debian.org">security@debian.org</a> eller 
   <a href="mailto:team@security.debian.org">team@security.debian.org</a>, som 
   begge læses af medlemmer af sikkerhedsteamet.</p>

   <p>Eventuelt kan du kryptere din e-mail med Debians sikkerhedskontaktnøgle 
   (nøgle-id 
   <a href="https://keyserver.ubuntu.com/pks/lookup?op=get&search=0x0d59d2b15144766a14d241c66baf400b05c3e651">\
   0x0D59D2B15144766A14D241C66BAF400B05C3E651</a>).  De individuelle teammedlemmers PGP-/GPG-nøgler kan ses på 
   nøgleserveren <a href="https://keyring.debian.org/">keyring.debian.org</a>.</p>


<toc-add-entry name=discover>Jeg har vist fundet et sikkerhedsproblem, hvad gør jeg?</toc-add-entry>

<p>Sv: Hvis du bliver opmærksom på et sikkerhedsproblem, enten i en af dine 
   egne pakker eller i en andens, så kontakt venligst altid sikkerhedsteamet.
   Hvis Debians sikkerhedsteam bekræfter sårbarheden og andre leverandører også
   formodes at være sårbare, vil teamet normalt også kontakte andre
   leverandører.  Hvis sårbarheden endnu ikke er offentligt kendt, vil teamet
   prøvet at koordinere sikkerhedsbulletinerne med de andre leverandører, så 
   alle store distributioner reagerer samtidig.</p>

   <p>Hvis sårbarheden allerede er offentlig kendt, så sørg for at indsende en
   fejlrapport til Debians fejlsporingssystem og giv den mærket <q>security</q>.</p>

   <p>Hvis du er Debian-udvikler, så <a href="#care">se nedenfor</a>.</p>


<toc-add-entry name=care>Hvad skal jeg gøre ved et sikkerhedsproblem i en af mine pakker?</toc-add-entry>

<p>Sv: Hvis du bliver opmærksom på et sikkerhedsproblem, enten i dine pakker
   eller i en andens, så kontakt altid sikkerhedsteamet via engelsksproget 
   e-mail til adressen team@security.debian.org.  De holder styr på 
   sikkerhedsproblemer som ikke er løst, kan hjælpe vedligeholdere med 
   sikkerhedsproblemer eller selv rette problemer, de er ansvarlige for at 
   udsende sikkerhedsbulletiner og vedligeholde security.debian.org.</p>

   <p><a href="$(DOC)/developers-reference/pkgs.html#bug-security">\
   Udviklernes opslagsbog</a> indeholder udførlige oplysninger om hvad der skal 
   gøres.</p>

   <p>Det er specielt vigtigt at du ikke uploader til andre distributioner, end 
   <q>unstable</q>, uden forudgående aftale med sikkerhedsteamet, fordi det vil 
   skabe forvirring og mere arbejde, at gå udenom sikkerhedsteamet.</p>


<toc-add-entry name=enofile>Jeg prøvede at hente en pakket listet i et af jeres 
   sikkerhedsbulletiner, men fik fejlmeddelelsen <q>filen findes ikke</q>.</toc-add-entry>

<p>Sv: Når en nyere fejlrettelse erstatter en ældre pakke på
   security.debian.org, er der stor sandsynlighed for at den gamle pakke vil
   blive fjernet samtidig med at den nye installeres.  Derfor vil du få 
   fejlmeddelelsen <q>filen findes ikke</q>.  Vi ønsker ikke distribuere pakker med
   kendte sikkerhedsfejl længere end absolut nødvendigt.</p>

   <p>Benyt venligst pakkerne fra de seneste sikkerhedsbulletiner, som 
   distribueres gennem postlisten
   <a href="https://lists.debian.org/debian-security-announce/">\
   debian-security-announce</a>. Det er bedst blot at køre 
   <code>apt-get update</code> før pakken opgraderes.</p>


<toc-add-entry name=upload>Jeg har en fejlrettelse, kan jeg uploade direkte til 
   security.debian.org?</toc-add-entry>

<p>Sv: Nej, det kan du ikke.  Arkivet på security.debian.org vedligeholdes af
   sikkerhedsteamet, som skal godkende alle pakker.  Du skal i stedet sende 
   dine rettelser (patches) eller kildekode-pakker til sikkerhedsteamet til 
   team@security.debian.org.  De vil blive gennemgået af sikkerhedsteamet og 
   slutteligt uploadet, enten med eller uden rettelser.</p>

   <p><a href="$(DOC)/developers-reference/pkgs.html#bug-security">\
   Udviklernes opslagsbog</a> indeholder udførlige oplysninger om hvad der skal 
   gøres.</p>

   <p>En måde måde at komme i gang med sikkerhedsarbejde på, er at hjælpe til 
   på Debians Security Tracker 
   (<a href="https://security-tracker.debian.org/tracker/data/report">\
   vejledning</a>).</p>


<toc-add-entry name=ppu>Jeg har en fejlrettelse, kan jeg uploade den til proposed-updates i stedet?</toc-add-entry>

<p>Sv: Rent teknisk kan du godt.  Men du bør ikke gøre det, da påvirker 
   sikkerhedsteamets arbejde i høj grad.  Pakker fra security.debian.org bliver
   automatisk kopieret til mappen proposed-updates.  Hvis en pakke med det
   samme eller et højere versionsnummer allerede er overført til arkivet, vil
   sikkerhedsopdateringen blive afvist af arkivsystemet.  På den måde vil den
   stabile distribution ende med, i stedet at mangle denne 
   sikkerhedsopdatering, med mindre den <q>forkerte</q> pakke i mappen 
   proposed-updates blev afvist.  Kontakt venligst sikkerhedsteamet i stedet, 
   vedlæg alle oplysninger om sårbarheden og vedhæft kildekoden (dvs. diff.gz- 
   og dsc-filer) til din mail.</p>

   <p><a href="$(DOC)/developers-reference/pkgs.html#bug-security">\
   Udviklernes opslagsbog</a> indeholder udførlige oplysninger om hvad der skal 
   gøres.</p>


<toc-add-entry name=SecurityUploadQueue>Jeg er ret sikker på at mine pakker er i orden, hvordan uploader jeg dem?</toc-add-entry>

<p>Hvis du er meget sikker på at du dine pakker ikke ødelægger noget, at 
   versionsnummeret er fornuftigt (dvs. større end versionsnummeret i <q>stable</q>
   og mindre end versionsnummeret i <q>testing/unstable</q>), at du ikke har ændret 
   på hvordan pakken opfører sig, på trods af det tilsvarede sikkerhedsproblem, 
   og at du har oversat pakken til den rigtige distribution (dvs. 
   <code>oldstable-security</code> eller <code>stable-security</code>), at
   pakken indeholder den originale kildekode hvis den er ny på 
   security.debian.org, at du kan bekræfte at rettelsen (patch'en) er i orden
   ved at kontrollere den mod den seneste version og at der kun rørers ved det 
   pågældende sikkerhedsproblem (kontroller med <code>interdiff -z</code> og 
   begge <code>.diff.gz</code>-filerne), at du har gennemgået rettelsen mindst 
   tre gange, og at <code>debdiff</code> ikke viser nogen ændringer, kan du 
   overføre filerne direkte til mappen incoming 
   <code>ftp://ftp.security.upload.debian.org/pub/SecurityUploadQueue</code> på 
   security.debian.org.  Send også en besked med alle oplysninger til 
   team@security.debian.org.</p>


<toc-add-entry name=help>Hvordan kan jeg hjælpe med sikkerhed?</toc-add-entry>

<p>Sv: Gennemgå hvert problem før du rapporterer det til secturity@debian.org.
   Hvis du har mulighed for at levere rettelser, så vil det gøre processen 
   hurtigere.  Videresend ikke bare e-mails fra bugtraq, dem modtager vi 
   allerede &mdash; men giv gerne flere oplysninger om ting der rapporteres 
   på bugtraq.</p>


<toc-add-entry name=proposed-updates>Hvad er omfanget af proposed-updates?</toc-add-entry>

<p>Sv: Denne mappe indeholder pakker som det er forslået skal med i den 
   næste revision af den stabile Debian-distribution (stable). Når en pakke 
   bliver uploadet af en vedligeholder, til den stabile distribution, havner 
   de i mappen <q>proposed-updates</q>. Da <q>stable</q> skal være stabil, sker der 
   ingen automatiske opdateringer. Sikkerhedsteamet uploader rettede pakker 
   nævnt i deres sikkerhedsbulletiner til <q>stable</q>, men pakkerne vil først 
   blive placeret i <q>proposed-updates</q>. Med nogle måneders mellemrum gennemgår
   den ansvarlige for den stabile udgivelse listen over pakker i 
   <q>proposed-updates</q> og diskuterer hvorvidt en pakke er egnet til <q>stable</q>
   eller ej. Dette bliver til en ny udgivelse af Debians stabile distribution
   (f.eks. 2.2r3 eller 2.2r4).  Pakker som ikke opfylder kriterierne, vil 
   formentlig blive afvist og også fjernet fra proposed-updates.</p>

   <p>Bemærk, at pakker uploadet af vedligeholdere (ikke sikkerhedsteamet) til
   mappen proposed-updates/ ikke understøttes af sikkerhedsteamet.</p>


<toc-add-entry name=composing>Hvem består sikkerhedsteamet af?</toc-add-entry>

<p>Sv: Debians sikkerhedsteam består af <a href="../intro/organization#security">\
   flere medlemmer og sekretærer</a>.  Sikkerhedsteamet udpeger selv folk til 
   at deltage i teamet.</p>


<toc-add-entry name=lifespan>I hvor lang tid vil sikkerhedsopdateringer blive stillet til rådighed?</toc-add-entry>	
<p>Sv: Sikkerhedsteamet prøver at understøtte en stabil distribution et års tid
   efter den næste stabile distribution er blevet udgivet, bortset fra når en 
   anden stabile distribution udgives indenfor det samme år.  Det er ikke 
   muligt at understøtte tre distributioner; det er svært nok at understøtte to 
   distributioner på samme tid.</p>


<toc-add-entry name=check>Hvordan kontrollerer jeg en pakkes integritet?</toc-add-entry>	
<p>Sv: Det kræver at man kontrollerer Release-filens signatur mod den
   <a href="https://ftp-master.debian.org/keys.html">offentlige 
   nøgle</a> som anvendes i forbindelse med arkivet.  Release-filen indeholder
   kontrolsummer for filerne Packages og Sources, der indeholder
   kontrolsummer hørende til binære og kildekodepakker.  For udførlige 
   oplysninger om hvordan man kontrollerer en pakkes integritet, se 
   <a href="$(HOME)/doc/manuals/securing-debian-howto/ch7#s-deb-pack-sign">\
   Debians sikkerhedshåndbog</a>.</p>


<toc-add-entry name=break>Hvad gør jeg hvis en tilfældig pakke holder op med at virke efter en sikkerhedsopdatering?</toc-add-entry>	
<p>Sv: Først og fremmest skal du finde ud af hvorfor pakken ikke længere virker
   og hvordan det hænger sammen med sikkerhedsopdateringen, dernæst kontaktes
   sikkerhedsteamet hvis problemet er alvorligt eller den stabile udgaves 
   udgivelsesansvarlige hvis det er mindre alvorligt.  Dette gælder hvis en
   tilfældig pakke holder op med at virke efter en anden pakke er blevet
   sikkerhedsopdateret.  Hvis du ikke finde ud af hvad der går galt, men har
   en rettelse, så kontaktes sikkerhedsteamet også.  De kan dog sende
   forespørgslen videre til den stabile udgaves udgivelsesansvarlige.</p>


<toc-add-entry name=cvewhat>Hvad er en CVE-identifikation?</toc-add-entry>
<p>Sv: Projektet Common Vulnerabilities and Exposures tildeler unikke navne, 
   kaldet CVE-identifikationer, til specifikke sikkerhedssårbarheder, for at 
   gøre det lettere, unikt at referere til et specifikt problem.  Flere 
   oplysninger finder man i 
   <a href="https://en.wikipedia.org/wiki/Common_Vulnerabilities_and_Exposures">\
   Wikipedia</a>.</p>


<toc-add-entry name=cvedsa>Udgiver Debian en DSA for hver CVE-id?</toc-add-entry>
<p>Sv: Debians Security Team holder styr på alle udgivne CVE-identifikationer, 
   forbinder dem med de relevante Debian-pakker og vurderer indvirkningen i en 
   Debian-sammenhæng - det faktum, at noget er blevet tildelt en CVE-id, betyder
   ikke nødvendigvis, at problemet er en alvorlig trussel mod et Debian-system.
   Oplysningen spores i <a href="https://security-tracker.debian.org">Debian 
   Security Tracker</a>, og hvad angår problemer, som anses for at være 
   alvorlige, vil et Debian Security Advisory blive udgivet.</p>

<p>Problemer med lav indvirkning, som ikke er kvalificeret til et DSA, kan blive 
   rettet i den næste Debian-udgivelse, i en punktopdatering til den aktuelle 
   stabile eller gamle stabile distribution eller medtages i en DSA, hvis en 
   sådan udgives vedrørende en mere alvorlig sårbarhed.</p>


<toc-add-entry name=cveget>Kan Debian tildele CVE-identifikationer?</toc-add-entry>
<p>Sv: Debian er en CVE Numbering Authority og kan tildele id'er, men jævnfør 
   CVE's retningslinjer kan det kun ske angående endnu ikke offentliggjorte 
   problemer.  Hvis man har kendskab til en endnu ikke offentliggjort 
   sikkerhedssårbarhed i software i Debian, og ønsker at få tildelt en 
   identifikation dertil, så kontakt Debians Security Team.  I fald sårbarheden 
   allerede er offentliggjort, anbefaler vi at man følger proceduren beskrevet i 
   <a href="https://github.com/RedHatProductSecurity/CVE-HOWTO">\
   CVE OpenSource Request HOWTO</a>.</p>


<toc-add-entry name=disclosure-policy>Har Debian en regel om at offentliggøre sårbarheder?</toc-add-entry>
<p>Sv: Debian har udgivet et <a href="disclosure-policy">regelsæt for 
   offentliggørelse af sårbarheder</a>, som en del af deltagelsen i 
   CVE-projektet.


<h1>Udgåede spørgsmål og svar til sikkerhed i Debian</h1>

<toc-add-entry name=localremote>Hvad betyder <q>lokal (fjern)</q>?</toc-add-entry>

<p>Sv: Nogle bulletiner beskriver sårbarheder som ikke kan identificeres
   inden for rammerne af den klassiske opdeling mellem lokale og fjerne 
   udnyttelser.  Nogle sårbarheder kan ikke fjernudnyttes, eksempelvis hvis de 
   ikke svarer til en dæmon, som lytter til en netværksport.  Hvis de kan 
   udnyttes af særlige filer, der leveres via netværket mens den sårbare 
   service ikke er permanent forbundet med netværket, skriver vi <q>lokal (fjern)</q> 
   (eller på engelsk <q>local (remote)</q>).</p>

   <p>Sådanne sårbarheder ligger nærmest mellem lokale og fjerne sårbarheder,
   og dækker ofte arkiver, der kan leveres via netværket, fx som vedhæftelser
   til e-mail eller hentes fra en webside.</p>