Let’s go for my web review for the week 2023-52.

Drivers of social influence in the Twitter migration to Mastodon | Scientific Reports

Tags: tech, social-media, sociology, psychology, community, fediverse, twitter

Despite understandable limitations, this studies has a few interesting findings on how communities can more easily switch platforms (in this case from Twitter to Mastodon). At least one is a bit counter-intuitive.

https://www.nature.com/articles/s41598-023-48200-7

Substack says it will not remove or demonetize Nazi content - The Verge

Tags: tech, moderation, social-media

Another platform failing at proper moderation…

https://www.theverge.com/2023/12/21/24011232/substack-nazi-moderation-demonetization-hamish-mckenzie

How Big is YouTube? - Ethan Zuckerman

Tags: tech, social-media, google, research

An important question for proper statistics about the content itself. Surprisingly harder to get an answer to it than one would think.

https://ethanzuckerman.com/2023/12/22/how-big-is-youtube/

The New York Times sues OpenAI and Microsoft for copyright infringement - The Verge

Tags: tech, ai, machine-learning, gpt, copyright, law

It was only a question of time until we’d see such lawsuits appear. We’ll see where this one goes.

https://www.theverge.com/2023/12/27/24016212/new-york-times-openai-microsoft-lawsuit-copyright-infringement

The growing energy footprint of artificial intelligence - ScienceDirect

Tags: tech, ai, machine-learning, gpt, economics, energy, ecology

Very interesting paper about the energy footprint of the latest trend in generator models. The conclusion is fairly clear: we should think twice before using them.

https://www.sciencedirect.com/science/article/pii/S2542435123003653#fig1

More than calculators: Why large language models threaten learning, teaching, and education | by Amy J. Ko | Bits and Behavior | Dec, 2023 | Medium

Tags: tech, ai, machine-learning, gpt, school, learning, education

When underfunded schools systems preaching obedience and conformity meet something like large language models, this tips over the balance enough that no proper learning can really happen anymore. Time to reform our school systems?

https://medium.com/bits-and-behavior/more-than-calculators-why-large-language-models-threaten-public-education-480dd5300939

You don’t need analytics on your blog

Tags: tech, blog, self-hosting, attention-economy

Definitely true… never had use for more than the server logs for understanding the traffic on my blog. No need to invade the privacy of people through their browser.

https://blog.yossarian.net/2023/12/24/You-dont-need-analytics-on-your-blog

Using Qt for Mobile in 2023 | Cameron Gaertner | Software Developer

Tags: tech, mobile, qt, android, ios

The experience is still not great on iOS and Android. This is in part due to the platforms design though, this still make Qt a great fit when you control the platform like for Plasma Mobile. For less friendly platforms this still limits the use to cases where you already have quite some Qt code. Still the same situation than a few years ago.

https://camg.me/qt-mobile-2023/

To Type or Not to Type: Quantifying Detectable Bugs in JavaScript

Tags: tech, javascript, type-systems, bug, quality

Interesting study, the amount of bugs which could have been prevented by the introduction of static typing in Javascript code bases is definitely impressive (15% is not a small amount in my opinion).

https://discovery.ucl.ac.uk/id/eprint/10064729/1/typestudy.pdf

Why large companies and fast-moving startups are banning merge commits

Tags: tech, git, version-control

It looks like git workflows using rebase are becoming the norm. People are actively trying to avoid merge commits in their repository history. Tooling support could be a bit better though.

https://graphite.dev/blog/why-ban-merge-commits

rscss - Styling CSS without losing your sanity

Tags: tech, css

Interesting guidelines for organizing CSS. This should avoid making things too much of a mess.

https://ricostacruz.com/rscss/

How to (and how not to) fix color banding

Tags: tech, graphics

Exploration of the causes of color banding and how to work around them.

https://blog.frost.kiwi/GLSL-noise-and-radial-gradient/

So You Want to Optimize Your Code?

Tags: tech, mozilla, observability, telemetry, profiling, optimization, performance

Very nice collection of stories from the trenches of Firefox development. Lots of lessons learned to unpack about optimizing for the right thing, tooling, telemetry and so on.

https://yoric.github.io/post/so-you-want-to-optimize-your-code/

John the Toolmaker

Tags: tech, tools, craftsmanship, developer-experience

It’s indeed important to hone your tools as well. Even though most things are not blocked due to tools, the right ones when well designed can make things easier.

https://two-wrongs.com/john-the-toolmaker

On chains and complex systems – Surfing Complexity

Tags: tech, complexity, reliability

Word of caution on how we tend to reason about complex systems. They don’t form a chain but a web, and that changes everything to understand how they can break.

https://surfingcomplexity.blog/2023/12/23/on-chains-and-complex-systems/

Cold-blooded software

Tags: tech, dependencies, maintenance

This is an interesting metaphor. I’ll try to keep it in mind.

https://dubroy.com/blog/cold-blooded-software/

Beyond Technical Aspects How Do Community Smells Influence the Intensity of Code Smells?

Tags: tech, community, smells, organization, quality

This study does a good job looking at the impact of community smells over the presence of code smells. This is an excellent reminder that the organization influences greatly the produced code.

https://repository.tudelft.nl/islandora/object/uuid%3A426a340b-83a6-480b-bbac-0d711092c704/datastream/OBJ/download

The LinkedIn Developer Productivity and Happiness Framework

Tags: tech, linkedin, developer-experience, metrics, productivity

Interesting framework. I wouldn’t take everything at face value, but this looks like a good source of inspiration to design your own.

https://linkedin.github.io/dph-framework/

Explorers are bad leaders | Derek Sivers

Tags: tech, management, leadership

A bit too archetypal for my taste but there’s some truth to it. If you lean towards “explorer” (I think I do), it’s hard to be also a leader. Now you could be aware of your flaws and put tools in place to compensate for them when you need lead.

https://sive.rs/exled

Bye for now! And see you in 2024!

The ownCloud product Infinite Scale is going to be released in version five soon. The latest stable version is 4.0.5 and I am sure everybody checked it out already and is blown away by it’s performance, elegance and ease of use.

No, not yet?

Ok, well, in that case, here comes rescue: With the little script described here, it becomes really easy to start Infinite Scale to check it out on your computer. It makes it really easy and quick for you, without Linux super admin powers whatsoever.

To use it, you just need to open a terminal on your machine and cd into a directory somewhere in your home where you can afford to host some bytes.

Without further preparation, you type the following command line (NOT as user root please):

curl -L https://owncloud.com/runocis.sh | /bin/bash

What it does is that it automatically pulls the latest stable version of Infinite Scale from the official download server of ownCloud onto your computer. For that, it creates a configuration and a start script, and starts the server. The script detects the platform on which your’re running to download the right binary version. It also looks up the hostname and configures the installation for that name.

Once the server was started Infinite Scale’s web client can be accessed by pointing a browser to the URL https://your-hostname:9200/. Since this is an installation for testing purposes, it does not have a proper certificate configured. That is why your browser is complaining about the cert, and you have to calm it. And indeed, that is one of the reasons why you’re not supposed to use this sneak peak in production or even exposed to the internet.

For the nerds, the script does not really do magic, but just curls the golang single binary of Infinite Scale down to the machine into a sandbox directory, chmod it to be executable and create a working config and a data dir. All happens with the priviledges of the logged in user, no sudo or root involved. You’re encouraged to double check the install script using for example the command curl -L https://owncloud.com/runocis.sh | less - of course you never should trust anybody running scripts from the internet on your machine.

If the server is stopped by pressing Ctrl-C, it later can be started again by the script runocis.sh that was kindly left behind in the sandbox as well.

The installer was tested on these three platforms: 64 bit AMD/Intel CPU based Linux machines, 64 bit Raspberry Pi with Raspbian OS and MacOSX. The flavour of Linux should not make a difference.

If you encounter a problem with the script or if you have suggestions to improve, please find it in my this’n that section on Github. I am happy to receive issue reports or pull requests.

For further information and setups suitable for production please refer to the Infinite Scale documentation.

As someone suffering from a latent burnout thingy which has become more imminent in recent years and as someone who is still struggling to develop strategies to alleviate its effects on health and general well-being, I wholeheartedly recommend everyone to watch this video and let those points sink. Yes, even if you are not (yet) affected. The video is not all about burnout but about strategies for sustaining long-term sanity.

https://www.youtube.com/watch?v=qyz6sOVON68

Enjoy. :)

Let’s go for my web review for the week 2023-51.

Do we need to rethink what free software is?

Tags: tech, foss, licensing, ethics

A bit of an older article I’m bumping into again. It lays out fairly well the current limits and issues with Free Software as it is defined today. I’m unconvinced it can be solved via licenses but the debate needs to happen… I feel that somehow it’s too much ignored.

https://mjg59.dreamwidth.org/52907.html

Adam Mosseri spells out Threads’ plans for the fediverse - The Verge

Tags: tech, facebook, fediverse, social-media

Looks like Meta is moving forward with more ActivityPub compatibility for Threads. This raises real questions about what they genuinely want to implement and what they’ll abandon along the way.

https://www.theverge.com/2023/12/15/24003435/adam-mosseri-threads-fediverse-plans

The Fediverse, Meta and the Tolerance Paradox

Tags: tech, facebook, fediverse, social-media

As Threads being connected to the Fediverse might turn into a reality, this article becomes all the more important. The question of this connection being even desirable is an important one.

https://www.viennawriter.net/blog/the-fediverse-meta-and-the-tolerance-paradox-en/

How bad are the thousands of new stochastically-generated websites?

Tags: tech, web, search, ai, gpt, criticism, knowledge

When SEO and generated content meet… this isn’t pretty. The amount of good content on the web reduced in the past decade, it looks like we’re happily crossing another threshold in mediocrity.

https://infosec.exchange/@bhawthorne/111601578642616056

Heather Ford: Is the Web Eating Itself? LLMs versus verifiability - Ethan Zuckerman

Tags: tech, ai, gpt, knowledge, wikipedia

The actual dangers of generative AI. Once the web is flooded with generated content, what will happen to knowledge representation and verifiability?

https://ethanzuckerman.com/2023/10/10/heather-ford-is-the-web-eating-itself-llms-versus-verifiability/

Facebook Is Being Overrun With Stolen, AI-Generated Images That People Think Are Real

Tags: tech, ai, machine-learning, gpt, social-media, criticism

Here we are… We’re really close to crossing into this territory where any fiction can disguise itself for reality. The problem is that we’ll literally be drowning in such content. The social impacts can’t be underestimated.

https://www.404media.co/facebook-is-being-overrun-with-stolen-ai-generated-images-that-people-think-are-real/

Cory Doctorow: What Kind of Bubble is AI?

Tags: tech, economics, business, ai, gpt

That’s a very good question. What will be left once all the hype is gone? Not all bubbles leaving something behind… we can hope this one will.

https://locusmag.com/2023/12/commentary-cory-doctorow-what-kind-of-bubble-is-ai/

Google OAuth is broken (sort of) - Truffle Security

Tags: tech, google, oauth, security

Interesting finding. This shows a potential issue in how identities are verified by providers.

https://trufflesecurity.com/blog/google-oauth-is-broken-sort-of/

SMTP Smuggling - Spoofing E-Mails Worldwide - SEC Consult

Tags: tech, security, email

New technique for SMTP smuggling… vulnerable servers then allow to spoof while still passing DMARC checks properly. Check your providers and server configuration.

https://sec-consult.com/blog/detail/smtp-smuggling-spoofing-e-mails-worldwide/

Terrapin Attack

Tags: tech, ssh, security

Interesting new attack on the SSH protocol. This is hard to achieve outside of the LAN though.

https://terrapin-attack.com/

The World Before Git - by Sarup Banskota

Tags: tech, version-control, git, history

Back to the history of VCS, anyone still remember and used SCCS? Well, I did use it…

https://osshistory.org/p/the-world-before-git

PowerInfer: Fast Large Language Model Serving with a Consumer-grade GPU

Tags: tech, ai, machine-learning, gpt

Interesting inference engine. The design is clever with an hybrid CPU-GPU approach to limit the memory demand on the GPU and the amount of data transfers. The results are very interesting, especially surprising if the apparently very limited impact on the accuracy.

https://ipads.se.sjtu.edu.cn/_media/publications/powerinfer-20231219.pdf

Medusa: Simple Framework for Accelerating LLM Generation with Multiple Decoding Heads

Tags: tech, ai, machine-learning, gpt, optimization

Interesting technique to speed up the generation of large language models.

https://sites.google.com/view/medusa-llm

Interface Dispatch | Lukas Atkinson

Tags: tech, programming, object-oriented, compiler

Nice state of the art view on how dynamic dispatch is implemented in several languages. Does a good way showing the trade-offs involved.

https://lukasatkinson.de/2018/interface-dispatch/

Database Fundamentals

Tags: tech, databases, distributed

An exploration of how databases work from first principles, going all the way to distributed nodes etc. Good list of topics to explore further.

https://tontinton.com/posts/database-fundementals/

Maybe We Don’t Need UUIDv7 After All

Tags: tech, databases, uuid

It might not be as clear cut as sometimes assumed. With the right index UUIDv4 can still do as key in databases.

https://lu.sagebl.eu/notes/maybe-we-dont-need-uuidv7/

How many CPU cores can you actually use in parallel?

Tags: tech, multithreading, performance, python

This is unsurprisingly highly depend on the actual code, not only on the hardware.

https://pythonspeed.com/articles/cpu-thread-pool-size/

Performance engineering, profilers, and seeing the invisible - Made of Bugs

Tags: tech, profiling, optimization

Or why using a profiler is not as easy as it sounds. This requires quite some experience and the ability to tap in other information not present in the profile.

https://blog.nelhage.com/post/profilers-seeing-the-invisible/

ELF binaries and everything

before main() starts Tags: tech, elf, unix, system

Ever wondered how ELF and ld.so work? This is a good primer on the topic with a few OpenBSD specifics.

https://2023.eurobsdcon.org/slides/eurobsdcon2023-janne_johansson-ELF-binaries.pdf

A curiously recurring lifetime issue

Tags: tech, api, safety, c++

This is an easy mistake to make. I’d say the API isn’t helping there either, there’s an improvement to find in Cap’n’proto to make it safer.

https://blog.dureuill.net/articles/recurring-lifetime/

Memory Safety is a Red Herring

Tags: tech, memory, safety, rust, c++, java, python

Very interesting musing about undefined behaviors and language constraints. This is a bit Rust focused for obvious reasons but is also looking at what other languages have been doing.

https://steveklabnik.com/writing/memory-safety-is-a-red-herring

Never trust a programmer who says they know C++ by Louis Brandy

Tags: tech, c++, learning, interviews

An old post, but very much true… People who really know C++ have stared the abyss in the eye, and you can tell.

http://lbrandy.com/blog/2010/03/never-trust-a-programmer-who-says-he-knows-c/

Simulating Fluids, Fire, and Smoke in Real-Time

Tags: tech, shader, 3d, simulation, physics, mathematics

Wonder how to implement such real-time simulations? This is a good summary of all the math involved. Also comes with code snippets and demos.

https://andrewkchan.dev/posts/fire.html

The day I started believing in Unit Tests

Tags: tech, tests, embedded

Interesting story about using unit tests by someone who thought it was a waste of time… until, they helped uncover a bug which was widespread. Also it was in an embedded context which comes with its own challenges.

https://mental-reverb.com/blog.php?id=42

Advice for new software devs who’ve read all those other advice essays • Buttondown

Tags: tech, programming, craftsmanship

This is a good set of advices for beginners. I especially like the ones about best practices, trying different things and why it makes sense to be conservative tech wise.

https://buttondown.email/hillelwayne/archive/advice-for-new-software-devs-whove-read-all-those/

Technical Debt is not real

Tags: tech, technical-debt

This is indeed a more complex topic than it sounds. When someone complains about “technical debt” always inquire what it really means to them, what this is about, what are the symptoms.

https://www.foxhound.systems/blog/technical-debt-is-not-real/

Managing Technical Debt - Jacob Kaplan-Moss

Tags: tech, technical-debt, product-management, project-management, metrics

Good approach for tackling it indeed. The crux of the issue is really measuring the tech debt since it’s still a fuzzy concept and we have no good metrics for it.

https://jacobian.org/2023/dec/20/tech-debt/

Ask Questions, Repeat The Hard Parts, and Listen – Rands in Repose

Tags: management, leadership, decision-making

This is an impressive piece about decision making and leadership. I love the approach: seeking to get the decision out of the person instead of deciding for them.

https://randsinrepose.com/archives/ask-questions-repeat-the-hard-parts-and-listen/

How Lego builds a new Lego set

Tags: lego, design

Fascinating article explaining how some Lego sets are designed.

https://www.theverge.com/c/23991049/lego-ideas-polaroid-onestep-behind-the-scenes-price

Bye for now!

chsh is a small tool that lets you change the default shell for your current user. In order to let any user change their own shell, which is set in /etc/passwd, it needs privileges and is generally setuid root.

I am of the opinion that setuid/setgid binaries are a UNIX legacy that should be deprecated. I will explain the security reasons behind that statement in a future post.

In this “UNIX legacy” series of posts, I am looking at classic setuid binaries and try to find better, safer alternatives for common use cases. In this post, we will look at alternatives to changing your login shell.

Should you change the default shell?

People usually change their default shell because they want to use a modern alternative to Bash (Zsh, fish, Oils, nushell, etc.).

Changing the default shell (especially to a non POSIX or Bash compatible one) might have unintended consequences as some scripts relying on Bash compatibility might not work anymore. There are lots of warnings about this, for example for the fish shell:

• Fish shell docs: Default Shell
• Arch Linux Wiki: fish: Setting fish as default shell
• Gentoo Wiki: fish: Caveats

On Fedora Atomic Desktops (Silverblue, Kinoite, etc.), your preferred shell may not always be available, notably if you have to reset your overlays for an upgrade, and could lead to an unusable system:

• Cannot Login after update of Silverblue Rawhide - Login loops back to login screen, same applies for tty2 login attempts
• using lchsh to change the shell brings user back to fedora setup

So overall, it is a bad idea to change the default login shell for interactive users.

For non-interactive users or system users, the shell is usually set by the system administrator only and the user itself never needs to change it.

If you are using systemd-homed, then you can change your own shell via the homectl command without needing setuid binaries but for the same reasons as above, it is still not a good idea.

Graphical interface: Use a modern terminal emulator

If you want to use another shell than the default one, you can use the functionality from your graphical terminal emulator to start it by default instead of Bash.

I recommend using the freshly released Prompt (sources) terminal if you are running on Fedora Silverblue or other GNOME related desktops. You can set your preferred shell in the Profiles section of the preferences. It also has great integration for toolbox/distrobox containers. We’re investigating making this the default in a future version of Fedora Silverblue (issue#520).

If you are running on Fedora Kinoite or other KDE related desktops, you should look at Konsole’s profiles features. You can create your own profiles and set the Command to /bin/zsh to use another shell. You can also assign shortcuts to profiles to open them directly a new tab, or use /bin/toolbox enter fedora-toolbox-39 as Command to directly enter a toolbox container for example.

This is obviously not an exhaustive list and other modern terminal emulators also let you specify which command to start.

If your terminal emulator does not allow you to do that, then you can use the alternative from the next section.

Or use a small snippet

If you want to change the default shell for a user on a server, then you can add the following code snippet at the beginning of the user’s ~/.bashrc (example for fish):

# Only trigger if:
# - 'fish' is not the parent process of this shell
# - We did not call: bash -c '...'
# - The fish binary exists and is executable
if [[ $(ps --no-header --pid=$PPID --format=comm) != "fish" && -z ${BASH_EXECUTION_STRING} && -x "/bin/fish" ]]; then
  shopt -q login_shell && LOGIN_OPTION='--login' || LOGIN_OPTION=''
  exec fish $LOGIN_OPTION
fi

References

• Arch Linux Wiki: fish: Setting fish as interactive shell only
• How to check if a shell is login/interactive/batch

Other posts from this series

• sudo without a setuid binary or SSH over a UNIX socket

Cutelyst the Qt web framework is now at v4.0.0 just a bit later for it’s 10th anniversary.

With 2.5k commits it has been steadly improving, and in production for many high traffic applications. With this release we say good bye to our old Qt5 friend, also dropped uWSGI support, clearsilver and Grantlee were also removed, many methods now take a QStringView and Cutelyst::Header class was heavly refactored to allow usage of QByteArrayView, and stopped storing QStrings internally in a QHash, they are QByteArray inside a vector.

Before, all headers were uppercased and dashes replaced with underscores, this was quite some work, so that when searching the string had to be converted to this format to be searcheable, this had the advantage of allowing the use of QHash and in templates you could c.request.header.CONTENT_TYPE. Turns out both cases aren’t so important, speed is more important for the wider use cases.

With these changes Cutelyst managed to get 10 – 15% faster on TechEmpower benchmarks, which is great as we are still well positioned as a full stack framework there.

https://github.com/cutelyst/cutelyst/releases/tag/v4.0.0

Have fun, Merry Christmas and Happy New Year!

This is an update on the ongoing migration of jobs from Binary Factory to KDE's GitLab. Since the last blog a lot has happened.

A first update of Itinerary was submitted to Google Play directly from our GitLab.

Ben Cooksley has added a service for publishing our websites. Most websites are now built and published on our GitLab with only 5 websites remaining on Binary Factory.

Julius Künzel has added a service for signing macOS apps and DMGs. This allows us to build signed installers for macOS on GitLab.

The service for signing and publishing Flatpaks has gone live. Nightly Flatpaks built on our GitLab are now available at https://cdn.kde.org/flatpak/. For easy installation builds created since yesterday include .flatpakref files and .flatpakrepo files.

Last, but not least, similar to the full CI/CD pipeline for Android we now also have a full CI/CD pipeline for Windows. For Qt 5 builds this pipeline consists of the following GitLab jobs:

• windows_qt515 - Builds the project with MSVC and runs the automatic tests.
• craft_windows_qt515_x86_64 - Builds the project with MSVC and creates various installation packages including (if enabled for the project) a *-sideload.appx file and a *.appxupload file.
• sign_appx_qt515 - Signs the *-sideload.appx file with KDE's signing certificate. The signed app package can be downloaded and installed without using the Microsoft store.
• microsoftstore_qt515 - Submits the *.appxupload package to the Microsoft store for subsequent publication. This job doesn't run automatically.

• The craft_windows_qt515_x86_64 job also creates .exe installers. Those installers are not yet signed on GitLab, i.e. Windows should warn you when you try to install them. For the time being, you can download signed .exe installers from Binary Factory.
• There are also jobs for building with MinGW, but MinGW builds cannot be used for creating app packages for the Microsoft Store. (It's still possible to publish apps with MinGW installers in the Microsoft Store, but that's a different story.)

1. You download the signed sideload app package, install it on a Windows (virtual) machine (after uninstalling a previously installed version) and perform a quick test to ensure that the app isn't completely broken.
2. Then you trigger the microsoftstore_qt515 job to submit the app to the Microsoft Store. This creates a new draft submission in the Microsoft Partner Center. The app is not published automatically. To actually publish the submission you have to log into the Microsoft Partner Center and commit the submission.

Enabling the Windows CD Pipeline for Your Project

[BlueprintSettings]
kde/applications/myapp.packageAppx = True

kde/applications/myapp must match the path of your project's Craft blueprint.

When you have successfully built the first Windows app packages then add the craft-windows-appx-qt5.yml or the craft-windows-appx-qt6.yml template to your .gitlab-ci.yml to get the sign_appx_qt* job and the microsoftstore_qt* job.

To enable signing your project (more precisely, a branch of your project) needs to be cleared for using the signing service. This is done by adding your project to the project settings of the appxsigner. Similarly, to enable submission to the Microsoft Store your project needs to be cleared by adding it to the project settings of the microsoftstorepublisher. If you have carefully curated metadata set in the store entry of you app that shouldn't be overwritten by data from your app's AppStream data then have a look at the keep setting for your project. I recommend to use keep sparingly if at all because at least for text content you will deprive people using the store of all the translations added by our great translation teams to your app's AppStream data.

Note that the first submission to the Microsoft Store has to be done manually.

All the Toolbx and Distrobox container images and the ones in my personal namespace on Quay.io are now signed using cosign.

How to set this up was not really well documented so this post is an attempt at that.

First we will look at how to setup a GitHub workflow using GitHub Actions to build multi-architecture container images with buildah and push them to a registry with podman. Then we will sign those images with cosign (sigstore) and detail what is needed to configure signature validation on the host. Finally we will detail the remaining work needed to be able to do the entire process only with podman.

Full example ready to go

If you just want to get going, you can copy the content of my github.com/travier/cosign-test repo and start building and pushing your containers. I recommend keeping only the cosign.yaml workflow for now (see below for the details).

“Minimal” GitHub workflow to build containers with buildah / podman

You can find those actions at github.com/redhat-actions.

Here is an example workflow with the Containerfile in the example sub directory:

name: "Build container using buildah/podman"

env:
  NAME: "example"
  REGISTRY: "quay.io/example"

on:
  # Trigger for pull requests to the main branch, only for relevant files
  pull_request:
    branches:
      - main
    paths:
      - 'example/**'
      - '.github/workflows/cosign.yml'
  # Trigger for push/merges to main branch, only for relevant files
  push:
    branches:
      - main
    paths:
      - 'example/**'
      - '.github/workflows/cosign.yml'
  # Trigger every Monday morning
  schedule:
    - cron:  '0 0 * * MON'

permissions: read-all

# Prevent multiple workflow runs from racing to ensure that pushes are made
# sequentialy for the main branch. Also cancel in progress workflow runs for
# pull requests only.
concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: ${{ github.event_name == 'pull_request' }}

jobs:
  build-push-image:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repo
        uses: actions/checkout@v4

      - name: Setup QEMU for multi-arch builds
        shell: bash
        run: |
          sudo apt install qemu-user-static

      - name: Build container image
        uses: redhat-actions/buildah-build@v2
        with:
          # Only select the architectures that matter to you here
          archs: amd64, arm64, ppc64le, s390x
          context: ${{ env.NAME }}
          image: ${{ env.NAME }}
          tags: latest
          containerfiles: ${{ env.NAME }}/Containerfile
          layers: false
          oci: true

      - name: Push to Container Registry
        uses: redhat-actions/push-to-registry@v2
        # The id is unused right now, will be used in the next steps
        id: push
        if: (github.event_name == 'push' || github.event_name == 'schedule') && github.ref == 'refs/heads/main'
        with:
          username: ${{ secrets.BOT_USERNAME }}
          password: ${{ secrets.BOT_SECRET }}
          image: ${{ env.NAME }}
          registry: ${{ env.REGISTRY }}
          tags: latest

This should let you to test changes to the image via builds in pull requests and publishing the changes only once they are merged.

You will have to setup the BOT_USERNAME and BOT_SECRET secrets in the repository configuration to push to the registry of your choice.

If you prefer to use the GitHub internal registry then you can use:

env:
  REGISTRY: ghcr.io/${{ github.repository_owner }}

...
  username: ${{ github.actor }}
  password: ${{ secrets.GITHUB_TOKEN }}

You will also need to set the job permissions to be able to write GitHub Packages (container registry):

permissions:
  contents: read
  packages: write

See the Publishing Docker images GitHub Docs.

You should also configure the GitHub Actions settings as follow:

• In the “Actions permissions” section, you can restict allowed actions to: “Allow <username>, and select non-<username>, actions and reusable workflows”, with “Allow actions created by GitHub” selected and the following additionnal actions:

  redhat-actions/*,
  

• In the “Workflow permissions” section, you can select the “Read repository contents and packages permissions” and select the “Allow GitHub Actions to create and approve pull requests”.

• Make sure to add all the required secrets in the “Secrets and variables”, “Actions”, “Repository secrets” section.

Signing container images

We will use cosign to sign container images. With cosign, you get two main options to sign your containers:

• Keyless signing: Sign containers with ephemeral keys by authenticating with an OIDC (OpenID Connect) protocol supported by Sigstore.
• Self managed keys: Generate a “classic” long-lived key pair.

We will choose the the “self managed keys” option here as it is easier to setup for verification on the host in podman. I will likely make another post once I figure out how to setup keyless signature verification in podman.

Generate a key pair with:

$ cosign generate-key-pair

Enter an empty password as we will store this key in plain text as a repository secret (COSIGN_PRIVATE_KEY).

Then you can add the steps for signing with cosign at the end of your workflow:

      # Include at the end of the workflow previously defined

      - name: Login to Container Registry
        uses: redhat-actions/podman-login@v1
        if: (github.event_name == 'push' || github.event_name == 'schedule') && github.ref == 'refs/heads/main'
        with:
          registry: ${{ env.REGISTRY }}
          username: ${{ secrets.BOT_USERNAME }}
          password: ${{ secrets.BOT_SECRET }}

      - uses: sigstore/cosign-installer@v3.3.0
        if: (github.event_name == 'push' || github.event_name == 'schedule') && github.ref == 'refs/heads/main'

      - name: Sign container image
        if: (github.event_name == 'push' || github.event_name == 'schedule') && github.ref == 'refs/heads/main'
        run: |
          cosign sign -y --recursive --key env://COSIGN_PRIVATE_KEY ${{ env.REGISTRY }}/${{ env.NAME }}@${{ steps.push.outputs.digest }}
        env:
          COSIGN_EXPERIMENTAL: false
          COSIGN_PRIVATE_KEY: ${{ secrets.COSIGN_PRIVATE_KEY }}

2024-01-12 update: Sign container images recursively for multi-arch images.

We need to explicitly login to the container registry to get an auth token that will be used by cosign to push the signature to the registry.

This step sometimes fails, likely due to a race condition, that I have not been able to figure out yet. Retrying failed jobs usually works.

You should then update the GitHub Actions settings to allow the new actions as follows:

redhat-actions/*,
sigstore/cosign-installer@*,

Configuring podman on the host to verify image signatures

First, we copy the public key to a designated place in /etc:

$ sudo mkdir /etc/pki/containers
$ curl -O "https://.../cosign.pub"
$ sudo cp cosign.pub /etc/pki/containers/
$ sudo restorecon -RFv /etc/pki/containers

Then we setup the registry config to tell it to use sigstore signatures:

$ cat /etc/containers/registries.d/quay.io-example.yaml
docker:
  quay.io/example:
    use-sigstore-attachments: true
$ sudo restorecon -RFv /etc/containers/registries.d/quay.io-example.yaml

And then we update the container signature verification policy to:

• Default to reject everything
• Then for the docker transport:
  • Verify signatures for containers coming from our repository
  • Accept all other containers from other registries

If you do not plan on using container from other registries, you can even be stricter here and only allow your containers to be used.

/etc/containers/policy.json:

{
    "default": [
        {
            "type": "reject"
        }
    ],
    "transports": {
        "docker": {
            ...
            "quay.io/example": [
                {
                    "type": "sigstoreSigned",
                    "keyPath": "/etc/pki/containers/quay.io-example.pub",
                    "signedIdentity": {
                        "type": "matchRepository"
                    }
                }
            ],
            ...
            "": [
                {
                    "type": "insecureAcceptAnything"
                }
            ]
        },
        ...
    }
}

See the full man page for containers-policy.json(5).

You should now be good to go!

What about doing everything with podman?

Using this workflow, there is a (small) time window where the container images are pushed to the registry but not signed.

One option to avoid this problem would be to first push the container to a “temporary” tag first, sign it, and then copy the signed container to the latest tag.

Another option is to use podman to push and sign the container image “at the same time”. However podman still needs to push the image first and then sign it so there is still a possibility that signing fails and that you’re left with an unsigned image (this happened to me during testing).

Unfortunately for us, the version of podman available in the version of Ubuntu used for the GitHub Runners (22.04) is too old to support signing containers. We thus need to use a newer podman from a container image to workaround this.

Here is the same workflow, adapted to only use podman for signing:

name: "Build container using buildah, push and sign it using podman"

env:
  NAME: "example"
  REGISTRY: "quay.io/example"
  REGISTRY_DOMAIN: "quay.io"

on:
  pull_request:
    branches:
      - main
    paths:
      - 'example/**'
      - '.github/workflows/podman.yml'
  push:
    branches:
      - main
    paths:
      - 'example/**'
      - '.github/workflows/podman.yml'
  schedule:
    - cron:  '0 0 * * MON'

permissions: read-all

# Prevent multiple workflow runs from racing to ensure that pushes are made
# sequentialy for the main branch. Also cancel in progress workflow runs for
# pull requests only.
concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: ${{ github.event_name == 'pull_request' }}

jobs:
  build-push-image:
    runs-on: ubuntu-latest
    container:
      image: quay.io/travier/podman-action
      options: --privileged -v /proc/:/host/proc/:ro
    steps:
      - name: Checkout repo
        uses: actions/checkout@v4

      - name: Setup QEMU for multi-arch builds
        shell: bash
        run: |
          for f in /usr/lib/binfmt.d/*; do cat $f | sudo tee /host/proc/sys/fs/binfmt_misc/register; done
          ls /host/proc/sys/fs/binfmt_misc

      - name: Build container image
        uses: redhat-actions/buildah-build@v2
        with:
          archs: amd64, arm64, ppc64le, s390x
          context: ${{ env.NAME }}
          image: ${{ env.NAME }}
          tags: latest
          containerfiles: ${{ env.NAME }}/Containerfile
          layers: false
          oci: true

      - name: Setup config to enable pushing Sigstore signatures
        if: (github.event_name == 'push' || github.event_name == 'schedule') && github.ref == 'refs/heads/main'
        shell: bash
        run: |
          echo -e "docker:\n  ${{ env.REGISTRY_DOMAIN }}:\n    use-sigstore-attachments: true" \
            | sudo tee -a /etc/containers/registries.d/${{ env.REGISTRY_DOMAIN }}.yaml

      - name: Push to Container Registry
        # uses: redhat-actions/push-to-registry@v2
        uses: travier/push-to-registry@sigstore-signing
        if: (github.event_name == 'push' || github.event_name == 'schedule') && github.ref == 'refs/heads/main'
        with:
          username: ${{ secrets.BOT_USERNAME }}
          password: ${{ secrets.BOT_SECRET }}
          image: ${{ env.NAME }}

This uses two additional workarounds for missing features:

• There is no official container image that includes both podman and buildah right now, thus I made one: github.com/travier/podman-action
• The redhat-actions/push-to-registry Action does not support signing yet (issue#89). I’ve implemented support for self managed key signing in pull#90. I’ve not looked at keyless signing yet.

You will also have to allow running my actions in the repository settings. In the “Actions permissions” section, you should use the following actions:

redhat-actions/*,
travier/push-to-registry@*,

Conclusion

The next steps are to figure out all the missing bits for keyless signing and replicate this entire process in GitLab CI.

Brise theme is yet another fork of Breeze. The name comes having both the French and German translations of Breeze, being Brise.

As some people know, I’m contributing quite a lot to the Breeze style for the Plasma 6 release and I don’t intend to stop doing that. Both git repositories share the same git history and I didn’t massively rename all the C++ classes from BreezeStyle to BriseStyle to make it as easy as possible to backport commits from one repository to the other. There are also no plans to make this the new default style for Plasma.

My goal with this Qt style is to have a style that is not a big departure of Breeze like you know it but does contain some cosmetic small changes. This would serve as a place where I can experiment with new ideas and if they tend to be popular to then move them to Breeze.

Here is a breakdown of all the changes I made so far.

• I made Brise coinstallable with Breeze, so that users can have both installed simultaneously. I minified the changes to avoid merge conflicts while doing so.

• I increased the border radius of all the elements from 3 pixels to 5 pixels. This value is configurable between small (3 pixels), medium (5 pixels) and large (7 pixels). A merge request was opened in Breeze and might make it into Plasma 6.1. The only difference is that in breeze the default will likely keep being 3 pixels for the time being.

• Add a separator between the search field and the title in the standard KDE config windows which serves as an extension of the separator between the list of the setting’s categories and the setting’s page. This is mostly to be similar to System Settings and other Kirigami applications. There is a pending merge request for this also in Breeze.
• A new tab style that removes the blue lines from the active lines and introduce other small changes. Non-editable tabs are also now filling the entire horizontal space available. I’m not completely happy with the look yet, so no merge requests have been submitted to Breeze.

• Remove outlines from menu and combobox items. My goal is to go in the same direction as KirigamiAddons.RoundedItemDelegate.

• Ensure that all the controls have the same height. Currently a small disparency in height is noticeable when they are in the same row. The patch is still a bit hacky and needs some wider testing on a large range of apps to ensure no regressions, but it is also a improvement I will definitively submit upstream once I feel like it’s ready.

Here, in these two screenshots, every control has 35 pixels as height.

Finally here is Kate and KMail’s settings with Breeze and Brise.