Recherche avancée

Sur d’autres sites (10338)

• Evolution #3926 : Remplacement de safehtml par le plug htmlpurifier ou autre

  14 janvier 2019, par Guillaume Fahrner

  Sorry je n’avais pas vu ce message :

  cedric - a écrit :

  Depuis https://core.spip.net/projects/spip/repository/revisions/24131 le plugin HTMLPurifier est fonctionel sans nécessiter de patch dans le core ?

  Malheureusement si : il reste une surcharge de la fonction propre() via inc/texte.php. Elle est utilisée pour réaliser la protection HTML via echappe_html() AVANT le 1er filtrage de sécurité via echapper_html_suspect(). Un deuxième est réalisé via echappe_retour_modeles($t, $interdire_script) ou $interdire_script est vrai en espacé privé ou si le mode parano actif et faux sinon. (Je n’ai pas su faire autrement, mais il y a peut être une astuce a trouver.)

  Je ne sais pas si tu considères que c’est le core mais une surchage des règles YAML de textwheel est également réalisé afin que l’on envoi bien tout qui doit l’être dans les filtres de sécurité.

  Donc non pas de modification du core nécessaire pour que le plugin fonctionne. A voir si ces surcharges mériterais une "intégration directe" future.

  on est bon et on peut release tel quel en indiquant que le plugin htmlpurifier est disponible pour tests et se laisser le temps ?

  A mon avis oui. Pour rappel : le mode parano est actuellement inutilisable avec l’actuel safehtml(). Du coup ça peut être une approche pour l’intégrer/le tester au fil de l’eau : commencé par les gens qui utilisent le mode parano en leur recommandant chaudement/forcant ce plugin.

  Ci dessous la liste des plugins que j’utilise sans problème hors textwheel/todo (cf https://core.spip.net/issues/4254) avec htmlPurifier :

  Abonnements 3.3.6 - stable
  Agenda 3.26.0 - stable
  API de vérification 1.8.1 - stable
  API Prix 0.1.16 - dev
  Article PDF 1.0.10 - stable
  Autorité 0.10.20 - stable
  Banque&paiement 3.6.7 - stable
  Cache Cool 0.5.4 - stable
  Challenge Hacking 1.0.0 - stable
  Champs Extras 3.11.7 - stable
  Chatbox 1.0.5 - stable
  Coloration Code 99 - stable
  Commandes 1.15.5 - stable
  Compositions 3.7.3 - stable
  Crayons 1.26.18 - stable
  CTF all the day 1.0.0 - stable
  Facteur 3.6.2 - stable
  Formulaire de contact avancé 0.16.5 - stable
  Frimousses 1.5.1 - stable
  GIS 4.44.24 - stable
  HTML Purifier 5.0.0.1 - test
  iCalendar 0.4.5 - test
  Import ics 4.4.3 - stable
  Imprimer document 0.2.2 - stable
  LangOnet 1.4.6 - stable
  MailShot 1.27.3 - stable
  MailSubscribers 2.11.3 - stable
  Markdown 1.0.2 - test
  Messagerie 3.1.8 - test
  Mini Calendrier 2.4.1 - stable
  Mot de passe dès l’inscription 1.0.19 - stable
  Newsletters 1.6.0 - stable
  Nombres de visiteurs connectés 0.2.3 - stable
  NoSPAM 1.5.18 - stable
  Notation 2.4.2 - test
  Notifications 3.6.8 - stable
  Notifications avancées 0.4.2 - test
  Pages 1.3.7 - stable
  Pre & Code 99 - test
  Saisies pour formulaires 3.11.1 - stable
  Social tags 1.1.1 - stable
  SPIP Bonux 3.4.6 - stable
  Tip A Friend 1.6.9 - stable
  Todo 2.2.1 - stable
  Traduction entre rubriques 3.1.3 - stable
  YAML 1.5.4 - stable

  Je pense que si on doit intégrer le plugin ça sera sur la version dev 3.3, pas sur la version stable, et ça va demander de prendre le temps de voir toutes les modifs et les impacts éventuels que tu n’aurais pas vu ou auxquelles tu n’aurais pas pensé.

  Clairement je pense me faire insulter :-) Je suis prêt ^^ Plus sérieusement il faut absolument tester/restester/reretester. J’ai tenté de faire au mieux mais je ne peux pas revoir tout le code HTML généré par les plugins... Au moindre écart de conformité HTML ca ne passera pas. Le bug https://core.spip.net/issues/4254 en est un bon exemple : avec htmlpurifier l’élément

  est supprimé ; avec "safehtml() standard" le code invalide est conservé et c’est le navigateur qui va corriger.

  Il faut voir les bons cotés : cela force les bonnes pratiques, met SPIP au plus haut niveau du standard (Drupal fait moins bien), aide a identifier des bugs et ce qui passe dans propre() sera obligatoirement valide. C’est aussi a terme moins de problèmes d’injection XSS a traiter pour la team.

  Sur la fonction de survol des logos le sujet reste ouvert ? On est en effet d’accord que cette écriture est obsolète et devrait être revue de toute façon, mais c’est donc un point à traiter dans le core le cas échéant

  Euh je comprend pas, faut-il intégrer le patch des puces de statut dans ce plugin ? Je pensais plus coder le truc """proprement""" avec un JS dans le directement dans /prive/. A décolérer complètement à mon sens.

  Encore merci pour le temps que tu y passes :)

• FFmpeg-kit : Unknown encoder 'libx264' / 'mediacodec' and Gradle dependency issues in Android Studio

  15 mai, par Izzet dönertaş

  I'm working on a video editor app in Android Studio using ffmpeg-kit. My goal is to export video segments with fade transitions and audio using FFmpeg.

  


  This implementation line works fine :

  


  implementation("com.arthenica:ffmpeg-kit-full:6.0-2")


  


  What doesn't work (Encoding) :
When I try to export a video segment using :

  


  -c:v libx264 -c:a aac


  


  I get this error in the logs :

  


  [vost#0:0 @ ...] Unknown encoder 'libx264'


  


  After checking the build configuration, it turns out libx264 is not enabled in the current FFmpeg-kit build :

  


  --disable-libx264 (or rather: --enable-libx264 is missing)


  


  Tried replacing libx264 with mediacodec :
Then I tried using :

  


  -c:v mediacodec -c:a aac


  


  But again I got :

  


  Unknown encoder 'mediacodec'


  


  Apparently, mediacodec is supported for decoding, but not as an encoder in FFmpeg-kit.

  


  Tried to compile my own FFmpeg binary :
I attempted building FFmpeg manually using the following flags :

  


  --enable-libx264 --enable-gpl --enable-shared ...


  


  My plan was to access it via JNI or ProcessBuilder.

  


  But the process is extremely frustrating :

  


  

  • Missing file errors

  


  • Configuration conflicts

  


  • Dependency hell (especially on macOS/Linux NDK toolchains)

  


  


  Tried other ffmpeg-kit variants :
I also tried switching to :

  


  implementation 'com.arthenica:ffmpeg-kit-full-gpl:6.0'


  


  and other variants like ffmpeg-kit-min-gpl, etc.
But in all of them I got the same Gradle error :

  


  Caused by: org.gradle.api.internal.artifacts.ivyservice.TypedResolveException:  Could not resolve all files for configuration ':app:debugRuntimeClasspath'.

  


  My build.gradle setup (yes, mavenCentral + google are already included) :

  


  pluginManagement {
    repositories {
        google()
        mavenCentral()
    }
}

dependencyResolutionManagement {
    repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)
    repositories {
        google()
        mavenCentral()
    }
}



  


  I also tried enabling offline mode, clearing cache, adding jetpack.io, nothing helped.

  


  I asked ChatGPT-4o, Gemini 2.5 Pro. None could provide a working solution for this combination of :

  


  

  • Working implementation

  


  • Proper video encoding (with libx264 or mediacodec)

  


  • Without breaking Gradle dependency resolution

  


  


  I just want one of the following :

  


  


  1. A working FFmpeg-kit implementation (that supports libx264) and doesn’t crash Gradle

     


  


  2. A reliable guide or build.gradle snippet that lets me use GPL version (with libx264) without resolve errors

     


  


  3. (Ideally) A prebuilt safe LGPL-compatible alternative that allows encoding and is Google Play compliant

     


  


  


  Any help or suggestions would be highly appreciated.
Thanks in advance

  


• lavc/vvc : Ensure subpictures don't overlap

  22 février, par Frank Plowman

  lavc/vvc : Ensure subpictures don't overlap
  This is essentially a re-implementation of
  
  https://patchwork.ffmpeg.org/project/ffmpeg/patch/20241005223955.54158-1-post@frankplowman.com/
  That patch was not applied last time.  Instead we opted to identify
  
  issues which could be caused by invalid subpicture layouts and remedy
  
  those issues where they manifest, either through error detection or code
  
  hardening.  This was primarily implemented in the set
  
  https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=13381.
  This has worked to some degree, however issues with subpicture layouts
  
  continue to crop up from the fuzzer and I've fixed a number of bugs
  
  related to subpicture layouts since then.  I think it's best to return
  
  to the initial plan and simply check if the subpicture layout is valid
  
  initially.
  This implementation is also lighter than the first time — by doing a
  
  bit more logic in pps_subpic_less_than_one_tile_slice, we are able to
  
  store a tile_in_subpic map rather than a ctu_in_subpic map.  This
  
  reduces the size of the map to the point it becomes possible to allocate
  
  it on the stack.  Similar to 8bd66a8c9587af61c7b46558be3c4ee317c1af5a,
  
  the layout is also validated in the slice map construction code, rather
  
  than in the CBS, which avoids duplicating some logic.
  Signed-off-by : Frank Plowman <post@frankplowman.com>
  

  • [DH] libavcodec/vvc/ps.c