Skip to main content

Electron 29.0.0

· 7 min read

Electron 29.0.0이 출시되었다! 이번 버전은 Chromium 122.0.6261.39, V8 12.2, 그리고 Node.js 20.9.0으로 업그레이드되었다.


Electron 팀은 Electron 29.0.0 출시를 기쁘게 발표한다. npm install electron@latest 명령어를 통해 npm으로 설치하거나 릴리스 웹사이트에서 다운로드할 수 있다. 이번 릴리스에 대한 자세한 내용은 계속 읽어보자.

피드백이 있다면 TwitterMastodon을 통해 공유하거나, Discord 커뮤니티에 참여해 보자. 버그와 기능 요청은 Electron의 이슈 트래커에 보고할 수 있다.

주요 변경 사항

하이라이트

  • 새로운 최상위 webUtils 모듈을 추가했다. 이 모듈은 렌더러 프로세스에서 Web API 객체와 상호작용하기 위한 유틸리티 계층을 제공한다. 이 모듈의 첫 번째 API는 webUtils.getPathForFile이다. 이전에 Electron의 File.path 확장은 웹 표준과 달랐지만, 이 새로운 API는 현재 웹 표준 동작에 더 부합한다.

스택 변경 사항

Electron 29은 Chromium을 120.0.6099.56에서 122.0.6261.39로, Node를 18.18.2에서 20.9.0로, V8을 12.0에서 12.2로 업그레이드한다.

새로운 기능

  • Web API 객체와 상호작용하기 위한 유틸리티 계층인 새로운 webUtils 모듈을 추가해 File.path 확장을 대체한다. #38776
  • 유틸리티 프로세스net 모듈을 추가한다. #40890
  • file:// 프로토콜이 Chromium과 동일한 더 안전하고 제한적인 동작을 선택하도록 하는 새로운 Electron FusegrantFileProtocolExtraPrivileges를 추가한다. #40372
  • 커스텀 스킴에서 V8 코드 캐시를 허용하는 옵션을 protocol.registerSchemesAsPrivileged에 추가한다. #40544
  • macOS 13.0 이상에서 app.{set|get}LoginItemSettings(settings)가 Apple의 새로운 권장 프레임워크를 사용하도록 마이그레이션한다. #37244

주요 변경 사항

동작 변경: ipcRenderercontextBridge를 통해 전달할 수 없음

contextBridge를 통해 ipcRenderer 모듈 전체를 객체로 전달하려고 하면, 이제 브리지의 수신 측에서 빈 객체를 받게 된다. 이 변경은 보안상의 위험을 제거하거나 완화하기 위해 도입되었다. ipcRenderer나 그 메서드를 직접 브리지에 노출시키면 안 된다. 대신 다음과 같이 안전한 래퍼를 제공해야 한다:

contextBridge.exposeInMainWorld('app', {
onEvent: (cb) => ipcRenderer.on('foo', (e, ...args) => cb(args)),
});

app 객체의 renderer-process-crashed 이벤트가 제거되었다. 이제 새로운 render-process-gone 이벤트를 사용해야 한다.

// 제거됨
app.on('renderer-process-crashed', (event, webContents, killed) => {
/* ... */
});

// 대체 코드
app.on('render-process-gone', (event, webContents, details) => {
/* ... */
});

제거됨: WebContents<webview>crashed 이벤트

WebContents<webview>crashed 이벤트가 제거되었다. 대신 새로운 render-process-gone 이벤트를 사용한다.

// 제거됨
win.webContents.on('crashed', (event, killed) => {
/* ... */
});
webview.addEventListener('crashed', (event) => {
/* ... */
});

// 대체 코드
win.webContents.on('render-process-gone', (event, details) => {
/* ... */
});
webview.addEventListener('render-process-gone', (event) => {
/* ... */
});

제거됨: appgpu-process-crashed 이벤트

appgpu-process-crashed 이벤트가 제거되었다. 이제 새로운 child-process-gone 이벤트를 사용해야 한다.

// 제거됨
app.on('gpu-process-crashed', (event, killed) => {
/* ... */
});

// 대체 코드
app.on('child-process-gone', (event, details) => {
/* ... */
});

26.x.y 버전 지원 종료

Electron 26.x.y 버전은 프로젝트의 지원 정책에 따라 지원이 종료되었다. 개발자와 애플리케이션은 더 새로운 버전의 Electron으로 업그레이드할 것을 권장한다.

E29 (2024년 2월)E30 (2024년 4월)E31 (2024년 6월)
29.x.y30.x.y31.x.y
28.x.y29.x.y30.x.y
27.x.y28.x.y29.x.y

다음 단계

Electron이 최근 커뮤니티 RFC(Request for Comments) 프로세스를 도입한 것을 알고 있는가? 프레임워크에 새로운 기능을 추가하고 싶다면, RFC는 유지 관리자와 설계에 대해 논의를 시작할 수 있는 유용한 도구다. 또한 Pull Requests에서 논의 중인 예정된 변경 사항을 확인할 수도 있다. 더 자세한 내용은 Introducing electron/rfcs 블로그 포스트를 참고하거나 electron/rfcs 저장소의 README를 직접 확인해 보자.

단기적으로, Electron 팀은 Chromium, Node, V8 등 Electron을 구성하는 주요 컴포넌트의 개발을 따라가는 데 계속 집중할 예정이다.

Electron의 공개 타임라인은 여기서 확인할 수 있다.

향후 예정된 변경 사항에 대한 더 많은 정보는 Planned Breaking Changes 페이지에서 찾아볼 수 있다.

Introducing electron/rfcs

· 5 min read

Electron의 API Working Group은 Electron 코어에 대한 주요 변경 사항을 관리하기 위해 공개적인 Requests for Comments (RFC) 프로세스를 도입하고 있다.

RFC가 필요한 이유

간단히 말해, 우리는 Electron 코어에 중대한 변경 사항을 적용하는 과정을 원활하게 만들고자 한다.

현재 새로운 코드 변경은 대부분 GitHub 이슈와 풀 리퀘스트를 통해 논의된다. 대부분의 Electron 변경 사항에 대해 이 시스템은 잘 작동한다. 많은 버그 수정, 문서 변경, 그리고 새로운 기능들은 GitHub의 표준 워크플로우를 통해 비동기적으로 리뷰하고 병합하기에 충분히 직관적이다.

그러나 더 중요한 변경 사항, 예를 들어 큰 API 영역이나 대부분의 Electron 앱에 영향을 미칠 수 있는 호환성 깨짐(breaking changes)과 같은 경우, 코드 대부분이 작성되기 전에 아이디어 단계에서 리뷰가 이루어지는 것이 합리적이다.

이 프로세스는 공개적으로 진행되도록 설계되어 있다. 이를 통해 오픈소스 커뮤니티가 Electron에 반영되기 전에 잠재적인 변경 사항에 대해 피드백을 제공하기가 더 쉬워진다.

동작 원리

전체 RFC 프로세스는 GitHub의 electron/rfcs 저장소에서 관리된다. 각 단계는 저장소의 README에 자세히 설명되어 있다.

간단히 설명하면, RFC는 electron/rfcs 저장소에 PR이 생성되면 Proposed 상태가 된다. Proposed RFC는 다음과 같이 변한다:

  • Active: PR이 저장소의 main 브랜치로 병합되면 Active 상태가 된다. 이는 Electron 관리자가 electron/electron에서 구현을 허용한다는 의미다.
  • Declined: PR이 최종적으로 거부되면 Declined 상태가 된다.
info

RFC가 Active 상태가 되려면, PR이 최소 2명의 API Working Group 멤버로부터 승인을 받아야 한다. 병합 전에 RFC는 동기화된 회의에서 발표되어야 하며, WG 멤버 중 최소 3분의 2 이상의 합의를 얻어야 한다. 합의가 이루어지면 1개월의 최종 코멘트 기간이 시작되며, 이 기간이 끝나면 PR이 병합된다.

Active 상태의 RFC는 구현이 electron/electron에 병합되면 Completed 상태가 된다.

누가 참여할 수 있나요?

Electron 커뮤니티의 누구나 electron/rfcs 저장소에 RFC를 제출하거나 피드백을 남길 수 있습니다!

이 과정을 양방향 대화로 만들고, 커뮤니티의 참여를 장려하여 향후 이러한 API를 사용할 수 있는 Electron 앱으로부터 다양한 의견을 수집하고자 합니다. 현재 제안된 RFC에 피드백을 남기고 싶다면, Electron 메인테이너들이 이미 몇 가지를 작성해 두었습니다:

크레딧

Electron의 RFC 프로세스는 여러 오픈소스 RFC 프로세스를 참고하여 설계되었다. 아이디어와 주요 문구 작성에 영감을 준 프로젝트는 다음과 같다:

runAsNode CVEs 관련 성명

· 7 min read

오늘 Electron 팀은 여러 유명 Electron 앱에 대해 최근 제출된 여러 공개 CVE에 대해 알림을 받았다. 이 CVE들은 Electron의 두 가지 퓨즈(fuse)runAsNodeenableNodeCliInspectArguments와 관련되어 있으며, 이 퓨즈들이 명시적으로 비활성화되지 않은 경우 원격 공격자가 이를 통해 임의의 코드를 실행할 수 있다고 잘못 주장하고 있다.

우리는 이 CVE들이 순수한 의도로 제출되었다고 보지 않는다. 첫째, 해당 주장은 사실이 아니다. 이 설정은 원격 코드 실행을 허용하지 않는다. 둘째, 이 CVE에서 언급된 회사들은 버그 바운티 프로그램을 운영하고 있음에도 불구하고 사전에 통보를 받지 못했다. 마지막으로, 해당 퓨즈를 비활성화하는 것이 앱 보안을 강화하는 데 도움이 된다고 생각하지만, 이 CVE들이 올바른 심각도로 제출되었다고 보지 않는다. "위험(Critical)" 등급은 가장 심각한 문제에만 적용되어야 하며, 이 경우는 해당되지 않는다.

누구나 CVE를 요청할 수 있다. 이는 소프트웨어 산업 전반의 건강에 도움이 되지만, 단일 보안 연구원의 평판을 높이기 위해 CVE를 남발하는 것은 도움이 되지 않는다.

그러나, 위험(Critical)이라는 심각도가 붙은 CVE가 존재한다는 사실만으로도 최종 사용자들이 혼란을 느낄 수 있다는 점을 이해한다. 따라서 프로젝트로서 이 문제를 해결하기 위한 지침과 지원을 제공하고자 한다.

이 문제가 나에게 어떤 영향을 미칠까?

Electron 팀은 이 CVE(공통 취약점 및 노출)가 심각하지 않다고 판단했다. 공격자는 이미 하드웨어에 물리적으로 접근하거나 원격 코드 실행을 완료한 상태여야 한다. 다시 말해, 이 취약점을 악용하려면 공격자가 이미 해당 시스템에 접근할 수 있어야 한다.

예를 들어, Chrome은 물리적 접근 공격을 위협 모델에서 고려하지 않는다:

Chrome(또는 어떤 애플리케이션도)은 사용자로 로그인하거나 운영체제 사용자 계정 권한으로 소프트웨어를 실행할 수 있는 악의적인 사용자로부터 방어할 방법이 없다. 따라서 이러한 공격은 Chrome의 위협 모델에서 제외한다. 이런 공격자는 실행 파일과 DLL을 수정하거나, PATH와 같은 환경 변수를 변경하거나, 설정 파일을 바꾸고, 사용자 계정이 소유한 모든 데이터를 읽어 이메일로 보낼 수 있다. 공격자는 디바이스를 완전히 통제하며, Chrome이 할 수 있는 일로는 심각한 방어를 보장할 수 없다. 이 문제는 Chrome에만 국한되지 않는다. 모든 애플리케이션은 물리적으로 접근 가능한 사용자를 신뢰할 수밖에 없다.

CVE에 설명된 익스플로잇은 공격자가 영향을 받는 앱을 상속된 TCC 권한을 가진 일반적인 Node.js 프로세스로 사용할 수 있게 한다. 예를 들어, 앱이 주소록에 접근할 수 있는 권한을 가지고 있다면, 공격자는 앱을 Node.js로 실행해 주소록 접근 권한을 상속받는 임의의 코드를 실행할 수 있다. 이는 일반적으로 "Living off the Land" 공격으로 알려져 있다. 공격자는 주로 PowerShell, Bash 또는 유사한 도구를 사용해 임의의 코드를 실행한다.

내 애플리케이션도 영향을 받을까?

기본적으로 모든 Electron 릴리스 버전은 runAsNodeenableNodeCliInspectArguments 기능이 활성화된 상태로 제공된다. Electron Fuses 문서에 설명된 대로 이 기능들을 비활성화하지 않았다면, 여러분의 애플리케이션도 "Living off the Land" 공격에 취약할 수 있다. 다시 강조하지만, 공격자가 피해자의 머신에서 코드와 프로그램을 실행할 수 있어야만 이런 공격이 가능하다는 점을 명심해야 한다.

문제 완화 방법

이 문제를 해결하는 가장 쉬운 방법은 Electron 앱 내에서 runAsNode 퓨즈를 비활성화하는 것이다. runAsNode 퓨즈는 ELECTRON_RUN_AS_NODE 환경 변수를 적용할지 여부를 결정한다. 이 퓨즈를 조작하는 방법은 Electron Fuses 문서에서 확인할 수 있다.

이 퓨즈를 비활성화하면 메인 프로세스에서 process.fork가 정상적으로 동작하지 않는다. 이 함수는 해당 환경 변수에 의존하기 때문이다. 대신, 독립적인 Node.js 프로세스가 필요한 경우(예: Sqlite 서버 프로세스 등) Utility Processes를 사용하는 것을 권장한다.

Electron 앱의 보안 모범 사례에 대한 자세한 내용은 보안 체크리스트에서 확인할 수 있다.

Electron 28.0.0

· 6 min read

Electron 28.0.0이 출시되었습니다! 이번 버전은 Chromium 120.0.6099.56, V8 12.0, 그리고 Node.js 18.18.2로 업그레이드되었습니다.


Electron 팀은 Electron 28.0.0 출시를 기쁘게 발표합니다. npm install electron@latest 명령어를 통해 npm으로 설치하거나 릴리스 웹사이트에서 직접 다운로드할 수 있습니다. 이번 릴리스에 대한 자세한 내용은 계속해서 읽어보세요.

여러분의 피드백은 트위터마스토돈을 통해 공유하거나, 커뮤니티 디스코드에 참여해 주세요. 버그 및 기능 요청은 Electron의 이슈 트래커에 보고할 수 있습니다.

주요 변경 사항

하이라이트

  • ECMAScript 모듈(ESM) 지원을 구현했다. (ECMAScript 모듈이란 무엇인가? 여기서 자세히 알아보기). 이는 Electron 자체뿐만 아니라 UtilityProcess API 진입점과 같은 영역에서도 ESM을 지원한다. 자세한 내용은 ESM 문서를 참고한다.
  • Electron 자체에서 ESM 지원을 활성화하는 것 외에도, Electron Forge도 ESM을 사용해 Electron 애플리케이션을 패키징, 빌드, 개발하는 것을 지원한다. 이 기능은 Forge v7.0.0 이상에서 사용할 수 있다.

스택 변경 사항

새로운 기능

  • ESM 지원 활성화. #37535
  • UtilityProcess API에 ESM 진입점 추가. #40047
  • display 객체에 detected, maximumCursorSize, nativeOrigin 등 여러 속성 추가. #40554
  • 리눅스에서 ELECTRON_OZONE_PLATFORM_HINT 환경 변수 지원 추가. #39792

주요 변경 사항

동작 변경: WebContents.backgroundThrottling을 false로 설정하면 호스트 BrowserWindow 내의 모든 WebContents에 영향을 미침

WebContents.backgroundThrottling을 false로 설정하면 해당 BrowserWindow에 표시된 모든 WebContents의 프레임 스로틀링이 비활성화된다.

제거됨: BrowserWindow.setTrafficLightPosition(position)

BrowserWindow.setTrafficLightPosition(position)은 더 이상 사용되지 않는다. 대신 BrowserWindow.setWindowButtonPosition(position) API를 사용해야 한다. 이 새로운 API는 위치를 시스템 기본값으로 재설정하기 위해 { x: 0, y: 0 } 대신 null을 인자로 받는다.

// Electron 28에서 제거됨
win.setTrafficLightPosition({ x: 10, y: 10 });
win.setTrafficLightPosition({ x: 0, y: 0 });

// 대체 코드
win.setWindowButtonPosition({ x: 10, y: 10 });
win.setWindowButtonPosition(null);

제거됨: BrowserWindow.getTrafficLightPosition()

BrowserWindow.getTrafficLightPosition() 메서드가 제거되었다. 이제는 BrowserWindow.getWindowButtonPosition() API를 사용해야 한다. 이 메서드는 커스텀 위치가 없을 때 { x: 0, y: 0 } 대신 null을 반환한다.

// Electron 28에서 제거됨
const pos = win.getTrafficLightPosition();
if (pos.x === 0 && pos.y === 0) {
// 커스텀 위치가 없음.
}

// 대체 코드
const ret = win.getWindowButtonPosition();
if (ret === null) {
// 커스텀 위치가 없음.
}

삭제됨: ipcRenderer.sendTo()

ipcRenderer.sendTo() API가 삭제되었다. 이 기능은 두 렌더러 사이에 MessageChannel을 설정하여 대체해야 한다.

IpcRendererEventsenderIdsenderIsMainFrame 속성도 함께 삭제되었다.

제거됨: app.runningUnderRosettaTranslation

app.runningUnderRosettaTranslation 프로퍼티가 제거되었다.
대신 app.runningUnderARM64Translation을 사용한다.

// 제거됨
console.log(app.runningUnderRosettaTranslation);
// 대체 코드
console.log(app.runningUnderARM64Translation);

25.x.y 버전 지원 종료

Electron 25.x.y 버전은 프로젝트의 지원 정책에 따라 지원이 종료되었다. 개발자와 애플리케이션은 더 새로운 버전의 Electron으로 업그레이드하는 것을 권장한다.

E28 (2023년 12월)E29 (2024년 2월)E30 (2024년 4월)
28.x.y29.x.y30.x.y
27.x.y28.x.y29.x.y
26.x.y27.x.y28.x.y

다음 단계

단기적으로는 Electron 팀이 Chromium, Node, V8과 같은 주요 컴포넌트의 개발 속도를 따라잡는 데 계속 집중할 것으로 예상된다.

Electron의 공개 타임라인은 여기에서 확인할 수 있다.

향후 변경 사항에 대한 더 자세한 정보는 예정된 주요 변경 사항 페이지에서 찾아볼 수 있다.

Ecosystem 2023 Recap

· 10 min read

2023년 Electron 개발자 생태계의 개선과 변화를 돌아보며


지난 몇 달 동안, 우리는 Electron 앱의 개발자 경험을 한층 더 강화하기 위해 Electron 생태계 전반에 걸쳐 다양한 변화를 준비해 왔다. Electron HQ에서 직접 전해드리는 최신 업데이트를 간략히 소개한다.

Electron Forge 7 그리고 그 이후

Electron Forge 7 — Electron 애플리케이션을 패키징하고 배포하기 위한 올인원 도구의 최신 메이저 버전 — 이 출시되었다.

Forge 6가 v5에서 완전히 재작성된 것과 달리, v7은 범위가 더 작지만 여전히 몇 가지 주요 변경 사항이 포함되어 있다. 앞으로는 주요 변경이 필요할 때마다 Forge의 메이저 버전을 계속 출시할 계획이다.

더 자세한 내용은 GitHub의 전체 Forge v7.0.0 변경 로그를 참고한다.

주요 변경 사항

  • macOS notarization을 위해 notarytool로 전환: 2023-11-01부터 Apple은 기존의 altool을 더 이상 지원하지 않으며, 이번 릴리스에서는 Electron Forge에서 완전히 제거했다.

  • 최소 Node.js 버전을 v16.4.0으로 상향: 이번 릴리스부터는 Node.js 버전 16.4.0 이상이 필수 요구 사항이다.

  • electron-prebuiltelectron-prebuilt-compile 지원 중단: electron-prebuiltElectron의 npm 모듈 초기 이름이었지만, v1.3.1부터 electron으로 대체되었다. electron-prebuilt-compile은 향상된 개발자 경험(DX) 기능을 제공하는 대안이었으나, 프로젝트로 더 이상 유지되지 않았다.

주요 내용

  • Google Cloud Storage publisher: 정적 자동 업데이트를 더 잘 지원하기 위해, Electron Forge가 이제 Google Cloud Storage에 직접 게시할 수 있게 되었다!
  • ESM forge.config.js 지원: Electron Forge가 이제 ESM forge.config.js 파일을 지원한다. (추가로, Electron 28에서 ESM 진입점 지원을 기대해도 좋다.)
  • Makers의 병렬 실행: Electron Forge 6에서 Makers는 ✨레거시✨ 이유로 순차적으로 실행되었다. 이후 Make 단계의 병렬화를 테스트한 결과 부작용 없이 성공했기 때문에, 같은 플랫폼에서 여러 타겟을 빌드할 때 속도가 빨라질 것이다!
감사합니다!

🙇 GCS Publisher와 Forge 구성에서의 ESM 지원을 위해 기여해 주신 **mahnunchik**에게 큰 감사를 드립니다!

더 나은 정적 저장소 기반 자동 업데이트

Squirrel.Windows와 Squirrel.Mac은 Electron의 내장 autoUpdater 모듈을 지원하는 플랫폼별 업데이트 기술이다. 두 프로젝트는 두 가지 방법으로 자동 업데이트를 제공한다:

  • Squirrel과 호환되는 업데이트 서버
  • 정적 저장소 프로바이더(예: AWS, Google Cloud Platform, Microsoft Azure 등)에 호스팅된 매니페스트 URL

업데이트 서버 방식은 전통적으로 Electron 앱에 권장되는 접근 방식이었으며, 업데이트 로직을 추가로 커스터마이징할 수 있다. 하지만 이 방식은 주요 단점이 있다. 클로즈드 소스 앱인 경우 자체 서버 인스턴스를 유지해야 한다.

반면, 정적 저장소 방식은 항상 가능했지만 Electron 내에서 문서화되지 않았고, Electron 도구 패키지 전반에서 지원이 미흡했다.

@MarshallOfSound의 훌륭한 작업 덕분에 서버리스 자동 앱 업데이트가 크게 간소화되었다:

  • Electron Forge의 Zip 및 Squirrel.Windows 메이커를 이제 autoUpdater와 호환되는 업데이트 매니페스트를 출력하도록 구성할 수 있다.
  • update-electron-app의 새로운 메이저 버전(v2.0.0)은 이제 생성된 매니페스트를 update.electronjs.org 서버의 대안으로 읽을 수 있다.

메이커와 퍼블리셔가 클라우드 파일 저장소에 업데이트 매니페스트를 업로드하도록 구성되면, 몇 줄의 설정만으로 자동 업데이트를 활성화할 수 있다:

const { updateElectronApp, UpdateSourceType } = require('update-electron-app');

updateElectronApp({
updateSource: {
type: UpdateSourceType.StaticStorage,
baseUrl: `https://my-manifest.url/${process.platform}/${process.arch}`,
},
});
추가 자료

📦 더 알고 싶다면? 자세한 가이드는 Forge의 자동 업데이트 문서를 참고하자.

@electron/ 확장 생태계

Electron이 처음 시작되었을 때, 커뮤니티는 Electron 앱을 개발하고, 패키징하며, 배포하는 과정을 개선하기 위해 다양한 패키지를 출시했다. 시간이 지나면서 이러한 패키지 중 상당수가 Electron의 GitHub 조직으로 통합되었고, 핵심 팀이 유지보수를 담당하게 되었다.

2022년부터는 이러한 퍼스트파티 도구들을 npm의 @electron/ 네임스페이스 아래로 통합하기 시작했다. 이 변경으로 인해 electron-foo로 불리던 패키지들은 이제 npm에서 @electron/foo로, electron/electron-foo로 명명되던 저장소들은 GitHub에서 electron/foo로 변경되었다. 이러한 변화는 퍼스트파티 프로젝트와 사용자 프로젝트를 명확히 구분하는 데 도움을 준다. 여기에는 다음과 같이 널리 사용되는 패키지들이 포함된다:

  • @electron/asar
  • @electron/fuses
  • @electron/get
  • @electron/notarize
  • @electron/osx-sign
  • @electron/packager
  • @electron/rebuild
  • @electron/remote
  • @electron/symbolicate-mac
  • @electron/universal

앞으로 출시될 모든 퍼스트파티 패키지도 @electron/ 네임스페이스 아래에 포함될 예정이다. 이 규칙에는 두 가지 예외가 있다:

  • Electron 코어는 계속해서 electron 패키지로 출시된다.
  • Electron Forge는 모든 모노레포 패키지를 @electron-forge/ 네임스페이스 아래에 출시한다.
스타 요청

⭐ 이 과정에서 실수로 electron/packager 저장소를 비공개로 전환했는데, 이로 인해 GitHub 스타 카운트가 초기화되는 부작용이 발생했다(초기화 전에는 9000개 이상이었다). Packager를 활발히 사용 중이라면 ⭐ 스타 ⭐를 눌러주시면 감사하겠다!

@electron/windows-sign 소개

2023년 6월 1일부터 업계 표준이 변경되어 Windows 코드 서명 인증서의 키를 FIPS 호환 하드웨어에 저장해야 한다. 이로 인해 CI 환경에서 빌드와 서명을 진행하는 앱들은 코드 서명 과정이 훨씬 복잡해졌다. 기존의 많은 Electron 도구들은 인증서 파일과 비밀번호를 설정 파라미터로 받아 하드코딩된 로직을 통해 서명을 시도했기 때문이다.

이 문제는 Electron 개발자들에게 공통적인 어려움으로 여겨졌다. 그래서 우리는 macOS에서 @electron/osx-sign가 하는 것처럼 Windows 코드 서명을 독립적인 단계로 분리하는 더 나은 해결책을 개발했다.

현재 이 패키지는 Electron Forge 툴체인에 완전히 통합될 예정이지만, 지금은 독립적으로 사용할 수 있다. npm install --save-dev @electron/windows-sign 명령어를 통해 설치할 수 있으며, 프로그래밍 방식이나 CLI를 통해 활용할 수 있다.

레포지토리의 이슈 트래커에서 여러분의 피드백을 기다린다!

다음은 무엇을 준비할까?

다음 달부터 연말 조용한 기간에 들어간다. 이 기간 동안 2024년에 더 나은 Electron 개발 환경을 만들기 위한 방법을 고민할 예정이다.

개선하고 싶은 부분이나 추가했으면 하는 기능이 있다면 알려주기 바란다!

December Quiet Month (Dec'23)

· 3 min read

Electron 프로젝트는 2023년 12월 한 달 동안 잠시 중단될 예정이며, 2024년 1월에 다시 본격적으로 진행될 예정이다.

via GIPHY


12월에도 변하지 않을 것들

  1. 제로데이 및 기타 주요 보안 관련 릴리즈는 필요에 따라 공개된다. 보안 문제는 SECURITY.md를 통해 보고해야 한다.
  2. 행동 강령에 대한 보고와 조치는 계속 이어질 것이다.

12월에 달라지는 점

  1. Electron 28.0.0이 12월 5일에 출시된다. Electron 28 이후, 12월 동안 새로운 안정 버전은 출시되지 않는다.
  2. 12월 마지막 2주 동안 Nightly 및 Alpha 버전이 출시되지 않는다.
  3. 몇 가지 예외를 제외하고, 풀 리퀘스트 리뷰나 병합이 이루어지지 않는다.
  4. 모든 저장소에서 이슈 트래커 업데이트가 없다.
  5. 메인테이너들이 Discord에서 디버깅 도움을 제공하지 않는다.
  6. 소셜 미디어 콘텐츠 업데이트가 없다.

앞으로의 계획

조용한 기간 실험을 진행한 지 이제 3년 차가 되었다. 지금까지 한 달간의 휴식과 그 후 정상적인 릴리즈 주기를 유지하는 데 있어서 많은 성과를 거두었다. 따라서 이제 이 실험을 정규 릴리즈 캘린더의 일부로 정기화하기로 결정했다. 매년 마지막 안정 버전 릴리즈 시에 여전히 알림을 추가할 예정이다.

2024년에 다시 만나자!

Electron 27.0.0

· 6 min read

Electron 27.0.0이 출시되었습니다! 이번 버전은 Chromium 118.0.5993.32, V8 11.8, 그리고 Node.js 18.17.1로 업그레이드되었습니다.


Electron 팀은 Electron 27.0.0 출시를 발표하게 되어 기쁩니다. npm install electron@latest 명령어를 통해 npm으로 설치하거나 릴리스 웹사이트에서 다운로드할 수 있습니다. 이번 릴리스에 대한 자세한 내용은 계속 읽어보세요.

피드백이 있다면 TwitterMastodon을 통해 공유하거나, 커뮤니티 Discord에 참여해 주세요. 버그나 기능 요청은 Electron의 이슈 트래커에 보고할 수 있습니다.

주요 변경 사항

스택 변경 사항

주요 변경 사항

삭제: macOS 10.13 / 10.14 지원 중단

macOS 10.13 (High Sierra)와 macOS 10.14 (Mojave)는 더 이상 Chromium에서 지원하지 않는다.

이전 버전의 Electron은 해당 운영체제에서 계속 실행할 수 있지만, Electron v27.0.0 이상 버전을 실행하려면 macOS 10.15 (Catalina) 이상이 필요하다.

더 이상 사용되지 않음: ipcRenderer.sendTo()

ipcRenderer.sendTo() API는 더 이상 사용되지 않는다. 이제는 두 렌더러 사이에 MessageChannel을 설정해 사용해야 한다.

IpcRendererEventsenderIdsenderIsMainFrame 속성도 더 이상 사용되지 않는다.

제거됨: systemPreferences의 컬러 스킴 이벤트

다음 systemPreferences 이벤트가 제거됐다:

  • inverted-color-scheme-changed
  • high-contrast-color-scheme-changed

대신 nativeTheme 모듈의 새로운 updated 이벤트를 사용한다.

// 제거됨
systemPreferences.on('inverted-color-scheme-changed', () => {
/* ... */
});
systemPreferences.on('high-contrast-color-scheme-changed', () => {
/* ... */
});

// 대체 코드
nativeTheme.on('updated', () => {
/* ... */
});

제거됨: webContents.getPrinters

webContents.getPrinters 메서드는 더 이상 사용되지 않는다. 대신 webContents.getPrintersAsync를 사용한다.

const w = new BrowserWindow({ show: false });

// 제거됨
console.log(w.webContents.getPrinters());
// 대체 코드
w.webContents.getPrintersAsync().then((printers) => {
console.log(printers);
});

제거된 기능: systemPreferences.{get,set}AppLevelAppearancesystemPreferences.appLevelAppearance

systemPreferences.getAppLevelAppearancesystemPreferences.setAppLevelAppearance 메서드, 그리고 systemPreferences.appLevelAppearance 프로퍼티가 제거되었다. 이제는 nativeTheme 모듈을 사용해야 한다.

// 제거됨
systemPreferences.getAppLevelAppearance();
// 대체 코드
nativeTheme.shouldUseDarkColors;

// 제거됨
systemPreferences.appLevelAppearance;
// 대체 코드
nativeTheme.shouldUseDarkColors;

// 제거됨
systemPreferences.setAppLevelAppearance('dark');
// 대체 코드
nativeTheme.themeSource = 'dark';

제거됨: systemPreferences.getColoralternate-selected-control-text

systemPreferences.getColoralternate-selected-control-text 값이 제거되었다. 대신 selected-content-background를 사용한다.

// 제거됨
systemPreferences.getColor('alternate-selected-control-text');
// 대체
systemPreferences.getColor('selected-content-background');

새로운 기능

  • 앱 접근성 투명도 설정 API 추가 #39631
  • chrome.scripting 확장 API 지원 추가 #39675
  • WaylandWindowDecorations 기본값 활성화 #39644

24.x.y 지원 종료 안내

Electron 24.x.y는 프로젝트의 지원 정책에 따라 지원이 종료되었다. 개발자와 애플리케이션은 더 새로운 버전의 Electron으로 업그레이드하는 것을 권장한다.

E27 (2023년 10월)E28 (2023년 12월)E29 (2024년 2월)
27.x.y28.x.y29.x.y
26.x.y27.x.y28.x.y
25.x.y26.x.y27.x.y

22.x.y 버전의 확장 지원 종료

올해 초, Electron 팀은 Windows 7/8/8.1에 대한 Chrome의 확장 지원 기간과 맞추기 위해 Electron 22의 지원 종료 예정일을 2023년 5월 30일에서 2023년 10월 10일로 연장했다. 자세한 내용은 Windows 7/8/8.1 지원 종료 공지를 참고하면 된다.

Electron 22.x.y는 프로젝트의 지원 정책과 이번 확장 지원에 따라 지원이 종료되었다. 이로 인해 지원 범위가 최신 3개의 안정적인 메이저 버전으로 축소되었으며, Windows 7/8/8.1에 대한 공식 지원도 종료되었다.

다음 단계

앞으로도 Electron 팀은 Chromium, Node, V8 등 주요 컴포넌트의 개발 속도를 따라가기 위해 계속 노력할 것이다.

Electron의 공개 타임라인에서 더 자세한 정보를 확인할 수 있다.

향후 예정된 변경 사항에 대한 자세한 내용은 Planned Breaking Changes 페이지에서 찾아볼 수 있다.

Breach to Barrier: Strengthening Apps with the Sandbox

· 8 min read

CVE-2023-4863: WebP의 힙 버퍼 오버플로우가 공개된 지 일주일이 넘었고, 이로 인해 webp 이미지를 렌더링하는 소프트웨어의 새로운 버전이 속속 출시되었다. macOS, iOS, Chrome, Firefox, 그리고 다양한 리눅스 배포판 모두 업데이트를 받았다. 이는 Citizen Lab의 조사에 따른 것으로, "워싱턴 DC에 기반을 둔 시민 사회 조직"이 사용하는 iPhone이 iMessage 내부의 제로 클릭 익스플로잇을 통해 공격받고 있음을 발견한 결과였다.

Electron 또한 이에 대응해 같은 날 새로운 버전을 출시했다. 만약 여러분의 앱이 사용자가 제공한 콘텐츠를 렌더링한다면, Electron 버전을 업데이트해야 한다. v27.0.0-beta.2, v26.2.1, v25.8.1, v24.8.3, 그리고 v22.3.24 버전 모두 webp 이미지 렌더링을 담당하는 libwebp 라이브러리의 수정된 버전을 포함하고 있다.

이제 "이미지 렌더링"과 같이 무해해 보이는 상호작용도 잠재적으로 위험한 활동일 수 있다는 사실을 모두가 새롭게 인지하게 되었다. 이 기회를 통해 Electron이 프로세스 샌드박스를 제공하여 다음 대규모 공격의 피해 범위를 제한할 수 있다는 점을 상기시키고자 한다. 이 공격이 무엇이든 간에 말이다.

샌드박스는 Electron v1부터 사용 가능했고, v20부터는 기본적으로 활성화되었다. 하지만 많은 앱(특히 오랫동안 사용되어 온 앱)이 코드 어딘가에 sandbox: false를 설정했거나, nodeIntegration: true를 설정하여 명시적인 sandbox 설정이 없을 때 샌드박스를 비활성화했을 가능성이 있다. 이는 이해할 수 있다. 오랫동안 Electron을 사용해왔다면, HTML/CSS를 실행하는 동일한 코드에 require("child_process")require("fs")를 추가하는 강력한 기능을 즐겼을 것이다.

샌드박스로 마이그레이션하는 방법에 대해 이야기하기 전에, 먼저 샌드박스를 사용해야 하는지 논의해보자.

샌드박스는 모든 렌더러 프로세스 주위에 견고한 케이지를 둔다. 이는 내부에서 무슨 일이 일어나든 코드가 제한된 환경 내에서 실행되도록 보장한다. 이 개념은 Chromium보다 훨씬 오래되었으며, 모든 주요 운영체제에서 기능으로 제공된다. Electron과 Chromium의 샌드박스는 이러한 시스템 기능 위에 구축된다. 사용자 생성 콘텐츠를 표시하지 않더라도, 렌더러가 손상될 가능성을 고려해야 한다. 공급망 공격과 같은 정교한 시나리오부터 작은 버그까지, 렌더러가 의도하지 않은 동작을 할 수 있다.

샌드박스는 이러한 시나리오를 훨씬 덜 무섭게 만든다. 내부 프로세스는 CPU 사이클과 메모리를 자유롭게 사용할 수 있지만, 그 이상의 권한은 없다. 프로세스는 디스크에 쓸 수도 없고, 자신의 윈도우를 표시할 수도 없다. libwebp 버그의 경우, 샌드박스는 공격자가 악성코드를 설치하거나 실행할 수 없도록 보장한다. 사실, 직원의 iPhone을 대상으로 한 원래의 Pegasus 공격에서, 공격자는 일반적으로 샌드박스된 iMessage의 경계를 벗어나기 위해 비 샌드박스된 이미지 프로세스를 특정적으로 타겟팅했다. 이 예제와 같은 CVE가 발표되면, 여전히 Electron 앱을 안전한 버전으로 업그레이드해야 하지만, 그동안 공격자가 할 수 있는 피해의 양은 크게 제한된다.

sandbox: false에서 sandbox: true로 바닐라 Electron 애플리케이션을 마이그레이션하는 것은 상당한 작업이다. 나는 Electron 보안 가이드라인의 초안을 직접 작성했음에도 불구하고, 내 앱 중 하나를 마이그레이션하지 못했음을 알고 있다. 이번 주말에 그 작업을 마쳤고, 여러분도 그렇게 하기를 권장한다.

라인 변경 수에 겁먹지 마세요. 대부분은 package-lock.json에 있습니다.

두 가지 작업을 해야 한다:

  1. preload 스크립트나 실제 WebContents에서 Node.js 코드를 사용하고 있다면, 모든 Node.js 상호작용을 메인 프로세스(또는, 고급스럽게 유틸리티 프로세스)로 옮겨야 한다. 렌더러가 얼마나 강력해졌는지 고려하면, 대부분의 코드는 리팩토링이 필요하지 않을 가능성이 높다.

    프로세스 간 통신에 대한 문서를 참고하라. 내 경우에는 많은 코드를 옮기고 ipcRenderer.invoke()ipcMain.handle()로 감쌌지만, 과정은 직관적이었고 빠르게 완료되었다. 여기서 API에 대해 조금 신경 써야 한다. 만약 executeCodeAsRoot(code)와 같은 API를 만든다면, 샌드박스가 사용자를 크게 보호해주지 못할 것이다.

  2. 샌드박스를 활성화하면 preload 스크립트에서 Node.js 통합이 비활성화되므로, 더 이상 require("../my-script")를 사용할 수 없다. 즉, preload 스크립트는 단일 파일이어야 한다.

    이를 위한 여러 방법이 있다: Webpack, esbuild, parcel, 그리고 rollup 모두 이 작업을 처리할 수 있다. 나는 Electron Forge의 훌륭한 Webpack 플러그인을 사용했고, electron-builder의 사용자는 electron-webpack을 사용할 수 있다.

전체적으로 이 과정은 약 4일이 걸렸다. Webpack의 강력한 기능을 어떻게 다룰지 고민하는 시간도 포함되었는데, 이 기회를 통해 코드를 다른 방식으로도 리팩토링하기로 결정했기 때문이다.

Electron 26.0.0

· 4 min read

Electron 26.0.0이 출시되었습니다! 이번 버전은 Chromium 116.0.5845.62, V8 11.2, 그리고 Node.js 18.16.1로 업그레이드되었습니다. 자세한 내용은 아래를 참고하세요!


Electron 팀은 Electron 26.0.0 출시를 기쁘게 발표합니다! npm install electron@latest 명령어를 통해 npm으로 설치하거나, 릴리스 웹사이트에서 직접 다운로드할 수 있습니다. 이번 릴리스에 대한 자세한 내용은 계속해서 읽어보세요.

피드백이 있다면 Twitter를 통해 공유하거나, 우리의 커뮤니티 Discord에 참여해 주세요. 버그 및 기능 요청은 Electron의 이슈 트래커에 보고할 수 있습니다.

주요 변경 사항

스택 변경

주요 변경 사항

더 이상 사용되지 않는 기능: webContents.getPrinters

webContents.getPrinters 메서드는 더 이상 사용되지 않는다. 대신 webContents.getPrintersAsync를 사용한다.

const w = new BrowserWindow({ show: false });

// 더 이상 사용되지 않음
console.log(w.webContents.getPrinters());
// 대체 방법
w.webContents.getPrintersAsync().then((printers) => {
console.log(printers);
});

더 이상 사용되지 않음: systemPreferences.{get,set}AppLevelAppearancesystemPreferences.appLevelAppearance

systemPreferences.getAppLevelAppearancesystemPreferences.setAppLevelAppearance 메서드, 그리고 systemPreferences.appLevelAppearance 속성은 더 이상 사용되지 않는다. 이제 nativeTheme 모듈을 사용해야 한다.

// 더 이상 사용되지 않음
systemPreferences.getAppLevelAppearance();
// 대체 방법
nativeTheme.shouldUseDarkColors;

// 더 이상 사용되지 않음
systemPreferences.appLevelAppearance;
// 대체 방법
nativeTheme.shouldUseDarkColors;

// 더 이상 사용되지 않음
systemPreferences.setAppLevelAppearance('dark');
// 대체 방법
nativeTheme.themeSource = 'dark';

더 이상 사용되지 않음: systemPreferences.getColoralternate-selected-control-text

systemPreferences.getColoralternate-selected-control-text 값은 더 이상 사용되지 않는다. 대신 selected-content-background를 사용한다.

// 더 이상 사용되지 않음
systemPreferences.getColor('alternate-selected-control-text');
// 대체 코드
systemPreferences.getColor('selected-content-background');

새로운 기능

  • safeStorage.setUsePlainTextEncryptionsafeStorage.getSelectedStorageBackend API를 추가했다. #39107
  • safeStorage.setUsePlainTextEncryptionsafeStorage.getSelectedStorageBackend API를 추가했다. #39155
  • ipcRenderer.sendTo()를 통해 전송된 메시지에 senderIsMainFrame 속성을 추가했다. #39206
  • 키보드로 시작된 Menu를 플래그로 표시하는 기능을 추가했다. #38954

23.x.y 버전 지원 종료

Electron 23.x.y 버전은 프로젝트의 지원 정책에 따라 지원이 종료되었다. 개발자와 애플리케이션은 더 새로운 버전의 Electron으로 업그레이드하는 것을 권장한다.

E26 (2023년 8월)E27 (2023년 10월)E28 (2024년 1월)
26.x.y27.x.y28.x.y
25.x.y26.x.y27.x.y
24.x.y25.x.y26.x.y
22.x.y

앞으로의 계획

단기적으로, Electron 팀은 Chromium, Node, V8과 같은 주요 컴포넌트의 개발 속도를 따라잡는 데 계속 집중할 예정이다.

Electron의 공개 타임라인은 여기에서 확인할 수 있다.

향후 변경 사항에 대한 자세한 정보는 예정된 주요 변경 사항 페이지에서 확인할 수 있다.

Electron 25.0.0

· 8 min read

Electron 25.0.0이 출시되었다! 이번 버전은 Chromium 114, V8 11.4, 그리고 Node.js 18.15.0으로 업그레이드되었다. 자세한 내용은 아래를 참고하자!


Electron 팀은 Electron 25.0.0 출시를 발표하게 되어 기쁘게 생각한다. npm install electron@latest를 통해 npm으로 설치하거나 릴리스 웹사이트에서 직접 다운로드할 수 있다. 이번 릴리스에 대한 자세한 내용은 계속 읽어보자.

피드백이 있다면 Twitter를 통해 공유하거나 Discord 커뮤니티에 참여해 보자. 버그나 기능 요청은 Electron의 이슈 트래커에 보고할 수 있다.

주요 변경 사항

주요 기능

  • Electron의 net 모듈 내에 net.fetch를 구현했다. 이 기능은 Chromium의 네트워킹 스택을 사용한다. Node.js의 HTTP 스택을 사용하는 Node의 fetch()와는 다르다. 자세한 내용은 #36733#36606을 참고한다.

  • protocol.handle을 추가했다. 이는 protocol.{register,intercept}{String,Buffer,Stream,Http,File}Protocol을 대체하며, 기존 기능을 더 이상 사용하지 않도록 권고한다. #36674

  • Electron 22에 대한 지원을 확장했다. 이는 Chromium과 Microsoft의 Windows 7/8/8.1 지원 중단 계획에 맞추기 위함이다. 자세한 내용은 이 블로그 포스트의 끝 부분에서 확인할 수 있다.

스택 변경 사항

주요 변경 사항

사용 중단: protocol.{register,intercept}{Buffer,String,Stream,File,Http}Protocol

protocol.register*Protocolprotocol.intercept*Protocol 메서드는 protocol.handle로 대체되었다.

새로운 메서드는 새로운 프로토콜을 등록하거나 기존 프로토콜을 가로챌 수 있으며, 응답은 어떤 타입이든 가능하다.

// Electron 25에서 사용 중단됨
protocol.registerBufferProtocol('some-protocol', () => {
callback({ mimeType: 'text/html', data: Buffer.from('<h5>Response</h5>') });
});

// 대체 코드
protocol.handle('some-protocol', () => {
return new Response(
Buffer.from('<h5>Response</h5>'), // 문자열이나 ReadableStream도 가능
{ headers: { 'content-type': 'text/html' } },
);
});
// Electron 25에서 사용 중단됨
protocol.registerHttpProtocol('some-protocol', () => {
callback({ url: 'https://electronjs.org' });
});

// 대체 코드
protocol.handle('some-protocol', () => {
return net.fetch('https://electronjs.org');
});
// Electron 25에서 사용 중단됨
protocol.registerFileProtocol('some-protocol', () => {
callback({ filePath: '/path/to/my/file' });
});

// 대체 코드
protocol.handle('some-protocol', () => {
return net.fetch('file:///path/to/my/file');
});

더 이상 사용되지 않음: BrowserWindow.setTrafficLightPosition(position)

BrowserWindow.setTrafficLightPosition(position)은 더 이상 사용되지 않는다. 대신 BrowserWindow.setWindowButtonPosition(position) API를 사용해야 한다. 이 API는 위치를 시스템 기본값으로 재설정할 때 { x: 0, y: 0 } 대신 null을 인자로 받는다.

// Electron 25에서 더 이상 사용되지 않음
win.setTrafficLightPosition({ x: 10, y: 10 });
win.setTrafficLightPosition({ x: 0, y: 0 });

// 대체 코드
win.setWindowButtonPosition({ x: 10, y: 10 });
win.setWindowButtonPosition(null);

더 이상 사용되지 않음: BrowserWindow.getTrafficLightPosition()

BrowserWindow.getTrafficLightPosition()은 더 이상 사용되지 않는다. 이제는 BrowserWindow.getWindowButtonPosition() API를 사용해야 한다. 이 API는 사용자 지정 위치가 없을 때 { x: 0, y: 0 } 대신 null을 반환한다.

// Electron 25에서 더 이상 사용되지 않음
const pos = win.getTrafficLightPosition();
if (pos.x === 0 && pos.y === 0) {
// 사용자 지정 위치가 없음.
}

// 대체 코드
const ret = win.getWindowButtonPosition();
if (ret === null) {
// 사용자 지정 위치가 없음.
}

새로운 기능

  • net.fetch()를 추가했다. #36733
    • net.fetchfile: URL과 protocol.register*Protocol로 등록된 커스텀 프로토콜에 대한 요청을 지원한다. #36606
  • BrowserWindow.set/getWindowButtonPosition API를 추가했다. #37094
  • protocol.handle을 추가하고, protocol.{register,intercept}{String,Buffer,Stream,Http,File}Protocol을 대체하며 더 이상 사용하지 않는다. #36674
  • webContents<webview> 태그에 will-frame-navigate 이벤트를 추가했다. 이 이벤트는 프레임 계층 구조 내의 어떤 프레임이 네비게이션을 시도할 때마다 발생한다. #34418
  • 네비게이션 이벤트에 initiator 정보를 추가했다. 이 정보를 통해 window.open이 부모 프레임에 의해 발생한 것인지, 자식 프레임에 의해 시작된 것인지 구분할 수 있다. #37085
  • net.resolveHost를 추가했다. 이 함수는 defaultSession 객체를 사용해 호스트를 해결한다. #38152
  • app에 새로운 'did-resign-active' 이벤트를 추가했다. #38018
  • webContents.print()에 여러 표준 페이지 크기 옵션을 추가했다. #37159
  • ses.setDisplayMediaRequestHandler() 콜백에 enableLocalEcho 플래그를 추가했다. 이 플래그는 audioWebFrameMain일 때 원격 오디오 입력이 로컬 출력 스트림에서 반향되도록 허용한다. #37315
  • powerMonitor에 열 관리 정보를 추가했다. #38028
  • session.fromPath() API에 절대 경로를 전달할 수 있도록 허용했다. #37604
  • webContentsaudio-state-changed 이벤트를 노출시켰다. #37366

22.x.y 지속 지원

Farewell, Windows 7/8/8.1에서 언급한 바와 같이, Electron 22(Chromium 108)의 종료 예정일은 2023년 5월 30일에서 2023년 10월 10일로 연장된다. Electron 팀은 2023년 10월 10일까지 Electron 22에 대한 보안 수정 사항을 계속해서 백포트할 예정이다. 10월 지원 일정은 Chromium과 Microsoft의 연장된 지원 일정을 따른다. 2023년 10월 11일부터 Electron 팀은 지원을 최신 3개의 안정적인 주요 버전으로 축소할 것이며, 이 버전들은 Windows 7/8/8.1을 더 이상 지원하지 않는다.

E25 (2023년 5월)E26 (2023년 8월)E27 (2023년 10월)
25.x.y26.x.y27.x.y
24.x.y25.x.y26.x.y
23.x.y24.x.y25.x.y
22.x.y22.x.y--

다음은?

단기적으로, Electron 팀은 Chromium, Node, V8 등 Electron을 구성하는 주요 컴포넌트의 개발 동향을 꾸준히 따라가는 데 집중할 것이다.

Electron의 공개 타임라인에서 더 자세한 정보를 확인할 수 있다.

향후 예정된 변경 사항에 대한 자세한 내용은 Planned Breaking Changes 페이지에서 찾아볼 수 있다.