Shell Hole: How Advanced Prompts are Putting Software Developers at Risk

Shell Hole: How Advanced Prompts are Putting Software Developers at Risk

Mikaël Barbero

Advanced shell prompts, such as those provided by theme engines like oh-my-zsh and oh-my-posh, have become increasingly popular among software developers due to their convenience, versatility, and customizability. However, the use of plugins that are executed outside of any sandbox and have full access to the developer shell environment, presents significant security risks, especially for Open Source Software developers.

Open Source Software Supply Chain Security starts with developers

Mikaël Barbero

Open Source Software Supply Chain is at risk: threat actors are shifting target to amplify the blast radius of their attacks and as such increasing their return on investment. Over the past 3 years, we’ve witnessed an astonishing 742% average annual increase in Software Supply Chain attacks. To make it worse, the attack surface of the supply chain is wide. Covering it all requires a deep scrutinity of many factors. However, there is a simple thing, easy, and free, that every open source developer should do right now: activate multi factor authentication (also known as two factor authentication) on all development related accounts.

Enforcing HTTPS on the Eclipse Marketplace

Enforcing HTTPS on the Eclipse Marketplace

Mikaël Barbero

As stewards of the Eclipse Marketplace, the Eclispe Foundation is responsible for providing a safe place for the Eclipse IDE users to download their plugins. While the Eclipse Marketplace does not host or transmit the plugins bits, it provides links to (p2) repositories containing them. Until today, there was no restriction on those links.

Beginning December 15, 2022, the Eclipse Marketplace will no longer support links to repositories over plain HTTP. The goal is to protect users of the Eclipse Marketplace from the main risk of plain HTTP links: man-in-the-middle (MITM) attacks.

Chromium / Eclipse SWT integration

Mikaël Barbero
Key takeaways: Do you want to see a Chromium based SWT Browser implementation? Please donate (or reach out to me if you want to do corporate donations) and the Eclipse Foundation will make it happens via the Friends of Eclipse Enhancement Program (FEEP). Browser support in SWT has always been a complicated story. By default (meaning without any hint from the application developers and the users), SWT relies on “native” renderers (Internet Explorer on Windows, WebKit on macOS and WebKitGTK+ or Mozilla/XULRunner on Linux).