Pas (encore) de 4K en TNT. En tous cas chez moi (Toulouse) il y a une chaîne de test qui tourne en boucle les même images, mais toujours pas de diffusion des chaînes nationales en 4K.
Après le standard pour le DVB-T en 4K étant le H265, ça devrait être supporté facilement dans le futur.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Posté par gUI (Mastodon) .
En réponse au message Téléphone portable.
Évalué à 5.
Dernière modification le 11 septembre 2023 à 18:05.
+1 pour les haut de gamme en fin de série, ce sont de super affaires. Attention toutefois, ils seront nécessairement mis à jour moins longtemps : l'engagement de mise à jours de 3, 4 ou même 5 ans c'est à la sortie du téléphone, pas quand toi tu l'achètes.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
le système n'a pas besoin que ce fichier soit lisible par les utilisateurs eux-même : /etc/shadow n'est pas lisible, alors que le système en a bien besoin pour vérifier le mot de passe.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Tu peux partir sur le hash dans un fichier texte. Tout comme ton /etc/passwd en fait ;)
Mais attention, ça restera facile pour le hacker de générer un nouveau hash dans ce fichier et ainsi être admin.
Du coup faudrait que tu signes ce fichier (avec ton certificat embarqué). Mais là aussi, le certificat ne doit pas être en clair dans le code sinon il pourra le modifier, ou s'en servir… Et de toutes façons, si c'est pour à la fin faire un simple if procedure_super_secure() un coup de debugger et toute ta procédure gicle.
En gros, si tu mets le produit dans les mains du hacker, il arrivera tôt ou tard à le hacker (regarde les consoles de jeu…). C'est à toi de voir où tu mets la limite selon la situation que tu vises.
Bon sinon :
- si ton produit vaut cher, est sensible, a de fortes chances d'être une cible, alors rapproche-toi d'un cabinet de cybersécu, c'est leur métier
- si c'est un produit maison et que tu veux juste pas que ce soit la fête du slip, un hash avec sel dans un fichier (et oui, le sel est en clair dans le binaire, tant pis… choisis un sel qui passe inaperçu quand tu fais un strings mon_appli.exe) ça me semblerait déjà pas dégueu.
Encore une fois, en matière de sécu faut savoir de quoi on veut se protéger : quels scénarios. Sinon on fini par se protéger de la mauvaise menace.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
C'est ça. Parce que "Robert l'a dit à Gérard mais tu le dis à personne", ou parce que "Jean-René a été viré et a pas apprécié et du coup a cherché à foutre le bordel"… Si le mot de passe sort du cercle, c'est mort.
Un mot de passe doit être révocable, tout comme un certificat.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Tout simplement tu le mets en "dur" mais pas en "clair". Tu mets par exemple son SHA256 (et tu t'assures qu'il est vraiment, vraiment très long pour être robuste à l'attaque par force brute).
Après ça reste une mauvaise idée de le mettre en "dur" : si pour une raison ou une autre il fuite, t'es mort, faut recompiler (et redéployer) l'appli.
Autre chose, tout le monde aura le même, je ne sais pas si il y a plusieurs instances de ton applis (plusieurs clients), et donc si ça fuite, ça fuite en grand (tu peux être sûr que c'est demain sur les forums spécialisés).
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
n'importe que fournisseur d'OpenID pourrait faire l'affaire non ?
oui, mais je doute fortement que leur problème soit de trouver des fournisseurs OpenID. Si ils utilisent ceux-là et uniquement ceux-là, il doit bien y avoir une raison autre que "ce sont les plus utilisées". On a quand même un beau trio Google-Facebook-Microsoft.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Première Clio, avec starter. Entre l'hiver à froid et l'été à chaud, si tu sais pas t'en servir tu peux jeter ta voiture à la poubelle tu démarreras pas 1x sur 2.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
L'employeur peut-il imposer l'utilisation d'un logiciel ou d'un service donné ?
Évidemment. Ton métier c'est ton métier. Après si t'as pas besoin du logiciel t'es pas obligé de l'utiliser (style j'utilise pas le logiciel de compta de l'entreprise), mais si tu dois faire de la compta, c'est sur le logiciel imposé par l'employeur (et rien d'autre).
Et si tous les postes sont sous Windows, alors tous les postes sont sous Windows (et pas Linux).
imaginez le cas d'un service en ligne avec des conditions craignos, genre qui stocke des infos, voire fuite des infos personnelles vous concernant
La loi c'est la loi, en France il y a le RGPD qui s'applique. Même (et surtout d'ailleurs) en entreprise. Donc ce cas n'est théoriquement pas possible.
Par exemple, un employeur peut-il imposer à un employé d'être fiché sur Facebook ou LinkeIn ?
L'employeur ne peut t'imposer que des trucs ayant un rapport avec ton activité. J'ai du mal à voir en quoi ce pourrait être obligatoire (même pour un community manager par exemple tu ferais un compte "pro").
Ou d'avoir un compte Google pour installer des logiciels sur son téléphone pro
Tu auras un compte Google pro oui.
voire sur son téléphone perso ?
Là c'est plus compliqué. J'ai déjà eu ça (le BYOD) mais c'était au volontariat. Par contre du coup tu prends des contraintes sur ton téléphone perso, à toi d'accepter ou pas.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
# Attentions aux termes
Posté par gUI (Mastodon) . En réponse au lien Travail - Patrons toxiques : il faut en finir avec la “culture des connards”. Évalué à 10.
Pas trop des "patrons" le problème, c'est plutôt en général les "chefaillons". Les 3e couteaux quoi.
Sinon de manière générale (parce que les chefs n'ont pas le monopôle de la connardise) une explication se trouve ici : https://www.youtube.com/watch?v=kJdXjtSnZTI
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Crocus 🌷 !
Posté par gUI (Mastodon) . En réponse au journal galae, le service email qui vous veut du bien ... c'est parti !. Évalué à 7.
Il est joli le logo… mais il manque de crocus :D
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
# Crocus 🌷 !
Posté par gUI (Mastodon) . En réponse au journal galae, le service email qui vous veut du bien ... c'est parti !. Évalué à 5.
La jolie nimage me donne envie de planter des crocus, c'est le moment je pense.
Quand ils sortent, c'est le premier signe du printemps :)
Sera-ce (*) le logo du service ?
(*) Que c'est laid, ça se dit au moins ?
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: RPI4
Posté par gUI (Mastodon) . En réponse au message Mise en œuvre d'un lecteur de films 4K HDR. Évalué à 5.
Pas (encore) de 4K en TNT. En tous cas chez moi (Toulouse) il y a une chaîne de test qui tourne en boucle les même images, mais toujours pas de diffusion des chaînes nationales en 4K.
Après le standard pour le DVB-T en 4K étant le H265, ça devrait être supporté facilement dans le futur.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: LineageOS
Posté par gUI (Mastodon) . En réponse au message Téléphone portable. Évalué à 3.
pour le moment…
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: haute de gamme
Posté par gUI (Mastodon) . En réponse au message Téléphone portable. Évalué à 5. Dernière modification le 11 septembre 2023 à 18:05.
+1 pour les haut de gamme en fin de série, ce sont de super affaires. Attention toutefois, ils seront nécessairement mis à jour moins longtemps : l'engagement de mise à jours de 3, 4 ou même 5 ans c'est à la sortie du téléphone, pas quand toi tu l'achètes.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: 3 étapes
Posté par gUI (Mastodon) . En réponse au message augmentation espace disque ?. Évalué à 3.
ouah merci du tuyau !
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: les deux commentaires d'avant mis ensemble :D
Posté par gUI (Mastodon) . En réponse au message augmentation espace disque ?. Évalué à 3.
Non le reste tu peux le faire dans la VM elle-même, en fonctionnement.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Bravo et Merci !
Posté par gUI (Mastodon) . En réponse au journal Quitter Gandi en prenant le chemin le plus improbable. Évalué à 8.
Oui bonne question à laquelle j'ajoute orange.fr . C'est là où on a le plus de soucis avec mon asso (email géré par Gandi).
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
# 3 étapes
Posté par gUI (Mastodon) . En réponse au message augmentation espace disque ?. Évalué à 5.
Dans l'ordre :
fdisk
resize2fs
Seule la première étape a besoin d'éteindre la VM, le reste est faisable en 'live' (au moins avec fdisk et resize2fs, pour gparted je ne sais pas).
Bien évidemment, avant de tenter tout ça, backup, backup et backup :)
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Acronymes
Posté par gUI (Mastodon) . En réponse au journal PAO avec logiciels libres au sein d’une équipe sur le long terme. Évalué à 3.
J'ai ajouté le lien vers ASBL (PAO est quand même assez connu - sans offense bien sûr :) )
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Du plus simple au plus évolué
Posté par gUI (Mastodon) . En réponse au message Comment stocker un mot de passe admin d'une application. Évalué à 3. Dernière modification le 06 septembre 2023 à 08:57.
Ah mais oui bien sûr ^^
quel con :)
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Du plus simple au plus évolué
Posté par gUI (Mastodon) . En réponse au message Comment stocker un mot de passe admin d'une application. Évalué à 3.
le système n'a pas besoin que ce fichier soit lisible par les utilisateurs eux-même : /etc/shadow n'est pas lisible, alors que le système en a bien besoin pour vérifier le mot de passe.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Du plus simple au plus évolué
Posté par gUI (Mastodon) . En réponse au message Comment stocker un mot de passe admin d'une application. Évalué à 2.
Oui j'ai fait un (gros) raccourcis. Mais du coup tiens, pourquoi les users ont besoin d'accéder à
/etc/passwd
?En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Hash
Posté par gUI (Mastodon) . En réponse au message Comment stocker un mot de passe admin d'une application. Évalué à 6.
Tu peux partir sur le hash dans un fichier texte. Tout comme ton
/etc/passwd
en fait ;)Mais attention, ça restera facile pour le hacker de générer un nouveau hash dans ce fichier et ainsi être admin.
Du coup faudrait que tu signes ce fichier (avec ton certificat embarqué). Mais là aussi, le certificat ne doit pas être en clair dans le code sinon il pourra le modifier, ou s'en servir… Et de toutes façons, si c'est pour à la fin faire un simple
if procedure_super_secure()
un coup de debugger et toute ta procédure gicle.En gros, si tu mets le produit dans les mains du hacker, il arrivera tôt ou tard à le hacker (regarde les consoles de jeu…). C'est à toi de voir où tu mets la limite selon la situation que tu vises.
Bon sinon :
- si ton produit vaut cher, est sensible, a de fortes chances d'être une cible, alors rapproche-toi d'un cabinet de cybersécu, c'est leur métier
- si c'est un produit maison et que tu veux juste pas que ce soit la fête du slip, un hash avec sel dans un fichier (et oui, le sel est en clair dans le binaire, tant pis… choisis un sel qui passe inaperçu quand tu fais un
strings mon_appli.exe
) ça me semblerait déjà pas dégueu.Encore une fois, en matière de sécu faut savoir de quoi on veut se protéger : quels scénarios. Sinon on fini par se protéger de la mauvaise menace.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Hash
Posté par gUI (Mastodon) . En réponse au message Comment stocker un mot de passe admin d'une application. Évalué à 7. Dernière modification le 05 septembre 2023 à 14:21.
C'est ça. Parce que "Robert l'a dit à Gérard mais tu le dis à personne", ou parce que "Jean-René a été viré et a pas apprécié et du coup a cherché à foutre le bordel"… Si le mot de passe sort du cercle, c'est mort.
Un mot de passe doit être révocable, tout comme un certificat.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Du plus simple au plus évolué
Posté par gUI (Mastodon) . En réponse au message Comment stocker un mot de passe admin d'une application. Évalué à 3. Dernière modification le 05 septembre 2023 à 13:55.
c'est ce que fait le fichier
/etc/password
non ? J'imagine donc que c'est déjà une protection correcte.Sinon encore plus évolué : stocker dans un TPM (donc pas dans le binaire). Là oui t'es sécure :)
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
# Hash
Posté par gUI (Mastodon) . En réponse au message Comment stocker un mot de passe admin d'une application. Évalué à 6. Dernière modification le 05 septembre 2023 à 13:47.
Tout simplement tu le mets en "dur" mais pas en "clair". Tu mets par exemple son SHA256 (et tu t'assures qu'il est vraiment, vraiment très long pour être robuste à l'attaque par force brute).
Après ça reste une mauvaise idée de le mettre en "dur" : si pour une raison ou une autre il fuite, t'es mort, faut recompiler (et redéployer) l'appli.
Autre chose, tout le monde aura le même, je ne sais pas si il y a plusieurs instances de ton applis (plusieurs clients), et donc si ça fuite, ça fuite en grand (tu peux être sûr que c'est demain sur les forums spécialisés).
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Opportunité?
Posté par gUI (Mastodon) . En réponse au journal meet.jit.si se ferme … un peu. Évalué à 5. Dernière modification le 05 septembre 2023 à 13:40.
oui, mais je doute fortement que leur problème soit de trouver des fournisseurs OpenID. Si ils utilisent ceux-là et uniquement ceux-là, il doit bien y avoir une raison autre que "ce sont les plus utilisées". On a quand même un beau trio Google-Facebook-Microsoft.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Attention à la confusion
Posté par gUI (Mastodon) . En réponse au journal meet.jit.si se ferme … un peu. Évalué à 4.
En bas de la page je vois "Jitsi on mobile - download our apps" avec les liens des apps officielles jitsi.org
Serait-ce le service officiel de jitsi.org, qui entre autre permettrait le financement du développement de l'appli par exemple ?
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Déjà dit
Posté par gUI (Mastodon) . En réponse au lien La récursivité sur linuxfr. Évalué à 4.
On est plus au comique de répétition qu'à la récursivité là…
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
# Déjà fait
Posté par gUI (Mastodon) . En réponse au lien La récursivité sur linuxfr. Évalué à 3.
https://linuxfr.org/users/gbetous/liens/qu-est-ce-que-la-recursivite
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: RTFM
Posté par gUI (Mastodon) . En réponse au journal Maltraitance informatique. Évalué à 4.
Et les motos jusqu'à peu : ma moto précédente avait encore un starter, ZZR1200 modèle 2004.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: RTFM
Posté par gUI (Mastodon) . En réponse au journal Maltraitance informatique. Évalué à 6.
Première Clio, avec starter. Entre l'hiver à froid et l'été à chaud, si tu sais pas t'en servir tu peux jeter ta voiture à la poubelle tu démarreras pas 1x sur 2.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Récapitulatif
Posté par gUI (Mastodon) . En réponse au message Imposer aux salariés ou usagers de signer un contrat tiers ?. Évalué à 4.
Évidemment. Ton métier c'est ton métier. Après si t'as pas besoin du logiciel t'es pas obligé de l'utiliser (style j'utilise pas le logiciel de compta de l'entreprise), mais si tu dois faire de la compta, c'est sur le logiciel imposé par l'employeur (et rien d'autre).
Et si tous les postes sont sous Windows, alors tous les postes sont sous Windows (et pas Linux).
La loi c'est la loi, en France il y a le RGPD qui s'applique. Même (et surtout d'ailleurs) en entreprise. Donc ce cas n'est théoriquement pas possible.
L'employeur ne peut t'imposer que des trucs ayant un rapport avec ton activité. J'ai du mal à voir en quoi ce pourrait être obligatoire (même pour un community manager par exemple tu ferais un compte "pro").
Tu auras un compte Google pro oui.
Là c'est plus compliqué. J'ai déjà eu ça (le BYOD) mais c'était au volontariat. Par contre du coup tu prends des contraintes sur ton téléphone perso, à toi d'accepter ou pas.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.