Comment j’ai réparé l’article sur la sécurisation SSH – Le blog de Seboss666

#15199

Débugage de malade.

La dernière fois que j’ai eu à faire un truc du genre c’était un plantage complet de Linux : freeze total, même les touches magiques ne fonctionnaient plus. Et aucun log disponible : le système freezait avant que le log puisse écrire.
C’était assez difficile à débuguer : il fallait faire varier un truc et attendre que ça plante, parfois des heures après : ajouter de la ram, désactiver le casque audio, arrêter le wifi, retirer la batterie…

Finalement c’était un problème d’architecture Intel, trop récente pour la version de Kernel en cours à l’époque : http://lehollandaisvolant.net/?d=2011/11/17/12/44/48-retour-sur-un-bug-coriace-avec-mon-pc-sous-linux


Dans tous les cas, partagez votre expérience ! Toujours toujours toujours !
Ça permettra à d’autres de ne pas perdre du temps et trouver une solution en tombant sur votre article (et de ne pas se sentir seul face à un bug, ce qui est déjà énorme).

https://blog.seboss666.info/2016/04/comment-jai-repare-larticle-sur-la-securisation-ssh/

Note : webfonts et proxy

#15182

Thuban, un utilisant de Blogotext m’a remonté un problème étrange : les webfonts que j’utilise ne fonctionnent pas chez lui.

Il a ce problème sur plusieurs sites, dans plusieurs navigateurs et impossible de savoir d’où ça venait.
En plus ça n’était pas systématique.

Il se trouve que c’était le proxy, qui avait du mal à mettre les fichiers au format "woff2" en cache.


Conclusion : encore une fois, les problèmes peuvent venir de n’importe où. Si c’est pas le navigateur, c’est le système, ou le serveur, ou le VPN, ou ici, un proxy.

N’oubliez pas, si vous utilisez des polices sur votre site, il peut être nécessaire d’ajouter ceci à votre .htaccess, pour la mise en cache des formats Woff2 et Woff de polices d’écritures (qui sont des formats assez récents et non implémentés nativement comme peuvent l’être JPG ou JS) :

<IfModule mod_expires.c>
  AddType application/x-font-woff .woff
  AddType application/x-font-woff2 .woff2
  ExpiresActive On
  ExpiresByType application/x-font-woff "access plus 1 year"
  ExpiresByType application/x-font-woff2 "access plus 1 year"
</IfModule>

http://lehollandaisvolant.net/?mode=links&id=20160426165002

Note : astuce sécurité PHP

#14797

MÀJ : voir les deux ÉDIT plus bas

Utilisez ça en haut de votre script PHP :

if ($_SERVER['PHP_SELF'] !== $_SERVER['SCRIPT_NAME']) {
	header('Location: '.$_SERVER['SCRIPT_NAME']);
}


Quand je vais sur la page "/index.php" ou sur la page "/" d’un répertoire, le contenu du fichier "index.php" est exécuté en PHP. Ceci est normal.
Par contre, quand je vais sur l’URL "/index.php/" (même chose, mais avec un slash à la fin) ou "/index.php/code_ici", alors Apache considère qu’on va dans un sous-répertoire (à cause du slash). Or, l’ouverture d’un répertoire constitue l’exécution de ce dernier (sous Unix/Linux). Du coup, le contenu de "index.php" est exécuté quand même, alors que pour n’importe quel autre fichier, ça aurait fait une erreur 404.

Le code PHP fonctionnera bien, mais tous les liens relatifs seront cassés, car apache considère qu’on a franchi un nouveau niveau de profondeur dans l’arborescence des fichiers.
Pire, quand on utilise le $_SERVER['PHP_SELF'] , ça contiendra le "/" et tout ce qui suit. Utilise le PHP_SELF est donc compromettant et peut devenir une faille XSS :
/index.php/%22onmouseover=prompt(971741)%3E



Ce que fait mon code : il compare le chemin du fichier actuellement exécuté (index.php) avec le chemin du fichier (index.php/). Si les deux sont différents, il y a un problème, et on renvoie sur (index.php).


ÉDIT :
Je viens de voir que certains serveurs, selon la config, retiraient directement tout ce qui suivait le "index.php". Mon code ci-dessus ne marche donc plus.
Du coup j’ai pondu ceci, qui a l’air de faire son job :

if (basename($_SERVER['SCRIPT_NAME']) === 'index.php' and strpos(parse_url($_SERVER['REQUEST_URI'], PHP_URL_PATH), 'index.php') === FALSE ) {
	$var_request_URI = parse_url($_SERVER['REQUEST_URI'], PHP_URL_PATH).'index.php';
} else {
	$var_request_URI = $_SERVER['REQUEST_URI'];
}
if (parse_url($var_request_URI, PHP_URL_PATH) !== $_SERVER['SCRIPT_NAME']) {
	header('Location: '.$_SERVER['SCRIPT_NAME']);
}


Vous pouvez essayer sur mon site :
http://lehollandaisvolant.net/
http://lehollandaisvolant.net/index.php
http://lehollandaisvolant.net/index.php?parametre
http://lehollandaisvolant.net/index.php/
http://lehollandaisvolant.net/index.php/?param
http://lehollandaisvolant.net/index.php/codeIci
http://lehollandaisvolant.net/index.php/codeIci/?param

J’ai vu que le problème était présent sur Shaarli aussi : allez sur votre shaarli, allez sur la page "index.php" (qui n’est habituellement pas affichée, mais qui existe quand même) et ajoutez un "/" à la fin de l’URL.

RÉ-ÉDIT : voir là : http://lehollandaisvolant.net/?mode=links&id=20160330174432

Pourquoi un faux easter egg vintage peut transformer votre iPhone en brique - Tech - Numerama

#14528

Ah oui : chez Apple, les nombres négatifs n’existe plus, c’est marqué dans les CGU.
Tim Cook veut que vous restiez positif, donc positif vous serez.
D’ailleurs, les électrons sont également interdits : leur réseau fonctionne exclusivement avec des positrons.



« Entre temps, évitez de vous connecter à un réseau public ou inconnu. Un petit malin pourrait avoir réglé la date émise par le serveur NTP (Network Time Protocol) sur le premier janvier 1970 et votre iPhone, bêta, pourrait alors se mettre automatiquement à cette heure […] »

Héhéhé.

http://www.numerama.com/tech/145906-pourquoi-un-easter-egg-vintage-peut-transformer-votre-iphone-en-brique.html

Note

#14380

Juste pour signaler que c’est "normal" que les liens récents de mon fil RSS sont publiés en double dans vos flux.
Une mise à jour du code a provoqué ça, ça n’est que temporaire.

http://lehollandaisvolant.net/?mode=links&id=20160128225738

Comment #12 : Bug #918019 : Bugs : firefox package : Ubuntu - Liens d'un Parigot-Manchot

#14367

Ah c’est donc ça…

Firefox veut toujours ouvrir tous les fichiers téléchargés avec Gedit (ou Pluma sous Mint). C’est assez chiant, quand il s’agit d’un Zip ou autre. Du coup on est obligé d’enregistrer le fichier (sur la bureau par exemple) et de double-cliquer dessus une fois que c’est fini.

(ÉDIT : murphystiquement, là je veux tester, je n’ai aucun problème…)

[question][css][chrome] - Couleur-Science

#13785

Sur le site Couleur-Science, y a t-il des personnes qui ont des soucis d’affichages de la police d’écriture sous Chrome/Opera (webkit/blink) ?

Est-ce que la police apparaît super fine (trop fine) comme ici : http://lehollandaisvolant.net/img/17/couleurscience_chromiumFontBug.png (ça s’affiche bien sous Presto (opera 12) et Gecko (Firefox) mais la police est manifestement trop fine sous Chromium).

Note : petit dommage collatéral avec les bloqueurs de pub

#13245

Dans Blogotext, pour éviter que les fichiers uploadés ne soient tous dans le même dossier (trop de fichiers dans un seul dossier a des répercutions sur les perfs du disque dur), j’utilise des dossiers au nom aléatoire.

J’ai ainsi le dossier "fichiers" et des sous dossiers dont le nom va de "00" à "ff" puis les fichiers à l’intérieur (rangés aléatoirement). Ainsi, avant qu’un dossier contienne 1000 fichiers (ce qui commence à être beaucoup), je dois en uploader 250 000 : j’ai donc de la marge.

Le truc, c’est que dans les noms de dossiers possibles il y a "ad", et les bloqueurs de publicité détectent ça comme de la publicité ("ad" = pub, en anglais) et bloquent les fichiers qui sont dans ce dossier.

Du coup je fais quoi ? Je dis de ne pas faire de dossier "ad" ? Dans ce cas, je devrais aussi bloquer le dossier "69" (risque de bloquage par les filtres parentaux), "66" (pour les satanistes), "75" (pour les parisiens), etc.

[CSS] You Know About Display Inline Block Gap

#12989

Ceci est un comportement très chiant. Seul Opera 12.x ne l’avait pas (en même temps, ce navigateur appliquait les spec mieux que les spec elle-mêmes…).

L’espacement est dû aux espaces dans le code source : espaces, tabulations, retour à la ligne.

Si on écrit tout le code HTML sur une seule ligne, ça sera moche mais le problème disparaît. Le code DOM généré en JS n’a pas ce soucis non plus.

Une autre solution est d’utiliser un « line-height:0; » dans le parent (le ul)et de remettre un line-height/font-size dans le block (les li).

http://www.frontendevelopers.com/you-know-about-display-inline-block-gap/