The term cord-cutter baffles me. You'd think it would mean someone who gets their video content exclusively via wireless technologies. And yet, every "cord-cutter" I ever hear about is still using a "cord" to access Netflix. Usually supplied by the cable company, even.
The concept of not buying a subscription to cable television is fine, but who had the idea to call it "cutting [a] cord"?
I still have a hard time trying to figure out why any user would need to modify a logo.
I assume you aren't a graphic artist. If you were, you would be much more likely to understand the appeal of starting with an existing image and turning it into something new, perhaps something which only vaguely resembles the original. It is the same idea as a programmer taking an existing piece of software and turning it into something new.
If you don't understand why it's useful to modify existing digital works to create new ones — which is pretty much what the entire free software movement is about — I'm not sure how to explain it to you. I guess you'll just have to take our word for it that a lot of our users really want this freedom, and we've promised it to them. This doesn't mean, of course, that every user will be interested in modifying every single bit of digital data we ship. Programmers are most likely interested in source code for specific applications. Artists are interested in images they may wish to incorporate into their art. Electronic music artists are interested in audio samples they can use. And so forth.
I think the original poster already pretty much answered the question for you. He thinks a Linux distro like Debian should focus more on being usable/desirable to the majority of users, vs. being less so for the sake of "principles".
Good point. Lots of people don't care about freedom for any kind of content we ship, be it source code, images, manuals, audio samples, or anything else. For such people, free software is pretty much equivalent to warez that you'll never get in trouble for.
But I've also heard lots of people say that they really do care about the Four Freedoms for source code... but do not think the same freedoms, or a close analogue, are valuable for non-program-code such as documentation or images. This is the part that makes no sense to me. One hears things like "it's OK for a font to be non-modifiable because font designers feel a need to maintain strict artistic control", for example. Yes, I've actually heard things like this! Why the same logic doesn't apply to programmers and our creative endeavors — that's what nobody seems to be able to explain to me.
I think Debian made a terrible mistake when they decided that more than source code had to be free. Sure, it's nice to have great principles like that, but it's better to have a usable distribution.
People keep bringing this up, and what it boils down to is the assertion that, while certain freedoms are important for source code, those same freedoms aren't important for other types of digital content. I've tried for years to get people to explain what principles would make this valid — why certain fundamental freedoms are only important for program code — but so far I have yet to hear a logically consistent answer.
[In fact, some people go so far as to claim that freedoms are important for code written in some languages but not other languages. For example, code written for the embedded processor of a gigabit network card is often downplayed as "just firmware", with the implication that it's less important for users to be able to hack on that than to hack on the rest of their OS. This puzzles me too.]
What I suspect is that a lot of people care only about rights they personally would take advantage of — that is, the right and the ability to modify things they personally might feel inclined to modify. For programmers, that means source code in languages they already know, for applications they care about. For graphic artists, that means images. For music producers, that means audio files. I think it's pretty myopic, and arrogant, for a programmer to tell an artist or a music producer that the right to edit, resample and remix code is more important than the right to edit, resample and remix images or audio. The artists could, after all, say the same to you in reverse: "Who cares about program source code, or the right to modify it? We don't have the skill to read or modify it anyway, it's a black box to us, and who would want to bother?"
The Firefox logo is trademarked, so Debian doesn't consider it to be Free and will not include it as part of its distribution.
I believe that everything has been said here !
Aha! So that is why everyone is confused — because TFA got it wrong. (Perhaps Slashdot readers actually do RTFA!) The reason the logo is not Free is not because it is trademarked, but because it has a copyright license which prohibits derivative works. That means you cannot take the Firefox logo, pull it up in your favorite image editor, and turn it into something else — like a 16x16 grayscale icon, or putting a Superman costume on the fox, or turning it into a texture map for a game.
[Hmmm, come to think of it, the Superman costume is probably someone else's trademark, but that's not the point. (: ]
We take our user freedoms seriously. We need for you to be able to take anything on the source CD and produce your own creative works based on it. Most of what we ship is program source code, but there's nothing special about program code — we believe the same freedoms are equally important for PNG files.
There are lots of reasons you might want to modify a logo image in a way that doesn't violate MozCorp's trademark. Unfortunately, MozCorp doesn't allow it. That's certainly their choice, but the practical effect is that we can't ship the logo images and still keep our promise to our users about your right to make modifications to all the content in Debian.
Except that this seems to be a clash over potential trademark claims. I realize that not all slashdot editors are lawyers, but haven't yall learned by now to distinguish between different forms of IP?
It's both. MozCorp is forcing the issue based on their trademarks, but the main thing Debian and MozCorp cannot agree on is the copyright license for the logos.
trademark issue (which Debian has no real problem with): "You cannot use this logo to represent any web browser except Firefox"
copyright issue: "You cannot modify these logo images in any way, for any purpose, whether your purpose is related to Firefox, or other web browsers, or selling Gouda cheese."
The second issue is the reason Debian stopped shipping the official Mozilla Firefox logo images. Which in turn prompted MozCorp to demand that Debian also stop using the Firefox name. So of course we'll comply.
There seems to be a general forgetting of who the real enemy is.
It's not a general forgetting, it's a general disagreement. You may choose to consider Microsoft an "enemy", but I don't. I find your jingoism (casting software development in terms of an "us against them" war or contest) tiresome. I'd much rather just ignore Microsoft and other proprietary software vendors, and focus on developing an OS people will want to use. They aren't the bad guys, they're just people writing, selling and supporting something I have no reason to care about. Why does there have to be an opponent who must be defeated?
So how's that different from Firefox? Firefox has the official-use logo (fox humping the Earth), and the open-use logo (Earth unmolested by giant wildlife).
Not really different. In fact, Debian is happy to use the open-use Firefox logo, and that's what we're already doing. The "problem" is that Mozilla Corporation has demanded that, if we don't use the official-use logo, we stop calling our browser Firefox. Of course we will comply.
Nothing to see here, except Debian preparing to comply with the demands of a trademark holder.
The only remaining problem is what to call the browser instead. I'd probably support a friend's suggestion of Firefaux, except that I think it would violate trademark law, which prohibits "confusingly similar" names. Because of this I think it's a bad idea to use either "Fire" or "Fox" in the new name. So... yeah. Iceweasel.
Just more proof that some Linux users are far too elitist. Who cares if the firefox logo is trademarked?
We don't, particularly — the trademark isn't the problem. What we care about is that it also has a copyright license that does not allow any derivative works. So, you can't start with a Firefox logo image, pull up your favorite image editor and hack it into something new and interesting — say, for example, an icon set for a desktop theme.
Debian takes the right to modify software very seriously. And yes, that includes images shipped with software.
It is possible to trademark an image yet still allow derivative works to be created from it. Mozilla Corp, unfortunately, chose not to do this.
Only if the 'plaintext' is not something that can be checked with a dictionary.
You still don't understand OTP. Every possible plaintext of the same length is equally likely. Every possible plaintext, from "Pick up the bomb Tuesday at the safe house outside Tokyo" to "Mission compromised, abort and meet Charles in Edinburgh". There is literally no way to tell which of the zillions of grammatically and contextually valid messages of that length is correct.
And if you pad the message randomly with a bit of whitespace, the attacker gets only a vague upper bound on the length. Oh and you can also do traffic analysis based on the existence and timing of the transmission itself. (That is, you can surmise that there was a message worth sending, of approximately this length, between these parties, at this time.)
If the plaintext really is plain text, IIRC the probability of a random key producing a plausible plaintext decreases with the length of the message.
Actually the ratio of key length to message length. The whole point of OTP is that the message is exactly as short as the key -- or, as one usually thinks of it, the key is exactly as long as the message.
It's not. Debian has very little need for money. Hardware? Donated. Bandwidth? Donated. Staff? Volunteer, or in a few cases salaried by companies with an interest in Debian. Conferences? Sponsored by those same companies. I'm sure there are things the Project could do with a huge budget, but all in all there are a lot more needy nonprofits out there.
I think a lot of the complaints about the GFDL are overblown. Personally, I've never even run across a GFDL'd document that contains any invariant sections, etc.
Several GNU manuals include the GNU Manifesto as an invariant section -- in fact, I can't back this up, but it certainly appears that the main motivation for the invariant section clause was specifically to prevent people from removing the GNU Manifesto from GNU manuals.
As others have said, there are quite a few onerous and ambiguous clauses in the GFDL; it's not all about invariant sections. Some of these seem to be mere bugs in the license text, rather than in the intent. Others, like the requirement to cram the whole text of the GFDL onto anything (even, say, a reference card) derived from GFDL'd works, are annoying but not necessarily non-free.
Certainly, the non-modifiable sections of a GFDL work cause the most fear and loathing. If you really think none of those problems could happen in practice, please see this message for a scenario I find very believable.
But anyway, if Debian doesn't like the GFDL, what does it like better? The CC share-alike license? Would the CC share-alike-attribution license be ok?
Creative Commons (in particular the Attribution license) seems to have its heart in the right place. Depending on whom you ask, there are a few "bugs" in that one too, but they seem to be relatively minor nits. As such, there is hope that the Debian legal eagles can negotiate with Creative Commons to iron out problems for future editions of the CC licenses. Certainly the two groups are talking to each other.
Meanwhile, there's no reason you can't use your code license for documentation -- be that the GPL, or some BSD-like thing, or what have you.
And in the meantime, what does Debian plan to do about documentation that is already GFDL'd?
Consensus seems to be that the GFDL has enough problems that even without invariant sections, it's not a free license. As such, the convenience to the user doesn't outweigh sticking to principles of freedom. Just as it did not in the case of Netscape 4.x, which was by far the best graphical web browser for Debian platforms in its day, but didn't ship with source code. If users want manuals, they'll have to point their/etc/apt/sources.list at the non-free section of the archive. In practice, including "non-free" in your downloads is really no inconvenience at all, unless you've only got Debian CDs and no net access, and the CD vendor chose not to include documentation packages from non-free. (This is something a vendor can choose to do, if they wish to take the trouble to comb through the non-free archive to see what they can legally ship at all.)
Curiously enough, practical problems of documentation are mitigated a little bit by a completely unrelated issue. The GNU Project tends to spurn "man pages" as a documentation format, so most GFDL documents are other format documents, such as info pages. The Debian Project still likes man pages, so there are a number of contributed man pages in GNU packages in Debian which were not from the GNU upstream.
"Developers" really means "members of the Project". The term refers to the reality that Debian is a technical project and doesn't have a lot of need for people who can't do actual software development.
As for why only Project members can be the Project Leader, that's pretty common in organisations of all sorts.
Guess that depends on what you mean by freedom.
Richard Stallman disagrees quite publicly with the Debian Project
in the matter of the GNU Free Documentation License the Project
does not consider it sufficiently free.
Some of you will think it is heresy to regard a license from the Free Software Foundation as insufficiently free. Heresy or not, though, I agree with the Debian Project: the GFDL imposes some onerous restrictions on what users can do with the licensed work, and Stallman seems unwilling to drop some of these restrictions.
As it happens (bringing us back on topic), the first nominee for Debian Project Leader 2005, Matthew Garrett, features prominently in the above document detailing why RMS's documentation license is not free enough.
Yes - but not "runtime" as in "virtual machine". It does indeed compile to native code, but it still uses its own libraries - libobjc in particular. This is really no different from C, C++, Common LISP, Fortran, or pretty much any other compiled language. They each have some sort of runtime library support to implement parts of their specific language specs.
That's the thing, though - why would you trust the.torrent? Because nobody posting on Slashdot could possibly be a malicious hax0r? Best to find a linux-2.6.0.tar.bz2.sign somewhere that checks out, and uses DSA key ID 517D0F0E.
(Oh yeah - don't take my word for the key ID, either.)
I run Win XP on a 700mhz p3 w/ 384 megs of RAM, and on a 300MHz p2 dell laptop with 384 megs of RAM.
Frankly I don't see the relevance of your data points.
I've seen plenty of machines that came with Windows 95 and 16 MB of RAM. Many Windows 98 machines came with 64 MB. You're talking about 6 times that much. Would you really be willing to stipulate that 64 MB is enough for Windows XP if you just "disable useless services and eye candy and voila"?
Then the next point of failure becomes the keyservers. How do you know you imported a good key, and that the keyserver hadn't been compromised when you did it?
PGP keyservers (unlike, say, Kerberos KDCs) are completely untrusted. Anyone can upload any key to a keyserver. And downloading a key from a keyserver implies nothing about that key.
To verify that you have a valid key, you have to rely on the web of trust. Basically, if a key is signed by someone whose key is signed by someone [recurse through however many levels you are comfortable with] whose key you have personally inspected, then the key can be assigned a trust metric based on how reliable you consider that chain of signatures to be. (Basically, how much you trust the integrity and acuity of the people controlling the chain of signatures.)
PGP and GnuPG have supported this infrastructure from Day 1. Asking people to trust an arbitrary third-party public keyserver was never in the plans.
So what do you think everyone? Good idea or should we wait for a few more server compromises before we think about securing software repositories?
Great idea. In fact, already implemented. See several other posts in this story, concerning AJ's and BenC's programs for this purpose. You will be gratified to know that they work pretty much as you described.
Indeed, that's one of the few areas where the Debian Project has lagged behind other distribution vendors technically - cryptographic signature verification for packages.
This infrastructure has been kind of long in coming, but as of a few months ago, you can now verify Debian package signatures with debsig-verify. Might I suggest everyone install and use that?
"Blocking" suggests dropping it on the floor. If it's returned to the sender, it's a bounce.
That's exactly what hacker is saying. His MTA is blocking the mail, dropping it on the floor. And producing a 550 status code, telling whoever tried to send the message that it is being dropped on the floor, instead of a 200 code, suggesting that it will be delivered.
hacker's MTA is not returning anything to sender.
If you return mail with a "550 whatever", you have no way of knowing if it's going back to the actual sender or not.
Also true. Whoever connected to his sendmail daemon can either generate a bounce, or not generate one. If the spammer connected directly to the SMTP port, he will almost certainly not bother to send a bounce that he knows is just a waste of his own resources. If, instead, the spammer has used an open relay and this relay is connecting to hacker's port 25, then the relay might (incorrectly) generate a bounce to the envelope sender - but this is the fault of the open relay, which never should have accepted responsibility in the first place for remotely delivering a message from an unknown sender.
And we can't use a tool like PWDUMP? to grab the hashes remotely?
I'm not up on the state of the art in grabbing hashes remotely. But I think you missed my point, so I'll restate it: it doesn't matter whether or not you can decrypt a LANMAN or NT hash (which is what this story is about). All you need to do is sniff the hash - then use the hash, as an opaque hash, to do pretty much anything on an NT network except log in interactively at the console.
So - yes it's nice to decrypt a hash, if you need to log in to a local console interactively and you don't want to change the user's password on the domain controller.[*]
And it is also nice in a "hmm, maybe he also used the same password for amazon.com" sort of way.
But NT security rests on the secrecy of the hash, not the encryption of the hash.
[*] (I thought about my earlier post - I wasn't sure if you could change a user's password without knowing the decrypted version. Thinking about it more, I'm almost positive that you
can. I don't think you can change it back to the original without knowing the decrypted original, though, unless you use the administrator-only RPC call.)
Windows password hashes (both the LanManager hash described here and the newer NT hash) are never sent "in the clear" over a network, or accessible to non-admins.
Why? Because they are plaintext-equivalent. Most NT network protocols treat the hash itself as a shared secret and do not make any attempt to verify that you know the actual password.
Yes, that's right. You already don't need to know the user's unencrypted password - except possibly for changing it (I can't remember offhand whether the various password-change calls require proof of knowledge of the old password - but I don't think they do either). Once an attacker gets the hashes out of your SAM, the game is already up, even if he can't decrypt them.
Given this fact, I sometimes wonder why Microsoft even bothered to try making NTLM a secure hash. BASE64 would have done pretty much the same job.
Move along, nothing to see here. Your passwords are just as secure, or as insecure, as they ever were.
Slashdot Mirror
The concept of not buying a subscription to cable television is fine, but who had the idea to call it "cutting [a] cord"?
I assume you aren't a graphic artist. If you were, you would be much more likely to understand the appeal of starting with an existing image and turning it into something new, perhaps something which only vaguely resembles the original. It is the same idea as a programmer taking an existing piece of software and turning it into something new.
If you don't understand why it's useful to modify existing digital works to create new ones — which is pretty much what the entire free software movement is about — I'm not sure how to explain it to you. I guess you'll just have to take our word for it that a lot of our users really want this freedom, and we've promised it to them. This doesn't mean, of course, that every user will be interested in modifying every single bit of digital data we ship. Programmers are most likely interested in source code for specific applications. Artists are interested in images they may wish to incorporate into their art. Electronic music artists are interested in audio samples they can use. And so forth.
Good point. Lots of people don't care about freedom for any kind of content we ship, be it source code, images, manuals, audio samples, or anything else. For such people, free software is pretty much equivalent to warez that you'll never get in trouble for.
But I've also heard lots of people say that they really do care about the Four Freedoms for source code ... but do not think the same freedoms, or a close analogue, are valuable for non-program-code such as documentation or images. This is the part that makes no sense to me. One hears things like "it's OK for a font to be non-modifiable because font designers feel a need to maintain strict artistic control", for example. Yes, I've actually heard things like this! Why the same logic doesn't apply to programmers and our creative endeavors — that's what nobody seems to be able to explain to me.
People keep bringing this up, and what it boils down to is the assertion that, while certain freedoms are important for source code, those same freedoms aren't important for other types of digital content. I've tried for years to get people to explain what principles would make this valid — why certain fundamental freedoms are only important for program code — but so far I have yet to hear a logically consistent answer.
[In fact, some people go so far as to claim that freedoms are important for code written in some languages but not other languages. For example, code written for the embedded processor of a gigabit network card is often downplayed as "just firmware", with the implication that it's less important for users to be able to hack on that than to hack on the rest of their OS. This puzzles me too.]
What I suspect is that a lot of people care only about rights they personally would take advantage of — that is, the right and the ability to modify things they personally might feel inclined to modify. For programmers, that means source code in languages they already know, for applications they care about. For graphic artists, that means images. For music producers, that means audio files. I think it's pretty myopic, and arrogant, for a programmer to tell an artist or a music producer that the right to edit, resample and remix code is more important than the right to edit, resample and remix images or audio. The artists could, after all, say the same to you in reverse: "Who cares about program source code, or the right to modify it? We don't have the skill to read or modify it anyway, it's a black box to us, and who would want to bother?"
Aha! So that is why everyone is confused — because TFA got it wrong. (Perhaps Slashdot readers actually do RTFA!) The reason the logo is not Free is not because it is trademarked, but because it has a copyright license which prohibits derivative works. That means you cannot take the Firefox logo, pull it up in your favorite image editor, and turn it into something else — like a 16x16 grayscale icon, or putting a Superman costume on the fox, or turning it into a texture map for a game.
[Hmmm, come to think of it, the Superman costume is probably someone else's trademark, but that's not the point. (: ]
We take our user freedoms seriously. We need for you to be able to take anything on the source CD and produce your own creative works based on it. Most of what we ship is program source code, but there's nothing special about program code — we believe the same freedoms are equally important for PNG files.
There are lots of reasons you might want to modify a logo image in a way that doesn't violate MozCorp's trademark. Unfortunately, MozCorp doesn't allow it. That's certainly their choice, but the practical effect is that we can't ship the logo images and still keep our promise to our users about your right to make modifications to all the content in Debian.
It's both. MozCorp is forcing the issue based on their trademarks, but the main thing Debian and MozCorp cannot agree on is the copyright license for the logos.
- trademark issue (which Debian has no real problem with): "You cannot use this logo to represent any web browser except Firefox"
- copyright issue: "You cannot modify these logo images in any way, for any purpose, whether your purpose is related to Firefox, or other web browsers, or selling Gouda cheese."
The second issue is the reason Debian stopped shipping the official Mozilla Firefox logo images. Which in turn prompted MozCorp to demand that Debian also stop using the Firefox name. So of course we'll comply.It's not a general forgetting, it's a general disagreement. You may choose to consider Microsoft an "enemy", but I don't. I find your jingoism (casting software development in terms of an "us against them" war or contest) tiresome. I'd much rather just ignore Microsoft and other proprietary software vendors, and focus on developing an OS people will want to use. They aren't the bad guys, they're just people writing, selling and supporting something I have no reason to care about. Why does there have to be an opponent who must be defeated?
Not really different. In fact, Debian is happy to use the open-use Firefox logo, and that's what we're already doing. The "problem" is that Mozilla Corporation has demanded that, if we don't use the official-use logo, we stop calling our browser Firefox. Of course we will comply.
Nothing to see here, except Debian preparing to comply with the demands of a trademark holder.
The only remaining problem is what to call the browser instead. I'd probably support a friend's suggestion of Firefaux, except that I think it would violate trademark law, which prohibits "confusingly similar" names. Because of this I think it's a bad idea to use either "Fire" or "Fox" in the new name. So ... yeah. Iceweasel.
We don't, particularly — the trademark isn't the problem. What we care about is that it also has a copyright license that does not allow any derivative works. So, you can't start with a Firefox logo image, pull up your favorite image editor and hack it into something new and interesting — say, for example, an icon set for a desktop theme.
Debian takes the right to modify software very seriously. And yes, that includes images shipped with software.
It is possible to trademark an image yet still allow derivative works to be created from it. Mozilla Corp, unfortunately, chose not to do this.
You still don't understand OTP. Every possible plaintext of the same length is equally likely. Every possible plaintext, from "Pick up the bomb Tuesday at the safe house outside Tokyo" to "Mission compromised, abort and meet Charles in Edinburgh". There is literally no way to tell which of the zillions of grammatically and contextually valid messages of that length is correct.
And if you pad the message randomly with a bit of whitespace, the attacker gets only a vague upper bound on the length. Oh and you can also do traffic analysis based on the existence and timing of the transmission itself. (That is, you can surmise that there was a message worth sending, of approximately this length, between these parties, at this time.)
Actually the ratio of key length to message length. The whole point of OTP is that the message is exactly as short as the key -- or, as one usually thinks of it, the key is exactly as long as the message.
What? You're referring to "DPL" for Debian Project Leader? Dude, we've all called the DPL the DPL as long as there has been one.
It's not. Debian has very little need for money. Hardware? Donated. Bandwidth? Donated. Staff? Volunteer, or in a few cases salaried by companies with an interest in Debian. Conferences? Sponsored by those same companies. I'm sure there are things the Project could do with a huge budget, but all in all there are a lot more needy nonprofits out there.
Several GNU manuals include the GNU Manifesto as an invariant section -- in fact, I can't back this up, but it certainly appears that the main motivation for the invariant section clause was specifically to prevent people from removing the GNU Manifesto from GNU manuals.
As others have said, there are quite a few onerous and ambiguous clauses in the GFDL; it's not all about invariant sections. Some of these seem to be mere bugs in the license text, rather than in the intent. Others, like the requirement to cram the whole text of the GFDL onto anything (even, say, a reference card) derived from GFDL'd works, are annoying but not necessarily non-free.
Certainly, the non-modifiable sections of a GFDL work cause the most fear and loathing. If you really think none of those problems could happen in practice, please see this message for a scenario I find very believable.
Creative Commons (in particular the Attribution license) seems to have its heart in the right place. Depending on whom you ask, there are a few "bugs" in that one too, but they seem to be relatively minor nits. As such, there is hope that the Debian legal eagles can negotiate with Creative Commons to iron out problems for future editions of the CC licenses. Certainly the two groups are talking to each other.
Meanwhile, there's no reason you can't use your code license for documentation -- be that the GPL, or some BSD-like thing, or what have you.
Consensus seems to be that the GFDL has enough problems that even without invariant sections, it's not a free license. As such, the convenience to the user doesn't outweigh sticking to principles of freedom. Just as it did not in the case of Netscape 4.x, which was by far the best graphical web browser for Debian platforms in its day, but didn't ship with source code. If users want manuals, they'll have to point their /etc/apt/sources.list at the non-free section of the archive. In practice, including "non-free" in your downloads is really no inconvenience at all, unless you've only got Debian CDs and no net access, and the CD vendor chose not to include documentation packages from non-free. (This is something a vendor can choose to do, if they wish to take the trouble to comb through the non-free archive to see what they can legally ship at all.)
Curiously enough, practical problems of documentation are mitigated a little bit by a completely unrelated issue. The GNU Project tends to spurn "man pages" as a documentation format, so most GFDL documents are other format documents, such as info pages. The Debian Project still likes man pages, so there are a number of contributed man pages in GNU packages in Debian which were not from the GNU upstream.
"Developers" really means "members of the Project". The term refers to the reality that Debian is a technical project and doesn't have a lot of need for people who can't do actual software development.
As for why only Project members can be the Project Leader, that's pretty common in organisations of all sorts.
Guess that depends on what you mean by freedom. Richard Stallman disagrees quite publicly with the Debian Project in the matter of the GNU Free Documentation License the Project does not consider it sufficiently free.
Some of you will think it is heresy to regard a license from the Free Software Foundation as insufficiently free. Heresy or not, though, I agree with the Debian Project: the GFDL imposes some onerous restrictions on what users can do with the licensed work, and Stallman seems unwilling to drop some of these restrictions.
As it happens (bringing us back on topic), the first nominee for Debian Project Leader 2005, Matthew Garrett, features prominently in the above document detailing why RMS's documentation license is not free enough.
Yes - but not "runtime" as in "virtual machine". It does indeed compile to native code, but it still uses its own libraries - libobjc in particular. This is really no different from C, C++, Common LISP, Fortran, or pretty much any other compiled language. They each have some sort of runtime library support to implement parts of their specific language specs.
That's the thing, though - why would you trust the .torrent? Because nobody posting on Slashdot could possibly be a malicious hax0r? Best to find a linux-2.6.0.tar.bz2.sign somewhere that checks out, and uses DSA key ID 517D0F0E.
(Oh yeah - don't take my word for the key ID, either.)
Ob2.6.0Mirror (.sign)
Frankly I don't see the relevance of your data points.
I've seen plenty of machines that came with Windows 95 and 16 MB of RAM. Many Windows 98 machines came with 64 MB. You're talking about 6 times that much. Would you really be willing to stipulate that 64 MB is enough for Windows XP if you just "disable useless services and eye candy and voila"?
PGP keyservers (unlike, say, Kerberos KDCs) are completely untrusted. Anyone can upload any key to a keyserver. And downloading a key from a keyserver implies nothing about that key.
To verify that you have a valid key, you have to rely on the web of trust. Basically, if a key is signed by someone whose key is signed by someone [recurse through however many levels you are comfortable with] whose key you have personally inspected, then the key can be assigned a trust metric based on how reliable you consider that chain of signatures to be. (Basically, how much you trust the integrity and acuity of the people controlling the chain of signatures.)
PGP and GnuPG have supported this infrastructure from Day 1. Asking people to trust an arbitrary third-party public keyserver was never in the plans.
Great idea. In fact, already implemented. See several other posts in this story, concerning AJ's and BenC's programs for this purpose. You will be gratified to know that they work pretty much as you described.
OpenBSD prevents stolen passwords from being used to log into a system? How?
Indeed, that's one of the few areas where the Debian Project has lagged behind other distribution vendors technically - cryptographic signature verification for packages.
This infrastructure has been kind of long in coming, but as of a few months ago, you can now verify Debian package signatures with debsig-verify. Might I suggest everyone install and use that?
That's exactly what hacker is saying. His MTA is blocking the mail, dropping it on the floor. And producing a 550 status code, telling whoever tried to send the message that it is being dropped on the floor, instead of a 200 code, suggesting that it will be delivered.
hacker's MTA is not returning anything to sender.
Also true. Whoever connected to his sendmail daemon can either generate a bounce, or not generate one. If the spammer connected directly to the SMTP port, he will almost certainly not bother to send a bounce that he knows is just a waste of his own resources. If, instead, the spammer has used an open relay and this relay is connecting to hacker's port 25, then the relay might (incorrectly) generate a bounce to the envelope sender - but this is the fault of the open relay, which never should have accepted responsibility in the first place for remotely delivering a message from an unknown sender.
I'm not up on the state of the art in grabbing hashes remotely. But I think you missed my point, so I'll restate it: it doesn't matter whether or not you can decrypt a LANMAN or NT hash (which is what this story is about). All you need to do is sniff the hash - then use the hash, as an opaque hash, to do pretty much anything on an NT network except log in interactively at the console.
So - yes it's nice to decrypt a hash, if you need to log in to a local console interactively and you don't want to change the user's password on the domain controller.[*]
And it is also nice in a "hmm, maybe he also used the same password for amazon.com" sort of way.
But NT security rests on the secrecy of the hash, not the encryption of the hash.
This isn't a security problem.
Windows password hashes (both the LanManager hash described here and the newer NT hash) are never sent "in the clear" over a network, or accessible to non-admins.
Why? Because they are plaintext-equivalent. Most NT network protocols treat the hash itself as a shared secret and do not make any attempt to verify that you know the actual password.
Yes, that's right. You already don't need to know the user's unencrypted password - except possibly for changing it (I can't remember offhand whether the various password-change calls require proof of knowledge of the old password - but I don't think they do either). Once an attacker gets the hashes out of your SAM, the game is already up, even if he can't decrypt them.
Given this fact, I sometimes wonder why Microsoft even bothered to try making NTLM a secure hash. BASE64 would have done pretty much the same job.
Move along, nothing to see here. Your passwords are just as secure, or as insecure, as they ever were.