eingousef a écrit 1604 commentaires

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!*

s/"des gens"/"des politiciens français"/

du coup c'est normal qu'on s'extasie

*splash!*