🚲 Tanguy Ortolo a écrit 12690 commentaires

Troff, c'est bien ce format de rédaction de documents, utilisé essentiellement pour les pages de manuels, qui utilise un formatage physique direct plutôt que des styles logiques, et qu'on utilise essentiellement en cible de convertisseurs à partir de DocBook ou de Markdown ?

Il y a aussi des cochons.

Si c'est écrit à la main, c'est fait avec une tablette graphique ou quelque chose du genre, sur ordinateur. Ou alors, je veux la marque de tes feutres qui donnent une largeur qui ne varie pas d'un iota et des bords de traits impeccables.

Oui enfin là, c'est une fonte informatique à modifier. Parce que bon, ça peut faire illusion trente secondes, mais ce n'est pas écrit à la main ça.

Hors donc, [...]

Or donc. Hors, ça veut seulement dire dehors, comme dans « Hors d'ici, gueux ! » (Phrase qu'eût pu prononcer le président Sarkozy, eût-il eu un peu de lettres et d'esprit. Mais d'esprit, ô le plus...)

C'est triste ton avis sur les forums.

Ça n'a pas l'air bien difficile à modifier, mais déjà, un truc intéressant à savoir : les images sont stockées telles quelles, et ne sont qu'affichées réduites dans la vue au sein d'un album. Les liens d'affichage de l'image et de téléchargement fournissent l'image d'origine.

Dans ce cas, c'est à signaler comme bug ça : ce comportement devrait au minimum être réglable, l'utilisateur devant pouvoir choisir si les photos nouvellement envoyées soient réduites ou gardées telles quelles.

PhotoShow: Même problème que PhotoFloat : on télécharge une image de 800px de large et le navigateur upscale.

Euh, non. Je crois que tu peux les mettre à la taille que tu veux, tes images.

make -j 42

Tu peux aussi évaluer Gallery, PhotoShow et MediaGoblin.

Il va falloir m'expliquer comment marche des drm sous linux ... Dans tous les cas sous linux on peut facilement recuperer le contenu en clair. Soit en capturant l'image. Soit, si le decodage a lieu en utilisant des librairie comme vdpau en capturant directement le h264 decrypte mais pas decode.

Chuuuut, pas si fort, on risque de t'entendre ! Oui, vu l'architecture décrite par Mozilla pour leur utilisation d'un plugin de DRM fait par Adobe, la copie privée sera très facile, sans même avoir à faire de recodage derrière. Mais il ne faut pas que ça s'ébruite, parce que les distributeurs aiment bien toucher la redevant pour copie privée mais n'aiment pas du tout que leurs clients fassent usage de ce droit, donc si ça se savait trop largement, ils risqueraient de revenir à des systèmes plus casse-pieds.

The password is not used directly in the digest, but rather HA1 = MD5(username:realm:password). This allows some implementations (e.g. JBoss[3]) to store HA1 rather than the cleartext password

De sorte que HA1 devient le véritable mot de passe, stocké en clair sur le serveur. Supaire.

Je ne sais pas si tu es au courant, mais il existe des CD d'installation de Debian spécifiques pour chaque bureau majeur.

Ces techniques nécessitent un stockage du mot de passe en clair sur le serveur, et sont donc à éviter.

Non, et ça tombe bien, on n'a pas besoin. Les paiements se font sur le site d'un intermédiaire de paiement qui est tout à fait sécurisé.

En revanche, pour, disons, le wiki d'un projet quelconque, il est préférable de transmettre son mot de passe en HTTPS sans authentification du serveur, que de le transmettre en clair, bien que le navigateur rendre cette seconde pratique moins effrayante que la première.

Parce que c'est mieux que de ne pas chiffrer du tout. Le chiffrement sans authentification est vulnérable aux attaques par réécriture, mais pas aux écoutes passives.

On ne t'a pas attendu pour ça !

https://en.wikipedia.org/wiki/DANE
http://www.bortzmeyer.org/6698.html
https://tools.ietf.org/html/rfc6698

Reste à convaincre les éditeurs de logiciels clients de s'y mettre. Bon courage.

Même avec un certificat auto-signé, la sécurité du https est strictement supérieure à celle du http.

Pluzun. C'est d'ailleurs un gros problème des navigateurs actuels, pour lequel j'avais ouvert un rapport de bogue sur Firefox : lorsqu'un utilisateur se connecte sur un serveur dont le certificat ne peut pas être validé, il y a un avertissement effrayant, alors que lorsqu'il envoie en clair un mot de passe, ce qui est bien pire, il n'y a aucun avertissement.

J'ai commencé la construction d'un site web pour la première fois et j'ai choisi de rediriger tout le traffic vers l'HTTPS par défaut.

Ce qui est une grave erreur. En effet, le visiteur peut ainsi s'habituer à taper l'adresse sans HTTPS et se reposer sur la redirection sans y prêter attention. En cas d'attaque, la première chose que fera un pirate en interception et réécriture sera de faire sauter la redirection en question et de laisser l'internaute rester en HTTP.

Il y a plusieurs alternatives à cette approche dangereuse :

1. ne pas fournir du tout d'accès HTTP : l'internaute qui essaie sans HTTPS tombe sur un refus de connexion et doit de facto s'habituer à bien demander du HTTPS ;
2. fournir un simple page d'erreur en HTTP, expliquant qu'il faut bien taper HTTPS ;
3. utiliser HSTS, l'internaute essayant en HTTP se retrouvant dirigé en HTTPS et son navigateur retenant cela pour ne plus jamais y accéder en HTTP.

Par contre, GOG ne recompile pas ses jeux pour Linux avec Wine – je ne pense d'ailleurs pas qu'il disposent des sources pour cela.

Si ce sont eux qui s'occupent du portage, j'espère bien que si ! Si je m'occupais d'un portage et qu'un éditeur de jeux me refusait les sources, je crois que je l'enverrai chier illico : je ne peux pas bosser correctement sans cela.

En effet, l'UEFI est plus « moderne ». Façon Intel, qui ont considéré que la voie à suivre pour un shell moderne, par exemple, était de le calquer sur un grand modèle tel qu'MS-DOS : on trouve donc dans un shell EFI des lettres de lecteur et des \ comme séparateur de répertoires... De même, ils ont considéré que le meilleure chose à faire pour le format d'exécutable à adopter était de prendre exactement le même que celui de Microsoft Windows, de sorte qu'un file sur un exécutable EFI indique qu'il s'agit d'un exécutable pour Windows.

C'est aussi considérablement plus complexe qu'un BIOS, donc parfois considérablement plus bogué malheureusement.

EFI Stub

L'architecture ARM 64 bits dispose désormais de la gestion d'EFI stub. Linux EFI stub permet à un système disposant d'un firmware (U)EFI de démarrer l'image du noyau directement sans avoir à passer par un bootloader (tel que Grub ou elilo). Ceci est notamment possible en ajoutant du code au début de l'image du noyau afin de faire croire au firmware (U)EFI qu'il s'agit d'une image de type PE/COFF, de cette façon le noyau se fait passer pour un exécutable (U)EFI.

Pourquoi « faire croire » et « se faire passer » ? Le noyau, ainsi préfixé par un en-tête et un code initial approprié, ne devient-il pas un vrai exécutable PE/COFF pour UEFI ? Exécutable qui fera plein de trucs et cessera rapidement d'utiliser l'UEFI, ce qui ne change rien à sa nature initiale, si ?

Ce qui est justement un des deux usages de Wine, probablement le moins connu, puisque ce logiciel permet :

• de faire tourner des logiciels conçus et compilés pour Windows, sous une couche de traduction ;
• et donc, de compiler des logiciels conçus pour Windows, en les liant à la libwine, de façon à produire des binaires natifs pour GNU/Linux.

Ce qui est intéressant, c'est que les binaires résultants ne tournent pas sous Wine mais sont bel et bien des binaires natifs pour GNU/Linux, qui appellent simplement des fonctions de la libwine. Cela a également ceci d'intéressant que ces logiciels peuvent même éventuellement être ensuite partiellement adaptés et utiliser en même temps des fonctions tout à fait indisponibles sous Windows. Autrement dit, avoir accès aux deux API Win32 et POSIX.

Petite question : quel intérêt y aurait-il à activer la fonction UEFI, à part casser grub et l'install ?

Pour un simple utilisateur qui ne veut pas se prendre la tête, à peu près aucun. Pour un bidouilleur, le plaisir d'utiliser une technologie censée être conçue de façon moderne et plus souple que celle d'un BIOS, notamment pour la façon dont se fait l'amorçage. En effet, avec un BIOS, l'amorçage c'est :

1. chercher, dans une liste pré-configurée de périphériques, un code de démarrage ;
2. l'exécuter, dans un environnement standard ;
3. c'est ensuite à ce code, qui doit être minuscule (512 octets il me semble) de sauter sur un endroit où est vraiment stocké le code principal du chargeur de démarrage ;
4. c'est ensuite au chargeur de démarrage de proposer plusieurs possibilités de démarrage et de lancer un système d'exploitation.

En particulier, le BIOS ne prévoit rien du tout pour permettre de choisir entre plusieurs systèmes d'exploitation : c'est au chargeur de démarrage de le faire, et comme c'est aussi à lui de charger chaque système, cela donne de belles contorsions pour permettre de choisir entre un GNU/Linux (que GRUB sait lancer) et un Windows (que GRUB ne sait pas lancer, et pour lequel il doit passer la main au chargeur de Microsoft, qui doit donc toujours être là mais pas lancé directement à l'amorçage).

En UEFI, cela a été rationnalisé :

1. l'UEFI propose une liste pré-configurée de systèmes d'exploitation (en fait de chargeurs de démarrage), chacun correspondant à un fichier présent sur une partition spéciale formatée en FAT ;
2. selon le choix de l'utilisateur, il exécute le fichier correspondant au choix de l'utilisateur ;
3. le fichier en question est un chargeur de démarrage qui se charge donc de la suite.

Il y a là deux avantages sur le BIOS :

• le choix du système à démarrer ne dépend pas d'une bidouille impliquant de chaîner des chargeurs de démarrage mais est prévu par la norme, l'utilisateur pouvant définir une liste des systèmes disponible, chacun correspondant à un fichier à exécuter ;
• la mise en place d'un chargeur de démarrage est « propre », dans la mesure où elle consiste seulement à mettre un fichier sur une partition formatée en FAT, puis à passer un appel UEFI demandant d'ajouter une option de démarrage correspondant à ce fichier (à comparer avec la méthode BIOS qui consiste à mettre le code principal du chargeur de démarrage dans l'espace intersticiel entre le MBR et le premier cyclindre, puis à éditer les 512 octets de code de démarrage de la MBR pour y mettre un saut sur cet espace intersticiel).