> I have no idea if they do this up front, inducing latency on all write operations, or as it goes.
All write IO is asynchronous, unless fsync() or O_DIRECT is used. The dedup check is done when the write goes out to stable storage (typically between 5 seconds and 60 seconds after the write is done).
The utility of this attack (which others have pointed out is pretty low until a SHA256-collision generator is done) is reduced by the fact that unless you are the first one in with a block, your collision will be thrown away (since it's a duplicate with the existing data).
So you would have to be able to predict the value which *will be written* and write out your attack block before the first version of the block you want to replace is written to the filesystem.
This doesn't make the attack useless, but it makes it much harder to pull off.
As the other poster said, you need to cite this. If the unrecoverable block is in user data, ZFS will return EIO when that block is read. If the unrecoverable block is in metadata, ZFS keeps at least 1 other copy of the metadata, so it will just read the other copy.
The same thing will happen if the checksum doesn't match.
It's not actually part of his sig -- it's part of the comment. (turn on "Disable Sigs" in Comment Preferences, and re-load) He just labeled it as "Sig:".
> CDDL code is exactly as "viral" as GPL No, it isn't -- CDDL is only viral to the file level (any change to a file licensed under CDDL must also be licensed under CDDL). GPL is vial to the *link* level -- any code which links against GPLed code must also be GPLed.
So you can have CDDL files in a source base that is otherwise BSD-licensed, or is otherwise closed-source, or...
Couldn't you just boot into single-user mode (command-s as it boots), start the netinto server (nibindd, I think, or just netinfod -s local), then assign root a password?
Read the FAQ -- the only requirement Google has is that the content is accessible to the Google crawlers, and that abstracts are available to people coming from Google.
So the ACM can have all of their articles indexed, but still charge for the full text.
The article (which I've only read through the google cache link) has a bunch of images, which are probably bloating it to the 5MB mark. The cached version, including all of the crazy markup google uses to make the HTML look like the PDF, is ~380K.
The CPU is underneath the huge heatsink with four screw-down bolts in the center of the board.
And these CPUs are factory-installed and tested, not plugged in by the random people who buy them, so being fully keyed is much less of an issue. From the picture, I believe the connectors are not pins, but metal pads, kept in connection by pressure from the above bolts. (which are tightened with torsion wrenches, you'd better believe)
And as for the gnu utils, the least they could do is install them by default into/usr/local. Sheesh. They do install quite a few in/usr/sfw/bin./usr/local is for the local admin's use.
Actually, all UNIX vendors must pay SCO for SysV code. Sun bought full rights to SysV *years ago*. Do some research -- that's why they can indemnify their customers against Linux lawsuits.
...except that the two prior patents pretty clearly cover the invention, so that MSFT's patent isn't valid.
5,307,494 in particular is exactly "how do I store long filenames in a filesystem which doesn't support them", and was granted a year and two days before the microsoft patent. Here's the abstract:
A method of augmenting the length of the name of a file in a computer system which allows the use of file names longer than otherwise allowed by the system. A file name table is searched for a table entry corresponding to a long provisional name. An actual file name contained in the corresponding table entry is used to access the file.
If you'd read the paper attached to the article, you would have known that: 1) files are assumed to be large -- 64MB chunk sizes. 2) old files are kept around for a couple days, before deleting them. (freeing up their chunks) 3) old chunks are deleted asynchronously, in a garbage-collected fashion.
And in any case, the data will be lying around on the hard drives until overwritten -- guaranteeing that you click "delete", and some user-response-level time later, the e-mail (or e-mail associated with the account) is inaccessible would be an impossible constraint to fulfill.
Google is just (sensibly) trying to set expectations, and avoiding making promises they can't keep.
Actually, the way ID generated it's keys is: Pick a range of integers that's at least an order of magnitude larger than the maximum number of copies you expect to sell (say 1 billion, to be on the safe side). For example: 0x1DDCDFF123450000 to 0x1DDCE0D9F7EA1000 And pick a random 56-bit DES key. (or a random 3-DES key, if you're extra-paranoid). To generate a key, encrypt a number from the above range using the key. To test if a key is valid, decrypt it using the key, and check if it's in the range. Much faster than having to look it up in some database...
I would have to agree. What gave _Lost Boys_ another level of interest to me was reading the short story it was expanded from, which is in _Maps in the Mirror, the Short Fiction of OSC_. It was orignally written with Card himself as the father, in a ghost-story sort of fashion.
The/orders/sisters/ind stuff is new, but the % stuff has been around since the foo@bar.baz e-mail addresses came around. I've seen it refered to as the "percent hack", where if slashdot.org receives an email addressed to joe%barfoo.com@slashdot.org it forwards it on to joe@barfoo.com.
Of course, this isn't exactly how the e-mail addresses are in the preview chapters...
If you look at the actual issue, the case you site is not equivilent -- Bomb threats, etc. don't stay around for longer than it takes to transmit them in the phone system, and are hard to remove. The case that this article references is different -- The guy sent them a formal notice of libelous material in their usenet feed, and showed that they did nothing in response. There is very little similarity in the things you bring up to this case.
Slashdot Mirror
I would also recommend this; well-written introduction, and talks a lot about the systems-issues that come up in games programming as well.
All true, except that copies can only be 1, 2, or 3; there's only room for three locations in a block pointer.
> I have no idea if they do this up front, inducing latency on all write operations, or as it goes.
All write IO is asynchronous, unless fsync() or O_DIRECT is used. The dedup check is done when the write goes out to stable storage (typically between 5 seconds and 60 seconds after the write is done).
The utility of this attack (which others have pointed out is pretty low until a SHA256-collision generator is done) is reduced by the fact that unless you are the first one in with a block, your collision will be thrown away (since it's a duplicate with the existing data).
So you would have to be able to predict the value which *will be written* and write out your attack block before the first version of the block you want to replace is written to the filesystem.
This doesn't make the attack useless, but it makes it much harder to pull off.
As the other poster said, you need to cite this. If the unrecoverable block is in user data, ZFS will return EIO when that block is read. If the unrecoverable block is in metadata, ZFS keeps at least 1 other copy of the metadata, so it will just read the other copy.
The same thing will happen if the checksum doesn't match.
It supports active directory, and user mapping between AD and LDAP. The CIFS stack is in-kernel.
It's not actually part of his sig -- it's part of the comment. (turn on "Disable Sigs" in Comment Preferences, and re-load) He just labeled it as "Sig:".
> CDDL code is exactly as "viral" as GPL
...
No, it isn't -- CDDL is only viral to the file level (any change to a file licensed under CDDL must also be licensed under CDDL). GPL is vial to the *link* level -- any code which links against GPLed code must also be GPLed.
So you can have CDDL files in a source base that is otherwise BSD-licensed, or is otherwise closed-source, or
Couldn't you just boot into single-user mode (command-s as it boots), start the netinto server (nibindd, I think, or just netinfod -s local), then assign root a password?
So the ACM can have all of their articles indexed, but still charge for the full text.
Couldn't they add it later, in a patch? The only tricky part might be going from being a USB Device to a USB Host.
> That's just what we need, more dependence on combustable fuel.
Umm.. Where do you think the energy in batteries comes from?
Uh, from chemical bonds?
The article (which I've only read through the google cache link) has a bunch of images, which are probably bloating it to the 5MB mark. The cached version, including all of the crazy markup google uses to make the HTML look like the PDF, is ~380K.
The CPU is underneath the huge heatsink with four screw-down bolts in the center of the board.
And these CPUs are factory-installed and tested, not plugged in by the random people who buy them, so being fully keyed is much less of an issue. From the picture, I believe the connectors are not pins, but metal pads, kept in connection by pressure from the above bolts. (which are tightened with torsion wrenches, you'd better believe)
And as for the gnu utils, the least they could do is install them by default into /usr/local. Sheesh. /usr/sfw/bin. /usr/local is for the local admin's use.
They do install quite a few in
Actually, all UNIX vendors must pay SCO for SysV code.
Sun bought full rights to SysV *years ago*. Do some research -- that's why they can indemnify their customers against Linux lawsuits.
5,307,494 in particular is exactly "how do I store long filenames in a filesystem which doesn't support them", and was granted a year and two days before the microsoft patent. Here's the abstract:
If you go to their "Activities" page and read the request itself, they are talking about:
5,579,517
which covers the "long file names" stuff Windows 95 introduced, and they site two patents:
5,307,494 to Yasumatsu et al., and
5,367,671 to Feigenbaum et al.
as new prior art.
If you'd read the paper attached to the article, you would have known that:
1) files are assumed to be large -- 64MB chunk sizes.
2) old files are kept around for a couple days, before deleting them. (freeing up their chunks)
3) old chunks are deleted asynchronously, in a garbage-collected fashion.
And in any case, the data will be lying around on the hard drives until overwritten -- guaranteeing that you click "delete", and some user-response-level time later, the e-mail (or e-mail associated with the account) is inaccessible would be an impossible constraint to fulfill.
Google is just (sensibly) trying to set expectations, and avoiding making promises they can't keep.
Another option is the Driver Porting Kit. which lets you use the XFree86 drivers with the Xsun (Sun's Xwindows server)
Actually, the way ID generated it's keys is:
Pick a range of integers that's at least an order of magnitude larger than the maximum number of copies you expect to sell (say 1 billion, to be on the safe side). For example:
0x1DDCDFF123450000
to
0x1DDCE0D9F7EA1000
And pick a random 56-bit DES key. (or a random 3-DES key, if you're extra-paranoid). To generate a key, encrypt a number from the above range using the key. To test if a key is valid, decrypt it using the key, and check if it's in the range. Much faster than having to look it up in some database...
I would have to agree. What gave _Lost Boys_ another level of interest to me was reading the short story it was expanded from, which is in _Maps in the Mirror, the Short Fiction of OSC_. It was orignally written with Card himself as the father, in a ghost-story sort of fashion.
Of course, this isn't exactly how the e-mail addresses are in the preview chapters...
If you look at the actual issue, the case you site is not equivilent -- Bomb threats, etc. don't stay around for longer than it takes to transmit them in the phone system, and are hard to remove. The case that this article references is different -- The guy sent them a formal notice of libelous material in their usenet feed, and showed that they did nothing in response. There is very little similarity in the things you bring up to this case.