+<p>Tidlig i januar oppdaget vi i
+<a href="http://www.openstreetmap.no/">OpenStreetmap.org-prosjektet</a>
+at Oslo kommune har tatt i bruk OpenStreetmap.org for å vise frem
+<a href="http://www.samferdselsetaten.oslo.kommune.no/miljo/piggdekkgebyr/">hvor
+piggdekkavgiften gjelder</a>, dvs. kommunegrensa. Årsaken til at
+denne siden bruker OpenStreetmap.org og ikke kommunens eget
+kartgrunnlag, er ganske absurd. Kommunens kart vedlikeholdes og
+styres av Plan og Bygningsetaten, mens det er Samferdselsetaten som
+styrer med piggdekkavgift og som har laget siden om piggdekkavgiften.
+I avtalen mellom Samferdselsetatet og Plan og Bygningsetaten om bruk
+av kommunens kart står det at kartet kun kan brukes internt, og dermed
+ikke publiseres på Internet. Oslo kommune forbyr altså Oslo kommune å
+publisere informasjon om sin kommunegrense på Internet. Ironien er
+upåklagelig, og årsaken er som alltid penger.</p>
+
+<p>Vi i OpenStreetmap.org-prosjektet synes det er veldig gledelig at
+Oslo kommune vil bruke kartet vårt, men det var et lite problem rundt
+bruken av kommunegrensen. Den kommer fra kartverkets N5000-kart, som
+i følge kartverket har nøyaktighet på 2 km. Et kart over hvor
+piggdekkavgiften gjelder bør ha høyere nøyaktighet enn det for å unngå
+konflikter, så det var dermed viktig for oss å forbedre nøyaktigheten
+for Oslogrensa.</p>
+
+<p>For litt over 2 uker siden ringte jeg derfor til Kartverket, for å
+høre om de kunne bidra. Jeg lurte på om de enten hadde noen
+datakilder med kommunegrensen i Oslo som vi ikke kjente til, eller om
+de kunne forklare hvordan vi kunne gjenskape kommunegrensen på bakken
+ved å følge en beskrivelse av grensen eller finne grensepunkter
+etc.</p>
+
+<p>For å ta det siste først, så var det beste forslaget der å bruke
+kartet tilgjengelig fra
+<a href="http://www.norgeskart.no/">norgeskart.no</a> til å slå opp
+gårds- og bruksnummer for eiendommer som grenset til kommunegrensa, og
+så be om innsyn i matrikkelen for hver av disse eiendommene og gå opp
+grensen basert på informasjon fra matrikkelen. Det fantes antagelig
+også noen grensesteiner som var merket på bakken, men de kjente ikke
+til noen offentlig kilde med informasjon om hvor disse steinene sto.
+Dette er en ganske arbeidskrevende oppgave, som får vente til en annen
+gang.<p>
+
+<p>For alternative datakilder vi ikke kjente til, så var det ingen som
+hadde gode forslag når det gjaldt datakilder fra kartverket. Men en
+nevnte at det kunne være enklere å få ut data fra veidatabasen til
+vegvesenet, f.eks. de punktene der veier inn og ut av Oslo byttet
+kommune. Dette ble jeg forklart var trivielt å hente ut (mindre enn 1
+minutts jobb), men vedkommende jeg snakket med kunne ikke avgjøre om
+vi kunne få disse punktene uten bruksbegrensninger.</p>
+
+<p>Og tilgang uten bruksbegrensninger er viktig for OpenStreetmap.org,
+da det skal være tillatt å bruke OpenStreetmap.org-data til å lage
+kommersielle tjenester og kopiere, endre og distribuere
+OpenStreetmap.org-data uten begrensninger. Jeg gjorde det derfor
+klart for de jeg snakket med hos Kartverket at jeg kun var interessert
+i å motta data som kunne legges inn i OpenStreetmap.org uten
+bindinger. Fikk f.eks. tilbud om å få "test-data" av kommunegrensen
+for Oslo til internt bruk og måtte takke nei.</p>
+
+<p>Ideen om veidatabasen var interessant, og jeg fulgte den opp
+videre. Ble satt videre til noen som kanskje kunne avgjøre om jeg
+fikk disse punktene uten bruksbegresninger, og etter en kort og
+interessant samtale fikk jeg ja til å få kopi av punktene der
+Oslogrensa krysser vei. De ble
+<a href="http://lists.nuug.no/pipermail/kart/2011-January/002242.html">sendt
+til kart-listen</a> i SOSI-format, og i løpet av noen dager brukt til
+å justere kommunegrensa for Oslo slik at den nå har nøyaktighet på
+noen meter der den krysser vei. Har fått tilbakemelding fra noen som
+har tilgang til Oslo kommunes kart at nøyaktigheten var blitt mye
+bedre. :)</p>
+
+<p>Det burde ikke være nødvendig å gjøre en slik innsats for å få vite
+hvor kommunegrensene går. En skulle jo tro dette var offentlig
+informasjon uten bruksbegrensing, og Gustav Fosseid og Magne Mæhre har
+et prosjekt gående for å be om innsyn i nettopp denne informasjonen.
+De har bedt om elektronisk kopi av kartkoordinatene for
+kommunegrensene i endel kommuner på østlandet i sitt <a
+href="http://www.frigeonorge.net/">Fri Geo Norge-prosjekt</a>, og har
+fått avslag i første instans og klagesvar fra fylkesmannen i sin klage
+på avslaget. Er spent på fortsettelsen, og gir dem all min hjelp og
+støtte i arbeidet med å få frigjort det som burde vært offentlig
+informasjon.</p>
+</div>
+ <div class="tags">
+
+
+
+ Tags: <a href="http://people.skolelinux.org/pere/blog/tags/kart">kart</a>, <a href="http://people.skolelinux.org/pere/blog/tags/norsk">norsk</a>, <a href="http://people.skolelinux.org/pere/blog/tags/opphavsrett">opphavsrett</a>.
+
+ </div>
+ </div>
+ <div class="padding"></div>
+
+ <div class="entry">
+ <div class="title"><a href="http://people.skolelinux.org/pere/blog/Using_NVD_and_CPE_to_track_CVEs_in_locally_maintained_software.html">Using NVD and CPE to track CVEs in locally maintained software</a></div>
+ <div class="date">2011-01-28 15:40</div>
+ <div class="body">
+<p>The last few days I have looked at ways to track open security
+issues here at my work with the University of Oslo. My idea is that
+it should be possible to use the information about security issues
+available on the Internet, and check our locally
+maintained/distributed software against this information. It should
+allow us to verify that no known security issues are forgotten. The
+CVE database listing vulnerabilities seem like a great central point,
+and by using the package lists from Debian mapped to CVEs provided by
+the testing security team, I believed it should be possible to figure
+out which security holes were present in our free software
+collection.</p>
+
+<p>After reading up on the topic, it became obvious that the first
+building block is to be able to name software packages in a unique and
+consistent way across data sources. I considered several ways to do
+this, for example coming up with my own naming scheme like using URLs
+to project home pages or URLs to the Freshmeat entries, or using some
+existing naming scheme. And it seem like I am not the first one to
+come across this problem, as MITRE already proposed and implemented a
+solution. Enter the <a href="http://cpe.mitre.org/index.html">Common
+Platform Enumeration</a> dictionary, a vocabulary for referring to
+software, hardware and other platform components. The CPE ids are
+mapped to CVEs in the <a href="http://web.nvd.nist.gov/">National
+Vulnerability Database</a>, allowing me to look up know security
+issues for any CPE name. With this in place, all I need to do is to
+locate the CPE id for the software packages we use at the university.
+This is fairly trivial (I google for 'cve cpe $package' and check the
+NVD entry if a CVE for the package exist).</p>
+
+<p>To give you an example. The GNU gzip source package have the CPE
+name cpe:/a:gnu:gzip. If the old version 1.3.3 was the package to
+check out, one could look up
+<a href="http://web.nvd.nist.gov/view/vuln/search?cpe=cpe%3A%2Fa%3Agnu%3Agzip:1.3.3">cpe:/a:gnu:gzip:1.3.3
+in NVD</a> and get a list of 6 security holes with public CVE entries.
+The most recent one is
+<a href="http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-0001">CVE-2010-0001</a>,
+and at the bottom of the NVD page for this vulnerability the complete
+list of affected versions is provided.</p>
+
+<p>The NVD database of CVEs is also available as a XML dump, allowing
+for offline processing of issues. Using this dump, I've written a
+small script taking a list of CPEs as input and list all CVEs
+affecting the packages represented by these CPEs. One give it CPEs
+with version numbers as specified above and get a list of open
+security issues out.</p>
+
+<p>Of course for this approach to be useful, the quality of the NVD
+information need to be high. For that to happen, I believe as many as
+possible need to use and contribute to the NVD database. I notice
+RHEL is providing
+<a href="https://www.redhat.com/security/data/metrics/rhsamapcpe.txt">a
+map from CVE to CPE</a>, indicating that they are using the CPE
+information. I'm not aware of Debian and Ubuntu doing the same.</p>
+
+<p>To get an idea about the quality for free software, I spent some
+time making it possible to compare the CVE database from Debian with
+the CVE database in NVD. The result look fairly good, but there are
+some inconsistencies in NVD (same software package having several
+CPEs), and some inaccuracies (NVD not mentioning buggy packages that
+Debian believe are affected by a CVE). Hope to find time to improve
+the quality of NVD, but that require being able to get in touch with
+someone maintaining it. So far my three emails with questions and
+corrections have not seen any reply, but I hope contact can be
+established soon.</p>
+
+<p>An interesting application for CPEs is cross platform package
+mapping. It would be useful to know which packages in for example
+RHEL, OpenSuSe and Mandriva are missing from Debian and Ubuntu, and
+this would be trivial if all linux distributions provided CPE entries
+for their packages.</p>
+</div>
+ <div class="tags">
+
+
+
+ Tags: <a href="http://people.skolelinux.org/pere/blog/tags/debian">debian</a>, <a href="http://people.skolelinux.org/pere/blog/tags/english">english</a>, <a href="http://people.skolelinux.org/pere/blog/tags/sikkerhet">sikkerhet</a>.
+
+ </div>
+ </div>
+ <div class="padding"></div>
+
+ <div class="entry">
+ <div class="title"><a href="http://people.skolelinux.org/pere/blog/Skolelinux_intervju__Morten_Amundsen.html">Skolelinux-intervju: Morten Amundsen</a></div>
+ <div class="date">2011-01-23 12:00</div>
+ <div class="body">
+<p>Denne gangen er det Tromsøkontoret til Friprog-senteret, og nyvalgt
+styremedlem i <a href="http://www.friprogramvareiskolen.no/">foreningen
+FRISK</a> jeg har fått i tale i min intervjuserie med
+<a href="http://www.skolelinux.org/">Skolelinux</a>-folk.</p>
projects / homepage.git / blobdiff