Ian Jackson: Let's Encrypt certificate revocation - panic now!
edited 2020-03-03 15:35 to fix arithmetic error
$ aws ec2 describe-images --owner 136693071363 \
--region us-east-1 --output json \
--query "Images[?Architecture=='arm64'] [?starts_with(Name, 'debian-10-')] max_by([], &Name)"
"Architecture": "arm64",
"CreationDate": "2020-02-10T19:04:55.000Z",
"ImageId": "ami-031d1abcdcbbfbd8f",
"ImageLocation": "136693071363/debian-10-arm64-20200210-166",
"ImageType": "machine",
"Public": true,
"OwnerId": "136693071363",
"State": "available",
"BlockDeviceMappings": [
"DeviceName": "/dev/xvda",
"Ebs":
"Encrypted": false,
"DeleteOnTermination": true,
"SnapshotId": "snap-0d8459c1e3fe12486",
"VolumeSize": 8,
"VolumeType": "gp2"
],
"Description": "Debian 10 (20200210-166)",
"EnaSupport": true,
"Hypervisor": "xen",
"Name": "debian-10-arm64-20200210-166",
"RootDeviceName": "/dev/xvda",
"RootDeviceType": "ebs",
"SriovNetSupport": "simple",
"VirtualizationType": "hvm"
Hopefully this helps reduce some of the confusion around the availability of the buster AMIs.
Next up, GovCloud!
Belgians
This month started off in Belgium for FOSDEM on 1-2 February. I attended FOSDEM in Brussels and wrote a separate blog entry for that.
The month ended with Belgians at Tammy and Wouter s wedding. On Thursday we had Wouter s bachelors and then over the weekend I stayed over at their wedding venue. I thought that other Debianites might be interested so I m sharing some photos here with permission from Wouter. It was the only wedding I ve been at where nearly everyone had questions about Debian!
I first met Wouter on the bus during the daytrip on DebConf12 in Nicaragua, back then I ve eagerly followed the Debianites on Planet Debian for a while so it was like meeting someone famous. Little did I know that 8 years later, I d be at his wedding back in my part of the world.
If you went to DebConf16 in South Africa, you might remember Tammy, who have done a lot of work for DC16 including most of the artwork, bunch of website work, design on the badges, bags, etc and also did a lot of organisation for the day trips. Tammy and Wouter met while Tammy was reviewing the artwork in the video loops for the DebConf videos, and then things developed from there.
Wouter s Bachelors
Wouter was blindfolded and kidnapped and taken to the city center where we prepared to go on a bike tour of Cape Town, stopping for beer at a few places along the way. Wouter was given a list of tasks that he had to complete, or the wedding wouldn t be allowed to continue
Wouter s tasks
Wouter s props, needed to complete his tasks
Bike tour leg at Cape Town Stadium.
Seeking out 29 year olds.
Wouter finishing his lemon and actually seemingly enjoying it.
Reciting South African national anthem notes and lyrics.
The national anthem, as performed by Wouter (I was actually impressed by how good his pitch was).
Accommodation at the lodge
Debian swirls everywhere
I took a canoe ride on the river and look what I found, a paddatrapper!


A bit of digital zoomage of previous image.
Time to say the vows.
Just married. Thanks to Sue Fuller-Good for the photo.
Except for one character being out of place, this was a perfect fairy tale wedding, but I pointed Wouter to https://jonathancarter.org/how-to-spell-jonathan/ for future reference so it s all good.Debian Package Uploads 2020-02-07: Upload package calamares (3.2.18-1) to Debian unstable. 2020-02-07: Upload package python-flask-restful (0.3.8-1) to Debian unstable. 2020-02-10: Upload package kpmcore (4.1.0-1) to Debian unstable. 2020-02-16: Upload package fracplanet (0.5.1-5.1) to Debian unstable (Closes: #946028). 2020-02-20: Upload package kpmcore (4.1.0-2) to Debian unstable. 2020-02-20: Upload package bluefish (2.2.11) to Debian unstable. 2020-02-20: Upload package gdisk (1.0.5-1) to Debian unstable. 2020-02-20: Accept MR#6 for gamemode. 2020-02-23: Upload package tanglet (1.5.5-1) to Debian unstable. 2020-02-23: Upload package gamemode (1.5-1) to Debian unstable. 2020-02-24: Upload package calamares (3.2.19-1) to Debian unstable. 2020-02-24: Upload package partitionmanager (4.1.0-1) to Debian unstable. 2020-02-24: Accept MR#7 for gamemode. 2020-02-24: Merge MR#1 for calcoo. 2020-02-24: Upload package calcoo (1.3.18-8) to Debian unstable. 2020-02-24: Merge MR#1 for flask-api. 2020-02-25: Upload package calamares (3.2.19.1-1) to Debian unstable. 2020-02-25: Upload package gnome-shell-extension-impatience (0.4.5-4) to Debian unstable. 2020-02-25: Upload package gnome-shell-extension-harddisk-led (19-2) to Debian unstable. 2020-02-25: Upload package gnome-shell-extension-no-annoyance (0+20170928-f21d09a-2) to Debian unstable. 2020-02-25: Upload package gnome-shell-extension-system-monitor (38-2) to Debian unstable. 2020-02-25: Upload package tuxpaint (0.9.24~git20190922-f7d30d-1~exp3) to Debian experimental.
Debian Mentoring 2020-02-10: Sponsor package python-marshmallow-polyfield (5.8-1) for Debian unstable (Python team request). 2020-02-10: Sponsor package geoalchemy2 (0.6.3-2) for Debian unstable (Python team request). 2020-02-13: Sponsor package python-tempura (2.2.1-1) for Debian unstable (Python team request). 2020-02-13: Sponsor package python-babel (2.8.0+dfsg.1-1) for Debian unstable (Python team request). 2020-02-13: Sponsor package python-pynvim (0.4.1-1) for Debian unstable (Python team request). 2020-02-13: Review package ledmon (0.94-1) (Needs some more work) (mentors.debian.net request). 2020-02-14: Sponsor package citeproc-py (0.3.0-6) for Debian unstable (Python team request). 2020-02-24: Review package python-suntime (1.2.5-1) (Needs some more work) (Python team request). 2020-02-24: Sponsor package python-babel (2.8.0+dfsg.1-2) for Debian unstable (Python team request). 2020-02-24: Sponsor package 2048 (0.0.0-1~exp1) for Debian experimental (mentors.debian.net request). 2020-02-24: Review package notcurses (1.1.8-1) (Needs some more work) (mentors.debian.net request). 2020-02-25: Sponsor package cloudpickle (1.3.0-1) for Debian unstable (Python team request).
Debian Misc 2020-02-12: Apply Planet Debian request and close MR#21. 2020-02-23: Accept MR#6 for ToeTally (DebConf Video team upstream). 2020-02-23: Accept MR#7 for ToeTally (DebConf Video team upstream).
Map of conflict
I've been practising Non-Violent Communication (NVC) for several years. It helps me to better understand my feelings and needs. The concepts of NVC can also help to look at conflicts. I would like to introduce a way to look at conflict using the basic concepts of NVC:
Here is my monthly update covering what I have been doing in the free software world during February 2020 (previous month):
warnings.warn method over logging.warning [...] and to document missing archive keyword argument to the get_bugs call [...].
libmate-desktop library component of the MATE Desktop Environment I submitted a pull request to make the build reproducible in/around various dialogs. [...]
python_example, an example pybind11 module built with a Python-based build system, I suggested sorting the extension sources to ensure a reproducible build in any projects based on this template. [...]
snapd component of the Snappy package manager. Here, I opened a pull request to make the build reproducible. [...]
For the Tails privacy-oriented operating system, I uploaded the following packages to Debian:
0.1.8-5):
dh-python to Build-Depends. (#952366)sphinxdoc:Depends to binary package dependencies. (#832588)tool:pytest section in setup.cfg over plain "pytest".dh-systemd with debhelper version 9.20160709, specify Rules-Requires-Root: no, use secure URL in debian/copyright, update Vcs-Git & Vcs-Browser and bump the package's Standards-Version to 4.5.0.0.2-9):
One of the original promises of open source software is that distributed peer review and transparency of process results in enhanced end-user security. However, whilst anyone may inspect the source code of free and open source software for malicious flaws, almost all software today is distributed as pre-compiled binaries. This allows nefarious third-parties to compromise systems by injecting malicious code into ostensibly secure software during the various compilation and distribution processes.
The motivation behind the Reproducible Builds effort is to provide the ability to demonstrate these binaries originated from a particular trusted source release: if identical results are generated from a given source in all circumstances, reproducible builds provides the means for multiple third-parties to reach a consensus on whether a build was compromised via distributed checksum validation or some other scheme.
The initiative is proud to be a member project of the Software Freedom Conservancy, a not-for-profit 501(c)(3) charity focused on ethical technology and user freedom.
Conservancy acts as a corporate umbrella allowing projects to operate as non-profit initiatives without managing their own corporate structure. If you like the work of the Conservancy or the Reproducible Builds project, please consider becoming an official supporter.
This month, I:
libmate-desktop library component of the MATE Desktop Environment I submitted a pull request to make the build reproducible in/around various dialog boxes, etc. [...]
snapd component of the Snappy package manager. Here, I opened a pull request to make the build reproducible. [...]
python_example, an example pybind11 module built with a Python-based build system, I suggested sorting the extension sources to ensure a reproducible build in any projects based on this template. [...]
debian-installer package to allow all arguments from sources.list files (such as [check-valid-until=no]) in order that we can test the reproducibility of the installer images on the Reproducible Builds own testing infrastructure. (#13)
openstack-pkg-tools to fix a curious issue where packages built differently if they built "too fast" for example, if we built for both Python 3.7 and Python 3.8 but the installation of the latter occurs within the same wall clock second of the former, the Python 3.8 version will not overwrite the Python 3.7 version and lead to a shebang of #!/usr/bin/python3.7, whilst if it does not occur within the same second, the shebang will be overwritten
to #!/usr/bin/python3.8. (#952762)
#include directives), designate (embedded build path), javatools (nondeterminstic parsing of command-line variables), mate-desktop (build timestamps), msgpack-c (embeds build path), pynwb (embedded timestamps in test files), python-oslo.reports (nondeterminstic/random numbers), snapd-glib (embedded build path) & xavs2 (embedded timestamps).
Meson.build example to the SOURCE_DATE_EPOCH documentation [...], replacing instances of "anyone can" with "anyone may" [...], correcting/improving the logic to skip commits when generating drafts [...][...][...], etc.
In our tooling, I also made the following changes to diffoscope, our in-depth and content-aware diff utility that can locate and diagnose reproducibility issues, including uploading version 137 to Debian:
sng image utility will return 1 if there are even minor errors in the file. (#950806)classes2.dex, classes3.dex from .apk files. (#88)str.format if we are just returning the string. [...]Command.VALID_RETURNCODES. [...]hsd, a blockchain-based top-level domain DNS protocol implementation that underpins Handshake and worked on some initial packaging. (#952472)
Debian LTS
This month I have worked 18 hours on Debian Long Term Support (LTS) and 12 hours on its sister Extended LTS project.
cacti (CVE-2020-8813), golang-go.crypto (CVE-2020-9283), netty, nodejs (CVE-2019-15605), nova (CVE-2015-9543), ntp, otrs2 (CVE-2019-11358)), php-horde-data (CVE-2020-8518), proftpd-dfsg, python-bleach (CVE-2020-6802), python-django, python-pysaml2, qtbase-opensource-src (CVE-2015-9541), ruby-rack, salt, sudo, systemd (CVE-2020-1712), waitress (CVE-2020-5236), wpa (CVE-2019-5061) & yara
1.10.7-2+deb9u8 to Debian stretch and 1.11.28-1~deb10u1 for Debian buster to address CVE-2020-7471, a potential SQL injection vulnerability.
2.2.10-1) New upstream security release. (#950581)
6.0~rc1-2 Add support for Transport Layer Security added in Redis 6.x (#951255) and add a comment regarding why we export a MAKEFLAGS variable in debian/rules.
5.0.7-2:
2.13+dfsg-2) Fix a regression in handling of CVE-2015-1197 with respect to the --no-absolute-filenames argument by reverting part of an upstream commit. (#946267 #946469)
0.14.0-6) Set the Bug-Database, Bug-Submit, Repository and Repository-Browse upstream metadata fields and rely on pre-initialised dpkg-architecture variables in debian/rules.
1.5.22-1 New upstream release.1.5.22-2 Apply a patch to fix build failures on the s390x architecture. (#950777)20.0.4-2 Set the upstream metadata fields (Repository, Repository-Browse, etc.), bump Standards-Version to 4.5.0.20.0.4-3 Specify that the gunicorn binary package provides the httpd-wsgi3 virtual package. (#952706)4.0.23-2:
future=+lfs to DEB_BUILD_MAINT_OPTIONS to support operating on large files. (#949665)gitlab-ci.yml.Rules-Requires-Root: no and bump the Standards-Version to 4.5.0.4.0.23-3 Drop quotes from DEB_BUILD_MAINT_OPTIONS export line. (#951037)
4.7.6-1) on behalf of Alexandre Rossi.
sbuild is a tool used by those maintaining packages in Debian, and
derived distributions such as Ubuntu. When used correctly, it can
catch a lot of categories of bugs before packages are uploaded. It
does this by building the package in a clean environment, and then
running the package through the Lintian, piuparts, adequate and
autopkgtest tools. However, configuring sbuild so that it makes use
of all of these tools is cumbersome.
In response to this complexity, I wrote a module for the
Propellor configuration management system to prepare a system such
that a user can just go ahead and run the sbuild(1) command.
This module is useful on one s development laptop if you need to
reinstall your OS, you don t have to look up the instructions for
setting up sbuild again. But it s also useful on throwaway build
boxes. I can instruct propellor to provision a new virtual machine to
build packages with sbuild, and all the different tools mentioned
above will be connected together for me.
I just uploaded Propellor version 5.1.0 to Debian unstable. The
version overhauls the API and internals of the Sbuild module to take
better advantage of Propellor s design. I won t get into those
details in this post. What I d like to do is demonstrate how you can
set up sbuild on your own machines, using Propellor.
Getting started with Propellor
apt-get install propellor, and then propellor --init.
You ll be offered two setups, options A and B. I suggest starting
with option B.
If you never use Propellor for anything other than provisioning
sbuild, you can stick with option B. If this tutorial makes you want
to check out more features of Propellor, you might consider switching
to option A and importing your old configuration.
Open ~/.propellor/config.hs. You will see something like this:
-- The hosts propellor knows about.
hosts :: [Host]
hosts =
[ mybox
]
-- An example host.
mybox :: Host
mybox = host "mybox.example.com" $ props
& osDebian Unstable X86_64
& Apt.stdSourcesList
& Apt.unattendedUpgrades
& Apt.installed ["etckeeper"]
& Apt.installed ["ssh"]
& User.hasSomePassword (User "root")
& File.dirExists "/var/www"
& Cron.runPropellor (Cron.Times "30 * * * *")
iris, so I might replace the above with this:
-- The hosts propellor knows about.
hosts :: [Host]
hosts =
[ iris
]
-- My laptop.
iris :: Host
iris = host "iris.silentflame.com" $ props
& osDebian Testing X86_64
& are the properties of the host
iris. Here, I ve removed all properties except the osDebian
property, which informs propellor that iris runs Debian testing and
has the amd64 architecture.
The effect of this is that Propellor will not try to change anything
about iris. In this tutorial, we are not going to let Propellor
configure anything about iris other than setting up sbuild.
(The osDebian property is a pure info property, which means that
it tells Propellor information about the host to which other
properties might refer, but it doesn t itself change anything about
iris.)
Telling Propellor to configure sbuild
First, add to the import lines at the top of config.hs the lines:
import qualified Propellor.Property.Sbuild as Sbuild
import qualified Propellor.Property.Schroot as Schroot
-- The hosts propellor knows about.
hosts :: [Host]
hosts =
[ iris
]
-- My laptop.
iris :: Host
iris = host "iris.silentflame.com" $ props
& osDebian Testing X86_64
& Apt.useLocalCacher
& sidSchrootBuilt
& Sbuild.usableBy (User "spwhitton")
& Schroot.overlaysInTmpfs
& Cron.runPropellor (Cron.Times "30 * * * *")
where
sidSchrootBuilt = Sbuild.built Sbuild.UseCcache $ props
& osDebian Unstable X86_64
& Sbuild.update period Daily
& Sbuild.useHostProxy iris
Apt.useLocalCacher set up apt-cacher-ng and points apt on iris
at the cacher. This is the most efficient way to share a cache of
packages between apt on iris, and apt within the sbuild chroot.sidSchrootBuilt builds the sbuild schroot. Unfortunately, we have
to use a where clause because of Haskell s rules about operator
precedence. But it s just a simple substitution: imagine that &
Sbuild.built ... replaces & sidSchrootBuilt.
osDebian specifies that this is a Debian unstable chroot. You
can easily change this, or add another chroot, for building
stable backports, etc.Sbuild.UseCcache enables ccache for builds in this chroot.
You can replace this with Sbuild.NoCcache when building a
package which is broken by ccache, which happens from
time-to-time.Sbuild.update updates the chroot once per day.Sbuild.useHostProxy iris causes Propellor to propagate iris s
apt proxy into the chroot, so that apt in the chroot will also
use iris s apt cacher.Sbuild.usableBy adds spwhitton to the right group, so that he is
allowed to invoke sbuild(1).Schroot.overlaysInTmpfs configures sbuild to install build
dependencies and build packages in tmpfs. You can omit this
property on machines with low amounts of memory.Cron.runPropellor sets up a cron job to re-run propellor once per
hour. This is needed to ensure that things like Sbuild.update
actually happen. It will also normalise sbuild configuration files,
replace chroots that you accidently deleted, etc.propellor iris.silentflame.com.
In this configuration, you don t need to worry about whether the
hostname iris.silentflame.com actually resolves to your laptop.
However, it must be possible to ssh root@localhost.
This should be enough that spwhitton can:
$ sbuild -A --run-lintian --run-autopkgtest --run-piuparts foo.dsc
Further configuration
It is easy to add new schroots; for example, for building backports:
...
& stretchSchrootBuilt
...
where
...
stretchSchrootBuilt = Sbuild.built Sbuild.UseCcache $ props
& osDebian (Stable "stretch") X86_64
& Sbuild.update period Daily
& Sbuild.useHostProxy iris
where
sidSchrootBuilt = Sbuild.built Sbuild.UseCcache $ props
& osDebian Unstable X86_64
& Sbuild.update period Daily
& Apt.mirror "https://foo.mirror/debian/"
& Apt.installed ["apt-transport-https"]
SOURCE_DATE_EPOCH support.SOURCE_DATE_EPOCH.88~bpo9+1 to stretch-backports.
reprotest development
util-linux confirmed bug in nsenter, awaiting fix.--print-sudoers work for --env-build as well./contribute/ on our
main website.apt-key addapt-key add
No more nagging me about the placeholder image from Wikipedia I used in
yesterday's report!
Set up
Here's what the team did today:
tumbleweed
Stefano started the day by hacking away on our video archive. We eventually want
to upload all our videos to YouTube to give them exposure, but sadly our archive
metadata is in a pretty poor shape.
With the script tumbleweed wrote, we can scrape the archive for matches against
the old DebConf's pentabarf XML we have.
tumbleweed also helped Ivo with the ansible PXE setup he's working on. Some
recent contributions from a collaborator implemented new features (like a nice
menu to choose from) but also came with a few annoying bugs.
ivodd
Ivo continued working on the PXE setup today. He also tried to break our ansible
setup by using fresh installs with different user cases (locales, interfaces,
etc.), with some success.
The reason he and Stefano are working so hard on the PXE boot is that we had a
discussion about the future of our USB install method. The general consensus on
this was although we would not remove it, we would not actively maintain it
anymore.
PXE is less trouble for multiple machines. For single machines or if you don't
control the DHCP server, using ansible manually on a fresh Debian install will
be the recommended way.
olasd
After a very long drive, olasd arrived late in the evening with all our gear.
Hurray! We were thus able to set up some test boxes and start wiring the airbnb
properly. Tomorrow will certainly be more productive with all this stuff at our
disposition.
pollo
Today I mainly worked on setting up our documentation website. After some
debate, we decided that sphinx was the right tool for the job.
I am a few pages in and if I work well I think we'll have something to show for
at the end of the sprint!
I also was thrown back into ansible after witnessing a bug in the locale
management. I'm still rusty, but it's slowly coming back to me.
Let's end this blog post with a picture of the neon pineapple that sits on the
wall of the solarium.
Following up on propelling disk images,
Propellor can now build custom ARM disk images for a variety of
different ARM boards. The disk image build can run on a powerful laptop or
server, so it's super fast and easy compared with manually installing
Debian on an ARM board.
Here's a simple propellor config for a Olimex LIME board, with ssh access
and a root password:
lime :: Host
lime = host "lime.example.com" $ props
& osDebian Unstable ARMHF
& Machine.olimex_A10_OLinuXino_LIME
& hasPartition (partition EXT4 mountedAt "/" setSize MegaBytes 8192)
& hasPassword (User "root")
& Ssh.installed
& Ssh.permitRootLogin (RootLogin True)
To make a disk image for that board, I only have to add this property to my
laptop:
& imageBuiltFor lime
(RawDiskImage "/srv/lime.img")
(Debootstrapped mempty)
Propellor knows what kernel to install and how to make the image bootable
for a bunch of ARM boards,
including the Olimex LIME, the SheevaPlug, Banana Pi, and CubieTruck.
To build the disk image targeting ARM, propellor uses qemu. So it's helpful
that, after the first build, propellor incrementally updates disk images,
quite quickly and efficiently.
Once the board has the image installed, you can run propellor on it to
further maintain it, and if there's a hardware problem, you can quickly
replace it with an updated image.
![]() |
olimex_A10_OLinuXino_LIME :: Property (HasInfo + DebianLike)
olimex_A10_OLinuXino_LIME = FlashKernel.installed "Olimex A10-OLinuXino-LIME"
requires sunixi "A10-OLinuXino-Lime"
requires armmp
My home server is a CubieTruck which serves as a wireless access point,
solar panel data collector, and git-annex autobuilder. It's deployed from
a disk image built by propellor,
using this config.
I've been involved with building disk image for ARM boards for a long
time -- it was part of my job for five years -- and this is the first time
I've been entirely happy with the process.
It finally happened
On the 6th of April 2017, I finally took the plunge and applied for Debian Developer status. On 1 August, during DebConf in Montr al, my application was approved. If you re paying attention to the dates you might notice that that was nearly 4 months ago already. I was trying to write a story about how it came to be, but it ended up long. Really long (current draft is around 20 times longer than this entire post). So I decided I d rather do a proper bio page one day and just do a super short version for now so that someone might end up actually reading it.
How it started
In 1999 no wait, I can t start there, as much as I want to, this is a short post, so In 2003, I started doing some contract work for the Shuttleworth Foundation. I was interested in collaborating with them on tuXlabs, a project to get Linux computers into schools. For the few months before that, I was mostly using SuSE Linux. The open source team at the Shuttleworth Foundation all used Debian though, which seemed like a bizarre choice to me since everything in Debian was really old and its boot-floppies installer program kept crashing on my very vanilla computers.

SLUG (Schools Linux Users Group) group photo. SLUG was founded to support the tuXlab schools that ran Linux.

Ubuntu 4.10 default desktop Image from distrowatch
Like each month, here comes a report about the work of paid contributors to Debian LTS.
Individual reports
In October, about 197 work hours have been dispatched among 13 paid contributors. Their reports are available:
No comment Liked this article? Click here. My blog is Flattr-enabled.
I've been tempted to run own ElectrumX server for quite some. First attempt was to run this on Turris Omnia router, however that turned out to be impossible due to memory requirements both Bitcoind and ElectrumX have.
This time I've dedicated host for this and it runs fine:
The server runs Debian sid (probably it would be doable on stretch as well, but I didn't try much) and the setup was pretty simple.
First we need to install some things - Bitcoin daemon and ElectrumX dependencies:
# Bitcoin daemon, not available in stretch
apt install bitcoind
# We will checkout ElectrumX from git
apt install git
# ElectrumX deps
apt install python3-aiohttp
# Build environment for ElectrumX deps
apt install build-essentials python3-pip libleveldb-dev
# ElectrumX deps not packaged in Debian
pip3 install plyvel pylru
# Download ElectrumX sources
su - electrumx -c 'git clone https://github.com/kyuupichan/electrumx.git'
adduser bitcoind
adduser electrumx
/home/bitcoind/.bitcoin/bitcoin.conf:
txindex=1
listen=1
rpcuser=bitcoin
rpcpassword=somerandompassword
/etc/electrumx.conf:
COIN=BitcoinSegwit
DB_DIRECTORY=/home/electrumx/.electrumx
DAEMON_URL=http://bitcoin:somerandompassword@localhost:8332/
TCP_PORT=50001
SSL_PORT=50002
HOST=::
DONATION_ADDRESS=3KPccmPtejpMczeog7dcFdqX4oTebYZ3tF
SSL_CERTFILE=/etc/letsencrypt/live/btc.cihar.com/fullchain.pem
SSL_KEYFILE=/etc/letsencrypt/live/btc.cihar.com/privkey.pem
REPORT_HOST=btc.cihar.com
BANNER_FILE=banner
/etc/systemd/system/electrumx.service:
[Unit]
Description=Electrumx
After=bitcoind.target
[Service]
EnvironmentFile=/etc/electrumx.conf
ExecStart=/home/electrumx/electrumx/electrumx_server.py
User=electrumx
LimitNOFILE=8192
TimeoutStopSec=30min
[Install]
WantedBy=multi-user.target
/etc/systemd/system/bitcoind.service:
[Unit]
Description=Bitcoind
After=network.target
[Service]
ExecStart=/usr/bin/bitcoind
User=bitcoind
TimeoutStopSec=30min
Restart=on-failure
RestartSec=30
[Install]
WantedBy=multi-user.target
# Enable services so that they start on boot
systemctl enable electrumx.service bitcoind.service
# Start services
systemctl start electrumx.service bitcoind.service
~/.bitcoin/blocks/). Only get blocks from sources you trust absolutely as it might change your view of history, see Bitcoin wiki for more information on the topic. There is also magnet link in the ElectrumX docs to download ElectrumX database to speed up this process. This should be safe to download from untrusted source.
The last think I'd like to mention is resources usage. You should have at least 4 GB of memory to run this, 8 GB is really preferred (both services consume around 4GB). On disk space, Bitcoin currently consumes 170 GB and ElectrumX 25 GB. Ideally all this should be running on the SSD disk.
You can however offload some of the files to slower storage as old blocks are rarely accessed and this can save some space on your storage. Following script will move around 50 GB of blockchain data to /mnt/btc/blocks (use only when Bitcoin daemon is not running):
1 2 3 4 5 6 7 8 9 10 11 | #!/bin/sh
set -e
DEST=/mnt/btc/blocks
cd ~/.bitcoin/blocks/
find . -type f \( -name 'blk00[0123]*.dat' -o -name 'rev00[0123]*dat' \) sed 's@^\./@@' while read name ; do
mv $name $DEST/$name
ln -s $DEST/$name $name
done
|
3KPccmPtejpMczeog7dcFdqX4oTebYZ3tF.
Narabu is a new intraframe video codec. You probably want to read
part 1,
part 2,
part 3,
part 4
and
part 5
first.
Like I wrote in part 5, there basically isn't a big splashy ending where
everything is resolved here; you're basically getting some graphs with
some open questions and some interesting observations.
First of all, though, I'll need to make a correction: In the last part,
I wrote that encoding takes 1.2 ms for 720p luma-only on my GTX 950,
which isn't correct I remembered the wrong number. The right number is
2.3 ms, which I guess explains even more why I don't think it's acceptable
at the current stage. (I'm also pretty sure it's possible to rearchitect
the encoder so that it's much better, but I am moving on to other
video-related things for the time being.)
I encoded a picture straight off my DSLR (luma-only) at various resolutions,
keeping the aspect. Then I decoded it a bunch of times on my GTX 950
(low-end last-generation NVIDIA) and on my HD 4400 (ultraportable Haswell
laptop) and measured the times. They're normalized for megapixels per second
decoded; remember that doubling width (x axis) means quadruple the pixels.
Here it is:
I'm not going to comment much beyond two observations:
This is interesting. I have few explanations. Probably more benchmarking and
profiling would be needed to make sense of any of it. In fact, it's so
strange that I would suspect a bug, but it does indeed seem to create a
valid bitstream that is decoded by the decoder.
Do note, however, that seemingly even on the smallest resolutions, there's a
1.7 ms base cost (you can't see it on the picture, but you'd see it in an
unnormalized graph). I don't have a very good explanation for this either
(even though there are some costs that are dependent on the alphabet size
instead of the number of pixels), but figuring it out would probably be a
great start for getting the performance up.
So that concludes the series, on a cliffhanger. :-) Even though it's not in a
situation where you can just take it and put it into something useful, I hope
it was an interesting introduction to the GPU! And in the meantime, I've
released version 1.6.3 of Nageru, my live video
mixer (also heavily GPU-based) with various small adjustments and bug fixes
found before and during Tr ndisk. And Movit is getting compute shaders
for that extra speed boost, although parts of it is bending my head.
Exciting times in GPU land :-)
Previously: v4.13.
Linux kernel v4.14 was released this last Sunday, and there s a bunch of security things I think are interesting:
vmapped kernel stack on arm64CONFIG_VMAP_STACK for arm64, which moves the kernel stack to an isolated and guard-paged vmap area. With traditional stacks, there were two major risks when exhausting the stack: overwriting the thread_info structure (which contained the addr_limit field which is checked during copy_to/from_user()), and overwriting neighboring stacks (or other things allocated next to the stack). While arm64 previously moved its thread_info off the stack to deal with the former issue, this vmap change adds the last bit of protection by nature of the vmap guard pages. If the kernel tries to write past the end of the stack, it will hit the guard page and fault. (Testing for this is now possible via LKDTM s STACK_GUARD_PAGE_LEADING/TRAILING tests.)
One aspect of the guard page protection that will need further attention (on all architectures) is that if the stack grew because of a giant Variable Length Array on the stack (effectively an implicit alloca() call), it might be possible to jump over the guard page entirely (as seen in the userspace Stack Clash attacks). Thankfully the use of VLAs is rare in the kernel. In the future, hopefully we ll see the addition of PaX/grsecurity s STACKLEAK plugin which, in addition to its primary purpose of clearing the kernel stack on return to userspace, makes sure stack expansion cannot skip over guard pages. This stack probing ability will likely also become directly available from the compiler as well.
set_fs() balance checkingaddr_limit field mentioned above, another class of bug is finding a way to force the kernel into accidentally leaving addr_limit open to kernel memory through an unbalanced call to set_fs(). In some areas of the kernel, in order to reuse userspace routines (usually VFS or compat related), code will do something like: set_fs(KERNEL_DS); ...some code here...; set_fs(USER_DS);. When the USER_DS call goes missing (usually due to a buggy error path or exception), subsequent system calls can suddenly start writing into kernel memory via copy_to_user (where the to user really means within the addr_limit range ).
Thomas Garnier implemented USER_DS checking at syscall exit time for x86, arm, and arm64. This means that a broken set_fs() setting will not extend beyond the buggy syscall that fails to set it back to USER_DS. Additionally, as part of the discussion on the best way to deal with this feature, Christoph Hellwig and Al Viro (and others) have been making extensive changes to avoid the need for set_fs() being used at all, which should greatly reduce the number of places where it might be possible to introduce such a bug in the future.
SLUB freelist hardeningCONFIG_SLAB_FREELIST_HARDENED, makes freelist pointer overwrites very hard to exploit unless an attacker has found a way to expose both the random value and the pointer location. This should render blind heap overflow bugs much more difficult to exploit.
Additionally, Alexander Popov implemented a simple double-free defense, similar to the fasttop check in the GNU C library, which will catch sequential free()s of the same pointer. (And has already uncovered a bug.)
Future work would be to provide similar metadata protections to the SLAB allocator (though SLAB doesn t store its freelist within the individual unused objects, so it has a different set of exposures compared to SLUB).
setuid-exec stack limitationCONFIG_GCC_PLUGIN_RANDSTRUCT, now includes one of the major targets of exploits: function pointer structures. Without knowing the build-randomized location of a callback pointer an attacker needs to overwrite in a structure, exploits become much less reliable.
structleak passed-by-reference variable initializationCONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL. Normally the compiler will yell if a variable is used before being initialized, but it silences this warning if the variable s address is passed into a function call first, as it has no way to tell if the function did actually initialize the contents. So the plugin now zero-initializes such variables (if they hadn t already been initialized) before the function call that takes their address. Enabling this feature has a small performance impact, but solves many stack content exposure flaws. (In fact at least one such flaw reported during the v4.15 development cycle was mitigated by this plugin.)
improved boot entropySECCOMP_FILTER_FLAG_LOG, he added a new action result, SECCOMP_RET_LOG. With these changes in place, it should be much easier for developers to inspect the results of seccomp filters, and for process launchers to generate logs for their child processes operating under a seccomp filter.
Additionally, I finally found a way to implement an often-requested feature for seccomp, which was to kill an entire process instead of just the offending thread. This was done by creating the SECCOMP_RET_ACTION_FULL mask (n e SECCOMP_RET_ACTION) and implementing SECCOMP_RET_KILL_PROCESS.
That s it for now; please let me know if I missed anything. The v4.15 merge window is now open!
2017, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
| Series: | Francesca #2 |
| Publisher: | Candlewick Press |
| Copyright: | 2010 |
| Printing: | 2011 |
| ISBN: | 0-7636-5458-2 |
| Format: | Kindle |
| Pages: | 330 |
Welcome to gambaru.de. Here is my monthly report that covers what I have been doing for Debian. If you re interested in Java, Games and LTS topics, this might be interesting for you.
Debian Games
Next.