Feeds

Whenever a large corporation disgorges the personal information of millions of people onto the Internet, there is a standard playbook that is followed.

“Security is our top priority”.

“Passwords were hashed”.

“No credit card numbers were disclosed”.

record scratch

Let’s talk about that last one a bit.

A Case Study

This post could have been written any time in the past… well, decade or so, really. But the trigger for my sitting down and writing this post is the recent breach of wallet-finding and criminal-harassment-enablement platform Tile. As reported by Engadget, a statement attributed to Life360 CEO Chris Hulls says

The potentially impacted data consists of information such as names, addresses, email addresses, phone numbers, and Tile device identification numbers.

But don’t worry though; even though your home address is now public information

It does not include more sensitive information, such as credit card numbers

Aaaaaand here is where I get salty.

Why Credit Card Numbers Don’t Matter

Describing credit card numbers as “more sensitive information” is somewhere between disingenuous and a flat-out lie. It was probably included in the statement because it’s part of the standard playbook. Why is it part of the playbook, though?

Not being a disaster comms specialist, I can’t say for sure, but my hunch is that the post-breach playbook includes this line because (a) credit cards are less commonly breached these days (more on that later), and (b) it’s a way to insinuate that “all your financial data is safe, no need to worry” without having to say that (because that statement would absolutely be a lie).

The thing that not nearly enough people realise about credit card numbers is:

1. The credit card holder is not usually liable for most fraud done via credit card numbers; and

2. In terms of actual, long-term damage to individuals, credit card fraud barely rates a mention. Identity fraud, Business Email Compromise, extortion, and all manner of other unpleasantness is far more damaging to individuals.

Why Credit Card Numbers Do Matter

Losing credit card numbers in a data breach is a huge deal – but not for the users of the breached platform. Instead, it’s a problem for the company that got breached.

See, going back some years now, there was a wave of huge credit card data breaches. If you’ve been around a while, names like Target and Heartland will bring back some memories.

Because these breaches cost issuing banks and card brands a lot of money, the Payment Card Industry Security Standards Council (PCI-SSC) and the rest of the ecosystem went full goblin mode. Now, if you lose credit card numbers in bulk, it will cost you big. Massive fines for breaches (typically levied by the card brands via the acquiring bank), increased transaction fees, and even the Credit Card Death Penalty (being banned from charging credit cards), are all very big sticks.

Now Comes the Finding Out

In news that should not be surprising, when there are actual consequences for failing to do something, companies take the problem seriously. Which is why “no credit card numbers were disclosed” is such an interesting statement.

Consider why no credit card numbers were disclosed. It’s not that credit card numbers aren’t valuable to criminals – because they are. Instead, it’s because the company took steps to properly secure the credit card data.

Next, you’ll start to consider why, if the credit card numbers were secured, why wasn’t the personal information that did get disclosed similarly secured? Information that is far more damaging to the individuals to whom that information relates than credit card numbers.

The only logical answer is that it wasn’t deemed financially beneficial to the company to secure that data. The consequences of disclosure for that information isn’t felt by the company which was breached. Instead, it’s felt by the individuals who have to spend weeks of their life cleaning up from identity fraud committed against them. It’s felt by the victim of intimate partner violence whose new address is found in a data dump, letting their ex find them again.

Until there are real, actual consequences for the companies which hemorrhage our personal data (preferably ones that have “percentage of global revenue” at the end), data breaches will continue to happen. Not because they’re inevitable – because as credit card numbers show, data can be secured – but because there’s no incentive for companies to prevent our personal data from being handed over to whoever comes along.

Support my Salt

My salty takes are powered by refreshing beverages. If you’d like to see more of the same, buy me one.

Two independent bachelor theses bring new privacy-focused features to GNU Taler. Christian Blättler designed and implemented token-based subscriptions and discounts in Taler, while Lukas Matyja and Johannes Casaburi's thesis introduces the Donau system, a new type of a donation authority system.

Data structures, like variables, contain references to objects, rather than the objects themselves.

Table of contents

1. Referencing the same object in multiple places
2. Data structures store references, not objects
3. Avoid referencing the same mutable object
4. An ouroboros: A list that contains itself
5. Python's data structures contain pointers to objects

Referencing the same object in multiple places

Let's point a variable row to a list of three zeroes:

>>> row = [0, 0, 0]

Now let's make a new variable that points to a list-of-lists:

>>> boat = [row, row, row]

We now have a list of three lists, each with three zeroes in it:

>>> boat [[0, 0, 0], [0, 0, 0], [0, 0, 0]]

What would happen if we look up index 1, and then index 1 again, and change that to the number 1?

>>> boat[1][1] = 1

What do you think might happen? What will change in our lists?

We're looking up the second list, and then the second value in the second list, and assigning that value to 1. So we've asked to change the middle item in the middle list to the number 1.

That's not quite what happens though:

>>> boat [[0, 1, 0], [0, 1, 0], [0, 1, 0]]

Instead, we changed the middle number in all three of our inner lists.

Why did this happen?

Well...

Data structures store references, not objects

Lists in Python don't actually …

Read the full article: https://www.pythonmorsels.com/data-structures-contain-pointers/

Here's what I've been working on for my LocalGov Drupal contributions this week. Thanks to Big Blue Door for sponsoring the time to work on these.

Montreal is set to host Evolve Drupal tomorrow, a premier event dedicated to the ever-evolving world of Drupal. With over 30 talks spread across three tracks—Digital, Tech, and Design Summit—attendees will have the opportunity to delve into the future of web development, gain wisdom from past projects, expand their professional networks, and grow as a vibrant community of professionals.

Hi! It has been over two weeks since the coding period began. In this blog post, I will provide a brief summary of my work during the first two weeks.

After spending some time reviewing the code, I decided to start by refactoring the existing code related to ASS format subtitles. This has two main goals: first, to enable Kdenlive to read as much information as possible from ASS subtitles (specifically, the features supported by libass) and load it into the memory; and second, to ensure that Kdenlive can save all this information back to the file. Since SubtitleModel already contains a significant amount of code for ASS format subtitles, my work mainly involved refining and expanding upon this existing code while maintaining compatibility.

So far, I have accomplished the following:

• Added initial support for reading and saving embedded fonts in ASS subtitles
• Optimized the storage method for subtitle styles
• Migrated from V4Style to V4+Style

Tasks still to be completed:

• Modify m_subtitleList to accommodate more information.
• Write unit tests for each feature

Once these steps are completed, we will have more comprehensive support for ASS format subtitles, marking the end of this phase of the ASS code refactoring. The next focus will be on refactoring the functionality for modifying subtitle styles. These two parts will be my primary focus for the next two weeks. Stay tuned!

A strange fact recently came into my purview – many users and developers don’t know what Open Source is.

Some time ago, there was a controversy regarding the Floorp web browser (a fork of Firefox) going closed source.

The cause for this was that some company forked Floorp and made a browser based on it. I’ll not comment on the irony that the author of a fork of a project complained that someone forked his project.

Obviously, this triggered a storm of negative reactions on quite a few platforms where fans of Free Software / Open Source software hang out.

The developer responded that this is just temporary, and that the browser will soon be Open Source again. After a while, the repositories became public again and all was fine.

The developer said that Floorp is again Open Source, the angry mob said good, the Floorp browser is again Open Source. And every discussion about Floorp got a plethora of comments that people should stop complaining, that Floorp is Open Source, and that the previous situation was just a misunderstanding.

Open Source

The term Open Source is well defined at opensource.org.

Making the source code of a program publicly available is not enough for something to be Open Source. Having an army of people saying that something is Open Source, is not enough for something to be Open Source.

If a license that the code is published under doesn’t conform to the criteria published on opensource.org, a program is not Open Source. A program whose license contains the following sentence, is, by definition, not Open Source:

You may not use or distribute this Software or any derivative works in any form for commercial purposes. Examples of commercial purposes would be running business operations, licensing, leasing, or selling the Software, or distributing the Software for use with commercial products.

– Floorp private components/LICENSE

This is strangely worded as it looks like you can not use the Floorp web browser to access, for example, a work e-mail account as that would be using it for commercial purposes. This is likely not what the license author intended – the intent of the license is to disallow creating commercial products by forking Floorp.

While it is a valid desire of the author not to have somebody else profit from his work, it is the thing that makes the Floorp web browser not Open Source.

You can call it ‘source available’, you can call it ‘fair code’ but you can not call it Open Source.

Update: A few days after this blog was published, Floorp moved the code from the private submodule to the main repository. So, it should be again Open Source. Let’s hope it remains like that.

Redefining Open Source

This blog post should have been written when the Floorp thing happened, but I thought this is just a random incident not worth the extra attention.

It seems I was wrong. It is something that people should start paying attention to.

A lot of people – developers and users alike, intentionally or not – misuse the term Open Source, and some of them like FUTO even go that far to redefine it and create their own incompatible The Open Source Definition that will suit their own purpose.

Open Source Confusion Cases

Now, the main purpose of this post isn’t for me to let off some steam, but to share a great project started by Dan Brown of attempting to find and list all projects which claim to be Open Source while their licenses say otherwise.

It can be found on his Github account.

Share your views to FSFE

Albert pointed out that FSFE is also interested in this topic:

The FSFE is looking for examples and thoughts about openwashing if you feel like it I’m sure they’ll welcome your input mastodon.social/@johas/112524760073638652 You can support my work on Patreon, or you can get my book Functional Programming in C++ at Manning if you're into that sort of thing. -->

A strange fact recently came into my purview – many users and developers don’t know what Open Source is.

Some time ago, there was a controversy regarding the Floorp web browser (a fork of Firefox) going closed source.

The cause for this was that some company forked Floorp and made a browser based on it. I’ll not comment on the irony that the author of a fork of a project complained that someone forked his project.

Obviously, this triggered a storm of negative reactions on quite a few platforms where fans of Free Software / Open Source software hang out.

The developer responded that this is just temporary, and that the browser will soon be Open Source again. After a while, the repositories became public again and all was fine.

The developer said that Floorp is again Open Source, the angry mob said good, the Floorp browser is again Open Source. And every discussion about Floorp got a plethora of comments that people should stop complaining, that Floorp is Open Source, and that the previous situation was just a misunderstanding.

Open Source

The term Open Source is well defined at opensource.org.

Making the source code of a program publicly available is not enough for something to be Open Source. Having an army of people saying that something is Open Source, is not enough for something to be Open Source.

If a license that the code is published under doesn’t conform to the criteria published on opensource.org, a program is not Open Source. A program whose license contains the following sentence, is, by definition, not Open Source:

You may not use or distribute this Software or any derivative works in any form for commercial purposes. Examples of commercial purposes would be running business operations, licensing, leasing, or selling the Software, or distributing the Software for use with commercial products.

– Floorp private components/LICENSE

This is strangely worded as it looks like you can not use the Floorp web browser to access, for example, a work e-mail account as that would be using it for commercial purposes. This is likely not what the license author intended – the intent of the license is to disallow creating commercial products by forking Floorp.

While it is a valid desire of the author not to have somebody else profit from his work, it is the thing that makes the Floorp web browser not Open Source.

You can call it ‘source available’, you can call it ‘fair code’ but you can not call it Open Source.

Redefining Open Source

This blog post should have been written when the Floorp thing happened, but I thought this is just a random incident not worth the extra attention.

It seems I was wrong. It is something that people should start paying attention to.

A lot of people – developers and users alike, intentionally or not – misuse the term Open Source, and some of them like FUTO even go that far to redefine it and create their own incompatible The Open Source Definition that will suit their own purpose.

Open Source Confusion Cases

Now, the main purpose of this post isn’t for me to let off some steam, but to share a great project started by Dan Brown of attempting to find and list all projects which claim to be Open Source while their licenses say otherwise.

It can be found on his Github account.

You can support my work on Patreon, or you can get my book Functional Programming in C++ at Manning if you're into that sort of thing. -->

This year, as part of our annual election process, the Python Software Foundation Board is offering three bylaws changes for our Members to vote on. These changes are all centered on our membership experience: making it simpler to qualify as a Member for Python-related volunteer work, making it easier to vote, and allowing the Board more options to keep our membership safe and enforce the Code of Conduct.

Voting Members will be asked to vote on these items during the July Board of Directors election. If the majority of voting members vote in favor of any of the changes, those changes will be incorporated into the bylaws and go into immediate effect.

We're sharing these changes with you today as an opportunity to understand why these changes are being proposed, and to give you an opportunity to ask questions of the Board before you vote, either by emailing psf-elections@pyfound.org or membership-wg@pyfound.org, or by responding to the thread on the PSF discussions site.

The text of the changes are available from the following links, all of which show visual representations of additions and deletions to our canonical bylaws repository:

• Change 1: Merging Contributing and Managing member classes
• Change 2: Simplifying the voter affirmation process by treating past voting activity as intent to continue voting
• Change 3: Allow for removal of Fellows by a Board vote in response to Code of Conduct violations, removing the need for a vote of the membership

The Board has carefully considered these changes and strongly encourages all Members to vote in favor of them. The rest of this post explains the changes, and why we're putting them to our Voting Members.

Change 1: Merging Contributing and Managing member classes

Since 2017, when we adopted our current membership model, we've had four classes of membership: Supporting (recognition for being a monetary donor), Managing (recognition for volunteer work in the PSF or in community events), Contributing (recognition for volunteer work on open source software), and Fellow (recognition of long-term service to the mission of the PSF).

For almost as long as our membership options have existed, there's been confusion about the distinction between Managing and Contributing members. Both require 5 hours a month of volunteer service, but the distinction between community work and work on software is increasingly out of step with how our community thinks about contributing.

In the future, we want community members to qualify for PSF membership by participating and giving back to the community, either through donating, through volunteer work, or in recognition of long service, without distinguishing between code contributions and non-code contributions.

With this proposed bylaws change, we would merge the Managing and Contributing membership classes. All Managing Members would become Contributing Members, and we would no longer have a Managing Member class. Further, this change would explicitly allow for works of authorship (including documentation, books, or blogs) beyond software to count as volunteer work, provided those works are openly licensed.

We think this would significantly simplify the membership categories, reduce confusion, and make it easier for volunteers who both run events and write code to decide which membership class best applies to them.

Change 2: Simplifying the voter affirmation process by treating past voting activity as intent to continue voting

Our bylaws (section 4.2) require every Member to affirm their intention to vote in an election before they can be issued a ballot. This is intended to ensure that our election reaches a quorum (i.e. one third of ballots issued are actually used to vote), and is therefore valid by our bylaws. Due to technical limitations, we only started requiring this affirmation in practice last year. Since then, we've received feedback that the affirmation process has unintentionally excluded some people who had intended to vote.

It is the Board's intention that we make it as easy as possible to vote in our elections, however, we must balance legal obligations that require us to maintain a quorum in our elections.

This bylaws change would allow us to treat any member who voted in the immediately previous year's election as having affirmed their intention to vote. The Board believes that voting in a PSF election is a good indicator that a member is likely to vote again, and including them in the quorum calculation is unlikely to put our quorum at risk.

While there may be technical limitations to us implementing this change, the change is necessary to allow the Foundation to alter the affirmation procedure at all. It is the Board's intention that this change would be implemented for the 2025 election should the Bylaws change be accepted by the membership during the 2024 election.

Change 3: Allow for removal of Fellows by a Board vote in response to Code of Conduct violations, removing the need for a vote of the membership

Currently PSF Fellows are awarded membership for life, as a reward for exceptional service to the mission of the Foundation. There are deliberately very few ways to remove a Fellow from the membership.

If a Fellow were found to have violated the Foundation's Code of Conduct in a way that warranted termination of their membership, currently the only way to remove them would be to put their removal to a vote of all Voting Members (per section 4.15 of our Bylaws). We believe that requiring a vote of the membership to remove a Code of Conduct violator from our community would subject members of the community --- including people directly impacted by that violator's behavior --- to undue distress.

On the other hand, we believe there is significant legal risk that could arise from Code of Conduct violators known to the PSF using their status as a PSF Fellow to enhance their reputation. In cases where the Foundation needs to act in order to continue being able to serve the Python community effectively, we currently have no choice but to name a known Code of Conduct violator as part of a vote put to the membership.

In practice, this requirement limits our ability to effectively enforce our Code of Conduct. This is a disservice to our community.

This proposed change gives the Board, by a majority vote, the ability to terminate the membership of a Fellow as a consequence of breaching any written policy of the Foundation, specifically including our Code of Conduct. This change would allow the Board to act in cases where there is a clear need for a problematic community member to no longer be affiliated with the Foundation, without further perpetuating the trauma caused by that community member's actions.

Adapted from: https://www.sitback.com.au/insights/article/working-with-javascript-in-d...

As far as I understand it, community initiatives exist because enough people say they’re interested and start working towards the initiative’s goals.

So I thought I would try starting an initiative to solve a problem I see pop up fairly regularly:

• https://www.drupal.org/project/drupal/issues/2873160
• https://www.drupal.org/project/drupal/issues/3198417
• https://drupal.slack.com/archives/C1BMUQ9U6/p1709942944844569
• https://drupal.slack.com/archives/C392CHBEW/p1686752209783039?thread_ts=1686733842.704469&cid=C392CHBEW
• and so on.

Basically: why isn’t there a standard way to install javascript dependencies?

Some modules have tried asset-packagist, but there are myriad problems with that:

• https://drupal.slack.com/archives/C1BMUQ9U6/p1709966024383969?thread_ts=1709942944.844569&cid=C1BMUQ9U6
• https://drupal.slack.com/archives/C392CHBEW/p1709810122839269

I had a whinge about it in #australia-nz: https://drupal.slack.com/archives/C45SW3FLM/p1712295645835869 and took up larowlan’s generous offer to try to get a new initiative this off the ground.

He introduced me to Théodore (@nod_) the frontend framework manager and we three had a short discussion around suitable directions to take. This initiative would not be happening without their help and guidance, thank you so much Lee and Théodore 🙇‍♂️

We explored the idea of using import-maps to let the browser handle module imports and agreed that the cascading downloads would be an unacceptable performance burden on non-admin pages.

The result of that meeting was the idea of trying out publishing Drupal modules on npm, or at least an npm-like repository, since @larowlan mentioned that GitLab can provide one. I got started and wrote some scripts for gathering package names and putting them in a central package.json to be downloaded by npm/yarn/whatever.

Then @larowlan pointed out https://github.com/php-forge/foxy which I had seen, but didn’t really understand the power of. What I didn’t understand was that you could define a package.json file inside a composer package, make a couple of tweaks to composer.json and without publishing any kind of npm package, foxy would find it and treat it like one.

Cue a couple of weeks of messing around with foxy, composer and vite, and I have created a working prototype for compiling multiple Drupal modules (including custom modules if desired) in a project, and routing the library system to the new entry points:

https://github.com/darvanen/drupal-js

It requires a few things:

Any module that wants to opt in:

• Adds php-forge/foxy to require or require-dev in composer.json.

• Adds a module-name.foxy.yml file to represent the library state when using foxy.

Site builders:

• Have one or more modules that use foxy in their project

• Require and enable drupal/foxy

• Add a provided vite.config.js to their project (could this be done by the foxy module?)

• Set up a way to run vite build (or their own implementation):

  • post-install/update commands

  • pipeline?

  • manually?

—

This is where you come in

The prototype is just a starting point. I want us to come together to define a new way of working with JavaScript in Drupal that everyone can and will want to use, similar to how drupal-composer/drupal-project pioneered effective usage of composer and was eventually adopted by core. I intend to keep working on this but I want it to be driven by the community, hence the initiative.

Things you can do right now:

• Spread the word, recruit more people to the initiative, especially if they maintain a module with JS dependencies.

• Try out the prototype and give feedback - no change is too big to explore.

• Join the #frontend-bundler-initiative channel to chat about ways forward - bikeshedding is welcome here, we used to call that brainstorming ;)

• If you have a module with JS dependencies: speak up to have your module included in the prototype, or make a PR.

• Contribute to the foxy module to get it to import css/image/asset dependencies from the vite manifest

So what do you say, are you in?- come join me in the channel!

Transition your Drupal 7 site to Drupal 10 with ease using the automated migration approach. This latest article from our comprehensive migration guide walks you through configuring the Drupal 10 site, enabling migration modules, and utilizing the Migrate Drupal UI for a smooth transition. Are you ready?

Read more mauricio Thu, 06/13/2024 - 06:37

For some time now, Debian has been discussing a possible enhancement to the way that Debian packages are uploaded to the archive. The basic idea is to allow a package upload to be triggered by pushing a signed tag, with some structured metadata, to Salsa, the instance of GitLab that Debian provides for packaging repositories. This would allow Debian package maintainers to use a more typical Git-first workflow, where releases are triggered by Git tags and the release artifacts are built in a clean CI environment, while still enforcing the existing Debian rules about who is allowed to upload packages.

As part of that effort, I recently completed a detailed security review of the tag2upload design. I sent it to debian-vote as part of the ongoing discussion, but have also posted it at the link above to give it a more permanent home.

This security review may be revised based on the discussion if people point out things that I missed.

In this episode, we welcome Will Vincent to the Python Show Podcast. Will has written several books on Django.

We chatted about all things Django and Python. Specifically, we covered the following topics:

• Favorite Python packages

• Podcasts

• Content creation

• Book writing

• Why Django versus another web framework

• AI and writing

• and more!

Links

• Follow Will on Mastodon

• Check out Will’s work on GitHub

• Learn Django with Will

• Will Vincent’s personal website

• Django News newsletter

• Django Chat podcast

• django-microframework

As promised in the last post, I have now orphaned the Pagure Debian package. Here’s the full text I posted on the BTS:

After several years, I finally decided to orphan pagure :-(.

I haven’t been using it as my personal forge anymore, and unfortunately upstream development slowed down quite a bit after the main author and maintainer stopped contributing regularly to the project. But that is not to say that upstream is dead; they are still working towards preparing the next release.

Pagure is a big package with several components and an extensive list of build dependencies (and an even bigger testsuite which I never managed to make fully work on Debian). It is not for the faint of heart, and most of the time is usually spent fixing its (build) dependencies so that it doesn’t get removed from testing.

If I may, I would like to leave some suggestions for a future maintainer.

• I never had the time to write dep8 tests, mainly because setting up the software is not trivial. It would be great if the package had more Debian-centric testing.

• Speaking of the hurdles to setting up Pagure, I believe the package installation could be made a bit more automated using debconf. I don’t see a way to fully automate it (look at d/README.Debian), but there is certainly room for improvement.

I also left a brief TODO list inside d/README.source; feel free to tackle any item there!

I wish the next maintainer can have as much fun with the package as I did when I first made it for Debian!

Thank you,

That’s it. It was while it lasted, but I needed to feel myself unburdened so that I don’t have that constant feeling of “I should be properly maintaining this package…”.

If you feel like you’d like to give it a try at maintaining Pagure, now is the time!

n this session, we will explore how to use Python to enhance your AI projects with:

PyCon US 2024 as Security Developer-in-Residence About • Blog • Newsletter • Links PyCon US 2024 as Security Developer-in-Residence

Published 2024-06-13 by Seth Larson
Reading time: minutes

This critical role would not be possible without funding from the Alpha-Omega project. Massive thank-you to Alpha-Omega for investing in the security of the Python ecosystem!

This was my first PyCon US as the Security Developer-in-Residence. I accepted the offer shortly after PyCon US 2023, where Deb Nicholson provided an exciting cliffhanger that the PSF was close to making a hiring decision for the role during the PSF update.

The timing of my hiring to coincide with PyCon US is quite the unique opportunity, it means I get to share all the things we've been able to accomplish together in the past year all-together in person. This also means I get to share the road ahead and learn from many people I don't get to see on a day-to-day, like maintainers of projects large and small, software users at organizations and companies, and users whose work extends beyond software like scientists and industrial control systems operators.

Overall I think this yearly cadence couldn't be better, I'm already looking forward to what I'll be able to share at PyCon US 2025 back in Pittsburgh. As I've said in the past, this role wouldn't be effective without the support of the community, so I want to thank you all for the parts you've played in me being successful.

State of Python Supply Chain Security with Alpha Omega

Alpha Omega is a sponsor of the Python Software Foundation, specifically for my role! Alpha Omega's goal is to "improve global software supply chain security by partnering with open source". I presented alongside Alpha Omega's co-founder Michael Winser. The slides for our presentation are available online.

Alpha Omega uses a two-pronged approach, and it's right there in the name: Alpha and Omega:

• Alpha: Improve the security posture of the most critical projects through staffing.
• Omega: Automated security analysis, metrics, and remediation for wider range of projects.

My role is full-time staffing, so is in the "Alpha" bucket of funding.

Speaking for Alpha Omega on the state of Python supply chain security

For readers of my blog, lots of the content of the presentation is review, but I went over the following accomplishments for the first year of the role:

• Python Software Foundation as a CVE Numbering Authority (and how we helped Linux, curl, and others with a guide).
• Joining Python Security Response Team and working on process
• Working with Python release managers to move the release process to GitHub Actions as an isolated build environment.
• Build reproducibility for the Python release process.
• Software Bill-of-Materials for Python release artifacts.
• Coordinated cross-ecosystem response to libwebp and xz-utils vulnerabilities.
• Tons of community work: PEP reviewer, talks, blogs, and more.

The more interesting part for existing readers is my plans for next year. My plan is to partially shift focus, continue working with Python core developer team of course, but to start making improvements to the wider community of projects using Python as well:

• Enabling Build Provenance and Software Bill-of-Materials for Python packages.
• Adoption of security features, hardening, and best practices for Python packages.
• Special focus on Python packaging tools and workflows.

I finished the talk by describing the unique nature of this role as being flexible and how that's a boon for the rapidly changing space of software supply chain security. This role has a fairly wide scoping, which means that when things come up (like xz-utils and novel social-engineering techniques) it's in this role's scope to think about how to respond for the Python ecosystem.

“Vuln Together”, an open space on vulnerability management

“Got vulns? Let's talk!” -- I co-hosted this open space with GitHub Security champion and CVE board member Madison Oliver. This open space focused on the soft-side of vulnerability management for open source projects: people!

Managing vulnerabilities for open source projects is a non-trivial and effort intensive process, because maintainers need to create and publish a security policy, accept private vulnerability reports, and then know what reporters need, request a CVE ID, know how to estimate severity and write an advisory text, and then how to publish an advisory alongside fixed versions. Phew!

Madison and I pictured holding the open space card for “Vuln Together”

The open space was a forum to discuss difficulties with managing vulnerabilities, answering questions, and pointing folks at resources. We shared recommendations like how maintainers can easily request CVEs from GitHub, enable Private Vulnerability Reporting on GitHub and Confidential Issues on GitLab to make reporting easier, and showed resources like the Guide for Vulnerability Disclosure Process from the OpenSSF Vulnerability Disclosures working group.

The open space was well attended!

Language Summit discussion on CPython security

My bingo space for "xz" was almost immediately filled at PyCon US when I attended the Python Language Summit as the blogger. Release manager and core developer Pablo Galindo Salgado spoke about the Python contribution security model in "the wake of xz-utils backdoor".

The complete language summit blog posts are coming soon to the Python Software Foundation blog (I should know, I authored them!) so if you're interested in this topic you can stay tuned over there. I won't spoil any of the contents of the blog post here, but it was a great discussion all around. Lots of interesting ideas and thoughts from core developers that'll help with figuring process improvements that work for CPython.

Meeting all the people

Mike Fiedler and I were on the stage briefly after Kate Chapman's keynote for a "Meet the Python Software Foundation Security Engineers" segment where we went over our plans for the upcoming year and recommended folks to follow the PSF and PyPI blogs for future updates.

Of course, I got to talk to so many people, too many to name individually. I chatted with the upcoming Release Manager for CPython, Hugo van Kemenade, on some ideas to further improve the CPython release process, specifically around signatures. I chatted with folks from specific sub-ecosystems like Jannis Leidel from Conda and Jazzband, David Lord from Flask, and Jarek Potiuk from Airflow.

Also I handed out stickers! I went through over a hundred, it brought me a lot of joy seeing how much folks liked the derpy snake knight design.

... and beyond!

PyCon US 2024 is the start of conferences this year for me. Shortly after PyCon US it was announced that I will be keynoting PyCon Taiwan in September and also speaking at All Things Open 2024 in Raleigh, North Carolina. If you're attending either of these events get in contact with me (and I promise to bring stickers).

That's all for this post! 👋 If you're interested in more you can read the previous report.

Thanks for reading! ♡ Did you find this article helpful and want more content like it? Get notified of new posts by subscribing to the RSS feed or the email newsletter.

This work is licensed under CC BY-SA 4.0

Over 180 individual programs plus dozens of programmer libraries and feature plugins are released simultaneously as part of KDE Gear.

Today they all get new bugfix source releases with updated translations, including:

• elisa: Fix DBus service activation (Commit, fixes bug #487905)
• kcalc: Handle certain expressions correctly (Commit, fixes bug #487614)
• kcolorpicker: Allow picking the screen color with Wayland (Commit, fixes bug #479406)

Distro and app store packagers should update their application packages.

• 24.05 release notes for information on tarballs and known issues.
• Package download wiki page
• 24.05.1 source info page
• 24.05.1 full changelog

For FreeBSD packaging (writing “ports”, as it is called), I usually just build on my host system – either in the actual host, or with poudriere – and call it a day. If it compiles on amd64 then it should work everywhere, right? (After all, “all the world’s a VAX”)

No exciting software engineering here, BTW, just a “here’s how I set up some infrastructure to help me build ports locally in various environments.”

I have recently finally fixed the build of Sayonara, an audio player that I quite like, on amd64. It still fails on i386, though, because of a mismatch between GStreamer integer sizes and host integer sizes, where the code on the Sayonara size assumes they are the same. Gladly, 32-bit code is rarely built and tested these days, but it keeps spamming me with build failures. So I set out to fix it with an i386 VM running FreeBSD 13.2 i386.

What I wanted to do was use the ports tree from my host – it is a git checkout of the upstream FreeBSD ports tree – and clone it into my VM. Then I can do packaging fixes on the host, commit them locally, update the checkout in the VM and test the packaging fixes there, too. I want to keep those commits local so that I don’t pollute the global upstream repo with a ton of “maybe this works” kind of commits. Once I’m done, I can squash it down to one commit and push, fixing the build for once and for all (ha!).

So, serve up a git checkout to some remote. It’s remarkably simple (as long as StackOverflow answers still show up in web search; to guard against future enshittification, these notes are my own copy):

ports$ git daemon --reuseaddr --base-path=. --export-all --verbose

In my ports/ directory, run the simple and insecure git server that comes with it. Export the ports tree. On the receiving (that is, in the VM) side, clone with git:// protocol.

# git clone git://host/ /usr/ports

And voila! That enables a quick turn-around for port fifxes that need to be done on a different machine from where I have my usual ports tree checkout (and my GPG keys, and …).

During his bachelor thesis, Joel Häberli designed and implemented a framework allowing for cashless withdrawals in GNU Taler.

It's been a number of years since we made the switch to DDEV, and have regretted it not once on any given day.