DEV Community: Heapstack

FOSDEM 26 - a quick summary

Heapstack — Wed, 11 Feb 2026 22:31:15 +0000

Another year, another FOSDEM. I think my first one was 2014, but I’m not sure. I can conclude that just like myself, the hotel I usually stay at has started to be in a small need of renovation, and Brussels nowadays feels a tiny bit like another home. With that, let’s head into a summary of FOSDEM 2026.

The theme this year was policy, security and regulation. A lot of developers nowadays are very interested in these aspects, so much in fact that you had to line up early to have a chance of attending the crowded rooms. This is good — software engineering is far much more than about the code. The public was the general mix of youngsters, old gray beards, people from the EU departments, academia, companies, public sector, hobbyists. Although the high interest in policy, there were still talks that deep dived into more obscure topics, so I don’t feel FOSDEM is losing its grassroots spirit, even though the talks are evolving.
Were there 10,000 visitors? I can only guess.

Saturday

My Saturday started with a strong brew coffee I luckily found at a coffee shop, near the corner of the big university park. At the same time I was a bit stressed, as I started to fill in the bookmarks for the talks of the day. The reality is - You can’t make a plan to stick to for FOSDEM, but you can at least think that you are making one. So in the FOSDEM app, I just ticked off interesting talks during the day, knowing my schedule would be changed many times. And yes it did.

Heading into the lovely chaos, me and my friends went to the welcome talk first. And… it was the first time for me that the room was so full we could not attend. A sign there were more visitors than ever at FOSDEM 2026? I don’t know. For sure, it was the first time that I missed it. Talk

I headed off to a quick talk about “with what and how should we sign our artefacts”. It pointed at the problems with current solutions, and that the infrastructure of Sigstore etc might not be the optimal from a sovereignty aspect. It gave no clear answers to these, but asked for more participation in solving them. It was a call for action. Talk

Next up was a talk about the current attestations ecosystem across different programming languages. It gave an overview of what is working and what the current challenges are. One insight was that most package systems have the provenance data, but might not have a standardized easy way to consume it, and it surprised me. Talk

The package name resolution talk came next, and this was the first one where I did not really engage as was doing a bit of coding meanwhile. It’s one of those foundational layers and the talk compared different ecosystems with their assumptions. Talk

Signing commits—yes I’m all for it! Here we were presented a solution that adds policy files to the project, instead of outsourcing it to a code hosting platform. An interesting idea, but still not sure yet if I will use the spec in practice. How about signing commits with other standards like SSH-signing. Talk

Then I made my way to a talk on package registry economics, and while we take these for granted, they are often a sensitive part of our critical infrastructure. Security is not just a technical problem but a sustainability problem. Talk

Time for lunch, and I don’t recall much. I said hi to some people and had a veggie burger from one of the booths. Quite ok and The FOSDEM way of getting energy.

Up next for me was a talk on using fuzzing to detect backdoors. It was about applying fuzzing in smarter ways to notice when code behavior starts getting off. Suspicious patterns, unexpected side effects, and highly interesting. Talk

I ended the FOSDEM day with a talk on VEX (Vulnerability Exploitability eXchange). We can just accept that vulnerabilities are going to keep being discovered, so how can we communicate “what matters in all the information” in a way that both tools and humans can act on? Talk

After that, food, long walk admiring the architecture of Brussels. Me and my friends ended up for a brief stint at a local pub, and then with a buzzing brain off to the hotel for a well-deserved sleep.:)

Sunday

Same place as Saturday, same brew coffee, energy restored. Filled out the schedule and off I went.

I started with a talk on Contextual SBOMs where the core idea is to build relationships between SBOMs so they have a deeper context beyond being these massive, flat ingredient lists. “What matters in this particular situation?” Often we generate SBOMs but the important thing is really, how do we use them and how do they improve our processes of handling security and license issues. Talk

Right after that was a talk on integrating VEX into open source workflows. Again it focused on how we can diminish the load of CVEs—and with VEX how we can improve our update flows. Talk

From a focus on supply chain security into CRA. First up was a session on the Cyber Resilience Act, FOSS, and compliance. This first talk was about things I already knew and was just giving an overview, without too much detail. This was for someone new to CRA more than if you’ve had a look already. Talk

After this CRA-focused talk came a really good one, watch this. Clear answers, detailed answers. What does it mean for A) a commercial actor, B) a public sector or NGO actor, Open Source Steward, C) a hobbyist maintainer with only sponsorships for basic costs? This was people from the commission’s behalf and I left there with the feeling that CRA is great for citizen safety and great for Open Source developers. I think they succeeded in ensuring that this has the potential to be really good for open source. Talk

A short talk and crowded talk on SSH logins comparing certificate-based authentication versus OPKSSH. Talk

After that I was running low on battery. That was it. Everything caught up and I just wanted a bit of silence, and to relax with some coding, coffee and chatted a bit with people. I found a corner and improved my commitlint tool Gommitlint (please test it:). My friends also started to get tired so we just left… another FOSDEM done. Have you booked your next one?

Moving from GitHub to Codeberg(Forgejo)

Heapstack — Wed, 21 Jan 2026 06:13:15 +0000

NOTE: This post is written from a private developer perspective, not that of my employer.

I've started migrating my active projects from GitHub to Codeberg.
Codeberg is a European open-source alternative that overall resembles GitHub—a code collaboration platform. I'd been considering it for a while, and now that it's almost done, I wanted to share my thoughts.

Why?

One thing I've increasingly felt about GitHub is that they ignore basic, important developer features while prioritizing other unrequested ones. What I miss includes fast-forward merges for linear history, rebase-only repos, SHA256 support, and AsciiDoc rendering that's still missing or broken. The whole markup rendering is a mess with uneven support for different formats.
Full token security has been requested for a long time, yet we still have to use old, insecure Classic tokens for publishing packages (fine-grained tokens aren't done). Many solutions end up 80% done and then seem to stall.
Maybe it's telling that the open source parts, like the GitHub markup repo, seem abandoned. There are issues sitting for years, and the commit history shows no steady stewardship.
Overall it feels like GitHub has, in some areas, stopped prioritizing developer community needs and technical excellence.
Much of GitHub is historically good too, of course, but I expect far more technical drive and listening to the developer community from such a widely used global service.

But not only that—lately I've also been thinking more about how important digital sovereignty is; no surprise, given the crises around us. GitHub is under US law, which has unfortunately become a liability. The idea of developers being cut off from their projects because of "tweet-of-the-day-and-it's-consequences"-politics is no longer far-fetched. Developers have historically been banned from the platform in regards to US sanctions. My, and many other developers', trust in US data services was already damaged by the stories of FISA702 and the NSA way back, and it hasn't grown stronger in recent years, in particular the two latest ones. Against that backdrop, supporting an initiative in Europe, under EU law, feels both motivated and straightforward.

So, if not GitHub, what then?
I looked around.
GitLab?
I also like GitLab a lot and have used it for years at work and privately. It's partly open source, which is better than GitHub's total black box. But I wanted something European, more community-driven—something where I could fix a feature myself if the platform didn't.
Sourcehut?
No—too bare-bones.

The choice fell on Codeberg.
Codeberg is run by a non-profit foundation that runs on the open-source project Forgejo. You can self-host components like runners, you can contribute solutions and future directions, and the foundation is EU-based. It's not just another "GitHub" clone.
For example, they're working on adding federation support.
Forgejo is written in Go, and it shows—the platform feels snappy and fast.

I started moving my projects over. Transferring code, features like Pages, and Renovate was fairly easy. Setting up more advanced CI flows required extra work, partly because there are still unresolved issues. You also have to set up your own runners (I used Podman-based ones).While Forgejo Actions are similar to GitHub Actions, there are some differences in how they work. So expect to miss features you're used to having from GitHub Actions and maybe GitLab CI.

Sure, the goal is probably not for Codeberg to reach feature parity with GitHub and others, but as an end user every such feature helps me migrate. So personally I hope they get even closer to parity.
That doesn't rule out solving the same user needs in even better ways.

I will still work on GitHub, and will keep contributing to projects there, both for myself and for my job. My point is simply that it’s worth thinking about who owns FOSS infrastructure and who controls it sometimes. If there are equivalent alternatives, maybe choose them instead.

Conclusion:

If you're a tech-minded individual with accounts or projects already on GitHub, GitLab, etc, I'd definitely say—give Codeberg a shot for your projects.Set up a Runner and get started.
If you're an organization, I'd suggest waiting until some of the missing features are resolved (or maybe better, start to fix them).

PS Here's a post about the rough edges I hit during the migration:

What I found missing on Codeberg as a new user - my practical notes

Relevant References

Gommitlint - a tool for keeping your commit quality

Heapstack — Fri, 16 Jan 2026 11:43:29 +0000

Commit messages matter.
Yet many of us still toss out a "fix stuff" or "wip" when we're moving fast. Maybe you let an AI agent vibe‑commit whatever it feels like.
That's totally fine in test branches, where you can clean them up later, but not in the main branch. The effort to write a good commit message is the same as writing a bad one. Although, the difference shows up six months later when you dig through the git logs and the messages don't give a clear picture of what happened.

I’ve written before about keeping a clean Git history and signing commits for security. Those posts were about how. But knowing and doing consistently are two different things. People (and perhaps even more so AI agents) forget.

Over the years I’ve tried several commit‑lint tools, but none have made me fully satisfied. Some were JS‑ or Python‑based, which means depending on a runtime ecosystem just to validate a commit message. Others looked very promising, like "conform", but are now almost abandoned with issue lists that does not get addressed.

I wanted a linter as a single binary, without runtime dependencies, that works out of the box and comes with sensible (in my view) defaults. The result was that I created Gommitlint. And I think it turned out pretty OK.
The goal was a tool that works just as well as a CLI tool as in a CI flow.

Gommitlint is thus a Git commit linter — a CLI tool written in Go for commit messages.
It validates commit messages against different configurable rules, for example Conventional Commits format, length and style of the subject line, sign‑off (DCO), cryptographic signatures (GPG or SSH), spelling, linear history, and limits for how far a branch may get ahead.
It can validate individual commits, commit ranges, entire branches against a base branch, or commit messages from stdin or files.
Since it’s a static binary it’s perfect for small container images and CI flows.

It runs in three modes: as a CLI for manual validation, as Git hooks (commit‑msg and pre‑push) to catch problems before they end up in history, and in CI/CD pipelines as a quality check.

Effort has gone into following good CLI UX practices, with the idea that it’s the small things that make a tool pleasant to use.

Tools that require initial configuration are demanding, so Gommitlint immediately enables several rules out of the box if no other configuration is provided: subject line max 100 characters and imperative mood, Conventional Commits format, sign‑off requirement, cryptographic signature verification, spell checking, linear history, and branch‑ahead limits.
You can disable or customize all of this as you like. The point is that it does something sensible right away without a config file.

The program supports installing git hooks, locally as well as globally.
For example: run gommitlint hook install --global and each commit will be validated before it’s created, for all projects.

gommitlint validate --base-branch=main --format=json

I learned a lot by building this project from scratch — everything from the Go ecosystem and hexagonal architecture in practice to good CLI design and more DevOps patterns. In side projects, the learning and insights are at least as valuable as the result.

The process was a mix of manual craft and AI prompting.
I wrote the base by hand, used AI to improve, analyze, and build out, went back to handwork and then AI again. And so on. There are a few parts I need to clean up more.

Gommitlint is open source (EUPL‑1.2) and available as binaries for Linux and BSD (and an untested and unsupported binary for macOS), system packages (.deb, .rpm, .apk) and container images.

Releases before the 1.0.0-series will have some embarrassing bugs or documentation misses, that is part of the deal. But, if you want to make it even better, issues, suggestions and contributions are welcome.

Happy Linting!

Links

Tool:

Related posts:

Translating Free Software - why bother

Heapstack — Thu, 29 May 2025 09:07:49 +0000

I’ve been translating free software on and off for years. It started with wanting to translate a project I used daily, and then it continued because it was interesting and fun. In this post I want to share a few thoughts about why translations are important, and what’s worth keeping in mind in this context.
Why Bother at all?

The simple answer is that good translations means more people can use tools in their own language. But it’s more than that.

A shared language is one of the strongest bonds holding a society together. It brings people closer and is deeply tied to people’s cultural identity. We are often pretty good at adopting anglicisms in the IT world, but there is value in preserving and using your beautiful mother tongue when possible. When making the software available in your native language, you help that preservation.

When you translate software, you learn a lot about the programs at a deep level. You discover features you never knew were there, and you get to think about how the user experience is built. It makes you truly understand both the program and the technology behind how it works.

AI translations are impressive. I use them all the time to do the groundwork. But they still miss meanings and linguistic nuances, and they need a human to review them, line by line. Human translators will still be needed for review and language quality.

If you want to help with free software but don’t code, translating is a great way to start. You get to be part of a project, learn how open source workflows and practices function, and make a real difference—without writing any code at all.
Challenges

You don’t need to be a professional translator who makes a living translating Japanese haiku day in and day out, but you do need decent language skills. Good spelling and grammar aren’t optional. Bad translations can mess up how well software works and make it look amateurish. In the worst cases, they can even cause problems in the translated software.

Keeping things consistent is another big headache. Using the same words everywhere sounds easy until you face the English word “file” and have to choose between fil, arkiv, or dokument in Swedish. What makes sense depends on the situation, and sometimes you just don’t have enough information.

Sometimes you also need to learn entirely new domains in depth. Can you translate an advanced video editor—or maybe software for birdwatching—without knowing the domain terminology? Usually not. Most of the time you need to dive deep into the domain of the software you translate.

Translating can take a lot of time. It can become a way to get things done while putting off other tasks. You see immediate progress, which feels good. But it’s easy for hours to slip by without noticing. Setting time limits helps keep things balanced.

Good software changes constantly. That means translations need constant updates. Keeping up with this over time can be challenging.

And the hardest part? Translating technical ideas where there isn’t an established word for it yet. Technology moves fast, and language doesn’t always keep up. Bridging that gap takes creativity and a good feel for language. Sometimes you just have to choose a word and see if it holds up over time.

That’s all for now. If this got you thinking, check out Translations for tips on how to get started. Good luck with translating!

From Hack Idea to Release: Reflections on Creating and Releasing a Open Source Project

Heapstack — Thu, 12 Sep 2024 10:00:28 +0000

This is part of a series aimed at beginner and intermediate developers, releasing or intrigued by releasing their ideas as Open Source Projects.
These reflections are biased and personal. More articles are planned. By sharing some reflections, I hope to inspire you to do your own projects

Reflections (this)
Learning Go lang as a Java Developer (TODO)
Open Source Health and Community files (TODO)
Open Source Security (TODO)

The needs

It all started years ago. I now and then needed something that seemed to always involve recreating the same old Bash script, either by me or someone else.
The overall requirements were simple, as they often are at a high level.
What we developers mostly do is really just about shuffling information from point A to point B, right?

Here, the goal was to mirror a bunch of Git repositories - to another Git provider, to disk, to an archive format, in a CLI app.
I needed this privately and in my work role. I've seen people struggle, investing a lot of time doing these things manually, and that bothers me.

Yet, it always seemed to stay as a simple Bash script. Quickly done, but as soon as anything extra had to be added - special cases, error handling, modularization, packaging, etc. - Bash scripts don't hold up for bigger tools, as most of us would agree.

So I decided to create a full CLI application for it.

The Pre-Decisions to be Made

Does such a tool exist already?

The first thing to do was to not reinvent the wheel.
There exist a few tools that are Open Source and solve this problem. At least one written in Go, a few Bash scripts, and if counting import functions like the one in Gitea.
I tried them out, but I couldn't find any that worked fully the way I wanted. And as I had other ideas of where I wanted to take the project, I decided not to deep dive into
starting to apply patches to the existing projects.

There also exist a few commercial tools, but I felt this small a tool is something that should also exist in Open Source forms.

Conclusion: There was a place for this CLI tool in this world.

Hacking on it at Work-hackdays or in Private free time?

We have hacking time at work at the end of sprints and on other occasions. One approach would be to hack on it during these occasions over time, crafting it into something useful.
I quickly decided to do it fully in my private spare time instead, for the following reasons:

Hack opportunities at work should be used for short bursts of learning and creativity, not long-term carving of a full project.
The solution doesn't fit into the core organization's business - it would always be an odd duck there if so.
Tying it to work would make it feel like just more work - I'm doing this for fun and learning Go etc - it would put pressure and stress on me.
Doing it on the work-hackdays would take forever. A few hours, spread over weeks.

Conclusion: I should do it for fun in my spare time.

Choice of Technology Stack

I've spent most of my time over the years in the Java/Kotlin world, with a few projects in JS/TS, Python/Ruby, and like every senior developer, dabbling in other at times.
For a long time though, I've wanted to really learn Go and/or Rust. So this would be an opportunity to get the motivation to dive into a new languague
The reason I picked Go is that quite a few CLI applications in the Open Source DevOps world are written in it, and I want to be able to submit patches to third-party projects at times. Also, writing in Go means one binary with many target architectures.

I was considering doing it in Java, for example, with Pico CLI and GraalVM of which of which I had a good impression since earlier tries but I decided that I really wanted to learn Go instead.

Conclusion: I should do it in Go and learn from that.

Other Learning Goals

With this, I also wanted to delve deeper into the subjects of delivering a nicely packaged Open Source project, following most of the Security practices - scorecards, SLSA,

and using tools like GoRelease to create builds of various kinds.

Conclusion: Take the opportunity to learn and delve into topics of your choice.

Keep the Scope

As I planned to experiment a lot, and I was totally new to Go, I knew I would do a lot of unstructured work.
Here it was important to set the scope - when would it be good enough for an alpha release?
I early on decided on what functionality it should have, and as tempting as it would be to sit and refine and expand it further, this was good.
I could sit with this for a long time.

Conclusion: Release the project as alpha when you are equally embarrassed and proud of it.

Estimation - How Hard Can It Be?

Learning a new language is a small part of learning the language itself, but much more about learning the ecosystem and its idioms.
What libraries are used, how are they used, what are the idiomatic ways of doing this and that?
I would have to spend a large amount of time learning and researching during this project, maybe 50% of the time I would
have spent just coding in a language and ecosystem I know.

Conclusion: Multiply your time estimate by three when learning new core stacks and involving experimentation. The language syntax will be the small thing.

The Creation Process

Initial Commit

The basic implementation was done in a day - it had no builds, error handling, documentation, edge cases, maintainability, etc.
This is where most Friday hacks end up, and most of them never goes further.

But as all senior developers know, making something work is many miles from releasing a product.

Soon done, eh? Not really.

Finding the Time

At times it was really hard finding the time to spend with the project, especially as I had an exhausting spring at work.
It's not every night that you feel like reading a book for 2 hours about something specific, or learning a new tech.
Or spending time writing documentation. I have kids and a house, and I couldn't afford to let a private project consume me more than other hobbies.
But something always has to give - I ended up watch fewer series, and any gaming has been almost non-existent during this period.

With that said, while I wish I could spend more time on the project, it was almost always motivating - I had a few night sessions where I slept less and coded or studied,
because I was so excited to get further. Also, when something is fun, it is fun, whether it's lifting weights, writing a book, developing, etc.

The Things I Forgot

I've been so used to working in teams for a long time. With a solo project, you have to manage a lot more hats and be quite good in every part of them, not often technical.
I spent quite a lot of time digging into good CLI design and idiomatic choices. Another area was the release process and building binaries for different platforms.
Following SLSA and other standards in Open Source also took time. And we want good test coverage, right?
Working in a team, someone else will hopefully do the logo you wanted, the documentation needed to be written.
Working solo, it's only you or it won't happen.
Writing code is not even 50% of delivering a project. And there's the rest.

The Impostor Syndrome Strikes

Impostor Syndrome is common in our knowledge-based developer world. Everyone has different skills, and at any given time, there will always be someone that knows more than you.
Being in a team, you have someone to discuss things with.
Alone, not as much.

But, it is all about accepting that one will do some stupid things in the code at times.
And, that Open Source isn't about being perfect. It's about learning, solving and releasing things that might be of use to others.

The Grind

Well, what can I say - it is done when it is done.

There were a few late nights debugging, refactoring, but also countless moments of flow and dopamine.

For me, the release time came when I felt the overall architecture in the project would not radically move - I had identified the interfaces, and felt that is extendable.
The codebase is OK.
Most of the basic features are there, and while everything is up for improvements, it is still a base to work on.

The Aftermath and Lessons Learned

Set the scope early: Decide where to stop. Set up your project structure, documentation, releases, pipelines, and community guidelines early. Future you will thank past you.
Don't stress, enjoy the learning process: It is done when it is done.
Be persistent: Open source is a marathon, not a sprint. Don't burn out. It is a hobby, not your life. However be persistent. Do a small thing every day.
Learn, learn, learn: See everything as an opportunity for learning and improving, not as a problem.
Coding is the easy part: The main code is what will take you the least time; everything else, like documentation, tests, etc., is where time is spent.
Do the extras: They are as fun as coding. Yes, even documentation can save you hours of explaining and re-explaining. Make it fun if bores you. Docs-as-code, vim-pong, etc.
Take breaks: Burnout is real. Step back when you need to. Just like every other creative learning process, do it in batches.
Use the system: Use your own dogfood in practice and in the real world as early as possible. Even better, find a person/community to give feedback.
Enjoy the journey: It is wonderful to create.
Complete it: There are a zillions half done projects in this world. Complete it. And then realise that the project really just starts after the first release.
Use AI as a help: I save hours by delegating a bit of boring extras to it, like asking for doc structures, summarizing things, etc. However, don't ever trust it blindly. Review and criticize the answers.

Well, happy hacking and now go and think about what you want to make next!!

Links

The project: Git Provider Sync

FOSDEM 2024 - Summary and Reflections

Heapstack — Mon, 05 Feb 2024 11:22:11 +0000

Back home from another visit to FOSDEM (the 8th, the 10th? - I'm getting old), and I thought I'd make a short summary with personal reflections.

So, what is FOSDEM, in case you don't know? It is one of Europe's biggest developer-focused conferences, mixing everything low-level and high-level in tech in a casual style. From the old obscure and up to the latest trends, you will find them all here. The common pillar is, as the name implies, Free and Open Source projects, with a healthy mix of hobbyists, NGOs, policymakers, and commercial organizations in a relaxed conference setting. Usually, there are also related events (Fringe events), before and after FOSDEM itself. With 900+ speakers, and talks available online for free there is something for everyone. Have a look here to grasp the size and diversity: Schedule.

Regarding the Fringes, some examples this year were: EU Open Source Policy Summit 2024, Workshop on FOSS license and security compliance tools, The joint 2024 Hackathon of the European Commission and PEReN, and a lot more. The Fringes are a great way to network and have fun in casual settings.

Usually, I try to attend before the actual FOSDEM event, like the license compliance and SBOM event, but this year, it was pure FOSDEM only. I also went "privately" this year, so that meant a bit more focus on just doing what I felt for at the moment. Anyway, that means these are all personal opinions, not those of my employer!

Everyone's FOSDEM experience will be different, but here are the topics where I attended during the two days (a healthy mix) with links to the FOSDEM videos and presentations.

General Reflections - the TL;DR

First, it is still the same old FOSDEM experience - lots of t-shirts and swag, beards, and the smell of GNU in overcrowded presentation halls:) - but it is really noticeable how the FOSS community has matured and is tackling new challenges on a more mature and abstract policy-related level. There are a lot of focus on regulations, laws, compliance, vulnerabilities, community funding, and how to collaborate to solve all these challenges. Surely, these issues have always been, in different forms, important - Open Source is the pillar on which modern digitalization work. But, most of the developer rooms handling these topics were jam-packed this year! So this is telling, and a good sign - the wide Open Source Challenges are of a broader interest in the developer communities also - it is not only about tech details.

Security, Policy, and Lawmaking - The Cyber Resilience ACT and the Product Liability Directive (PLD)

There were many chances to dig into the EU Cyber Resilience Act. Simplified, the CRA will regulate software as done today with hardware from a Security perspective, which means that any software on the market will fall under regulation and security demands. And of course, as every software project today mostly consists of Open Source Software (70%-90%), it will have effects on Open Source Software consumers (and producers). In the first drafts, there were many potential problems, but the Security and Open Source Community has together reworked the wordings, so it will (could be) even something beneficial to Open Source, as projects relying on releasing products to the market will also be responsible to report and avoid (fix?) vulnerabilities. This will not be the responsibility of the Open Source projects themselves. But if you are a commercial actor, this will apply.

But, as of yet, there are many things that will be interesting to see how it plays out in practice here - how will a vendor commercial product make the Open Source project they are using make the project fix the vulnerabilities? Will the vendor fund a fix for the Open Source project? Will they submit a patch? If the project maintainer does not want to fix any issues regardless, will the vendor and maintain, rewrite or what? In my simplified take, I can see that the CRA is a tough and expensive coming-of-age regulation regarding security responsibility for software for commercial vendors and commercial producers. But, as a potentially good thing for Open Source Security and trust, funding and maintenance in the long term. There will be learning pains as such, but in the end, I'm quite positive for what this might mean for Open Source. We will see.

So, For us as citizens and end consumers, I believe this is a good thing.

CRA is one example of where policymakers and the real-world communities have worked together to improve the policies, and all parts have done a great job in the end. I applaud unsung heroes here, thanks! Now there will be other up-and-coming policies - like the Interoperable Act - where it is very important to have these discussions and feedback loops between policymakers and communities/producers as we go along. With parts of the EU Commission OSPO in place and other important key players, with the lessons learned from the CRA, and the open discussions, I feel trust in that coming policies will be open to being beneficial to both the EU's digital strategy as a whole and the Open Source community's ecosystem in specific. And where it really counts, for us as citizens and end consumers - us the citizens - as intended.

See a presentation and overview about CRA here and deep dive into EU Open Source Policy details here.

SBOMS, Vulnerabilities Handling, and License Compliance

In recent years, we have been talking about Software Bill of Materials - this is in demand by the industry, will be even more in demand by upcoming regulations like CRA, among others. Roughly, it is a component catalog that can be automated and used to check vulnerabilities and license compliance - if the product is the sum of its parts, then this is mostly about declaring the parts in an automated way and, by that way, handle vulnerabilities and license compliance. While it might seem like a simple problem at first, it is not - in fact, a complicated matter, with many interesting real-world challenges to solve. Even if a lot of work has been done, and a lot of effort has gone into creating Open Source tooling and practices, it will take time to get this right.

Producing an SBOM is in no way a magical security ticket; - How do we get organizations to handle the vulnerabilities quickly, what vulnerabilities should be handled, and what SBOMs are you talking about when you say SBOM - the build, runtime, the container SBOM or what? How far the transient dependency tree should we walk, how do we handle that package managers handle dependencies differently, how do we handle that different tools report different SBOMs, what do we do we all the SBOMS and so on, and so on.

Have a look at some of the talks (there are videos for most) here.

Public Code and Digital Public Goods

Another fully packed room - yet again, glad to see this - was the talks about Public Code - in brief, code that implements public policy, used for the public good, and by public organizations like governments, public administrations, etc.

I like the notation of Digital public goods (DPGs) - an umbrella term for open-source software, open standards, open data, open AI systems, and open content collections. This helps us focus on fewer silos, and see that Open-topics are siblings.

I listened to updates about how Public Code is both heading along and meeting new challenges in Germany, and especially Germany's Sovereign Tech Fund should be an inspiration for other member states. Basically, it is Germany funding important Open Source Projects. Here is the Public Code in Germany talk.

Other Public Code And DPG Talks (video stream).

Communities

The community for a product is an important part - for what use is a dead piece of undocumented code repository if it does not solve someone's problem in an easy to understand way (answer: worthless)? So even if community building is not where my own heart lies at in Open Source, (My heart is in making it easy to release, contribute and comply with sec and licensing, knowledge sharing) and truly and fully understand the importance of it.

I was only briefly in here to feel the positive collaboration spirit, but one of the aspects lifted was funding - it is as important as ever, and still an unsolved issue in Open Source - and a great inspiration has been the work of Germany as mentioned above in the Public Code room, a work more states should follow.

Other Community Talks.

Java

With the recent releases of Java, the Java world is getting exciting again, that has been my opinion for the latest years. I went to a few Java talks, an overview of Quarkus and GraalVM to build native binaries (without JVM) and to a deep dive into Virtual Threads. While Native Java is exciting I would currently not offer it as the main release artifact of my system, but as an experimental side artifact and a companion to the main artifact.

Virtual Threads are basically lightweight threads, instead of system threads. Something other languages have had for quite a time, think async/await in JS, coroutines in Kotlin, and so on for inspiration. Brian Goetz (Architect for the Java Language at Oracle, and master of concurrency in Java) a while ago said "I think Project Loom (virtual threads) is going to kill Reactive Programming". And I do think I agree with him. Reactive has always felt like forcing in a different paradigm in Java with a shoehorn, and from our real-life experiment with it in my last organization, it was easy to create hard-to-catch bugs in production, which ultimately led us to abandoning it for a Keep-it-simple-practice instead (and also, we headed for Kotlin and Coroutines at the time). Virtual Threads solve roughly the same async problem space in a much elegant and maintainable way. I would recommend anyone on the Reactive train in the Java world to start looking at Virtual Threads instead.

Other Java talks.

Go

Recently, I have dug into the Go-lang world and will soon hopefully have one or two tools to release, written in Go-lang. "Soon":) Actually, I'm a bit obsessed with Go-lang at the moment.
So I hung around on a few Go-lang talks.

News in Golang 1.2x - and here, as promised - Go-lang evolves slowly. So while no revolutionary additions, but minor good things like min, max etc here.

I also got my eyes on GoReleaser, which I will use in my (Go) projects.

Other Go talks.

What I Missed

A lot of talks, talking to you, and filter coffee!

Besides that, I said hi to some old and some new faces, had a couple of Belgian beers and mussels, and just had a great time. As always at FOSDEM!

So that's all. Today, I'm just processing the whole experience and loading up the batteries.

Open Source is More Secure than Closed Source because Closed Source is More Secure than Open Source

Heapstack — Thu, 23 Nov 2023 21:18:43 +0000

The other day I had a discussion about whether source code is more secure when hidden out of sight — a valid discussion point that sometimes comes up. So, I thought I'd write a little opinionated post on why it is both.

And without further suspense, it is as simple as that. Because it depends. It depends on project maintenance, processes around it, and project maturity.

And this depends has proven itself in real life over the years. We can just look at the former closed-source giants, like Microsoft, which has had countless security breaches over the years, Apple and other friends with a heavy usage of closed source. While open-source software also has its daily bugs and security breaches, just like the weekly security patches and zero-day issues in Closed software that arrives in a never ending stream.

So the sad outcome is that a skilled attacker will find your bugs (vulnerabilities) regardless of code visibility. Maybe, just maybe, you can delay the finding by obscurity. But it will find you in the end if the project is interesting enough for someone to put time and effort into.

And, if the argument still seems to ring true after pondering this, why the heck is every piece of software we are currently running and basing our life's on running on open source as a base and dependency? Why has the European Union accepted it as a key for their digital strategy? Why has the White House listed open source as a must in their Cyber Security agenda if it's so unsecure? Why has big tech adopted it so hard? We might be nuts or...

Or, because the visibility of the code has proven itself not to matter as much as we might think.

If so, what can we REALLY do to improve security in a meaningful way in our open and closed projects?

A lot!! Really! Much more than we are doing at this moment. This is where the focus should go if we want REAL secure code. Not into the development model itself. Into securing and improving the system

And this is much easier now than just a few years ago. The software security world has matured after the latest years of big breaches, and a lot of former expensive or rare tooling has arrived.

Humans make mistakes. Make it easy to do it right and hard to do it wrong. Which means among other things automating

Here are some things you could do tomorrow in your projects, no intention means to be complete. I would almost bet that 9 out 10 of you who are reading this are not doing them all (including myself).

Automation of checks mistakenly committed of configuration, secrets, IPs, and passwords in commits like gitleaks.
Automation of checks for supply chain security vulnerabilities (third-party dependencies) with tools like OWASP's tools, Dependabot, Renovated.
Automation of Static Application Security Testing (SAST) to find insecure code problems.
Automation of Dynamic Application Security Testing (DAST) to find vulnerabilities.
Automation of Software Component Analysis (SCA) to focus on third-party dependencies.
Look over write access to projects.
Clearly defined processes for code reviews and size of merge request.
Plan and accept ongoing maintenance to regularly fix issues as they will change weekly.
Minimizing the container images
Make it easy and secure and encouragable to report security issues for outsiders and users.

Outside activities:

Pen test bigger releases.
Arrange a community Pen test invited hackday with prizes. Break the solutions and find vulnerabilities.

And so on, and so on...

Compare an open code base having all of the above steps in place, with documentation in place about the steps taken, or a closed-source base with no other docs "We have rigid security analysis process (trust us)". Who would you trust has the most security vulnerabilities? Whom would you or I as the end user trust? Whom should the end user trust? I know whom I would bet on.

Why we in the Public Sector should foster trust and transparency whenever we can

I honestly and truly believe that we who work in the Public Sector or similar tax payed jobs should have our goals on reaching our end users. For us in the digitalization services, that might be by means of Open Source, Open Data, good services and such. It has been proven again and again that it can not only help and give our Public Sector colleagues, but we can also receive trust from our real users—the citizens and part of that is we as humans and we as organizations should just admit that we sometimes write crappy solutions - I create bad solutions every day, and so do you and everyone else ( and other days we do it just perfectly). We miss a few things, we sometimes make the wrong decisions, miss some facts and we need improvements. While doing our best to avoid them, we should still acknowledge that we will make these mistakes at times.

This is version 0.9 ... it will contains bugs, but belive us, we are doing our best to improve upon it; We are still proud as **** of it and it is really usable - use it and please report the bugs!!. It will be maintained until archived

TL;DR
A bug is a bug is a bug. And while we can't avoid them, we can diminish them with good processes and tools. That is and should be the focus. Regardless of the development model. We in the Public Sector have an extra responsibility to be transparent.

Open Source and Closed Source has already proven itself in our global infrastructure. Don't fall for arguments that one code base is safer or more unsecure due the Source visibilty itself. Instead focus on what really means something regarding security, like security quality actions, reviews and system runtime security actions.

Links

https://en.wikipedia.org/wiki/Security_through_obscurity

http://csrc.nist.gov/publications/nistpubs/800-123/SP800-123.pdf - The National Institute of Standards and Technology (NIST) in the United States recommends against this practice: "System security should not depend on the secrecy of the implementation or its components.

ISO27001 - I think some misunderstandings come from this, but read the answer here. https://security.stackexchange.com/questions/221644/is-the-iso-iec-27001-standard-incompatible-with-free-open-source-software

The "linear git commit history with signing in GitHub-UI"-workaround

Heapstack — Tue, 10 Oct 2023 20:48:19 +0000

Intro

I prefer maintaining a linear Git history, where features are added in traceable portions. This approach has many benefits, as it makes it easy to track what has happened earlier in the project. Such a workflow often necessitates the frequent use of Git rebase capabilities, including:

Rebasing the feature branch into a coherent feature chunk.
Rebasing it against the main branch to keep it on top of other changes.
And so on.

Another Git/Git-service feature I appreciate is the ability to sign commits, which UI-wise results in a green "Verified" label on the Git-service's UI. This adds an extra layer of trust regarding the identity of the commit/feature submitter.

Every major Git service provider, including GitLab, BitBucket, and GitHub, supports this workflow. Or do they?

The Problem:

To be honest, GitHub has a issue in this regard. In short, when performing a rebase action in the GitHub UI, it will rewrite your commits, even if the feature branch could be merged without merge commits. This means you will lose your signed verification signature — quite a horror!

Note, Other major platforms will perform the expected fast-forward-only merge in the same case, meaning they won't create any merge commits. This allows you to simply add the commit on top of the main branch, preserving the signature.

This is a known GitHub-problem, as evidenced by discussions at GitHub Community and Stack Overflow.

GitHub has also acknowledged this issue with their platform. It is highlighted in their documentation and has received a response from their support:

This is a known issue we are tracking internally and a pain point for a number of folks....

Currently, reverted pull requests created from a previously squash and merge pull request or a rebase and merge pull request are indeed not signed...

While we don’t yet have a specific ETA for when this might be implemented...

Pain point?! YES!

The Workaround:

So, what can you do? Just follow their advice in their documentation: "A workaround for this is to rebase and merge locally, and then push the changes to the pull request's base branch." Aha, seems easy in words, but how can you translate this into terminal commands?

For example, if you have a pull request that you are ready to merge:

First, fetch the pull request locally by creating a feature branch for it.

git fetch origin pull/<PULL-REQUEST-NUMBER>/head:<NAME-YOU-WANT-THE-PR-BRANCH-TO-HAVE-LOCALLY>

Then, while on your base branch i.e main, merge the locally fetched PR branch into it.

git merge --ff-only <THE-LOCAL-PR-BRANCH>

Finally, push it to the base branch.

git push

GitHub will now close the pull request as merged, and you will have a clean commit history with the signed commit intact.

The Summary:

Is pushing to the main branch a hackish? Yes, but until GitHub fixes this problem, it is the only way and they recommend it in the documentation.

Other

Other Git related articles on DEV from me:
Git signing and signoff like a champ
A clean Git history with Git Rebase and Conventional Commits

A clean Git history with Git Rebase and Conventional Commits

Heapstack — Sun, 12 Mar 2023 19:11:46 +0000

Other Git related articles on DEV from me:
Git signing and signoff like a champ
The "linear-git-commit-history-with-signing-in-github-ui"-workaround

Introduction

As developers we always strive to improve and simplify our processes. One important motivator is less time spent on future guesswork. We also would like that new developers in our projects will be able to quickly focus on their task instead of diving into a mess of lasagna and spaghetti code.
And we all know that the "new developer" is in many cases you, a half year later when you are wondering what the hell you were thinking about many commits earlier.

One part of making life simpler for everyone is by keeping a clean Git history. Now, What is a clean Git History? Well, you can find different opinions on that, but for me (and quite a few projects) a nice Git history:

tells the reader something in an expected understandable way
makes a feature coherent.
makes it easy to revert or cherry pick a feature
tells the reader that the former contributors cared about the project and new contributors

So, caring about your Git history is a well spent investment for your projects, and surely worth the small extra time it might take to learn.

This article will give you a short opinionated lightweight view of how to achieve that.

The basic rules:

The commit that goes into the main (or develop etc) branch should aim to be atomic, aiming to contain only the feature you are working on
While working in your feature branch, your commit messages can look in whatever way you wish: wip and so on. But, the important thing is that when you are done with your feature and ready to go for a Pull Request you first rebase your feature branch and clean up your commits.
The feature commit should have a clear defined message - Don't re-invent here - There exists a fairly used and accepted convention called Conventional Commits, so we are going to use that.

Rebase and avoiding merge commits

Rebasing might sound scary if you are not familiar with it, (overwriting history, yikes?), but it is really not after you got the hang of where to, and how to. It puts your commits on top of whatever you rebase against.

Instead of when you do Pull Requests with merge:

"Merging main into the feature branch" by Atlassian is licensed under CC BY 2.5 AU

You will do this with rebase:

"Rebasing the feature branch onto main" by Atlassian is licensed under CC BY 2.5 AU

And in practice, the history of your commit graph will look like the one to the right, instead of the one to the left:
"Messy left vs linear right" by Unknown is licensed under Unknown

Much cleaner to follow and understand. And, just ignore the commit messages themselves for now - we will improve upon that soon.

Basically you will use rebase in a few different ways.
One is when you pull from the current branch. Always use pull with --rebase flag.

git pull --rebase

Another case is when you pull your changes from main/develop into your feature branch


git rebase --interactive origin/main

(instead of doing git merge )

Finally, the last case is when you squash all your features in your feature branch - before submitting your Pull/Merge-Request.


git rebase --interactive <sha-with-the-commit-you-are-squashing-from>

This article wont go into every detail about learning you how to rebase, as there are many good articles about that already - I recommend that you read more about it in the following links:
Merge vs Rebase
Git Rebasing

And, then practice. Set up a git project and add a few commits, and a branch or two and start experimenting. If you don't try it for real, you will never feel comfortable.

So, now we now how to get a linear, easy to follow Git graph. But if you look at the earlier comparison picture above, there is still much to improve upon regarding the commit messages themselves.

Enter..

Conventional Commits

It is a simple convention that is used in quite a few Open Source projects. I think it originated in the Angular community (not sure here).

The Conventional Commit format looks roughly like this:

<type(optional scope): imperative of what it does

So a practical example message could then look like this:

fix: add a validator for the fluxcapacitor class

But, for the real format read more about Conventional Commits.

The great thing of not re-inventing things like commit message standards is that you

bypass endless organisation and team discussions about how to do things in certain way. Instead you can agree, avoid distractions and focus on the important work - making a good product
make it easier for new people to dive in to the project
can use tools written for that standard - in the case of Conventional Commits, autogenerate changelogs and more.
write better commit messages, as you have to give them a bit of thought

A rebase/conventional commit workflow example in practice

Lets walk through the life of fictional feature branch.

Start: You start your feature-branch from a branch, here main, (but might as well be develop or however you are working with branches).

git switch -c feature/my-branch

working....

taking a long break so

git commit -m 'chore: a commit'

git push -u origin feature/my-branch

working ...

git commit -m 'wip gotta go'

git push

Ah, meanwhile, new features (commits) was added to main by collegue Knuth, so you update your feature branch:


git rebase -i origin/main

back to working...

git commit -m 'docs: last docs update'

git push

Finally, ready to proudly clean up our feature commit history, before submitting a Pull/Merge Request:

git rebase -i <sha-to-latest-commit-before-the-feature-branch>

OR, if you read my article about signoff and signing :) :)


git rebase -i --signoff --gpg-sign <sha-hash-of-the-commit-before the-the-feature-branch>

Now you will enter Git's interactive rebasing mode, which shows a list of the commits (from the hash you choose), and you get a list of options too.

Default 'pick' just takes the commit as is. Most often I do r (reword) for the top commit (oldest) and f (fixup) for the others. f means the commit contents will be squashed into the previous commit, and so we will end up with a single commit that we got the chance to reword. But see the example in next section.

So, With a lot of in work-in-progress commits on the feature-branch, you want to squash every commit with 'f' so there only will be one commit on the end. Except the last one that you want to reword with 'r'.

After saving, you are given the dialouge to reword the commit you choose 'r' for. So just rewrite the commit header message as you please, here as a Conventional Commit:

Finally, after saving, and rebase signals done succesfully, you do a quick sanity check that everythings seems fine and then force push (to the feature branch).


git push --force-with-lease

Done! Oh,,, then you remember - you want to improve your feature commit by adding a detailed description. So you rebase again (the now cleaned up, single commit), and add a description body.

And, as you have rewritten your feature branch history again, you will also need to force push again.

git push --force-with-lease

And cheers - open a Pull Request after verifying everything was fine.

F.A.Q

When should I not rebase?

Never rebase and force push to a public branch without telling everyone first. In other words, only force push to your feature branch. That is a golden rule, because if you do push to common branches, you might overwrite others commits, mess up their forks and, in general create confusion for other developers. However as long as you are in your feature branch, do as you please. There are advanced cases where you want to, or even need to force push to main/develop etc, but that is out scope for this article.

Is rebasing widely used?

When submitting to Open Source projects it is not uncommon to get comments in the style of "looks fine, but please rebase your feature branch into one feature",

What is the --force-with-lease good for?

If you force push, make a habit of using --force-with-lease option instead of --force, for a bit of extra safety - it will stop you from overwriting other peoples eventual added changes and stop the push.

Should I always add a Git description?

You be the judge, but for big or hard to understand features, please take the care to add a longer description (body) besides the header message.

Should I sign and signoff commits?

Yes, why not really? See Sign and signoff your feature commits

How can I enforce this in GitLab?

To enforce a linear history in GitLab UI:

How can I enforce this in GitHub?

To enforce a linear history in GitHub UI:

But, if you also sign your commits - Sadly Rebase with UI is broken in GitHub, and you will lose your signature. There is a simple CLI workaround, read more under the F.A.Q in this article for a workaround hint.

Can I reuse this information?
All content in this article is licensed under the CC0 if not stated otherwise. Which means, use as you please, no need for any attribution. Please add suggestions and corrections if I mixed up something, or that you feel something important is missing.

Git signoff and signing like a champ

Heapstack — Thu, 16 Feb 2023 18:10:53 +0000

Introduction

Signing and sign-off your Git commits for improved security, contributions assurance and contributor history? What's not to like? Well, Let's jump right in.

Why?: Summarized as short and simple as possible

Git Sign-off is a de facto standard way in the Open Source communities about ensuring to the project you are contributing to that _you _have the right to submit your content. Often together with an note in the projects CONTRIBUTING.md, that you agree to the DCO-standard by doing a sign-off (see the F.A.Q for a short summary of the DCO). Also, Sign-off's helps improving the git history tracking of whom submitted what.
Git Signing adds an extra layer of trust regarding your commits.

So, in essence, they are solutions to different problems, to increase your project security, trust, and traceability. It is easy to mix up their names (and their short flags versions -s vs -S:) but they are different concepts. Both have fairly good support in modern versions of Git Services like for example GitLab and GitHub.

Are they cumbersome to configure?: No, as we will see. Configure once and mostly forget about it!

How do they work in practice?: Basically: Sign-off adds an extra comment to your commits - "you sign them off"!

Sign-off example :

$ git log


........

feat: add a test for the superservice

Signed-off-by: Heap Stacksson <heap.stacksson@example.com>

Signing then. Well, as you might expect, it signs your commits cryptographically (by gpg- or ssh-key):

Signing example:

$ git log --show-signature 

<commit f3974852488dde8b4cd087d5b5a27817d3358777 (HEAD -> feature/show-sign-example, tag: 300.0.1)
Good "git" signature for heap.stacksson@example.com with ED25519 key SHA256:ABCToTLNtOKINCIuFYusrK+ohNbr5R4V9igTmCqciN4
Author: Heap Stacksson <heap.stacksson@example.com>
Date: Thu Feb 29 04:36:44 2024 +0100
feat: add a test for the superservice

Signed-off-by: Heap Stacksson <heap.stacksson@example.com>

and as mentioned, the common Git services have pretty good support for these methods. Here is an example from GitHub for how signing is implemented visually:

Set up Git Sign-off

Add the -s or the --signoff flag to your commits:

$ git commit --signoff -m 'chore: this commit will be signoff:ed'

Set up Git Signing (before Git version 2.34.0, with GPG-key)

If your Git version is less than 2.34.0 (or if you just prefer GPG-signing anyway) you need to supply a gpg-key for signing.

$ git --version

There are many articles on how to generate and add a gpg-key to your hosted Git service, so I will leave that part to you (See, for example GitLab's excellent guide):

Add the -S or the --gpg-sign flag to your commits:

$ git commit --gpg-sign -m 'chore: this will sign your commit'

And for signing tags:

$ git tag -s thetag

Set up Git Signing (Git version 2.34.0++, with ssh-key)

Git introduced signing with ssh-keys from 2.34.0 and upwards. This simplifies life, as you most likely already have a ssh-key for your Git chores, and don't need to keep track of an extra gpg-key.
The ssh feature also needs a fairly modern openssh version,8.8++, and finally, for visual candy, a fairly modern instance of GitLab etc, (cloud GitHub already supports this visually) so that your signatures are visually shown.
Note: Using gpg-keys after Git 2.34.0 is still perfectly fine.

Configure git to use ssh-key for signing instead of gpg:

$ git config --global gpg.format ssh

Give it your public ssh-key, inline or filepath:

$ git config --global user.signingKey 'path/to/yourkey.pub'

SSH has no web-of-trust as gpg has, so you will also need to add an allowedSigners file where you add public signatures you trust, including your own. Otherwise verifying signatures will fail.

$ touch ~/.config/git/allowed_signers
$ git config --global gpg.ssh.allowedSignersFile "$HOME/.config/git/allowed_signers"

Make sure to add your own public ssh-key to this (and your collborators- creating a repo of team public keys for sharing might be a good idea).

Example

$ cat ~/.config/git/allowed_signers

..keys
heap.stacksson@example.com asdfas4949494949adfasfAAAAFASDFASDFSAD9939

Add an Git alias for signoff and signing or configure a global "always sign"

And by using signoff and signing without an alias, you will forget to add them at times:). Therefore, I highly recommend that you add an git alias so that you can mostly forget about this:

$ git config --global alias.cs commit --signoff --gpg-sign
$ git cs -m 'chore: this commit will be signed off and signed even though I forgot to set the flags'

Alternatively, You could also configure the global Git configuration to make it "always sign" instead of an alias for you. This is how you would do it, including "always sign tags".

$ git config --global commit.gpgsign true
$ git config --global tag.gpgsign true
$ git config --global user.signingkey <KEY ID> --see for example https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/#create-a-gpg-key

But, you will still need a alias for the signoff feature (a global Git configuration to always signoff is not supported by git).

$ git config --global alias.cs commit --signoff
$ git cs -m 'chore: this commit will be signed-off and signed even though I forgot to set the flags'

F.A.Q

I get an error, "failed to sign commit in my shell"?

You might need to set the GPG_TTY env var

 export GPG_TTY=$TTY

Should I use GPG or SSH-signing?

Both have pro's cons so it is up to you - for example, - ssh-key might be easier to configure (no need for extra gpg-key handling, you might already have an ssh-key setup for git needs), but then you need to share the public ssh keys in the mentioned allowed_signatures, to be able to verify. The sharing part is easily handled if using gpg, by uploading the public key to an public key server.
Also, with ssh, if using older GitLab versions, you are going to miss out on the visual support for this. And it won't work with older git/openssh-combos if you are stuck with old development environments/versions.

My nice verification signature disappeared when merging/squashing etc in GitLab/GitHub GUI?

Depending on your workflow, Git platform/PR-strategy and merge configuration there might be caveats. There are certainly room for improvements here from GitHub, GitLab and others.

Some Links about different takes:
GitHub Discussion about GitHubs Rebase Strategy (a bit broken, GitLabs works better here
General about signing with gpg
How to squash/merge via CLI

How can I rebase and with Sign/Signoff?

The git rebase command supports this usecase:

$ git rebase -i --signoff --gpg-sign <your sha that you are rebasing from>

What is the DCO mentioned regarding signoffs?

_The meaning of a signoff depends on the project, but it typically certifies that the committer has the rights to submit this work under the same license (as the project) and agrees to a Developer Certificate of Origin (see https://developercertificate.org for more information).
_

So, make sure to add something about agreeing to the DCO by Sign-off in your CONTRIBUTING.md, if that applies for your project.

My nice green verified button disappered on GitHub when I choose Rebase on Pull Request with signed commits, with the WebUI

Rebase from the Web-UI on GitHub is broken. Instead of the expected behaviour (as in Git, GitLab, BitBucket and other providers), it always rewrites the hashes, and your nice verified signature is gone. That means you currently cant keep a linear Git history with signed commits and Rebase. However a CLI workaround is to do as described in the Stack Overflow Question here.
I left a bug report and got this answer "I'm afraid this is a known issue we are tracking internally and a pain point for a number of folks. ... While we don’t yet have a specific ETA for when this might be implemented..

Various interesting links
More about about SSH signing
Stack Overflow: What is the Signoff for?

All content in this article is licensed under the CC0 if not stated otherwise. Please add suggestions and corrections if I mixed up something, or that you feel something important is missing.