Je comprends parfaitement ton mécontentement t'inquiète pas :-)
Je dis juste que c'est principalement une limitation technique.
Typiquement, sur une distrib pas trop moderne, n'importe quelle application que tu installes/lances en tant que ton utilisateur a déjà tous ces droits, et ça ne te choque pas. (la différence étant qu'il ne l'affiche pas)
Et quand bien même le bootloader serait moins fermé qu'avant, je ne vois pas en quoi un téléphone Android bloaté serait fondamentalement différent d'un ordinateur livré ous Windows : pour avoir un truc libre, il faut réinstaller l'OS.
On est parfaitement d'accord. C'est d'ailleurs exactement ce que j'ai dit: « De mon point de vue, un téléphone Android est actuellement aussi libre qu'un ordinateur. »
Ma réaction était sur:
« De manière générale, et ça n'est pas nouveau, ces appareils ne font pas ce qu'on leur demande. Ils n'appartiennent pas à leur propriétaire légitime, ils travaillent pour l'entreprise qui les a programmé. »
Ton commentaire me fait rugir.
Google/Android est férocement anti-NSA, et anti logiciel proprio pour les services "de coeur".
Les services de communication avec le modem ont des politiques SELinux des plus violentes (d'ailleurs ils se prennent pas mal d'erreurs)
La grande majorité des téléphones Android récents ont un bootloader ouvert/ouvrable.
L'architecture des téléphones a pas mal changé depuis l'époque des smartphone.
À l'heure actuelle un téléphone à base de Qualcomm peut être compilé et fonctionnel avec juste des daemons de communication avec le modem. Les sources Android modifiées par Qualcomm sont disponibles sur https://www.codeaurora.org
Certains constructeurs fournissent les quelques binaires à mettre pour avoir un support matériel complet sur l'Android opensource (AOSP), par exemple: http://developer.sonymobile.com/knowledge-base/open-source/open-devices/list-of-devices-and-resources/
Les modems n'ont même plus d'accès direct au stockage (trop complexe à implémenter), tout passe par un proxy userland, non root, et ils se font booter par Linux lui-même.
De mon point de vue, un téléphone Android est actuellement aussi libre qu'un ordinateur.
Les communications avec l'extérieur ne sont pas libres, le début du boot n'est pas libre/dans un autre processeur, les drivers 3D ne sont pas libres, et il n'y a pas de morceau proprio dans le kernel.
En fait, le fait que que tu ne puisses pas désinstaller l'appli, ça veut dire que c'est une application dites shareduid system, ou platform. Ce pouvoir est utilisé pour certaines fonctions non prévues par l'API standard Android, et donc pour lesquels il faut les droit tout puissant. En particulier, pour tuer toutes les applications, il faut avoir ce droit.
Maintenant, quand une application utilise le mécanisme de shareduid (littéralement que deux applications partagent le même uid unix), Android affiche (et donne de fait.) tous les droits que chacune de ces applications ont demandés à toutes les applications.
Le développeur de cette application ne peut pas afficher "pour de vrai" les permissions utilisées.
En pratique tu trouveras de nombreuses applications dans ton téléphone qui ont cette liste intégrale de permissions.
Que le code GPL soit publié, c'est "juste" une obligation légale, encore heureux qu'ils le publient!
Y a pas de quoi générer un firmware alternatif pour autant
Bah, le monsieur du journal dit:
« La question qui fache : combien de blobs binaires à sources fermées là dedans ? En attendant, moi je choisi Parrot (un seul module non libre : pour l'audio, et pas fait par parrot. Le reste est sous GPL. Bravo. Accès root, source, facilités, bonnes docs/commentaires. »
Du coup je comprends pas vraiment…
(pour Qualcomm c'est un peu pareil, ce qui est sur le processeur principal est libre, à part le driver GPU, le code des DSPs est proprio, mais programmable)
Ça tient plus de l'interprétation, mais « dont les spécifications techniques sont publiques et sans restriction d'accès ni de mise en œuvre »
pour moi ça signifie qu'on peut le modifier pour faire sa propre version/on est pas obligé de respecter à la lettre la specif.
D'ailleurs, la licence d'Adobe Flash est identique à celle de VP9 depuis un certain temps (la différence étant que dans un cas c'est du copyright, dans l'autre des patents). Le format est publiquement disponible, et tu as le droit d'implémenter ton propre player, à condition qu'il soit pixel perfect.
Le développeur n'est même pas libre d'avoir de bug.
Si vous ne définissez pas de phrase secrète, vous pouvez utiliser le cloud de Google en laissant Google lire vos données.
Si tu ne mets pas de clefs de chiffrement, alors les données sont "en clair" (chiffrées avec mot de passe du compte, whatever), donc Google peut y accedér.
Pour moi c'est une formulation purement technique, et ne veut pas dire que Google le fera.
Une formulation beaucoup moins "Google is the evil" est juste que s'ils se reçoivent un mandat de la police, alors ils pourront le lire, donc si tu veux te protéger de ça, mets une passephrase.
Tu te plains que tu demandes à ton navigateur web d'enregistrer tes mots de passes dans le cloud, et t'es choqué de pouvoir relire les mots de passes en question ?
Ça perdrait de son intérêt s'il n'était pas capable de les relire…
Je vois pas vraiment comment sans mot de passe (ou du moins sans secret partagé entre les clients) un client peut chiffrer les données.
Ou alors on parle de chiffrements de communication entre le client et le serveur, ce que Google fait déjà?
S'ils font ça, c'est pas par volonté de nuire, d'espionner ou quoique ce soit de vilain, c'est que ça existe déjà et ça marche.
Cf http://fortune.com/2015/05/22/a-chinese-app-that-steals-wifi-passwords-just-raised-50-million/ :
Il existe en Chine une application mobile de partage de mot de passes sur exactement le même principe, qui est utilisée par 270 Millions d'habitants. Genre, plus que le marché de Windows aux USAs.
Donc proposer l'option ne parait pas déraisonnable, vu qu'il doit répondre à un besoin de plus d'un quart des clients de Microsoft (bon euh client… utilisateurs du moins.)
Euh…
Le lien que tu cites ne parles que des services en hotel/aéroport/centre de conférence, bref certainement pas les WiFi personnels, dont il est question ici.
Je pense que s'ils prévoient de partager les mots de passes WiFi à plus que juste les amis facebook, ça sera pour un service type Fon.
En plus, ces WiFi sont généralement trustés depuis plusieurs générations et pour encore plusieurs autres à venir, par nos gros opérateurs adorés.
Aucune information n'est donnée, mais pour moi c'est juste un partenariat avec les opérateurs WiFi de "centres d'intérêts", dont il est question ici.
Ouaip, mais globalement ça va en s'améliorant.
Tous les constructeurs de puces (même les chinois, Mediatek, Rockchip, Allwinner du moins) se mettent à pousser des morceaux dans Linux, et Qualcomm (le constructeur Android "historique") se met au vert, en avançant sur l'usage d'API standard (genre leur driver 3D utilise DRM maintenant, ils ont l'API standard de GPIO et clocks, ils utilisent les device-tree, …).
Ils tournaient avec des kernel fait par Qualcomm (kernel dispo sur leur page opensource, https://www.codeaurora.org), potentiellement légèrement modifié par le constructeur
Et ça va durer, même maintenant que Linux 4.1 est sorti, vu que les kernel Android ont toujours 3 ans de retard.
Je peux être à côté de la plaque, mais ma compréhension du terme est très différente.
Pour moi, DevOps désigne les administrateurs systèmes qui travaillent comme des développeurs:
Par exemple:
Une configuration est sous git, et faire le git push déploie automatiquement la configuration partout.
Une nouvelle machine à déployer prend quelques minutes au devops.
Il existe des branches master et des branches "stables", les branches master étant les systèmes "en dév"
Et ensuite, il y a des outils de tests continu d'intégration pour vérifier sur la branche master que rien n'est cassé
Il se trouve que les outils les plus couramment utilisés pour ce type de développement est docker, lxc, ou plus basiquement des scripts autour de debootstrap, et il est plus difficile de faire la même chose sur des systèmes propriétaires, donc il se trouve que la majorité des DevOps utilisent des outils libres, mais il n'y a pas de lien dur entre DevOps et libre.
J'ai testé Sailfish OS (l'os de jolla) sur Nexus 5
Et pour le coup je trouve le store beaucoup trop petit, mais l'UI super bien léchée, et avec des bonnes idées.
Mais tu viens de me faire découvrir qu'il est compatible avec des applis Android, donc ça m'ouvre plein de possibilités, merci :)
Rajouter un mode d'économie d'énergie pour avoir plus d'autonomie, c'est pas dur, suffit de couper les data, le wifi, réduire la luminosité, etc.
Google a annoncé des optimisations batteries pour Android L et M, qui sont du même acabit:
- En dessous de 15%, t'as une notification qui te propose d'activer le mode économie (qui fait ce que j'ai dit au dessus)
- Sur Android M ils essaient d'être plus intelligents, et déterminent avec l’accéléromètre si le téléphone est utilisé, et ne réactiver les communications avec les serveurs que quand y a du mouvement.
Perso sur mon Nexus 5, c'est une catastrophe, mes mails ne sont plus synchronisés que deux fois par jour
Moui, alors effectivement, quand t'as une caméra à profondeur de champ, dans une tablette prévue pour faire du SLAM (Simultaneous Localisation and Mapping), encore heureux qu'ils arrivent à faire de la localisation -_-'
Mais sans caméra ils pourraient pas.
Ma formulation est volontairement flou.
Je fais partie des gens qui considère que le NAT n'est jamais une solution de sécurité en soit, et effectivement ici non plus, le NAT n'apporte pas intrinsèquement de sécurité.
Juste, le NAT fait qu'il est plus facile de comprendre/faire des schémas de ce qu'il se passe, et le pare-feu se fait de la manière classique, à savoir selon l'adressage réseau.
Aussi, le filtrage par cgroups est moins testé, et a plus de chances d'avoir des failles. (typiquement je vois pas d'option à lxc pour rester dans le même namespace réseau, mais après c'est peut-être plus philosophique de leur part)
Tant qu'à faire, tu mets une machine virtuelle qui limite limite au niveau de l'interface ethernet, encore plus simple ! Et c'est encore plus secure !
docker n'est qu'un ensemble de scripts autour de "vraies" technos (comme les namespaces), évidement que si c'est faisable avec docker, c'est faisable sans trop de complexité avec autre chose.
En l’occurrence, pas besoin de namespace network (qui serait un bordel sans nom à gérer avec du NAT au milieu, mais qui est pas forcement une mauvaise option si on veut un système sécurisé), on peut utiliser iptables pour marker des paquet en fonction du pid, de l'uid et/ou du cgroup, et après cette mark peut être utilisée par le shaper.
En plus simpliste, iptables intègre des rate limiters (mais c'est en nombre de paquets par seconde).
La seule vraie question est de séparer les process par cgroups, heureusement systemd est là ! (pas taper.)
Un peu quand même.
La plupart des algos de compressions d'image consiste à prendre une version basse résolution, à l'agrandir, et à corriger les erreurs.
Moins d'erreurs à corriger, ça fait un fichier plus petit.
Je pense que tu exagères considérablement. Les attaques tels que CRIME doivent avoir un certain nombre d'autres pré-requis qui ne sont pas réunis dans toutes les situations.
Certes. Après, le monsieur en haut demandé un algo prouvé qui fasse compression ET chiffrement, et je pensais qu'il voulait ça pour pouvoir augmenter la sécurité du système, en fait vu les autres messages, c'est plus une question de vitesse.
Effectivement la seule attaque connue/vaguement exploitable est en attaque à clair choisi, et potentiellement l'auteur n'est pas dans ce cas. On parle typiquement de GPG plus bas, sauf si c'est script, il n'y a pas d'attaque à clair choisi possible.
[^] # Re: Application vs. Système
Posté par Ph Husson (site web personnel) . En réponse au journal Mise à jour Samsung S5, Smart Manager de votre vie privée.. Évalué à 1.
C'est clairement plus complexe.
[^] # Re: Mauvaises permissions
Posté par Ph Husson (site web personnel) . En réponse au journal Mise à jour Samsung S5, Smart Manager de votre vie privée.. Évalué à 6.
Je comprends parfaitement ton mécontentement t'inquiète pas :-)
Je dis juste que c'est principalement une limitation technique.
Typiquement, sur une distrib pas trop moderne, n'importe quelle application que tu installes/lances en tant que ton utilisateur a déjà tous ces droits, et ça ne te choque pas. (la différence étant qu'il ne l'affiche pas)
[^] # Re: Application vs. Système
Posté par Ph Husson (site web personnel) . En réponse au journal Mise à jour Samsung S5, Smart Manager de votre vie privée.. Évalué à 4.
On est parfaitement d'accord. C'est d'ailleurs exactement ce que j'ai dit: « De mon point de vue, un téléphone Android est actuellement aussi libre qu'un ordinateur. »
Ma réaction était sur:
« De manière générale, et ça n'est pas nouveau, ces appareils ne font pas ce qu'on leur demande. Ils n'appartiennent pas à leur propriétaire légitime, ils travaillent pour l'entreprise qui les a programmé. »
[^] # Re: Application vs. Système
Posté par Ph Husson (site web personnel) . En réponse au journal Mise à jour Samsung S5, Smart Manager de votre vie privée.. Évalué à 10.
Ton commentaire me fait rugir.
Google/Android est férocement anti-NSA, et anti logiciel proprio pour les services "de coeur".
Les services de communication avec le modem ont des politiques SELinux des plus violentes (d'ailleurs ils se prennent pas mal d'erreurs)
La grande majorité des téléphones Android récents ont un bootloader ouvert/ouvrable.
L'architecture des téléphones a pas mal changé depuis l'époque des smartphone.
À l'heure actuelle un téléphone à base de Qualcomm peut être compilé et fonctionnel avec juste des daemons de communication avec le modem. Les sources Android modifiées par Qualcomm sont disponibles sur https://www.codeaurora.org
Certains constructeurs fournissent les quelques binaires à mettre pour avoir un support matériel complet sur l'Android opensource (AOSP), par exemple: http://developer.sonymobile.com/knowledge-base/open-source/open-devices/list-of-devices-and-resources/
Les modems n'ont même plus d'accès direct au stockage (trop complexe à implémenter), tout passe par un proxy userland, non root, et ils se font booter par Linux lui-même.
De mon point de vue, un téléphone Android est actuellement aussi libre qu'un ordinateur.
Les communications avec l'extérieur ne sont pas libres, le début du boot n'est pas libre/dans un autre processeur, les drivers 3D ne sont pas libres, et il n'y a pas de morceau proprio dans le kernel.
# Mauvaises permissions
Posté par Ph Husson (site web personnel) . En réponse au journal Mise à jour Samsung S5, Smart Manager de votre vie privée.. Évalué à 10.
En fait, le fait que que tu ne puisses pas désinstaller l'appli, ça veut dire que c'est une application dites shareduid system, ou platform. Ce pouvoir est utilisé pour certaines fonctions non prévues par l'API standard Android, et donc pour lesquels il faut les droit tout puissant. En particulier, pour tuer toutes les applications, il faut avoir ce droit.
Maintenant, quand une application utilise le mécanisme de shareduid (littéralement que deux applications partagent le même uid unix), Android affiche (et donne de fait.) tous les droits que chacune de ces applications ont demandés à toutes les applications.
Le développeur de cette application ne peut pas afficher "pour de vrai" les permissions utilisées.
En pratique tu trouveras de nombreuses applications dans ton téléphone qui ont cette liste intégrale de permissions.
[^] # Re: code des drones parrot ?
Posté par Ph Husson (site web personnel) . En réponse au journal Qualcomm & les drones & Ubuntu. Évalué à 2.
Un article dans Nature, on considère qu'il est publié?
[^] # Re: code des drones parrot ?
Posté par Ph Husson (site web personnel) . En réponse au journal Qualcomm & les drones & Ubuntu. Évalué à 1.
Que le code GPL soit publié, c'est "juste" une obligation légale, encore heureux qu'ils le publient!
Y a pas de quoi générer un firmware alternatif pour autant
[^] # Re: code des drones parrot ?
Posté par Ph Husson (site web personnel) . En réponse au journal Qualcomm & les drones & Ubuntu. Évalué à 5.
Bah, le monsieur du journal dit:
« La question qui fache : combien de blobs binaires à sources fermées là dedans ? En attendant, moi je choisi Parrot (un seul module non libre : pour l'audio, et pas fait par parrot. Le reste est sous GPL. Bravo. Accès root, source, facilités, bonnes docs/commentaires. »
Du coup je comprends pas vraiment…
(pour Qualcomm c'est un peu pareil, ce qui est sur le processeur principal est libre, à part le driver GPU, le code des DSPs est proprio, mais programmable)
[^] # Re: 927
Posté par Ph Husson (site web personnel) . En réponse au journal Un codec libre ? ... Oui Madame !!!. Évalué à 3.
Ça tient plus de l'interprétation, mais « dont les spécifications techniques sont publiques et sans restriction d'accès ni de mise en œuvre »
pour moi ça signifie qu'on peut le modifier pour faire sa propre version/on est pas obligé de respecter à la lettre la specif.
D'ailleurs, la licence d'Adobe Flash est identique à celle de VP9 depuis un certain temps (la différence étant que dans un cas c'est du copyright, dans l'autre des patents). Le format est publiquement disponible, et tu as le droit d'implémenter ton propre player, à condition qu'il soit pixel perfect.
Le développeur n'est même pas libre d'avoir de bug.
[^] # Re: Moi pas comprendre
Posté par Ph Husson (site web personnel) . En réponse au journal Google est ton ami, Chrome son confident. Évalué à 2.
Si tu ne mets pas de clefs de chiffrement, alors les données sont "en clair" (chiffrées avec mot de passe du compte, whatever), donc Google peut y accedér.
Pour moi c'est une formulation purement technique, et ne veut pas dire que Google le fera.
Une formulation beaucoup moins "Google is the evil" est juste que s'ils se reçoivent un mandat de la police, alors ils pourront le lire, donc si tu veux te protéger de ça, mets une passephrase.
# Moi pas comprendre
Posté par Ph Husson (site web personnel) . En réponse au journal Google est ton ami, Chrome son confident. Évalué à 3.
Tu te plains que tu demandes à ton navigateur web d'enregistrer tes mots de passes dans le cloud, et t'es choqué de pouvoir relire les mots de passes en question ?
Ça perdrait de son intérêt s'il n'était pas capable de les relire…
Je vois pas vraiment comment sans mot de passe (ou du moins sans secret partagé entre les clients) un client peut chiffrer les données.
Ou alors on parle de chiffrements de communication entre le client et le serveur, ce que Google fait déjà?
# Aucune victime non-consentante.
Posté par Ph Husson (site web personnel) . En réponse au journal Combien de victimes avec M$ Machin 10?. Évalué à 5.
S'ils font ça, c'est pas par volonté de nuire, d'espionner ou quoique ce soit de vilain, c'est que ça existe déjà et ça marche.
Cf http://fortune.com/2015/05/22/a-chinese-app-that-steals-wifi-passwords-just-raised-50-million/ :
Il existe en Chine une application mobile de partage de mot de passes sur exactement le même principe, qui est utilisée par 270 Millions d'habitants. Genre, plus que le marché de Windows aux USAs.
Donc proposer l'option ne parait pas déraisonnable, vu qu'il doit répondre à un besoin de plus d'un quart des clients de Microsoft (bon euh client… utilisateurs du moins.)
D'autre part, cf http://arstechnica.com/gadgets/2015/07/wi-fi-sense-in-windows-10-yes-it-shares-your-passkeys-no-you-shouldnt-be-scared/
C'est un opt-in par réseau. On dit explicitement chacun des réseaux qu'on veut partager.
[^] # Re: les sources
Posté par Ph Husson (site web personnel) . En réponse au journal Combien de victimes avec M$ Machin 10?. Évalué à 4.
Euh…
Le lien que tu cites ne parles que des services en hotel/aéroport/centre de conférence, bref certainement pas les WiFi personnels, dont il est question ici.
Je pense que s'ils prévoient de partager les mots de passes WiFi à plus que juste les amis facebook, ça sera pour un service type Fon.
En plus, ces WiFi sont généralement trustés depuis plusieurs générations et pour encore plusieurs autres à venir, par nos gros opérateurs adorés.
Aucune information n'est donnée, mais pour moi c'est juste un partenariat avec les opérateurs WiFi de "centres d'intérêts", dont il est question ici.
[^] # Re: Snap 410
Posté par Ph Husson (site web personnel) . En réponse à la dépêche Sortie du noyau Linux 4.1. Évalué à 2.
Ouaip, mais globalement ça va en s'améliorant.
Tous les constructeurs de puces (même les chinois, Mediatek, Rockchip, Allwinner du moins) se mettent à pousser des morceaux dans Linux, et Qualcomm (le constructeur Android "historique") se met au vert, en avançant sur l'usage d'API standard (genre leur driver 3D utilise DRM maintenant, ils ont l'API standard de GPIO et clocks, ils utilisent les device-tree, …).
[^] # Re: Snap 410
Posté par Ph Husson (site web personnel) . En réponse à la dépêche Sortie du noyau Linux 4.1. Évalué à 4.
Ils tournaient avec des kernel fait par Qualcomm (kernel dispo sur leur page opensource, https://www.codeaurora.org), potentiellement légèrement modifié par le constructeur
Et ça va durer, même maintenant que Linux 4.1 est sorti, vu que les kernel Android ont toujours 3 ans de retard.
# Ma compréhension
Posté par Ph Husson (site web personnel) . En réponse au journal DevOps. Évalué à 10.
Je peux être à côté de la plaque, mais ma compréhension du terme est très différente.
Pour moi, DevOps désigne les administrateurs systèmes qui travaillent comme des développeurs:
Par exemple:
Une configuration est sous git, et faire le git push déploie automatiquement la configuration partout.
Une nouvelle machine à déployer prend quelques minutes au devops.
Il existe des branches master et des branches "stables", les branches master étant les systèmes "en dév"
Et ensuite, il y a des outils de tests continu d'intégration pour vérifier sur la branche master que rien n'est cassé
Il se trouve que les outils les plus couramment utilisés pour ce type de développement est docker, lxc, ou plus basiquement des scripts autour de debootstrap, et il est plus difficile de faire la même chose sur des systèmes propriétaires, donc il se trouve que la majorité des DevOps utilisent des outils libres, mais il n'y a pas de lien dur entre DevOps et libre.
[^] # Re: Petite remarque en passant.
Posté par Ph Husson (site web personnel) . En réponse au journal Ubuntu Touch sur BQ Aquarius - Revue de détail. Évalué à 4.
J'ai testé Sailfish OS (l'os de jolla) sur Nexus 5
Et pour le coup je trouve le store beaucoup trop petit, mais l'UI super bien léchée, et avec des bonnes idées.
Mais tu viens de me faire découvrir qu'il est compatible avec des applis Android, donc ça m'ouvre plein de possibilités, merci :)
[^] # Re: Music
Posté par Ph Husson (site web personnel) . En réponse au journal Récit d'un gros dégringolage anticipable. Évalué à 2.
Rajouter un mode d'économie d'énergie pour avoir plus d'autonomie, c'est pas dur, suffit de couper les data, le wifi, réduire la luminosité, etc.
Google a annoncé des optimisations batteries pour Android L et M, qui sont du même acabit:
- En dessous de 15%, t'as une notification qui te propose d'activer le mode économie (qui fait ce que j'ai dit au dessus)
- Sur Android M ils essaient d'être plus intelligents, et déterminent avec l’accéléromètre si le téléphone est utilisé, et ne réactiver les communications avec les serveurs que quand y a du mouvement.
Perso sur mon Nexus 5, c'est une catastrophe, mes mails ne sont plus synchronisés que deux fois par jour
[^] # Re: Centrale à inertie
Posté par Ph Husson (site web personnel) . En réponse au journal Sécurité et accéléromètres de téléphones. Évalué à 2.
Moui, alors effectivement, quand t'as une caméra à profondeur de champ, dans une tablette prévue pour faire du SLAM (Simultaneous Localisation and Mapping), encore heureux qu'ils arrivent à faire de la localisation -_-'
Mais sans caméra ils pourraient pas.
[^] # Re: Centrale à inertie
Posté par Ph Husson (site web personnel) . En réponse au journal Sécurité et accéléromètres de téléphones. Évalué à 2.
Même quelques minutes c'est assez optimiste…
[^] # Re: limiter
Posté par Ph Husson (site web personnel) . En réponse au journal Ce que Linux aurait du devenir ces 15 dernières années…. Évalué à 2.
Ma formulation est volontairement flou.
Je fais partie des gens qui considère que le NAT n'est jamais une solution de sécurité en soit, et effectivement ici non plus, le NAT n'apporte pas intrinsèquement de sécurité.
Juste, le NAT fait qu'il est plus facile de comprendre/faire des schémas de ce qu'il se passe, et le pare-feu se fait de la manière classique, à savoir selon l'adressage réseau.
Aussi, le filtrage par cgroups est moins testé, et a plus de chances d'avoir des failles. (typiquement je vois pas d'option à lxc pour rester dans le même namespace réseau, mais après c'est peut-être plus philosophique de leur part)
[^] # Re: limiter
Posté par Ph Husson (site web personnel) . En réponse au journal Ce que Linux aurait du devenir ces 15 dernières années…. Évalué à 3.
Pas beaucoup plus qu'un docker en fait…
C'était de l'ironie sur le fait que docker est un marteau piqueur pour cet usage.
[^] # Re: limiter
Posté par Ph Husson (site web personnel) . En réponse au journal Ce que Linux aurait du devenir ces 15 dernières années…. Évalué à 2.
Tant qu'à faire, tu mets une machine virtuelle qui limite limite au niveau de l'interface ethernet, encore plus simple ! Et c'est encore plus secure !
docker n'est qu'un ensemble de scripts autour de "vraies" technos (comme les namespaces), évidement que si c'est faisable avec docker, c'est faisable sans trop de complexité avec autre chose.
En l’occurrence, pas besoin de namespace network (qui serait un bordel sans nom à gérer avec du NAT au milieu, mais qui est pas forcement une mauvaise option si on veut un système sécurisé), on peut utiliser iptables pour marker des paquet en fonction du pid, de l'uid et/ou du cgroup, et après cette mark peut être utilisée par le shaper.
En plus simpliste, iptables intègre des rate limiters (mais c'est en nombre de paquets par seconde).
La seule vraie question est de séparer les process par cgroups, heureusement systemd est là ! (pas taper.)
[^] # Re: rien a voir avec la compression
Posté par Ph Husson (site web personnel) . En réponse au journal Algo de compression JPEG waifu2x . Évalué à 2.
Un peu quand même.
La plupart des algos de compressions d'image consiste à prendre une version basse résolution, à l'agrandir, et à corriger les erreurs.
Moins d'erreurs à corriger, ça fait un fichier plus petit.
[^] # Re: Quel est le problème avec une combinaison de l'existant ?
Posté par Ph Husson (site web personnel) . En réponse au journal Existe-t-il un bon algorithme qui permet de compresser et de chiffrer en meme temps. Évalué à 4.
Certes. Après, le monsieur en haut demandé un algo prouvé qui fasse compression ET chiffrement, et je pensais qu'il voulait ça pour pouvoir augmenter la sécurité du système, en fait vu les autres messages, c'est plus une question de vitesse.
Effectivement la seule attaque connue/vaguement exploitable est en attaque à clair choisi, et potentiellement l'auteur n'est pas dans ce cas. On parle typiquement de GPG plus bas, sauf si c'est script, il n'y a pas d'attaque à clair choisi possible.