Fedora is a Trademark of Red Hat, Inc, an operating system built by volunteers around the world. This page is provided so that independent volunteers can showcase our contributions to Fedora and Free Software in general. Official Fedora Download page.

RSS Atom

We Make Fedora

December 11, 2023

• Josh Bressers Episode 406 – The security of radio

  Josh and Kurt talk about a few security stories about radio. The TETRA:BURST attack on police radios, spoofing GPS for airplanes near Iran, and Apple including cellular radios in the macbooks. The common thread between all these stories is looking at the return on investment for security. Sometimes good enough security is fine, sometimes it’s not worth fixing certain security problems because the risk vs reward doesn’t work out.

  Show Notes

  • TETRA:BURST
  • GPS spoofing attack
  • Apple MacBooks cellular radio
  • Mossad vs Not Mossad

December 09, 2023

• Bodhi 8.0.0

  Released on 2023-12-09.
  This is a major release that introduces several breaking changes. Please read the details below and make sure to update any customized value in your config file.

  Backwards incompatible changes

  • The 'required testcases' feature is removed, as it mostly just duplicated what we do with Greenwave, only worse. The SaveUpdate schema is modified (#5548).
  • The custom skopeo-light script has been dropped. Please adjust your config file to use the real skopeo command (#5505).
  • Build NVRs are added to the Bugzilla comment. Please adjust initial_bug_msg in Bodhi config during upgrade (#5513).
  • Settings for repodata and updateinfo can now be set by an external config file and no more hardcoded. Custom settings can be applied per Release, see the devel/ci/integration/bodhi/createrepo_c.ini file for reference (#5521).

  Dependency changes

  • libcomps >= 0.20 is required to correctly validate repodata created with createrepo_c >= 1.0. Bodhi can now support all compression method available in createrepo_c (#5455).
  • Authentication and Authorization have been ported to Pyramid 2.0 Security Policies and session serializer has been switched from PickleSerializer to JSONSerializer. Bodhi will now require Pyramid > 2.0. (#5091).
  • Bodhi now can run with sqlalchemy 2. At the same time the minimum required sqlalchemy version is raised to 1.4 (#5105).

  Server upgrade instructions

  This release contains database migrations. To apply them, run:

  $ sudo -u apache /usr/bin/alembic -c /etc/bodhi/alembic.ini upgrade head
  

  Summary of the migrations:

  • The Release model has gained a released_on column which reports the date of first release.
  • The requirements column has been removed from both Package and Update models.
  • The email column of the User model has been modified to UnicodeText.

  Features

  • Support for storing critical path data in PDC is removed, as it is no longer needed (#5431).
  • Server: added a get_critpath_components json endpoint to list critical path components configured for a Release (#5484).
  • The release timeline graph now uses logarithmic scale for better display (#5492).
  • The webUI now allows unpushing Rawhide updates which fail gating tests (#5542).
  • Releases can now inherit buildroot override tags from other releases by settings in Bodhi config file (#4737).
  • Update notes are now converted to plaintext when printed in email or messages (#5049).
  • Members of QA groups defined in configuration are now able to waive or trigger tests for any update, despite they're packagers/provenpackagers or not (#5448).
  • Make the update.comment message schema more informative (#5469).
  • Release data now give information about the status of pre_beta and post_beta and of the first date of release (#5481).
  • Builds associated to unpushed updates can now be moved to other existing updates (#5485).
  • JSON APIs now support quering Releases by multiple states, for example ?state=pending&state=frozen (#5518).
  • The UpdateReadyForTesting message format is simplified, and the message is now published on update creation and edit with changed builds instead of push to testing (#5538).

  Bug fixes

  • Exclude locked updates being composed from being modified by cron tasks (#5524).
  • WebUI will not show the "push to testing" option meanwhile the update is waiting for builds to be signed (#5550).
  • Updates ejected from the composes would remain stuck in pending state due to wrong tags applied to thei builds (#5396).
  • Usernames containing a - are now correctly matched when mentioning (#5453).
  • Sidetags in the dropdown of the new update form are now sorted alphabetically (#5470).
  • Fixed "cannot access local variable 'tags'" error when editing flatpak updates (#5503).
  • The new update page now displays a meaningful page title (#5540).

  Contributors

  The following developers contributed to this release of Bodhi:

  • Aurélien Bompard
  • Adam Williamson
  • Jonathan Lebon
  • Lenka Segura
  • Mattia Verga
  • Owen W. Taylor
  • Ryan Lerch

December 08, 2023

• Fedora Community Blog Mindshare Committee election: Interview with Luiz Bazan

  This is a part of the Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Friday, 8 December and closes promptly at 23:59:59 UTC on Thursday, 21 December.

  Interview with Luis Bazan

  • Fedora Account: Luis Bazan
  • IRC/Nick: lbazan / LoKoMurdoK
  • Matrix Channels typically found in: fedora-latam channel and all the others
  • Fedora User Wiki Page

  
  What is your background in Fedora? What have you worked on and what are you doing now?

  I have been participating in Fedora for more than 10 years. In my country, I engage in various events, showcasing Fedora as my primary distribution and encouraging students and professionals to use it in their daily activities. I am an active contributor to the Fedora community, consistently collaborating with my fellow Fedora enthusiasts in Panama. On a Latin American scale, I have endeavored and will continue to strive to maintain my involvement, aiming to keep more people interested in this expansive community.

  Please elaborate on the personal “Why” which motivates you to be a candidate for Mindshare.

  I want to participate with the Mindshare team, contributing to the growth of Fedora. I aim to contribute to enhancing the community in every aspect and do everything I can to help improve and expand Fedora.

  How would you improve Mindshare Committee visibility and awareness in the Fedora community?

  Collaborate closely with Fedora Ambassadors to stimulate increased engagement at both local and global levels, ensuring that information about Mindshare activities is widely shared during events. Encourage Ambassadors to actively participate and promote initiatives in their respective regions.

  What part of Fedora do you think needs the most attention from the Mindshare Committee during your term?

  Enhance coordination of events, both local and global, by providing support and resources for organizers. Promote these events effectively to maximize participation.

  The post Mindshare Committee election: Interview with Luiz Bazan appeared first on Fedora Community Blog.

• Fedora Community Blog Fedora Council election: Interview with Akashdeep Dhar

  This is a part of the Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Friday, 8 December and closes promptly at 23:59:59 UTC on Thursday, 21 December.

  Interview with Akashdeep Dhar

  • Fedora Account: Akashdeep Dhar
  • IRC/Nick: t0xic0der
  • Matrix Channels typically found in: Fedora Join, Fedora Badges, Fedora Social, Fedora Infrastructure, Fedora Documentation, Fedora Network Operations Center, Fedora Release Engineering, Fedora Zodbot Development, Fedora Diversity, Equity & Inslusion, Packit, Fedora India, Fedora Marketing, Fedora App, Fedora Council, Fedora Websites and Apps, Fedora Design, Fedora EPEL, Fedora Mentoring, Fedora Badges Development, Fedora Community Operations, Fedora Mindshare, Flock To Fedora, Fedora Ask
  • Fedora User Wiki Page

  Why are you running for Fedora Council?

  Once the Fedora Websites and Apps community initiative was successfully completed with the release of Fedora Websites 3.0, I decided to go on a hiatus from community leadership positions to firstly, spend some well-deserved downtime with my family and secondly, to get back to the drawing board for identifying the aspects of the Fedora Project community that could use some assistance. Among all the issues I discovered with time, two of the most prominent ones in my opinion were incentivization and rewarding of persistent contributions and sustenance and improvement of community health. Working actively with project teams like Fedora Badges and Project Aspen in the past months, I began documenting my investigations [1] [2], designing the strategies [1] [2] and prototyping the game plan [1] [2].

  To address the community health issue, I wish to utilize the platform to continue working with the various subprojects/SIGs to understand their perspective on community health, garner the statistical metrics that govern the current condition of a community and address the concerning findings to ensure that the community health is looked after. Alongside that, I wish to act as an exemplary conduit between sponsored teams and community teams to lead the work on the Fedora Badges revamp as well as help in organizing and running events that establish the community’s presence. With my attempts to enhance the contributor’s quality of life, my purpose is to radically progress in realizing the Fedora Project Strategy Goal 2028 of “doubling the number of active contributors over a given period of time“.

  I think it is about time for me to come back from the hiatus.

  What do you see as Fedora’s place in the universe?

  Fedora Linux has been and continues to be one of the rarest upstream GNU/Linux distributions that provides its users with a balanced blend of unmatched innovation and stellar experience in a single package. An exceptional development like this can only be built by an admirable community like Fedora Project that many other free and open-source software communities can learn from. We should not only lead in the forefront when it comes to the Features and First foundations, but we should also set a cardinal example of how contributors get onboarded on a mission, collaborate for a goal and are rewarded for the efforts, thereby also leading in the forefront in the Freedom and Friends foundations and creating what might not be the largest but most definitely the most active communities in the universe.

  How can we best measure Fedora’s success?

  The success of Fedora Project is inherently connected with the health of the community. In order to ensure the excellent quality and timely releases of our GNU/Linux distribution offerings that define our success to the outside world, it is undeniably crucial to evaluate the conditions of the many subprojects/SIGs that form the overall community and ensure that the contributors behind our substantial areas are incentivized to put their best foot forward by lowering the barrier of entry for beginners ones and rewarding consistent contributions from the experienced ones.

  Anonymous statistical metrics received about the contributors like but not limited to discussions in forums, meetings in channels, contributions in repositories, accolades in badges, footfall in events, releases in packages, perception in media, responses in surveys etc., and their trends with respect to time can be a concrete indicator of inherent issues with certain subprojects/SIGs and that in turn, should help us understand tasks that need to be fulfilled in order to ensure that the success of Fedora Project is not only maintained but is growing significantly with time.

  The Fedora Council is intended to be an active working body. How will you make room for Council work?

  During my participation in the community, I have always made it a point to keep some time aside to connect and collaborate with community members irrespective of whether I am in a community leadership role or not. One of the factors that have been remarkably favourable to my participation in the community is my employment with a community-facing team that works with Fedora Project and the CentOS Project called the Red Hat Community Platform Engineering team. I am pretty sure that I will be comfortable with moving things around in my calendar to make room for the Council work.

  The post Fedora Council election: Interview with Akashdeep Dhar appeared first on Fedora Community Blog.

• Fedora Community Blog FESCo election: Interview with Zbigniew Jędrzejewski-Szmek

  This is a part of the Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Friday, 8 December and closes promptly at 23:59:59 UTC on Thursday, 21 December.

  Interview with Zbigniew Jędrzejewski-Szmek

  • Fedora Account: Zbigniew Jędrzejewski-Szmek
  • IRC/Nick: zbyszek
  • Matrix Channels typically found in: fedora-devel, fedora-python, systemd, mkosi
  • Fedora User Wiki Page

  Why do you want to be a member of FESCo and how do you expect to help steer the direction of Fedora?

  I see the role of FESCo as a place where all voices are heard so that a consensus decision can be reached. It is individual community members, SIGs, and other groups who should propose and implement changes. FESCo is the place where questions about motivation, backwards compatibility, user experience, schedules and contingency plans are asked and answered. I think it’s totally fine when the majority of decisions by FESCo is unanimous after that.

  Overall, I think Fedora is doing OK. We are consistently delivering very solid releases regularly, with latest packages, and with a number of interesting new features in each release. The release of F39 was delayed, but this can be attributed to internal Red Hat problems. I hope we’re past this and will be back on track for F40.

  To maintain the position of Fedora as the most innovative distro, we need to keep adapting and implementing big new initiatives. I would love to see Fedora more widely used, with more packages delivered more reliably. I very much support the FPL’s goal to double the number of contributors. Coincidentally, I think it’ll be easier to engage new contributors, including existing upstream maintainers, when the packaging story is streamlined.

  We have a number of initiatives that improve specific areas, but we’re not doing enough to build tools and procedures that provide a uniform and consistent experience. For example, we have rpmautospec, but it’s not universally used. We have automatic bodhi updates for rawhide, but the same functionality is not available for stable releases. We have gating, but it’s still very hard to use, with lots of false positives. Packit is being used by some packages, but it’s something on the side, only awkwardly integrated with the normal Fedora packaging infrastructure. We need to build a more coherent packaging experience so that we can do bold, innovative things in Fedora.

  How do you currently contribute to Fedora? How does that contribution benefit the community?

  I’m active in systemd upstream, and I’ve been doing systemd package maintenance in Fedora since 2013; if you’ve submitted a systemd bug in Bugzilla or in the upstream bugtracker, chances are I’ve looked at it. I maintain a few dozen packages, and I try to do new package reviews regularly (469 so far). I’ve been in FESCo since F28. I’be been involved in various initiatives, like the transition of various upstream to Python 3, mass rename of Python 2 packages during the transition to Python 3, improvements to packaging tools (rust2rpm, rpmautospec), transition of the packaging documentation from the wiki, ELF package notes, reproducible builds, updating of Packaging Guidelines for new techniques. I try to help with all aspects of packaging, but I’m especially interested in mass cleanups and automatization of various packaging processes.

  How do you handle disagreements when working as part of a team?

  Team members must trust each other and be transparent about their reasoning and motivations. If that is true, technical differences can be explained away or proven with actual code. For all this to work, the group must share a common goal.

  What else should community members know about you or your positions?

  In the same question in the interview one year ago I made a wishlist for 2023:

  • rethink how we use buildroot overrides and side tags (see fedora-devel thread started by Adam Williamson) — side-tags are now the documented way to do multi-package updates, yay!
  • really have reliable gating for package updates — gating has been enabled for rawhide critical-path updates, but in general gating needs more work. The results have too many false positives and the interface makes it hard to figure out what went wrong.
  • embrace rpmautospec — Rpmautospec by Default was accepted and the core documentation has been updated. But many people are still using the old method. If you are in that camp, please come talk to me — I would like to know what is keeping people from switching.
  • embrace SPDX license tags — this is still WIP. Miroslav Suchý and the rest of the team working on this have done extensive work, but we’re only at 60% of packages.
  • work towards reproducible builds of rpms — various ground-level pieces are in place, see the Report from the RB hackfest during Flock. We have a plan to set up a continuous rebuild for rawhide/amd64, but we’re still working on the tooling.
  • work towards unified kernel images and pre-built initrds — this one is important if we want Fedora (and derivatives) to be relevant for confidential computing and other high-security environments. We now have a kernel subpackage that delivers a UKI for VMs, but this approach is hard to scale. Lots of work was done upstream in systemd, but so far this has little effect on Fedora.

  My wishlist for 2024:

  • Clean up bodhi update gating so that false failures are infrequent and packagers start relying on the status and always consider the results.
  • Figure out how rpmautospec should be used during initial packaging and during review. The documented method before and after review must be consistent.
  • Convert 90+% of packages to SPDX license tags.
  • Set up a continuous rebuilds of rawhide/amd64 to gather statistics on build reproducibility of Fedora packages. Once the common issues have been resolved, plan towards making build reproducibility an official feature.
  • SystemdSecurityHardening
  • continue the work on Unified Kernel Images and non-dracut initrds. This year we should get a pre-built initrd as an option for normal users.

  The post FESCo election: Interview with Zbigniew Jędrzejewski-Szmek appeared first on Fedora Community Blog.

• Fedora Community Blog FESCo election: Interview with Tomas Hckra

  This is a part of the Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Friday, 8 December and closes promptly at 23:59:59 UTC on Thursday, 21 December.

  Interview with Tomas Hckra

  • Fedora Account: Tomas Hckra
  • IRC/Nick: jednorozec/humaton
  • Matrix Channels typically found in: fedora-releng, #fedora-devel, #fedora-devel, #fedora-noc
  • Fedora User Wiki Page

  Why do you want to be a member of FESCo and how do you expect to help steer the direction of Fedora?

  I believe that my perspective as a fedora release engineer can bring some new opinions into the steering process. My focus is mostly on user/contributor self-service where possible so we can remove obstacles for new people coming into the Fedora project.

  How do you currently contribute to Fedora? How does that contribution benefit the community?

  Over the last decade, I went through package maintenance and app development. Currently, I am part of the release engineering team, helping out with releases and related infrastructure work. Right now I am working on dropping the Product Definition Center from our workflows so we can reduce the complexity in our package-related processes and tooling.

  How do you handle disagreements when working as part of a team?

  Most of the team disagreements I was part of were caused by communication issues and misunderstanding of one or the other side. So I strongly believe that most problems are resolvable by listening, considering the other side, and communicating about the disagreement clearly. The next step is building consensus keeping in mind all the viewpoints that caused the conflict in the first place.

  What else should community members know about you or your positions?

  I am a full-on open-source nerd, everything in my house is running open-source SW. I am not shy of public speaking you can find some of my talks on YouTube like this one about opensource home automation: https://www.youtube.com/watch?v=HUhHaHnzhYA

  Two main ideas that define my approach to technology:
  “I want all things open and all sources shown”
  “Where is a serial console there is a way”

  The post FESCo election: Interview with Tomas Hckra appeared first on Fedora Community Blog.

• Fedora Community Blog FESCo election: Interview with Michel Lind

  This is a part of the Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Friday, 8 December and closes promptly at 23:59:59 UTC on Thursday, 21 December.

  Interview with Michel Lind

  • Fedora Account: Michel Lind (you might know me as Michel Salim previously, I changed my legal name recently)
  • IRC/Nick: michel-slm(libera), salimma (matrix)
  • Matrix Channels typically found in: I’m in many Fedora channels – including devel, epel, infra, releng, and social
  • Fedora User Wiki Page

  Why do you want to be a member of FESCo and how do you expect to help steer the direction of Fedora?

  I have been active in the Fedora community since almost the very beginning (see also the next question), and have participated in FESCo meetings from the perspective of a Change Proposal owner as well as just an observer for a few years. Given my personal and work interest in Fedora and CentOS Stream, I see being part of FESCo as the next step, and hope to add my unique perspective to the decision making process.

  How do you currently contribute to Fedora? How does that contribution benefit the community?

  I’ve been doing packaging for RPM based distros since the Red Hat Linux days, and joined Fedora early on during the Fedora Core days. I’m a proven packager and a packager sponsor, and am currently actively maintaining packages both personally and in the Rust, EPEL, Python, Lua, and (to a certain extent) Golang SIGs.

  My $dayjob at Meta pays me to contribute to Linux Userspace projects, of which Fedora is currently the main focus as the upstream to CentOS Stream and other Enterprise Linux distributions (RHEL etc.); my focus has been on automation to make bootstrapping EPEL for new Stream releases easier with tools such as ebranch and an upcoming Package of Interest tracker.

  I have landed change proposals in the past – most notably around Btrfs and systemd-oomd – and have several more in the pipeline for Fedora 40; I also suggested allowing DNF repository configuration to be overriden (added to dnf5-5.1.3)

  How do you handle disagreements when working as part of a team?

  In my experience, disagreements are often caused by misunderstandings, and I would try to clear them in one-to-one interactions whenever possible rather than having a public spat; in open source work in particular, given that the participants are often either volunteers or people working for other companies, it’s better to go slower and accommodate the concern of others rather than trying to push my ideas through before gaining consensus.

  What else should community members know about you or your positions?

  I work for Meta – which runs CentOS Stream on millions of bare metal servers and in containers. That being said, if I were to be elected I would not be representing Meta in FESCo, and instead would cast my vote with the best interest of the Fedora project itself.

  I am a parent to two cats and a toddler, and love cats and dogs equally.

  The post FESCo election: Interview with Michel Lind appeared first on Fedora Community Blog.

• Remi Collet PHP version 8.1.27RC1, 8.2.14RC1 and 8.3.1RC3

  Release Candidate versions are available in the testing repository for Fedora and Enterprise Linux (RHEL / CentOS / Alma / Rocky and other clones) to allow more people to test them. They are available as Software Collections, for a parallel installation, the perfect solution for such tests, and also as base packages.

  RPMs of PHP version 8.3.1RC3 are available

  • as base packages
    • in the remi-php83-test repository for Enterprise Linux 7
    • in the remi-modular-test for Fedora 37-39 and Enterprise Linux ≥ 8
  • as SCL in remi-test repository

  RPMs of PHP version 8.2.14RC1 are available

  • as base packages
    • in the remi-php82-test repository for Enterprise Linux 7
    • in the remi-modular-test for Fedora 37-39 and Enterprise Linux ≥ 8
  • as SCL in remi-test repository

  RPMs of PHP version 8.1.27RC1 are available

  • as base packages
    • in the remi-php81-test repository for Enterprise Linux 7
    • in the remi-modular-test for Fedora 37-39 and Enterprise Linux ≥ 8
  • as SCL in remi-test repository

  The Fedora 39,  EL-8 and EL-9 packages (modules and SCL) are available for x86_64 and aarch64.

  PHP version 8.1 is now in security mode only, so this is the last RC.

  Installation: follow the wizard instructions.

  Parallel installation of version 8.3 as Software Collection:

  yum --enablerepo=remi-test install php83

  Parallel installation of version 8.2 as Software Collection:

  yum --enablerepo=remi-test install php82

  Parallel installation of version 8.1 as Software Collection:

  yum --enablerepo=remi-test install php81

  Update of system version 8.3 (EL-7) :

  yum --enablerepo=remi-php83,remi-php83-test update php\*

  or, the modular way (Fedora and EL ≥ 8):

  dnf module reset php
  dnf module enable php:remi-8.3
  dnf --enablerepo=remi-modular-test update php\*

  Update of system version 8.2 (EL-7) :

  yum --enablerepo=remi-php82,remi-php82-test update php\*

  or, the modular way (Fedora and EL ≥ 8):

  dnf module reset php
  dnf module enable php:remi-8.2
  dnf --enablerepo=remi-modular-test update php\*

  Update of system version 8.1 (EL-7) :

  yum --enablerepo=remi-php81,remi-php81-test update php\*

  or, the modular way (Fedora and EL ≥ 8):

  dnf module reset php
  dnf module enable php:remi-8.1
  dnf --enablerepo=remi-modular-test update php\*

  Notice:

  • version 8.3.1RC3 is also in Fedora rawhide for QA
  • EL-9 packages are built using RHEL-9.3
  • EL-8 packages are built using RHEL-8.9
  • EL-7 packages are built using RHEL-7.9
  • oci8 extension uses the RPM of the Oracle Instant Client version 21.12 on x86_64 or 19.19 on aarch64
  • intl extension uses libicu 73.2
  • RC version is usually the same as the final version (no change accepted after RC, exception for security fix).
  • versions 8.1.27, 8.2.14 and 8.3.1 are planed for December 21th, in 2 weeks.

  Software Collections (php81, php82, php83)

  

  

  

  Base packages (php)

  

  

  

December 07, 2023

• Peter Robinson Any Linux distro on NVIDIA Jetson Orin with JetPack 6

  NVIDIA has just released the Jetpack 6 Developer Preview for the NVIDIA Jetson Orin hardware. The thing that is most exciting about this release is they finally support the ability to use upstream kernels and other Linux distributions. This means you can start to use both RHEL (9.3 and later) and Fedora on the Jetson Orin hardware! This has been a LONG time coming, something I’ve been involved with for 5 years!

  So while this is a developer preview, AKA public Beta, it’s still very usable and for people that are interested in using other Linux distributions now is the time to get stuck in. Like all things it’s not perfect and there’s still work to be done, but many hands do make light work!

  You start by downloading the BSP from there you can follow the following instructions and you should end up with a device you can easily install Fedora 39 or RHEL 9.3 or other distros with the appropriate bits enabled.

  To flash the firmware you need to follow the Orin AGX guide for recovery and cabling, for Orin NX/nano you need to use the HW pins near the mSD card, to put the device in recovery mode and cabling then do the following for Orin AGX:

  $ tar zvf Jetson_Linux_R36.2.0_aarch64.tbz2
  $ cd Linux_for_Tegra/
  $ lsusb|grep -i nv
  Bus 003 Device 044: ID 0955:7045 NVIDIA Corp. [unknown]
  Bus 003 Device 045: ID 0955:7023 NVIDIA Corp. [unknown]
  $ sudo ./flash.sh p3737-0000-p3701-0000-qspi external
  removed a lot of output
  *** The target generic has been flashed successfully. ***
  Make the target filesystem available to the device and reset the board to boot from external external.
  $
  

  The command for other Orin devices such as NX and Nano will be similar, you’ll just have to swap the p3737 variable, eg for Orin Nano use: sudo ./flash.sh p3737-0000-p3701-0000-qspi external.

  Once the flash completes the device will reboot and you will be able to use the usual mechanisms to install your OS, whether the RHEL or Fedora installers or a Fedora Arm image. I’ve tested running OSes off both the microSD and a NVME card, plus installing off USB, the DisplayPort output should work in EFI console mode. The firmware is based upon the widely known TianoCore/EDK2 so the firmware interface should be straight forward. For those that may need a serial console if it’s not automatically detected you can use console=ttyAMA0,115200, This runs off the microUSB port on /dev/ttyACM2 on the host device.

  For hardware vendors that have hardware based on the NVIDIA Orin hardware they will be able to adopt and make this available to their customers that may wish to run distributions other than L4T. If they are unsure feel free to reach out to me in the usual locations.

• Felipe Borges GNOME will have two Outreachy interns working on implementing end-to-end tests for GNOME OS using openQA

  We are happy to announce that GNOME is sponsoring two Outreachy internship projects for the December 2023 to March 2024 Outreachy internship round where they will be working on implementing end-to-end tests for GNOME OS using openQA.

  Dorothy Kabarozi and Tanjuate Achaleke will be working with mentors Sam Thursfield and Sonny Piers.

  Stay tuned to Planet GNOME for future updates on the progress of this project!

  This is a repost from https://discourse.gnome.org/t/announcement-gnome-will-have-two-outreachy-interns-working-on-implementing-end-to-end-tests-for-gnome-os-using-openqa

December 06, 2023

• Richard Hughes 100 Million Firmware Updates Supplied By The LVFS

  The LVFS has now supplied over 100 million updates to Linux machines all around the globe. The true number is unknown, as we allow users to re-distribute updates without any kind of tracking, and also allow large companies or agencies to mirror the entire LVFS so the archive can be used offline. The true number of updates deployed will probably be a lot higher. Just 8 years ago Red Hat asked me to “make firmware updates work on Linux” and now we have a thriving set of projects that respect both your freedom and your privacy, and a growing ecosystem of hardware vendors who consider Linux users first class citizens. Every month we have two or three new vendors join; the logistical, security and most importantly commercial implications of not being “on the LVFS” are now too critical for IHVs, ODMs and OEMs to ignore.

  Red Hat can certainly take a lot of credit for the undeniable success of LVFS and fwupd, as they have been paying my salary and pushing me forward over the last decade and more. Customer use of fwupd and LVFS is growing and growing – and planning for new fwupd/LVFS device support now happens months in advance to ensure fwupd is ready-to-go in long term support distributions like Red Hat Enterprise Linux. With infrastructure supplied and support paid for by the Linux Foundation, the LVFS really has a stable base that will be used for years to come.

  

  As the number of devices supported by the LVFS goes up and up every week, and I’m glad that the community around fwupd is growing at the same pace as the popularity. Google and Collabora have also been amazing partners in encouraging and helping vendors to ship updates on the LVFS and supporting fwupd in ChromeOS — and their trust and support has been invaluable. I’m also glad the “side-projects” like “GNOME Firmware“, “Host Security ID“, “fwupd friendly firmware” and “uSWID as a SBoM format” also seem to be flourishing into independent projects in their own right.

  Everybody is incredibly excited about the long term future of both fwupd and the LVFS and I’m looking forward to the next 100 million updates. A huge thank you to all that helped.

• Kiwi TCMS Feature showcase: Personal API tokens

  For a long time now Kiwi TCMS has supported integration with external issue tracking systems, such as JIRA. This integration is usually configured via bot accounts and their respective credentials and our flagship functionality is 1-click bug report! This is how it looks like:

  • For any TestExecution click on the menu in the corner

  • Select an existing Issue Tracker configuration and click Report bug

  • Your browser will open a new window with the resulting report inside the external Issue Tracker

  Notice that Reporter (field 1) is kiwitcms-bot although the currently logged in user (field 2) is different. The Reporter text reference (field 3) is the full name of the tester working on the Kiwi TCMS side and may not match neither of fields 1 and 2! This presents a challenge if you are tracking any metrics based on the actual Reporter field in JIRA.

  The new Personal API tokens functionality allows Kiwi TCMS users to override existing issue tracker configurations with their own API credentials. Here's how it works:

  • In JIRA click on your account and select Manage account

  • Then select the Security tab

  • Then click on Create and manage API tokens

  • And create a new API token; Copy the token value for use inside Kiwi TCMS!

  • From the Kiwi TCMS navigation menu select PLUGINS -> Personal API tokens

  • Select an existing Issue Tracker via its URL and fill-in your credentials. For JIRA api_username is your JIRA email and api_password is your JIRA API token. Other issue trackers may only require the api_password field. The meaning of these fields can be found in documentation for each different type of issue tracker that Kiwi TCMS can integrate with

  • Repeat the 1-click bug report steps shown in the beginning. Your browser will open a new window with the resulting report inside JIRA

  Notice that Reporter (field 1), the currently logged in user (field 2) and the Reporter text reference (field 3) now represent the same person!

  Happy Testing!

  ---

  If you like what we're doing and how Kiwi TCMS supports various communities please help us!

  • Give â­� on GitHub;
  • Give ğŸ‘� on GitLab;
  • Donate via Open Collective as low as 1 EUR;
  • Join our newsletter and follow all project news;
  • Become a contributor and an awesome open source hacker;
  • Become a customer and we'll share our profits with the community

December 05, 2023

• Gwyn Ciesla Minetest 5.8.0

  Minetest 5.8.0 is coming to Rawhide and Fedora 39.

  The biggest change users should be aware of is that the Minetest Game is no longer shipped with the engine by upstream, and this is reflected in the #fedora packaging as well. At first run, desktop users will be asked if they’d like to re-download the Minetest game, which is needed to play previously created worlds that use it.

  For servers, this process is less straightforward. For that reason, we now place the Minetest Game in the appropriate place in minetest server user’s home folder, as part of the server RPM. This allows for a more seamless upgrade process.

  I’ve tested all of this on my local and server worlds, and everything works perfectly. If you test it and find the same, please give the update some karma. If not, let me know.

  https://bodhi.fedoraproject.org/updates/FEDORA-2023-877949f206

  Additionally, Minetest is in the Fediverse, at @Minetest.

• Peter Robinson Getting started with OpenCL using mesa/rusticl

  Mesa, the open source low level graphics stack, has featured support for Open Compute Language (OpenCL) for some time via a front end called Clover. The problem was that the GPUs that it supported were limited, it didn’t have Image support, and wasn’t really under active development. Around a year ago Karol Herbst filed a merge request adding rusticl to Mesa 22.3 release, and soon after that I enabled it optionally in Fedora.. What is rusticl? It’s a OpenCL API implementation written in rust for Mesa, it will eventually replace clover. One advantage it has is image support from the outset and also works on much wider range of OpenCL capable GPUs, including some ARM GPUs, and the support is actively improving all the time.

  In the year since it landed in a stable mesa release rusticl keeps evolving, faster, more HW support, more features, less crashes. I’ve tinkered with it as I’ve had spare time on the weekends and evenings as well as trying to work out details of how you’d use it to run higher level stacks.

  As of writing it works with following gallium drivers: iris (Intel), nouveau (Nvidia), radeonsi/r600 (AMD ATI), and panfrost (Arm MALI). There’s other drivers that are various stages of development but are not yet upstream.

  So let’s get the basics up and running on Fedora if you have supported hardware. First install the core software stack:

  $ sudo dnf install -y mesa-libOpenCL mesa-dri-drivers spirv-llvm-translator spirv-tools-libs clinfo clpeak
  

  Next we run clinfo and clpeak with required parameters, from the driver names above (in this case an Intel laptop), to enable rusticl. The two commands output a lot of information so I’m not going to post them here but the output shows OpenCL running and some details about what’s supported:

  $ RUSTICL_ENABLE=iris clinfo --list
  WARNING: OpenCL support via iris+clover is incomplete.
  For a complete and conformant OpenCL implementation, use
  https://github.com/intel/compute-runtime instead
  Platform #0: rusticl
   `-- Device #0: Mesa Intel(R) Xe Graphics (TGL GT2)
  Platform #1: Portable Computing Language
   `-- Device #0: cpu-11th Gen Intel(R) Core(TM) i7-1185G7 @ 3.00GHz
  Platform #2: Clover
  $ RUSTICL_ENABLE=iris clinfo
  output a lot of details
  $ RUSTICL_ENABLE=iris clpeak
  output a lot of details
  

  This gets up the basic pieces up and running for OpenCL, there’s of course more to do and not all use cases are complete. Eventually we won’t need to have the environment variables to enable rusticl. The details of drivers and other features enabled by environment variables are documented here. I plan to do some more posts as follow ups to build on this basis.

• Daniel Vrátil QCoro 0.10.0 Release Announcement

  QCoro 0.10.0 Release Announcement

  Thank you to everyone who reported issues and contributed to QCoro. Your help is much appreciated!

  Support for awaiting Qt signals with QPrivateSignal

  Qt has a feature where signals can be made “private” (in the sense that only class that defines the signal can emit it) by appending QPrivateSignal argument to the signal method:

  class MyObject : public QObject {
      Q_OBJECT
  ...
  Q_SIGNALS:
      void error(int code, const QString &message, QPrivateSignal);
  };
  

  QPrivateSignal is a type that is defined inside the Q_OBJECT macro, so it’s private and as such only MyObject class can emit the signal, since only MyObject can instantiate QPrivateSignal:

  void MyObject::handleError(int code, const QString &message)
  {
      Q_EMIT error(code, message, QPrivateSignal{});
  }
  

  QCoro has a feature that makes it possible to co_await a signal emission and returns the signals arguments as a tuple:

  
  MyObject myObject;
  const auto [code,  message] = co_await qCoro(&myObject, &MyObject::handleError);
  

  While it was possible to co_await a “private” signal previously, it would get return the QPrivateSignal value as an additional value in the result tuple and on some occasions would not compile at all.

  In QCoro 0.10, we can detect the QPrivateSignal argument and drop it inside QCoro so that it does not cause trouble and does not clutter the result type.

  Achieving this wasn’t simple, as it’s not really possible to detect the type (because it’s private), e.g. code like this would fail to compile, because we are not allowed to refer to Obj::QPrivateSignal, since that type is private to Obj.

  template<typename T, typename Obj>
  constexpr bool is_qprivatesignal = std::same_as_v<T, typename Obj::QPrivateSignal>;
  

  After many different attempts we ended up abusing __PRETTY_FUNCTION__ (and __FUNCSIG__ on MSVC) and checking whether the function’s name contains QPrivateSignal string in the expected location. It’s a whacky hack, but hey - if it works, it’s not stupid :). And thanks to improvements in compile-time evaluation in C++20, the check is evaluated completely at compile-time, so there’s no runtime overhead of obtaining current source location and doing string comparisons.

  Source Code Reorganization (again!)

  Big part of QCoro are template classes, so there’s a lot of code in headers. In my opinion, some of the files (especially qcorotask.h) were getting hard to read and navigate and it made it harder to just see the API of the class (like you get with non-template classes), which is what users of a library are usually most interested in.

  Therefore I decided to move definitions into separated files, so that they don’t clutter the main include files.

  This change is completely source- and binary-compatible, so QCoro users don’t have to make any changes to their code. The only difference is that the main QCoro headers are much prettier to look at now.

  Bugfixes

  • QCoro::waitFor() now re-throws exceptions (#172, Daniel Vrátil)
  • Replaced deprecated QWebSocket::error with QWbSocket::errorOccured in QCoroWebSockets module (#174, Marius P)
  • Fix QCoro::connect() not working with lambdas (#179, Johan Brüchert)
  • Fix library name postfix for qmake compatibilty (#192, Shantanu Tushar)
  • Fix std::coroutine_traits isn't a class template error with LLVM 16 (#196, Rafael Sadowski)

  Full changelog

  See changelog on Github

• Peter Czanik Syslog-ng can now do a full configuration check

  One of the most frequent syslog-ng feature requests is now resolved. Welcome the --check-startup option, allowing you to check the syntax and also spot spelling mistakes!

  Before you begin

  To use the --check-startup option, you need version 4.5.0 or later of syslog-ng. If your favorite operating system does not have it yet, you can check https://syslog-ng.org/3rd-party-binaries/ if there are ready-to-use third-party syslog-ng packages for your OS.

  Testing

  Once you have syslog-ng 4.5.0 or later up and running, testing the new feature is easy. Just create a typo in your configuration and check it. If you use the good old -s option, it will not spot the typo, as it only checks for syntax errors:

  [root@fedora ~]# syslog-ng -s
  [root@fedora ~]#

  However, if you run syslog-ng using the new --check-startup option, you will immediately see the difference:

  [root@fedora ~]# syslog-ng --check-startup
  Error resolving reference; content='destination', name='d_fajl', location='/etc/syslog-ng/conf.d/otel.conf:15:21'
  [root@fedora ~]#

  In this example, --check-startup found one of my typical problems: mixing the English and Hungarian spelling of the same word…

  False positives

  When you use the --check-startup option, syslog-ng does a full initialization to catch any errors. This, however, has a side effect: if the configuration includes a network source which is in use by a running syslog-ng instance, then syslog-ng will throw an error message, even if the configuration itself does not have any problems:

  [root@fedora ~]# syslog-ng --check-startup
  Error binding socket; addr='AF_INET(0.0.0.0:514)', error='Address already in use (98)'
  Error initializing message pipeline; plugin_name='tcp', location='/etc/syslog-ng/conf.d/otel.conf:2:3'
  [root@fedora ~]#

  In practice, this probably means that you cannot use the --check-startup option in a script. However, even with this limitation, this new option allows you to spot spelling mistakes before adding new configurations to your live environment, minimizing downtime.

  What is next?

  With a bit of extra work, you might be able to create a script which detects false positives, like network ports already in use.

  -

  If you have questions or comments related to syslog-ng, do not hesitate to contact us. You can reach us by email or even chat with us. For a list of possibilities, check our GitHub page under the “Community” section at https://github.com/syslog-ng/syslog-ng. On Twitter, I am available as @PCzanik, on Mastodon as @Pczanik@fosstodon.org.

• Matthew Garrett Why does Gnome fingerprint unlock not unlock the keyring?

  There's a decent number of laptops with fingerprint readers that are supported by Linux, and Gnome has some nice integration to make use of that for authentication purposes. But if you log in with a fingerprint, the moment you start any app that wants to access stored passwords you'll get a prompt asking you to type in your password, which feels like it somewhat defeats the point. Mac users don't have this problem - authenticate with TouchID and all your passwords are available after login. Why the difference?
  
  Fingerprint detection can be done in two primary ways. The first is that a fingerprint reader is effectively just a scanner - it passes a graphical representation of the fingerprint back to the OS and the OS decides whether or not it matches an enrolled finger. The second is for the fingerprint reader to make that determination itself, either storing a set of trusted fingerprints in its own storage or supporting being passed a set of encrypted images to compare against. Fprint supports both of these, but note that in both cases all that we get at the end of the day is a statement of "The fingerprint matched" or "The fingerprint didn't match" - we can't associate anything else with that.
  
  Apple's solution involves wiring the fingerprint reader to a secure enclave, an independently running security chip that can store encrypted secrets or keys and only release them under pre-defined circumstances. Rather than the fingerprint reader providing information directly to the OS, it provides it to the secure enclave. If the fingerprint matches, the secure enclave can then provide some otherwise secret material to the OS. Critically, if the fingerprint doesn't match, the enclave will never release this material.
  
  And that's the difference. When you perform TouchID authentication, the secure enclave can decide to release a secret that can be used to decrypt your keyring. We can't easily do this under Linux because we don't have an interface to store those secrets. The secret material can't just be stored on disk - that would allow anyone who had access to the disk to use that material to decrypt the keyring and get access to the passwords, defeating the object. We can't use the TPM because there's no secure communications channel between the fingerprint reader and the TPM, so we can't configure the TPM to release secrets only if an associated fingerprint is provided.
  
  So the simple answer is that fingerprint unlock doesn't unlock the keyring because there's currently no secure way to do that. It's not intransigence on the part of the developers or a conspiracy to make life more annoying. It'd be great to fix it, but I don't see an easy way to do so at the moment.
  
  comments

• Zach Oglesby

  Finished reading: No Time Like The Past by Jodi Taylor 📚

  Halfway through the series, still enjoying it.

December 04, 2023

• Charles-Antoine Couret Fedora Linux 37 tire sa révérence

  C'est en ce mardi 5 décembre 2023 que la maintenance de Fedora Linux 37 prend fin.

  Qu'est-ce que c'est ?

  Un mois après la sortie d'une version de Fedora n, ici Fedora Linux 39, la version n-2 (donc Fedora Linux 37) n'est plus maintenue.

  Ce mois sert à donner du temps aux utilisateurs pour faire la mise à niveau. Ce qui fait qu'en moyenne une version est officiellement maintenue pendant 13 mois.

  En effet, la fin de vie d'une version signifie qu'elle n'aura plus de mises à jour et plus aucun bogue ne sera corrigé. Pour des questions de sécurité, avec des failles non corrigées, il est vivement conseillé aux utilisateurs de Fedora Linux 37 et antérieurs d'effectuer la mise à niveau vers Fedora Linux 39 ou 38.

  Que faire ?

  Si vous êtes concernés, il est nécessaire de faire la mise à niveau de vos systèmes. Vous pouvez télécharger des images CD ou USB plus récentes.

  Il est également possible de faire la mise à niveau sans réinstaller via DNF ou GNOME Logiciels.

  GNOME Logiciels a également dû vous prévenir par une pop-up de la disponibilité de Fedora Linux 39 ou 38. N'hésitez pas à lancer la mise à niveau par ce biais.

• The NeuroFedora Blog Next Open NeuroFedora meeting: 04 December 1300 UTC

  

  Photo by William White on Unsplash.

  
  

  Please join us at the next regular Open NeuroFedora team meeting on Monday 04 December at 1300 UTC. The meeting is a public meeting, and open for everyone to attend. You can join us over:

  • Matrix

  You can use this link to convert the meeting time to your local time. Or, you can also use this command in the terminal:

  $ date --date='TZ="UTC" 1300 2023-12-04'
  

  The meeting will be chaired by @ankursinha. The agenda for the meeting is:

  • New introductions and roll call.
  • Tasks from last meeting.
  • Open Pagure tickets.
  • Package health check.
  • Open package reviews check.
  • CompNeuro lab compose status check for Fedora 40/rawhide.
  • Neuroscience query of the week
  • Next meeting day, and chair.
  • Open floor.

  We hope to see you there!

• Josh Bressers Episode 405 – Modding games isn’t cheating and security isn’t fair

  Josh and Kurt talk about Capcom claiming modding a game is akin to cheating. The arguments used are fundamentally one of equity vs equality. Humans love to focus on equality instead of equity when we deal with most problems. This is especially true in the world of security. Rather than doing something that has a net positive, we ignore the details and focus on doing something that feels “right”.

  Show Notes

  • Why Capcom thinks PC game modding is akin to “cheating”
  • Ben Heck

December 03, 2023

• Kevin Fenzi Asus Hyper m.2 Gen 4 card review

  

  Last year I upgraded my main server from an old 1u cloud box to a new Ryzen Quiet PC. The motherboard has 2 nvme slots on it and I filled them up and mirrored them for the OS and vm storage, but my main storage setup (music, video, backups, etc) was/is a RAID of old 7200rpm spinning SATA drives. At the time I just moved it to the new sever with a note to replace it later. Recently one of the drives completely died, so I knew it was time.

  I picked up a https://www.asus.com/us/motherboards-components/motherboards/accessories/hyper-m-2-x16-gen-4-card/helpdesk_knowledge?model2Name=Hyper-M-2-x16-Gen-4-Card. This is a pcie gen4 x16 card that has slots for 4 nvme drives on it. My plan was to fill it up and raid those drives for storage and completely replace the old spinning drives.

  The card was ~75$, but I see it’s dropped to ~58$ now. The card is well made and solid. It has a really quick massive heat sink and a small fan (which you can enable/disable with a switch on the back). It also has lights on the back to show activity on each of the drives.

  First, to use this card and see all 4 nvme drives, your motherboard MUST support pcie bifurcation. This means it has to have a setting to take a x16 card and split it into 4 x4 ‘lanes’. I made sure the one I got did, but even so there’s some caveats that I ran into. First, on my MB, only the first x16 pcie slot can be set for x4x4x4x4, so the Hyper card must go there. With the Hyper card in pcie slot 1, and video card in slot 2, it would only do x8x8 on the first slot (so, only 2 drives of 4 are seen). Unfortunately I was unable to move the video card to the 3rd x16 slot because the heat sink on it was too large and would try and occupy the same space as a power connector. In fact, no video card I could find would fit in that slot due to the power connector. So, first, I just booted with no video card at all. Blindly typing my luks passphrases isn’t much fun, but it worked and all 4 nvme drives are seen just fine.

  So, after looking around a great deal, I finally found a x1 video card (my MB has 2 x1 slots. one of which I was using for a network card). Its mentioned in this Phoronix review: https://www.phoronix.com/review/asus-50-gpu Sadly, it’s a nvidia based card “NVIDIA Corporation GK208B [GeForce GT 730]” but it’s the only x1 card I could find at all. I also don’t need 4 HDMI outputs, only one, but oh well. I got the card last week and put it in. Sadly it didn’t seem to work, but I realized the second x1 slot has a cooling baffle right after it, and the card wasn’t fully able to insert. So, I swapped it with the network card in the other slot and Success! Everything comes up right. (Aside the network card changing it’s name due to ‘predictable network names’ and messing up the bridge it was supposed to be on, but that was easy to fix).

  Cooling seems pretty nice on the card. The drives are at about 49C idle, and when syncing a few TB of data to them they only ever crept up to about 53C. High temp on these drives is 89.8C. I managed to pick up 4 4TB drives with a pretty good deal due to sales last week. Performance is great! As soon as I finish syncing content off I am looking forward to powering off the old spinning drives and retiring them.

  If you’re looking to add some more nvme storage and your MB supports the bifrucation settings needed, this is a pretty nice little card and storage expansion option.

• Daniel Pocock Debian trademark canceled

  In November, I submitted a request to the Swiss intellectual property office to cancel the Debian trademark registration. In the request, I noted that the main reason for cancelation is my lack of confidence in the Swiss legal system. This is explained in much more detail in my earlier blog about Parreaux, Thiebaud & Partners / Justicia SA.

  The fact that a small group of lawyers decided to fly too close to the sun is not very dramatic if it happened in isolation. What makes this case so outrageous is that the practices of Parreaux, Thiebaud & Partners were known to the bar associations for a number of years and yet the rogue firm continued trading. News reports told us they had 450 clients in 2018. A LinkedIn post from Mr Parreaux tells us he had 20,000 clients when the financial regulator shut him down in 2023. How many of those 20,000 clients could have been saved if the bar association and FINMA had acted two years earlier in 2021? They knew and they failed to protect the public and small businesses.

  In every other industry, ethical disputes such as this can be escalated to the judiciary. For example, if there are disputes about a doctor or an airline pilot, they may initially resolve the matter within a professional body or they may escalate the dispute into the courts. The legal profession is unique in that it is the only profession that regulates itself. If lawyers can not resolve misconduct within their own ranks, there is no other profession who can come in and do it for them.

  The only example that is remotely similar is that of the Catholic Church, where they decided they could ignore national regulations about abuse and investigate the complaints under Cannon Law. They even published the Crimen Sollicitationis, their own secret Code of Conduct for investigating abuse. Crimen Sollicitationis tells bishops that abuse cases should be kept hidden. We see exactly the same thing in Switzerland where FINMA published a verdict that redacts the names of the rogue lawyers so clients would be unlikely to ever find it.

  

  While concern about the integrity of the Swiss legal profession is a significant factor in my decision to cancel the trademark, I want to emphasize one other point from the attempts to censor various web sites using the UDRP. In each of the censorship cases, aggressors have argued that independent web sites run the risk of tarnishing the trademark. In the case of Debian, I can't think of anything that tarnishes the trademark more than the repeated deaths of volunteers, including the volunteer who resigned to commit suicide on the Debian Day anniversary and in the middle of the 2023 legal vendettas, in the middle of the Debian annual conference DebConf23, another volunteer died in avoidable circumstances. Given the enormous damage that these avoidable deaths do to both the brand and the community, it feels absurd to spend money fighting over whether some independent web site has tarnished the trademark too.

  If you have registered domain names containing the Debian trademark then it is recommended that you seek advice about whether your web site content meets the criteria for legitimate interests under the UDRP or similar fair use frameworks that apply in your jurisdiction. The judgment about the Scientologie.org domain name provides an interesting example where the right of copyright interests was deemed to be superior to the trademark rights. As all Debian Developers have copyright interests in our work, the Scientologie.org precedent gives us a strong defence against malicious UDRP cases.

  From a practical perspective, if the Scientologie.org precedent authorizes legitimate interest and fair use web sites using the Debian domain name then it feels wasteful to spend large amounts of time and money arguing over which authors can have a trademark registration.

  The ball is now in Jonathan Carter's court to decide whether he wants to continue vendettas into 2024 or whether he wants to use the Christmas season as an opportunity to bury the hatchet and stop attacking my family and I. Rogue elements of the Debian community began attacking my family at a time when I lost two family members. It reflects something uniquely bad about Debian culture and leadership.

• Fedora fans آموزش نصب Docker در فدورا لینوکس

  

   

   

   

  Docker یک پلتفرم متن باز برای برنامه نویسان، توسعه دهندگان و مدیران سیستم جهت بنا کردن، توزیع و اجرای برنامه های کاربردی می باشد. در واقع Docker یک مجازی ساز در لایه سیستم عامل یا به عبارتی Container Virtualization Technology می باشد که کار توسعه و اجرای برنامه ها را بسیار سریعتر کرده است. اکنون در این مطلب قصد داریم تا داکر (Docker) را بر روی توزیع فدورا لینوکس نصب کنیم.

  ابتدا بسته های قدیمی را حذف کنید :

   

  # dnf remove docker \
  docker-client \
  docker-client-latest \
  docker-common \
  docker-latest \
  docker-latest-logrotate \
  docker-logrotate \
  docker-selinux \
  docker-engine-selinux \
  docker-engine

  اکنون بسته ی dnf-plugins-core را که برای مدیریت مخازن DNF می باشد را نصب کنید :

   

  # dnf -y install dnf-plugins-core

   

  اکنون مخزن Docker را به سیستم اضافه کنید:

  # dnf config-manager --add-repo https://download.docker.com/linux/fedora/docker-ce.repo

   

   

   

  اکنون برای نصب Docker می توانید دستور پایین را اجرا کنید:

   

  # dnf install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

   

  پس از نصب Docker اکنون برای start کردن سرویس Docker کافیست تا دستور پایین را اجرا کنید:

   

  # systemctl start docker

  برای اینکه سرویس Docker هنگام Boot شدن سیستم به صورت خودکار اجرا شود کافیست تا دستور پایین را اجرا کنید:

   

  # systemctl enable docker

   

  اکنون برای بررسی وضعیت سرویس Docker می توانید دستور پایین را اجرا کنید:

  # systemctl status docker

  جهت بررسی موفقت امیز بودن نصب Docker  می توانید Image با نام hello-world را اجرا کنید:

   

  # docker run hello-world

   

  این دستور یک Image آزمایشی را دانلود کرده و در یک کانتینر (container) اجرا می کند. هنگامی که کانتینر اجرا می شود، یک پیام تأیید چاپ می کند و خارج می شود.

   

  امید است تا از این مطلب استفاده لازم را برده باشید.

  The post آموزش نصب Docker در فدورا لینوکس first appeared on طرفداران فدورا.

December 02, 2023

• Ankur Sinha "FranciscoD" Vit aliases to view tasks over different periods

  I use Vit as a terminal interface to view my Taskwarrior tasks. In a terminal, that's just running the vit command. Sometimes, one doesn't want to look at the full list, though. I usually have a few "views" of my tasks which give me a better idea of my work load. I add them to my ~/.bashrc so they're available as commands. Here they are. They're very simple, and should be modified to suit one's workflow:

  # filters common to all functions
  TASK_FILTERS=""
  # all tasks
  vit-tl ()
  {
      vit ${TASK_FILTERS}
  }
  # tasks due before the end of the day
  vit-tl-today () {
      vit ${TASK_FILTERS} 'due.by:eod'
  }
  # tasks due before the end of the week
  vit-tl-this-week () {
      vit ${TASK_FILTERS} 'due.by:eow'
  }
  # tasks due before the end of the month
  vit-tl-this-month () {
      vit ${TASK_FILTERS} 'due.by:eom'
  }
  # tasks due in a week
  vit-tl-in-a-week () {
      vit ${TASK_FILTERS} 'due.by:1w'
  }
  # tasks due in a month
  vit-tl-in-a-month () {
      vit ${TASK_FILTERS} 'due.by:1m'
  }
  # tasks due in six months
  vit-tl-in-six-months () {
      vit ${TASK_FILTERS} 'due.by:6m'
  }
  # tasks due in a year
  vit-tl-in-a-year () {
      vit ${TASK_FILTERS} 'due.by:1y'
  }
  # next N tasks (2 by default)
  vit-next () {
      echo "Active tasks:"
      echo
      task active
      echo
      echo
      echo "Next ${1:-2} tasks:"
      echo
      task ${TASK_FILTERS} limit:"${1:-2}"
      echo
      echo
  }
  

• William Brown Webauthn Attestation and OpenSource Keys

  Webauthn Attestation and OpenSource Keys

  Webauthn (Passkeys) are only going to become more important in the future and as this grows, deployments with higher security risks and criticality are going to need to start to understand and embrace attestation of their keys.

  In their current form, almost all software products and IDM's today allow you to enroll any cryptographic authenticator. It doesn't matter what make or model it is, it will be allowed.

  However, not all authenticators are made equal. They each have different properties, security features, and some even have security issues affecting their hardware or software. Because webauthn is a self contained multiple factor authenticator, this means we need to be even more careful to ensure these devices are secure.

  To manage this deployments can attest keys during enrollment. Attestation is a cryptographic proof of origin that proves the device is of a certain make and model. This allows us to select which devices we allow - and which we don't.

  Threat Modelling

  To make an informed determination about what keys we should allow in our IDM we have to assess our individual risks. Generally we want to consider the damage from a compromised authenticator.

  When I'm inside my home network going to control my house lightbulbs, that's quite low risk. Private network, with little consequences of damage.

  For my personal email, compromise would represent a huge amount of personal damage as email is so critical to individual account security.

  If the release engineers in a linux distribution were compromised for example, that could lead to malware being distributed in the distribution aftecting thousands of people. Similar for developers of opensource where compromise of their credentials can lead to bugdoors being injected into code.

  Authenticator Risks

  Because of this, we need to consider the possible threat vectors against authenticators, and how an authenticator may become compromised.

  A problem here is that in Webauthn attestation, firmware versions are not (currently) included. This means that if any model or version of an authenticator's software or hardware is compromised, that all versions of that device must be considered compromised. This raises the bar for vendors to be sure they "get it right" when they ship a device the first time.

  Physical Attacks

  This is the most obvious one. It can occur either in transit as the device is sent to you, or it can occur when the device is in your possesion.

  Mitigations are tamper evident packaging (transit only), tamper evident features on the device, or device construction that requires destruction actions to open.

  Local Software Attacks

  Rather than attacking the device physically, the device may be attacked locally via it's interfaces such as USB, NFC or Bluetooth. This leaves no physical evidence, but can still allow compromise of a device if physical access is obtained.

  Mitigations are tamper evident packaging (to prevent transit software attacks), and software hardening and use of memory safe languages.

  Remote Software Attacks

  This is the most nefarious class, where a device can be compromised by it being connected to your machine as it visits a webpage. This is due to weaknesses in it's software via it's CTAP interface.

  Mitigations are software hardening, auditing for hidden vendor commands, and devices ensuring that any out of band management is never performed via the CTAP interface (it must be a seperate channel).

  Cryptographic Failures

  This is a failure of the devices programming or hardware during cryptographic operations allowing private keys to be removed from the secure enclave that exists inside the device.

  Mitigations are in the hands of vendors requiring detailed audits and work to ensure their software is not vulnerable.

  External Certification Bodies

  FIDO who certifies authenticators publishes a metadata service that shows details about various authenticators and their assessments. These can be found on the mds service site.

  The MDS defines multiple certification levels for devices. These are defined on fido's site.

  Currently the best reference for an overview is the table of authenticator hardware examples.

  We have a tool for querying this data as part of webauthn-rs

  What Authenticator Do You Recommend?

  Yubikey 5 Series

  These are the gold standard, and have all the best features here.

  • Tamper evident packaging
  • Hardware that can not be opened without destruction
  • Hardened software to prevent local compromise
  • No hidden vendor commands in CTAP preventing remote compromise
  • Audits of their cryptographic processors to ensure they are high quality
  • FIPS variant meets L2 FIDO criteria - the highest level currently granted by FIDO
    • Non FIPS variants are the same HW, so should be able to achieve L2 as well in future

  Token2 T2F2

  Runner up - this is the only other authenticator we have found with high quality tamper resitent features.

  • No tamper evident packaging
  • Hardware that can not be opened without destruction
  • Hardened software to prevent local compromise
  • No hidden vendor commands in CTAP preventing remote compromise

  So What About OpenSource Authenticators?

  There are two major brands that I am aware of. Nitrokey and Solokey.

  Sadly both have issues, meaning I advise against their use.

  Solokey

  Solokey is the only opensource authenticator with a FIDO certification. They are built with an epoxy over their main circuits to highlight if these are altered. This is a great level of tamper resistence.

  The solokey is based on an LPC55S69 which unfortunately means it has been affected by a trust chain bypass. As a result NXP have had to issue new board revisions to resolve this, but it's not clear when you own a solokey if you have an affected revision or not. Since webauthn can't distinguish firmware versions either, it's also impossible to tell if a device has been fully software updated.

  In summary

  • No tamper evident packaging
  • Hardware that can not be opened without destruction
  • Unable to tell if fully updated (vendor must change aaguids on fw version update)
  • Local software trust chain bypass may be possible

  Nitrokey 3 NFC

  The Nitrokey 3 is built on the same hardware and software as the solokey. This means it is also vulnerable to the same issues. Unlike the solokey, the Nitrokey lacks tamper proof hardware - I can open mine quite easily with a spudger leaving no evidence of access. The NK3 I own is also a revision of the LPC55S69 which I can confirm is vulnerable to the trust chain bypass.

  • No tamper evident packaging
  • Hardware has no tamper resistance
  • Unable to tell if fully updated (vendor must change aaguids on fw version update)
  • Local software trust chain bypass may be possible

  Nitrokey 3 Mini

  The Nitrokey 3 Mini uses the same software an the NK3N, but uses a different chip (nrf32). We are unable to assess the hardware security as we don't own one, but nitrokeys trackrecord would indicate it likely has poor tamper resistance.

  The NK3M shop page as of 2023 declares:

  IMPORTANT NOTE: The included Secure Element is not used at this time. We are currently working on its integration and will enable its use later via firmware update.

  This means that keys are very likely not stored with secure mechanisms. Unless a firmware update that enables this feature changes the aaguid, it will always have to be assumed that this model of key is a version not using the secure enclave, making it inelligble for any serious use.

  • No tamper evident packaging
  • Hardware likely has no tamper resistance
  • Unable to tell if fully updated (vendor must change aaguids on fw version update)
  • Does not use devices own secure element

  Nitrokey 2

  Also called the Nitrokey FIDO2. While this device is named "FIDO2", it has never been certified by FIDO. Like the NK 3, it has no tamper resistant packaging or hardware.

  The NK2 has a weird feature though - you can update it from a website ( update site ).

  The way this is performed is with a hidden set of vendor commands that are hidden inside the credential ID of the CTAP2 get assertion process, defined by the value WALLET_TAG. You can see the checks for this in the nitrokey firmware source

  The problem here is that this means any website can sent a credential id with this WALLET_TAG and the nitrokey will respect and start to process those commands. More shocking, is these commands do not require interaction (touch) of the device or the pin to proceed, so visiting any webpage can trigger these commands. These commands include retrieving the device firmware versions, triggering the device to go into bootloader mode, and updating the firmware.

  At this time I am not aware of or sure about vulnerabilities in the NK2 L432KC6 chip. However, the ability to perform remote unauthenticated firmware updates is not something I want in a secure authenticator.

  Just like the other keys, since webauthn can't distinguish firmware versions either, it's also impossible to tell if a device has been fully software updated.

  • No tamper evident packaging
  • Hardware has no tamper resistance
  • Unable to tell if fully updated (vendor must change aaguids on fw version update)
  • Remote software trust chain bypass may be possible due to vendor commands

  Summary

  Today there are no opensource keys that meet basic security requirements for use in higher security environments. This means that attestation of webauthn keys in these environments is critical to ensure that these and other compromised keys documented in the FIDO MDS are not used in these situations.

  If there are other models and makes of opensource security keys I haven't reviewed, let me know so that I can purchase them for auditing!

December 01, 2023

• Gary Benson GitLab YAML Docker Registry client

  Have you written a Docker Registry API client in GitLab CI/CD YAML? I have.

  # Delete candidate image from CI repository.
  clean-image:
    stage: .post
    except:
      - main
  
    variables:
      AUTH_API: "$CI_SERVER_URL/jwt/auth"
      SCOPE: "repository:$CI_PROJECT_PATH"
      REGISTRY_API: "https://$CI_REGISTRY/v2/$CI_PROJECT_PATH"
  
    before_script:
      - >
        which jq >/dev/null
        || (sudo apt-get update
        && sudo apt-get -y install jq)
  
    script:
      - echo "Deleting $CANDIDATE_IMAGE"
      - >
        TOKEN=$(curl -s
        -u "$CI_REGISTRY_USER:$CI_REGISTRY_PASSWORD"
        "$AUTH_API?service=container_registry&scope=$SCOPE:delete,pull"
        | jq -r .token)
      - >
        DIGEST=$(curl -s -I
        -H "Authorization: Bearer $TOKEN"
        -H "Accept: application/vnd.docker.distribution.manifest.v2+json"
        "$REGISTRY_API/manifests/$CI_COMMIT_SHORT_SHA"
        | tr -d "\r"
        | grep -i "^docker-content-digest: "
        | sed "s/^[^:]*: *//")
      - >
        curl -s
        -X DELETE
        -H "Authorization: Bearer $TOKEN"
        "$REGISTRY_API/manifests/"$(echo $DIGEST | sed "s/:/%3A/g")

• ! Avi Alkalay ¡ Nefasta campanha de estatísticas de audição do Spotify

  Sem chance de eu obter qualquer estatística sobre meus gostos musicais, artistas e músicas que mais ouço. Ora, porque não uso Spotify. Ouço música majoritariamente de meu acervo pessoal (via Jellyfin, Kodi e outros tocadores) ou no Tidal que ganhei do plano de telefonia. E também em rádios como Soma.FM, Mixcloud, Rádio USP FM e Cultura FM onde o repertório é feito diretamente por humanos.

  

  As pessoas ouvem música para se inspirarem. Energizar, relaxar, viajar, distrair, divertir, viver uma nostalgia, preencher o silêncio. É um lance emocional e de momento. E também íntimo e pessoal, social, coletivo e até ato político.

  Estatísticas sobre o que as pessoas ouvem interessam aos artistas e a quem faz dinheiro com música. Para ouvintes de música, quantificar este hábito é, ao mesmo tempo, meramente curioso e bem irrelevante. Não consigo enxergar de outra forma, pois ao olhar essas estatísticas você jamais dirá “puxa, preciso ouvir mais Vivaldi”. Faz muito bem em continuar ouvindo o que te inspira naquele momento enquanto você realiza o tamanho do poder que uma única empresa pode exercer sobre os ouvidos e mentes de uma sociedade inteira.

  Eu sei que você tem orgulho da boa música que você ouve. Todos temos. Mas como sociedade deveríamos ter vergonha de permitir a formação de um monopólio como esse.

  A campanha do Spotify (de estatísticas de gostos musicais pessoais) é prá criar marcas, monetizar e oferecer a múltiplos setores indústrias (não só ao da música) uma nova modalidade de produto chamada “ouvinte”. Você nem imagina como essas estatísticas de audiência são reagrupadas e usadas no outro lado da indústria. Sim, adivinhou, para influenciar e moldar os seus gostos, para fidelizar, para te vender produtos, para lotar shows de Coldplays e Taylors Swifts.

  Eis algumas estatísticas que são bem mais úteis para você:

  • atividade parlamentar dos legisladores eleitos por você e pelo resto da sociedade
  • tempo diário gasto no trânsito
  • performance de seus investimentos pessoais
  • onde você gasta mais dinheiro (restaurantes, viagens, cultura, despesas)
  • custo e valor de bens de consumo ao longo do tempo

  Também no meu Facebook.

November 30, 2023

• Kevin Fenzi 20 years of blog!

  Just a short post to note that 20 years ago (!) I posted the first entry in this blog. I’ve been rather busy of late and haven’t posted too much, but it’s still up and a going concern. Then, I posted about a long thanksgiving trip. This year I stayed very close to home for thanksgiving. Changes all around.

  I plan some posts soon reviewing the amd/ryzen frame.work upgrade I got and the lovely asus hyper M.2 card (4 nvme drives). Also, some thoughts on open source and the like.

  Here’s to 20 more.

• Daniel Berrange ANNOUNCE: libvirt-glib release 5.0.0

  I am pleased to announce that a new release of the libvirt-glib package, version 5.0.0, is now available from

  https://libvirt.org/sources/glib/
  

  The packages are GPG signed with

  Key fingerprint: DAF3 A6FD B26B 6291 2D0E 8E3F BE86 EBB4 1510 4FDF (4096R)
  

  Changes in this release:

  • Fix compatiblity with libxml2 >= 2.12.0
  • Bump min libvirt version to 2.3.0
  • Bump min meson to 0.56.0
  • Require use of GCC >= 4.8 / CLang > 3.4 / XCode CLang > 5.1
  • Mark USB disks as removable by default
  • Add support for audio device backend config
  • Add support for DBus graphics backend config
  • Add support for controlling firmware feature flags
  • Improve compiler flag handling in meson
  • Extend library version script handling to FreeBSD
  • Fix pointer sign issue in capabilities config API
  • Fix compat with gnome.mkenums() in Meson 0.60.0
  • Avoid compiler warnings from gi-ir-scanner generated code by not setting glib version constraints
  • Be more robust about NULL GError parameters
  • Disable unimportant cast alignment compiler warnings
  • Use ‘pragma once’ in all header files
  • Updated translations

  Thanks to everyone who contributed to this new release.

• Truong Anh Tuan AI sẽ thay đổi hoàn toàn trò chơi dành cho những kẻ gửi thư rác và những trò lừa đảo phức tạp sẽ trở nên tinh vi hơn rất nhiều

  Bài được đăng trên tạp chí Fortune – Lược dịch nhân ngày An Toàn Thông Tin Việt Nam 2023 đang diễn ra với chủ đề “An toàn dữ liệu trong thời đại Điện toán đám mây & Trí tuệ nhân tạo”. Về tác giả: John Licato là trợ lý giáo sư Khoa học Máy tínhContinue reading "AI sẽ thay đổi hoàn toàn trò chơi dành cho những kẻ gửi thư rác và những trò lừa đảo phức tạp sẽ trở nên tinh vi hơn rất nhiều"

November 29, 2023

• Peter Czanik Version 4.5.0 of syslog-ng is now available with OpenObserve JSON API support

  Recently, syslog-ng 4.5.0 was released with many new features. These include sending logs to OpenObserve using its JSON API, support for Google Pub/Sub, a new macro describing message transport mechanisms like RFC 3164 + TCP, an SSL option to ignore validity periods, and many more. You can find a full list of new features and bug fixes in the release notes at: https://github.com/syslog-ng/syslog-ng/releases/tag/syslog-ng-4.5.0

  In this blog, you can find some pointers on how to install the very latest syslog-ng version and learn how you can configure syslog-ng to use the OpenObserver JSON API.

  Getting syslog-ng 4.5.0

  There is a new syslog-ng version almost every second month. Most Linux distributions cannot keep up with this speed, as they have a new release only every half a year (or just every 3-5 years). Right now, even the Repology website is lagging behind, as they consider 4.4.0 to be the latest version at the time of writing this blog: https://repology.org/project/syslog-ng/versions

  Repology lists only official distro repositories or semi-official repos, like RHEL EPEL. There are also some unofficial syslog-ng repositories for major Linux distributions, which you can use to install the very latest syslog-ng version, often with more features than what is available in Linux distributions. For more information check the related blogs:

  • Debian / Ubuntu: https://www.syslog-ng.com/community/b/blog/posts/installing-the-latest-syslog-ng-on-ubuntu-and-other-deb-distributions

  • openSUSE / SLES & Fedora / RHEL: https://www.syslog-ng.com/community/b/blog/posts/overview-of-syslog-ng-rpm-repositories

  After a bit of delay, I usually make syslog-ng available in FreeBSD ports and in my syslog-ng-stable RPM repositories as well. This time, however, I spotted a number of smaller bugs after the release became available. Because of this, my safety delay might be longer this time, or I might even skip 4.5.0 altogether.

  You can read about why some of the features are not available everywhere from one of my earlier blogs: https://www.syslog-ng.com/community/b/blog/posts/why-is-a-feature-not-available-in-the-syslog-ng-package

  Using the OpenObserve JSON API

  I covered OpenObserve in this blog just a couple months ago. At that time, I showed you how to ingest logs to OpenObserve using the Elasticsearch bulk API: https://www.syslog-ng.com/community/b/blog/posts/sending-logs-to-openobserve-using-syslog-ng However, I have heard about OpenObserve even more often from users ever since. Then, version 4.5.0 introduced official support for the OpenObserve JSON API. Working with OpenObserve this way is not much different but is slightly easier to configure.

  Configuring syslog-ng was already easy, as OpenObserve provides the user with a copy paste-ready syslog-ng configuration snippet in its user interface under the “ingest” menu. You only need to make sure that you use the right log source – otherwise, the configuration is ready to use.

  The configuration below shows you both the destination configuration generated by OpenObserve and the version using the new openobserve-log() destination, which utilizes the OpenObserve JSON API instead of the Elasticsearch API.

  destination d_openobserve_http {
      elasticsearch-http(
          index("syslog-ng")
          type("")
          user("peter@czanik.hu")
          password("0PsCZD4qCBp6UVyT")
          url("http://172.16.167.180:5080/api/default/_bulk")
          template("$(format-json --scope rfc5424 --scope dot-nv-pairs
          --rekey .* --shift 1 --scope nv-pairs
          --exclude DATE --key ISODATE @timestamp=${ISODATE})")
      );
  };
  
  destination d_openobserve_jsonapi {
      openobserve-log(
          user("peter@czanik.hu")
          password("0PsCZD4qCBp6UVyT")
          url("http://172.16.167.180")
          stream("syslog-ng")
          port(5080)
      );
  };
  
  source s_tcp {
    tcp(port(514));
  };
  
  
  log {
      source(s_tcp);
      destination(d_openobserve_jsonapi);
      flags(flow-control);
  };

  The d_openobserve_http destination is what OpenObserve automatically generates. It uses the Elasticsearch API. It is only there for reference, as it is not utilized in this configuration in a log path.

  The d_openobserve_jsonapi destination uses the OpenObserve JSON API to forward log messages. The two destinations are almost equivalent. The only difference is that the destination using the JSON API does not have any templates configured. For the openobserve-log() destination, it is called record() instead of template(), as it is not a full template: it contains only the name-value pair selectors for the format-json template function.

  The configuration above also adds a tcp() source and a log path, which connects this tcp() source to the d_openobserve_jsonapi destination.

  Testing

  Testing is easy: just send some logs to port 514 on the host. If you are on localhost, then something similar should be OK (but note that logger parameters might be different on your host):

  logger --rfc3164 -T -n 127.0.0.1 -P 514 this is a test massage1

  Right after you send this message, it should show up in your next query in the syslog-ng stream in the OpenObserve search interface.

  What is next

  The new, dedicated OpenObserve destination is just one of the new features of syslog-ng 4.5.0. I hope that this overview made you interested in installing syslog-ng 4.5.0 on a test system and check out other new features as well.

  -

  If you have questions or comments related to syslog-ng, do not hesitate to contact us. You can reach us by email or even chat with us. For a list of possibilities, check our GitHub page under the “Community” section at https://github.com/syslog-ng/syslog-ng. On Twitter, I am available as @PCzanik, on Mastodon as @Pczanik@fosstodon.org.

• Cockpit Project Cockpit 306

  Cockpit is the modern Linux admin interface. We release regularly.

  Here are the release notes from Cockpit 306, cockpit-machines 303, cockpit-podman 82, and cockpit-ostree 198.1:

  Kdump: Add Ansible/shell automation

  The Kdump page can generate an Ansible role or a shell script for replicating the current kdump configuration on other machines.

  

  

  OSTree: Redesign, with new features

  The OSTree page for software updates has been redesigned and includes several new features.

  Update status is now listed in the “Status” card, and details about the current OSTree repository and branch are visible in the “OSTree source” card.

  

  Unused deployments and package cache can be removed in using the “clean up” action.

  

  A new “Reset” feature has been added, which can remove layered and overriden packages.

  

  Deployments can be pinned to persist even when new deployments trigger an auto-cleanup and unpinned.

  

  Machines: Change “Add disk” default behavior

  The “Always attach” Persistent option will now be set by default.

  Podman: Delete intermediate images

  Intermediate images have no tags or other identifiers. They are usually intermediate layers from building container images or leftovers from moved tags. Intermediate images can now be deleted within Cockpit Podman.

  

  Try it out

  Cockpit 306, cockpit-machines 303, cockpit-podman 82, and cockpit-ostree 198.1 are available now:

  • For your Linux system

  • Cockpit Client

  • Cockpit Source Tarball
  • Cockpit Fedora 39
  • Cockpit Fedora 38
  • cockpit-machines Source Tarball
  • cockpit-machines Fedora 39
  • cockpit-machines Fedora 38
  • cockpit-ostree Source Tarball
  • cockpit-ostree Fedora 39
  • cockpit-ostree Fedora 38
  • cockpit-podman Source Tarball
  • cockpit-podman Fedora 39
  • cockpit-podman Fedora 38

November 28, 2023

• Kiwi TCMS Call for participation: Testing and Continuous Delivery devroom, FOSDEM'24

  

  Attention testers! On behalf of the Testing and Continuous Delivery devroom we'd like to announce that call for participation is still open. This room is about building better software through a focus on testing and continuous delivery practices across all layers of the stack. The purpose of this devroom is to share good and bad examples around the question “how to improve quality of our software by automating tests, deliveries or deployments� and to showcase new open source tools and practices.

  Note: for FOSDEM 2024 this devroom is a merger between the former Testing and Automation and Continuous Integration and Continuous Deployment devrooms and is jointly co-organized between devroom managers in previous FOSDEM editions! Kiwi TCMS is proud to be part of the team hosting this devroom!

  Important: devroom will take place on Sunday, February 4th 2024 at ULB Solbosch Campus, Brussels, Belgium! Presentations will be streamed online but all accepted speakers are required to deliver their talks in person!

  Here are some ideas for topics that are a good fit for this devroom:

  Testing in the real, open source world

  • War stories/strategies for testing large scale or complex projects
  • Tools that extend the ability to test low-level code, e.g. bootloaders, init systems, etc.
  • Projects that are introducing new/interesting ways of testing "systems"
  • Address the automated testing frameworks fragmentation
  • Stories from end-users (e.g. success/failure)
  • Continuous Integration
  • Continuous Delivery
  • Continuous Deployment
  • Security in Software Supply Chain
  • Pipeline standardization
  • Interoperability in CI/CD
  • Lessons learned

  Cool Tools (good candidates for lightning talks)

  • Project showcases, modern tooling
  • How your open source tool made developing quality software better
  • What tools do you use to setup your CI/CD
  • Combining projects/plugins/tools to build amazing things "Not enough people in the open source community know how to use $X, but here's a tutorial on how to use $X to make your project better."

  In the past the devroom has seen both newbies/students and experienced professionals and past speakers as part of the audience and talks covering from beginner/practical to advanced/abstract topics. If you have doubts then submit your proposal and leave a comment for the devroom managers and we'll get back to you.

  To submit a talk proposal (you can submit multiple proposals if you'd like) use Pretalx, the FOSDEM paper submission system. Be sure to select Testing and Continuous delivery!

  Checkout https://fosdem-testingautomation.github.io/ for more information!

  Happy Testing!

  ---

  If you like what we're doing and how Kiwi TCMS supports various communities please help us!

  • Give â­� on GitHub;
  • Give ğŸ‘� on GitLab;
  • Donate via Open Collective as low as 1 EUR;
  • Join our newsletter and follow all project news;
  • Become a contributor and an awesome open source hacker;
  • Become a customer and we'll share our profits with the community

• Fabio Alessandro Locati On the nature of the right to privacy

  In the last month, Meta has started to give their European users a choice between an account for their services paid in data or one paid in Euros. Today, noyb has filed a GDPR complaint against Meta over this behavior. Noyb has very good points to sustain their filing, but I don’t want to delve too much into those since those are very well explained in their press release. I think there is a deeper problem that they quickly touch but do not address directly, which is the interpretation of the kind of right that privacy is.

November 27, 2023

• Adam Young recvfrom system call in python

  With a socket created, and a message sent, the next step in our networking journey is to receive data.

  Note that I used this post to get the parameter right. Without using the ctypes pointer function I got an address error.

  print("calling recvfrom")
  recv_sockaddr_mctp = struct_sockaddr_mctp(AF_MCTP, 0, mctp_addr , 0, 0)
  len = 2000;
  rxbuf = create_string_buffer(len)
  sock_addr_sz = c_int(sizeof(recv_sockaddr_mctp))
  MSG_TRUNC = 0x20
  rc = libc.recvfrom(sock, rxbuf, len, MSG_TRUNC, byref(recv_sockaddr_mctp), pointer(sock_addr_sz));
  errno = get_errno_loc()[0]
  
  if (rc < 0 ):
      print("rc = %d errno =  %d" % (rc, errno))
      exit(rc)
  
  print(rxbuf.value)
  

  From previous articles you might be wondering about these values.

  AF_MCTP = 45
  mctp_addr = struct_mctp_addr(0x32)

  However, the real magic is the structures defined using ctypesgen. I recommend reading the previous article for the details.

  While the previous two article are based on the code connect example that I adjusted and posted here, the recvfrom code is an additional call. The c code it is based on looks like this:

      addrlen = sizeof(addr);
  
      rc = recvfrom(sd, rxbuf, len, MSG_TRUNC,
                  (struct sockaddr *)&addr, &addrlen);

• Remi Collet PHP 8.0 is retired

  One year after PHP 7.4, and as announced, PHP version 8.0.30 was the last official release of PHP 8.0

  To keep a secure installation, the upgrade to a maintained version is strongly recommended:

  • PHP 8.1 has security only support and will be maintained until November 2024.
  • PHP 8.2 has active support and will be maintained until December 2024 (2025 for security).
  • PHP 8.3 has active support and will be maintained until November 2025 (2026 for security).

  Read :

  • PHP Supported versions
  • Migration guide from PHP 8.0.x to PHP 8.1.x
  • Migration guide from PHP 8.1.x to PHP 8.2.x
  • Migration guide from PHP 8.2.x to PHP 8.3.x

  However, given the very important number of downloads by the users of my repository the version is still available in remi repository for Enterprise Linux (RHEL, CentOS, Alma, Rocky...) and Fedora and will include the latest security fixes.

  Warning : this is a best effort action, depending on my spare time, without any warranty, only to give users more time to migrate. This can only be temporary, and upgrade must be the priority.

  You can also watch the sources repository on github.

• Josh Bressers Episode 403 – Does the government banning apps work?

  Josh and Kurt talk about the Canadian Government banning WeChat and Kaspersky. There’s a lot of weird little details in this conversation. It fundamentally comes down to a conversation about risk. It’s easy to spout nonsense about risk, but having an honest discussion about it is REALLY complicated. But the government plays by a very different set of rules.

  Show Notes

  • Canada bans WeChat, Kaspersky applications on government devices
  • Fitness tracking app Strava gives away location of secret US army bases
  • Phishing emails increase over 1,200 percent since ChatGPT launch
  • FedRAMP Rev 5
  • FAIR Institute

November 26, 2023

• Charles-Antoine Couret Revue de presse de Fedora Linux 39

  Cela fait depuis Fedora 19 que je publie sur la liste de diffusion de Fedora-fr une revue de presse de chaque sortie d'une nouvelle version. Récapituler quels sites en parle et comment. Je le fais toujours deux semaines après la publication (pour que tout le monde ait le temps d'en parler). Maintenant, place à Fedora Linux 39 !

  Bien entendu je passe sous silence mon blog et le forum de fedora-fr.

  Sites web d'actualité

  • Linuxfr ;
  • Next ;
  • Développez.com ;
  • Goodtech.info.
  • Programmez.com ;
  • Linux addicts ;
  • Numétopia.

  Soit 7 sites.

  Les vidéos

  • Linuxtricks.
  • Vinceff.
  • La revue Geek.

  Soit 3 vidéos.

  Bilan

  Le nombre de sites parlant de Fedora Linux 39 est stable, tandis que els vidéos sont en hausse.

  La semaine de sa sortie, nous avons eu globalement une augmentation de visites par rapport à la semaine d'avant de cet ordre là :

  • Forums : hausse de 27,1% (plus de 800 visites en plus)
  • Documentation : hausse d'environ 41,6% (soit environ 800 visites en plus)
  • Le site Fedora-fr : hausse de 82,1% (soit 150 visites en plus)
  • Borsalinux-fr : hausse de 82% (soit 23 visites en plus)

  Si vous avez connaissance d'un autre lien, n'hésitez pas à partager !

  Rendez-vous pour Fedora Linux 40.

• Kiwi TCMS Kiwi TCMS 12.7

  We're happy to announce Kiwi TCMS version 12.7!

  IMPORTANT: This is our first release after reaching 2 million downloads on Docker Hub earlier this month! It is a small release which contains security related updates, several improvements, bug fixes and internal refactoring!

  You can explore everything at https://public.tenant.kiwitcms.org!

  ---

  Upstream container images (x86_64):

  kiwitcms/kiwi   latest  973df48a2f82    613MB
  

  IMPORTANT: version tagged and multi-arch container images are available only to subscribers!

  Changes since Kiwi TCMS 12.6.1

  Security

  • Update django from 4.2.4 to 4.2.7. Fixes CVE-2023-46695, CVE-2023-43665 and CVE-2023-41164
  • Update django-simple-captcha from 0.5.18 to 0.5.20
  • We believe that none of these issue affect Kiwi TCMS directly however we recommend that you upgrade your installation as soon as possible

  Improvements

  • Update bleach from 6.0.0 to 6.1.0
  • Update django-colorfield from 0.9.0 to 0.10.1
  • Update django-grappelli from 3.0.6 to 3.0.8
  • Update django-simple-history from 3.3.0 to 3.4.0
  • Update markdown from 3.4.4 to 3.5.1
  • Update psycopg2 from 2.9.7 to 2.9.9
  • Update pygments from 2.16.1 to 2.17.2
  • Update python-gitlab from 3.15.0 to 4.1.1
  • Update uwsgi from 2.0.22 to 2.0.23
  • Update node_modules/crypto-js from 4.1.1 to 4.2.0
  • Update node_modules/datatables.net-buttons from 2.4.1 to 2.4.2
  • Update node_modules/pdfmake from 0.2.7 to 0.2.8
  • Update bug-tracker integration documentation with specifics about matches for product name
  • When searching for JIRA projects try also matching by project key
  • Fall-back to credentials from database if settings.EXTERNAL_ISSUE_RPC_CREDENTIALS override returns None

  Database

  • New migrations after upgrading django-color-field. Increases field max_length from 18 to 25

  Bug fixes

  • Fix error in filtering by TestRun ID on TestCase Search page (@somenewacc)
  • Fix TestRun page to not automatically update its stop_date when marking statuses for test executions if there are more neutral executions left on the page outside of the currently filtered selection (@somenewacc)
  • Fix bug with JIRA integration not being able to find project via name

  Refactoring and testing

  • Refactor calls to delete expandedExecutionIds to satisfy https://rules.sonarsource.com/typescript/RSPEC-2870/ (@somenewacc)
  • Refactor calls to delete expandedTestCaseIds to satisfy https://rules.sonarsource.com/typescript/RSPEC-2870/
  • Use tuple as the cache-key for IssueTrackerType.rpc_cache internally
  • Add test for collectstatic because of an upstream issue with django-grappelli
  • Improve tests for JIRA integration
  • Test against Bugzilla on Fedora 39
  • Update actions/checkout from 3 to 4
  • Update node_modules/eslint from 8.48.0 to 8.54.0
  • Update node_modules/eslint-plugin-import from 2.28.1 to 2.29.0
  • Update node_modules/eslint-plugin-n from 16.0.2 to 16.3.1
  • Update node_modules/webpack from 5.88.2 to 5.89.0
  • Update pylint-django from 2.5.3 to 2.5.5 and all of our custom linter rules

  Kiwi TCMS Enterprise v12.7-mt

  • Based on Kiwi TCMS v12.7

  • Update kiwitcms-tenants from 2.5.1 to 2.5.2

  • Update kiwitcms-trackers-integration from 0.5.0 to 0.6.0

    Provides functionality for personal API tokens. Accessible via PLUGINS -> Personal API tokens menu!

    WARNING: in order for users to be able to define personal API tokens for 3rd party bug-trackers they will need to be assigned permissions.

    Kiwi TCMS administrators should consider granting the following permissions:

    tracker_integrations | api token | Can add api token
    tracker_integrations | api token | Can change api token
    tracker_integrations | api token | Can delete api token
    tracker_integrations | api token | Can view api token
    

    either individually per-user basis or via groups!

  • Update python3-saml from 1.15.0 to 1.16.0

  • Update social-auth-app-django from 5.2.0 to 5.4.0

    Private container images:

    quay.io/kiwitcms/version            12.7 (aarch64)          aa6a4c5434c9    25 Nov 2023     624MB
    quay.io/kiwitcms/version            12.7 (x86_64)           973df48a2f82    25 Nov 2023     613MB
    quay.io/kiwitcms/enterprise         12.7-mt (aarch64)       e19c493e7291    25 Nov 2023     814MB
    quay.io/kiwitcms/enterprise         12.7-mt (x86_64)        f38a49d661ad    25 Nov 2023     801MB
    

  IMPORTANT: version tagged, multi-arch and Enterprise container images are available only to subscribers!

  How to upgrade

  Backup first! Then follow the Upgrading instructions from our documentation.

  Happy testing!

  ---

  If you like what we're doing and how Kiwi TCMS supports various communities please help us grow!

  • Give â­� on GitHub;
  • Give ğŸ‘� on GitLab;
  • Donate via Open Collective as low as 1 EUR;
  • Join our newsletter and follow all project news;
  • Become a contributor and an awesome open source hacker;
  • Become a subscriber and help us sustain development

• Zach Oglesby

  Finished reading: A Trail Through Time by Jodi Taylor 📚

November 24, 2023

• Jan Grulich PipeWire Camera Support in Firefox #2

  I wrote the first blog post about PipeWire cameras in Firefox in May and a lot has happened since then. The first PipeWire support arrived shortly after the blog post was published and was released as part of Firefox 116 (August). We didn’t enable it by default, of course since it’s still a “work in progress”, but many of you tried it (thank you for that) and we were able to fix some issues that I, as the only tester at the time, hadn’t found. However, aside from all the crashes and minor issues we were able to fix relatively quickly, there was one major problem (or drawback) with the PipeWire camera that made it unusable with most popular video conferencing sites, such as Google Meet. Kind of a deal breaker, right? This has kept me busy ever since, but we are finally close to fixing it in upstream. I’m going to explain why this was a problem and how we fixed it, and forgive me in advance if I write anything wrong, I’m still learning and discovering things as they unfold.

  There are Javascript APIs that are implemented by all the major browsers. The API documentation is here. It defines APIs sites can use to query information about media devices. I will now describe a simplified workflow used with V4L2 on the aforementioned Google Meet once you start a meeting:

  • GMeet makes enumerateDevices() call to get information about available devices
  • Firefox can respond with the list of available cameras (+ audio devices obviously) on the system because the information about cameras is available and no permission is needed
  • GMeet makes getUserMedia() call to get access to the camera since it knows there is a camera available
  • Firefox will prompt the user to get access to the selected devices (including camera) and start streaming

  Now the same situation, but with PipeWire:

  • GMeet makes enumerateDevices() call to get information about available devices
  • Firefox cannot respond with the list of available cameras because this enumeration request cannot ask for user permission and we cannot access PipeWire without it. Firefox will return an empty list of camera devices and there will be only audio devices announced
  • GMeet makes getUserMedia() call, but only to get access to the devices that were previously announced, so only audio devices
  • Firefox will prompt the user to get access only to the selected audio devices and no camera

  How did we solve this?

  The documentation here also covers this situation. The enumerateDevices() request is allowed to return a placeholder device for each type. This means that we can return a placeholder camera device, which tells Google Meet there is actually a camera device to ask for. With this device placeholder, the subsequent getUserMedia() request will also request access to camera devices. How do we know that a camera device is present without having access to PipeWire, you ask? The camera portal from xdg-desktop-portal has a IsCameraPresent property for exactly the same purpose and we use it to know whether to insert the camera device placeholder or not.

  While such a solution sounds simple on paper, it required a significant amount of changes to the entire media handling stack. There is not a small amount of PipeWire specific code, so this fix also involves some restructuring so that all the backend specific logic is in one place. And while I’m getting more and more familiar with the Firefox code, which is helping me to progress faster, there’s still a lot to learn.

  Anyway, the reason I’m writing this blog post now is that all the related changes have been approved and will hopefully be landing soon, making Firefox fully usable with PipeWire . Although not yet merged, Fedora users can use a COPR repository I created. The repository has Fedora Firefox builds with all the necessary changes backported and PipeWire camera enabled by default. Just note that while I’ve been testing and using it for the past few months and it’s worked perfectly for me, you use it at your own risk. You better to use it just to test PipeWire camera support as the official Fedora Firefox package is the one we keep fully updated and my repo may lag behind. There will be a new PipeWire 1.0 release soon, which will be a big milestone for PipeWire and I hope that PipeWire camera support in Firefox and browsers in general will be part of the PipeWire success story.

• Daniel Pocock Dublin Burning, weakness in police response brutally exposed

  The report to the UK Health & Safety Executive has been evolving very slowly, a few lines per day, over the last six months. It was a difficult task but I was motivated to try and capture these things in writing after some of the attacks on my family. Submitting it was a small milestone to be followed up with a quiet stroll and maybe a pint in Dublin city center.

  Dublin seemed to have other plans though.

  One of the scariest things, which I discovered early in the evening, is that the police (Garda) had failed to secure the bridges crossing the river and the mob had moved from the north side to the south side. Authorities revealed they only had a single helicopter and it had to take breaks for refuelling. Police told me they had been brought in from regions over an hour away from Dublin but their police lines appeared to be far too thin and they would have been easily overrun by a more organized mob. I heard rumors about the army being mobilized but didn't see that with my own eyes.

  Shop owners had placed rubbish out in the street for collection the next morning. This provided a source of fuel for bonfires.

  Things were equally bad on the public information front. All public transport had been canceled but the bus stop information screens continued to display information promised busses were on the way. Roads had been blocked but many young women were simply standing alone waiting at the side of the road for a father or boyfriend to drive in and get them. They would have been far safer getting into a group and seeking shelter indoors but there was no official communication to this effect. At no point did I see any emergency broadcasts on any of my phones.

  Heading north up Camden Street, I had been warned what to expect. Bouncers at one of the bars were well briefed and told me that rioters had easily crossed the river from north to south before police lines were put in place.

  The position of the police helicopter in the sky gave some indication of where things were happening. Dublin only appears to have one helicopter.

  Passing Lidl on Aungier Street, I began to feel the smell of the city burning, although it wasn't yet visible at that point.

  By this point, a lot of normally busy bars and restaurants were already closed and barricaded for the night. A small number of them had remained open, customers choosing to ignore the emergency vehicles zipping back and forth up the street.

  A brigade of riot police was moving along the quay. I noticed these groups were only arriving well after rioters had already moved on. They were outnumbered and vulnerable to attack from behind. I followed them up the quay and then turning up towards the castle.

  Even in the areas where things were burning, half the Garda units were without any riot gear whatsoever.

  Newspaper reports have tried to link the riot to the stabbing earlier in the day. It is really important to emphasize that it was a warm night without any rain. Had it been cold or wet, many of these people would have simply stayed home. Some, maybe all of them appeared to have simply come out of the pub and decided to join in for fun rather than for any political motive.

  This is one of those situations when you really value the service of the police, known as the Garda in Ireland.

  On the other hand, I felt that the police were seriously understaffed. Looking at the pictures, we can see huge gaps between the riot police. Had the mob been larger or more organized, they would have easily penetrated the police lines and caused even more havoc. Any groups hoping to cause such chaos in future have gained valuable insights from observing the official response tonight.

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

• Remi Collet PHP version 8.1.26 and 8.2.13

  RPMs of PHP version 8.2.13 are available in the remi-modular repository for Fedora ≥ 37 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...) and in the remi-php82 repository for EL 7.

  RPMs of PHP version 8.1.26 are available in the remi-modular repository for Fedora ≥ 37 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...) and in the remi-php81 repository for EL 7.

  The Fedora 39, EL-8 and EL-9 packages (modules and SCL) are available for x86_64 and aarch64.

  There is no security fix this month, so no update for version 8.0.30.

  PHP version 7.4 has reached its end of life and is no longer maintained by the PHP project.

  These versions are also available as Software Collections in the remi-safe repository.

  Version announcements:

  • PHP 8.2.13 Release Annoucement
  • PHP 8.1.26 Release Annoucement

  Installation: use the Configuration Wizard and choose your version and installation mode.

  Replacement of default PHP by version 8.2 installation (simplest):

  dnf module reset php
  dnf module enable php:remi-8.2
  dnf update php\*

  or, the old EL-7 way:

  yum-config-manager --enable remi-php82
  yum update

  Parallel installation of version 8.2 as Software Collection

  yum install php82

  Replacement of default PHP by version 8.1 installation (simplest):

  dnf module reset php
  dnf module enable php:remi-8.1
  dnf update php\*

  or, the old EL-7 way:

  yum-config-manager --enable remi-php81
  yum update php\*

  Parallel installation of version 8.1 as Software Collection

  yum install php81

  And soon in the official updates:

  • Fedora Rawhide now has PHP version 8.3.0
  • Fedora 39 - PHP 8.2.13
  • Fedora 38 - PHP 8.2.13

  To be noticed :

  • EL-9 RPMs are built using RHEL-9.2 (next builds will use 9.3)
  • EL-8 RPMs are built using RHEL-8.8 (next builds will use 8.9)
  • EL-7 RPMs are built using RHEL-7.9
  • intl extension now uses libicu73 (version 73.2)
  • mbstring extension (EL builds) now uses oniguruma5php (version 6.9.9, instead of the outdated system library)
  • oci8 extension now uses the RPM of Oracle Instant Client version 21.12 on x86_64, 19.19 on aarch64
  • a lot of extensions are also available, see the PHP extensions RPM status (from PECL and other sources) page

  Information:

  • Migrating from PHP 7.4.x to PHP 8.0.x
  • Migrating from PHP 8.0.x to PHP 8.1.x
  • Migrating from PHP 8.1.x to PHP 8.2.x

  Base packages (php)

  

  

  Software Collections (php80 / php81 / php82)

  

  

• Truong Anh Tuan Zimbra 10 builds

  Như thông tin từ Zimbra, phiên bản 8.8.15 sẽ hết thời gian hỗ trợ vào 31/12/2023 và phiên bản 9.0 cũng sẽ hết hỗ trợ vào 31/12/2024 (vừa gia hạn thêm); nguồn lực phát triển sẽ được tập trung cho phiên bản 10 và các phiên bản tiếp theo. Xem ảnh dưới: Cũng kể từContinue reading "Zimbra 10 builds"

November 23, 2023

• Daniel Pocock British Health & Safety Executive investigating open source deaths and culture problems

  In the United Kingdom, the Health & Safety Executive is now examining the accidents, suicides and other cultural defects of certain bad actors engaging with open source volunteer communities.

  Anybody with evidence is invited to submit reports and testimonials.

  The case number is CAT-0125111

  Health and Safety Executive
  10 South Colonnade
  Canary Wharf
  London
  E14 4PU

  This investigation is taking place concurrently with a police investigation into the death of Abraham Raji at Debian's DebConf23.

  Please see my chronological history of how the Debian harassment and abuse culture evolved.

  The canary in the coal mine

  RIP Abraham Raji

  

• Remi Collet PHP version 8.3.0 is released!

  RC6 was GOLD, so version 8.3.0 GA is just released, at planned date.

  A great thanks to Eric Mann, Jakub Zelenka, and Pierrick Charron our Release Managers,  to all developers who have contributed to this new long awaiting version of PHP, and thanks to all testers of the RC versions who have allowed us to deliver a good quality version.

  RPM are available in the php:remi-8.3 module for Fedora and Enterprise Linux ≥ 8 and as Software Collection in the remi-safe repository.

  RPM are also available in the remi-php83 repository for  Enterprise Linux 7 (RHEL, CentOS, Alma, Rocky...).

  Read the PHP 8.3.0 Release Announcement and its Addendum for new features detailed description.

  For memory, this is the result of 6 months of work for me to provide these packages, starting in June for Software Collections of alpha versions, in August for module streams of RC versions, and also a lot of work on extensions to provide a mostly full PHP 8.3 stack.

  Installation: read the Repository configuration and choose installation mode, or follow the Configuration Wizard instructions.

  Replacement of default PHP by version 8.3 installation (simplest):

  Fedora modular or Enterprise Linux ≥ 8:

  dnf module reset php
  dnf module install php:remi-8.3

  Enterprise Linux 7:

  yum-config-manager --enable remi-php83
  yum update php\*

  Parallel installation of version 8.3 as Software Collection (recommended for tests):

  yum install php83

  To be noticed :

  • EL9 RPMs are build using RHEL-9.2
  • EL8 RPMs are build using RHEL-8.8
  • EL7 RPMs are build using RHEL-7.9
  • this version will also be the default version in Fedora 40
  • lot of extensions are already available, see the PECL extension RPM status page.

  Information, read:

  • PHP 8.3 Released!
  • Migrating from PHP 8.2.x to PHP 8.3.x
  • UPGRADING
  • UPGRADING.INTERNALS

  Base packages (php)
  

  Software Collections (php83)
  

November 22, 2023

• Adam Young sendto system call from python

  Once we open a socket, we probably want to send and receive data across it.Here is the system call we need to make in order to send data as I wrote about in my last post:

  c = sendto(sd, buf, sizeof(buf), 0,
                  (struct sockaddr *)&addr, sizeof(addr));

  Note the cast of the addr parameter. This is a structure with another structure embedded in it. I tried hand-jamming the structure, but the data sent across the system call interface was not what I expected. In order to make it work ,I uses a utility called ctypesgen with the header I separated out in my last post. Runing this:

  ctypesgen ./spdmcli.h
  

  generates a lot of code, much of which I don’t need. The part I do need looks like this:

  
  __uint8_t = c_ubyte# /usr/include/bits/types.h: 38
  __uint16_t = c_ushort# /usr/include/bits/types.h: 40
  __uint32_t = c_uint# /usr/include/bits/types.h: 42
  uint8_t = __uint8_t# /usr/include/bits/stdint-uintn.h: 24
  uint16_t = __uint16_t# /usr/include/bits/stdint-uintn.h: 25
  uint32_t = __uint32_t# /usr/include/bits/stdint-uintn.h: 26
  
  # /root/spdmcli/spdmcli.h: 5
  class struct_mctp_addr(Structure):
      pass
  
  struct_mctp_addr.__slots__ = [
      's_addr',
  ]
  struct_mctp_addr._fields_ = [
      ('s_addr', uint8_t),
  ]
  
  # /root/spdmcli/spdmcli.h: 9
  class struct_sockaddr_mctp(Structure):
      pass
  
  struct_sockaddr_mctp.__slots__ = [
      'smctp_family',
      'smctp_network',
      'smctp_addr',
      'smctp_type',
      'smctp_tag',
  ]
  struct_sockaddr_mctp._fields_ = [
      ('smctp_family', uint16_t),
      ('smctp_network', uint32_t),
      ('smctp_addr', struct_mctp_addr),
      ('smctp_type', uint8_t),
      ('smctp_tag', uint8_t),
  ]
  
  # /root/spdmcli/spdmcli.h: 3
  try:
      MCTP_TAG_OWNER = 0x08
  except:
      pass
  
  mctp_addr = struct_mctp_addr# /root/spdmcli/spdmcli.h: 5
  
  sockaddr_mctp = struct_sockaddr_mctp# /root/spdmcli/spdmcli.h: 9
  

  With those definition, the following code makes the system call with the parameter data in the right order:

  
  mctp_addr = struct_mctp_addr(0x32) # /root/spdmcli/spdmcli.h: 16
  sockaddr_mctp = struct_sockaddr_mctp(AF_MCTP, 1, mctp_addr , 5, 0x08)
  
  p = create_string_buffer(b"Held") 
  p[0] = 0x10 
  p[1] = 0x82
  
  sz = sizeof(sockaddr_mctp)
  print("calling sendto")
  
  
  rc = libc.sendto(sock, p, sizeof(p), 0, byref(sockaddr_mctp), sz) 
  errno = get_errno_loc()[0]
  print("rc = %d errno =  %d" % (rc, errno)   )
  
  if (rc < 0 ):
      exit(rc)
  
  print("OK")

  With this Next step is to read the response.

• Adam Young Updated MCTP send code

  While the existing documentation is good, there are a couple things that have changed since it was originally written, and I had to make a couple minor adjustments to get it to work. Here’s the code to send a message. The receive part should work as originally published; what is important is the set of headers. I built and ran this on an AARCH64 platform running Fedora 38.

  I split the code into a header and a .c file for reasons I will address in another article.

  spdmcli.h

  #include <stdint.h>
  
  #define MCTP_TAG_OWNER 0x08
  
  struct mctp_addr {
      uint8_t             s_addr;
  };
  
  struct sockaddr_mctp {
      uint16_t            smctp_family;
      uint32_t            smctp_network;
      struct mctp_addr    smctp_addr;
      uint8_t             smctp_type;
      uint8_t             smctp_tag;
  }

  I also coded this for spdm, not MCTP control messages. The difference is the value for addr.smctp_type

  EDIT: I also added the recvfrom call to make this complete.

  spdmcli.c

  #include <linux/mctp.h>
  #endif
  #include <linux/if_link.h>
  #include <linux/rtnetlink.h>
  
  #include "stdio.h"
  #include "spdmcli.h"
  
  int main(void)
  {
      struct sockaddr_mctp addr = { 0 };
      char buf[] = "hello, world!";
      int sd, rc;
  
      /* create the MCTP socket */
      sd = socket(AF_MCTP, SOCK_DGRAM, 0);
      if (sd < 0)
          err(EXIT_FAILURE, "socket() failed");
  
      /* populate the remote address information */
      addr.smctp_family = AF_MCTP;  /* we're using the MCTP family */
      addr.smctp_addr.s_addr = 0x32;   /* send to remote endpoint ID 32 */
      addr.smctp_type = 5;          /* encapsulated protocol type iSPDM = 5 */
      addr.smctp_tag = MCTP_TAG_OWNER; /* we own the tag, and so the kernel
                                          will allocate one for us */
  
      addr.smctp_network = 1 ;
      /* send the MCTP message */
      rc = sendto(sd, buf, sizeof(buf), 0,
                  (struct sockaddr *)&addr, sizeof(addr));
  
      if (rc != sizeof(buf))
          err(EXIT_FAILURE, "sendto() failed");
  
     //EDIT: The following code recieves a message from the network and prints it to the console.
          if (rc < 0){
          err(EXIT_FAILURE, "recvfrom() failed");
      }
  
      printf("recv rc = %d\n",rc);        
  
      for (int i =0; i< rc; i++){
          printf("%x", rxbuf[i]); 
  
      }
  
  
  
      return EXIT_SUCCESS;
  }

November 21, 2023

• Adam Young socket system call from python

  While the Python socket API is mature, it does not yet support MCTP. I thought I would thus try to make a call from python into native code. The first step is to create a socket. Here is my code to do that.

  Note that this is not the entire C code needed to make network call, just the very first step.I did include the code to read errno if the call fails.

  #!/usr/bin/python3
  from ctypes import *
  libc = CDLL("/lib64/libc.so.6")
  AF_MCTP = 45
  SOCK_DGRAM  = 2
  rc = libc.socket (AF_MCTP, SOCK_DGRAM, 0)
  #print("rc = %d " % rc)
  get_errno_loc = libc.__errno_location
  get_errno_loc.restype = POINTER(c_int)
  errno = get_errno_loc()[0]
  print("rc = %d errno =  %d" % (rc, errno)   )
  print("OK")

  Running this code on my machine shows success

  # ./spdm.py 
  rc = 3 errno =  0
  OK
  

• Peter Czanik Logging to Humio / Logscale simplified in syslog-ng

  Logging into Humio (which was recently re-branded to Falcon LogScale) was available for years, using their Elasticsearch compatible API. However, according to Humio developers, it is slightly slower than other APIs for log ingestion. Axoflow contributed a Logscale destination to syslog-ng, which uses Logscale’s native API. I did not measure if there is really a performance difference, however it is definitely easier to configure it.

  Before you begin

  The logscale() destination was introduced in syslog-ng version 4.3.1. If your operating system has an older version of syslog-ng, check our 3^rd party repositories page, if there is something more recent for your OS: https://syslog-ng.org/3rd-party-binaries/.

  You also need a Humio / Logscale account, a token and a URL. The default URL in the destination is suitable for commercial customers outside of the EU. There is a different URL for customers in the rest of the World. Community users have yet another URL, I will use that one in my examples.

  The old way

  You can read more about how to ingest logs with Humio using the Elasticsearch API at https://www.syslog-ng.com/community/b/blog/posts/sending-logs-to-humio-using-the-elasticsearch-http-destination-of-syslog-ng. Here I just want to copy & paste the configuration for reference:

  destination d_elastic_humio {
      elasticsearch-http(
          type("humio") # not used by humio, but required by plugin
          index("syslog-humio") # not used by humio, but required by plugin
          url("https://cloud.community.humio.com/api/v1/ingest/elastic-bulk")
          workers(2)
          batch-lines(200)
          user("syslog-ng") # not used by humio, can be whatever you want
          password("a555ef1c-XXX-YYY-ZZZ-63e6914e22e1")
          template("$(format-json --scope rfc5424 --scope dot-nv-pairs
          --exclude .journald.*
          --rekey .* --shift 1 --scope nv-pairs
          --exclude DATE  @timestamp=${ISODATE})")
      );
  };

  The mandatory parameters are type(), index(), url(), user() and password(), the others just fine-tune how the destination works.

  Configuring the logscale() destination

  If you are a non-EU commercial customer, your job is very easy: the only mandatory parameter is the token:

  destination d_logscale {
    logscale(
      token("my-token")
    );
  };

  My configuration is slightly more complex, as I also configured the url() parameter:

  destination d_logscale {
    logscale(
      token("a5xxxx1c-xxxx-42b1-xxxx-63e6xxxx22e1")
      url("https://cloud.community.humio.com")
    );
  };

  What is next?

  If you take a look at the GitHub pull request, you will see a few more available configuration parameters: https://github.com/syslog-ng/syslog-ng/pull/4472. And if you take a closer look at the SCL itself, which implements the logscape() destination, you will see that you can change the attributes() parameter to change the content of log messages. You can view it on-line at https://github.com/syslog-ng/syslog-ng/blob/master/scl/logscale/logscale.conf.

  -

  If you have questions or comments related to syslog-ng, do not hesitate to contact us. You can reach us by email or even chat with us. For a list of possibilities, check our GitHub page under the “Community” section at https://github.com/syslog-ng/syslog-ng. On Twitter, I am available as @PCzanik, on Mastodon as @Pczanik@fosstodon.org.

• ! Avi Alkalay ¡ Nascimento da Internet

  No dia de hoje, mas em 1969, nasceu a Internet.

  Criada por desejo e necessidade de pesquisadores americanos trocarem mensagens, dados e recursos computacionais para suas pesquisas, foi viabilizada quando um orçamento de $1 milhão das forças armadas americanas foi realocado de mísseis balísticos para o projeto ARPANET.

  Em 21 de Novembro de 1969, uma conexão permanente foi estabelecida entre a Universidade da Califórnia em Los Angeles (UCLA) e o Instituto de Pesquisas de Stanford (SRI), perto de San Francisco. Protocolos como TCP/IP, Telnet, FTP também foram criados para facilitar o uso dessa novidade. Até o final daquele ano diversas outras universidades também foram conectadas. O diagrama mostra os pontos de acesso à Internet em 1970.

  No Brasil, a Internet chegou nas universidades na virada para a década de 1990. Apagamos o Windows 3 de alguns PCs da IBM que tinham acabado de chegar e instalamos FreeBSD para poder usar a internet discada que foi disponibilizada no meu campus, na UNESP em Rio Claro. Um pesquisador da EmBraPA me deu as primeiras dicas sobre X11, Netscape, o terminal e alguns comandos, e não parei mais.

  Hoje, não conseguimos sequer imaginar qualquer aspecto da nossa vida sem a Internet, que nos ensinou que tudo pode ser convertido ou expresso em informação, serializada e transmitida pelos cabos, sinais de rádio e protocolos que conectam nossa enorme fauna de aparelhos.

  21 de Novembro de 2023, a Internet faz 54 anos.

November 20, 2023

• The NeuroFedora Blog Next Open NeuroFedora meeting: 20 November 1300 UTC

  

  Photo by William White on Unsplash.

  
  

  Please join us at the next regular Open NeuroFedora team meeting on Monday 20 November at 1300 UTC. The meeting is a public meeting, and open for everyone to attend. You can join us over:

  • Matrix

  You can use this link to convert the meeting time to your local time. Or, you can also use this command in the terminal:

  $ date --date='TZ="UTC" 1300 2023-11-20'
  

  The meeting will be chaired by @ankursinha. The agenda for the meeting is:

  • New introductions and roll call.
  • Tasks from last meeting.
  • Open Pagure tickets.
  • Package health check.
  • Open package reviews check.
  • CompNeuro lab compose status check for Fedora 38/rawhide.
  • Neuroscience query of the week
  • Next meeting day, and chair.
  • Open floor.

  We hope to see you there!

• Josh Bressers Episode 402 – The EU’s eIDAS regulation is a terrible idea

  Josh and Kurt talk about the new EU eIDAS regulation. This is a bill that will force web browsers to add root certificates based on law instead of technical merits, which is how it’s currently done. This is concerning for a number of reasons that we discuss on the show. This proposal is not a good idea.

  Show Notes

  • Mozilla site
  • Root CA mailing list
  • UK eIDAS regulation
  • EFF statement on eIDAS
  • Fixed XKCD comic

November 19, 2023

• Zach Oglesby

  Finished reading: A Second Chance by Jodi Taylor 📚

  Book #3 was action packed, I was surprised to find how much of the book was left when I thought it was nearly done (an ebook problem), but the story was great and the ending was worth it. Really pulling out all the stops in the time travel genre.

• Kevin Fenzi Some Fedora Infra stats in Nov 2023

  Things have been crazy busy of late, but with Fedora 39 out the door and a week of vacation coming up I am finally starting to feel caught up. So, I thought I would share a quick post on some stats:

  Number of instances in fedora-infra ansible inventory: 448

  Instances here means bare metal machines, vm’s on those bare metal machines and some aws instances. It doesn’t include containers or the like.

  Breakdown by OS:

  273 are Fedora of some version and 175 are some RHEL version

  Of the Fedora ones, 1 is f40 (rawhide-test), 39 are f39, 210 are f38 (all the builders are still on f38, going to be reinstalled with f39 soon), 13 f37 and the rest odd older things (our OSBS cluster which is slated for retiremenet).

  Of the RHEL ones, 70 are 9, 59 are 8 and 46 are 7. Many of the ones still on RHEL7 are services we are working to retire or waiting on applications to be ported to RHEL9 (mirrormanager, badges, mailman3, osbs, pdc, mbs). Many of the RHEL8 ones are just tricky ones to upgrade like database servers or virthosts that house those database servers.

  Likely in the coming weeks I will try and get a bunch more of those uplifted before the end of the year. There may be some downtime doing the databases, but hopefully it will be minimal.

November 16, 2023

• Peter Czanik Working with multiple systemd-journal namespaces in syslog-ng

  Initial support for systemd-journal namespaces is available in syslog-ng 3.29. However, only version 4.4.0 allows you to work with multiple namespaces in your syslog-ng configuration.

  So, what changed in the latest version of syslog-ng? Previously, you could only configure a single systemd-journal() source in syslog-ng. By default, it collected logs from all namespaces, but you could configure it to collect log messages from a single one exclusively. This means that logs from other namespaces could not be collected by syslog-ng. Version 4.4.0 allows you to use multiple systemd-journal() source drivers in the configuration, as long as each source uses a unique namespace.

  Before you begin

  You need to install syslog-ng 4.4.0 or later to work with multiple systemd-journal namespaces in syslog-ng. If it is not yet available for your Linux distribution of choice, check our 3^rd party download page: https://syslog-ng.org/3rd-party-binaries/

  You also need systemd-journal with multiple namespaces. Setting this up is not in the scope of this blog. You can learn more about it from its manual pages:

  man systemd-journald.service

  Configuring syslog-ng

  Create a new configuration snippet under /etc/syslog-ng/conf.d/ or append the following configuration to your syslog-ng.conf file (if the conf.d directory is not supported):

  source s_mynamespace {
  	systemd-journal(
  		namespace(mynamespace)
  	);
  };
  
  destination d_mynamespace {
  	file("/var/log/mynamespace");
  };
  
  log {
  	source(s_mynamespace);
  	destination(d_mynamespace);
  };
  
  source s_defnamespace {
  	systemd-journal(
  		namespace("")
  	);
  };
  
  destination d_defnamespace {
  	file("/var/log/defnamespace");
  };
  
  log {
  	source(s_defnamespace);
  	destination(d_defnamespace);
  };
  

  You should also comment out the system() source in syslog-ng.conf while you are testing, as that also includes the systemd-journal() driver.

  Replace the parameter of namespace() in the s_mynamespace source to a name available on your system.

  Note that you can refer to the default namespace by an empty namespace() definition, as seen in the s_defnamespace source.

  Testing

  You should send a few test messages. Sending logs to the default namespace is easy, as you can use logger:

  logger this is a test message

  The test message should show up in /var/log/defnamespace with the aforementioned configuration.

  Creating a test message for the other namespace is a bit more tricky. In my test environment I added the following line to a service file:

  LogNamespace=mynamespace

  Then I reloaded that service. I could see the related log messages showing up in the /var/log/mynamespace file.

  Other recent systemd-source() changes

  Previous syslog-ng versions read the journal from the beginning during the first start. This is not a problem when you install syslog-ng on first boot, but it could result in processing gigabytes of logs if installed later. The journal was also read from the beginning if the syslog-ng persists file was deleted or damaged. There is now a new option, starting with syslog-ng 4.2.0, which is enabled by default in the system() source: match-boot(yes). With this feature, syslog-ng reads logs starting from the current boot instead of the beginning of times. If you want the old behavior, you should configure the systemd-source() yourself instead of the system() source.

  Another new option is the match() filter within the systemd-journal() source. It is best to explain it with a configuration snippet:

  source s_journal_systemd_only {
    systemd-source(matches(
      "_COMM" => "systemd" # filtering on the application name
      )
    );
  };

  What is next?

  By using systemd-journal namespaces, you can selectively process log messages from various namespaces in syslog-ng. You can skip collecting logs from namespaces with logs you do not want to collect centrally using syslog-ng. You can also easily send logs from different namespaces to different destinations.

  -

  If you have questions or comments related to syslog-ng, do not hesitate to contact us. You can reach us by email or even chat with us. For a list of possibilities, check our GitHub page under the “Community” section at https://github.com/syslog-ng/syslog-ng. On Twitter, I am available as @PCzanik, on Mastodon as @Pczanik@fosstodon.org.

• Remi Collet New Computer and x86_64 builder for 2024, 2025...

  My new computer is operational :

  • Gigabyte B760 AORUS Elite AX
  • Intel(R) Core(TM) i9-13900K CPU
  • Memory: 2x32GiB DDR5
  • NVMe disk of 2TB

  Retrieved from my previous computer:

  • Corsair Graphite series 760T box
  • WaterCooling
  • SSD disks, 180GB and 480GB
  • SATA disk of 4TB

  This computer is now my main development workstation and also my x86_64 builder.

  First test, boot time < 5", PHP 8.3 build takes 20" instead of 55". Nice.

  CPU Benchmark shows tripling of results, see i9-9900K vs i9-13900K

  Another comparison, building grpc extension RPM, with the old i9-9900K

  • 4'12" for a single build using -j16
  • 3'29" average for 2 builds using -j8
  • 3'25" average for 3 builds using -j5

  With the new i9-13900K

  • 2'20" for a single build using -j32
  • 1'20" average for 2 builds using -j16
  • 1'05" average for 3 builds using -j10

  I plan to extend it quickly:

  • +64GiB memory

  Thanks to all who want to participate, see the Merci/Thanks page.

  

  Of course, my previous machine, from 2019, will be re-used

November 15, 2023

• Harish Pillay 9v1hp Running a web-based bastion host

  So, I’ve been stuck with two issues:

  a) no ssh access to my servers when I am in a location that’s blocking ssh access.

  b) No access resources on the web on ports like 9090 for management or any non-80 or non-443 port.

  I have a solution for the first problem but none for the second one (yet).

  So, here’s the solution to the first issue: install shellinabox. On my Fedora systems, it is just a simple “dnf install shellinabox -y”.

  The default config of shellinabox – in /etc/sysconfig/shellinabox is shown below:

  # Shell in a box daemon configuration
  # For details see shellinaboxd man page
  
  # Basic options
  USER=shellinabox
  GROUP=shellinabox
  CERTDIR=/var/lib/shellinabox
  PORT=4200
  OPTS="--disable-ssl-menu -s /:LOGIN"
  
  # Additional examples with custom options:
  
  # Fancy configuration with right-click menu choice for black-on-white:
  # OPTS="--user-css Normal:+black-on-white.css,Reverse:-white-on-black.css --disable-ssl-menu -s /:LOGIN"
  
  # Simple configuration for running it as an SSH console with SSL disabled:
  # OPTS="-t -s /:SSH:localhost"

  I changed the last line to read:

  OPTS=" -t -s /:SSH:0.0.0.0"

  Then restart the service via systemctl (systemctl enable shellinaboxd.service and systemctl start shellinaboxd.service), then from the browser point to locahost:4200, and you can get in.

  What I then did was to install shellinabox behind a nginx proxy server on a public Internet facing system and have the nginx proxy server route 80 and 443 requests to the shellinaboxd listening on the default port.

  Now I have to find a way to fix the second problem. Ideas welcome.

November 14, 2023

• Fedora fans نسخه نهایی لینوکس فدورا ۳۹ منتشر شد

  

  

  در ششم نوامبر سال ۲۰۰۳ بود که پروژه ی فدورا اولین نسخه ی خود یعنی Fedora Core 1 را منتشر کرد که اکنون پس بیست سال نسخه نهایی Fedora Linux 39 را منتشر کرد.
  فدورا لینوکس یک سیستم عامل بر پایه جامعه می باشد که برای دسکتاپ، لپ تاپ، سرور، محیط های ابری (Cloud) و edge device ها کاربرد دارد.

  اخبار دسکتاپ

   

  نسخه Fedora workstation اکنون دارای میزکار Gnome 45 است که عملکرد بهتر و بسیاری از پیشرفت‌های قابل توجه از جمله یک تعویض‌کننده جدید فضای کاری و یک نمایشگر تصویر بسیار بهبود یافته را به ارمغان می‌آورد.

  اگر به دنبال تجربه دسکتاپ متفاوتی هستید، گروه Budgie ما Fedora Onyx را ایجاد کرده است که یک دسکتاپ “اتمی” مبتنی بر Budgie با روح Fedora Silverblue می باشد.

  البته این همه چیز نیست و سایر نسخه ها با میزکارهای مختلف از جمله KDE Plasma Desktop, Xfce, Cinnamon و سایر میزکارهای دیگر نیز بروزرسانی شده اند.

   

  فدورا در ابر (Cloud)

   

  Image های  فدورا Cloud به طور رسمی در Microsoft Azure (علاوه بر Google Cloud و AWS) در دسترس خواهند بود. همچنین، Image های ابری اکنون به گونه‌ای پیکربندی شده‌اند که cloud-init می‌تواند (به انتخاب شما) به‌روزرسانی‌ها را نصب کند و هنگامی که برای اولین بار provision شد، reboot شود، بنابراین می‌دانید که از آخرین به‌روزرسانی‌های امنیتی استفاده می‌کنید.

   

  دیگر بروزرسانی ها

   

  مانند همیشه، بسیاری از بسته‌های دیگر بروزرسانی شده اند، در حالی که تلاش می شود بهترین‌ها را از همه چیزهایی که دنیای نرم‌افزار متن‌باز و رایگان ارائه می‌دهد به شما ارائه دهیم.

  لینوکس فدورا ۳۹ شامل gcc 13.2, binutils 2.40, glibc 2.38, gdb 13.2 و rpm 4.19 می باشد و همچنین بروزرسانی زبان های برنامه نویسی مانند Python 3.12 و Rust 1.73

  نکته قابل توجه، فدورا ۳۹ جدیدترین نسخه Inkscape، ابزار محبوب تصویر برداری و طراحی گرافیک برداری را شامل می شود. Inkscape نیز دیروز 20 ساله شد – ما دوقلوهای دیجیتالی هستیم! به همه در آن پروژه عالی نیز تبریک می گویم.

   

  دانلود فدورا ۳۹

  همواره جهت دانلود فدورا لینوکس می توانید به وب سایت رسمی پروژه فدورا مراجعه کنید:

  https://fedoraproject.org/

   

  شاد و فدورایی باشید

   

  The post نسخه نهایی لینوکس فدورا ۳۹ منتشر شد first appeared on طرفداران فدورا.