True, you have support libraries in the/Library folder that may be orphaned, but this happens in every OS
This doesn't happen in Debian (if you use deborphan or debfoster).
In Debian, every file is accounted for and dependencies are documented.
No guesswork involved and your system will remain a lot cleaner.
That size problem is just the DB log. In older versions you could clean it up using svnadmin list-unused-dblogs and the newer versions (based on db4.2) remove them automatically.
ext2dump is unsupported; in particular I recall a quote from Linus to the extent that anyone who uses ext2dump might just as well not make backups at all.
No. That is wrong. It's usually *harder* to retrieve a deleted file from an XFS filesystem than from ext2/ext3, not in the first place because the on-disk structures are more complicated.
But more importantly, the 2.6 kernels use a new set of module handling utilities!
You need to grab a module-init-tools package from somewhere. This package should be able to coexist with the previous modules package so that you have a way to go back to a 2.4 kernel if need be.
It's one thing to find flaws in Open Source products, but Peter *did* get a bit too personal with his "penis-shaped sound waves" remark.
He may be right (I think he is) but phrasing it like
that will simply make those developers take a defensive stand instead of a constructive one.
This is what inspired the grandparent post, not the actual problems that Gutmann found.
Mallory sends CHAL_REPLY SHA1(H2) encrypted with S1 to Bob, Bob responds with CHAL_REPLY SHA1(H1) encrypted with S2 to Mallory. Mallory sends CHAL_REPLY SHA1(H1) encrypted with S2 to Alice. Alice responds with CHAL_REPLY SHA1(H2) encrypted with S3 to Mallory.
Mallory at this point only knows H2 encrypted with S2, but not H2 itself because Mallory doesn't know S2. He therefore can't send CHAL_REPLY SHA1(H2) encrypted with S1. The attack fails.
Alice encrypts the session key with Bob's public key, and sends it across the network. Mallory takes the packets and deletes it. Mallory encrypts his own session key with Bob's public key, and sends it to Bob. Mallory then creates a second (possibly different) session key and encrypts it with Alice's public key and sends it to Alice. Mallory sends Bob a encrypted challenge string, and Bob replies with hashed results. Mallory repeats this with Alice.
The challenge that Alice sent is encrypted using the original session key. Bob decrypts it with
Mallory's fake key and gets garbage. The hash of
this garbage is not what Alice expects and Alice
drops the connection.
Vice versa, Bob sends Alice a hash, encrypted using Mallory's fake session key. Alice decrypts it with
her real session key and gets garbage. When she
returns the hash of this garbage, Bob rejects it
and closes the connection.
In your scheme you also subvert the other session key. This only makes the mess worse for
Mallory, because now the challenge replies
get garbled as well.
The reply that Bob returns to Mallory's challenge is simply the hash of Mallory's challenge, decrypted using Mallory's own session key. No information is leaked here.
The problem here seems to be that what is called an "IV" in this instance isn't really an IV in the sense that it usually has with CBC ciphers.
This counter is prepended to packets to provide the necessary perturbation that is enough to make packets different. In fact, this is preferable to using random numbers because you avoid the birthday paradox.
As for the RSA argument: assuming you're referring to the problem of page 236 of Practical Cryptography by Ferguson and Schneier:
tinc uses the 0xFFFF value
for the rsa e value, a string would have to be as short as 2048^(1/65535),
which means 1 bit, to be vulnerable. Needless to say that the keys that are
sent like this are a little longer than that.
The challenge is encrypted with one key and the challenge reply is encrypted using the other key.
If Mallory switched out a key then either the challenge or the challenge reply
is going to be encrypted with a key that the first side didn't expect and the challenge will fail (after decryption, only garbage remains).
Slashdot Mirror
True, you have support libraries in the /Library folder that may be orphaned, but this happens in every OS
This doesn't happen in Debian (if you use deborphan or debfoster). In Debian, every file is accounted for and dependencies are documented. No guesswork involved and your system will remain a lot cleaner.
apt doesn't do that, the hardworking package maintainers do that.
It's only a commercial activity in the sense that robbing old ladies is a commercial activity. I don't see any problem in restraining that.
Downloading is allowed under copyright law. Offering it for download isn't.
(Dutch copyright law).
Apply the background to the html-tag instead of the body-tag and you'll be fine. Or at least, that's what worked for me.
This website has ready-made movies for your downloading convenience.
Yes please, if zle would support multibyte character encodings. Which it doesn't.
I think you'd rather want to use jpegtran for rotations: it rotates your JPEGs losslessly.
That size problem is just the DB log. In older versions you could clean it up using svnadmin list-unused-dblogs and the newer versions (based on db4.2) remove them automatically.
Two wrongs don't make a right.
Journalling helps against sudden crashes, not against media corruption. Soft updates might be a much better option.
ext2dump is unsupported; in particular I recall a quote from Linus to the extent that anyone who uses ext2dump might just as well not make backups at all.
xfsdump on the other hand will work correctly.
Delete times were mostly fixed in XFS 1.3, if I recall correctly.
No. That is wrong. It's usually *harder* to retrieve a deleted file from an XFS filesystem than from ext2/ext3, not in the first place because the on-disk structures are more complicated.
You need to grab a module-init-tools package from somewhere. This package should be able to coexist with the previous modules package so that you have a way to go back to a 2.4 kernel if need be.
This is what inspired the grandparent post, not the actual problems that Gutmann found.
tinc encrypts RSA_KEYLEN bits of data using the RSA key. That part is in the docs.
Mallory at this point only knows H2 encrypted with S2, but not H2 itself because Mallory doesn't know S2. He therefore can't send CHAL_REPLY SHA1(H2) encrypted with S1. The attack fails.
tinc already pads to RSAKEYLEN by the way. Not exactly raw.
No, I didn't miss it. I was just guessing which attack you're referring to.
The challenge that Alice sent is encrypted using the original session key. Bob decrypts it with Mallory's fake key and gets garbage. The hash of this garbage is not what Alice expects and Alice drops the connection.
Vice versa, Bob sends Alice a hash, encrypted using Mallory's fake session key. Alice decrypts it with her real session key and gets garbage. When she returns the hash of this garbage, Bob rejects it and closes the connection.
In your scheme you also subvert the other session key. This only makes the mess worse for Mallory, because now the challenge replies get garbled as well.
The reply that Bob returns to Mallory's challenge is simply the hash of Mallory's challenge, decrypted using Mallory's own session key. No information is leaked here.
This counter is prepended to packets to provide the necessary perturbation that is enough to make packets different. In fact, this is preferable to using random numbers because you avoid the birthday paradox.
As for the RSA argument: assuming you're referring to the problem of page 236 of Practical Cryptography by Ferguson and Schneier: tinc uses the 0xFFFF value for the rsa e value, a string would have to be as short as 2048^(1/65535), which means 1 bit, to be vulnerable. Needless to say that the keys that are sent like this are a little longer than that.
The challenge is encrypted with one key and the challenge reply is encrypted using the other key. If Mallory switched out a key then either the challenge or the challenge reply is going to be encrypted with a key that the first side didn't expect and the challenge will fail (after decryption, only garbage remains).
Uh, have you actually seen Spirited Away? It's a children's movie, for crying out loud.