Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Remote code execution, git, and OS X

rachelbythebay.com

Post reply on HN
Print view View original

221–230 of 385 posts

Re: Remote code execution, git, and OS X

#221

Post by blub »

lmm wrote: post #192
blub wrote: 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.

My impression is that projects that mix C and C++ tend to use the C-like subset of C++ (with classes), so they wouldn't gain any safety advantage from moving to C++. Many other languages support C linkage in a way that's comparable to C++.

Using std::vector, std::string and smart pointers would already bring large benfits, so even a C-like subset could work fine.

The point is that code like in that function is a nightmare to write correctly and test in plain C.

Re: Remote code execution, git, and OS X

#222

Post by fauigerzigerk »

mjn wrote: post #70
fauigerzigerk wrote: post #67

Earlier quoted context omitted.

Why does debian do that instead of upgrading everyone to the latest git version?

Debian 'stable' releases mainly target people who like fixed upgrade cycles. No feature/API/etc. changes for the lifetime of a release, only security patches. Means that you can have your servers routinely applying updates with relatively little worry that something is going to stop working because of a change. Even minor feature changes can break things, especially when run in scripts, so they prefer not to risk non…

The problem with this concept of "stability" is that it depends on a particular software development philosophy that isn't shared by all projects.

It works well if developers make sure that bugs in older versions of their software are fixed even after the next version is released. I think that is the case with a lot of infrastructure sort of software.

But if developers do not maintain old versions and fix bugs only by releasing a newer version of their software, then debian's approach leads to stability only in the sense of a reliably buggy system.

Re: Remote code execution, git, and OS X

#223

Post by kccqzy »

joushou wrote: post #193
blub wrote: post #190

Earlier quoted context omitted.

Yes it would, because this is basically string processing where C is the worst possible language one could use. I've detailed in another comment how std::string could be used.

You're talking about naked char[]. You can just as easily make a struct{ int len; char* str; } in C, and combined with the "n" variants of string operations, would work just fine with common tools. Again, C++ does not make anything safer, and its types can easily be replicated in any other language.

I believe this is called pascal style strings and GCC has builtin support for it.

Re: Remote code execution, git, and OS X

#224

Post by acdha »

chris_wot wrote: post #213
acdha wrote: post #208

Earlier quoted context omitted.

They didn't change the user experience in any way - most updates do not require a reboot, the ones which do are fast - so I'm guessing that the kernel checks the code signature on the process doing the write when deciding what to block and possibly even requires a valid Apple signature on the new file.

Yeah, it's looking increasingly that way. I'd still love to know their thinking behind put git into a directory that SIP makes deliberately hard to update! I mean, git is additional software and not even part of their base operating system, my understanding about SIP was that it was meant to prevent people from tampering with the underlying system software and installing rootkits. git (and ssh for that matter) aren't…

I think the idea is that they protect everything which they ship, so you can add other things but not replace Apple-provided components.

From a sysadmin's perspective this makes a lot of sense: beyond malware, I've seen security and stability problems caused by installers from large companies, developers cowboying up with “sudo make install", etc. but it definitely puts the onus on Apple to ship updates promptly.

Re: Remote code execution, git, and OS X

#226

Post by pjmlp »

lmm wrote: post #192
blub wrote: 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.

My impression is that projects that mix C and C++ tend to use the C-like subset of C++ (with classes), so they wouldn't gain any safety advantage from moving to C++. Many other languages support C linkage in a way that's comparable to C++.

That is my feeling as well.

I do like to use C++ a lot on personal projects, but there I can make full use of C++ best practices.

At work, I tend to avoid using it, because most C++ developers I have met on my career, actually use it as Better C, keeping all safety loopholes from C.

I had my share of spending weeks tracking down memory corruption issues.

Re: Remote code execution, git, and OS X

#227

Post by fabulist »

chris_wot wrote: post #159
fabulist wrote: post #16

Earlier quoted context omitted.

I disagree that it is clickbait. There is a schema people use for announcing security vulnerabilities (" in version through "), and the RCE issue was recent, so to those familiar it was clear that it was exposition rather than disclosure. For those unfamiliar, now you know

Rachel is a widely known and reputable author. I doubt she aimed it as clickbait.

People on HN seem to have forgotten clickbait is directly related to ad revenue, and use it in lieu of "sensational."

Re: Remote code execution, git, and OS X

#228

Post by pjmlp »

joushou wrote: post #193
blub wrote: post #190

Earlier quoted context omitted.

Yes it would, because this is basically string processing where C is the worst possible language one could use. I've detailed in another comment how std::string could be used.

You're talking about naked char[]. You can just as easily make a struct{ int len; char* str; } in C, and combined with the "n" variants of string operations, would work just fine with common tools. Again, C++ does not make anything safer, and its types can easily be replicated in any other language.

Being possible, doesn't mean the majority of C developers make use of it.

The "n" variants are a joke in terms of security, even the C99 annex, that was demoted to optional in C11.

I call them a joke, because tracking the pointer and length separately is hardly an improvement in terms of security.

The only improvement that the "n" variants added is that the null character is always added to the end, instead of how strncpy does it, by only adding the character if there is enough space.

Re: Remote code execution, git, and OS X

#229

Post by pjmlp »

blub wrote: post #221
lmm wrote: post #192

Earlier quoted context omitted.

My impression is that projects that mix C and C++ tend to use the C-like subset of C++ (with classes), so they wouldn't gain any safety advantage from moving to C++. Many other languages support C linkage in a way that's comparable to C++.

Using std::vector, std::string and smart pointers would already bring large benfits, so even a C-like subset could work fine. The point is that code like in that function is a nightmare to write correctly and test in plain C.

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++.

Re: Remote code execution, git, and OS X

#230

Post by ascagnel_ »

pyre wrote: post #201
efdee wrote: 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…

Installing homebrew is a hoop; in an ideal world, your OS vendor would provide a means for installing such packages safely (the Mac App Store would count if Apple cared about it).

This is also a bit weird since getting git installed on OSX in the first place requires it's own hoop: "buying" the free copy of XCode and installing it is required for the command line tools that homebrew relies on.

Post reply on HN