Jeg ble så imponert over -dagens -gladnyhet på NRK, om at Forbrukerrådet klager inn vilkårene for -bruk av aktivitetsbånd fra Fitbit, Garmin, Jawbone og Mio til -Datatilsynet og forbrukerombudet, at jeg sendte følgende brev til -forbrukerrådet for å uttrykke min støtte: +
+Did you ever wonder where the web trafic really flow to reach the +web servers, and who own the network equipment it is flowing through? +It is possible to get a glimpse of this from using traceroute, but it +is hard to find all the details. Many years ago, I wrote a system to +map the Norwegian Internet (trying to figure out if our plans for a +network game service would get low enough latency, and who we needed +to talk to about setting up game servers close to the users. Back +then I used traceroute output from many locations (I asked my friends +to run a script and send me their traceroute output) to create the +graph and the map. The output from traceroute typically look like +this: -
- -+Jeg ble veldig glad over å lese at Forbrukerrådet -klager -inn flere aktivitetsbånd til Datatilsynet for dårlige vilkår. Jeg -har ønsket meg et aktivitetsbånd som kan måle puls, bevegelse og -gjerne også andre helserelaterte indikatorer en stund nå. De eneste -jeg har funnet i salg gjør, som dere også har oppdaget, graverende -inngrep i privatsfæren og sender informasjonen ut av huset til folk og -organisasjoner jeg ikke ønsker å dele aktivitets- og helseinformasjon -med. Jeg ønsker et alternativ som _ikke_ sender informasjon til -skyen, men derimot bruker -en -fritt og åpent standardisert protokoll (eller i det minste en -dokumentert protokoll uten patent- og opphavsrettslige -bruksbegrensinger) til å kommunisere med datautstyr jeg kontrollerer. -Er jo ikke interessert i å betale noen for å tilrøve seg -personopplysninger fra meg. Desverre har jeg ikke funnet noe -alternativ så langt.
- -Det holder ikke å endre på bruksvilkårene for enhetene, slik -Datatilsynet ofte legger opp til i sin behandling, når de gjør slik -f.eks. Fitbit (den jeg har sett mest på). Fitbit krypterer -informasjonen på enheten og sender den kryptert til leverandøren. Det -gjør det i praksis umulig både å sjekke hva slags informasjon som -sendes over, og umulig å ta imot informasjonen selv i stedet for -Fitbit. Uansett hva slags historie som forteller i bruksvilkårene er -en jo både prisgitt leverandørens godvilje og at de ikke tvinges av -sitt lands myndigheter til å lyve til sine kunder om hvorvidt -personopplysninger spres ut over det bruksvilkårene sier. Det er -veldokumentert hvordan f.eks. USA tvinger selskaper vha. såkalte -National security letters til å utlevere personopplysninger samtidig -som de ikke får lov til å fortelle dette til kundene sine.
- -Stå på, jeg er veldig glade for at dere har sett på saken. Vet -dere om aktivitetsbånd i salg i dag som ikke tvinger en til å utlevere -aktivitets- og helseopplysninger med leverandøren?
++traceroute to www.stortinget.no (85.88.67.10), 30 hops max, 60 byte packets + 1 uio-gw10.uio.no (129.240.202.1) 0.447 ms 0.486 ms 0.621 ms + 2 uio-gw8.uio.no (129.240.24.229) 0.467 ms 0.578 ms 0.675 ms + 3 oslo-gw1.uninett.no (128.39.65.17) 0.385 ms 0.373 ms 0.358 ms + 4 te3-1-2.br1.fn3.as2116.net (193.156.90.3) 1.174 ms 1.172 ms 1.153 ms + 5 he16-1-1.cr1.san110.as2116.net (195.0.244.234) 2.627 ms he16-1-1.cr2.oslosda310.as2116.net (195.0.244.48) 3.172 ms he16-1-1.cr1.san110.as2116.net (195.0.244.234) 2.857 ms + 6 ae1.ar8.oslosda310.as2116.net (195.0.242.39) 0.662 ms 0.637 ms ae0.ar8.oslosda310.as2116.net (195.0.242.23) 0.622 ms + 7 89.191.10.146 (89.191.10.146) 0.931 ms 0.917 ms 0.955 ms + 8 * * * + 9 * * * +[...] +-
This show the DNS names and IP addresses of (at least some of the) +network equipment involved in getting the data traffic from me to the +www.stortinget.no server, and how long it took in milliseconds for a +package to reach the equipment and return to me. Three packages are +sent, and some times the packages do not follow the same path. This +is shown for hop 5, where three different IP addresses replied to the +traceroute request.
+ +There are many ways to measure trace routes. Other good traceroute +implementations I use are traceroute (using ICMP packages) mtr (can do +both ICMP, UDP and TCP) and scapy (python library with ICMP, UDP, TCP +traceroute and a lot of other capabilities). All of them are easily +available in Debian.
+ +This time around, I wanted to know the geographic location of +different route points, to visualize how visiting a web page spread +information about the visit to a lot of servers around the globe. The +background is that a web site today often will ask the browser to get +from many servers the parts (for example HTML, JSON, fonts, +JavaScript, CSS, video) required to display the content. This will +leak information about the visit to those controlling these servers +and anyone able to peek at the data traffic passing by (like your ISP, +the ISPs backbone provider, FRA, GCHQ, NSA and others).
+ +Lets pick an example, the Norwegian parliament web site +www.stortinget.no. It is read daily by all members of parliament and +their staff, as well as political journalists, activits and many other +citizens of Norway. A visit to the www.stortinget.no web site will +ask your browser to contact 8 other servers: ajax.googleapis.com, +insights.hotjar.com, script.hotjar.com, static.hotjar.com, +stats.g.doubleclick.net, www.google-analytics.com, +www.googletagmanager.com and www.netigate.se. I extracted this by +asking PhantomJS to visit the +Stortinget web page and tell me all the URLs PhantomJS downloaded to +render the page (in HAR format using +their +netsniff example. I am very grateful to Gorm for showing me how +to do this). My goal is to visualize network traces to all IP +addresses behind these DNS names, do show where visitors personal +information is spread when visiting the page.
+ + + +When I had a look around for options, I could not find any good +free software tools to do this, and decided I needed my own traceroute +wrapper outputting KML based on locations looked up using GeoIP. KML +is easy to work with and easy to generate, and understood by several +of the GIS tools I have available. I got good help from by NUUG +colleague Anders Einar with this, and the result can be seen in +my +kmltraceroute git repository. Unfortunately, the quality of the +free GeoIP databases I could find (and the for-pay databases my +friends had access to) is not up to the task. The IP addresses of +central Internet infrastructure would typically be placed near the +controlling companies main office, and not where the router is really +located, as you can see from the +KML file I created using the GeoLite City dataset from MaxMind. + +
+ +I also had a look at the visual traceroute graph created by +the scrapy project, +showing IP network ownership (aka AS owner) for the IP address in +question. +The +graph display a lot of useful information about the traceroute in SVG +format, and give a good indication on who control the network +equipment involved, but it do not include geolocation. This graph +make it possible to see the information is made available at least for +UNINETT, Catchcom, Stortinget, Nordunet, Google, Amazon, Telia, Level +3 Communications and NetDNA.
+ + + +In the process, I came across the +web service GeoTraceRoute by +Salim Gasmi. Its methology of combining guesses based on DNS names, +various location databases and finally use latecy times to rule out +candidate locations seemed to do a very good job of guessing correct +geolocation. But it could only do one trace at the time, did not have +a sensor in Norway and did not make the geolocations easily available +for postprocessing. So I contacted the developer and asked if he +would be willing to share the code (he refused until he had time to +clean it up), but he was interested in providing the geolocations in a +machine readable format, and willing to set up a sensor in Norway. So +since yesterday, it is possible to run traces from Norway in this +service thanks to a sensor node set up by +the NUUG assosiation, and get the +trace in KML format for further processing.
+ + + +Here we can see a lot of trafic passes Sweden on its way to +Denmark, Germany, Holland and Ireland. Plenty of places where the +Snowden confirmations verified the traffic is read by various actors +without your best interest as their top priority.
+ +Combining KML files is trivial using a text editor, so I could loop +over all the hosts behind the urls imported by www.stortinget.no and +ask for the KML file from geotraceroute, and create a combined KML +file with all the traces (unfortunately only one of the IP addresses +behind the DNS name is traced this time. To get them all, one would +have to request traces using IP number instead of DNS names from +geotraceroute). That might be the next step in this project.
+ +Armed with these tools, I find it a lot easier to figure out where +the IP traffic moves and who control the boxes involved in moving it. +And every time the link crosses for example the Swedish border, we can +be sure Swedish Signal Intelligence (FRA) is listening, as GCHQ do in +Britain and NSA in USA and cables around the globe. (Hm, what should +we tell them? :) Keep that in mind if you ever send anything +unencrypted over the Internet.
+ +PS: KML files are drawn using +the KML viewer from Ivan +Rublev, as it was less cluttered than the local Linux application +Marble. There are heaps of other options too.
-Jeg håper en konkurrent som respekterer kundenes privatliv klarer å -nå opp i markedet, slik at det finnes et reelt alternativ for oss som -har full tillit til at skyleverandører vil prioritere egen inntjening -og myndighetspålegg langt over kundenes rett til privatliv. Jeg har -ingen tiltro til at Datatilsynet vil kreve noe mer enn at vilkårene -endres slik at de forklarer eksplisitt i hvor stor grad bruk av -produktene utraderer privatsfæren til kundene. Det vil nok gjøre de -innklagede armbåndene "lovlige", men fortsatt tvinge kundene til å -dele sine personopplysninger med leverandøren.
+As usual, if you use Bitcoin and want to show your support of my +activities, please send Bitcoin donations to my address +15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b.
In July -I -wrote how to get the Signal Chrome/Chromium app working without -the ability to receive SMS messages (aka without a cell phone). It is -time to share some experiences and provide an updated setup.
- -The Signal app have worked fine for several months now, and I use -it regularly to chat with my loved ones. I had a major snag at the -end of my summer vacation, when the the app completely forgot my -setup, identity and keys. The reason behind this major mess was -running out of disk space. To avoid that ever happening again I have -started storing everything in userdata/ in git, to be able to -roll back to an earlier version if the files are wiped by mistake. I -had to use it once after introducing the git backup. When rolling -back to an earlier version, one need to use the 'reset session' option -in Signal to get going, and notify the people you talk with about the -problem. I assume there is some sequence number tracking in the -protocol to detect rollback attacks. The git repository is rather big -(674 MiB so far), but I have not tried to figure out if some of the -content can be added to a .gitignore file due to lack of spare -time.
- -I've also hit the 90 days timeout blocking, and noticed that this -make it impossible to send messages using Signal. I could still -receive them, but had to patch the code with a new timestamp to send. -I believe the timeout is added by the developers to force people to -upgrade to the latest version of the app, even when there is no -protocol changes, to reduce the version skew among the user base and -thus try to keep the number of support requests down.
- -Since my original recipe, the Signal source code changed slightly, -making the old patch fail to apply cleanly. Below is an updated -patch, including the shell wrapper I use to start Signal. The -original version required a new user to locate the JavaScript console -and call a function from there. I got help from a friend with more -JavaScript knowledge than me to modify the code to provide a GUI -button instead. This mean that to get started you just need to run -the wrapper and click the 'Register without mobile phone' to get going -now. I've also modified the timeout code to always set it to 90 days -in the future, to avoid having to patch the code regularly.
- -So, the updated recipe for Debian Jessie:
- --
-
-
- First, install required packages to get the source code and the
-browser you need. Signal only work with Chrome/Chromium, as far as I
-know, so you need to install it.
-
-
-apt install git tor chromium -git clone https://github.com/WhisperSystems/Signal-Desktop.git -
-
- - Modify the source code using command listed in the the patch -block below. - -
- Start Signal using the run-signal-app wrapper (for example using -`pwd`/run-signal-app). - -
- Click on the 'Register without mobile phone', will in a phone -number you can receive calls to the next minute, receive the -verification code and enter it into the form field and press -'Register'. Note, the phone number you use will be user Signal -username, ie the way others can find you on Signal. - -
- You can now use Signal to contact others. Note, new contacts do -not show up in the contact list until you restart Signal, and there is -no way to assign names to Contacts. There is also no way to create or -update chat groups. I suspect this is because the web app do not have -a associated contact database. - -
I am still a bit uneasy about using Signal, because of the way its -main author moxie0 reject federation and accept dependencies to major -corporations like Google (part of the code is fetched from Google) and -Amazon (the central coordination point is owned by Amazon). See for -example -the -LibreSignal issue tracker for a thread documenting the authors -view on these issues. But the network effect is strong in this case, -and several of the people I want to communicate with already use -Signal. Perhaps we can all move to Ring -once it work on my -laptop? It already work on Windows and Android, and is included -in Debian and -Ubuntu, but not -working on Debian Stable.
- -Anyway, this is the patch I apply to the Signal code to get it -working. It switch to the production servers, disable to timeout, -make registration easier and add the shell wrapper:
- --cd Signal-Desktop; cat <<EOF | patch -p1 -diff --git a/js/background.js b/js/background.js -index 24b4c1d..579345f 100644 ---- a/js/background.js -+++ b/js/background.js -@@ -33,9 +33,9 @@ - }); - }); - -- var SERVER_URL = 'https://textsecure-service-staging.whispersystems.org'; -+ var SERVER_URL = 'https://textsecure-service-ca.whispersystems.org'; - var SERVER_PORTS = [80, 4433, 8443]; -- var ATTACHMENT_SERVER_URL = 'https://whispersystems-textsecure-attachments-staging.s3.amazonaws.com'; -+ var ATTACHMENT_SERVER_URL = 'https://whispersystems-textsecure-attachments.s3.amazonaws.com'; - var messageReceiver; - window.getSocketStatus = function() { - if (messageReceiver) { -diff --git a/js/expire.js b/js/expire.js -index 639aeae..beb91c3 100644 ---- a/js/expire.js -+++ b/js/expire.js -@@ -1,6 +1,6 @@ - ;(function() { - 'use strict'; -- var BUILD_EXPIRATION = 0; -+ var BUILD_EXPIRATION = Date.now() + (90 * 24 * 60 * 60 * 1000); - - window.extension = window.extension || {}; - -diff --git a/js/views/install_view.js b/js/views/install_view.js -index 7816f4f..1d6233b 100644 ---- a/js/views/install_view.js -+++ b/js/views/install_view.js -@@ -38,7 +38,8 @@ - return { - 'click .step1': this.selectStep.bind(this, 1), - 'click .step2': this.selectStep.bind(this, 2), -- 'click .step3': this.selectStep.bind(this, 3) -+ 'click .step3': this.selectStep.bind(this, 3), -+ 'click .callreg': function() { extension.install('standalone') }, - }; - }, - clearQR: function() { -diff --git a/options.html b/options.html -index dc0f28e..8d709f6 100644 ---- a/options.html -+++ b/options.html -@@ -14,7 +14,10 @@ - <div class='nav'> - <h1>{{ installWelcome }}</h1> - <p>{{ installTagline }}</p> -- <div> <a class='button step2'>{{ installGetStartedButton }}</a> </div> -+ <div> <a class='button step2'>{{ installGetStartedButton }}</a> -+ <br> <a class="button callreg">Register without mobile phone</a> -+ -+ </div> - <span class='dot step1 selected'></span> - <span class='dot step2'></span> - <span class='dot step3'></span> ---- /dev/null 2016-10-07 09:55:13.730181472 +0200 -+++ b/run-signal-app 2016-10-10 08:54:09.434172391 +0200 -@@ -0,0 +1,12 @@ -+#!/bin/sh -+set -e -+cd $(dirname $0) -+mkdir -p userdata -+userdata="`pwd`/userdata" -+if [ -d "$userdata" ] && [ ! -d "$userdata/.git" ] ; then -+ (cd $userdata && git init) -+fi -+(cd $userdata && git add . && git commit -m "Current status." || true) -+exec chromium \ -+ --proxy-server="socks://localhost:9050" \ -+ --user-data-dir=$userdata --load-and-launch-app=`pwd` -EOF -chmod a+rx run-signal-app -+ +
Do you have a large iCalendar +file with lots of old entries, and would like to archive them to save +space and resources? At least those of us using KOrganizer know that +turning on and off an event set become slower and slower the more +entries are in the set. While working on migrating our calendars to a +Radicale CalDAV server on our +Freedombox server, my +loved one wondered if I could find a way to split up the calendar file +she had in KOrganizer, and I set out to write a tool. I spent a few +days writing and polishing the system, and it is now ready for general +consumption. The +code for +ical-archiver is publicly available from a git repository on +github. The system is written in Python and depend on +the vobject Python +module.
+ +To use it, locate the iCalendar file you want to operate on and +give it as an argument to the ical-archiver script. This will +generate a set of new files, one file per component type per year for +all components expiring more than two years in the past. The vevent, +vtodo and vjournal entries are handled by the script. The remaining +entries are stored in a 'remaining' file.
+ +This is what a test run can look like: + +
+% ical-archiver t/2004-2016.ics +Found 3612 vevents +Found 6 vtodos +Found 2 vjournals +Writing t/2004-2016.ics-subset-vevent-2004.ics +Writing t/2004-2016.ics-subset-vevent-2005.ics +Writing t/2004-2016.ics-subset-vevent-2006.ics +Writing t/2004-2016.ics-subset-vevent-2007.ics +Writing t/2004-2016.ics-subset-vevent-2008.ics +Writing t/2004-2016.ics-subset-vevent-2009.ics +Writing t/2004-2016.ics-subset-vevent-2010.ics +Writing t/2004-2016.ics-subset-vevent-2011.ics +Writing t/2004-2016.ics-subset-vevent-2012.ics +Writing t/2004-2016.ics-subset-vevent-2013.ics +Writing t/2004-2016.ics-subset-vevent-2014.ics +Writing t/2004-2016.ics-subset-vjournal-2007.ics +Writing t/2004-2016.ics-subset-vjournal-2011.ics +Writing t/2004-2016.ics-subset-vtodo-2012.ics +Writing t/2004-2016.ics-remaining.ics +% ++ +
As you can see, the original file is untouched and new files are +written with names derived from the original file. If you are happy +with their content, the *-remaining.ics file can replace the original +the the others can be archived or imported as historical calendar +collections.
+ +The script should probably be improved a bit. The error handling +when discovering broken entries is not good, and I am not sure yet if +it make sense to split different entry types into separate files or +not. The program is thus likely to change. If you find it +interesting, please get in touch. :)
As usual, if you use Bitcoin and want to show your support of my activities, please send Bitcoin donations to my address @@ -272,7 +255,7 @@ activities, please send Bitcoin donations to my address
@@ -280,129 +263,96 @@ activities, please send Bitcoin donations to my addressNRK -lanserte -for noen uker siden en ny -varslerportal som bruker -SecureDrop til å ta imot tips der det er vesentlig at ingen -utenforstående får vite at NRK er tipset. Det er et langt steg -fremover for NRK, og når en leser bloggposten om hva de har tenkt på -og hvordan løsningen er satt opp virker det som om de har gjort en -grundig jobb der. Men det er ganske mye ekstra jobb å motta tips via -SecureDrop, så varslersiden skriver "Nyhetstips som ikke krever denne -typen ekstra vern vil vi gjerne ha på nrk.no/03030", og 03030-siden -foreslår i tillegg til et webskjema å bruke epost, SMS, telefon, -personlig oppmøte og brevpost. Denne artikkelen handler disse andre -metodene.
- -Når en sender epost til en @nrk.no-adresse så vil eposten sendes ut -av landet til datamaskiner kontrollert av Microsoft. En kan sjekke -dette selv ved å slå opp epostleveringsadresse (MX) i DNS. For NRK er -dette i dag "nrk-no.mail.protection.outlook.com". NRK har som en ser -valgt å sette bort epostmottaket sitt til de som står bak outlook.com, -dvs. Microsoft. En kan sjekke hvor nettverkstrafikken tar veien -gjennom Internett til epostmottaket vha. programmet -traceroute, og finne ut hvem som eier en Internett-adresse -vha. whois-systemet. Når en gjør dette for epost-trafikk til @nrk.no -ser en at trafikken fra Norge mot nrk-no.mail.protection.outlook.com -går via Sverige mot enten Irland eller Tyskland (det varierer fra gang -til gang og kan endre seg over tid).
- -Vi vet fra -introduksjonen av -FRA-loven at IP-trafikk som passerer grensen til Sverige avlyttes -av Försvarets radioanstalt (FRA). Vi vet videre takket være -Snowden-bekreftelsene at trafikk som passerer grensen til -Storbritannia avlyttes av Government Communications Headquarters -(GCHQ). I tillegg er er det nettopp lansert et forslag i Norge om at -forsvarets E-tjeneste skal få avlytte trafikk som krysser grensen til -Norge. Jeg er ikke kjent med dokumentasjon på at Irland og Tyskland -gjør det samme. Poenget er uansett at utenlandsk etterretning har -mulighet til å snappe opp trafikken når en sender epost til @nrk.no. -I tillegg er det selvsagt tilgjengelig for Microsoft som er underlagt USAs -jurisdiksjon og -samarbeider -med USAs etterretning på flere områder. De som tipser NRK om -nyheter via epost kan dermed gå ut fra at det blir kjent for mange -andre enn NRK at det er gjort.
- -Bruk av SMS og telefon registreres av blant annet telefonselskapene -og er tilgjengelig i følge lov og forskrift for blant annet Politi, -NAV og Finanstilsynet, i tillegg til IT-folkene hos telefonselskapene -og deres overordnede. Hvis innringer eller mottaker bruker -smarttelefon vil slik kontakt også gjøres tilgjengelig for ulike -app-leverandører og de som lytter på trafikken mellom telefon og -app-leverandør, alt etter hva som er installert på telefonene som -brukes.
- -Brevpost kan virke trygt, og jeg vet ikke hvor mye som registreres -og lagres av postens datastyrte postsorteringssentraler. Det vil ikke -overraske meg om det lagres hvor i landet hver konvolutt kommer fra og -hvor den er adressert, i hvert fall for en kortere periode. Jeg vet -heller ikke hvem slik informasjon gjøres tilgjengelig for. Det kan -være nok til å ringe inn potensielle kilder når det krysses med hvem -som kjente til aktuell informasjon og hvor de befant seg (tilgjengelig -f.eks. hvis de bærer mobiltelefon eller bor i nærheten).
- -Personlig oppmøte hos en NRK-journalist er antagelig det tryggeste, -men en bør passe seg for å bruke NRK-kantina. Der bryter de nemlig -Sentralbanklovens -paragraf 14 og nekter folk å betale med kontanter. I stedet -krever de at en varsle sin bankkortutsteder om hvor en befinner seg -ved å bruke bankkort. Banktransaksjoner er tilgjengelig for -bankkortutsteder (det være seg VISA, Mastercard, Nets og/eller en -bank) i tillegg til politiet og i hvert fall tidligere med Se & Hør -(via utro tjenere, slik det ble avslørt etter utgivelsen av boken -«Livet, det forbannede» av Ken B. Rasmussen). Men hvor mange kjenner -en NRK-journalist personlig? Besøk på NRK på Marienlyst krever at en -registrerer sin ankost elektronisk i besøkssystemet. Jeg vet ikke hva -som skjer med det datasettet, men har grunn til å tro at det sendes ut -SMS til den en skal besøke med navnet som er oppgitt. Kanskje greit å -oppgi falskt navn.
- -Når så tipset er kommet frem til NRK skal det behandles -redaksjonelt i NRK. Der vet jeg via ulike kilder at de fleste -journalistene bruker lokalt installert programvare, men noen bruker -Google Docs og andre skytjenester i strid med interne retningslinjer -når de skriver. Hvordan vet en hvem det gjelder? Ikke vet jeg, men -det kan være greit å spørre for å sjekke at journalisten har tenkt på -problemstillingen, før en gir et tips. Og hvis tipset omtales internt -på epost, er det jo grunn til å tro at også intern eposten vil deles -med Microsoft og utenlands etterretning, slik tidligere nevnt, men det -kan hende at det holdes internt i NRKs interne MS Exchange-løsning. -Men Microsoft ønsker å få alle Exchange-kunder over "i skyen" (eller -andre folks datamaskiner, som det jo innebærer), så jeg vet ikke hvor -lenge det i så fall vil vare.
- -I tillegg vet en jo at -NRK -har valgt å gi nasjonal sikkerhetsmyndighet (NSM) tilgang til å se på -intern og ekstern Internett-trafikk hos NRK ved oppsett av såkalte -VDI-noder, på tross av -protester -fra NRKs journalistlag. Jeg vet ikke om den vil kunne snappe opp -dokumenter som lagres på interne filtjenere eller dokumenter som lages -i de interne webbaserte publiseringssystemene, men vet at hva noden -ser etter på nettet kontrolleres av NSM og oppdateres automatisk, slik -at det ikke gir så mye mening å sjekke hva noden ser etter i dag når -det kan endres automatisk i morgen.
- -Personlig vet jeg ikke om jeg hadde turt tipse NRK hvis jeg satt på -noe som kunne være en trussel mot den bestående makten i Norge eller -verden. Til det virker det å være for mange åpninger for -utenforstående med andre prioriteter enn NRKs journalistiske fokus. -Og den største truslen for en varsler er jo om metainformasjon kommer -på avveie, dvs. informasjon om at en har vært i kontakt med en -journalist. Det kan være nok til at en kommer i myndighetenes -søkelys, og de færreste har nok operasjonell sikkerhet til at vil tåle -slik flombelysning på sitt privatliv.
+ +I received a very nice Christmas present today. As my regular +readers probably know, I have been working on the +the Isenkram +system for many years. The goal of the Isenkram system is to make +it easier for users to figure out what to install to get a given piece +of hardware to work in Debian, and a key part of this system is a way +to map hardware to packages. Isenkram have its own mapping database, +and also uses data provided by each package using the AppStream +metadata format. And today, +AppStream in +Debian learned to look up hardware the same way Isenkram is doing it, +ie using fnmatch():
+ ++% appstreamcli what-provides modalias \ + usb:v1130p0202d0100dc00dsc00dp00ic03isc00ip00in00 +Identifier: pymissile [generic] +Name: pymissile +Summary: Control original Striker USB Missile Launcher +Package: pymissile +% appstreamcli what-provides modalias usb:v0694p0002d0000 +Identifier: libnxt [generic] +Name: libnxt +Summary: utility library for talking to the LEGO Mindstorms NXT brick +Package: libnxt +--- +Identifier: t2n [generic] +Name: t2n +Summary: Simple command-line tool for Lego NXT +Package: t2n +--- +Identifier: python-nxt [generic] +Name: python-nxt +Summary: Python driver/interface/wrapper for the Lego Mindstorms NXT robot +Package: python-nxt +--- +Identifier: nbc [generic] +Name: nbc +Summary: C compiler for LEGO Mindstorms NXT bricks +Package: nbc +% ++ +
A similar query can be done using the combined AppStream and +Isenkram databases using the isenkram-lookup tool:
+ ++% isenkram-lookup usb:v1130p0202d0100dc00dsc00dp00ic03isc00ip00in00 +pymissile +% isenkram-lookup usb:v0694p0002d0000 +libnxt +nbc +python-nxt +t2n +% ++ +
You can find modalias values relevant for your machine using +cat $(find /sys/devices/ -name modalias). + +
If you want to make this system a success and help Debian users +make the most of the hardware they have, please +helpadd +AppStream metadata for your package following the guidelines +documented in the wiki. So far only 11 packages provide such +information, among the several hundred hardware specific packages in +Debian. The Isenkram database on the other hand contain 101 packages, +mostly related to USB dongles. Most of the packages with hardware +mapping in AppStream are LEGO Mindstorms related, because I have, as +part of my involvement in +the Debian LEGO +team given priority to making sure LEGO users get proposed the +complete set of packages in Debian for that particular hardware. The +team also got a nice Christmas present today. The +nxt-firmware +package made it into Debian. With this package in place, it is +now possible to use the LEGO Mindstorms NXT unit with only free +software, as the nxt-firmware package contain the source and firmware +binaries for the NXT brick.
+ +As usual, if you use Bitcoin and want to show your support of my +activities, please send Bitcoin donations to my address +15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b.
The Isenkram -system provide a practical and easy way to figure out which -packages support the hardware in a given machine. The command line -tool isenkram-lookup and the tasksel options provide a -convenient way to list and install packages relevant for the current -hardware during system installation, both user space packages and -firmware packages. The GUI background daemon on the other hand provide -a pop-up proposing to install packages when a new dongle is inserted -while using the computer. For example, if you plug in a smart card -reader, the system will ask if you want to install pcscd if -that package isn't already installed, and if you plug in a USB video -camera the system will ask if you want to install cheese if -cheese is currently missing. This already work just fine.
- -But Isenkram depend on a database mapping from hardware IDs to -package names. When I started no such database existed in Debian, so -I made my own data set and included it with the isenkram package and -made isenkram fetch the latest version of this database from git using -http. This way the isenkram users would get updated package proposals -as soon as I learned more about hardware related packages.
- -The hardware is identified using modalias strings. The modalias -design is from the Linux kernel where most hardware descriptors are -made available as a strings that can be matched using filename style -globbing. It handle USB, PCI, DMI and a lot of other hardware related -identifiers.
- -The downside to the Isenkram specific database is that there is no -information about relevant distribution / Debian version, making -isenkram propose obsolete packages too. But along came AppStream, a -cross distribution mechanism to store and collect metadata about -software packages. When I heard about the proposal, I contacted the -people involved and suggested to add a hardware matching rule using -modalias strings in the specification, to be able to use AppStream for -mapping hardware to packages. This idea was accepted and AppStream is -now a great way for a package to announce the hardware it support in a -distribution neutral way. I wrote -a -recipe on how to add such meta-information in a blog post last -December. If you have a hardware related package in Debian, please -announce the relevant hardware IDs using AppStream.
- -In Debian, almost all packages that can talk to a LEGO Mindestorms -RCX or NXT unit, announce this support using AppStream. The effect is -that when you insert such LEGO robot controller into your Debian -machine, Isenkram will propose to install the packages needed to get -it working. The intention is that this should allow the local user to -start programming his robot controller right away without having to -guess what packages to use or which permissions to fix.
- -But when I sat down with my son the other day to program our NXT -unit using his Debian Stretch computer, I discovered something -annoying. The local console user (ie my son) did not get access to -the USB device for programming the unit. This used to work, but no -longer in Jessie and Stretch. After some investigation and asking -around on #debian-devel, I discovered that this was because udev had -changed the mechanism used to grant access to local devices. The -ConsoleKit mechanism from /lib/udev/rules.d/70-udev-acl.rules -no longer applied, because LDAP users no longer was added to the -plugdev group during login. Michael Biebl told me that this method -was obsolete and the new method used ACLs instead. This was good -news, as the plugdev mechanism is a mess when using a remote user -directory like LDAP. Using ACLs would make sure a user lost device -access when she logged out, even if the user left behind a background -process which would retain the plugdev membership with the ConsoleKit -setup. Armed with this knowledge I moved on to fix the access problem -for the LEGO Mindstorms related packages.
- -The new system uses a udev tag, 'uaccess'. It can either be -applied directly for a device, or is applied in -/lib/udev/rules.d/70-uaccess.rules for classes of devices. As the -LEGO Mindstorms udev rules did not have a class, I decided to add the -tag directly in the udev rules files included in the packages. Here -is one example. For the nqc C compiler for the RCX, the -/lib/udev/rules.d/60-nqc.rules file now look like this: +system I wrote two years ago to make it easier in Debian to find +and install packages to get your hardware dongles to work, is still +going strong. It is a system to look up the hardware present on or +connected to the current system, and map the hardware to Debian +packages. It can either be done using the tools in isenkram-cli or +using the user space daemon in the isenkram package. The latter will +notify you, when inserting new hardware, about what packages to +install to get the dongle working. It will even provide a button to +click on to ask packagekit to install the packages.
+ +Here is an command line example from my Thinkpad laptop:
-SUBSYSTEM=="usb", ACTION=="add", ATTR{idVendor}=="0694", ATTR{idProduct}=="0001", \ - SYMLINK+="rcx-%k", TAG+="uaccess" +% isenkram-lookup +bluez +cheese +ethtool +fprintd +fprintd-demo +gkrellm-thinkbat +hdapsd +libpam-fprintd +pidgin-blinklight +thinkfan +tlp +tp-smapi-dkms +tp-smapi-source +tpb +%-
The key part is the 'TAG+="uaccess"' at the end. I suspect all -packages using plugdev in their /lib/udev/rules.d/ files should be -changed to use this tag (either directly or indirectly via -70-uaccess.rules). Perhaps a lintian check should be created -to detect this?
- -I've been unable to find good documentation on the uaccess feature. -It is unclear to me if the uaccess tag is an internal implementation -detail like the udev-acl tag used by -/lib/udev/rules.d/70-udev-acl.rules. If it is, I guess the -indirect method is the preferred way. Michael -asked for more -documentation from the systemd project and I hope it will make -this clearer. For now I use the generic classes when they exist and -is already handled by 70-uaccess.rules, and add the tag -directly if no such class exist.
- -To learn more about the isenkram system, please check out -my -blog posts tagged isenkram.
- -To help out making life for LEGO constructors in Debian easier, -please join us on our IRC channel -#debian-lego and join -the Debian -LEGO team in the Alioth project we created yesterday. A mailing -list is not yet created, but we are working on it. :)
+It can also list the firware package providing firmware requested +by the load kernel modules, which in my case is an empty list because +I have all the firmware my machine need: -
As usual, if you use Bitcoin and want to show your support of my -activities, please send Bitcoin donations to my address -15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b.
++% /usr/sbin/isenkram-autoinstall-firmware -l +info: did not find any firmware files requested by loaded kernel modules. exiting +% ++ +
The last few days I had a look at several of the around 250 +packages in Debian with udev rules. These seem like good candidates +to install when a given hardware dongle is inserted, and I found +several that should be proposed by isenkram. I have not had time to +check all of them, but am happy to report that now there are 97 +packages packages mapped to hardware by Isenkram. 11 of these +packages provide hardware mapping using AppStream, while the rest are +listed in the modaliases file provided in isenkram.
+ +These are the packages with hardware mappings at the moment. The +marked packages are also announcing their hardware +support using AppStream, for everyone to use:
+ +air-quality-sensor, alsa-firmware-loaders, argyll, +array-info, avarice, avrdude, b43-fwcutter, +bit-babbler, bluez, bluez-firmware, brltty, +broadcom-sta-dkms, calibre, cgminer, cheese, colord, +colorhug-client, dahdi-firmware-nonfree, dahdi-linux, +dfu-util, dolphin-emu, ekeyd, ethtool, firmware-ipw2x00, fprintd, +fprintd-demo, galileo, gkrellm-thinkbat, gphoto2, +gpsbabel, gpsbabel-gui, gpsman, gpstrans, gqrx-sdr, gr-fcdproplus, +gr-osmosdr, gtkpod, hackrf, hdapsd, hdmi2usb-udev, hpijs-ppds, hplip, +ipw3945-source, ipw3945d, kde-config-tablet, kinect-audio-setup, +libnxt, libpam-fprintd, lomoco, +madwimax, minidisc-utils, mkgmap, msi-keyboard, mtkbabel, +nbc, nqc, nut-hal-drivers, ola, +open-vm-toolbox, open-vm-tools, openambit, pcgminer, pcmciautils, +pcscd, pidgin-blinklight, printer-driver-splix, +pymissile, python-nxt, qlandkartegt, +qlandkartegt-garmin, rosegarden, rt2x00-source, sispmctl, +soapysdr-module-hackrf, solaar, squeak-plugins-scratch, sunxi-tools, +t2n, thinkfan, thinkfinger-tools, tlp, tp-smapi-dkms, +tp-smapi-source, tpb, tucnak, uhd-host, usbmuxd, viking, +virtualbox-ose-guest-x11, w1retap, xawtv, xserver-xorg-input-vmmouse, +xserver-xorg-input-wacom, xserver-xorg-video-qxl, +xserver-xorg-video-vmware, yubikey-personalization and +zd1211-firmware
+ +If you know of other packages, please let me know with a wishlist +bug report against the isenkram-cli package, and ask the package +maintainer to +add AppStream +metadata according to the guidelines to provide the information +for everyone. In time, I hope to get rid of the isenkram specific +hardware mapping and depend exclusively on AppStream.
+ +Note, the AppStream metadata for broadcom-sta-dkms is matching too +much hardware, and suggest that the package with with any ethernet +card. See bug #838735 for +the details. I hope the maintainer find time to address it soon. In +the mean time I provide an override in isenkram.