Generated.

[homepage.git] / blog / archive / 2014 / 11 / 11.rss

<?xml version="1.0" encoding="ISO-8859-1"?>
<rss version='2.0' xmlns:lj='http://www.livejournal.org/rss/lj/1.0/'>
        <channel>
                <title>Petter Reinholdtsen - Entries from November 2014</title>
                <description>Entries from November 2014</description>
                <link>http://www.hungry.com/~pere/blog/</link>

        
        <item>
                <title>How to stay with sysvinit in Debian Jessie</title>
                <link>http://www.hungry.com/~pere/blog/How_to_stay_with_sysvinit_in_Debian_Jessie.html</link>        
                <guid isPermaLink="true">http://www.hungry.com/~pere/blog/How_to_stay_with_sysvinit_in_Debian_Jessie.html</guid>
                <pubDate>Sat, 22 Nov 2014 01:00:00 +0100</pubDate>
                <description>&lt;p&gt;By now, it is well known that Debian Jessie will not be using
sysvinit as its boot system by default.  But how can one keep using
sysvinit in Jessie?  It is fairly easy, and here are a few recipes,
courtesy of
&lt;a href=&quot;http://www.vitavonni.de/blog/201410/2014102101-avoiding-systemd.html&quot;&gt;Erich
Schubert&lt;/a&gt; and
&lt;a href=&quot;http://smcv.pseudorandom.co.uk/2014/still_universal/&quot;&gt;Simon
McVittie&lt;/a&gt;.

&lt;p&gt;If you already are using Wheezy and want to upgrade to Jessie and
keep sysvinit as your boot system, create a file
&lt;tt&gt;/etc/apt/preferences.d/use-sysvinit&lt;/tt&gt; with this content before
you upgrade:&lt;/p&gt;

&lt;p&gt;&lt;blockquote&gt;&lt;pre&gt;
Package: systemd-sysv
Pin: release o=Debian
Pin-Priority: -1
&lt;/pre&gt;&lt;/blockquote&gt;&lt;p&gt;

&lt;p&gt;This file content will tell apt and aptitude to not consider
installing systemd-sysv as part of any installation and upgrade
solution when resolving dependencies, and thus tell it to avoid
systemd as a default boot system.  The end result should be that the
upgraded system keep using sysvinit.&lt;/p&gt;

&lt;p&gt;If you are installing Jessie for the first time, there is no way to
get sysvinit installed by default (debootstrap used by
debian-installer have no option for this), but one can tell the
installer to switch to sysvinit before the first boot.  Either by
using a kernel argument to the installer, or by adding a line to the
preseed file used.  First, the kernel command line argument:

&lt;p&gt;&lt;blockquote&gt;&lt;pre&gt;
preseed/late_command=&quot;in-target apt-get install --purge -y sysvinit-core&quot;
&lt;/pre&gt;&lt;/blockquote&gt;&lt;p&gt;

&lt;p&gt;Next, the line to use in a preseed file:&lt;/p&gt;

&lt;p&gt;&lt;blockquote&gt;&lt;pre&gt;
d-i preseed/late_command string in-target apt-get install -y sysvinit-core
&lt;/pre&gt;&lt;/blockquote&gt;&lt;p&gt;

&lt;p&gt;One can of course also do this after the first boot by installing
the sysvinit-core package.&lt;/p&gt;

&lt;p&gt;I recommend only using sysvinit if you really need it, as the
sysvinit boot sequence in Debian have several hardware specific bugs
on Linux caused by the fact that it is unpredictable when hardware
devices show up during boot.  But on the other hand, the new default
boot system still have a few rough edges I hope will be fixed before
Jessie is released.&lt;/p&gt;

&lt;p&gt;Update 2014-11-26: Inspired by
&lt;ahref=&quot;https://www.mirbsd.org/permalinks/wlog-10-tg_e20141125-tg.htm#e20141125-tg_wlog-10-tg&quot;&gt;a
blog post by Torsten Glaser&lt;/a&gt;, added --purge to the preseed
line.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>Hvordan vurderer regjeringen H.264-patentutfordringen?</title>
                <link>http://www.hungry.com/~pere/blog/Hvordan_vurderer_regjeringen_H_264_patentutfordringen_.html</link>        
                <guid isPermaLink="true">http://www.hungry.com/~pere/blog/Hvordan_vurderer_regjeringen_H_264_patentutfordringen_.html</guid>
                <pubDate>Sun, 16 Nov 2014 10:30:00 +0100</pubDate>
                <description>&lt;p&gt;For en stund tilbake spurte jeg Fornyingsdepartementet om hvilke
juridiske vurderinger rundt patentproblemstillingen som var gjort da
H.264 ble tatt inn i &lt;a href=&quot;http://standard.difi.no/&quot;&gt;statens
referansekatalog over standarder&lt;/a&gt;.  Stig Hornnes i FAD tipset meg
om følgende som står i oppsumeringen til høringen om
referansekatalogen versjon 2.0, som jeg siden ved hjelp av en
innsynsforespørsel fikk tak i
&lt;a href=&quot;http://wiki.nuug.no/uttalelser/200901-standardkatalog-v2?action=AttachFile&amp;do=get&amp;target=kongelig-resolusjon.pdf&quot;&gt;PDF-utgaven av&lt;/a&gt;
datert 2009-06-03 (saksnummer 200803291, saksbehandler Henrik
Linnestad).&lt;/p&gt;

&lt;p&gt;Der står det følgende om problemstillingen:&lt;/p&gt;

&lt;p&gt;&lt;blockquote&gt;
&lt;strong&gt;4.4 Patentproblematikk&lt;/strong&gt;

&lt;p&gt;NUUG og Opera ser det som særlig viktig at forslagene knyttet til
lyd og video baserer seg på de royalty-frie standardene Vorbis, Theora
og FLAC.&lt;/p&gt;

&lt;p&gt;Kommentarene relaterer seg til at enkelte standarder er åpne, men
inneholder tekniske prosedyrer som det i USA (og noen andre land som
Japan) er gitt patentrettigheter til. I vårt tilfelle berører dette
spesielt standardene Mp3 og H.264, selv om Politidirektoratet peker på
at det muligens kan være tilsvarende problematikk også for Theora og
Vorbis.  Dette medfører at det i USA kan kreves royalties for bruk av
tekniske løsninger knyttet til standardene, et krav som også
håndheves. Patenter kan imidlertid bare hevdes i de landene hvor
patentet er gitt, så amerikanske patenter gjelder ikke andre steder
enn USA.&lt;/p&gt;

&lt;p&gt;Spesielt for utvikling av fri programvare er patenter
problematisk. GPL, en &quot;grunnleggende&quot; lisens for distribusjon av fri
programvare, avviser at programvare kan distribueres under denne
lisensen hvis det inneholder referanser til patenterte rutiner som
utløser krav om royalties. Det er imidlertid uproblematisk å
distribuere fri programvareløsninger under GPL som benytter de
aktuelle standardene innen eller mellom land som ikke anerkjenner
patentene. Derfor finner vi også flere implementeringer av Mp3 og
H.264 som er fri programvare, lisensiert under GPL.&lt;/p&gt;

&lt;p&gt;I Norge og EU er patentlovgivningen langt mer restriktiv enn i USA,
men det er også her mulig å få patentert metoder for løsning av et
problem som relaterer seg til databehandling. Det er AIF bekjent ikke
relevante patenter i EU eller Norge hva gjelder H.264 og Mp3, men
muligheten for at det finnes patenter uten at det er gjort krav om
royalties eller at det senere vil gis slike patenter kan ikke helt
avvises.&lt;/p&gt;

&lt;p&gt;AIF mener det er et behov for å gi offentlige virksomheter mulighet
til å benytte antatt royaltyfrie åpne standarder som et likeverdig
alternativ eller i tillegg til de markedsledende åpne standardene.&lt;/p&gt;

&lt;/blockquote&gt;&lt;/p&gt;

&lt;p&gt;Det ser dermed ikke ut til at de har vurdert patentspørsmålet i
sammenheng med opphavsrettsvilkår slik de er formulert for f.eks.
Apple Final Cut Pro, Adobe Premiere Pro, Avid og Sorenson-verktøyene,
der det kreves brukstillatelse for patenter som ikke er gyldige i
Norge for å bruke disse verktøyene til annet en personlig og ikke
kommersiell aktivitet når det gjelder H.264-video.  Jeg må nok lete
videre etter svar på det spørsmålet.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>A Debian package for SMTP via Tor (aka SMTorP) using exim4</title>
                <link>http://www.hungry.com/~pere/blog/A_Debian_package_for_SMTP_via_Tor__aka_SMTorP__using_exim4.html</link>        
                <guid isPermaLink="true">http://www.hungry.com/~pere/blog/A_Debian_package_for_SMTP_via_Tor__aka_SMTorP__using_exim4.html</guid>
                <pubDate>Mon, 10 Nov 2014 13:40:00 +0100</pubDate>
                <description>&lt;p&gt;The right to communicate with your friends and family in private,
without anyone snooping, is a right every citicen have in a liberal
democracy.  But this right is under serious attack these days.&lt;/p&gt;

&lt;p&gt;A while back it occurred to me that one way to make the dragnet
surveillance conducted by NSA, GCHQ, FRA and others (and confirmed by
the whisleblower Snowden) more expensive for Internet email,
is to deliver all email using SMTP via Tor.  Such SMTP option would be
a nice addition to the FreedomBox project if we could send email
between FreedomBox machines without leaking metadata about the emails
to the people peeking on the wire.  I
&lt;a href=&quot;http://lists.alioth.debian.org/pipermail/freedombox-discuss/2014-October/006493.html&quot;&gt;proposed
this on the FreedomBox project mailing list in October&lt;/a&gt; and got a
lot of useful feedback and suggestions.  It also became obvious to me
that this was not a novel idea, as the same idea was tested and
documented by Johannes Berg as early as 2006, and both
&lt;a href=&quot;https://github.com/pagekite/Mailpile/wiki/SMTorP&quot;&gt;the
Mailpile&lt;/a&gt; and &lt;a href=&quot;http://dee.su/cables&quot;&gt;the Cables&lt;/a&gt; systems
propose a similar method / protocol to pass emails between users.&lt;/p&gt;

&lt;p&gt;To implement such system one need to set up a Tor hidden service
providing the SMTP protocol on port 25, and use email addresses
looking like username@hidden-service-name.onion.  With such addresses
the connections to port 25 on hidden-service-name.onion using Tor will
go to the correct SMTP server.  To do this, one need to configure the
Tor daemon to provide the hidden service and the mail server to accept
emails for this .onion domain.  To learn more about Exim configuration
in Debian and test the design provided by Johannes Berg in his FAQ, I
set out yesterday to create a Debian package for making it trivial to
set up such SMTP over Tor service based on Debian.  Getting it to work
were fairly easy, and
&lt;a href=&quot;https://github.com/petterreinholdtsen/exim4-smtorp&quot;&gt;the
source code for the Debian package&lt;/a&gt; is available from github.  I
plan to move it into Debian if further testing prove this to be a
useful approach.&lt;/p&gt;

&lt;p&gt;If you want to test this, set up a blank Debian machine without any
mail system installed (or run &lt;tt&gt;apt-get purge exim4-config&lt;/tt&gt; to
get rid of exim4).  Install tor, clone the git repository mentioned
above, build the deb and install it on the machine.  Next, run
&lt;tt&gt;/usr/lib/exim4-smtorp/setup-exim-hidden-service&lt;/tt&gt; and follow
the instructions to get the service up and running.  Restart tor and
exim when it is done, and test mail delivery using swaks like
this:&lt;/p&gt;

&lt;p&gt;&lt;blockquote&gt;&lt;pre&gt;
torsocks swaks --server dutlqrrmjhtfa3vp.onion \
  --to fbx@dutlqrrmjhtfa3vp.onion
&lt;/pre&gt;&lt;/blockquote&gt;&lt;/p&gt;

&lt;p&gt;This will test the SMTP delivery using tor.  Replace the email
address with your own address to test your server. :)&lt;/p&gt;

&lt;p&gt;The setup procedure is still to complex, and I hope it can be made
easier and more automatic.  Especially the tor setup need more work.
Also, the package include a tor-smtp tool written in C, but its task
should probably be rewritten in some script language to make the deb
architecture independent.  It would probably also make the code easier
to review.  The tor-smtp tool currently need to listen on a socket for
exim to talk to it and is started using xinetd.  It would be better if
no daemon and no socket is needed.  I suspect it is possible to get
exim to run a command line tool for delivery instead of talking to a
socket, and hope to figure out how in a future version of this
system.&lt;/p&gt;

&lt;p&gt;Until I wipe my test machine, I can be reached using the
&lt;tt&gt;fbx@dutlqrrmjhtfa3vp.onion&lt;/tt&gt; mail address, deliverable over
SMTorP. :)&lt;/p&gt;
</description>
        </item>
        
        </channel>
</rss>