Live data from Hacker News

Remote code execution, git, and OS X

rachelbythebay.com

261–270 of 385 posts

Re: Remote code execution, git, and OS X

#261
post #247

Earlier quoted context omitted.

But if the goal of the rewrite is safer tooling then Rust wins.

Or Python, or Ada, or Ruby, or Go, or Java, or Lisp, or any of the myriad of other memory safe programming languages. When it comes to memory safe languages, your choices do not boil down to "Rust or nothing".

No, in this case it pretty much does boil down to Rust or C++. This is a low-level tool, not a webapp.

Re: Remote code execution, git, and OS X

#262
post #4

Remember when I said El Capitan? Apple is doing something new which basically keeps you from twiddling certain system-level programs without going to fantastic lengths. Not even root is enough to do it. Can someone explain it to me?

CoreOS also does this, much of the base system is mounted read-only.

Re: Remote code execution, git, and OS X

#263
post #247
post #188

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.

But if the goal of the rewrite is safer tooling then Rust wins.

The goal is writing safer code, but that also comes with some costs. The interesting question is which costs can the project afford.

Otherwise yes, it could even be rewritten in Ruby, as falcolas suggested...

Re: Remote code execution, git, and OS X

#264
post #256
post #229

Earlier quoted context omitted.

I agree with you, the only problem being that even in 2016 there are shops that prohibit the usage of STL. The real way out is to eventually change to a language where safety is opt-out and not opt-in, like in C++.

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.

Re: Remote code execution, git, and OS X

#265

Earlier quoted context omitted.

Disable it, reboot, fix the problem, reboot again with it enabled. Big f'ing deal. I'm far from a fan of Apple's protectionism, and yet this doesn't seem like anything to be up in arms about.

The core issue is that the system is vulnerable in its default configuration.

It's not, in it's default configuration there is no xcode so there is no git.

Re: Remote code execution, git, and OS X

#266
post #201
post #164

Earlier quoted context omitted.

Claiming this isn't a hoop to jump through is Apple fanboyism at its best.

Really? Talking about how homebrew is pretty painless is "Apple fanboyism at its best?" Sure it's another thing to do, but look at any thread about running Linux on a laptop. How many people are like X laptop runs great you just need to add Y kernel parameter to the boot options. Isn't that a "hoop to jump through" too? Or all of the people fighting to keep their Windows install from upgrading to Windows 10. Isn't th…

Comparing with the hoops Linux or Windows require you to jump through doesn't make this less of a hoop.

Re: Remote code execution, git, and OS X

#267
post #164

Earlier quoted context omitted.

Claiming this isn't a hoop to jump through is Apple fanboyism at its best.

Would much rather have a system that just worked but required a "hoop to jump through" in order to use git, vs the multitudes of hoops you have to jump to in order to get a Linux desktop system functional in a corporate environment. At home when I'm futzing around I don't mind (and quite enjoy it). But at work I don't have time to diddle my device drivers and OMG the xorg.conf crap I had to deal with in the past that…

I agree. But that doesn't make this less of a hoop.

Re: Remote code execution, git, and OS X

#268
post #255

Earlier quoted context omitted.

And as has also been asked - why do they symlink to the /usr/bin directory in the first place then? They have three perfectly reasonable directories they can install into, which is what they recommend that application developers do when installing their software: /Applications /Library /usr/local So why do they feel the need to link git into /usr/bin? They could link it into /usr/local/bin - the $PATH variable includ…

There are no symlinks in /usr/bin, they are wrapper programs determining whether you already have the Command Line Tools or full Xcode installed. If not, they will open dialogs asking you to install these additional software packages.

[deleted]

Re: Remote code execution, git, and OS X

#269
post #255

Earlier quoted context omitted.

And as has also been asked - why do they symlink to the /usr/bin directory in the first place then? They have three perfectly reasonable directories they can install into, which is what they recommend that application developers do when installing their software: /Applications /Library /usr/local So why do they feel the need to link git into /usr/bin? They could link it into /usr/local/bin - the $PATH variable includ…

There are no symlinks in /usr/bin, they are wrapper programs determining whether you already have the Command Line Tools or full Xcode installed. If not, they will open dialogs asking you to install these additional software packages.

And if you do have them installed? What does it do then - invoke git?

Re: Remote code execution, git, and OS X

#270
post #261

Earlier quoted context omitted.

Or Python, or Ada, or Ruby, or Go, or Java, or Lisp, or any of the myriad of other memory safe programming languages. When it comes to memory safe languages, your choices do not boil down to "Rust or nothing".

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.

Post reply on HN