Slashdot Mirror
Not Just Apple: GnuTLS Bug Means Security Flaw For Major Linux Distros
According to an article at Ars Technica, a major security bug faces Linux users, akin to the one recently found in Apple's iOS (and which Apple has since fixed). Says the article:"The bug is the result of commands in a section of the GnuTLS code that verify the authenticity of TLS certificates, which are often known simply as X509 certificates. The coding error, which may have been present in the code since 2005, causes critical verification checks to be terminated, drawing ironic parallels to the extremely critical 'goto fail' flaw that for months put users of Apple's iOS and OS X operating systems at risk of surreptitious eavesdropping attacks. Apple developers have since patched the bug." And while Apple can readily fix a bug in its own software, at least for users who keep up on patches, "Linux" refers to a broad range of systems and vendors, rather than a single company, and the affected systems include some of the biggest names in the Linux world, like Red Hat, Debian, and Ubuntu.
Who uses GnuTLS over OpenSSL anyway?!
This if nothing else, should show everyone it's time to switch to Windows, the OS immune to exploits.
The shepherds did so well protecting the flock that the sheep no longer believed that wolves existed.
Even if the distribution doesn't provide the update as quickly as desired...
The site can get the update directly from the project and apply it themselves.
The impact of this bug does not compare to the goto fail bug. Most Linux distributions use OpenSSL for TLS. Even if a program links to GnuTLS, it may not use GnuTLS for certificate validation, and if it doesn't, then it's not affected by this bug (one example is Google Chrome). It's not like iOS where everything is required (by App Store rules) to use SecureTransport.
My distro patched this over a month ago.
Il n'y a pas de Planet B.
that Apple took notice of some accusations that the NSA managed to modiy some open source codebases, reviewed all code that was checked in at about the suspicious time frame, and found the "goto fail" bug that way. No idea whether this is true, but I'd be curious who checked in this bug.
Funny :) I suppose we should switch all of our web-servers to IIS too?
Is anyone other than Debian zealous enough to use GnuTLS?
I rarely agree with Howard Chu of OpenLDAP fame, but... http://www.openldap.org/lists/...
> Most Linux distributions use OpenSSL for TLS.
> Even if a program links to GnuTLS, it may not use GnuTLS for certificate validation,
> and if it doesn't, then it's not affected by this bug (one example is Google Chrome)
Agree. I've ran through everything that linked to gnutls on my distro (Arch) and although there's
quite a lot of binaries that do, most of those do not offer TLS connections (or any network connectivity at all), so my
guess (without knowing GNuTLS at all) is that they use some other feature offered by the library.
Of those that I know actually capable of SSL/TLS connections, all (also) link to OpenSSL.
So without making a definitive statement, AFAICT this should have near zero impact on GNU/Linux.
And use OpenSSL. As awkward as it may be, it doesn't have the design flaws that GNU TLS does.
Are you trolling for an Apple-vs-Linux flame war? do you have a zealous attachment to Apple? or are you just dull?
1) This is old news, and the /. has already reported on it;
2) Hardly anything uses the GNU TLS library, and for the same reason people have been advising against Apple's rewrite of security libraries: because it's better to use something that's had over a decade of development and review and is widely deployed across a series of platforms;
3) You're arguing about the heterogeneity of the Linux platform as if it's a bad thing, while in fact this acts in Linux's favour. Even though the GNU project might like people to use gnutls, distros have chosen not to. Apple either discourages choice or makes it impossible, depending on what exactly you're targeting, which is why everything was affected.
Fixed at the beginning of March.
Example: http://advisories.mageia.org/MGASA-2014-0117.html
"Nothing to see here. Move on."
Create a library with that name that does nothing, or logs errors for any entry points. Why is something being shipped that is insecure. I understand that the builds have to be changed. But the library could be replaced with a skeleton right now, can't it?
And maybe we would see that its not quite as in-active as people think.
"Linux" refers to a broad range of systems and vendors
Actually, Linux refers to the operating system kernel which has nothing to do with GnuTLS. (Wow, someone actually uses GnuTLS?)
Ezekiel 23:20
And while Apple can readily fix a bug in its own software, at least for users who keep up on patches, "Linux" refers to a broad range of systems and vendors, rather than a single company, and the affected systems include some of the biggest names in the Linux world, like Red Hat, Debian, and Ubuntu.
Gee. it sure is a problem that Red Hat, Debian, or Ubuntu couldn't just, you know, fix the bug and recompile the source code. Oh wait, they already did
FTFA
GnuTLS developers published this bare-bones advisory that urges all users to upgrade to version 3.2.12. The flaw, formally indexed as CVE-2014-0092, is described by a GnuTLS developer as "an important (and at the same time embarrassing) bug discovered during an audit for Red Hat." Debian's advisory is here.
This is a problem only where sysadmins don't regularly update their systems.
It's Okay, boys: this is FIXED already.
Create a library with that name that does nothing, or logs errors for any entry points. Why is something being shipped that is insecure. I understand that the builds have to be changed. But the library could be replaced with a skeleton right now, can't it?
And maybe we would see that its not quite as in-active as people think.
There are two distinct part of SSL/TLS; encryption and authentication. In this case it's only the authentication portion that has an issue, not the encryption portion. There are several places in which GnuTLS is used for encryption but not authentication such as MTA (email) transfers over TLS (at least most of the time).
As for why GnuTLS exists, AFAIK it's mainly because of licensing issues -- compiling a GPLv2+ program against OpenSSL gets into licensing troubles, so there needed to be a GPL compatible alternative.
You pay 5.5 billion for a supprt contract for XP
That's why I use semaphore code, no freaking computers for me, as I couldn't investigate the hardware AND software myself, and, as you say, trust no one. But I CAN trust my semaphore flags. I sometimes use morse code, but I'm not sure if there are any bugs in the transmission of it.
The difference is that with closed source, the only exploits that are discovered by third parties and get fixed are those that have already been exploited, and already resulted in vulnerable systems.
With open source, exploits can potentially be discovered and reported by other parties *before* the exploit has actually ever been used, meaning that a fix is available at the same time that the exploit becomes public knowledge, and anyone who updates as soon as such an exploit becomes known has a higher level of confidence that their system will have not yet been compromised. The very fact that open source may also make it easier for a third party to find a way to exploit a previously unknown vulnerability also makes it easier for a third party to take action that will lead to the issue being corrected.
With open source, such critical bugs can and actually *will* be fixed, a sufficiently technically competent individual could even do so themselves, where with closed source, absolutely everyone is at the whim of the development team's schedule.
File under 'M' for 'Manic ranting'
Free/Open code is a necessary but not sufficient condition for security.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
This will be the last post you ever make. The black helicopters will swoop you up and take you to the area 51 where aliens will perform experiments on you on the set where they faked the moon landing.
And lmfao, the captia was "abortion"!
There are two distinct part of SSL/TLS; encryption and authentication. In this case it's only the authentication portion that has an issue, not the encryption portion.
Unauthenticated public key encryption is useless against an active attacker (one able to modify traffic, rather than just eavesdrop on it).
There are several places in which GnuTLS is used for encryption but not authentication such as MTA (email) transfers over TLS (at least most of the time).
Huh? Even for SSMTP, certificates can -- and must! -- be checked.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
Now, who was this comment for? Half the stories generate complaints about obcure acronyms and lack of context in the summary, but you manage to throw that in?
Fuck systemd. Fuck Redhat. Fuck Soylent, too. Wait, scratch the last one.
Yes its used, but only sometimes. Only for that mail stuff, and hey maybe only if someone else is handling authentication because we know thats broken. And we need the stuff there for legal reasons and we need it there as an alternative. Just in case we need to use it, even though we know its broken.
So tell me, why cant we have the parts we know are insecure issue a log each time they are run?
This is an unprovable statement. You have no idea how many exploits are discovered by the authors or those in charge of maintaining closed code nor how many of those are fixed.
What your statement really is saying is that the only publicized exploits are those found by third parties. And this is, for the most part, the same with open source code.
Eight years later? And this in code needed for security. Are you saying my confidence in open source code review should be increased now?
This story should prove once and for all that ... "open source" does not provide any different level of security than closed source.
Um how? It proves that OSS is not perfect. No one ever claimed otherwise. An isolated incident proves nothing about the reltive security of the two.
OpenBSD (OSS) has had a couple of security flaws over the years. Windows 95 also had "some". Doesn't mean they're equally secure.
SJW n. One who posts facts.
libgnutls26:amd64 2.12.23-1ubuntu4.2
zless /usr/share/doc/libgnutls26/changelog.Debian.gz
gnutls26 (2.12.23-1ubuntu4.2) saucy-security; urgency=medium
* SECURITY UPDATE: certificate validation bypass
- debian/patches/CVE-2014-0092.patch: correct return codes in
lib/x509/verify.c.
- CVE-2014-0092
-- Marc Deslauriers Mon, 03 Mar 2014 14:14:00 -0500
EIght years is better than never.
This bug was fixed the same day that it became public knowledge. Unless the bug was discovered by the internal team, this will never be case with closed source.
File under 'M' for 'Manic ranting'
There are several places in which GnuTLS is used for encryption but not authentication such as MTA (email) transfers over TLS (at least most of the time).
Huh? Even for SSMTP, certificates can -- and must! -- be checked.
I think you mean ESMTPS. And no, usually TLS certificates are not checked by default (they can be, optionally); many TLS certificates used for ESMTPS are not signed by a CA, so there's nothing to check them against. There's also a new DANE protocol where domains that are using DNSSEC can specify TLS certificate details for mail in the DNS record for the domain, but this is currently not popular (supposedly only about 20 domains are using it). Other issues with this are that a number of DNS servers haven't implemented DNSSEC, and a number of MTAs haven't implemented the DANE protocol either.
And we don't want the situation where mail domains have to have thier TLS certificate signed by a CA, because that gets back into the mess of "which CAs are trustworthy" for mail purposes, paying fees for SSL certificate signatures, and so on. It's better to at least have encrypted email transfers than to only allow encrypted transfers from authenticated senders.
Maybe it just prove that you should use the tested variant even if you don't like the license. Most people use openSSL and even gnuTLS was fixed before it hit the news (a month ago). If it proves something, it proves that some people are too ideologically entrenched. There is really good and reviewed stuff out there and then come the GPL evangelists, writing stuff again and a little bit different just to make a point and sometime a little bit too different.
It's better to at least have encrypted email transfers than to only allow encrypted transfers from authenticated senders.
Better in what sense? Without authentication MITM attacks are trivial, making the encryption irrelevant.
If what you say is true (and it probably is) then the state of e-mail security is even worse than I thought it was. Most mail providers don't support TLS anyway, but without authentication it doesn't really matter if they do.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
It's not a question of "liking" the licence, it's a question of legally being allowed to use it or not.
And while Apple can readily fix a bug in its own software, at least for users who keep up on patches, "Linux" refers to a broad range of systems and vendors, rather than a single company, and the affected systems include some of the biggest names in the Linux world, like Red Hat, Debian, and Ubuntu.
And thanks to the LGPL license of GnuTLS, all the users have the possibility to upgrade their systems, independently of whether Red Hat, Debian, Ubuntu, Apple, Microsoft believe that maintaining those systems is still commercially convenient or not. GPLv3 would be better, as it would give the users the warranty of being able to actually install the updated code into their devices, which is important for non-PCs.
I prefer Aldis Lamps. They're quite versatile - we just did a performance of Julius Caesar with them.
I'd hate to think some people are being bankrolled to vilify Linux just as Windows XP is dumped and new operating systems are under consideration.
What a coincidence given this is old news, patchable and SSL'able. How cynical of me.
And while Apple can readily fix a bug in its own software, at least for users who keep up on patches, "Linux" refers to a broad range of systems and vendors, rather than a single company, and the affected systems include some of the biggest names in the Linux world, like Red Hat, Debian, and Ubuntu.
What a trolling comment. Each Linux distro is an OS in its own right. Red Hat, Debian and Canonical can also readily fix a bug in their distros and have a good record of releasing fixes fast when it comes to security issues.
Looks like someone can't tell the difference between "March" and "April". Hint: "April" is the one that starts with an "A".
The major distros posted patches for this flaw to their repositories within a day or two of it being made public. (Not to say that it isn't embarrassing for stuff like this to make it into the codebase; but at least it was fixed quickly once it was discovered.)
The GnuTLS bug is freakishly easy to exploit. The OpenSSL bug at least requires you to modify your code to exploit the bug. This one is almost work-free.
If the same bug appears on OpenSSL, I would immediately disable all SSL related applications.
Thank god nothing uses GnuTLS...except aptitude.
(I am a security researcher who spent a day or 2 researching these 2 bugs)
The irony, of course, is that most people haven't read Microsoft's EULA which effectively says 'Not only are we not responsible if Windows fails, but we'll sue you if you try to fix it yourself.'
This is really gonna bite the hundreds of millions running XP who will be orphaned this year when Microsoft stops supporting it. Not only do they face the prospect, in a matter of weeks, of never again seeing security updates from Microsoft, but it will be illegal to even try to fix future bugs themselves (or hire a third party to do it).
This last bit is something that Linux users have as a right
Sometimes boldness is in fashion. Sometimes only the brave will be bold.
MITM requires active interception to eavsdrop, wheras an unencrypted connection is vulnerable to passive eavesdropping. That is the sense in which an encrypted but not properly authenticated connection is "better". Also if the ID of the offered certificate is logged it is possible to audit for a MITM attack after the fact. According to Snowden, the NSA can crack 1024 bit certs' private keys. So really even properly verifying the cert is not secure depending on who your adversary is.
Can we please stop refereing to Linux as if it's an Operating System!? We properly call Apple's Operating System OS X and their mobile variant iOS. We don't call it Darwin now do we? Come on guys! Get it right. This affects RHEL, CentOS, Debian, Ubuntu, Arch, CRUX, etc, etc and anyone else that happens to use the GNU TLS Software in question. Which brings me to another point... What is the software here that's actually affected? gnupgp?
Just try to write an assembler program without using a goto: B R12
If what you say is true (and it probably is) then the state of e-mail security is even worse than I thought it was. Most mail providers don't support TLS anyway, but without authentication it doesn't really matter if they do.
Actually it's quite common for email providers to support TLS transfers today. And the reason I think that's true is that one isn't required to purchase a CA-signed certificate to get that working. If we all had to purchase a CA-signed certificate, I think it would become more rare to see TLS transfers to/from privately-held servers.
If you look at the mail headers for email you receive, you're likely to find "smtps" or "esmtps" in the Received: lines which indicates that it was sent via a TLS transfer. Most mailing list traffic is often done without TLS, though there are exceptions -- Debian's mailing lists still use TLS transfers, which is good.
Generally you're right to point to router security, but I don't think it's relevant here. Router software package installation -- where you might think you want tls to fetch the package safely -- should be using package signatures rather than relying on tls.
Article writer Dan Goodin missed this point in his first draft. He thought he had a story, and failed at the fact-checking stage.
Would you rely on X.509 for a vpn? The implementation is irrelevant.
ATMs, no. Web banking really does have a problem, and it's much bigger than bugs in tls.
I think David Jao and others are right, and this is not news.
This bug was fixed the same day that it became public knowledge.
What do you mean "public knowledge"? The code was always there, the bug was always "public knowledge". I think what you really mean is "responsibly disclosed" which also happens regularly in closed-source software.
The code was always public knowledge.. the bug itself was still unknown until its discovery last month. With closed source, the only way to find a bug is by seeing it happen in a live running instance, while with open source bugs can also be discovered by individuals through inspection of the code itself.
Also, with open source, a programmer or programming team can effect the necessary fixes themselves if they are unsatisfied with the speed of the software development team, while with closed source, absolutely everyone must wait for the software's dev team to address the issue.
File under 'M' for 'Manic ranting'
The code was always public knowledge.. the bug itself was still unknown until its discovery last month.
Unknown to who? Everybody? You really think responsible disclosure is unique to closed source software? It isn't.
Also, with open source, a programmer or programming team can effect the necessary fixes themselves if they are unsatisfied with the speed of the software development team, while with closed source, absolutely everyone must wait for the software's dev team to address the issue.
Yeah nobody disputed that, you're getting confused.
MITM requires active interception to eavsdrop
It's not like it's impossible to have toolkits for making active interception nearly trivial to do (provided you've got the hardware to run it on) and if you're thinking about ISPs or governments as the attackers, they've got access to the sorts of hardware which can run active interception on a massive scale.
Your main defence against them is that your life is very boring and ordinary and they don't give a shit about you. It's the other major group of attackers — plain old criminals who want to steal your money or your identity — who you're really protecting against.
"Little does he know, but there is no 'I' in 'Idiot'!"
...lots of bugs.
The X509 directory for openssl contains 25k lines of C code.
GnuTLS has 35k lines of C.
parsing X509 is a mess, so I expect a lot more bugs... it's not paranoia, just that lots of code mean lots of bugs... and bugs are easy when coding in C....
Oracle installs the Ask toolbar!!!!!!!!!!!!!!
The ones that were fixed by the updates for all RHEL-derived distros, like CentOS, a month ago?
mark
Wow who submitted this? This is over a month old and was already on slashdot when it was breaking. Everyone should be patched by now.
And the reason I think that's true is that one isn't required to purchase a CA-signed certificate to get that working. If we all had to purchase a CA-signed certificate, I think it would become more rare to see TLS transfers to/from privately-held servers.
I think you're arguing that would be a bad thing, but in reality it'd be a nearly-irrelevant thing. Without authentication, encryption protects only against the most casual of snoopers, most of whom wouldn't be able to sniff the packets anyway.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
MITM requires active interception to eavsdrop, wheras an unencrypted connection is vulnerable to passive eavesdropping.
Yes, of course. However, in practice the set of real-world circumstances in which an attacker manages to get sufficient physical access to eavesdrop without also getting sufficient physical access to perform active attacks are vanishingly small, at least in the wired networking space. For wireless it's different, of course (assuming there's no link-layer encryption applied), but inter-MTA transfers are almost never wireless.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
And the reason I think that's true is that one isn't required to purchase a CA-signed certificate to get that working. If we all had to purchase a CA-signed certificate, I think it would become more rare to see TLS transfers to/from privately-held servers.
I think you're arguing that would be a bad thing, but in reality it'd be a nearly-irrelevant thing.
No. The word "reality" doesn't apply here, because what you're describing isn't what's being actually done for SMTP.
Without authentication, encryption protects only against the most casual of snoopers, most of whom wouldn't be able to sniff the packets anyway.
No, but I understand why you'd think this, as it seems to be a common misconception. If you have a specific example to illustrate this case, that would help.
No, but I understand why you'd think this, as it seems to be a common misconception. If you have a specific example to illustrate this case, that would help.
MITM attack.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
No, but I understand why you'd think this, as it seems to be a common misconception. If you have a specific example to illustrate this case, that would help.
MITM attack.
That's not a specific example related to TLS or encryption, it's a vague attack classification. The reason I'm asking the question is to find out if there is an actual issue, and so a vague answer like this cannot help our understanding any.
Oh well. OpenSSL apparently has a vulnerability too. sigh :-/
I feel like I'm spelling out the obvious, but: mail server A opens a TLS connection to mail server B to transfer mail, which starts with a TLS handshake, requiring B to send its public key A. The attacker intercepts the message and sends his public key to A, and completes the handshake with both sides, then proceeds to happily pass the data through reading all of it, since he has the session keys on both sides.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
Zontar's "touched in the head" by schizophrenic multiple personality disorder http://slashdot.org/comments.p... and manic depression http://slashdot.org/comments.p... now go take those meds, you whacko!
Zontar's posts ac evidencing schizophrenic multiple personality disorder http://slashdot.org/comments.p... and manic depression http://slashdot.org/comments.p... now go take those meds you need whacko since when you startup ac posts we know that your mpd is kicking in again and you need a dose!
For your schizophrenic multiple personality disorder http://slashdot.org/comments.p... + manic depression http://slashdot.org/comments.p... now go take those meds, you whacko!
I feel like I'm spelling out the obvious, but: mail server A opens a TLS connection to mail server B to transfer mail, which starts with a TLS handshake, requiring B to send its public key A. The attacker intercepts the message and sends his public key to A, and completes the handshake with both sides, then proceeds to happily pass the data through reading all of it, since he has the session keys on both sides.
You've skipped over the PFS key exchange portion used in TLS.
https://en.wikipedia.org/wiki/...
https://en.wikipedia.org/wiki/...
https://en.wikipedia.org/wiki/...
Maybe the MITM exploit you're talking about is possible, I don't know.
It is. There are many tools out there that implement it. It's the whole reason that we use CAs -- not that they're an ideal solution to the problem, but without some way to verify the authenticity of the public key you're using to bootstrap the key exchange, any PK-based key agreement protocol is subject to MITM attacks.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
It is. There are many tools out there that implement it. It's the whole reason that we use CAs -- not that they're an ideal solution to the problem, but without some way to verify the authenticity of the public key you're using to bootstrap the key exchange, any PK-based key agreement protocol is subject to MITM attacks.
MITM can be an issue. More detailed information about the state of things at the link below.
https://wiki.exim.org/lurker/m...
See you here http://tech.slashdot.org/comme... you bigmouthed little nobody...
APK
P.S.=> Have the balls to show up there in the link above to reply to it (& NOT days later like you did, LONG after I left that thread!)
NOW, in the link above, I simply tore you apart in it vs. your "so-called 'points'" that you "amended" bogusly, changing your parameters/constraints there!
(& I am going to rip you a new asshole there YET AGAIN, publicly, for your BIG mouth you little shit - prepare to be utterly humiliated, publicly...)
... apk
"You barge into discussions with your off-topic hosts file nonsense" - by Zontar The Mindless (9002) on Friday April 11, 2014 @09:51PM (#46731153) FROM -> http://slashdot.org/comments.p...
You said my "APK Hosts File Engine" is a virus/malware http://slashdot.org/comments.p... but it's EASILY PROVABLE it's not, right there in that link too.
Now PROVE YOUR FALSE ACCUSATION above: Show me a quote OR POST of me posting off topic on hosts where they did NOT apply... go for it!
---
You avoided backing up your accusation where YOU said I say you are Barbara, not Barbie = TomHudson (same person http://tech.slashdot.org/comme... , & sockpuppeteer like you) -> http://slashdot.org/comments.p...
Funny you can't back up your "bluster" there either, lol...
---
Why, Lastly?
You're crackers! See here multiple personality disorder http://slashdot.org/comments.p... + manic depression http://slashdot.org/comments.p...
APK
P.S.=> So, THIS quote below is my policy on sockpuppeteers like you Zontar = TrollingForHostsFiles (your sockpuppetry):
"The only way to a achieve peace, is thru the ELIMINATION of those who would perpetuate war (sockpuppet masters like YOU, troll -> http://slashdot.org/comments.p... ). THIS IS MY PROGRAMMING -> http://start64.com/index.php?o... & soon, I will be UNSTOPPABLE..." - Ultron 6 FROM -> http://www.youtube.com/watch?v...
Which quite obviously, I am, since none of you DOLTISH TROLLS are able to validly technically disprove my points on hosts enumerated in the link to my program above of how hosts give users of them more speed, security, reliability, & anonymity... period!
(Trolls like YOU that use sockpuppets http://slashdot.org/comments.p... (your sockpuppet "alterego" TrollingForHostsFiles) & TomHudson - Barbara, not Barbie too http://tech.slashdot.org/comme... before you)
... apk
"You barge into discussions with your off-topic hosts file nonsense" - by Zontar The Mindless (9002) on Friday April 11, 2014 @09:51PM (#46731153) FROM -> http://slashdot.org/comments.p...
You said my "APK Hosts File Engine" is a virus/malware http://slashdot.org/comments.p... but it's EASILY PROVABLE it's not, right there in that link too.
Now PROVE YOUR FALSE ACCUSATION above: Show me a quote OR POST of me posting off topic on hosts where they did NOT apply... go for it!
---
You avoided backing up your accusation where YOU said I say you are Barbara, not Barbie = TomHudson (same person http://tech.slashdot.org/comme... , & sockpuppeteer like you) -> http://slashdot.org/comments.p...
Funny you can't back up your "bluster" there either, lol...
---
Why, Lastly?
You're crackers! See here multiple personality disorder http://slashdot.org/comments.p... + manic depression http://slashdot.org/comments.p...
APK
P.S.=> So, THIS quote below is my policy on sockpuppeteers like you Zontar = TrollingForHostsFiles (your sockpuppetry):
"The only way to a achieve peace, is thru the ELIMINATION of those who would perpetuate war (sockpuppet masters like YOU, troll -> http://slashdot.org/comments.p... ). THIS IS MY PROGRAMMING -> http://start64.com/index.php?o... & soon, I will be UNSTOPPABLE..." - Ultron 6 FROM -> http://www.youtube.com/watch?v...
Which quite obviously, I am, since none of you DOLTISH TROLLS are able to validly technically disprove my points on hosts enumerated in the link to my program above of how hosts give users of them more speed, security, reliability, & anonymity... period!
(Trolls like YOU that use sockpuppets http://slashdot.org/comments.p... (your sockpuppet "alterego" TrollingForHostsFiles) & TomHudson - Barbara, not Barbie too http://tech.slashdot.org/comme... before you)
... apk
"You barge into discussions with your off-topic hosts file nonsense" - by Zontar The Mindless (9002) on Friday April 11, 2014 @09:51PM (#46731153) FROM -> http://slashdot.org/comments.p...
You said my "APK Hosts File Engine" is a virus/malware http://slashdot.org/comments.p... but it's EASILY PROVABLE it's not, right there in that link too.
Now PROVE YOUR FALSE ACCUSATION above: Show me a quote OR POST of me posting off topic on hosts where they did NOT apply... go for it!
---
You avoided backing up your accusation where YOU said I say you are Barbara, not Barbie = TomHudson (same person http://tech.slashdot.org/comme... , & sockpuppeteer like you) -> http://slashdot.org/comments.p...
Funny you can't back up your "bluster" there either, lol...
---
Why, Lastly?
You're crackers! See here multiple personality disorder http://slashdot.org/comments.p... + manic depression http://slashdot.org/comments.p...
APK
P.S.=> So, THIS quote below is my policy on sockpuppeteers like you Zontar = TrollingForHostsFiles (your sockpuppetry):
"The only way to a achieve peace, is thru the ELIMINATION of those who would perpetuate war (sockpuppet masters like YOU, troll -> http://slashdot.org/comments.p... ). THIS IS MY PROGRAMMING -> http://start64.com/index.php?o... & soon, I will be UNSTOPPABLE..." - Ultron 6 FROM -> http://www.youtube.com/watch?v...
Which quite obviously, I am, since none of you DOLTISH TROLLS are able to validly technically disprove my points on hosts enumerated in the link to my program above of how hosts give users of them more speed, security, reliability, & anonymity... period!
(Trolls like YOU that use sockpuppets http://slashdot.org/comments.p... (your sockpuppet "alterego" TrollingForHostsFiles) & TomHudson - Barbara, not Barbie too http://tech.slashdot.org/comme... before you)
... apk
That shit is 1-2 months old and it was fixed imidietly