293 private links
The unpaid work of volunteers for core libraries is unsustainable. We can all agree on that.
There is few comments suggesting sustainable models.
Securam ProLogic ne réglera pas cette porte dérobée.
Les raccourcisseurs d'URLs sont une fausse bonne idée dans la plupart des cas:
- Les URLs raccourcies ne sont pas toujours générées aléatoirement
- Le phishing rendu possible
- La dépendance au service, qui peut fermer, comme ici avec goo.gl
Here we go again. A small package is
is abused.
The transcription makes it clear how it works:
- Expose node's require with a
get "switch"() { return require; }
- Load
os
andws
modules fromthis['switch']
- Connect to the websocket
new Function(data)(); // remote code execution
of a WebSocket message.
About using C code:
- there obviously the potential bugs and vulnerabilities in the C code itself and in the code wrapping the C code.
- specific C toolchains, which makes things hard when you do cross compilation.
- you (sometimes) need to deploy the dynamically-linked C library (OpenSSL). It prevents you from using secure FROM scratch container images.
- can't compile it for WebAssembly.
- maintenance! it's hard to review a 2000 line implementation of an encryption algorithm
Pure Rust cryptography is usually around 10-25% slower than an ultra optimized C or assembly code.
Diffusé via de la publicité malveillante redirigeant sur un faux site de KeePass afin de déchiffrer les mots de passes.
Update ASAP to Firefox 139
Maybe too much
Press article of https://shaarli.lyokolux.space/#x6SmSw
ENISA is mandated to develop and maintain the European vulnerability database.
All that's required is to create a malicious software package under a hallucinated package name and then upload the bad package to a package registry or index like PyPI or npm for distribution. Thereafter, when an AI code assistant re-hallucinates the co-opted name, the process of installing dependencies and executing the code will run the malware.
Aboukhadijeh explained that _Iain "automated the creation of thousands of typo-squatted packages (many targeting crypto libraries) and even used ChatGPT to generate realistic-sounding variants of real package names at scale. He shared video tutorials walking others through the process, from publishing the packages to executing payloads on infected machines via a GUI. It’s a clear example of how attackers are weaponizing AI to accelerate software supply chain attacks."
Not in France.
3.5 millions fines after a ransomware attack because no security measure was set.
Gmail révolutionne le chiffrement des emails - Ah bon ? | Protection des données | Le site de Korben
Fin de l’article ??? Naaaaan ! Attendez une minute, bande d’impatients ! Car quand on regarde sous le capot, on se rend compte que Google joue “un peu” avec les mots. Ils appellent ça “end-to-end encryption” (E2EE), mais les puristes de la sécurité sont en train d’hurler au scandale (et pas “d’hurler aux sandales”, c’est pas encore les vacances). En réalité, ce qu’a mis en place Google s’appelle du “client-side encryption” (CSE). La différence n’est pas juste sémantique, elle est fondamentale !
Dans un vrai système E2EE comme Signal ou WhatsApp, les clés de chiffrement sont générées et restent uniquement sur les appareils des utilisateurs finaux. Personne d’autre, pas même le fournisseur du service, ne peut déchiffrer les messages. C’est le Saint Graal de la sécurité des communications et c’est bien pour ça que les Etats veulent des backdoor dans tous ces services !
Mais avec le CSE de Google, les clés sont générées ET stockées dans un service cloud de gestion des clés. Les administrateurs peuvent donc y accéder, révoquer des accès, surveiller ce que les utilisateurs chiffrent. Donc c’est un genre de un coffre-fort ultra-sécurisé protégeant vos données les plus sensibles, mais où le mec qui l’a installé a gardé un double de la clé “au cas où”, et pourrait même regarder ce que vous y stockez s’il s’emmerde.