Many mail clients have support for PGP. Someone has written a wrapper called pgpgpg which accepts PGP arguments and sends a translated set of arguments to GPG. This makes integration into existing mail clients much easier.
If you can't use the wrapper for some reason, all is not lost. Many PGP command-line arguments translate directly into GPG. Although PGP has some vestigal DOS-isms in its command-line syntax -- e.g., you need to use the -f switch to get it to DTRT with pipes, which is not necessary in GPG -- it's simple to flense them out in most cases.
The true importance of this news item never had anything to do with practical matters of security. If you're concerned with and knowledgeable about computer security, you're probably not using Windows -- especially if you're trying to keep the NSA out.
The real issue is the effect this story will have on Microsoft's international image. They are already considered to be very Americocentric (as are many other American companies, to be fair). Remember Microsoft's refusal to produce an Icelandic version of Windows? They ticked off lots of non-Americans with that move, not all of them in Iceland.
The idea that Microsoft would truckle to the whims of an American intelligence agency only worsens the problem. It didn't turn out to be true, but people aren't going to remember that. They'll remember the accusation far longer than they'll recall the exoneration.
It sucks, but the truth just isn't an important factor in shaping public opinion. Microsoft lost big on this one.
What's this idea so many people seem to have about shielding twelve-year-olds from anything that might make them sad? Is it some sort of child abuse to tell them what you believe to be the truth?
And don't give me that "do it for the children" schtick, or I'll find you wherever you hide.
Well, y'know what I'm waiting for? I'm awaiting Bill Gates' attempt to provide himself immortality through a computer.
His holographic image will briefly appear and say the words:
"General Protection Fault. Oh, the pain!..."
And that'll be it for the next hundred years, while programmers pretend to try to fix the problem while secretly mapping out new levels of VRHell for Gates.
Sitting in the kitchen with Grandpa's hologram 'Though he has no substance he is still a great old man Come on by and say hello any time you can We'll be sitting in the kitchen with Grandpa's hologram
All comedy eventually comes true in some form. Read Mad magazine from the 1950's if you don't believe me.
Under the zero-one-infinity rule, one should either allow no moderation, M1 moderation only, or Mn moderation. Perl will make this easier than C would; it is my understanding that Slashdot's backend is written in Perl. Should be lots of fun!
H.L. Mencken wrote about the attempts to define a journalistic code of ethics. He had his usual fun with ridiculing the proposals, but he also exposed their real weakness: Journalists, unlike doctors and lawyers, are not usually their own bosses. Thus, their attempts to define ethical codes comparable to those which doctors and lawyers swear to obey are basically flawed.
Ethical initiatives from the bottom up rarely succeed, in my experience. Ethical rot comes from the top down.
If developers want to impose such ethics on the software industry, they must do one of two things first:
Convince the owners of software companies to sign on to a code of ethics.
Unionize, and use some of their subsequent negotiating power to push such a code through.
Expect failure. Programmers don't generally organize that way, and managers don't care. Sorry, there is no other way.
It took Hotmail a good long time to respond to this crack, which has been up since Sunday morning proximo. During that time, much email has been illicitly read, some illicitly sent, a few DejaNews identities probably pirated.
If the users of Hotmail wanted to try their hand at a class-action suit, they might be able to pull it off. Yes, Hotmail is free, but they generate income based upon the number of users; therefore, their userbase is responsible for their income. They can't ask for their money back, but they can probably collect damages.
Something for an enterprising attorney to investigate!
I don't think it's a good idea to merge updates/ and redhat-contrib/ as the author suggests. updates/ should be reserved for, well, updates to the packages supplied with a typical Red Hat distribution. redhat-contrib/ is a nice way to provide things they can't include in the distribution, for licensing or other reasons.
Chuck may look more friendly than mean, but Tux just sits there looking vegitative. Seriously, take a good look at Tux. He just sort of sits there, staring off into space.
I take it you don't think serial killers are dangerous.
Tux's real secret has nothing to do with psychic powers or concealed weapons. While he does have an arsenal under that tuxedo that would make Travis Bickle envious, and he thinks his neighbor's 3000-year-old dog is mentally urging him to kill, the real reason to fear Tux is simply this:
I have no direct knowledge of his programming creds, but he's certainly a good writer. We need that as much as we need good coders, maybe even more. Hacker advocacy so far has been amateurishly pathetic except for a few shining instances. It's time we started winning -- and this guy writes like a winner.
As far as the myriad formats go, it is possible for the maintainers to convert from one to another. This doesn't require any knowledge of the topic at hand, and with most formats it could probably be done mechanically.
This is false. It is not possible to convert automatically ("mechanically"? sweet God!) from HTML to TeX in a reasonable way, since TeX contains information that is entirely absent in HTML. Ditto HTML to SGML. Ditto HTML to PostScript and vice versa. Ditto plaintext to much of anything.
SGML is the best all-around choice, since it contains more information than any other format. TeX is also quite good. texinfo is not as good, but it will do.
Incidentally, TeX source is quite readable. Your concern in that regard has more to do with the formats provided by the LDP than with the submission formats. If a contributor sends the LDP an SGML document, they can automatically convert it to any number of formats, some printable, others browseable, others viewable through cat or similar programs.
In summary, the choice of a document format is a lot more complicated than you make it out to be, and a lot more relevant as well.
While it's a good thing to cater to the authors of HOWTO documents as much as possible, it's also good to consider the reader's convenience. I wouldn't want to be confronted with a melange of TeX, HTML, PostScript, ASCII and SGML docs in one hierarchy, nor would I care to go searching through multiple hierarchies if the author decided to provide the docs in only one format.
Of course, SGML covers that requirement admirably -- one can generate any number of representations from SGML source -- but unless authors are constrained to provide SGML docs, one of two problems will arise:
The user has to hunt for the proper doc, then has to know how to read it. This last requirement will cause more problems as Linux widens its user base; it may already be untrue of a good percentage of Linux users.
The LDP has to convert the doc to SGML. This is difficult, certainly not easy to automate since SGML is a more general format than other common source formats, and it won't scale well as the number of HOWTO's grows.
These are strictly long-term concerns, however. For now, the LDP has not reached a state of completeness where it can afford to discard any contributions. Please, though -- no MSWord.
if you use your brain (and I know you must have one in there some where) you shouldn't have a need to use lynx.
Interesting. Is it your assertion, then, that blind people using emacspeak are stupid and unworthy? (And don't even try to convince me to use w3. lynx is much better.)
If your comment is moderated down, I can only suggest that this is justice in action.
Pretty Good Privacy, bullshat. PGP will offer protection from some kid intercepting your mail from a gateway, but anyone serious can crack it in a couple of hours.
Really? That's an interesting claim -- sounds testable!
Here's something we can do: I'll encrypt a 60 KB message using PGP. I guarantee that the message is in clear ASCII English text. I'll turn over the cleartext and the key to a mutually-agreed-upon third party, and send the encrypted text to both of you. The third party can confirm that the encrypted text was encrypted with the key I submitted.
A couple of hours is too short -- I'll give you a day. If within 24 hours you have cracked that message to the satisfaction of the third party, you win. If you haven't, PGP wins.
The fact that you have not addressed key strengths or other matters in your original statement implies one of two things: Either you have discovered a weakness in RSA that renders those issues irrelevant, or you don't know what you're talking about. If you have broken 2048-bit RSA, that is interesting news.
The author of this article concentrated solely (she thought) on the respects in which technology has compromised our privacy. She misses the boat on two counts by doing so.
First, she fails to note the respects in which technology can enhance our privacy as well. It's a hoary example but a good one: For every radar gun we invent, we can and should invent a radar detector and a radar scrambler. If we have not developed countermeasures for other methods of surveillance, then it's up to knowledgeable people to educate the market so that there is a demand for those countermeasures. Is that naive? I hope not.
Secondly, she doesn't pick up on the fact that most of these privacy invasions were caused by law, not just technology. Some of us live in countries where we can fight unjust laws -- do so! We can't hurt 'em if we don't hit 'em!
If we lose our rights due to inaction, then we didn't deserve them in the first place.
He first states that companies should open up their source because there is a larger market -- then threatens that even if they don't, we will reverse engineer your product anyway -- so just give us the goods now.
So you're confused by the author's presentation of more than one reason to do something. What's the problem?
He also touches upon, but fails to strike down the idea that if everyone has your product specifications, then the competition can clone your cycle even faster.
This is false. He quotes some frighteningly short times for the reverse engineering of some products -- go back to the article and to a search on 3C509 to refresh your memory.
Many mail clients have support for PGP. Someone has written a wrapper called pgpgpg which accepts PGP arguments and sends a translated set of arguments to GPG. This makes integration into existing mail clients much easier.
If you can't use the wrapper for some reason, all is not lost. Many PGP command-line arguments translate directly into GPG. Although PGP has some vestigal DOS-isms in its command-line syntax -- e.g., you need to use the -f switch to get it to DTRT with pipes, which is not necessary in GPG -- it's simple to flense them out in most cases.
--
The true importance of this news item never had anything to do with practical matters of security. If you're concerned with and knowledgeable about computer security, you're probably not using Windows -- especially if you're trying to keep the NSA out.
The real issue is the effect this story will have on Microsoft's international image. They are already considered to be very Americocentric (as are many other American companies, to be fair). Remember Microsoft's refusal to produce an Icelandic version of Windows? They ticked off lots of non-Americans with that move, not all of them in Iceland.
The idea that Microsoft would truckle to the whims of an American intelligence agency only worsens the problem. It didn't turn out to be true, but people aren't going to remember that. They'll remember the accusation far longer than they'll recall the exoneration.
It sucks, but the truth just isn't an important factor in shaping public opinion. Microsoft lost big on this one.
--
What's this idea so many people seem to have about shielding twelve-year-olds from anything that might make them sad? Is it some sort of child abuse to tell them what you believe to be the truth?
And don't give me that "do it for the children" schtick, or I'll find you wherever you hide.
--
How is thy logic broken? Let me count the ways:
Incidentally, how can you favor one OS for every conceivable task? And why do you attribute similarly limited views to others?
--
Well, y'know what I'm waiting for? I'm awaiting Bill Gates' attempt to provide himself immortality through a computer.
His holographic image will briefly appear and say the words:
"General Protection Fault. Oh, the pain!..."
And that'll be it for the next hundred years, while programmers pretend to try to fix the problem while secretly mapping out new levels of VRHell for Gates.
I Have No Mouth And I Must Scream, here we come.
--
...this?
Sitting in the kitchen with Grandpa's hologram
'Though he has no substance he is still a great old man
Come on by and say hello any time you can
We'll be sitting in the kitchen with Grandpa's hologram
All comedy eventually comes true in some form. Read Mad magazine from the 1950's if you don't believe me.
--
Under the zero-one-infinity rule, one should either allow no moderation, M1 moderation only, or Mn moderation. Perl will make this easier than C would; it is my understanding that Slashdot's backend is written in Perl. Should be lots of fun!
(Yes, I'm kidding.)
--
H.L. Mencken wrote about the attempts to define a journalistic code of ethics. He had his usual fun with ridiculing the proposals, but he also exposed their real weakness: Journalists, unlike doctors and lawyers, are not usually their own bosses. Thus, their attempts to define ethical codes comparable to those which doctors and lawyers swear to obey are basically flawed.
Ethical initiatives from the bottom up rarely succeed, in my experience. Ethical rot comes from the top down.
If developers want to impose such ethics on the software industry, they must do one of two things first:
Expect failure. Programmers don't generally organize that way, and managers don't care. Sorry, there is no other way.
--
It took Hotmail a good long time to respond to this crack, which has been up since Sunday morning proximo. During that time, much email has been illicitly read, some illicitly sent, a few DejaNews identities probably pirated.
If the users of Hotmail wanted to try their hand at a class-action suit, they might be able to pull it off. Yes, Hotmail is free, but they generate income based upon the number of users; therefore, their userbase is responsible for their income. They can't ask for their money back, but they can probably collect damages.
Something for an enterprising attorney to investigate!
--
I don't think it's a good idea to merge updates/ and redhat-contrib/ as the author suggests. updates/ should be reserved for, well, updates to the packages supplied with a typical Red Hat distribution. redhat-contrib/ is a nice way to provide things they can't include in the distribution, for licensing or other reasons.
--
Number of known exploits != number of exploits. More eyes looking at the code equals more problems found -- and fixed.
If you want to create an OS with no known exploits, you can run your own, sui generis homebrew system. Security through obscurity. Terrific.
--
I take it you don't think serial killers are dangerous.
Tux's real secret has nothing to do with psychic powers or concealed weapons. While he does have an arsenal under that tuxedo that would make Travis Bickle envious, and he thinks his neighbor's 3000-year-old dog is mentally urging him to kill, the real reason to fear Tux is simply this:
A penguin without hope is a penguin without fear.
--
It ought to be a pitchfork, as Dante's Inferno informs us. And when you know what the pitchfork is for, you won't think that little demon's so cute.
Hint: What's the difference between a dumptruck full of dead babies and a dumptruck full of bowling balls?
--
I have no direct knowledge of his programming creds, but he's certainly a good writer. We need that as much as we need good coders, maybe even more. Hacker advocacy so far has been amateurishly pathetic except for a few shining instances. It's time we started winning -- and this guy writes like a winner.
--
This is false. It is not possible to convert automatically ("mechanically"? sweet God!) from HTML to TeX in a reasonable way, since TeX contains information that is entirely absent in HTML. Ditto HTML to SGML. Ditto HTML to PostScript and vice versa. Ditto plaintext to much of anything.
SGML is the best all-around choice, since it contains more information than any other format. TeX is also quite good. texinfo is not as good, but it will do.
Incidentally, TeX source is quite readable. Your concern in that regard has more to do with the formats provided by the LDP than with the submission formats. If a contributor sends the LDP an SGML document, they can automatically convert it to any number of formats, some printable, others browseable, others viewable through cat or similar programs.
In summary, the choice of a document format is a lot more complicated than you make it out to be, and a lot more relevant as well.
--
While it's a good thing to cater to the authors of HOWTO documents as much as possible, it's also good to consider the reader's convenience. I wouldn't want to be confronted with a melange of TeX, HTML, PostScript, ASCII and SGML docs in one hierarchy, nor would I care to go searching through multiple hierarchies if the author decided to provide the docs in only one format.
Of course, SGML covers that requirement admirably -- one can generate any number of representations from SGML source -- but unless authors are constrained to provide SGML docs, one of two problems will arise:
These are strictly long-term concerns, however. For now, the LDP has not reached a state of completeness where it can afford to discard any contributions. Please, though -- no MSWord.
--
Interesting. Is it your assertion, then, that blind people using emacspeak are stupid and unworthy? (And don't even try to convince me to use w3. lynx is much better.)
If your comment is moderated down, I can only suggest that this is justice in action.
--
As a programmer? Nah. Delayed release is an important part of programming.
--
Should have been: "Beware of gifts bearing Greeks." :)
--
This is false. $2500 spends exactly the same as 12.5% of $20K, 50% of $5K, or 200% of $1250. $2500 is $2500.
If I saw $2500 lying on the street, I believe I might exert myself to pick it up.
--
Really? That's an interesting claim -- sounds testable!
Here's something we can do: I'll encrypt a 60 KB message using PGP. I guarantee that the message is in clear ASCII English text. I'll turn over the cleartext and the key to a mutually-agreed-upon third party, and send the encrypted text to both of you. The third party can confirm that the encrypted text was encrypted with the key I submitted.
A couple of hours is too short -- I'll give you a day. If within 24 hours you have cracked that message to the satisfaction of the third party, you win. If you haven't, PGP wins.
The fact that you have not addressed key strengths or other matters in your original statement implies one of two things: Either you have discovered a weakness in RSA that renders those issues irrelevant, or you don't know what you're talking about. If you have broken 2048-bit RSA, that is interesting news.
Let's get testing!
--
The author of this article concentrated solely (she thought) on the respects in which technology has compromised our privacy. She misses the boat on two counts by doing so.
First, she fails to note the respects in which technology can enhance our privacy as well. It's a hoary example but a good one: For every radar gun we invent, we can and should invent a radar detector and a radar scrambler. If we have not developed countermeasures for other methods of surveillance, then it's up to knowledgeable people to educate the market so that there is a demand for those countermeasures. Is that naive? I hope not.
Secondly, she doesn't pick up on the fact that most of these privacy invasions were caused by law, not just technology. Some of us live in countries where we can fight unjust laws -- do so! We can't hurt 'em if we don't hit 'em!
If we lose our rights due to inaction, then we didn't deserve them in the first place.
--
So you're confused by the author's presentation of more than one reason to do something. What's the problem?
This is false. He quotes some frighteningly short times for the reverse engineering of some products -- go back to the article and to a search on 3C509 to refresh your memory.
--
Okay, 3DES then.
IPSEC bases its authentication on trusted hosts, not on trusted users. It does not solve the same problem.
--
We can be free at last of the scourge of IP NAT!
--