Cédric Bonhomme a écrit 31 commentaires

Pour un peu plus de contexte voici un ancien lien partagé:
https://linuxfr.org/users/cbonhomme/journaux/referentiels-de-securite-sur-mosp

MOSP est développé en Python (Flask):
https://github.com/CASES-LU/MOSP
Assez simple à déployer pour ceux qui ont un peu de temps:
https://github.com/CASES-LU/MOSP#clone-the-repository-and-use-a-python-virtualenv …

Un journal sur MONARC? Cool!

Pourquoi pas. Cela peut se faire. J'aurai enfin une description en Français.

Au début une instance de MOSP propose des schémas JSON. Par la suite il est possible de créer des organisations (composées d'utilisateurs) qui utilisent ces schémas et fournissent de nouveaux schémas (si l'instance en question accepte ceci).

Les schémas sont toujours publics. Le but est que un utilisateur puisse sélectionner un schéma (qui définit un type d'objet, exemples métier https://github.com/MISP/misp-objects/tree/master/objects , désolé…). La sélection du schéma va générer un formulaire pour créer l'objet. Jusque là pas besoin de jsonschema.
Et il pourra créer ce schéma pour l'une des organisations dont il est membre. Ou simplement forker un schéma.

Mais tout ceci est aussi faisable via l'API. C'est la que jsonschema intervient. Pour la validation de ce qui arrive par l'API:
https://www.monarc.lu/documentation/MOSP-documentation/#creating-a-new-object-2
(même si normalement le client, par exemple MONARC, est sensé envoyer des données bien formés…)

Une autre solution que nous utilisons depuis longtemps est GitHub + Travis:
https://github.com/MISP/misp-objects/blob/master/validate_all.sh#L29
C'est disons un peu plus rude pour les utilisateurs de logiciels comme MONARC qui préféreront une interface un plus sympa.

On ne progresse guère. L'essentiel de ce que je peux inférer de cette troisième explication apparaissait déjà dans le journal et la seconde.

Si mon précédent commentaire permet de comprendre la même chose que le billet, c'est "pratiquement" ce que je voulais.
Et donc LinuxFr n'est certainement pas le bon endroit pour mon billet. Tant pis pour moi. Je ne voulais pas expliquer ce cas d'usage de MOSP (quitte à perdre des lecteurs). Sinon j'aurai je pense fait un billet sur MONARC. J'ai trop insisté sur l'aspect sécurité certainement parce qu'il s'agit actuellement du seul qui se trouve être utile pour moi.
J'aurai aimé avoir des retours sur l'idée, avoir des suggestions, etc.

J'ai vraiment mal orienté ce billet. Le titre est mauvais aussi.

Le but était de parler de MOSP: des objets JSON que l'on peut éditer et partager. Ainsi que de l'édition via les schémas JSON.
Actuellement MONARC est un des logiciels qui bénéficient de MOSP. Dans le domaine de la sécurité, en effet.
La où NIST intervient, c'est dans les standards. Mais je ne vais pas insister sur ceci. Le fait est que dans MOSP nous avons maintenant quelques standards au format JSON qu'il est possible d'éditer, forker, partager, etc. Ceci en passant par l'éditeur Web ou par l'API (toujours en étant assuré du bon format de l'objet).

L'instance objects.monarc.lu de MOSP est dédiée aux objets liés à la sécurité. Ce qui m'intéresse pour des usages liés avec MONARC.
Je n'exclue pas dans l'avenir de déployer une seconde instance initialisée avec d'autres schémas JSON. Pour partager d'autres types d'objets. Une des raisons pour laquelle il est très facile à déployer (surtout sur Heroku, voir le README).

MONARC est utilisée pour effectuer des analyses de sécurité (ou effectuer un DPIA - Data Protection Impact Assessments). Le logiciel utilise dans sa base de données différents types d'objets (par exemple: threats, vulnerabilities, assets). Ces objets de base permettent de travailler sur un un projet dans MONARC (un analyse de risque 27002 - je ne vais pas m'étendre sur cet aspect).

Jusqu'à présent les données étaient fournies avec le logiciel MONARC. Dans le logiciel une interface permet l'édition de la base (création de nouveaux objets, éditions, etc.) si besoin pour de nouvelles analyses.
Ceci était manuel. Et pas pratique pour le partager.
Car par exemple des personnes vont créer un nouveau référentiel type NIST (des mesures de sécurité) pour une analyse. Ce nouveau référentiel personnalisé peut intéressé d'autres personnes qui utilisent MONARC.
D'où l'idée d'avoir une plateforme, MOSP, permettant la création de nouveaux objets valides. Pour, mais pas que, MONARC.

Et bientôt, MONARC pourra directement récupérer de nouveaux objets via l'API de MOSP. Ce qui évite à un utilisateur d'exporter un JSONsur MOSP, puis d'importer dans MONARC.

Mais avec ce billet je voulais surtout présenter MOSP et ne pas m'étendre sur le métier (analyse de sécurité). MOSP est un outil générique, qui sera je l’espère utilisable dans d'autres contextes.

En bref, MOSP est un éditeur dont un est des objectifs est de partager des objets JSON. Ici liés à la sécurité (référentiel de contrôle NIST, ISO/IEC 27002, etc.).
L'éditeur est généré automatiquement en se basant sur un schéma. Exemple:
https://objects.monarc.lu/schema/view/12
pour les objets de ce type:
https://objects.monarc.lu/schema/12

Et ces objets sont utilisables dans différents outils.

Dans les référentiels de l'outil MONARC:
https://www.monarc.lu/assets/images/posts/MONARCv2.8-Referentials.png#center

Et aussi utilisables dans MISP (https://misp-project.org) avec, par exemple, ces objets:
https://objects.monarc.lu/schema/3
Ceci nous permet d'usiter la taxonomie "Threats" de MONARC sur des IOC (Indicator of compromise) dans MISP.

C'est mieux?  ;-)

Désolé pour les liens:

3: https://github.com/misp/misp-objects
4: https://github.com/MISP/misp-galaxy
5: https://github.com/MISP/misp-taxonomies

Je suis d'accord que cela mérite un journal. Je vais peut être en faire un lorsque j'aurais le temps et que l'application sera plus avancée en terme de fonctionnalité.

À la base l'objectif de la plate-forme est d'échanger des modèles de données liés à la sécurité.
Le premier but était de créer une communauté afin d'échanger des modèles pour des applications comme MONARC1 ou MISP2. De créer un pont entre ces applications.

Le projet MISP, qui je pense n'est plus à présenter, utilise déjà beaucoup des modèles de ce type [3, 4, 5].
MOSP permet donc de créer, éditer et échanger ce type de données7. Par exemple ici8 en cliquant sur "Create a new object with this schema", il est possible de créer un nouvel objet JSON valide suivant un schéma JSON stocké dans la base.

Concernant l'application MONARC, les données utilisées par l'application sont en cours de définition 6. Cela favorisera l'échange d'information.

MONARC, sous licence AGPL v3, permet également de conduire une DPIA.

Pas dans l'immédiat. Je pourrai assez facilement faire un module générique qui permettrait de cacher des informations dans n'importe quel type de fichier. Mais ce serait avec une technique vraiment basique, qui ferait grossir la taille du fichier où se trouve le message caché.
Je préférerai avoir une approche plus spécifique, par module, en fonction des différents types de media utilisés pour cacher de l'information. Mais ça, ce n'est pas pour tout de suite.

Pourquoi pas.
Il faudrait juste que je repasse à des id relatifs aux flux pour éviter les collisions.
Mais si c'est vraiment fiable, ça vaut le coup que j'essaie. Il faut savoir que certains flux RSS sont mal formés (surtout au niveau des dates). Donc il faut que je puisse générer un id indépendemment de celui fournit par le flux, en cas de pépin.

Et il faudrait quand même extraire cet ID de la chaîne. Il y a différentes possibilités (RSS, ATOM, etc.):
https://pythonhosted.org/feedparser/reference-entry-id.html

Par contre, je pense qu'il est bien de nettoyer les adresses des articles. Notamment, je n'aime pas avoir des adresses avec feedproxy dedans.

À une époque je faisais comme tu dis. Je générai l'identifiant avec un hash sur le contenu de l'article… Et je crois même que les id des articles étaient relatifs aux flux. Mais ça ne me plaisait pas trop. Maintenant l'id est simplement une variable auto-incrémenté (non relative au flux).

Actuellement, j'utilise simplement l'adresse de l'article pour vérifier si il est déjà en base. Après avoir nettoyé l'URL. Akregator a le même problème, j'ai des doublons. Mais ça ne me choque pas du tout. Comment vraiment générer un ID qui sera unique et désigne toujours le même article?

Pour moi, c'est d'autant plus embêtant que j'utilise pratiquement toujours Tor, même avec cet agrégateur.
Ainsi je peux récupérer le même article avec différentes adresses. Exemple:
http://python-history.blogspot.[fr|de|it]/2013/11/the-history-of-bool-true-and-false.html
Ça dépend donc du noeud de sortie.

Ou, pire:
- http://feedproxy.google.com/~r/AFewThoughtsOnCryptographicEngineering/~3/kbMS_0-DeYQ/how-do-we-pay-for-privacy.html (URL dans le flux ATOM/RSS. Dégueulasse)
- http://blog.cryptographyengineering.com/2015/02/how-do-we-pay-for-privacy.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+AFewThoughtsOnCryptographicEngineering+%28A+Few+Thoughts+on+Cryptographic+Engineering%29&utm_content=FeedBurner (URL qu'on obtient après avoir fait un GET sur l'URL de flux. Horrible)

C'est pour ça que je nettoie les URL.

Et si j'active cette option l'URL sera stockée sous la forme:
http://blog.cryptographyengineering.com/2015/02/how-do-we-pay-for-privacy.html
Et là, je limite vraiment les problèmes de doublons.
Sur ma base de test, j'ai plus de 100.000 articles. Et aucun doublon (quelques uns, mais j'ai une fonction pour les détecter automatiquement. Je supprime manuellement après contrôle).

Merci pour ces bons retours!

Je suis conscient de certains problèmes. Par exemple pour les catégories. Je vais y penser. Actuellement, l'import d'un OPML ne prend volontairement pas en compte les catégories. Dans tous les cas je limiterai les catégories à un seul niveau. Ça me dérange surtout pour l'interface. Je n'aime trop les interfaces… C'est pour ça que j'aime bien Bootstrap.

Je vais donc prendre en compte tes commentaires. Déjà pour simplifier le menu principal et pour les catégories.
Concernant le menu principal, j'aime avoir pas mal de fonctionnalités accessibles via ce menu. Car l'affichage est correct sur mon smartphone (Nexus 4). Le menu de gauche est moins utilisable sur un petit écran, donc il disparaît.
Il faut donc que je trouve un compromis si je veux vraiment supprimer le menu "Filter" et "Articles".

J'ai conservé le mode mosaïque pour des raisons historique (c'était la vue de la page principale). J'ai pensé à le supprimer, mais j'aime garder la possibilité de l'utiliser.

Le menu "Filtrer" est assez inconsistant

Je suis d'accord pour le menu filtrer. C'est un peu un menu fourre-tout.
Il faudrait peut être déjà changer son nom.

En mode série si on choisit afficher par 10, comment passe t'on à la page des 10 suivantes ?

Bonne idée. En fait, je n'affiche jamais les articles 10 par 10. Je lis bcp de news. Et si j'ai bcp de retard -> "Mark all as read" ;-)

Je n'ai pas compris commenta fonctionnait la recherche

Pour le moment, tu dois indexer manuellement les articles via la page "management". J'ai désactivé l'indexation automatique des nouveaux articles pour pouvoir mieux tester le nouveau crawler. L'indexation sera appelée dès que le crawler a fini son travail.
Sur Heroku, l'indexation est désactivée. Whoosh utilise un fichier et le système de fichier sur Heroku n'est pas persistant (l'application peut changer des conteneurs…).

Ce volet pourrait aussi inclure l'ajout d'un nouveau flux plutôt que "Articles > Ajouter un flux"

J'ai peur que ce soit moins utilisable sur un smartphone. Pour l'instant l'interface est plutôt bien sur mon Nexus 4.

Je ne tiens forcément pas à faire comme la plupart des agrégateurs. Le seul que je connaisse vraiment bien, c'est akregator, avec lequel il est possible de supprimer des articles. Et je n'avais jamais utilisé celui de Google.

Personnellement, j'essaie plutôt de lire un maximum d'articles qui semblent intéressant. Si un article m'intéresse particulièrement je le marque en tant que favori.
Je le supprime surtout quand je vois que l'auteur du post à fait une erreur. Par exemple, j'ai parfois des articles en double de LinuxFr. Genre une petite différence dans le titre. Souvent quand l'auteur a fait une faute de frappe. Si mon crawler et passé avant que le titre soit corrigé, j'ai les deux versions dans ma base…

Il y a une fonction pour supprimer les anciens articles accessible via une des pages Web. Il faudrait que j'utilise cette fonction via un cron sur Heroku (il y a déjà un cron pour le crawler). J'aurai pas grand chose à changer pour faire ceci.
Car là, ma base "Hobby-dev" est en train d'exploser avec tous les comptes qui ont été créés aujourd'hui ;-)

J'ai déjà reçu une alerte d'Heroku en fin d'après-midi ;-)

La grammaire a été mise à jour dans Python 3.3. Il suffit d'installer asyncio.
Je développe 50% avec Python 3.3.2 et 50% sur Python 3.4.2.
Pour les tests de déploiement, c'est souvent sur Heroku (Python 3.4.2) ou Vagrant (actuellement Utopic server, donc Python 3.4.2).

Lorsque c'est possible, je préfère de suite faire tourner mon code avec Python 3, et des librairies standards ou même provisionnelles comme asyncio.
Et dans le cas de pyAggr3g470r, je pense qu'il n'y a pas de problème à casser la compatibilité avec Python 2. Je développe avec une Debian stable… Et pour le déploiement sur Heroku, de même, je n'ai rien eu de spécial à faire.

Pour le crawler, je voulais surtout tester asyncio et me passer de gevent. Asyncio était plus ma motivation de passer à Python 3.
Et mis à part le crawler, dans le reste du code je n'ai rien fait pour faire fonctionner l'application sous Python 3. Mon seul soucis était avec gevent (j'ai trouvé quelques "fork" de gevent pour Python 3). Donc en fait, je n'ai même pas vraiment fait de portage. Même pas avec 2to3.
Après je pourrai très bien restaurer l'ancien crawler, puis importer le bon crawler en fonction de la version de Python utilisée. Mais ça fera plus de code à maintenir.

Oui, Flask supporte très bien Python 3. Y compris toutes les extensions que j'utilise. À ce niveau, je n'ai franchement rien eu à faire.

En effet Python 3.4 ou alors 3.3 si on installe asyncio via pip.

Il est vrai que je pourrai le préciser dans la documentation.

Mais mis à part le crawler de flux, pyAggr3g470r fonctionne toujours avec Python 2.7. Tu as raison.
Et pour le crawler, on peut connecter son propre crawler avec les services web. Bien que je n'ai pas testé.

Ça fonctionne plutôt bien en fait (j'ai testé plusieurs prototypes). D'après diverses publications les performances sont aussi bonnes qu'avec IP et l'architecture bien plus simple. Évidemment je suis d'accord avec le fait que les CCN ne verront peut être jamais le jour (à très grande échelle). Mais c'est vraiment intéressant.

Il est peut être plus sensé d'utiliser GPS pour remplacer NTP (http://lists.ntp.org/pipermail/questions/2012-March/032415.html).

Pour DNS, pourquoi pas un routage basé sur le contenu (ie http://www.ict-convergence.eu/wp-content/uploads/C4.pdf) avec des CCN? Ou un peu plus simplement, Namecoin :-)

L'index n'est pas du tout mis à jour automatiquement ?

Il l'était (les articles étaient ajouté après le fetch…). Mais plus depuis qu'il est désactivé pour Heroku (je dois encore tester .

J'ai activé les issues. C'est mieux qu'ici. Merci!
Je traiterai ce problème un peu plus tard.

En fait les dépendances devraient être surtout dans un setup.py mais je ne sais pas comment on fait pour les dépendances optionnelles. Tu es intéressé par un retour sur ce point ?

C'est bon merci. Je vois globalement comment faire. Mais pour l'instant je vais laisser ça comme ça (avec le requirements.txt pour Heroku).

Je viens de tester, ça semble bien fonctionner avec SQLite. Cool.

Merci pour le retour. Je n'ai jamais testé avec SQLite depuis que j'utilise SQLAlchemy.

Le login par défaut est root@pyAggr3g470r.localhost et le mot de passe root (voir le README).

Si tu as une adresse email, je peux te créer un compte de test sur mon instance Heroku.

En effet, le requirements.txt est surtout pour Heroku. Whoosh ne peut pas vraiment y être utilisé.
Par contre sur Heroku sans psycopg2, ça plante…
En tout cas merci, je vais quand même ajouter Whoosh.

J'ai presque envie de renommer le projet là. Merci!