theamk
For personal services, even something as simple as HTTP basic auth on the webserver dramatically reduces the attack surface by blocking all probers and drive-by attacks.
The variable alone, however, is kinda suspicious - I'd do both variable and command-line flag, just for extra assurance.
(another idea might be to enforce docker, but I know some people run agents in VMs, so this won't work)
As someone who walks on the streets / uses public transport, Waymo was 100% in the right there. Wish all taxi services were like that.
Those protections exist and cost money - both to pay for customer support handing those, as well as to reimburse customer when the original money cannot be found anymore.
(And related, this is one of the big problems with cryptocurrencies: most people are not happy to know that one typo / software bug means their money is lost forever. Those protections on regular baking are there for a reason.)
But would anyone do this? No. If you are writing pool-based packet processor in Python, you'd deal in buffers (safe from overread), in C# you'd return Span/Memory (safe from overread) and only in C you'd return overread-prone raw pointer.
Not that you can blame programmers in this case - C simply lacks the facilities for safe memory access, such as bounded pointers or spans. And you can't really blame it on custom allocator - malloc() would have had the same problem.
Every language has a preferred way to deal with things. In C, it's raw pointers, which are very error prone. Other languages have something better. For example, if you were to implement custom allocator in C#, would you return raw pointer? Or maybe base array + offset pair? Of course not, you'd choose a Span or Memory, and those are not prone to buffer overruns.
Your solution for using unreliable Wikipedia is to cite it. My solution (and the way I was taught) is to simply _never use it_ for stuff which goes into the paper.
If I wanted to claim something ("widgets are quux"), I might certainly _start_ with Wikipedia, just to make sure that my understanding is correct and that I am not wasting my time, but if I want to use this in the paper, I will need to move to primary sources, read them and ensure that there is a good evidence that widgets are indeed quux.
So now that I spent all that time reading primary sources, I'd certainly cite them and not Wikipedia - after all, primary sources are better, and a single citation is enough. And in the case the Wikipedia author was wrong, I will avoid a mistake.
By extension, if I am citing Wikipedia, this means I have not found/read any better sources, and that just shows that I am lazy or maybe those widgets are not quux at all. Any advisor/reviewer would immediately point to this mistake - "Why are you citing Wikipedia here? Find a better source or remove the claim"
And that's how the rule is made - it's not "Don't cite Wikipedia [put ideas unattributed instead]", it is actually "Don't cite Wikipedia [find a better source and cit it instead]".
(Although I agree that some lazy people do former rather than latter)
(And sure, there are escape hatches - like Python has "recv_into" that could be used to implement heartbleed if you are really inclined to - but this would not be a realistic python program. In python, even with buffer reuse, you'd be using memoryview or similar that can't have a heartbleed problem)
In the research, there are often long paths that lead to the ideas: lunch room conversation -> paper 1 -> web search on term seen -> paper 2 -> web search on another term seen -> wikipedia page -> another wikipedia page -> original source (paper 3) -> paper 3's citation list -> paper 4 -> fact for your own paper
We always cite only the very last item in the chain, paper 4. I'd might cite other papers I've seen, but only if they are relevant. I was taught that the tertiary sources, like encyclopedias, are never to be cited, unless they have original facts which cannot be traced to other sources.
(And then proxying via your home is much faster and safer. You can do websocket-based proxy, but even exposing ssh server on port 443 works in a lot of places!)
(Just don't turn on ForwardAgent)
2>/dev/null && echo nopass || echo maybe) || echo none)"
A human would simply run the two commands in sequence and parse errors on the remote side - this would have gave more information about unexpected errors.
I remember Obnam being retired in 2017[0]. I was evaluating backup systems back then, and went to borg (and later to restic). But turns out, it came back 2020. I like the motivation [1]:
> Borg and Restic are both fine backup programs. I've been using Borg for a while. The point here for me is that I find implementing backup systems to be a fascinating hobby. Thus, I want to write my own. The act of developing being the point more than having something I can use myself. Everyone else should use something battle-tested, unless they want to help me build something they'd like to use themselves.
(sadly I have not found nice website with newer version photos yet)
I never did this myself (except while learning how to drive). And I don't think I've heard about my friends doing this either. Turn around because the road was impassable? Sure. Pass the wheel to someone else? nope.
That means a lot (most?) human drivers are "level 5 autonomous".
This is amazingly naive. C has significant amount of problems, and while OOB array accesses cause a lot of bugs, there are plenty of other C parts which cause bugs too (like use-after-free and concurrency). And even if we just focus on the OOB array accesses, there are a lot of places which cannot be covered by simple counted_by()
Wasn't the whole point of smart contracts that the "code is law", that people can audit the code they put their money into, and no one can change it?
If you are going to put the backdoors in, might as well do the regular finance. Much cheaper, no gas fee, more functionality and so on.
Something of the note: despite the scary name, this is a "parsing mismatch" vulnerability. The discovery what was that one could make a tar file which would safe in the "tar" tool, but when extracted by an affected rust crate, it would find more files, possibly malicious. By itself, it's fine - if you are extracting untrusted tar files without the filter, you are going to have a bad time, vulnerability or not. The vulnerability would only occur if you have a combination of files: like a security scanner which uses one library, followed by the real app which uses a different library. Then the bad code could escape security scanner's attention.
So the role of school is to make sure that the kids have everything they need to reach their potential.
This ordering requires defining the scope, and the narrower the scope, the easier it is to compare people. If you only look at "maintain the rented city apartment" and "live in rural house" in isolation, it's pretty easy to rank people by independence. But if you say that _either_ of those counts as "independence", the things get much harder to qualify. But either way, there will be people who can't do anything, people who can do everything, and a large mass of "uncomparable" people in the middle.
I think you misunderstood the article - it's great to try new things, and it's not a problem to promise things you are not 100% sure about. What's important is the honesty - "I've tried, I've failed, here is what I learned". OP said the the best:
> "Failure" does not have to be a failure, and V itself does not have to be the sole product of V's development. Alex has time and time again promised to write blog articles on various aspects of V's development. Had he done that, instead of silently backpedalling on claims about V, we could have had very interesting reads reflecting on the challenges of creating a new programming language.
instead, we have disappearing claims that require internet archive to find out, denial of any problems, and blaming of every problem on "misinformation from haters".
You don't need to be corporate or in in academia for basic integrity.
To the author: project maintenance is hard work. Your PR might work for you just fine on your machine, but what about other setups? Will your code still work after the next library upgrade? If not, who will fix it? That's why the maintainers can reject any changes they want - they are ultimately on the hook for all that so they are the ones with final words.
SPAM is officially described as UCE, "Unsolicited Commercial Emails". Your emails are both unsolicited and commercial, so people rightfully block it. I know I always click "report spam" when I see an unsolicited commercial email, not just to clean my inbox ("report spam" and "delete" are right next to each other), but to make sure sender's reputation takes a hit and fewer other people get spam email.
If you have sub-projects which cross-depend on each other (no total ordering), then recursive make will have a bad time. I agree.
Author thinks the best way is to stop doing recursive make. I disagree.
IMHO, the best way to solve this is to arrange your sub-projects properly, so the are no circular dependencies and thus there is one correct order. Not only your build should be a DAG on file level, it should also be a DAG on the sub-project/directory level. Then a single recursive "make" pass builds everything properly, no need for ugly tricks like running make twice, or intentionally omitting some dependencies.
(Even better option is to stop using make for such large projects - it's great for smaller ones, but for the huge ones, there are much better runners available. But I assume there is some reason to use make)
(sorry if they in the video - I generally don't watch the videos before reading the text first)
- For ingress, you use special "file transfer" software. Run the receiver on secure side, run the sender on insecure side. It blasts the file "blind" - it has has no way to know if anyone ever received it. Make sure the receiver is fast enough, and the error-correcting codes are a great idea too, as they don't need feedback. It's up to user to want to secure side computer and check that the file was received without problems. Yeah, this is similar to sneakernet, but more secure, as you can't accidentally carry a virus on seemingly-empty drive.
- For status egress, you have secure side broadcast status periodically, say every minute. Insecure side receives the status, updates the database, and runs the regular web server to share the status. Again, secure side has no way to know if someone is listening on the other end, it just blasts out the messages and it's done.
And you are correct, if the secure system has both egress and ingress diodes, it is no longer isolated, and devious enough malware can establish two-way communications. But even if it won't save you from Stuxnet, the simple fact that it is no longer possible to have direct network connection to the outside raises security bar quite a bit - all the ideas about "let's just open this one port on firewall, it'll fine I swear" are completely stopped.
(Which reminds me of something in GP's (mikewaro) message: _why_ would a data diode need a promiscuous mode? Given every single data diode I have seen needs a special software on both sides, you should not need anything beoynd a basic TCP session)
> The technology to eradicate mosquito-borne disease already exists.
One approach is eliminate one specific kind of mosquitoes, another is to change them so they don't carry diseases. Either way, we'd still get mosquito bites.