Bonjour à tous , je fais actuellement la chasse aux logiciels ayant un code source fermé , et il me reste ces 5 là:
iucode-tool Intel processor microcode tool
intel-microcode Processor microcode firmware for Intel CPUs
firmware-iwlwifi Binary firmware for Intel Wireless cards
firmware-linux Binary firmware for various drivers in the Linux kernel
firmware-linux-nonfree Binary firmware for various drivers in the Linux kernel

Ma question est assez simple : puis-je les enlever sans avoir de problèmes plus tard , par exemple au niveau du wifi ou du processeur ?

Je suis sous debian ( amd64 ) , j'ai un processeur intel , et une carte wifi intel. Si je poste cette question , c'est parce que je me suis aperçu qu'après avoir enlevé les programmes proprio relatifs à ma carte graphique ( nvdia ) et au port ethernet ( realtek ) , tout continuer de fonctionner parfaitement , donc si ces 5 logiciels là sont aussi utiles ( ironie ) autant les supprimer.

Merci d'avance

Salut, donne toujours une liste complète avec lspci -nn et lsusb histoire qu'on ait une vue d'ensemble de ton matos.
Déjà, pas de firmware-iwlwifi = pas de WiFi avec ta carte Intel.
Pour ta carte Ethernet, c'est pareil chez moi, ça marche avec ou sans. (ça fait gagner du temps pendant l'install ).
Pour ta carte graphique... il existe un driver libre pour NVidia appelé nouveau qui vaut ce qu'il vaut mais fonctionne un minimum dans la plupart des cas, au moins. Donc tu n'es pas obligé de reposer sur le driver propriétaire en effet. (même si tu risques d'en avoir besoin pour faire tourner des applications gourmandes en rendu 3D, genre certains jeux)

Pour les différents firmware-linux et le reste, regarde leurs descriptions respectives dans ton gestionnaire de paquets pour déterminer si tu en as besoin ou non.

Google_Bot Donc je suis obligé de garde ce firmware -iwlwifi
En ce qui concerne la carte Nvidia , c'est pas la peine , je ne fait tourner aucun jeu ( à part des émulateurs GBA/DS mais il y a aucun problème avec )

Résultat de lspci -nn :
00:00.0 Host bridge [0600]: Intel Corporation 3rd Gen Core processor DRAM Controller [8086:0154] (rev 09)
00:01.0 PCI bridge [0604]: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor PCI Express Root Port [8086:0151] (rev 09)
00:02.0 VGA compatible controller [0300]: Intel Corporation 3rd Gen Core processor Graphics Controller [8086:0166] (rev 09)
00:14.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller [8086:1e31] (rev 04)
00:16.0 Communication controller [0780]: Intel Corporation 7 Series/C210 Series Chipset Family MEI Controller #1 [8086:1e3a] (rev 04)
00:1a.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 [8086:1e2d] (rev 04)
00:1b.0 Audio device [0403]: Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller [8086:1e20] (rev 04)
00:1c.0 PCI bridge [0604]: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 1 [8086:1e10] (rev c4)
00:1c.1 PCI bridge [0604]: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 2 [8086:1e12] (rev c4)
00:1c.2 PCI bridge [0604]: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 3 [8086:1e14] (rev c4)
00:1d.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #1 [8086:1e26] (rev 04)
00:1f.0 ISA bridge [0601]: Intel Corporation HM77 Express Chipset LPC Controller [8086:1e57] (rev 04)
00:1f.2 SATA controller [0106]: Intel Corporation 7 Series Chipset Family 6-port SATA Controller [AHCI mode] [8086:1e03] (rev 04)
00:1f.3 SMBus [0c05]: Intel Corporation 7 Series/C210 Series Chipset Family SMBus Controller [8086:1e22] (rev 04)
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:0fd3] (rev a1)
02:00.0 Network controller [0280]: Intel Corporation Centrino Advanced-N 6235 [8086:088e] (rev 24)
03:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS5209 PCI Express Card Reader [10ec:5209] (rev 01)
04:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller [10ec:8168] (rev 07)

Résultat de lsusb:
Bus 004 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 004: ID 174f:1453 Syntek
Bus 003 Device 003: ID 08ff:168f AuthenTec, Inc. AES1660 Fingerprint Sensor
Bus 003 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 005: ID 093a:2510 Pixart Imaging, Inc. Optical Mouse
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Bien, d'après https://wiki.debian.org/fr/Microcode , les paquets relatifs à Intel (les deux premiers dans ta liste) servent essentiellement à mettre à jour le firmware de ton processeur. Donc en gros ça sert dès qu'un nouveau microcode sort... maintenant, aucune idée de la fréquence à laquelle ça se produit.
Mais a priori ton système devrait fonctionner sans (après tout, Debian propose de s'installer sans activer les dépôts non-free par défaut donc bon)., à la limite si tu vois des mises à jour qui t'intéressent tu peux réinstaller les deux paquets le temps de l'effectuer, puis les virer. (ce qui en définitive revient au même puisqu'ils ne servent pas le reste du temps )

Pour firmware-linux-nonfree (qui est une dépendance de firmware-linux, qui n'est qu'un méta-paquet pointant vers d'autres paquets), regarde ça https://packages.debian.org/jessie/firmware-linux-nonfree et compare avec ton matériel. Pour ma part la seule fois où j'ai eu besoin de ce dernier c'était sur la machine de mon frère, équipée d'une carte graphique AMD. Même avec le pilote libre, l'utilisation du microcode propriétaire était nécessaire de mémoire.

Merci Google_Bot pour ton implication

Je vais dégager les firmware-linux et firmware-linux-nonfree , on verra bien Mais normalement ça devrait aller

Pour le microcode , j'avais vu un document qui me laissait perplexe face à l'utilité des maj d'intel , le voic si ça intéresse quelqu'un :
http://inertiawar.com/microcode/hawkes_intel_microcode.pdf

Je vais réfléchir un peu et faire quelque recherches supplémentaire

Je viens de faire un tour sur les forums de Trisquel et maintenant j'ai peur que ces microcodes apportent une floppée de backdoors

Le 24 juin 2015 à 23:44:13 Yamironin a écrit :
Je viens de faire un tour sur les forums de Trisquel et maintenant j'ai peur que ces microcodes apportent une floppée de backdoors

Euh...
Méfie-toi de la définition qu'ont Stallman et ses amis de ce qu'est une backdoor, tout de même.

(mais envoie les sources quand même, ça peut intéresser du monde et on est susceptibles d'éclaircir la situations si papy-extrême sombre encore dans ses délires)

Voilà : https://trisquel.info/en/forum/intel-processor-microcode-security-update-trisquel

Ça va j'ai viré adobe flashplayer donc je me sens pas trop visé

"éclaircir la situations si papy-extrême sombre encore dans ses délires"
Je sais pas du tout ce qu'il s'est passé mais ok

Faut aussi se méfier des fabriquants qui te proposent des firmware open-source et qui te foutent du binaire sous le firmware dans ton matos et si tu t'intéresses au code du firmware tu vois que la logique proprio est cachée dans les appels à ce code chelou.
(Référence à Broadcom sur le SoC de la PI à un moment )

À peu près la seule phrase qui vaut la peine d'être lue dans ce tas de merde:

The irony is that Trisquel's users will still have non-free code in their system, just an older version. Worst of both worlds.

Effectivement là où il y a blob, rien ne peut être vérifié. Maintenant, sans un blob de départ de toute façon ton CPU est une brique, donc à partir de là la seule solution si tu n'en veux pas c'est de ne pas l'acheter.
Morale de l'histoire, le seul choix que tu as dans la vie c'est celui du niveau requis pour compromettre tes systèmes: soit tu restes dans le passé et n'impore quel crétin sachant faire une recherche Google peut venir foutre le boxon chez toi, soit tu te mets à la page et les choses sont moins pires (mais, oui, si jamais tu te poses la question: la NSA peut encore potentiellement s'introduire chez toi).

kernel[] Normalement soit je n'ai jamais installé ce type de firmware soit je les ai virés ( nvidia ) et je n'ai aucun packet de Broadcom d'installé

Google_Bot Ça me rassure:hap:
Après j'ai normalement assez sécurisé et "loggué" mon système pour détecter une activité suspecte.
Et je doute ensuite d'être assez important pour qu'un agent de la NSA tente d'accèder physiquement à mon PC afin d'activer la dite backdoor

Tu sais pas ce qu'il y a dans ton CPU de toute manière, ils me semblent que les russes par exemple achètent des licences de design ARM et font le sillicone eux-même, comme ça ils maitrisent vraiment tout le contenu de la chip. Sinon tu peux pas savoir ce qu'on a foutu dedans, faut pas être parano, mais voilà tu peux pas te protéger efficacement dans ce cas-là.

Le 25 juin 2015 à 14:13:32 Yamironin a écrit :
kernel[] Normalement soit je n'ai jamais installé ce type de firmware soit je les ai virés ( nvidia ) et je n'ai aucun packet de Broadcom d'installé

Google_Bot Ça me rassure:hap:
Après j'ai normalement assez sécurisé et "loggué" mon système pour détecter une activité suspecte.

Haha je ne veux pas te décevoir mais les attaques qui visent les bas niveaux logiciels voire le hardware seront les dernières à laisser une trace dans de quelconques logs.
Mais bon, au moins t'es protégé contre le reste du spectre des attaquants potentiels.

Et je doute ensuite d'être assez important pour qu'un agent de la NSA tente d'accèder physiquement à mon PC afin d'activer la dite backdoor

Certes.

kernel[] Après il faudrait avoir du hardware libre , mais je sais même si ça existe

Google_Bot Oh non , j'ai déjà intégré le fait que niveau hardware s'était " the end" alors en fait j'ai crée des règles audit pour qu'il me loggue toutes les activités sur le système , comme ça si je suis infecté et que mon PC communique avec le C&C je devrais normalement être au courant. De même je compte sur rkhunter pour me dire si un fichier a été modifié ou non