Open-source News

Best Music Games for Linux of 2022 May  BollyInside

Tails 5.0 Linux users warned against using it "for sensitive information"  BleepingComputer

20 systemctl commands for system and service management  TechTarget

Build 2022: Microsoft Adds Linux XDP Support via Windows for XDP  WinBuzzer

How to install the Apache Druid real-time analytics database on Ubuntu-based Linux distributions  TechRepublic

A Beginner's Guide to Pamac in Manjaro Linux  MUO - MakeUseOf

Psychonauts 2 May 24 Update Brings Linux and macOS Versions  Player.One

Software Metadata Standards Wrap Up Bigger Connections

This article originally appeared on Linux.com. The author, Cameron Laird, is vice president of Phaseit, Inc. where he implements software projects and publishes articles about the results. A long-time developer, manager, and author, he’s most recently concentrated on architectural challenges of “continuous everything”: continuous integration, continuous testing, and so on.

You’re in the news. But not with the headline you want.

You’re not getting attention because of your choice of text editor or the number of spaces you use to indent code blocks. However motivating those preferences are for you and me, the non-technical world sees them as private choices. You find your code in the headlines for a different and unpleasant reason: open source dependency management.

We have dependencies, of course, because we know not to “reinvent the wheel”; instead, we software experts re-use the implementations others have created. However, when done poorly, dependency management introduces more risk and degrades the quality of your application. For example, failure to comply with license requirements might be the problem.  Even worse: the absence of a license tied to a component you embedded in your application. In both cases, there are potential legal implications.

Still more traumatic is a media headline announcing that a vulnerability just breached your organization in one of those dependencies. Projects frequently re-use software components to simplify or accelerate development; but sometimes, it can have detrimental results by introducing said vulnerabilities.

That’s not all:  suppose you are experienced and thoughtful enough to recognize this hazard and commit to good dependency management.  It turns out that’s a harder problem than might first appear, and certainly not the kind of thing that can be slipped into a project on its last days, without significant time or other costs.

Building A Standard For Software Bill Of Materials

How, for instance, does an industrial oven manufacturer communicate that one of its products depends on a particular library with a known vulnerability?  How does it say that it does not have such a dependency?  One of the difficulties comes from mixing open and closed information sets. What happens in a scenario where an automotive chip uses an open source sorting algorithm, but the auto manufacturer wants to keep the use of that algorithm proprietary?

Without a better alternative, any discussion about the algorithm has to occur under cover of a non-disclosure agreement (NDA), often one written specifically for the business and technical situation.  Where developers investigating a particular piece of software might be accustomed to connecting to GitHub and inspecting the source in question in a few seconds, even the simplest proprietary questions sometimes take months of legal, security, and compliance negotiation to begin to examine. “Manual” inspection, in any case, is unscalable.  The average application contains 200 OSS components, and each component might manually take three hours to inspect.  Does your project have a better use for 600 hours of effort?  Open source truly begins to pay off when it’s inspected not just by expert engineers but by automatic tools.

Recognize, moreover, that transitive dependencies make dependency management a harder problem than first appears.  Many of the most notorious breaches occurred not because anything was wrong with the source of a product or even the source of the libraries on which it depends; the vulnerability only turned up in a library used by those other libraries.  Over and over again, CEOs who’ve asked, “does $SOME_PROBLEM affect us?” have received the answer, “we don’t know yet: we’re not sure where it shows up in our systems.” We need transparency about dependencies and enough intelligence and standardization around hierarchical relationships to “trace the whole tree.” Organizations must track dependencies through to the operating system run-time and sometimes down to “the silicon,” that is, the microprocessor on which the software runs.

It’s a hard problem but also a solvable one.  Part of any solution is a well-defined software bill of materials (SBOM or sometimes SBoM). That’s where Kate Stewart’s career began to track this story.  Stewart currently serves the Linux Foundation as a vice president of Dependable Embedded Systems.  In previous assignments with such employers as Motorola, Freescale Semiconductor, Canonical, and Linaro, she frequently faced challenges that mixed technical and legal aspects.  As she explained her long-time focus in a recent interview, “if open source components are going to be in safety-critical places … [we need] to be able to trust open source in those spaces …” Good SBOM practices are simply necessary for the level of trust we want to have not just in industrial ovens, but airplanes, medical devices, home security systems, and much more.  An SBOM organizes such metadata about a software artifact as its identity, verification checks it hasn’t been tampered with, copyright, license, where to look up known security vulnerabilities, dependencies to check, and so on. Think of an SBOM as an ingredients list for your software.  It makes those ingredients visible, trackable, and traceable.  It lets you know if you have used the highest quality and least risky open source components to build your software.

Enter SPDX

Stewart and other technologists eventually began to team with specialists in intellectual property, product managers, and others. They developed such concepts in the early years of this millennium as SBOM, the Software Package Data Exchange (SPDX), and the OpenChain Specification.  She co-founded SPDX in 2009 to pursue “[a]n open standard for communicating software bill of materials information ….” Among other features and benefits, these frameworks provide standard and scalable ways to discuss dependencies.

Instead of each vendor having to certify that each of its releases has been verified for security and license compliance of each of eight hundred JavaScript libraries, for example, many of the most time-consuming aspects of compliance can be automated.  When a new vulnerability is identified in an implementation of a networking protocol, automated methods can largely be applied to determine which products embed known vulnerable libraries, even while we developers remain largely unaware of the details of each component and dependency they use.  For Stewart, standards-based transparency and best practices are prerequisites for the security of safety-critical communities she helps serve.  As Stewart observes, “you can’t really be safe unless you know what you’re running.”

Daily Headlines

Does that sound mundane?  The reality’s far different:  SBOM and related technologies actually play roles in events on the world stage.  For example, on the 12th of May, 2021, US President Biden issued Executive Order 14028 on Cybersecurity Improvement; SBOMs play a prominent role there.  The Open Source Initiative just named Stefano Maffulli its first Executive Director precisely because of the need for mature open source licensing practices.  Dr. Gail Murphy argued in a recent interview that it’s time to recognize that open source software is a “triumph of information-hiding [and] modularity …” in enabling the remarkable software supply chains on which we depend.  Emerging information on breaches including SolarWinds, Rapid7, Energetic Bear, and especially the latest on Juniper’s Dual-EC affair shows how disastrous it becomes when we get those supply chains wrong.  The most prominent breaches in computing history have been tied to component vulnerabilities that seemed peripheral until break-ins demonstrated their centrality.

Drone strikes?  Vaccine efficacy?  Voter fraud?  International commerce?  Nuclear proliferation?  Questions about software and data reliability and fidelity are central to all these subjects, not mere technical tangents.

That’s why SPDX’s management of hierarchical relationships is so crucial.

ISO/IEC 5926:2021 Introduces SBOM Standard

SPDX went live as an official international standard at the end of August.  With that milestone, standardization lowers many of the hurdles to the successful completion of an SBOM project.  Implementation becomes more consistent. “Bookkeeping” about external parts becomes largely a responsibility of the standard.  Software engineers focus more on the details specific to an application.  Then, as those external parts–the ingredients of an SBOM recipe–age and security vulnerabilities are discovered in them, developers can reliably track those components to the applications where they were used and update components to newer, hardened versions. What does that mean for you?  In your own work, the faster you identify and update vulnerable components, the less likely the chance you will have of becoming the next breach headline following an attack.

SPDX’s standardization fits in the frameworks of the International Organization for Standardization (ISO) the International Electrotechnical Commission (IEC).  ISO is a post-war transnational creation that originally focused on bolt sizes, temperature measurements, and medical supplies.  ISO tracks human affairs, of course, and its attention in recent years has shifted from materials to business processes and, in this millennium, to software.  IEC is a prior generation’s initiative to pursue the same kinds of standardization and cooperation, specifically in the realm of electrical machinery; the IEC and ISO often collaborate.

In bald terms, ISO and IEC matter to you as a programmer because governments trust them.  The new standard is sure to make its way rapidly into procurement specifications, especially for government purchases.  Suppliers become accustomed to compliance with such standards and apply them in their practices more generally.  The earlier ISO 9000 collection of standards has already greatly influenced software development.

Important Though Abstract

The impact and scope of ISO:IEC 5926:2021 is a challenge to understand, let alone explain.  On the one hand, millions of working programmers worldwide go about their daily chores with little thought of SPDX or even SBOMs.  While we all know we depend on packages, we largely leave it to Maven or npm, or RubyGems, etc., to handle the details for us.  Standardization of SPDX looks like a couple of layers of abstraction, even more remote from the priorities of the current sprint or customer emergency on our desks right now.

And it’s true:  SPDX is abstract, and its technical details look dry to some programmers, the opposite of the “sexy” story many start-ups aspire to.

Without this infrastructure, though, the development of many large, complex, or mission-critical projects would grind to a halt from the friction of communication about proprietary dependencies on open source artifacts.  Think of it on a weight basis:  as the Linux Foundation’s own press release underlines, “… between eighty and ninety percent of a modern application is assembled from open source software components.” SPDX is immensely important at the same time as it’s uninteresting to all but the most specialized practitioners.

Look to history for examples of how momentous this kind of standardization is.  The US’s Progressive movement at the beginning of the twentieth century is instructive.  While often taught in ideological terms, many of its greatest achievements had to do with mundane, household matters:  does a milk bottle actually contain milk?  Can standard doses of medicines be trusted?  Is a “pound” in a butcher’s shop a full sixteen ounces?  Standards in these areas resulted in more convenience and transformed commerce to enable new market arrangements and achievements. That’s the prospect for SPDX:  more transparent and effective management of software dependencies and interactions will have far larger consequences than are first apparent.  Notice, for instance, that while the standard examples of its use have to do with open-source software, the standard itself and the tools that support it can also be applied to proprietary software and other intellectual property.  SPDX doesn’t solve all problems of communicating about dependencies; it goes a long way, though, to clarify the boundaries between technical and legal aspects.

Long Lead Time

The significance and need for secure software supply chains haven’t made SPDX’s adoption easy, though.  Stewart reports that individual companies drag their feet: “why should we do something before we have to?” these profit-oriented companies reasonably wonder.  Even in the best of circumstances, when an industry has largely achieved a technical consensus, “From first proposal to final publication, developing a standard usually takes about 3 years.“

Stewart herself cites this year’s Executive Order as crucial: “the one thing that made a difference” in pushing forward adoption of SPDX in 2021 was the emerging SBOM requirements that followed EO14028.  Much of her own emphasis and achievement of late has been to get decision-makers to face the reality of how crucial their dependence on open source is. No longer can they restrict focus to the 10% of a proprietary product because supply chain attacks have taught us that the 90% they re-use from the software community at large needs to be exposed and managed.

Publication of a standard mirrors application development in having so many dependencies “under the covers.” It’s not just Stewart who worked on this for more than a decade, but, as I’ll sketch in follow-ups through the next month, a whole team of organizations and individuals who each supplied a crucial requirement for completion of ISO/IEC 5926:2021.  When you or I think of great software achievements, our memories probably go to particular winning prototypes turned out over a weekend. Standards work isn’t like that.  The milestones don’t come at the rapid pace we relish. Successful standards hold out the promise, though, of impacting tens of thousands of applications at a time. That’s a multiplier and scalability that deserves more attention and understanding.

SBOMs For Everything

And that’s why ISO/IEC 5926:2021 is good news for us.  We still have licensing and security issues to track down. We still need to attend meetings on governance policies. Management of proprietary details remains delicate.  Every project and product needs its own SBOM, and vulnerabilities will continue to crop up inconveniently. With the acceptance of ISO/IEC 5926:2021, though, there’s enough standardization to implement continuous integration/continuous deployment (CI/CD) pipelines usefully. We can exchange dependency information with third parties reliably. SPDX provides a language for describing dependency management chores. SPDX gives answers that are good enough to focus most of our attention on delivering great new functionality.

The best practices of application development applied by developers as a learned methodology can be something more than an exercise in walking a tightrope of intellectual property restrictions. Enterprise-class proposal requests become more engineering than lawyering.  You have a better shot at being in the news for your positive achievements rather than the security calamities into which you’ve stumbled.

Check in over the next several weeks to learn more about what SPDX means to your own programming, how SPDX is a model for other large-scale collaborations the Linux Foundation enables, and how teamwork is possible across profit-making boundaries.  In the meantime, celebrate ISO/IEC 5926:2021 as one more problem that each project does not have to solve for itself.

The post ISO establishes SBOM standard for open source development with SPDX appeared first on Linux Foundation.

Install Jitsi Meet on Ubuntu 22.04 LTS Jammy Linux  Linux Shout

Original killer PC spreadsheet Lotus 1-2-3 now runs on Linux natively  The Register

Windows Server 2022 now supports WSL2 Linux distributions  XDA Developers

Linux 5.19 Heavy On Intel Power Management & Thermal Improvements  Phoronix

The power management, ACPI, and thermal control updates are ready for Linux 5.19. This cycle there is a lot of PM/thermal work as usual on the Arm side while Intel also continues with a lot of changes from new hardware support to improving overheat handling of laptops for S0ix handling...

Migrate databases to Kubernetes using Konveyor Yasu Katsuno Wed, 05/25/2022 - 08:21 1 reader likes this 1 reader likes this

Kubernetes Database Operator is useful for building scalable database servers as a database (DB) cluster. But because you have to create new artifacts expressed as YAML files, migrating existing databases to Kubernetes requires a lot of manual effort. This article introduces a new open source tool named Konveyor Tackle-DiVA-DOA (Data-intensive Validity Analyzer-Database Operator Adaptation). It automatically generates deployment-ready artifacts for database operator migration. And it does that through datacentric code analysis.

What is Tackle-DiVA-DOA?

Tackle-DiVA-DOA (DOA, for short) is an open source datacentric database configuration analytics tool in Konveyor Tackle. It imports target database configuration files (such as SQL and XML) and generates a set of Kubernetes artifacts for database migration to operators such as Zalando Postgres Operator.

Image by:

(Yasuharu Katsuno and Shin Saito, CC BY-SA 4.0)

DOA finds and analyzes the settings of an existing system that uses a database management system (DBMS). Then it generates manifests (YAML files) of Kubernetes and the Postgres operator for deploying an equivalent DB cluster.

Image by:

(Yasuharu Katsuno and Shin Saito, CC BY-SA 4.0)

More on Kubernetes What is Kubernetes? Free online course: Containers, Kubernetes and Red Hat OpenShift technical over… eBook: Storage Patterns for Kubernetes Test drive OpenShift hands-on An introduction to enterprise Kubernetes How to explain Kubernetes in plain terms eBook: Running Kubernetes on your Raspberry Pi homelab Kubernetes cheat sheet eBook: A guide to Kubernetes for SREs and sysadmins Latest Kubernetes articles

Database settings of an application consist of DBMS configurations, SQL files, DB initialization scripts, and program codes to access the DB.

• DBMS configurations include parameters of DBMS, cluster configuration, and credentials. DOA stores the configuration to postgres.yaml and secrets to secret-db.yaml if you need custom credentials.
   
• SQL files are used to define and initialize tables, views, and other entities in the database. These are stored in the Kubernetes ConfigMap definition cm-sqls.yaml.
   
• Database initialization scripts typically create databases and schema and grant users access to the DB entities so that SQL files work correctly. DOA tries to find initialization requirements from scripts and documents or guesses if it can't. The result will also be stored in a ConfigMap named cm-init-db.yaml.
   
• Code to access the database, such as host and database name, is in some cases embedded in program code. These are rewritten to work with the migrated DB cluster.

Tutorial

DOA is expected to run within a container and comes with a script to build its image. Make sure Docker and Bash are installed on your environment, and then run the build script as follows:

$ cd /tmp
$ git clone https://github.com/konveyor/tackle-diva.git
$ cd tackle-diva/doa
$ bash util/build.sh
…
docker image ls diva-doa
REPOSITORY   TAG       IMAGE ID       CREATED        SIZE
diva-doa     2.2.0     5f9dd8f9f0eb   14 hours ago   1.27GB
diva-doa     latest    5f9dd8f9f0eb   14 hours ago   1.27GB

This builds DOA and packs as container images. Now DOA is ready to use.

The next step executes a bundled run-doa.sh wrapper script, which runs the DOA container. Specify the Git repository of the target database application. This example uses a Postgres database in the TradeApp application. You can use the -o option for the location of output files and an -i option for the name of the database initialization script:

$ cd /tmp/tackle-diva/doa
$ bash run-doa.sh -o /tmp/out -i start_up.sh \
      https://github.com/saud-aslam/trading-app
[OK] successfully completed.

The /tmp/out/ directory and /tmp/out/trading-app, a directory with the target application name, are created. In this example, the application name is trading-app, which is the GitHub repository name. Generated artifacts (the YAML files) are also generated under the application-name directory:

$ ls -FR /tmp/out/trading-app/
/tmp/out/trading-app/:
cm-init-db.yaml  cm-sqls.yaml  create.sh*  delete.sh*  job-init.yaml  postgres.yaml  test/

/tmp/out/trading-app/test:
pod-test.yaml

The prefix of each YAML file denotes the kind of resource that the file defines. For instance, each cm-*.yaml file defines a ConfigMap, and job-init.yaml defines a Job resource. At this point, secret-db.yaml is not created, and DOA uses credentials that the Postgres operator automatically generates.

Now you have the resource definitions required to deploy a PostgreSQL cluster on a Kubernetes instance. You can deploy them using the utility script create.sh. Alternatively, you can use the kubectl create command:

$ cd /tmp/out/trading-app
$ bash create.sh  # or simply “kubectl apply -f .”

configmap/trading-app-cm-init-db created
configmap/trading-app-cm-sqls created
job.batch/trading-app-init created
postgresql.acid.zalan.do/diva-trading-app-db created

The Kubernetes resources are created, including postgresql (a resource of the database cluster created by the Postgres operator), service, rs, pod, job, cm, secret, pv, and pvc. For example, you can see four database pods named trading-app-*, because the number of database instances is defined as four in postgres.yaml.

$ kubectl get all,postgresql,cm,secret,pv,pvc
NAME                                        READY   STATUS      RESTARTS   AGE
…
pod/trading-app-db-0                        1/1     Running     0          7m11s
pod/trading-app-db-1                        1/1     Running     0          5m
pod/trading-app-db-2                        1/1     Running     0          4m14s
pod/trading-app-db-3                        1/1     Running     0          4m

NAME                                      TEAM          VERSION   PODS   VOLUME   CPU-REQUEST   MEMORY-REQUEST   AGE   STATUS
postgresql.acid.zalan.do/trading-app-db   trading-app   13        4      1Gi                                     15m   Running

NAME                            TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
service/trading-app-db          ClusterIP   10.97.59.252    <none>        5432/TCP   15m
service/trading-app-db-repl     ClusterIP   10.108.49.133   <none>        5432/TCP   15m

NAME                         COMPLETIONS   DURATION   AGE
job.batch/trading-app-init   1/1           2m39s      15m

Note that the Postgres operator comes with a user interface (UI). You can find the created cluster on the UI. You need to export the endpoint URL to open the UI on a browser. If you use minikube, do as follows:

$ minikube service postgres-operator-ui

Then a browser window automatically opens that shows the UI.

Image by:

(Yasuharu Katsuno and Shin Saito, CC BY-SA 4.0)

Now you can get access to the database instances using a test pod. DOA also generated a pod definition for testing.

$ kubectl apply -f /tmp/out/trading-app/test/pod-test.yaml # creates a test Pod
pod/trading-app-test created
$ kubectl exec trading-app-test -it -- bash  # login to the pod

The database hostname and the credential to access the DB are injected into the pod, so you can access the database using them. Execute the psql metacommand to show all tables and views (in a database):

# printenv DB_HOST; printenv PGPASSWORD
(values of the variable are shown)

# psql -h ${DB_HOST} -U postgres -d jrvstrading -c '\dt'
             List of relations
 Schema |      Name      | Type  |  Owner  
--------+----------------+-------+----------
 public | account        | table | postgres
 public | quote          | table | postgres
 public | security_order | table | postgres
 public | trader         | table | postgres
(4 rows)

# psql -h ${DB_HOST} -U postgres -d jrvstrading -c '\dv'
                List of relations
 Schema |         Name          | Type |  Owner  
--------+-----------------------+------+----------
 public | pg_stat_kcache        | view | postgres
 public | pg_stat_kcache_detail | view | postgres
 public | pg_stat_statements    | view | postgres
 public | position              | view | postgres
(4 rows)

After the test is done, log out from the pod and remove the test pod:

# exit
$ kubectl delete -f /tmp/out/trading-app/test/pod-test.yaml

Finally, delete the created cluster using a script:

$ bash delete.shWelcome to Konveyor Tackle world!

To learn more about application refactoring, you can check out the Konveyor Tackle site, join the community, and access the source code on GitHub.

Konveyor Tackle-DiVA-DOA helps database engineers easily migrate database servers to Kubernetes.

Kubernetes Upstream Communities What to read next Refactor your applications to Kubernetes This work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License. 31 points | Follow shinsa82 Open Enthusiast Author Register or Login to post a comment.

Cyber Security Today, May 25, 2022 - A Linux trojan is spreading, malware aimed at security researchers and more  IT World Canada

BPFDoor malware uses Solaris vulnerability to get root privileges  BleepingComputer

Gain foundational skills in Linux and IT with this course bundle deal  BleepingComputer

TUXEDO Aura 15 Gen2 - AMD Ryzen 5000 Series Powered, Linux Laptop Review  Phoronix

Bavarian PC vendor TUXEDO Computers that specializes in various Linux pre-loaded notebooks and desktop computers recently launched their Aura 15 Gen2 laptop focused on being an "affordable business allrounder" and powered by AMD Ryzen 5000 series processors with integrated Vega graphics to make for a nice open-source driver experience. TUXEDO sent over the Aura 15 Gen2 for a round of testing and here's a look at this Ubuntu Linux laptop's performance and capabilities.

It was over a year ago that AMD initially added the "GFX90A" target to their LLVM AMDGPU compiler back-end while now this week added to the GNU Compiler Collection for the GCC 13 release not due out until next year is its GFX90A support for the GNU toolchain...