eingousef a écrit 1582 commentaires

Cas de figure 1 :

Entreprise Machin sort le nouveau format VP11 de vidéo pour le web. En 3 mois elle est incluse dans les nouvelles versions des principaux brouteurs et encodeurs. Au bout d'un an les 3/4 des vidéos sur le web sont en VP11. Et encore 1 an après la nouvelle Debian sort, et les utilisateurs de stable sur le desktop peuvent profiter des vidéos du web en VP11. Pas de pot, on est déjà passés à VP12.

Cas de figure 2 :

Des utilisateurs communiquent sur une ML qui rajoute un titre en début de sujet (par exemple: [Râleurs] ) si celui-ci n'existe pas déjà. Kévin envoie un e-mail en mettant pour sujet sainul sa marchent pa xD, toute la ML recevra un e-mail ayant pour sujet [Râleurs] sainul sa marchent pa xD encodé en UTF-8. Un utilisateur avec un client à jour répond, le sujet de la réponse est Re: [Râleurs] sainul sa marchent pa xD. Un utilisateur en Debian stable avec un vieux icedove qui ne gère pas les changements d'encoding dans les sujets répond, le sujet devient Re: [R�leurs] Re: [Râleurs] sainul sa marchent pa xD. Au bout de 5 échanges de réponses ça devient :

Re: [R�leurs] Re: [Râleurs] Re: [R�leurs] Re: [Râleurs] Re: [R�leurs] Re: [Râleurs] sainul sa marchent pa xD

Dans l'affichage des threads d'un client mail c'est juste illisible. Déjà que le mail de Kévin à la base était tout pourri >:(

Cas de figure 3 :

Le nouveau jeu Battle For Bidule sort une nouvelle version stable. Un utilisateur de Debian stable veut jouer avec une bande de copains. Situation :

— On joue à Bidule, version X.Y.
— Ah mais j'ai pas la X.Y, elle est pas dans les dépôts.
— Ben utilise les backports.
— Elle est pas dans les backports
— Ben fais de l'apt-pinning alors
— Ok j'installe le paquet de testing. Ah zut il me demande de mettre à jour 250 paquets dont la libc.
— Ouch attends un peu tu risques de tout péter.
— T'inquiète, ça risque r
*user disconnected*

Pour résumer, le problème auxquels sont confrontés les utilisateurs de stable c'est qu'aujourd'hui les standards évoluent plus vite que ne sortent les nouvelles versions de Debian. Pour une utilisation sur serveur, ce n'est généralement pas un problème, parce que quand on fait évoluer les protocoles implémentés sur les serveurs, c'est généralement par petites incrémentations en faisant gaffe à casser le moins souvent la compatibilité avec les versions précédentes. Et ces petites incrémentations sont généralement bien gérées par les mainteneurs des backports Debian. Pour une utilisation sur Desktop, c'est plus problématique, parce que les standards implémentés sur les clients évoluent beaucoup plus vite (en peu de temps tu peux avoir un nouveau codec vidéo pour le web qui se déploie, un nouveau codec audio pour la VoIP, un nouveau champ dans les header des e-mails, une nouvelle version d'un jeu multijoueur), ils évoluent de façon plus massive (pour les jeux d'une version à une autre t'auras des changements de gameplay, ça va forcément casser), et les backports debian ne peuvent pas suffire.

Donc mon conseil: n'utilisez pas stable sur votre desktop, sauf si vous n'allez jamais sur internet / n'interagissez jamais avec personne. Sinon, utilisez plutôt testing ou unstable. Personnellement à part quelques programmes que j'ai pas réussi à compiler parce qu'ils étaient écrits par des jeunots hyperactifs qui ont décidé que le C++11 c'était HaZBine et qu'ils étaient incapables de coder un hello world sans utiliser C++17, j'ai jamais eu de problèmes avec testing.

*splash!*

Pas bête ! Il y avait aussi "la version qui n'existera jamais", "la version auto-générée par une intelligence artificielle (fireplop<)" et "la version qui existera mais qui ne sera jamais publiée pour whatever raison à la con". La partie continue !

*splash!*

La version téléchargeable de Firefox

Parce qu'il y a une version "non-téléchargeable" ?

*splash!*

C’est juste que je préfère. Parce que ça me passionne, m’intéresse et me fait plaisir.

Ben te plains pas alors

*splash!*

Comment ça se passe pour rapporter les bugs ? Dans Debian il y a un outil reportbug qui envoie les rapports de bug au mainteneur, qui corrige le bug ou renvoie le rapport à l'upstream suivant les cas.

Dans Devuan, si on rencontre un bug lié à un "remplacement" de systemd (sysvinit, runit, vdev/eudev, etc.) c'est assez évident qu'on doit faire un rapport de bug directement à Devuan, mais si on rencontre un bug sur un paquet qui est en commun avec Debian, à qui doit-on envoyer le rapport ?

Et aussi, est-ce que l'outil reportbug a été modifié dans Devuan pour prendre cela en compte ?

*splash!*

Va vite leur dire qu'ils se trompent ! Tu as peut-être encore la possibilité de les sauver !

PS: n'oublie pas de les menacer de passer à windows ! Je suis sûr que ça fera son petit effet.

*splash!*

la vis.

*splash!*

J'ai trouvé, voir plus bas : https://linuxfr.org/users/gouttegd/journaux/de-la-distribution-des-clefs-openpgp#comment-1702481

*splash!*

aaaaaaah punaise ça y est j'ai trouvé ! C'est parce que j'avais juste le port UDP 53 d'ouvert en ipv4 et pas le port TCP 53 ! Si je bloque le port TCP 53 ET le port UDP 53 ça marche, mais si je bloque juste le port TCP 53 en laissant UDP 53 ouvert ça ne marche plus !

*splash!*

mais quand je fais un gpg --refresh-keys (avec TCP 53 bloqué en ipv4) dans mon netstat -tunlap j'ai une ligne du style :

tcp        0      1 XXX.XXX.XXX.XXX:33385      217.70.184.225:53       SYN_SENT    14935/gpgkeys_hkp

*splash!*

Oui.

*splash!*

nameserver 2001:4b98:dc0:49::225
nameserver 217.70.184.225
nameserver 217.70.184.226

(c'est une machine gandi)

*splash!*

Sur une machine sous debian stable, avec firewall qui a sur une policy DROP sur ipv4 en INPUT et OUTPUT. Impossible de se connecter à un serveur de clés (y compris en utilisant ipv6.pool.sks-keyservers.net) tant que je n'ai pas ouvert le traffic sur ipv4 en OUTPUT sur le port TCP 53. C'est normal ?

*splash!*

attention tu as utilisé des derrièreapostrophes

*splash!*

en publiques

O_o

*splash!*

Effectivement !

 Êtes-vous certain(e) de vouloir installer/mettre à jour les paquets ci-dessus ? [Y/n/?/...] ?
     y     - continuer l'installation avec APT, mais sans marquer les bogues                 
             comme étant ignorés.                                                            
     a     - continuer l'installation avec APT en marquant                                   
             tous les bogues ci-dessus comme étant ignorés.                                  
     n     - interrompre l'installation avec APT.                                            
   <num>   - demander le rapport de bogue spécifié (nécessite reportbug).                    
  #<num>   - identique à <num>.                                                              
   b<id>   - comme <num>, mais interrogeant le bogue identifié par <id>.                     
     r     - afficher les listes de bogues.                                                  
 p <pqt..> - figer les paquets (APT doit être relancé pour activer                           
             cette option).                                                                  
 p         - figer tous les paquets ci-dessus (APT doit être relancé pour                    
             activer cette option).                                                          
 i <num>   - marquer comme étant ignoré le bogue numéro <num>.                               
 i b<id>   - marquer comme étant ignoré le bogue identifié par <id>.                         
     ?     - afficher cette aide.                                                            
     w     - afficher les listes de bogues en HTML (cette option                             
             utilise sensible-browser).                                                      

*splash!*

Ah ? De mémoire elle ne me proposait que [Y/n/?]

*splash!*

Comme tous la série de journaux de gouttegd sur OpenPGP en fait.

*splash!*

1) Est-ce que ça existe un logiciel qui, plutôt que d'aller chercher une clé sur un seul serveur HKP, va la chercher sur plusieurs et compare les réponses obtenues des différents serveurs ?

Certes ça ne serait pas utile au cas où un attaquant ferait du MITM juste derrière la connexion du client, mais si il s'agit d'un attaquant qui peut corrompre les réponses d'un seul serveur au lieu de plusieurs, ça pourrait être utile.

2) Tu dis :

Si vous choisissez d’utiliser un serveur HKPS dont le certificat n’est pas signé par une autorité de certification reconnue du système d’exploitation, vous devrez ajouter l’option hkp-cacert qui pointera vers un fichier contenant le(s) certificat(s) racine(s) au format PEM. Notez que ce n’est pas nécessaire pour le pool hkps.pool.sks-keyservers.net, dont le certificat racine est connu de GnuPG.

Mais est-ce qu'il ne vaut pas mieux le faire quand même ? Si gnupg va chercher dans les certificats installés sur le système, n'importe quelle CA installée peut produire un faux certificat qui sera utilisé par gnupg, alors que si on spécifie la CA du pool à la main, on sait que ce sera cette CA qui sera utilisée pour ce pool et jamais une autre.

*splash!*

et puis :

Par exemple, pour rafraîchir toutes les clefs associées à des adresses en @fsf.org et @slackware.com :

$ gpg2 --refresh-keys @fsf.org@example.com

*splash!*

Certes, tous les 2 ans le freeze fera que pendant 6 mois il n'y aura plus de mises à jour… mais rien n'empêche de mettre ponctuellement un paquet à jour depuis sid ou experimental !

Ça en ce qui me concerne ça dépend des paquets. J'ai aucun problème à prendre un paquet "utilisateur final" dans unstable ou experimental, comme mutt, isync, iceweasel, kakoune, et la plupart des jeux, autant j'évite de piocher dans unstable et experimental pour des trucs plus critiques comme mesa, Xorg, linux-image, acpi, openrc, et la plupart des libs. Je préfère avoir des libs obsolètes pendant 6 mois tous les deux ans que de prendre le risque d'en avoir une qui me pète tous les logiciels qui en dépendent.

Autre choix : utiliser la version stable avec les dépôts backports, qui permettent d'avoir des logiciels plus à jour : libreoffice 5.2.6, linux-image-4.9 par exemple.

C'est quoi le pourcentage des logiciels de testing/stable présent dans backports ? Parce que si on veut que stable soit utilisable sur un desktop il faudrait rétroporter pratiquement toute la section games/ ainsi que la plupart des logiciels de communication (messagerie instantanée, vidéostreaming, etc.).

*splash!*

Lors des mises à jours, vous aurez alors un message vous prévenant que le paquet a été signalé comme contenant un bug. Je réponds alors toujours "p" pour "Pinning" et la mise à jour attendra une version non buggé de ce paquet.

Ah ben j'ai lu trop vite, il en parlait dans le journal. Je ne savais pas qu'apt-get/unstable proposait de pinner comme ça, c'est une fonctionnalité bien pratique que aptitude/testing n'a pas.

*splash!*

Puis comme une nouvelle version de debian devait sortir ils ont gelés SID pendant plusieurs mois. Il n'y avait alors plus de montée de version. Le Firefox (qui a l'époque montait de version moins souvent qu'aujourd'hui) était dépassé sur la base SID.
De plus j'ai eu quelques mise à jour qui se sont assez mal passées.

Les périodes de freeze c'est assez chiant ouais. Je suis sous testing et là je sais que je vais devoir attendre plusieurs mois avant d'avoir l'alléchant mesa 17.

D'autant plus que je ne met pas à jour tout mon système tout de suite à la fin du freeze, parce que je sais que la vague de paquets transférés de unstable à testing à ce moment-là peut poser pas mal de problèmes. J'attends donc entre 2 semaines et 1 mois avant de mettre à jour (c'est à dire que je passe en stable pendant 2 semaines - 1 mois :) ). Après cette période le gros des bugs qui cassent tout a été corrigé.

Note que j'utilise un environnement de bureau minimaliste et que je privilégie les logiciels les plus "KISS" (les plus simples et qui dépendent le moins d'un autre logiciel particulier), ce qui réduit pas mal la probabilité de "yatouképété suite à l'upgrade".

Si tu utilises un environnement complexe, style Gnome, KDE, Mate, Xfce, avec du GTK/Qt de partout, du *-kit, du *-dbus, du systemd-*, du upower, etc., je conseille d'attendre plutôt entre 1 et 2 mois.

*splash!*

Ne pas oublier d'installer aussi reportbug, pour le cas où tu installes tes mises à jour très vite, avant que apt-listbug ait des bugs à te rapporter.

*splash!*

Je ne peux pas parler pour unstable mais j'utilise testing et apt-listbugs et ça me sert. Parfois un bug important apparaît dans l'un des paquets que je veux mettre à jour, dans ce cas je le garde en "hold" pendant quelques semaines, et je le met à jour quand le bug n'apparaît plus. Donc mes paquets sont bien souvent à jour par rapport à la branche, il y en a juste un ou deux qui sont en "hold" une fois de temps en temps.

*splash!*