Open-source News

Intel Alder Lake-N & Raptor Lake-P CPUs To See Huge Power Management Improvements in Linux 6.2  Wccftech

How to Empty a File in Linux  groovyPost

Siemens ports Sokol Linux to RISC-V ...  eeNews Europe

A new generation of tools for open source vulnerability management vdanen Fri, 12/16/2022 - 03:00

Product security incident response teams (PSIRTs) are teams of security professionals that work diligently behind the scenes to protect software products and services of companies. A PSIRT is a different breed than a computer security incident response team (CSIRT), those that tend to be called Information Security. The difference is simple but stark: a CSIRT focuses on responding to incidents that affect a company's infrastructure, data or users. A PSIRT focuses on responding to incidents that affect products a company builds, the most common being the discovery of a vulnerability or security defect, and subsequent actions to manage or remediate.

Tools for PSIRT

I've been a part of a PSIRT for over 20 years, first as the leader of Mandriva's PSIRT (although we didn't call it that then) and currently for Red Hat. While its changing somewhat today, there were never that many tools for a PSIRT to use, compared to the plethora of tools available to CSIRTs. Sure we have static code analysis (SCA), static application security testing (SAST), and dynamic application security testing (DAST) tools to identify known and unknown vulnerabilities in our products. But there was never a great way to manage the data around those vulnerabilities so most PSIRTs rely on homegrown tooling or piggyback things onto existing tools that weren't meant for that use.

For example, when I started at Red Hat nearly 14 years ago, I used the Bugzilla instance directly to track and file bugs and vulnerability information. Back then it was quite simple – there was a CVE bug which contained the details of a vulnerability and then created children bugs for product teams to track to remediation. This worked when we only had to worry about OpenShift and the JBoss Enterprise Application Platform. As we began to develop and support more products, we found doing this manually didn't scale with such a small team. We wrote a series of scripts in Python, fondly referred to as security flaw manager (SFM), that manipulated Bugzilla through API calls to create bugs, add comments, and other metadata. This occurred when a flaw was reported, made public, impact and scoring metrics, what products were affected, and other useful data. None of which were properly supported by the bug tracking systems, and were instead stuffed in other fields in custom formats, prone to human meddling. While rudimentary, these scripts did what we needed them to do, for a time. But as we wanted to collect more metadata, and had increasingly more products to support, SFM felt a little long in the tooth. After all, who wants to do all of this work on the command line?

A number of years ago we endeavored to create a new tool. We developed SFM2, which was a single web-based application that did what SFM did and more. It had better search, which helped with the ever-growing number of CVEs we had to track and deal with. It provided better checks for quality, ensuring we didn't miss anything as dealing with more vulnerabilities and more products became ever more complicated. We knew this was something that other PSIRTs might be interested in and for some time we held out hope to modularize it and make it open and available. But it was still bound to specific Bugzilla customizations. This made it difficult or impossible for anyone (other than us) to use it.

More on Microservices Microservices cheat sheet How to explain microservices to your CEO Free eBook: Microservices vs. service-oriented architecture Free online course: Developing cloud-native applications with microservices arc… Latest microservices articles The evolution of SFM2

This was quite frustrating as we had effectively developed innersource, a term coined by Tim O'Reilly over two decades ago. Everything was written with open languages and built in an open source way. But we couldn't share it and no one could benefit from our work, nor could we benefit from others experience and input. We knew there were other companies out there dealing with more complexity in their products and, now, managed or hosted services. As a leader in managing open source vulnerabilities, our team had some excellent tooling we couldn't share with anyone due to how we had inadvertently allowed feature creep and ties to custom tooling to get in the way.

So last year we took a look again at the problem. SFM2 was not designed in a way that allowed us to maintain it well, and there were some other deficiencies that we needed to correct — but we had hit a wall. We needed different capabilities, and the tooling was designed for a very specific way of working that needed to change for efficiency and scale. And using Bugzilla as a backend database, which worked well enough a decade ago, was no longer ideal. In fact it was the single biggest hindrance we had.

What we needed was not a monolithic application but a set of smaller services that worked well together using APIs. The way I explained it when we were conceptualizing this a year ago was the difference between the sendmail and qmail email servers. Sendmail was a single monolithic application that did everything, whereas qmail had different services where output from one was passed as input to another, and each service was distinct and unique enough to make it easier to maintain. This was after all, a key part of the original UNIX philosophy, something that many of us who've been doing this for quite a while, still hold in high esteem.

As a result, we set out to build four primary applications: a flaw database that would store all of the vulnerability information (replacing Bugzilla as our backend), a frontend to that database to make it easy to add and update information, a registry of components that could be used as a manifest of all our products and services so we could easily find where any given component might live, and finally a license scanner to ensure we met our open source license compliance requirements. One of the core design principles was to have the primary method of interaction be via APIs such that we could write a frontend that no one was obligated to use (if an end-user was authorized, they could recreate the SFM scripts of yore to interact with the flaw information via the command line). But more importantly, the services could be integrated with other existing tooling directly, using standardized and open data interchange formats, rather than manual duplication of metadata from one platform to another.

Further, another core principle that had to be adhered to was that these tools needed to be developed in the open. We did this for a few reasons. One, we wanted others to be able to use and contribute to these tools. Second, it enforced a certain amount of rigor — we couldn't design these tools for our own use exclusively, so no more innersource.

With the experience and lessons learned moving through not just one but two generations of tooling to support open source vulnerability management, we're pretty sure we chose the right path forward. Yet, we're humble enough to know that others may have different needs and hence the invitation to join us to develop these tools. Nearly everyone, from large enterprise open source producers, to the pizza shop down the street with their web and mobile applications, are software developers. So there's a need for tools to manage vulnerabilities beyond homegrown ones, spreadsheets, hacked up add-ons to software or services not designed to handle a PSIRT process. There are a lot of tools for CSIRTs and developers, but not that many tools for incident response and coordination.

If you're interested in looking at or using any of these tools, we invite you to collaborate with us through GitHub. While we have been working on these for a while, we have only worked on three of the four tools to-date. The fourth, the frontend to the flaw database, or the service layer that operates between these services, is yet to be started.

• Component Registry: which is used to store all of the component information across any number of products and services

• OSIDB: the Open Security Issue Database, is the database to store all vulnerability data

• OpenLCS: the Open License and Crypto Scanner, is the tool to obtain license and cryptography information from shipped components

Product security incident response teams require a unique set of tools for the discovery and remediation of a vulnerability or security defect. Open source is the solution.

Image by:

Opensource.com

Innersource Security and privacy Microservices What to read next This work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License. Register or Login to post a comment.

5 reasons to love Linux GNOME Files sethkenlon Fri, 12/16/2022 - 03:00

The GNOME desktop is a common default desktop for most Linux distributions and, as with most operating systems, you manage your data on GNOME with software called a file manager. GNOME promotes a simple and clear naming scheme for its applications, and so its file manager is called, simply, Files. Its intuitive interface is simple enough that you forget what operating system you're using altogether. You're just using a computer, managing files in the most obvious way. GNOME Files is a shining example of thoughtful, human-centric design, and it's an integral part of modern computing. These are my top five favorite things about GNOME Files, and why I love using it.

1. Intuitive design Image by:

(Seth Kenlon, CC BY-SA 4.0)

More Linux resources Linux commands cheat sheet Advanced Linux commands cheat sheet Free online course: RHEL technical overview Linux networking cheat sheet SELinux cheat sheet Linux common commands cheat sheet What are Linux containers? Our latest Linux articles

As long as you've managed files on a computer before, you basically already know how to use GNOME Files. Sure, everybody loves innovation, and everybody loves seeing new ideas that make the computer world a little more exciting. However, there's a time and a place for everything, and frankly sometimes the familiar just feels better. Good file management is like breathing. It's something you do without thinking about what you're doing. When it becomes difficult for any reason, it's disruptive and uncomfortable.

GNOME Files doesn't have any surprises in store for you, at least not the kind that make you stop what you thought you were doing in order to recalculate and start again. And my favorite aspect of the "do it the way you think you should do it" design of GNOME Files is that there isn't only one way to accomplish a task. One thing I've learned from teaching people how to do things on computers is that everyone seems to have a slightly different workflow for even the simplest of tasks, so it's a relief that GNOME Files accounts for that.

When you need to move a file, do you open a second window so you can drag and drop between the two? Or do you right-click and Cut the file and then navigate to the destination and Paste the file? Or do you drag the file onto a button or folder icon, blazing a trail through directories as they open for you? In GNOME Files, the "standard" assumptions usually apply (insofar as there are standard assumptions.)

2. Space saver

If you manage a lot of files for a lot of the time you're at your computer, you're probably familiar with just how much screen real estate a file manager can take up. Many file managers have lots of buttons across several toolbars, a menu bar, and a status bar, such that just one file manager window takes up a good portion of your screen. To make matters worse, many users prefer to open several folders, each in its own window, which takes even more space.

GNOME Files tends to optimize space. What takes up three separate toolbars in other file managers is in a single toolbar in GNOME Files, and that toolbar is what would traditionally be the window title bar. In the top bar, there's a forward and back button, file path information, a view settings button, and a drop-down menu with access to common functions.

Image by:

(Seth Kenlon, CC BY-SA 4.0)

3. Other locations

Not all operating systems or file managers make it so you can interact with your network as naturally as you can interact with your own computer. Linux has a long tradition of viewing the network as just another computer, and in fact, the name "GNOME" was an acronym for "GNU Network Object Model Environment."

In GNOME Files, it's trivial to open a folder on a computer you're not sitting in front of. Whether it's a server in a data center or just your office desktop while you're relaxing in your lounge with a laptop, the Other Locations bookmark in the GNOME Files side panel allows you to access files as if they were on your hard drive.

Image by:

(Seth Kenlon, CC BY-SA 4.0)

To use it, you enter the file sharing protocol you want to use, along with the username and IP address of the computer you want to access. The ssh:// protocol is most common between Linux or Unix machines, while smb:// is useful for an environment with Windows machines, and dav:// is useful for applications running on the Internet. Assuming the target computer is accessible over the protocol you're using, and that its firewall is set correctly to permit you to pass through it, you can interact with a remote system as naturally as though they were on your local machine.

4. Preferences

Most file managers have configuration options, and to be fair GNOME Files actually doesn't give you very many choices compared to others. However, the options that it does offer are, like the modes of working it offers its users, the "standard" ones. I'm misusing the word "standard" intentionally: There is no standard, and what feels standard to one person is niche to someone else. But if you like what you're experiencing with GNOME Files under normal circumstances, and you feel that you're its intended audience, then the configuration options it offers are in line with the experience it promotes. For example:

• Sort folders before files

• Expand folders in list view

• Show the Create link option in the contextual menu

• Show the Delete Permanently option in the contextual menu

• Adjust visible information beneath a filename in icon view

That's nearly all the options you're given, and in a way it's surface-level choices. But that's GNOME Files. If you want something with more options, there are several very good alternatives that may better fit your style of work. If you're looking for a file manager that just covers the most common use cases, then try GNOME Files.

5. It's full of stars

I love the concept of metadata, and I generally hate the way it's not implemented. Metadata has the potential to be hugely useful in a pragmatic way, but it's usually relegated to specialized metadata editing applications, hidden from view and out of reach. GNOME Files humbly contributes to improving this situation with one simple feature: The gold star.

In GNOME Files, you can star any file or folder. It's a bit of metadata so simple that it's almost silly to call it metadata, but in my experience, it makes a world of difference. Instead of desperately running find command to filter files by recent changes, or re-sorting a folder by modification time, or using grep to find that one string I just know is in an important file, I can star the files that are important to me.

Making plans for the zombie apocalypse all day? Star it so you can find it tomorrow when you resume your important work. After it's over and the brain-eaters have been dealt with, un-star the folder and resume normal operation. It's simple. Maybe too simple for some. But I'm a heavy star-user, and it saves me several methods of searching and instead reduces "what was I working on?" to the click of a single button.

Install GNOME Files

If you've downloaded a mainstream Linux distribution, then chances are good that you already have GNOME and GNOME Files installed. However, not all distributions default to GNOME, and even those that do often have different desktops available for download. The development name of GNOME Files is nautilus, so to find out whether you have GNOME Files installed, open a terminal and type nautilus & and then press Return. If you see this error, you don't have GNOME Files available:

bash: nautilus: command not found...

To install GNOME Files, you must install the GNOME desktop. If you're happy with your current desktop, though, that's probably not what you want to do. Instead, consider trying PCManFM or Thunar.

If you're interested in GNOME, though, this is a great reason to try it. You can probably install GNOME from your distribution's repository or software center.

GNOME Files is the name of the file manager for the GNOME desktop. Its intuitive design is just one of the many reasons I love to use it.

Image by:

Gunnar Wortmann via Pixabay. Modified by Opensource.com. CC BY-SA 4.0.

Linux What to read next This work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License. Register or Login to post a comment.

The post How To Run a Cron Job Every 30 Seconds in Linux first appeared on Tecmint: Linux Howtos, Tutorials & Guides .

Brief: The cron job scheduler does not support scheduling jobs to run at an interval of seconds. In this article, we will show you a simple trick to help you run a cron job

The post How To Run a Cron Job Every 30 Seconds in Linux first appeared on Tecmint: Linux Howtos, Tutorials & Guides.

The advantages of coding on Linux  Qrius

The advantages of coding on Linux  Qrius

Updated Linux Kernel 6.1 Makes Rust the Greatest Programming ...  Analytics Insight

KVM Preps For New Intel CPU Instructions With Linux 6.2  Phoronix

The initial batch of feature updates for the Kernel-based Virtual Machine (KVM) have been submitted for the Linux 6.2 merge window...

OnePlus to launch its first keyboard with customisable design for Mac, Windows, Linux  Business Today

Harmonoid: A Beautiful Cross-Platform Music Player With Essential ...  It's FOSS

Pine64 announces PineTab2 Linux tablet powered by Rockchip ...  Notebookcheck.net

First Look at Ubuntu 23.04’s Brand-New Desktop Installer Written in Flutter  9to5Linux

exFAT With Linux 6.2 Allows Creating Files & Directories Much Faster  Phoronix

For those relying on Microsoft's exFAT file-system for your SD cards or USB flash drives, the kernel driver with Linux 6.2 is capable of handling much faster file and directory creation than on prior versions...

AMD today capped off their busy week by releasing ROCm 5.4.1 as the newest version of their open-source compute stack...

Daily Crunch: Major Tech Firms Partner with Linux Foundation to Support Open Map Data ... - Latest Tweet by  LatestLY

Daily Crunch: Major tech firms partner with Linux Foundation to support open map data development  TechCrunch