311–320 of 385 posts
Earlier quoted context omitted.
No, in this case it pretty much does boil down to Rust or C++. This is a low-level tool, not a webapp.
That still gives you Lisp, Ada, Go, Haskell, and Java, if you make the (imo incorrect) assumption that "low level" tools can only be written in languages which compile down to bytecode. Of course, Mercurial gives lie to this assumption.
Earlier quoted context omitted.
There really isn't a hoop tp jump through... Everyone uses homebrew, which happens to work extremely well (to the point where it's apparently being ported to linux now – go figure). With the homebrew git installed, the stars really have to align for that vulnerability to be exploited. You can possibly get a user to clone from your repository. But if you can also get him to use the git version you want, we're at the p…
> Also: I'd hate if I had to fiddle around with kernel parameters to get printing, sleeping, networking, waking, font-displaying, account-switching, video-playing, time-knowing or up-backing to work every time canonical decides it's time for a new subsystem. I love linux on the server, but maintaining a function desktop system is simply a waste of time. A somewhat evil waste of productivity, actually, because it feel…
I don't get the idea that Mac users are attracted to the system because they cannot handle windows or linux – they just don't want to. Isn't it kinda obvious that the stereotype can't survive when you see >3/4 of all google employees using Macs?
But hey, maybe I should write an App that randomly introduces bugs into my stack to finally learn a bit more about it. And when my car breaks down, I'll be thankful for the learning experience.
Earlier quoted context omitted.
There are many arguments to be made in favor of C++, such as talent availability, experience from other porting projects, the possibility of doing incremental porting, etc. My impression is that some projects are already experimenting with or using C++ in their C code bases, so C to C++ is quite likely.
Incremental porting is possible in Rust. There are a few ways to go about it, and it is pretty easy to link Rust and C code together.
However, using C and C++ together in a project is especially easy. If I were to do this, I would first get the code base compiling with a C++ compiler (this already brings some extra type safety) and is not particularly difficult.
Then I'd start replacing C code blocks with safer C++ code. This could mean changing a function, some parameter-passing conventions, replacing char* with std::string, etc.
This has the biggest chance of success I feel, and there's already success stories and strategies available that describe this method. E.g: GCC.
Earlier quoted context omitted.
No, the dev tool binaries are magic binaries that check if the "Command Line Tools" package is installed, and if not, asks you if you want to download it. They're protected by System Integrity Protection, so you have to temporarily boot with that disabled to remove or modify them. I think it's a fairly common measure to download a lot of what OS X comes with over homebrew, simply because OS X's versions tend to be an…
That sounds annoying.
Earlier quoted context omitted.
With the ability to modify .bashrc, you have execution right to the machine. If not before, to modify the file, then after, because you modified a shell script that is automatically run all the time. Thr machine is already pwned, and one privilege escalation bug away from being completely lost. With this level of privileges, you can, on any machine, mask existing binaries with whatever you want. It is hardly related…
> With the ability to modify .bashrc, you have execution right to the machine. You have the user's execution rights only; you don't have root access. > Thr machine is already pwned, and one privilege escalation bug away from being completely lost. This is true of any program the user runs. The fix is for the user to not run untrusted code. Trusted code should not be modifying .bashrc without the user's knowledge. > W…
That is also what I said - code execution. Like the git RCE gives you. But, it would be rather redundant to use code execution as a local user to obtain code execution as a local user, no? With .bashrc, it doesn't matter how new your git is, there's no reason to exploit it.
Also, privilege escalation bugs.
> This is true of any program the user runs. The fix is for the user to not run untrusted code. Trusted code should not be modifying .bashrc without the user's knowledge.
Exactly my point. If the .bashrc has been modified in an evil way, as you suggested, you're screwed because someone is executing code as your user, which is usually exactly what they need. Add one privilege escalation, and they can do whatever they want, but that's not really necessary, depending on what they want to do.
In essence, if I can write to a file of my liking on your machine as your user, then I have code execution rights as your user (potentially with a time delay, depending on what I tamper with).
> And the user can unmask them just as easily. It's not at all the same as having root access.
Exactly, like installing a different version of git with homebrew and masking the old one. Also, privilege escalation bugs. I think you're forgetting how common they are. A decent set of privilege escalation bugs is part of any decent hackers toolkit.
If someone modifies .bashrc, as you initially suggested ("Not really, they just need to be able to modify a single file owned by the user (.bashrc), or just the current shell session (again, with a variable owned by the user)"), then the git RCE is redundant, as you already have obtained code execution on the machine.
Earlier quoted context omitted.
C++ is far safer than C precisely for the reasons listed. The standard is safe by default (it's not opt-in). If you want or need backward compatibility with C, then you can use the more error prone C constructs for that. Otherwise, pure C++ code is safe.
It is opt-in, because it depends on the STL, which many shops forbid. I have always been on the C++, in the C vs C++ wars, but I am also aware of all those developers that just code C with a C++ compiler, hence opt-in.
Earlier quoted context omitted.
> Tricking you into using the old version would require execution rights on the machine Not really, they just need to be able to modify a single file owned by the user (.bashrc), or just the current shell session (again, with a variable owned by the user). Re-ordering `/usr/bin` and `/usr/local/bin` in $PATH isn't that hard.
I would argue it's not even that difficult. In the README.md, put some kind of note that there's a bug in the current version of git (and maybe point to some random Google group posting) and mention that on OS X it's better to use the XCode version.
I don't think you'll ever be able to help people that follow internet advice blindly, for these people, it might be better not to bundle anything at all.
Earlier quoted context omitted.
I'd like to point out, however, that installing a new version of git is not in any way blocked by either Microsoft or Apple. If you install git with homebrew, you get the newest version, which will take precedence over the Xcode variety unless you mess with your $PATH. Tricking you into using the old version would require execution rights on the machine. You can also remove the /usr/bin/* binaries if you boot the mac…
Imagine that you are a corp IT and managing a fleet of developers with Macs. You can push a newer version of git to them, and you can even change their default PATH so that the version of git you pushed are before the git comes with Apple. But you still cannot remove the one comes with Apple, and you cannot prevent it from being used.
I'm not arguing that it's okay that Apple bundles an affected version of git, but if they start undoing what you did to protect them, I don't think they can be helped. I'm a bit pessimistic in this sense, but I keep getting surprised by the kind of crap that makes their way onto peoples machines, sometimes people that really should know better.
Earlier quoted context omitted.
Incremental porting is possible in Rust. There are a few ways to go about it, and it is pretty easy to link Rust and C code together.
Most languages have some C interop, and that satisfies the minimal definition of "incremental". However, using C and C++ together in a project is especially easy. If I were to do this, I would first get the code base compiling with a C++ compiler (this already brings some extra type safety) and is not particularly difficult. Then I'd start replacing C code blocks with safer C++ code. This could mean changing a functi…
I'm not suggesting that C -> Rust is easier than or quite as easy as C -> C++, just that it is much easier than C -> most other languages, and that it is close enough to C -> C++ that it is worth investigating. It is definitely more robust than the minimal definition of "incremental."
Earlier quoted context omitted.
> just restrict filenames to 255 bytes and nesting to 255 levels, which limits paths to 64KB at most. Anyone trying to use git repositories exceeding either of those limits should be considered insane. Funny, because I've actually been locked up for being insane five times. Speaking from experience, they'd only consider me insane if I said something like 255 was an important number because there are two sides to ever…
As someone who has also spent time in a mental institution, I just want to say that I really think you need to be less sensitive on this one. That's just an expression and not in any way aimed at people who have mental illness.