It seems enough people appreciated the story to upvote it though... but that assumes HN's algorithm is fair, it's free of bots, and the people voting are critical and honest on what they upvote.
In my opinion, it boils down to what ideas/experiences were seeded.
In this article for example, the author is clearly sharing their first-hand experience, therefore injecting observations from reality and their own reflection on top of it, and they then probably shaped/refined it with AI.
A slop, as I see it, is when you generate content from a very thin prompt and then share it as is.
A few things, Zookos conjecture dates to 2001. It was an observation, not a formal proof of anything, nor a physical limit, as he said in the paper: "I didn't prove that it is impossible to have all three features"
So without conflating Zooko with all the commentators who followed saying, "but Secure meant ...", lets look at the real definition from Zooko:
1. distributed (in the sense that there is no central authority which
can control the namespace, which is the same as saying that the namespace spans trust boundaries),
2. secure (in the sense that name lookups cannot be forced to return incorrect values by an attacker, where the definition of "incorrect" is determined by some
universal policy of name ownership),
3. and having human-usable keys.
So the system we are building (I am the architect) Satisfies all 3. I went and added a fourth, which is privacy. I say:
4. Private (Whereby a scan of the name registry does not reveal the human readable names).
I think 4 is a necessary property to mitigate CT log like reconnaissance feeds being used by threat actors to enumerate every registered identity for the purpose of automated attacks.
Hello! I am a Debian Developer, though not likely to work on this as I haven't done a ton of rust binary packaging.
I did want to clear up one misconception that you might be having, though. The .deb versions shipped by upstream are great, but they're not really ever going to be useful for Debian. One of the side-effects of Debian's requirements around software freedom is an important principle: you should be able to build any package in Debian with only the things that are in Debian.
The problem with fresh isn't fresh itself -- packaging that isn't particularly difficult, though it does need some amount of care and attention. The problem is that fresh pulls in 732 different crates which all need to be packaged in Debian before fresh can be. Some of them are already in Debian, of course, but... you can imagine that the effort here is very much not insignificant.
Upstream doesn't have to deal with this problem, as they can simply statically build them into the executables. That's a violation of Debian policy, though, and isn't allowed for anything in the archive.
Hope that helps you understand why you may not get many bites at this offer, generous as it is!
The problem that Debian has with rust packages is that they try to apply handling a C-style dependency chain (usually only a few C libraries with large scope) for the rust crate ecosystem (a lot of dependencies with small scope).
Having to maintain 732 just for one release of a new package is not sustainable.
I don't understand why the policy is not: pulling all crate sources and prepackaging into a tar with associated licenses.
The source tree then is part of the package which can still be built from source and gets linked statically.
Security is part of it -- dpkg and apt were not built to deal with the problem of tracking each individual executables' complied library versions. When the next Heartbleed happens, how will you know which things need to be recompiled? (Some of this data exists in adjacent Debian systems for DD's internal use, but it's not integrated into dpkg in any way.)
I think this is a fine description, and respect your reasoning! I think there is in this case, no conflict: Keep the OS-managed packages strict about dependency security, and let the user run the .deb or compiled program Fresh (or whatever software) has provided. So, I think your (Debian perspective), and Fresh (Providing binaries for download, including as a multi-linux script) is on the simpler/easier/just-works end of installing software. No conflicts. Single-CLI line install either way.
Yes. For about 98% of embedded, you want the pinout for the TC2030-FTDI-C232HD-DDHSP-0-DTR cable that has DTR and RTS on it for STM32, ESP32, and Arduino-style bootloaders. It's 3.3V only iirc. Power is delivered by the cable on pin 1 so leave that terminal disconnected if it's an issue.
You can "break glass" and get the off the shelf cable delivered overnight (and you can spec it if you need a spec cable) or you can make an adapter for the 6-pin tag-connect cable and the TTL-serial adapter that you have.
That's true... for the exploit demo that they released. The primitive that underlies the exploit, however -- a page cache write -- can easily bypass the container boundary. One only needs to hook an executable which is also present in the host.
In fact, the authors specifically say on the very first line of their website that the copy/fail primitive can be used as a container escape. The entire premise of this article is flawed and irresponsible.
> if libraries or binaries are shared (read-only) between the host and container.
Yeah, exactly - that's a pretty big "if", and not how a lot of container automation does things. In particular you'd need to hit the base system, it's no help at all if some application files that the host does nothing with can be hit.
It's not hard to see ways to escape the container with a cache write primative. I suspect the copy.fail team have held back on releasing a POC because of the disruption it could cause.
It's not a cache write primitive though; it's a write-to-readable-mappings primitive. At least the way I understood it is, you need to be able to get a (read) file descriptor to the target in order to throw it into the splice() syscall.
Now, there are some "funky" no-fs things that could be opened and are mmap'able/spliceable (some stuff in /proc/*, no idea what exactly though), but it's not immediately obvious to me how this is a generic container escape.
reply