raggi

8 ms·

91.
A Vulnerability in Libsodium(00f.net)
333 points by raggi 10mo ago|48 comments
92.
by raggi 10mo ago
I found it very opaquely worded the whole way through. I think the work being presented is simply an implementation of the technique in eduos, but short of going and reading the paper I don’t know.
93.
by raggi 10mo ago
We are doing this, and it’s terrible. Having done both at scale this one is worse.
94.
by raggi 10mo ago
I have been self hosting a product on Postgres that serves GIS applications for 20 years and that has been upgraded through all of the various versions during that time. It has a near perfect uptime record modulo two hardware failures and s
95.
by raggi 10mo ago
It may not matter for clouds with massive margins but there are substantial opportunities for optimizing wear.
96.
by raggi 10mo ago
I think this is a fair take. Local security for Linux is nightmare fuel already, we don't need more.
97.
.well-known/SSH-known-hosts – WebPKI bootstrapping for SSH known hosts(github.com)
2 points by raggi 10mo ago|0 comments
98.
by raggi 10mo ago
So you’re correct that covering the broadest general case is problematic. You have to block code from doing IO of any form to be safe. In general though getting to a fairly predictable place is possible and the typical case of key material
99.
by raggi 10mo ago
Do you have actual evidence of this? What ASN operates this way?
100.
by raggi 10mo ago
This seems like it might be expensive (though plausibly complete), so I wonder if it’ll actually benchmark with a low enough overhead to be practical. We already struggle with a lack of optimization in some of the named target use cases - t
101.
by raggi 10mo ago
It doesn’t but the problem space is more constrained as you are at least in control of heap vs stack storage. Register clearing is not natively available though. To put it more simply: yes but you can write this in rust- you can’t write it
102.
by raggi 10mo ago
It is fundamentally not possible to be in complete control of where the data you are working with is stored in go. The compiler is free to put things on the heap or on the stack however it wants. Relatedly it may make whatever copies it lik
103.
by raggi 10mo ago
Resumable “at least once” pub sub would be exactly the same architectural semantics as a more complete SSE implementation. A server would keep a buffer of events and a cursor keyed by some kind of event id. Resuming clients would reattach o
104.
by raggi 10mo ago
Sure, you drop an active arena pointer into TLS and allocate out of that then pop and free it once you pop the stack. Producing API guarantees that all incoming references are dead before you do that though, that's the real trick.
105.
by raggi 10mo ago
It's not, but joining the two comments together sync.Pool is often close to what you want for a subset of cases, and it's sort of a locality biased generational storage (without actually providing you strong long-term guarantees t
106.
by raggi 10mo ago
Yes, there's a case to be made that exposing "real" pointers in a GC'd language was a substantial mistake, but I guess it simplified _some_ parts of FFI. The trade-off so far maybe is fine, but it is a shame that there a
107.
by raggi 10mo ago
> You can do fully manual memory management in Go if you want. The runtime is full of tons of examples where they have 0-alloc, Pools, ring buffers, Assembly, and tons of other tricks. The runtime only exposes a small subset of what it u
108.
by raggi 10mo ago
Not with good measured performance no. There are some which advertise good numbers (such as high refresh rates) but are unable to drive the panels to visibly change pixels at anywhere near the refresh rate.
109.
by raggi 10mo ago
That first sentence though. Bitfields and ABI alongside each other. Bitfield packing rules get pretty wild. Sure the user facing API in the language is convenient, but the ABI it produces is terrible (particularly in evolution).
110.
by raggi 10mo ago
If it was being removed the title would be "An update on rust in the kernel"
111.
by raggi 10mo ago
Thanks for following up here. I’m glad to hear the OEM stuff is ongoing that’s going to be so big. Congrats and good luck!
112.
by raggi 10mo ago
Some considerations can be similar, but the total set of details are different. It also depends which lock free solutions you're evaluating. Some are higher order spins (more similar high level problems), others have different secondar
113.
by raggi 10mo ago
> Spinlocks outside the kernel are a bad idea in almost all cases, except dedicated nonpreemptable cases; use a hybrid mutex. Spinning for consumer threads can be done in specialty exclusive thread per core cases where you want to minimi
114.
by raggi 10mo ago
Yup, your example was fine, as I said I just wanted to show a safe method too :-)
115.
by raggi 10mo ago
Their contributions upstream go way back, I think someone could misread this comment that they've not contributed, and that would be an unfortunate misunderstanding.
116.
by raggi 10mo ago
OP you keep comparing to doesn't even declare the variable. I'm done with you.
117.
by raggi 10mo ago
> I don't think that's a fair comparison. Fair? > OEMs have quite a lot of extra steps before releasing any build to the public. AIUI updates are less stringent and burdensome than initial certification. Regardless much of t
118.
by raggi 10mo ago
I agree precise tracing GC's are a huge mess of integration so making them pluggable is likely a pain. I think I'm fairly down on the notion of tracing GC's though and I'd rather have other lifetime tracking mechanisms.
119.
by raggi 10mo ago
Understaffed gift product wants 1 week cycles. OEMs want 2-4 month cycles. This is a perfect representation of the state of the software industry.
120.
by raggi 10mo ago
use std::sync::Mutex; fn main() -> Result<(), Box<dyn std::error::Error>> { static PEDANTRY: Mutex<u64> = Mutex::new(0); *PEDANTRY.lock()? += 1; println!("{}", PEDANTRY.lock(

More ›