"After approximately seven years in development, the Eclipse Foundation's Theia IDE project is now generally available," writes ADT magazine, "emerging from beta to challenge Microsoft's similar Visual Studio Code (VS Code) editor." The Eclipse Theia IDE is part of the Eclipse Cloud DevTools ecosystem. The Eclipse Foundation calls it "a true open-source alternative to VS Code," which was built on open source but includes proprietary elements, such as default telemetry, which collects usage data... Theia was built on the same Monaco editor that powers VS Code, and it supports the same Language Server Protocol (LSP) and Debug Adapter Protocol (DAP) that provide IntelliSense code completions, error checking and other features. The Theia IDE also supports the same extensions as VS Code (via the Open VSX Registry instead of Microsoft's Visual Studio Code Marketplace), which are typically written in TypeScript and JavaScript. There are many, many more extensions available for VS Code in Microsoft's marketplace, while "Extensions for VS Code Compatible Editors" in the Open VSX Registry number 3,784 at the time of this writing... The Eclipse Foundation emphasized another difference between its Theia IDE and VS Code: the surrounding ecosystem/community. "At the core of Theia IDE is its vibrant open source community hosted by the Eclipse Foundation," the organization said in a news release. "This ensures freedom for commercial use without proprietary constraints and fosters innovation and reliability through contributions from companies such as Ericsson, EclipseSource, STMicroelectronics, TypeFox, and more. The community-driven model encourages participation and adaptation according to user needs and feedback." Indeed, the list of contributors to and adopters of the platform is extensive, also featuring Broadcom, Arm, IBM, Red Hat, SAP, Samsung, Google, Gitpod, Huawei and many others. The It's FOSS blog has some screenshots and a detailed rundown. ADT magazine stresses that there's also an entirely distinct (but related) project called the Eclipse Theia Platform (not IDE) which differs from VS Code by allowing developers "to create desktop and cloud IDEs using a single, open-source technology stack" [that can be used in open-source initiatives]. The Eclipse Theia platform "allows developers to customize every aspect of the IDE without forking or patching the code... fully tailored for the needs of internal company projects or for commercial resale as a branded product."

Read more of this story at Slashdot.

The search for the busy beaver is ultimately a trophy hunt. The specific value of BB(5) doesn't have applications in other areas of computer science. But for busy beaver hunters, the hard-fought victory over mathematical impossibility is its own reward. It may be the last battle they'll ever win. from With Fifth Busy Beaver, Researchers Approach Computation's Limits [Quanta; ungated]

USENIX, the long-running OS/networking research group, also publishes a magazine called ;login:. Today the magazine's editor — security consultant Rik Farrow — stopped by Slashdot to share some new research. rikfarrow writes: Caching means using faster memory to store frequently requested data, and the most commonly used algorithm for determining which items to discard when the cache is full is Least Recently Used [or "LRU"]. These researchers have come up with a more efficient and scalable method that uses just a few lines of code to convert LRU to SIEVE. Just like a sieve, it sifts through objects (using a pointer called a "hand") to "filter out unpopular objects and retain the popular ones," with popularity based on a single bit that tracks whether a cached object has been visited: As the "hand" moves from the tail (the oldest object) to the head (the newest object), objects that have not been visited are evicted... During the subsequent rounds of sifting, if objects that survived previous rounds remain popular, they will stay in the cache. In such a case, since most old objects are not evicted, the eviction hand quickly moves past the old popular objects to the queue positions close to the head. This allows newly inserted objects to be quickly assessed and evicted, putting greater eviction pressure on unpopular items (such as "one-hit wonders") than LRU-based eviction algorithms. It's an example of "lazy promotion and quick demotion". Popular objects get retained with minimal effort, with quick demotion "critical because most objects are not reused before eviction." After 1559 traces (of 247,017 million requests to 14,852 million objects), they found SIEVE reduces the miss ratio (when needed data isn't in the cache) by more than 42% on 10% of the traces with a mean of 21%, when compared to FIFO. (And it was also faster and more scalable than LRU.) "SIEVE not only achieves better efficiency, higher throughput, and better scalability, but it is also very simple."

Read more of this story at Slashdot.

In collaboration with the Federal Bureau of Investigation (FBI), Australian Signals Directorate’s Australian Cyber Security Centre (ACSC), and Canadian Cyber Security Center (CCCS), the Cybersecurity and Infrastructure Security Agency (CISA) have released comprehensive guidance aimed at tackling memory safety vulnerabilities within critical open source software (OSS) projects. This initiative highlights the importance of mitigating risks associated with memory safety, as outlined in "The Case for Memory Safe Roadmaps".

Understanding Memory Safety Vulnerabilities with The Case for Memory Safe Roadmaps

Memory safety vulnerabilities pose threats to software integrity and security, leading to costly consequences such as frequent patching and incident responses. Recognizing these challenges, CISA advocates for the adoption of memory-safe roadmaps by software manufacturers. These roadmaps are designed to address memory safety concerns, particularly in external dependencies, which often include OSS components. The joint report by CISA, FBI, ACSC, and CCCS analyzed 172 critical OSS projects to assess their vulnerability to memory safety risks. The findings reveal that a substantial proportion of these projects are written in memory-unsafe languages, with 52% of projects containing such code. Even more strikingly, memory-unsafe languages account for 55% of the total lines of code across all projects studied. The report highlights that many of the largest OSS projects, critical to global digital infrastructure, rely heavily on memory-unsafe languages. For instance, among the ten largest projects analyzed, the median proportion of memory-unsafe code is 62.5%, highligheting the pervasive nature of this issue even in prominent software initiatives.

Implications and Industry Response

Despite efforts to promote memory-safe programming languages like Rust, the analysis found that projects purportedly written in memory-safe languages often incorporate dependencies that are still coded in memory-unsafe languages. This interdependence highlights the complexity of achieving comprehensive memory safety across complex software ecosystems. In response to these findings, CISA is urging organizations and software manufacturers to take several proactive steps. One key recommendation is to prioritize efforts aimed at mitigating memory safety vulnerabilities in open-source software (OSS). By addressing these vulnerabilities, organizations can bolster the overall security posture of their software environments. Additionally, CISA emphasizes the importance of informed decision-making when it comes to software dependencies. Organizations are encouraged to carefully evaluate and select software based on considerations of memory safety. This strategic approach can help mitigate risks associated with potential vulnerabilities in OSS. Furthermore, CISA calls for collaboration with the OSS community to advance the adoption of memory-safe practices and languages. By working together, industry stakeholders can contribute to the development and implementation of more secure software solutions.

3 min read Security teams can enhance business operations by providing workload credential management as a service, freeing developers to focus on innovation.

The post Why Devs Aren’t Responsible for Non-Human Credential Hygiene appeared first on Aembit.

The post Why Devs Aren’t Responsible for Non-Human Credential Hygiene appeared first on Security Boulevard.