patrick_g a écrit 6388 commentaires

Je pense que cette partie fait référence au fait que le kernel 3.2 a été choisi pour faire de la maintenance sur le long terme

C'est Greg KH qui choisit les noyaux qu'il va maintenir en mode LTS. Actuellement seuls les noyaux 3.4.x et 3.10.x font l'objet de ce maintien LTS officiel.
Après il y a d'autres développeurs qui décident de maintenir des noyaux en fonction de leurs besoins propres. On a par exemple Jiri Slaby qui maintient le 3.12.x et Ben Hutchings qui maintient le 3.2.x. Ils font ce travail dans git.kernel.org et c'est pour ça que ces noyaux sont listés sur la page de kernel.org mais ça ne signifie rien de plus.
Ubuntu a annoncé qu'ils prenaient en charge la maintenance à long terme du noyau 3.13.x mais ils font ce maintien sur git://kernel.ubuntu.com/ubuntu/linux.git au lieu de le faire sur kernel.org.
C'est la seule différence et le mainteneur ne doit pas plus "aller à la pêche" des patchs que Jiry ou Ben. Il leur suffit d'être abonné à la liste de diffusion stable pour voir passer les patchs et décider si ça s'applique au noyau qu'ils maintiennent.

Je ne connais pas les personnes responsables du maintient des patchs noyau pour Ubuntu, mais je doute de leur capacité à réaliser ce fastidieux travail alors qu'aucune autre distribution ne le fera pour ce noyau.

Pur procès d'intention. Pourquoi est-ce que tu doutes ? Tu as des raisons objectives ou bien est-ce juste du FUD ?
En quoi est-ce différent de la situation de Debian Wheezy ? C'est bien Ben Hutchings qui maintient le noyau 3.2 dans ce cas, alors pourquoi reprocher par avance à Ubuntu de maintenir le 3.13 ?

Le premier problème ici est lié au support d'Upstart

Là encore il n'y a aucun argument factuel qui expliquerait que ce choix est mauvais. Il est évident qu'Ubuntu ne pouvait pas faire la transition vers systemd en quelques semaines, après la décision Mark Shuttleworth de suivre Debian et de basculer vers systemd.
Donc il n'y avait pas d'alternative à Upstart. Et cela ne pose pas de problèmes ! La seule critique que tu exprimes c'est que ce "sera donc supporté uniquement par les développeurs d'Ubuntu". Encore une fois ou est le problème ?

MySQL

Ce choix résulte sans doute d'un partenariat avec Oracle, tant mieux si ça fait rentrer de l'argent dans les caisses de Canonical. Et puis de toute façon MariaDB est dans Universe.

Pollinate : Premier problème évident : il faut faire confiance à cet ensemble de serveurs

C'est faux puisque, comme l'explique Dustin Kirkland dans sa présentation, on peut parfaitement changer la liste des serveurs. Cela se paramètre dans /etc/default/pollinate donc il n'est nullement nécessaire de faire confiance aux serveurs de Canonical.

Pollinate : La première session TLS sera créée avec très peu d'entropie disponible

Là encore il faut lire ce qu'écris Dustin Kirkland dans sa présentation : We are mitigating that (risk) by bundling the public certificates in the client. The pollinate package ships the public certificate of entropy.ubuntu.com.
Et là encore il est toujours possible d'ajouter des serveurs dans /etc/default/pollinate. Pourquoi pas un serveur local qui distribuerait la graine aux machines virtuelles ?
Et ne pas oublier que tout ça va s'ajouter dans l'entropy pool du noyau. Cela ne peux pas faire de mal (c'est comme RDRAND, on ne l'utilise pas exclusivement, on l'ajoute à tout le reste).

Compiz & Mir : Unity est le seul environnement de bureau qui utilise encore Compiz et les développeurs d'Ubuntu sont les seuls à le maintenir.

Toujours le même argument ! Mais en quoi est-ce un problème ? Les autres distros aussi utilisent des trucs spécifiques qu'ils sont les seuls à supporter. Sur LWN cette semaine on parlait de firewalld pour Fedora. Est-ce que tu vas beugler en disant que firewalld n'est supporté que par les devs de Fedora et qu'en conséquence on ne peut pas utiliser cette distribution ?

Bien que Mir ne soit pas le serveur d'affichage par défaut dans Ubuntu 14.04

Donc cela ne peut pas servir d'argument pour ne pas utiliser Ubuntu. Donc le citer est du pur FUD.
Je suis le premier à regretter la création de Mir. J'ai même écris un journal à ce sujet. Mais citer ce point alors que la 14.04 n'utilise pas Mir c'est un peu fort de café.

En résumé ton texte me semble être en grande partie du FUD non supporté par les faits.
Et puis conseiller Fedora 20 comme serveur…heu comment te dire…

Coquilles corrigées. Merci.

• Explications sur REE
• Explications sur LRA

La nouvelle fonction dans GCC est mieux. Voir l'exemple mis en valeur dans les notes de version et aussi la doc.

Faute corrigée.
Merci pour le lien.

En attendant, je préfère la mentalité OpenSSL, plus ouverte sur les gens.

Elle est surtout très ouverte sur les exploits…

LGPL pour GnuTLS non ?

Et ils n'avaient pas vu tout ce "merdier" (je reprends leurs mots) lors du précédent audit entrepris suite aux révélations d'une porte dérobée dans un des algorithmes de chiffrement?

A quoi est-ce que tu fais allusion exactement ? Si c'est l'affaire Gregory Perry alors il s'agissait d'accusations au sujet d'une backdoor dans la pile IPSec.
Rien à voir avec OpenSSL donc.

on est pas encore arrivé dans une phase de stabilisation et d'ailleurs les développeurs ne s'en cachent pas.

Je trouve que c'est complètement hallucinant de dire ça.
- Afin de bénéficier d'une maturité et d'un polissage suffisant, la sortie de Gnome 3.0 a été repoussé deux fois de suite (12 mois donc) par les devs du projet.
- Gnome 3.0 est finalement sorti il y a trois ans, en avril 2011.
- Gnome 3.12 est la septième version stable de Gnome 3.x.

Et, après tout ça, on ne serait même pas encore arrivé dans une phase de stabilisation et d'ailleurs les développeurs ne s'en cachent pas ??????????
Si c'est vraiment ce qu'ils pensent alors c'est à pleurer.

Bah ça pourrait être les noces de son frère ou sa soeur et il serait là en qualité de témoin.

Tes noces à toi ?

Nan, je suis juste déçu de plus pouvoir installer Gnome chez les gens normaux, je suis pas hyper fan de Unity et je ne regarde aujourd'hui plus que du coté de elementaryos pour une environnement simple…

Xubuntu est ton ami.
La distro la plus répandue et qui a un très bon support du matos + un bureau traditionnel et qui ne change pas tout d'une version à l'autre.
C'est parfait pour les gens normaux.

Photos ne gère que les photos dans le cloud

Sérieusement ?
Je croyais que Photos c'était un remplaçant pour Eye of Gnome…donc ça devrait gérer les photos en local quand même non ?

Tu peux aussi penser que le biais s'exerce en sens inverse. Les firmes qui ont la volonté de proposer des logiciels propriétaires de bonne qualité vont soumettre leur code à Coverity.
Les firmes qui se foutent de la qualité et dont le code propriétaire est dégueulasse ne vont même pas envisager d'utiliser Coverity.

Donc peut-être que la qualité moyenne du code proprio est encore bien pire que ce qu'on voit dans ce rapport.

Exim est le MTA par défaut de Debian. Je pense qu'il y a un certain nombre de serveurs Debian sur cette planète tu ne crois pas ?
CUPS est le système d'impression utilisé par tous les Unix et par Mac OSX. Il me semble que là aussi ça fait un sacré paquet de monde…

GnuTLS est utilise par tres peu de gros softs

D'après l'article Wikipedia il y a au moins GNOME, Exim, Mutt, wireshark et CUPS. Loin d'être négligeable donc.
Et si je regarde les dépendances inverses du paquet libgnutls26 sur ma Xubuntu j'ai ça :

patrick@laptop:~$ apt-cache rdepends libgnutls26
libgnutls26
Reverse Depends:
  libvirt0
  libvirt-bin
  libgnutls26:i386
  libgnutls26:i386
  xen-utils-4.3
  mutt-patched
  libavformat-extra-53
  chromium-browser
  qemu-system-x86
  qemu-system-sparc
  qemu-system-ppc
  qemu-system-misc
  qemu-system-mips
  qemu-system-arm
  mutt
  libvirt0
  libvirt-bin
  libgnutlsxx27
  libgnutls26-dbg
  libgnutls-openssl27
  libgnutls-dev
  libgadu3
  libcurl3-gnutls
  libcups2
  libavformat53
  gnutls-bin
  glib-networking
  empathy
  cups-daemon
  libgnutls26:i386
  libgnutls26:i386
  libgcrypt11:i386
  xxxterm
  xfce4-mailwatch-plugin
  xen-utils-4.3
  wzdftpd
  wmbiff
  wine1.4-amd64
  weechat-plugins
  weechat-curses
  weechat-core
  webfs
  vpnc
  vlc-nox
  sogo
  shishi-kdc
  scrollz
  rsyslog-gnutls
  qutim
  python-gnutls
  proxytunnel
  prelude-manager
  postal
  plasma-widget-mail
  pianobar
  pacemaker-remote
  pacemaker-mgmt-client
  pacemaker-mgmt
  openconnect
  nzbget
  nullmailer
  ngircd
  newsbeuter
  mutt-patched
  msmtp-gnome
  msmtp
  mpop-gnome
  mpop
  minbif
  mandos-client
  libyaz4
  libxmlsec1-gnutls
  libwireshark3
  libvmime0
  libucommon5
  libsope1
  libshishi0
  libpiano0
  libpam-pin
  libopenvasnasl2-dev
  libopenvasnasl2
  libopenvas2
  libopenconnect2
  libnussl1
  libnet6-1.3-0
  libmicrohttpd10
  libmailutils4
  libloudmouth1-0
  libinfinity-0.5-0
  libinfgtk3-0.5-0
  libiksemel3
  libgwenhywfar60
  libgnustep-base1.24
  libgloox8
  libggz2
  libgensec0
  libevd-0.1-0
  libetpan15
  libepc-1.0-3
  libeet1
  libecore-con1
  libavformat-extra-53
  libapache2-mod-gnutls
  kildclient
  kbtin
  jd
  ircd-ratbox
  inspircd
  infinoted
  gurlchecker
  gtk-gnutella
  gstreamer1.0-plugins-bad
  gsasl
  gnu-smalltalk
  gnomint
  gkrellm
  git-annex
  freetds-bin
  filezilla
  emacs24-lucid
  elinks-lite
  elinks
  ekg2-remote
  ekg2-jabber
  echoping
  dwb
  csync2
  connman
  claws-mail
  chromium-chromedriver
  chromium-browser
  centerim-utf8
  centerim-fribidi
  centerim
  bitlbee-libpurple
  bitlbee
  aria2
  anubis
  aiccu
  abiword
  vino
  telepathy-salut
  telepathy-gabble
  tdsodbc
  qemu-system-x86
  qemu-system-sparc
  qemu-system-ppc
  qemu-system-misc
  qemu-system-mips
  qemu-system-arm
  pacemaker
  ntfs-3g
  mutt
  lynx-cur
  libvncserver0
  libvirt0
  libvirt-bin
  libsybdb5
  librtmp0
  librelp0
  libprelude2
  libneon27-gnutls
  liblrmd1
  libldap-2.4-2
  libimobiledevice4
  libgvnc-1.0-0
  libgnutlsxx27
  libgnutls26-dbg
  libgnutls-openssl27
  libgnutls-dev
  libgnomevfs2-0
  libgcrypt11
  libgadu3
  libcurl3-gnutls
  libcups2
  libct4
  libcrmcommon3
  libcib3
  libavformat53
  lftp
  gnutls-bin
  glib-networking
  exim4-daemon-light
  exim4-daemon-heavy
  empathy
  emacs24-nox
  emacs24
  cups-daemon

GnuTLS ?
Pas sur que ce soit mieux qu'OpenSSL…

Ben si. Des bugs il y en a dans tous les logiciels, même les mieux écrits et les plus scrutés (par exemple OpenSSH).
Le problème spécifique d'OpenSSL c'est que d'après les spécialiste qui ont regardé son code source c'est une horreur sans nom, une abomination absolue (cf les divers articles à ce sujet).
Donc même si GnuTLS a déjà eu des bugs (et, encore une fois, quel logiciel n'en a pas ?), ce serait quand même un immense progrès que de jeter OpenSSL et de le remplacer par GnuTLS. D'autant plus que la LGPL est assez permissive.

C'est quand même dommage de devoir réécrire tout OpenSSL quand on peut utiliser GnuTLS non ?

Je croyais que la politique de Linux était de refuser les patchs introduisant des régressions?
Hop encore un mythe qui s'en va

Évidement que c'est désactivé par défaut.

+config RANDOMIZE_BASE
+ bool "Randomize the address of the kernel image"
+ depends on RELOCATABLE
+ depends on !HIBERNATION
+ default n

Faux, je peux le prouver : je ne lui reproche rien du tout et le remercie de faire ce qu'il fait, ce qui rend par définition de "tout le monde" ta phrase fausse.

Tu fais exprès de jouer au boulet ?
Par "tout le monde" j'entends "les gens impliqués dans le développement de Linux". Et toi tu fais semblant de prendre ça au pied de la lettre comme si j'incluais également le paysan du fin fond de la Mongolie.
Oui je te confirme que ce paysan ne reproche absolument rien à Spender.

Mais bon j'arrête là parce que tu as un talent particulier pour toujours avoir le dernier mot, quel que soit le sujet.

L'idée c'est de boucher progressivement les infos leak afin que la défense KASLR devienne plus efficace (sachant que ça restera une défense statistique et pas absolue).

Je ne pense pas que quiconque rejette les arguments de Spender sur le fond, c'est juste que, pour Kees Cook, le jeu en vaut la chandelle puisque ça ajoute un peu de protection sans enlever grand chose; Et puis, selon l'article LWN, le système sera amélioré par la suite (retour de l'hibernation, augmentation du nombre de slots au delà de 512, etc).

tu viens de dire que tu aimes la politique de Microsoft en termes de sécurité

Et après tu t'étonnes qu'on te tape dessus parce que tu racontes n'importe quoi.
En quoi la politique de sécurité de Microsoft (à l'époque, parce qu'ils ont changé depuis) était comparable à l'actuelle politique suivie par les mainteneurs Linux ? Autrefois Microsoft se foutait royalement de la sécurité et seul le "time to market" comptait. Depuis ils ont bien appris leur leçon et ils ont maintenant une politique assez efficace.
Donc évoquer Microsoft comme tu le fais n'a aucun sens à part le plaisir d'agiter un chiffon rouge pour faire dérailler la conversation.

Et cela n'a absolument rien à voir avec la nécessité de faire des compromis entre plusieurs buts contradictoires.
C'est sûr que c'est confortable pour Spender de cracher sur les devs Linux quand on se branle royalement des perfs du noyau patché Grsecurity/PaX.
Regarde donc le journal que j'avais écris à l'époque sur ces perfs : https://linuxfr.org/users/patrick_g/journaux/les-performances-d-un-noyau-avec-le-patch-pax
Les résultats des micro-benchmarks sont absolument catastrophiques !

Un peu facile de taper sur une personne qui a le malheur de ne pas rentrer dans le moule "gentil qui fait tout comme les mainteneurs upstream et/ou certains utilisateurs attendent".

Tu crois que je suis le seul à lui taper dessus ? Tout le monde lui reproche son attitude infecte, son arrogance inouïe ,sa propension à se faire mousser en permanence et son incapacité absolue à travailler avec les autres.
Bien entendu il est très compétent, et là personne ne remet ça en cause…mais des gens compétents il y en a d'autres (par exemple Kees Cook, l'auteur de KASLR). Pour bosser sur le noyau il ne suffit pas d'être compétent, il faut collaborer avec les autres puisque c'est un projet collectif et il faut accepter les compromis puisque c'est un noyau généraliste.

Sauf que tu as 511 chances sur 512 de faire planter le noyau quand tu tentes d'en prendre le contrôle. Et un plantage noyau ça a tendance à se remarquer un peu plus qu'un plantage de process en userspace.
Et tout ça c'est sans évoquer les autres bénéfices du patch (protection de la table IDT par exemple).

Je pense que kASLR n'est pas une bonne idée. Les raisons sont simples et elles sont détaillés dans l'article sur le blog/forum de grsecurity

Sauf que Spender est un maximaliste qui ne pense qu'à la sécurité et se fiche de tout le reste (perfs, portabilité, etc). Les mainteneurs du noyau eux doivent faire des choix et des compromis.
Dans l'article LWN dédié on comprend bien que KASLR n'est pas une solution miracle mais que ça apporte quand même des bénéfices non nuls en terme de sécurité et sans aucune dégradation des perfs.

C'est la bataille des mots

Un lien fort utile : http://politiquedunetz.sploing.be/2013/07/les-mots-ont-un-sens-parler-de-monopole-du-droit-dauteur-pour-sauvegarder-nos-libertes/