More than 400 malicious packages were recently uploaded to PyPI (Python Package Index), the official code repository for the Python programming language, in the latest indication that the targeting of software developers using this form of attack isn't a passing fad. From a report: All 451 packages found recently by security firm Phylum contained almost identical malicious payloads and were uploaded in bursts that came in quick succession. Once installed, the packages create a malicious JavaScript extension that loads each time a browser is opened on the infected device, a trick that gives the malware persistence over reboots. The JavaScript monitors the infected developer's clipboard for any cryptocurrency addresses that may be copied to it. When an address is found, the malware replaces it with an address belonging to the attacker. The objective: intercept payments the developer intended to make to a different party.

An anonymous reader quotes a report from MIT Technology Review: Many software projects emerge because -- somewhere out there -- a programmer had a personal problem to solve. That's more or less what happened to Graydon Hoare. In 2006, Hoare was a 29-year-old computer programmer working for Mozilla, the open-source browser company. Returning home to his apartment in Vancouver, he found that the elevator was out of order; its software had crashed. This wasn't the first time it had happened, either. Hoare lived on the 21st floor, and as he climbed the stairs, he got annoyed. "It's ridiculous," he thought, "that we computer people couldn't even make an elevator that works without crashing!" Many such crashes, Hoare knew, are due to problems with how a program uses memory. The software inside devices like elevators is often written in languages like C++ or C, which are famous for allowing programmers to write code that runs very quickly and is quite compact. The problem is those languages also make it easy to accidentally introduce memory bugs -- errors that will cause a crash. Microsoft estimates that 70% of the vulnerabilities in its code are due to memory errors from code written in these languages.

Most of us, if we found ourselves trudging up 21 flights of stairs, would just get pissed off and leave it there. But Hoare decided to do something about it. He opened his laptop and began designing a new computer language, one that he hoped would make it possible to write small, fast code without memory bugs. He named it Rust, after a group of remarkably hardy fungi that are, he says, "over-engineered for survival." Seventeen years later, Rust has become one of the hottest new languages on the planet -- maybe the hottest. There are 2.8 million coders writing in Rust, and companies from Microsoft to Amazon regard it as key to their future. The chat platform Discord used Rust to speed up its system, Dropbox uses it to sync files to your computer, and Cloudflare uses it to process more than 20% of all internet traffic.

When the coder discussion board Stack Overflow conducts its annual poll of developers around the world, Rust has been rated the most "loved" programming language for seven years running. Even the US government is avidly promoting software in Rust as a way to make its processes more secure. The language has become, like many successful open-source projects, a barn-raising: there are now hundreds of die-hard contributors, many of them volunteers. Hoare himself stepped aside from the project in 2013, happy to turn it over to those other engineers, including a core team at Mozilla. It isn't unusual for someone to make a new computer language. Plenty of coders create little ones as side projects all the time. But it's meteor-strike rare for one to take hold and become part of the pantheon of well-known languages alongside, say, JavaScript or Python or Java. How did Rust do it?

Last week Microsoft announced 10,000 layoffs — and a multibillion-dollar investment in OpenAI, the company that created ChatGPT.

But OpenAI also released a tool called Codex in August of 2021 "designed to translate natural language into code," reports Semafor. And now OpenAI "has ramped up its hiring around the world, bringing on roughly 1,000 remote contractors over the past six months in regions like Latin America and Eastern Europe, according to people familiar with the matter."

The article points out that roughly 40% of those contractors "are computer programmers who are creating data for OpenAI's models to learn software engineering tasks." "A well-established company, which is determined to provide world-class AI technology to make the world a better and more efficient place, is looking for a Python Developer," reads one OpenAI job listing in Spanish, which was posted by an outsourcing agency....

OpenAI appears to be building a dataset that includes not just lines of code, but also the human explanations behind them written in natural language. A software developer in South America who completed a five-hour unpaid coding test for OpenAI told Semafor he was asked to tackle a series of two-part assignments. First, he was given a coding problem and asked to explain in written English how he would approach it. Then, the developer was asked to provide a solution. If he found a bug, OpenAI told him to detail what the problem was and how it should be corrected, instead of simply fixing it.

"They most likely want to feed this model with a very specific kind of training data, where the human provides a step-by-step layout of their thought-process," said the developer, who asked to remain anonymous to avoid jeopardizing future work opportunities.

An anonymous reader quotes a report from 9to5Linux: Ubuntu maker Canonical announced Thursday the general availability of its Ubuntu Pro comprehensive subscription for Ubuntu users who want to expand the security updates and compliance of their systems.

First released in a beta version in October 2022 with free subscriptions for personal and small-scale commercial use on up to 5 machines, Ubuntu Pro is only available for Ubuntu LTS (Long-Term Support) releases, starting with Ubuntu 16.04, and promises up to 10 years of security updates, as well as access to exclusive tools. These include Ansible, Apache Tomcat, Apache Zookeeper, Docker, Drupal, Nagios, Node.js, phpMyAdmin, Puppet, PowerDNS, Python 2, Redis, Rust, WordPress, ROS, and many others.

The Ubuntu Pro subscription promises patches for critical CVEs in less than 24 hours and expands the optional technical support to an additional 23,000 open-source packages and toolchains beyond the main operating system, not just for Ubuntu's main software repository....

Canonical says that if you need Ubuntu Pro for more than five PCs, you will have to purchase a paid plan, which is currently priced at $25 USD per year for workstations or $500 USD per year for servers with a 30-day free trial. Official Ubuntu Community members get free support for up to 50 machines.

74.48% of developers use Microsoft's Visual Studio Code, according to one survey conducted by StackOverflow. And besides GitHub Copilot, there's over 40,000 other extensions in the VSCode Marketplace.

Unfortunately, InfoWorld reports, "Researchers at Aqua Nautilus say they have found that attackers could easily impersonate popular extensions and trick unknowing developers into downloading them." It can be challenging to distinguish between malicious and benign extensions, and the lack of sandbox capabilities means that extensions could install ransomware, wipers, and other malicious code, Aqua security researcher Ilay Goldman wrote in a January 6 blog post. ["In fact, it can access and even alter all the code that you have locally and even use your SSH key to change the code in all your organization's repositories."] VS Code extensions, which provide capabilities ranging from Python language support to JSON file editing, can be downloaded from Microsoft's Visual Studio Code Marketplace.

Aqua Nautilus uploaded an extension masquerading as the Prettier code formatter and saw more than 1,000 installs in less than 48 hours, from around the world. The spoof extension has been removed.

Goldman noted that the Visual Studio Code Marketplace runs a virus scan for each new extension and subsequent updates, and removes malicious extensions when it finds them. Users can report suspicious-looking extensions via a Report Abuse link.
"While the media is full of stories about malicious packages that have been uploaded to popular package managers such as NPM and PyPI, there is very little information about malicious VSCode extension," the blog post notes. Yet it points out that a blue checkmark on a VSCode extension "merely means that whoever the publisher is has proven the ownership of a domain. That means any domain."

And even Microsoft acknowledged to InfoWorld that social engineering techniques have been used to persuade victims to download malicious extensions — though they point out that Microsoft confirms that each extension has a Marketplace certificate and verifiable signature before being installed. "To help make informed decisions, we recommend consumers review information, such as domain verification, ratings and feedback to prevent unwanted downloads."

InfoWorld reports: JavaScript, Java, and Python skills are most in-demand by recruiters, according to a report published this week by tech hiring platforms CodinGame and CoderPad. But while the supply of those skills exceeds demand, the demand for TypeScript, Swift, Scala, Kotlin, and Go skills all exceed supply.

The State of Tech Hiring in 2023, a CodinGame-CoderPad report published January 10, draws on a survey of 14,000 professionals and offers insights into what 2023 may hold for tech industry recruiters and job seekers. The demand for JavaScript, Java, and Python skills is consistent with previous years, the report notes.

Among development frameworks, Node.js, React, and .NET Core proved to be the best-known and most in-demand.
InfoWorld summarizes some other interesting findings:

• "59% of developers do not have a university degree in computer science. Nearly one-third consider themselves primarily self-taught."

• "Developers' main challenges at work include unplanned changes to their schedule, unclear direction, and a lack of technical knowledge by team members."

• "Most teams are now hybrid between remote and on-site work. Only 15% work onsite 100% of the time."

"The Tiobe index gauges language popularity using a formula that assesses searches on programming languages in Google, Bing, Yahoo, Wikipedia, and other search engines," writes InfoWorld. And they add that this year the "vaunted" C++ programming language was the index's biggest gainer in 2022.

TIOBE's announcement includes their calculation that C++ rose 4.62% in popularity in 2022: Runners up are C (+3.82%) and Python (+2.78%). Interestingly, C++ surpassed Java to become the number 3 of the TIOBE index in November 2022. The reason for C++'s popularity is its excellent performance while being a high level object-oriented language. Because of this, it is possible to develop fast and vast software systems (over millions of lines of code) in C++ without necessarily ending up in a maintenance nightmare.
So which programming languages are most popular now? For what it's worth, here's TIOBE's latest ranking:


- Python
- C
- C++
- Java
- C#
- Visual Basic
- JavaScript
- SQL
- Assembly Language
- PHP


InfoWorld adds that "Helping C++ popularity was the publication of new language standards with interesting features, such as C++ 11 and C++ 20."

More from TIOBE: What else happened in 2022? Performance seemed to be important. C++ competitor Rust entered the top 20 again (being at position #26 one year ago), but this time it seems to be for real. Lua, which is known for its easy interfacing with C, jumped from position #30 to #24. F# is another language that made an interesting move: from position #74 to position #33 in one years' time. Promising languages such as Kotlin (from #29 to #25), Julia (from #28 to #29) and Dart (from #37 to #38) still have a long way to go before they reach the top 20. Let's see what happens in 2023.

An anonymous reader quotes a report from TechCrunch: A recent study finds that software engineers who use code-generating AI systems are more likely to cause security vulnerabilities in the apps they develop. The paper, co-authored by a team of researchers affiliated with Stanford, highlights the potential pitfalls of code-generating systems as vendors like GitHub start marketing them in earnest. The Stanford study looked specifically at Codex, the AI code-generating system developed by San Francisco-based research lab OpenAI. (Codex powers Copilot.) The researchers recruited 47 developers -- ranging from undergraduate students to industry professionals with decades of programming experience -- to use Codex to complete security-related problems across programming languages including Python, JavaScript and C.

Codex was trained on billions of lines of public code to suggest additional lines of code and functions given the context of existing code. The system surfaces a programming approach or solution in response to a description of what a developer wants to accomplish (e.g. "Say hello world"), drawing on both its knowledge base and the current context. According to the researchers, the study participants who had access to Codex were more likely to write incorrect and "insecure" (in the cybersecurity sense) solutions to programming problems compared to a control group. Even more concerningly, they were more likely to say that their insecure answers were secure compared to the people in the control.

Megha Srivastava, a postgraduate student at Stanford and the second co-author on the study, stressed that the findings aren't a complete condemnation of Codex and other code-generating systems. The study participants didn't have security expertise that might've enabled them to better spot code vulnerabilities, for one. That aside, Srivastava believes that code-generating systems are reliably helpful for tasks that aren't high risk, like exploratory research code, and could with fine-tuning improve in their coding suggestions. "Companies that develop their own [systems], perhaps further trained on their in-house source code, may be better off as the model may be encouraged to generate outputs more in-line with their coding and security practices," Srivastava said. The co-authors suggest vendors use a mechanism to "refine" users' prompts to be more secure -- "akin to a supervisor looking over and revising rough drafts of code," reports TechCrunch. "They also suggest that developers of cryptography libraries ensure their default settings are secure, as code-generating systems tend to stick to default values that aren't always free of exploits."

An anonymous reader quotes a report from Hackaday: Stabilizing an inverted pendulum is a classic problem in control theory, and if you've ever taken a control systems class you might remember seeing pages full of differential equations and bode diagrams just to describe its basic operation. Although this might make such a system seem terribly complicated, actually implementing all of that theory doesn't have to be difficult at all, as [Limenitis Reducta] demonstrates in his latest project. All you need is a 3D printer, some basic electronic skills and knowledge of Python. The components needed are a body, two wheels, motors to drive those wheels and some electronics. [Limenitis] demonstrates the design process in the video [here] (in Turkish, with English subtitles available) in which he draws the entire system in Fusion 360 and then proceeds to manufacture it. The body and wheels are 3D-printed, with rubber bands providing some traction to the wheels which would otherwise have difficulty on slippery surfaces.

Two stepper motors drive the wheels, controlled by a DRV8825 motor driver, while an MPU-9250 accelerometer and gyroscope unit measures the angle and acceleration of the system. The loop is closed by a Raspberry Pi Pico that implements a PID controller: another control theory classic, in which the proportional, integral and derivative parameters are tuned to adapt the control loop to the physical system in question. External inputs can be provided through a Bluetooth connection, which makes it possible to control the robot from a PC or smartphone and guide it around your living room. All design files and software are available on Limenitis' GitHub page.

Computer scientists from Stanford University have found that programmers who accept help from AI tools like Github Copilot produce less secure code than those who fly solo. From a report: In a paper titled, "Do Users Write More Insecure Code with AI Assistants?", Stanford boffins Neil Perry, Megha Srivastava, Deepak Kumar, and Dan Boneh answer that question in the affirmative. Worse still, they found that AI help tends to delude developers about the quality of their output. "We found that participants with access to an AI assistant often produced more security vulnerabilities than those without access, with particularly significant results for string encryption and SQL injection," the authors state in their paper.

"Surprisingly, we also found that participants provided access to an AI assistant were more likely to believe that they wrote secure code than those without access to the AI assistant." Previously, NYU researchers have shown that AI-based programming suggestions are often insecure in experiments under different conditions. The Stanford authors point to an August 2021 research paper titled "Asleep at the Keyboard? Assessing the Security of GitHub Copilot's Code Contributions," which found that given 89 scenarios, about 40 per cent of the computer programs made with the help of Copilot had potentially exploitable vulnerabilities.

That study, the Stanford authors say, is limited in scope because it only considers a constrained set of prompts corresponding to 25 vulnerabilities and just three programming languages: Python, C, and Verilog. The Stanford scholars also cite a followup study from some of the same NYU eggheads, "Security Implications of Large Language Model Code Assistants: A User Study," as the only comparable user study they're aware of. They observe, however, that their work differs because it focuses on OpenAI's codex-davinci-002 model rather than OpenAI's less powerful codex-cushman-001 model, both of which play a role in GitHub Copilot, itself a fine-tuned descendant of a GPT-3 language model.

For three years Stockholm-based games studio Embark has been working on the Rust-gpu project to make Rust "a first class language and ecosystem for GPU programming." The project's latest announcement? rust-gpu now supports ray-tracing.

Their original announcement explained the rationale for this years-long dvelopment effort: Historically in games GPU programming has been done through writing either HLSL, or to a lesser extent GLSL. These are simple programming languages that have evolved along with rendering APIs over the years. However, as game engines have evolved, these languages have failed to provide mechanisms for dealing with large codebases, and have generally stayed behind the curve compared to other programming languages.

In part this is because it's a niche language for a niche market, and in part this has been because the industry as a whole has sunk quite a lot of time and effort into the status quo. While over-all better alternatives to both languages exist, none of them are in a place to replace HLSL or GLSL. Either because they are vendor locked, or because they don't support the traditional graphics pipeline. Examples of this include CUDA and OpenCL. And while attempts have been made to create language in this space, none of them have gained any notable traction in the gamedev community.

Our hope with this project is that we push the industry forward by bringing an existing, low-level, safe, and high performance language to the GPU; namely Rust. And with it come some additional benefits that can't be overlooked: a package/module system that's one of the industry's best, built in safety against race-conditions or out of bounds memory access, a wide range of tools and utilities to improve programmer workflows, and many others!
Along with ray-tracing, this week they announced plans to keep rust-gpu on the same schedule as the stable Rust release, "so you can use your favorite new language features as new stable versions of Rust are being released, by just updating your rust-gpu version."

Thanks to Slashdot reader guest reader for sharing the news!

Walking like John Cleese's character, Mr. Teabag, in Monty Python's famous "Ministry of Silly Walks" skit requires considerably more energy expenditure than a normal walking gait because the movement is so inefficient, according to a new paper published in the annual Christmas issue of the British Medical Journal. From a report: In fact, just 11 minutes a day of walking like Mr. Teabag was equivalent to 75 minutes of vigorously intense physical activity per week, presenting a novel means of boosting cardiovascular fitness. "Half a century ago, the [Ministry of Silly Walks] skit might have unwittingly touched on a powerful way to enhance cardiovascular fitness in adults," the authors wrote. "Had an initiative to promote inefficient movement been adopted in the early 1970s, we might now be living among a healthier society."

The BMJ's Christmas issue is typically more lighthearted, though the journal maintains that the papers published therein still "adhere to the same high standards of novelty, methodological rigor, reporting transparency, and readability as apply in the regular issue." Past years have included papers on such topics as why 27 is not a dangerous age for musicians, the side effects of sword swallowing, and measuring the toxicity of the concoction brewed in Roald Dahl's 1981 book George's Marvelous Medicine. (It's very toxic indeed.) The most widely read was 1999's infamous "Magnetic resonance imaging of male and female genitals during coitus and female sexual arousal."

An anonymous reader quotes a report from KrebsOnSecurity: On Dec. 10, 2022, the relatively new cybercrime forum Breached featured a bombshell new sales thread: The user database for InfraGard, including names and contact information for tens of thousands of InfraGard members. The FBI's InfraGard program is supposed to be a vetted Who's Who of key people in private sector roles involving both cyber and physical security at companies that manage most of the nation's critical infrastructures -- including drinking water and power utilities, communications and financial services firms, transportation and manufacturing companies, healthcare providers, and nuclear energy firms. "InfraGard connects critical infrastructure owners, operators, and stakeholders with the FBI to provide education, networking, and information-sharing on security threats and risks," the FBI's InfraGard fact sheet reads.

KrebsOnSecurity contacted the seller of the InfraGard database, a Breached forum member who uses the handle "USDoD" and whose avatar is the seal of the U.S. Department of Defense. USDoD said they gained access to the FBI's InfraGard system by applying for a new account using the name, Social Security Number, date of birth and other personal details of a chief executive officer at a company that was highly likely to be granted InfraGard membership. The CEO in question -- currently the head of a major U.S. financial corporation that has a direct impact on the creditworthiness of most Americans -- did not respond to requests for comment. USDoD told KrebsOnSecurity their phony application was submitted in November in the CEO's name, and that the application included a contact email address that they controlled -- but also the CEO's real mobile phone number. "When you register they said that to be approved can take at least three months," USDoD said. "I wasn't expected to be approve[d]." But USDoD said that in early December, their email address in the name of the CEO received a reply saying the application had been approved. While the FBI's InfraGard system requires multi-factor authentication by default, users can choose between receiving a one-time code via SMS or email. "If it was only the phone I will be in [a] bad situation," USDoD said. "Because I used the person['s] phone that I'm impersonating."

USDoD said the InfraGard user data was made easily available via an Application Programming Interface (API) that is built into several key components of the website that help InfraGard members connect and communicate with each other. USDoD said after their InfraGard membership was approved, they asked a friend to code a script in Python to query that API and retrieve all available InfraGard user data. "InfraGard is a social media intelligence hub for high profile persons," USDoD said. "They even got [a] forum to discuss things." USDoD acknowledged that their $50,000 asking price for the InfraGard database may be a tad high, given that it is a fairly basic list of people who are already very security-conscious. Also, only about half of the user accounts contain an email address, and most of the other database fields -- like Social Security Number and Date of Birth -- are completely empty. [...] While the data exposed by the infiltration at InfraGard may be minimal, the user data might not have been the true end game for the intruders. USDoD said they were hoping the imposter account would last long enough for them to finish sending direct messages as the CEO to other executives using the InfraGuard messaging portal.

"Java is no longer among the top three most popular programming languages in the TIOBE Index," reports the Register, "one of several not particularly definitive yardsticks by which such things are measured." According to Paul Jansen, CEO of Netherlands-based TIOBE Software, the rising popularity of C++ has pushed Java down a notch. The index's rankings are now:

- Python in first place
- C second
- C++ third, and
- Java fourth.

C++ stepped up to third, and Java fell to fourth. "C++ surpassed Java for the first time in the history of the TIOBE Index, which means that Java is at position 4 now," said Jansen in the December update for the TIOBE Index. "This is the first time that Java is not part of the top 3 since the beginning of the TIOBE Index in 2001."

The surge in C++, perhaps in part helped by the stable release of C++ 20 in December 2020, is particularly ironic in light of the language's recent dismissal by Microsoft CTO Mark Russinovich, which coincides with industry evangelism for Rust and its capacity for memory safety.
The article points out that other rankings still show a slighty higher popularity for Java. And ZDNet notes the other languages rising quickly in popularity over the last 12 months: In a year-on-year comparison in Tiobe's index, the languages now in the top 20 that made significant gains over the period are: Rust (up from 27 to 20), Objective-C (up from 29 to 19), science-specialized MATLAB (20 to 14), and Google's Go language (up from 19 to 12).

DeepMind's new artificial intelligence system called AlphaCode was able to "achieve approximately human-level performance" in a programming competition. The findings have been published in the journal Science. Slashdot reader sciencehabit shares a report from Science Magazine: AlphaCode's creators focused on solving those difficult problems. Like the Codex researchers, they started by feeding a large language model many gigabytes of code from GitHub, just to familiarize it with coding syntax and conventions. Then, they trained it to translate problem descriptions into code, using thousands of problems collected from programming competitions. For example, a problem might ask for a program to determine the number of binary strings (sequences of zeroes and ones) of length n that don't have any consecutive zeroes. When presented with a fresh problem, AlphaCode generates candidate code solutions (in Python or C++) and filters out the bad ones. But whereas researchers had previously used models like Codex to generate tens or hundreds of candidates, DeepMind had AlphaCode generate up to more than 1 million.

To filter them, AlphaCode first keeps only the 1% of programs that pass test cases that accompany problems. To further narrow the field, it clusters the keepers based on the similarity of their outputs to made-up inputs. Then, it submits programs from each cluster, one by one, starting with the largest cluster, until it alights on a successful one or reaches 10 submissions (about the maximum that humans submit in the competitions). Submitting from different clusters allows it to test a wide range of programming tactics. That's the most innovative step in AlphaCode's process, says Kevin Ellis, a computer scientist at Cornell University who works AI coding.

After training, AlphaCode solved about 34% of assigned problems, DeepMind reports this week in Science. (On similar benchmarks, Codex achieved single-digit-percentage success.) To further test its prowess, DeepMind entered AlphaCode into online coding competitions. In contests with at least 5000 participants, the system outperformed 45.7% of programmers. The researchers also compared its programs with those in its training database and found it did not duplicate large sections of code or logic. It generated something new -- a creativity that surprised Ellis. The study notes the long-term risk of software that recursively improves itself. Some experts say such self-improvement could lead to a superintelligent AI that takes over the world. Although that scenario may seem remote, researchers still want the field of AI coding to institute guardrails, built-in checks and balances.

"Rust is awesome, for certain things. But think twice before picking it up for a startup that needs to move fast," Matt Welsh, co-founder and chief executive of Fixie.ai and former Google engineering director, writes in a blog post. From the post: I hesitated writing this post, because I don't want to start, or get into, a holy war over programming languages. (Just to get the flame bait out of the way, Visual Basic is the best language ever!) But I've had a number of people ask me about my experience with Rust and whether they should pick up Rust for their projects. So, I'd like to share some of the pros and cons that I see of using Rust in a startup setting, where moving fast and scaling teams is really important. Right up front, I should say that Rust is very good at what it's designed to do, and if your project needs the specific benefits of Rust (a systems language with high performance, super strong typing, no need for garbage collection, etc.) then Rust is a great choice. But I think that Rust is often used in situations where it's not a great fit, and teams pay the price of Rust's complexity and overhead without getting much benefit.

My primary experience from Rust comes from working with it for a little more than 2 years at a previous startup. This project was a cloud-based SaaS product that is, more-or-less, a conventional CRUD app: it is a set of microservices that provide a REST and gRPC API endpoint in front of a database, as well as some other back-end microservices (themselves implemented in a combination of Rust and Python). Rust was used primarily because a couple of the founders of the company were Rust experts. Over time, we grew the team considerably (increasing the engineering headcount by nearly 10x), and the size and complexity of the codebase grew considerably as well. As the team and codebase grew, I felt that, over time, we were paying an increasingly heavy tax for continuing to use Rust. Development was sometimes sluggish, launching new features took longer than I would have expected, and the team was feeling a real productivity hit from that early decision to use Rust. Rewriting the code in another language would have, in the long run, made development much more nimble and sped up delivery time, but finding the time for the major rewrite work would have been exceedingly difficult.

So we were kind of stuck with Rust unless we decided to bite the bullet and rewrite a large amount of the code. Rust is supposed to be the best thing since sliced bread, so why was it not working so well for us? [...] Despite being some of the smartest and most experienced developers I had worked with, many people on the team (myself included) struggled to understand the canonical ways to do certain things in Rust, how to grok the often arcane error messages from the compiler, or how to understand how key libraries worked (more on this below). We started having weekly "learn Rust" sessions for the team to help share knowledge and expertise. This was all a significant drain on the team's productivity and morale as everyone felt the slow rate of development. As a comparison point of what it looks like to adopt a new language on a software team, one of my teams at Google was one of the first to switch entirely from C++ to Go, and it took no more than about two weeks before the entire 15-odd-person team was quite comfortably coding in Go for the first time.

Vulnerabilities in mobile apps exposed Hyundai and Genesis car models after 2012 to remote attacks that allowed unlocking and even starting the vehicles. BleepingComputer reports: Security researchers at Yuga Labs found the issues and explored similar attack surfaces in the SiriusXM "smart vehicle" platform used in cars from other makers (Toyota, Honda, FCA, Nissan, Acura, and Infinity) that allowed them to "remotely unlock, start, locate, flash, and honk" them. At this time, the researchers have not published detailed technical write-ups for their findings but shared some information on Twitter, in two separate threads.

The mobile apps of Hyundai and Genesis, named MyHyundai and MyGenesis, allow authenticated users to start, stop, lock, and unlock their vehicles. After intercepting the traffic generated from the two apps, the researchers analyzed it and were able to extract API calls for further investigation. They found that validation of the owner is done based on the user's email address, which was included in the JSON body of POST requests. Next, the analysts discovered that MyHyundai did not require email confirmation upon registration. They created a new account using the target's email address with an additional control character at the end. Finally, they sent an HTTP request to Hyundai's endpoint containing the spoofed address in the JSON token and the victim's address in the JSON body, bypassing the validity check. To verify that they could use this access for an attack on the car, they tried to unlock a Hyundai car used for the research. A few seconds later, the car unlocked. The multi-step attack was eventually baked into a custom Python script, which only needed the target's email address for the attack.

Yuga Labs analysts found that the mobile apps for Acura, BMW, Honda, Hyundai, Infiniti, Jaguar, Land Rover, Lexus, Nissan, Subaru, and Toyota, use SiriusXM technology to implement remote vehicle management features. They inspected the network traffic from Nissan's app and found that it was possible to send forged HTTP requests to the endpoint only by knowing the target's vehicle identification number (VIN). The response to the unauthorized request contained the target's name, phone number, address, and vehicle details. Considering that VINs are easy to locate on parked cars, typically visible on a plate where the dashboard meets the windshield, an attacker could easily access it. These identification numbers are also available on specialized car selling websites, for potential buyers to check the vehicle's history. In addition to information disclosure, the requests can also carry commands to execute actions on the cars. [...] Before posting the details, Yuga Labs informed both Hyundai and SiriusXM of the flaws and associated risks. The two vendors have fixed the vulnerabilities.

Kite, a start-up that has been developing artificial intelligence technology to help developers write code for nearly a decade, is saying farewell and open-sourcing its code. Silicon Republic reports: Based in San Francisco, Kite was founded in 2014 as an early pioneer in the emerging field of AI that assists software developers in writing code -- an 'autocomplete' for programming of sorts. But now, after eight years of pursuing its vision to be a leader in AI-assisted programming, founder Adam Smith announced on the company website that the business is now wrapping up. According to him, even state-of-the-art machine learning models today don't understand the structure of code -- and too few developers are willing to pay for available services. "We failed to deliver our vision of AI-assisted programming because we were 10-plus years too early to market, ie, the tech is not ready yet," Smith explained. "You can see this in GitHub Copilot, which is built by GitHub in collaboration with OpenAI. As of late 2022, Copilot shows a lot of promise but still has a long way to go."

Copilot was first revealed in June 2021 as an AI assistant for programmers that essentially does for coding what predictive text does for writing emails. Developed in collaboration with OpenAI, GitHub had kept Copilot in technical preview until this summer, during which time it had been used by more than 1.2m developers. The AI was made available to all developers in June, at a cost of $10 a month or $100 a year. However, Smith said that the inadequacy of machine learning models in understanding the structure of code, such as non-local context, has been an insurmountable challenge for the Kite team. "We made some progress towards better models for code, but the problem is very engineering intensive. It may cost over $100m to build a production-quality tool capable of synthesizing code reliably, and nobody has tried that quite yet."

While the business could have still been successful without necessarily increasing developer productivity by 10 times using AI, Smith said he thinks that Kite's delay and unsuccessful attempt at monetizing the service prevented the start-up from taking flight. "We sequenced building our business in the following order: First we built our team, then the product, then distribution and then monetization," he explained, adding that Kite did not reach product-market fit until 2019, five years after starting the company. Despite the time taken to get to the market, Smith said Kite was able to capture 500,000 monthly active developers using its AI with "almost zero marketing spend." But the product failed to generate revenue because the developers refused to pay for it. Smith says most of their code has been open sourced on GitHub, including their "data-driven Python type inference engine, Python public-package analyzer, desktop software, editor integrations, GitHub crawler and analyzer, and more more."

Fedora 37 is now officially released. From a report: Fedora 37 brings the GNOME 43 desktop to Fedora Workstation 37, updated toolchain components like Glibc 2.36 and LLVM 15 and Binutils 2.38, official support for the Raspberry Pi 4, retiring 32-bit ARMv7 support, Fedora CoreOS has been promoted to a Fedora Edition, Perl 5.36, Python 3.11, RPM 4.18, LXQt 1.1, and a wealth of other updated packages.

While the popularity of jQuery is decreasing, React.JS "is currently the most widely used client-side framework," reports ZDNet, citing SlashData's 23rd State of the Developer Nation report (compiled from more than 26,000 developers last summer from 163 countries).

ZDNet believe it shows developers "experimenting less and sticking with what they know and what works." JavaScript remains the largest programming language community, SlashData found. According to its research, there are an estimated 19.6 million developers worldwide using JavaScript every day in everything from web development and mobile apps to backend coding, cloud and game design. Java, meanwhile, is growing rapidly. In the last two years, the size of the Java community has more than doubled from 8.3 million to 16.5 million, SlashData found. For perspective, the global developer population grew about half as fast over the same period....

Python also continued to grow strongly, adding about eight million new developers over the last two years, according to SlashData. It accredited the rise of data science and machine learning as "a clear factor in Python's growing popularity". Approximately 63% of machine-learning developers and data scientists report using Python, whereas less than 15% use R, another programming language often associated with data science.
Both the Kotlin and Rust communities doubled in size in the past two years, the article points out. But according to the survey, only 9% of developers were involved in blockchain technologies.

Yet 27% of respondents reported they were learning about (if not currently working on) cryptocurrency-based projects. ZDNet summarizes the findings: Of the three blockchain technologies covered in the report, non-fungible tokens (NFTs) were found to be of least interest to developers: 58% showed "no interest" in NFTs, which SlashData said was "likely due to its perception as a novelty".

The report found that one-quarter (25%) of developers currently work on, or are learning about, blockchain applications other than cryptocurrencies.