sudo rm -rf --no-preserve-root /

@pcaversaccio

154 Following

3617 Followers

sudo rm -rf --no-preserve-root / pfp

sudo rm -rf --no-preserve-root /

and yes this is based on real victims

0 reply

0 recast

1 reaction

sudo rm -rf --no-preserve-root / pfp

sudo rm -rf --no-preserve-root /

ffs, please don't ask ChatGPT or other LLMs if a file is safe. First, new malware is not part of past training data used for the LLMs (even tho certain, e.g. infostealer pattern, are recycled over time), second ChatGPT cannot execute files (needed to detect behaviours that only manifest during execution), and usually malware also uses advanced obfuscation, which cannot be analysed. Use your brain and upload it to eg VirusTotal (not fool proof!), don't fucking delegate your security to an over calibrated language model.

1 reply

0 recast

7 reactions

sudo rm -rf --no-preserve-root / pfp

sudo rm -rf --no-preserve-root /

I have come to the conclusion that 95% of security products in our industry are nothing more than vaporware, offering the illusion of security rather than actual protection.

3 replies

10 recasts

78 reactions

sudo rm -rf --no-preserve-root / pfp

sudo rm -rf --no-preserve-root /

Every time I skim through the (updated) EOF specs, it's a reminder of how we've drowned in complexity for the sake of flexing. There is no reason this monstrosity should ever see the light of day. Sorry. Let’s get back to KISS.

1 reply

4 recasts

46 reactions

sudo rm -rf --no-preserve-root / pfp

sudo rm -rf --no-preserve-root /

Rust devs after their 101th rewrite-in-rust

2 replies

5 recasts

42 reactions

sudo rm -rf --no-preserve-root / pfp

sudo rm -rf --no-preserve-root /

a sweet story from "RIP Solidity" to "must have eventually" within 3 days https://github.com/ethereum/solidity/issues/14208#issuecomment-2523104434

0 reply

4 recasts

50 reactions

sudo rm -rf --no-preserve-root / pfp

sudo rm -rf --no-preserve-root /

gents, amidst the whirlwind of SEAL 911 tickets, I somehow managed (don’t ask me how!) to add support for off-chain message hashes to my Safe transaction hashes Bash script over the past few days. The updated script now outputs the raw message, along with the domain, message, and Safe message hashes, making it easy for you to verify them against the values shown on your Ledger hardware wallet screen. This can be particularly useful for security councils using 1/1 multisigs to sign into governance tools or for logging into platforms like OpenSea with your multisig. Always remember: Don't trust, verify! https://github.com/pcaversaccio/safe-tx-hashes-util/pull/10 On a side note, I've been asked a few times over the last weeks how people can support my open-source work. Everything I create is for the community. If you feel like showing your appreciation, you can find my donation address here https://github.com/pcaversaccio/snekmate/blob/main/FUNDING.json#L4

0 reply

19 recasts

122 reactions

sudo rm -rf --no-preserve-root / pfp

sudo rm -rf --no-preserve-root /

Tbf we see users also ignoring all warnings... (mostly in the moments when the greed takes over)

1 reply

0 recast

2 reactions

sudo rm -rf --no-preserve-root / pfp

sudo rm -rf --no-preserve-root /

Sometimes (tbh multiple times a day), I wish we could rewind to the early crypto days—when everything felt like the wild west, principles-based, and full of endless possibilities.

2 replies

10 recasts

98 reactions

sudo rm -rf --no-preserve-root / pfp

sudo rm -rf --no-preserve-root /

Can people please stop fucking getting rekt by interacting with malicious websites?? Like seriously, since 5 days we get non-stop draining victim tickets in SEAL 911. Look I will be totally frank: all of your security products help shit to prevent people getting drained. It's almost 2025 and we're nowhere solving this.

3 replies

1 recast

18 reactions

sudo rm -rf --no-preserve-root / pfp

sudo rm -rf --no-preserve-root /

So this morning I found a rather annoying bug in the Safe UI for older Safe versions `<=1.2.0`. TL;DR: the domain hash displayed is wrong. https://x.com/pcaversaccio/status/1864643674304373121

1 reply

18 recasts

98 reactions

sudo rm -rf --no-preserve-root / pfp

sudo rm -rf --no-preserve-root /

This is such a retarded take. A VPN is your digital armour. People might use a public Wi-Fi or want to prevent government/ISP tracking when logging into Coinbase. I'm not sure if this a personal view or a Coinbase view, but if it's a company-wide opinion you're fucking anti-privacy clowns! First, you celebrate the legal win to overturn OFAC sanctions against Tornado Cash, and now using a VPN is uncool? A very, very moronic take. https://x.com/scottshapiro/status/1863691538661883925

1 reply

1 recast

23 reactions

sudo rm -rf --no-preserve-root / pfp

sudo rm -rf --no-preserve-root /

Sooner or later, we'll come to a powerful realisation: the most pivotal move for L2s will be acknowledging that, in the long run, we may not need them at all. In hindsight, Layer 2 solutions will appear as temporary stopgaps. Not now, not in 6 months, but in 3-5 years' time. That's my bet.

0 reply

4 recasts

63 reactions

sudo rm -rf --no-preserve-root / pfp

sudo rm -rf --no-preserve-root /

It amazes me how L2s think that it's a great idea to modify the source code of one of the most successful smart contracts to date. If you ask me, this is just insane. What can go wrong? hint: insufficient approval to self. Can we fucking stop this fragmentation, it only hurts. Welcome to Blast's WETH version.

2 replies

0 recast

10 reactions

sudo rm -rf --no-preserve-root / pfp

sudo rm -rf --no-preserve-root /

For example for `bafybeicu2anhh7cxbeeakzqjfy3pisok2nakyiemm3jxd66ng35ib6y5ri` you can look it up here: https://github.com/tornado-repositories for e.g. `bafybeiduouhoquhndpzlqrhcfb7wt2jme7qdp4omldal3kulbx63dsrigq` you can verify some old governance links https://x.com/MicahZoltu/status/1603617404113760256. It requires some digging. Always verify and not trust. As background I published here (https://x.com/pcaversaccio/status/1761447148468474265) when the UI got compromised, so I kept a list of uncompromised, reviewed hashes that I published now.

0 reply

0 recast

1 reaction

sudo rm -rf --no-preserve-root / pfp

sudo rm -rf --no-preserve-root /

This is a legal question which I can't answer myself. I don't know what exactly has to happen besides the OFAC removal that exchanges accept it again...

1 reply

0 recast

1 reaction

sudo rm -rf --no-preserve-root / pfp

sudo rm -rf --no-preserve-root /

Different iterations of the TC interface.

0 reply

0 recast

0 reaction

sudo rm -rf --no-preserve-root / pfp

sudo rm -rf --no-preserve-root /

For those who want to exercise their privacy rights and want to use an uncompromised Tornado Cash interface, here are some secure IPFS hashes: - bafybeicu2anhh7cxbeeakzqjfy3pisok2nakyiemm3jxd66ng35ib6y5ri - bafybeia7cu2axyyxsarmaemvlpdpofa4q23lzpltbl4jbrnfixdn573h4y - bafybeiduouhoquhndpzlqrhcfb7wt2jme7qdp4omldal3kulbx63dsrigq - bafybeiguelxw5aanwnhvaea5vjhknmcdmwvujne36wgabnkmcbt3563toa - bafybeiezldbnvyjgwevp4cdpu44xwsxxas56jz763jmicojsa6hm3l3rum https://x.com/iampaulgrewal/status/1861549058797772874

4 replies

22 recasts

109 reactions

Vitalik Buterin pfp

Vitalik Buterin

@bountybot complete Ivan Makeev gets the largest share for identifying an actual pretty significant vulnerability: the possibility that the liabilities counter gets over-filled if the contract runs out of money, and then someone stakes 1 wei some amount of time _after_ that happens. Using correctedNow in both stake and unstake fixed it. The others who contributed ideas for changes that made it into the final contract gets 0.08 each Ivan Makeev: 1.36 Charles Cooper: 0.08 Tanguy Rocher: 0.08 dcposch.eth: 0.08 sebayaki.eth: 0.08 leoglisic.eth: 0.08 warpcastadmin.eth: 0.08 bout3fiddy: 0.08 psaversaccio: 0.08

2 replies

2 recasts

15 reactions

sudo rm -rf --no-preserve-root / pfp

sudo rm -rf --no-preserve-root /

So we have an "official" (i.e. NIST-based) deadline now: ECDSA should be deprecated by 2030 (for 112 bits only) and completely disallowed by 2035. Thx for the crazy ride secp256k1 (and secp256r1). https://nvlpubs.nist.gov/nistpubs/ir/2024/NIST.IR.8547.ipd.pdf

2 replies

19 recasts

152 reactions