path: root/swedish/security/faq.wml

#use wml::debian::template title="Debians frågor och svar om säkerhet"
#use wml::debian::translation-check translation="848f05ee39ce74ed77b065b215fbbefc6aa4532c"
#include "$(ENGLISHDIR)/security/faq.inc"

<maketoc>

<toc-add-entry name="buthow">Jag tog emot en DSA via debian-security-announce, hur kan jag uppgradera de sårbara paketen?</toc-add-entry>
<p>S: Så som DSA-mailet säger, bör du uppgradera paketen som påverkas av 
tillkännagivna sårbarheter. Du kan göra detta genom att helt enkelt uppgradera 
alla paket (efter att du har uppdaterat listan på tillgängliga paket mha
<tt>apt-get update</tt>)
i ditt system med <tt>apt-get upgrade</tt> eller genom att uppgradera endast
ett enskilt paket, med <tt>apt-get install <i>package</i></tt>.</p>

<p>E-postmeddelandet med tillkännagivandet nämner källkodspaketet där
	sårbarheten fanns. Därför bör du uppdatera alla binära paket från det
	källkodspaketet. För att kontrollera vilka binära paket som behöver
	uppdateras, besök
	<tt>https://packages.debian.org/src:<i>source-package-name</i></tt> och
	klicka på <i>[show ... binary packages]</i> för distributionen som du
	uppdaterar.</p>

<p>Det kan även vara nödvändigt att start om en tjänst eller en körande process.
	Kommandot <a href="https://manpages.debian.org/checkrestart"><tt>checkrestart</tt></a>
	som inkluderas i paketet
	<a href="https://packages.debian.org/debian-goodies">debian-goodies</a> kan
	hjälpa dig att avgöra vilka.</p>

<toc-add-entry name=signature>Signaturen på era bulletiner gick inte igenom verifieringen
ordentligt!</toc-add-entry>
<p>S: Detta är med största sannolikhet ett problem på din sida.
Sändlistan
<a href="https://lists.debian.org/debian-security-announce/">
debian-security-announce</a> har ett filter som bara tillåter
meddelanden med en giltig signatur från en av säkerhetsgruppens medlemmar
att posta på den.
</p>

<p>Med största sannolikhet har någon e-postprogramvara på din sida gjort små
ändringar i meddelandet så att signaturen inte är giltig.
Se till att din programvara inte utför någon MIME-(av)kodning eller
konvertering av blanksteg och tabbtecken.
</p>

<p>Kända syndare är fetchmail (med mimedecode-flaggan aktiverad) och
formail (endast från procmail 3.14) samt evolution.
</p>

<toc-add-entry name=handling>Hur hanteras säkerhet i Debian?</toc-add-entry>
<p>S: När säkerhetsgruppen först får en indikation om en incident undersöker
en eller flera medlemmar den och ser hur det påverkar den stabila utgåvan
av Debian (dvs. om den är sårbar eller inte).
Om vårt system är sårbart arbetar vi med en rättelse för problemet.
Ansvarige för paketet kontaktas också, om denne inte redan själv har kontaktat
säkerhetsgruppen.
Slutligen testas rättelsen och nya paket förbereds, vilka sedan kompileras
på alla arkitekturer i den stabila utgåvan och sedan sänds in.
När allt detta är gjort publiceras en bulletin.
</p>

<toc-add-entry name=oldversion>Varför håller ni på med en gammal version av
det där paketet?</toc-add-entry>

<p>
Den viktigaste riktlinjen att följa när man skall skapa nya paket som
rättar säkerhetsproblem är att göra så få ändringar som möjligt.
Våra användare och utvecklare är beroende av att en utgåva fungerar på ett
givet sätt när den väl har släppts, så alla ändringar vi gör kan resultera
i att någons system slutar fungera.
Detta gäller speciellt för bibliotek:
se till att du aldrig ändrar programmeringsgränssnittet (API) eller
binärgränssnittet (ABI), oavsett hur liten ändringen är.
</p>

<p>
Detta innebär att det inte är en bra idé att gå över på en ny
uppströmsversion, utan att de relevanta ändringarna istället måste
bakåtanpassas.
Oftast är uppströmsförfattarna villiga att hjälpa till om det är nödvändigt,
om inte kan Debians säkerhetsgrupp hjälpa till.
</p>

<p>
I vissa fall är det inte möjligt att bakåtanpassa en säkerhetsrättelse, till
exempel när stora mängder källkod måste ändras eller skrivas om.
Om det sker kan det vara nödvändigt att gå över till en ny uppströmsversion,
men detta måste samordnas med säkerhetsgruppen på förhand.
</p>

<toc-add-entry name=version>Versionsnumret för ett paket tyder på att jag fortfarande kör en
sårbar version!</toc-add-entry>

<p>S: Istället för att uppgradera till en ny utgåva bakåtanpassar vi
säkerhetsrättelser till versionen som medföljde den stabila utgåvan.
Skälet till att vi gör detta är för att vara säkra att den nya versionen
ändrar så lite som möjligt så att saker inte oväntat ändras eller går sönder
på grund av säkerhetsrättelsen.
Du kan se om du kör en säker version av ett paket genom att se på paketets
ändringslogg, eller genom att jämföra dess exakta versionsnummer med
den version som beskrivs i Debians säkerhetsbulletin.</p>

<toc-add-entry name=archismissing>Jag har tagit emot en bulletin, men det verkar saknas paket för en
  processorarkitektur.</toc-add-entry>
<p>S: Oftast släpper säkerhetsgruppen en bulletin med uppdaterade
   paket för alla arkitekturer som Debian stödjer. Vissa arkitekturer
   är dock långsammare än andra och det kan hända att paket för de flesta arkitekturer
   är färdiga medan andra ännu saknas. Dessa mindre arkitekturer representerar en mindre
   del av vår användarbas. Beroende på hur kritiskt problemet är
   kan vi besluta att släppa bulletinen i förväg. De saknade paketen kommer
   installeras så snart de blir tillgängliga, men ingen ytterligare information om detta kommer
   ges. Självklart kommer vi aldrig släppa en bulletin där i386- eller amd64-paket
   saknas.</p>

<toc-add-entry name=unstable>Hur hanteras säkerheten för
<tt lang=en>unstable</tt>
(utvecklingsutgåvan)?</toc-add-entry>
<p>S: Säkerheten för unstable hanteras primärt av de paketansvariga och inte
	av Debians säkerhetsgrupp. Även om säkerhetsgruppen kan ladda upp
	brådskande rättelser av endast säkerhetsproblem när den paketansvarige
	verkar vara inaktiv, så är den stabila utgåvan alltid första prioritet.
	Om du vill ha en säker (och stabil) server så rekommenderas du starkt att
	hålla dig till den stabila utgåvan.</p>

<toc-add-entry name=testing>Hur hanteras säkerheten för
<tt lang=en>testing</tt>
(uttestningsutgåvan)?</toc-add-entry>
<p>S: Säkerheten i testing tjänar på säkerhetsinsatserna som hela projektet
	utför för unstable. Dock så finns det en migrationsfördröjning på minst
	två dagar och ibland så kan säkerhetsrättelser hållas av övergångar.
	Säkerhetsgruppen hjälper till att hålla igång dessa övergångar genom att
	hålla tillbaka viktiga säkerhetsuppdateringar, men ibland är detta inte
	möjligt och fördröjningar kan ske. Speciellt i månaderna som följer en 
	stabil utgåva så kan säkerhetsuppdateringarna för uttestningsutgåvan hamna 
	bakom, då många nya versioner laddas upp till den instabila utgåvan. Om du
	vill ha ett säkert (och stabilt) system så rekommenderas du starkt att
	hålla dig till den stabila utgåvan.</p>

<toc-add-entry name=contrib>Hur hanteras säkerhet för <tt>contrib</tt>,
 <tt>non-free</tt> och <tt>non-free-firmware</tt>?</toc-add-entry>
<p>
S: Det korta svaret är att den inte hanteras.
Contrib, non-free och non-free-firmware är inte officiellt en del av
Debiandistributionen och hör inte dit, och stöds därför inte av
säkerhetsgruppen. Vissa icke-fria programvaror distribueras utan källkod eller
utan licens som gör det möjligt att distribuera ändrade versioner.
I de fallen är det inte möjligt att göra några säkerhetsrättelser alls.
Om det är möjligt att rätta problemet, och paketansvarige eller någon annan
tillhandahåller korrekta uppdaterade paket, kommer säkerhetsgruppen
vanligtvis hantera dem och publicera en bulletin.
</p>

<toc-add-entry name=sidversionisold>Bulletinen säger att den instabila
utgåvan rättats i version 1.2.3-1, men unstable har 1.2.5-1, vad menas med 
det?</toc-add-entry>

<p>
S: Vi försöker ange den första version i den instabila utgåvan där felet är
rättat. Ibland har paketansvariga sänt in ännu nyare versioner sedan dess.
Jämför versionsnumret i den instabila utgåvan med versionen vi anger, och om
den är samma eller högre så bör du vara säker från det här problemet. Om du
vill säkerställa detta, kan kontrollera paketets förändringslogg med
<tt>apt-get changelog paketnamn</tt> och söka efter posten som tillkännager
rättningen.
</p>

<toc-add-entry name=mirror>Varför finns det inte några officiella speglar av
security.debian.org?</toc-add-entry>
<p>S: Det finns det faktiskt.
Det finns flera officiella speglar, som implementerats som DNS-alias.
Målet med security.debian.org är att göra säkerhetsuppdateringar
tillgängliga så fort och enkelt som möjligt.
</p>

<p>
Om vi skulle rekommendera användandet av speglar skulle det ge ytterligare
komplexitet som normalt inte behövs och som kan orsaka
frustration i de fall de inte är à jour.
</p>

<toc-add-entry name=missing>Jag har sett DSA 100 och DSA 102, var har DSA 101 tagit
vägen?</toc-add-entry>
<p>S: Flera distributörer (de flesta av Linux, men även BSD-derivat)
samordnar säkerhetsbulletiner för vissa incidenter och kommer överens om
specifika tidsscheman så att alla distributörer kan släppa bulletiner
samtidigt.
Detta bestämdes för att inte diskriminera mot distributörer som behöver mer
tid (t.ex då distributören måste sända paket genom långvariga
kvalitetsstyrningstester, eller måste stöda flera arkitekturer eller
binärdistributioner).
Vår egen säkerhetsgrupp skriver bulletiner i förväg, och ibland måste andra
säkerhetsproblem hanteras innan den parkerade bulletinen kan släppas, vilket
därmed tillfälligtvis kan göra att en eller flera bulletinnummer
utelämnas.</p>

<toc-add-entry name=contact>Hur når jag säkerhetsgruppen?</toc-add-entry>
<p>
S: Säkerhetsrelaterad information kan sändas till security@debian.org
eller team@security.debian.org, bägge dessa adresserna läses av
säkerhetsgruppen.
</p>

<p>
Om så önskas kan e-post krypteras med Debians säkerhetskontaktsnyckel
(nyckel-id
<a
href="https://keyserver.ubuntu.com/pks/lookup?op=get&search=0x0d59d2b15144766a14d241c66baf400b05c3e651">\
0x0D59D2B15144766A14D241C66BAF400B05C3E651</a>).
För enskilda gruppmedlemmars OpenPGP-nycklar, se
nyckelservern <a href="https://keyring.debian.org/">keyring.debian.org</a>.
</p>

<toc-add-entry name=discover>Det verkar som jag upptäckt ett
säkerhetsproblem, vad skall jag göra nu?</toc-add-entry>

<p>
S: Om du får kännedom om ett säkerhetsproblem, antingen i ditt paket
eller i någon annans, skall du alltid ta kontakt med säkerhetsgruppen.
Om Debians säkerhetsgrupp bekräftar sårbarheten och det är sannolikt att
även andra distributioner är sårbara kontaktar de vanligen de som ansvarar
för dessa.
Om sårbarheten ännu inte är allmänt känd kommer de försöka samordna
säkerhetsbulletinerna med de andra distributionerna så att alla större
distributioner hålls synkroniserade.
</p>

<p>
Om sårbarheten redan är allmänt känd, se till att du sänder in en felrapport
i Debians felrapporteringsystem och märker det med
<q><span lang="en">security</span></q>.
</p>

<p>
Om du är Debianutvecklare, <a href="#care">se nedan</a>.
</p>

<toc-add-entry name=care>Vad skall jag göra om jag har säkerhetsproblem i ett av mina
paket?</toc-add-entry>

<p>S: Om du får kännedom om ett säkerhetsproblem, antingen i ditt paket
eller i någon annans, skall du alltid ta kontakt med säkerhetsgruppen via 
e-post på team@security.debian.org.
De håller reda på oavklarade säkerhetsproblem, hjälper paketansvariga med
säkerhetsproblem eller rättar själva problemen, är ansvariga för att sända
säkerhetsbulletiner och att underhålla security.debian.org.
</p>

<p>
<a href="$(DOC)/developers-reference/pkgs.html#bug-security">
Utvecklarreferensen</a> innehåller detaljerad information om vad man skall
göra.
</p>

<p>
Det är speciellt viktigt att du inte sänder in paket till andra
distributioner än den instabila utan att det först har blivit godkänt av
säkerhetsgruppen, eftersom det kan orsaka frustration och ökande arbetsbörda
att förbigå dem.
</p>

<toc-add-entry name=enofile>Jag försökte hämta ett paket som listas i en av
säkerhetsbulletinerna, men jag får felmeddelandet <q>filen kunde inte
hittas</q>.</toc-add-entry>

<p>S: Närhelst en ny felrättelse ersätter ett gammalt paket på
security.debian.org är det mycket möjligt att det gamla paketet kommer tas
bort när det nya installeras, varför du får detta <q>filen kunde inte
hittas</q>-fel.
Vi vill inte distribuera paket med kända säkerhetsfel längre än absolut
nödvändigt.</p>

<p>Använd paketen från de senaste säkerhetsbulletinerna, vilka
distribueras genom sändlistan
<a href="https://lists.debian.org/debian-security-announce/">
debian-security-announce</a>.
Det bästa är att helt enkelt köra <code>apt-get update</code>
innan du uppgraderar paketet.</p>

<toc-add-entry name=upload>Jag har en rättelse, kan jag sända den direkt till
security.debian.org?</toc-add-entry>

<p>S: Nej, det kan du inte.
Arkivet på security.debian.org underhålls av säkerhetsgruppen, som
godkänner alla paket.
Du bör istället sända patchar eller hela källkodspaket till säkerhetsgruppen 
via team@security.debian.org.
De kommer att granskas av säkerhetsgruppen och sedan sändas in, antingen med
eller utan ändringar.
</p>

<p>
<a href="$(DOC)/developers-reference/pkgs.html#bug-security">
Utvecklarreferensen</a> innehåller detaljerad information om vad man skall
göra.
</p>

<toc-add-entry name=ppu>Jag har en felrättelse, kan jag sända in till
proposed-updates istället?</toc-add-entry>

<p>
S: Tekniskt sett kan du det, men du bör inte göra det eftersom detta stör ut
säkerhetsgruppens arbete.
Paket från security.debian.org kommer automatiskt att kopieras till
proposed-updates.
Om ett paket med samma versionsnummer redan har installerats i arkivet
kommer säkerhetsuppdateringen att avvisas av arkivsystemet, vilket får till
följd att den stabila versionen inte kommer få in säkerhetsuppdateringen för
paketet, såvida inte <q>fel</q> paket i proposed-updates förkastades.
Kontakta säkerhetsgruppen och sänd med alla detaljer gällande sårbarheten
och bifoga källkodsfilerna (dvs. diff.gz- och dsc-filerna) till ditt brev.
</p>

<p>
<a href="$(DOC)/developers-reference/pkgs.html#bug-security">
Utvecklarreferensen</a> innehåller detaljerad information om vad man skall
göra.
</p>

<toc-add-entry name=SecurityUploadQueue>Jag är rätt säker på att mina paket
är okej, hur sänder jag in dem?</toc-add-entry>

<p>S: Om du är helt säker på att inget gick sönder, att versionsnumret är
vettigt (dvs. större än versionen i den stabila utgåvan och mindre än det i
uttestnings-/den instabila utgåvan), att paketets beteende inte
förändrades trots det motsvarande säkerhetsproblemet, att du kompilerade det
mot rätt utgåva (alltså <code>oldstable-security</code> eller
<code>stable-security</code>), att paketet innehåller den ursprungliga
källkoden om paketet är nytt för security.debian.org, att du kan bekräfta
att ändringen mot den senaste versionen är ren och bara ändrar det
motsvarande säkerhetsproblemet (kontrollera med <code>interdiff -z</code>
och de båda <code>.diff.gz</code>-filerna), att du korrekturläst ändringen
åtminstone tre gånger, och att <code>debdiff</code> inte visar några ändringar
så kan du sända filerna direkt till incoming-katalogen
<code>ftp://ftp.security.upload.debian.org/pub/SecurityUploadQueue</code> direkt på
security.debian.org.
Sänd dessutom en bekräftelse med alla detaljer och länkar till
team@security.debian.org.
</p>

<toc-add-entry name=help>Hur kan jag hjälpa till med säkerheten?</toc-add-entry>
<p>S: Kontrollera alla problem innan du rapporterar dem till
security@debian.org.
Om du kan tillhandahålla patchar snabbar det upp processen.
Skicka inte bara vidare brev från bugtraq, eftersom vi redan tar emot dem
&ndash; men sänd gärna ytterligare information om problem som rapporterats
på bugtraq.
</p>

<p>
Ett bra sätt att komma igång med säkerhetsarbete är att hjälpa till med
Debians säkerhetsspårare
(<a href="https://security-tracker.debian.org/tracker/data/report">instruktioner</a>).
</p>

<toc-add-entry name=proposed-updates>Varför finns proposed-updates?</toc-add-entry>
<p>S: Denna katalog består av paket som föreslås komma in i nästa underutgåva
av Debians stabila utgåva.
Närhelst paket sänds in av en utvecklare för den stabila utgåvan
hamnar de i katalogen proposed-updates.
Eftersom den stabila utgåvan är menad att vara stabil görs inga
automatiska uppdateringar.
Säkerhetsgruppen sänder in de rättade paket som avhandlas i bulletinerna
till den stabila utgåvan, men de hamnar i proposed-updates först.
Med några månaders mellanrum går den ansvarige för den stabila utgåvan genom
paketen i proposed-updates och diskuterar huruvida paketen är lämpade för
den stabila utgåvan eller inte.
Dessa paket samlas till en underutgåva (t.ex 2.2r3 eller 2.2r4).
Paket som inte uppfyller kraven kommer troligen nekas och även tas bort från
proposed-updates.
</p>

<p>
Observera att paket som sänds in av paketansvariga (inte av
säkerhetsgruppen) till katalogen proposed-updates/ inte stöds av
säkerhetsgruppen.
</p>

<toc-add-entry name=composing>Hur är säkerhetsgruppen uppbyggd?</toc-add-entry>
<p>S: Debians säkerhetsgrupp består av
<a href="../intro/organization#security">flera medlemmar och sekreterare</a>.
Säkerhetsgruppen utser själv vilka personer som skall delta i den.
</p>

<toc-add-entry name=lifespan>Hur länge tillhandahålls säkerhetsuppdateringar?</toc-add-entry>
<p>
S: Säkerhetsgruppen kommer att ge stöd till en den stabila utgåvan tre år
efter dess utgivning. Det är inte möjligt att ge stöd för tre distributioner,
att stödja två samtidigt är redan tillräckligt komplicerat.
</p>

<toc-add-entry name=check>Hur kan jag säkerställa paketens integritet?</toc-add-entry>
<p>
S: Proceduren innefattar kontroll av Release-filens signatur mot den
<a href="https://ftp-master.debian.org/keys.html">öppna nyckel</a>
som används för arkivet.
Release-filen innehåller kontrollsummorna för Packages- och
Sources-filerna, vilka innehåller kontrollsummor för binär- och
källkodspaket.
Detaljerade instruktioner för hur man kontrollerar paketens integritet finns i
<a href="$(HOME)/doc/manuals/securing-debian-howto/ch7#s-deb-pack-sign">Debian Securing Manual</a>.
</p>

<toc-add-entry name=break>Vad gör jag om ett annat paket går sönder efter en säkerhetsuppdatering?</toc-add-entry>
<p>
S: Först och främst bör du ta reda på varför paketet går sönder och hur det
har samband med säkerhetsuppdateringen.
Därefter kontaktar du säkerhetsgruppen om det är allvarligt, eller den
ansvarige för den stabila utgåvan om det är mindre allvarligt.
Vi talar om paket som går sönder efter en säkerhetsuppdatering av andra
paket.
Om du inte lyckas komma fram till vad det är som händer, men har ett sätt
att korrigera problemet, tar du också kontakt med säkerhetsgruppen.
Det är dock möjligt att du blir hänvisad till den ansvarige för den stabila
utgåvan.
</p>

<toc-add-entry name=cvewhat>Vad är en CVE-identifierare?</toc-add-entry>
<p>S: Projektet Common Vulnerabilities and Exposures tilldelar unika namn
	som kallas CVE-identifierare till specifika säkerhetssårbarheter, för att
	göra det lättare att unikt hänvisa till ett specifikt problem. Mer 
	information finns på <a
	href="https://en.wikipedia.org/wiki/Common_Vulnerabilities_and_Exposures">\
	Wikipedia</a>.</p>

<toc-add-entry name=cvedsa>Tilldelar Debian en DSA för varje CVE-id?</toc-add-entry>
<p>S: Debians säkerhetsgrupp håller reda på varje CVE-identifierare, kopplar den
	till det relevanta Debian-paketet och bedömer dess effekter i ett 
	Debian-sammanhang - endast det faktum att ett problem har tilldelats en 
	CVE-identifierare behöver inte betyda att problemet är ett allvarligt hot
	mot ett Debiansystem. Denna information spåras i 
	<a href="https://security-tracker.debian.org">Debians säkerhetsspårare (Debian Security Tracker)</a>
	och för de problem som anses vara allvarliga så kommer en säkerhetsbulletin
	(DSA) att ges ut.</p>

<p>Problem med liten påverkan som inte kvalificerar för en DSA kan rättas i
	nästa utgåva av Debian i en punktutgåva av den aktuella stabila eller 
	gamla stabila utgåvan eller så inkluderas de i en DSA som ges ut för ett
	allvarligare problem.</p>

<toc-add-entry name=cveget>Kan Debian tilldela CVE-identifierare?</toc-add-entry>
<p>S: Debian är en CVE-numreringsmyndighet (CVE Numbering Authority) och kan
	tilldela identifierare, men per policy endast till ännu icke avslöjade 
	problem. Om du har ett säkerhetsproblem för mjukvara i Debian som 
	fortfarande inte är avslöjat och vill få en identifierare för detta, kontakta
	Debians säkerhetsgrupp. För fall där säkerhetsbristen redan är publik 
	så rekommenderar vi proceduren som beskrivs i <a
	href="https://github.com/RedHatProductSecurity/CVE-HOWTO">\
	CVE OpenSource Request HOWTO</a>.</p>

<toc-add-entry name=disclosure-policy>Har Debian en policy för avslöjande av sårbarheter?</toc-add-entry>
<p>S: Debian har publicerat en <a href="disclosure-policy">policy för
   avslöjande av sårbarheter</a> som en del av deras deltagande i CVE-programmet.</p>

<toc-add-entry name=cve-severity-assessment>Vårt verktyg för sårbarhetshantering
   har visat att följande säkerhetsproblem är öppna (lista på CVEer med olika
   CVSS-poäng). När kommer dessa att fixas?</toc-add-entry>
<p>S: Debian tillhandahåller inte CVSS-poäng och använder inte CVSS-poäng från
   externa källor vid undersökning av säkerhetsproblem.</p>
<p>Du kan kontrollera status för varje enstaka CVE-ID i Debians säkerhetsspårare genom
   att söka med hjälp av <a href="https://security-tracker.debian.org/tracker/CVE-ID">ID</a>.</p>
<p>Avdelningen "anteckningar" kommer att innehålla ytterligare information, exempelvis att ett
   säkerhetsproblem inte kräver en säkerhetsuppdatering i Debian, men kan rättas i en
   efterföljande punktutgåva.</p>
<p>En lista på paket där en säkerhetsuppdatering är planerad kan hittas i
<a href="https://salsa.debian.org/security-tracker-team/security-tracker/raw/master/data/dsa-needed.txt">\
   listan dsa-needed</a>.</p>
<p>Om du hittar ett fel i triage-data välkomnas du att rapportera detta. Debians säkerhetsgrupp
   kommer i allmänhet inte att reagera på förfrågningar efter mer specifik information, utan
   du bör istället kontakta tillverkaren av ditt verktyg för säkerhetshantering, eftersom det är
   dom som uppmärksammade dig på ett säkerhetsproblem, och inte Debian.</p>


<h1>Övergivna frågor i Debian Säkerhets-FAQ</h1>

<toc-add-entry name=localremote>Vad betyder <q>local
(remote)</q>?</toc-add-entry>

<p><b>Fältet <i>Problemtyp</i> i DSA-meddelanden används inte sedan April 2014.</b><br/>
S: Vissa bulletiner beskriver sårbarheter det inte är möjligt att placera i
den klassiska uppdelningen mellan lokalt och utifrån nåbart utnyttjande.
Vissa sårbarheter kan inte utnyttjas utifrån, t.ex är inte kopplade till en
server som lyssnar på en nätverksport.
Om de kan utnyttjas genom speciella filer som kan komma via nätverket trots
att den sårbara tjänsten inte är permanent ansluten till nätverket skriver
vi <q><span lang="en">local (remote)</span></q>.
</p>

<p>
Dessa sårbarheter ligger någonstans mellan lokala och utifrån nåbara
sårbarheter, och handlar ofta om arkiv som kan komma över nätverket, t.ex
e-postbilagor eller filer från en hämtningssida.
</p>