- <title>Introducing ical-archiver to split out old iCalendar entries</title>
- <link>http://people.skolelinux.org/pere/blog/Introducing_ical_archiver_to_split_out_old_iCalendar_entries.html</link>
- <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Introducing_ical_archiver_to_split_out_old_iCalendar_entries.html</guid>
- <pubDate>Wed, 4 Jan 2017 12:20:00 +0100</pubDate>
- <description><p>Do you have a large <a href="https://icalendar.org/">iCalendar</a>
-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
-<a href="http://radicale.org/">Radicale CalDAV server</a> on our
-<a href="https://freedomboxfoundation.org/">Freedombox server</a/>, 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
-<a href="https://github.com/petterreinholdtsen/ical-archiver">code for
-ical-archiver</a> is publicly available from a git repository on
-github. The system is written in Python and depend on
-<a href="http://eventable.github.io/vobject/">the vobject Python
-module</a>.</p>
-
-<p>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.</p>
-
-<p>This is what a test run can look like:
-
-<p><pre>
-% 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
-%
-</pre></p>
-
-<p>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.</p>
-
-<p>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. :)</p>
-
-<p>As usual, if you use Bitcoin and want to show your support of my
-activities, please send Bitcoin donations to my address
-<b><a href="bitcoin:15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b&label=PetterReinholdtsenBlog">15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b</a></b>.</p>
-</description>
- </item>
-
- <item>
- <title>Appstream just learned how to map hardware to packages too!</title>
- <link>http://people.skolelinux.org/pere/blog/Appstream_just_learned_how_to_map_hardware_to_packages_too_.html</link>
- <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Appstream_just_learned_how_to_map_hardware_to_packages_too_.html</guid>
- <pubDate>Fri, 23 Dec 2016 10:30:00 +0100</pubDate>
- <description><p>I received a very nice Christmas present today. As my regular
-readers probably know, I have been working on the
-<a href="http://packages.qa.debian.org/isenkram">the Isenkram
-system</a> 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,
-<a href="https://tracker.debian.org/pkg/appstream">AppStream</a> in
-Debian learned to look up hardware the same way Isenkram is doing it,
-ie using fnmatch():</p>
-
-<p><pre>
-% 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
-%
-</pre></p>
-
-<p>A similar query can be done using the combined AppStream and
-Isenkram databases using the isenkram-lookup tool:</p>
-
-<p><pre>
-% isenkram-lookup usb:v1130p0202d0100dc00dsc00dp00ic03isc00ip00in00
-pymissile
-% isenkram-lookup usb:v0694p0002d0000
-libnxt
-nbc
-python-nxt
-t2n
-%
-</pre></p>
-
-<p>You can find modalias values relevant for your machine using
-<tt>cat $(find /sys/devices/ -name modalias)</tt>.
-
-<p>If you want to make this system a success and help Debian users
-make the most of the hardware they have, please
-help<a href="https://wiki.debian.org/AppStream/Guidelines">add
-AppStream metadata for your package following the guidelines</a>
-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
-<a href="https://wiki.debian.org/LegoDesigners">the Debian LEGO
-team</a> 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
-<a href="https://tracker.debian.org/pkg/nxt-firmware">nxt-firmware
-package</a> 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.</p>
-
-<p>As usual, if you use Bitcoin and want to show your support of my
-activities, please send Bitcoin donations to my address
-<b><a href="bitcoin:15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b&label=PetterReinholdtsenBlog">15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b</a></b>.</p>
-</description>
- </item>
-
- <item>
- <title>Isenkram updated with a lot more hardware-package mappings</title>
- <link>http://people.skolelinux.org/pere/blog/Isenkram_updated_with_a_lot_more_hardware_package_mappings.html</link>
- <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Isenkram_updated_with_a_lot_more_hardware_package_mappings.html</guid>
- <pubDate>Tue, 20 Dec 2016 11:55:00 +0100</pubDate>
- <description><p><a href="http://packages.qa.debian.org/isenkram">The Isenkram
-system</a> 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.</p>
-
-<p>Here is an command line example from my Thinkpad laptop:</p>
-
-<p><pre>
-% isenkram-lookup
-bluez
-cheese
-ethtool
-fprintd
-fprintd-demo
-gkrellm-thinkbat
-hdapsd
-libpam-fprintd
-pidgin-blinklight
-thinkfan
-tlp
-tp-smapi-dkms
-tp-smapi-source
-tpb
-%
-</pre></p>
-
-<p>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:
-
-<p><pre>
-% /usr/sbin/isenkram-autoinstall-firmware -l
-info: did not find any firmware files requested by loaded kernel modules. exiting
-%
-</pre></p>
-
-<p>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.</p>
-
-<p>These are the packages with hardware mappings at the moment. The
-<strong>marked packages</strong> are also announcing their hardware
-support using AppStream, for everyone to use:</p>
-
-<p>air-quality-sensor, alsa-firmware-loaders, argyll,
-<strong>array-info</strong>, avarice, avrdude, b43-fwcutter,
-bit-babbler, bluez, bluez-firmware, <strong>brltty</strong>,
-<strong>broadcom-sta-dkms</strong>, calibre, cgminer, cheese, colord,
-<strong>colorhug-client</strong>, dahdi-firmware-nonfree, dahdi-linux,
-dfu-util, dolphin-emu, ekeyd, ethtool, firmware-ipw2x00, fprintd,
-fprintd-demo, <strong>galileo</strong>, 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,
-<strong>libnxt</strong>, libpam-fprintd, <strong>lomoco</strong>,
-madwimax, minidisc-utils, mkgmap, msi-keyboard, mtkbabel,
-<strong>nbc</strong>, <strong>nqc</strong>, nut-hal-drivers, ola,
-open-vm-toolbox, open-vm-tools, openambit, pcgminer, pcmciautils,
-pcscd, pidgin-blinklight, printer-driver-splix,
-<strong>pymissile</strong>, python-nxt, qlandkartegt,
-qlandkartegt-garmin, rosegarden, rt2x00-source, sispmctl,
-soapysdr-module-hackrf, solaar, squeak-plugins-scratch, sunxi-tools,
-<strong>t2n</strong>, 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</p>
-
-<p>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
-<a href="https://wiki.debian.org/AppStream/Guidelines">add AppStream
-metadata according to the guidelines</a> to provide the information
-for everyone. In time, I hope to get rid of the isenkram specific
-hardware mapping and depend exclusively on AppStream.</p>
-
-<p>Note, the AppStream metadata for broadcom-sta-dkms is matching too
-much hardware, and suggest that the package with with any ethernet
-card. See <a href="http://bugs.debian.org/838735">bug #838735</a> for
-the details. I hope the maintainer find time to address it soon. In
-the mean time I provide an override in isenkram.</p>
+ <title>Idea for storing trusted timestamps in a Noark 5 archive</title>
+ <link>http://people.skolelinux.org/pere/blog/Idea_for_storing_trusted_timestamps_in_a_Noark_5_archive.html</link>
+ <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Idea_for_storing_trusted_timestamps_in_a_Noark_5_archive.html</guid>
+ <pubDate>Wed, 7 Jun 2017 21:40:00 +0200</pubDate>
+ <description><p><em>This is a copy of
+<a href="https://lists.nuug.no/pipermail/nikita-noark/2017-June/000297.html">an
+email I posted to the nikita-noark mailing list</a>. Please follow up
+there if you would like to discuss this topic. The background is that
+we are making a free software archive system based on the Norwegian
+<a href="https://www.arkivverket.no/forvaltning-og-utvikling/regelverk-og-standarder/noark-standarden">Noark
+5 standard</a> for government archives.</em></p>
+
+<p>I've been wondering a bit lately how trusted timestamps could be
+stored in Noark 5.
+<a href="https://en.wikipedia.org/wiki/Trusted_timestamping">Trusted
+timestamps</a> can be used to verify that some information
+(document/file/checksum/metadata) have not been changed since a
+specific time in the past. This is useful to verify the integrity of
+the documents in the archive.</p>
+
+<p>Then it occured to me, perhaps the trusted timestamps could be
+stored as dokument variants (ie dokumentobjekt referered to from
+dokumentbeskrivelse) with the filename set to the hash it is
+stamping?</p>
+
+<p>Given a "dokumentbeskrivelse" with an associated "dokumentobjekt",
+a new dokumentobjekt is associated with "dokumentbeskrivelse" with the
+same attributes as the stamped dokumentobjekt except these
+attributes:</p>
+
+<ul>
+
+<li>format -> "RFC3161"
+<li>mimeType -> "application/timestamp-reply"
+<li>formatDetaljer -> "&lt;source URL for timestamp service&gt;"
+<li>filenavn -> "&lt;sjekksum&gt;.tsr"
+
+</ul>
+
+<p>This assume a service following
+<a href="https://tools.ietf.org/html/rfc3161">IETF RFC 3161</a> is
+used, which specifiy the given MIME type for replies and the .tsr file
+ending for the content of such trusted timestamp. As far as I can
+tell from the Noark 5 specifications, it is OK to have several
+variants/renderings of a dokument attached to a given
+dokumentbeskrivelse objekt. It might be stretching it a bit to make
+some of these variants represent crypto-signatures useful for
+verifying the document integrity instead of representing the dokument
+itself.</p>
+
+<p>Using the source of the service in formatDetaljer allow several
+timestamping services to be used. This is useful to spread the risk
+of key compromise over several organisations. It would only be a
+problem to trust the timestamps if all of the organisations are
+compromised.</p>
+
+<p>The following oneliner on Linux can be used to generate the tsr
+file. $input is the path to the file to checksum, and $sha256 is the
+SHA-256 checksum of the file (ie the "<sjekksum>.tsr" value mentioned
+above).</p>
+
+<p><blockquote><pre>
+openssl ts -query -data "$inputfile" -cert -sha256 -no_nonce \
+ | curl -s -H "Content-Type: application/timestamp-query" \
+ --data-binary "@-" http://zeitstempel.dfn.de > $sha256.tsr
+</pre></blockquote></p>
+
+<p>To verify the timestamp, you first need to download the public key
+of the trusted timestamp service, for example using this command:</p>
+
+<p><blockquote><pre>
+wget -O ca-cert.txt \
+ https://pki.pca.dfn.de/global-services-ca/pub/cacert/chain.txt
+</pre></blockquote></p>
+
+<p>Note, the public key should be stored alongside the timestamps in
+the archive to make sure it is also available 100 years from now. It
+is probably a good idea to standardise how and were to store such
+public keys, to make it easier to find for those trying to verify
+documents 100 or 1000 years from now. :)</p>
+
+<p>The verification itself is a simple openssl command:</p>
+
+<p><blockquote><pre>
+openssl ts -verify -data $inputfile -in $sha256.tsr \
+ -CAfile ca-cert.txt -text
+</pre></blockquote></p>
+
+<p>Is there any reason this approach would not work? Is it somehow against
+the Noark 5 specification?</p>