LibreSSL 2.3.3 est disponible depuis le 22 mars 2016. Ce projet, démarré par des développeurs d’OpenBSD, vise à proposer une alternative sécurisée et moderne à OpenSSL, suite notamment aux failles Heartbleed et Poodle.
À propos
LibreSSL consiste en quatre parties :
- l’outil en ligne de commande openssl(1), qui permet de gérer entre autres, clés et certificats ;
- libcrypto, une bibliothèque cryptographique ;
- libssl, une bibliothèque TLS rétrocompatible avec OpenSSL ;
- et enfin, libtls, une bibliothèque plus récente, pensée pour faciliter l’écriture d’applications « foolproof ».
Comme beaucoup d’autres projets de la fondation OpenBSD, LibreSSL est développé d’abord pour ce système. Une version dite « portable » est ensuite créée, via un ensemble de correctifs, pour fonctionner sur plus de systèmes d’exploitation. Actuellement, LibreSSL fonctionne sur les plates‐formes suivantes :
- GNU/Linux (Linux 3.17 et suivants préférés) ;
- FreeBSD (testé sur 9.2 et après) ;
- NetBSD (7.0 et suivants préférés) ;
- HP-UX (11i) ;
- Solaris (11 et suivants préférés) ;
- OS X (testé sur 10.8 et suivants) ;
- AIX (5.3 et suivants) ;
- Windows (XP et suivants, x86 et x64) ;
- Wine (32 bits et 64 bits).
Sur le plan technique
Cette version de LibreSSL apporte les changements suivants :
- les scripts de compilations ont été retravaillés afin de mieux se synchroniser avec OpenNTPD-portable ;
- correction de liens cassés dans la page de manuel ;
- correction d’un problème de compatibilité avec le serveur Web Nginx, en ajoutant un alias make nommé install_sw ;
- des corrections de compilation pour HP-UX ;
- pour la version Windows, le répertoire de configuration par défaut est maintenant
C:\LibreSSL\ssl; -
cert.pema été réorganisé et synchronisé avec le magasin de certificats de Mozilla.
Sur le plan organisationnel
À partir de cette version, les développeurs de LibreSSL considèrent maintenant la branche 2.3 comme stable, et annoncent d’ailleurs que la branche 2.1 ne sera plus maintenue lors de la sortie d’OpenBSD 5.9 (initialement prévue pour mai 2016, sorti finalement le 29 mars 2016).
Avec la sortie avancée d’OpenBSD 5.9, rien ne dit pour le moment si cette branche 2.1 restera maintenue jusqu’à mai ou si elle est déjà en fin de vie. Les notes de version mentionnent par ailleurs que LibreSSL 2.3.3 est identique à la version livrée dans OpenBSD 5.9, alors que ce dernier annonce LibreSSL 2.3.2.
Côté calendrier, la page listant les versions publiées annonce une transition vers la publication d’une version stable tous les six mois, en coordination avec le calendrier de développement d’OpenBSD. Les branches stables de LibreSSL sont maintenues pendant un an après que leur version correspondante dans OpenBSD a été étiquetée pour livraison.
Aller plus loin
- LibreSSL (400 clics)
- Notes de version (108 clics)
- OpenBSD (116 clics)
- DLFP : LibreSSL 2 est bien lancé (189 clics)
- DLFP : OpenBSD 5.9 (154 clics)
# Wine ?
Posté par Anthony Jaguenaud . Évalué à 6.
Je suis surpris de voir Wine en temps que plateforme/OS. Même se ce n’est pas un émulateur, c’est un wrapper d’appel système Windows pour Unix.
[^] # Re: Wine ?
Posté par laurentb (site web personnel) . Évalué à 2.
Il existe tout de même https://wiki.winehq.org/Winelib
[^] # Re: Wine ?
Posté par Nils Ratusznik (site web personnel, Mastodon) . Évalué à 10.
J'ai été aussi surpris que toi en écrivant l'article. Mon hypothèse est que certains développeurs ou contributeurs utilisent Wine pour compiler/tester les binaires Windows. Je ne serais pas surpris que cela se fasse aussi par manque de licence Windows (volontaire ou non).
[^] # Re: Wine ?
Posté par Shunesburg69 . Évalué à 4.
Personnellement ça ne m'a pas surpris car Wine est bien une plateforme mais pas un OS, tout comme le support JAVA est également considéré comme une plateforme.
# A tester
Posté par MTux . Évalué à 4.
On attend ça avec impatience malheureusement ça ne semble pas encore disponible pour Linux (dans le sens où c'est pas packagé). Par contre c'est installable assez facilement pour les ports FreeBSD.
[^] # Re: A tester
Posté par Parleur . Évalué à 6. Dernière modification le 12 avril 2016 à 00:51.
J'avais installé une Gentoo avec LibreSSL pleinement fonctionnelle avec les dépôts officiels instables, en septembre dernier. Ça fait au moins une distribution où c'est « packagé ».
[^] # Re: A tester
Posté par Nils Ratusznik (site web personnel, Mastodon) . Évalué à 3.
C'est disponible aussi pour NetBSD, via pkgsrc : security/libressl.
[^] # C’est une question de distribution
Posté par Arthur Accroc . Évalué à 6.
Void est passé à LibreSSL par défaut.
Après, c’est un choix de chaque distribution de rester avec OpenSSL ou de passer à LibreSSL (et quand)…
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: C’est une question de distribution
Posté par Parleur . Évalué à 1.
Je ne connaissais pas cette distribution, qui m'a l'air vraiment très sexy, au vu des premières informations que je trouves.
# sécurisée et moderne
Posté par sizvix (site web personnel) . Évalué à -10.
Je ne sais pas trop pourquoi, mais je n'ai pas trop aimé la vitesse où les gens ont rejeté openSSL , et la création de cette alternative ne m'a pas plût …
Pour moi, "une alternative sécurisée et moderne à OpenSSL" sonnerait mieux avec Rust :P , dans ce cas là je testerai ( ça sera peut-être aussi l'occasion de contribuer ^ ) et ça aurai à ma vue plus de sens.
Essaie pour vivre sans brider les utilisateurs https://www.indiegogo.com/projects/iwinote
[^] # Re: sécurisée et moderne
Posté par barmic . Évalué à 10.
Moi aussi je trouve ça nul, ils auraient dû le faire en OCaml. Là j'aurais contribué !
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: sécurisée et moderne
Posté par khivapia . Évalué à 4. Dernière modification le 12 avril 2016 à 21:50.
Ça existe déjà, et c'est prouvé en plus : mitls.org
Par contre il faut accepter d'écrire trois fois plus d'annotations que de code.
[^] # Re: sécurisée et moderne
Posté par Enj0lras . Évalué à 5. Dernière modification le 13 avril 2016 à 14:12.
ça existe, et ça s'appelle ocaml-tls
[^] # Re: sécurisée et moderne
Posté par Jean Parpaillon (site web personnel) . Évalué à 3.
De nombreux langages proposent des mises en oeuvre natives de SSL.
Exemple:
http://erlang.org/doc/man/ssl_app.html
"Liberté, Sécurité et Responsabilité sont les trois pointes d'un impossible triangle" Isabelle Autissier
[^] # Re: sécurisée et moderne
Posté par sizvix (site web personnel) . Évalué à 2.
On code dans les langages qu'on connait, pour ma part, j'essaie d'apprendre les Rust (je dis j'essaie, car je n'ai pas trop de temps) . Et c'était une boutade par rapport au fait que "moderne et sécurisé" sont un peu l'étiquette que se veut Rust.
Mon commentaire était surtout sur le fait de lyncher une équipe qui distribue du code librement depuis plus de 15ans au moindre faux pas … Plutôt leur filer un coup de main et refondre le code ensemble (ok, vive les bisounours) que de forker directement ou mettre en place des alternatives … (disons que la vague de rejet qu'il y a eu envers eux qui distribuent du code depuis longue date ne me paraissait pas respectueuse …)
Essaie pour vivre sans brider les utilisateurs https://www.indiegogo.com/projects/iwinote
[^] # Re: sécurisée et moderne
Posté par xcomcmdr . Évalué à 10.
Ah, c'est sûr que rejeter une tonne de code spaghetti merdique, obsolète, peu maintenu, et bourré de failles, c'est rageant…
Ou pas…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: sécurisée et moderne
Posté par Shunesburg69 . Évalué à 7.
On a bien fait la même chose avec LibreOffice et quand on voit ce que ça donne perso je trouve pas gênant d'abandonner des projets mort et les forker si ça devient vitale.
[^] # Re: sécurisée et moderne
Posté par Misc (site web personnel) . Évalué à 2.
Oui enfin, on peut aussi dire le contraire avec mate, ou le fork de gnome à l'époque de gnome 2, ou trinity, qui sont globalement comme apache openoffice, pas mort mais avec un niveau d'activité pas non plus énorme.
[^] # Re: sécurisée et moderne
Posté par xcomcmdr . Évalué à 2.
C'est des projets zombie ?
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: sécurisée et moderne
Posté par Shunesburg69 . Évalué à 7. Dernière modification le 12 avril 2016 à 13:18.
Je suis d'accord par contre malheureusement tous ne partage pas notre avis et continue leurs supports. Quand on voit le nombre de distributions qui utilise Mate, on voit que certains on l'air de l’apprécier. Moi personnellement j'utilise Xfce (qui a été créé bien avant gnome 3) et le projet avance doucement mais est très stable.
[^] # Re: sécurisée et moderne
Posté par barmic . Évalué à 10.
C'est très positif ! Quand on découvre qu'un projet important de l'écosystème a un problème chercher à résoudre ce problème ne me paraît pas choquant. La linux fondation a mandaté des audits du code, OpenBSD se lance dans une alternative,… Lancer plusieurs solutions et voir la quelle va émerger n'est pas délirant. D'autant plus que ce sont des gens qui n'auraient probablement pas réussi à collaborer pour choisir une solution et travailler de concert donc ça n'éparpille pas une force de travail.
Quand un projet fais un choix critique, le fait d'avoir des alternatives qui se créent n'est pas un problème à mon humble avis.
Ça me fait penser que Devuan a l'air très très calme (je peux me tromper).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: sécurisée et moderne
Posté par Misc (site web personnel) . Évalué à 3.
Le souci n'est pas de forker, mais de croire que parce qu'un truc est un fork, alors c'est meilleur, et de croire que tout les forks vont faire mieux que l'original.
Il y a tout un tas de facteurs à prendre en compte pour voir si c'est opportun ou pas, et si j'osais faire un début d’hypothèse, le facteur le plus important, c'est de voir ou les développeurs de longue date du projet vont. Dans le cas d'Openoffice et de Mandrake, les forks sont ceux qui ont globalement survécus. Dans le cadre de certains forks de gnome, kde ou debian, c'est globalement pas le cas (Ubuntu étant une des exceptions à mon hypothèse, tout comme Libressl).
[^] # Re: sécurisée et moderne
Posté par barmic . Évalué à 4.
Ubuntu n'est pas un fork mais une dérivée. Ubuntu a besoin de Debain pour exister.
Le fork d'OS qui correspond à ce que tu dis serait plutôt DragonflyBSD.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: sécurisée et moderne
Posté par trancheX . Évalué à 5.
Rust n'est pas aussi portable que le C (pour l'instant) et si on veut quelque chose d'utilisable (compilable à peu prés partout x86/POWER/SPARC/ARM/MIPS/AVR/…) le C est encore pour longtemps un (le seul?) choix pragmatique.
Ce que je ne comprend pas, c'est pourquoi il n'y a pas eu plus de fuite vers PolarSSL, comme Hiwatha web server avait eu la bonne idée de le faire avant l'apparition des problèmes de sécurité d'OpenSSL.
[^] # Re: sécurisée et moderne
Posté par barmic . Évalué à 3.
Ou comme l'on fait les gens de Belldonne Communication pour leur soft SIP ? ;)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: sécurisée et moderne
Posté par Antoine . Évalué à 6.
On connaît l'état du code OpenSSL qui a été très audité, mais la robustesse de concurrents tels que PolarSSL n'est pas forcément établie.
Par ailleurs, si PolarSSL ne propose pas une API similaire à celle d'OpenSSL, il y a un coût de migration important.
[^] # Re: sécurisée et moderne
Posté par AnthonyRabine (site web personnel) . Évalué à 1.
https://github.com/cesanta/polar ?
[^] # Re: sécurisée et moderne
Posté par Antoine . Évalué à 5.
Si j'en crois le README, c'est un jeu de fonctions très réduit qui ne permet que des cas d'usage triviaux. Par exemple, aucun moyen d'activer ou désactiver certaines versions de TLS, de choisir les algorithmes de chiffrement autorisés, de prendre en charge le SNI, et tant d'autres besoins assez courants.
(je passe sur le fait que cette bibliothèque est sous licence GPL…)
[^] # Re: sécurisée et moderne
Posté par barmic . Évalué à 7.
Moi je suis surpris que gnutls n'ai pas sorti son épingle du jeu
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: sécurisée et moderne
Posté par trancheX . Évalué à 3.
J'ai volontairement cité PolarSSL et pas GnuTLS qui n'avait (selon certain ouï-dire) pas bonne réputation niveau sécurité/audit.
Pour l'API incompatible, j'entends bien par "fuite vers PolarSSL" fuir le code et également l'API de OpenSSL, qui n'a pas bonne réputation et apparemment la doc c'est pire (le mainteneur d'hiwatha justifiait la migration à cause de la documentation d'OpenSSL). Donc oui, ça a un coût, mais justement je suis étonné que si peu de personne aient trouvé que ce coût en vaille la peine.
Surtout que depuis que ARM a repris PolarSSL pour en faire mbedTLS, ils y ont ajouté la licence Apache qui, à mon sens, rend possible l'utilisation partout où OpenSSL est utilisé (ils sont d’ailleurs pas tendre avec OpenSSL).
[mes 2cts d'expérience]
Lorsqu'une bibliothèque logiciel employable pour l'embarqué entre en concurrence avec une autre inutilisable pour l’embarqué, c'est très souvent celle pour l'embarqué qui devient la solution technique supérieur; bien que son développement soit plus lent au début.
[/mes 2cts d'expérience]
[^] # Re: sécurisée et moderne
Posté par Harvesterify (site web personnel) . Évalué à 5.
Une partie de PolarSSL a été formellement prouvé par les ptits gars de chez TrustInSoft (un outil qui se base sur l'excellent outil Frama-C), avec en prime un kit de vérification :
http://trust-in-soft.com/polarssl-verification-kit/
C'est déjà bien plus qu'OpenSSL, en un sens :)
Mes messages engagent qui je veux.
[^] # Re: sécurisée et moderne
Posté par claudex . Évalué à 5.
L'avantage de LibreSSL, c'est que c'est globalement compatible avec l'existant. De plus, il y a la critique facile contre OpenSSL mais tout le monde l'utilisait avant, cela montre bien qu'il est relativement developper friendly.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: sécurisée et moderne
Posté par Antoine . Évalué à 10.
L'API d'OpenSSL est une merde très loin d'être developer friendly. Et ne parlons de la doc longtemps rachitique…
[^] # Re: sécurisée et moderne
Posté par Aris Adamantiadis (site web personnel) . Évalué à 3.
Sans parler des API bas niveau de libcrypto. Je me suis souvent retrouver à fouiller le code source pour comprendre comment utiliser correctement l'API. Certaines sections ont 0 docs, le code source est pourris et remplis de #ifdef (donc le code du très important mt_rand()).
# choix de dossier
Posté par guppy . Évalué à 10.
Je sais bien que Windows est pas le coeur de cible, mais c'est quand même curieux ce choix de dossier. C'est un peu comme si sous linux la conf par défaut était dans /LibreSSL/ssl.
[^] # Re: choix de dossier
Posté par steph1978 . Évalué à -7.
Et tu proposes quoi ?
Entre les noms de répertoires avec des espaces qui font tout péter à tel point qu'ils portent deux noms ou plus et le répertoire système qu'il n'est pas recommander de polluer (le système s'en charge lui même), tu n'as pas vraiment de choix.
Est ce que MS produit un guide line pour bien choisir ce dossier ?
[^] # Re: choix de dossier
Posté par xcomcmdr . Évalué à 10. Dernière modification le 12 avril 2016 à 11:27.
oui
Et le dossier ProgramData est tout indiqué (il existe depuis Vista)
%SYSTEMDRIVE%\ProgramData\LibreSSL aurait suffit.
Sous XP, ça aurait été %SYSTEMDRIVE%\Documents and Settings\All Users\Application Data\LibreSSL
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: choix de dossier
Posté par guppy . Évalué à 6.
Même %PROGRAMDATA%\LibreSSL.
[^] # Re: choix de dossier
Posté par Zenitram (site web personnel) . Évalué à 6.
Mauvais code, changer code.
Sérieux si en 2016 tu n'es pas capable de gérer un nom de fichier avec un espace, c'est grave.
Non, ici c'est juste considérer les Windowsiens comme de la merde (car ils ne font pas la même chose chez eux à coup de /LibreSSL/ssl, ils font attention à respecter les us et coutumes sur ce qui leur plait).
Note : bon, c'est le même respect pour d'autres style Python, Ruby… Pour citer les derniers que j'ai installé. Même Oracle est plus correct avec Java bien placé, c'est dire le niveau de respect des autres.
Et même une API!
SHGetFolderPath(NULL, CSIDL_COMMON_APPDATA, NULL, 0, szPath)
pour une config par appli (globale à la machine)
SHGetFolderPath(NULL, CSIDL_APPDATA, NULL, 0, szPath)
pour une config par user (et qui se balade, indépendant de la machine,
En fait, ça dépend de ce que tu veux faire (machine locale uniquement, par user et local, par user en roaming…), le problème est peut-être que Microsoft offre trop de choix? Moi qui croyais que le proprio était horrible car trop limité…
https://msdn.microsoft.com/en-us/library/windows/desktop/bb776911%28v=vs.85%29.aspx
https://msdn.microsoft.com/en-us/library/windows/desktop/bb762494%28v=vs.85%29.aspx
bref, rien de compliqué pour qui souhaite le faire. Excuser est juste "protéger" la flemmardise.
Salaud de gens qui fournissent de la compatibilité. Note : si tu programmes en 2016, tu n'as rien à faire du deuxième nom.
Bref, en fait tu ne connais pas mais critique (faussement du coup), ça vais vachement sérieux… Parce que bon, perso j'en conclue que quand on a besoin de critiquer faussement, c'est qu'on ne crois pas en ce qu'on aime (pas besoin de tromper les gens sur le concurrent si on y croit dans ses choix).
[^] # Re: choix de dossier
Posté par shbrol . Évalué à 5.
Avec un système datant de 2011 (Seven SP1), j'essaie:
ça fonctionne, et je dois avouer que j'ai été surpris, je ne m'y attendais pas.
Essayons autre chose:
et ce n'est pas la bonne réponse. Recommençons avec des guillemets:
Et voila la réponse attendue.
J'ai hâte d'avoir sous la main un système de 2016, histoire de voir si la gestion des nom de fichiers avec espace est devenue cohérente.
[^] # Re: choix de dossier
Posté par xcomcmdr . Évalué à 8.
Euh, tu mets des guillemets dès qu'il a des espaces. C'est comme ça depuis Windows 95 OSR 2 (sortie en Août 1996).
C'est pourtant pas compliqué…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: choix de dossier
Posté par Zenitram (site web personnel) . Évalué à 7.
tu vois en négatif quelque chose de positif.
Si tu es curieux :
"cd" n'accepte qu'un champs, si il y en a plusieurs ça veut dire que les guillemets ont été oubliés et l'OS "corrige" ton erreur. Il est sympa l'OS, il corrige tes bêtises, toi tu l'insultes.
"dir" accepte plusieurs champs, si il y en a plusieurs l'OS ne peut pas (ou moins facilement) savoir si tu as fait une erreur ou si c'est la commande que tu voulais, donc il ne corrige pas et préfère te laisser gérer l'erreur.
Tu fais une erreur, l'OS corrige quand il peut, et tu fais d'une fonctionnalité un défaut juste pour pouvoir cracher sur l'OS. C'est d'une objectivité…
A la base, tu es juste mauvais, et tu dois mettre des guillemets quand il y a des espaces (comme… Sous Linux). J'appelle ça de la mauvaise foi ;-).
(tu veux qu'on parle de la logique globale des commandes Linux, vraiment?)
[^] # Re: choix de dossier
Posté par KiKouN . Évalué à 4.
Je pense plutôt que c'est le programme qui corrige.
[^] # Re: choix de dossier
Posté par barmic . Évalué à 7.
C'est plus précis, mais inclure le shell et ces éventuels programmes associés dans ce que l'on appel OS ça n'a rien de choquant.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: choix de dossier
Posté par DerekSagan . Évalué à 3.
Je ne voudrais pas reprendre les trolls Linux contre GNU/Linux, mais quand même, penser que le shell de base (cmd.exe) ou les commandes bas niveau (cd) ne font pas partie de l'OS parce que ce n'est pas dans le noyau, c'est soit de la mauvaise foi, soit un truc de gros noob.
[^] # Re: choix de dossier
Posté par KiKouN . Évalué à 3.
Ce que je souligne, c'est que deux programmes d'une même suite de logiciel peuvent avoir les mêmes comportements. Ce comportement ne dépends pas de son origine. Et que ce comportement dépend bien du programme, qu'il fasse partie d'une suite, d'un OS, d'un dépot github abandonné ou vu dans une série americaine.
[^] # Re: choix de dossier
Posté par shbrol . Évalué à 4.
J'assume la mauvaise foi, et je préfère effectivement un système cohérent avec des guillemets partout. Ca te pose un problème ?
Intéressant le choix de ton vocabulaire : "insulter", "cracher sur", "tu est mauvais" … tu t'ennuies ?
[^] # Re: choix de dossier
Posté par X345 . Évalué à 10.
Tu es nouveau ici ?
[^] # Re: choix de dossier
Posté par steph1978 . Évalué à 1.
fonctionne
dir C:\program files
plante.
Deux commandes systèmes, deux comportements.
[^] # Re: choix de dossier
Posté par DerekSagan . Évalué à 5.
cmd.exe est le pire shell de la création, c'est un fait, mais c'est la ligne de commande Windows qui est incohérente, quand t'attaques programmatiquement (par API) les noms de fichiers avec espaces ça marche nickel de façon cohérente depuis Windows 95
soit depuis 20 ans
donc t'es au même niveau de mauvaise foi que les gens qui reprochent à Linux en 2016 les défauts qu'il avait en 1995, genre la gestion des threads lamentable, le support matériel de niche, l'interface graphique des années 70, la nécessité de recompiler le noyau pour ajouter un driver ou changer un paramètre, etc.
[^] # Re: choix de dossier
Posté par sifu . Évalué à 6.
MS a parfois du mal avec lui même ;)
Renommer des répertoires pour faire fonctionner des compilations, c'est pas top en 2016.
cf. https://github.com/Microsoft/msbuild/issues/53
[^] # Re: choix de dossier
Posté par Zenitram (site web personnel) . Évalué à -2. Dernière modification le 12 avril 2016 à 22:42.
Encore un procès d'intention un peu facile ;-).
- Pour les "fous" aimant les répertoires de plus de 260 caractères (noter le mot, ce n'est pas octets), certains outils ont du mal sous Windows, pas d'autres (ça dépend de savoir si ils utilisent l'API étendue ou pas). Donc avec Windows, tu peux si tu codes pour. Visual Studio n'est pas prévu, mais tu peux faire ton logiciel compatible si tu veux.
- Pour les utilisateurs Linux… Ben ce n'est jamais possible! Ext4, Btrfs, ZFS… sont tous limités à 255 octets (noter le mot, ça veut dire qu'on peut tomber à une limite de 63 caractères si ont s'amuse avec des caractères dans la plage très étendue Unicode, youpi!)
Qui est le pire? J'ai l'impression que vous n'êtes pas trop au point sur vos connaissances des limites de votre OS préféré ;-)
ne pas pouvoir stocker un nom de fichier de 64 caractères en 2016, c'est moins top que de ne pas pouvoir stocker un nom de fichier de 250 caractères en 2016.
marche sous ligne de commande Windows (qui est le soucis pour ton bug report, utilisé l'API limitant à 260 caractères), pas sous Linux (qui limite à 255 octets, j'ai pris un caractères sur 2 octets ayant la flemme d'en chercher un sur 4 octets, bam la honte de ne pas pouvoir stocker ça).
PS : bon, à décharge de Windows, Windows dit "file not found" pas logique de tout, Linux dit "File name too long" soit le bon message. 1 point pour Linux. Et surtout Linux sait afficher le nom en ligne de commande pas de "?", 2 points pour Linux (et des importants, plus que la limite à 255 octets, la phrase au dessus était surtout pour troller :) )
[^] # Re: choix de dossier
Posté par Kerro . Évalué à 1.
Tu m'as mis un doute à l'esprit.
Donc test.
[^] # Re: choix de dossier
Posté par claudex . Évalué à 7.
En ext4, c'est le nom du fichier qui est limité à 255 octets, pas le chemin d'accès.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: choix de dossier
Posté par claudex . Évalué à 7.
J'ai testé pour être sûr:
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: choix de dossier
Posté par shbrol . Évalué à 10.
Sur Linux et Windows, on a la même limite à 255/260 octets pour un nom (basename) de fichier ou de répertoire. Dans le cas d'une compilation, ce n'est généralement pas un problème parce que les nom de fichier/répertoire (basename) aussi longs, ça ne court pas les rues.
La limite qui devient vite génante pour une compilation, c'est celle du chemin complet depuis la racine (readlink -f), c'est facile de constuire un chemin absolu trop long si l'arborescence du code source est un peu profonde. Et le probleme sous windows, c'est que la limite à 260 porte sur le chemin complet, alors que sous Linux ca doit plutot être 4096 (à verifier).
Par exemple, sur un Linux:
on vient de créer un répertoire dont le chemin absolu est long de 391 octets, chaque element étant <= 128 octets.
La même chose sous Seven SP1 :
Et c'est bien un problème d'API, pas du filesystem, les trois premieres lignes de bash passent très bien sous Cygwin et le répertoire est accessible dans l'explorateur.
[^] # Re: choix de dossier
Posté par Zenitram (site web personnel) . Évalué à -4.
Dans ma tentative de troll, j'ai zappé cette différence, bon point!
Reste qu'il y a des limites un peu partout ;-).
J'avoue avoir eu le problème une fois. Mais fallait que ce soit vraiment tarabiscoté (moi qui mettait un chemin super long avant), si on ne veut pas troller ça reste rare comme problème (sur tous les OS)…
[^] # Re: choix de dossier
Posté par Raphaël G. (site web personnel) . Évalué à 2.
Problème pas si rare que ça, tu as créé le chemin trop long sous linux, copié/collé ou logiciel sans la limitation.
Quand tu vas tenter de supprimer l'arborescence, windows 7 par exemple va échouer.
Tu vas devoir couper des branches de l'arborescence à la racine pour pouvoir finir de supprimer tout l'arbre…
[^] # Re: choix de dossier
Posté par Antoine . Évalué à 9.
[…]
Grosse confusion ici. Sous Windows, c'est le chemin entier qui est limité à 260 caractères. Sous Linux, c'est la longueur de chaque composant qui est limitée à 255, mais un chemin peut faire jusqu'à 4096 octets (d'après les quelques sources que je trouve sur le Web).
Or, 260 caractères dans un chemin, ça s'atteint assez vite (ça m'est arrivé plusieurs fois sur divers systèmes d'intégration continue), alors que 4096 laisse beaucoup plus de marge.
(quant à la distinction octets <-> caractères, elle a peu d'impact puisque la plupart des chemins, que ce soit sous Windows ou Unix, sont majoritairement ASCII)
Ce n'est pas une "API étendue", c'est la même API mais avec une convention de nommage différente pour les chemins. Par exemple,
C:\Foo\Barsera soumis à la limite de 260 caractères, pour y échapper il faut écrire\\?\C:\Foo\Bar. Malheureusement cette syntaxe ne permet que les chemins absolus, ce qui limite la possibilité de l'utiliser toujours.[^] # Re: choix de dossier
Posté par claudex . Évalué à 8.
On le retrouve aussi dans un fichier limits.h (/usr/src/linux-headers-4.4.0-1-common/include/uapi/linux/limits.h chez moi)
On peut imaginer que les sources ne sont pas tordues et utilisent bien cette valeur.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: choix de dossier
Posté par gouttegd . Évalué à 8.
En fait c’est un peu plus compliqué que ça. POSIX définit la « valeur minimale acceptable » à 256 (
_POSIX_PATH_MAX), mais explique que la limite réelle peut être supérieure et surtout qu’elle n’est pas nécessairement constante (par exemple, elle peut varier selon le système de fichiers utilisé).Du coup, la limite réelle n’est pas à chercher dans un fichier d’en-tête, mais doit être obtenue à l’exécution avec pathconf(3).
[^] # Re: choix de dossier
Posté par steph1978 . Évalué à -8.
D'abord, c'est faux : UTF8, chaque caractère prend deux octets, tu peux donc créer en ext4 un fichier avec 128 caractères.
Faut tester avant de dire n'importe quoi.
Ensuite, quelle rapport avec le fait que sous cmd.exe, deux commandes aient un comportement différent vis à vis des noms avec espaces ?
[^] # Re: choix de dossier
Posté par Zenitram (site web personnel) . Évalué à 3. Dernière modification le 13 avril 2016 à 11:23.
Je te conseille de te renseigner sur UTF-8 et Unicode avant de dire n'importe quoi…
Ta phrase est simplement fausse (la bonne est : UTF8, chaque caractère prend 1, 2, 3, 4, 5 ou 6 octets, j'ai été gentil et me suis arrêté à 4 car l'IETF a fait une RFC limitant à 4 et a viré les 5 et 6 octets de la proposition initiale, et eu la flemme de trouver un caractère de 4 certes, mais ça ne rend pas ta phrase juste)
Faux dans le cas général, vrai dans des cas particuliers (les plus utilisés, certes) : ça dépend des caractères choisis.
La bonne phrase est : tu peux très souvent créer en ext4 un fichier avec 255 caractères, parfois ça limite à 127, parfois à 63 si tu utilises des trucs vraiment bizarre qui sont que sur 4 octets par caractères, bref ça dépend des caractères que tu choisis, tu peux juste être sûr pour 63 caractères, pas un de plus (si tu dis plus, tu assumes quelque chose de l'utilisateur).
Note : c'est rare, c'est pour troller, mais dire que Linux accepte tout nom de fichier (sans path, j'ai compris :) ) de 64 caractères est simplement faux (sur la partie "tout"), le maximum "pour sûr quoi que l'utilisateur fait) est de 63 caractères, et certains nom de fichiers seront acceptés par Windows même un vieux quand ils seront refusés par Linux.
C'était ce qu'on appelle une aparté.
[^] # Re: choix de dossier
Posté par Renault (site web personnel) . Évalué à 8.
Après, si je ne me trompe pas, dans les langues encodées sur 4 octets dans Unicode ou les langues asiatiques ne sont pas des alphabets mais des idéogrammes. Et tu as besoin de moins d'idéogrammes normalement que de lettre d'un alphabet quelconque pour exprimer la même idée.
Résultat, si en effet le nom sera plus court, en terme d'informations stockées utiles il n'est pas dit que ce soit très limitant pour ces langues là.
Je ne suis pas spécialiste de ces langues là, je peux dire des conneries sur le sujet.
[^] # Re: choix de dossier
Posté par kna . Évalué à 3.
Je ne suis pas spécialiste non plus, mais ça ne me parait pas si évident.
En japonais, il y a des idéogrammes mais aussi 2 syllabaires. Ça fait certes toujours moins de caractères pour un mot aussi long. Mais il faudrait savoir si en moyenne les mots sont plus ou moins long, ou s'il faut plus ou moins de mots pour exprimer la même idée.
[^] # Re: choix de dossier
Posté par lasher . Évalué à 4.
Les deux syllabaires, les ~10000 idéogrammes du chinois simplifié, etc., n'entrent en compte que pour le nombre de combinaisons possibles (sans tenir compte de la grammaire ou de la logique inhérentes à ces langues). Oui, les deux syllabaires du japonais peuvent (et sont) être mélangés dans une même phrase, mais au final, ça ne fait que 2×46 symboles avec la ponctuation et le chiffres en plus. Et tout ne sera pas utilisé en même temps.
Au final, si j'écris « わたしはラシャーと私はのフランスアム » (mélange d'hiragana et katakana, avec un idéogramme, car j'ai oublié tout mon japonais et j'ai laissé google traduire), je me retrouve avec 18 caractères, donc la plupart sont sans doute codés sur deux octets, et un peut-être sur plus, soit ~40 octets pour une phrase simple, mais comme on parle de noms de fichiers, ça devrait aller. :-)
[^] # Re: choix de dossier
Posté par Olivier Jeannet . Évalué à 5.
Ça dépend de ce qu'on appelle gérer, sous Linux ça peut passer avec des guillemets (comme sous Windows pour une commande "Dir") en shell, mais je ne mets jamais d'espace dans un nom de fichier, je les remplace par des "_" qui sont faits pour ça (sinon à quoi sert ce caractère d'ailleurs ?).
Quand on est un habitué de la ligne de commande pour faire des recherches ou des mini-traitements, avec par exemple des "find" ou des "locate" qui sont tubés (pipe) dans une commande qui suit, les espaces très franchement c'est ch*ant (même si en écrivant ses scripts ou commandes d'une certaines façon ça peut passer).
[^] # Re: choix de dossier
Posté par Zenitram (site web personnel) . Évalué à -10.
J'adore les excuses des "vieux" : on a appris à souffrir et s'interdire l'espace dans le nom de fichier, donc ce n'est pas gênant. Les nouveaux ne comprennent tout simplement pas "" (comme "|" qu'ils n'utilisent jamais non plus) et mettent des espaces pour désigner un espace dans leur nom de fichier (est-ce si anormal?). Avoir un "" est juste moche.
Franchement, que ce soit chiant pour ta ligne de commande à toi, ce n'est pas la priorité pour le cas général, où l'humain "normal" doit plutôt être au centre des préoccupation. Si même Linus dit que pour le desktop c'est pas terrible avec Linux, peut-être que ça vient de la publicité de gens mettant des "_" à la place de " " dans les noms de fichiers?
[^] # Re: choix de dossier
Posté par Olivier Jeannet . Évalué à 6.
Je n'ai pas "moinssé" ton commentaire mais je cherche encore le rapport entre le fait que Linux n'a pas encore pris sur le Desktop, et le fait de préférer mettre des "_" dans les noms fichiers quand on est utilisateur.
Par ailleurs je viens d'y penser, sur les sites de téléchargement (et sur la Mule) étrangement les espaces sont remplacés non pas par des "_" mais par des ".", exemple :
Weeds.6x13.Theoretical.Love.Is.Not.Dead.Vostfr.Hdtv-Ghost-Team.avi. Finalement les Windowsiens (très forte majorité d'utilisateurs de ces sites) savent remplacer les espaces quand ça facilite le fonctionnement :-) .[^] # Re: choix de dossier
Posté par Zenitram (site web personnel) . Évalué à -7. Dernière modification le 13 avril 2016 à 11:09.
C'est "l'esprit" des gens conseillant. Si pour une personne qui a un problème avec des espaces dans un nom de fichier, on lui sort "tu as tort, remplace par des underscores, comme moi", ça ne donne franchement pas envie de rester sur cet OS. C'est un "détail", mais détail+détail+…
Ton exemple est pris de gens assez conservateurs (pas les "clients finaux", mais les "sources" qui votent pour des règles et qui décident du nom). Et on voit aussi que chacun y va de son délire (underscore par ci, point par la… amusant).
Bref, juste pour dire qu'il va falloir vivre avec les espaces, car de plus en plus d'utilisateurs ne connaissent pas ces "caractères de remplacement" (et non, tout le monde n'est pas sur les site de téléchargement non plus…), et je suis plutôt dans l'idée que la machine doit s'adapter à l'homme et pas l'homme qui doit s'adapter à la machine.
[^] # Re: choix de dossier
Posté par lasher . Évalué à 7.
Pour le coup je suis assez d'accord. Gamin, j'utilisais DOS, puis quand Windows 95 est arrivé, j'ai usé et abusé des noms avec espaces (malgré l'abstraction un peu ratée, vu qu'utiliser un terminal DOS pouvait parfois toujours être nécessaire, et du coup on se retrouvait avec
monfic~1.txtau lieu demonfichieràmoiquejaime.txt). Avecbash_completionje peux facilement utiliser des espaces en ligne de commande (il rajoute les guillemets tout seul, et je suis sûr que zsh peut faire pareil), mais c'est vrai que mon réflexe est d'utiliser des underscores, et c'est vrai que je peste un peu contre les espaces dans les noms de fichiers, mais je me rends bien compte que c'est un réflexe de vieuxcon™®©.En règle générale, les espaces dans les noms de fichiers ne gênent absolument pas lorsqu'on utilise une GUI (je n'ai pas trouvé d'exemple gênant en tout cas), mais en ligne de commande ça force juste à rajouter quelques symboles (guillemets), mais bon, on s'y fait. :-)
[^] # Re: choix de dossier
Posté par Olivier Jeannet . Évalué à 2. Dernière modification le 14 avril 2016 à 10:59.
Je ne conseille l'absence d'espace que si quelqu'un veut utiliser des scripts ou faire des commandes rapides en bash. Si je mets un nouveau sous Linux je lui dis que ça peut être plus pratique d'éviter les espaces, après ce n'est pas une contrainte s'il n'utilise jamais la ligne de commande.
Je me sers aussi de l'interface graphique quand c'est plus pratique que la ligne de commande, mais quand tu vois le nombre de gens qui ont installé Cygwin rien que pour pouvoir utiliser la ligne de commande pour des petites manips, c'est qu'il y a un besoin. Et là, les espaces font vite ch*er alors que franchement avoir des " _ " dans les noms à la place des espaces je vois pas le souci, d'ailleurs j'utilise régulièrement la commande «
rename 's/ /_/g' toto* tata*» quand j'ai récupéré des fichiers avec des espaces (exemple typique avec youtube-dl sur les replay TV), c'est vite réglé.Sinon on est d'accord que la machine doit s'adapter à l'homme, mais la solution aux espaces dans les noms de fichiers et les petites manips en bash n'est pas encore satisfaisante.
[^] # Re: choix de dossier
Posté par Psychofox (Mastodon) . Évalué à 9.
Je suis tout à fait d'accord avec toi concernant la gestion des espaces qui de toute façon est assez bien gérée même en ligne de commande, à condition de penser à les prendre en compte.
En revanche moi que je me retrouve sur un windows, que j'ai besoin de faire un Ç ou un É et qu'on me répond qu'il faut passer par une combinaison de touche impliquant un ALT + un nombre à connaitre par cœur et que le reste me dis que ça va plus vite de faire un google c cédille majuscule et un copier coller…j'ai tendance à pouffer sur le Qui est prêt pour le desktop ?
[^] # Re: choix de dossier
Posté par xcomcmdr . Évalué à 4.
prends le clavier fr_oss pour Windows.
Ça change la vie.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: choix de dossier
Posté par nonas . Évalué à 3.
Ou WinCompose : https://linuxfr.org/news/sortie-de-wincompose-0-7-5
[^] # Re: choix de dossier
Posté par Psychofox (Mastodon) . Évalué à 4.
Le problème c'est qu'en général quand tu te retrouves sur un windows, c'est que t'as pas cherché, t'es pas administrateur et/ou ce n'est pas ton pc. Donc tu ne peux/veux rien installer par égard pour les autres.
(et accessoirement ça ne corrige pas le fonctionnement abérrant du caps lock)
[^] # Re: choix de dossier
Posté par Joris Dedieu (site web personnel) . Évalué à 3.
Ceux qui ont un modèle économique attirant pour les éditeurs ? Non ?
[^] # Re: choix de dossier
Posté par Olivier Jeannet . Évalué à 3.
Haha bien vu :-) .
J'ai découvert il y a longtemps le clavier x-fr-latin9 (super aussi pour taper les guillemets français « » ) mais comme l'a dit quelqu'un on n'est pas toujours admin sous son poste Windows.
(PS : j'ai beau être tout ce qu'il y a d'expérimenté en bash (et tous les petits programmes genre awk sed et compagnie) et en d'autres langages, c'est quand même vachement mieux d'éviter les espaces dans les noms de fichiers parce que de temps à autre ça complique inutilement les recherches que je fais.
[^] # Re: choix de dossier
Posté par rewind (Mastodon) . Évalué à 6.
Je te conseille la lecture de Path Name Portability, par des gens qui savent de quoi ils parlent (notamment concernant les limites). Tu y apprendras notamment que la norme POSIX elle-même considère qu'un nom portable, c'est uniquement des lettres, des chiffres et
-,_et.(et donc, pas d'espace).[^] # Re: choix de dossier
Posté par Frank-N-Furter . Évalué à 3.
POSIXLY_CORRECT
Depending on the time of day, the French go either way.
[^] # Re: choix de dossier
Posté par pushmepullme . Évalué à 3.
C'est vrai mais restons simples et homogènes autant que possibles. On serait sans doutes tous surpris du cumul des temps perdus par l'ensemble des développeurs et autres sysadmin de la planète à cause de l'espace entre Program et Files. Ça doit se chiffrer en années..
[^] # Re: choix de dossier
Posté par xcomcmdr . Évalué à 6.
"%PROGRAMFILES%", c'est pas pour les pigeons.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: choix de dossier
Posté par pushmepullme . Évalué à 0.
Merci pour l'info mais hélas encore aujourd'hui, une telle variable dans les fichiers de configurations ne donne pas le résultat escompté. Alors tu cherches, tu ne comprends pas et tu perds ton temps cf.mon commentaire du dessus. Et puis bon, ce n'était qu'un exemple. Je crois pas que %MONREPERTOIRE% existe.
[^] # Re: choix de dossier
Posté par Frank-N-Furter . Évalué à 4.
%userprofile% ?
Depending on the time of day, the French go either way.
[^] # Re: choix de dossier
Posté par karteum59 . Évalué à 8.
On est en 2016 (et Linux permet d'ailleurs aussi les noms de fichiers/répertoire avec des espaces). Je n'en suis pas fan, mais si "ça fait tout péter" comme tu dis, c'est un bug qui se doit donc d'être corrigé côté LibreSSL ! Je ne suis pas familier de la base de code LibreSSL, mais il me semble que gérer les espaces ne devrait quand même pas être la mer à boire…
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.