Starting December 1, the Electron project will enter a quiet period before picking back up at full capacity in January 2026. For full details, see the Policies section below.

Since 2020, December has been a time for project maintainers to take a breather from regular maintenance duties in order to take a break or focus on heads-down work. This break helps us rest up and come back energized for the year to come.

That said, a month-long pause like this one is only achievable when an open-source project is in a healthy state—we’d like to thank all maintainers and external contributors for all of their continued efforts to keep the project moving. ❤️

O projeto Electron será pausado durante o mês de dezembro de 2024, e retornará em janeiro de 2025 com velocidade máxima.

via GIPHY

What will be the same in December​

1. Zero-day and other major security-related releases will be published as necessary. Security incidents should be reported via SECURITY.md.
2. Code of Conduct reports and moderation will continue.

What will be different in December​

1. 2024's last stable branch releases for the year, which include Electron 31, 32, and 33, will occur the week of December 1st. There will be no additional planned releases in December.
2. No Nightly and Alpha releases for the last two weeks of December.
3. With few exceptions, no pull request reviews or merges.
4. No issue tracker updates on any repositories.
5. No Discord debugging help from maintainers.
6. No social media content updates.

See you all in 2025!

The Electron project will pause for the month of December 2023, then return to full speed in January 2024.

via GIPHY

What will be the same in December​

1. Zero-day and other major security-related releases will be published as necessary. Security incidents should be reported via SECURITY.md.
2. Code of Conduct reports and moderation will continue.

What will be different in December​

1. Electron 28.0.0 will be released on December 5th. After Electron 28, there will be no new Stable releases in December.
2. No Nightly and Alpha releases for the last two weeks of December.
3. With few exceptions, no pull request reviews or merges.
4. No issue tracker updates on any repositories.
5. No Discord debugging help from maintainers.
6. No social media content updates.

Going forward​

This is our third year running our quiet period experiment, and we've had a lot of success so far in balancing a month of rest with maintaining our normal release cadence afterwards. Therefore, we've decided to make this a regular part of our release calendar going forward. We'll still be putting a reminder into the last stable release of every calendar year.

See you all in 2024!

O primeiro commit do repositório electron/electron foi em 13 de março de 2013¹.

Após 10 anos e 27,147 mais commits de 1192 contribuintes únicos, Electron se tornou uma das estruturas mais populares para construir aplicativos de desktop hoje. Esse marco é a oportunidade perfeita para celebrar e refletir sobre nossa jornada até agora, e para compartilhar o que aprendemos ao longo o caminho.

Nós não estaríamos aqui hoje sem todos que dedicaram seu tempo e seu esforço para contribuir com o projeto. Embora as contribuições de commits de código-fonte sejam sempre as mais visíveis, também devemos reconhecer o esforço das pessoas que relatam bugs, mantêm módulos de usuário, fornecem documentação e traduções, e participam na comunidade Electron em todo o ciberespaço. Todos os contributos são inestimáveis para nós, como mantenedores.

Antes de continuarmos com o resto do post: obrigado. ❤️

Como chegamos aqui?​

Atom Shell foi construído como a espinha dorsal do GitHub Editor Atom, que foi lançado em beta público em Abril de 2014. Foi construído a partir do zero como uma alternativa aos frameworks baseados na web disponíveis no tempo (node-webkit e Chromium Embedded Framework). Ele tinha um recurso matador: incorporando Node.js e Chromium para fornecer um poderoso tempo de execução desktop para tecnologias web.

Dentro de um ano, Atom Shell começou a assistir a um enorme crescimento das capacidades e da popularidade. Grandes empresas, startups e desenvolvedores individuais também começaram a construir aplicativos com ele (alguns early adopters incluem Slack, GitKraken, e WebTorrent), e o projeto foi apropriadamente renomeado para Electron.

A partir daí, o Electron começou com força total e nunca parou. Aqui está uma olhada em nossa contagem semanal de downloads ao longo do tempo, cortesia de npmtrends.com:

Electron v1 foi lançado em 2016, prometendo maior estabilidade da API e melhores documentos e ferramentas. Electron v2 foi lançado em 2018 e introduzido a versão semântica, tornando mais fácil para desenvolvedores Electron manter controle do ciclo de lançamento.

Por Electron v6, mudamos para uma cadência de lançamento maior de 12 semanas para combinar com a do Chromium. Esta decisão foi uma alteração na mentalidade do projeto, trazendo “ter a versão mais atualizada do Chromium ” de um nicho a ter uma prioridade. Isso reduziu a quantidade de dívida em tecnologia entre atualizações, tornando mais fácil para nós manter o Electron atualizado e seguro.

Desde então, temos funcionado como uma máquina bem oleada, lançando uma nova versão do Electron no mesmo dia que cada versão estável do Chromium. Quando o Chromium acelerou seu cronograma de lançamentos para 4 semanas em 2021, conseguimos simplesmente dar de ombros e aumentar nossa cadência de lançamentos para 8 semanas de acordo.

Agora estamos no Electron v23 (e contando), e ainda estamos dedicados a construir o melhor tempo de execução para construir aplicativos desktop multiplataforma. Mesmo com o boom das ferramentas de desenvolvedor de JavaScript em últimos anos, Electron continuou a ser uma paisagem estável e testada por batalhas do framework do aplicativo para desktop. Aplicativos Electron atualmente são onipresentes: você pode programar com o Visual Studio Code, projetar com Figma, se comunicar com o Slack, e fazer notas com Notion (entre muitos outros casos de uso). Estamos incrivelmente orgulhosos desta conquista e gratos a todos que a tornaram possível.

O que aprendemos ao longo do caminho?​

O caminho para o marco da década tem sido longo e ventoso. Aqui estão algumas coisas-chave que nos ajudaram a administrar um projeto de código aberto grande e sustentável.

Dimensionamento da tomada decisória distribuída com um modelo de governança​

Um desafio que tivemos que superar foi lidar com a direção de longo prazo do projeto uma vez que o Electron explodiu na popularidade. Como lidamos com ser uma equipe de algumas dezenas de engenheiros distribuídos por empresas, países e fusos horários?

Nos primeiros dias, o grupo de mantenedores do Electron baseou-se em coordenação informal, que é rápido e leve para projetos menores, mas não escala para uma colaboração mais ampla. Em 2019, mudamos para um modelo de governança onde diferentes grupos de trabalho têm áreas formais de responsabilidade. Isto tem sido instrumental na racionalização de processos e atribuição de porções de propriedade do projeto a mantenedores específicos. Qual é a responsabilidade de cada grupo de trabalho (WG) actualmente?

• Obter lançamentos do Electron rápido (Releases WG)
• Atualizar o Chromium e o Node.js (Atualiza o WG)
• Supervisão do design da API pública (Grupo de Trabalho de API)
• Manter o Electron seguro (WG de segurança)
• Manter o site, a documentação e a ferramenta (Ecosystem WG)
• Alcance da Comunidade e corporativa (Outreach WG)
• Moderação comunitária (Community & Segurança WG)
• Manutenção de nossa infraestrutura construtiva, mantenedores de ferramentas e serviços de nuvem (Infraestrutura de WG)

Por volta do mesmo período em que mudamos para o modelo de governança, transferimos a propriedade do Electron do GitHub para a OpenJS Foundation. Embora a equipe central original ainda trabalhe na Microsoft hoje, eles são apenas uma parte de um grupo maior de colaboradores que compõem a governança do Electron.²

Embora esse modelo não seja perfeito, ele nos serviu bem durante uma pandemia global e desafios econômicos contínuos. Indo em frente, nós planejamos renovar a carta de governança para nos guiar durante a segunda década da Electron.

Comunidade​

A parte da comunidade de código aberto é difícil, especialmente quando sua equipe de Outreach é uma dúzia de engenheiros em um casaco de trincheiras que diz "gerente da comunidade". Dito isso, ser um grande projeto de código aberto significa que temos muitos usuários, e utilizar sua energia para o Electron construir um ecossistema da userland é uma parte crucial para sustentar a saúde do projeto.

O que temos estado a fazer para desenvolver a nossa presença na comunidade?

Criando comunidades virtuais​

• Em 2020, lançamos o servidor da nossa comunidade do Discord. Anteriormente tínhamos uma secção no fórum do Atom, mas decidiu ter uma plataforma de mensagens mais informal para ter um espaço para discussões entre mantenedores e desenvolvedores Electron e para ajuda geral na depuração.
• Em 2021, estabelecemos o grupo de usuários Electron China com a ajuda da @BlackHole1. Este grupo tem sido instrumental no crescimento do Electron em usuários da cena tecnológica da China, proporcionando um espaço para eles colaborarem em ideias e discuta o Electron fora de nossos espaços em inglês. Nós também gostaríamos de agradecer à cnpm pelo seu trabalho de apoio aos lançamentos noturnos da Electron, em seu espelho Chinês para o npm.

Participando de programas de alta visibilidade de código aberto​

• Temos comemorado o Hacktoberfest todos os anos desde 2019. O Hacktoberfest é uma celebração anual de código aberto organizada pela DigitalOcean, e todos os anos recebemos dezenas de colaboradores entusiasmados que buscam deixar sua marca no software de código aberto.
• Em 2020, participamos da iteração inicial da Google Season of Docs, onde trabalhamos com @bandantonio para retrabalhar o novo fluxo de tutorial do Electron.
• Em 2022, mentoramos um aluno do "Google Summer of Code" pela primeira vez. @aryanshridhar fez um ótimo trabalho para refatorar a principal lógica de carregamento de versão do Electron Fiddle e migrar o seu empacotamento para webpack.

Automatizar todas as coisas!​

Hoje, a governaça do Electron conta com cerca de 30 mantenedores ativos. Menos de metade de nós somos colaboradores a tempo integral contribuidores, o que significa que há muito trabalho a fazer. Qual é o nosso truque para manter tudo funcionando sem problemas? O nosso lema é que os computadores são baratos, e o tempo humano é caro. De forma típica de engenheiro, nós desenvolvemos um conjunto de ferramentas automatizadas de suporte para tornar nossas vidas mais fáceis.

Not Goma​

A base de código central do Electron é um gigante de código C++, e os tempos de compilação sempre foram um fator limitante na velocidade com que podemos entregar correções de falhas e novos recursos. In 2020, we deployed Not Goma, a custom Electron-specific backend for Google’s Goma distributed compiler service. Não é um processo de compilação do (Goma) que solicita solicitações de máquinas autorizadas do usuário e distribui o processo por centenas de núcleos do backend. Ele também armazena em cache o resultado da compilação, para que qualquer outra pessoa que compile os mesmos arquivos precisem

Desde o lançamento Não Goma, os tempos de compilação para mantenedores diminuíram de uma escala de horas para minutos. Uma conexão estável com a internet tornou-se o requisito mínimo de contribuidores para compilar o Electron!

Fator de Autenticação Contínua​

Continuous Factor Authentication (CFA) é uma camada de automação em torno do sistema de autenticação de dois fatores (2FA) do npm, que combinamos com o semantic-release para gerenciar lançamentos seguros e automatizados de nossos vários pacotes @electron/ do npm.

Embora o semantic-release já automatize o processo de publicação de pacotes npm, ele exige desativar a autenticação de dois fatores ou passar um token secreto que contorna essa restrição.

Construímos o CFA para fornecer uma senha de uso único baseada em tempo (TOTP) para o 2FA do npm em tarefas de CI arbitrárias, permitindo-nos aproveitar a automação do semantic-release enquanto mantemos a segurança adicional da autenticação de dois fatores.

Usamos o CFA com um front-end de integração do Slack, permitindo que os mantenedores validem a publicação do pacote de qualquer dispositivo em que o Slack esteja ativado, contanto que tenham seu gerador TOTP útil.

Sheriff​

Sheriff é uma ferramenta de código aberto que escrevemos para automatizar a ferramenta gerenciamento de permissões em todo o GitHub, Slack e Google Workspace.

A proposta de valor-chave do Sherif é que a gestão de permissão deve ser um processo transparente. Ele usa um único arquivo de configuração YAML que designa permissões através de todos os serviços listados acima. Com o Sheriff, obter o status de colaborador em um repositório ou criar uma nova lista de e-mails é tão fácil quanto obter um PR aprovado e mesclado.

O Sheriff também possui um registro de auditoria que posta no Slack, alertando os administradores quando atividades suspeitas ocorrem em qualquer lugar na organização Electron.

…e todos os nossos bots no GitHub​

O GitHub é uma plataforma com a rica extensibilidade da API e um framework de aplicativo de primeiro grupo chamado Probot. Para nos ajudar a focar nas partes mais criativas do nosso trabalho, construímos um conjunto de bots menores que nos ajudam a fazer o trabalho sujo. Eis alguns exemplos:

• Sudowodo automatiza o processo de lançamento do Electron do início ao fim, desde o início das compilações até o upload dos arquivos de lançamento para o GitHub e npm.
• Trop automatiza o processo de backporting para o Electron, tentando aplicar patches (usando cherry-pick) em branches de versões anteriores com base nos labels das Pull Requests (PRs) do GitHub.
• Roller automatiza as atualizações do Chromium do Electron e das dependências do Node.js.
• Cation é nosso bot de verificação de status para electron/electron PRs.

Ao todo, nossa pequena família de bots nos deu um grande impulso na produtividade do desenvolvedor!

What’s next?​

À medida que entramos em nossa segunda década como um projeto, você deve estar perguntando: o que vem por aí com o Electron?

Vamos continuar em sincronia com a cadência de lançamentos do Chromium, lançando novas versões principais do Electron a cada 8 semanas, mantendo o framework atualizado com o que há de mais recente na plataforma web e no Node.js, ao mesmo tempo em que mantemos estabilidade e segurança para aplicativos de nível empresarial.

Normalmente anunciamos notícias sobre iniciativas futuras quando elas se tornam concretas. Se você quiser se manter informado sobre as versões futuras, recursos e atualizações gerais do projeto, você pode ler nosso blog e seguir nossos perfis de mídia social (Twitter e Mastodon)!

Electron will end support of Windows 7, Windows 8 and Windows 8.1 beginning in Electron 23.

In line with Chromium’s deprecation policy, Electron will end support of Windows 7, Windows 8 and Windows 8.1 beginning in Electron 23. This matches Microsoft's end of support for Windows 7 ESU and Windows 8.1 extended on January 10th, 2023.

Electron 22 will be the last Electron major version to support Windows versions older than 10. Windows 7/8/8.1 will not be supported in Electron 23 and later major releases. Older versions of Electron will continue to function on Windows 7, and we will continue to release patches for Electron the 22.x series until May 30 2023, when Electron will end support for 22.x (according to our support timeline).

Why deprecate?​

Electron follows the planned Chromium deprecation policy, which will deprecate support in Chromium 109 (read more about Chromium's timeline here). Electron 23 will contain Chromium 110, which won’t support older versions of Windows.

Electron 22, which contains Chromium 108, will thus be the last supported version.

Linha do tempo da depreciação​

The following is our planned deprecation timeline:

• December 2022: The Electron team is entering a quiet period for the holidays
• January 2023: Windows 7 & 8 related issues are accepted for all supported release branches.
• February 7 2023: Electron 23 is released.
• February 8 2023 - May 29 2023: Electron will continue to accept fixes for supported lines older than Electron 23.
• May 30 2023: Electron 22 reaches the end of its support cycle.

What this means for developers:

• The Electron team will accept issues and fixes related to Windows 7/8/8.1 for stable supported lines, until each line reaches the end of its support cycle.
  • This specifically applies to Electron 22, Electron 21 and Electron 20.
• New issues related to Windows 7/8/8.1 will be accepted for Electron versions older than Electron 23.
  • New issues will not be accepted for any newer release lines.
• Once Electron 22 has reached the end of its support cycle, all existing issues related to Windows 7/8/8.1 will be closed.

What's next​

Please feel free to write to us at info@electronjs.org if you have any questions or concerns. You can also find community support in our official Electron Discord.

O projeto Electron será pausado durante o mês de dezembro de 2022, e retornará em janeiro de 2023 com velocidade máxima.

via GIPHY

What will be the same in December​

1. Zero-day and other major security-related releases will be published as necessary. Security incidents should be reported via SECURITY.md.
2. Code of Conduct reports and moderation will continue.

What will be different in December​

1. No new Stable releases in December. No Nightly and Alpha releases for the last two weeks of December.
2. With few exceptions, no pull request reviews or merges.
3. No issue tracker updates on any repositories.
4. No Discord debugging help from maintainers.
5. No social media content updates.

Why is this happening?​

With the success of December Quiet Month 2021, we wanted to bring it back for 2022. December continues to be a quiet month for most companies, so we want to give our maintainers a chance to recharge. Everyone is looking forward to 2023, and we expect good things to come! We encourage other projects to consider similar measures.

No mês passado, o grupo de mantenedores do Electron se reuniu em Vancouver, Canadá, para discutir a direção do projeto para 2023 e além. Durante quatro dias em uma sala de conferências, os principais mantenedores e colaboradores convidados discutiram novas iniciativas, pontos problemáticos de manutenção e a saúde geral do projeto.

No futuro, a equipe continuará totalmente dedicada a lançar atualizações regulares e rápidas do Chromium, corrigir bugs e tornar o Electron mais seguro e eficiente para todos. Também temos alguns projetos interessantes em andamento que adoraríamos compartilhar com a comunidade!

Novas APIs transformadoras​

As principais propostas de API no projeto Electron que exigem consenso passam por um processo de Solicitação de Comentários (RFC), que é revisado pelos membros do nosso Grupo de Trabalho de API.

Este ano, avançamos com duas propostas importantes que têm o potencial de desbloquear uma nova dimensão de capacidades para os aplicativos Electron. Essas propostas são altamente experimentais, mas aqui está uma prévia do que esperar!

Novos aprimoramentos de complementos nativos (APIs C)​

This proposal outlines a new layer of Electron C APIs that will allow app developers to write their own Native Node Addons that interface with Electron’s internal resources, similar to Node’s own Node-API. More information about the proposed new API can be found here.

Exemplo: turbinando aplicativos com recursos do Chromium​

Muitos aplicativos Electron mantêm seus próprios forks para interagir diretamente com os componentes internos do Chromium que, de outra forma, seriam inacessíveis com o Electron puro (sem modificações). By exposing these resources in the C API layer, this code can instead live as a native module alongside Electron, potentially reducing app developer maintenance burden.

Exposing Chromium’s UI layer (Views API)​

Under the hood, the non-website parts of Chrome’s user interface (UI), such as toolbars, tabs, or buttons, are built with a framework called Views. The Views API proposal introduces parts of this framework as JavaScript classes in Electron, with the eventual goal of allowing developers to create non-web UI elements to their Electron applications. This will prevent apps from having to hack together web contents.

The groundwork to make this new set of APIs possible is currently in progress. Here are a few of the first things you can expect in the near future.

Example: Refactoring the window model with WebContentsView​

Our first planned change is to expose Chrome’s WebContentsView to Electron’s API surface, which will be the successor to our existing BrowserView API (which, despite the name, is Electron-specific code unrelated to Chromium Views). With WebContentsView exposed, we will have a reusable View object that can display web contents, opening the door to making the BrowserWindow class pure JavaScript and eliminating even more code complexity.

Although this change doesn’t provide a lot of new functionality to app developers, it is a large refactor that eliminates a lot of code under the hood, simplifying Chromium upgrades and reducing the risk of new bugs appearing between major versions.

If you’re an Electron developer using BrowserViews in your app: don’t worry, we haven’t forgotten about you! We plan on making the existing BrowserView class a shim for WebContentsView to provide a buffer as you transition to the newer APIs.

Veja: electron/electron#35658

Example: Scrollable web contents with ScrollView​

Our friends at Stack have been driving an initiative to expose the Chromium ScrollView component to Electron’s API. With this new API, any child View component can be made scrollable horizontally or vertically.

Although this new API fulfills a single smaller functionality, the team’s eventual goal is to build a set of utility View components that can be used as a toolkit to build more complex non-HTML interfaces.

Envolvendo-se​

Você é um desenvolvedor de aplicativos Electron interessado em alguma dessas propostas de API? Embora não estejamos prontos para receber RFCs adicionais, fique atento para mais detalhes no futuro!

Electron Forge v6 stable release​

Since the framework’s inception, Electron’s build tooling ecosystem has been largely community-driven and has consisted of many small single-purpose packages (e.g. electron-winstaller, electron-packager, electron-notarize, electron-osx-sign). Although these tools work well, it’s intimidating for users to piece together a working build pipeline.

To help build a friendlier experience for Electron developers, we built Electron Forge, an all-in-one solution that combines all this existing tooling into a single interface. Although Forge has been in development since 2017, the project has lain dormant for the last few years. However, given community feedback on the state of build tooling in Electron, we have been hard at work on releasing the next-gen stable major version of Forge.

Electron Forge 6 comes with first-class TypeScript and Webpack support, as well as an extensible API that allows developers to create their own plugins and installers.

Stay tuned: announcement coming soon​

If you’re interested in building a project with Forge or building templates or plugins with Forge’s extensible third-party APIs, stay tuned for our official announcement on the Forge v6 stable release sometime this month!

What’s next?​

Aside from the above, the team is always thinking of a bunch of exploratory projects to make the Electron experience better for app developers and end users. Updater tooling, API review processes, and enhanced documentation are other things we are experimenting with. We hope to have more news to share in the near future!

Electron 21 and later will have the V8 Memory Cage enabled, with implications for some native modules.

In Electron 21, we will be enabling V8 sandboxed pointers in Electron, following Chrome's decision to do the same in Chrome 103. This has some implications for native modules. Also, we previously enabled a related technology, pointer compression, in Electron 14. We didn't talk about it much then, but pointer compression has implications for the maximum V8 heap size.

These two technologies, when enabled, are significantly beneficial for security, performance and memory usage. However, there are some downsides to enabling them, too.

The main downside of enabling sandboxed pointers is that ArrayBuffers which point to external ("off-heap") memory are no longer allowed. This means that native modules which rely on this functionality in V8 will need to be refactored to continue working in Electron 20 and later.

The main downside of enabling pointer compression is that the V8 heap is limited to a maximum size of 4GB. The exact details of this are a little complicated—for example, ArrayBuffers are counted separately from the rest of the V8 heap, but have their own limits.

The Electron Upgrades Working Group believes that the benefits of pointer compression and the V8 memory cage outweigh the downsides. There are three main reasons for doing so:

1. It keeps Electron closer to Chromium. The less Electron diverges from Chromium in complex internal details such as V8 configuration, the less likely we are to accidentally introduce bugs or security vulnerabilities. Chromium's security team is formidable, and we want to make sure we are taking advantage of their work. Further, if a bug only affects configurations that aren't used in Chromium, fixing it is not likely to be a priority for the Chromium team.
2. It performs better. Pointer compression reduces V8 heap size by up to 40% and improves CPU and GC performance by 5%–10%. For the vast majority of Electron applications which won't bump into the 4GB heap size limit and don't use native modules that require external buffers, these are significant performance wins.
3. It's more secure. Some Electron apps run untrusted JavaScript (hopefully following our security recommendations!), and for those apps, having the V8 memory cage enabled protects them from a large class of nasty V8 vulnerabilities.

Lastly, there are workarounds for apps that really need a larger heap size. For example, it is possible to include a copy of Node.js with your app, which is built with pointer compression disabled, and move the memory-intensive work to a child process. Though somewhat complicated, it is also possible to build a custom version of Electron with pointer compression disabled, if you decide you want a different trade-off for your particular use case. And lastly, in the not-too-distant future, wasm64 will allow apps built with WebAssembly both on the Web and in Electron to use significantly more than 4GB of memory.

Perguntas Frequentes​

How will I know if my app is impacted by this change?​

Attempting to wrap external memory with an ArrayBuffer will crash at runtime in Electron 20+.

If you don't use any native Node modules in your app, you're safe—there's no way to trigger this crash from pure JS. This change only affects native Node modules which allocate memory outside of the V8 heap (e.g. using malloc or new) and then wrap the external memory with an ArrayBuffer. This is a fairly rare use case, but some modules do use this technique, and such modules will need to be refactored in order to be compatible with Electron 20+.

How can I measure how much V8 heap memory my app is using to know if I'm close to the 4GB limit?​

In the renderer process, you can use performance.memory.usedJSHeapSize, which will return the V8 heap usage in bytes. In the main process, you can use process.memoryUsage().heapUsed, which is comparable.

What is the V8 memory cage?​

Some documents refer to it as the "V8 sandbox", but that term is easily confusable with other kinds of sandboxing that happen in Chromium, so I'll stick to the term "memory cage".

There's a fairly common kind of V8 exploit that goes something like this:

1. Find a bug in V8's JIT engine. JIT engines analyze code in order to be able to omit slow runtime type checks and produce fast machine code. Sometimes logic errors mean it gets this analysis wrong, and omits a type check that it actually needed—say, it thinks x is a string, but in fact it's an object.
2. Abuse this confusion to overwrite some bit of memory inside the V8 heap, for instance, the pointer to the beginning of an ArrayBuffer.
3. Now you have an ArrayBuffer that points wherever you like, so you can read and write any memory in the process, even memory that V8 normally doesn't have access to.

The V8 memory cage is a technique designed to categorically prevent this kind of attack. The way this is accomplished is by not storing any pointers in the V8 heap. Instead, all references to other memory inside the V8 heap are stored as offsets from the beginning of some reserved region. Then, even if an attacker manages to corrupt the base address of an ArrayBuffer, for instance by exploiting a type confusion error in V8, the worst they can do is read and write memory inside the cage, which they could likely already do anyway. There's a lot more available to read on how the V8 memory cage works, so I won't go into further detail here—the best place to start reading is probably the high-level design doc from the Chromium team.

I want to refactor a Node native module to support Electron 21+. How do I do that?​

There are two ways to go about refactoring a native module to be compatible with the V8 memory cage. The first is to copy externally-created buffers into the V8 memory cage before passing them to JavaScript. This is generally a simple refactor, but it can be slow when the buffers are large. The other approach is to use V8's memory allocator to allocate memory which you intend to eventually pass to JavaScript. This is a bit more involved, but will allow you to avoid the copy, meaning better performance for large buffers.

To make this more concrete, here's an example N-API module that uses external array buffers:

// Create some externally-allocated buffer.
// |create_external_resource| allocates memory via malloc().
size_t length = 0;
void* data = create_external_resource(&length);
// Wrap it in a Buffer--will fail if the memory cage is enabled!
napi_value result;
napi_create_external_buffer(
    env, length, data,
    finalize_external_resource, NULL, &result);

This will crash when the memory cage is enabled, because data is allocated outside the cage. Refactoring to instead copy the data into the cage, we get:

size_t length = 0;
void* data = create_external_resource(&length);
// Create a new Buffer by copying the data into V8-allocated memory
napi_value result;
void* copied_data = NULL;
napi_create_buffer_copy(env, length, data, &copied_data, &result);
// If you need to access the new copy, |copied_data| is a pointer
// to it!

This will copy the data into a newly-allocated memory region that is inside the V8 memory cage. Optionally, N-API can also provide a pointer to the newly-copied data, in case you need to modify or reference it after the fact.

Refactoring to use V8's memory allocator is a little more complicated, because it requires modifying the create_external_resource function to use memory allocated by V8, instead of using malloc. This may be more or less feasible, depending on whether or not you control the definition of create_external_resource. The idea is to first create the buffer using V8, e.g. with napi_create_buffer, and then initialize the resource into the memory that has been allocated by V8. It is important to retain a napi_ref to the Buffer object for the lifetime of the resource, otherwise V8 may garbage-collect the Buffer and potentially result in use-after-free errors.

Electron is changing its primary S3 bucket, you may need to update your build scripts

What is happening?

A significant amount of Electron's build artifacts are uploaded to an S3 bucket called gh-contractor-zcbenz. As part of ongoing infrastructure/ownership migrations that started way back in 2020, we will be changing everything that used gh-contractor-zcbenz from its old home in S3 to a new storage system hosted at https://artifacts.electronjs.org. The path prefix that most of our assets use is changing slightly as well. Examples are included below:

Before: https://gh-contractor-zcbenz.s3.amazonaws.com/atom-shell/dist/v17.0.0/node.lib After: https://artifacts.electronjs.org/headers/dist/v17.0.0/node.lib

The important things here are the Hostname changed and the /atom-shell prefix changed. Another example, this time for debug symbols:

Before: https://gh-contractor-zcbenz.s3.amazonaws.com/atom-shell/symbols/path/to/symbol.pdb After: https://artifacts.electronjs.org/symbols/path/to/symbol.pdb

Again, the hostname changed and the /atom-shell prefix was changed.

How might this impact you?

Anyone using standard build tooling such as electron-rebuild, electron-packager or @electron/get won't have to do anything. This should be the majority of people.

For anyone directly referencing the S3 bucket, you must update your reference to point at the hostname and update the path as well.

What about existing data?

Most data that existed on the gh-contractor-zcbenz bucket has been cloned into the new storage system. This means all debug symbols and all headers have been copied. If you relied on some data in that bucket that hasn't been copied over please raise an issue in electron/electron and let us know.

The current gh-contractor-zcbenz S3 bucket will not be actively deleted. However, we can't guarantee how long that bucket will be left alive. We strongly recommend updating to target the new bucket as soon as possible.

O projeto Electron será pausado durante o mês de dezembro de 2021, e retornará em janeiro de 2022 com velocidade máxima.

via GIPHY

What will be the same in December​

1. Zero-day and other major security-related releases will be published as necessary. Security incidents should be reported via SECURITY.md.
2. Code of Conduct reports and moderation will continue.

What will be different in December​

1. No new Beta or Stable releases in December. No Nightly releases for the last two weeks of December.
2. With few exceptions, no pull request reviews or merges.
3. No issue tracker updates on any repositories.
4. No Discord debugging help from maintainers.
5. No social media content updates.

Why is this happening?​

In short, while maintainers are happy and engaged with the project, THE WORLD IS TIRED. December is a quiet month for most companies, so we want to give our maintainers a chance to recharge. We encourage other projects to consider similar measures.

Should I be worried about the future of Electron?​

Não. We are able to take this step because the project is in good shape. Everyone is looking forward to 2022, and we expect good things to come!