[Перевод] setHTML(), Trusted Types и Sanitizer API
Ранняя версия Sanitizer API была реализована в Chrome, но позже была удалена . Поэтому не стоит ориентироваться на старые материалы — спецификация API со временем значительно изменилась. На данный момент Sanitizer API поддерживается в Firefox Nightly в соответствии с актуальной спецификацией. В Chrome Canary он также доступен, но только при включении специального флага. В Safari реализация пока не ведется, однако команда разработчиков Safari выразила поддержку этой инициативе. Trusted Types API уже реализован в Chrome/Edge, Samsung Internet, Safari и Firefox Nightly . В Chrome он поддерживается начиная с версии 83, а начиная с версии 144 полностью соответствует последней спецификации и реализации в других браузерах.
https://habr.com/ru/companies/timeweb/articles/965142/
#html #javascript #js #timeweb_статьи_перевод #sethtml #trusted_types #sanitizer #доверенные_типы #санитайзер #xss
🫧 Gel developed as alternative to alcohol-based hand sanitizers
https://medicalxpress.com/news/2025-08-gel-alternative-alcohol-based-sanitizers.h
#health #drugs #sanitizer #materials #infections #chemistry #research
For two days straight, I just can't reproduce #swad #crashing with *anything* in place (#clang #sanitizer instrumentation, attached #debugger like #lldb) that could give me the slightest hint what's going wrong. 😡
But it *does* crash when "unobserved". And it looks like this is happening a lot sooner (or, more often?) when using #LibreSSL ... but I also suspect this could be a red herring in the end.
Situation reminds me of my physics teacher back at school, who used to say something in german I just can't ever forget:
"Wer misst, misst Mist."
Feeble attempt in english would be "the one who measures measures crap", it was his humorous way to bring one consequence of #Heisenberg's indeterminacy principle to the point. And indeed, #debugging computer programs always suffers from similar problems...
I need help. First the question: On #FreeBSD, with all ports built with #LibreSSL, can I somehow use the #clang #thread #sanitizer on a binary actually using LibreSSL and get sane output?
What I now observe debugging #swad:
- A version built with #OpenSSL (from base) doesn't crash. At least I tried very hard, really stressing it with #jmeter, to no avail. Built with LibreSSL, it does crash.
- Less relevant: the OpenSSL version also performs slightly better, but needs almost twice the RAM
- The thread sanitizer finds nothing to complain when built with OpenSSL
- It complains a lot with LibreSSL, but the reports look "fishy", e.g. it seems to intercept some OpenSSL API functions (like SHA384_Final)
- It even complains when running with a single-thread event loop.
- I use a single SSL_CTX per listening socket, creating SSL objects from it per connection ... also with multithreading; according to a few sources, this should be supported and safe.
- I can't imagine doing that on a *single* thread could break with LibreSSL, I mean, this would make SSL_CTX pretty much pointless
- I *could* imagine sharing the SSL_CTX with multiple threads to create their SSL objects from *might* not be safe with LibreSSL, but no idea how to verify as long as the thread sanitizer gives me "delusional" output 😳
Fixed *that* issue by making sure each instance of the Process class has an owning thread, but forks the child on the main thread and receives exit events from there, delegating that info back to the owing thread. Seems to work.
Now, I can still make #swad crash. But no matter what I tried so far, as soon as I build it with both #debugging symbols and the #thread #sanitizer, I just can't reproduce a crash.
Now what? 😞🤷
Yep, there's a second bug. #clang #thread #sanitizer had nothing to complain, and the output from #assert doesn't help much. So, first step: "pimp your assert" 😂 --- #FreeBSD, like some other systems, provides functions to collect and print rudimentary stacktraces, use these if available:
https://github.com/Zirias/poser/commit/c45dd56312dd05b6bf02a27bf9e39eb31331f05a
Now I got closer, see screenshot. That's enough to understand, the issue is with the global event firing when a #child #process exits, this was used from multiple threads. Ok, it obviously doesn't work that way, so, back to the drawing board regarding my handling for child processes... 🤔
Next #swad release: Soon, so I hope 🙈
Next #swad release will still be a while. 😞
I *thought* I had the version with multiple #reactor #eventloop threads and quite some #lockfree stuff using #atomics finally crash free. I found that, while #valgrind doesn't help much, #clang's #thread #sanitizer is a very helpful debugging tool.
But I tested without #TLS (to be able to handle "massive load" which seemed necessary to trigger some of the more obscure data races). Also without the credential checkers that use child processes. Now I deployed the current state to my prod environment ... and saw a crash there (only after running a load test).
So, back to debugging. I hope the difference is not #TLS. This just doesn't work (for whatever reason) when enabling the address sanitizer, but I didn't check the thread sanitizer yet...
Fun with -fsanitize=undefined and Picolibc
https://keithp.com/blogs/sanitizer-fun/
#HackerNews #Fun #with #-fsanitize=undefined #and #Picolibc #sanitizer #fun #undefined #behavior #picolibc #coding #techniques
Project Anime
Spab
Habr
Paul Houle
Felix Palmen 
Hacker News