gaaaaaAab a écrit 1387 commentaires

effectivement, les systèmes de fichiers habituellement utilisés sous Unix stockent la date de dernière modification, et pas la date de création. Et effectivement, c'est parfois génant.

Pour répondre aux autres questions du message de départ, la date de dernier accès à un fichier (le atime) est disponible. On peut la voir avec la commande
stat fichier
ou avec ls (mais probablement pas du tout portable)
ls -l --time atime fichier

Attention cependant, pour gagner quelques pouillèmes en performance en lecture (sur les gros systèmes très sollicités, ça peut faire des gros pouillèmes), les systèmes de fichiers sont parfois montés avec l'option noatime. Dans ce cas, les dates d'accès ne sont pas mis à jour dans les inodes des fichiers.
Tant que j'y suis, les atime, en fait, osef. En tout cas, je n'en ai jamais eu besoin jusqu'à présent, et je ne connais (en tout cas, pour l'instant) aucun soft qui s'en serve.

Pour finir, les outils habituels d'archivage sont sympas, ils préservent les dates des fichiers, donc pas la peine de s'embêter à fabriquer une liste à côté. Les fichiers sauvegardés auront les mêmes attributs fonctionnels que les fichiers originaux (uid, gid, permissions, dates diverses et variées).
Même la commande cp peut préserver ces attributs si on lui demande gentiment (man cp) !

Mais ça, avec quelques tests de ton côté, t'aurais pu répondre tout seul ;)

Le protocole SMS était à l'origine un système interne pour tester la ligne.

heu ... non. Le protocole SMS sert à pleins d'autres trucs que d'échanger des messages de type texte.

Par contre, possible que ça devienne vrai si on transforme la phrase en :
les SMS au format texte était à l'origine un système interne pour tester la ligne
mais il faudrait des gens dans le secteur depuis plus longtemps que moi pour confirmer.

... désolai pour les fôtes

(et qui semble être mal implémenté)

en fait, il y a plusieurs classes de SMS. Parmi les SMS affichables, il y en a deux sortes, ceux interprétés par le mobile qui s'affiche une fois et ne sont pas stockés, et ceux à destination de la carte SIM qui peut en stocker un certain nombre (défini au moment de la personnalisation de la carte). Vu le format du système de fichier GSM, le maximum théorique est de 255 SMS. Les anciennes cartes à puce ne supportent souvent pas le stockage de plus de 10 SMS (parce que ça prend de la place et les opérateurs veulent réduire le coup des cartes SIM en payant des composants de moindre capacité, donc moins chers).

Pour les SMS concaténés, il y a aussi une limitation au niveau de la carte. Les différents fragments sont stockés dans un tampon qui fait n * 133 (140 ou 160 en fait, avec les en-tête, la flemme de chercher), mais n vaut rarement 255 (aussi un paramètre de personnalisation).

Pour pallier les limitations des cartes SIM là dessus, les téléphones modernes permettent aussi de gérer les SMS reçus et envoyés dans la mémoire du téléphone. Avantage : on peut en stocker pleins. Inconvénient, quand on change la SIM de tél, on ne transporte pas l'historique.

Pour conclure, c'est globalement le gros bins, parce que le nombre max de fragments d'un SMS concaténé dépend du modèle de la carte (et il y a une tripotée de modèle et chaque modèle est décliné suivant une tripotée de personnalisation) et des capacités du tél.

Je comprends du coup que les opérateurs ne communiquent pas trop là dessus, parce qu'ils ne peuvent pas garantir un fonctionnement homogène pour tous leurs abonnés.

oui, bien vu.
Moment nostalgie : en prépa, sur les PCs, l'environnement Windows était très très limité. Par contre, l'IDE qu'on utilisait (ça devait être du Borland Pascal, ça nous rajeunit pas) avait une chouette menu pour ouvrir un shell dos =)

ok, j'en déduis que tu as rencontré des problèmes (probablement contournables en y passant un peu de temps) dans l'implémentation d'un script particulier, mais pas de critique de fond sur le mécanisme.
merci pour les précisions

heu ... ça m'arrive de faire ça et je ne vois pas quels problèmes ça soulève. Au contraire même, je trouve ça très bien :)
Du coup, ça m'intéresserait que tu développes sur ce que tu vois de négatif là dedans.

ah ... manifestement, je suis total à côté de la plaque là :
cf http://linuxfr.org/comments/1091331.html#1091331

donc 4100 € ? ;-)

de ce que j'en avais compris, l'idée du port knocking part du constat que les méchants pirates^w script kiddies tentent de casser les mots de passe faibles pour les utilisateurs habituels sur les ports standards (genre le mdp root/admin/www-data ou autre sur ssh).

L'idée du port knocking est que le port 22 soit fermé par défaut, et que seule une combinaison de ping sur des ports dans un ordre déterminé l'ouvre pendant quelques minutes.
Ensuite, c'est une connexion ssh classique avec authentification classique.
Au bout d'un certain temps (configuré quelque part), le port 22 se referme.

Pour tout attaquant scannant les ports en dehors de cette plage de quelque minutes, la probabilité qu'il scan les ports dans le bon ordre étant faible, le service ssh n'est pas accessible (donc pas troutable)

ce que tu décris (grosso modo, l'envoi d'un challenge), c'est finalement l'authentification par clefs . Ca existe aussi, mais c'est pas du port knocking.

je suis pas sûr que ça répond à la question de départ, mais ce que tu écris là, ça serait plus joli comme ça:

SELECT t1.id
FROM table_contenant_toutes_les_ids t1
WHERE NOT EXISTS (SELECT 1 FROM table_des_ids_réservés t2 WHERE t1.id = t2.id)


;-)
sur ce coup là, je n'aurais pas pu écrire ça sans ton commentaire.

Le hold space, c'est le genre de trucs ou on se demande après coup comment on a pu passer à côté si longtemps ...
Je compte plus le nombre de trucs que j'ai appris sur programmation.shell, je l'aime bien ce forum :)

et en élaborant encore un peu (pour couper les blocs incomplets en fin de fichier, même si ce n'était pas demandé) :

sed -n '/TIMESTAMP/,/OUT/{
/TIMESTAMP/ { h }
/IN/ { H }
/OUT/ {
H
x
p
}
}' ./path/to/file


a y est, je suis fan du hold space :)

ton script m'a fait farfouiller le man =)

On peut le raccourcir un tout petit peu en omettant le label, puisque d'après le man (et confirmé par mes tests), lorsqu'il est omis, ça branche en fin de script.

Sinon, avec sed, on peut aussi travailler par bloc de lignes (pas seulement en ligne à ligne), et ça permet de simplfier :

sed -n '/TIMESTAMP/,/OUT/{
/IN\|OUT\|TIMESTAMP/{
p
}
}' /path/to/file


à noter que dans ces deux versions, on affiche le début du dernier bloc TIMESTAMP/IN/OUT même s'il est incomplet.

par "requête SQL plus courte", tu parles de la longueur de la chaîne de caractères qui contient la requête ? ou de la conso mémoire lors de son exécution ?

j'aurais presque envie de faire un multi pour pouvoir te re plusser :-)

C'est mieux?
En mettant de côté le "petit" problème opérationnel avec RMS (le clônage n'existe pas ;-), envisageons un logiciel pas libre qui forge des captures d'écran de logiciel libre et qui les envoie toutes les secondes (au lieu d'une seule fois).

Quand l'utilisateur veut se connecter, le serveur lui envoie la fameuse fonction d'authentification générée pseudo-aléatoirement. Là l'utilisateur dispose de 3 minutes pour compiler le client et se connecter avec. Le role de la fonction c'est qu'elle doit être réputée très difficile a analyser et réimplémenter en 3 minutes. Donc l'utilisateur ne pourra en 3 munites n'utiliser que celle là.

Je pense qu'en quelques dizaines de connexion, un attaquant aura suffisamment de billes pour distinguer les quelques classes de ces fonctions (vu comme c'est déjà pas simple d'en fabriquer ne serait-ce qu'une seule, je ne suis pas convaincu que ça soit très faisable d'en générer pleins à la volée), analyser tranquillement et écrire du code pour gérer tous les cas.
Sinon, pas la peine de s'embêter, suffit de s'en servir une fois dans un client libre dans la plage des 3 min, en espionnant la mémoire ou les traces réseaux, et les quelques informations utiles sont accessibles.

Vu tout ce que tu lui demandes de faire à cette fameuse fonction, c'est plus une fonction, c'est un logiciel ! Ce qui nous ramène au cas précédent. Il suffit de comprendre le protocole entre cette fonction et le serveur pour la ré implémenter sans l'utiliser.

Le problème fondamental, c'est que tu dois donner au client des moyens pour se connecter, et, tu peux essayer tout ce que tu veux pour essayer d'obscurcir le mécanisme d'authentification, in fine, la machine cliente dispose toujours des informations nécessaires à la connexion. Du coup, ça sera toujours contournable par quelqu'un d'expérimenté (cf toutes les majs d'Itunes).

La liberté n'a pas de prix!
En même temps, il me semblait que pour la GPL, l'idée, c'était de protéger les liberté tant des développeurs que des utilisateurs. Si on ne s'occupe de protéger la liberté que d'un point de vue dogmatique (il faut que ça doit libre parce qu'il faut que ça soit libre), ça perd un peu de son sens.

En fait, on mélange un peu deux choses dans ce débat j'ai l'impression : la liberté du code et l'ouverture d'un service. Et là, on n'essaie de calquer les notions de liberté (qu'on a l'habitude de voir pour le code) sur un hybride code/service, et amha, ça marche pas bien :)

voui, je ne peux que présenter mes plates excuses pour cette erreur grossière :)

Effectivement, tant qu'il n'y a pas de redistribution, y a pas de question.

précaution d'usage : IANAL (je ne suis pas juriste)

Par conséquent, j'imaginais qu'une donnée (au sens large), nécessaire pour se connecter au service, licenciée en gplv3, s'apparentait à du code source et donc ne pouvait être "fermée".

sauf qu'en droit, y a pas beaucoup de place pour l'imagination (ni pour l'imprécision d'ailleurs).
"Une donnée s'apparentant à du code source", j'avoue avoir du mal à cerner ce que ça veut dire :)
Le code source est protégé, pas ce qu'il fait (il n'y a pas de brevets logiciels en Europe). Du coup, réimplémenter un algorithme utile à une interaction avec du soft GPL n'en fait pas (à mon avis) une violation de la GPL.

Pour finir, en dehors du fait qu'on peut s'interroger sur ce que signifie le mot libre dans un tel contexte, à part des conditions d'utilisations strictes, l'enregistrement de tous les utilisateurs, des mécanisme techniques (pas très fiables) pour détecter les violations des conditions et des mécanismes de fermeture de compte, je ne vois pas trop.
Mais là, ça sort du cadre de la technique.

bon, je répond un peu en vrac, mais en même temps, ton commentaire est un peu ramassé sur lui même :)

je peux t'envoyer des captures d'écran d'un logiciel ... et en utiliser un autre.

Et ta fonction d'authentification, quelle est son rôle ? S'il s'agit simplement d'encapsuler la valeur magique dans une fonction, y a encore moins de doute qu'avec un simple chiffre magique. Il suffit de réimplémenter sa propre fonction d'authentification, d'utiliser la valeur magique récupérée du fichier téléchargé, et cest plié.
(sachant qu'il n'y a déjà pas de doute sur un simple nombre, cf DeCSS)

S'il faut que j'upload mon client SOAP pour l'appeler ensuite en SSH, reconnais que ça perd une partie de son intérêt.
Et puis, comment vérifies-tu que le programme uploadé en SSH est bien libre ?

Si le fichier source est sous GPL, ca force même le client à l'être aussi.

Juridiquement oui, techniquement, c'est beaucoup moins certain ;)

Finalement c'était pas si difficile que ca :D

Ah, voilà une conclusion qui va faire plaisir à nos amis industriels du disque, du cinéma et des jeux vidéos, parce que pour l'instant, ils y arrivent pas =)
(ok, ils veulent le faire dans l'autre sens, mais c'est une problématique symétrique de ce point de vue là)

ça ne marche pas. Rien n'empéche de récupérer ce nombre magique et de l'utiliser dans un fichier à soi, sans faire une quelconque référence au fichier "chiffre_magique" en GPL V3. En fait, tu ne peux pas protéger un nombre.

Jette un oeil sur l'AGPL (Affero GPL), ça pourrait p-e te convenir (mais j'ai l'impression que ça couvre un autre problème en fait).

Concernant l'accès au service, techniquement, je ne vois pas comment tu peux forcer l'utilisation d'une implémentation GPL (ou autre licence libre) d'un client.
A priori, tu publieras un protocole que les clients devront implémenter pour interagir avec le serveur.
Ensuite, vu que l'intégralité des échanges client/serveur sera défini dans ce protocole, il sera techniquement rigoureusement impossible de distinguer un client libre d'un client proprio à partir du moment ou ils implémentent tous les deux correctement le protocole.

Tu peux éventuellement favoriser (mais pas garantir) l'émergence de clients libres en proposant des API en affero GPL.

Sinon, dans ton commentaire, quand tu parles de logiciels proprios, on pense tout de suite à la méchante boite parasite qui se goinfre sur le dos des gentils développeurs de LL (ou alors c'est juste moi, possible que je souffre d'un biais sémantique :)
mais si quelqu'un chez lui implémente ce protocole dans un soft qu'il utilise chez lui et qu'il ne redistribue à personne, c'est aussi une implémentation propriétaire.

Pour finir, est-ce vraiment bloquer l'utilisation de logiciels proprios que tu veux ? ou simplement fermer l'utilisation à tout logiciel à visée commerciale ?

respire un coup :)
lis http://www.maitre-eolas.fr/category/Magistrats-en-colere .
Dans la foulée, tu peux lire toutes les archives d'Eolas.
Pis on reparlera des juges après.

trailer : si le législatif et l'exécutif faisait bien leur boulot, la justice remplirait mieux son rôle.

presque bien, tant que les noms de fichiers n'ont le mauvais goût de contenir des espaces.
ça peut se contourner en awk (en bouclant de $2 jusqu'à $NF), mais c'est un peu pénible.
ça peut aussi se faire en sed :

ls -s * |sed 's/^\s*\([0-9]*\) \(.*\)/\2;\1/'

oula, je viens de relire mes commentaires
bon, oubliez moi sur ce thread, je raconte vraiment nimp' :D

je suis d'accord.
cf http://linuxfr.org/comments/1075397.html#1075397