Hírolvasó

Végre egy tisztességesebb előrelépést jelent elődjéhez képest a dél-koreaiak legújabb foldable mobilja.

"Ezt a 8 éves procis gépre felmegy részhez tudnál linket adni?" trey 2025. 07. 10., cs – 10:02

A cég értéke a tegnapi kereskedési napon áttörte a négybillió dolláros határt.

Inside this week's LWN.net Weekly Edition:

• Front: Python packaging; Kernel API specification; Kselftests and KUnit; niri; pedalboard.
• Briefs: Git security fixes; Amarok 3.3; Bash 5.3; Thunderbird 140; tmux-rs; U-Boot 2025.07; Quotes; ...
• Announcements: Newsletters, conferences, security updates, patches, and more.

Version 3.3 of the Amarok music player has been released. This is the first release of Amarok based on KDE Frameworks 6 and Qt 6. Amarok 3.3 also includes a major rework of its audio engine to use GStreamer for audio playback.

The reworked audio engine provides unified feature set for all users and should provide a solid and future-proof sonic experience for years to come. Notable improvements have also landed to the database system: improved character set support helps with e.g. emojis in podcast descriptions and other very exotic symbols, date handling has been improved ('year 2038 problem'), and various other potential and actual database-related issues have been fixed.

The AlmaLinux project has announced new upgrade paths for its ELevate utility, which allows users to upgrade between major versions of Red Hat Enterprise Linux derivatives. The new paths include upgrades from AlmaLinux 9 to AlmaLinux 10 and CentOS Stream 9 to CentOS Stream 10, with support for EPEL, Docker CE, and PostgreSQL third-party package repositories. LWN covered ELevate last year.

It is no secret that the Python packaging world is at something of a crossroads; there have been debates and discussions about the packaging landscape that started long before our 2023 series describing some of the difficulties. There has been progress since then—and incremental improvements all along, in truth—but a new initiative is looking to overhaul packaging for the language. At PyCon US 2025, Barry Warsaw and Jonathan Dekhtiar gave a presentation on the WheelNext project, which is a community effort that aims to improve the experience for users and providers of Python packages while also working with toolmakers and other parts of the ecosystem to "reinvent the wheel". While the project's name refers to Python's wheel binary distribution format, its goals stretch much further than simply the format.

"It's the worst piece of shit i've ever driven in my life" trey 2025. 07. 09., sze – 15:17

Viszlát, Christian! trey 2025. 07. 09., sze – 15:12

Security updates have been issued by AlmaLinux (container-tools:rhel8, jq, kernel, podman, python-setuptools, socat, and thunderbird), Gentoo (Chromium, Google Chrome, Microsoft Edge. Opera, ClamAV, Git, NTP, REXML, and strongSwan), Oracle (buildah, gnome-remote-desktop, ipa, jq, kernel, podman, python-setuptools, ruby:3.3, socat, uek-kernel, and xorg-x11-server-Xwayland), SUSE (kernel), and Ubuntu (freerdp3, git, gnupg2, linux-aws, linux-oracle, linux-azure, linux-azure, linux-azure-6.11, linux-fips, linux-aws-fips, linux-azure-fips, linux-gcp-fips, linux-ibm-5.15, linux-intel-iotg, linux-nvidia-tegra, linux-nvidia-tegra-5.15, linux-nvidia-tegra-igx, linux-kvm, linux-lowlatency, linux-oem-6.11, and onionshare).

Drasztikus módon reagált a Revolut arra, hogy a Büntető törvénykönyvben kriminalizálták a kriptovaluta-ügyleteket.

A gyártók szerencséjére a világ többi régiójában javában cserélik le a Windows 10-es gépeket.

"Jó újra otthon!"

A Power11 az első jelentősebb fejlesztése a termékvonalnak 2020 óta.

Sokkal könnyebbé válik a hírlevelek és feliratkozások kezelése.

27 év után hagyja el a céget a fontos feladatokat ellátó Jeff Williams.

Minden napra egy kammantás Magyartól trey 2025. 07. 09., sze – 10:34

A Gigabit Magyarország Program keretén belül 85 milliárd forintnyi vissza nem térítendő támogatás nyílik meg a szolgáltatók előtt.

Diogo Jotáról ... trey 2025. 07. 09., sze – 09:11

The independent security researcher Adam Gowdiak has published an extensive report on flaws he found in some eUICCs (the chips used to store eSIM profiles within the GSMA eSIM architecture). While the specific demonstrable exploit was in a product of one specific CardOS Vendor (Kigen, formerly part of ARM), the fundamental underlying issue is actually an architectural one.

The Oracle Javacard [memory] safety architecture relies on a so-called bytecode verifier which is a program that you run after compiling an application, but before executing the code on the Javacard. The specifications allow for both on-card and off-card verification. However, the computational complexity of this verifier is generally assumed to exceed the resources available inside many microcontrollers used to implement java cards. Such microcontrollers often are ARM SC000 (Cortex-M0 based) or SC300 (Cortex-M3 based) based, with only tens of kilobytes of RAM and hundreds of kilobytes of flash.

Javacard was originally developed for use cases within the banking/payment industry. In that industry, the card-issuing bank is the sole entity that has the keys to load java applets onto a card. That entity is of course interested in the security of the card, and will hence always run an off-card bytecode verifier. In a world of physical SIM/USIM cards issued by a single mobile operator, the situation is the same: The card-issuing MNO/MVNO is the only entity with key materials to install additional java applets on the card.

This fundamental problem became already apparent by earlier findings by Adam Gowdiak in 2019, but at least in terms of public responses by Oracle and Gemalto back then, they mostly did hand-waving and/or made lame excuses.

However, when the industry represented in GSMA standardized the eSIM architecture, this changed. Suddenly we have various eSIM profiles of various different operators, each holding key material to install Java applets on the shared card. In such an environment, it is no longer safe to assume that every MNO/MVNO can be trusted to be non-adverserial and hence trusted to run that off-card bytecode verifier before loading applets onto the card.

If the Javacard runtime on the existing card/chip itself cannot autonomously perform those verification tasks, I don't see how the problem can ever be solved short of completely removing/disabling Javacard support in such eUICCs. Luckily it is an optional feature and not a mandatory requirement for an eUICC to be approved/accredited. Sadly many MNOs/MVNOS however will mandate Javacard support in their eSIM profiles and hence refuse to install into an eUICC without it :(

In my opinion, the solution to the problem can only be to either make the GSMA require full on-card bytecode verification on all eUICCs, or to remove Javacard support from the eUICC.

We have to keep in mind that there are hundreds if not thousands of MVNOs around the planet, and all of them are subject to whatever local jurisdiction they operate in, and also subject to whatever government pressure (e.g from intelligence agencies).

In hindsight, anyone familiar with the 2019 work by Gowdiak and an understanding of the fundamental change to multiple stakeholders in an eUICC (compared to classic SIM/USIM) should have arrived at the conclusion that there is a serious problem that needs addressing. I think the 2019 work had not been publicized and covered significantly enough to make sure that everyone in the industry was made aware of the problems. And that in turn is mostly a result of Oracle + Gemalto downplaying the 2019 findings back in the day, rather than raising awareness within all relevant groups and bodies of the industry.

Mitigation via TS.48 key diversification

The specific attack presented was using a GSMA TS.48 test profile to install the malicious java bytecode; those TS.48 profiles are standardized profiles used by the industry for cellular testing; until the attack they contained well-known static OTA key material. The mitigation to randomize/diversity those keys in TS.48v7 closes that particular vector, but the attack itself is not dependent on test profiles. Any MNO/NVNO (or rather, anyone with access to a commercial service of a SM-DP+ accredited by GSMA) obviously has the ability to load java applets into the eSIM profile that they create, using keys that they themselves specify.

What IMHO ought to be done

• Oracle should get off their we only provide a reference implementation and vendors should invent their own prporietary verification mechanisms horse. This is just covering their own ass and not helping any of their downstream users/implementers. The reference implementation should show how proper verification can be done in the most resource-constrained environment of cards (it's JavaCard, after all!), and any advances of the verifier should happen once at Oracle, and then used by all the implementers (CardOS vendors). Anyone who really cares about security of a standardized platform (like Javacard) should never leave key aspects of it up to each and every implementer, but rather should solve the problem once, publicly, with validation and testing tools, independent 3rd party penetration testing and then ensure that every implementer uses that proven implementation.

• GSMA should have security requirements (and mandatory penetration tests) specifically regarding the JVM/JRE of each card that gets SAS-UP accredited.

• GSMA should require that Javacard support should be disabled on all existing eUICCs that cannot legitimately claim/demonstrate that they are performing full bytecode verification entirely on-card.

• GSMA should refuse any future SAS-UP accreditation to any product that requires off-card bytecode verification

• The entire industry should find a way to think beyond Javacard, or in fact any technology whose security requires verification of the executable program that is too complex to perform on-card on the targeted microcontrollers.