Forgot your password?
typodupeerror

Comment: No, not quite true. (Score 2) 574

by Myria (#46754055) Attached to: Microsoft Confirms It Is Dropping Windows 8.1 Support

Yes, apple want you to upgrade to iOS 7, but if you don't want to (or can't because your hardware is too old) they still provide security patches for iOS 6.

The last update was iOS 6.1.6 in Feb:

6.1.6 was only released for devices that cannot run iOS 7. If you have a device that can run iOS 7, you had to upgrade to iOS 7 in order to get the important security fix, even if the device had iOS 6.x at the time. There was never an iOS 6.1.6 released for iPad 2 or 3, for example.

If they had released an iOS 6.1.6 for iPad 2/3, it would've allowed downgrading from iOS 7.x to iOS 6.x then jailbreaking, something Apple hates with a passion.

Comment: Chrome's SSL uses a lot of the OS certificate mana (Score 2) 303

by Myria (#46689975) Attached to: OpenSSL Bug Allows Attackers To Read Memory In 64k Chunks

Chrome just uses the operating system for a lot of the certificate validation of HTTPS, so it can be vulnerable to security holes that apply to the operating system. Chrome wasn't vulnerable to "goto fail", but presumably it has been vulnerable to others in Windows and Mac OS.

Comment: One big way in which Git is not SVN-compatible (Score 1) 162

by Myria (#46635791) Attached to: Subversion Project Migrates To Git

(Technically, as Git is SVN compatible, so you could get this effect simply by using Git 'locally'.)

git2svn has a problem that we ran into recently: because git does not support hierarchical branching, if you do not keep all your branches in a single Subversion directory, it will take an excessively long time for a local git repository to synchronize with a Subversion repository.

For example, let's say that you have the typical /branches directory in Subversion. Now user "myria" comes along, and she wants to make her own directory of branches so that her own branches don't pollute the /branches directory. She does an svn copy of /trunk to /branches/myria/new-crypto. Now git2svn tries to import this change from Subversion into a local git repository and takes three hours. Why?

Because git doesn't support hierarchical branch names, from git's naive perspective, what Myria has done is make a copy of the entire repository into a new directory named "new-crypto" inside of her "myria" branch. Git does not interpret her commit as a creation of a branch - it sees "myria" as the branch, and "new-crypto" as merely a directory within the branch. Subversion gives no special meaning to the directory named "branches", so git2svn is simply using a hack of assuming that the "branches" directory contains objects that it can convert into git's branch objects. Git thus sees her commit as one giant commit of 100,000 files, and consequently takes forever processing it.

The above was a recently-encountered real-life situation at the office from about two weeks ago.

Comment: Why can't encryption be in the SATA controller? (Score 1) 222

by Myria (#45971575) Attached to: TrueCrypt Master Key Extraction and Volume Identification

Why can't there be SATA controllers with drive encryption support? Your drive encryption program could then just be an expansion UEFI ROM card that prompts you for your password and sends it to the SATA controller, then erases it from main memory. There's no need to do anything else after that point, because encryption and decryption would be completely transparent to all software on the system.

Comment: Re:so does this mean.... (Score 1) 433

by Myria (#45667203) Attached to: Simulations Back Up Theory That Universe Is a Hologram

So this means if a tree falls in the forest and no one was listening, it wouldn't be simulated and therefore would not make a sound. That was easy...

So long as it is provably impossible for anyone to feel or notice the effects of that sound for all of eternity, yes, a simulation could get away with not simulating it. Provable impossibility in our Universe would be something happening outside the light cone of the simulated area.

Comment: If they hadn't locked it down... (Score 1) 293

by Myria (#45544619) Attached to: Microsoft May Finally Put Windows RT Out To Pasture

If they hadn't locked it down, Windows RT could have just been another target to which developers could recompiled their software and that would have kick-started the application ecosystem somewhat. It would have been with desktop applications, though, which Microsoft considers deprecated. Desktop applications also don't work with touch control very well and more importantly don't make Microsoft any money.

It seems as well that Microsoft wanted the locked-down environment to prevent Windows RT from having viruses, an inevitable side effect of open development. Many more people bought the virus-laden Surface Pro than the Surface RT, so maybe people like their viruses =)

Comment: Re: How should we have made it more differentiate (Score 1) 293

by Myria (#45544495) Attached to: Microsoft May Finally Put Windows RT Out To Pasture

They should have just left it unlocked, rather than make us jailbreak it by force. By forcing us to jailbreak, they guarantee that commercial applications never get ported to it.

I guess Microsoft didn't care, because they consider the desktop to be deprecated, something they will remove in a future version.

Comment: Wrong number of atoms in the Universe (Score 2) 53

by Myria (#45440209) Attached to: Experts Hail Quantum Computer Memory Stability Breakthrough

It's about 10^80, not 2^80.

I think we'll find that the amount of energy required to hold X entangled particles in coherence will be exponential in X. This would make quantum computing essentially worthless.

If not, wake me when we get to 2048 qubits, for the original Xbox's public key and I have some unfinished business from last decade...

Comment: These bugs exist even *without* signed integers! (Score 5, Interesting) 470

by Myria (#45275979) Attached to: How Your Compiler Can Compromise Application Security

The first mistake was using signed integers.

The problem is C's promotion rules. In C, when promoting integers to the next size up, typically to the minimum of "int", the rule is to use signed integers if the source type fits, even if the source type is unsigned. This can cause code that seems to use unsigned integers everywhere break because C says signed integer overflow is undefined. Take the following code, for example, which I saw on a blog recently:

uint64_t MultiplyWords(uint16_t x, uint16_y)
{
    uint32_t product = x * y;
    return product;
}

MultiplyWords(0xFFFF, 0xFFFF) on GCC for x86-64 was returning 0xFFFFFFFFFFFE0001, and yet this is not a compiler bug. From the promotion rules, uint16_t (unsigned short) gets promoted to int, because unsigned short fits in int completely without loss or overflow. So the multiplication became ((int) 0xFFFF) * ((int) 0xFFFF). That multiplication overflows in a signed sense, an undefined operation. The compiler can do whatever it feels like - including generate code that crashes if it wants.

GCC in this case assumes that overflow cannot happen, so therefore x * y is positive (when it's really not at runtime). This means the uint32_t cast does nothing, so is omitted by the optimizer. Now, the code generator sees an int cast to uint64_t, which means sign extension. The optimizer this time isn't smart enough to know again that it's positive and therefore can ignore sign extension and use "mov eax, ecx" to clear the high 32 bits, so it emits a "cqo" opcode to do the sign extension.

So no, avoiding signed integers does not always save you.

Comment: Re:Fix the C standard to not be so silly (Score 1) 470

by Myria (#45275859) Attached to: How Your Compiler Can Compromise Application Security

* Fixation of two's complement as the integer format.

Are you trying to make C less portable, or what?

The "broken" code is already nonportable to non-two's-complement machines, and much of this code is things critical to the computing and device world as a whole, such as the Linux kernel.

Comment: Fix the C standard to not be so silly (Score 1, Insightful) 470

by Myria (#45274871) Attached to: How Your Compiler Can Compromise Application Security

The C standard needs to meet with some realities to fix this issue. The C committee wants their language to be usable on the most esoteric of architectures, and this is the result.

The reason that the result of signed integer overflow and underflow are not defined is because the C standard does not require that the machine be two's complement. Same for 1 31 and the negative of INT_MIN being undefined. When was the last time that you used a machine whose integer format was one's complement?

Here are the things I think should change in the C standard to fix this:

  * Fixation of two's complement as the integer format.
  * For signed integers, shifting left a 1 bit out of the most-significant bit gets shifted into the sign bit. Combined with the above, this means that for type T, ((T) 1) << ((sizeof(T) * CHAR_BIT) - 1) is the minimum value.
  * The result of signed addition, subtraction, and multiplication are defined as conversion of all promoted operands to the equivalent unsigned type, executing the operation, then converting the result back. (In the case of multiplication, the high half is chopped off. This makes signed and unsigned multiplication equivalent.)
  * When shifting right a signed integer, each new bit is a copy of the sign bit. That is, INT_MIN >> ((sizeof(int) * CHAR_BIT) - 1) == -1.

That should fix most of these. Checking a pointer for wraparound on addition, however, is just dumb programming, and should remain the programmers' problem. Segmentation is something that has to remain a possibility.

Ma Bell is a mean mother!

Working...