-
xataz édité il y a 5 ans | lien | sur : Unix/Linux : importante faille dans Sudo, le correctif disponible
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.
-
-
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é
-
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.
-
Pour moi c'est simplement installer sudo qui est une mauvaise pratique…
-
ç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.
-
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.
-
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
statusdesystemctl, mais seulement l'autoriser à utilisersystemctlou non.-
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.
-
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 UserApplipour 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 desudo, 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. -
-
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.
-
-
-
-
-
-
-
-
-
-
-
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.
-
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.
-
-
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.
-
exact, le critère de la batterie est ultra-important avec les smartphones
-
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).
-
-
PetitYoda plus de 5 ans | lien | sur : Facebook confesse avoir écouté les conversations privées de ses utilisateurs
Tout comme Amazon, Google et Apple, Facebook vient d’avouer avoir transmis des conversations privés à des sous-traitants.
-
-
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 ?
-
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.
-
-
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 !
-
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.
-
-
hyakosm plus de 5 ans | lien | sur : Pourquoi Linux n'a-t-il pas de succès sur desktop ? Entretien avec Mark Shuttleworth
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.
-
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.
-
-
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.
-
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.
-
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 ^^
-
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.
-
-
-
-
-
bortzmeyer plus de 5 ans | lien | sur : Générer un mot de passe solide | CNIL => ou les supers recommandations de sécurité...
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.
-
-
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.
-
-
-
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é.
-
“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.
-
-
-
Wallabag + nextcloud, et c'est top
-
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.
-
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 ! :)
-
-
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.
-
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.
-
-
Je plussoie à pieds joints. Achetez des jouets en bois à vos enfants, incitez-les à faire du vélo et à grimper aux arbres. Et évitez-leur les smartphones et les ordinateurs.
-
-
Petite erreur sur les SMS cela dit. Signal ne les chiffre pas.
-
-
Si je ne m'abuse, non Signal ne chiffre pas les SMS, il chiffre uniquement les messages (donc transmission par TCP/IP).
Silence, lui, permet de chiffrer les SMS et MMS.
-
-
C'est d'ailleurs pour ça que j'utilise toujours silence en application SMS par défaut, et signal en chat. La différence est surtout que pour envoyer un message par SMS, un signal gprs suffit, pour envoyer un message par signal, il faut minimum du edge. Et étant souvent en campagne, il n'est pas rare de n'avoir que du gprs.
-
-
-
-
-
-
-
Je suis totalement d'accord sur le fait que beaucoup d'utilisateurs le font en temps que consommateurs (souvent par ignorance du modèle FOSS, j'ai vu y'a pas longtemps, quelqu'un qui pensait que libreoffice, était une version de M. office gratuite et light).
Autrement, en lisant l'article, j'ai eu l'impression que tu disais que la remonté de bug n'était pas considérer comme une contribution, alors que pour moi, c'est la première contribution, et surement la plus importante.
Personnellement, j'essai de contribuer au maximum, mais quotidiennement, c'est impossible. Quand c'est possible, et que mes faibles compétences en devs le permets, je peux ajouter des features et/ou faire de la correction de bug. Sinon sur github, je star, et si bug il y a, je remonte. Je ne fais pas de documentation, car je n'ai pas un niveau rédactionnel très élevé. Pour ce qui est des dons, c'est plus compliqué (pas une question d'argent), car la je me base plus sur le comportement des devs, leurs relationnel, que sur le code ou le soft lui même, si le mec réclame un don dès qu'on lui remonte un bug, ou prends les gens de haut, il n'aura jamais un don de moi.
++
-
Lord plus de 6 ans | lien | sur : Les 5 mesures de sécurité à mettre en place immédiatement sur un nouveau routeur
Mouai mouai mouai mouai.
Première manœuvre : se connecter à un VPN… Mouai. Ça protège de quoi au final cette méthode ? Pour être anonyme sur le net ? Mouai, se protéger derrière un vendeur de VPN à 5€/mois dans l'espoir qu'ils n'obéissent pas aux lois en ne fournissant pas de logs ni de moyen d'identification…
Seconde : masquer le SSID. Bon là ça protège du voisin désirant squatter votre wifi. Tout comme un bon mot de passe. Il est préferrable d'employer un bon mot de passe et de le renouveller de temps à autres plutôt que de masquer son SSID. Tous les outils de hacks se foutent littéralement du masquage de SSID.
Troisième : couper le DHCP. Encore une fois ça protège de quoi ? De tata Jeanette qui vient squatter votre lan avec son ordi vérolé. Et voilà… Cette protection est plus facilement assuré par le filtrage de MAC mis en place en quatrième position. Et ici ça parle d'ajouter des caractères non ASCII à son SSID. Bon pas de rapport avec le DHCP et en plus ils préconisaient précédemment de le masquer mais en plus ça ne protège de rien.
Quatrième : filtrage de mac. Là c'est bon. Encore que bon une adresse MAC ça se forge mais bon c'est une protection toujours bienvenue.
La cinquième et dernière : baisser la puissance d'émission du wifi pour limiter la portée du wifi. Là aussi c'est un bon conseil.
Bref ces conseils instillent un sentiment de sécurité mais ne protège pas de grand chose et les protections qu'elles procurent ne sont pas expliquées clairement.
-
La meilleur protection, désactiver le wifi, pas de CPL.
- Ne protège pas son réseau, seulement ces communications vers l'extérieur (si vendeur sérieux et offshore)
- Le masquer ne sers strictement à rien, on se base sur l'adresse mac pour hacker un réseau wifi, pas sur le SSID. Le changer, ou changer la clé d'origine (indispensable), permets d'éviter le calcul de la clé WPA/WEP, si basé sur le nom de la box (c'était le cas sur une des box de bouygues ou sfr il me semble).
- Ne sers à rien, voir point suivant.
- Ne sers à rien également, le spoof de mac est relativement simple.
- Utile dans un studio, mais dans une maison, un peu moins.
5 mesures pas forcément utile,
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.
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.