Planet Debian

Subscribe to Planet Debian feed
Planet Debian - https://planet.debian.org/
Updated: 18 hours 10 min ago

Freexian Collaborators: Monthly report about Debian Long Term Support, November 2023 (by Roberto C. Sánchez)

Mon, 2023-12-11 19:00

Like each month, have a look at the work funded by Freexian’s Debian LTS offering.

Some notable fixes which were made in LTS during the month of November include the gnutls28 cryptographic library and the freerdp2 Remote Desktop Protocol client/server implementation. The gnutls28 update was prepared by LTS contributor Markus Koschany and dealt with a timing attack which could be used to compromise a cryptographic system, while the freerdp2 update was prepared by LTS contributor Tobias Frost and is the result of work spanning 3 months to deal with dozens of vulnerabilities.

In addition to the many ordinary LTS tasks which were completed (CVE triage, patch backports, package updates, etc), there were several contributions by LTS contributors for the benefit of Debian stable and old-stable releases, as well as for the benefit of upstream projects. LTS contributor Abhijith PA uploaded an update of the puma package to unstable in order to fix a vulnerability in that package while LTS contributor Thosten Alteholz sponsored an upload to unstable of libde265 and himself made corresponding uploads of libde265 to Debian stable and old-stable. LTS contributor Bastien Roucariès developed patches for vulnerabilities in zbar and audiofile which were then provided to the respective upstream projects. Updates to packages in Debian stable were made by Markus Koschany to deal with security vulnerabilities and by Chris Lamb to deal with some non-security bugs.

As always, the LTS strives to provide high quality updates to packages under the direct purview of the LTS team while also rendering assistance to maintainers, the stable security team, and upstream developers whenever practical.

Debian LTS contributors

In November, 18 contributors have been paid to work on Debian LTS, their reports are available:

  • Abhijith PA did 7.0h (out of 0h assigned and 14.0h from previous period), thus carrying over 7.0h to the next month.
  • Adrian Bunk did 15.0h (out of 14.0h assigned and 9.75h from previous period), thus carrying over 8.75h to the next month.
  • Anton Gladky did 10.0h (out of 9.5h assigned and 5.5h from previous period), thus carrying over 5.0h to the next month.
  • Bastien Roucariès did 16.0h (out of 18.25h assigned and 1.75h from previous period), thus carrying over 4.0h to the next month.
  • Ben Hutchings did 12.0h (out of 16.5h assigned and 12.25h from previous period), thus carrying over 16.75h to the next month.
  • Chris Lamb did 18.0h (out of 17.25h assigned and 0.75h from previous period).
  • Emilio Pozuelo Monfort did 15.5h (out of 23.5h assigned and 0.25h from previous period), thus carrying over 8.25h to the next month.
  • Guilhem Moulin did 13.0h (out of 12.0h assigned and 8.0h from previous period), thus carrying over 7.0h to the next month.
  • Lee Garrett did 14.5h (out of 16.75h assigned and 7.0h from previous period), thus carrying over 9.25h to the next month.
  • Markus Koschany did 30.0h (out of 30.0h assigned).
  • Ola Lundqvist did 6.5h (out of 8.25h assigned and 15.5h from previous period), thus carrying over 17.25h to the next month.
  • Roberto C. Sánchez did 5.5h (out of 12.0h assigned), thus carrying over 6.5h to the next month.
  • Santiago Ruano Rincón did 3.25h (out of 13.62h assigned and 2.375h from previous period), thus carrying over 12.745h to the next month.
  • Sean Whitton did 3.25h (out of 10.0h assigned), thus carrying over 6.75h to the next month.
  • Sylvain Beucler did 10.0h (out of 13.5h assigned and 10.25h from previous period), thus carrying over 13.75h to the next month.
  • Thorsten Alteholz did 14.0h (out of 14.0h assigned).
  • Tobias Frost did 12.0h (out of 12.0h assigned).
  • Utkarsh Gupta did 0.0h (out of 6.0h assigned and 17.75h from previous period), thus carrying over 23.75h to the next month.
Evolution of the situation

In November, we have released 35 DLAs.

Thanks to our sponsors

Sponsors that joined recently are in bold.

Categories: FLOSS Project Planets

Jonathan Dowland: Talks: why?

Mon, 2023-12-11 11:08

I'd planned to write some private mail on the subject of preparing and delivering conference talks. However, each time I try to write that mail, I've managed to somehow contrive to lose it. So I thought I'd try as a blog post instead, to break the curse.

The first aspect I wanted to write about is the pre-planning phase, or, the bit where you decide to give a talk in the first place. But first a bit about me.

I don't talk all that regularly. I think I'm averaging one talk a year. I don't consider myself to be a natural talk-giver: I don't particularly enjoy it and I still get quite nervous. So the first question is: why do it?

One motivation is that you want to attend a particular conference, and presenting at it makes it much easier to get institutional support for doing so (i.e., travel and accommodation covered). At the moment, I've written some talk proposals for FOSDEM because I want to attend, and it increases my chances if I'm delivering a talk.

Another reason, pertinent to academia, is you wish to have a paper published. Last year I attended a conference in Portland that I had a paper accepted to. A condition of the paper being accepted is you attend and do a presentation about it. Obviously, the presentation itself is a useful form of dissemination for your work, but the paper has the potential to reach more people.

You may wish to promote what you're talking about: academic work, but perhaps a piece of open source software that would benefit from wider awareness, more adoption, more bug reports, testing, and patches.

You may wish to support the venue. There are a some of small-scale conferences that I enjoy participating in which don't receive a lot of submissions and so I tend to send one or more in order to help make sure there are enough possible talks to keep the whole thing viable.

Finally, you may wish to promote yourself: certainly, some Software Engineers I've met seem to spend as much time on talks and travelling as writing software. It's a good way to see a lot of the world, and might be a good way to get your name known and increase your employment prospects. I feel lucky I haven't had to rely on this.

Categories: FLOSS Project Planets

Jonathan Dowland: Tex Shura

Mon, 2023-12-11 10:36

So yeah, I bought the Shura.

It's been about a year since I got the Tex Shinobi keyboard. I ended up taking to the office and using it there. The MX Silent Red switches are a good fit for a shared space, and I have a bit more desk space so the extra large footprint is not a problem.

Back at home, I have a reasonably large desk, but I've got a Synth jammed at the back-centre, leaving a slightly tight budget for keyboard depth. The Shura is nice and compact and fits in perfectly.

So what should I say about it? Build quality is excellent. I went with MX Reds (non-silent this time) which feel a lot better to me than the silent variant. I do worry about waking the kids up if I type after they've gone to bed, but it hasn't actually been a problem (and the switches activate quite early in travel so you can "tip-toe" type silently, and slowly).

I like these keyboards (and I've otherwise avoided the Mech keyboard money pit) because they have the integrated trackpoint, which I rely on. Just as with the Shinobi, the Trackpoint is of an excellent quality, pretty much indistinguishable from that on the official Lenovo trackpoint keyboards.

Since the Shura is a a "60%" or "65%" or "70%" or something, thus forgoing the Function keys and such, I rely on "layers": switching the function of all the regular keys whilst "Fn" is pressed. You can reprogram the Tex keyboards using a profile output by their web-based configurator which I've used to mildly customize the layout: swapped left-hand "Win" with "Fn" (FN1), mapped FN1 to the right-hand "Win". That's it so far, the defaults are otherwise sufficient for me. I've also used the DIP switches to enable mouse wheel emulation with the trackpoint (in common with the Lenovos).

In September, Justin from TeX left an intriguing comment on my last blog post:

Thanks for your promotion !! We will try to design a new keyboard ( a little ergo keyboard ) should be release end of this year !!

Categories: FLOSS Project Planets

Scarlett Gately Moore: KDE: KDE Snaps 23.08.4, PIM! KDE neon, Debian

Sun, 2023-12-10 08:33
KDE PIM Kaddressbook snap

KDE Snaps:

This weeks big accomplishment is KDE PIM snaps! I have successfully added akonadi as a service via an akonadi content snap and running it as a service. Kaddressbook is our first PIM snap with this setup and it works flawlessly! It is available in the snap store. I have a pile of MRs awaiting approvals, so keep your eye out for the rest of PIM in the next day.

KDE Applications 23.08.4 has been released and available in the snap store.

Krita 5.2.2 has been released.

I have created a new kde-qt6 snap as the qt-framework snap has not been updated and the maintainer is unreachable. It is in edge and I will be rebuilding our kf6 snap with this one.

I am debugging an issue with the latest Labplot release.

KDE neon:

This week I helped with frameworks release 5.113 and KDE applications 23.08.4.

I also worked on the ongoing Unstable turning red into green builds as the porting to qt6 continues.

Debian:

With my on going learning packaging for all the programming languages, Rust packaging: I started on Rustic https://github.com/rustic-rs/rustic unfortunately, it was a bit of wasted time as it depends on a feature of tracing-subcriber that depends on matchers which has a grave bug, so it remains disabled.

Personal:

I do have an interview tomorrow! And it looks like the ‘project’ may go through after the new year. So things are looking up, unfortunately I must still ask, if you have any spare change please consider a donation. The phone company decided to take an extra $200.00 I didn’t have to spare and while I resolved it, they refused a refund, but gave me a credit to next months bill, which doesn’t help me now. Thank you for your consideration.

https://gofund.me/b74e4c6f

Categories: FLOSS Project Planets

Freexian Collaborators: Debian Contributions: Python 3.12 preparations, debian-printing, merged-/usr tranisition updates, and more! (by Utkarsh Gupta)

Sat, 2023-12-09 19:00

Contributing to Debian is part of Freexian’s mission. This article covers the latest achievements of Freexian and their collaborators. All of this is made possible by organizations subscribing to our Long Term Support contracts and consulting services.

Preparing for Python 3.12 by Stefano Rivera

Stefano uploaded a few packages in preparation for Python 3.12, including pycxx and cython. Cython has a major new version (Cython 3), adding support for 3.12, but also bringing changes that many packages in Debian aren’t ready to build with, yet. Stefano uploaded it to Debian experimental and did an archive rebuild of affected packages, and some analysis of the result. Matthias Klose has since filed bugs for all of these issues.

debian-printing, by Thorsten Alteholz

This month Thorsten invested some of the previously obtained money to build his own printlab. At the moment it only consists of a dedicated computer with an USB printer attached. Due to its 64GB RAM and an SSD, building of debian-printing packages is much faster now. Over time other printers will be added and understanding bugs should be a lot easier now.

Also Thorsten again adopted two packages, namely mink and ink, and moved them to the debian-printing team.

Merged-/usr transition by Helmut Grohne, et al

The dumat analysis tool has been improved in quite some aspects. Beyond fixing false negative diagnostics, it now recognizes protective diversions used for mitigating Multi-Arch: same file loss. It was found that the proposed mitigation for ineffective diversions does not work as expected. Trying to fix it up resulted in more problems, some of which remain unsolved as of this writing. Initial work on moving shared libraries in the essential set has been done.

Meanwhile, the wider Debian community worked on fixing all known Multi-Arch: same file loss scenarios. This work is now being driven by Christian Hofstaedler and during the Mini DebConf in Cambridge, Chris Boot, Étienne Mollier, Miguel Landaeta, Samuel Henrique, and Utkarsh Gupta sent the other half of the necessary patches.

Miscellaneous contributions
  • Stefano merged patches to support loong64 and hurd-amd64 in re2.
  • For the Cambridge mini-conf, Stefano added a web player to the DebConf video streaming frontend, as the Cambridge miniconf didn’t have its own website to host the player.
  • Raphaël helped the upstream developers of hamster-time-tracker to prepare a new upstream release (the first in multiple years) and packaged that new release in Debian unstable.
  • Enrico joined Hemut in brainstorming some /usr-merge solutions.
  • Thorsten took care of RM-bugs to remove no longer needed packages from the Debian archive and closed about 50 of them.
  • Helmut ported the feature of mounting a fuse connection via /dev/fd/N from fuse3 to fuse2.
  • Helmut sent a number of patches simplifying unprivileged use of piuparts.
  • Roberto worked with Helmut to prepare the Shorewall package for the ongoing /usr-move transition.
  • Utkarsh also helped with the ongoing /usr-merge work by preparing patches for gitlab, libnfc, and net-tools.
  • Utkarsh, along with Helmut, brainstormed on fixing #961138, as this affects the whole archive and all the suites and not just R packages. Utkarsh intends to follow up on the bug in December.
  • Santiago organized a MiniDebConf in Uruguay. In total, nine people attended, including most of DDs in the surrounding area. Here’s a nicely written blog by Gunnar Wolf.
  • Santiago also worked on some issues on Salsa CI, fixed with some merge requests: #462, #463, and #466.
Categories: FLOSS Project Planets

Simon Josefsson: Classic McEliece goes to IETF and OpenSSH

Sat, 2023-12-09 18:11

My earlier work on Streamlined NTRU Prime has been progressing along. The IETF document on sntrup761 in SSH has passed several process points. GnuPG’s libgcrypt has added support for sntrup761. The libssh support for sntrup761 is working, but the merge request is stuck mostly due to lack of time to debug why the regression test suite sporadically errors out in non-sntrup761 related parts with the patch.

The foundation for lattice-based post-quantum algorithms has some uncertainty around it, and I have felt that there is more to the post-quantum story than adding sntrup761 to implementations. Classic McEliece has been mentioned to me a couple of times, and I took some time to learn it and did a cut’n’paste job of the proposed ISO standard and published draft-josefsson-mceliece in the IETF to make the algorithm easily available to the IETF community. A high-quality implementation of Classic McEliece has been published as libmceliece and I’ve been supporting the work of Jan Mojžíš to package libmceliece for Debian, alas it has been stuck in the ftp-master NEW queue for manual review for over two months. The pre-dependencies librandombytes and libcpucycles are available in Debian already.

All that text writing and packaging work set the scene to write some code. When I added support for sntrup761 in libssh, I became familiar with the OpenSSH code base, so it was natural to return to OpenSSH to experiment with a new SSH KEX for Classic McEliece. DJB suggested to pick mceliece6688128 and combine it with the existing X25519+sntrup761 or with plain X25519. While a three-algorithm hybrid between X25519, sntrup761 and mceliece6688128 would be a simple drop-in for those that don’t want to lose the benefits offered by sntrup761, I decided to start the journey on a pure combination of X25519 with mceliece6688128. The key combiner in sntrup761x25519 is a simple SHA512 call and the only good I can say about that is that it is simple to describe and implement, and doesn’t raise too many questions since it is already deployed.

After procrastinating coding for months, once I sat down to work it only took a couple of hours until I had a successful Classic McEliece SSH connection. I suppose my brain had sorted everything in background before I started. To reproduce it, please try the following in a Debian testing environment (I use podman to get a clean environment).

# podman run -it --rm debian:testing-slim apt install wget python3 librandombytes-dev libcpucycles-dev gcc make git autoconf libz-dev wget -q -O- https://lib.mceliece.org/libmceliece-20230612.tar.gz | tar xfz - cd libmceliece-20230612/ ./configure make install cd .. git clone https://gitlab.com/jas/openssh-portable cd openssh-portable git checkout jas/mceliece autoreconf ./configure # verify 'libmceliece support: yes' make # CC="cc -DDEBUG_KEX=1 -DDEBUG_KEXDH=1 -DDEBUG_KEXECDH=1"

You should now have a working SSH client and server that supports Classic McEliece! Verify support by running ./ssh -Q kex and it should mention mceliece6688128x25519-sha512@openssh.com.

To have it print plenty of debug outputs, you may remove the # character on the final line, but don’t use such a build in production.

You can test it as follows:

adduser --system sshd ./ssh-keygen -A # writes to /usr/local/etc/ssh_host_... mkdir /var/empty # setup public-key based login by running the following: ssh-keygen cat ~/.ssh/id_rsa.pub > ~/.ssh/authorized_keys while true; do $PWD/sshd -p 2222 -f /dev/null -oKexAlgorithms=mceliece6688128x25519-sha512@openssh.com -d; done & ./ssh -v -p 2222 localhost -oKexAlgorithms=mceliece6688128x25519-sha512@openssh.com date

On the client you should see output like this:

OpenSSH_9.5p1, OpenSSL 3.0.11 19 Sep 2023 debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling debug1: Connecting to localhost [::1] port 2222. debug1: Connection established. debug1: identity file /root/.ssh/id_rsa type 0 debug1: identity file /root/.ssh/id_rsa-cert type -1 debug1: identity file /root/.ssh/id_ecdsa type -1 debug1: identity file /root/.ssh/id_ecdsa-cert type -1 debug1: identity file /root/.ssh/id_ecdsa_sk type -1 debug1: identity file /root/.ssh/id_ecdsa_sk-cert type -1 debug1: identity file /root/.ssh/id_ed25519 type -1 debug1: identity file /root/.ssh/id_ed25519-cert type -1 debug1: identity file /root/.ssh/id_ed25519_sk type -1 debug1: identity file /root/.ssh/id_ed25519_sk-cert type -1 debug1: identity file /root/.ssh/id_xmss type -1 debug1: identity file /root/.ssh/id_xmss-cert type -1 debug1: identity file /root/.ssh/id_dsa type -1 debug1: identity file /root/.ssh/id_dsa-cert type -1 debug1: Local version string SSH-2.0-OpenSSH_9.5 debug1: Remote protocol version 2.0, remote software version OpenSSH_9.5 debug1: compat_banner: match: OpenSSH_9.5 pat OpenSSH* compat 0x04000000 debug1: Authenticating to localhost:2222 as 'root' debug1: load_hostkeys: fopen /root/.ssh/known_hosts2: No such file or directory debug1: load_hostkeys: fopen /usr/local/etc/ssh_known_hosts: No such file or directory debug1: load_hostkeys: fopen /usr/local/etc/ssh_known_hosts2: No such file or directory debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: algorithm: mceliece6688128x25519-sha512@openssh.com debug1: kex: host key algorithm: ssh-ed25519 debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: SSH2_MSG_KEX_ECDH_REPLY received debug1: Server host key: ssh-ed25519 SHA256:YognhWY7+399J+/V8eAQWmM3UFDLT0dkmoj3pIJ0zXs debug1: load_hostkeys: fopen /root/.ssh/known_hosts2: No such file or directory debug1: load_hostkeys: fopen /usr/local/etc/ssh_known_hosts: No such file or directory debug1: load_hostkeys: fopen /usr/local/etc/ssh_known_hosts2: No such file or directory debug1: Host '[localhost]:2222' is known and matches the ED25519 host key. debug1: Found key in /root/.ssh/known_hosts:1 debug1: rekey out after 134217728 blocks debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: rekey in after 134217728 blocks debug1: Will attempt key: /root/.ssh/id_rsa RSA SHA256:+ShnZ7q1PzYOVnirxGFkrYpH7GgmpLYzoJ6F9dHIOFs debug1: Will attempt key: /root/.ssh/id_ecdsa debug1: Will attempt key: /root/.ssh/id_ecdsa_sk debug1: Will attempt key: /root/.ssh/id_ed25519 debug1: Will attempt key: /root/.ssh/id_ed25519_sk debug1: Will attempt key: /root/.ssh/id_xmss debug1: Will attempt key: /root/.ssh/id_dsa debug1: SSH2_MSG_EXT_INFO received debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,sk-ssh-ed25519@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ecdsa-sha2-nistp256@openssh.com,webauthn-sk-ecdsa-sha2-nistp256@openssh.com,ssh-dss,ssh-rsa,rsa-sha2-256,rsa-sha2-512> debug1: kex_ext_info_check_ver: publickey-hostbound@openssh.com=<0> debug1: kex_ext_info_check_ver: ping@openssh.com=<0> debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,password,keyboard-interactive debug1: Next authentication method: publickey debug1: Offering public key: /root/.ssh/id_rsa RSA SHA256:+ShnZ7q1PzYOVnirxGFkrYpH7GgmpLYzoJ6F9dHIOFs debug1: Server accepts key: /root/.ssh/id_rsa RSA SHA256:+ShnZ7q1PzYOVnirxGFkrYpH7GgmpLYzoJ6F9dHIOFs Authenticated to localhost ([::1]:2222) using "publickey". debug1: channel 0: new session [client-session] (inactive timeout: 0) debug1: Requesting no-more-sessions@openssh.com debug1: Entering interactive session. debug1: pledge: filesystem debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0 debug1: client_input_hostkeys: searching /root/.ssh/known_hosts for [localhost]:2222 / (none) debug1: client_input_hostkeys: searching /root/.ssh/known_hosts2 for [localhost]:2222 / (none) debug1: client_input_hostkeys: hostkeys file /root/.ssh/known_hosts2 does not exist debug1: client_input_hostkeys: no new or deprecated keys from server debug1: Remote: /root/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding debug1: Remote: /root/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding debug1: Sending command: date debug1: pledge: fork debug1: permanently_set_uid: 0/0 Environment: USER=root LOGNAME=root HOME=/root PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin MAIL=/var/mail/root SHELL=/bin/bash SSH_CLIENT=::1 46894 2222 SSH_CONNECTION=::1 46894 ::1 2222 debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0 Sat Dec 9 22:22:40 UTC 2023 debug1: channel 0: free: client-session, nchannels 1 Transferred: sent 1048044, received 3500 bytes, in 0.0 seconds Bytes per second: sent 23388935.4, received 78108.6 debug1: Exit status 0

Notice the kex: algorithm: mceliece6688128x25519-sha512@openssh.com output.

How about network bandwidth usage? Below is a comparison of a complete SSH client connection such as the one above that log in and print date and logs out. Plain X25519 is around 7kb, X25519 with sntrup761 is around 9kb, and mceliece6688128 with X25519 is around 1MB. Yes, Classic McEliece has large keys, but for many environments, 1MB of data for the session establishment will barely be noticeable.

# ./ssh -v -p 2222 localhost -oKexAlgorithms=curve25519-sha256 date 2>&1 | grep ^Transferred Transferred: sent 3028, received 3612 bytes, in 0.0 seconds # ./ssh -v -p 2222 localhost -oKexAlgorithms=sntrup761x25519-sha512@openssh.com date 2>&1 | grep ^Transferred Transferred: sent 4212, received 4596 bytes, in 0.0 seconds # ./ssh -v -p 2222 localhost -oKexAlgorithms=mceliece6688128x25519-sha512@openssh.com date 2>&1 | grep ^Transferred Transferred: sent 1048044, received 3764 bytes, in 0.0 seconds

So how about session establishment time?

# date; i=0; while test $i -le 100; do ./ssh -v -p 2222 localhost -oKexAlgorithms=curve25519-sha256 date > /dev/null 2>&1; i=`expr $i + 1`; done; date Sat Dec 9 22:39:19 UTC 2023 Sat Dec 9 22:39:25 UTC 2023 # 6 seconds # date; i=0; while test $i -le 100; do ./ssh -v -p 2222 localhost -oKexAlgorithms=sntrup761x25519-sha512@openssh.com date > /dev/null 2>&1; i=`expr $i + 1`; done; date Sat Dec 9 22:39:29 UTC 2023 Sat Dec 9 22:39:38 UTC 2023 # 9 seconds # date; i=0; while test $i -le 100; do ./ssh -v -p 2222 localhost -oKexAlgorithms=mceliece6688128x25519-sha512@openssh.com date > /dev/null 2>&1; i=`expr $i + 1`; done; date Sat Dec 9 22:39:55 UTC 2023 Sat Dec 9 22:40:07 UTC 2023 # 12 seconds

I never noticed adding sntrup761, so I’m pretty sure I wouldn’t notice this increase either. This is all running on my laptop that runs Trisquel so take it with a grain of salt but at least the magnitude is clear.

Future work items include:

  • Use a better hybrid mode combiner than SHA512? See for example KEM Combiners.
  • Write IETF document describing the Classic McEliece SSH protocol
  • Submit my patch to the OpenSSH community for discussion and feedback, please review meanwhile!
  • Implement a mceliece6688128sntrup761x25519 multi-hybrid mode?
  • Write a shell script a’la sntrup761.sh to import a stripped-down mceliece6688128 implementation to avoid having OpenSSH depend on libmceliece?
  • My kexmceliece6688128x25519.c is really just kexsntrup761x25519.c with the three calls to sntrup761 replaced with mceliece6688128. This should be parametrized to avoid cut’n’paste of code, if the OpenSSH community is interested.
  • Consider if the behaviour of librandombytes related to closing of file descriptors is relevant to OpenSSH.

Happy post-quantum SSH’ing!

Categories: FLOSS Project Planets

Steinar H. Gunderson: Cubemap 1.5.0 released

Sat, 2023-12-09 11:18

I've released version 1.5.0 of Cubemap, my scalable video reflector. This was a long time coming, and I've mostly been lazy about getting the actual release out. :-) There are some fairly big features this time, reflecting further the fact that my primary way of creating video isn't VLC anymore (which was Cubemap's original proposal; a better reflector for VLC). It's on its way up into Debian unstable, but you can also get it from git and just build.

Changelog goes as follows:

Cubemap 1.5.0, 2023-12-09 * Support input from pipes (subprocesses). With a program that can output Metacube on stdout, such as a suitably patched FFmpeg binary, this gives Cubemap transcoding/remuxing capabilities. Of course, one cannot upgrade such a binary by SIGHUP-ing it, but it will survive a Cubemap reload/restart. * Add a LD_PRELOAD-able library to force Metacube output from FFmpeg. This hooks just the right amount of functions to add Metacube output to arbitrary FFmpeg programs, but is obviously very brittle. (Native FFmpeg support would be better, but a patch did not go through when I tried a while back.) It is only lightly tested. Documentation in the README and cubemap.config.sample. * Various bugfixes.
Categories: FLOSS Project Planets

Thorsten Alteholz: My Debian Activities in November 2023

Sat, 2023-12-09 08:49
FTP master

This month I accepted 276 and rejected 25 packages. The overall number of packages that got accepted was 276. I also handled several RM bugs, so the archive did not grow that much :-).

Debian LTS

This was my hundred-thirteenth month that I did some work for the Debian LTS initiative, started by Raphael Hertzog at Freexian.

During my allocated time I uploaded:

  • [DLA 3670-1] minizip security update for one CVE to fix an integer overflow
  • [DLA 3673-1] gst-plugins-bad1.0 security update for one CVEs to fix an use-after-free
  • [#1056934] Bookworm PU-bug for libde265
  • [#1056935] Bullseye PU-bug for libde265
  • [#1056737] Bookworm PU-bug for minizip
  • [#1056738] Bullseye PU-bug for minizip
  • [libde265] sponsor upload to unstable
  • [zlib] all CVEs could be marked as not-affected

The update of libde265 was a bit unusual this time. The security tracker had three CVEs listed for it and the maintainer was looking for a sponsor to fix them in Unstable. So far, so good! I sponsored the upload and suddenly a fourth CVE appeared in the security tracker. As the debian/changelog mentioned a different CVE, it was automatically added. Indeed upstreams changelog contained a patch for a CVE that was reserved but not yet published (hence the security tracker could not connect it to libde265). I informed upstream and as things turned out marking the CVE as public was just forgotten. Luckily there was some time left for the upcoming point release and all four patches finally arrived in Bookworm.

Debian ELTS

This month was the sixty-fourth ELTS month. During my allocated time I uploaded:

  • [ELA-1004-1] libde265 update in Jessie and Stretch for three CVEs. The issues are related to segmentation faults and bufferf overflows in different functions, which might result in DoS.
  • [ELA-1006-1] libde265 update in Jessie and Stretch for one CVE. This issue is related to an buffer over read which might result in an information leak or denial of service when processing crafted H.265 files
  • [ELA-1010-1 ]minizip update in Stretch for one CVE. This issue was related to a heap-based buffer overflow.
  • [ELA-1015-1] gst-plugins-bad1.0 update in Jessie and Stretch for one CVEs to fix a use-after-free of some pointers within the MXF demuxer.

In order to check whether the patch for the standalone version of minizip was ok, I used a test from the embedded minizip version in chromium and it worked.

Debian Printing

This month I uploaded a new upstream version of:

Within the context of preserving old printing packages, I adopted:

If you know of any other package that is also needed and still maintained by the QA team, please tell me.

This work is generously funded by Freexian!

Debian Astro

This month I uploaded a new upstream version of:

Debian IoT

This month I uploaded a new upstream version of:

Debian Mobcom

This month I uploaded a package to fix one or the other issue:

Other stuff

This month I uploaded new upstream version of packages, did a source upload for the transition or uploaded it to fix one or the other issue:

Categories: FLOSS Project Planets

Dirk Eddelbuettel: RcppInt64 0.0.4 on CRAN: Minor Bugfix

Sat, 2023-12-09 08:22

The new-ish package RcppInt64 (announced earlier this fall in this post, with two small updates following) arrived on CRAN minutes ago as relase 0.0.4. RcppInt64 collects some of the previous conversions between 64-bit integer values in R and C++, and regroups them in a single package. It offers two interfaces: both a more standard as<>() converter from R values along with its companions wrap() to return to R, as well as more dedicated functions ‘from’ and ‘to’.

This release addresses an issues Sebastian reported a few hours and which is reported by newer, pickier compilers: We need to include <cstdint> so that int64_t is declared. CRAN was at its usual best processing this efficiently including tests of the by now two reverse dependencies. Twenty two minutes total, all automated:

The brief NEWS entry follows:

Changes in version 0.0.4 (2023-12-09)
  • The cstdint header is now included (closes #1).

Courtesy of my CRANberries, there is a diffstat report relative to previous release.

If you like this or other open-source work I do, you can sponsor me at GitHub.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

Categories: FLOSS Project Planets

Jonathan Dowland: The scourge of Electron, the nostalgia of Pidgin

Fri, 2023-12-08 09:18

For reasons I won't go into right now, I've spent some of this year working on a refurbished Lenovo Thinkpad Yoga 260. Despite it being relatively underpowered, I love almost everything about it.

Unfortunately the model I bought has 8G RAM which turned out to be more limiting than I thought it would be. You can do incredible things with 8G of RAM: incredible, wondrous things. And most of my work, whether that's wrangling containers, hacking on OpenJDK, or complex Haskell projects, are manageable.

Where it falls down is driving the modern scourge: Electron, and by proxy, lots of modern IM tools: Slack (urgh), Discord (where one of my main IRC social communities moved to), WhatsApp Web1 and even Signal Desktop.

For that reason, I've (temporarily) looked at alternatives, and I was pleasantly surprised to find serviceable plugins for Pidgin, the stalwart Instant Messenger multiplexer. I originally used Pidgin (then called Gaim) back in the last century, at the time to talk to ICQ, MSN Messenger and AIM (all but ICQ2 long dead). It truly is an elegant weapon from a more civilized age.

Discord from within Pidgin

The plugins are3:

Pidgin with all of these plugins loaded runs perfectly well and consumes fractions of the RAM that each of those Electron apps did prior.

A side-effect of moving these into Pidgin (in particular Discord) is a refocussing of the content. Fewer distractions around the text. The lack of auto-link embedding, and other such things, make it a cleaner, purer experience.

This made me think of the Discord community I am in (I'm really only active in one). It used to be an IRC channel of people that I met through a mutual friend. Said friend recently departed Discord, due to the signal to noise ratio being too poor, and the incessant nudge to click on links, engage, engage, engage.

I wonder if the experience — mediated by Pidgin — would be more tolerable to them?

What my hexchat looks like

I'm still active in one IRC channel (and inactive in many more). I could consider moving IRC into Pidgin as well. At the moment, my IRC client of choice is hexchat, which (like Pidgin) is still using GTK2 for the UI. There's something perversely pleasant about that.

  1. if you go to the trouble of trying to run it as an application distinct from your web browser.
  2. I'm still somewhat surprised ICQ is still going. I might try and recover my old ID.
  3. There may or may not be similar plugins for Slack, but as I (am forced to) use that for corporate stuff, I'm steering clear of them.
Categories: FLOSS Project Planets

Reproducible Builds (diffoscope): diffoscope 253 released

Thu, 2023-12-07 19:00

The diffoscope maintainers are pleased to announce the release of diffoscope version 253. This version includes the following changes:

* Improve DOS/MBR extraction by adding support for 7z. (Closes: reproducible-builds/diffoscope#333) * Process objdump symbol comment filter inputs as the Python "bytes" type (and not str). (Closes: reproducible-builds/diffoscope#358) * Add a missing RequiredToolNotFound import. * Update copyright years.

You find out more by visiting the project homepage.

Categories: FLOSS Project Planets

Dima Kogan: roslanch and =LD_PRELOAD=

Thu, 2023-12-07 15:56

This is part 2 of our series entitled "ROS people don't know how to use computers". This is about ROS1. ROS2 is presumably broken in some completely different way, but I don't know.

Unlike normal people, the ROS people don't "run" applications. They "launch" "nodes" from "packages" (these are "ROS" packages; obviously). You run

roslaunch PACKAGE THING.launch

Then it tries to find this PACKAGE (using some rules that nobody understands), and tries to find the file THING.launch within this package. The .launch file contains inscrutable xml, which includes other inscrutable xml. And if you dig, you eventually find stuff like

<node pkg="PACKAGE" name="NAME" type="TYPE" args="...." ...>

This defines the thing that runs. Unexpectedly, the executable that ends up running is called TYPE.

I know that my particular program is broken, and needs an LD_PRELOAD (exciting details described in another rant in the near future). But the above definition doesn't have a clear way to add that. Adding it to the type fails (with a very mysterious error message). Reading the docs tells you about launch-prefix, which sounds exactly like what I want. But when I add LD_PRELOAD=/tmp/whatever.so I get

RLException: Roslaunch got a 'No such file or directory' error while attempting to run: LD_PRELOAD=/tmp/whatever.so ..../TYPE .....

But this is how you're supposed to be attaching gdb and such! Presumably it looks at the first token, and makes sure it's a file, instead of simply prepending it to the string it passes to the shell. So your options are:

  • Do only approved ROS things in the docs (which are limited, since the docs were written by people who don't know how to use computers)
  • Be expert-enough to work around it

I'm expert-enough. You do this:

launch-prefix="/lib64/ld-linux-x86-64.so.2 --preload /tmp/whatever.so"
Categories: FLOSS Project Planets

Pages