BT

Diffuser les connaissances et l'innovation dans le développement logiciel d'entreprise

Contribuez

Sujets

Sélectionner votre région

Accueil InfoQ Actualités OpenJDK Propose La Dépréciation Du SecurityManager

OpenJDK Propose La Dépréciation Du SecurityManager

Favoris
null Contenu HTML mixte :

Le projet OpenJDK a proposé la JEP-411 comme moyen de déprécier le SecurityManager. Si elle est acceptée, elle s'agirait de la première étape d'un processus pluriannuel dans lequel la Campagne OpenJDK Quality Outreach peut guider les projets concernés vers des alternatives avant que quoi que ce soit ne soit supprimé.

Le vote sur la JEP n'a pas encore eu lieu et la dépréciation ne signifie pas la suppression immédiate. Un vote affirmatif lancerait le processus de désapprobation et toute suppression future n'aurait pas d'impact rétroactif sur les versions précédentes de Java. La gestion pour supprimer le SecurityManager suit la phase récente (2021) de la processus de dépréciation des applets (2017) qui est en cours depuis plusieurs années (2016). La JEP-411 fournit une explication de la dépréciation :

"Le Security Manager date de Java 1.0. Il n'a pas été le principal moyen de sécuriser le code Java côté client depuis de nombreuses années, et il a rarement été utilisé pour sécuriser le code côté serveur. Pour faire avancer Java, nous avons l'intention de déprécier le Security Manager pour le supprimer de concert avec l'ancienne API Applet (JEP 398)."

Le SecurityManager original a été conçu en 1996 comme une défense contre le code portable exécuté sur un PC client. La disponibilité des applets a été conçue dans NPAPI (Netscape Plugin API) de Netscape Navigator pour ajouter des fonctionnalités qui n'étaient pas présentes dans les premières versions de JavaScript.

L'utilisation du SecurityManager se produit en dehors des applets et plusieurs projets concernés ont été identifiés. Certains se sont prononcés en faveur de la JEP-411. InfoQ s'est entretenu avec Arjan Tijms, responsable de la sécurité pour Jakarta EE, à propos de la discussion récente sur la liste de diffusion de Jakarta.

Maintenant, je me dis personnellement depuis longtemps de ne pas utiliser / dépendre du gestionnaire de sécurité dans le code côté serveur. L'idée d'exécuter du code potentiellement non fiable sur son propre serveur m'a toujours semblé gênante et quelque chose que vous ne feriez pas de toute façon, même lorsque l'exécution de plusieurs applications sur une seule instance de serveur était encore quelque chose de courant.

  -Arjan Tijms, responsable de la sécurité pour Jakarta EE

Un long thread Reddit a cité des commentaires antérieurs de Tijms de 2014 dans Omnifaces, disant :" Le gestionnaire de sécurité Java SE est utilisé pour la protection au niveau code, qui est un niveau de protection qui est rarement, voire jamais, nécessaire dans Java EE car il est extrêmement rare qu'un serveur exécute du code non approuvé (comme par exemple un navigateur qui exécute une applet non approuvée à partir d'Internet). "

Jim Manico, auteur de Iron Clad Java, est d'accord en déclarant, "Je n'ai littéralement jamais utilisé de [SecurityManager] dans le développement d'entreprise."

Les projets qui utilisent le SecurityManager peuvent utiliser différents canaux des projets OpenJDK. Uwe Schindler, chef de projet pour Apache Lucene a identifié Apache Solr et ElasticSearch / OpenSearch en tant que projets concernés. Les cas d'utilisation non-Applet de ces projets incluent la possibilité pour les plugins de lire les informations sans affecter l'hôte. D'autres projets incluent Apache NetBeans, qui utilise le SecurityManager pour la surveillance plutôt que pour la sécurité. Les capacités de surveillance ont été migré vers JDK Flight Recorder et des systèmes tiers comme Contrast Community Edition.

Avec les discussions en cours, même un vote en faveur de la dépréciation offrira suffisamment de temps aux parties concernées pour identifier des alternatives.

 

Evaluer cet article

Pertinence
Style

Bonjour étranger!

Vous devez créer un compte InfoQ ou cliquez sur pour déposer des commentaires. Mais il y a bien d'autres avantages à s'enregistrer.

Tirez le meilleur d'InfoQ

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

Commentaires de la Communauté

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

BT

Votre profil est-il à jour? Merci de prendre un instant pour vérifier.

Note: en cas de modification de votre adresse email, une validation sera envoyée.

Nom de votre entreprise:
Rôle dans votre entreprise:
Taille de votre entreprise:
Pays/Zone:
État/Province/Région:
Vous allez recevoir un email pour confirmer la nouvelle adresse email. Ce pop-up va se fermer de lui-même dans quelques instants.