It means they broke a 768-bit RSA key in 6 months. As a practical matter, everyone has to have the information they had, so the decryption can be done offline. They only used 80 computers, so assuming the task is linearly parallelizable (which I don't know), anyone who cares (and can afford 1000 high-end computers) can break a 768-bit RSA key in about 2 days or so.
Which means that a 1024-bit key is only safe for about 3 years. (But 3 years of 1000 high-end computers dedicated to the task of breaking your key is still really expensive. So that's probably pretty safe. Stealing the computer with the private key is still cheaper). But given the pace of technology and factoring techniques, that will likely come down.
4096-bit keys seem to be sufficiently safe for the foreseeable future. (Didn't gpg used to mock you if you told it to create a key that large?)
Dr. Seuss Enterprises v. Penguin Books USA
Penguin Books published a poetic account of the O.J. Simpson trial in a book titled, The Cat NOT in the Hat! A Parody by Dr. Juice. The 9th Circuit held that the book did not parody The Cat in the Hat, but simply retold the Simpson story. Therefore, there was no fair-use defense, and the book was deemed a copyright infringement.
My solution to this problem: http://code.google.com/p/hal-autofs/. I wrote it for Fedora, and use it under Fedora and CentOS. It might work elsewhere, but I make no promises.
Basically I set up the automounter with a 1 second idle timeout, and edit the automount config as devices get added and removed. (And also add.desktop files to my desktop when devices get added and removed, pointing to the automounter mount point for the device)
This was a vote for closure (bring it to an actual vote). You need 60 votes (60%) to bring a bill to closure in the Senate. The Democrats only have 51 (49 Democrats, 2 Independents who votes for the Democratic leadership). Add in the 6 republicans, and you get 57, which is still 3 votes short. So, given that they were 4 votes short, only one "Democrat" didn't vote for it. (Joe Lieberman, who is one of the two independents, voted against closure)
You do not have a right to sublicense a copyrighted work unless that right is explicitly granted to you by somebody who has the right to do so. In the case of BSD or GPL licensed works, nobody grants you the right to sublicense them.
So where does this leave <Commercial Vendor>, who used BSD-licensed code in their commercial software, which is distributed via a commercial license? Is this sublicensing? If so, how are you distinguishing between making a deritive work (allowed), and sublicensing (not allowed?)
If not, what's the distinction you're drawing again?
The presentation covers it pretty well. At least the GSWTK attack.
(It's a straight forward time-of-use vs. time-of-check attack. And we were at least partially aware of it when we wrote GSWTK. The problem is that the original system calls require memory in the processes space, so you can't just copy in the string after you validate it to keep the process from changing it. I wrote some methods for Linux that allocated extra pages in the processes memory space so we could copy in the string, but that just makes the attack harder via obscurity. It doesn't address the fundamental issue at all.)
Reading the technology link I think that's exactly what they are planning on doing. Its a reasonable strategy. The system call vector is reasonably sized, most of the calls are sane...
However: A lot of calls take weird undocumented arguments that only Microsoft applications use. And from experience in system call interception, if you don't pass them along, the applications don't work. So someone reimplimenting the system calls will have a fun time reverse engineering those weird arguments. (Or, "reverse engineer" them from the leaked source code)
But the major implication of this approach is that you won't get the licensing cost savings, as you will still need a licensed copy of the Win32 layer. Ignoring the EULA conflict issues (running Win32 not on the NT kernel), this will kill any cost advantages.
Sure, I can use automount, but then its not safe to just remove the floppy.
$ more/etc/auto.master # Format of this file: # mountpoint map options # For details of the format look at autofs(8). /misc/etc/auto.misc --timeout=1
A 1 second delay good enough? There are still some details about remembering to change out of any automounted subdirectories, but this setup "Works For Me(TM)"
I also use the CD like this, and have setup some view profiles for Konqi that start in the directory. Now I can buttons on the desktop I click to look at the cd... and no need to care about mounting/unmounting it.
This isn't a full solution, but some "mount by label" stuff is already there.
e2label/dev/foo "Foo" mount LABEL=Foo/mnt/foo
Add in automounter magic, and TaDa: "Its a userspace
problem," albeit one that assumes you are using ext2
as your only file system.
If you actually want to hack this, look into the executable maps and wildcards features of autofs (man 5 autofs). It might be possible now with some clever automounter config files...
If you're seeing this type of bloat, it's more likely to be either a compilier problem or a really bad implimentation of the STL.
No real argument there. Its a non-optimized implimentation of the STL that doesn't appear to use specializations... But it not one I can easily get away from.
[dougk@pitr src]$ ls -l privman.cc privman.o ; gcc -v
-rw-r--r-- 1 dougk
dougk14613 Apr 29 12:56 privman.cc
-rw-rw-r-- 1 dougkdougk
290144 Apr 29 12:54 privman.o
Reading specs from/usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-98)
Don't read headers to learn STL. Get a good book like [...]
I like "STL Tutorial and Reference Guide" by Musser and Saini (Addison-Wesley Professional series, aka. The Swoosh books). Yes, the online guide is also very handy.
there is a lot of overhead with using the STL. Virtual function and things of that like can make your code bigger and slower.
STL doesn't normally use virtual functions, unless some of the comparison functions or functor objects do. The main cause of bloat (in my experience) is the lack of provided specializations, and the huge symbol names generated by name mangling.
(Fer fun, create a map< foo, map<bar, map<fred, qux> > >, and run "nm" on the generated.o file. I had a problem with blowing up the size limits on the default Solaris linker with stunts like that)
The header files you want to read to find out the API's are practically illegable. You'll probally want to get a book or other such better documentation.
Depending on your compilier, you might end up with excessive binary-code bloat, as three different copies of "list" are created for list<foo*>
, list<bar*>, and list<fred*> instead of using a single specilization for all three.
I don't know how well the inheritance issues are nailed down, but I've never been tempted to make a class inherit from a container, I just have classes have containers.
That said, I like STL and highly suggest using it. Never write a linked-list again.
Slashdot Mirror
I expect, in terms of rounds fired, handguns are overwhelmingly used for harmless recreation.
Because maintaining a google apps account takes zero time?
It means they broke a 768-bit RSA key in 6 months. As a practical matter, everyone has to have the information they had, so the decryption can be done offline. They only used 80 computers, so assuming the task is linearly parallelizable (which I don't know), anyone who cares (and can afford 1000 high-end computers) can break a 768-bit RSA key in about 2 days or so.
Which means that a 1024-bit key is only safe for about 3 years. (But 3 years of 1000 high-end computers dedicated to the task of breaking your key is still really expensive. So that's probably pretty safe. Stealing the computer with the private key is still cheaper). But given the pace of technology and factoring techniques, that will likely come down.
4096-bit keys seem to be sufficiently safe for the foreseeable future. (Didn't gpg used to mock you if you told it to create a key that large?)
Relevant case law:
Dr. Seuss Enterprises v. Penguin Books USA Penguin Books published a poetic account of the O.J. Simpson trial in a book titled, The Cat NOT in the Hat! A Parody by Dr. Juice. The 9th Circuit held that the book did not parody The Cat in the Hat, but simply retold the Simpson story. Therefore, there was no fair-use defense, and the book was deemed a copyright infringement.
Basically I set up the automounter with a 1 second idle timeout, and edit the automount config as devices get added and removed. (And also add .desktop files to my desktop when devices get added and removed, pointing to the automounter mount point for the device)
Er, no. Verisign owns the .com, .net registries. Verisign used to own Network Solutions, but they were spun out several years ago.
This was a vote for closure (bring it to an actual vote). You need 60 votes (60%) to bring a bill to closure in the Senate. The Democrats only have 51 (49 Democrats, 2 Independents who votes for the Democratic leadership). Add in the 6 republicans, and you get 57, which is still 3 votes short. So, given that they were 4 votes short, only one "Democrat" didn't vote for it. (Joe Lieberman, who is one of the two independents, voted against closure)
So where does this leave <Commercial Vendor>, who used BSD-licensed code in their commercial software, which is distributed via a commercial license? Is this sublicensing? If so, how are you distinguishing between making a deritive work (allowed), and sublicensing (not allowed?) If not, what's the distinction you're drawing again?
The presentation covers it pretty well. At least the GSWTK attack.
(It's a straight forward time-of-use vs. time-of-check attack. And we were at least partially aware of it when we wrote GSWTK. The problem is that the original system calls require memory in the processes space, so you can't just copy in the string after you validate it to keep the process from changing it. I wrote some methods for Linux that allocated extra pages in the processes memory space so we could copy in the string, but that just makes the attack harder via obscurity. It doesn't address the fundamental issue at all.)
I ran into a linker bug because of symbols that were too long ... just by using STL. Boost isn't required.
ufraw is the Gimp plugin to the raw converter that you want. It has all the knobs to frob, and you can easily prevent the washed out colors.
Other than that, I have to agree, but I'm still managing to just use the Gimp, ImageMagick, and some shell scripts I wrote, with the same Canon D10
http://ac4lt.org:5472/gallery/DougsPhotos
X*1=X
X^1=X
Without these, algebra comes significantly harder.
To help show the problem:
So the packages there assume python 2.2, and FC2 comes with 2.3, and the paths differ slightly.Link here
However: A lot of calls take weird undocumented arguments that only Microsoft applications use. And from experience in system call interception, if you don't pass them along, the applications don't work. So someone reimplimenting the system calls will have a fun time reverse engineering those weird arguments. (Or, "reverse engineer" them from the leaked source code)
But the major implication of this approach is that you won't get the licensing cost savings, as you will still need a licensed copy of the Win32 layer. Ignoring the EULA conflict issues (running Win32 not on the NT kernel), this will kill any cost advantages.
http://obsequious.net/blog/tech/?permalink=2003080 8a.txt
East coast time, its not April 1st yet. Shouldn't you wait a couple more hours before posting these?
function rip () /dev/cdrom
{
local width div last;
if [ $# -ne 1 ]; then
echo "usage: rip file-name-prefix";
echo "ex: rip var-Devils_Blues-";
return 1;
fi;
last=$(cdparanoia -Q 2>&1 | grep -B1 TOTAL | head -1 | sed 's/^ *\([0-9][0-9]*\).*$/\1/');
width=1;
div=$last;
while [[ $div -ge 10 ]]; do
width=$((width+1));
div=$(( $div / 10 ));
done;
echo "Last: $last, width: $width";
for i in $(seq -f "%0$width.0f" 1 $last);
do
cdparanoia -q -r -- $i - | oggenc -Q -q5 --raw --output=$1$i.ogg -;
done;
eject
}
Then "rip Band-Album-" No pretty pictures, but awfully easy.
And if so, is this a bad thing?
$ more /etc/auto.master
/misc /etc/auto.misc --timeout=1
# Format of this file:
# mountpoint map options
# For details of the format look at autofs(8).
A 1 second delay good enough? There are still some details about remembering to change out of any automounted subdirectories, but this setup "Works For Me(TM)"
I also use the CD like this, and have setup some view profiles for Konqi that start in the directory. Now I can buttons on the desktop I click to look at the cd... and no need to care about mounting/unmounting it.
e2label /dev/foo "Foo" /mnt/foo
mount LABEL=Foo
Add in automounter magic, and TaDa: "Its a userspace problem," albeit one that assumes you are using ext2 as your only file system.
If you actually want to hack this, look into the executable maps and wildcards features of autofs (man 5 autofs). It might be possible now with some clever automounter config files...
No real argument there. Its a non-optimized implimentation of the STL that doesn't appear to use specializations... But it not one I can easily get away from.
[dougk@pitr src]$ ls -l privman.cc privman.o ; gcc -v /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
-rw-r--r-- 1 dougk dougk14613 Apr 29 12:56 privman.cc
-rw-rw-r-- 1 dougkdougk 290144 Apr 29 12:54 privman.o
Reading specs from
gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-98)
I like "STL Tutorial and Reference Guide" by Musser and Saini (Addison-Wesley Professional series, aka. The Swoosh books). Yes, the online guide is also very handy.
Thought I already said that.... *shrug*
STL doesn't normally use virtual functions, unless some of the comparison functions or functor objects do. The main cause of bloat (in my experience) is the lack of provided specializations, and the huge symbol names generated by name mangling.
(Fer fun, create a map< foo, map<bar, map<fred, qux> > >, and run "nm" on the generated .o file. I had a problem with blowing up the size limits on the default Solaris linker with stunts like that)
Depending on your compilier, you might end up with excessive binary-code bloat, as three different copies of "list" are created for list<foo*> , list<bar*>, and list<fred*> instead of using a single specilization for all three.
I don't know how well the inheritance issues are nailed down, but I've never been tempted to make a class inherit from a container, I just have classes have containers.
That said, I like STL and highly suggest using it. Never write a linked-list again.