Search Results: "ag"

6 May 2021

Matthew Garrett: More doorbell adventures

Back in my last post on this topic, I'd got shell on my doorbell but hadn't figured out why the HTTP callbacks weren't always firing. I still haven't, but I have learned some more things.

Doorbird sell a chime, a network connected device that is signalled by the doorbell when someone pushes a button. It costs about $150, which seems excessive, but would solve my problem (ie, that if someone pushes the doorbell and I'm not paying attention to my phone, I miss it entirely). But given a shell on the doorbell, how hard could it be to figure out how to mimic the behaviour of one?

Configuration for the doorbell is all stored under /mnt/flash, and there's a bunch of files prefixed 1000eyes that contain config (1000eyes is the German company that seems to be behind Doorbird). One of these was called 1000eyes.peripherals, which seemed like a good starting point. The initial contents were "Peripherals":[] , so it seemed likely that it was intended to be JSON. Unfortunately, since I had no access to any of the peripherals, I had no idea what the format was. I threw the main application into Ghidra and found a function that had debug statements referencing "initPeripherals and read a bunch of JSON keys out of the file, so I could simply look at the keys it referenced and write out a file based on that. I did so, and it didn't work - the app stubbornly refused to believe that there were any defined peripherals. The check that was failing was pcVar4 = strstr(local_50[0],PTR_s_"type":"_0007c980);, which made no sense, since I very definitely had a type key in there. And then I read it more closely. strstr() wasn't being asked to look for "type":, it was being asked to look for "type":". I'd left a space between the : and the opening " in the value, which meant it wasn't matching. The rest of the function seems to call an actual JSON parser, so I have no idea why it doesn't just use that for this part as well, but deleting the space and restarting the service meant it now believed I had a peripheral attached.

The mobile app that's used for configuring the doorbell now showed a device in the peripherals tab, but it had a weird corrupted name. Tapping it resulted in an error telling me that the device was unavailable, and on the doorbell itself generated a log message showing it was trying to reach a device with the hostname bha-04f0212c5cca and (unsurprisingly) failing. The hostname was being generated from the MAC address field in the peripherals file and was presumably supposed to be resolved using mDNS, but for now I just threw a static entry in /etc/hosts pointing at my Home Assistant device. That was enough to show that when I opened the app the doorbell was trying to call a CGI script called peripherals.cgi on my fake chime. When that failed, it called out to the cloud API to ask it to ask the chime[1] instead. Since the cloud was completely unaware of my fake device, this didn't work either. I hacked together a simple server using Python's HTTPServer and was able to return data (another block of JSON). This got me to the point where the app would now let me get to the chime config, but would then immediately exit. adb logcat showed a traceback in the app caused by a failed assertion due to a missing key in the JSON, so I ran the app through jadx, found the assertion and from there figured out what keys I needed. Once that was done, the app opened the config page just fine.

Unfortunately, though, I couldn't edit the config. Whenever I hit "save" the app would tell me that the peripheral wasn't responding. This was strange, since the doorbell wasn't even trying to hit my fake chime. It turned out that the app was making a CGI call to the doorbell, and the thread handling that call was segfaulting just after reading the peripheral config file. This suggested that the format of my JSON was probably wrong and that the doorbell was not handling that gracefully, but trying to figure out what the format should actually be didn't seem easy and none of my attempts improved things.

So, new approach. Rather than writing the config myself, why not let the doorbell do it? I should be able to use the genuine pairing process if I could mimic the chime sufficiently well. Hitting the "add" button in the app asked me for the username and password for the chime, so I typed in something random in the expected format (six characters followed by four zeroes) and a sufficiently long password and hit ok. A few seconds later it told me it couldn't find the device, which wasn't unexpected. What was a little more unexpected was that the log on the doorbell was showing it trying to hit another bha-prefixed hostname (and, obviously, failing). The hostname contains the MAC address, but I hadn't told the doorbell the MAC address of the chime, just its username. Some more digging showed that the doorbell was calling out to the cloud API, giving it the 6 character prefix from the username and getting a MAC address back. Doing the same myself revealed that there was a straightforward mapping from the prefix to the mac address - changing the final character from "a" to "b" incremented the MAC by one. It's actually just a base 26 encoding of the MAC, with aaaaaa translating to 00408C000000.

That explained how the hostname was being generated, and in return I was able to work backwards to figure out which username I should use to generate the hostname I was already using. Attempting to add it now resulted in the doorbell making another CGI call to my fake chime in order to query its feature set, and by mocking that up as well I was able to send back a file containing X-Intercom-Type, X-Intercom-TypeId and X-Intercom-Class fields that made the doorbell happy. I now had a valid JSON file, which cleared up a couple of mysteries. The corrupt name was because the name field isn't supposed to be ASCII - it's base64 encoded UTF16-BE. And the reason I hadn't been able to figure out the JSON format correctly was because it looked something like this:

"Peripherals":[] "prefix": "type":"DoorChime","name":"AEQAbwBvAHIAYwBoAGkAbQBlACAAVABlAHMAdA==","mac":"04f0212c5cca","user":"username","password":"password" ]

Note that there's a total of one [ in this file, but two ]s? Awesome. Anyway, I could now modify the config in the app and hit save, and the doorbell would then call out to my fake chime to push config to it. Weirdly, the association between the chime and a specific button on the doorbell is only stored on the chime, not on the doorbell. Further, hitting the doorbell didn't result in any more HTTP traffic to my fake chime. However, it did result in some broadcast UDP traffic being generated. Searching for the port number led me to the Doorbird LAN API and a complete description of the format and encryption mechanism in use. Argon2I is used to turn the first five characters of the chime's password (which is also stored on the doorbell itself) into a 256-bit key, and this is used with ChaCha20 to decrypt the payload. The payload then contains a six character field describing the device sending the event, and then another field describing the event itself. Some more scrappy Python and I could pick up these packets and decrypt them, which showed that they were being sent whenever any event occurred on the doorbell. This explained why there was no storage of the button/chime association on the doorbell itself - the doorbell sends packets for all events, and the chime is responsible for deciding whether to act on them or not.

On closer examination, it turns out that these packets aren't just sent if there's a configured chime. One is sent for each configured user, avoiding the need for a cloud round trip if your phone is on the same network as the doorbell at the time. There was literally no need for me to mimic the chime at all, suitable events were already being sent.

Still. There's a fair amount of WTFery here, ranging from the strstr() based JSON parsing, the invalid JSON, the symmetric encryption that uses device passwords as the key (requiring the doorbell to be aware of the chime's password) and the use of only the first five characters of the password as input to the KDF. It doesn't give me a great deal of confidence in the rest of the device's security, so I'm going to keep playing.

[1] This seems to be to handle the case where the chime isn't on the same network as the doorbell

comment count unavailable comments

4 May 2021

Steve Kemp: Password store plugin: env

Like many I use pass for storing usernames and passwords. This gives me easy access to credentials in a secure manner. I don't like the way that the metadata (i.e. filenames) are public, but that aside it is a robust tool I've been using for several years. The last time I talked about pass was when I talked about showing the age of my credentials, via the integrated git support. That then became a pass-plugin: 
  frodo ~ $ pass age
  6 years ago GPG/root@localhost.gpg
  6 years ago GPG/steve@steve.org.uk.OLD.gpg
  ..
  4 years, 8 months ago Domains/Domain.fi.gpg
  4 years, 7 months ago Mobile/dna.fi.gpg
  ..
  1 year, 3 months ago Websites/netlify.com.gpg
  1 year ago Financial/ukko.fi.gpg
  1 year ago Mobile/KiK.gpg
  4 days ago Enfuce/sre.tst.gpg
  ..
Anyway today's work involved writing another plugin, named env. I store my data in pass in a consistent form, each entry looks like this: 
   username: steve
   password: secrit
   site: http://example.com/login/blah/
   # Extra data
The keys vary, sometimes I use "login", sometimes "username", other times "email", but I always label the fields in some way. Recently I was working with some CLI tooling that wants to have a username/password specified and I patched it to read from the environment instead. Now I can run this: 
     $ pass env internal/cli/tool-name
     export username="steve"
     export password="secrit"
That's ideal, because now I can source that from within a shell: 
   $ source <(pass env internal/cli/tool-name)
   $ echo username
   steve
Or I could directly execute the tool I want: 
   $ pass env --exec=$HOME/ldap/ldap.py internal/cli/tool-name
   you are steve
   ..
TLDR: If you store your password entries in "key: value" form you can process them to export $KEY=$value, and that allows them to be used without copying and pasting into command-line arguments (e.g. "~/ldap/ldap.py --username=steve --password=secrit")

Steve Kemp: Password store plugin: enve

Like many I use pass for storing usernames and passwords. This gives me easy access to credentials in a secure manner. I don't like the way that the metadata (i.e. filenames) are public, but that aside it is a robust tool I've been using for several years. The last time I talked about pass was when I talked about showing the age of my credentials, via the integrated git support. That then became a pass-plugin: 
  frodo ~ $ pass age
  6 years ago GPG/root@localhost.gpg
  6 years ago GPG/steve@steve.org.uk.OLD.gpg
  ..
  4 years, 8 months ago Domains/Domain.fi.gpg
  4 years, 7 months ago Mobile/dna.fi.gpg
  ..
  1 year, 3 months ago Websites/netlify.com.gpg
  1 year ago Financial/ukko.fi.gpg
  1 year ago Mobile/KiK.gpg
  4 days ago Enfuce/sre.tst.gpg
  ..
Anyway today's work involved writing another plugin, named env. I store my data in pass in a consistent form, each entry looks like this: 
   username: steve
   password: secrit
   site: http://example.com/login/blah/
   # Extra data
The keys vary, sometimes I use "login", sometimes "username", other times "email", but I always label the fields in some way. Recently I was working with some CLI tooling that wants to have a username/password specified and I patched it to read from the environment instead. Now I can run this: 
     $ pass env internal/cli/tool-name
     export username="steve"
     export password="secrit"
That's ideal, because now I can source that from within a shell: 
   $ source <(pass env internal/cli/tool-name)
   $ echo username
   steve
Or I could directly execute the tool I want: 
   $ pass env --exec=$HOME/ldap/ldap.py internal/cli/tool-name
   you are steve
   ..
TLDR: If you store your password entries in "key: value" form you can process them to export $KEY=$value, and that allows them to be used without copying and pasting into command-line arguments (e.g. "~/ldap/ldap.py --username=steve --password=secrit")

Erich Schubert: Machine Learning Lecture Recordings

I have uploaded most of my Machine Learning lecture to YouTube. The slides are in English, but the audio is in German. Some very basic contents (e.g., a demo of standard k-means clustering) were left out from this advanced class, and instead only a link to recordings from an earlier class were given. In this class, I wanted to focus on the improved (accelerated) algorithms instead. These are not included here (yet). I believe there are some contents covered in this class you will find nowhere else (yet). The first unit is pretty long (I did not split it further yet). The later units are shorter recordings. ML F1: Principles in Machine Learning ML F2/F3: Correlation does not Imply Causation & Multiple Testing Problem ML F4: Overfitting beranpassung ML F5: Fluch der Dimensionalit t Curse of Dimensionality ML F6: Intrinsische Dimensionalit t Intrinsic Dimensionality ML F7: Distanzfunktionen und hnlichkeitsfunktionen ML L1: Einf hrung in die Klassifikation ML L2: Evaluation und Wahl von Klassifikatoren ML L3: Bayes-Klassifikatoren ML L4: N chste-Nachbarn Klassifikation ML L5: N chste Nachbarn und Kerndichtesch tzung ML L6: Lernen von Entscheidungsb umen ML L7: Splitkriterien bei Entscheidungsb umen ML L8: Ensembles und Meta-Learning: Random Forests und Gradient Boosting ML L9: Support Vector Machinen - Motivation ML L10: Affine Hyperebenen und Skalarprodukte Geometrie f r SVMs ML L11: Maximum Margin Hyperplane die breitest m gliche Stra e ML L12: Training Support Vector Machines ML L13: Non-linear SVM and the Kernel Trick ML L14: SVM Extensions and Conclusions ML L15: Motivation of Neural Networks ML L16: Threshold Logic Units ML L17: General Artificial Neural Networks ML L18: Learning Neural Networks with Backpropagation ML L19: Deep Neural Networks ML L20: Convolutional Neural Networks ML L21: Recurrent Neural Networks and LSTM ML L22: Conclusion Classification ML U1: Einleitung Clusteranalyse ML U2: Hierarchisches Clustering ML U3: Accelerating HAC mit Anderberg s Algorithmus ML U4: k-Means Clustering ML U5: Accelerating k-Means Clustering ML U6: Limitations of k-Means Clustering ML U7: Extensions of k-Means Clustering ML U8: Partitioning Around Medoids (k-Medoids) ML U9: Gaussian Mixture Modeling (EM Clustering) ML U10: Gaussian Mixture Modeling Demo ML U11: BIRCH and BETULA Clustering ML U12: Motivation Density-Based Clustering (DBSCAN) ML U13: Density-reachable and density-connected (DBSCAN Clustering) ML U14: DBSCAN Clustering ML U15: Parameterization of DBSCAN ML U16: Extensions and Variations of DBSCAN Clustering ML U17: OPTICS Clustering ML U18: Cluster Extraction from OPTICS Plots ML U19: Understanding the OPTICS Cluster Order ML U20: Spectral Clustering ML U21: Biclustering and Subspace Clustering ML U22: Further Clustering Approaches

Benjamin Mako Hill: NSF CAREER Award

In exciting professional news, it was recently announced that I got an National Science Foundation CAREER award! The CAREER is the US NSF s most prestigious award for early-career faculty. In addition to the recognition, the award involves a bunch of money for me to put toward my research over the next 5 years. The Department of Communication at the University of Washington has put up a very nice web page announcing the thing. It s all very exciting and a huge honor. I m very humbled. The grant will support a bunch of new research to develop and test a theory about the relationship between governance and online community lifecycles. If you ve been reading this blog for a while, you ll know that I ve been involved in a bunch of research to describe how peer production communities tend to follow common patterns of growth and decline as well as a studies that show that many open communities become increasingly closed in ways that deter lots of the kinds contributions that made the communities successful in the first place. Over the last few years, I ve worked with Aaron Shaw to develop the outlines of an explanation for why many communities because increasingly closed over time in ways that hurt their ability to integrate contributions from newcomers. Over the course of the work on the CAREER, I ll be continuing that project with Aaron and I ll also be working to test that explanation empirically and to develop new strategies about what online communities can do as a result. In addition to supporting research, the grant will support a bunch of new outreach and community building within the Community Data Science Collective. In particular, I m planning to use the grant to do a better job of building relationships with community participants, community managers, and others in the platforms we study. I m also hoping to use the resources to help the CDSC do a better job of sharing our stuff out in ways that are useful as well doing a better job of listening and learning from the communities that our research seeks to inform. There are many to thank. The proposed work was the direct research of the work I did as the Center for Advanced Studies in the Behavioral Sciences at Stanford where I got to spend the 2018-2019 academic year in Claude Shannon s old office and talking through these ideas with an incredible range of other scholars over lunch every day. It s also the product of years of conversations with Aaron Shaw and Yochai Benkler. The proposal itself reflects the excellent work of the whole CDSC who did the work that made the award possible and provided me with detailed feedback on the proposal itself.

3 May 2021

Russell Coker: DNS, Lots of IPs, and Postal

I decided to start work on repeating the tests for my 2006 OSDC paper on Benchmarking Mail Relays [1] and discover how the last 15 years of hardware developments have changed things. There have been software changes in that time too, but nothing that compares with going from single core 32bit systems with less than 1G of RAM and 60G IDE disks to multi-core 64bit systems with 128G of RAM and SSDs. As an aside the hardware I used in 2006 wasn t cutting edge and the hardware I m using now isn t either. In both cases it s systems I bought second hand for under $1000. Pedants can think of this as comparing 2004 and 2018 hardware. BIND I decided to make some changes to reflect the increased hardware capacity and use 2560 domains and IP addresses, which gave the following errors as well as a startup time of a minute on a system with two E5-2620 CPUs. 
May  2 16:38:37 server named[7372]: listening on IPv4 interface lo, 127.0.0.1#53
May  2 16:38:37 server named[7372]: listening on IPv4 interface eno4, 10.0.2.45#53
May  2 16:38:37 server named[7372]: listening on IPv4 interface eno4, 10.0.40.1#53
May  2 16:38:37 server named[7372]: listening on IPv4 interface eno4, 10.0.40.2#53
May  2 16:38:37 server named[7372]: listening on IPv4 interface eno4, 10.0.40.3#53
[...]
May  2 16:39:33 server named[7372]: listening on IPv4 interface eno4, 10.0.47.0#53
May  2 16:39:33 server named[7372]: listening on IPv4 interface eno4, 10.0.48.0#53
May  2 16:39:33 server named[7372]: listening on IPv4 interface eno4, 10.0.49.0#53
May  2 16:39:33 server named[7372]: listening on IPv6 interface lo, ::1#53
[...]
May  2 16:39:36 server named[7372]: zone localhost/IN: loaded serial 2
May  2 16:39:36 server named[7372]: all zones loaded
May  2 16:39:36 server named[7372]: running
May  2 16:39:36 server named[7372]: socket: file descriptor exceeds limit (123273/21000)
May  2 16:39:36 server named[7372]: managed-keys-zone: Unable to fetch DNSKEY set '.': not enough free resources
May  2 16:39:36 server named[7372]: socket: file descriptor exceeds limit (123273/21000)
The first thing I noticed is that a default configuration of BIND with 2560 local IPs (when just running in the default recursive mode) takes a minute to start and needed to open over 100,000 file handles. BIND also had some errors in that configuration which led to it not accepting shutdown requests. I filed Debian bug report #987927 [2] about this. One way of dealing with the errors in this situation on Debian is to edit /etc/default/named and put in the following line to allow BIND to access to many file handles: 
OPTIONS="-u bind -S 150000"
But the best thing to do for BIND when there are many IP addresses that aren t going to be used for DNS service is to put a directive like the following in the BIND configuration to specify the IP address or addresses that are used for the DNS service: 
listen-on   10.0.2.45;  ;
I have just added the listen-on and listen-on-v6 directives to one of my servers with about a dozen IP addresses. While 2560 IP addresses is an unusual corner case it s not uncommon to have dozens of addresses on one system. dig When doing tests of Postfix for relaying mail I noticed that mail was being deferred with DNS problems (error was Host or domain name not found. Name service error for name=a838.example.com type=MX: Host not found, try again . I tested the DNS lookups with dig which failed with errors like the following: 
dig -t mx a704.example.com
socket.c:1740: internal_send: 10.0.2.45#53: Invalid argument
socket.c:1740: internal_send: 10.0.2.45#53: Invalid argument
socket.c:1740: internal_send: 10.0.2.45#53: Invalid argument
; <
> DiG 9.16.13-Debian <
> -t mx a704.example.com
;; global options: +cmd
;; connection timed out; no servers could be reached


Here is a sample of the strace output from tracing dig:

bind(20,  sa_family=AF_INET, sin_port=htons(0), 
sin_addr=inet_addr("0.0.0.0") , 16) = 0
recvmsg(20,  msg_namelen=128 , 0)       = -1 EAGAIN (Resource temporarily 
unavailable)
write(4, "\24\0\0\0\375\377\377\377", 8) = 8
sendmsg(20,  msg_name= sa_family=AF_INET, sin_port=htons(53), 
sin_addr=inet_addr("10.0.2.45") , msg_
namelen=16, msg_iov=[ iov_base="86\1 
\0\1\0\0\0\0\0\1\4a704\7example\3com\0\0\17\0\1\0\0)\20\0\0\0\0
\0\0\f\0\n\0\10's\367\265\16bx\354", iov_len=57 ], msg_iovlen=1, 
msg_controllen=0, msg_flags=0 , 0) 
= -1 EINVAL (Invalid argument)
write(2, "socket.c:1740: ", 15)         = 15
write(2, "internal_send: 10.0.2.45#53: Invalid argument", 45) = 45
write(2, "\n", 1)                       = 1
futex(0x7f5a80696084, FUTEX_WAIT_PRIVATE, 0, NULL) = 0
futex(0x7f5a80696010, FUTEX_WAKE_PRIVATE, 1) = 0
futex(0x7f5a8069809c, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f5a80698020, FUTEX_WAKE_PRIVATE, 1) = 1
sendmsg(20,  msg_name= sa_family=AF_INET, sin_port=htons(53), 
sin_addr=inet_addr("10.0.2.45") , msg_namelen=16, msg_iov=[ iov_base="86\1 
\0\1\0\0\0\0\0\1\4a704\7example\3com\0\0\17\0\1\0\0)\20\0\0\0\0\0\0\f\0\n\0\10's\367\265\16bx\354", 
iov_len=57 ], msg_iovlen=1, msg_controllen=0, msg_flags=0 , 0) = -1 EINVAL 
(Invalid argument)
write(2, "socket.c:1740: ", 15)         = 15
write(2, "internal_send: 10.0.2.45#53: Invalid argument", 45) = 45
write(2, "\n", 1)


Ubuntu bug #1702726 claims that an insufficient ARP cache was the cause of dig problems [3]. At the time I encountered the dig problems I was seeing lots of kernel error messages  neighbour: arp_cache: neighbor table overflow  which I solved by putting the following in /etc/sysctl.d/mine.conf:

net.ipv4.neigh.default.gc_thresh3 = 4096
net.ipv4.neigh.default.gc_thresh2 = 2048
net.ipv4.neigh.default.gc_thresh1 = 1024


Making that change (and having rebooted because I didn t need to run the server overnight) didn t entirely solve the problems. I have seen some DNS errors from Postfix since then but they are less common than before. When they happened I didn t have that error from dig. At this stage I m not certain that the ARP change fixed the dig problem although it seems likely (it s always difficult to be certain that you have solved a race condition instead of made it less common or just accidentally changed something else to conceal it). But it is clearly a good thing to have a large enough ARP cache so the above change is probably the right thing for most people (with the possibility of changing the numbers according to the required scale). Also people having that dig error should probably check their kernel message log, if the ARP cache isn t the cause then some other kernel networking issue might be related.
Preliminary Results
With Postfix I m seeing around 24,000 messages relayed per minute with more than 60% CPU time idle. I m not sure exactly how to count idle time when there are 12 CPU cores and 24 hyper-threads as having only 1 process scheduled for each pair of hyperthreads on a core is very different to having half the CPU cores unused. I ran my script to disable hyper-threads by telling the Linux kernel to disable each processor core that has the same core ID as another, it was buggy and disabled the second CPU altogether (better than finding this out on a production server). Going from 24 hyper-threads of 2 CPUs to 6 non-HT cores of a single CPU didn t change the thoughput and the idle time went to about 30%, so I have possibly halved the CPU capacity for these tasks by disabling all hyper-threads and one entire CPU which is surprising given that I theoretically reduced the CPU power by 75%. I think my focus now has to be on hyper-threading optimisation.
Since 2006 the performance has gone from ~20 messages per minute on relatively commodity hardware to 24,000 messages per minute on server equipment that is uncommon for home use but which is also within range of home desktop PCs. I think that a typical desktop PC with a similar speed CPU, 32G of RAM and SSD storage would give the same performance. Moore s Law (that transistor count doubles approximately every 2 years) is often misquoted as having performance double every 2 years. In this case more than 1024* the performance over 15 years means the performance doubling every 18 months. Probably most of that is due to SATA SSDs massively outperforming IDE hard drives but it s still impressive.
Notes
I ve been using example.com for test purposes for a long time, but RFC2606 specifies .test, .example, and .invalid as reserved top level domains for such things. On the next iteration I ll change my scripts to use .test.
My current test setup has a KVM virtual machine running my bhm program to receive mail which is taking between 20% and 50% of a CPU core in my tests so far. While that is happening the kvm process is reported as taking between 60% and 200% of a CPU core, so kvm takes as much as 4* the CPU of the guest due to the virtual networking overhead   even though I m using the virtio-net-pci driver (the most efficient form of KVM networking for emulating a regular ethernet card). I ve also seen this in production with a virtual machine running a ToR relay node.
I ve fixed a bug where Postal would try to send the SMTP quit command after encountering a TCP error which would cause an infinite loop and SEGV.



Related posts:
    

  1. interesting things  /tmp /mnt/bind bind bind 0 0 Today I discovered that...
    2. 

  2. new release of postal  Today I have released a significant new version of my...
    3. 

  3. BIND Stats  In Debian the BIND server will by default append statistics...
    4.

Russ Allbery: Review: The Voyage of the Dawn Treader

Review: The Voyage of the Dawn Treader, by C.S. Lewis
Illustrator: Pauline Baynes
Series: Chronicles of Narnia #3
Publisher: Collier Books
Copyright: 1952
Printing: 1978
ISBN: 0-02-044260-2
Format: Mass market
Pages: 216
There was a boy named Eustace Clarence Scrubb and he almost deserved it.
The Voyage of the Dawn Treader is the third Narnia book in original publication order (see my review of The Lion, the Witch and the Wardrobe for more about reading order). You could arguably start reading here; there are a lot of references to the previous books, but mostly as background material, and I don't think any of it is vital. If you wanted to sample a single Narnia book to see if you'd get along with the series, this is the one I'd recommend. Since I was a kid, The Voyage of the Dawn Treader has held the spot of my favorite of the series. I'm happy to report that it still holds up. Apart from one bit that didn't age well (more on that below), this is the book where the story and the world-building come together, in part because Lewis picks a plot shape that works with what he wants to write about. The younger two Pevensie children, Edmund and Lucy, are spending the summer with Uncle Harold and Aunt Alberta because their parents are in America. That means spending the summer with their cousin Eustace. C.S. Lewis had strong opinions about child-raising that crop up here and there in his books, and Harold and Alberta are his example of everything he dislikes: caricatured progressive, "scientific" parents who don't believe in fiction or mess or vices. Eustace therefore starts the book as a terror, a whiny bully who has only read boring practical books and is constantly scoffing at the Pevensies and making fun of their stories of Narnia. He is therefore entirely unprepared when the painting of a ship in the guest bedroom turns into a portal to the Narnia and dumps the three children into the middle of the ocean. Thankfully, they're in the middle of the ocean near the ship in the painting. That ship is the Dawn Treader, and onboard is Caspian from the previous book, now king of Narnia. He has (improbably) sorted things out in his kingdom and is now on a sea voyage to find seven honorable Telmarine lords who left Narnia while his uncle was usurping the throne. They're already days away from land, headed towards the Lone Islands and, beyond that, into uncharted seas. MAJOR SPOILERS BELOW. Obviously, Eustace gets a redemption arc, which is roughly the first half of this book. It's not a bad arc, but I am always happy when it's over. Lewis tries so hard to make Eustace insufferable that it becomes tedious. As an indoor kid who would not consider being dumped on a primitive sailing ship to be a grand adventure, I wanted to have more sympathy for him than the book would allow. The other problem with Eustace's initial character is that Lewis wants it to stem from "modern" parenting and not reading the right sort of books, but I don't buy it. I've known kids whose parents didn't believe in fiction, and they didn't act anything like this (and kids pick up a lot more via osmosis regardless of parenting than Lewis seems to realize). What Eustace acts like instead is an entitled, arrogant rich kid who is used to the world revolving around him, and it's fascinating to me how Lewis ignores class to focus on educational philosophy. The best part of Eustace's story is Reepicheep, which is just setup for Reepicheep becoming the best part of The Voyage of the Dawn Treader. Reepicheep, the leader of Narnia's talking mice, first appears in Prince Caspian, but there he's mostly played for laughs: the absurdly brave and dashing mouse who rushes into every fight he sees. In this book, he comes into his own as the courage and occasionally the moral conscience of the party. Caspian wants to explore and to find the lords of his past, the Pevensie kids want to have a sea adventure, and Eustace is in this book to have a redemption arc, but Reepicheep is the driving force at the heart of the voyage. He's going to Aslan's country beyond the sea, armed with a nursemaid's song about his destiny and a determination to be his best and most honorable self every step of the way, and nothing is going to stop him. Eustace, of course, takes an immediate dislike to a talking rodent. Reepicheep, in return, is the least interested of anyone on the ship in tolerating Eustace's obnoxious behavior and would be quite happy to duel him. But when Eustace is turned into a dragon, Reepicheep is the one who spends hours with him, telling him stories and ensuring he's not alone. It's beautifully handled, and my only complaint is that Lewis doesn't do enough with the Eustace and Reepicheep friendship (or indeed with Eustace at all) for the rest of the book. After Eustace's restoration and a few other relatively short incidents comes the second long section of the book and the part that didn't age well: the island of the Dufflepuds. It's a shame because the setup is wonderful: a cultivated island in the middle of nowhere with no one in sight, mysterious pounding sounds and voices, the fun of trying to figure out just what these invisible creatures could possibly be, and of course Lucy's foray into the second floor of a house, braving the lair of a magician to find and read one of the best books of magic in fantasy. Everything about how Lewis sets this scene is so well done. The kids are coming from an encounter with a sea serpent and a horrifically dangerous magic island and land on this scene of eerily normal domesticity. The most dangerous excursion is Lucy going upstairs in a brightly lit house with soft carpet in the middle of the day. And yet it's incredibly tense because Lewis knows exactly how to put you in Lucy's head, right down to having to stand with her back to an open door to read the book. And that book! The pages only turn forward, the spells are beautifully illustrated, and the sense of temptation is palpable. Lucy reading the eavesdropping spell is one of the more memorable bits in this series, at least for me, and makes a surprisingly subtle moral point about the practical reasons why invading other people's privacy is unwise and can just make you miserable. And then, when Lucy reads the visibility spell that was her goal, there's this exchange, which is pure C.S. Lewis:
"Oh Aslan," said she, "it was kind of you to come." "I have been here all the time," said he, "but you have just made me visible." "Aslan!" said Lucy almost a little reproachfully. "Don't make fun of me. As if anything I could do would make you visible!" "It did," said Aslan. "Did you think I wouldn't obey my own rules?"
I love the subtlety of what's happening here: the way that Lucy is much more powerful than she thinks she is, but only because Aslan decided to make the rules that way and chooses to follow his own rules, making himself vulnerable in a fascinating way. The best part is that Lewis never belabors points like this; the characters immediately move on to talk about other things, and no one feels obligated to explain. But, unfortunately, along with the explanation of the thumping and the magician, we learn that the Dufflepuds are (remarkably dim-witted) dwarfs, the magician is their guardian (put there by Aslan, no less!), he transformed them into rather absurd shapes that they hate, and all of this is played for laughs. Once you notice that these are sentient creatures being treated essentially like pets (and physically transformed against their will), the level of paternalistic colonialism going on here is very off-putting. It's even worse that the Dufflepuds are memorably funny (washing dishes before dinner to save time afterwards!) and are arguably too dim to manage on their own, because Lewis made the authorial choice to write them that way. The "white man's burden" feeling is very strong. And Lewis could have made other choices! Coriakin the magician is a fascinating and somewhat morally ambiguous character. We learn later in the book that he's a star and his presence on the island is a punishment of sorts, leading to one of my other favorite bits of theology in this book:
"My son," said Ramandu, "it is not for you, a son of Adam, to know what faults a star can commit."
Lewis could have kept most of the setup, kept the delightfully silly things the Dufflepuds believe, changed who was responsible for their transformation, and given Coriakin a less authoritarian role, and the story would have been so much stronger for it. After this, the story gets stranger and wilder, and it's in the last part that I think the true magic of this book lies. The entirety of The Voyage of the Dawn Treader is a progression from a relatively mundane sea voyage to something more awe-inspiring. The last few chapters are a tour de force of wonder: rejuvenating stars, sunbirds, the Witch's stone knife, undersea kingdoms, a sea of lilies, a wall of water, the cliffs of Aslan's country, and the literal end of the world. Lewis does it without much conflict, with sparse description in a very few pages, and with beautifully memorable touches like the quality of the light and the hush that falls over the ship. This is the part of Narnia that I point to and wonder why I don't see more emulation (although I should note that it is arguably an immram). Tolkien-style fantasy, with dwarfs and elves and magic rings and great battles, is everywhere, but I can't think of many examples of this sense of awe and discovery without great battles and detailed explanations. Or of characters like Reepicheep, who gets one of the best lines of the series:
"My own plans are made. While I can, I sail east in the Dawn Treader. When she fails me, I paddle east in my coracle. When she sinks, I shall swim east with my four paws. And when I can swim no longer, if I have not reached Aslan's country, or shot over the edge of the world in some vast cataract, I shall sink with my nose to the sunrise and Peepiceek shall be the head of the talking mice in Narnia."
The last section of The Voyage of the Dawn Treader is one of my favorite endings of any book precisely because it's so different than the typical ending of a novel. The final return to England is always a bit disappointing in this series, but it's very short and is preceded by so much wonder that I don't mind. Aslan does appear to the kids as a lamb at the very end of the world, making Lewis's intended Christian context a bit more obvious, but even that isn't belabored, just left there for those who recognize the symbolism to notice. I was curious during this re-read to understand why The Voyage of the Dawn Treader is so much better than the first two books in the series. I think it's primarily due to two things: pacing, and a story structure that's better aligned with what Lewis wants to write about. For pacing, both The Lion, the Witch and the Wardrobe and Prince Caspian have surprisingly long setups for short books. In The Voyage of the Dawn Treader, by contrast, it takes only 35 pages to get the kids in Narnia, introduce all the characters, tour the ship, learn why Caspian is off on a sea voyage, establish where this book fits in the Narnian timeline, and have the kids be captured by slavers. None of the Narnia books are exactly slow, but Dawn Treader is the first book of the series that feels like it knows exactly where it's going and isn't wasting time getting there. The other structural success of this book is that it's a semi-episodic adventure, which means Lewis can stop trying to write about battles and political changes whose details he's clearly not interested in and instead focus wholeheartedly on sense-of-wonder exploration. The island-hopping structure lets Lewis play with ideas and drop them before they wear out their welcome. And the lack of major historical events also means that Aslan doesn't have to come in to resolve everything and instead can play the role of guardian angel. I think The Voyage of the Dawn Treader has the most compelling portrayal of Aslan in the series. He doesn't make decisions for the kids or tell them directly what to do the way he did in the previous two books. Instead, he shows up whenever they're about to make a dreadful mistake and does just enough to get them to make a better decision. Some readers may find this takes too much of the tension out of the book, but I have always appreciated it. It lets nervous child readers enjoy the adventures while knowing that Aslan will keep anything too bad from happening. He plays the role of a protective but non-interfering parent in a genre that usually doesn't have parents because they would intervene to prevent adventures. I enjoyed this book just as much as I remembered enjoying it during my childhood re-reads. Still the best book of the series. This, as with both The Lion, the Witch and the Wardrobe and Prince Caspian, was originally intended to be the last book of the series. That, of course, turned out to not be the case, and The Voyage of the Dawn Treader is followed (in both chronological and original publication order) by The Silver Chair. Rating: 9 out of 10

Junichi Uekawa: First email from my new machine.

First email from my new machine. I didn't have my desktop Debian machine for a long time and now I have one set up. I rewrote my procmail/formail recipe, especially the part where I wrote complex shell script to generate my folder rules. I rewrote that 4 lines of shell script in 200 lines of Go, with unit tests. The part that took the longest time was finding out how to write unit tests in Go, and how to properly use go.mod to be able to import packages from subdirectories. I guess that's part of the fun.

2 May 2021

Santiago Garc a Manti n: Windows and Linux software Raid dual boot BIOS machine

One could think that nowadays having a machine with software raid doing dual boot should be easy, but... my experience showed that it is not that easy.Having a Windows machine do software raid is easy (I still don't understand why it doesn't really work like it should, but that is because I'm used to Linux software raid), and having software raid on Linux is also really easy. But doing so on a BIOS booted machine, on mbr disks (as Windows doesn't allow GPT on BIOS) is quite a pain.The problem is how Windows does all this, with it's dynamic disks. What happens with this is that you get from a partitioning like this:/dev/sda1 * 2048 206847 204800 100M 7 HPFS/NTFS/exFAT /dev/sda2 206848 312580095 312373248 149G 7 HPFS/NTFS/exFAT /dev/sda3 312580096 313165823 585728 286M 83 Linux /dev/sda4 313165824 957698047 644532224 307,3G fd Linux raid autodetect To something like this:/dev/sda1 63 2047 1985 992,5K 42 SFS /dev/sda2 * 2048 206847 204800 100M 42 SFS /dev/sda3 206848 312580095 312373248 149G 42 SFS /dev/sda4 312580096 976769006 664188911 316,7G 42 SFS These are the physical partitions as seen by fdisk, logical partitions are still like before, of course, so there is no problem in accesing them under Linux or windows, but what happens here is that Windows is using the first sectors for its dynamic disks stuff, so... you cannot use those to write grub info there :-(So... the solution I found here was to install Debian's mbr and make it boot grub, but then... where do I store grub's info?, well, to do this I'm using a btrfs /boot which is on partition 3, as btrfs has room for embedding grub's info, and I setup the software raid with ext4 on partition 4, like you can see on my first partition dump. Of course, you can have just btrfs with its own software raid, then you don't need the fourth partition or anything.There are however some caveats on doing all this, what I found was that I had to install grub manually using grub-install --no-floppy on /dev/sda3 and /dev/sdb3, as Debian's grub refused to give me the option to install there, also... several warnings came as a result, but things work ok anyway.One more warning, I did all this on Buster, but it looks like for Grub 2.04 which is included on Bullseye, things have gotten a bit bigger, so at least on my partitions there was no room for it, so I had to leave the old Buster's grub around for now, if anybody has any ideas on how to solve this... they are welcome.

1 May 2021

Ingo Juergensmann: The Fediverse What About Resources?

Today ist May, 1st. In about two weeks on May, 15th WhatsApp will put their changed Terms of Service into action and when you don t accept their rules you won t be able to use WhatsApp any longer. Early this year there was already a strong movement away from WhatsApp towards other solutions. Mainly to Signal, but also some other services like the Fediverse gained some new users. And also XMPP got their fair share of new users. So, what to do about the WhatsApp ToS change then? Shall we go all to Signal? Surely not. Signal is another vendor lock-in silo. It s centralistic and recent development plans want to implement some crypto payment system. Even Bruce Schneier thinks that this is a bad idea. Other alternatives often named include Matrix/Element or XMPP. Today, Don di Dislessia in the (german) Fediverse asked about power consumption of the Fediverse incl. Matrix and XMPP and how much renewable energy is being used. Of course this is no easy answer to this question, but I tried my best at least for my own server. Here are my findings and conclusions Power
screenshot showing power consumption of serverscreenshot showing power consumption of server
Currently my server in the colocation is using about 93W in average with 6c Xeon E5-2630L, 128 GB RAM, 4x 2 TB WD Red + 1 Samsung 960pro NVMe. The server is 7 years old. When I started with that server the power consumption was about 75W, but back then there were far less users on the server. So, 20W more over the past year Users I m running my Friendica node on Nerdica.net since 2013. Over the years it became one of the largest Friendica servers in the Fediverse, for some time it was the largest one. It has currently like 700 total users and 180 monthly active users. My Mastodon instance on Nerdculture.de has about 1000 total users and about 300 monthly active users. Since last year I also run a Matrix-Synapse server. Although I invited my family I m in fact the only active user on that server and have joined some channels. My XMPP server is even older than my Friendica node. For long time I had like maybe 20 users. Now I setup a new website and added some domains like hookipa.net and xmpp.social the user count increased and currently I have like 130 users on those two domains and maybe like 50 monthly active users. Also note that all my Friendica and Mastodon users can use XMPP with their accounts, but won t be counted the same way as on native users on ejabberd, because the auth backend is different. So, let s assume I do have like 2000 total users and 500 monthly active users. CPU, Database Sizes and Disk I/O Let s have a look about how many resources are being used by those users. Database Sizes: CPU times according to xentop: Friendica does use the largest database and causes most disk I/O on NVMe, but it s difficult to differentiate between the load between the web apps on the webserver. So, let s have a quick look on an simple metric: Number of lines in webserver logfile: These metrics correlate to some degree with the database I/O load, at least for Friendica. If you take into account the number of users, things look quite different. Conclusion Overall, and my personal impression, is that Matrix is really bad in regards of resource usage. Given that I m the only active user it uses exceptionally many resources. When you also consider that Matrix is using a distributed database for its chat rooms, you can assume that the resource usage is multiplied across the network, making things even worse. Friendica is using a large database and many disk accesses, but has a fairly large user base, so it seems ok, but of course should be improved. Mastodon seems to be quite good, considering the database size, the number of log lines and the user count. XMPP turns out to be the most efficient contestant in this comparison: it uses much less CPU cycles and database disk I/O. Of course, Mastdon/Friendica are different services than XMPP or Matrix. So, coming back to the initial question about alternatives to WhatsApp, the answer for me is: you should prefer XMPP over Matrix alone for reasons of saving resources and thus reducing power consumption. Less power consumption also means a smaller ecological footprint and fewer CO2 emissions for your communication with your family and friends. XMPP is surely not the perfect replacement for WhatsApp, but I think it is the best thing to recommend. As said above, I don t think that Signal is an viable option. It s just another proprierary silo with all the problems that come with it. Matrix is a resource hog and not a messenger but a MS Teams replacement. Element as the main Matrix client is laggy and not multi-account/multi-server capable. Other Matrix clients do support multiple accounts but are not as feature-complete as Element. In the end the Matrix ecosystem will suffer from the same issues as XMPP did already a decade ago. But XMPP has learned to deal with it. Also XMPP is proceeding fast in the last years and it has solved many problems many people are still complaining about. Sure, there still some open issues. The situation on IOS is still not as good as on Android with Conversations, but it is fairly close to it. There are many efforts to improve XMPP. There is Quicksy IM, which is a service that will use your phone number as Jabber ID/JID and is thus comparable to Signal which uses phone numbers as well as unique identifier. But Quicksy is compatible with XMPP standards. Snikket is another new XMPP ecosystem aiming at smaller groups hosting their own server by simply installing a Docker container and setup some basic SRV records in the DNS. Or there is Mailcow, a Docker based mailserver setup that added XMPP server in their setup as well, so you can have the same mail and XMPP address. Snikket even got EU based funding for implementing XMPP Account Portability which also will improve the decentralization even further. Additionally XMPP helps vaccination in Canada and USA with vaxbot by Monal. Be smart and use ecofriendly infrastructure.

Utkarsh Gupta: FOSS Activites in April 2021

Here s my (nineteenth) monthly update about the activities I ve done in the F/L/OSS world.

Debian
This was my 28th month of actively contributing to Debian. I became a DM in late March 2019 and a DD on Christmas 19! \o/ Crazy month, as always. Lots of things happening and lots of moving parts.
Now that I am working on Ubuntu-full time, I barely get much time to do any extra stuff. Then the massive COVID wave that has plunged India had made this month further crazier. More on that later, maybe. IDK. Anyway, I did some Debian stuff, thanks to Salzburg BSP (more down below). I worked on the following stuff:

Uploads and bug fixes:

Other $things:
  • Mentoring for newcomers and assisting people in BSP.
  • Moderation of -project mailing list.

Salzburg BSP 2021 This was my first virtual BSP and the first BSP in Salzburg and it was absolutely amazing!
Many kudos to Bernd Zeimetz for organizing it so smoothly and wonderfully, for real! \o/ We had a bunch of amazing sessions, besides hacking, of course, like:
  • yoga,
  • sports,
  • games, and
  • datacenter tour -> which was super!
We also had lots of things happening at #debian-bsp-2021-szg and did a lot of work.
Whilst everything we did is available on the pad, I work on the following things:
  • [deki/utkarsh]: CVE-2021-28421/fluidsynth (sid); cf: #987168/#987471.
  • [deki/utkarsh]: CVE-2021-28421/fluidsynth (buster); cf: #987168/#987494.
  • [utkarsh]: 18 CVEs for jackson-databind (buster); cf: #987489.
  • [utkarsh]: fix for ruby-librarian/#987113 (unblock request: #987501).
  • [utkarsh]: 17 CVEs for jackson-databind (stretch); LTS upload.
  • [utkarsh]: CVE-2020-12460/opendmarc (stretch); LTS upload.
  • [utkarsh]: CVE-2020-12460/opendmarc (buster); cf: #987531.
  • [deki/utkarsh]: libpam-alreadyloggedin, broken autopkgtest; #958224
  • [deki/utkarsh]: libpam-alreadyloggedin, installed in wrong directory; #986247
  • [deki/utkarsh]: libpam-alreadyloggedin, FTCBFS; #969122
  • [donfede/utkarsh] 10 CVEs for salt (buster)
  • [donfede/utkarsh] 10 CVEs for salt (bullseye)
And finally, we clicked a picture! \o/

Debian (E)LTS
Debian Long Term Support (LTS) is a project to extend the lifetime of all Debian stable releases to (at least) 5 years. Debian LTS is not handled by the Debian security team, but by a separate group of volunteers and companies interested in making it a success. And Debian Extended LTS (ELTS) is its sister project, extending support to the Jessie release (+2 years after LTS support). This was my nineteenth month as a Debian LTS and tenth month as a Debian ELTS paid contributor.
I was assigned 60.00 hours for LTS and 60.00 hours for ELTS and worked on the following things:

LTS CVE Fixes and Announcements:

ELTS CVE Fixes and Announcements:

Other (E)LTS Work:
  • Front-desk duty from 29-03 until 04-04 and then from 26-04 until 02-05 for both LTS and ELTS.
  • Triaged spamassassin, codemirror-js, jackson-databind, wordpress, gstreamer, underscore, python-bleach, plinth, libpano13, salt, dojo, ruby2.7, firefox-esr, clamav, composter, courier-authlib, opendmarc, openexr, libimage-exiftool-perl, tomcat7, libjs-handlebars, libnet-netmask-perl, network-manager, and curl.
  • Mark CVE-2021-20297/network-manager as not-affected for jessie.
  • Mark CVE-2021-22890/curl as not-affected for jessie and stretch.
  • Mark CVE-2020-7760/codemirror-js as not-affected for jessie.
  • Mark CVE-2021-25122/tomcat8 as not-affected for jessie.
  • Mark CVE-2021-XXXX/plinth as no-dsa for stretch.
  • Mark CVE-2021-29424/libnet-netmask-perl as no-dsa for stretch.
  • Mark CVE-2021-28374/courier-authlib as fixed in 0.58-3.1 for jessie.
  • Mark CVE-2021-1252/clamav as not-affected for jessie.
  • Mark CVE-2021-1404/clamav as not-affected for jessie.
  • Mark CVE-2020-4051/dojo as no-dsa for jessie.
  • Mark CVE-2021-29447/wordpress as not-affected for jessie.
  • Mark CVE-2021-29450/wordpress as not-affected for jessie.
  • Mark CVE-2019-20920/libjs-handlebars as ignored for stretch and jessie.
  • Mark CVE-2021-23369/libjs-handlebars as ignored for stretch and jessie.
  • Mark CVE-2020-4051/dojo as fixed in 1.15.4+dfsg1-1 for sid and bullseye.
  • Mark CVE-2021-28965/ruby2.7 fixed in 2.7.3-1 for sid.
  • Mark CVE-2020-12272/opendmarc as postponed for jessie.
  • Mark CVE-2021-20296, CVE-2021-3475, CVE-2021-3476, CVE-2021-3477, CVE-2021-3478, and CVE-2021-3479, affecting openexr, as no-dsa for jessie and stretch.
  • Suggest proposed fixes for CVE-2021-22876/curl on LTS public list.
  • Publish the missing DLA update for the website on behalf of the community contribution. Thread here.
  • Help suggest and unblock work if FD is missing or something. Thread here.
  • Suggest marking CVE-2021-23369/ node,libjs -handlebars as no-dsa/ignored for all suites. Thread here.
  • Help unblock Anton with the failed python2.7 build on i386 by coordinating with the sec team. Thread here.
  • Private ELTS-related discussion on the ELTS list (+ w/ Raphael).
  • Auto EOL ed webkit2gtk, python-bleach, tika, linux, ircii, spice-vdagent, libspring-security-2.0-java, file-roller, rustc, python-django-registration, gsoap, thunderbird, mosquitto, ruby-sidekiq, gnuchess, libpodofo, unbound, drupal7, 389-ds-base, and scrollz for jessie.
  • Answered questions (& discussions) on IRC (#debian-lts and #debian-elts).
  • General and other discussions on LTS private and public mailing list.
Until next time.
:wq for today.

Petter Reinholdtsen: VLC bittorrent plugin in Bullseye, saved by the bell?

Yesterday morning I got a warning call from the Debian quality control system that the VLC bittorrent plugin was due to be removed because of a release critical bug in one of its dependencies. As you might remember, this plugin make VLC able to stream videos directly from a bittorrent source using both torrent files and magnet links, similar to using a HTTP source. I believe such protocol support is a vital feature in VLC, allowing efficient streaming from sources such at the almost 7 million movies in the Internet Archive. The dependency was the unmaintained libtorrent-rasterbar package, and the bug in question blocked its python library from working properly. As I did not want Bullseye to release without bittorrent support in VLC, I set out to check out the status, and track down a fix for the problem. Luckily the issue had already been identified and fixed upstream, providing everything needed. All I needed to do was to fetch the Debian git repository, extract and trim the patch from upstream and apply it to the Debian package for upload. The fixed library was uploaded yesterday evening. But that is not enough to get it into Bullseye, as Debian is currently in package freeze to prepare for a new next stable release. Only non-critical packages with autopkgtest setup included, in other words able to validate automatically that the package is working, are allowed to migrate automatically into the next release at this stage. And the unmaintained libtorrent-rasterbar lack such testing, and thus needed a manual override. I am happy to report that such manual override was approved a few minutes ago, thus increasing significantly the chance of VLC bittorrent streaming being available out of the box also for Debian/Buster users. A bit too close shave for my liking, as the Bullseye release is most likely just a few days away, and this did feel like the package was saved by the bell. I am so glad the warning email showed up in time for me to handle the issue, and a big thanks go to the Debian Release team for the quick feedback on #debian-release and their swift unblocking. As usual, if you use Bitcoin and want to show your support of my activities, please send Bitcoin donations to my address 15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b.

30 April 2021

Paul Wise: FLOSS Activities April 2021

Focus This month I didn't have any particular focus. I just worked on issues in my info bubble.

Changes

Issues

Review

Administration
  • Debian: restart service killed by OOM killer, revert mirror redirection
  • Debian wiki: unblock IP addresses, approve accounts

Communication

Sponsors The flower/sptag work was sponsored by my employer. All other work was done on a volunteer basis.

Chris Lamb: Free software activities in April 2021

Here is my monthly update covering what I have been doing in the free software world during April 2021 (previous month): Reproducible Builds 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 ensure no flaws have been introduced during this compilation process by promising identical results are always generated from a given source, thus allowing multiple third-parties to come to a consensus on whether a build was compromised. The project is proud to be a member project of the Software Freedom Conservancy. 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:
Debian
Debian Long Term Support (LTS) This month I have worked 18 hours on Debian Long Term Support (LTS) and 12 hours on its sister Extended LTS project: You can find out more about the project via the following video:

Rapha&#235;l Hertzog: Freexian s report about Debian Long Term Support, March 2021

A Debian LTS logo
Like each month, have a look at the work funded by Freexian s Debian LTS offering. Debian project funding In March, we put aside 3225 EUR to fund Debian projects but sadly nobody picked up anything, so this one of the many reasons Raphael posted as series of blog posts titled Challenging times for Freexian , posted in 4 parts on the last two days of March and the first two of April. [Part one, two, three and four] So we re still looking forward to receive more projects from various Debian teams! Learn more about the rationale behind this initiative in this article! Debian LTS contributors In March, 11 contributors have been paid to work on Debian LTS, their reports are available: Evolution of the situation In March we released 28 DLAs and held our second LTS team meeting for 2021 on IRC, with the next public IRC meeting coming up at the end of May. At that meeting Holger announced that after 2.5 years he wanted to step back from his role helping Rapha l in coordinating/managing the LTS team. We would like to thank Holger for his continuous work on Debian LTS (which goes back to 2014) and are happy to report that we already found a successor which we will introduce in the upcoming April report from Freexian. Finally, we would like to remark once again that we are constantly looking for new contributors. For a last time, please contact Holger if you are interested! The security tracker currently lists 42 packages with a known CVE and the dla-needed.txt file has 28 packages needing an update. We are also pleased to report that we got 4 new sponsors over the last 2 months : thanks to sipgate GmbH, OVH US LLC, Tilburg University and Observatoire des Sciences de l Univers de Grenoble ! Thanks to our sponsors Sponsors that joined recently are in bold.

Reproducible Builds (diffoscope): diffoscope 173 released

The diffoscope maintainers are pleased to announce the release of diffoscope version 173. This version includes the following changes: 
[ Chris Lamb ]
* Add support for showing annotations in PDF files.
  (Closes: reproducible-builds/diffoscope#249)
* Move to assert_diff in test_pdf.py.
[ Zachary T Welch ]
* Difference.__init__: Demote unified_diff argument to a Python "kwarg".
You find out more by visiting the project homepage.

29 April 2021

Anton Gladky: 2021/04, FLOSS activity

LTS This is my second month of working for LTS. I was assigned 12 hrs and worked all of them.

Released DLAs
  1. DLA 2619-1 python3.5_3.5.3-1+deb9u4 CVE-2021-23336 introduced an API-change. It was hard decision to upload this fix, because it can potentially break user s code, if they code uses semicolon as separator. Another option is not to fix it at all, leaving the security issue open. Not the best solution. Also I have fixed the failing autopkgtest, which was introduced in one of latest CVE fixes. CI-pipelines on salsa.d.o are helping now to detect such mistakes.
  2. DLA 2628-1 python2.7_2.7.13-2+deb9u5 CVE-2021-23336 introduced an API-change, same as for python3.5. But the backporting was much harder because python3->2 is not always easy.

CI-pipelines I try to setup for all LTS-packages which I touch CI-pipelines on salsa.d.o. Setting up pipelines for python3.5 and python2.7 was much harder as for other packages. Failing autopkgtests and some other issues. Though it takes at the beginning more time to setup, I believe it improves package quality.

LTS-Meeting I attended the Debian LTS team Jitsi-meeting.

Junichi Uekawa: Setting wake-on-lan in Debian way.

Setting wake-on-lan in Debian way. There's several ways that your network interfaces can be configured. The Debian way is to use ifup/ifdown. Make sure your network is configured with it by checking ifquery. nmcli d and networkctl list are NM and systemd equivalents of commands. After you know which one is managing your device you can go ahead and set up WoL configuration appropriately. Default Debian installation would probably start with a ifup/ifdown config.

Junichi Uekawa: Surrounding a region with Emacs lisp.

Surrounding a region with Emacs lisp. I wanted to surround a region with HTML tags and here's what I learnt today. Specifying "r" in interactive gives two numbers, begin and end. When I want to obtain multiple kinds of values in interactive, I can use newlines to delimit. set-marker is an api to keep a marker at relative position even after edits, API needs making make-marker to create an empty marker first, and seems like the number of markers affects editing speed so the API is made to allow reuse of markers. After I got these going I could now write.

28 April 2021

Antoine Beaupr : Building a status page service with Hugo

The Tor Project now has a status page which shows the state of our major services. You can check status.torprojet.org for news about major outages in Tor services, including v3 and v2 onion services, directory authorities, our website (torproject.org), and the check.torproject.org tool. The status page also displays outages related to Tor internal services, like our GitLab instance. This post documents why we launched status.torproject.org, how the service was built, and how it works.

Why a status page The first step in setting up a service page was to realize we needed one in the first place. I surveyed internal users at the end of 2020 to see what could be improved, and one of the suggestions that came up was to "document downtimes of one hour or longer" and generally improve communications around monitoring. The latter is still on the sysadmin roadmap, but a status page seemed like a good solution for the former. We already have two monitoring tools in the sysadmin team: Icinga (a fork of Nagios) and Prometheus, with Grafana dashboards. But those are hard to understand for users. Worse, they also tend to generate false positives, and don't clearly show users which issues are critical. In the end, a manually curated dashboard provides important usability benefits over an automated system, and all major organisations have one.

Picking the right tool It wasn't my first foray in status page design. In another life, I had setup a status page using a tool called Cachet. That was already a great improvement over the previous solutions, which were to use first a wiki and then a blog to post updates. But Cachet is a complex Laravel app, which also requires a web browser to update. It generally requires more maintenance than what we'd like, needing silly things like a SQL database and PHP web server. So when I found cstate, I was pretty excited. It's basically a theme for the Hugo static site generator, which means that it's a set of HTML, CSS, and a sprinkle of Javascript. And being based on Hugo means that the site is generated from a set of Markdown files and the result is just plain HTML that can be hosted on any web server on the planet.

Deployment At first, I wanted to deploy the site through GitLab CI, but at that time we didn't have GitLab pages set up. Even though we do have GitLab pages set up now, it's not (yet) integrated with our mirroring infrastructure. So, for now, the source is hosted and built in our legacy git and Jenkins services. It is nice to have the content hosted in a git repository: sysadmins can just edit Markdown in the git repository and push to deploy changes, no web browser required. And it's trivial to setup a local environment to preview changes: 
hugo serve --baseUrl=http://localhost/
firefox https://localhost:1313/
Only the sysadmin team and gitolite administrators have access to the repository, at this stage, but that could be improved if necessary. Merge requests can also be issued on the GitLab repository and then pushed by authorized personnel later on, naturally.

Availability One of the concerns I have is that the site is hosted inside our normal mirror infrastructure. Naturally, if an outage occurs there, the site goes down. But I figured it's a bridge we'll cross when we get there. Because it's so easy to build the site from scratch, it's actually trivial to host a copy of the site on any GitLab server, thanks to the .gitlab-ci.yml file shipped (but not currently used) in the repository. If push comes to shove, we can just publish the site elsewhere and point DNS there. And, of course, if DNS fails us, then we're in trouble, but that's the situation anyway: we can always register a new domain name for the status page when we need to. It doesn't seem like a priority at the moment. Comments and feedback are welcome!
This article was first published on the Tor Project Blog.

Next.

Previous.