Reproducible Builds (diffoscope): diffoscope 256 released

Planet Debian - Thu, 2024-02-08 19:00

The diffoscope maintainers are pleased to announce the release of diffoscope version 256. This version includes the following changes:

* Use a determistic name when extracting content from GPG artifacts instead of trusting the value of gpg's --use-embedded-filenames. This prevents a potential information disclosure vulnerability that could have been exploited by providing a specially-crafted GPG file with an embedded filename of, say, "../../.ssh/id_rsa". Many thanks to Daniel Kahn Gillmor <dkg@debian.org> for reporting this issue and providing feedback. (Closes: reproducible-builds/diffoscope#361) * Temporarily fix support for Python 3.11.8 re. a potential regression with the handling of ZIP files. (See reproducible-builds/diffoscope#362)

You find out more by visiting the project homepage.

Categories: FLOSS Project Planets

Balint Pekker: To Patch or Not To Patch

Planet Drupal - Thu, 2024-02-08 18:35
There is an ongoing debate among developers regarding the use of patches versus pull requests for contributions. Since its migration to GitLab in 2018, Drupal has undergone significant changes. As of July 2024, the removal of Drupal CI and automated patch testing could potentially change the way contributions are made.
Categories: FLOSS Project Planets

Dirk Eddelbuettel: RcppArmadillo on CRAN: New Upstream, Interface Polish

Planet Debian - Thu, 2024-02-08 18:33

Armadillo is a powerful and expressive C++ template library for linear algebra and scientific computing. It aims towards a good balance between speed and ease of use, has a syntax deliberately close to Matlab, and is useful for algorithm development directly in C++, or quick conversion of research code into production environments. RcppArmadillo integrates this library with the R environment and language–and is widely used by (currently) 1119 other packages on CRAN, downloaded 32.5 million times (per the partial logs from the cloud mirrors of CRAN), and the CSDA paper (preprint / vignette) by Conrad and myself has been cited 575 times according to Google Scholar.

This release brings a new (stable) upstream (minor) release Armadillo 12.8.0 prepared by Conrad two days ago. We, as usual, prepared a release candidate which we tested against the over 1100 CRAN packages using RcppArmadillo. This found no issues, which was confirmed by CRAN once we uploaded and so it arrived as a new release today in a fully automated fashion.

We also made a small change that had been prepared by GitHub issue #400: a few internal header files that were cluttering the top-level of the include directory have been moved to internal directories. The standard header is of course unaffected, and the set of ‘full / light / lighter / lightest’ headers (matching we did a while back in Rcpp) also continue to work as one expects. This change was also tested in a full reverse-dependency check in January but had not been released to CRAN yet.

The set of changes since the last CRAN release follows.

Changes in RcppArmadillo version (2024-02-06)
  • Upgraded to Armadillo release 12.8.0 (Cortisol Injector)

    • Faster detection of symmetric expressions by pinv() and rank()

    • Expanded shift() to handle sparse matrices

    • Expanded conv_to for more flexible conversions between sparse and dense matrices

    • Added cbrt()

    • More compact representation of integers when saving matrices in CSV format

  • Five non-user facing top-level include files have been removed (#432 closing #400 and building on #395 and #396)

Courtesy of my CRANberries, there is a diffstat report relative to previous release. More detailed information is on the RcppArmadillo page. Questions, comments etc should go to the rcpp-devel mailing list off the Rcpp R-Forge page.

If you like this or other open-source work I do, you can sponsor me at GitHub.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

Categories: FLOSS Project Planets

15-Minute Bug Initiative update

Planet KDE - Thu, 2024-02-08 15:50

A tad over two years ago, I revealed the 15-Minute Bug Initiative–an attempt to improve the out-of-the box user experience for Plasma by focusing on fixing obvious papercut issues. The idea was to crush the meme of “KDE is buggy” the same way we systematically addressed similar complaints like “KDE is ugly” and “KDE is bloated” in years past.

Well, it’s been two years, so how did it go? Let’s talk about it! First some numbers, because we like numbers:

  • Starting number of bugs: 92
  • Current number of bugs: 32
  • Total number of bugs fixed (because more were added over time): 231
  • Percent of all total 15-minute bugs that have been fixed: 87.8%

(note if you’re from the future: if you visit those links, some numbers may be different–hopefully lower for the second one and higher for the third one!)

Wow! That’s quite a few. So this initiative looks like it’s been a real success so far! Nevertheless, 32 bug reports remain open, so we can’t declare victory yet. These are some of the stubbornest, hardest-to-fix bugs that require major re-architecting, working upstream, or similarly challenging efforts. Hopefully the pace of improvement seen over these years has managed to convince you that they’ll eventually be resolved as well.

“Wait a minute, Plasma is still buggy AF you n00b”

Keep in mind these aren’t all the bug reports in the world we can fix (there are over 5000 of them for Plasma and Plasma-aligned software alone), just the ones I and some others have deemed to be most obvious to the average user! If you’re not an average user because you have three monitors arranged in a weird shape, each plugged into a different GPU from a different vendor and its own different DPI, scale factors, and custom Plasma panels, plus 4 activities and 9 virtual desktops and 6 internal disks, only half of which automount, and 12 apps set to autostart, and each of them is installed onto different disks, 15 window rules, and finally a custom theming setup including Kvantum themes and Aurorae window decorations… then yeah, you’re probably going to experience some more bugs compared to a more typical user who doesn’t have such a complex setup!

That’s okay. We care about you too, and we do work on those kinds of more esoteric bugs because many of us also have complex setups! But progress here will be necessarily slower, because the complex setups are more varied, more unusual, and harder to debug. And let’s be honest here: those of us with setups like these are experts capable of working around most bugs we find, who really should be helping to investigate and fix them. Admit it, you know it’s true!

But in a way, this is good: it represents Plasma moving from “It’s generally buggy” to “it’s specifically buggy–buggy with only certain less common combinations of settings, rather than buggy in a way that anyone can find within 15 minutes of using a system with its default settings. Improving on that was the point of this initiative.

Next steps

Up until now we’ve been ignoring Wayland-only bugs here, because the Wayland session was not the default one. Well, with Plasma 6 that changes, so all of those Wayland-only issues that meet the loose criteria to be a 15-minute bug will be promoted. Similarly, current 15-minute bugs that are X11-only will be demoted. So sometime in the next few weeks, expect the list to shift around a bit.

Once the number gets down to 0, it will of course go up again periodically as new bugs are found or introduced. But this is great! It means we can whack them as they appear, rather than letting them pile up over time. In this way the list becomes a “rapid response needed” task list rather than a backlog we’re always behind on.

What happens with those development resources once the 15-minute Plasma bugs are under control? I have a plan, first articulated in the original announcement 2 years ago: extend the program to Frameworks bugs! There are quite a few candidates there too. And because frameworks bugs can affect Plasma and our vast app library, quality will go up overall.

Speaking of those apps, once the 15-minute Frameworks bugs are also down to zero or close to it, we can include app bugs. This will finally give us complete coverage! I have a dream that one day, we’ll have a stable and mostly bug-free UI layer and our limited development resources can be focused more on performance work, sustainably-crafted new features, usability, more standardized styling, etc. I think it’s doubtful we can get there while we’re still battling routine bugs all the time.

How you can help

As always, help work on the existing 15-minute bugs if you can! If not, it’s always useful to work on bug triaging, so that more of those issues that will eventually become 15-minute bugs can get discovered. Another impactful way is to donate to KDE e.V., the nonprofit that support KDE on a ridiculously small budget. We’re still running the Plasma 6 fundraiser which represents a great way to donate!

Categories: FLOSS Project Planets

Drupal Association blog: The Top 6 Benefits of Attending DrupalCon Portland 2024

Planet Drupal - Thu, 2024-02-08 14:51

DrupalCon Portland 2024 promises to be an unmissable event for web developers, designers, and business professionals invested in the Drupal ecosystem. As one of the most significant gatherings in the Drupal community, the conference offers a variety of benefits that extend beyond just technical knowledge. From networking opportunities to staying ahead in the rapidly evolving digital landscape, attending DrupalCon Portland can be a game-changer for professionals. Let's explore 6 of the top benefits of being part of this transformative event!

Cutting-Edge Insights

DrupalCon is renowned for bringing together thought leaders and experts in the Drupal community. Attendees will have the chance to gain insights into the latest trends, innovations, and best practices in web development, ensuring they stay at the forefront of the industry.

Networking and Career Opportunities

Connect with like-minded professionals and Drupal enthusiasts at DrupalCon. The conference offers a networking platform beyond sessions, fostering relationships for potential partnerships, job opportunities, and collaborative projects. Explore career prospects by engaging with hiring companies and recruiters in the Drupal ecosystem, as many organizations actively seek skilled professionals to join their teams.

Skill Enhancement

Join interactive training sessions and learn from industry experts at DrupalCon. These sessions aim to improve your skills and offer practical knowledge for immediate application to your projects. DrupalCon provides a variety of session tracks suitable for different interests and skill levels. Whether you're a beginner or an experienced developer, there are sessions customized to meet your requirements, guaranteeing a comprehensive learning experience.

Stay Informed About Drupal releases

DrupalCon Portland 2024 presents a fantastic chance to stay informed about the latest developments and insights in Drupal's upcoming core and feature releases. By participating, you can stay ahead of the curve by gaining knowledge about the new features, enhancements, and possible challenges that Drupal has in store. This event provides a valuable opportunity to stay current and well-informed within the Drupal community.

Contribute to the Community

DrupalCon provides a comprehensive experience beyond training and discussions, allowing participants to actively contribute through collaborative code sprints. These hands-on sessions, where developers collectively enhance Drupal core and modules, offer valuable practical experience. Beyond coding, attendees can also contribute through non-code avenues such as volunteering and mentoring, enriching their overall DrupalCon experience. This inclusive and collaborative spirit defines DrupalCon, fostering a vibrant community of shared knowledge and expertise.

Vendor Expo

Take advantage of the vendor expo at DrupalCon Portland 2024 to explore cutting-edge tools, services, and technologies that seamlessly integrate with Drupal. Immerse yourself in engaging conversations with industry-leading vendors to gain a deep understanding of their offerings. This is a unique opportunity to identify potential partnerships or solutions that can significantly enhance the effectiveness of your Drupal projects. By actively participating in the expo, you'll be able to discover and leverage the latest innovations that can elevate your Drupal experience.

DrupalCon Portland 2024 is not just a conference; it's an immersive experience that can significantly impact your professional growth. The benefits are extensive, from staying updated on the latest Drupal developments to forging valuable connections and contributing to the open source community. Attendees can expect to leave the conference with enhanced skills, fresh perspectives, and a network of contacts that can propel their careers to new heights.

Registration is now open for DrupalCon Portland 2024, held from 6-9 May at the Oregon Convention Center.

Categories: FLOSS Project Planets

Python People: Nikita Karamov - Django project maintainer, from Russia to Germany

Planet Python - Thu, 2024-02-08 14:08

Nikita Karamov is a Python developer and maintainer on various open source Python projects.

Some topics covered:

  • Notes on university education in programming and engineering vs theory
  • Jazzband for maintaining Django projects
  • Contributing to open source makes you a better programmer
  • Moving from Russia to Germany during college
  • Cultural differences between Russia, Germany, and Oregon
  • The nice lack of drama in the Python community
  • A lack of universities teaching Python for web development

Links from the show

The Complete pytest Course

★ Support this podcast on Patreon ★ <p>Nikita Karamov is a Python developer and maintainer on various open source Python projects.</p><p>Some topics covered:</p><ul><li>Notes on university education in programming and engineering vs theory</li><li>Jazzband for maintaining Django projects</li><li>Contributing to open source makes you a better programmer</li><li>Moving from Russia to Germany during college</li><li>Cultural differences between Russia, Germany, and Oregon</li><li>The nice lack of drama in the Python community</li><li>A lack of universities teaching Python for web development</li></ul><p><br>Links from the show</p><ul><li><a href="https://jazzband.co">Jazzband</a></li><li><a href="https://jazzband.co/projects/django-simple-menu">django-simple-menu</a></li></ul> <br><p><strong>The Complete pytest Course</strong></p><ul><li>Level up your testing skills and save time during coding and maintenance.</li><li>Check out <a href="https://courses.pythontest.com/p/complete-pytest-course">courses.pythontest.com</a></li></ul> <strong> <a href="https://www.patreon.com/PythonPeople" rel="payment" title="★ Support this podcast on Patreon ★">★ Support this podcast on Patreon ★</a> </strong>
Categories: FLOSS Project Planets

lightning @ Savannah: GNU lightning 2.2.3 released!

GNU Planet! - Thu, 2024-02-08 13:51

GNU lightning is a library to aid in making portable programs
that compile assembly code at run time.


Download release:

  GNU Lightning 2.2.3 main new features:

  • PowerPC port now optimize for a variable stack frame size and only create a stack frame if a non leaf function.
  • New callee test to ensure register values saved on the stack are not corrupted when calling a jit or C function. While no problem was found in any port, the new test was added to make sure there were no failures.
  • Add back the jit_hmul interface, from Lightning 1.x. There are special cases where it is desirable to only know the high part of a multiplication.
  • Correct wrong implementation of zero right shift with two registers output.
  • Add new pre and post increment for load and store instructions.
  • Several minor bug fixes.
Categories: FLOSS Project Planets

PyCharm: PyCharm 2024.1 EAP 4: Sticky Lines, and More

Planet Python - Thu, 2024-02-08 12:44

The Early Access Program for PyCharm 2024.1 continues with our latest build where you can preview new features, including convenient sticky lines in the editor, and more.

You can download the new version from our website, update directly from the IDE or via the free Toolbox App, or use snaps for Ubuntu.

Download PyCharm 2024.1 EAP

Learn about the key highlights below.

User experience Sticky lines in the editor

To simplify working with large files and exploring new codebases, we’ve introduced sticky lines in the editor. This feature keeps key structural elements, like the beginnings of classes or methods, pinned to the top of the editor as you scroll. This way, scopes always remain in view, and you can promptly navigate through the code by clicking on a pinned line.

As of PyCharm 2024.1, this feature will be enabled by default. You can disable it via a checkbox in Settings/Preferences | Editor | General | Appearance, where you can also set the maximum number of pinned lines.

Version control systems Option to display review branch changes in a Git Log tab

IntelliJ IDEA 2024.1 EAP 4 streamlines the code review workflow by offering a focused view of branch-related changes. For GitHub, GitLab, and Space, it is now possible to see changes in a certain branch in a separate Log tab within the Git tool window. To do so, click on the branch name in the Pull Requests tool window and pick Show in Git Log from the menu.

These are the most notable improvements in the latest PyCharm 2024.1 EAP build. Explore the full list of changes in the release notes, and stay tuned for more updates next week.

We encourage you to share your opinion about the newest additions in the comments below or by contacting us on X (formerly Twitter). If you spot a bug, please report it via our issue tracker.

Categories: FLOSS Project Planets

TechBeamers Python: Python’s Map() and List Comprehension: Tips and Best Practices

Planet Python - Thu, 2024-02-08 11:20

Welcome to this tutorial where we will explore Python map() and List Comprehension best practices and share some cool coding tips. These techniques, when mastered, can make your code cleaner, more concise, and efficient. In this guide, we’ll explore these concepts from the ground up, using simple and practical examples. Let’s begin mastering the map […]

The post Python’s Map() and List Comprehension: Tips and Best Practices appeared first on TechBeamers.

Categories: FLOSS Project Planets

TechBeamers Python: 20 Practical Python Data Analysis Tips and Tricks

Planet Python - Thu, 2024-02-08 09:00

Hey, welcome! Today, we’re talking about practical Python data analysis tips and tricks. With Pandas and NumPy, we’ll tidy up data, spot trends, and do some smart analysis. It’s all about making your data work easier and getting cool insights. Let’s dive in to optimize your data analysis tasks. Practical Python Tips for Solid Data […]

The post 20 Practical Python Data Analysis Tips and Tricks appeared first on TechBeamers.

Categories: FLOSS Project Planets

Ramsalt Lab: Upgrading your site from Drupal 9 to 10

Planet Drupal - Thu, 2024-02-08 08:44
Upgrading your site from Drupal 9 to 10 Perry Aryee Developer 08.02.2024

With Drupal 9 having reached its end of life (EOL) on November 1, it’s time to start planning for an upgrade.

For those already operating on Drupal 9, upgrading to Drupal 10 is not as daunting as earlier upgrades and promises to be easy, reflecting the software’s overall trend towards smaller, more incremental upgrades and faster iterations. According to Drupal, you should "completely update your Drupal 9 site to the most recent version of the modules and theme(s), before updating to Drupal 10." 

The deprecated code will be based on Drupal 9 moving into Drupal 10, but there are ways to search your system and update the specified code block.

The first thing to do is to install the  drupal/upgrade_status module in your project and enable it. composer require drupal/upgrade_status && drush en upgrade_status, if you have drush installed else go to admin > modules  and search for upgrade status and install it. After the module is enabled, go to Admin > Reports > Upgrade Status. This page should contain all the upgrades and code changes necessary before your site can be upgraded to Drupal 10.

Steps to upgrade Drupal 9 to Drupal 10

Migrating from Drupal 9 to Drupal 10 can be easy or can be difficult depending on the project you are involved in. Yes, because every site is different and may present its own unique challenges.

These are the following steps to migrate from Drupal 9 to Drupal 10.

  1. Keeping your custom modules up to date with new standards and removing deprecated code will result in small changes before you have to do a major core upgrade. If the site is well maintained the changes are mostly with the core_version_requirement. You will need to update from core_version_requirement: ^9 to core_version_requirement: ^9 || ^10 . As soon as we are sure that our custom code is compatible with Drupal 10, we can move to check the contrib modules. And this is where things might get tricky
  1. Upgrade contrib modules to versions which support Drupal 9 and 10. If the new version only supports D10, then you can add it to composer as an alternative version, for example: 'drupal/module_name': '^1 || ^2', and you can have version 1 still installed while on Drupal 9. Once you install Drupal 10, version 2 of the module will be installed by composer.
  1. Uninstall obsolete modules and themes like Color, RDF, Seven etc. You can’t remove core modules or themes, but if you are not sure if these are depended upon, it can be moved from core to contrib especially classy and stable, which you can keep as contrib modules. You may need to set your Admin theme to Claro and re-export your config on this step. Use drush theme:uninstall theme(s) command (drush thun for short) to uninstall themes.
  1. Remove orphaned permissions which are still assigned to user roles. Export your config before starting this step. The upgrade_status module will tell you which permissions need to go from which roles. Simply edit the user.role.[role].yml config ymls and remove the relevant lines from the permissions array. 
  1. Upgrade Drupal core to latest 9.5, in order to upgrade to 10.

composer require drupal/core-recommended:^9.5 drupal/core-composer-scaffold:^9.5  --update-with-all-dependencies

Now let's look at the tricky part. Drupal 10 has some specific things we have to do to allow us to upgrade to drupal 10.

  1. Drupal 10 runs with PHP 8.2 or later so make sure you have it to be able to upgrade. 
  1. Not all modules are Drupal 10 ready so you will have to use drupal lenient.  You will have to get a patch for Drupal 9 only modules. Install mglaman/composer-drupal-lenient before attempting to upgrade. Otherwise these modules will create a dependency problem. After the installation, you need to declare the Drupal 9 modules which should be treated as Drupal 10 modules. For example, to allow drupal/token to be installed run:

composer require mglaman/composer-drupal-lenient

composer config --merge --json extra.drupal-lenient.allowed-list '["drupal/token"]'

  1. If you have Drush installed make sure the version is ^11 || ^12, we use this because some module may not be version 12 compatible.
  1. Drupal Console (drupal/console) is not Drupal 10 compatible and as such we have to remove it. 

composer remove drupal/console --no-update

  1. Upgrade CKEditor 4 to CKEditor 5,if you have custom CKEditor 4 plugins which don’t have an upgrade path to CKEditor 5, then you can keep using CKEditor 4 but as a contrib module. You may have to use it although it is deprecated, to avoid errors when you deploy the Drupal 10 upgrade, when the config import tries to uninstall CKEditor.
  1. If you use Entity Embed, you need to manually replace CKEditor Embed buttons with SVG icons as Drupal 10 is not using png.
  1. Check custom code for core/jquery.once if it does exist update it to use core/once because jquery.once is removed from Drupal 10
  1. If you encounter dependency issues, and composer just won’t let you upgrade to D10, but you are sure that all the dependencies are in order, then the quickest thing to do is to delete the composer.lock file(although its not a best practice), delete vendor folder then run composer install which will install from the composer.json file and create a new .lock file.
  1. Note that you can ignore some false positives such as an empty custom profile, which phpstan can’t scan, and as such upgrade status would complain, the trick would be to create an empty .php file to get the issue fix

After all these are done and ready for upgrade, you can run this command

composer require 'drupal/core-recommended:^10' 'drupal/core-composer-scaffold:^10' 'drupal/core-project-message:^10' --no-update

If   drupal/core happens to be part of the composer.json file, remove it. This dependency is included in drupal/core-recommended and may cause problems. If you have drupal/core-dev installed, you can run this

composer require 'drupal/core-dev:^10' --dev --no-update

Now,let us test perform the update with the --dry-run option: this allows us to see if the update will runs smoothly or might encounter some errors.

composer update --dry-run

If you encounter any errors, walk through the process to resolve them. Resume the process when the errors are resolved, run the update with dependencies to update any transitive module.

composer update -W

Don’t forget to run drush updb and drush cex after the upgrade. This means you should run the upgrade on top of an installed and functioning D9 database.

If you have a custom theme that is  based on classy,seven or stable then don’t forget to install them as  contrib themes - composer require 'drupal/[module_name]'. You should uninstall and remove upgrade status after the upgrade process.

Pathauto has an issue with some config files so, if you have Pathauto installed then you need to update some configs by hand. Namely pathauto.pattern.[name] config files have had their selection_criteria plugins updated. For example node_type becomes entity_bundle:node. or  try the following command

drush eval 'include_once(DRUPAL_ROOT . "/modules/contrib/pathauto/pathauto.install"); pathauto_update_8108()'

In summary the whole update process for a site can be very difficult and ranges from project to project. It could have different modules installed, with some even locked to specific dev versions, as well as heavily patched old major versions of modules which needed to be upgraded. You walk through these steps and iterate through if need be to get your upgrade completed.

Categories: FLOSS Project Planets

The Drop Times: André Angelantoni Discusses Automated Testing Kit Module

Planet Drupal - Thu, 2024-02-08 08:44
Discover how the Automated Testing Kit for Drupal, led by André Angelantoni, revolutionizes end-to-end testing with its versatile features, impactful vision, and seamless integration of Cypress.io and Playwright frameworks.
Categories: FLOSS Project Planets

Python Software Foundation: Software Bill-of-Materials documents are now available for CPython

Planet Python - Thu, 2024-02-08 05:53

Our Security Developer-in-Residence, Seth Larson, has been working to improve the management of vulnerabilities for Python users. Seth has championed progress on this goal in a variety of areas:

With the release of CPython 3.12.2, the next step of the Python Software Foundation’s vulnerability management strategy is now available in the form of Software Bill-of-Materials (SBOM) documents for CPython source releases. The documents are available for download in their own column labeled “SBOM” in the “Files” table on the release page. User documentation and a getting started guide for CPython SBOMs is available on python.org.

These documents are relatively new but have been tested with multiple tools that accept SPDX SBOM documents. Please report any feedback on the SBOM to the CPython issue tracker.

What is a Software Bill-of-Materials (SBOM)?

Software Bill-of-Materials are machine-readable documents using an ecosystem-independent format like SPDX or CycloneDX to describe what a piece of software is made of and how each component within the software relates to other components. There are multiple use-cases for SBOMs, but for CPython we primarily focused on software supply chain and vulnerability management.

Many vulnerability scanning tools support passing an SBOM document as input to provide a comprehensive scan for software vulnerabilities without needing to rely on fallible software discovery. This means there’s less chances for vulnerabilities to be missed by scanners.

There are existing tools for automatically creating SBOMs for software, but SBOMs which aren’t accurate are sometimes more dangerous than having no SBOM due to causing a false sense of security. This is especially true for complex pieces of software or projects which exist outside of package ecosystems, both of which apply to CPython and make generating an SBOM difficult. For this reason the content of CPython SBOMs is curated by hand on first pass to ensure accuracy and completeness and then automated to track updates as the software changes.

SBOM documents are becoming a requirement for compliance in multiple areas and industries. In order to meet those requirements we are providing a comprehensive and accurate SBOM for CPython that will provide assurance for Python users.

What is included in CPython SBOMs?

CPython SBOMs use the SPDX SBOM standard. SBOM documents include a description of the contained software, including all of its dependencies. Information in CPython SBOMs includes:

  • Names and versions of all software components
  • Software identifiers (like CPE and Package URLs)
  • Download URLs for source code with checksums
  • File names and content checksums
  • Dependency relationships between each component

CPython SBOMs satisfy the requirements listed in the NTIA Minimum Elements for a Software Bill of Materials. Software identifiers can be used for correlating software in use to vulnerability databases like the CVE database and Open Source Vulnerability database, typically done automatically using vulnerability scanning tools.

What isn’t included in CPython SBOMs?

Keep in mind that software libraries that you supply yourself to compile CPython, such as OpenSSL and zlib, are not included in the SBOMs for source artifacts.

This is due to these libraries not being included in source artifacts, so CPython users have a choice of which version and sources to use for these third-party libraries. Folks who are compiling CPython from source are responsible for tracking their own dependencies either in a separate SBOM document or by appending new entries to your local CPython SBOM.

CPython’s SBOMs don’t include licensing information for dependencies. See the CPython licensing page for licensing information.

What is coming next for CPython SBOMs?

This is only the beginning for CPython SBOMs, as mentioned above there are only SBOM documents published for source releases today. The CPython release managers also publish binary installers for Windows and macOS on a variety of distribution channels. These artifacts will need their own SBOM documents as they are compiled with software that’s typically not available on those platforms (e.g. OpenSSL).

There’s also more infrastructure needed to reduce noise and churn for Python users and Python Security Response Team members alike. Vulnerability EXchange (VEX) statements are a set of standards which allows software producers to signal to user tooling whether a piece of software in use is affected by a vulnerability, even for vulnerabilities affecting dependencies. This is an area of active development and is being explored alongside the OpenSSF Security Tooling Working Group.

The Security Developer-in-Residence role and this work is funded by a substantial investment from the OpenSSF Alpha-Omega Project. Thanks to Alpha-Omega for their support in improving the security posture of the entire Python ecosystem.The OpenSSF is a non-profit cross-industry collaboration that unifies security initiatives and brings together leaders to improve the security of open source software by building a broader community, targeted initiatives, and best practices.

Categories: FLOSS Project Planets

Sven Hoexter: Use GitHub CLI to List all Repository Secrets

Planet Debian - Thu, 2024-02-08 05:12

Write it down before I forget about it again:

for x in $(gh api graphql --paginate -f query='query($endCursor:String) { organization(login:"myorg") { repositories(first: 100, after: $endCursor, isArchived:false) { pageInfo { hasNextPage endCursor } nodes { name } } } }' --jq '.data.organization.repositories.nodes[].name'); do secrets=$(gh secret list --json name --jq '.[].name' -R "myorg/${x}" | tr '\n' ',') if ! [ -z "${secrets}" ]; then echo "${x},${secrets}" fi done

Requests a list of all not archived repositories in a GitHub org and queries repository secrets. If we find some we output the repo name and the secrets in a comma separated list. Not real CSV, but good enough for further processing. I've to admit it's kinda beautiful what you can do with the gh cli by now. Sadly it seems the secrets are not yet available via GraphQL (or I missed it in the docs), so I just use the gh cli to do the REST calls.

Categories: FLOSS Project Planets

Talk Python to Me: #448: Full-Time Open Source Devs Panel

Planet Python - Thu, 2024-02-08 03:00
So you've created a Python-based open source project and it's started to take off. You're getting contributors, lots of buzz in the podcast space, and more. But you have that day job working on Java. How do you make the transition from popular hobby project to full time job? After all, you are giving away your open source project for free, right? Well, on this episode, I have put together an amazing panel of guests who all have done exactly this: Turned their project into full time work and even companies in some cases. We have Samuel Colvin, Gina Häußge, Sebastián Ramírez, Charlie Marsh, Will McGugan and Eric Holscher on to share their stories.<br/> <br/> <strong>Episode sponsors</strong><br/> <br/> <a href='https://talkpython.fm/basedash'>Basedash</a><br> <a href='https://talkpython.fm/sentry-monorepo'>Sentry Error Monitoring, Code TALKPYTHON</a><br> <a href='https://talkpython.fm/training'>Talk Python Courses</a><br/> <br/> <strong>Links from the show</strong><br/> <br/> <div><b>Will McGugan</b>: <a href="https://twitter.com/willmcgugan" target="_blank" rel="noopener">@willmcgugan</a><br/> <b>Charlie Marsh</b>: <a href="https://hachyderm.io/@charliermarsh" target="_blank" rel="noopener">@charliermarsh@hachyderm</a><br/> <b>Sebastián Ramírez</b>: <a href="https://twitter.com/tiangolo" target="_blank" rel="noopener">@tiangolo</a><br/> <b>Samuel Colvin</b>: <a href="https://twitter.com/samuel_colvin" target="_blank" rel="noopener">@samuel_colvin</a><br/> <b>Gina on Mastodon</b>: <a href="https://chaos.social/@foosel" target="_blank" rel="noopener">chaos.social/@foosel</a><br/> <b>Eric Holscher</b>: <a href="https://twitter.com/ericholscher" target="_blank" rel="noopener">@ericholscher</a><br/> <br/> <b>Pydantic</b>: <a href="https://pydantic.dev" target="_blank" rel="noopener">pydantic.dev</a><br/> <b>Astral (makes of Ruff)</b>: <a href="https://astral.sh" target="_blank" rel="noopener">astral.sh</a><br/> <b>Octoprint</b>: <a href="https://octoprint.org" target="_blank" rel="noopener">octoprint.org</a><br/> <b>Read the Docs</b>: <a href="https://about.readthedocs.com/" target="_blank" rel="noopener">readthedocs.com</a><br/> <b>FastAPI</b>: <a href="https://fastapi.tiangolo.com" target="_blank" rel="noopener">fastapi.tiangolo.com</a><br/> <b>Textual (makes of Rich)</b>: <a href="https://www.textualize.io" target="_blank" rel="noopener">textualize.io</a><br/> <b>Watch this episode on YouTube</b>: <a href="https://www.youtube.com/watch?v=HV1LKitAr44" target="_blank" rel="noopener">youtube.com</a><br/> <b>Episode transcripts</b>: <a href="https://talkpython.fm/episodes/transcript/448/full-time-open-source-devs-panel" target="_blank" rel="noopener">talkpython.fm</a><br/> <br/> <b>--- Stay in touch with us ---</b><br/> <b>Subscribe to us on YouTube</b>: <a href="https://talkpython.fm/youtube" target="_blank" rel="noopener">youtube.com</a><br/> <b>Follow Talk Python on Mastodon</b>: <a href="https://fosstodon.org/web/@talkpython" target="_blank" rel="noopener"><i class="fa-brands fa-mastodon"></i>talkpython</a><br/> <b>Follow Michael on Mastodon</b>: <a href="https://fosstodon.org/web/@mkennedy" target="_blank" rel="noopener"><i class="fa-brands fa-mastodon"></i>mkennedy</a><br/></div>
Categories: FLOSS Project Planets

Bits from Debian: DebConf24 Logo Contest Results

Planet Debian - Thu, 2024-02-08 00:00

Earlier this month the DebConf team announced the DebConf24 Logo Contest asking aspiring artists, designers, and contributors to submit an image that would represent the host city of Busan, the host nation of South Korea, and promote the next Debian Developer Conference.

The logo contest for DebConf24 received 10 submissions and garnered 354 responses with 3 proposals in particular getting very close to first place. The winning logo received 88 votes, the 2nd favored logo received 87 votes, and the 3rd most favored received 86 votes.

Thank you to Woohee Yang and Junsang Moon for sharing their artistic visions.

A very special Thank You to everyone who took the time to vote for our beautiful new logo!

The DebConf24 Team is proud to share for preview only the winning logo for the 24th Debian Developer Conference:

'sun-seagull-sea' by Woohee Yang

This is a preview copy, other revisions will occur for sizing, print, and media... but we had to share it with you all now. :).

Looking forward to seeing you all at #debconf24 in #Busan, South Korea 2024!

Categories: FLOSS Project Planets

Reproducible Builds: Reproducible Builds at FOSDEM 2024

Planet Debian - Wed, 2024-02-07 19:00

Core Reproducible Builds developer Holger Levsen presented at the main track at FOSDEM on Saturday 3rd February this year in Brussels, Belgium. Titled Reproducible Builds: The First Ten Years

In this talk Holger ‘h01ger’ Levsen will give an overview about Reproducible Builds: How it started with a small BoF at DebConf13 (and before), then grew from being a Debian effort to something many projects work on together, until in 2021 it was mentioned in an Executive Order of the President of the United States. And of course, the talk will not end there, but rather outline where we are today and where we still need to be going, until Debian stable (and other distros!) will be 100% reproducible, verified by many.

h01ger has been involved in reproducible builds since 2014 and so far has set up automated reproducibility testing for Debian, Fedora, Arch Linux, FreeBSD, NetBSD and coreboot.

More information can be found on FOSDEM’s own page for the talk.

Separate from Holger’s talk, however, there were a number of other talks about reproducible builds at FOSDEM this year:

… and there was even an entire track on Software Bill of Materials.

Categories: FLOSS Project Planets

Reproducible Builds: Reproducible Builds in January 2024

Planet Debian - Wed, 2024-02-07 17:16

Welcome to the January 2024 report from the Reproducible Builds project. In these reports we outline the most important things that we have been up to over the past month. If you are interested in contributing to the project, please visit our Contribute page on our website.

“How we executed a critical supply chain attack on PyTorch”

John Stawinski and Adnan Khan published a lengthy blog post detailing how they executed a supply-chain attack against PyTorch, a popular machine learning platform “used by titans like Google, Meta, Boeing, and Lockheed Martin”:

Our exploit path resulted in the ability to upload malicious PyTorch releases to GitHub, upload releases to [Amazon Web Services], potentially add code to the main repository branch, backdoor PyTorch dependencies – the list goes on. In short, it was bad. Quite bad.

The attack pivoted on PyTorch’s use of “self-hosted runners” as well as submitting a pull request to address a trivial typo in the project’s README file to gain access to repository secrets and API keys that could subsequently be used for malicious purposes.

New Arch Linux forensic filesystem tool

On our mailing list this month, long-time Reproducible Builds developer kpcyrd announced a new tool designed to forensically analyse Arch Linux filesystem images.

Called archlinux-userland-fs-cmp, the tool is “supposed to be used from a rescue image (any Linux) with an Arch install mounted to, [for example], /mnt.” Crucially, however, “at no point is any file from the mounted filesystem eval’d or otherwise executed. Parsers are written in a memory safe language.”

More information about the tool can be found on their announcement message, as well as on the tool’s homepage. A GIF of the tool in action is also available.

Issues with our SOURCE_DATE_EPOCH code?

Chris Lamb started a thread on our mailing list summarising some potential problems with the source code snippet the Reproducible Builds project has been using to parse the SOURCE_DATE_EPOCH environment variable:

I’m not 100% sure who originally wrote this code, but it was probably sometime in the ~2015 era, and it must be in a huge number of codebases by now.

Anyway, Alejandro Colomar was working on the shadow security tool and pinged me regarding some potential issues with the code. You can see this conversation here.

Chris ends his message with a request that those with intimate or low-level knowledge of time_t, C types, overflows and the various parsing libraries in the C standard library (etc.) contribute with further info.

Distribution updates

In Debian this month, Roland Clobus posted another detailed update of the status of reproducible ISO images on our mailing list. In particular, Roland helpfully summarised that “all major desktops build reproducibly with bullseye, bookworm, trixie and sid provided they are built for a second time within the same DAK run (i.e. [within] 6 hours)”. Additionally 7 of the 8 bookworm images from the official download link build reproducibly at any later time.

In addition to this, three reviews of Debian packages were added, 17 were updated and 15 were removed this month adding to our knowledge about identified issues.

Elsewhere, Bernhard posted another monthly update for his work elsewhere in openSUSE.

Community updates

There were made a number of improvements to our website, including Bernhard M. Wiedemann fixing a number of typos of the term ‘nondeterministic’. [] and Jan Zerebecki adding a substantial and highly welcome section to our page about SOURCE_DATE_EPOCH to document its interaction with distribution rebuilds. [].

diffoscope is our in-depth and content-aware diff utility that can locate and diagnose reproducibility issues. This month, Chris Lamb made a number of changes such as uploading versions 245 and 255 to Debian but focusing on triaging and/or merging code from other contributors. This included adding support for comparing eXtensible ARchive’ (.XAR/.PKG) files courtesy of Seth Michael Larson [][], as well considerable work from Vekhir in order to fix compatibility between various and subtle incompatible versions of the progressbar libraries in Python [][][][]. Thanks!

Reproducibility testing framework

The Reproducible Builds project operates a comprehensive testing framework (available at tests.reproducible-builds.org) in order to check packages and other artifacts for reproducibility. In January, a number of changes were made by Holger Levsen:

  • Debian-related changes:

    • Reduce the number of arm64 architecture workers from 24 to 16. []
    • Use diffoscope from the Debian release being tested again. []
    • Improve the handling when killing unwanted processes [][][] and be more verbose about it, too [].
    • Don’t mark a job as ‘failed’ if process marked as ‘to-be-killed’ is already gone. []
    • Display the architecture of builds that have been running for more than 48 hours. []
    • Reboot arm64 nodes when they hit an OOM (out of memory) state. []
  • Package rescheduling changes:

    • Reduce IRC notifications to ‘1’ when rescheduling due to package status changes. []
    • Correctly set SUDO_USER when rescheduling packages. []
    • Automatically reschedule packages regressing to FTBFS (build failure) or FTBR (build success, but unreproducible). []
  • OpenWrt-related changes:

    • Install the python3-dev and python3-pyelftools packages as they are now needed for the sunxi target. [][]
    • Also install the libpam0g-dev which is needed by some OpenWrt hardware targets. []
  • Misc:

    • As it’s January, set the real_year variable to 2024 [] and bump various copyright years as well [].
    • Fix a large (!) number of spelling mistakes in various scripts. [][][]
    • Prevent Squid and Systemd processes from being killed by the kernel’s OOM killer. []
    • Install the iptables tool everywhere, else our custom rc.local script fails. []
    • Cleanup the /srv/workspace/pbuilder directory on boot. []
    • Automatically restart Squid if it fails. []
    • Limit the execution of chroot-installation jobs to a maximum of 4 concurrent runs. [][]

Significant amounts of node maintenance was performed by Holger Levsen (eg. [][][][][][][] etc.) and Vagrant Cascadian (eg. [][][][][][][][]). Indeed, Vagrant Cascadian handled an extended power outage for the network running the Debian armhf architecture test infrastructure. This provided the incentive to replace the UPS batteries and consolidate infrastructure to reduce future UPS load. []

Elsewhere in our infrastructure, however, Holger Levsen also adjusted the email configuration for @reproducible-builds.org to deal with a new SMTP email attack. []

Upstream patches

The Reproducible Builds project tries to detects, dissects and fix as many (currently) unreproducible packages as possible. We endeavour to send all of our patches upstream where appropriate. This month, we wrote a large number of such patches, including:

Separate to this, Vagrant Cascadian followed up with the relevant maintainers when reproducibility fixes were not included in newly-uploaded versions of the mm-common package in Debian — this was quickly fixed, however. []

If you are interested in contributing to the Reproducible Builds project, please visit our Contribute page on our website. However, you can get in touch with us via:

Categories: FLOSS Project Planets

Jonathan Dowland: carbon

Planet Debian - Wed, 2024-02-07 14:24

I got a new work laptop this year: A Thinkpad X1 Carbon (Gen 11). It wasn't the one I wanted: I'd ordered an X1 Nano, which had a footprint very reminiscent to me of my beloved x40.

Never mind! The Carbon is lovely. Despite ostensibly the same size as the T470s it's replacing, it's significantly more portable, and more capable. The two USB-A ports, as well as the full-size HDMI port, are welcome and useful (over the Nano).

I used to keep notes on setting up Linux on different types of hardware, but I haven't really bothered now for years. Things Just Work. That's good!

My old machine naming schemes are stretched beyond breaking point (and I've re-used my favourite hostname, qusp, one too many times) so I went for something new this time: Riffing on Carbon, I settled (for now) on carbyne, a carbon allotrope which is of interest to nanotechnologists (Seems appropriate)

Categories: FLOSS Project Planets

Qt Creator 12.0.2 released

Planet KDE - Wed, 2024-02-07 08:59

We are happy to announce the release of Qt Creator 12.0.2!

Categories: FLOSS Project Planets