CVE-2026-111943: Compromised Intermediate Certificate Authority (nvd.nist.gov)

I feel like you shouldn’t have to ask for a non-default version of the package at this point.

"proactively" doing some work.

The problem is Golang has it's own trust store. So you don't benefit from OS patching.

Here a CA derived a secret key from the number 4.

If you think "that's weird to see such a small number in key generation" than you're one step ahead of whoever generated that key.

Unfortunately, unlike with RSA, small primes are not apparent in elliptic cryptography.

This is basically the whole idea of the novel War with the Newts

> It's like the fish in a pool creating a shark

What a weird comparison...

What are you talking about?

Create the problem, sell the solution

I wonder if they made this change with an assumption that the root CAs wouldn't be distrusted later same day, too.

Any sufficiently advanced stupidity is indistinguishable from malice.

No it affects everybody, but most browsers/OSs etc have updated already. This is just a workaround Go put in case the underlying OS has not been updated. Not sure why it is on the front page as it duplicates previous posts and confuses people, I think it should be merged.

Here is the original story: https://news.ycombinator.com/item?id=50166579

I've had since Debian 8 (2015) few helper scripts to make me remember better how to manage approved CA's. There are three of those, which have been working all Debian versions since 8 to current 13.

# cat /usr/local/sbin/ca-certificates-list-active

  #!/usr/bin/env bash
  #
  # BFMI tool to list Debian CA certificates active  - mesrik, 2015
  #
  
  CA_CONFIG=/etc/ca-certificates.conf
  CA_REPO_DEBIAN=/usr/share/ca-certificates
  
  if [ -f $CA_CONFIG ]; then
      # study any ca-certificates which have been configured active
      for i in $(egrep -v '^[#!]' /etc/ca-certificates.conf) ; do
         cert_source=$(dirname $i)
         cert_file=$(basename $i)
         openssl x509 -in $CA_REPO_DEBIAN/$cert_source/$cert_file -noout -subject |\
           sed 's/^subject=//'
      done
  
  else
      echo "$(basename $0): Ooops, was not able to access $CA_CONFIG"
  fi
  
  # eof
  

# cat /usr/local/sbin/ca-certificates-reconfigure

  #!/usr/bin/env bash
  LANG=C dpkg-reconfigure ca-certificates

# cat /usr/local/sbin/ca-certificates-invalidate-all

  #!/usr/bin/env bash
  #
  # BFMI tool to invalidate all CA certificates in Debian Jessie - mesrik, 2015
  #
  
  CA_CONFIG=/etc/ca-certificates.conf
  prog=$(basename $0)
  usage="Usage: $prog  { -commit }"
  
  if [ $# -lt 1 ]; then
      echo $usage
      exit 1
  fi
  
  if [ "$1" = "-commit" ]; then
      if [ -f $CA_CONFIG ]; then
         backup_ext=$(date -r $CA_CONFIG +".%FT%T%z")
         perl -wpi$backup_ext -e 's/^([^!#].*)$/!$1/;' $CA_CONFIG
         if [ $? -eq 0 ]; then
            echo "$prog: backup $CA_CONFIG$backup_ext was made."
            /usr/sbin/update-ca-certificates
         fi
      else
         echo "$prog: Ooops, was not able to access $CA_CONFIG"
      fi
  else
      echo "$prog: Need -commit to actually invalidate all CA's"
  fi
  
  # eof

ps. I did bit of editing, I didn't expect Tab to be ignored when pasting here.

This is such a clusterfuck. I use so many containers in my home lab and various local installations and stuff. Honestly, I have no idea what I'm even supposed to do at this point because I'm not a full time developer.

> Failure to do so could result in monster-in-the-middle (MITM) attacks against TLS clients, including python.org and pypi.org .

Monster?

This is not the first that RHEL is comically slow with updates...

We pay good money for their highest support tier and they are almost always the latest to bring a needed update.

Can't exactly remember what it was but it has happened before. It's a shame.

[dead]

What are the options available besides using intermediate signing keys? This seems like a weak link in trusting crypto.