9:37 a.m.
Bonjour,
Je vais intégrer les CSP (content security policies) côté admin et en more
reporting pour l'instant dans mon prochain commit (et donc dans la nightly
de la nuit prochaine). Ce système, à partir de PHP 5.4, devrait produire en
cas de violation de la directive, un rapport dans le fichier texte
/admin/csp_report.txt
Pouvez-vous tester de votre côté cette prochaine nightly, jouer un peu avec
l'admin, et me retourner le contenu du fichier csp_report.txt si jamais il
était créé et pas vide ?
À noter que cette directive, si jamais elle était trop restrictive, peut
assez vite foutre en l'air une admin (et encore plus la partie publique
d'un blog), c'est la raison pour laquelle j'y vais doucement.
Si tout va bien, on gardera les CSP côté admin pour la 2.10, et je verrai
comment gérer la partie publique (largement plus complexe puisqu'on peut
intégrer des éléments de sources variées dans un blog).
Vous ne savez pas ce que sont les CSP ? Eh bien prenez 15 minutes pour
visionner ceci →
https://www.paris-web.fr/2015/conferences/csp-content-security-policy.php
À vous lire…
--
Franck — Operating Crocker’s rules (http://sl4.org/crocker.html)
12:34 p.m.
"à partir de PHP 5.4"...
Donc après PHP 5.3 annoncé comme prérequis pour Dotclear 2.9, voilà PHP 5.4 pour Dotclear
2.10... Et les utilisateurs qui n'ont pas la possibilité de changer facilement de
version PHP vont faire quoi ?
Ceci dit, je vais essayer de comprendre à quoi peut servir les CSP.
A propos, "security" et "policy" c'est-y lié au prolongement de
l'état d'urgence ou bien...? :-)
Le 20/07/2016 à 09:37, Franck Paul a écrit :
Bonjour,
Je vais intégrer les CSP (content security policies) côté admin et en more
reporting pour l'instant dans mon prochain commit (et donc dans la nightly
de la nuit prochaine). Ce système, à partir de PHP 5.4, devrait produire en
cas de violation de la directive, un rapport dans le fichier texte
/admin/csp_report.txt
Pouvez-vous tester de votre côté cette prochaine nightly, jouer un peu avec
l'admin, et me retourner le contenu du fichier csp_report.txt si jamais il
était créé et pas vide ?
À noter que cette directive, si jamais elle était trop restrictive, peut
assez vite foutre en l'air une admin (et encore plus la partie publique
d'un blog), c'est la raison pour laquelle j'y vais doucement.
Si tout va bien, on gardera les CSP côté admin pour la 2.10, et je verrai
comment gérer la partie publique (largement plus complexe puisqu'on peut
intégrer des éléments de sources variées dans un blog).
Vous ne savez pas ce que sont les CSP ? Eh bien prenez 15 minutes pour
visionner ceci →
https://www.paris-web.fr/2015/conferences/csp-content-security-policy.php
À vous lire…
2:10 p.m.
Eh bien il faudra mettre à jour PHP, même si c'est compliqué :
Depuis la sortie de PHP 5.6, la configuration est :
- branche de développement : 7.0 ;
- branches encore supportées (corrections de bugs et de la sécurité) :
5.6, 5.5 ;
- branche en obsolescence et ne recevant que des correctifs de
sécurité : 5.4 ;
- toutes les branches < 5.4 ne sont plus supportées.
Donc il est possible que la 2.10 nécessite PHP 5.4, version qui est d'ores
et déjà obsolète, et la 2.11 peut-être PHP 5.5 ou 5.6.
Quoi qu'il en soit je recommande vivement PHP 7, le gain de perf est
impressionnant ! Sinon PHP 5.6 c'est bien. Quant à la version 5.3 de PHP,
la conserver c'est s'exposer à plus ou moins brève échéance à des problèmes
de sécu.
Cf https://fr.wikipedia.org/wiki/PHP
Le 20 juillet 2016 à 12:34, mirovinben <forum(a)mirovinben.com> a écrit :
"à partir de PHP 5.4"...
Donc après PHP 5.3 annoncé comme prérequis pour Dotclear 2.9, voilà PHP
5.4 pour Dotclear 2.10... Et les utilisateurs qui n'ont pas la possibilité
de changer facilement de version PHP vont faire quoi ?
Ceci dit, je vais essayer de comprendre à quoi peut servir les CSP.
A propos, "security" et "policy" c'est-y lié au prolongement de
l'état
d'urgence ou bien...? :-)
Le 20/07/2016 à 09:37, Franck Paul a écrit :
> Bonjour,
>
> Je vais intégrer les CSP (content security policies) côté admin et en
more
> reporting pour l'instant dans mon prochain commit (et donc dans la
nightly
> de la nuit prochaine). Ce système, à partir de PHP 5.4, devrait produire
en
> cas de violation de la directive, un rapport dans le fichier texte
> /admin/csp_report.txt
>
> Pouvez-vous tester de votre côté cette prochaine nightly, jouer un peu
avec
> l'admin, et me retourner le contenu du fichier csp_report.txt si jamais
il
> était créé et pas vide ?
>
> À noter que cette directive, si jamais elle était trop restrictive, peut
> assez vite foutre en l'air une admin (et encore plus la partie publique
> d'un blog), c'est la raison pour laquelle j'y vais doucement.
>
> Si tout va bien, on gardera les CSP côté admin pour la 2.10, et je verrai
> comment gérer la partie publique (largement plus complexe puisqu'on peut
> intégrer des éléments de sources variées dans un blog).
>
> Vous ne savez pas ce que sont les CSP ? Eh bien prenez 15 minutes pour
> visionner ceci →
>
https://www.paris-web.fr/2015/conferences/csp-content-security-policy.php
>
> À vous lire…
>
--
Dev mailing list - Dev(a)list.dotclear.org -
http://ml.dotclear.org/listinfo/dev
--
Franck — Operating Crocker’s rules (http://sl4.org/crocker.html)
10:27 a.m.
Hello Franck,
Yep. Je teste ça sur mon install de test en local. Ça marche pour du
local, ou il est préférable de tester en ligne, d'ailleurs ?
Tomek
Le 20/07/2016 à 09:37, Franck Paul a écrit :
Bonjour,
Je vais intégrer les CSP (content security policies) côté admin et en more
reporting pour l'instant dans mon prochain commit (et donc dans la nightly
de la nuit prochaine). Ce système, à partir de PHP 5.4, devrait produire en
cas de violation de la directive, un rapport dans le fichier texte
/admin/csp_report.txt
Pouvez-vous tester de votre côté cette prochaine nightly, jouer un peu avec
l'admin, et me retourner le contenu du fichier csp_report.txt si jamais il
était créé et pas vide ?
À noter que cette directive, si jamais elle était trop restrictive, peut
assez vite foutre en l'air une admin (et encore plus la partie publique
d'un blog), c'est la raison pour laquelle j'y vais doucement.
Si tout va bien, on gardera les CSP côté admin pour la 2.10, et je verrai
comment gérer la partie publique (largement plus complexe puisqu'on peut
intégrer des éléments de sources variées dans un blog).
Vous ne savez pas ce que sont les CSP ? Eh bien prenez 15 minutes pour
visionner ceci →
https://www.paris-web.fr/2015/conferences/csp-content-security-policy.php
À vous lire…
12:49 p.m.
Peu importe pour l'endroit, c'est actif dans tous les cas.
Sinon les miniatures des thèmes de DA ne sont pas affichées (en tout cas
jusqu'à la prochaine nightly), Annie Strohem vient de me signaler le pb et
je viens de corriger ça.
Merci pour les tests
Le 21 juillet 2016 à 10:27, Franck L <franck.lafay(a)sfr.fr> a écrit :
Hello Franck,
Yep. Je teste ça sur mon install de test en local. Ça marche pour du
local, ou il est préférable de tester en ligne, d'ailleurs ?
Tomek
Le 20/07/2016 à 09:37, Franck Paul a écrit :
> Bonjour,
>
> Je vais intégrer les CSP (content security policies) côté admin et en more
> reporting pour l'instant dans mon prochain commit (et donc dans la nightly
> de la nuit prochaine). Ce système, à partir de PHP 5.4, devrait produire
> en
> cas de violation de la directive, un rapport dans le fichier texte
> /admin/csp_report.txt
>
> Pouvez-vous tester de votre côté cette prochaine nightly, jouer un peu
> avec
> l'admin, et me retourner le contenu du fichier csp_report.txt si jamais il
> était créé et pas vide ?
>
> À noter que cette directive, si jamais elle était trop restrictive, peut
> assez vite foutre en l'air une admin (et encore plus la partie publique
> d'un blog), c'est la raison pour laquelle j'y vais doucement.
>
> Si tout va bien, on gardera les CSP côté admin pour la 2.10, et je verrai
> comment gérer la partie publique (largement plus complexe puisqu'on peut
> intégrer des éléments de sources variées dans un blog).
>
> Vous ne savez pas ce que sont les CSP ? Eh bien prenez 15 minutes pour
> visionner ceci →
> https://www.paris-web.fr/2015/conferences/csp-content-security-policy.php
>
> À vous lire…
>
>
--
Dev mailing list - Dev(a)list.dotclear.org -
http://ml.dotclear.org/listinfo/dev
--
Franck — Operating Crocker’s rules (http://sl4.org/crocker.html)
2:03 p.m.
En effet, j'ai testé et vu les effets, avec une simple histoire de
config d'url qui n'était pas bonne pour la prévisualisation.
Je n'avais pas vu pour les thèmes.
Le 21/07/2016 à 12:49, Franck Paul a écrit :
Peu importe pour l'endroit, c'est actif dans tous les cas.
Sinon les miniatures des thèmes de DA ne sont pas affichées (en tout cas
jusqu'à la prochaine nightly), Annie Strohem vient de me signaler le pb et
je viens de corriger ça.
Merci pour les tests
Le 21 juillet 2016 à 10:27, Franck L <franck.lafay(a)sfr.fr> a écrit :
> Hello Franck,
>
> Yep. Je teste ça sur mon install de test en local. Ça marche pour du
> local, ou il est préférable de tester en ligne, d'ailleurs ?
>
> Tomek
>
> Le 20/07/2016 à 09:37, Franck Paul a écrit :
>
>> Bonjour,
>>
>> Je vais intégrer les CSP (content security policies) côté admin et en more
>> reporting pour l'instant dans mon prochain commit (et donc dans la nightly
>> de la nuit prochaine). Ce système, à partir de PHP 5.4, devrait produire
>> en
>> cas de violation de la directive, un rapport dans le fichier texte
>> /admin/csp_report.txt
>>
>> Pouvez-vous tester de votre côté cette prochaine nightly, jouer un peu
>> avec
>> l'admin, et me retourner le contenu du fichier csp_report.txt si jamais il
>> était créé et pas vide ?
>>
>> À noter que cette directive, si jamais elle était trop restrictive, peut
>> assez vite foutre en l'air une admin (et encore plus la partie publique
>> d'un blog), c'est la raison pour laquelle j'y vais doucement.
>>
>> Si tout va bien, on gardera les CSP côté admin pour la 2.10, et je verrai
>> comment gérer la partie publique (largement plus complexe puisqu'on peut
>> intégrer des éléments de sources variées dans un blog).
>>
>> Vous ne savez pas ce que sont les CSP ? Eh bien prenez 15 minutes pour
>> visionner ceci →
>> https://www.paris-web.fr/2015/conferences/csp-content-security-policy.php
>>
>> À vous lire…
>>
>>
> --
> Dev mailing list - Dev(a)list.dotclear.org -
> http://ml.dotclear.org/listinfo/dev
>
2:41 p.m.
Avec les navigateurs qui prennent en compte les CSP (cf →
http://caniuse.com/#feat=contentsecuritypolicy) , ça peut verrouiller
encore mieux côté sécu, en tout cas pour l'admin et c'est pas plus mal.
Le 21 juillet 2016 à 14:03, Franck L <franck.lafay(a)sfr.fr> a écrit :
En effet, j'ai testé et vu les effets, avec une simple histoire
de config
d'url qui n'était pas bonne pour la prévisualisation.
Je n'avais pas vu pour les thèmes.
Le 21/07/2016 à 12:49, Franck Paul a écrit :
> Peu importe pour l'endroit, c'est actif dans tous les cas.
>
> Sinon les miniatures des thèmes de DA ne sont pas affichées (en tout cas
> jusqu'à la prochaine nightly), Annie Strohem vient de me signaler le pb et
> je viens de corriger ça.
>
> Merci pour les tests
>
> Le 21 juillet 2016 à 10:27, Franck L <franck.lafay(a)sfr.fr> a écrit :
>
> Hello Franck,
>>
>> Yep. Je teste ça sur mon install de test en local. Ça marche pour du
>> local, ou il est préférable de tester en ligne, d'ailleurs ?
>>
>> Tomek
>>
>> Le 20/07/2016 à 09:37, Franck Paul a écrit :
>>
>> Bonjour,
>>>
>>> Je vais intégrer les CSP (content security policies) côté admin et en
>>> more
>>> reporting pour l'instant dans mon prochain commit (et donc dans la
>>> nightly
>>> de la nuit prochaine). Ce système, à partir de PHP 5.4, devrait produire
>>> en
>>> cas de violation de la directive, un rapport dans le fichier texte
>>> /admin/csp_report.txt
>>>
>>> Pouvez-vous tester de votre côté cette prochaine nightly, jouer un peu
>>> avec
>>> l'admin, et me retourner le contenu du fichier csp_report.txt si jamais
>>> il
>>> était créé et pas vide ?
>>>
>>> À noter que cette directive, si jamais elle était trop restrictive, peut
>>> assez vite foutre en l'air une admin (et encore plus la partie publique
>>> d'un blog), c'est la raison pour laquelle j'y vais doucement.
>>>
>>> Si tout va bien, on gardera les CSP côté admin pour la 2.10, et je
>>> verrai
>>> comment gérer la partie publique (largement plus complexe puisqu'on peut
>>> intégrer des éléments de sources variées dans un blog).
>>>
>>> Vous ne savez pas ce que sont les CSP ? Eh bien prenez 15 minutes pour
>>> visionner ceci →
>>>
>>> https://www.paris-web.fr/2015/conferences/csp-content-security-policy.php
>>>
>>> À vous lire…
>>>
>>>
>>> --
>> Dev mailing list - Dev(a)list.dotclear.org -
>> http://ml.dotclear.org/listinfo/dev
>>
>>
>
>
--
Dev mailing list - Dev(a)list.dotclear.org -
http://ml.dotclear.org/listinfo/dev
--
Franck — Operating Crocker’s rules (http://sl4.org/crocker.html)
1:03 p.m.
Toujours pas de csp_report.txt rempli les gens ? (à part Annie Thomas qui
m'a fourni le sien le premier jour ce qui m'a permis de régler un pb).
Le 21 juillet 2016 à 14:41, Franck Paul <carnet.franck.paul(a)gmail.com> a
écrit :
Avec les navigateurs qui prennent en compte les CSP (cf →
http://caniuse.com/#feat=contentsecuritypolicy) , ça peut verrouiller
encore mieux côté sécu, en tout cas pour l'admin et c'est pas plus mal.
Le 21 juillet 2016 à 14:03, Franck L <franck.lafay(a)sfr.fr> a écrit :
> En effet, j'ai testé et vu les effets, avec une simple histoire de config
> d'url qui n'était pas bonne pour la prévisualisation.
>
> Je n'avais pas vu pour les thèmes.
>
>
> Le 21/07/2016 à 12:49, Franck Paul a écrit :
>
>> Peu importe pour l'endroit, c'est actif dans tous les cas.
>>
>> Sinon les miniatures des thèmes de DA ne sont pas affichées (en tout cas
>> jusqu'à la prochaine nightly), Annie Strohem vient de me signaler le pb
>> et
>> je viens de corriger ça.
>>
>> Merci pour les tests
>>
>> Le 21 juillet 2016 à 10:27, Franck L <franck.lafay(a)sfr.fr> a écrit :
>>
>> Hello Franck,
>>>
>>> Yep. Je teste ça sur mon install de test en local. Ça marche pour du
>>> local, ou il est préférable de tester en ligne, d'ailleurs ?
>>>
>>> Tomek
>>>
>>> Le 20/07/2016 à 09:37, Franck Paul a écrit :
>>>
>>> Bonjour,
>>>>
>>>> Je vais intégrer les CSP (content security policies) côté admin et en
>>>> more
>>>> reporting pour l'instant dans mon prochain commit (et donc dans la
>>>> nightly
>>>> de la nuit prochaine). Ce système, à partir de PHP 5.4, devrait
>>>> produire
>>>> en
>>>> cas de violation de la directive, un rapport dans le fichier texte
>>>> /admin/csp_report.txt
>>>>
>>>> Pouvez-vous tester de votre côté cette prochaine nightly, jouer un peu
>>>> avec
>>>> l'admin, et me retourner le contenu du fichier csp_report.txt si
>>>> jamais il
>>>> était créé et pas vide ?
>>>>
>>>> À noter que cette directive, si jamais elle était trop restrictive,
>>>> peut
>>>> assez vite foutre en l'air une admin (et encore plus la partie
publique
>>>> d'un blog), c'est la raison pour laquelle j'y vais
doucement.
>>>>
>>>> Si tout va bien, on gardera les CSP côté admin pour la 2.10, et je
>>>> verrai
>>>> comment gérer la partie publique (largement plus complexe puisqu'on
>>>> peut
>>>> intégrer des éléments de sources variées dans un blog).
>>>>
>>>> Vous ne savez pas ce que sont les CSP ? Eh bien prenez 15 minutes pour
>>>> visionner ceci →
>>>>
>>>>
https://www.paris-web.fr/2015/conferences/csp-content-security-policy.php
>>>>
>>>> À vous lire…
>>>>
>>>>
>>>> --
>>> Dev mailing list - Dev(a)list.dotclear.org -
>>> http://ml.dotclear.org/listinfo/dev
>>>
>>>
>>
>>
> --
> Dev mailing list - Dev(a)list.dotclear.org -
> http://ml.dotclear.org/listinfo/dev
>
--
Franck — Operating Crocker’s rules (http://sl4.org/crocker.html)
--
Franck — Operating Crocker’s rules (http://sl4.org/crocker.html)
1:04 p.m.
oups, spa Annie Thomas, c'est une autre Annie, mais je l'ai reçu et pris en
compte tout de même :-p
Le 23 juillet 2016 à 13:03, Franck Paul <carnet.franck.paul(a)gmail.com> a
écrit :
Toujours pas de csp_report.txt rempli les gens ? (à part Annie Thomas
qui
m'a fourni le sien le premier jour ce qui m'a permis de régler un pb).
Le 21 juillet 2016 à 14:41, Franck Paul <carnet.franck.paul(a)gmail.com> a
écrit :
> Avec les navigateurs qui prennent en compte les CSP (cf →
> http://caniuse.com/#feat=contentsecuritypolicy) , ça peut verrouiller
> encore mieux côté sécu, en tout cas pour l'admin et c'est pas plus mal.
>
> Le 21 juillet 2016 à 14:03, Franck L <franck.lafay(a)sfr.fr> a écrit :
>
>> En effet, j'ai testé et vu les effets, avec une simple histoire de
>> config d'url qui n'était pas bonne pour la prévisualisation.
>>
>> Je n'avais pas vu pour les thèmes.
>>
>>
>> Le 21/07/2016 à 12:49, Franck Paul a écrit :
>>
>>> Peu importe pour l'endroit, c'est actif dans tous les cas.
>>>
>>> Sinon les miniatures des thèmes de DA ne sont pas affichées (en tout cas
>>> jusqu'à la prochaine nightly), Annie Strohem vient de me signaler le pb
>>> et
>>> je viens de corriger ça.
>>>
>>> Merci pour les tests
>>>
>>> Le 21 juillet 2016 à 10:27, Franck L <franck.lafay(a)sfr.fr> a écrit :
>>>
>>> Hello Franck,
>>>>
>>>> Yep. Je teste ça sur mon install de test en local. Ça marche pour du
>>>> local, ou il est préférable de tester en ligne, d'ailleurs ?
>>>>
>>>> Tomek
>>>>
>>>> Le 20/07/2016 à 09:37, Franck Paul a écrit :
>>>>
>>>> Bonjour,
>>>>>
>>>>> Je vais intégrer les CSP (content security policies) côté admin et
en
>>>>> more
>>>>> reporting pour l'instant dans mon prochain commit (et donc dans
la
>>>>> nightly
>>>>> de la nuit prochaine). Ce système, à partir de PHP 5.4, devrait
>>>>> produire
>>>>> en
>>>>> cas de violation de la directive, un rapport dans le fichier texte
>>>>> /admin/csp_report.txt
>>>>>
>>>>> Pouvez-vous tester de votre côté cette prochaine nightly, jouer un
peu
>>>>> avec
>>>>> l'admin, et me retourner le contenu du fichier csp_report.txt si
>>>>> jamais il
>>>>> était créé et pas vide ?
>>>>>
>>>>> À noter que cette directive, si jamais elle était trop restrictive,
>>>>> peut
>>>>> assez vite foutre en l'air une admin (et encore plus la partie
>>>>> publique
>>>>> d'un blog), c'est la raison pour laquelle j'y vais
doucement.
>>>>>
>>>>> Si tout va bien, on gardera les CSP côté admin pour la 2.10, et je
>>>>> verrai
>>>>> comment gérer la partie publique (largement plus complexe
puisqu'on
>>>>> peut
>>>>> intégrer des éléments de sources variées dans un blog).
>>>>>
>>>>> Vous ne savez pas ce que sont les CSP ? Eh bien prenez 15 minutes
pour
>>>>> visionner ceci →
>>>>>
>>>>>
https://www.paris-web.fr/2015/conferences/csp-content-security-policy.php
>>>>>
>>>>> À vous lire…
>>>>>
>>>>>
>>>>> --
>>>> Dev mailing list - Dev(a)list.dotclear.org -
>>>> http://ml.dotclear.org/listinfo/dev
>>>>
>>>>
>>>
>>>
>> --
>> Dev mailing list - Dev(a)list.dotclear.org -
>> http://ml.dotclear.org/listinfo/dev
>>
>
>
>
> --
>
> Franck — Operating Crocker’s rules (http://sl4.org/crocker.html)
>
--
Franck — Operating Crocker’s rules (http://sl4.org/crocker.html)
--
Franck — Operating Crocker’s rules (http://sl4.org/crocker.html)
2:51 p.m.
Je pence que ce service devrait être optionnel ( sous forme de module
activable/désactivable ) et non intégré en dur dans le code.
Message du 20/07/16 09:38
De : "Franck Paul"
A : "dev(a)list.dotclear.org"
Copie à :
Objet : [Dotclear Dev] CSP côté admin
Bonjour, Je vais intégrer les CSP (content security policies) côté admin et en more
reporting pour l'instant dans mon prochain commit (et donc dans la nightly de la nuit
prochaine). Ce système, à partir de PHP 5.4, devrait produire en cas de violation de la
directive, un rapport dans le fichier texte /admin/csp_report.txt Pouvez-vous tester de
votre côté cette prochaine nightly, jouer un peu avec l'admin, et me retourner le
contenu du fichier csp_report.txt si jamais il était créé et pas vide ? À noter que cette
directive, si jamais elle était trop restrictive, peut assez vite foutre en l'air une
admin (et encore plus la partie publique d'un blog), c'est la raison pour laquelle
j'y vais doucement. Si tout va bien, on gardera les CSP côté admin pour la 2.10, et je
verrai comment gérer la partie publique (largement plus complexe puisqu'on peut
intégrer des éléments de sources variées dans un blog). Vous ne savez pas ce que sont les
CSP ? Eh bien prenez 15 minutes pour visionner ceci →
https://www.paris-web.fr/2015/conferences/csp-content-security-policy.php À vous lire… --
Franck — Operating Crocker’s rules (http://sl4.org/crocker.html) -- Dev mailing list -
Dev(a)list.dotclear.org - http://ml.dotclear.org/listinfo/dev
7:42 p.m.
Côté admin, je pense qu'on peut l'imposer. Par contre c'est côté public ou
il faudra permettre un réglage beaucoup plus fin ; mais j'ai mon idée à ce
sujet.
Le 23 juillet 2016 à 14:51, Benoit GRELIER <adjaya2(a)orange.fr> a écrit :
Je pence que ce service devrait être optionnel ( sous forme de
module
activable/désactivable ) et non intégré en dur dans le code.
> Message du 20/07/16 09:38
> De : "Franck Paul"
> A : "dev(a)list.dotclear.org"
> Copie à :
> Objet : [Dotclear Dev] CSP côté admin
>
> Bonjour, Je vais intégrer les CSP (content security policies) côté admin
et en more reporting pour l'instant dans mon prochain commit (et donc dans
la nightly de la nuit prochaine). Ce système, à partir de PHP 5.4, devrait
produire en cas de violation de la directive, un rapport dans le fichier
texte /admin/csp_report.txt Pouvez-vous tester de votre côté cette
prochaine nightly, jouer un peu avec l'admin, et me retourner le contenu du
fichier csp_report.txt si jamais il était créé et pas vide ? À noter que
cette directive, si jamais elle était trop restrictive, peut assez vite
foutre en l'air une admin (et encore plus la partie publique d'un blog),
c'est la raison pour laquelle j'y vais doucement. Si tout va bien, on
gardera les CSP côté admin pour la 2.10, et je verrai comment gérer la
partie publique (largement plus complexe puisqu'on peut intégrer des
éléments de sources variées dans un blog). Vous ne savez pas ce que sont
les CSP ? Eh bien prenez 15 minutes pour visionner ceci →
https://www.paris-web.fr/2015/conferences/csp-content-security-policy.php
À vous lire… -- Franck — Operating Crocker’s rules (
http://sl4.org/crocker.html) -- Dev mailing list - Dev(a)list.dotclear.org
- http://ml.dotclear.org/listinfo/dev
--
Dev mailing list - Dev(a)list.dotclear.org -
http://ml.dotclear.org/listinfo/dev
--
Franck — Operating Crocker’s rules (http://sl4.org/crocker.html)
8 a.m.
Je n'ai pas trop le loisir de tester actuellement, mais après quelques lecture sur le
sujet ( très technique pour mon niveau de compréhension, par exemple :
https://hacks.mozilla.org/2016/02/implementing-content-security-policy/ ) je retiens
que:
_Il y a encore des bugs,
_l’implémentation n'est pas simple et demande du temps.
_Ce peut-être effectivement un bon outils de contrôle pour la phase de dev d'une
application et inciter à de bonnes pratiques.
Coté admin pour dotclear, le fait d'ajout de plugins tiers plus ou moins bien conçu
ne risque-t-il pas de tout casser à l'affichage?
Benoit.
Message du 23/07/16 19:43
De : "Franck Paul"
A : "dev(a)list.dotclear.org"
Copie à :
Objet : Re: [Dotclear Dev] CSP côté admin
Côté admin, je pense qu'on peut l'imposer. Par contre c'est côté public ou il
faudra permettre un réglage beaucoup plus fin ; mais j'ai mon idée à ce sujet. Le 23
juillet 2016 à 14:51, Benoit GRELIER a écrit : > Je pence que ce service devrait être
optionnel ( sous forme de module > activable/désactivable ) et non intégré en dur dans
le code. > > > > > >
2:55 p.m.
Plop les gens,
Alors effectivement des plugins tiers peuvent s'inviter et nécessiter un
accès à des ressources externes, exemple mygmaps (merci Gvx pour le
rapport).
Du coup j'ai implémenté des réglages qui permettent de désactiver les CSP
côté admin et de compléter si besoin les directives (default, script, style
et img). Si vous avez des domaines à ajouter (ex : maps.googleapis.com
utilisé par le plugin mygmaps), ajoutez-les à la directive correspondance
(séparez chaque domaine par une espace).
En place dans la nightly de ce soir.
Le 24 juillet 2016 à 08:00, Benoit GRELIER <adjaya2(a)orange.fr> a écrit :
Je n'ai pas trop le loisir de tester actuellement, mais après
quelques
lecture sur le sujet ( très technique pour mon niveau de compréhension, par
exemple :
https://hacks.mozilla.org/2016/02/implementing-content-security-policy/
) je retiens que:
_Il y a encore des bugs,
_l’implémentation n'est pas simple et demande du temps.
_Ce peut-être effectivement un bon outils de contrôle pour la phase de dev
d'une application et inciter à de bonnes pratiques.
Coté admin pour dotclear, le fait d'ajout de plugins tiers plus ou moins
bien conçu ne risque-t-il pas de tout casser à l'affichage?
Benoit.
> Message du 23/07/16 19:43
> De : "Franck Paul"
> A : "dev(a)list.dotclear.org"
> Copie à :
> Objet : Re: [Dotclear Dev] CSP côté admin
>
> Côté admin, je pense qu'on peut l'imposer. Par contre c'est côté public
ou il faudra permettre un réglage beaucoup plus fin ; mais j'ai mon idée à
ce sujet. Le 23 juillet 2016 à 14:51, Benoit GRELIER a écrit : > Je pence
que ce service devrait être optionnel ( sous forme de module >
activable/désactivable ) et non intégré en dur dans le code. > > > > >
>
--
Dev mailing list - Dev(a)list.dotclear.org -
http://ml.dotclear.org/listinfo/dev
--
Franck — Operating Crocker’s rules (http://sl4.org/crocker.html)
3:03 p.m.
Sinon et pour répondre à Benoit, j'ai choisi des directives pas trop
fermées (au détriment du risque) :
Les scripts JS inline et l'eval sont autorisés
Idem pour les styles CSS inline
Ça vaudra peut-être le coup de donner un coup de tournevis en allant à la
chasse aux scripts et style inline et d'évaluer si l'eval JS peut être
interdit. Cela dit, maintenant qu'on a accès aux différentes directives,
tout le monde peut les modifier et faire les tests idoines. Vos rapports
seront utiles pour affiner ça.
Merci
Le 24 juillet 2016 à 08:00, Benoit GRELIER <adjaya2(a)orange.fr> a écrit :
Je n'ai pas trop le loisir de tester actuellement, mais après
quelques
lecture sur le sujet ( très technique pour mon niveau de compréhension, par
exemple :
https://hacks.mozilla.org/2016/02/implementing-content-security-policy/
) je retiens que:
_Il y a encore des bugs,
_l’implémentation n'est pas simple et demande du temps.
_Ce peut-être effectivement un bon outils de contrôle pour la phase de dev
d'une application et inciter à de bonnes pratiques.
Coté admin pour dotclear, le fait d'ajout de plugins tiers plus ou moins
bien conçu ne risque-t-il pas de tout casser à l'affichage?
Benoit.
> Message du 23/07/16 19:43
> De : "Franck Paul"
> A : "dev(a)list.dotclear.org"
> Copie à :
> Objet : Re: [Dotclear Dev] CSP côté admin
>
> Côté admin, je pense qu'on peut l'imposer. Par contre c'est côté public
ou il faudra permettre un réglage beaucoup plus fin ; mais j'ai mon idée à
ce sujet. Le 23 juillet 2016 à 14:51, Benoit GRELIER a écrit : > Je pence
que ce service devrait être optionnel ( sous forme de module >
activable/désactivable ) et non intégré en dur dans le code. > > > > >
>
--
Dev mailing list - Dev(a)list.dotclear.org -
http://ml.dotclear.org/listinfo/dev
--
Franck — Operating Crocker’s rules (http://sl4.org/crocker.html)
11:29 a.m.
Plop tout le monde,
Je viens de reprendre un peu le code pour offrir aux plugins tiers
l'opportunité d'intégrer leur complément de directive CSP (behavior
adminPageHTTPHeaderCSP).
Il y aura donc 2 moyen de les régler : about:config et 1 behavior pour les
plugins qui le prendront en compte.
j'ai aussi ajouté un behavior plus générique qui permet d'intervenir sur
toutes les entêtes HTP envoyées avant l'affichage d'une page de l'admin
(behavior adminPageHTTPHeaders).
Avec ça on devrait pouvoir faire ce qu'on veut côté admin.
Côté public, je pense que je vais attendre un peu de retour en "prod" avec
la 2.10 et implémenter ça pour la 2.11.
Le 24 juillet 2016 à 15:03, Franck Paul <carnet.franck.paul(a)gmail.com> a
écrit :
Sinon et pour répondre à Benoit, j'ai choisi des directives pas
trop
fermées (au détriment du risque) :
Les scripts JS inline et l'eval sont autorisés
Idem pour les styles CSS inline
Ça vaudra peut-être le coup de donner un coup de tournevis en allant à la
chasse aux scripts et style inline et d'évaluer si l'eval JS peut être
interdit. Cela dit, maintenant qu'on a accès aux différentes directives,
tout le monde peut les modifier et faire les tests idoines. Vos rapports
seront utiles pour affiner ça.
Merci
Le 24 juillet 2016 à 08:00, Benoit GRELIER <adjaya2(a)orange.fr> a écrit :
> Je n'ai pas trop le loisir de tester actuellement, mais après quelques
> lecture sur le sujet ( très technique pour mon niveau de compréhension, par
> exemple :
> https://hacks.mozilla.org/2016/02/implementing-content-security-policy/
> ) je retiens que:
>
> _Il y a encore des bugs,
>
> _l’implémentation n'est pas simple et demande du temps.
>
> _Ce peut-être effectivement un bon outils de contrôle pour la phase de
> dev d'une application et inciter à de bonnes pratiques.
>
>
>
> Coté admin pour dotclear, le fait d'ajout de plugins tiers plus ou moins
> bien conçu ne risque-t-il pas de tout casser à l'affichage?
>
> Benoit.
>
>
>
>
>
> > Message du 23/07/16 19:43
> > De : "Franck Paul"
> > A : "dev(a)list.dotclear.org"
> > Copie à :
> > Objet : Re: [Dotclear Dev] CSP côté admin
> >
> > Côté admin, je pense qu'on peut l'imposer. Par contre c'est côté
public
> ou il faudra permettre un réglage beaucoup plus fin ; mais j'ai mon idée à
> ce sujet. Le 23 juillet 2016 à 14:51, Benoit GRELIER a écrit : > Je pence
> que ce service devrait être optionnel ( sous forme de module >
> activable/désactivable ) et non intégré en dur dans le code. > > > > >
>
> --
> Dev mailing list - Dev(a)list.dotclear.org -
> http://ml.dotclear.org/listinfo/dev
>
--
Franck — Operating Crocker’s rules (http://sl4.org/crocker.html)
--
Franck — Operating Crocker’s rules (http://sl4.org/crocker.html)
5:50 p.m.
Le 25 juillet 2016 à 11:29, Franck Paul <carnet.franck.paul(a)gmail.com> a écrit :
Je viens de reprendre un peu le code pour offrir aux plugins tiers
l'opportunité d'intégrer leur complément de directive CSP (behavior
adminPageHTTPHeaderCSP).
Il y aura donc 2 moyen de les régler : about:config et 1 behavior pour les
plugins qui le prendront en compte.
Je serais bien intéressé par un exemple pour le plugin mygmaps ;)
--
Philippe
10:13 p.m.
Yep Philippe, je te fais ça demain.
Le 25 juillet 2016 à 17:50, Philippe <philippe(a)dissitou.org> a écrit :
Le 25 juillet 2016 à 11:29, Franck Paul
<carnet.franck.paul(a)gmail.com> a
écrit :
> Je viens de reprendre un peu le code pour offrir aux plugins tiers
> l'opportunité d'intégrer leur complément de directive CSP (behavior
> adminPageHTTPHeaderCSP).
> Il y aura donc 2 moyen de les régler : about:config et 1 behavior pour
les
> plugins qui le prendront en compte.
Je serais bien intéressé par un exemple pour le plugin mygmaps ;)
--
Philippe
--
Dev mailing list - Dev(a)list.dotclear.org -
http://ml.dotclear.org/listinfo/dev
--
Franck — Operating Crocker’s rules (http://sl4.org/crocker.html)
8:26 a.m.
Philippe, poyr mygmaps, dans _admin.php, quelque chose comme :
$core->addBehavior('adminPageHTTPHeaderCSP',array('myAdminBehaviors','adminPageHTTPHeaderCSP'));
class myAdminBehaviors
{
public static function adminPageHTMLHead($csp)
{
if (isset($csp['script-src'])) {
$csp['script-src'] .= ' maps.googleapis.com';
} else {
$csp['script-src'] = 'maps.googleapis.com';
}
}
}
devrait faire l'affaire.
Le 25 juillet 2016 à 17:50, Philippe <philippe(a)dissitou.org> a écrit :
Le 25 juillet 2016 à 11:29, Franck Paul
<carnet.franck.paul(a)gmail.com> a
écrit :
> Je viens de reprendre un peu le code pour offrir aux plugins tiers
> l'opportunité d'intégrer leur complément de directive CSP (behavior
> adminPageHTTPHeaderCSP).
> Il y aura donc 2 moyen de les régler : about:config et 1 behavior pour
les
> plugins qui le prendront en compte.
Je serais bien intéressé par un exemple pour le plugin mygmaps ;)
--
Philippe
--
Dev mailing list - Dev(a)list.dotclear.org -
http://ml.dotclear.org/listinfo/dev
--
Franck — Operating Crocker’s rules (http://sl4.org/crocker.html)
10:21 a.m.
Merci
Avec ton code, l'API est bien chargée, mais pour faire tout
fonctionner il m'a fallu en rajouter pas mal ! En effet il y a des tas
de serveurs d'images et de scripts chez Google : le lecteur de
fichiers kml, Street View, les tuiles de cartes, les icônes, etc.
Plus les tuiles pour les cartes OpenStreetMap
Pour l'instant, je ne suis pas encore sûr d'avoir tout, et il me
faudra probablement surveiller si les serveurs changent (et comment
?), mais voici la fonction
public static function adminPageHTTPHeaderCSP($csp)
{
if (isset($csp['default-src'])) {
$csp['default-src'] .= ' fonts.gstatic.com';
} else {
$csp['default-src'] = 'fonts.gstatic.com';
}
if (isset($csp['script-src'])) {
$csp['script-src'] .= ' maps.googleapis.com';
} else {
$csp['script-src'] = 'maps.googleapis.com';
}
if (isset($csp['img-src'])) {
$csp['img-src'] .= ' maps.gstatic.com maps.googleapis.com
csi.gstatic.com khms0.googleapis.com khms1.googleapis.com
mts0.googleapis.com mts1.googleapis.com cbks0.googleapis.com
cbks1.googleapis.com tile.openstreetmap.org';
} else {
$csp['img-src'] = 'maps.gstatic.com maps.googleapis.com
csi.gstatic.com khms0.googleapis.com khms1.googleapis.com
mts0.googleapis.com mts1.googleapis.com cbks0.googleapis.com
cbks1.googleapis.com tile.openstreetmap.org';
}
if (isset($csp['style-src'])) {
$csp['style-src'] .= ' fonts.googleapis.com';
} else {
$csp['style-src'] = 'fonts.googleapis.com';
}
}
Ça ne fait pas un peu beaucoup ?
:D
--
Philippe
Le 26 juillet 2016 à 08:26, Franck Paul <carnet.franck.paul(a)gmail.com> a écrit :
Philippe, poyr mygmaps, dans _admin.php, quelque chose comme :
$core->addBehavior('adminPageHTTPHeaderCSP',array('myAdminBehaviors','adminPageHTTPHeaderCSP'));
class myAdminBehaviors
{
public static function adminPageHTMLHead($csp)
{
if (isset($csp['script-src'])) {
$csp['script-src'] .= ' maps.googleapis.com';
} else {
$csp['script-src'] = 'maps.googleapis.com';
}
}
}
devrait faire l'affaire.
Le 25 juillet 2016 à 17:50, Philippe <philippe(a)dissitou.org> a écrit :
> Le 25 juillet 2016 à 11:29, Franck Paul <carnet.franck.paul(a)gmail.com> a
> écrit :
>
> > Je viens de reprendre un peu le code pour offrir aux plugins tiers
> > l'opportunité d'intégrer leur complément de directive CSP (behavior
> > adminPageHTTPHeaderCSP).
> > Il y aura donc 2 moyen de les régler : about:config et 1 behavior pour
> les
> > plugins qui le prendront en compte.
>
> Je serais bien intéressé par un exemple pour le plugin mygmaps ;)
>
>
> --
> Philippe
> --
> Dev mailing list - Dev(a)list.dotclear.org -
> http://ml.dotclear.org/listinfo/dev
>
--
Franck — Operating Crocker’s rules (http://sl4.org/crocker.html)
--
Dev mailing list - Dev(a)list.dotclear.org - http://ml.dotclear.org/listinfo/dev
10:28 a.m.
Beaucoup oui, quoique comparé à la taille totale d'une page d'admin, ça ne
doit pas peser bien lourd dans les échanges avec le serveur.
Maintenant c'est aussi le prix à payer pour avoir une admin à peu près
sécurisée.
Quoi qu'il en soit, on peut aussi décider d'ici la sortie de la 2.10 de ne
pas activer par défaut les CSP. J'attends de faire le bilan de tous vos
retours pour décider.
2016-07-26 10:21 GMT+02:00 Philippe <philippe(a)dissitou.org>:
Merci
Avec ton code, l'API est bien chargée, mais pour faire tout
fonctionner il m'a fallu en rajouter pas mal ! En effet il y a des tas
de serveurs d'images et de scripts chez Google : le lecteur de
fichiers kml, Street View, les tuiles de cartes, les icônes, etc.
Plus les tuiles pour les cartes OpenStreetMap
Pour l'instant, je ne suis pas encore sûr d'avoir tout, et il me
faudra probablement surveiller si les serveurs changent (et comment
?), mais voici la fonction
public static function adminPageHTTPHeaderCSP($csp)
{
if (isset($csp['default-src'])) {
$csp['default-src'] .= ' fonts.gstatic.com';
} else {
$csp['default-src'] = 'fonts.gstatic.com';
}
if (isset($csp['script-src'])) {
$csp['script-src'] .= ' maps.googleapis.com';
} else {
$csp['script-src'] = 'maps.googleapis.com';
}
if (isset($csp['img-src'])) {
$csp['img-src'] .= ' maps.gstatic.com maps.googleapis.com
csi.gstatic.com khms0.googleapis.com khms1.googleapis.com
mts0.googleapis.com mts1.googleapis.com cbks0.googleapis.com
cbks1.googleapis.com tile.openstreetmap.org';
} else {
$csp['img-src'] = 'maps.gstatic.com maps.googleapis.com
csi.gstatic.com khms0.googleapis.com khms1.googleapis.com
mts0.googleapis.com mts1.googleapis.com cbks0.googleapis.com
cbks1.googleapis.com tile.openstreetmap.org';
}
if (isset($csp['style-src'])) {
$csp['style-src'] .= ' fonts.googleapis.com';
} else {
$csp['style-src'] = 'fonts.googleapis.com';
}
}
Ça ne fait pas un peu beaucoup ?
:D
--
Philippe
Le 26 juillet 2016 à 08:26, Franck Paul <carnet.franck.paul(a)gmail.com> a
écrit :
> Philippe, poyr mygmaps, dans _admin.php, quelque chose comme :
>
>
$core->addBehavior('adminPageHTTPHeaderCSP',array('myAdminBehaviors','adminPageHTTPHeaderCSP'));
>
> class myAdminBehaviors
> {
> public static function adminPageHTMLHead($csp)
> {
> if (isset($csp['script-src'])) {
> $csp['script-src'] .= ' maps.googleapis.com';
> } else {
> $csp['script-src'] = 'maps.googleapis.com';
> }
> }
> }
>
> devrait faire l'affaire.
>
> Le 25 juillet 2016 à 17:50, Philippe <philippe(a)dissitou.org> a écrit :
>
>> Le 25 juillet 2016 à 11:29, Franck Paul <carnet.franck.paul(a)gmail.com>
a
>> écrit :
>>
>> > Je viens de reprendre un peu le code pour offrir aux plugins tiers
>> > l'opportunité d'intégrer leur complément de directive CSP
(behavior
>> > adminPageHTTPHeaderCSP).
>> > Il y aura donc 2 moyen de les régler : about:config et 1 behavior pour
>> les
>> > plugins qui le prendront en compte.
>>
>> Je serais bien intéressé par un exemple pour le plugin mygmaps ;)
>>
>>
>> --
>> Philippe
>> --
>> Dev mailing list - Dev(a)list.dotclear.org -
>> http://ml.dotclear.org/listinfo/dev
>>
>
>
>
> --
>
> Franck — Operating Crocker’s rules (http://sl4.org/crocker.html)
> --
> Dev mailing list - Dev(a)list.dotclear.org -
http://ml.dotclear.org/listinfo/dev
--
Dev mailing list - Dev(a)list.dotclear.org -
http://ml.dotclear.org/listinfo/dev
--
Franck — Operating Crocker’s rules (http://sl4.org/crocker.html)
10:29 a.m.
Toujours est-il que surveiller le fichier de rapport (admin/csp_report.txt)
fournit de bonnes indications sur les directives qui sont violées. Une fois
corrigé, tu peux vider le fichier et continuer tes tests.
Le 26 juillet 2016 à 10:28, Franck Paul <carnet.franck.paul(a)gmail.com> a
écrit :
Beaucoup oui, quoique comparé à la taille totale d'une page
d'admin, ça ne
doit pas peser bien lourd dans les échanges avec le serveur.
Maintenant c'est aussi le prix à payer pour avoir une admin à peu près
sécurisée.
Quoi qu'il en soit, on peut aussi décider d'ici la sortie de la 2.10 de ne
pas activer par défaut les CSP. J'attends de faire le bilan de tous vos
retours pour décider.
2016-07-26 10:21 GMT+02:00 Philippe <philippe(a)dissitou.org>:
> Merci
>
> Avec ton code, l'API est bien chargée, mais pour faire tout
> fonctionner il m'a fallu en rajouter pas mal ! En effet il y a des tas
> de serveurs d'images et de scripts chez Google : le lecteur de
> fichiers kml, Street View, les tuiles de cartes, les icônes, etc.
>
> Plus les tuiles pour les cartes OpenStreetMap
>
> Pour l'instant, je ne suis pas encore sûr d'avoir tout, et il me
> faudra probablement surveiller si les serveurs changent (et comment
> ?), mais voici la fonction
>
> public static function adminPageHTTPHeaderCSP($csp)
> {
> if (isset($csp['default-src'])) {
> $csp['default-src'] .= ' fonts.gstatic.com';
> } else {
> $csp['default-src'] = 'fonts.gstatic.com';
> }
>
> if (isset($csp['script-src'])) {
> $csp['script-src'] .= ' maps.googleapis.com';
> } else {
> $csp['script-src'] = 'maps.googleapis.com';
> }
>
> if (isset($csp['img-src'])) {
> $csp['img-src'] .= ' maps.gstatic.com maps.googleapis.com
> csi.gstatic.com khms0.googleapis.com khms1.googleapis.com
> mts0.googleapis.com mts1.googleapis.com cbks0.googleapis.com
> cbks1.googleapis.com tile.openstreetmap.org';
> } else {
> $csp['img-src'] = 'maps.gstatic.com maps.googleapis.com
> csi.gstatic.com khms0.googleapis.com khms1.googleapis.com
> mts0.googleapis.com mts1.googleapis.com cbks0.googleapis.com
> cbks1.googleapis.com tile.openstreetmap.org';
> }
>
> if (isset($csp['style-src'])) {
> $csp['style-src'] .= ' fonts.googleapis.com';
> } else {
> $csp['style-src'] = 'fonts.googleapis.com';
> }
> }
>
> Ça ne fait pas un peu beaucoup ?
>
> :D
>
>
> --
> Philippe
>
>
> Le 26 juillet 2016 à 08:26, Franck Paul <carnet.franck.paul(a)gmail.com> a
> écrit :
> > Philippe, poyr mygmaps, dans _admin.php, quelque chose comme :
> >
> >
>
$core->addBehavior('adminPageHTTPHeaderCSP',array('myAdminBehaviors','adminPageHTTPHeaderCSP'));
> >
> > class myAdminBehaviors
> > {
> > public static function adminPageHTMLHead($csp)
> > {
> > if (isset($csp['script-src'])) {
> > $csp['script-src'] .= ' maps.googleapis.com';
> > } else {
> > $csp['script-src'] = 'maps.googleapis.com';
> > }
> > }
> > }
> >
> > devrait faire l'affaire.
> >
> > Le 25 juillet 2016 à 17:50, Philippe <philippe(a)dissitou.org> a écrit :
> >
> >> Le 25 juillet 2016 à 11:29, Franck Paul
<carnet.franck.paul(a)gmail.com>
> a
> >> écrit :
> >>
> >> > Je viens de reprendre un peu le code pour offrir aux plugins tiers
> >> > l'opportunité d'intégrer leur complément de directive CSP
(behavior
> >> > adminPageHTTPHeaderCSP).
> >> > Il y aura donc 2 moyen de les régler : about:config et 1 behavior
> pour
> >> les
> >> > plugins qui le prendront en compte.
> >>
> >> Je serais bien intéressé par un exemple pour le plugin mygmaps ;)
> >>
> >>
> >> --
> >> Philippe
> >> --
> >> Dev mailing list - Dev(a)list.dotclear.org -
> >> http://ml.dotclear.org/listinfo/dev
> >>
> >
> >
> >
> > --
> >
> > Franck — Operating Crocker’s rules (http://sl4.org/crocker.html)
> > --
> > Dev mailing list - Dev(a)list.dotclear.org -
> http://ml.dotclear.org/listinfo/dev
> --
> Dev mailing list - Dev(a)list.dotclear.org -
> http://ml.dotclear.org/listinfo/dev
>
--
Franck — Operating Crocker’s rules (http://sl4.org/crocker.html)
--
Franck — Operating Crocker’s rules (http://sl4.org/crocker.html)
10:38 a.m.
Le 26 juillet 2016 à 10:28, Franck Paul <carnet.franck.paul(a)gmail.com> a écrit :
Maintenant c'est aussi le prix à payer pour avoir une admin à peu
près
sécurisée.
Pas grave, si ce n'est que ça.
Quoi qu'il en soit, on peut aussi décider d'ici la sortie de la 2.10 de ne
pas activer par défaut les CSP. J'attends de faire le bilan de tous vos
retours pour décider.
Par défaut c'est mieux je crois. ceux qui n'en veulent pas peuvent décocher.
Une question : quid des images de la médiathèque si elles ne sont pas
sur le même domaine que l'admin du blog ?
--
Philippe
10:48 a.m.
Pour la médiathèque il faudra compléter la directive img-src côté
about:config (soit côté blog, soit côté réglages généraux pour toute la
plateforme).
Brol, si tu as modifié les directives, essaies d'enlever les protocoles
(mettre le domaine suffit amplement).
À savoir : on peut utiliser des wildcards (*) pour les domaines, genre *.
domaine.com
Plus de doc →
https://developer.mozilla.org/fr/docs/Web/Security/CSP/CSP_policy_directives
Le 26 juillet 2016 à 10:38, Philippe <philippe(a)dissitou.org> a écrit :
Le 26 juillet 2016 à 10:28, Franck Paul
<carnet.franck.paul(a)gmail.com> a
écrit :
> Maintenant c'est aussi le prix à payer pour avoir une admin à peu près
> sécurisée.
Pas grave, si ce n'est que ça.
>
> Quoi qu'il en soit, on peut aussi décider d'ici la sortie de la 2.10 de
ne
> pas activer par défaut les CSP. J'attends de faire le bilan de tous vos
> retours pour décider.
Par défaut c'est mieux je crois. ceux qui n'en veulent pas peuvent
décocher.
Une question : quid des images de la médiathèque si elles ne sont pas
sur le même domaine que l'admin du blog ?
--
Philippe
--
Dev mailing list - Dev(a)list.dotclear.org -
http://ml.dotclear.org/listinfo/dev
--
Franck — Operating Crocker’s rules (http://sl4.org/crocker.html)
11:21 a.m.
Le mardi 26 juillet 2016 à 10:48:26, vous écriviez :
Brol, si tu as modifié les directives, essaies d'enlever les
protocoles
(mettre le domaine suffit amplement).
modifié quoi ? où ?
ce qui est fun c'est que ça ne le fait que sur un blog du multi...
et si c'est un conflit avec un plugin, sachant qu'il y en a un certain
nombre d'activés comme de désactivés, ça va pas être long du tout de
déterminer qui fait son emmerdeur.
une idée pour comment débusquer ce qui coince ?
--
brol
11:27 a.m.
Brol, si ce n'est que sur un des blogs, alors c'est un plugin uniquement
actif sur ce blog qui fout le dawa : va falloir fouiller.
Le 26 juillet 2016 à 11:21, brol <brol31(a)gmail.com> a écrit :
Le mardi 26 juillet 2016 à 10:48:26, vous écriviez :
> Brol, si tu as modifié les directives, essaies d'enlever les protocoles
> (mettre le domaine suffit amplement).
modifié quoi ? où ?
ce qui est fun c'est que ça ne le fait que sur un blog du multi...
et si c'est un conflit avec un plugin, sachant qu'il y en a un certain
nombre d'activés comme de désactivés, ça va pas être long du tout de
déterminer qui fait son emmerdeur.
une idée pour comment débusquer ce qui coince ?
--
brol
--
Dev mailing list - Dev(a)list.dotclear.org -
http://ml.dotclear.org/listinfo/dev
--
Franck — Operating Crocker’s rules (http://sl4.org/crocker.html)
11:34 a.m.
Le mardi 26 juillet 2016 à 11:27:23, vous écriviez :
Brol, si ce n'est que sur un des blogs, alors c'est un plugin
uniquement
actif sur ce blog qui fout le dawa : va falloir fouiller.
c'est qu'il y a 98 plugins additionnels (actifs et non actifs)...
on est sûr à 100% que les inactifs ne peuvent interagir ?
--
brol
11:39 a.m.
A priori oui.
Le 26 juillet 2016 à 11:34, brol <brol31(a)gmail.com> a écrit :
Le mardi 26 juillet 2016 à 11:27:23, vous écriviez :
> Brol, si ce n'est que sur un des blogs, alors c'est un plugin uniquement
> actif sur ce blog qui fout le dawa : va falloir fouiller.
c'est qu'il y a 98 plugins additionnels (actifs et non actifs)...
on est sûr à 100% que les inactifs ne peuvent interagir ?
--
brol
--
Dev mailing list - Dev(a)list.dotclear.org -
http://ml.dotclear.org/listinfo/dev
--
Franck — Operating Crocker’s rules (http://sl4.org/crocker.html)
11:45 a.m.
Le mardi 26 juillet 2016 à 11:39:01, vous écriviez :
A priori oui.
donc non à 100%...
bon, l'enquiquineur est :
dcCKEditorAddons 0.3.3
bug malgré tout dans les widgets texte quand on insère une image d'un
domaine externe : pas d'affichage.
ceci étant, comment peut-on ne pas avoir la barre d'édition dans les
widgets texte ? je ne parle pas de la masquer mais de ne pas avoir du
tout l'éditeur dckeditor (ça serait bien d'avoir le choix).
enfin : quid des plugins qui ne sont pas compatibles déjà avec dc2.9.1
(question déjà posée et zappée purement et simplement) ?
--
brol
8:05 p.m.
Pour les widgets textes avec images externes, c'est en effet un des effets
de bord. Donc soit il faut rajouter le domaine correspondant côté directive
img-src du blog, soit il faut contrôler côté public du blog, ce qui peut
être acceptable vu qu'on ne doit pas changer les widgets tous les jours.
Pour l'éditeur ou pas dans les widgets, c'est un ticket à ouvrir et on peut
mettre ça au programme de la 2.10 si ce n'est pas trop compliqué, ou pour
la 2.11 à venir.
Je pense qu'il y a très peu de plugins qui ne seront pas adaptés aux CSP,
et si vraiment ça coince, les CSP peuvent être désactivées dans
about:config, donc rien de bloquant.
Le 27 juillet 2016 à 11:45, brol <brol31(a)gmail.com> a écrit :
Le mardi 26 juillet 2016 à 11:39:01, vous écriviez :
> A priori oui.
donc non à 100%...
bon, l'enquiquineur est :
dcCKEditorAddons 0.3.3
bug malgré tout dans les widgets texte quand on insère une image d'un
domaine externe : pas d'affichage.
ceci étant, comment peut-on ne pas avoir la barre d'édition dans les
widgets texte ? je ne parle pas de la masquer mais de ne pas avoir du
tout l'éditeur dckeditor (ça serait bien d'avoir le choix).
enfin : quid des plugins qui ne sont pas compatibles déjà avec dc2.9.1
(question déjà posée et zappée purement et simplement) ?
--
brol
--
Dev mailing list - Dev(a)list.dotclear.org -
http://ml.dotclear.org/listinfo/dev
--
Franck — Operating Crocker’s rules (http://sl4.org/crocker.html)
11 a.m.
Pour autant que je puisse en juger, le plugin mygmaps est prêt pour la 2.10 \o/
--
Philippe
11:02 a.m.
\o/
Mais je risque de tout casser d'ici le 13 août, hein ? :-D
Le 26 juillet 2016 à 11:00, Philippe <philippe(a)dissitou.org> a écrit :
Pour autant que je puisse en juger, le plugin mygmaps est prêt pour
la
2.10 \o/
--
Philippe
--
Dev mailing list - Dev(a)list.dotclear.org -
http://ml.dotclear.org/listinfo/dev
--
Franck — Operating Crocker’s rules (http://sl4.org/crocker.html)
5:52 p.m.
Le lundi 25 juillet 2016 à 11:29:21, vous écriviez :
Plop tout le monde,
Je viens de reprendre un peu le code pour offrir aux plugins tiers
l'opportunité d'intégrer leur complément de directive CSP (behavior
adminPageHTTPHeaderCSP).
Il y aura donc 2 moyen de les régler : about:config et 1 behavior pour les
plugins qui le prendront en compte.
j'ai aussi ajouté un behavior plus générique qui permet
d'intervenir sur
toutes les entêtes HTP envoyées avant l'affichage d'une page de l'admin
(behavior adminPageHTTPHeaders).
Avec ça on devrait pouvoir faire ce qu'on veut côté admin.
Côté public, je pense que je vais attendre un peu de retour en
"prod" avec
la 2.10 et implémenter ça pour la 2.11.
Le 24 juillet 2016 à 15:03, Franck Paul
<carnet.franck.paul(a)gmail.com> a
écrit :
> Sinon et pour répondre à Benoit, j'ai choisi des directives
pas trop
> fermées (au détriment du risque) :
>
> Les scripts JS inline et l'eval sont autorisés
> Idem pour les styles CSS inline
>
> Ça vaudra peut-être le coup de donner un coup de tournevis en allant à la
> chasse aux scripts et style inline et d'évaluer si l'eval JS peut être
> interdit. Cela dit, maintenant qu'on a accès aux différentes directives,
> tout le monde peut les modifier et faire les tests idoines. Vos rapports
> seront utiles pour affiner ça.
>
> Merci
>
>
>
> Le 24 juillet 2016 à 08:00, Benoit GRELIER <adjaya2(a)orange.fr> a écrit :
>
>> Je n'ai pas trop le loisir de tester actuellement, mais après quelques
>> lecture sur le sujet ( très technique pour mon niveau de compréhension, par
>> exemple :
>> https://hacks.mozilla.org/2016/02/implementing-content-security-policy/
>> ) je retiens que:
>>
>> _Il y a encore des bugs,
>>
>> _l’implémentation n'est pas simple et demande du temps.
>>
>> _Ce peut-être effectivement un bon outils de contrôle pour la phase de
>> dev d'une application et inciter à de bonnes pratiques.
>>
>>
>>
>> Coté admin pour dotclear, le fait d'ajout de plugins tiers plus ou moins
>> bien conçu ne risque-t-il pas de tout casser à l'affichage?
>>
>> Benoit.
>>
>>
>>
>>
>>
>> > Message du 23/07/16 19:43
>> > De : "Franck Paul"
>> > A : "dev(a)list.dotclear.org"
>> > Copie à :
>> > Objet : Re: [Dotclear Dev] CSP côté admin
>> >
>> > Côté admin, je pense qu'on peut l'imposer. Par contre c'est côté
public
>> ou il faudra permettre un réglage beaucoup plus fin ; mais j'ai mon idée à
>> ce sujet. Le 23 juillet 2016 à 14:51, Benoit GRELIER a écrit : > Je pence
>> que ce service devrait être optionnel ( sous forme de module >
>> activable/désactivable ) et non intégré en dur dans le code. > > > >
> >
>> --
>> Dev mailing list - Dev(a)list.dotclear.org -
>> http://ml.dotclear.org/listinfo/dev
>>
>
>
>
> --
>
Franck — Operating Crocker’s rules (http://sl4.org/crocker.html)
> --
Franck — Operating Crocker’s rules (http://sl4.org/crocker.html)
goret quotage powa \o/
v3291 quand le machincsp est activé, pu possible de textarea pour la
description du blog, idem pour les zones txt des widgets (en gros, pas
mal de textarea sont impactés).
sinon, je me demande quand même l'intérêt du truc sachant que nombre
de plugins tiers ne sont déjà pas à jour pour une compatibilité à 100%
avec dc2.9.1, alors en remettre une couche d'incompatibilité ne
risque pas de diminuer un peu plus le catalogue des dits plugins
tiers ?
--
brol
10:13 p.m.
Brol,
Le contenu du csp_report.txt est ?
Le 25 juillet 2016 à 17:52, brol <brol31(a)gmail.com> a écrit :
Le lundi 25 juillet 2016 à 11:29:21, vous écriviez :
> Plop tout le monde,
> Je viens de reprendre un peu le code pour offrir aux plugins tiers
> l'opportunité d'intégrer leur complément de directive CSP (behavior
> adminPageHTTPHeaderCSP).
> Il y aura donc 2 moyen de les régler : about:config et 1 behavior pour
les
> plugins qui le prendront en compte.
> j'ai aussi ajouté un behavior plus générique qui permet d'intervenir sur
> toutes les entêtes HTP envoyées avant l'affichage d'une page de l'admin
> (behavior adminPageHTTPHeaders).
> Avec ça on devrait pouvoir faire ce qu'on veut côté admin.
> Côté public, je pense que je vais attendre un peu de retour en "prod"
avec
> la 2.10 et implémenter ça pour la 2.11.
> Le 24 juillet 2016 à 15:03, Franck Paul <carnet.franck.paul(a)gmail.com> a
> écrit :
>> Sinon et pour répondre à Benoit, j'ai choisi des directives pas trop
>> fermées (au détriment du risque) :
>>
>> Les scripts JS inline et l'eval sont autorisés
>> Idem pour les styles CSS inline
>>
>> Ça vaudra peut-être le coup de donner un coup de tournevis en allant à
la
>> chasse aux scripts et style inline et d'évaluer si l'eval JS peut être
>> interdit. Cela dit, maintenant qu'on a accès aux différentes directives,
>> tout le monde peut les modifier et faire les tests idoines. Vos rapports
>> seront utiles pour affiner ça.
>>
>> Merci
>>
>>
>>
>> Le 24 juillet 2016 à 08:00, Benoit GRELIER <adjaya2(a)orange.fr> a écrit
:
>>
>>> Je n'ai pas trop le loisir de tester actuellement, mais après quelques
>>> lecture sur le sujet ( très technique pour mon niveau de
compréhension, par
>>> exemple :
>>>
https://hacks.mozilla.org/2016/02/implementing-content-security-policy/
>>> ) je retiens que:
>>>
>>> _Il y a encore des bugs,
>>>
>>> _l’implémentation n'est pas simple et demande du temps.
>>>
>>> _Ce peut-être effectivement un bon outils de contrôle pour la phase de
>>> dev d'une application et inciter à de bonnes pratiques.
>>>
>>>
>>>
>>> Coté admin pour dotclear, le fait d'ajout de plugins tiers plus ou
moins
>>> bien conçu ne risque-t-il pas de tout casser à l'affichage?
>>>
>>> Benoit.
>>>
>>>
>>>
>>>
>>>
>>> > Message du 23/07/16 19:43
>>> > De : "Franck Paul"
>>> > A : "dev(a)list.dotclear.org"
>>> > Copie à :
>>> > Objet : Re: [Dotclear Dev] CSP côté admin
>>> >
>>> > Côté admin, je pense qu'on peut l'imposer. Par contre c'est
côté
public
>>> ou il faudra permettre un réglage beaucoup plus fin ; mais j'ai mon
idée à
>>> ce sujet. Le 23 juillet 2016 à 14:51, Benoit GRELIER a écrit : > Je
pence
>>> que ce service devrait être optionnel ( sous forme de module >
>>> activable/désactivable ) et non intégré en dur dans le code. > > >
> >
>
>>> --
>>> Dev mailing list - Dev(a)list.dotclear.org -
>>> http://ml.dotclear.org/listinfo/dev
>>>
>>
>>
>>
>> --
>>
>> Franck — Operating Crocker’s rules (http://sl4.org/crocker.html)
>>
> --
> Franck — Operating Crocker’s rules (http://sl4.org/crocker.html)
goret quotage powa \o/
v3291 quand le machincsp est activé, pu possible de textarea pour la
description du blog, idem pour les zones txt des widgets (en gros, pas
mal de textarea sont impactés).
sinon, je me demande quand même l'intérêt du truc sachant que nombre
de plugins tiers ne sont déjà pas à jour pour une compatibilité à 100%
avec dc2.9.1, alors en remettre une couche d'incompatibilité ne
risque pas de diminuer un peu plus le catalogue des dits plugins
tiers ?
--
brol
--
Dev mailing list - Dev(a)list.dotclear.org -
http://ml.dotclear.org/listinfo/dev
--
Franck — Operating Crocker’s rules (http://sl4.org/crocker.html)
2835
days inactive
2842
days old
32 comments
6 participants
participants (6)
-
Benoit GRELIER -
brol -
Franck L -
Franck Paul -
mirovinben -
Philippe