reno a écrit 3879 commentaires

et on se dit que les ventes d'iPhone vont baisser aussi

Ah? Pourtant le futur iPhone grand écran devrait être un carton.

Les smartphones stagnent: plus de nouvelle super-fonctionnalité, juste du peaufinage, mais le peaufinage ça peut être super important: il y a plein de points soit rare (étanchéité, batterie amovible) soit carrément inexistant (anti choc, inrayable(*), écran bien lisible en plein soleil) qui amélioreraient beaucoup la vie des utilisateurs..

Ça c'est le coté matériel, mais coté logiciel la fluidité d'Android, l'ergonomie des téléphones/tablettes c'est loin d'être ça encore (exemples: comment on fait pour remonter en haut d'écran avec Chrome? pour avoir un clavier décent sur iPad il faut attendre iOS8..).

Après le peu d'appareil avec double SIM, microSD et batterie amovible montre bien que les fabriquant d'appareil pensent d'abord à eux et aux opérateurs téléphoniques, les besoins du clients passent ensuite seulement.

*: à voir les futurs écrans d'Apple en saphirs..

Là il y a en plus, "quasiment tout" généré, mais oui ça n'est pas nouveau.
Mon plus gros problème c'est que tout cette recherche va dans le vide, ou sont les sources?

Et bien d'après leur rapport, ils sont plutôt content de ce qu'ils ont obtenu.
Après je ne crois pas qu'il y ait un accès aux sources donc..

Pour seL4, ça fait 5 ans que c'est sorti et ils marquent toujours que le support du multicœur comme 'expérimental'.. Même mon téléphone est multicœur, donc je maintiens: seL4 est un jouet (à l'heure actuelle).

Pour le reste, c'est probablement une question de temps..

Bricoleurs? Quand tu vois la difficulté de prouver même des petits programmes..
seL4 est l'exception pas la règle et quand tu lis leur FAQ sur le multicoeur..
Par contre pour l'utilisation du C plutôt qu Ada (par exemple) là je suis d'accord.

la refactorisation du mamouth LibreOffice..

D'un autre coté, il y a le projet STEPS d'Alan Kay qui repart du début et prétend avoir un traitement de texte puissant en très peu de ligne.. Dommage que STEPS ce soit uniquement de la recherche et que ça a l'air moribond (dernier rapport officiel en 2011), les 2 approches sont intéressantes..

Y a qu'a demander.. Voici le lien: https://news.ycombinator.com/item?id=8104407

Oui enfin quand tu lis leur FAQ sur le support expérimental du multi-coeur par seL4, ça calme plutôt à l'heure actuelle, non?

Capsicum reste, malgré tout cela, un gain mesurable en sécurité puisque ça permet de faire passer la surface d'attaque de "absolument titanesque" [coupé] à juste "complètement énorme" (le noyau Linux).

La fin pourrait être "affinée": à une partie du noyau Linux puisque tu peux restreindre les appels systèmes autorisés.

Pas la peine d'aller chercher à l'étranger: le rainbow warrior, les écoutes personnelles de Mitterand (on pourrait trouver plein d'autre exemples) ça me parait difficilement légal, non?

Et pourtant les suites judiciaire ont été ridicules..

Je ne mettrais pas LXC/Docker et Capsicum dans la même catégorie..
Pour LXC/Docker effectivement pouvoir attaquer tout le noyau ça fait beaucoup.

Pour Capsicum, je ne sais pas si je suis d'accord, certes ça dépend beaucoup de l'application et de la façon dont elle conçue, mais en général tu restreins beaucoup ce qu'il est permis de faire ce qui complique quand même énormément la vie d'attaquant.

Ce qui est sympa avec Capsicum, c'est que les gens d'OpenSSH et de Chrome s'y intéressent et rien qu'avec ces 2 applications "capsicumisées", cela devrait apporter un réel gain en sécurité..

Mais ça pose de redoutables problèmes d'ergonomie et d'interfaces

L'approche de qube-os ne me parait pas si mal que ça: par exemple, tu mets une VM différente pour des contextes différents: une pour ton boulot, une pour tes activités perso, une pour les enfants et une autre pour les activités risquées: installation d'une appli dont tu ne sais pas trop si elle inclut un adware ou pas, etc.

Les contextes étant différent le besoin de communication entre les VMs est réduit..

Après comme le dit Michel Barret, la virtualisation ça consomme énormément de RAM et de disque, ce qui est un sacré inconvénient..

Heartbleed et beaucoup, beaucoup d'autre failles.. Le C ou le C++ d'un point de vue sécurité..

Linus avait jeté le bébé avec l'eau du bain en disant qu'il y avait suffisamment de modules de sécurité et qu'il ne voulait pas en intégrer un nouveau.

Oui enfin Linus, par défaut il dit non et puis après il discute..
Vu le nombre de fonctionnalités qu'on doit lui demander d'introduire dans Linux, ça me parait d'ailleurs une stratégie tout à fait raisonnable!

Question de quelqu'un qui ne connaît rien au kernel : ne serait-il pas possible d'implémenter Capsicum sous forme d'un LSM

Alors
1) les LSM ne sont pas 'stackable'/additionnable donc si tu implémente Capsicum sous forme d'un LSM alors tu aurais l'alternative d'utiliser Capsicum XOU SELinux XOU …

2) Capsicum c'est pour les devs qui veulent rendre leur logiciel plus robuste, c'est donc assez différent des politiques de sécurité qui sont plus pour les admins.

Donc si Capsicum n'est pas présent en standard, il y a peu de chance que les devs vont faire l'effort de modifier leur code pour en tenir compte.

Je ne vois pas pourquoi tu réponds sur ma suggestion de "contraignante", "héréditaire" comme évoqué plus haut me parait bien mieux..

Lu sur Internet: la WTFPL est déconseillé par un avocat aux USA.

Suite à ces révélations, comment se fait-il qu'on autorise encore les google cars en France, ou que le cloud CNRS soit géré par Microsoft ??

Je ne vois pas le rapport entre les 2..
Pour Microsoft OK c'est aberrant, pour les voitures Google que font-elle d'illégal?

La cryptographie fonctionne !

Mort de rire.. Tu ose écrire ça après toute une série de vulnérabilité dans les implémentations??

Pour ce qui est de prendre en compte sérieusement la sécurité, quand est-ce qu'on porte tout du C/C++ vers ATS ou Ada (ou Rust quand il sera mur)?

Plutot d'accord, mais c'est quand meme ce que le titre du journal implique/sous-entends..

Ouh, la mon poste était là pour rappeler que libre n'implique pas sécurisé.

Et non avoir Capsicum dans FreeBSD n'est pas suffisant pour être plus sécurisé car il faut ensuite le support des applications (ce qu'ils ont commencé à faire).
Les dev de Capsicum ont commencé a travailler sur le support Linux, mais bon d'ici à ce que cela soit intégré, ça peut être long..

En ce qui concerne openSSL, ce n'est pas parce que tout le monde a mis la tête dans le sable pendant des années que tu dois généraliser.

C'est vrai, il y a plein d'autres raisons pour généraliser!
En vrac:

• la conception d'X ou chaques applications peut "sniffer" tout ce qui se passe.

• X lui même qui tourne root dans beaucoup de cas.

• ceux qui s'intéresse fortement à la sécurité critiquent régulièrement la gestion de la sécurité dans Linux..

D'ailleurs les dev de Capsicum (un des projets que je trouve le + intéressant pour la sécurité) ont commencé par bosser sur FreeBSD pas par Linux.

[JDN] Comment se repérer dans la jungle des licences open source

Même pas mention de LGPL, Boost.

Description de la GPL comme 'contaminante', une contamination c'est INVOLONTAIRE, l'utilisation (ou pas) de code GPL c'est toujours volontaire, donc 'contraignante' est beaucoup plus juste.

Note qu'il y a eu une reprise des ventes de PC à peu près au moment ou XP n'a plus eu de MAJ de sécurité (13 ans d'age quand même) donc effectivement ne pas changer est courant (et parfaitement raisonnable si tu as du support).

Et avoir des évolutions à apporter sur une application quand on change d'OS, ce n'est pas de la merde, juste de la logique…

Ça, ça dépend de la philosophie de ceux qui font l'OS..
Avec Microsoft, la compatibilité des nouvelles version de Windows avec l'existant est traité de manière assez sérieuse (enfin c'est TRÈS loin d'être parfait mais ils essayent), dans le monde des OS a base de Linux (mis à part pour Linux lui-même ironiquement) la compatibilité est très aléatoire..

Donc non ce n'est pas de la "logique".

Et je pense que les applications qui utilisent le GPU sont principalement les jeux, qui sont souvent en plein écran et dans ce cas là le desktop ne devrait plus jouer.
Après pour les jeux en fenetres..

Je crois qu'il y a des algorithmes plus intelligent que mémoriser les serveurs pour tout les clients, par exemple commencer par faire un algorithme qui fait un hash des informations du client et qui s'il tombe sur un serveur indisponible (planté ou plein) va appliquer une deuxième étape.

Il y a aussi le problème lié a l'augmentation du nombre de serveur a gérer si possible de manière transparente.