A High severity vulnerability has been discovered in Chrome which affects all software based on Chromium, including Electron.

This vulnerability has been assigned CVE-2019-13720. Vous pouvez en lire d'avantage à ce sujet dans ce billet du Chrome Blog .

Please note that Chrome has reports of this vulnerability being used in the wild so it is strongly recommended you upgrade Electron as soon as possible.

Portée​

This affects any Electron application that may run third-party or untrusted JavaScript.

Atténuation​

Affected apps should upgrade to a patched version of Electron.

Nous avons publié de nouvelles versions d'Electron qui incluent des corrections pour cette vulnérabilité :

• 6.1.4

Electron 7.0.1 automatically included the fix from upstream, before the announcement was made. Electron 8 n'est pas non plus affecté. La vulnérabilité n'existait pas dans Electron 5, cette version n'est donc pas affectée.

Informations complémentaires ​

This vulnerability was discovered by Anton Ivanov and Alexey Kulaev at Kaspersky Labs and reported to the Chrome team. Le billet du blog Chrome peut être trouvé ici.

Pour en savoir plus sur les meilleures pratiques pour sécuriser vos applications Electron, consultez notre tutoriel de sécurité.

Si vous souhaitez signaler une vulnérabilité dans Electron, envoyez un e-mail à security@electronjs.org.

Electron 7.0.0 est disponible ! Il comprend des mises à jour vers Chromium 78, V8 7.8 et Node.js 12.8.1. Sur la version Arm 64, nous avons ajouté une fenêtre , des méthodes IPC plus rapides, une nouvelle API nativeTheme et bien plus encore !

La team Electron est excitée d'annoncer la sortie de Electron 7.0.0 ! Vous pouvez l'installer via npm install electron@latest ou le télécharger depuis notre site officiel. Cette version inclue des mises à jour, des correctifs et de nouvelles fonctionnalités. On a hâte de voir vos prochaines créations avec cette version ! Continuez de lire pour plus de détails sur cette version, et s'il vous plaît, partagez vos commentaires et remarques !

Changements notables​

• Stack Upgrades:

  Stack	Version dans Electron 6	Version dans Electron 7	Quoi de neuf
  Chromium	76.0.3809.146	78.0.3905.1	77, 78
  V8	7.6	7.8	7.7, 7.8
  Node.js	12.4.0	12.8.1	12.5, 12.6, 12.7, 12.8, 12.8.1

• Added Windows on Arm (64 bit) release. #18591, #20112

• Added ipcRenderer.invoke() and ipcMain.handle() for asynchronous request/response-style IPC. These are strongly recommended over the remote module. See this "Electron’s ‘remote’ module considered harmful" blog post for more information. #18449

• Added nativeTheme API to read and respond to changes in the OS's theme and color scheme. #19758, #20486

• Switched to a new TypeScript Definitions generator. The resulting definitions are more precise; so if your TypeScript build fails, this is the likely cause. #18103

See the 7.0.0 release notes for a longer list of changes.

Changements majeurs avec rupture de compatibilité​

Vous trouverez plus d’informations sur ces changements et les changements futurs sur la pagechangements de rupture prévus.

• Removed deprecated APIs:
  • Callback-based versions of functions that now use Promises. #17907
  • Tray.setHighlightMode() (macOS). #18981
  • app.enableMixedSandbox() #17894
  • app.getApplicationMenu(),
  • app.setApplicationMenu(),
  • powerMonitor.querySystemIdleState(),
  • powerMonitor.querySystemIdleTime(),
  • webFrame.setIsolatedWorldContentSecurityPolicy(),
  • webFrame.setIsolatedWorldHumanReadableName(),
  • webFrame.setIsolatedWorldSecurityOrigin() #18159
• Session.clearAuthCache() no longer allows filtering the cleared cache entries. #17970
• Native interfaces on macOS (menus, dialogs, etc.) now automatically match the dark mode setting on the user's machine. #19226
• Updated the electron module to use @electron/get. The minimum supported node version is now Node 8. #18413
• The file electron.asar no longer exists. Any packaging scripts that depend on its existence should be updated. #18577

Fin du support pour 4.x.y​

Electron 4.x.y a atteint la fin du support conformément au projet politique d'assistance. Nous encourageons les développeurs à mettre à jour vers une version plus récente d'Electron et de faire de même avec leurs applications.

Programme de feedback​

We continue to use our App Feedback Program for testing. Projects who participate in this program test Electron betas on their apps; and in return, the new bugs they find are prioritized for the stable release. If you'd like to participate or learn more, check out our blog post about the program.

Et maintenant ?​

À court terme, vous pouvez compter sur l’équipe pour continuer a se concentrer sur le développement des principaux composants qui composent Electron, notamment Chromium, Node et V8. Bien que nous veillions à ne pas faire de promesses à propos des dates de publication, notre plan est la sortie de nouvelles versions majeures d'Electron avec de nouvelles versions de ces composants environ un trimestre. Le planning escompté de la version 8.0.0 planning défini les dates clés du cycle de vie de développement d'Electron 8. Aussi, regardez notre document de versioning pour plus d'informations sur le versioning dans Electron.

Pour des informations sur les changements de rupture prévus dans les versions à venir d'Electron, regardez notre documentation sur les changements de rupture planifiés.

La team Electron est excitée d'annoncer la sortie de Electron 6.0.0 ! Vous pouvez l'installer via npm install electron@latest ou le télécharger depuis notre site officiel. Cette version inclue des mises à jour, des correctifs et de nouvelles fonctionnalités. On a hâte de voir vos prochaines créations avec cette version ! Continuez de lire pour plus de détails sur cette version, et s'il vous plaît, partagez vos commentaires et remarques !

Quoi de neuf​

Today marks a first for the Electron project: this is the first time we've made a stable Electron release on the same day as the corresponding Chrome stable release! 🎉

Much of Electron's functionality is provided by the core components of Chromium, Node.js, and V8. Electron keeps up-to-date with these projects to provide our users with new JavaScript features, performance improvements, and security fixes. Each of these packages has a major version bump in Electron 6:

• Chromium 76.0.3809.88
  • New in 74
  • New in 75
  • New in 76
• Node.js 12.4.0
  • Article de blog sur Node 12.4.0
• V8 7.6.303.22
  • Article de blog sur V8 7.6

This release also includes improvements to Electron's APIs. The release notes have a more complete list, but here are the highlights:

Promisification​

Electron 6.0 continues the modernization initiative started in 5.0 to improve Promise support.

These functions now return Promises and still support older callback-based invocation:

• contentTracing.getCategories() #16583
• contentTracing.getCategories() #16583
• contentTracing.getTraceBufferUsage() #16600
• contents.executeJavaScript() #17312
• cookies.flushStore() #16464
• cookies.get() #16464
• cookies.remove() #16464
• cookies.set() #16464
• dialog.showCertificateTrustDialog() #17181
• inAppPurchase.getProducts() #17355
• inAppPurchase.purchaseProduct()#17355
• netLog.stopLogging() #16862
• session.clearAuthCache() #17259
• session.clearCache() #17185
• session.clearHostResolverCache() #17229
• session.clearStorageData() #17249
• session.getBlobData() #17303
• session.getCacheSize() #17185
• session.resolveProxy() #17222
• session.setProxy() #17222
• webContents.hasServiceWorker() #16535
• webContents.printToPDF() #16795
• webContents.savePage() #16742
• webFrame.executeJavaScript() #17312
• webFrame.executeJavaScriptInIsolatedWorld() #17312
• webviewTag.executeJavaScript() #17312

Ces fonctions ont maintenant deux formes, synchrone et asynchrone basées sur Promise :

• dialog.showMessageBox()/dialog.showMessageBoxSync() #17298
• dialog.showOpenDialog()/dialog.showOpenDialogSync() #16973
• dialog.showSaveDialog()/dialog.showSaveDialogSync() #17054

These functions now return Promises:

• app.dock.show() #16904

Electron Helper (Renderer).app, Electron Helper (GPU).app and Electron Helper (Plugin).app​

In order to enable the hardened runtime, which restricts things like writable-executable memory and loading code signed by a different Team ID, special code signing entitlements needed to be granted to the Helper.

To keep these entitlements scoped to the process types that require them, Chromium added three new variants of the Helper app: one for renderers (Electron Helper (Renderer).app), one for the GPU process (Electron Helper (GPU).app) and one for plugins (Electron Helper (Plugin).app).

Folks using electron-osx-sign to codesign their Electron app shouldn't have to make any changes to their build logic. Si vous coconcevez votre application avec des scripts personnalisés, vous devriez vous assurer que les trois nouvelles applications Helper sont correctement codées.

Afin d'empaqueter correctement votre application avec ces nouveaux helpers, vous devez utiliser electron-packager@14.0.4 ou une version supérieure. Si vous utilisez electron-builder , vous devriez suivre ce problème pour suivre le support de ces nouveaux aides.

Changements majeurs avec rupture de compatibilité​

• Cette version commence à poser les bases d'une future exigence selon laquelle les modules natifs de Node.js chargés dans le processus de rendu soient soit N-API ou Context Aware. Les raisons de ce changement sont des performances plus rapides, une sécurité accrue et une charge de travail de maintenance réduite. Lisez tous les détails, y compris le calendrier proposé dans ce problème. Cette modification devrait être terminée dans Electron v11.

• les headers net.IncomingMessage ont légèrement changé pour correspondre plus étroitement au comportement de Node.js, en particulier avec la valeur de set-cookie et la manière dont les headers en double sont gérés. #17517.

• shell.showItemInFolder()retourne désormais void, est un appel asynchrone. #17121

• Les applications doivent maintenant définir explicitement un chemin de log en appelant la nouvelle fonction app.setAppLogPath() avant d'utiliser app.getPath('log'). #17841

Fin du support pour 3.x.y​

Par notre politique de support, 3.x.y a atteint sa fin de la vie. Nous encourageons les développeurs à mettre à jour vers une version plus récente d'Electron et de faire de même avec leurs applications.

Programme de feedback​

Nous continuons à utiliser notre Programme de Feedback de l'application pour les tests. Les projets qui participent à ce programme testent les bétas d'Electron sur leurs applications ; et en retour, les nouveaux bogues qu'ils trouvent sont priorisés pour la version stable. Si vous souhaitez participer ou en savoir plus, consultez notre blog sur le programme.

Et maintenant ?​

À court terme, vous pouvez compter sur l’équipe pour continuer a se concentrer sur le développement des principaux composants qui composent Electron, notamment Chromium, Node et V8. Bien que nous veillions à ne pas faire de promesses à propos des dates de publication, notre plan est la sortie de nouvelles versions majeures d'Electron avec de nouvelles versions de ces composants environ un trimestre. Le planning escompté de la version 7.0.0 planning défini les dates clés du cycle de vie de développement d'Electron 7. Aussi, regardez notre document de versioning pour plus d'informations sur le versioning dans Electron.

Pour des informations sur les changements de rupture prévus dans les versions à venir d'Electron, regardez notre documentation sur les changements de rupture planifiés.

🎉 Electron sort une nouvelle version stable majeure toutes les 12 semaines ! 🎉

⚡ Wow c'est rapide ! Mais pourquoi?​

En termes simples, Chromium n’arrête pas de livrer des nouvelles versions, donc Electron ne va pas ralentir non plus.

Sorties de Chromium sur un calendrier cohérent de 6 semaines. To deliver the most up-to-date versions of Chromium in Electron, our schedule needs to track theirs. More information around Chromium's release cycle can be found here.

🚀 Pourquoi toutes les 12 semaines?​

Toutes les 6 semaines, une nouvelle version de Chromium est déployée avec de nouvelles fonctionnalités, des corrections de bugs / des correctifs de sécurité et des améliorations de V8. Les utilisateurs d'Electron ont été très insistants et très clairs sur le souhait que ces changements soient effectués dans les plus brefs délais. Nous avons donc adaptés nos dates de publications à celles de Chromium. En premier lieu, la v6.0.0 d'Electron inclura M76 et la version stable est prévue pour le 30 juillet 2019, le même jour que celle de Chromium M76.

🚧 Qu'est-ce que cela signifie pour moi et mon application Electron ?​

Vous aurez accès aux nouvelles fonctionnalités et correctifs de Chromium et V8 plus tôt qu'auparavant. Il est important de noter que vous serez également avertis lorsque ces nouveaux changements arriveront, de sorte que vous serez en mesure de planifier avec de meilleures informations qu’auparavant.

L'équipe d'Electron continuera à supporter les trois dernières versions majeures. Par exemple, lorsque v6.0.0 sera stable le 30 juillet 2019, nous prendrons en charge v6.x, v5.x et v4.x, tandis que v3.x atteindra sa fin de vie.

💬 Programme de feedback​

Ce serait bien d'envisager de rejoindre notre App Feedback Program pour nous aider à tester nos versions bêta et notre stabilisation. Les projets qui participent à ce programme testent les bétas d'Electron sur leurs applications ; et en retour, les nouveaux bogues qu'ils trouvent sont priorisés pour la version stable.

📝 Un bref historique des versions d'Electron​

Les décisions concernant les versions stables avant la version 3.0.0 n’ont pas suivi de calendrier. Nous avons ajouté des calendriers internes au projet avec v3.0.0 et v4.0.0. En début d'année, nous avons décidé de publier pour la première fois la date de version stable Electron v5.0.0. L'annonce de nos dates de publication stable a été bien reçue et nous sommes heureux de continuer à le faire pour les prochaines versions.

Afin de mieux rationaliser ces efforts liés aux mises à niveau, nos groupes de travail Upgrades et Releases ont été créés au sein de notre système Governance. Ils nous ont permis de mieux hiérarchiser et déléguer ce travail, ce qui, nous l'espérons, deviendra plus évident avec chaque version ultérieure.

Voici où notre nouvelle cadence nous placera par rapport à celle de Chromium :

📨 Si vous avez des questions, veuillez nous écrire à info@electronjs.org.

La team Electron est excitée d'annoncer la sortie de Electron 5.0.0 ! You can install it with npm via npm install electron@latest or download the tarballs from our releases page. Cette version inclue des mises à jour, des correctifs et de nouvelles fonctionnalités. On a hâte de voir vos prochaines créations avec cette version ! Continuez de lire pour plus de détails sur cette version, et s'il vous plaît, partagez vos commentaires et remarques !

Quoi de neuf ?​

Much of Electron's functionality is provided by the core components of Chromium, Node.js, and V8. Electron keeps up-to-date with these projects to provide our users with new JavaScript features, performance improvements, and security fixes. Each of these packages has a major version bump in Electron 5:

• Chromium 73.0.3683.119
  • New in 70
  • New in 71
  • New in 72
  • New in 73
• Node.js 12.0.0
  • Node 12 Blog Post
• V8 7.3.492.27.
  • New JS Features

Electron 5 also includes improvements to Electron-specific APIs. A summary of the major changes is below; for the full list of changes, check out the Electron v5.0.0 release notes.

Promisification​

Electron 5 continues Promisification initiative initiative to convert Electron's callback-based API to use Promises. These APIs were converted for Electron 5:

• app.getFileIcon
• contentTracing.getCategories
• contentTracing.startRecording
• contentTracing.stopRecording
• debugger.sendCommand
• Cookies API
• shell.openExternal
• webContents.loadFile
• webContents.loadURL
• webContents.zoomLevel
• webContents.zoomFactor
• win.capturePage

System colors access for macOS​

These functions were changed or added to systemPreferences to access macOS systems' colors:

• systemPreferences.getAccentColor
• systemPreferences.getColor
• systemPreferences.getSystemColor

Process memory information​

The function process.getProcessMemoryInfo has been added to get memory usage statistics about the current process.

Additional filtering for remote APIs​

To improve security in the remote API, new remote events have been added so that remote.getBuiltin, remote.getCurrentWindow, remote.getCurrentWebContents and <webview>.getWebContents can be filtered.

Multiple BrowserViews on BrowserWindow​

BrowserWindow now supports managing multiple BrowserViews within the same BrowserWindow.

Changements majeurs avec rupture de compatibilité​

Defaults for packaged apps​

Packaged apps will now behave the same as the default app: a default application menu will be created unless the app has one and the window-all-closed event will be automatically handled unless the app handles the event.

Mixed sandbox​

Mixed sandbox mode is now enabled by default. Renderers launched with sandbox: true will now be actually sandboxed, where previously they would only be sandboxed if mixed-sandbox mode was also enabled.

Security improvements​

The default values of nodeIntegration and webviewTag are now false to improve security.

Spellchecker now asynchronous​

The SpellCheck API has been changed to provide asynchronous results.

Deprecations​

The following APIs are newly deprecated in Electron 5.0.0 and planned for removal in 6.0.0:

Mksnapshot binaries for arm and arm64​

Les binaires natifs de mksnapshot pour arm et arm64 sont dépréciés et seront supprimés en 6. . 0. Des instantanés peuvent être créés pour les arm et arm64 à l’aide des binaires x64.

ServiceWorker APIs on WebContents​

Deprecated ServiceWorker APIs on WebContents in preparation for their removal.

• webContents.hasServiceWorker
• webContents.unregisterServiceWorker

Automatic modules with sandboxed webContents​

In order to improve security, the following modules are being deprecated for use directly via require and will instead need to be included via remote.require in a sandboxed webcontents:

• electron.screen
• child_process
• fs
• os
• path

webFrame Isolated World APIs​

webFrame.setIsolatedWorldContentSecurityPolicy,webFrame.setIsolatedWorldHumanReadableName, webFrame.setIsolatedWorldSecurityOrigin have been deprecated in favor of webFrame.setIsolatedWorldInfo.

Mixed sandbox​

enableMixedSandbox and the --enable-mixed-sandbox command-line switch still exist for compatibility, but are deprecated and have no effect.

End of support for 2.0.x​

Per our supported versions policy, 2.0.x has reached end of life.

Programme de feedback​

Nous continuons à utiliser notre Programme de Feedback de l'application pour les tests. Les projets qui participent à ce programme testent les bétas d'Electron sur leurs applications ; et en retour, les nouveaux bogues qu'ils trouvent sont priorisés pour la version stable. Si vous souhaitez participer ou en savoir plus, consultez notre blog sur le programme.

Et maintenant ?​

À court terme, vous pouvez compter sur l’équipe pour continuer a se concentrer sur le développement des principaux composants qui composent Electron, notamment Chromium, Node et V8. Bien que nous veillions à ne pas faire de promesses à propos des dates de publication, notre plan est la sortie de nouvelles versions majeures d'Electron avec de nouvelles versions de ces composants environ un trimestre. Le planning escompté de la version 6.0.0 planning défini les dates clés du cycle de vie de développement d'Electron 6. Aussi, regardez notre document de versioning pour plus d'informations sur le versioning dans Electron.

Pour des informations sur les changements de rupture prévus dans les versions à venir d'Electron, regardez notre documentation sur les changements de rupture planifiés.

Comment les fonctionnalités d'Electron écrites en C++ ou Objective-C peuvent-elles être accessibles à un utilisateur final?

Information de base​

Electron est une plate-forme JavaScript dont le but principal est de réduire les obstacles pour les développeurs afin qu'ils construisent des applications de bureau robustes sans se soucier des implémentations spécifiques à la plate-forme. Cependant, à la base, Electron lui-même a toujours besoin de fonctionnalités spécifiques à la plate-forme pour être écrit dans un langage système donné.

En réalité, Electron gère le code natif pour vous afin que vous puissiez vous concentrer sur une seule API JavaScript.

Mais comment cela fonctionne-t-il? Comment les fonctionnalités d'Electron écrites en C++ ou Objective-C peuvent-elles être accessibles à un utilisateur final?

Pour tracer les grandes lignes, commençons par le module app.

En ouvrant le fichier app.ts dans notre répertoire lib/ , vous trouverez vers le haut du fichier la ligne de code suivante :

const binding = process.electronBinding('app');

Cette ligne pointe directement vers le mécanisme d'Electron pour relier ses modules C++/Objective-C à JavaScript pour une utilisation par les développeurs. Cette fonction est créée par l'en-tête et le fichier d'implémentation pour la classe ElectronBindings.

process.electronBinding​

Ces fichiers ajoutent la fonction process.electronBinding , qui se comporte comme le process.binding de Node.js. process.binding est une implémentation de niveau inférieur de la méthode require() de Node, mais elle autorise les utilisateurs à effectuer unrequire de code natif au lieu d'un code écrit en JS. Cette fonction personnalisée process.electronBinding permet de charger du code natif depuis Electron.

Comment l'état de ce code natif est-il déterminé et défini quand un module JavaScript de haut niveau (comme app) requiert ce code natif, ? Où sont exposées les méthodes à JavaScript ? Qu'en est-il des propriétés ?

native_mate​

À l'heure actuelle les réponses à cette question peuvent être trouvées dans native_mate : un fork de la bibliothèque gin de Chromium qui facilite l'échange de types entre C++ et JavaScript.

On trouve dans native_mate/native_mate un en-tête et un fichier d'implémentation pour object_template_builder. C'est ce qui nous permet de former des modules en code natif dont la forme est conforme à ce que les développeurs JavaScript attendent.

mate::ObjectTemplateBuilder​

Si nous considérons chaque module Electron comme un object, il devient plus facile de voir pourquoi nous voudrions utiliser object_template_builder pour les construire. Cette classe est construite sur une classe exposée par V8, qui est le moteur JavaScript open source haute performance de Google et et WebAssembly écrits en C ++. V8 implémente la spécification JavaScript (ECMAScript) donc les implémentations de ses fonctionnalités natives peuvent être directement corrélées aux implémentations en JavaScript. Par exemple, v8::ObjectTemplate nous donne des objets JavaScript sans constructeur ni prototype dédiés. Il utilise Object[.prototype] avec l'équivalent en JavaScript étant Object.create().

Pour voir cela en action, consultez le fichier d’implémentation du module app, atom_api_app.cc. En bas de ce fichier vous trouverez:

mate::ObjectTemplateBuilder(isolate, prototype->PrototypeTemplate())
    .SetMethod("getGPUInfo", &App::GetGPUInfo)

Dans la ligne ci-dessus, .SetMethod est invoquée sur mate::ObjectTemplateBuilder. .SetMethod peut être invoquée sur toute instance de la classe ObjectTemplateBuilder pour définir des méthodes sur l' Object prototype en JavaScript, avec la syntaxe suivante :

.SetMethod("method_name", &function_to_bind)

Il s’agit de l’équivalent JavaScript de :

function App{}
App.prototype.getGPUInfo = function () {
  // rajouter l'implementation ici
}

Cette classe contient également des fonctions pour définir des propriétés d'un module :

.SetProperty("property_name", &getter_function_to_bind)

ou

.SetProperty("property_name", &getter_function_to_bind, &setter_function_to_bind)

Et donc les implémentations JavaScript de Object.defineProperty seraient elles les suivantes:

function App {}
Object.defineProperty(App.prototype, 'myProperty', {
  get() {
    return _myProperty
  }
})

et

function App {}
Object.defineProperty(App.prototype, 'myProperty', {
  get() {
    return _myProperty
  }
  set(newPropertyValue) {
    _myProperty = newPropertyValue
  }
})

Il est possible de créer des objets JavaScript avec prototypes et propriétés comme attendus par les développeurs et plus clairement de raisonner sur les fonctions et les propriétés implémentées à ce niveau inférieur du system!

La décision quant à l'endroit où implémenter une méthode d'un module donné est elle-même complexe et souvent non déterministe, que nous aborderons dans un article futur.

À mesure qu'Electron gagne en popularité pour les applications de bureau, l'équipe qui y travaille s'est également étoffée : nous avons plus de responsables à temps plein travaillant pour différentes sociétés, vivant dans différents fuseaux horaires, et ayant des intérêts différents. Nous introduisons donc une structure de gouvernance afin de pouvoir continuer à croître en douceur.

Pourquoi les choses changent-elles ?​

Les gens du projet Electron se coordonnent en vivant dans des fuseaux horaires du monde entier avec des volontaires, des responsables à temps plein et avec plusieurs entreprises qui dépendent toutes d'Electron. Jusqu'à présent, nous avons réussi sans une coordination formelle ; mais au fur et à mesure du développement de l'équipe, nous avons constaté que l'approche n'était pas évolutive. Nous voulons également faciliter la tâche des nouveaux contributeurs pour qu'ils se sentent bien en intégrant le projet.

Groupes de travail​

La gouvernance d'Electron comprend des groupes de travail responsables des différentes parties du projet. Nous commençons avec sept groupes :

• Communauté & Sécurité : gère le Code de conduite.
• Docs & Outils : supervise les outils externes (par exemple Fiddle, Forge) et la documentation d'Electron .
• Vulgarisation: Participe à l'aggrandissement de la communauté Electron.
• Versions : Permet de s'assurer que les versions sont stables et dans les délais.
• Sécurité : Effectue des tests de sécurité et répond aux problèmes de sécurité.
• Mises à jour : intègre les mises à jour en amont telles que les nouvelles versions de V8, Chromium et Node.
• Site Web: Maintient et améliore le site Web d'Electron.

Ces groupes se coordonnent entre eux, cependant chacun d'entre eux a ses propres calendriers et agendas à des fins de productivité. Plus de détails sur ces groupes sont disponibles sur le dépôt de gouvernance.

Est ce que cela modifie la direction du projet Electron ?​

Cela ne devrait pas avoir d'effet direct sur la direction d'Electron. Si notre stratégie est couronnée de succès, les groupes de travail permettront aux nouveaux contributeurs de trouver plus facilement des sujets qui les intéressent, et ainsi faciliter la vie des responsables en déplaçant toute discussion sans rapport avec leur travail quotidien vers d'autres groupes. Si tout se passe bien, cela impliquera davantage de personnes non bloquées pouvant travailler ensemble.

Où puis-je en apprendre davantage ?​

• Le repo de gouvernance et la charte contiennent des informations sur la nouvelle structure de gouvernance.
• Chaque groupe de travail a sa propre page : Communauté, Doc & Outils, Vulgarisation, Versions, Sécurité, Mises à jour, et Site.
• Vous pouvez contacter les responsables en déclarant un problème ou en nous envoyant un e-mail à info@electronjs.org.

A High severity vulnerability has been discovered in Chrome which affects all software based on Chromium, including Electron.

This vulnerability has been assigned CVE-2019-5786. You can read more about it in the Chrome Blog Post.

Please note that Chrome has reports of this vulnerability being used in the wild so it is strongly recommended you upgrade Electron ASAP.

Portée​

This affects any Electron application that may run third-party or untrusted JavaScript.

Atténuation​

Affected apps should upgrade to a patched version of Electron.

Nous avons publié de nouvelles versions d'Electron qui incluent des corrections pour cette vulnérabilité :

• 4.0.8
• 3.1.6
• 3.0.16
• 2.0.18

The latest beta of Electron 5 was tracking Chromium 73 and therefore is already patched:

• 5.0.0-bêta.5

Informations complémentaires ​

This vulnerability was discovered by Clement Lecigne of Google's Threat Analysis Group and reported to the Chrome team. The Chrome blog post can be found here.

Pour en savoir plus sur les meilleures pratiques pour sécuriser vos applications Electron, consultez notre tutoriel de sécurité.

Si vous souhaitez signaler une vulnérabilité dans Electron, envoyez un e-mail à security@electronjs.org.

L'équipe d'Electron cessera de prendre en charge Linux 32 bits (ia32 / i386) à partir d'Electron v4.0. La dernière version d'Electron qui prend en charge les installations basées sur 32 bits de Linux est Electron v3.1, qui recevra des versions de support jusqu'à la sortie d'Electron v6. Support for 64-bit based Linux and armv7l will continue unchanged.

What exactly is Electron no longer supporting?​

You may have seen the description "64-bit" and "32-bit" as stickers on your computer or as options for downloading software. The term is used to describe a specific computer architecture. Most computers made in the 1990s and early 2000s were made with CPUs that were based on the 32-bit architecture, while most computers made later were based on the newer and more powerful 64-bit architecture. The Nintendo 64 (get it?) and the PlayStation 2 were the first widely available consumer devices with the new architecture, computers sold after 2010 contained almost exclusively 64-bit processors. As a result, support has been shrinking: Google stopped releasing Chrome for 32-bit Linux in March 2016, Canonical stopped providing 32-bit desktop images in 2017 and dropped support for 32-bit altogether with Ubuntu 18.10. Arch Linux, elementary OS, and other prominent Linux distributions have already dropped support for the aging processor architecture.

Until now, Electron has provided and supported builds that run on the older 32-bit architecture. From release v4.0 onwards, the Electron team will no longer be able to provide binaries or support for 32-bit Linux.

Electron has always been a vibrant open source project and we continue to support and encourage developers interested in building Electron for exotic architectures.

What does that mean for developers?​

If you are not currently providing 32-bit distributions of your app for Linux, no action is required.

Projects which ship 32-bit Linux Electron applications will need to decide how to proceed. 32-bit Linux will be supported on Electron 3 until the release of Electron 6, which gives some time to make decisions and plans.

What does that mean for users?​

If you are a Linux user and not sure whether or not you're running a 64-bit based system, you are likely running on a 64-bit based architecture. To make sure, you can run the lscpu or uname -m commands in your terminal. Either one will print your current architecture.

If you are using Linux on a 32-bit processor, you have likely already encountered difficulties finding recently released software for your operating system. The Electron team joins other prominent members in the Linux community by recommending that you upgrade to a 64-bit based architecture.

Une vulnérabilité de code a été découverte qui permettait à Node d'être réactivé dans les fenêtres enfants.

L'ouverture d'un BrowserView avec sandbox: true ou nativeWindowOpen: true et nodeIntegration: false donne un contenu Web où window.open peut être appelé et la fenêtre enfant nouvellement ouverte aura nodeIntegration activé. Cette vulnérabilité affecte toutes les versions prises en charge d'Electron.

Atténuation​

Nous avons publié de nouvelles versions d'Electron qui incluent des corrections pour cette vulnérabilité : 2.0.17, 3.0.15, 3.1.3, 4.0.4, et 5.0.0-beta.2. Nous encourageons tous les développeurs d'Electron à mettre à jour leurs applications vers la dernière version stable immédiatement.

Si pour une raison quelconque, vous ne pouvez pas mettre à jour votre version d'Electron, vous pouvez atténuer ce problème en désactivant tous les contenus web enfants :

view.webContents.on('-add-new-contents', (e) => e.preventDefault());

Informations complémentaires ​

Cette vulnérabilité a été trouvée et signalée de manière responsable au projet Electron par PalmerAL.

Pour en savoir plus sur les meilleures pratiques pour sécuriser vos applications Electron, consultez notre tutoriel de sécurité.

Si vous souhaitez signaler une vulnérabilité dans Electron, envoyez un e-mail à security@electronjs.org.