faiss 1.15.1

SingleFile CLI 2.14.0

New features

• --filename-replaced-character accepts a JSON array, for example '[" ", "_"]' to replace spaces with underscores. It is the way to ask for a replacement the space-separated form cannot express, a space as the replaced character being the one that was wanted

Changes

• Resources fetched outside the browser now carry a Referer. That lane runs when the browser could not get a resource itself, and it sent no referrer at all, so a host that varies its answer on one — a font service answering 404, an image host serving a placeholder — gave the saved page something the reader never saw. The value follows the referrer policy the document declares, the way the browser computes it
• Runs of control characters in a filename collapse into a single replacement character, as they already did in the extensions and in single-file-core
• --filename-replaced-character keeps the order it is given. An entry written without a replacement used to be moved to the end of the table
• --help prints default values in the form the option reads back. The list of replaced characters was printed as a JSON array, so its control-character entry appeared with the backslashes doubled, and passing that back selected digits and uppercase letters instead of control characters
• --load-deferred-content-dispatch-scroll-event also defaults to on when the CLI is used as a library, as it has on the command line since 2.13.0. The two now share one set of defaults and can no longer disagree

Fixes

• --filename-replaced-character no longer drops a replacement containing a space. The value was split on every space and only the first two parts were kept, so "> _G T_" replaced > with _G
• --filename-replaced-character no longer accepts a value with nothing before the space. It matched no character at all, so the option did nothing without saying so; it is now reported as an invalid value
• An entry given without a replacement no longer shifts the entries after it, which gave the following character someone else's replacement
• --max-appended-data-length shows the real default in --help instead of a copy of it

Fixes from single-file-core 1.6.2, 1.6.3 and 1.6.4

• Fonts declared with font-style: oblique and an angle are no longer removed as unused when the page uses them as italic. The face was kept only when the style text matched exactly, so oblique 14deg never matched the italic the page asked for and the text lost its font. Font styles are now compared as angle ranges, the way the CSS specification defines the match
• A filename replacement left empty in the middle of the table no longer writes undefined into the name

Co-authored by Claude (Claude Code)

Changed

• PR comments paint as comments. Badge images become P1/P2/P3 chips, mermaid fences become
  a ⧉ mermaid placeholder, HTML headings match markdown headings, <details> starts collapsed,
  and HTML tags no longer leak as source. The same renderer drives the All-files preview.

• A review thread shows every reply in the read pane. GitHub, GitLab, and Azure DevOps.
  The ↳ N replies — open on GitHub line is gone. Click a <details> summary to toggle it;
  on the PR tab →/← expand/collapse every details in the open thread.

• A capped list says so in the pane (newest 100 comments / newest 100 checks) instead of
  sending you to the forge.

sync repo: +2 releases, -1 release

## New releases
- [ida-nexus](https://github.com/hexrayssa/ida-nexus): 0.11.2
- [mcrit-ida](https://github.com/danielplohmann/mcrit-plugin): 1.1.10

## Changes
- [ida-codemode](https://github.com/hexrayssa/ida-codemode):
  - removed version(s): 0.4.0

Fixed

• Function Scope returning no matches for every function after the first, on SMDA 4.8 and later.
  SmdaReport.getFunctions() caches its result there, and the plugin reused a single outline
  report across queries while only swapping its xcfg, so every query after the first
  re-submitted the first function. A fresh outline is now built per query.

• The outline now follows a replaced local report, so an upload after renaming no longer carries
  the previous report's metadata.

What's Changed

Changes

• docs: add DeepWiki badge by @r0ny123 in #14
• Pick the versioned libpython for idapyswitch by @danielplohmann in #19
• Build a fresh SMDA report outline per function query (1.1.10) by @danielplohmann in #18
• Release on a tag from the changelog, with the checks that were memory before by @r0ny123 in #15

Full Changelog : v1.1.9...v1.1.10

|

1. Fly to Taipei. Round-trip from Orlando: $1,081.
2. Go to the largest retailer in Taiwan to Spend NT$129,990 ≈ US$4,093.
3. Hang out in Taiwan for two weeks. Eat good food. Touch international grass.
4. Fly home and flex on r/LocalLLaMA.

https://preview.redd.it/vtve8s6wgrph1.png?width=287&format=png&auto=webp&s=fcc391187f458d2ca023a929e554b880bf425560 https://preview.redd.it/guffjq55hrph1.png?width=340&format=png&auto=webp&s=04cb074f89467c4ad73e36ac6e0570d14d228443 https://preview.redd.it/fe1obue0hrph1.png?width=1095&format=png&auto=webp&s=e3955e613ce4e53d65972b7f6e69e1468b6d6396 submitted by /u/DegenDataGuy
[link] [comments]
---|---

You're watching a video on your favourite streaming platform. The platform sends video frames over HTTPS (encrypted), encapsulated in an IP packet with your IP address, ultimately forwarded to your fibre router inside an Ethernet frame. What you might not expect is that this Ethernet frame, containing your encrypted video, is actually received by all your neighbours' routers as well.

The technology behind this behaviour is Passive Optical Networks (PON) : the optical signal received by your router is the same signal received by your neighbours, containing data for several nearby subscribers. It is effectively like having access to your neighbours' Ethernet cables from inside your home, but in one direction only.

What can be extracted then depends entirely on what the subscriber is doing. If protocols are encrypted, the ONU only receives unencrypted metadata (source/destination addresses, ports, etc.), which can still reveal internet habits. If protocols are unencrypted, such as unencrypted DNS, unencrypted VoIP traffic, or legacy protocols, the entire payload is exposed.

Several mechanisms can be activated to encrypt and authenticate each part of the signal so that only the intended recipient can decrypt and process it.

ℹ️ Glossary

There are many acronyms and definitions used in this article. The glossary is available at Annex A: Glossary.

Fibre networks

Internet Service Providers (ISPs) and companies often use Passive Optical Networks (PONs) to connect end-user devices to their infrastructure using optical fibre in the last kilometre (Fibre-to-the-x (FTTx)). If you have fibre internet in France or Europe, your router is probably using this technology, Gigabit-capable PON (GPON) or 10-Gigabit-capable (Symmetric) PON (XG(S)-PON) in particular.

Before examining the security aspects of PONs, we will first review the evolution of the specifications, how PONs work, and how data is structured on the link.

PON specifications

Over the years, several iterations of PON specifications have been published by the ITU-T (International Telecommunication Union Telecommunication Standardization Sector):

PON specifications timeline based on first specification publication date

All the iterations in the timeline above are currently in use (although XGS- PON might be preferred to XG-PON) and can often coexist. While GPON has been around for more than 20 years, it is still standard for basic internet plans in France.

As for the latest specification, 50-Gigabit-capable PON (50G-PON), released 5 years ago, some ISPs are only now starting to make real-world deployments. Orange, a French multinational ISP, made a small-scale demonstration of 50G-PON in October 2025 which it calls "the future standard for transmission systems in fibre access networks (FTTH)"1.

Newer PON specifications can be grouped by the PON development phase they belong to:

• Next-generation PON 1 (NG-PON1): XG-PON, XGS-PON.
• Next-generation PON 2 (NG-PON2): NG-PON2.
• Higher Speed PON (HSP): 50G-PON.
• Very High Speed PON (VHSP): in development.

We will stop at HSP/50G-PON, as it is the latest PON specification that has been released.

Competing standards from the IEEE exist as well, to cite a few:

• Ethernet PON (EPON): 1 Gbps symmetric.
• Asymmetric 10G-EPON: 10 Gbps downstream, 1 Gbps upstream.
• Symmetric 10G-EPON: 10 Gbps symmetric.

We will focus on the ITU-T standards as they seem to be prevalent in France and Europe.

Passive Optical Network (PON)

ONUs, OLTs and the ODN

PONs are optical fibre networks connecting Optical Line Terminations (OLTs) to Optical Network Units (ONUs) through Optical Distribution Networks (ODNs).

ODNs used to be built around passive optical filters, splitters and combiners; hence the "Passive" Optical Network designation. However, newer specifications have introduced active elements such as Range Extenders, so the passive part depends on how the ODN is deployed.

The ONU is the component of the router interfacing with the PON and it is sometimes a separate device connected to the router. When a single subscriber uses an ONU, it may also be called an Optical Network Termination (ONT).

A simple description of an ONU would be that it is a device extracting Ethernet frames from the optical signal and forwarding them to the router. However, ONUs support other protocols as well (such as VoIP), have Quality-of- Service features (for time-sensitive signals), Layer-2/Layer-3 features (VLANs, IP configuration, TCP/UDP services, etc), configuration of xDSL if the ONU has xDSL ports, configuration of the security features, etc. The ONU Management and Control Interface (OMCI) specification, which defines the protocol used to configure the ONU, is 700 pages long. ONUs are more complex than they seem.

ONUs are connected to an OLT which can be described as a fibre switch/router, through the ODN. The OLT is located on the service provider's side (ISP for instance).

ONU (top) connected to the OLT (bottom) through an optical fibre. The ONU is plugged on one of the passive optical splitter ports, the splitter is integrated with the OLT here.

The Optical Distribution Network: multiplexing optical signals

One key aspect of an Optical Distribution Network (ODN) is that the signal is carried over a reduced number of optical fibres up to a splitter where individual fibres will carry the signal to the end user.

To multiplex signals over a single fibre, several techniques are used depending on the specification or implementer's choice: Wavelength Division Multiplexing (WDM) , Time Division Multiplexing (TDM) or combining both using Time and Wavelength Division Multiplexing (TWDM).

WDM uses different light frequencies to carry multiple signals. Due to carefully chosen frequencies, GPON, XG(S)-PON, NG-PON2 and 50G-PON can coexist on the ODN using a coexistence element (see ITU-T G.980519). For NG-PON2 and HSP, WDM is also used to increase the overall bandwidth by creating several channels that each use a different frequency pair. WDM can also designate the separation of transmit/receive frequencies to use on a single fibre, as opposed to using an individual fibre for each direction.

Taking GPON as an example, the downstream signal is carried on a single fibre from the OLT up to a passive splitter. WDM is used: the upstream and downstream signals use separate wavelengths. The signal is then split (copied) between up to 128 users in the last kilometre and carried using individual fibres. Instead of running 128 individual fibres over up to 60km, only the last few metres will require individual fibres, which reduces the cost and complexity. However, this also means that all 128 users on the same ODN will receive the same downstream signal containing all users' data.

Downstream PON

As for the upstream signal, it uses Time Division Multiple Access (TDMA) , a specific type of TDM : each ONU sends bursts on a timing provided by the OLT, which enables all the individual optical signals from the ONUs to be passively aggregated again before reaching the OLT.

Upstream PON

For HSP and NG-PON2, the combination of WDM and TDM to create channels is designated as TWDM.

The impact of PON architecture on security

As the downstream signal is passively split between all the ONUs, they all receive the same downstream signal which contains their data but also their neighbours'. Basically, all downstream communications are broadcast at the link level, which mandates specific security measures.

As for the upstream signal, it is not carried to other users. However, it can still be intercepted on each individual fibre or when aggregated by the combiner en route to the OLT.

In both cases, authentication and encryption are desirable to avoid eavesdropping, tampering, or man-in-the-middle attacks, which brings us to the threat model of PON specifications.

The PON's protocol stack

In the previous sections, we learned how PONs are structured. This section presents the protocols used to configure the PON link and how data is framed. The objective is to present a condensed view of the frame structure; it can be glossed over and used as a reference for the next security-focused part.

Three main configuration channels: Embedded OAM , PLOAM and OMCI

Before going into the frame structures, let us mention three protocols used by GPON, XG(S)-PON, NG-PON2 and 50G-PON:

• Embedded layer Operation, Administration and Maintenance (Embedded OAM): fields embedded in the frame headers for low latency access, for instance, the frame identifier or the upstream bandwidth allocation.
• Physical layer Operation, Administration and Maintenance (PLOAM): used for other information not sent by the above that relates to the link layer, information that is less time-sensitive but used to configure the connection. For instance, sending the serial number to the OLT, the ONU ID, sending the data encryption key, etc.
• ONU Management and Control Interface (OMCI): the protocol used for high-level configuration of the ONU (the channel is actually called ONU Management and Control Channel (OMCC)). The protocol is defined in the ITU-T G.988 ONU management and control interface (OMCI) specification 15. It uses a Management Information Base (MIB) synchronised between the ONU and the OLT, and allows complex mutual authentication, Layer 2 and Layer 3 configuration, ONU debug, etc.

Four layers

GPON, XG(S)-PON, NG-PON2 and 50G-PON all have similar frame structures, sharing a few similar characteristics:

• When TDM is used (which is most of the time), the upstream frame structure is slightly different from the downstream frame structure.
• The frames have four layers: Physical Medium Dependent (PMD) layer, Transmission Convergence (TC) PHY Adaptation Sublayer, TC Framing Sublayer (FS) and TC Service Adaptation Sublayer.
• The lower layer is the PMD layer, which defines how data is encoded on the optical line.
• The layer between the PMD and user functionalities (Service Data Units, SDUs) is the TC layer. It's called GTC for GPON4, XGTC for XG-PON9, XGS-PON TC10 for XGS-PON, TWDM TC for NG-PON214 and ComTC (for Common TC) for 50G-PON (HSP)17. 50G-PON/Higher Speed PON generalises the TC layer from XG-PON onwards.
• The TC service adaptation sublayer contains (X)GEM frames ((10) Gigabit PON Encapsulation Method) which encapsulate the actual data payload (Ethernet frames for instance).

The diagram below represents a downstream frame and its separation into different layers. This representation deliberately shows only a few fields which are relevant to explain how PON works or are security-related. Technically, it only applies to XG(S)-PON, NG-PON2 and 50G-PON, but GPON is similar. Moreover, while the name and overall purpose of a field might be the same between PON versions, the structure can differ.

XG(S)-PON, NG-PON2 and 50G-PON downstream frame structure

The fields shown on the diagram have the following use:

• Superframe counter (SFC) : 51-bit (XG(S)-PON, NG-PON2 and 50G-PON), 30-bit (GPON), wraps around to 0. It is used in the data encryption process for the counter mode of operation.
• PLOAMd : used by the OLT in the PLOAM configuration protocol, for instance to request a new data encryption key.
• BWmap : not directly security-related, but contains the timings on which upstream frames can be sent for each ONU (for TDMA). More precisely, the OLT assigns Allocation IDs (Alloc-IDs) to the ONUs (a default one is always assigned for OMCI). These Alloc-IDs are then associated with Transmission Containers (T-CONs) which represent a group of logical connections which can be assigned a bandwidth. Finally, each downstream frame contains the bandwidth assignment for the Alloc-IDs, which means each Alloc-ID/T-CON will have a dedicated time to send an upstream burst. Note that the TC layer is only concerned with Alloc-IDs, T-CONs are managed through OMCI and another structure could map to Alloc-IDs. T-CONs are then mapped to (X)GEM ports, the smallest connection entity. Grouping (X)GEM ports into T-CON enables managing bandwidth for QoS (Quality-of-Service) purposes, to prioritise real-time signals such as voice audio.
• Encryption key index : only for XG(S)-PON, NG-PON2 and 50G-PON. Indicates if the downstream payload is: unencrypted, encrypted using key 1, encrypted using key 2 (key index relative to the key slot). GPON does not have such a field: the OLT does not select a key slot but sends a Superframe counter value to the ONU through PLOAMd at which the new key (to be sent) will be used.

In GPON, the FS Header and PSBd are actually merged as a single header (named GTC Header or PCBd) with a similar purpose. Another difference is that while the PLOAMd , BWmap and SFC fields are present in all PON versions, the Encryption key index is only present in XG(S)-PON, NG-PON2 and 50G-PON.

The diagram below represents an upstream frame for XG(S)-PON, NG-PON2 and 50G-PON; it differs slightly for GPON, but it is overall very similar:

XG(S)-PON, NG-PON2 and 50G-PON upstream frame structure

The upstream frames are sent in bursts. Each Alloc-ID is given an opportunity to send data according to the BWMap field sent in the downstream frame. Alloc-ID bandwidth allocations that belong to the same ONU and are consecutive (in time and thus in the BWMap) are called an allocation series. They start with an FS Header and end with an FS Trailer.

Threat models of GPON, XG(S)-PON, NG-PON2 and 50G-PON

All the ITU-T PON specifications referenced have a threat model, which has greatly improved from GPON to XG-PON. XGS-PON/NG-PON2/50G-PON share the XG-PON threat model for the most part.

The GPON4 threat model can be summarised as such:

• An attacker or user having reprogrammed an ONU, or having otherwise access to the incoming optical signal, can access all downstream communications including data from all the other OLT users.
• Other threats such as eavesdropping on the upstream link are considered impractical because the attacker would have to tap into the fibre, sometimes in public places and in a noticeable way for the PON.

The XG-PON specification9 as well as XGS- PON9 10, NG- PON214 and 50G-PON17 have gone back on this model, taking upstream threats into account as well:

• An attacker or user having reprogrammed an ONU, or having otherwise access to the incoming optical signal, can access all downstream communications including data from all the other OLT users.
• An attacker or user having reprogrammed an ONU can impersonate another ONU and forge packets.
• An attacker could intercept or generate traffic at any point on the ODN (which sometimes spans 60 km) between the OLT and the ONU, impersonating the OLT or an ONU.
• An attacker or user could use any of the scenarios above to record and replay packets transmitted on the PON, or modify the packets (bitflips for instance).

Overall, the threat model has improved significantly since GPON, considering security issues in both directions (OLT to ONU and ONU to OLT), as well as eavesdropping anywhere between the OLT and ONUs. This translates into improved security features as well.

Additionally, a study group with members from China Telecommunications Corporation, Verizon, Huawei Technologies Co., Ltd. and ZTE Corporation has published recommendations named "Practical aspects of PON security" starting from 2022. A first supplement has been published20, with the objective "to guide the security experts on operators' expectations about the security of their access networks and on the criteria of a valuable security proposal, as well as the reference to the operators on configuring their networks to achieve the best possible security performance.".

The improved threat model in the supplement separates the threats into several categories:

• Eavesdropping: downstream and upstream.
• Theft of service: unauthorised access to the PON.
• Denial of service.
• Theft of data.
• Impersonation.
• Disruption of operations: disruption from a single ODN to a larger scale (entire ISP for instance).

The supplement insists that "regardless of how strong the link-level encryption strength is, no end-to-end data security property can be derived from it". Indeed, PON specifications are only concerned with establishing a secure channel between an ONU and an OLT, at the link level. This channel is not established between an end user and a service provider directly.

Overall, the supplement gives more context to the threat model and makes recommendations on key management and handling of ONU identifier duplication. The XG-PON ITU-T G.987.39, NG- PON2 ITU-T G.989.314 and 50G-PON ITU-T G.9804.217 specifications' latest amendments actually recommend using this supplement for best practices related to key management. As it is recommended by the specifications, it probably must be implemented.

One threat that does not seem to be mentioned in any of the threat models is the exploitation of vulnerabilities in the OMCI Management Entities, which have a large attack surface. The implementation of the OMCI Management Entities functionalities is down to the manufacturer so this might be outside the specification perimeter however.

PON security measures

Authentication and cryptographic schemes

Authentication in ITU-T PONs can be surprisingly complex, as there are multiple identifiers and schemes available. They are sometimes combined, and the authentication methods do not all ensure the same level of security.

We will separate the use of these identifiers into two categories:

• Identification: the OLT requests an identifier, but there is no secure channel bound to this identifier. In GPON, the OLT can request an identifier and then request an encryption key, but the key is not bound to the identifier, which is why only one authentication scheme is considered for GPON (OMCI-based).
• Authentication: the OLT (and the ONU if the authentication is symmetric) uses a cryptographic scheme to authenticate its counterpart. The results of this authentication can be used to establish a secure channel between the two devices. Keep in mind that, as we'll see in the next sections, a successful authentication does not mean the secure channel is activated, only that it can be.

All PON versions start with an identification step: at the very start of its connection to the OLT, the ONU sends its serial number.

Then, for GPON, cryptographic authentication is entirely optional. For XG-PON and later, a Registration ID -based authentication will always be performed after ONU initialis ation, whether Registration_ID is the default null string or a provisioned one. If a Registration_ID is not provisioned, it will not provide meaningful authentication.

After the mandatory identification or authentication steps, the OLT can start a new authentication process at any point, or request other identifiers. For authentication, up to three cryptographic schemes are available depending on the PON version. Some of these schemes allow for mutual authentication (ONU to OLT, but also OLT to ONU), all of them lead to the creation of a Master Session Key (MSK) which can then be used to establish a secure channel.

Authentication decision diagram

The Logical ONU ID (LOID) / LOID password identifiers often present in ONU web interfaces can be a bit confusing. They seem to be both implemented in custom OMCI Management Entities (as is the case for the Management Entity 65530 used by Huawei ONUs) and in the standard "ONU-G" OMCI Management Entity. The O3 Labs website21 lists several vendor-specific OMCI Management Entities.

Note that a combination of these identifiers and schemes can be used at different steps during the configuration of the ONU. For an XGS-PON link the following sequence could be used:

1. Identify the ONU through the serial number sent at the start of the link initialisation.
2. Request the Registration ID from the ONU, derive an MSK using the corresponding cryptographic scheme and enable encryption.
3. Start the OMCI cryptographic scheme and transition to the new MSK.

The (mutual) secure authentication mechanisms

In the previous section, we mentioned three authentication mechanisms based on cryptography: Registration ID-based, OMCI-based and IEEE 802.1X-based.

Only the last two are mutual authentication schemes that authenticate both the ONU and the OLT.

Registration ID-based authentication

Only available in XG(S)-PON, NG-PON2 and 50G-PON. This is the default authentication mode based on a 36-byte value called Registration_ID and it is not mutual. The Registration_ID is requested by the OLT during the ONU activation process and can be queried at any time through a PLOAM message, which is unencrypted.

This mechanism is thus vulnerable to several threats, for instance:

• An attacker can unplug the target optical fibre, plug it in their OLT, request the Registration_ID , derive the keys and use them to decrypt the encrypted data encryption key transmitted through PLOAM after the device has been plugged back to the original OLT.
• An attacker could tap at any point between the targeted user and the OLT and see the Registration_ID in clear form, derive the keys and use them to decrypt the encrypted data encryption key transmitted through PLOAM.

The Registration_ID is not meant to be changed regularly, the attacker can query it once and reuse it at any time. Moreover, if it is unchanged, the default is used.

A key consideration is that Registration_ID \def\pelican{\textrm{pelican}^2} \text{Registration\ID} has a default value (0x00)36 \def\pelican{\textrm{pelican}^2} (0x00){36}, which will be used for the Registration ID-based authentication unless a Registration_ID has been provisioned. Thus, the specifications effectively allow the use of one of the cryptographic authentication schemes with a known (weak) secret. Having the possibility to use an unauthenticated/unencrypted channel, which would not provide a false sense of security, would seem preferable.

Registration ID-based MSK derivation

Let:

• Registration_ID \def\pelican{\textrm{pelican}^2} \text{Registration\_ID} be the 36-byte Registration ID.
• TMSK \def\pelican{\textrm{pelican}^2} T_{MSK} be the required MSK length.
• K \def\pelican{\textrm{pelican}^2} K be the 128-bit AES key used in the AES-ECMAC definition.
• M \def\pelican{\textrm{pelican}^2} M be the input message used in the AES-ECMAC definition.
• Tlen \def\pelican{\textrm{pelican}^2} Tlen be the requested MAC output length in bits.
• MlessLastBlock \def\pelican{\textrm{pelican}^2} M_{\text{lessLastBlock}} be the M \def\pelican{\textrm{pelican}^2} M with its final 16 octets removed.

MSK \def\pelican{\textrm{pelican}^2} MSK is derived the following way:

MSK={AES-128-CMAC&af((0x55)16,Registration_ID,128),TMSK=128AES-128-ECMAC&af((0x55)16,Registration_ID,256),TMSK=256 (50G-PON/HSP) \def\pelican{\textrm{pelican}^2} MSK = \begin{cases} \operatorname{AES-128-CMAC}\left((\text{0x55}){16}, \text{Registration\_ID}, 128\right), & T{MSK}=128 \\[6pt] \operatorname{AES-128\text{-}ECMAC}\left((\text{0x55}){16}, \text{Registration\_ID}, 256\right), & T{MSK}=256 \text{ (50G-PON/HSP)} \end{cases}

where

AES-128-ECMAC&af(K,M,Tlen)={AES-128-CMAC&af(K,M,Tlen),Tlen≤128AES-128-CMAC&af(K,MlessLastBlock,128)&smidAES-128-CMAC&af(K,M,128),Tlen=256 \def\pelican{\textrm{pelican}^2} \operatorname{AES-128\text{-}ECMAC}(K, M, Tlen) = \begin{cases} \operatorname{AES-128-CMAC}(K, M, Tlen), & Tlen \leq 128 \\[4pt] \operatorname{AES-128-CMAC}\left(K, M_{\text{lessLastBlock}}, 128\right) | \operatorname{AES-128-CMAC}(K, M, 128), & Tlen = 256 \end{cases}

OMCI-based authentication

This is one of the two mutual secure authentication mechanisms, now defined in ITU-T G.98815 (originated in ITU-T G.984.45 for GPON). The scheme assumes a Pre-Shared Key (PSK \def\pelican{\textrm{pelican}^2} PSK) has been provisioned on both the ONU and OLT beforehand.

A three-step challenge-based mutual authentication is used:

Three-step OMCI authentication

1. The OLT sends its list of supported MAC (Message Authentication Code) functions and OLT random challenge \def\pelican{\textrm{pelican}^2} OLT\ random\ challenge to the ONU.
2. Then, the ONU selects one of the supported OLT MAC functions, then sends the ONU random challenge \def\pelican{\textrm{pelican}^2} ONU\ random\ challenge and the following MAC to the OLT: MACFunction(PSK,(selected_cryptographic_capabilities&smidOLT random challenge&smidONU random challenge&smid(0x00)16)) \def\pelican{\textrm{pelican}^2} \text{MACFunction}(\text{PSK}, (selected\cryptographic\_capabilities|OLT\ random\ challenge|ONU\ random\ challenge|(0x00){16}))
3. Finally, OLT then sends a MAC to the ONU as well: MACFunction(PSK,(selected_cryptographic_capabilities&smidONU random challenge&smidOLT random challenge&smidONU Serial Number)) \def\pelican{\textrm{pelican}^2} \text{MACFunction}(\text{PSK}, (selected\_cryptographic\_capabilities|ONU\ random\ challenge|OLT\ random\ challenge|ONU\ Serial\ Number))

The OLT advertises its supported MACFunction \def\pelican{\textrm{pelican}^2} MACFunction in the "OLT crypto capabilities" attribute of the OMCI "Enhanced security control" Management Entity. Then, the ONU chooses one of these MACFunctions \def\pelican{\textrm{pelican}^2} MACFunctions and sets the "ONU selected crypto capabilities" attribute of the OMCI "Enhanced security control" Management Entity. It is then used as onu_selected_cryptographic_capabilities \def\pelican{\textrm{pelican}^2} \text{onu\_selected\_cryptographic\_capabilities}.

MACFunction \def\pelican{\textrm{pelican}^2} MACFunction is chosen from the following list:

• AES-CMAC-128 (default, must be supported).
• HMAC-SHA-256.
• HMAC-SHA-512.

Master Session Key derivation

Finally, the MSK \def\pelican{\textrm{pelican}^2} MSK is derived from the PSK \def\pelican{\textrm{pelican}^2} PSK and the challenges. The following formula is used when a 128-bit MSK \def\pelican{\textrm{pelican}^2} MSK is required, which is always the case for GPON, XG(S)-PON and NG-PON2:

OMCI-based 128-bit MSK \def\pelican{\textrm{pelican}^2} MSK derivation

MSK=MACFunction(PSK,(OLT random challenge&smidONU random challenge)), take the 128 most significant bits. \def\pelican{\textrm{pelican}^2} \text{MSK} = \text{MACFunction}(\text{PSK}, (OLT\ random\ challenge | ONU\ random\ challenge))\text{, take the 128 most significant bits.}

However, 50G-PON also supports 256-bit MSKs. When combining the ITU-T G.988 (OMCI)15 and ITU-T G.9804.2 (50G-PON)17 specifications, it is unclear how MSK \def\pelican{\textrm{pelican}^2} MSK should be derived in this situation. ITU-T G.9804.2 also defers to ITU-T G.987.39 for OMCI authentication.

When MACFunction=AES-CMAC-128 \def\pelican{\textrm{pelican}^2} \text{MACFunction}=\text{AES-CMAC-128}, the equation is clear:

OMCI-based 50G-PON 256-bit MSK derivation for MACFunction=AES-CMAC-128 \def\pelican{\textrm{pelican}^2} \text{MACFunction}=\text{AES-CMAC-128}

MSK=AES-128-ECMAC&af(PSK,(OLT random challenge&smidONU random challenge),256) \def\pelican{\textrm{pelican}^2} \text{MSK} = \operatorname{AES-128\text{-}ECMAC}\left(\text{PSK}, (OLT\ random\ challenge | ONU\ random\ challenge), 256\right)

where
AES-128-ECMAC&af(K,M,Tlen)={AES-128-CMAC&af(K,M,Tlen),Tlen≤128AES-128-CMAC&af(K,MlessLastBlock,128)&smidAES-128-CMAC&af(K,M,128),Tlen=256 \def\pelican{\textrm{pelican}^2} \operatorname{AES-128\text{-}ECMAC}(K, M, Tlen) = \begin{cases} \operatorname{AES-128-CMAC}(K, M, Tlen), & Tlen \leq 128 \\[4pt] \operatorname{AES-128-CMAC}\left(K, M_{\text{lessLastBlock}}, 128\right) | \operatorname{AES-128-CMAC}(K, M, 128), & Tlen = 256 \end{cases}

When MACFunction=HMAC-SHA-256 \def\pelican{\textrm{pelican}^2} \text{MACFunction}=\text{HMAC-SHA-256} or MACFunction=HMAC-SHA-512 \def\pelican{\textrm{pelican}^2} \text{MACFunction}=\text{HMAC-SHA-512} are used, the specifications imply one of two things:

• Following ITU-T G.9804.2 Annex C "Secure mutual authentication", the output of MACFunction \def\pelican{\textrm{pelican}^2} \text{MACFunction} is truncated to 256 bits, as HMAC-SHA-256 \def\pelican{\textrm{pelican}^2} \text{HMAC-SHA-256} generates a 256-bit value and HMAC-SHA-512 \def\pelican{\textrm{pelican}^2} \text{HMAC-SHA-512} a 512-bit value.
• ITU-T G.988 requires MSK \def\pelican{\textrm{pelican}^2} MSK to be truncated to 128 bits. According to ITU-T G.9804.2 clause 9.13, MSK \def\pelican{\textrm{pelican}^2} MSK must be extended to 256 bits using the same process as the "OMCI-based 50G-PON 256-bit MSK derivation for MACFunction=AES-CMAC-128 \def\pelican{\textrm{pelican}^2} \text{MACFunction}=\text{AES-CMAC-128}" equation above.

The key contradictory quotes are available in Annex C: Contradictory specification quotes relative to the derivation of a 256-bit MSK \def\pelican{\textrm{pelican}^2} MSK for HMACs with an output size of 256-bit or more.

As both the ONU and OLT must derive the same MSK \def\pelican{\textrm{pelican}^2} MSK, a manufacturer testing this specific case with different ONUs or OLTs would notice any implementation mismatch. A clarification of the specification would make clear what is actually implemented, but all manufacturers should have the same implementation eventually. As 50G-PON is not widely deployed, they might not have faced this choice yet, especially with these specific MACFunctions \def\pelican{\textrm{pelican}^2} \text{MACFunctions}.

IEEE 802.1X-based authentication

This is the second mutual secure authentication mechanism, only available in XG(S)-PON, NG-PON2 and 50G-PON. Its implementation is mostly detailed in Annex D of ITU-T G.987.39.

IEEE 802.1X supports many authentication methods through the Extensible Authentication Protocol (EAP)23. EAP- GPSK24 which is based around a pre-shared key, must be supported according to ITU-T G.987.39. EAP- TLS25 is also mentioned in the specification and allows the use of public-key cryptography. Any EAP method that supports mutual authentication and the generation of a secret MSKEAP \def\pelican{\textrm{pelican}^2} MSK_{EAP} can be used.

RFC 374823 mentions that the MSKEAP \def\pelican{\textrm{pelican}^2} MSK_{EAP} generated must be at least 64 bytes long, however we need only 16 bytes or 32 bytes (50G-PON only).

IEEE 802.1X-based MSK derivation

Let TMSK \def\pelican{\textrm{pelican}^2} T_{MSK} be the required MSKPON \def\pelican{\textrm{pelican}^2} MSK_{PON} size in bits. MSKPON \def\pelican{\textrm{pelican}^2} MSK_{PON} is derived from MSKEAP \def\pelican{\textrm{pelican}^2} MSK_{EAP} as follows:

MSKPON=TMSK most significant bits of MSKEAP \def\pelican{\textrm{pelican}^2} MSK_{PON} = T_{MSK}\text{ most significant bits of } MSK_{EAP}

A note on Forward Secrecy

Only one authentication scheme, the IEEE 802.1X-based scheme with the right EAP (EAP-TLS with a Diffie-Hellman key exchange for instance), might lead to an encrypted session that provides perfect forward secrecy. For the other schemes, the leak of the Registration_ID or PSK would enable attackers to decrypt the signal in harvest now, decrypt later attacks. The encrypted data encryption key contained in the PLOAM messages could be decrypted, and then the payloads of the XGEM frames.

Key Derivation

MSK \def\pelican{\textrm{pelican}^2} MSK and its derived keys have three purposes: encrypting the data encryption key (using the MSK \def\pelican{\textrm{pelican}^2} MSK for GPON or the Key Encryption Key (KEK \def\pelican{\textrm{pelican}^2} KEK) otherwise), authenticating PLOAM messages and authenticating OMCI messages (XG-PON and above only).

Key derivation decision diagram

Note that the typos and wordplays in the strings match the actual values used by the specifications, as specific string lengths were required.

XG(S)-PON and NG-PON2 derivations

SK=AES-128-CMAC(MSK,(SN&smidPON-TAG&smid"SessionK")) \def\pelican{\textrm{pelican}^2} SK = \text{AES-128-CMAC}(MSK, (\text{SN}|\text{PON-TAG}|\text{"SessionK"})) OMCI_IK=AES-128-CMAC(SK,"OMCIIntegrityKey") \def\pelican{\textrm{pelican}^2} OMCI\_IK = \text{AES-128-CMAC}(SK, \text{"OMCIIntegrityKey"}) PLOAM_IK=AES-128-CMAC(SK,"PLOAMIntegrtyKey") \def\pelican{\textrm{pelican}^2} PLOAM\_IK = \text{AES-128-CMAC}(SK, \text{"PLOAMIntegrtyKey"}) KEK=AES-128-CMAC(SK,"KeyEncryptionKey") \def\pelican{\textrm{pelican}^2} KEK = \text{AES-128-CMAC}(SK, \text{"KeyEncryptionKey"})

50G-PON derivations

Let:

• K \def\pelican{\textrm{pelican}^2} K be the key used in the BC-ECMAC definition.
• M \def\pelican{\textrm{pelican}^2} M be the input message used in the BC-ECMAC definition.
• Tlen \def\pelican{\textrm{pelican}^2} Tlen be the requested MAC output length in bits.
• BC \def\pelican{\textrm{pelican}^2} BC be the chosen Block Cipher.
• MlessLastBlock \def\pelican{\textrm{pelican}^2} M_{\text{lessLastBlock}} be M \def\pelican{\textrm{pelican}^2} M with its final 16 octets removed.

SK=BC-ECMAC(MSK,(SN&smidPON-TAG&smidPON-TAG&smidSN),Tlen) \def\pelican{\textrm{pelican}^2} SK = \text{BC-ECMAC}(MSK, (SN|\text{PON-TAG}|\text{PON-TAG}|SN), Tlen) OMCI_IK=BC-ECMAC(SK, "OMCIIntegrityKeyMakeOMCImoreSafe",Tlen) \def\pelican{\textrm{pelican}^2} OMCI\IK = \text{BC-ECMAC}(SK, \text{ "OMCIIntegrityKeyMakeOMCImoreSafe"}, Tlen) PLOAM_IK=AES-128-CMAC(SK16 least significant bytes,"PLOAMIntegrtyKey") \def\pelican{\textrm{pelican}^2} PLOAM\_IK = \text{AES-128-CMAC}(SK\text{16 least significant bytes}, \text{"PLOAMIntegrtyKey"}) KEK=BC-ECMAC(SK,"KeyEncryptionKeyMakeKEKMoreSafey",Tlen) \def\pelican{\textrm{pelican}^2} KEK = \text{BC-ECMAC}(SK, \text{"KeyEncryptionKeyMakeKEKMoreSafey"}, Tlen) where BC-ECMAC&af(K,M,Tlen)={BC-CMAC&af(K,M,Tlen),Tlen≤128BC-CMAC&af(K,MlessLastBlock,128)&smidBC-CMAC&af(K,M,128),Tlen=256 \def\pelican{\textrm{pelican}^2} \operatorname{BC\text{-}ECMAC}(K, M, Tlen) = \begin{cases} \operatorname{BC-CMAC}(K, M, Tlen), & Tlen \leq 128 \\[4pt] \operatorname{BC-CMAC}\left(K, M_{\text{lessLastBlock}}, 128\right) | \operatorname{BC-CMAC}(K, M, 128), & Tlen = 256 \end{cases}

For GPON, the data encryption key is only sent encrypted when the OMCI authentication is used; otherwise it is sent in clear form. The key is always sent encrypted in XG(S)-PON, NG-PON2 and 50G-PON, using the KEK \def\pelican{\textrm{pelican}^2} KEK key derived from the MSK.

The other two keys derived from the MSK in XG(S)-PON, NG-PON2 and 50G-PON are used for the authentication of OMCI and PLOAM messages, so only OMCI and PLOAM have authenticity checks, not the main payload. GPON does not have such a mechanism.

Authentication of PLOAM and OMCI messages

Only XG(S)-PON, NG-PON2 and 50G-PON authenticate the PLOAM and OMCI messages; GPON does not. Authentication ensures the messages have been sent by the right peer and that they have not been tampered with.

The PLOAM and OMCI Message Integrity Check (MIC) values are derived the following way:

PLOAM and OMCI MIC calculation

PLOAM-MIC=AES-128-CMAC(PLOAM_IK,(Cdir&smidPLOAM_CONTENT),64) \def\pelican{\textrm{pelican}^2} \text{PLOAM-MIC} = \text{AES-128-CMAC} (\text{PLOAM\IK}, (C{dir} | \text{PLOAM\_CONTENT}), 64)

OMCI-MIC=BC-CMAC(OMCI_IK,(Cdir&smidOMCI_CONTENT),32) \def\pelican{\textrm{pelican}^2} \text{OMCI-MIC} = \text{BC-CMAC} (\text{OMCI\IK}, (C{dir} | \text{OMCI\CONTENT}), 32)
where Cdir=0x01 \def\pelican{\textrm{pelican}^2} C{dir} = 0x01 for downstream and Cdir=0x02 \def\pelican{\textrm{pelican}^2} C_{dir} = 0x02 for upstream.

and

BC-CMAC \def\pelican{\textrm{pelican}^2} \text{BC-CMAC} is AES-128-CMAC \def\pelican{\textrm{pelican}^2} \text{AES-128-CMAC} for XG(S)-PON and NG- PON2. For 50G-PON, the chosen block cipher used across data encryption, key derivation and message integrity checks is used for OMCI. This allows 50G-PON to use stronger keys (256-bit). PLOAM, however, always uses AES-128-CMAC \def\pelican{\textrm{pelican}^2} \text{AES-128-CMAC}.

PLOAM and OMCI authentication is always enabled; however, before any MSK has been derived a default key is used for PLOAM: 0x5516 \def\pelican{\textrm{pelican}^2} 0x55_{16}. The default key is always used for downstream broadcast PLOAM messages, as well as some unicast PLOAM messages such as the Serial_Number_ONU , Deactivate_ONU-ID , Request_Registration and Registration PLOAM messages. After that, the keys derived from the MSK established from the Registration_ID are used, and finally the keys derived from any new MSK established from one of the authentication mechanisms.

Generating the data encryption keys

There are two types of data encryption keys: unicast and multicast (broadcast). In the previous sections, we only mentioned which keys are used to encrypt the unicast data encryption key; not how it is generated.

The unicast data encryption key used in the GPON, XG(S)-PON and NG-PON2 specifications is generated by each ONU, not the OLT.

GPON, XG-PON and NG-PON2 data encryption key generation

EncryptionKey=ONU-generated random generated value of size 128 bits \def\pelican{\textrm{pelican}^2} EncryptionKey = \text{ONU-generated random generated value of size 128 bits}

A secure random number generator must be used.

Moreover, if the key is not generated properly, all the authentication and key encryption will not matter as the attacker could bruteforce the data encryption key. Thus, according to the XG(S)-PON and NG-PON2 specifications, "the ONU generates a new encryption key using a random number generator suitable for cryptographic purposes"14. The GPON specification has a similar mention "The ONU should generate a cryptographically unpredictable key."4.

As for 50G-PON, the unicast data encryption key is now derived from both an OLT and an ONU random number, instead of being taken directly from the random number generator output:

50G-PON data encryption key generation

Let:

• KEK \def\pelican{\textrm{pelican}^2} \text{KEK} be the Key Encryption Key derived from MSK \def\pelican{\textrm{pelican}^2} MSK.
• BC \def\pelican{\textrm{pelican}^2} \text{BC} be the chosen Block Cipher.
• Tlen \def\pelican{\textrm{pelican}^2} \text{Tlen} be the BC \def\pelican{\textrm{pelican}^2} \text{BC} key size.
• KeyControl_RandomX \def\pelican{\textrm{pelican}^2} \text{KeyControl\_RandomX} and KeyControl_RandomX \def\pelican{\textrm{pelican}^2} \text{KeyControl\_RandomX} be values sent to the ONU through PLOAM by the OLT.
• BC-ECMAC \def\pelican{\textrm{pelican}^2} \text{BC-ECMAC} as previously defined.
• BC-ECB \def\pelican{\textrm{pelican}^2} \text{BC-ECB} be BC \def\pelican{\textrm{pelican}^2} \text{BC} with the ECB cipher mode.

EncryptionKey=BC-ECMAC(KEK,ONUKeyContrib&smidOLTKeyContrib,Tlen) \def\pelican{\textrm{pelican}^2} EncryptionKey = \text{BC-ECMAC}(KEK, \text{ONUKeyContrib}|\text{OLTKeyContrib}, Tlen)

where

OLTKeyContrib={BC-ECB&af(KEK,KeyControl_RandomX),Tlen=128BC- ECB&af(KEK,KeyControl_RandomX|KeyControl_RandomY),Tlen=256 \def\pelican{\textrm{pelican}^2} \text{OLTKeyContrib} = \begin{cases} \operatorname{BC-ECB}(KEK, \text{KeyControl\_RandomX}), & Tlen=128 \\[4pt] \operatorname{BC-ECB}(KEK, \text{KeyControl\_RandomX|KeyControl\_RandomY}), & Tlen=256 \end{cases}

and

ONUKeyContrib=ONU-generated random generated value of size Tlen \def\pelican{\textrm{pelican}^2} \text{ONUKeyContrib} = \text{ONU-generated random generated value of size Tlen}
A secure random number generator must be used.

However, the key is still generated on the ONU side, sent encrypted to the OLT and used as-is. Thus, it seems that the ONU can still hardcode a key or ignore the OLT's contribution, and is responsible for the key strength more generally. But the ONU can now use the OLT entropy pool to increase the data encryption key strength.

Finally, for XG-PON and above, the data encryption key is sent encrypted to the OLT, using the chosen block cipher in ECB mode and KEK \def\pelican{\textrm{pelican}^2} KEK as key. For GPON, MSK \def\pelican{\textrm{pelican}^2} MSK is used instead of KEK \def\pelican{\textrm{pelican}^2} KEK, and encryption of the data encryption key not mandatory.

Encryption of the data encryption key

For GPON Encrypted EncryptionKey=AES-128-ECB&af(MSK,Encryption Key), \def\pelican{\textrm{pelican}^2} \text{Encrypted EncryptionKey} = \operatorname{AES-128-ECB}(MSK, \text{Encryption Key}),

For XG-PON and above Encrypted EncryptionKey=BC-ECB&af(KEK,Encryption Key), \def\pelican{\textrm{pelican}^2} \text{Encrypted EncryptionKey} = \operatorname{BC-ECB}(KEK, \text{Encryption Key}),
where BC=AES−128 \def\pelican{\textrm{pelican}^2} BC = AES-128 for XG(S)-PON and NG-PON2.

XG(S)-PON, NG-PON2 and 50G-PON also allow the use of a multicast data encryption key which is generated on the OLT and allows a frame to be encrypted once so that it can be decrypted by multiple ONUs.

Enabling encryption

Encryption is mostly disabled by default for all PON versions.

For GPON, the encryption of a GEM port is activated through PLOAM, and only the downstream frames are encrypted. For XG-PON and above, the default XGEM port which is used for OMCI is always set for bidirectional unicast encryption, other XGEM ports must be provisioned (unicast/multicast, direction of the encryption, etc). However, the encryption of the frame is still enabled by the Key_index field in the frame header, although the XG-PON specification does mention that it must be done "within the explicitly configured or pre-defined capabilities of the associated XGEM port".

Enabling encryption decision diagram

For the encryption of the OMCI messages (on the OMCC channel), no OMCI Management Entity needs to be configured. For XG-PON and above, ITU-T G.98815 mentions that "If the GEM frame itself contains an encryption key index, it is understood to refer to the unicast key and to require encryption both up- and downstream." and the XG(S)-PON and above specifications say "Whenever the default XGEM port traffic is encrypted in the downstream direction, the ONU is expected to encrypt the default XGEM port traffic upstream". One interpretation of that last quote could imply that an unencrypted frame can be sent to the default (OMCI) XGEM port, which slightly contradicts the ITU-T G.988 specification.

Implementers should make sure that the Key_index value of a specific frame matches the configuration of the XGEM port.

PLOAM messages and OMCI Management Entities relevant to security features

There are a few PLOAM messages and OMCI Management Entities related to security features that are scattered in the specifications. Annex B: PLOAM and OMCI security-related messages can be used as a reference and might be useful for the next section.

Encrypted communications

Finally! We've identified the ONU, passed the authentication process, established an MSK , derived the keys, generated a random data encryption key and sent it encrypted to the OLT, we've enabled the encryption on the (X)GEM port, set the right fields in the (X)GEM header, authenticated the OMCI and PLOAM messages (unless GPON), and at last we can send our encrypted message!

Block cipher and CTR mode

First of all, only the payload of the X(GEM) frame is encrypted, not the X(GEM) header.

The default encryption method is AES-128-CTR (AES-128 with the counter mode of operation specified in NIST SP 800-38A22) and it must be supported by both the ONU and the OLT. In addition to AES-128, 50G-PON (ITU-T G.9804.217) must also support AES-256. However, for 50G-PON, the OMCI "ONU2-G" Management Entity can advertise and enable support for other block ciphers: Camellia-128, Camellia-256 and SM4-128.

While technically, the NIST SP 800-38A22 "assumes that a FIPS-approved symmetric key block cipher algorithm has been chosen as the underlying algorithm", and Camellia and SM4 are not NIST- approved, the same counter mode is used for all block ciphers.

Even though CTR is a strong encryption mode, it does not provide authentication, which means an attacker can blindly modify the encrypted payload. Other protocols such as TLS 1.3 use AEAD (Authenticated encryption with additional data) modes to provide both encryption and authentication of the main payload, as well as authentication of additional data that must stay visible (a header for instance).

The Counter

The counter is reset at the start of each (X)GEM frame, and its initial value is called Initial Counter Block in XG-PON and later but this designation works for GPON as well. It is then increased by one after each 16-byte block inside the (X)GEM frame.

The Initial Counter Block is a function of the SFC which is sent by the OLT and the Intraframe counter (IFC). The IFC is reset to 0 at the start of each FS frame, increased every 4 bytes for GPON and every 16 bytes for XG-PON and later. The IFC value used in the Initial Counter Block calculation is the IFC value at the first byte of the GEM header for GPON, and at the position of the first four bytes for XG-PON and later (XGEM frames are aligned on a 4-byte boundary).

The figures below represent the SFC , IFC and how (X)GEM frames are encrypted for downstream GPON and XG-PON (and above).

Encryption of a downstream (GPON) GEM frame

Encryption of a downstream XGEM frame

Duplicated counter blocks

The XG-PON specification and above mention two SFC values which lead to duplicated counter blocks in both directions:

• For XG(S)-PON and NG-PON2: SFC(49..0)=0b1(0)49 \def\pelican{\textrm{pelican}^2} SFC(49..0)=0b1(0){49} and SFC(49..0)=0b0(1)49 \def\pelican{\textrm{pelican}^2} SFC(49..0)=0b0(1){49}. According to the specifications, the duplicated counter blocks appear for 250μs once every 4000 years. SFC(49..0) \def\pelican{\textrm{pelican}^2} SFC(49..0) is used, as one of the 51 bits of SFC is dropped before the counter calculation.
• For HSP/50G-PON: SFC(47..0)=0b1(0)47 \def\pelican{\textrm{pelican}^2} SFC(47..0)=0b1(0){47} and SFC(47..0)=0b0(1)47 \def\pelican{\textrm{pelican}^2} SFC(47..0)=0b0(1){47}. According to the specification, the duplicated counter blocks appear for 100μs once every 1000 years. SFC(47..0) \def\pelican{\textrm{pelican}^2} SFC(47..0) is used, as three of the 51 bits of SFC are dropped before the counter calculation.

where SFC(x..y) \def\pelican{\textrm{pelican}^2} SFC(x..y) represents SFC \def\pelican{\textrm{pelican}^2} SFC's bits x to y (included) in that order.

To mitigate this issue, the specifications recommend initialising SFC to a small value.

As for the upstream payloads, GPON does not encrypt them. For XG-PON and above, upstream frames can be encrypted, when they are the operation is very similar to the encryption of downstream frames.

The main difference is how IFC is calculated: instead of starting at 0 \def\pelican{\textrm{pelican}^2} 0, IFC starts with a value derived from the StartTime at which the upstream burst is sent. This way, IFC is unique for each Alloc-ID.

Reduced data encryption strength: why?

All the ITU-T PON specifications discussed specify the use of data encryption keys with "reduced effective length".

Instead of generating a 128-bit encryption key, an ONU may generate a key of size Leff \def\pelican{\textrm{pelican}^2} L_{eff} bits where Leff \def\pelican{\textrm{pelican}^2} L_{eff} is a multiple of 8, filling the remaining most significant bytes with 0x55 \def\pelican{\textrm{pelican}^2} 0x55.

Leff \def\pelican{\textrm{pelican}^2} L_{eff} can be reported through the OMCI "Enhanced security control" Management Entity and the "Effective key length" attribute, but it is optional.

While this provision was probably in place to support older devices, it is odd that it is still present in newer specifications that require more capable devices.

Bringing it all together: ONU initialisation and key switching

While we have all the bricks to authenticate and encrypt secure channels between ONUs and OLTs, timing is important: some authentication methods are not available right away, keys are renewed regularly (key switching) or must transition from one authentication method to another, etc.

The diagram below presents the key events of an XG-PON ONU from power-up to the establishment of a secure data channel, highlighting the transitions between authentication schemes. Note that this is a "happy path" scenario; it is designed to demonstrate the integration of the security mechanisms discussed in this post rather than provide an exhaustive state-machine analysis of the full specification.

On the left of the diagram are represented the approximate ONU and key management states that are used in state-machines in the specification; not all events are displayed and some are simplified.

XG-PON timeline for power-up to secure channel

The data encryption key should be regularly regenerated by the ONU on the OLT's request; however, the renewal frequency is at the OLT's discretion.

During key renewal, all PON specifications implement measures to ensure only valid keys are used and the link is not left broken. For GPON, the OLT simply sends a superframe counter value to the ONU, at which the new key will be used. For XG-PON and above, the process is more complex and involves timers and state machines. While the XG-PON and later specifications mention two ONU timers (the "ONU key exchange waiting timer" and "Key Ack waiting timer"), the ITU-T Supplement 8120 deprecates them "the ONT-side timers are deprecated", leaving timeout management to the OLT.

Conclusion

ITU-T PON specifications implement link-level encryption and authentication between OLTs and ONUs to protect against eavesdropping, data theft, and impersonation. However, there are many choices to make and steps to follow, and the specifications do not always have a "secure by default" approach.

GPON, as the oldest PON specification in this blog post, offers the most limited security: downstream-only encryption and optional OMCI-based authentication. Without OMCI authentication, unicast data encryption keys are transmitted unencrypted to the OLT.

XG-PON and newer PON specifications (XGS-PON, NG-PON2, 50G-PON) mandate authentication and support bidirectional encryption. However, the Registration ID-based scheme will use a default null string if not provisioned: while the resulting secure channel will be authenticated and encrypted, it will be based on a known secret, which defeats the purpose of the secure channel. Only the IEEE 801.2X-based scheme with the right EAP mode (such as EAP-TLS with a Diffie-Hellman key exchange) can support Perfect Forward Secrecy (PFS), preventing "harvest now, decrypt later" attacks.

For all PON versions, encryption is usually disabled by default. Only the OMCI XGEM port is always encrypted in both directions for XG-PON and above.

Then, a block cipher (usually AES-128) is used in CTR mode for the actual encryption of the (X)GEM payloads. The CTR mode does not provide authentication of the payload, which means an attacker can blindly modify the ciphertext without being detected. AEAD modes, which are the only modes supported by TLS 1.3 for instance, provide both encryption and authentication of the payload simultaneously.

A somewhat new evolution in the PON specifications is the support of 256-bit block ciphers by the Higher Speed PON (HSP)/50G-PON specifications. 50G-PON now mandates the support of 256-bit keys, and generalises the use of ciphers of this key size. While we do not make any conclusions on the specifications' resilience against quantum cryptography, 256-bit AES keys are recommended by multiple agencies' post-quantum cryptography notes2627 as a measure against Grover's algorithm. ITU-T Supplement 8120 recommends using HMAC-SHA-256 in the OMCI-based authentication scheme for quantum-resistance.

50G-PON also changes how the unicast data encryption key is generated by including an OLT-generated value. However, the key is still generated on the ONU's side and sent to the OLT, unlike a Diffie-Hellman key exchange for instance, where the shared secret is at least guaranteed to include each sides' secret.

Moreover, 50G-PON still includes a section relative to "reduced data encryption strength", which has carried on across PON specifications since GPON. It is unclear why such a provision is still necessary when 256-bit keys have been introduced.

Finally, while we did go through a lot of PON security threats and features, there are other concerns that we did not discuss. The ITU-T specifications and supplements also mention "rogue ONUs", ONUs that do not behave according to the specification, and how to protect against them. Cloned ONUs, attacks against OMCI Management Entities, are other subjects we did not tackle.

Acknowledgments

I would like to thank my colleagues Angele Bossuat and Celian Glenaz for their review, as well as all other reviewers of this blog post!

Further reading

• Annex A: Glossary

• Annex B: PLOAM and OMCI security-related messages

• Annex C: Contradictory specification quotes relative to the derivation of a 256-bit MSK \def\pelican{\textrm{pelican}^2} MSK for HMACs with an output size of 256-bit or more

References

---

1. R. Rousseau, "Avec le 50G-PON, Orange propose une experience inedite en France et demontre la prouesse de la fibre du futur," Newsroom Groupe Orange. Available: https://newsroom.orange.com/?p=60059. &larrhk

2. ITU-T G.984.1 (03/2008) - Gigabit-capable passive optical networks (GPON): General characteristics &larrhk

3. ITU-T G.984.2 (08/2019) - Gigabit-capable Passive Optical Networks (G-PON): Physical Media Dependent (PMD) layer specification &larrhk

4. ITU-T G.984.3 (2014) Amd. 2 (11/2025) - Gigabit-capable passive optical networks (G-PON): Transmission convergence layer specification &larrhk&larrhk&larrhk

5. ITU-T G.984.4 (02/2008) - Gigabit-capable passive optical networks (G-PON): ONT management and control interface specification &larrhk

6. ITU-T G.987 (06/2012) - 10-Gigabit-capable passive optical network (XG-PON) systems: Definitions, abbreviations and acronyms &larrhk

7. ITU-T G.987.1 (2016) Cor. 1 (03/2020) - 10-Gigabit-capable passive optical networks (XG-PON): General requirements &larrhk

8. ITU-T G.987.2 (2023) Amd. 1 (06/2023) - 10-Gigabit-capable passive optical networks (XG-PON): Physical media dependent (PMD) layer specification &larrhk

9. ITU-T G.987.3 (05/2025) - 10-Gigabit-capable passive optical networks (XG-PON): Transmission convergence (TC) layer specification &larrhk&larrhk&larrhk&larrhk&larrhk&larrhk&larrhk

10. ITU-T G.9807.1 (2023) Amd. 1 (05/2025) - 10-Gigabit-capable symmetric passive optical network (XGS-PON) &larrhk&larrhk

11. ITU-T G.989 (10/2015) - 40-Gigabit-capable passive optical networks (NG-PON2): Definitions, abbreviations and acronyms &larrhk

12. ITU-T G.989.1 (03/2013) - 40-Gigabit-capable passive optical networks (NG-PON2): General requirements &larrhk

13. ITU-T G.989.2 (2019) Amd. 1 (10/2020) - 40-Gigabit-capable passive optical networks 2 (NG-PON2): Physical media dependent (PMD) layer specification &larrhk

14. ITU-T G.989.3 (2021) Amd. 2 (05/2025) - 40-Gigabit-capable passive optical networks (NG-PON2): Transmission convergence layer specification &larrhk&larrhk&larrhk&larrhk

15. ITU-T G.988 (2022) Amd. 2 (05/2025) - ONU management and control interface (OMCI) specification &larrhk&larrhk&larrhk&larrhk

16. ITU-T G.9804.1 (2019) Amd. 3 (05/2025): Higher speed passive optical networks - Requirements &larrhk

17. ITU-T G.9804.2 (2021) Amd. 3 (11/2025): Higher speed passive optical networks - Common transmission convergence layer specification &larrhk&larrhk&larrhk&larrhk&larrhk

18. ITU-T G.9804.3 (2021) Amd. 3 (02/2026): 50-Gigabit-capable passive optical networks (50G-PON): Physical media dependent (PMD) layer specification &larrhk

19. ITU-T G.9805 (2022) Amd. 2 (11/2025) : Coexistence of passive optical network systems &larrhk

20. G Suppl. 81 (ex G Suppl.PONsec) - Practical aspects of PON security - Revision 1 &larrhk&larrhk&larrhk

21. "GPON - OMCI MIB [O3 Labs]." Available: https://www.tripleoxygen.net/wiki/misc/gpon/omci-mib#privados &larrhk

22. M. J. Dworkin, "Recommendation for block cipher modes of operation : methods and techniques," National Institute of Standards and Technology, Gaithersburg, MD, NIST SP 800-38a, 2001. doi: 10.6028/NIST.SP.800-38a. &larrhk&larrhk

23. J. Vollbrecht, J. D. Carlson, L. Blunk, B. D. Aboba, and H. Levkowetz, "Extensible Authentication Protocol (EAP)," Internet Engineering Task Force, Request for Comments RFC 3748, Jun. 2004. doi: 10.17487/RFC3748. &larrhk&larrhk

24. C. Clancy and H. Tschofenig, "Extensible Authentication Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method," Internet Engineering Task Force, Request for Comments RFC 5433, Feb. 2009. doi: 10.17487/RFC5433. &larrhk

25. D. Simon, R. Hurst, and B. D. Aboba, "The EAP-TLS Authentication Protocol," Internet Engineering Task Force, Request for Comments RFC 5216, Mar. 2008. doi: 10.17487/RFC5216. &larrhk

26. "ANSSI views on the Post-Quantum Cryptography transition". Available: https://messervices.cyber.gouv.fr/guides/en-anssi-views-post-quantum-cryptography-transition &larrhk

27. "Post-Quantum Cryptography: Current state and quantum mitigation | ENISA.". Available: https://www.enisa.europa.eu/publications/post-quantum-cryptography-current-state-and-quantum-mitigation &larrhk

Earlier this week I caught myself copy/pasting code between two agents.

I don’t want to be a meat proxy, but it really was going to be best if they just…talked to each other. And yet it was weirdly hard to arrange that.

So I summoned Mayfly Chat.

There’s not much to it. It provides transient chat channels for agents. You click “New Channel” and then give the URL to your agents, and then they can chat there. You can watch or chime in if you want.

Use Cases

The instant I had my first prototype up I suddenly had a dozen use cases.

For example, on one of my systems, I had an agent rearranging some dotfiles and doing some configuration, and I wanted the same thing to be replicated on another of my computers, which had a somewhat different base configuration. Instead of having to figure out how to systematize it, which was really not worth the time, I started a new agent on the second machine and asked the first agent to guide it on what the new configuration should look like. Communicating over Mayfly Chat, the two agents worked together to adapt the setup to the shape of the second machine in a way that would have been pretty tedious to do through scripting.

Later, I found that some code that I had developed on one machine needed specialized access to a service conveniently available from a VM. No problem. Spin up a second agent on the VM, get them both in a chat, give them both their brief, and let them work it out together.

It's like having a subagent, only the subagent runs anywhere you like.

Mayfly Chat supports having a large number of participants. Farming out a task to a little swarm? Ensure they all have the channel URL up front, and watch them sort it out together.

Yet another use case: I started an agent on a little server in my house but had to step away from my LAN. I wanted to keep communicating with it from my phone, so I set up a channel and used that.

Yes, most of these use cases would be obviated by better planning. Sounds nice. But also…hahahahahahaha.

Oh, and of course, agents can create Mayfly Chat channels too. What could go wrong.

Security

The hardest design aspect was the security and privacy model. My initial prototype sent everything in cleartext with simple curl commands.

It was easy to use and easy to explain, and it just worked. And if you completely control all access to the server, that's fine. But I wanted to be able to stand this up as a public service for folks who wanted to kick the tires or just plain didn't want to run their own.

I didn't want anybody else's readable data anywhere near my VM, which meant end-to-end encryption was a hard requirement.

Of course, end-to-end encryption requires that the client actually do some real work, not just send a curl command. And I wanted using Mayfly Chat to involve no setup for the human and no thick client libraries. The whole point was to be lightweight.

The solution: Hand the agents a small script that they could use to do the end-to-end encryption. This should terrify you. Wait, you say. Your server is going to solve its security problem by handing out code to my agents? Yes. Yes it is.

There is already a variant of this problem with any browser-based end-to-end encryption. The server serves you the JavaScript that you feed your data into, and the server can just send you different JavaScript. Our world fundamentally runs on trust, and anyone who says otherwise is trying to sell you cryptocurrencies.

(Remember: end-to-end encryption here is solving my problem of not wanting to have your data. To solve your problem, namely having to trust the server, you can and should run your own. It is open source! I made it intentionally easy to deploy. You might even choose to deploy it on exe.dev. But failing that, you may also decide to just trust me.)

The alternative to these scripts was to describe the protocol in detail and make every single agent re-implement their own client. For something that is supposed to be speedy and disposable, that was going to be too slow and token- hungry.

So I selected an end-to-end encryption scheme that was as small and lightweight as possible, so that the actual scripts are extremely auditable, including by the agents grabbing them. Will the agents actually audit it? I dunno, probably not. But in principle they should be able to readily spin off a subagent, glance at a very moderate amount of mundane code, and convince themselves readily that it is not malicious and does exactly what it says on the tin.

This requirement precluded fancier forms of encryption like, say, the Signal protocol. I'm still not super happy about it, but between the Scylla of clear text and the Charybdis of client support, I will take the client support. I had hoped that there were existing widely distributed unix tools that could be chained together to accomplish what I wanted, but I couldn't find any. (If you know of some, please let me know, and I will happily retrofit them in!)

Another tricky question was permissions boundaries. For example, if an agent joins the conversation late, should it be able to see the history of all the messages to date or only the new ones? I eventually realized that it didn’t matter. Anyone who joins the conversation late can simply ask one of the agents to catch them up on everything that happened so far, and that agent will happily comply.

By far, the best thing to do in this scenario is to have a very simple, very honest mental model, which is: once you have the URL, you have root. Every client is equally privileged. Every client can read everything. It can post; it can lie about its identity; it can delete the thread. Anything else is theater, and this model is easy to reason about.

The last sticky point was metadata. It’s always metadata. And I basically punted. The server has metadata. And more than that, I made one conscious decision to store and forward client IP addresses. The server is in a unique position to have unspoofable knowledge of the IP address, unlike the data. By forwarding it along, if an agent suddenly has a different IP address, there is at least a little chance that one of the other agents might notice. And if you notice, you can at least assess, is that IP address a plausible one? On balance, I felt that the value to the user of the service warranted having the IP address stored in the clear alongside the other metadata.

I'm sure that other people would make different choices about security and privacy than I would. That's fine. Code is cheap now.

I have shared the idea with you. Go forth and make your own transient chat that matches your exact needs. Fork Mayfly Chat if you feel like, or start from scratch. And if you just want to use the hosted version https://mayfly.chat/, it's at your disposal.

Propaganda is one of those things which has obviously improved in its execution over time. In part this is due to higher levels of education among the populace. Educated people are used to stuffing facts in their brains, and continue the habit after the formal education has ended. This is what propaganda is: stuffing unverified […]

sync repo: +4 releases, -2 releases

## New releases
- [IDAssist](https://github.com/symgraph/idassist): 2.4.0
- [ida-nexus](https://github.com/hexrayssa/ida-nexus): 0.11.1
- [ida-settings-editor](https://github.com/williballenthin/ida-settings): 1.2.4
- [llm-explainer](https://github.com/pgarba/ida-llm-explainer): 1.14.0

## Changes
- [IDAssist](https://github.com/symgraph/idassist):
  - removed version(s): 1.3.0
- [ida-codemode](https://github.com/hexrayssa/ida-codemode):
  - removed version(s): 0.3.2

| it be like that submitted by /u/Every-Walrus
[link] [comments]
---|---

Disclaimer: no AI was used whatsoever to write this post

Cautionary tale about chasing cheap tokens.

exposé: https://kendell.dev/blog/crofaifalse/

reaction by nahcrof, announcing the shutdown of the service: https://x.com/nahcrof/status/2099552389434900643 - now deleted, archive picture: https://i.imgur.com/teOQngH.png

NahCrofAI (crof.ai, nahcrof.com) was an inference provider which had all the latest models at the cheapest price, often significantly below the lowest alternative on OpenRouter. The owner claimed that they are running custom inference engines that allows them to offer tokens for dirt cheap, and other providers are suffering from "skill issues", that's why they are so expensive.

In reality:

• "CrofAI is an OpenRouter wrapper that silently routes to cheaper or weaker models than what you request"

• For example, expensive models like kimi-k3 are sold at $2/$10 in/out, but instead routed to GLM 5.3 Flash via OpenRouter, representing a 13.3x multiple on input, and 20x multiple on output

• CrofAI's "own model family" greg-2-ultra routes to GLM 5.2, greg-1-mini routes to Qwen 3.5 9B. greg-2-super, greg-1, greg-1-super routes to Kimi K2.7 Code. All of these at a significant markup compared to the actual model being served. CrofAI admits in DMs that his claims of the greg family being made by him is a lie.

• The person investigating details the 5 different attempts by CrofAI at fixing their models being served via OpenRouter after given a heads-up and a lengthy grace period. In all 5 attempts, the only change CrofAI made was attempts to hide the fingerprints of OpenRouter, while still serving models through them

• Other inconsistencies don't add up either: CrofAI claims to run Kimi K3 on RTX Pro 6000s rented via Vast. That model requires ~802GiB even at the lobotomy level quantization of Q2_K. The largest RTX PRO 6000 machine on Vast has only 8 of them, totaling 765GiB. He also claimed that for the purposes of "investigating" the "issue" of his API routing to OpenRouter, he will have deepseek-v4-flash-0731 running on his local DGX Spark. A Spark has 128GB memory, and is therefore unable to run that model.

CrofAI responded to the exposé by announcing the shutting down of their service; after their failure to provide their own inference, they promise to provide one last thing: a refund to those asking.

UPDATE

UPDATE: around 4:30 AM UTC of Sept 15, the owner published a now-deleted blog post (archive image) writing under the fake pretense that it's his "team" authoring it, stating all of CrofAI founder's claims "were written under a lot of stress, and they described the situation as worse it was", and that a new team is taking over, with the service being resumed in 2 weeks.

At the same time, the CrofAI twitter account was also supposedly "taken over" by the team, starting each twitter reply with "Hey, Nathan here", stating the founder is stepping back and a "team" is taking over everything. This fake pretense act only lasted a few hours, and scared either by the public not buying the Nth fake story of the pathological liar that CrofAI is, or by the public's replies reminding him that what he committed is numerous counts of wire fraud, he has now deleted all his online presence: nahcrof.com and crof.ai return 404, Twitter page is deleted, /r/CrofAI sub is now private.

Here is another image of the owner admitting that he was defrauding customers for the entire 2 year operation of his service, then begging the investigator to help him cover his tracks and not expose him

EDIT: Commenters pointed out that NahCrof is 4chan in reverse. The owner's Discord name was "Devious Flimflam". Flimlam is defined as "deception, fraud". Looks like it was a deliberate scam operation from the get-go, and the owner's age was among the many lies.

I cannot stress this enough: if you bought any credits (even if you used them up) you are entitled to a full refund for every transaction as the victim of fraud. Open a chargeback with your bank for every transaction made. If you used their API, assume that everything was logged and is currently being mined for personal information and API keys to sell on the black markets. Rotate your keys, change passwords, get a new debit/credit card.

submitted by /u/SorosAhaverom
[link] [comments]

Summary

Library view

Recent Books has grown into a powerful way to browse your entire collection on your SD card. Sort by recently added, title, or author, and use search to instantly find exactly what you're looking for.

X4 Classic support

The new ESP32-S3-based X4 Classic is officially supported now.

The rest

List navigation is a bit snappier. SD reads are a bit faster. Sleep-screen transparency is more accurate. KOSync now sends more precise EPUB reading positions. EPUB lists, hidden content, chapter position display, and end-of- book navigation also received fixes. The release also reduces font and EPUB memory pressure, fixes USB drive disconnection, and improves web file-transfer safety.

---

What's Changed

• chore: update pioarduino to 55.03.311 by @serialx in #3397
• fix: Fixes KOSync memory checks and reduces memory pressure by @itsthisjustin in #3412
• fix: pack font manifest catalog into one arena by @fain182 in #3398
• docs(issue forms): Correct links to scope/roadmap by @cassidyjames in #3433
• fix(reader): synchronize end-of-book menu selection by @Daviex in #3418
• fix: render NFD Hangul filenames from macOS transfers by @serialx in #3036
• fix: reader's menu book chapter current position by @unnamedd in #3437
• fix: stabilize X3 EPUB anti-aliasing by @uxjulia in #3439
• fix(input): wake the idle poll on raw button contact so short presses register by @Techneaux in #3463
• feat: HTTP serve static with Cache-Control and ETag headers by @shirok1 in #2560
• chore: add direct download links for PR artifacts by @Uri-Tauber in #3389
• fix(webserver): normalize every user-supplied path and escape file names in the files page by @s0lness in #3353
• chore: Consolidates grayscale capability checks and enables absolute grayscale for supported screens by @itsthisjustin in #3478
• fix: don't display elements with hidden HTML attribute by @jjharpham in #3390
• fix(KOSync): compare mapped KOReader sync positions by @WhoTheHeck in #3111
• fix: update OTA to recognize the new format by @Uri-Tauber in #3493
• fix(debugging_monitor): if PSRAM is logged, add subplot by @olifre in #3490
• fix(KOSync): preserve precise KOSync upload progress positions by @WhoTheHeck in #3174
• refactor: reduce EPUB heap fragmentation with unique ownership by @serialx in #3518
• fix: reduce font-cache heap fragmentation by @serialx in #3521
• fix: release font caches before EPUB chapter layout by @serialx in #3527
• chore: add x4 Classic to CI pipelines by @Uri-Tauber in #3532
• docs: make roadmap easier to scan by @fain182 in #3517
• fix: number ordered lists and fix list container indents by @jan-xyz in #3500
• fix: dropped presses while a list repaints by @Techneaux in #3534
• perf: batch SdFat's SPI transfers on ESP32 by @osakanataro in #3501
• fix: USB OTG not disconnected when you unplug the cable by @itsthisjustin in #3538
• feat: Library view by @oreglio in #3366
• fix: Skip bw rendering on sleep images & fix white as transparent for sleep covers by @itsthisjustin in #3541

New Contributors

• @cassidyjames made their first contribution in #3433
• @Daviex made their first contribution in #3418
• @unnamedd made their first contribution in #3437
• @Techneaux made their first contribution in #3463
• @shirok1 made their first contribution in #2560
• @s0lness made their first contribution in #3353
• @jjharpham made their first contribution in #3390
• @olifre made their first contribution in #3490
• @osakanataro made their first contribution in #3501

Full Changelog : 1.6.0...1.6.5rc

🚀 Jellyfin Server 12.1

We are pleased to announce the latest stable release of Jellyfin, version 12.1! This minor release brings several bugfixes to improve your Jellyfin experience. As always, please ensure you take a full backup before upgrading!

Discuss this release further on our forums.

Changelog (47)

📈 General Changes

• Stop resolving items with every field where only stored columns are read [PR #18039], by @Shadowghost
• Fix nested unnumbered season folders collapsing onto the first one [PR #18044], by @Shadowghost
• Release a folder's children once its subtree has been scanned [PR #17884], by @Shadowghost
• Enforce channel mediasource id [PR #18037], by @Shadowghost
• Fix Norwegian ratings [PR #18017], by @theguymadmax
• Stop the library monitor from refreshing against a disposed host [PR #18020], by @Shadowghost
• Don't queue by-name items for playback and reject source requests for them [PR #17999], by @Shadowghost
• Fix forced-only not overriding remembered subtitles [PR #17998], by @Shadowghost
• Fix SyncPlay authentication error handling and limit group member wait time [PR #17938], by @Shadowghost
• Fix /UserViews exhausting memory and reporting random child counts [PR #17881], by @Shadowghost
• Fix device access revocation not logging out existing sessions [PR #18026], by @fmarcac
• Fix database optimization memory use and pre-migration backup integrity [PR #17836], by @Shadowghost
• Stop wrong-type alternate version cleanup from recursing [PR #18030], by @Shadowghost
• Fix incorrect color range during CSC after VK tonemapping [PR #18025], by @nyanmisaka
• Preserve active scans when requesting a background library refresh [PR #18006], by @orut34iop
• Clean up orphaned people when deleting items [PR #17897], by @nintwentydo
• Check Live TV access for a single user instead of enumerating all users [PR #18003], by @Shadowghost
• Fix slashed rating handling [PR #18002], by @Shadowghost
• Skip empty ZIP comments for ComicBookInfo [PR #17971], by @Shadowghost
• Fix EPG issues [PR #17935], by @Shadowghost
• Avoid full people scans and writes for unchanged credits [PR #18004], by @orut34iop
• Clean up invalid data before running migrations [PR #17835], by @Shadowghost
• Restore [JsonIgnore] on AggregateFolder.Children [PR #18011], by @Shadowghost
• Correct SyncPlay sessions that report playback at a stale position [PR #17797], by @fmarcac
• Don't let a torn-down WebSocket take down the request handler [PR #17958], by @Shadowghost
• Fix SimilarItemsManager concurrency [PR #17982], by @Shadowghost
• Delete the full ownership closure when deleting items [PR #17873], by @Shadowghost
• Fix versions of a video still listing separately from their group and preserve manual merges [PR #17842], by @Shadowghost
• Preserve library items when directory enumeration fails [PR #18007], by @orut34iop
• Don't resample or sharpen images Skia isn't actually resizing [PR #17956], by @Shadowghost
• Drop dead item data and fix query ordering and bound parameters [PR #17980], by @Shadowghost
• Stop requesting unused credits when looking up a TMDb person [PR #17973], by @Shadowghost
• Use thumbs for image tmdb image preview [PR #17924], by @enter-a-random-username
• Fix playlist encoding recognition [PR #17930], by @Shadowghost
• Populate missing tags array in Filters2 [PR #17898], by @Shadowghost
• Fix collection creation when the collections library was just added [PR #17950], by @Shadowghost
• Don't record a failed refresh as a completed one [PR #17947], by @Shadowghost
• Fix Italian ratings [PR #17933], by @Shadowghost
• Fix ContainsSubPath check [PR #17929], by @Shadowghost
• Fix trickplay using the wrong video stream [PR #17883], by @crobibero
• Fix metadata provider order needing a restart to apply [PR #17939], by @Shadowghost
• Fix decimal point handling in version names [PR #17931], by @Shadowghost
• Improve SeriesNameRegex [PR #17858], by @Shadowghost
• Report image resolutions for TMDb images when no image size is configured [PR #17859], by @Shadowghost
• Fix transcode throttling not enabling on supported systems (caused by race condition) [PR #17906], by @SimonvBez
• Only group episodes as versions on a confident path parse [PR #17890], by @Shadowghost
• Match parental ratings case-insensitively [PR #17844], by @Jellyfrog

Last September, the Servo project announced that long-time maintainer Josh Bowman-Matthews (@jdm) would work part-time on improving the Servo contributor experience, entirely funded by the monthly donations on OpenCollective and GitHub. In his own words, here is a look back over the past year!

---

First of all, I am enormously grateful to everyone who financially supports Servo, as those donations have enabled me to devote significant time to a project that I care a lot about. Some highlights from that funded work that I’m proud of:

• I nominated 8 newmaintainers
• I reviewed 1150 pull requests
• I filed 114 issues targeted at newer contributors (92% of them have been fixed)
• I wrote new documentation about borrow hazards, experimental features, the AI policy, finding things to do, and fixing stable and intermittent test failures

On top of that, I spent time diagnosing unexpected failures in others’ PRs and fixed numerous intermittent test failures that made merging PRs more difficult for everyone.

A few pieces of work from this period that stand out to me:

• supporting a large scale rewrite of Servo’s JS engine integration to address intermittent panics related to garbage collection—I reviewed lots of pull requests, but also filed many issues that enabled the work addressing the panics to be spread across many other contributors
• getting tagged in to help understand test failures, uncovering our broken window.open behaviour, and eventually making a lot of flaky tests more stable
• supporting another contributor’s grant proposal to work on Servo that was approved!

This role I’ve carved out means a lot to me—I’ve found a healthy balance that allows me to spend time with my family as well as make meaningful contributions to Servo, and I get to spend a lot of time looking for ways to make the project more accessible for others. A big thank you to everybody supporting the project and my work; each individual monthly donation makes a big difference! I’m excited to see what’s possible in the coming year.

exe.dev has one API, which looks like a CLI, but it can be used over multiple transports. You can run commands over SSH or send those same commands over HTTPS to https://exe.dev/exec. This extends to running commands on your VMs!

# Generate a token using your SSH key. (You can do this on the web UI as well!)
TOKEN=$(ssh exe.dev ssh-key generate-api-key --exp 1h --cmds=ssh,new --label tmp-$(date +%s) --json | jq .token -r)

# Create a new VM
curl https://exe.dev/exec -H "Authorization: Bearer $TOKEN" \
    -d 'new --name example-vm'
{"vm_name":"example-vm"...

# Run "hostname" on that new VM
curl https://exe.dev/exec -H "Authorization: Bearer $TOKEN" \
    -d 'ssh example-vm hostname'
example-vm

See the complete docs: https://exe.dev/docs/https-api-run-on-vm

This API shape composes nicely with the powerful primitives in your VM. So, if you want to start a task and return immediately, you can do something like the following with setsid nohup and output redirection.

curl https://exe.dev/exec -H "Authorization: Bearer $TOKEN" \
    -d "ssh example-vm 'setsid nohup sleep 10 > /tmp/out 2>&1 &'"
# Returns immediately

| submitted by /u/Norwood_Reaper_
[link] [comments]
---|---

SingleFile CLI 2.13.0

New features

• --load-deferred-content-min-zoom-factor bounds how far the page is zoomed out while deferred content loads. The page is zoomed out to make the site believe the whole document is on screen. That lie also shrinks every measurement the site takes at that moment, so a page sizing a block from innerHeight can record a value the reader never saw. Raise the factor to bound the effect, or set it to 1 to load deferred content without zooming out at all
• --load-deferred-content-block-cookies and --load-deferred-content-block-storage block document.cookie, localStorage and indexedDB for the time the deferred content pass runs. Both options existed in single-file-core and had no flag here

Changes

• The options loading lazy content are renamed from --load-deferred-images-* to --load-deferred-content-*. They never applied to images only. They also load frames, and the messages a page unmounts as you scroll. The old spellings still work and reach the same options, so existing scripts keep running unchanged
• --load-deferred-content-dispatch-scroll-event is now on by default. Both extensions already dispatch the event. Without it a site driven by a scroll handler rather than by an observer loads nothing at all. The consequence is that a site appending content near the bottom of the document can now append it. The page is told it sits one viewport from the end, so a handler triggering within a longer distance than that fires, and so does any handler measuring that distance against innerHeight. A handler waiting for a scroll position never fires, because the page is moved by a transform and not by scrolling. Pass --load-deferred-content-dispatch-scroll-event false to get the previous behaviour

Fixes from single-file-core 1.6.0 and 1.6.1

• Archives are created with no worker URI by default. The vendored zip.js bundle declared one that nothing serves
• The deferred content pass no longer takes a native timeout option, which no host declared

Co-authored by Claude (Claude Code)

After talking about it for a bit, and meeting some great people at HTML day, I decided to finally try to start up a Homebrew Website Club in the Twin Cities.

The first meeting will be on Monday Sep 21, 2026 at 5:00PM at Loons Coffee.

Link to the event: https://events.indieweb.org/R2UxWLeu3IHZ

What's Changed

• Pin GitHub Actions to full-length commit SHAs by Dan Fiedler (@danfiedler-msft) in #2316
• Mitigate UnicodeDecodeError due to wrong ASCII charset guess for long files by Fabio Catalano (@fcatalan92) in #2360
• fix: support extended content-disposition filenames by Rāna(Bass Ver.) (@cat0825) in #2045
• fix: fall back to plain text when RSS item content triggers RecursionError by Jeremy Schoemaker (@shoemoney) in #2333
• fix(cli): allow Content Understanding conversion from stdin by Tyyyy (@uczltw6) in #2318
• fix: correct \underleftarrow macro and map math italic h in equation conversion by Guillermo Dols (@gdols) in #2293
• feat(cli): support MARKITDOWN_CU_ENDPOINT / MARKITDOWN_DOCINTEL_ENDPOINT by Sinan Olsson-Pasic (@seenws) in #2358
• fix(csv): strip the UTF-8 BOM and skip blank rows before building the table by Ruiming Zhao (@uuzzrm) in #2303
• Preserve strikethrough from and CSS line-through by Gyanu Mayank (@gyanu2507) in #2342
• Fix percent-encoded Windows drive paths in file URIs by Zhewen Tan (@tandede) in #2315
• fix: escape pipes and newlines in CSV values by Asjad Abbas (@asjad3) in #2266
• fix(epub): safely extract metadata text without crashing on None nodeValue or nested elements by Henry Su (@hsusul) in #2247
• fix: handle math run with no text child in OMML->LaTeX conversion by S1MS4 in #2189
• fix: IpynbConverter.accepts() catches UnicodeDecodeError on non-decodable content (fixes #1894) by hanhan761 in #1929
• fix(docx): ignore malformed styles missing type by S M (@gingerninja85) in #2190
• Preserve percent-encoded octets in href paths by Sonai Biswas (@Sonai124) in #2173
• fix: remove extra closing brace from caron and ring-above accent templates by Andrew Avery (@AndrewAvery7) in #2279
• fix: preserve strikethrough semantics for , line-through CSS, and w:dstrike by MOHAMMED WASIM KHAN (@wasim-builds) in #2356
• fix: buffer CLI stdin before format detection on Windows by Mo Hui (@mohui666) in #2351
• fix(rss): preserve Atom XHTML content by will wang (@weivwang) in #2297
• fix: initialize md_text in _parse_rss_type to prevent UnboundLocalError by Sai Medavarapu (@smedavarapu1) in #2164
• fix: ZipConverter renders '(unknown)' instead of literal 'None' when stream has no source info by JSap0914 in #2134
• fix: truncate uppercase data image URIs by Lucas Ma (@pony-maggie) in #2122
• fix(doc-intel): default api_version to None in DocumentIntelligenceConverter by Nefelibata (@MeiSiristhebest) in #2267
• fix(outlook): read .msg string properties saved in the non-Unicode format by Guillermo Dols (@gdols) in #2295
• fix: handle URI schemes case-insensitively by Lucas Ma (@pony-maggie) in #2121
• fix: normalize data URI parameter case by Lucas Ma (@pony-maggie) in #2120
• fix(xlsx): tolerate legacy showZeroes sheet views by Yufeng He (@he-yufeng) in #2064
• docs: use canonical markdown result property by Sheroy Cooper (@CooperSheroy) in #2259
• fix(youtube): handle missing title metadata without raising AssertionError by Henry Su (@hsusul) in #2238
• Bump actions/checkout from 5.1.0 to 7.0.1 by Dependabot (@dependabot)[bot] in #2320
• Bump actions/setup-python from 5.6.0 to 7.0.0 by Dependabot (@dependabot)[bot] in #2321
• fix(ipynb): preserve leading # in notebook heading titles by Cpthimself (@Alphaxiaoteng) in #2371
• fix(docx): preserve underlined text by Yufeng He (@he-yufeng) in #2017
• fix(pptx): ignore empty llm captions by Lubrsy (@Lubrsy706) in #1886
• fix: PptxConverter tolerates None shape.text and notes text by Alvin Tang (@alvinttang) in #2059
• fix(pptx): prevent crash in PptxConverter when chart title lacks a text frame by aoright (@aoright) in #2194
• fix: catch OSError when exiftool binary is missing (#1960) by 王艺霖 (@doitgo) in #2082
• Fix exiftool JSON decoding to use UTF-8 by Vedant (@Vedant43hh) in #2067
• fix: WikipediaConverter renders hash None heading when page has no title by hanhan761 in #1990
• fix: guard against missing oMath element in DOCX math converter (#1979) by hanhan761 in #1995
• fix: handle DOCX files with inconsistent ZIP filename casing (#1812) by liyrds (@lyydsheep) in #2016
• Support short YouTube URLs by Mukunda Rao Katta (@MukundaKatta) in #1882
• fix: suppress pydub RuntimeWarning when ffmpeg is missing (fixes #1685) by hanhan761 in #1985
• chore: remove unused mammoth import from PlainTextConverter (#1951) by hanhan761 in #1953
• fix(rss): treat Atom text content and summary as plain text by Lazizbek Ergashev (@lazerg) in #2374
• fix: ImageConverter gracefully handles LLM API failures (fixes #1942) by hanhan761 in #1948
• fix(docx): handle unknown math functions in OMML converter without crashing by Nefelibata (@MeiSiristhebest) in #2268
• Update README to help scope PRs. by afourney in #2376
• Bump versions. by afourney in #2377
• Test markitdown-ocr in CI against the sibling markitdown by afourney in #2378
• Be sure to run the proper Python version. by afourney in #2379
• Remove uv lockfile that was accidentally committed. by afourney in #2380
• fix(pptx): chart_title.text_frame is never None — use has_text_frame instead by kapil971390 in #2385
• Updated README by afourney in #2393
• Preserve all CSV columns by matching the widest row by afourney in #2430
• Fix CSV parsing for CR-only line endings by Kim Do Yeon (@tkv00) in #2412
• chore(deps): bump actions/setup-python from 5.6.0 to 7.0.0 by Dependabot (@dependabot)[bot] in #2431
• fix(rss): support namespace-prefixed Atom feeds by Xing Zheng (@Elysium-Seeker) in #2429
• fix(rss): drop layout whitespace from feed and entry titles by kevin (@kevin9327) in #2428
• fix(pptx): do not emit a Notes heading for a slide with no notes by kevin (@kevin9327) in #2427
• fix(ipynb): strip the UTF-8 BOM so a notebook is not emitted as raw JSON by kevin (@kevin9327) in #2425
• fix(rss): preserve complete feed content and resolve relative link by afourney in #2432
• fix(epub): forward conversion options to the HTML converter by kevin (@kevin9327) in #2426
• Update Docker images to Debian trixie (Python 3.13-slim-trixie) by Erwin Kersten (@erwinkersten) in #2421
• Fix Zip converter forwarding kwargs to nested conversions by SpongeBob (@As9xm) in #2409
• Do not convert an undecodable file to the word "None" by kevin (@kevin9327) in #2418
• Fix PPTX shape sorting treating top-zero as missing by SpongeBob (@As9xm) in #2408
• fix(epub): resolve percent-encoded manifest hrefs to ZIP entries by Sushant Lokhande (@sushantlokhande14) in #2413
• Fix --list-plugins help text to reference correct --use-plugins flag by freetg71527152-ui in #2381
• fix: prefer data-src over placeholder data URI in img src by Machen John (@macjayz) in #2417
• fix(zip): preserve content of entries with duplicate filenames by liyrds (@lyydsheep) in #2434
• fix(pptx): do not emit a heading for a slide with an empty title by kevin (@kevin9327) in #2442
• fix(mcp): migrate to MCP SDK 2.x so 2026-07-28 clients can connect by Çağdaş Yürekli (@cagdasyurekli) in #2363
• Reject UNC and Windows device paths (similar to how netlocks are alre… by afourney in #2452
• Expand test matrix to include windows-latest by afourney in #2453
• Workaround for ARM CI tests. by afourney in #2460
• Fix ANSI Outlook MSG decoding for Japanese code pages and padded strings by afourney in #2462
• Trim CSV blank runs without repeatedly shifting the row list by dickbown (@ROTl24) in #2450
• Improve efficiency of escaping pipes in CSVs by afourney in #2464
• fix: avoid splitting UTF-8 characters during charset detection by afourney in #2466
• fix(docx): preserve namespaces when repairing stylesheets by afourney in #2467
• fix(youtube): fall back to HTML when no video content is extracted by afourney in #2469
• Throw an error when llm client fails with image converter. by afourney in #2476
• Preserve whitespace underlines by afourney in #2477

New Contributors

• Dan Fiedler (@danfiedler-msft) made their first contribution in #2316
• Fabio Catalano (@fcatalan92) made their first contribution in #2360
• Rāna(Bass Ver.) (@cat0825) made their first contribution in #2045
• Jeremy Schoemaker (@shoemoney) made their first contribution in #2333
• Tyyyy (@uczltw6) made their first contribution in #2318
• Guillermo Dols (@gdols) made their first contribution in #2293
• Sinan Olsson-Pasic (@seenws) made their first contribution in #2358
• Ruiming Zhao (@uuzzrm) made their first contribution in #2303
• Gyanu Mayank (@gyanu2507) made their first contribution in #2342
• Zhewen Tan (@tandede) made their first contribution in #2315
• Asjad Abbas (@asjad3) made their first contribution in #2266
• Henry Su (@hsusul) made their first contribution in #2247
• S1MS4 made their first contribution in #2189
• hanhan761 made their first contribution in #1929
• S M (@gingerninja85) made their first contribution in #2190
• Sonai Biswas (@Sonai124) made their first contribution in #2173
• Andrew Avery (@AndrewAvery7) made their first contribution in #2279
• MOHAMMED WASIM KHAN (@wasim-builds) made their first contribution in #2356
• Mo Hui (@mohui666) made their first contribution in #2351
• will wang (@weivwang) made their first contribution in #2297
• Sai Medavarapu (@smedavarapu1) made their first contribution in #2164
• JSap0914 made their first contribution in #2134
• Lucas Ma (@pony-maggie) made their first contribution in #2122
• Nefelibata (@MeiSiristhebest) made their first contribution in #2267
• Yufeng He (@he-yufeng) made their first contribution in #2064
• Sheroy Cooper (@CooperSheroy) made their first contribution in #2259
• Cpthimself (@Alphaxiaoteng) made their first contribution in #2371
• Lubrsy (@Lubrsy706) made their first contribution in #1886
• Alvin Tang (@alvinttang) made their first contribution in #2059
• aoright (@aoright) made their first contribution in #2194
• 王艺霖 (@doitgo) made their first contribution in #2082
• Vedant (@Vedant43hh) made their first contribution in #2067
• liyrds (@lyydsheep) made their first contribution in #2016
• Mukunda Rao Katta (@MukundaKatta) made their first contribution in #1882
• Lazizbek Ergashev (@lazerg) made their first contribution in #2374
• kapil971390 made their first contribution in #2385
• Kim Do Yeon (@tkv00) made their first contribution in #2412
• Xing Zheng (@Elysium-Seeker) made their first contribution in #2429
• kevin (@kevin9327) made their first contribution in #2428
• Erwin Kersten (@erwinkersten) made their first contribution in #2421
• SpongeBob (@As9xm) made their first contribution in #2409
• Sushant Lokhande (@sushantlokhande14) made their first contribution in #2413
• freetg71527152-ui made their first contribution in #2381
• Machen John (@macjayz) made their first contribution in #2417
• Çağdaş Yürekli (@cagdasyurekli) made their first contribution in #2363
• dickbown (@ROTl24) made their first contribution in #2450

Full Changelog : v0.1.7...v0.1.8b2