Long-time Slashdot reader ArchieBunker writes: Everyone's favorite security focused operating system OpenBSD released version 7.0 Thursday. In addition to the usual bug fixes and performance enhancements, support for RISC-V processors has been added.
It's 26 years old, and still chugging along. One interesting feature highlighted by Phoronix: Improving the ARM64 platform support with improved drivers for the Apple Silicon / Apple M1 but still not considered ready yet for end-users. OpenBSD 7.0 improvements on the Apple M1 include support for installing on a disk with a GPT and various Apple driver improvements for USB, GPIO, SPMI, NVMe storage, and other Apple M1 hardware components.
Also check out the 7.0 Song: "The Style Hymn" (part of an archive of all the OpenBSD release songs).

ArchieBunker writes: Everyone's favorite security-focused operating system, OpenBSD, released version 7.0 today. In addition to the usual bug fixes and performance enhancements, support for RISC-V processors has been added. The changelog and mirrors can be found at their respective links.

AMD warned last week that its chips are experiencing performance issues in Windows 11, and now Microsoft's first update to its new OS has reportedly made the problems worse. From a report: TechPowerUp reports that it's seeing much higher latency, which means worse performance, after the Windows 11 update went live yesterday. AMD and Microsoft found two issues with Windows 11 on Ryzen processors. Windows 11 can cause L3 cache latency to triple, slowing performance by up to 15 percent in certain games. The second issue affects AMD's preferred core technology, that shifts threads over to the fastest core on a processor. AMD says this second bug could impact performance on CPU-reliant tasks. TechPowerUp measured the L3 cache latency on its Ryzen 7 2700X at around 10ns, and Windows 11 increased this to 17ns. "This was made much worse with the October 12 'Patch Tuesday' update, driving up the latency to 31.9ns," says TechPowerUp. That's a huge jump, and the exact type of issue AMD warned about.

LibreOffice and OpenOffice have pushed updates to address a vulnerability that makes it possible for an attacker to manipulate documents to appear as signed by a trusted source. Although the severity of the flaw is classified as moderate, the implications could be dire. BleepingComputer reports: The discovery of the flaw, which is tracked as CVE-2021-41832 for OpenOffice, was the work of four researchers at the Ruhr University Bochum. The same flaw impacts LibreOffice, which is a fork of OpenOffice spawned from the main project over a decade ago, and for their project is tracked as CVE-2021-25635. If you're using either of the open-source office suites, you're advised to upgrade to the latest available version immediately. For OpenOffice, that would be 4.1.10 and later, and for LibreOffice, 7.0.5 or 7.1.1 and later. Since neither of these two applications offer auto-updating, you should do it manually by downloading the latest version from the respective download centers -- LibreOffice, OpenOffice. If you're using Linux and the aforementioned versions aren't available on your distribution's package manager yet, you are advised to download the "deb", or "rpm" package from the Download center or build LibreOffice from source. If updating to the latest version is not possible for any reason, you can always opt to completely disable the macro features on your office suite, or avoid trusting any documents containing macros.

The Apache Software Foundation has released a security patch to address a vulnerability in its HTTP Web Server project that has been actively exploited in the wild. From a report: Tracked as CVE-2021-41773, the vulnerability affects only Apache web servers running version 2.4.49 and occurs because of a bug in how the Apache server converts between different URL path schemes (a process called path or URI normalization). "An attacker could use a path traversal attack to map URLs to files outside the expected document root," the ASF team said in the Apache HTTP Server 2.4.50 changelog. "If files outside of the document root are not protected by 'require all denied' these requests can succeed. Additionally this flaw could leak the source of interpreted files like CGI scripts," Apache engineers added. More than 120,000 servers currently exposed online to attacks.

We thought the carnage was over for popular decentralized finance, or DeFi, staking protocol Compound, but as it turns out, millions more than we thought are at risk. About $162 million is up for grabs after an upgrade gone very wrong, according to Robert Leshner, founder of Compound Labs. CNBC reports: At first, the Compound chief tweeted Friday that there was a cap to how many comp tokens could be accidentally distributed, noting that âoethe impact is bounded, at worst, 280,000 comp tokens,â or about $92.6 million. But on Sunday morning, Leshner revealed that the pool of cash that had already been emptied once had been replenished â" exposing another 202,472.5 comp tokens to exploit, or roughly $66.9 million at its current price.

On Wednesday, Compound rolled out what should have been a pretty standard upgrade. Soon after implementation, however, it was clear that something had gone seriously wrong, once users started to receive millions of dollars in comp tokens. For example, $30 million worth of comp tokens were claimed in one transaction. The saving grace of the entire debacle, however, was the fact that the pool of cash that was open to exploit -- something called the Comptroller contract -- had a finite amount of tokens. The problem is that this leaky pool got a fresh influx of cash, and 0.5 comp tokens are being added roughly every 15 seconds, according to Gupta. "When the drip() function was called this morning, it sent the backlog (202,472.5, about two months of COMP since the last time the function was called) into the protocol for distribution to users," Leshner wrote in a tweet Sunday morning. Leshner noted that this brought the total comp at risk to 490,000 comp tokens, or about $162 million.

There are a few proposals to fix the bug, but Compound's governance model is such that any changes to the protocol require a multiday voting window, and Gupta said it takes another week for the successful proposal to be executed. In the meantime, this pool of cash is once again up for grabs for users who know how to exploit the bug. Compound made clear that no supplied or borrowed funds were at risk, which is some consolation. "No user funds are or were at risk so it's not that big of a deal," said Gupta. "Everyone kinda got diluted but didn't lose anything directly."

An anonymous reader quotes a report from Ars Technica: Telegram patched another image self-destruction bug in its app earlier this year. This flaw was a different issue from the one reported in 2019. But the researcher who reported the bug isn't pleased with Telegram's months-long turnaround time -- and an offered $1,159 bounty award in exchange for his silence. In February 2021, Telegram introduced a set of such auto-deletion features in its 2.6 release: Set messages to auto-delete for everyone 24 hours or 7 days after sending; Control auto-delete settings in any of your chats, as well as in groups and channels where you are an admin; and To enable auto-delete, right-click on the chat in the chat list > Clear History > Enable Auto-Delete. But in a few days, mononymous researcher Dmitrii discovered a concerning flaw in how the Telegram Android app had implemented self-destruction.

Messages that should be auto-deleted from participants in private and private group chats were only 'deleted' visually [in the messaging window], but in reality, picture messages remained on the device [in] the cache," the researcher wrote in a roughly translated blog post published last week. Tracked as CVE-2021-41861, the flaw is rather simple. In the Telegram Android app versions 7.5.0 to 7.8.0, self-destructed images remain on the device in the /Storage/Emulated/0/Telegram/Telegram Image directory after approximately two to four uses of the self-destruct feature. But the UI appears to indicate to the user that the media was properly destroyed.

But for a simple bug like this, it wasn't easy to get Telegram's attention, Dmitrii explained. The researcher contacted Telegram in early March. And after a series of emails and text correspondence between the researcher and Telegram spanning months, the company reached out to Dmitrii in September, finally confirming the existence of the bug and collaborating with the researcher during beta testing. For his efforts, Dmitrii was offered a $1,159 bug bounty reward. Since then, the researcher claims he has been ghosted by Telegram, which has given no response and no reward. "I have not received the promised reward from Telegram in [$1,159] or any other," he wrote.

Bleeping Computer has an update on the unique predicament of Compound, "an Ethereum-based money market protocol that enables users to earn interest or borrow assets against collateral." (Which "Due to an erroneous upgrade process, the decentralized finance platform ended up spilling out Ethereum assets worth $90 million to its users...") Compound's founder Robert Leshner urged users who received these Compound tokens in error to return the assets to the platform's Timelock contract. To incentivize users, Leshner stated that for their "white-hat" behaviour they may keep 10% as a reward. "Otherwise, it's being reported as income to the IRS, and most of you are doxxed," threatened the founder in the same tweet... Realizing that the original wording of his tweet may not have sat well with many, Leshner revised his tone:

"I'm trying to do anything I can to help the community get some of its COMP back, and this was a bone-headed tweet / approach. That's on me," said Leshner. "Luckily, the community is much bigger, and smarter, than just me. I appreciate your ridicule and support...."

Because the Compound protocol requires a seven-day governance process before any production changes can be made, Compound's only option at this time is to wait on users, hoping they will return the assets.
CoinDesk reported Friday afternoon that "So far, two users have returned a total of 37,493 COMP tokens worth over $12 million at the time of writing." But on Saturday Leshner was tweeting out more thank-you's to additional white-hat users "returning COMP to the community." In an interview with CoinDesk, Leshner said the moral dilemma can be split roughly into two camps. "There's a lot of members of the community that view protocols like Compound as benefitting the entire ecosystem," he said. "And there are some users that don't necessarily care. The builder mindset is, 'This adds value, this is crucially important,' and the trader mindset is 'Money is money,' and that's the only ethos of crypto."

He went on: "I'm personally hopeful users will return funds to the community. It's not my property, it's not their property, it's the community's property...."
One suggestion from Twitter? "The first 5 people to return COMP get 1/5 pieces of Leshner NFT that can be combined Exodia style to summon Robert in real life." "This idea is crazy, and I'm in," Leshner tweeted, adding later that "Anyone who returns COMP to the community is an alien giga-chad; and if a squad of alien giga-chads ever summon me, I will appear."

Leshner told CoinDesk: "I want to hear other people's views on this, because it's not my decision," he said. "This is a decision every user has to make themselves, and I think most of them are taking the view of, 'Haha, f**k you guys, it's your problem.'"

An anonymous reader quotes a report from The Record: More than 6,000 Coinbase users had funds stolen from their accounts after hackers used a vulnerability in Coinbase's SMS-based two-factor authentication system to breach accounts. The intrusions took place earlier this year, between March and May, the exchange said in a data breach notification letter it has filed with US state attorney general offices. Coinbase said the attacks could exploit this bug only if they knew the victim's username and password. "While we are not able to determine conclusively how these third parties gained access to this information, this type of campaign typically involves phishing attacks or other social engineering techniques to trick a victim into unknowingly disclosing login credentials to a bad actor. "We have not found any evidence that these third parties obtained this information from Coinbase itself," the company said. Coinbase said it would reimburse all users who lost funds in these intrusions.

phalse phace writes: Robert Leshner, the founder of Compound Labs, just sent out a tweet pleading its users to return the $90.1 million in COMP tokens it accidentally deposited to user accounts.

Users of the popular DeFi staking protocol received the platform's crypto tokens after a system upgrade went epically wrong. As an incentive, Leshner told users to "keep 10% as a white-hat. Otherwise, it's being reported as income to the IRS, and most of you are doxxed."

In another tweet Leshner explains what happened: "A few hours ago, Proposal 62 went into effect, updating the Comptroller contract, which distributes COMP to users of the protocol. The new Comptroller contract contains a bug, causing some users to receive far too much COMP. All supplied assets, borrowed assets, and positions are completely unaffected. Users don't have to worry about their funds; the only risk is that you (or another user) receives an unfairly large quantity of COMP."

Researchers have demonstrated that someone could use a stolen, unlocked iPhone to pay for thousands of dollars of goods or services, no authentication needed. Threatpost reports: An attacker who steals a locked iPhone can use a stored Visa card to make contactless payments worth up to thousands of dollars without unlocking the phone, researchers are warning. The problem is due to unpatched vulnerabilities in both the Apple Pay and Visa systems, according to an academic team from the Universities of Birmingham and Surrey, backed by the U.K.'s National Cyber Security Centre (NCSC). But Visa, for its part, said that Apple Pay payments are secure and that any real-world attacks would be difficult to carry out.

The team explained that fraudulent tap-and-go payments at card readers can be made using any iPhone that has a Visa card set up in "Express Transit" mode. Express Transit allows commuters around the world, including those riding the New York City subway, the Chicago El and the London Underground, to tap their phones on a reader to pay their fares without unlocking their devices. "An attacker only needs a stolen, powered-on iPhone," according to a writeup (PDF) published this week. "The transactions could also be relayed from an iPhone inside someone's bag, without their knowledge. The attacker needs no assistance from the merchant."

This attack is made possible by a combination of flaws in both Apple Pay and Visa's systems, the academic team noted. "The details of this vulnerability have been disclosed to Apple (Oct 2020) and to Visa (May 2021)," according to the writeup. "Both parties acknowledge the seriousness of the vulnerability, but have not come to an agreement on which party should implement a fix." "Variations of contactless-fraud schemes have been studied in laboratory settings for more than a decade and have proven to be impractical to execute at scale in the real world," Visa said in a statement to the BBC, adding that its fraud-detection systems would flag any suspicious transactions. Apple meanwhile shifted the responsibility to Visa and told the outlet, "We take any threat to users' security very seriously. This is a concern with a Visa system, but Visa does not believe this kind of fraud is likely to take place in the real world given the multiple layers of security in place. In the unlikely event that an unauthorized payment does occur, Visa has made it clear that their cardholders are protected by Visa's zero-liability policy." The researchers say users can protect themselves by not using Visa as a transport card in Apple Pay, and if they do, by remotely wiping the device if lost or stolen. The bug does not affect other types of payment cards or payment systems.

An anonymous reader shares an excerpt from a ZDNet article, written by Liam Tung: [A] survey has come up with another reason why your engineers might want to quit -- their fellow developers' terrible code. Software engineers have long struggled with 'technical debt' created by past coding practices that might have been clever but also were undocumented and exotic. At a high level, technical debt is the price paid by supporting legacy systems rather than overhauling them or implementing a better, new system. The term can span everything from a major IT implementation, such as a core banking system that requires a decade of bug fixes, to the choice of programming language to build backend systems. In the latter case, subsequent language updates can require today's developers to rewrite old code written by long-gone developers who wrote under different conditions and who might not have documented what they did and why they did it. That's a big problem for companies that have millions of lines of code written in a language.

Stepsize, a firm that focuses on technical debt by tracking development issues in major code editors such as VS Code, conducted a fairly small survey of 200 software engineers to find out why they leave their jobs. The company said that 51% of engineers in its survey have considered leaving or left a job because of technical debt. Of that group who feel irked by technical debt issues, some 20% said that type of debt is the main reason they left a company. The results should be taken in context: the company's key selling point is trying to solve technical debt challenges that organizations face, but at the same time, technical debt could be one area worthy of attention considering how hard it is to hire and retain software engineers.

Technical debt, or 'code quality and codebase health', was the fourth most important issue cited by respondents. Salary still trumped it, with 82% citing it as one of the "most important factors" when interviewing for a new role. The survey allowed respondents to choose several primary factors. "Technical challenges and growth opportunities" was the second priority, with 75% choosing it as the one of the most important factors. Some 68% of respondents said remote work was the most important actor, while 62% put said 'code quality and codebase health' was one of those prime factors. Slashdot reader ellithligraw first shared the report, adding: "Yet another reason developers are quitting... to escape the technical debt, or schlock code, or code rot. COBOL anyone?"

A serious bug in the iOS 15 Messages app can cause some saved photos to be deleted, according to multiple complaints reported by MacRumors readers and Twitter users. From the report: If you save a photo from a Messages thread and then go on to delete that thread, the next time an iCloud Backup is performed, the photo will disappear. Even though the image is saved to your personal iCloud Photo Library, it appears to still be linked to the Messages app in "iOS 15," and saving it does not persist through the deletion of the thread and an "iCloud" backup. This is a concern because most users keep the "iCloud" Backup feature enabled and it's something that happens automatically. If you're someone who regularly deletes message threads, if there's a photo that you want to keep, you won't be able to keep it with "iCloud" Backup turned on.

To replicate this bug, the following steps must be taken:
1. Save a photo from a Messages conversation to your Camera Roll.
2. Check to see that the photo has been saved.
3. Delete the Messages conversation the photo came from. The photo will still be in your "iCloud Photo Library" at this point.
4. Perform an "iCloud" Backup, and the photo disappears.

An anonymous reader quotes a report from Krebs On Security: The new $30 AirTag tracking device from Apple has a feature that allows anyone who finds one of these tiny location beacons to scan it with a mobile phone and discover its owner's phone number if the AirTag has been set to lost mode. But according to new research, this same feature can be abused to redirect the Good Samaritan to an iCloud phishing page -- or to any other malicious website. The AirTag's "Lost Mode" lets users alert Apple when an AirTag is missing. Setting it to Lost Mode generates a unique URL at https://found.apple.com/ and allows the user to enter a personal message and contact phone number. Anyone who finds the AirTag and scans it with an Apple or Android phone will immediately see that unique Apple URL with the owner's message.

When scanned, an AirTag in Lost Mode will present a short message asking the finder to call the owner at at their specified phone number. This information pops up without asking the finder to log in or provide any personal information. But your average Good Samaritan might not know this. That's important because Apple's Lost Mode doesn't currently stop users from injecting arbitrary computer code into its phone number field -- such as code that causes the Good Samaritan's device to visit a phony Apple iCloud login page. The vulnerability was discovered and reported to Apple by Bobby Rauch, a security consultant and penetration tester based in Boston. Rauch told KrebsOnSecurity the AirTag weakness makes the devices cheap and possibly very effective physical trojan horses.

The Record reports: The Electronic Frontier Foundation said it is preparing to retire the famous HTTPS Everywhere browser extension after HTTPS adoption has picked up and after several web browsers have introduced HTTPS-only modes." "After the end of this year, the extension will be in 'maintenance mode' for 2022," said Alexis Hancock, Director of Engineering at the EFF. Maintenance mode means the extension will receive minor bug fixes next year but no new features or further development.

No official end-of-life date has been decided, a date after which no updates will be provided for the extension whatsoever.

Launched in June 2010, the HTTPS Everywhere browser extension is one of the most successful browser extensions ever released. The extension worked by automatically switching web connections from HTTP to HTTPS if websites had an HTTPS option available. At the time it was released, it helped upgrade site connections to HTTPS when users clicked on HTTP links or typed domains in their browser without specifying the "https://" prefix. The extension reached cult status among privacy advocates and was integrated into the Tor Browser and, after that, in many other privacy-conscious browsers. But since 2010, HTTPS is not a fringe technology anymore. Currently, around 86.6% of all internet sites support HTTPS connections. Browser makers such as Chrome and Mozilla previously reported that HTTPS traffic usually accounts for 90% to 95% of their daily connections.
From EFF's announcement: The goal of HTTPS Everywhere was always to become redundant. That would mean we'd achieved our larger goal: a world where HTTPS is so broadly available and accessible that users no longer need an extra browser extension to get it. Now that world is closer than ever, with mainstream browsers offering native support for an HTTPS-only mode.

With these simple settings available, EFF is preparing to deprecate the HTTPS Everywhere web extension as we look to new frontiers of secure protocols like SSL/TLS... We know many different kinds of users have this tool installed, and want to give our partners and users the needed time to transition.
The announcement also promises to inform users of browser-native HTTPS-only options before the day when the extension reaches its final sunsetting — and ends with instructions for how to activate the native HTTPS-only features in Firefox, Chrome, Edge, and Safari, "and celebrate with us that HTTPS is truly everywhere for users."

According to multiple databases, researchers, and cybersecurity companies who spoke to MIT Technology Review, 2021 has had the highest number of zero-day exploits on record. "At least 66 zero-days have been found in use this year, according to databases such as the 0-day tracking project -- almost double the total for 2020, and more than in any other year on record," the report says. From the report: One contributing factor in the higher rate of reported zero-days is the rapid global proliferation of hacking tools. Powerful groups are all pouring heaps of cash into zero-days to use for themselves -- and they're reaping the rewards. At the top of the food chain are the government-sponsored hackers. China alone is suspected to be responsible for nine zero-days this year, says Jared Semrau, a director of vulnerability and exploitation at the American cybersecurity firm FireEye Mandiant. The US and its allies clearly possess some of the most sophisticated hacking capabilities, and there is rising talk of using those tools more aggressively.

Attackers are exploiting the same types of software vulnerabilities over and over again, because companies often miss the forest for the trees. And cybercriminals, too, have used zero-day attacks to make money in recent years, finding flaws in software that allow them to run valuable ransomware schemes. "Financially motivated actors are more sophisticated than ever," Semrau says. "One-third of the zero-days we've tracked recently can be traced directly back to financially motivated actors. So they're playing a significant role in this increase which I don't think many people are giving credit for."

While there may be an increasing number of people developing or buying zero-days, the record number reported isn't necessarily a bad thing. In fact, some experts say it might be mostly good news. No one we spoke to believes that the total number of zero-day attacks more than doubled in such a short period of time -- just the number that have been caught. That suggests defenders are becoming better at catching hackers in the act. You can look at the data, such as Google's zero-day spreadsheet, which tracks nearly a decade of significant hacks that were caught in the wild. One change the trend may reflect is that there's more money available for defense, not least from larger bug bounties and rewards put forward by tech companies for the discovery of new zero-day vulnerabilities. But there are also better tools. Defenders have clearly gone from being able to catch only relatively simple attacks to detecting more complex hacks, says Mark Dowd, founder of Azimuth Security. "I think this denotes an escalation in the ability to detect more sophisticated attacks," he says. Further reading: Emergency Software Patches Are on the Rise

On the day Apple released iOS 15, a Spanish security researcher disclosed an iPhone lock screen bypass that can be exploited to grant attackers access to a user's notes. From a report: In an interview with The Record, Jose Rodriguez said he published details about the lock screen bypass after Apple downplayed similar lock screen bypass issues he reported to the company earlier this year. "Apple values reports of issues like this with up to $25,000 but for reporting a more serious issue, I was awarded with $5,000," the researcher wrote on Twitter last week. [...] Because of the unprofessional way Apple handled his bug report, the researcher published today a variation of the same bypass, but this time one that uses the Apple Siri and VoiceOver services to access the Notes app from behind the screen lock. Further reading: Apple Pays Hackers Six Figures To Find Bugs in Its Software. Then It Sits On their Findings.

An anonymous reader shares a report: Hackers associated with the hacktivist collective Anonymous say they have leaked gigabytes of data from Epik, a web host and domain registrar that provides services to far-right sites like Gab, Parler and 8chan, which found refuge in Epik after they were booted from mainstream platforms. In a statement attached to a torrent file of the dumped data this week, the group said the 180 gigabytes amounts to a "decade's worth" of company data, including "all that's needed to trace actual ownership and management" of the company. The group claimed to have customer payment histories, domain purchases and transfers, and passwords, credentials and employee mailboxes. The cache of stolen data also contains files from the company's internal web servers, and databases that contain customer records for domains that are registered with Epik.

The hackers did not say how they obtained the breached data or when the hack took place, but timestamps on the most recent files suggest the hack likely happened in late February. Epik initially told reporters it was unaware of a breach, but an email sent out by founder and chief executive Robert Monster on Wednesday alerted users to an "alleged security incident." TechCrunch has since learned that Epik was warned of a critical security flaw weeks before its breach. Security researcher Corben Leo contacted Epik's chief executive Monster over LinkedIn in January about a security vulnerability on the web host's website. Leo asked if the company had a bug bounty or a way to report the vulnerability. LinkedIn showed Monster had read the message but did not respond.

An anonymous reader quotes a report from Ars Technica: Travis CI is a popular software-testing tool due to its seamless integration with GitHub and Bitbucket. As the makers of the tool explain: "When you run a build, Travis CI clones your GitHub repository into a brand-new virtual environment and carries out a series of tasks to build and test your code. If one or more of those tasks fail, the build is considered broken. If none of the tasks fail, the build is considered passed and Travis CI can deploy your code to a web server or application host." But this month, researcher Felix Lange found a security vulnerability that caused Travis CI to include secure environment variables of all public open source repositories that use Travis CI into pull request builds. Environment variables can include sensitive secrets like signing keys, access credentials, and API tokens. If these variables are exposed, attackers can abuse the secrets to obtain lateral movement into the networks of thousands of organizations.

Tracked as CVE-2021-41077, the bug is present in Travis CI's activation process and impacts certain builds created between September 3 and September 10. As a part of this activation process, developers are supposed to add a ".travis.yml" file to their open source project repository. This file tells Travis CI what to do and may contain encrypted secrets. Another place encrypted secrets may be defined is Travis' web UI. But, these secrets are not meant to be exposed. In fact, Travis CI's docs have always stated, "Encrypted environment variables are not available to pull requests from forks due to the security risk of exposing such information to unknown code." Ideally, Travis is expected to run in a manner that prevents public access to any secret environment variables specified. [...] This vulnerability caused these sorts of secrets to be unexpectedly exposed to just about anyone forking a public repository and printing files during a build process. Fortunately, the issue didn't last too long -- around eight days, thanks to Lange and other researchers who notified the company of the bug on September 7. But out of caution, all projects relying on Travis CI are advised to rotate their secrets.

The presence and relatively quick patching of the flaw aside, Travis CI's concise security bulletin and overall handling of the coordinated disclosure process has infuriated the developer community. In a long Twitter thread, Peter Szilagyi details the arduous process that his group endured as it waited for Travis CI to take action and release a brief security bulletin on an obscure webpage. "After 3 days of pressure from multiple projects, [Travis CI] silently patched the issue on the 10th. No analysis, no security report, no post mortem, not warning any of their users that their secrets might have been stolen," tweeted Szilagyi. After Szilagyi and Lange asked GitHub to ban Travis CI over its poor security posture and vulnerability disclosure processes, an advisory showed up. "Finally, after multiple ultimatums from multiple projects, [they] posted this lame-ass post hidden deep where nobody will read it... Not even a single 'thank you.' [No] acknowledgment of responsible disclosure. Not even admitting the gravity of it all," said Szilagyi, while referring to the security bulletin -- and especially its abridged version, which included barely any details. Szilagyi was joined by several members of the community in criticizing the bulletin. Boston-based web developer Jake Jarvis called the disclosure an "insanely embarrassing 'security bulletin.'" "Travis CI implemented a series of security patches starting on Sept 3rd that resolves this issue," concluded Mendy on behalf of the Travis CI team. "As a reminder, cycling your secrets is something that all users should do on a regular basis. If you are unsure how to do this, please contact Support."

An anonymous reader quotes a report from Ars Technica: Amazon's Kindle e-readers get new software updates regularly, and they're mostly of the nondescript, invisible "performance improvements and bug fixes" variety. But the most recent operating system update (version 5.13.7) is rolling out now, and it refreshes the device's user interface for the first time since 2016 or so. Amazon says that redesigns for the Home and Library screens, which are mostly untouched in the current Kindle update, will be coming "later this year." The software update that enables the new interface began rolling out in August, but because Kindles only install updates automatically when they're charging and connected to Wi-Fi, it will be a few weeks or months before all supported Kindles will have a chance to grab the update (mine only installed it over this past weekend).

The new update is available on most Kindles released in or after 2015, including the 7th- and 10th-generation Kindle Paperwhite, the 8th-, 9th-, and 10th-generation Kindle Oasis, and the 8th- and 10th-generation standard Kindle. Older "7th-generation" Kindle devices like 2014's Kindle Voyage don't appear to be supported. [...] The new update doesn't fix Amazon's confusing Kindle naming scheme, which groups different devices into "generations" that are numbered based roughly on when they were released, not on what generation of product they actually are; the "10th-generation" Paperwhite is actually only the fourth Paperwhite Amazon has released. But you now can head into the Device Info screen and see which Kindle you're using instead of having to guess.