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 !
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 ?
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 !
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 ?
Ê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).
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.
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.).
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.
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.
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.
[^] # Re: Plus d'une façon d'utiliser Debian...
Posté par eingousef . En réponse à la dépêche Debian 9 : Stretch déploie ses tentacules. Évalué à 5.
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!*
[^] # Re: Plus d'une façon d'utiliser Debian...
Posté par eingousef . En réponse à la dépêche Debian 9 : Stretch déploie ses tentacules. Évalué à 4.
Parce qu'il y a une version "non-téléchargeable" ?
*splash!*
[^] # Re: Vivement la suivante
Posté par eingousef . En réponse à la dépêche Debian 9 : Stretch déploie ses tentacules. Évalué à 4.
Ben te plains pas alors
*splash!*
# Comment ça se passe pour rapporter les bugs ?
Posté par eingousef . En réponse à la dépêche Sortie de Devuan Jessie 1.0. Évalué à 5.
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!*
[^] # Re: Ah non ! ça suffit !
Posté par eingousef . En réponse à la dépêche Sortie de Devuan Jessie 1.0. Évalué à 10.
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!*
[^] # Re: gnome-disks
Posté par eingousef . En réponse au journal HOW TO : Bench this SSD. Évalué à 3.
la vis.
*splash!*
[^] # Re: GPG impossible en IPv6 ?
Posté par eingousef . En réponse au journal De la distribution des clefs OpenPGP. Évalué à 2.
J'ai trouvé, voir plus bas : https://linuxfr.org/users/gouttegd/journaux/de-la-distribution-des-clefs-openpgp#comment-1702481
*splash!*
[^] # Re: GPG impossible en IPv6 ?
Posté par eingousef . En réponse au journal De la distribution des clefs OpenPGP. Évalué à 3.
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!*
[^] # Re: GPG impossible en IPv6 ?
Posté par eingousef . En réponse au journal De la distribution des clefs OpenPGP. Évalué à 2. Dernière modification le 21 mai 2017 à 12:30.
mais quand je fais un
gpg --refresh-keys
(avec TCP 53 bloqué en ipv4) dans monnetstat -tunlap
j'ai une ligne du style :*splash!*
[^] # Re: GPG impossible en IPv6 ?
Posté par eingousef . En réponse au journal De la distribution des clefs OpenPGP. Évalué à 2.
Oui.
*splash!*
[^] # Re: GPG impossible en IPv6 ?
Posté par eingousef . En réponse au journal De la distribution des clefs OpenPGP. Évalué à 2.
(c'est une machine gandi)
*splash!*
# GPG impossible en IPv6 ?
Posté par eingousef . En réponse au journal De la distribution des clefs OpenPGP. Évalué à 4.
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!*
[^] # Re: ¨Langue anglaise, international oblige !
Posté par eingousef . En réponse à la dépêche Libre OS USB veut opter pour la gratuité. Évalué à 2.
attention tu as utilisé des derrièreapostrophes
*splash!*
[^] # Re: Tu ne dois pas souvent dormir...
Posté par eingousef . En réponse au journal [TRÈS_HS] « Moyen de gamme », sur lemonde.fr, nan mais je rêve. Évalué à 10.
O_o
*splash!*
[^] # Re: Pertinence de listbug
Posté par eingousef . En réponse au journal Comment je suis passé d'Ubuntu à Debian Sid. Évalué à 3.
Effectivement !
*splash!*
[^] # Re: Pertinence de listbug
Posté par eingousef . En réponse au journal Comment je suis passé d'Ubuntu à Debian Sid. Évalué à 3.
Ah ? De mémoire elle ne me proposait que [Y/n/?]
*splash!*
[^] # Re: Journal ~~> Dépêche
Posté par eingousef . En réponse au journal De la distribution des clefs OpenPGP. Évalué à 6.
Comme tous la série de journaux de gouttegd sur OpenPGP en fait.
*splash!*
# 2 questions
Posté par eingousef . En réponse au journal De la distribution des clefs OpenPGP. Évalué à 3.
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 :
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!*
[^] # Re: petite coquille
Posté par eingousef . En réponse au journal De la distribution des clefs OpenPGP. Évalué à 2.
et puis :
*splash!*
[^] # Re: imprécisions et mauvais conseils
Posté par eingousef . En réponse au journal Comment je suis passé d'Ubuntu à Debian Sid. Évalué à 3.
Ç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.
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!*
[^] # Re: Pertinence de listbug
Posté par eingousef . En réponse au journal Comment je suis passé d'Ubuntu à Debian Sid. Évalué à 2.
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 queaptitude/testing
n'a pas.*splash!*
[^] # Re: SID
Posté par eingousef . En réponse au journal Comment je suis passé d'Ubuntu à Debian Sid. Évalué à 3.
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
, dusystemd-*
, duupower
, etc., je conseille d'attendre plutôt entre 1 et 2 mois.*splash!*
[^] # Re: apt-listbugs
Posté par eingousef . En réponse au journal Comment je suis passé d'Ubuntu à Debian Sid. Évalué à 6.
Ne pas oublier d'installer aussi
reportbug
, pour le cas où tu installes tes mises à jour très vite, avant queapt-listbug
ait des bugs à te rapporter.*splash!*
[^] # Re: Pertinence de listbug
Posté par eingousef . En réponse au journal Comment je suis passé d'Ubuntu à Debian Sid. Évalué à 3.
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!*
[^] # Re: Trop fort !
Posté par eingousef . En réponse au journal MacronLeaks est tombé dans le pot de miel tendu par En Marche!. Évalué à 10.
s/"des gens"/"des politiciens français"/
du coup c'est normal qu'on s'extasie
*splash!*