Quand j’étais en thèse, j’avais assisté à une formation organisée par mon labo sur le thème de la propriété intellectuelle et de la valorisation de la recherche.
Quand est venu le sujet des brevets, quelqu’un dans la salle a fait remarquer qu’on ne pouvait pas breveter un logiciel en Europe. Le formateur a répondu, avec le petit sourire en coin qui va bien, « vous inquiétez pas, y’a moyen ;) ».
En faisant une recherche rapide, j'ai trouvé deux petites choses : plus simple à implémenter et un peu plus résistant à une réutilisation de nonce avec une même clé. Ça me semble assez faible comme arguments.
Et pourtant ce sont bien ces arguments qui font que GCM n’a pas les faveurs des cryptologues.
Le problème, c’est que si un algo peut être mal implémenté, alors il le sera. Et c’est bien le cas de GCM.
On peut être tenté de balayer ce problème en disant « pas de la faute de l’algo, les développeurs ont qu’à faire attention », mais le consensus chez les cryptologues désormais est plutôt qu’il vaut mieux éviter de donner aux développeurs trop d’occasion de se tirer une balle dans le pied.
(La comparaison du jour : mieux vaut déporter les mitrailleuses dans les ailes de l’avion, loin de l’hélice, plutôt que de compter sur les mécaniciens pour régler correctement le système de synchronisation entre la mitrailleuse et les pales de l’hélice.)
il y’a un twitter-drama car Schnorr prétend avoir cassé RSA (ce qui mérite amplement un journal, c’est même à cela que ça sert).
S’il faut faire un journal chaque fois qu’un gus prétend quelque chose sur Twitter, il va falloir donner un peu d’argent à DLFP pour augmenter la capacité de stockage derrière le site…
(Et non, le fait que le gus en question soit un nom respectable dans le domaine ne change rien. Il y a déjà assez de la virologie où on accorde beaucoup trop d’importance aux délires de « sommités » comme Montagnier ou Raoult, j’ai pas envie qu’on en fasse de même avec la cryptographie.)
Disclaimer : Au cas où quelqu’un en douterait, je ne suis absolument pas qualifié pour évaluer la qualité d’un papier de crypto.
Par contre, on peut quand même relever facilement quelques détails qui incitent à une dose saine de scepticisme.
Comme le fait que le mot « RSA » apparaît en tout et pour tout une seule fois dans tout le papier : c’est la dernière phrase de l’abstract, “This destroys the RSA cryptosystem”. Le texte complet qui suit n’évoque plus jamais RSA. La moindre des choses quand on inclut une prétention pareille dans un abstract, c’est de la soutenir un minimum dans le corps de l’article.
Ou le fait que ça fait des années que Schnorr prétend pouvoir factoriser des entiers en temps polynomial (1991, 2009), sans qu’il n’ait jamais démontré pouvoir réellement le faire.
Pour ce que j’ai vu jusqu’à présent les cryptologues qui se sont penchés sur cette nouvelle édition ne sont pas plus impressionnés que par les éditions précédentes (ici ou là par exemple).
Si je devais générer une paire de clefs cryptographiques aujourd’hui, je n’utiliserais peut-être pas RSA (incidemment la bêta de GnuPG 2.3 est sorti la semaine dernière, elle génère des clefs ECC par défaut), mais si vous avez déjà des clefs RSA en cours d’usage, pas la peine de vous précipiter pour les jeter…
La dernière fois qu’on m’a refilé un formulaire PDF, ça commence à remonter à plusieurs années, mais Okular (KDE) faisait bien le boulot.
Sauf pour les formulaires XFA, typiquement créés par Adobe LiveCycle, qui ne font pas partie du standard PDF et qu’à ma connaissance seul Adobe Reader a jamais supporté (et encore, seulement les versions desktop pour Windows et Mac OS X).
… que quasiment personne n’utilise, comme presque toutes les fonctionnalités un tant soit peu « avancées » de ces logiciels (valable aussi bien pour MS Office que pour LibreOffice). >_<
Dans mon expérience, pour la quasi-totalité des gens, le travail collaboratif sur un document c’est à coup de CP.OLD ou méthodes assimilées.
En quinze ans, j’ai eu l’occasion de travailler avec une personne qui utilisait les fonctionnalités de versionnage et de suivi des modifications. J’en étais ému.
Note : Je ne critique pas le fait de devoir convertir les vieux .doc en .docx avant de pouvoir les éditer, je peux comprendre la stratégie derrière : plutôt que devoir gérer simultanément l’ancien et le nouveau format en lecture et écriture, on ne supporte l’ancien qu’en lecture, toute écriture ne pouvant se faire que dans le nouveau format.
C’est possiblement plus simple à gérer pour une petite startup comme Microsoft et ses moyens limités (contrairement à LibreOffice qui peut se permettre d’essayer de gérer le .doc, le .docx, le .odt, le .rtf… en lecture et en écriture), et ça a l’avantage accessoire de forcer les gens à utiliser le nouveau format (ben ouais ce serait quand même con d’avoir une position dominante et de pas s’en servir).
Mais la moindre des choses quand on choisit cette stratégie, ce serait de la mettre en œuvre correctement, avec une conversion de l’ancien format vers le nouveau qui marche… C’est pas comme si Microsoft était le mieux placé pour connaître les entrailles de leur propre format propriétaire…
(Ah, mais je viens de comprendre : les spécifications du format .doc ont probablement été conservées, dans les archives de Microsoft, au format .doc ! Du coup, aujourd’hui ils ne peuvent plus les lire ! Tout s’explique.)
Si tu fais référence à ça, non, ce n’est pas la réponse, parce que ce n’est pas le problème.
Le problème n’est pas que Word est configuré pour refuser d’ouvrir des documents trop anciens, le problème est qu’il les ouvre, mais est infichu de les éditer sans d’abord les convertir dans un format plus récent et est infichu de réaliser la conversion correctement.
La réponse est d’utiliser LibreOffice.
(Si ça se trouve, Microsoft est bien content qu’il y ait des couillons de développeurs de logiciels libres pour continuer à prendre en charge leurs vieux formats qu’ils n’ont plus envie de se fatiguer à maintenir aujourd’hui, alors qu’ils ont eux-mêmes inondé le monde de ces formats pendant des années. Pourquoi ramasser la merde de son chien quand d’autres sont prêts à le faire à votre place, hein ?)
Tu veux une killer feature de LibreOffice ? Bah tiens, j’en ai utilisé une juste ce matin.
La DRH m’envoie un formulaire à compléter et à leur retourner. Le formulaire est un .doc (pas un .docx, non, un .doc — bizarre vu que toute l’université utilise Office365 et qu’on a donc tous des versions légèrement plus récentes que Word 2003, mais bon… pas chercher à comprendre).
Le document s’affiche très bien dans la preview intégrée à Outlook, et sans problème non plus dans Word en mode lecture-seule. Je clique sur le bouton Edit pour quitter le mode lecture-seule et compléter le formulaire… Et là, c’est le drame…
« Le document doit être converti dans un format plus récent pour pouvoir être édité. Voulez-vous continuer ? Ne vous inquiétez pas, le document original sera sauvegardé. »
OK, ok, je m’en fous moi du format tant que je peux faire ce que j’ai à faire. À la DRH de se débrouiller après derrière. Sauf que… la conversion est un désastre ! La mise en page du formulaire après conversion est totalement foutue en l’air, les cases à cocher ont purement et simplement disparu, le texte déborde de tous les côtés… la comparaison avec la version ouverte en lecture seule est sans appel.
Bon. Je télécharge la version originale (toujours en .doc, donc), l’ouvre dans cette fameuse suite bureautique en perte de vitesse et qui fait des documents pas beaux. Le document s’affiche parfaitement, je le remplis, sauvegarde la version modifiée.
(Pour tester, je rouvre la version modifiée avec Word365, elle s’ouvre parfaitement – en lecture seule toujours — et mes modifications sont bien là, sans aucune perturbation de la mise en page ; par contre, si je m’aventure une nouvelle fois à passer en mode édition, rebelotte, Word365 bousille complètement le document.)
Du coup, je renvoie à la DRH mon formulaire rempli sous LibreOffice dans le format original, en maudissant au passage cette daube infâme d’Office365, qui est capable d’afficher correctement un document .doc mais ni de l’éditer ni même de le convertir sans le foutre complètement en l’air.
MERCI aux développeurs de LibreOffice de faire ce que Microsoft ne peut (ou veut ?) pas faire, à savoir gérer correctement leurs propres formats.
Suggestion pour Microsoft : un peu plus de développeurs pour faire un outil de conversion de .doc à .docx qui marche, et un peu moins de graphistes pour faire des modèles de documents super beaux, peut-être ? Juste une idée comme ça, hein.
Ah, mais je suis complètement d’accord que si tu veux sortir un document de qualité (et/ou facilement modifiable dans le temps, y compris si les consignes de mise en page changent par exemple), quel que ce soit l’outil il va falloir apprendre à s’en servir.
Mais le fait est que justement tu peux obtenir quelque chose qui « ressemble plus ou moins » à ce qui était voulu avec Word ou Writer sans avoir la moindre formation ou lire le moindre tutoriel (alors que c’est impossible avec LaTeX : « OK j’ai installé LaTeX — je fais quoi maintenant ? »). Et cela suffit à convaincre la plupart des utilisateurs qu’après tout aucune formation n’est nécessaire, ce qui leur permet après de mettre « maîtrise de la suite Office » dans la rubrique « Autres compétences » de leurs CV.
Le fait que la production du document a demandé plus de temps qu’il n’en aurait fallu à quelqu’un qui sait réellement se servir de son outil, ben… ça ne ne se voit pas une fois le document imprimé/sorti en PDF, donc tout le monde s’en fiche.
C'est destiné a être utilisé par Mme/M Michu+ et je suis pas sur que ça plaise trop aux services info qui passent leur temps à dire de pas tout accepter :)
D’autant qu’il y a un risque : si tu demandes aux utilisateurs d’installer le certificat racine de ta CA sur leurs machines, ta CA se retrouve en position d’émettre des certificats valides pour n’importe quel site.1 Tu as intérêt à faire très attention à la clef privée de ta CA…
Ça n'apporte pas d'authentification, ça ne chiffre pas les urls, ni les données de la page, mais au moins les données envoyées au serveur peuvent être chiffrées. Ça peut peut-être suffire dans mon cas.
Il va falloir sérieusement penser à ton threat model. En particulier : est-ce que tu crains les attaques actives ou pas ? On dirait que oui, vu que tu ne veux pas utiliser un certificat auto-signé « qui ne protégerait pas d’attaque “Man in the middle” ».
Si l’hypothèse d’un attaquant actif est crédible, alors ton « bricolage » en JS ne t’apporte absolument rien, et certainement pas la garantie que les données envoyées au serveur sont chiffrés.
Sauf les sites épinglés « en dur » dans le navigateur, typiquement les sites de Google & Co. ↩
Encore faut-il que les modèles de documents et les documents soient bien conçus, ce qui est assez rare.
Dans mon expérience et pour ce que ça vaut, les « modèles » fournis par quiconque me demandait un document formaté d’une certaine manière (dans mon cas c’était mon université) étaient malheureusement des exemples parfaits de ce qu’il ne faut pas faire : aucun style défini, que du formatage direct…
(Du coup je n’avais pas beaucoup de scrupules à ne pas les utiliser et à reproduire l’apparence demandé avec LaTeX. Mais quand même, c’est navrant de voir à quel point les fonctionnalités pourtant élémentaires d’un traitement de texte — parce que oui, les styles, pour moi, c’est juste la base, ça ne fait pas partie des « fonctionnalités avancées » — sont complètement sous-utilisées y compris par ceux qui sont supposés maîtriser ce genre d’outils…)
On parle souvent de séparation du fond et de la forme, mais il n'y a aucune séparation en LaTeX
Il n’y a aucune séparation automatique du fond et de la forme, non, pas plus qu’avec un traitement de texte. C’est à la charge de l’utilisateur, ni LaTeX ni n’importe quel traitement de texte ne va le faire automagiquement.
si tu veux vraiment changer l'aspect, tu es bon pour réécrire ton document pour changer les commandes
C’est à toi de prévoir dès le début d’utiliser des commandes sémantiques (ce qui peut impliquer de créer toi-même les commandes en question) plutôt que des commandes de formatage.
Exactement comme avec un traitement de texte : si tu as utilisé du formatage direct, tu es bon pour refaire tout le formatage le jour où tu veux changer l’apparence. Si tu veux éviter ça, il t’appartient d’utiliser correctement les styles (ce qui peut impliquer de créer toi-même les styles sémantiques dont tu as besoin).
beaucoup de galères pour obtenir un document qui ressemble exactement à ce qui est demandé.
Ça c’est clairement pas évident, en effet. C’est faisable, mais il faut avoir une bonne dose de motivation pour ne pas abandonner en disant « oh la barbe, je vais faire ça sous Word/Writer/whatever » :D
Après une façon assez sympa c'est de te créer un certificat d'autorité, et mettre ce certificat dans ton browser (a la suite des 10aines qui sont livrés avec) et ensuite tu n'auras pas à accepter quoi que ce soit, ton site HTTPS auto-signé sera accepté.
Ce serait clairement la meilleure solution ici, sauf qu’apparemment ykrons n’a pas la main sur les postes clients pour y ajouter sa propre CA.
Reste la possibilité d’inviter gentiment les utilisateurs à installer eux-mêmes le certificat racine de la CA. Est-ce une solution envisageable dans le contexte de la demande, seul ykrons peut le dire.
LibreOffice oui, clairement, faut seulement prendre la peine d'apprendre à l'utiliser correctement.
Complètement d’accord.
À mon avis, une différence essentielle entre LaTeX et n’importe quel traitement de texte graphique (LO Writer ou autre) est qu’avec LaTeX, le passage par « prendre la peine d’apprendre à l’utiliser » est obligatoire. Il est impossible de tirer quoi que ce soit de LaTeX (même pas un document mal fichu) sans lire un minimum de documentation — au moins un tutoriel rapide. Et la plupart des tutoriels pour LaTeX apprennent d’emblée certaines bonnes habitudes, comme utiliser les commandes sémantiques (par exemple, formatter les titres avec \section plutôt qu’avec \textbf, ce genre de choses — ce qui est plus ou moins équivalent en LaTeX à l’utilisation des styles dans un traitement de texte).
À l’inverse, nulle documentation n’est nécessaire pour un usage basique d’un traitement de texte WYSIWYG, c’est même un de leurs arguments. Le problème, c’est que du coup rares sont ceux qui prennent effectivement la peine d’apprendre à s’en servir efficacement, ce qui est dommage.
J'héberge personnellement du gitea depuis plusieurs années, et je n'ai jamais eu de bots.
Tu dois avoir un site racine super populaire didonc !
C’est malin, je vais prendre la grosse tête maintenant !
Sérieusement, si quelqu’un a une explication sur pourquoi certaines instances attirent les bots et pas d’autres (et s’il y a éventuellement des choses à faire pour éviter de les attirer), je suis preneur. Parce que chez moi, dès que j’ai ré-ouvert le formulaire d’inscription, le premier bot est arrivé après même pas dix minutes. o_O
Genre il y avait un type en embuscade qui surveillait mon site avec des jumelles, prêt à crier « Ça y est les gars, il a ré-ouvert les inscriptions ! À l’attaaaaaque ! »
Perso, je pense que j'activerais l'oauth github. Je ne pense pas qu'il y ait autant de bot sur github
C’est fait. :) On verra ce que ça donne, mais (naïvement peut-être) j’ai assez bon espoir que Github sache faire du bon boulot en la matière — vue leur position, ils ne doivent pas tellement avoir le choix…
Pas de raison particulière, c’est « au doigt mouillé. » J’abaisserai peut-être le délai à 24 h par la suite.
J'imaginais que 3 heures était un délai amplement suffisant.
Trois heures, ça me semble vraiment court.
Je peux imaginer que quelqu’un remplisse le formulaire puis, le mail de confirmation n’arrivant pas immédiatement (peut-être parce que son fournisseur fait du greylisting, ce qui peut facilement retarder la réception d’une bonne heure selon « l’agressivité » du greylisting), passe à autre chose, peut-être quitte son bureau parce que c’est la fin de la journée, et ne rouvre pas son client mail avant le lendemain matin…
Je remarque que parmi les solutions envisageables, personne ne s’est prononcé pour les CAPTCHA externes (reCAPTCHA ou hCaptcha). J’avoue que ça m’a (agréablement) surpris, je m’attendais un peu à être orienté vers cette solution, sur le mode « Ouais les reCAPTCHA, personne n’aime ça, mais enfin ça marche, alors vas-y te casse pas la tête (et pis d’toute façon tout le monde les utilise déjà, alors bon…) ».
En définitive, j’ai ré-ouvert la création de comptes locaux, avec les contraintes suivantes :
saisie d’une CAPTCHA générée nativement par Gitea (dans les faits ça n’arrête pas beaucoup de bots, mais c’est toujours ça de pris) ;
confirmation par e-mail requise, les comptes non-confirmés au bout de trois jours étant automatiquement supprimés (ça arrête presque tous les bots sauf ceux associés à des adresses Gmail, qui malheureusement représentent de loin le plus gros contingent) ;
interdiction pure et simple de créer un compte avec une adresse Gmail,1 sauf sur demande adressée directement à moi-même2 — merci à vv222 pour m’avoir suggéré cette approche à l’artillerie lourde, que je n’avais pas osé envisagé.
J’ai aussi ajouté GitHub comme fournisseur OAuth2, pour permettre à celles et ceux ayant un compte GitHub de l’utiliser pour se connecter chez moi. On verra bien si ça ouvre de nouveau la porte en grand aux bots, auquel cas je mettrais évidemment fin à l’expérience.
Demande sur papier libre à m’adresser par lettre recommandée, merci d’inclure une enveloppe timbrée libellée à votre adresse pour recevoir en réponse le mot de passe du compte nouvellement crée.↩
J’ai clairement un gros contingent de comptes fantômes associés à des adresses gmail.com, mais le reste vient d’un peu partout. J’ai du .ru, du .pw, du .nl, du .cn…
Ce qui est intéressant en revanche, c’est qu’il n’y a quasiment que les bots avec des adresses en gmail.com qui arrivent à passer l’étape de la confirmation par e-mail (REGISTER_EMAIL_CONFIRM), tous les autres sont correctement filtrés par cette étape (c’est-à-dire qu’ils créent bien des comptes, mais ne les activent jamais, ce qui permet de les nettoyer facilement).
Je ne sais pourquoi les bots gmail.com sont plus « fûtés » que les autres, mais du coup, coupler la demande de confirmation par e-mail à un refus pur et simple des adresses Gmail pourrait être une bonne solution (en laissant quand même la possibilité d’ouvrir un compte sur demande manuelle, pour les 0.01% d’utilisateurs de Gmail qui ne sont pas des bots).
Je me suis toujours demandé si finalement il ne valait pas mieux se créer un petit captcha simple dans ces cas-là.
Pas franchement motivé pour aller tripatouiller le code de Gitea (d’autant que le Go n’est pas un langage avec lequel je suis familier) pour y injecter un captcha de mon cru, même si je suis d’accord que ça pourrait être une solution suffisante.
Et pour un petit site "insignifiant" (avec tout le respect…) ça suffirait peut-être ?
Mon site est clairement insignifiant, de même que les projets que j’héberge dessus, mais le problème je pense c’est que la forge que j’utilise, elle, ne l’est pas. Gitea est assez populaire il me semble (bon, « populaire » auprès d’un certain public, évidemment), ça ne m’étonnerait pas que des bots scannent le net spécifiquement pour rechercher des instances.
Du coup, toute solution implémentée directement dans le code upstream (par opposition à un bidouillage local propre à une instance précise) ne résisterait probablement pas longtemps (comme c’est arrivé pour les CAPTCHA ”natives” de Gitea, totalement inutiles aujourd’hui).
Imagine que tu veuilles qu’on puisse te rapporter un bogue sur un petit logiciel sans importance […], qu’est-ce que tu préférerais ou que serais-tu prêt à accepter ?
Alors, de mon point de vue, « la question elle est vite répondue » en effet : l’e-mail, moi ça me convient parfaitement.
tant que tu tiens la charge par courrier électronique
Vu le nombre de rapports de bogue que je reçois, je pense que j’ai encore une marge considérable avant d’être surchargé.
(Mes logiciels ont soit très peu de bogues, soit très peu d’utilisateurs… :D )
Je n'activerais pas les fournisseurs d'identité tiers, d'expérience c'est encore pire pour les bots.
Ah zut. Je n’avais pas l’intention d’essayer Google de toute façon (vu le nombre de comptes fantômes associés à des adresses Gmail…), mais j’étais quand même tenté par GitHub… Merci pour le retour.
Ce que tu peux imaginer, c'est via un cron purger chaque jour chaque compte de plus de 5 jours qui a été créé sans générer une issue ou une pull request.
C’est ce que je faisais « manuellement » avant de désactiver purement et simplement la création de nouveaux comptes.
Gitea n’offre malheureusement pas la possibilité de supprimer massivement les comptes « inactifs ». On peut supprimer automatiquement les comptes inactivés (ceux qui n’ont pas répondu à l’e-mail de confirmation), mais pas les comptes « activés mais inactifs ».
Tiens, je sens comme une odeur de feature request…
Qu’est-ce qui empêchait les étudiants de diffuser leur code sous GPL de leur propre initiative, sans avoir à demander d’autorisation à quiconque ?
Notamment, s’agissait-il pour les étudiants d’une question de moyens ou d’un manque de droits ?
Si les étudiants avaient voulu diffuser le projet par eux-mêmes, indépendamment de leur école, auraient-ils pu le faire sans avoir à demander d’autorisation à quiconque ? Auquel cas l’autorisation du directeur pourrait se comprendre comme une « autorisation à utiliser les serveurs de l’école ».
Ou bien est-ce que l’école était par défaut titulaires des droits sur le projet, et aucune diffusion n’était possible sans cette autorisation préalable, que ce soit sur les serveurs de l’école ou n’importe où ailleurs ?
Le deuxième considérant de la lettre du directeur (« les élèves […] autorisent la publication sous licence publique GNU ») laisse penser que les étudiants ont les droits sur le code (puisqu’apparemment ce sont eux qui décident de la licence à utiliser). Mais le communiqué de VideoLAN dit que « Mr. Gourisse allowed the open-sourcing of the whole VideoLAN project under the GNU GPL », ce qui au contraire laisse penser que la libération (et pas seulement la diffusion) n’aurait pas été possible sans cette autorisation de la direction.
J’aimerais simplement savoir ce qu’il en est, excusez-moi de vouloir en savoir plus plutôt que d’accepter tel quel ce qui pour moi ressemble à un coup de comm de l’école, pour tout dire.
[^] # Re: Breveté aux USA, breveté partout ?
Posté par gouttegd . En réponse au journal OCB serait-il toujours protégé par des brevets ?. Évalué à 7.
Quand j’étais en thèse, j’avais assisté à une formation organisée par mon labo sur le thème de la propriété intellectuelle et de la valorisation de la recherche.
Quand est venu le sujet des brevets, quelqu’un dans la salle a fait remarquer qu’on ne pouvait pas breveter un logiciel en Europe. Le formateur a répondu, avec le petit sourire en coin qui va bien, « vous inquiétez pas, y’a moyen ;) ».
[^] # Re: Par rapport à GCM?
Posté par gouttegd . En réponse au journal OCB serait-il toujours protégé par des brevets ?. Évalué à 10.
Et pourtant ce sont bien ces arguments qui font que GCM n’a pas les faveurs des cryptologues.
Le problème, c’est que si un algo peut être mal implémenté, alors il le sera. Et c’est bien le cas de GCM.
On peut être tenté de balayer ce problème en disant « pas de la faute de l’algo, les développeurs ont qu’à faire attention », mais le consensus chez les cryptologues désormais est plutôt qu’il vaut mieux éviter de donner aux développeurs trop d’occasion de se tirer une balle dans le pied.
(La comparaison du jour : mieux vaut déporter les mitrailleuses dans les ailes de l’avion, loin de l’hélice, plutôt que de compter sur les mécaniciens pour régler correctement le système de synchronisation entre la mitrailleuse et les pales de l’hélice.)
[^] # Re: Mauvais lien ?
Posté par gouttegd . En réponse au journal OCB serait-il toujours protégé par des brevets ?. Évalué à 4.
Oups, erreur de copier-coller, désolé.
Le bon lien, vers la liste de discussion du groupe de travail OpenPGP.
[^] # Re: Bof
Posté par gouttegd . En réponse au journal Schnorr aurait-il cassé RSA ?. Évalué à 10.
S’il faut faire un journal chaque fois qu’un gus prétend quelque chose sur Twitter, il va falloir donner un peu d’argent à DLFP pour augmenter la capacité de stockage derrière le site…
(Et non, le fait que le gus en question soit un nom respectable dans le domaine ne change rien. Il y a déjà assez de la virologie où on accorde beaucoup trop d’importance aux délires de « sommités » comme Montagnier ou Raoult, j’ai pas envie qu’on en fasse de même avec la cryptographie.)
# Bof
Posté par gouttegd . En réponse au journal Schnorr aurait-il cassé RSA ?. Évalué à 10.
Disclaimer : Au cas où quelqu’un en douterait, je ne suis absolument pas qualifié pour évaluer la qualité d’un papier de crypto.
Par contre, on peut quand même relever facilement quelques détails qui incitent à une dose saine de scepticisme.
Comme le fait que le mot « RSA » apparaît en tout et pour tout une seule fois dans tout le papier : c’est la dernière phrase de l’abstract, “This destroys the RSA cryptosystem”. Le texte complet qui suit n’évoque plus jamais RSA. La moindre des choses quand on inclut une prétention pareille dans un abstract, c’est de la soutenir un minimum dans le corps de l’article.
Ou le fait que ça fait des années que Schnorr prétend pouvoir factoriser des entiers en temps polynomial (1991, 2009), sans qu’il n’ait jamais démontré pouvoir réellement le faire.
Pour ce que j’ai vu jusqu’à présent les cryptologues qui se sont penchés sur cette nouvelle édition ne sont pas plus impressionnés que par les éditions précédentes (ici ou là par exemple).
Si je devais générer une paire de clefs cryptographiques aujourd’hui, je n’utiliserais peut-être pas RSA (incidemment la bêta de GnuPG 2.3 est sorti la semaine dernière, elle génère des clefs ECC par défaut), mais si vous avez déjà des clefs RSA en cours d’usage, pas la peine de vous précipiter pour les jeter…
[^] # Re: The killing features
Posté par gouttegd . En réponse au journal C'est foutu pour LibreOffice. Évalué à 7.
La dernière fois qu’on m’a refilé un formulaire PDF, ça commence à remonter à plusieurs années, mais Okular (KDE) faisait bien le boulot.
Sauf pour les formulaires XFA, typiquement créés par Adobe LiveCycle, qui ne font pas partie du standard PDF et qu’à ma connaissance seul Adobe Reader a jamais supporté (et encore, seulement les versions desktop pour Windows et Mac OS X).
[^] # Re: Pourquoi vouloir toujours des versions en ligne?
Posté par gouttegd . En réponse au journal C'est foutu pour LibreOffice. Évalué à 6.
… que quasiment personne n’utilise, comme presque toutes les fonctionnalités un tant soit peu « avancées » de ces logiciels (valable aussi bien pour MS Office que pour LibreOffice). >_<
Dans mon expérience, pour la quasi-totalité des gens, le travail collaboratif sur un document c’est à coup de CP.OLD ou méthodes assimilées.
En quinze ans, j’ai eu l’occasion de travailler avec une personne qui utilisait les fonctionnalités de versionnage et de suivi des modifications. J’en étais ému.
[^] # Re: Killer feature
Posté par gouttegd . En réponse au journal C'est foutu pour LibreOffice. Évalué à 10.
Note : Je ne critique pas le fait de devoir convertir les vieux .doc en .docx avant de pouvoir les éditer, je peux comprendre la stratégie derrière : plutôt que devoir gérer simultanément l’ancien et le nouveau format en lecture et écriture, on ne supporte l’ancien qu’en lecture, toute écriture ne pouvant se faire que dans le nouveau format.
C’est possiblement plus simple à gérer pour une petite startup comme Microsoft et ses moyens limités (contrairement à LibreOffice qui peut se permettre d’essayer de gérer le .doc, le .docx, le .odt, le .rtf… en lecture et en écriture), et ça a l’avantage accessoire de forcer les gens à utiliser le nouveau format (ben ouais ce serait quand même con d’avoir une position dominante et de pas s’en servir).
Mais la moindre des choses quand on choisit cette stratégie, ce serait de la mettre en œuvre correctement, avec une conversion de l’ancien format vers le nouveau qui marche… C’est pas comme si Microsoft était le mieux placé pour connaître les entrailles de leur propre format propriétaire…
(Ah, mais je viens de comprendre : les spécifications du format .doc ont probablement été conservées, dans les archives de Microsoft, au format .doc ! Du coup, aujourd’hui ils ne peuvent plus les lire ! Tout s’explique.)
[^] # Re: Killer feature
Posté par gouttegd . En réponse au journal C'est foutu pour LibreOffice. Évalué à 10. Dernière modification le 17 février 2021 à 18:58.
Si tu fais référence à ça, non, ce n’est pas la réponse, parce que ce n’est pas le problème.
Le problème n’est pas que Word est configuré pour refuser d’ouvrir des documents trop anciens, le problème est qu’il les ouvre, mais est infichu de les éditer sans d’abord les convertir dans un format plus récent et est infichu de réaliser la conversion correctement.
La réponse est d’utiliser LibreOffice.
(Si ça se trouve, Microsoft est bien content qu’il y ait des couillons de développeurs de logiciels libres pour continuer à prendre en charge leurs vieux formats qu’ils n’ont plus envie de se fatiguer à maintenir aujourd’hui, alors qu’ils ont eux-mêmes inondé le monde de ces formats pendant des années. Pourquoi ramasser la merde de son chien quand d’autres sont prêts à le faire à votre place, hein ?)
# Killer feature
Posté par gouttegd . En réponse au journal C'est foutu pour LibreOffice. Évalué à 10.
Tu veux une killer feature de LibreOffice ? Bah tiens, j’en ai utilisé une juste ce matin.
La DRH m’envoie un formulaire à compléter et à leur retourner. Le formulaire est un .doc (pas un .docx, non, un .doc — bizarre vu que toute l’université utilise Office365 et qu’on a donc tous des versions légèrement plus récentes que Word 2003, mais bon… pas chercher à comprendre).
Le document s’affiche très bien dans la preview intégrée à Outlook, et sans problème non plus dans Word en mode lecture-seule. Je clique sur le bouton Edit pour quitter le mode lecture-seule et compléter le formulaire… Et là, c’est le drame…
« Le document doit être converti dans un format plus récent pour pouvoir être édité. Voulez-vous continuer ? Ne vous inquiétez pas, le document original sera sauvegardé. »
OK, ok, je m’en fous moi du format tant que je peux faire ce que j’ai à faire. À la DRH de se débrouiller après derrière. Sauf que… la conversion est un désastre ! La mise en page du formulaire après conversion est totalement foutue en l’air, les cases à cocher ont purement et simplement disparu, le texte déborde de tous les côtés… la comparaison avec la version ouverte en lecture seule est sans appel.
Bon. Je télécharge la version originale (toujours en .doc, donc), l’ouvre dans cette fameuse suite bureautique en perte de vitesse et qui fait des documents pas beaux. Le document s’affiche parfaitement, je le remplis, sauvegarde la version modifiée.
(Pour tester, je rouvre la version modifiée avec Word365, elle s’ouvre parfaitement – en lecture seule toujours — et mes modifications sont bien là, sans aucune perturbation de la mise en page ; par contre, si je m’aventure une nouvelle fois à passer en mode édition, rebelotte, Word365 bousille complètement le document.)
Du coup, je renvoie à la DRH mon formulaire rempli sous LibreOffice dans le format original, en maudissant au passage cette daube infâme d’Office365, qui est capable d’afficher correctement un document .doc mais ni de l’éditer ni même de le convertir sans le foutre complètement en l’air.
MERCI aux développeurs de LibreOffice de faire ce que Microsoft ne peut (ou veut ?) pas faire, à savoir gérer correctement leurs propres formats.
Suggestion pour Microsoft : un peu plus de développeurs pour faire un outil de conversion de .doc à .docx qui marche, et un peu moins de graphistes pour faire des modèles de documents super beaux, peut-être ? Juste une idée comme ça, hein.
[^] # Re: Beaux documents
Posté par gouttegd . En réponse au journal C'est foutu pour LibreOffice. Évalué à 9. Dernière modification le 15 février 2021 à 22:15.
Ah, mais je suis complètement d’accord que si tu veux sortir un document de qualité (et/ou facilement modifiable dans le temps, y compris si les consignes de mise en page changent par exemple), quel que ce soit l’outil il va falloir apprendre à s’en servir.
Mais le fait est que justement tu peux obtenir quelque chose qui « ressemble plus ou moins » à ce qui était voulu avec Word ou Writer sans avoir la moindre formation ou lire le moindre tutoriel (alors que c’est impossible avec LaTeX : « OK j’ai installé LaTeX — je fais quoi maintenant ? »). Et cela suffit à convaincre la plupart des utilisateurs qu’après tout aucune formation n’est nécessaire, ce qui leur permet après de mettre « maîtrise de la suite Office » dans la rubrique « Autres compétences » de leurs CV.
Le fait que la production du document a demandé plus de temps qu’il n’en aurait fallu à quelqu’un qui sait réellement se servir de son outil, ben… ça ne ne se voit pas une fois le document imprimé/sorti en PDF, donc tout le monde s’en fiche.
[^] # Re: Oui !
Posté par gouttegd . En réponse au message HTTPS sur réseau local. Évalué à 2.
D’autant qu’il y a un risque : si tu demandes aux utilisateurs d’installer le certificat racine de ta CA sur leurs machines, ta CA se retrouve en position d’émettre des certificats valides pour n’importe quel site.1 Tu as intérêt à faire très attention à la clef privée de ta CA…
Il va falloir sérieusement penser à ton threat model. En particulier : est-ce que tu crains les attaques actives ou pas ? On dirait que oui, vu que tu ne veux pas utiliser un certificat auto-signé « qui ne protégerait pas d’attaque “Man in the middle” ».
Si l’hypothèse d’un attaquant actif est crédible, alors ton « bricolage » en JS ne t’apporte absolument rien, et certainement pas la garantie que les données envoyées au serveur sont chiffrés.
Sauf les sites épinglés « en dur » dans le navigateur, typiquement les sites de Google & Co. ↩
[^] # Re: Beaux documents
Posté par gouttegd . En réponse au journal C'est foutu pour LibreOffice. Évalué à 7. Dernière modification le 15 février 2021 à 20:56.
Dans mon expérience et pour ce que ça vaut, les « modèles » fournis par quiconque me demandait un document formaté d’une certaine manière (dans mon cas c’était mon université) étaient malheureusement des exemples parfaits de ce qu’il ne faut pas faire : aucun style défini, que du formatage direct…
(Du coup je n’avais pas beaucoup de scrupules à ne pas les utiliser et à reproduire l’apparence demandé avec LaTeX. Mais quand même, c’est navrant de voir à quel point les fonctionnalités pourtant élémentaires d’un traitement de texte — parce que oui, les styles, pour moi, c’est juste la base, ça ne fait pas partie des « fonctionnalités avancées » — sont complètement sous-utilisées y compris par ceux qui sont supposés maîtriser ce genre d’outils…)
[^] # Re: Beaux documents
Posté par gouttegd . En réponse au journal C'est foutu pour LibreOffice. Évalué à 7.
Il n’y a aucune séparation automatique du fond et de la forme, non, pas plus qu’avec un traitement de texte. C’est à la charge de l’utilisateur, ni LaTeX ni n’importe quel traitement de texte ne va le faire automagiquement.
C’est à toi de prévoir dès le début d’utiliser des commandes sémantiques (ce qui peut impliquer de créer toi-même les commandes en question) plutôt que des commandes de formatage.
Exactement comme avec un traitement de texte : si tu as utilisé du formatage direct, tu es bon pour refaire tout le formatage le jour où tu veux changer l’apparence. Si tu veux éviter ça, il t’appartient d’utiliser correctement les styles (ce qui peut impliquer de créer toi-même les styles sémantiques dont tu as besoin).
Ça c’est clairement pas évident, en effet. C’est faisable, mais il faut avoir une bonne dose de motivation pour ne pas abandonner en disant « oh la barbe, je vais faire ça sous Word/Writer/whatever » :D
[^] # Re: Oui !
Posté par gouttegd . En réponse au message HTTPS sur réseau local. Évalué à 2.
Ce serait clairement la meilleure solution ici, sauf qu’apparemment ykrons n’a pas la main sur les postes clients pour y ajouter sa propre CA.
Reste la possibilité d’inviter gentiment les utilisateurs à installer eux-mêmes le certificat racine de la CA. Est-ce une solution envisageable dans le contexte de la demande, seul ykrons peut le dire.
[^] # Re: Oui !
Posté par gouttegd . En réponse au message HTTPS sur réseau local. Évalué à 5.
Oui, c’est tout-à-fait possible.
Par contre, aucune CA ne délivrera de certificat pour une IP privée (ou un nom d’hôte local), c’est interdit par le CA/Browser Forum.
[^] # Re: Beaux documents
Posté par gouttegd . En réponse au journal C'est foutu pour LibreOffice. Évalué à 10. Dernière modification le 15 février 2021 à 11:57.
Complètement d’accord.
À mon avis, une différence essentielle entre LaTeX et n’importe quel traitement de texte graphique (LO Writer ou autre) est qu’avec LaTeX, le passage par « prendre la peine d’apprendre à l’utiliser » est obligatoire. Il est impossible de tirer quoi que ce soit de LaTeX (même pas un document mal fichu) sans lire un minimum de documentation — au moins un tutoriel rapide. Et la plupart des tutoriels pour LaTeX apprennent d’emblée certaines bonnes habitudes, comme utiliser les commandes sémantiques (par exemple, formatter les titres avec \section plutôt qu’avec \textbf, ce genre de choses — ce qui est plus ou moins équivalent en LaTeX à l’utilisation des styles dans un traitement de texte).
À l’inverse, nulle documentation n’est nécessaire pour un usage basique d’un traitement de texte WYSIWYG, c’est même un de leurs arguments. Le problème, c’est que du coup rares sont ceux qui prennent effectivement la peine d’apprendre à s’en servir efficacement, ce qui est dommage.
[^] # Re: Écrire son propre captcha ?
Posté par gouttegd . En réponse au journal Gitea contre les bots. Évalué à 3.
C’est malin, je vais prendre la grosse tête maintenant !
Sérieusement, si quelqu’un a une explication sur pourquoi certaines instances attirent les bots et pas d’autres (et s’il y a éventuellement des choses à faire pour éviter de les attirer), je suis preneur. Parce que chez moi, dès que j’ai ré-ouvert le formulaire d’inscription, le premier bot est arrivé après même pas dix minutes. o_O
Genre il y avait un type en embuscade qui surveillait mon site avec des jumelles, prêt à crier « Ça y est les gars, il a ré-ouvert les inscriptions ! À l’attaaaaaque ! »
C’est fait. :) On verra ce que ça donne, mais (naïvement peut-être) j’ai assez bon espoir que Github sache faire du bon boulot en la matière — vue leur position, ils ne doivent pas tellement avoir le choix…
[^] # Re: Follow-up
Posté par gouttegd . En réponse au journal Gitea contre les bots. Évalué à 9.
Pas de raison particulière, c’est « au doigt mouillé. » J’abaisserai peut-être le délai à 24 h par la suite.
Trois heures, ça me semble vraiment court.
Je peux imaginer que quelqu’un remplisse le formulaire puis, le mail de confirmation n’arrivant pas immédiatement (peut-être parce que son fournisseur fait du greylisting, ce qui peut facilement retarder la réception d’une bonne heure selon « l’agressivité » du greylisting), passe à autre chose, peut-être quitte son bureau parce que c’est la fin de la journée, et ne rouvre pas son client mail avant le lendemain matin…
# Follow-up
Posté par gouttegd . En réponse au journal Gitea contre les bots. Évalué à 4.
Merci pour tous les commentaires pertinents.
Je remarque que parmi les solutions envisageables, personne ne s’est prononcé pour les CAPTCHA externes (reCAPTCHA ou hCaptcha). J’avoue que ça m’a (agréablement) surpris, je m’attendais un peu à être orienté vers cette solution, sur le mode « Ouais les reCAPTCHA, personne n’aime ça, mais enfin ça marche, alors vas-y te casse pas la tête (et pis d’toute façon tout le monde les utilise déjà, alors bon…) ».
En définitive, j’ai ré-ouvert la création de comptes locaux, avec les contraintes suivantes :
J’ai aussi ajouté GitHub comme fournisseur OAuth2, pour permettre à celles et ceux ayant un compte GitHub de l’utiliser pour se connecter chez moi. On verra bien si ça ouvre de nouveau la porte en grand aux bots, auquel cas je mettrais évidemment fin à l’expérience.
Avec l’option
EMAIL_DOMAIN_BLOCKLIST, qui je l’espère sera disponible à partir de Gitea 1.15.0. ↩Demande sur papier libre à m’adresser par lettre recommandée, merci d’inclure une enveloppe timbrée libellée à votre adresse pour recevoir en réponse le mot de passe du compte nouvellement crée.↩[^] # Re: Bloquer les GAFAM
Posté par gouttegd . En réponse au journal Gitea contre les bots. Évalué à 4.
J’ai clairement un gros contingent de comptes fantômes associés à des adresses
gmail.com, mais le reste vient d’un peu partout. J’ai du.ru, du.pw, du.nl, du.cn…Ce qui est intéressant en revanche, c’est qu’il n’y a quasiment que les bots avec des adresses en
gmail.comqui arrivent à passer l’étape de la confirmation par e-mail (REGISTER_EMAIL_CONFIRM), tous les autres sont correctement filtrés par cette étape (c’est-à-dire qu’ils créent bien des comptes, mais ne les activent jamais, ce qui permet de les nettoyer facilement).Je ne sais pourquoi les bots
gmail.comsont plus « fûtés » que les autres, mais du coup, coupler la demande de confirmation par e-mail à un refus pur et simple des adresses Gmail pourrait être une bonne solution (en laissant quand même la possibilité d’ouvrir un compte sur demande manuelle, pour les 0.01% d’utilisateurs de Gmail qui ne sont pas des bots).[^] # Re: Écrire son propre captcha ?
Posté par gouttegd . En réponse au journal Gitea contre les bots. Évalué à 3.
Pas franchement motivé pour aller tripatouiller le code de Gitea (d’autant que le Go n’est pas un langage avec lequel je suis familier) pour y injecter un captcha de mon cru, même si je suis d’accord que ça pourrait être une solution suffisante.
Mon site est clairement insignifiant, de même que les projets que j’héberge dessus, mais le problème je pense c’est que la forge que j’utilise, elle, ne l’est pas. Gitea est assez populaire il me semble (bon, « populaire » auprès d’un certain public, évidemment), ça ne m’étonnerait pas que des bots scannent le net spécifiquement pour rechercher des instances.
Du coup, toute solution implémentée directement dans le code upstream (par opposition à un bidouillage local propre à une instance précise) ne résisterait probablement pas longtemps (comme c’est arrivé pour les CAPTCHA ”natives” de Gitea, totalement inutiles aujourd’hui).
[^] # Re: Crée les comptes manuellement
Posté par gouttegd . En réponse au journal Gitea contre les bots. Évalué à 3.
Alors, de mon point de vue, « la question elle est vite répondue » en effet : l’e-mail, moi ça me convient parfaitement.
Vu le nombre de rapports de bogue que je reçois, je pense que j’ai encore une marge considérable avant d’être surchargé.
(Mes logiciels ont soit très peu de bogues, soit très peu d’utilisateurs… :D )
[^] # Re: une option
Posté par gouttegd . En réponse au journal Gitea contre les bots. Évalué à 4.
Ah zut. Je n’avais pas l’intention d’essayer Google de toute façon (vu le nombre de comptes fantômes associés à des adresses Gmail…), mais j’étais quand même tenté par GitHub… Merci pour le retour.
C’est ce que je faisais « manuellement » avant de désactiver purement et simplement la création de nouveaux comptes.
Gitea n’offre malheureusement pas la possibilité de supprimer massivement les comptes « inactifs ». On peut supprimer automatiquement les comptes inactivés (ceux qui n’ont pas répondu à l’e-mail de confirmation), mais pas les comptes « activés mais inactifs ».
Tiens, je sens comme une odeur de feature request…
[^] # Re: Quand, en 2001, le directeur de Centrale diffuse le projet Videolan
Posté par gouttegd . En réponse au lien Videolan a 20 ans. Évalué à 2.
Pourquoi l’aval du directeur était nécessaire ?
Qu’est-ce qui empêchait les étudiants de diffuser leur code sous GPL de leur propre initiative, sans avoir à demander d’autorisation à quiconque ?
Notamment, s’agissait-il pour les étudiants d’une question de moyens ou d’un manque de droits ?
Si les étudiants avaient voulu diffuser le projet par eux-mêmes, indépendamment de leur école, auraient-ils pu le faire sans avoir à demander d’autorisation à quiconque ? Auquel cas l’autorisation du directeur pourrait se comprendre comme une « autorisation à utiliser les serveurs de l’école ».
Ou bien est-ce que l’école était par défaut titulaires des droits sur le projet, et aucune diffusion n’était possible sans cette autorisation préalable, que ce soit sur les serveurs de l’école ou n’importe où ailleurs ?
Le deuxième considérant de la lettre du directeur (« les élèves […] autorisent la publication sous licence publique GNU ») laisse penser que les étudiants ont les droits sur le code (puisqu’apparemment ce sont eux qui décident de la licence à utiliser). Mais le communiqué de VideoLAN dit que « Mr. Gourisse allowed the open-sourcing of the whole VideoLAN project under the GNU GPL », ce qui au contraire laisse penser que la libération (et pas seulement la diffusion) n’aurait pas été possible sans cette autorisation de la direction.
J’aimerais simplement savoir ce qu’il en est, excusez-moi de vouloir en savoir plus plutôt que d’accepter tel quel ce qui pour moi ressemble à un coup de comm de l’école, pour tout dire.