i wonder if it's about protecting it from extraction/distillation or if it's about not having to answer for surface that hasn't been properly vetted for public consumption. (ie, is someone going to sue them or complain or write blog posts because the thinking has transient things that people don't like where the final result is what is actually vetted?)
i agree with the author. i argue a preference for loose coupling over centralized abstractions. sure it's pleasing to compress the code, but if the use cases actually are sufficiently divergent (as well as bugs and externally driven changes) ultimately it becomes brittle, littered with edge cases behind if fences and both challenging and daunting to change.
ideal case: support libraries and then very simple duplicated code that is easy to read and modify. critically the core control flow should remain duplicated, but simplified by the support libraries.
my first reaction: this pivot makes no sense at all to me.
my second reaction: maybe it does? did they hire up an army of physicists to make better diffusion models or something and they actually have people on staff who can do this?
that's how i understand it. it's a portfolio with front matter, back matter, the papers that got published with some connective tissue between them and maybe some discussion of the things that didn't work out and why.
I saw those and got excited; I've been using Mathematica for decades and do a lot of work with symbolic music.
Unfortunately they are extremely surface level in this release. It looks like there isn't even any ability to load/export MusicXML, kind of weird low level primitives and zero interesting higher level functions. Hopefully they keep iterating on it but I don't think it'll be useful for my workflow right now.
Sometimes you want to do something that curl cannot express, e.g. timing, protocol oddities, etc. For example you may want to issue a CONNECT to an echo server through a proxy and observe the bytes flowing back and forth. You may want to see what happens when conflicting hop-by-hop headers are specified without worrying about the client's (curl's) interpretation of them. A simple nc -c (or openssl s_client -crlf) lets you do all of that.
Ah, I see what you mean. Aside from putting the proxy into debug logging one would have to use curl -vvv to get similar details but I suppose whatever works best with muscle memory is the right choice and one may not always have access to put the proxy into debug logging.
I need to try this with a Squid SSL Bump MitM proxy just dont have one up at the moment.
curl -vvv -A Mozilla -H "Accept-Language: en_us" -H "Sec-Fetch-Mode: navigate" --url 'https://nochan.net/.env'
Note: Telnet is not completely plaintext and has control characters in the upper byte range (like 0xff or something, I forget).
Use nc or this TCP Bash technique if you really want to ensure decent compatibility when doing hacky solutions, otherwise a random 0xFF somewhere from a terminal console color change (or other control character) might really screw you over.
Is it the reply to ‘HELO’ that enables things like tarpits?
Like if my server replied with ‘HI PLEASURE TO MEET YOU 127.0.0.1 THAT NAME SOUNDS FAMILIAR ARE YOU BY CHANCE FROM BOSTON MY MOTHER IS FROM BOSTON WELL QUINCY ACTUALLY BUT DO YOU KNOW 127.0.1.1 THEY ARE A REALLY GOOD FRIEND OF MINE YOU SHOULD MEET I HEAR THEIR DAUGHTER IS A DOCTOR DONTYAKNOW AND YOU COULD…”
For SMTP tarpits you can do all kinds of fun stuff. Not just in the reply to helo. Like: always be slow to respond. Respond to each command with a temporary error. Accept everything, then pause, then error. Send back large chunks of garbage.
the '90s version of finding the hiring manager or boss on linkedin to try and get a job was connecting to the company's public smtp server with telnet, using their name to probe different email address patterns with "rcpt to:" (those days the actual servers were often directly connected to the internet and would leak email address validity in how they would respond to rcpt to) and then sending them a nice email.
smtp grew up to be an antisocial curmudgeon. extended smtp starts with EHLO.
yeah, i think you're right. i originally read a bit of snarky blow-off, like "eh?" ... but you know, now that i think of it, it's actually does have more of a friendly canadian style vibe.
Sometimes I don't understand why people use those most tiny of images, at least for anything that they might ever ssh into.
When there is no corresponding level of restraint in the libraries that we add to most applications, does it really make a difference to leave out the likes of curl, nano, ping, etc compared to how frustrating it is to operate in just busybox (etc)?
I'm not just ranting, I'd actually like someone who swears by always shipping alpine images (etc) and never installing any basic utilities in them to share their reasoning.
i read all the pkgbuild diffs, still doesn't give me a good sense. sure, i can verify that it's coming from the official repo but even then there's no guarantee that there isn't junk in there or that the git ref is actually pointing at the right thing.
it would be better if there were stronger community moderation and review that has stamps i can trust rather than this idea that eyeballing build scripts is a reasonable security posture.
> it would be better if there were stronger community moderation and review that has stamps i can trust rather than this idea that eyeballing build scripts is a reasonable security posture.
Ok, so instead of having a reasonable security posture yourself, you'd rather rely on a number of random strangers who've eyeballed the PKGBUILD instead?
Generally, I think Arch tries to prevent users from relying on bad signals, and this principle might be applied here too.
> i read all the pkgbuild diffs, still doesn't give me a good sense. sure,
Do you have an example of a diff that doesn't give a good sense? I review all my diffs too, but I feel like all of them give me a good sense if it's safe to install or not. I mean, why would I otherwise, what's the point in reviewing if you don't use it to make a decision if to install it or not?
pretty much all of them. the diffs only really show that it's coming from the same source, the changed hash and maybe some urls for some patches. actually looking at what is in that changed hash is a much more complicated story. this gives end users a false sense of security ("i read the diffs" -- not really), and attackers a clean vector (all it takes is one bad commit that might not even be on a real branch, or linked patch or late download dependency in the package itself).
> the diffs only really show that it's coming from the same source
What else do you have to review? Both in the cases of binaries and source, the idea is that you trust upstream already, otherwise you shouldn't install software from them. And since you trust upstream, the only thing you need to review in the PKGBUILD is quite literally: Where is this stuff coming from, is it the official domain/repository? Are there other non-official dependencies? Are there patches applied?
Once you've reviewed those, you're done, and as safe as if you installed straight from upstream, zero false sense of security here.
You're mixing concerns here, as what you describe is completely different issue.
blindly trusting upstream is not really a reasonable posture. that is pretty much the source of all software supply chain attacks.
there is work involved in figuring out how to get the complete diff of the code and dependencies that are included in the change, plus review time. this could range anywhere from 5-10m to 1h per package updated- if not more.
Well ArchLinux has a product for you if you want packages that were vetted: the official repositories.
AUR is just a centralized place to put user created packages, like npm is a place to put user created node packages.
two scenarios i could think of where there's additional risk for bio/nuclear weapons 1) basement lab leaks and 2) improving quality of execution for shops that are already resourced enough to hire experts but maybe they're not that great.
i think the correct answer is probably to funnel more money to global (bio)security initiatives and maybe use ai leverage as a way to get more of the world on board. (some kind of access to nvidia or cloud ai or whatever in exchange for policy commitments deal- while that leverage lasts).
reply