Logo journal du hacker middle
  1. 1

    Vraiment sympa comme application, si ça pouvais être implémenté dans tout les we mails, ce serais vraiment top

    1. 2

      Excellent article, vraiment bien écrit. J’espère juste avoir des exemples plus concrète sur de vrais applications beaucoup plus complexe qu’un hello world

      1. 3

        Youhou, encore des nouveaux services !!!! Plus sérieusement, ça ne serait pas possible de se mettre d’accord sur un protocole sécurisé, avoir une vrai interopérabilité, et une vrai alternative standard au SMS. Car là je vois juste une énième application pour envoyer des messages qui vient s’ajouter a toute celles existantes, et en plus assez complexe pour le grand publique (recovery code, changement de téléphone, etc …)

        1. 2

          « Pour la première utilité, une solution assez simple serait de changer et d’utiliser un réseau social ouvert de décentralisé comme Diaspora, Mastodon, Friendica ou Movim. »

          Ce serait assez simple si on pouvait faire changer tous ses amis de réseau social mais dans la vrai vie ce n’est pas possible. Le principal obstacle c’est toujours ça et en ne répondant pas à ce problème, l’article ne répond pas à la question « comment se débarrasser de Facebook ».

          1. 2

            Bien entendu, et c’est le même problème avec tous les services de ce type (WhatsApp, Instagram, Twitter…). Le souci, c’est qu’en général, le simple fait de créer un service alternatif plus respectueux ou mieux pensé, ne suffit pas à faire changer les gens qui ont leurs habitudes et ne voient pas pourquoi ils devraient changer de service. J’en fais l’expérience au quotidien avec mes amis et ma famille à propos de Facebook, WhatsApps…

            1. 1

              C’est ce que je me dis, ce ne sont en aucun cas des services alternatifs, mais de nouveaux services plus respectueux. Même si j’ai beaucoup d’amis qui ont adopter un autre service, la seul chose que je vois c’est la multiplication des services que j’utilise pour faire exactement la même chose, je dois bien maintenant avoir une 10ene d’outils pour converser, et je n’ai toujours pas pu quitter Facebook (Messenger principalement)

          1. 1

            J’ai vu ça hier soir, j’étais rediriger vers la preprod3

            D’ailleurs mon gestionnaire de flux rss merde, et essaie toujours de taper sur preprod3, a voir si c’est pas le cache qui merdouille.

            1. 1

              yes, hier soir c’était la migration, normalement tout est bon maintenant. Tu peux en effet avoir des problèmes de cache, mais si tu ouvres un navigateur en mode privé, tu devrais avoir un comportement normal quelque soit la requête.

            1. 2

              Globalement d'accord, on évite au maximum le vendredi ou veille de jour férié, mais ça reste du cas par cas.

              Dans ma boite actuelle, c'est évolution toute les 2 semaines (le jeudi généralement), et correctif tout les Lundis et Jeudis. Hors dérogation bien évidemment.

              Mais dans mon ancienne boite, c'était différent, 2 à 3 MEP par an, où on relivrait bien souvent tout le SI, donc là c'était le vendredi, pour avoir le weekend pour récupérer ce qui pouvait mal se passer. Après les tests étaient éprouvé, début 2015 par exemple, on travaillait déjà sur les MEP de 2017. Et en 3 ans, je n'ai eu qu'une seul fois une merde qui m'a fait rester jusqu'au samedi soir.

              1. 2

                Je dirais que ça dépend de ce que tu livres et du personnel à disposition.

                Si tu livres un service qui va être utilisé immédiatement et que t'as pas d'astreinte pour le week-end, tu cours un risque fort d'avoir une coupure ou une dégradation de service pendant le week-end (puisque personne ne sera là pour réparer).

                Maintenant si t'as les équipes pour, pourquoi pas, mais en règle générale tu l'as pas et c'est le DSI qui va déranger les équipes techniques pendant le week-end alors qu'il n'y a pas d'astreinte prévue, d'où l'existence dans le métier de cette “pratique” de ne pas déployer le vendredi ,parce que la majorité des boîtes n'ont pas d'astreinte le week-end et qu'on va embêter l'équipe technique le week-end si la livraison du vendredi part en vrille.

              1. 1

                Une faille exploitable seulement avec une mauvaise configuration de sudo, mais malheureusement beaucoup de configuration par défaut comme ça.

                Sudo devrait seulement être configurer avec une liste blanche et non avec une liste noire.

                1. 1

                  Je n'ai au contraire jamais croisé la règle (ALL, !root), pas même en configuration par défaut. Ou peut-être que c'est la règle par défaut dans Mac OS, ce qui expliquerait pourquoi c'est eux qui ont trouvé la faille :).

                  1. 2

                    Quand je dis par défaut, pas out of box, mais je l'ai souvent rencontré en entreprise, car plus simple niveau configuration.

                    La configuration par défaut est par contre une faille en elle même, donner tout les droits à un utilisateur, ce n'est pas secure.

                    Autre que pour le nom de la machine, et dans le cas d'une infra mono-serveur, mono-utilisateur, le terme ALL ne devrait jamais être utilisé

                    1. 1

                      Jamais rencontré en entreprise non plus, je n'en ai pas écumé des centaines cela dit mais s'amuser à donner tous les droit sauf root à un utilisateur est de toute façon une mauvais pratique. Un responsable DSI sérieux ne laisserait jamais faire ça.

                      Mais autrement, totalement d'accord avec ton commentaire.

                      1. 1

                        Pour moi c'est simplement installer sudo qui est une mauvaise pratique…

                        1. 1

                          ça reste mieux que de donner les mots de passe des utilisateurs spécifique à plusieurs personnes, ou pire l'utilisateur root. En serveur perso ou tu es tout seul dessus, pas de soucis, mais en entreprise, quand tu dois avoir 50 personnes qui sont susceptible de devoir faire des actions, y'a rien de mieux que sudo (ou doas pour openBSD), par exemple quand tu as un services de supervision en 24/7, c'est bien qu'ils puissent être autonome dans la relance de service, sans pour autant leur donner les droits full root pour le faire.

                          1. 1

                            Non, ce ne sont quand même pas de bonne pratique, j'insiste. Les groupes et les ACLs c'est fait pour ça, et ça fonctionne très bien. Dans mon labo de recherche on fonctionne comme ça et tout le monde peut bosser sans aucun problème, y compris des développeurs ou des gens qui conçoivent des outils de mesure et les trucs qui vont avec (et qui finiront dans des satellites). Vu le fric que ça coute je t'assure qu'ont ne fait pas d'économie sur les tests.

                            Après c'est sur c'est moins pratique et il faut bosser, mais notre niveau et exigence forcément très élevé de sécurité n'est pas compromis par ce genre d'outil, ce qui dans notre cas n'est pas négociable.

                            1. 1

                              Je ne vois pas comment tu peux faire de l'administration système grâce au ACLs, à part en jouant avec le SUID et GUID, ce qui reste pire que sudo, tu augmentes grandement la surface d'attaque. Car dans ce cas ça veut dire que les administrateurs et techniciens ont des comptes avec des permissions élevés, sous Unix, un utilisateur doit être un simple utilisateur, et demander des permissions élevés temporairement (via compte root ou sudo). D'ailleurs ça m'agace de voir des connexions root sur les serveurs.

                              De plus avec les ACLs, tu peux seulement limiter l'accès (rwx) sur un fichier, par exemple tu ne peux pas dire qu'un utilisateur ne peux utiliser que l'argument status de systemctl, mais seulement l'autoriser à utiliser systemctl ou non.

                              1. 1

                                Tu viens de démontrer la supériorité des scripts init. Chez nous Systemd n'est pas du tout le bienvenu. En plus ce truc est une faille de sécurité à lui tout seul. Les évaluations en termes de sécurité et qualité de code des travaux de Lennart Poetering sont assez catastrophique…

                                Nos outils disposent des permissions nécessaire pour être utilisés. S'il le faut nos scripts init peuvent appartenir au groupe qui pourra les manipuler (c'est ultra rare par ailleurs, ils peuvent faire une quantité astronomique de choses en espace utilisateur). Les rares qui veulent être admin de leur machine sont dans un réseau à part (bac à sable). On peut aussi jouer avec des outils comme Policykit mais dans notre cas ça n'a jamais été nécessaire. Et bien évidemment personne à part les deux ASR habilité n'a de mot de passe root, jamais.

                                Alors, oui, il arrive que parfois un utilisateur viennent nous voir pour nous demander de faire un truc qu'il ne peut pas faire sans être root, mais c'est notre boulot et au passage ça nous permet d'évaluer la pertinence de la demande et de la valider ou la rejeter (et proposer une alternative). Quoi qu'il en soit, nous n'avons jamais trouvé de bonne raison ou de cas ou l'usage de sudo serait nécessaire.

                                1. 1

                                  Pour les applications métiers je comprends, c'est d'ailleurs ce qu'on fait, chaque applications à son propre utilisateur, et son lancer par un script init perso, donc chaque opérateur à le droit de lancer sudo -u UserAppli pour lancer les taches de maintenance de cette appli. Après de mon cotés, aucun outils n'est exécuter en local sur les machines, les utilisateurs n'ont que des IHM. Les devs n'ont par contre en aucun cas accès au machine, les environnements sont généré à la volée via jenkins.

                                  Par exemple dans ma boite on compte plus de 500 informaticiens (tout métier confondu), dont environs 100 pour la gestion de l'infrastructure (15 techniciens d'exploitation/supervision présent H24, 7/7j, une 20ène d'admin et ingé, les intégrateurs, les analystes etc …), chacun doit être capable à n'importe qu'elle moment de pouvoir redémarrer un serveur, ou simplement un service système ou une application, pas le choix d'avoir un accès “root” pour redémarrer sshd par exemple.
                                  Franchement j'aimerai me passer de sudo, mais franchement je ne vois pas comment faire pour que si user1 lance un script d'init d'un service, ce script se lance avec les permissions de userX.
                                  A part utiliser que des comptes génériques ou technique où on partage les mdps, on a essayé, jusqu'a ce qu'un petit malin décide de changer des mdps sans prévenir personnes.

                                  1. 1

                                    Les évaluations en termes de sécurité et qualité de code des travaux de Lennart Poetering sont assez catastrophique…

                                    Tu aurais une source à ce sujet stp ? Ca m'intéresserait.

                                    1. 2

                                      C'est le résultat d'une étude interne qui a simplement consisté en la lecture de quelque fichiers pris au hasard dans différents de ses projets. Ensuite il y a les fréquentes alertes de sécurité à propos de Systemd (mais aussi PulseAudio et d'autre trucs, internet t'en dira long), au hasard : * https://www.itprotoday.com/linux/linuxs-systemd-hit-three-security-holes * https://news.slashdot.org/story/18/10/27/196227/new-systemd-vulnerability-discovered

                                      À noter qu'à l'inverse je n'ai jamais entendu parler de graves failles de sécurité dans SystemV init ou BSD init.

                                      Il y a aussi les pétages de câbles légendaires de Linus Tovald sur le comportement de Poettering et de certains de ses développeurs. Par exemple, je ne ferait jamais confiance en des devs qui se comportent comme ça (et je comprend parfaitement la position de Torvalds) : * https://news.ycombinator.com/item?id=19023232 * https://www.phoronix.com/scan.php?page=news_item&px=mty1mza

                                      Sans compter que par principe, le processus 1 (init) doit être ultra protégé et qu'un plantage de ce processus provoque l'effondrement de tout le système. Idéalement, c'est du KISS. Et enfin le non respect des principes fondamentaux d'Unix (un outils, une tâche) ne sont pas de bon augure non plus.

                  1. 1

                    Si on veut jouer sur les mots, on ne peut pas parler de PC en entreprise. Personal Computer n'est pas le terme pour un ordinateur prêté par l'entreprise. Il me semble que l'article en question (https://upandclear.org/2019/09/22/noob-creer-un-container-docker/) est très clair, il suffit de lire (sans mauvaise foi) pour comprendre de quoi il s'agit.

                    1. 1

                      Perso dire un docker ne me choque pas plus que ça, je le fait cette abus de langage, un docker est pour moi le conteneur. Tout comme je dis souvent que j'utilise linux, je parle évidemment de distribution GNU/Linux. D'autant à l'oral c'est moins choquant, à l'écrit un peu plus (sans non plus me rendre fou, comme le terme crypter, qui me donne des boutons ^^) Par contre ce qui me “choque” un peu sur cette article, c'est plus le fait que le titre c'est “Créer un conteneur docker”, alors que on crée ici une image.

                    1. 1

                      J'avais testé Syncthing il y a quelques temps. D'autant sur desktop j'avais trouvé ça très bien, mais sur Androphone, putain que ça bouffe de la batterie, en tout cas pour la version f-droid, peux être que celle du play store utilise GCM, ce qui permets de consommer moins. Quand une appli utilise 75% de la batterie en une demi journée, alors que sans je tiens 2 jours, ça fait mal.

                      Je suis donc revenu à nextcloud, sans synchro sur mon androphone.

                      1. 1

                        exact, le critère de la batterie est ultra-important avec les smartphones

                        1. 1

                          Syncthing sur android a plusieurs options pour économiser de la batterie/de la bande passante. Par exemple, il est possible de ne synchroniser que via wifi, voire uniqement sur certains SSIDs, et il y a également des options d'intégration à la gestion d'énergie d'android. Je n'ai pas eu besoin de toucher à ces options, et n'ai aucun problème de conso (Syncthing installé depuis le play store).

                        1. 1

                          Tout comme Amazon, Google et Apple, Facebook vient d’avouer avoir transmis des conversations privés à des sous-traitants.

                          1. 1

                            Même si je n'adhère pas au pratique des GAFAM, amazon, google et apple ont une “excuse” d'écouter, celà à des fins d'amélioration de la qualités de leurs assistant vocaux. Par contre Facebook, qu'elle est le but ? Je ne le vois pas en fait

                          1. 2

                            C'est bien beau de critiquer FaceApp, mais ces conditions sont exactement les mêmes pour google, facebook, microsoft, snapchat etc … C'est le fait que l'application soit russe qui choque ou quoi ?

                            1. 1

                              En effet, au final le seul argument qui reste ce sont les droits qu'ils s'accordent sur les photos dans les CGU. Mais en quoi c'est différent de YouTube, Instagram, etc. ? Sachant que les USA sont autrement plus belliqueux que la Russie, et prompts à espionner même leurs “alliés”. Ce deux poids deux mesures commence à me fatiguer, surtout quand on le retrouve chez des médias, comme Le Monde, censés être sérieux.

                            1. 5

                              Pour ma part, je vois l'inverse. Le bureau Linux se restructure.

                              Effectivement, les installations sapins de Noël avec trouze millions d'outils incohérents avec chacun leurs dépôts, sont sur le déclin. De même que plus personne ne va rue montgallet acheter sa tour en pièces détachées. Les ordinateurs portables ont tué cela.

                              En revanche, avec une Debian + GNOME 3, j'installe le poste de madame ou de papa et j'ai la paix pour un moment. Et eux aussi. Ils ont même quelques applis proprios natives pour certains besoins spécifiques. Ils sont très heureux d'avoir un système aussi simple que leur téléphone. Pas de popups de partout, pas d'instabilité, pas de reboot avec 30 minutes de mises-à-jours, etc.

                              Alors oui, c'est d'autant plus confortable qu'on a moins de gadget dernier cri, incompatible avec la debian d'il y a deux ans. Il se trouve que ça rejoint notre souhait de plus de sobriété : plus de tablettes, moins d'écrans, etc.

                              Côté jeux, j'ai été bluffé de découvrir Lutris et la bibliothèque conséquente. J'ai aussi découvert OpenRA, une superbe implémentation d'Alerte Rouge. Il ont même réimplémenté le comportement agaçant des unités qui font des détours chez l'ennemi pour rentrer à la base !

                              Oui, les choses changent. Je ne trouve pas qu'un monde entre Google, Windows et Mac OS soit désirable. Quelle confiance leur accorder ??

                              Merci Debian, Red Hat, Canonical et les grandes entreprises qui jouent le jeu du libre et contribue un système dans lequel j'ai confiance !

                              1. 3

                                Je suis relativement du même avis. GNU/Linux se structure, et s'ouvre de plus en plus, notamment avec les nouveaux format d'application flatpak, snap et/ou appimage, qui permettent plus facilement au entreprise créant du logiciel non libre et non opensource de partager leur application sur plusieurs distribution sans risque de compatibilité. Je suis pas fan de ces technos pour les applications natives, mais pour les applications proprio, pourquoi pas, si cela peux aider.

                                Les bureaux aussi s'améliore énormément, avec une intégration sans égal, notamment kde (j'aime pas, mais je l'ai testé il y a peu) qui permets de connecter pas mal de type de compte (nextcloud, google, outlook, facebook etc …), et d'y intégrer directement les contacts au gestionnaire de contact, et les évènements directement dans le calendrier système. Il me semble que gnome 3 le permets aussi. On arrive de plus en plus à une expérience utilisateur à la Android, avec une interaction entre les applications, manque plus qu'une API générique pour tout les DE, et c'est parfait.

                                Comme tu dis, coté jeux, c'est fou les améliorations qu'il y a eu en quelques temps, merci à DXVK (désolé j'ai pas le nom du dev) et Valve pour ça, maintenant y'a facilement 50% des jeux qui tourne aussi bien que sous Windows, certains même mieux. Avec Lutris qui simplifie énormément l'installation avec DXVK, c'est top. J'avoue que j'ai toujours un Windows 10 qui me sert 1 fois par semaine pour ma partie hebdomadaire de Rainbow Six ^^.

                                J'installe énormément de distribution GNU/Linux (principalement du Ubuntu et dérivés, Linux Mint et DeepinOS) pour des utilisateurs lamba (web, mail, jeux de carte etc …), et depuis j'ai rarement d'appels pour des trucs à la con, genre “j'ai ça qui me demande de mettre à jour”, “j'ai un message qui apparait” ou “Tu peux m'installer un truc”. Tout est centralisé, les mises à jours ne sont pas intrusives, elles se font, et tu redémarre quand tu veux.

                                Je pense que ce qui tue réellement GNU/Linux, c'est la vente lié, car beaucoup de personnes achètent encore dans des grandes surfaces (carrefour ou autre), et là tu n'as pas le choix, c'est Windows (même Mac est rare). Attention, je ne dis pas que si GNU/Linux était vendu dans les grands surfaces il aurait 50% de part de marché, mais je pense qu'il pourrait atteindre un bon 10% pour se mettre au même niveau que Mac OS.

                              1. 4

                                Le problème pratique, c'est le manque de logiciels professionnels et sérieux. Les gens utilisent un ordinateur pour les logiciels, l'OS tout le monde s'en fout tant qu'on peut exécuter les logiciels voulus facilement. Linux c'est pas juste qu'il faut l'installer manuellement, c'est aussi qu'il manque beaucoup d'applications, que celles qui sont disponibles le sont en cinquante versions différentes, avec cinquante méthodes d'installation différentes et incompatibles toutes distributions confondues.

                                Le problème structurel : l'écosystème Linux est un échec parce qu'il manque des API unifiées de haut niveau pour beaucoup de choses, entre autres pour les interfaces utilisateur, pour le multimédia, pour le dessin, le son… Beaucoup de ces choses là ont été plus ou moins unifiées au niveau des environnements de bureau, ce qui est une erreur de conception historique et monumentale. Avoir des applications KDE et Gnome sur son système, ça revient presque à avoir deux OS en même temps (d'un côté une pile entière GLib / GDK / Gtk / Gstreamer…) (de l'autre une pile Qt / KF5 / KIO / Ktastrophe…). C'est un gaspillage des ressources de l'ordinateur et un gaspillage des ressources des développeurs.

                                Les outils proposés sur Linux ne sont pas sérieux pour produire des applications destinées à l'utilisateur final en 2019. Il aurait fallu quelque chose comme ça ou comme ça pour avoir un environnement solide à l'échelle du monde GNU/Linux. On a raté un tournant, même plusieurs. Avec le manque de progrès, l'essouflement de nombreux projets et maintenant l'intégration du noyau Linux dans Windows, les distributions Linux pour desktop c'est plombé, en tous cas sous la forme actuelle.

                                1. 2

                                  Un professionnel aura toujours des besoins particuliers, et choisira son OS en conséquence des besoins logiciels. Au taf j'utilise AS/400 et Unisys, ce n'est pas par plaisir, c'est qu'a l'époque de ce choix, il n'y avait que ça qui correspondait au besoin. L'utilisateur lambda n'a pas besoin de chose spécifique en général, un navigateur, un client mail, et pourquoi pas un petit solitaire pour faire le foufou.

                                  Le problème des API de haut niveau, c'est quel ne sont pas cross-platform, ce n'est qu'un avis personnels, mais pour moi une application devrait tourner sur toute les plateformes, sans distinctions, et il n'y a pas 36 000 framework existant, .NET, gtk et qt (et certaines petites librairies spécifiques à un langage). Je ne vois pas forcément le problème de faire cohabiter du qt et du gtk, sous windows j'ai de tout, du QT, du GTK et du Windows form (et surement d'autre), avec en plus le désavantages que c'est installé en double voir en triple puisque chaque application apporte sa librairies. Le problème doit être le même sous MacOS. De plus, plus c'est haut niveau, plus il y a de gaspillage de ressources de l'ordinateur, car de plus en plus d'abstraction, après ça ne m'étonne pas de voir des applications consommer 50% du CPU, et 4Go de ram juste pour la GUI.

                                  Comme je l'ai déjà, GNU/Linux aura du mal à s'imposer en Desktop tant qu'il ne sera pas vendu dans le commerce, et pré-installé, c'est d'ailleurs ce qui à fait le succès de Mac ou Windows, c'est que c'est pré-installé, si ce n'était pas le cas, l'informatique ne sera pas ce qu'elle est aujourd'hui. Et c'est le chien qui se mort la queue, tant que GNU/Linux n'aura pas plus de part du marché, les éditeurs ne seront pas intéresser par GNU/Linux, mais tant qu'il n'y aura pas plus d'éditeur sur GNU/Linux, il n'y aura pas plus de PC vendu avec.

                                1. 3

                                  Excellent article malgré une vulgarité gratuite. Il manque quand même une raison : parfois, on fait des erreurs, tout simplement. Et plus qu'on ne l'imagine. Un matin difficile, un peu de paresse ou une distraction et on glisse des erreurs, même dans la conception.

                                  Autre point, l'informatique n'est pas le bâtiment : on peut remanier beaucoup plus facilement. Donc critiquer « on aurait dû faire comme ça » ne sert à rien. Il faut faire passer l'idée qu'en logiciel évolue toujours, non seulement en terme de fonctionnalité mais dans sa structure même, dans ses technologies.

                                  1. 1

                                    La vulgarité est pour moi l'humanisation d'un article, l'humain est vulgaire de base. Enfin les gouts et les couleurs. Par contre oui l'erreur est humaine, et il n'y a que ceux qui ne font rien qui n'en font jamais, par contre faut savoir les reconnaitre, ce que dans ma boite, la majorité des devs ne font pas.

                                    L'informatique est plus proche du bâtiment que l'on crois, il y a aussi des fondations, qui sont très complexe à toucher, car la moindre modification, et tout s'écroule, et faire des tests n'est toujours pas faisable. Je l'ai vu très souvent ou tout un SI est dépendant d'un vieux système qui d'un coup n'est plus maintenu, mais qui est le coeur de se SI.

                                    1. 1

                                      la majorité des devs ne font pas.

                                      C'est vrai, moi le premier. Dans l'agilité, il y a une réflexion sur « assumer ses erreurs » à la fois pour les reconnaître mais aussi les dédramatiser, leur accorder du temps et passer à autre chose. On ne fait pas de v1.0 parfaite du premier coup. On est d'accord.

                                      On flatte énormément l'orgueil des développeurs. L'exemple des rockstar cité dans l'article est révélateur. Ça n'aide pas à accepter que « je vais faire des erreurs, j'en ferai plus sous la pression, cela doit être pris en compte dans mon travail de dév ».

                                      L'informatique est plus proche du bâtiment que l'on crois, il y a aussi des fondations, qui sont très complexe à toucher, car la moindre modification, et tout s'écroule

                                      Je suis tout à fait d'accord avec toi. J'utilise souvent le secteur du bâtiment comme analogie pour expliquer l'informatique : on retrouve les fondations, la distinction interface/arrière-boutique, l'architecture, et plein d'autres points communs.

                                      Je voulais compléter en disant que le dév a une qualité qui permet de dépasser certaines limite du bâtiment : tout est virtuel. C'est juste une question de moyen et de volonté. Avec l'analogie du bâtiment, on est tenté de négliger ce point.

                                      Si on touche un brique essentielle, on peut toujours remanier sans repartir d'une feuille blanche (et subir l'effet tunnel).

                                      Pour éviter les régressions et attaquer vaillamment le remaniement, le pire scénario que je vois est d'avoir une batterie de test selenium sur la prod, de sorte qu'on puisse valider la prod à chaque déploiement. Quand t'es dans la mouise à ce point, faut assumer :-D heureusement, pas mal de projets peuvent avoir une préprod.

                                      C'est ça qu'on a pas dans le bâtiment : cloner une maison pourrite, améliorer le clone, y habiter une journée et une nuit pour s'assurer que tout va bien et remplacer l'originale. Bien des architectes rêveraient de pouvoir faire ça !

                                      Une approche comme ça est plus coûteuse qu'une réécriture complète, mais le retour est immédiat et plus certains. Ça reste coûteux comme toute dette impayées depuis des générations ^^

                                      1. 1

                                        Après on n'aide pas les gens à assumer leurs erreurs, il suffit de voir les “réunion de crise”, la première question que les responsables posent, c'est “qui a fait une erreur ?”. La dernière réunion du type que j'ai faite, je suis partie au bout de 30 secondes, en disant “Je pensais être là pour trouver une solution, pas un coupable”. Mais on travail dans un mauvais sens, dernière grosse erreur sur le SI, j'ai d'abord pensé à une erreur de conf de mon cotés, puis j'ai contacté les devs, qui m'ont envoyés chier. Pour finir j'ai regarder le code sur le SVN, et j'ai vu que y'avait une base de données de recette en dur. J'ai remonté ça, et chercher un plan d'amélioration. Seul amélioration, j'ai perdu les droits SVN.

                                        1. 2

                                          Ah ouai… O_O Bah démissionne ! Tu peux ?

                                  1. 5

                                    Marrant, j'ai davantage confiance dans la CNIL et dans l'ANSSI que dans un message rapide qui ne donne aucun argument qualitatif ou quantitatif.

                                    1. 2

                                      Bof, tu as juste à lire la BD sur xkcd. Ça résume tous les arguments qualitatifs ou quantitatifs que tu veux. ;-)

                                      1. 2

                                        Les recommandations de la CNIL à suivre pour être certain de choisir un mauvais mot de passe. Effarant.

                                        La BD part du principe que qu'il n'y a que le premier caractère qui peux être une majuscule, et que les chiffres et caractères spéciaux sont à la fin.

                                        En réalité, on a une entropie similaire entre les deux :
                                        11 caractères aléatoire, en comptant 70 caractères possible (aAzZ + chiffre), donne une entropie de 67 bits (log(70^11)/log(2)=67),
                                        4 mots français, en comptant un dictionnaire de 90000 mots, ça donne une entropie de 66 bits (log(90000^4)/log(2)).

                                        Donc un temps de hack par brut force sera similaire. Après biensur, un mot de passe aléatoire est plus difficile à retenir. Mais un mot de passe aléatoire n'est pas prédictible, comparer à un mot de passe basé sur des mots.

                                    1. 5

                                      Tout est dit !!! Et cela ne s'applique pas qu'aux développeurs, et peux être pas qu'a l'informatique. Y'a même pire, j'ai fait un entretien récemment, avec un recruteur qui est venu vers moi, me demande ma motivation pour intégrer la société …. Heu, mec, c'est toi qui vient vers moi, c'est à toi de me montrer ta motivation à me recruter !!!

                                      J'ai l'impression que les boites galèrent en ce moment (c'est bon pour nous), je reçois une demande par jour en moyenne, et y'en a même qui après refus de ma part, me demande si je connais quelqu'un susceptible d'être intéressé.

                                      1. 1

                                        “y'en a même qui après refus de ma part, me demande si je connais quelqu'un susceptible d'être intéressé”

                                        C'est un classique.

                                        1. 1

                                          Je trouve qu'ils deviennent même agressif maintenant, message reçu ce matin (et un bon exemple d'aucune information) :

                                          Quelles sont vos disponibilités pour un échange ?
                                          Cordialement

                                      1. 2

                                        Wallabag + nextcloud, et c'est top

                                        1. 2

                                          1 petite chose à redire : - sudo est très mal utilisé dans ce cas, car si l'attaquant chope le mdp de toto, il aura un accès full root sur la machine (sudo su -). sudo doit être utilisé en mode restrictif, on refuse tout, et autorise au compte goute. Surtout dans ce cas ou ssh est accessible via mdp.

                                          1. 1

                                            Salut xataz, Effectivement, j'ai rectifié le tire en proposant la création d'un utilisateur non-root (n'étant ni dans le groupe “sudo”, ni dans le groupe “admin”) et en spécifiant au niveau de la conf SSH que seul le groupe de cet utilisateur peut se connecter. Merci pour ton retour, c'est mon premier article ! :)

                                          1. 1

                                            Encore une fois, je ne suis pas d'accord avec le fait d'enseigner le code en école. Le code est un métier (et/ou une passion), donc pourquoi faire découvrir ceci en cours, mais pas d'autres choses (Mécanique, électricité, social etc …).

                                            Autrement, en terme d'apprentissage, y'a rien de mieux que le système de notation (Avis personnel). Le droit à l'erreur est présent dans toutes les matières, ce sont les cours, a ce moment ont peu se tromper, recommencer et chercher/demander de l'aide (normalement, avec un bon prof). Puis même pendant un devoir, ont peu tester, brouillonné etc … Et faut bien valider la compréhension, avec une notation finale. Dans le monde professionnel c'est pareil, dans le code par exemple, tu as une deadline, si à la fin ton programme n'est pas fini ou pas fonctionnel, je suis pas sur que le client te donnes la note (argent) maximum.

                                            Et pour finir, l'apprentissage continu est valable pour tout, c'est juste une question de curiosité. Par exemple, je connais pas mal de dev cobol, qui ne connaisse que ça, car c'est leur métier, et point. Mais par exemple, autant niveau informatique, que mécanique ou même autre, si tu es passionné, et surtout curieux, tu apprendras tout les jours. Pour moi, ce qu'il manque à l'éducation (en général, parents/école), c'est de mettre un sens à ce qu'on apprends, et de rendre les enfants curieux.

                                            1. 1

                                              Si si ça sert à quelque chose ! Il faut faire découvrir aux enfants et essayer de leur donner envie. S'ils ressentent l'envie de continuer et que ça les intéresse, ils vont continuer l'apprentissage d'eux-mêmes. Les forcer ? Non. Les inciter à passer de l'autre côté du miroir et faire leurs propres programmes ? OUI ! Si j'ai des enfants je vais les inciter à s'amuser à expérimenter et faire des chouettes trucs si ça leur plait.

                                              1. 1

                                                Pourquoi les inciter à programmer, et pas à faire de la mécanique par exemple, ou la cuisine ou autre choses.

                                                Pour moi faut pas inciter un gamin à faire de la programmation, mais l'inciter à apprendre des choses, peu importe quoi.