Pourquoi devrais-je signer mes fichiers JAR ?
Je sais que je dois signer mes fichiers JAR côté client (contenant des applets) pour que des choses spéciales comme l'accès au système de fichiers puissent être faites, et pour que la partie ennuyeuse en bas de Windows ne s'affiche pas, mais pourquoi d'autre ? Et dois-je signer mes fichiers JAR côté serveur contenant des Servlets, etc.
Quelques règles de base pour savoir quand et quand ne pas signer les JARs seraient appréciées - merci !
En bref, ne le faites pas, sauf si la politique de votre entreprise vous y oblige.
La réponse longue
Signer des bocaux revient à dire à votre client : "J'ai créé ce produit et je vous garantis qu'il ne perturbera pas votre système. Si c'est le cas, venez me voir pour un châtiment". C'est pourquoi les jars signés dans les solutions côté client déployées à partir de serveurs distants (applets / webstart) bénéficient de privilèges plus élevés que les solutions non signées.
Pour les solutions côté serveur, où vous n'avez pas à répondre aux exigences de sécurité de la JVM, cette garantie est uniquement destinée à assurer la tranquillité d'esprit de vos clients.
L'inconvénient des jars signés est qu'ils se chargent plus lentement que les jars non signés. Combien plus lent ? C'est lié au CPU, mais j'ai remarqué une augmentation de plus de 100% du temps de chargement. De plus, les correctifs sont plus difficiles (vous devez resigner le jar), les correctifs de classe sont impossibles (toutes les classes d'un même paquet doivent avoir la même source de signature) et la division des jars devient une corvée. Sans oublier que votre processus de construction est plus long et que les certificats appropriés coûtent de l'argent (les certificats auto-signés sont pratiquement inutiles).
Ainsi, à moins que la politique de votre entreprise ne vous y oblige, ne signez pas les jars côté serveur et conservez les jars communs en versions signées et non signées (les versions signées sont destinées au déploiement côté client, les versions non signées sont destinées à la base de code côté serveur).
Une bonne raison pourrait être que vous ne voulez pas que quelqu'un soit capable d'introduire en douce des classes modifiées qui seront appelées par votre code.
Malheureusement, vous en faites partie :-D Donc, vous ne devez le faire que si vous en avez vraiment besoin. Vérifiez le concept de "bocal scellé".
En termes d'applets : A partir de la 6u10, le JRE de Sun remplace la bannière d'avertissement par un triangle d'avertissement moins gênant (à partir de la 6u12, IIRC) (nécessaire pour supporter les Windows en forme et transparents). La version 6u10 permet également un accès contrôlé aux fichiers via l'API de services JNLP.
Le principe du moindre privilège veut que vous ne signiez pas les classes de vos fichiers jar. La sécurité n'est pas nécessairement facile.
Le simple fait d'afficher une boîte de dialogue de certificat ne doit pas être interprété comme signifiant que l'ensemble du contenu d'une page Web est digne de confiance.
La signature d'un fichier jar, tout comme l'utilisation de certificats dans d'autres contextes, est effectuée afin que les personnes qui l'utilisent sachent d'où il provient. Les gens peuvent croire que Chris Carruthers ne va pas écrire de code malveillant, et ils sont donc prêts à autoriser votre applet à accéder à leur système de fichiers. La signature leur donne une certaine garantie que le jar a vraiment été créé par vous, et non par un imposteur ou une personne en qui ils n'ont pas confiance.
Dans le cas de jars côté serveur ou de bibliothèques, il n'est généralement pas nécessaire de fournir ce type de garantie à qui que ce soit. S'il s'agit de votre serveur, vous savez quels jars vous utilisez et d'où ils proviennent, et vous faites probablement confiance à votre propre code pour ne pas être malveillant.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
