292 private links
AppWrite support Rust with a dedicated SDK
A cybersecurity researcher has published proof-of-concept (PoC) exploits for two unpatched Microsoft Windows vulnerabilities named YellowKey and GreenPlasma, which are a BitLocker bypass and a privilege-escalation flaw.
"The result of this is that the X:\Windows\System32\winpeshl.ini is deleted, and when Windows Recovery is entered, rather than launching the actual Windows Recovery environment, it pops up a CMD.EXE. With the disk still unlocked" - Will Dormann
Why?
Async in Rust is hard. The biggest drawback of async is the fragmentation of the ecosystem. Now you have sync functions and libs, async functions and libs, and different runtimes that are incompatible and thus require dedicated libraries for I/O.
An anemic standard library for daily needs.
The steep learning curve before being productive.
When Rust makes the most sense?
- common core for cross-platform apps. Proton leads the way.
- system programming
- embedded development
- insane scale
The websites must renew their certificates. Certificates are issued for two years but it's hard to renew certificates after two years! Let's Encrypt came up with a brilliant idea: all certificates are valid for only 90 days.
It has two advantates: it rotates the private key every 90 days and it pushes website owner to automate the renewal process.
In case of private key compromission, there are two methods to revoke the certificates: CRL and OCSP.
In principle, CA certificates themselves carry this information, informing clients that when verifying a certificate, they should visit this URL list to check if the certificate they are validating is in the revocation list. If it is, they should not trust it.
The CRL provides exactly that with the DER format.
The OCSP method needs to verify every URL of each certificates. This method has downsides:
- The website's performance will decrease due to the additional time required for CA requests. The OCSP servers could become htspots and might be overloaded by clients.
- The CA will know which domain names the client has accessed.
- If the CA's OCSP service is down, the client has two choices: ignore verification or no trust the target site.
There can be workarounds with the OCSP Stapling: the website itself query the CA's OCSP service and when a client visits the website, the website provides the OCSP response.
All of these methods works if the CA can be trusted. WoSign had for example a chaotic organization that issued certificates for websites directly, whereas the CA should have issued certificates for Chinese users only.
That's what Certificate Transparency (CT) should address after the DigiNotar incident in 2011.n CT must log the issued certificate in a CT database and the CT will provide a Signed Certificate Timestamp (SCT) back to the website. The clients will only trust certificates that have an SCT when visiting websites and websites (and everyone) can monitor the CT database to check if any certificates have been issued for their domains.
The client must have CA Root. Once the CA Root is verified, the client cana trust the certificates signed by the root and its other intermediate certificates.
Verification starts from the certificate of the domain. If it’s valid, the client verifies its issuer, and continues this process until reaching a certificate where the issuer is itself, indicating it is a Root.
For lyokolux.space, it goes as follow:
$openssl s_client -showcerts -connect lyokolux.space:443 -servername lyokolux.space 2> /dev/null | grep -A1 s:
0 s:CN = lyokolux.space
i:C = US, O = Let's Encrypt, CN = E8
--
1 s:C = US, O = Let's Encrypt, CN = E8
i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
lyokolux.space is certified by Let's Encrypt. Let's Ecrypt is certified by the root certificate ISRG Root X1. The browser also tells ISRG Root X1 is a Certificate Authority.
Following the incident of DST Root CA X3 with a notable certificate expiration, the browsers started to trust Let's Encrypt directly. It seems openssl does it too because we don't see the certificate of ISRG Root X1 in the openssl output. The let's encrypt certificate is trusted because of ISRF Root XA.
- A certificate can have only one issuer because the issuer is a fixed field in the certificate, not a list.
- The essence of signing is just appending a hash value encrypted with a private key.
- Intermediate certificates are not directly trusted by clients; clients only trust Root CAs.
To increase security, a certificate can be cross-signed and verified by one or the other sources. It's up to the client or the software to trust root certificates. When the client further narrows down the trusted list to only its certificates (or its CA), this is Client Certificate Pinning. For example, the TikTok app uses this.
Next: https://shaarli.lyokolux.space/shaare/13012
Previous: https://shaarli.lyokolux.space/shaare/1ar20g
lol
Adding query string for a referral (with ?via for example)
- can broke the URL such as
https://int10h.org/oldschool-pc-fonts/fontlist/?foo. Altering a URL gives you a new URL. The new URL could point to a completely different resource, or to no resource at all, even if the alteration is as small as adding a seemingly harmless query string. - There is already the HTTP Referrer header for that. It's governed by the Referrer-Policy
Another post describe this problem: https://chrismorgan.info/no-query-strings
"Unix was named (phonetically) by bwk. I don't think he ever spelled it, but, since it was a play on multics, he thought it was unics. (you can ask him)
at the time, unix was compiled on the central computer at bell labs (GE-635) that produced a PDP--7 paper tape. usuallly i just ran the tape and threw it away. when i needed to save a tape, i wrote "unix" on the tape. it stuck after that.
Ça fait plusieurs fois que je vois passer la notion de "instant software", pour du logiciel qui serait tellement facile et peu cher à produire par des agents de codage que ça ne vaudrait plus la peine de le conserver au-delà de ses usages immédiats.
L'auteur propose "touillette logicielle" pour les nommer en français.
Problème : le kit choisi par l’Europe se connecte en Lightning, le port contre lequel la Commission européenne a lutté pendant plus d’une décennie. Une erreur évidente de communication, alors que l’USB-C a remplacé le port d’Apple grâce aux efforts de l’Europe. Encore plus amusant : il existe bien une version USB-C du micro cravate sur le catalogue de Devia… mais elle est plus chère.
C'est le problème lorsque les responsabilités sont diluées, plus personne n'est responsable de rien et il n'y a plus de structure commune. C'est ici un exemple mineur qui n'a pas vraiment d'impact.
A new model emerges after the cathedral and the bazaar: the kitchen. The author describes it.
Every kitchen evolves around the habits of its cook. Tools sit where they are convenient. Ingredients are substituted freely. Recipes are modified on instinct. Two people may start from the same dish and end up with completely different results.
Kitchen rarely converge into a universal standard.
The project is available at https://github.com/kadir/cloakrs
Je suis bien déçu de Deepl et GitLab.
La restructuration en supprimant des niveaux hiérarchique me semble sensé pour un produit numérique. Je ne sais pas si cela est pertinent pour les autres domaines comme le marketing.
There are a number of serialization libraries that outperform JSON in NodeJS.
It's important to avoid generating extraneous garbage when doing these kinds of benchmarks.
It's important to provide an appropriately sized buffer when performing serialization.
If you care about serialization performance, consider using a different programming language with better tradeoffs.
A Finite State Transducer seems to be the best algorithm instead of a full index search.
The data don't need to be stored in a database indeed. They only need to be searched as text.