Petter Reinholdtsen

Foreningen NUUG melder i natt at NRK nå har bestemt seg for når den norske dokumentarfilmen om datalagringsdirektivet skal sendes (se IMDB for detaljer om filmen) . Første visning blir på NRK2 mandag 2014-03-31 kl. 19:50, og deretter visninger onsdag 2014-04-02 kl. 12:30, fredag 2014-04-04 kl. 19:40 og søndag 2014-04-06 kl. 15:10. Jeg har sett dokumentaren, og jeg anbefaler enhver å se den selv. Som oppvarming mens vi venter anbefaler jeg Bjørn Stærks kronikk i Aftenposten fra i går, Autoritær gjøkunge, der han gir en grei skisse av hvor ille det står til med retten til privatliv og beskyttelsen av demokrati i Norge og resten verden, og helt riktig slår fast at det er vi i databransjen som sitter med nøkkelen til å gjøre noe med dette. Jeg har involvert meg i prosjektene dugnadsnett.no og FreedomBox for å forsøke å gjøre litt selv for å bedre situasjonen, men det er mye hardt arbeid fra mange flere enn meg som gjenstår før vi kan sies å ha gjenopprettet balansen.

Jeg regner med at nettutgaven dukker opp på NRKs side om filmen om datalagringsdirektivet om frem dager. Hold et øye med siden, og tips venner og slekt om at de også bør se den.

Did you ever need to store logs or other files in a way that would allow it to be used as evidence in court, and needed a way to demonstrate without reasonable doubt that the file had not been changed since it was created? Or, did you ever need to document that a given document was received at some point in time, like some archived document or the answer to an exam, and not changed after it was received? The problem in these settings is to remove the need to trust yourself and your computers, while still being able to prove that a file is the same as it was at some given time in the past.

A solution to these problems is to have a trusted third party "stamp" the document and verify that at some given time the document looked a given way. Such notarius service have been around for thousands of years, and its digital equivalent is called a trusted timestamping service. The Internet Engineering Task Force standardised how such service could work a few years ago as RFC 3161. The mechanism is simple. Create a hash of the file in question, send it to a trusted third party which add a time stamp to the hash and sign the result with its private key, and send back the signed hash + timestamp. Both email, FTP and HTTP can be used to request such signature, depending on what is provided by the service used. Anyone with the document and the signature can then verify that the document matches the signature by creating their own hash and checking the signature using the trusted third party public key. There are several commercial services around providing such timestamping. A quick search for "rfc 3161 service" pointed me to at least DigiStamp, Quo Vadis, Global Sign and Global Trust Finder. The system work as long as the private key of the trusted third party is not compromised.

But as far as I can tell, there are very few public trusted timestamp services available for everyone. I've been looking for one for a while now. But yesterday I found one over at Deutches Forschungsnetz mentioned in a blog by David Müller. I then found a good recipe on how to use the service over at the University of Greifswald.

The OpenSSL library contain both server and tools to use and set up your own signing service. See the ts(1SSL), tsget(1SSL) manual pages for more details. The following shell script demonstrate how to extract a signed timestamp for any file on the disk in a Debian environment:

#!/bin/sh
set -e
url="http://zeitstempel.dfn.de"
caurl="https://pki.pca.dfn.de/global-services-ca/pub/cacert/chain.txt"
reqfile=$(mktemp -t tmp.XXXXXXXXXX.tsq)
resfile=$(mktemp -t tmp.XXXXXXXXXX.tsr)
cafile=chain.txt
if [ ! -f $cafile ] ; then
    wget -O $cafile "$caurl"
fi
openssl ts -query -data "$1" -cert | tee "$reqfile" \
    | /usr/lib/ssl/misc/tsget -h "$url" -o "$resfile"
openssl ts -reply -in "$resfile" -text 1>&2
openssl ts -verify -data "$1" -in "$resfile" -CAfile "$cafile" 1>&2
base64 < "$resfile"
rm "$reqfile" "$resfile"

The argument to the script is the file to timestamp, and the output is a base64 encoded version of the signature to STDOUT and details about the signature to STDERR. Note that due to a bug in the tsget script, you might need to modify the included script and remove the last line. Or just write your own HTTP uploader using curl. :) Now you too can prove and verify that files have not been changed.

But the Internet need more public trusted timestamp services. Perhaps something for Uninett or my work place the University of Oslo to set up?

Keeping your DVD collection safe from scratches and curious children fingers while still having it available when you want to see a movie is not straight forward. My preferred method at the moment is to store a full copy of the ISO on a hard drive, and use VLC, Popcorn Hour or other useful players to view the resulting file. This way the subtitles and bonus material are still available and using the ISO is just like inserting the original DVD record in the DVD player.

Earlier I used dd for taking security copies, but it do not handle DVDs giving read errors (which are quite a few of them). I've also tried using dvdbackup and genisoimage, but these days I use the marvellous python library and program python-dvdvideo written by Bastian Blank. It is in Debian already and the binary package name is python3-dvdvideo. Instead of trying to read every block from the DVD, it parses the file structure and figure out which block on the DVD is actually in used, and only read those blocks from the DVD. This work surprisingly well, and I have been able to almost backup my entire DVD collection using this method.

So far, python-dvdvideo have failed on between 10 and 20 DVDs, which is a small fraction of my collection. The most common problem is DVDs using UTF-16 instead of UTF-8 characters, which according to Bastian is against the DVD specification (and seem to cause some players to fail too). A rarer problem is what seem to be inconsistent DVD structures, as the python library claim there is a overlap between objects. An equally rare problem claim some value is out of range. No idea what is going on there. I wish I knew enough about the DVD format to fix these, to ensure my movie collection will stay with me in the future.

So, if you need to keep your DVDs safe, back them up using python-dvdvideo. :)

Det offentlige Norge har mye kunnskap og informasjon. Men hvordan kan en få tilgang til den på en enkel måte? Takket være et lite knippe lover og tilhørende forskrifter, blant annet offentlighetsloven, miljøinformasjonsloven og forvaltningsloven har en rett til å spørre det offentlige og få svar. Men det finnes intet offentlig arkiv over hva andre har spurt om, og dermed risikerer en å måtte forstyrre myndighetene gang på gang for å få tak i samme informasjonen på nytt. Britiske mySociety har laget tjenesten WhatDoTheyKnow som gjør noe med dette. I Storbritannia blir WhatdoTheyKnow brukt i ca 15% av alle innsynsforespørsler mot sentraladministrasjonen. Prosjektet heter Alaveteli, og er takk i bruk en rekke steder etter at løsningen ble generalisert og gjort mulig å oversette. Den hjelper borgerne med å be om innsyn, rådgir ved purringer og klager og lar alle se hvilke henvendelser som er sendt til det offentlige og hvilke svar som er kommet inn, i et søkpart arkiv. Her i Norge holder vi i foreningen NUUG på å få opp en norsk utgave av Alaveteli, og her trenger vi din hjelp med oversettelsen.

Så langt er 76 % av Alaveteli oversatt til norsk bokmål, men vi skulle gjerne vært oppe i 100 % før lansering. Oversettelsen gjøres på Transifex, der enhver som registrerer seg og ber om tilgang til bokmålsoversettelsen får bidra. Vi har satt opp en test av tjenesten (som ikke sender epost til det offentlige, kun til oss som holder på å sette opp tjenesten) på maskinen alaveteli-dev.nuug.no, der en kan se hvordan de oversatte meldingen blir seende ut på nettsiden. Når tjenesten lanseres vil den hete Mimes brønn, etter visdomskilden som Odin måtte gi øyet sitt for å få drikke i. Den nettsiden er er ennå ikke klar til bruk.

Hvis noen vil oversette til nynorsk også, så skal vi finne ut hvordan vi lager en flerspråklig tjeneste. Men i første omgang er fokus på bokmålsoversettelsen, der vi selv har nok peiling til å ha fått oversatt 76%, men trenger hjelp for å komme helt i mål. :)

The Freedombox project is working on providing the software and hardware for making it easy for non-technical people to host their data and communication at home, and being able to communicate with their friends and family encrypted and away from prying eyes. It has been going on for a while, and is slowly progressing towards a new test release (0.2).

And what day could be better than the Pi day to announce that the new version will provide "hard drive" / SD card / USB stick images for Dreamplug, Raspberry Pi and VirtualBox (or any other virtualization system), and can also be installed using a Debian installer preseed file. The Debian based Freedombox is now based on Debian Jessie, where most of the needed packages used are already present. Only one, the freedombox-setup package, is missing. To try to build your own boot image to test the current status, fetch the freedom-maker scripts and build using vmdebootstrap with a user with sudo access to become root:

git clone http://anonscm.debian.org/git/freedombox/freedom-maker.git \
  freedom-maker
sudo apt-get install git vmdebootstrap mercurial python-docutils \
  mktorrent extlinux virtualbox qemu-user-static binfmt-support \
  u-boot-tools
make -C freedom-maker dreamplug-image raspberry-image virtualbox-image

Root access is needed to run debootstrap and mount loopback devices. See the README for more details on the build. If you do not want all three images, trim the make line. But note that thanks to a race condition in vmdebootstrap, the build might fail without the patch to the kpartx call.

If you instead want to install using a Debian CD and the preseed method, boot a Debian Wheezy ISO and use this boot argument to load the preseed values:

url=http://www.reinholdtsen.name/freedombox/preseed-jessie.dat

But note that due to a recently introduced bug in apt in Jessie, the installer will currently hang while setting up APT sources. Killing the 'apt-cdrom ident' process when it hang a few times during the installation will get the installation going. This affect all installations in Jessie, and I expect it will be fixed soon.

Give it a go and let us know how it goes on the mailing list, and help us get the new release published. :) Please join us on IRC (#freedombox on irc.debian.org) and the mailing list if you want to help make this vision come true.

On larger sites, it is useful to use a dedicated storage server for storing user home directories and data. The design for handling this in Debian Edu / Skolelinux, is to update the automount rules in LDAP and let the automount daemon on the clients take care of the rest. I was reminded about the need to document this better when one of the customers of Skolelinux Drift AS, where I am on the board of directors, asked about how to do this. The steps to get this working are the following:

1. Add new storage server in DNS. I use nas-server.intern as the example host here.
2. Add automoun LDAP information about this server in LDAP, to allow all clients to automatically mount it on reqeust.
3. Add the relevant entries in tjener.intern:/etc/fstab, because tjener.intern do not use automount to avoid mounting loops.

DNS entries are added in GOsa², and not described here. Follow the instructions in the manual (Machine Management with GOsa² in section Getting started).

Ensure that the NFS export points on the server are exported to the relevant subnets or machines:

root@tjener:~# showmount -e nas-server
Export list for nas-server:
/storage         10.0.0.0/8
root@tjener:~#

Here everything on the backbone network is granted access to the /storage export. With NFSv3 it is slightly better to limit it to netgroup membership or single IP addresses to have some limits on the NFS access.

The next step is to update LDAP. This can not be done using GOsa², because it lack a module for automount. Instead, use ldapvi and add the required LDAP objects using an editor.

ldapvi --ldap-conf -ZD '(cn=admin)' -b ou=automount,dc=skole,dc=skolelinux,dc=no

When the editor show up, add the following LDAP objects at the bottom of the document. The "/&" part in the last LDAP object is a wild card matching everything the nas-server exports, removing the need to list individual mount points in LDAP.

add cn=nas-server,ou=auto.skole,ou=automount,dc=skole,dc=skolelinux,dc=no
objectClass: automount
cn: nas-server
automountInformation: -fstype=autofs --timeout=60 ldap:ou=auto.nas-server,ou=automount,dc=skole,dc=skolelinux,dc=no

add ou=auto.nas-server,ou=automount,dc=skole,dc=skolelinux,dc=no
objectClass: top
objectClass: automountMap
ou: auto.nas-server

add cn=/,ou=auto.nas-server,ou=automount,dc=skole,dc=skolelinux,dc=no
objectClass: automount
cn: /
automountInformation: -fstype=nfs,tcp,rsize=32768,wsize=32768,rw,intr,hard,nodev,nosuid,noatime nas-server.intern:/&

The last step to remember is to mount the relevant mount points in tjener.intern by adding them to /etc/fstab, creating the mount directories using mkdir and running "mount -a" to mount them.

When this is done, your users should be able to access the files on the storage server directly by just visiting the /tjener/nas-server/storage/ directory using any application on any workstation, LTSP client or LTSP server.

For noen uker siden ble NXCs fri programvarelisenserte NOARK5-løsning presentert hos NUUG (video på youtube foreløbig), og det fikk meg til å titte litt mer på NOARK5, standarden for arkivhåndtering i det offentlige Norge. Jeg lurer på om denne kjernen kan være nyttig i et par av mine prosjekter, og for ett av dem er det mest aktuelt å lagre epost. Jeg klarte ikke finne noen anbefaling om hvordan RFC 822-formattert epost (aka Internett-epost) burde lagres i NOARK5, selv om jeg vet at noen arkiver tar PDF-utskrift av eposten med sitt epostprogram og så arkiverer PDF-en (eller enda værre, tar papirutskrift og lagrer bildet av eposten som PDF i arkivet).

Det er ikke så mange formater som er akseptert av riksarkivet til langtidsoppbevaring av offentlige arkiver, og PDF og XML er de mest aktuelle i så måte. Det slo meg at det måtte da finnes en eller annen egnet XML-representasjon og at det kanskje var enighet om hvilken som burde brukes, så jeg tok mot til meg og spurte SAMDOK, en gruppe tilknyttet arkivverket som ser ut til å jobbe med NOARK-samhandling, om de hadde noen anbefalinger:

Hei.

Usikker på om dette er riktig forum å ta opp mitt spørsmål, men jeg lurer på om det er definert en anbefaling om hvordan RFC 822-formatterte epost (aka vanlig Internet-epost) bør lages håndteres i NOARK5, slik at en bevarer all informasjon i eposten (f.eks. Received-linjer). Finnes det en anbefalt XML-mapping ala den som beskrives på <URL: https://www.informit.com/articles/article.aspx?p=32074 >? Mitt mål er at det skal være mulig å lagre eposten i en NOARK5-kjerne og kunne få ut en identisk formattert kopi av opprinnelig epost ved behov.

Postmottaker hos SAMDOK mente spørsmålet heller burde stilles direkte til riksarkivet, og jeg fikk i dag svar derfra formulert av seniorrådgiver Geir Ivar Tungesvik:

Riksarkivet har ingen anbefalinger når det gjelder konvertering fra e-post til XML. Det står arkivskaper fritt å eventuelt definere/bruke eget format. Inklusive da - som det spørres om - et format der det er mulig å re-etablere e-post format ut fra XML-en. XML (e-post) dokumenter må være referert i arkivstrukturen, og det må vedlegges et gyldig XML skjema (.xsd) for XML-filene. Arkivskaper står altså fritt til å gjøre hva de vil, bare det dokumenteres og det kan dannes et utrekk ved avlevering til depot.

De obligatoriske kravene i Noark 5 standarden må altså oppfylles - etter dialog med Riksarkivet i forbindelse med godkjenning. For offentlige arkiv er det særlig viktig med filene loependeJournal.xml og offentligJournal.xml. Private arkiv som vil forholde seg til Noark 5 standarden er selvsagt frie til å bruke det som er relevant for dem av obligatoriske krav.

Det ser dermed ut for meg som om det er et lite behov for å standardisere XML-lagring av RFC-822-formatterte meldinger. Noen som vet om god spesifikasjon i så måte? I tillegg til den omtalt over, har jeg kommet over flere aktuelle beskrivelser (søk på "rfc 822 xml", så finner du aktuelle alternativer).

• XML MIME Transformation protocol (XMTP) fra OpenHealth, sist oppdatert 2001.
• An XML format for mail and other messages utkast fra IETF datert 2001.
• xMail: E-mail as XML en artikkel fra 2003 som beskriver python-modulen rfc822 som gir ut XML-representasjon av en RFC 822-formattert epost.

Finnes det andre og bedre spesifikasjoner for slik lagring? Send meg en epost hvis du har innspill.