The safest option is to delete/rename the "Diagnostics" directory and then create an empty file called "Diagnostics". Remove system level privileges from it (only your user account has access) for good measure. Then even if an update or Windows Defender or whatever re-enables it, it won't be able to create any data to send.
I like it, and I plan to implement it. Thanks for the idea.
I didn't understand the following statement:
The system level stuff that bypasses proxies is there to prevent viruses simply setting up a proxy to prevent Windows Defender and Windows Update working.
I don't understand this as-is and I've re-read this a few times trying to figure out "what you probably meant instead" and haven't been able to figure that out either. If you wouldn't mind, please respond with a tad more detail so I can try to understand better. Thanks.
Telemetry should be able to be switched off entirely, on all Windows installs, so that our right to privacy in respected.
I agree; sharing of data online should be an opt-in operation rather than something that for the most part cannot be completely opted-out-of. Microsoft's EULA allows for sharing any data they collect with third-parties, and there are reports that they already have and are continuing to do so. There are those that are proponents of what Microsoft is doing, saying that it's "good" for the OS, however if any open-source operating system were to do what Microsoft is doing, it would receive a lot of criticism for sharing data without opt-in consent.
There is some relief to be had however: on Windows 10 Pro and above the Telemetry service can be disabled. The service is named "Customer User Experiences and Telemetry". Look in "Administrative Tools" in "Services" and stop + disable it. The way to verify that the service is disabled is to look at the hidden folder %Program Data%\Microsoft\Diagnostics before-and-after stopping and disabling the service; before stopping the service the encrypted files there cannot be deleted because they're "in use", after stopping the service the files can be deleted and don't return.
There are firewall rules concerning the "Customer User Experience and Telemetry" service that can be disabled too -- but (from what I've read) supposedly disabling these rules won't block the service from the Internet. i.e. similar to how some sites cannot be blocked via "hosts" file entries because Microsoft has hardcoded certain names/IPs in their DNS resolver, supposedly there are certain hardcoded bypasses to the firewall as well.
It's possible to get Windows Update working over Tor, BTW. Windows Update unfortunately only understands an HTTP proxy, not Socks5, so another proxy (such as Privoxy, which is open source) is required to forward traffic to Tor via Socks5. Windows Update follows the proxy set by 'netsh winhttp set proxy IP:PORT;exception_list' (which requires being run from an Admin command prompt). Then firewall rules to block all traffic not coming from the Tor daemon. Verification via packet sniffing or via 'Tcpview' from SysInternals. Unfortunately what I see after all that is there is still some System-level traffic that accesses the 'Net directly, i.e. bypassing the firewall, so this still doesn't seem to be 100% trustable. (Not that it could be, anyway, given that Windows is not open source.)
The US Constitution guarantees him a fair trial. This is just grandstanding in the style of Julian Assange.
Edward Snowden has been charged under the Espionage Act which presents an impossible burden to defend one's self against. https://en.wikipedia.org/wiki/...
I'm bummed that Ian's GR concerning init system equality failed
Why? What that GR said was that packages that didn't support all init systems would be removed from Debian -- i.e. if it had passed Xfce4 would simply be removed.
the intent of which was to insure that alternate init systems continued to work, not to remove packages that didn't support that. Making a bug RC could potentially cause a package to be removed if the bug was ignored and unfixed, but any DD can NMU the package to fix an RC bug at any time, so packages like Xfce4 being removed as a result of an init system RC bug is fairly unrealistic IMHO.
Have you tried to run Debian 8 without systemd? Systemd-less laptop is not just usable anymore at least on XFCE; usb automount and anything related to gvfs is gone, laptop special keys (backlight, volume) do not work, etc.
Yep, I tried my best to install Xfce4 without systemd... that didn't go well, even on a desktop system. KDE can run without running systemd as the init system as well but exhibits several annoying quirks -- it cannot tell when the system is internet-connected, so for instance KMail2 will instantly try to get mail on login and then complain for every account that the connection fails.
I'm bummed that Ian's GR concerning init system equality failed, which means that going forward systemd is the only init system that has to work in Debian, because devs have the option not to care if changes to the packages they maintain break other inits. (Hopefully that won't happen, but based on what I've seen devs say in [debian-devel] I'm not terribly hopeful.) I'm also bummed that Debian had to drop the kFreeBSD port as an official port for Jessie. Ugh.
So yeah needless to say this transition is... rough.
What the hell is happening to the Linux ecosystem?
I've been a Debian user since late 1999 and I very much sympathize with what you've said here. Over time I've gotten increasingly deeper into Debian, and I also find I have some nagging issues with systemd that I didn't have under sysvinit/sysv-rc. Thankfully I've never been a heavy Gnome user, but I've been testing Gnome 3, Cinnamon, and MATE lately, and find that I heavily dislike the current Gnome 3 in Debian Jessie, can deal with Cinnamon, and like MATE the most of the three. Agree re: Firefox/Iceweasel, though I can still tolerate it's current version in Sid.
The biggest problem I have with systemd isn't on the technical side but rather the social side; the issue has been very devisive -- no other issue to date has set groups against one another in such a heated way in some time now. A number of Debian developers have quit or dropped out of teams over it, let alone the heated threads in [debian-devel] about it.
Right now my short-term plan is to ride out the Jessie release by sticking with sysvinit on servers but use systemd on desktops to gain more familiarity with it. I don't have any plans to switch to FreeBSD, and I'm upset that Debian dropped the kFreeBSD port from being official for Jessie.:-/ It would have been nice to have that as a fallback.
Re: Debian Testing -- the stability of Testing has been the issue of ongoing discussions at DebConfs so unfortunately this is a known issue. I can't say I know all of the reasons behind this problem, but I think one of them might be the automatic removal of source packages within 30 days that have RC bugs, and another being that transitions from Sid -> Testing can be such that source package versions in Testing can be out-of-sync compared to Sid. So the irony is that Sid / "Unstable" is actually more stable than Testing, almost all of the time. Sid doesn't get support from the security team though, so I don't consider it good for servers. So because of this I avoid Testing altogether, and run Stable for servers (and "customer" desktops) and Sid for my own desktops. That seems to work except of course that I run into some frustrations with packages for Stable being a bit old.
Anyway -- good post. Best of luck in whatever you choose to use for your free OS.
systemd is "optional" in Debian Jessie in that it's possible to uninstall, but systemd gets installed by deafult in Jessie, and it's also not easy to remove depending on what you're looking to run on the machine. Gnome depends on systemd heavily, so I'm not even sure if it's possible to remove systemd without removing Gnome. I've tried to run a Jessie system without systemd installed and it's... difficult. You can have systemd installed without using it as the PID 1 init, but that too leads to unexpected behavior. Both Gnome and KDE have been built today with the assumption of systemd being PID 1, Gnome depends on logind to be able to log in, and so on.
The other init systems still work for now in Jessie but the GR [General Resolution] that Ian Jackson from the Debian Technical Committee started to declare that keeping the other init systems working was RC [Release Critical] was voted down, which means that systemd is now by default considered the only init system that has to continue to work. Because of this GR's defeat and the backlash on Ian for bringing it up, he's since resigned from the Debian-TC which I think is a great loss.:-( (My big thanks goes to Ian Jackson for his work within the Debian Technical Commttee.)
I haven't yet tried OpenRC outside of VM but IIRC in the VM it worked fine for me. Unfortunately the OpenRC packages (and documentation) in Debian were not in good shape at the time fo the Debian-TC discussion and decision on the default init system for the Jessie release.
Ian Jackson is a man of principle, and the way the final vote was done within the TC [Technical Committee] was certainly objectionable: he was in the middle of discussing what should be on the ballot when Bdale Garbee called for an immediate vote on the same subject but with a totally different ballot. Then when the vote came to a tie, Bdale used the "casting" vote, meaning he had two votes where all the other TC members had only one. Furthermore Bdale's friend and close business partner Keith Packard had just recently joined the TC.
Furthermore this GR [General Resolution] isn't about reversing the TC decision nor in changing the default init system for the Jessie release -- it's about giving the other init systems a fair chance by making them possible to use by making the bugs in packages causing them to break RC [Release Critical]. That's all.
And he did bring this GR up in March, but at that time the Debian community was more hopeful that support would continue for the other init systems, but instead support for everything else has waned -- Ubuntu immediately decided to switch to systemd and drop upstart, and there have been issues with support for other packages concerning the standard sysv-rc init -- all of which Ian had expected to happen.
The main objection from Debian developers concerns the timing of this GR only because the Jessie release is nearing, but... Ian did bring this up in March...
You apparently never had to put your C64 power supply in the refrigerator.
The C64 power supply used a 5v linear regulator rated for 0.2A - 0.3A less current than the C64 itself drew through it, so the part would have premature failure because it was underrated. Apparently/supposedly the difference was expected to be dumped as heat, and the supply was potted which made it very difficult to get to the part that failed and replace it... but doing so was necessary because the replacement supplies had the same design flaw. I did that replacement and after doing so the power supply looked terrible (I left it ripped open), but with a linear regulator that had a sufficient current rating it never failed again (whereas the replacement supplies all did).
Putting the power supply in a refrigerator sounds terrible (but dedicated), but then, so was the "correct" fix.;-)
I've heard of drilling through the potting material to remove and replace a fuse buried in there, but never that. What was the hope behind the refrigeration of the "brick"?
Yes, the C64 power supply was potted -- and after digging through it what had to be replaced wasn't a fuse, it was a 5v linear regulator. The problem with the C64 power supply was that the Linear regulator was designed for 1A, but Commodore was using it to pass 1.2A. This shortened the life of the part, and when it failed it required a huge effort to dig through it to find the part that was bad and replace it.
But I did exactly that. And unfortunately one generally had to do that if they wanted to end up with a reliable supply, because the replacement supplies had the same design flaw and would thus fail in the same way. Once I replaced the 5v regulator with one that was rated for 1.5A, it never failed again.:-)
I am the wrong person to get into the nitty gritty of it, but I believe this is handled by Side-by-Side dependencies (SxS) in windows. I have only very rarely seen dependency problems on Windows, even going back to the days when XP was new and 2000 still roamed the earth. Linux dependency problems are less common but theyre definitely a bigger issue than Windows ones.
Well, I was speaking of modularity in design terms, not about dependencies per se. Vista and above are known to be "more integrated" than previous Windows versions, and simultaneously nowhere near as modular for the base OS as most Linux distributions. [And as such I agree that dependencies are a bigger issue on Linux than Windows.;-)] What I'm getting at is that on Linux a bug such as the OpenSSL problem can be quickly narrowed down to a particular package, whereby the code that needs looking at for a fix is much smaller that way. On a more integrated system the source of the error is likely harder to find, and once found more complicated to fix, than a modular system.
However this is speculation on my part, as I'm not familiar with nor involved in the design of Windows OSes, nor have I looked at any of the Windows source code, and I also don't otherwise have a way of making a "Linux vs Windows" side-by-side comparison.
The SSL flaw has been fixed and rolled out very quickly, it was not the first and will not be the last. How many known Security flaws for windows, IE and many other Microsoft products are out there, unfixed?
Could you explain why "Microsoft has a bigger problem with having to support old platforms" than anyone else? They seem to have vast resources and should actually be able to react quicker than others.
Best -S
This is probably obvious, but the larger they get and the more "integrated" their system is (i.e. I'm thinking of the new level of system integration with Vista versions and above), the slower they're likely to be able to create correct fixes. I don't know this for a fact, but it seems as though the Windows system itself isn't terribly modular compared to other systems (Debian Gnu/Linux for instance) that have packages and dependencies. On a modular system focus can be placed on the "one package" that has a problem (if you can debug the issue down to the package level), but on a very integrated non-modular system where the source code itself is a guarded secret, that sounds like a difficult problem to deal with.
At least it fails gracefully with a clean error code. In Linux world it would show up as a dialog with corrupted text and a mysterious "Invalid argument" error message written in some log.;)
I wouldn't call "erorr 800F0092" to be a "clean" error code -- more like a bizarre confusing unintelligible error code. The errors in Linux can sometimes be frustrating too, or might even be hidden in a log like you pointed out, but they're never designed to be as unintelligible as many of the Windows system error messages are. On Windows there seem to be two kinds of error messages: ones for developers and ones for users; "error 800F0092" vs "check the cable", and there doesn't seem to be a whole lot in-between. At least on Linux systems you get a full range of them.;-)
I wish that were so... unfortunately Windows still has the Desktop userbase majority by a wide margin, and that doesn't seem to be changing despite Microsoft's many steps towards making computer owners' lives more difficult. "Windows Genuine Advantage" that limits your ability to change hardware in a computer running Windows, licensing confusion concerning running Windows in a Virtual Machine, version confusion ("home", "professional", "enterprise", "ultimate", etc), UI confusion with Metro and the Office "banner"... and so on.
I wish Linux were "the answer" to this, but I've been running it on the Desktop since 1998 and I know it's not. A user trying to switch first has to go through a painful process of figuring out what programs they can use to do their daily tasks -- because they're not going to be running Internet Explorer or Outlook anymore, and the new programs have a different menu layout and (for the most part) different shortcut keys. If you've been working with a Linux desktop you've probably forgotten just how painful this transition was -- and it's not trivial. For people that are "stuck in their ways" and get anxious when they feel lost, this in itself is sometimes an insurmountable challenge.
Also the Linux ecosystem is very different, mostly relying on volunteer efforts with a few paid developers on the side. Being that this ecosystem represents less than 5% of the market, it's not an ecosystem that would be able to cope with the other 95%+ of the market suddenly needing support. And because it's mostly volunteers that help, users first need to figure out where to report issues (which isn't always easy), then there are issues concerning user demads vs helper pushback, sometimes leading to rudeness and communication breakdown, occasional elitism or ignoring problems, etc. It's "a different world" than Windows users are used to in that respect too.
And when you say "Or Linux", if the users given that advice knew to they'd ask "which one?" (i.e. which distribution?) Yeah... that problem too. Which window manager / desktop environment? That too. Etc.
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.
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.
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:-/
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.
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.
So tell me, why cant we have the parts we know are insecure issue a log each time they are run?
I understand what you're trying to get at; you'd like to have a log of the failure. However unfortunately that wouldn't tell you what you needed to know in this case; if you did have logging on this, the result you'd get would be "client authenticated" even though it was possible that the authentication actually didn't succeed.:-(
The unfortunate truth is that software bugs happen, and bugs that report success are harder to find than bugs that cause a failure.
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.
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.
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.
Another (non-issue) example is MTA (email) transfers; typically on Linux systems MTAs such as Exim use GnuTLS for TLS transfers, but purposely don't do certificate verification (but can be specifically configured to do so).
This is still a serious security issue for anything that does use GnuTLS for certificate verification of course, but off the top of my head I don't have a specific example of where this is done on the Linux platform. [There probably is an example to be found somewhere though.]
Damn, that doesn't sound like much fun. Sorry you had to go through that.:(
No, definitely wasn't.
Thankfully I'm okay and I don't think I'm worse for wear. For a time I was worried that I might have gotten brain damage from it (I know a couple of people that got brain damage from high fevers), but after this happened I went back to college and was able to complete a masters degree in electrical engineering with a high GPA, so I think I'm fine.;-)
Thanks for the warning. I don't take it often enough to probably hit that. The ibuprofen dose is only 200mg, which is one OTC pill.
I pretty much take maybe 1 or 2 a week at most as needed, but they keep me out of the hospital or urgent care place so it's worth it.
(Annoys me that pain pills are hard to get for people who really need them because some people abuse them...)
I believe I was taking 2 200 mg pills every 6 hours for a full week straight. (Even if I had to get up in the middle of the night if necessary to take another 2 pills.) Unfortunately that's what it required to make the unbearable headache pain subside. I tried only taking 1 pill, that wouldn't cut it. I've never experienced a headache like that before or since.
Heat stroke also messes up your electrolytes too, so I had to eat bananas nuts and sports drinks for several days, during which everything tasted like metal until I got the electrolytes back. And during that time my face was still drooping from palsy, so drinking without spilling it out of my mouth onto my shirt was a challenge. I can look back on it now and laugh a bit, but at the time it was frightening. Also couldn't whistle, drinking from a straw was extremely difficult too because one side of my mouth couldn't close.
If you're only taking an Ibuprofin here and there I'm sure you won't run into what I did.;-)
Slashdot Mirror
The safest option is to delete/rename the "Diagnostics" directory and then create an empty file called "Diagnostics". Remove system level privileges from it (only your user account has access) for good measure. Then even if an update or Windows Defender or whatever re-enables it, it won't be able to create any data to send.
I like it, and I plan to implement it. Thanks for the idea.
I didn't understand the following statement:
The system level stuff that bypasses proxies is there to prevent viruses simply setting up a proxy to prevent Windows Defender and Windows Update working.
I don't understand this as-is and I've re-read this a few times trying to figure out "what you probably meant instead" and haven't been able to figure that out either. If you wouldn't mind, please respond with a tad more detail so I can try to understand better. Thanks.
Telemetry should be able to be switched off entirely, on all Windows installs, so that our right to privacy in respected.
I agree; sharing of data online should be an opt-in operation rather than something that for the most part cannot be completely opted-out-of. Microsoft's EULA allows for sharing any data they collect with third-parties, and there are reports that they already have and are continuing to do so. There are those that are proponents of what Microsoft is doing, saying that it's "good" for the OS, however if any open-source operating system were to do what Microsoft is doing, it would receive a lot of criticism for sharing data without opt-in consent.
There is some relief to be had however: on Windows 10 Pro and above the Telemetry service can be disabled. The service is named "Customer User Experiences and Telemetry". Look in "Administrative Tools" in "Services" and stop + disable it. The way to verify that the service is disabled is to look at the hidden folder %Program Data%\Microsoft\Diagnostics before-and-after stopping and disabling the service; before stopping the service the encrypted files there cannot be deleted because they're "in use", after stopping the service the files can be deleted and don't return.
There are firewall rules concerning the "Customer User Experience and Telemetry" service that can be disabled too -- but (from what I've read) supposedly disabling these rules won't block the service from the Internet. i.e. similar to how some sites cannot be blocked via "hosts" file entries because Microsoft has hardcoded certain names/IPs in their DNS resolver, supposedly there are certain hardcoded bypasses to the firewall as well.
It's possible to get Windows Update working over Tor, BTW. Windows Update unfortunately only understands an HTTP proxy, not Socks5, so another proxy (such as Privoxy, which is open source) is required to forward traffic to Tor via Socks5. Windows Update follows the proxy set by 'netsh winhttp set proxy IP:PORT;exception_list' (which requires being run from an Admin command prompt). Then firewall rules to block all traffic not coming from the Tor daemon. Verification via packet sniffing or via 'Tcpview' from SysInternals. Unfortunately what I see after all that is there is still some System-level traffic that accesses the 'Net directly, i.e. bypassing the firewall, so this still doesn't seem to be 100% trustable. (Not that it could be, anyway, given that Windows is not open source.)
The US Constitution guarantees him a fair trial. This is just grandstanding in the style of Julian Assange.
Edward Snowden has been charged under the Espionage Act which presents an impossible burden to defend one's self against.
https://en.wikipedia.org/wiki/...
This is discussed some by defense lawyers during the movie Citizenfour.
http://www.imdb.com/title/tt40...
I'm bummed that Ian's GR concerning init system equality failed
Why? What that GR said was that packages that didn't support all init systems would be removed from Debian -- i.e. if it had passed Xfce4 would simply be removed.
This is the GR:
https://www.debian.org/vote/20...
the intent of which was to insure that alternate init systems continued to work, not to remove packages that didn't support that. Making a bug RC could potentially cause a package to be removed if the bug was ignored and unfixed, but any DD can NMU the package to fix an RC bug at any time, so packages like Xfce4 being removed as a result of an init system RC bug is fairly unrealistic IMHO.
Have you tried to run Debian 8 without systemd? Systemd-less laptop is not just usable anymore at least on XFCE; usb automount and anything related to gvfs is gone, laptop special keys (backlight, volume) do not work, etc.
Yep, I tried my best to install Xfce4 without systemd... that didn't go well, even on a desktop system. KDE can run without running systemd as the init system as well but exhibits several annoying quirks -- it cannot tell when the system is internet-connected, so for instance KMail2 will instantly try to get mail on login and then complain for every account that the connection fails.
I'm bummed that Ian's GR concerning init system equality failed, which means that going forward systemd is the only init system that has to work in Debian, because devs have the option not to care if changes to the packages they maintain break other inits. (Hopefully that won't happen, but based on what I've seen devs say in [debian-devel] I'm not terribly hopeful.) I'm also bummed that Debian had to drop the kFreeBSD port as an official port for Jessie. Ugh.
So yeah needless to say this transition is ... rough.
What the hell is happening to the Linux ecosystem?
I've been a Debian user since late 1999 and I very much sympathize with what you've said here. Over time I've gotten increasingly deeper into Debian, and I also find I have some nagging issues with systemd that I didn't have under sysvinit/sysv-rc. Thankfully I've never been a heavy Gnome user, but I've been testing Gnome 3, Cinnamon, and MATE lately, and find that I heavily dislike the current Gnome 3 in Debian Jessie, can deal with Cinnamon, and like MATE the most of the three. Agree re: Firefox/Iceweasel, though I can still tolerate it's current version in Sid.
The biggest problem I have with systemd isn't on the technical side but rather the social side; the issue has been very devisive -- no other issue to date has set groups against one another in such a heated way in some time now. A number of Debian developers have quit or dropped out of teams over it, let alone the heated threads in [debian-devel] about it.
Right now my short-term plan is to ride out the Jessie release by sticking with sysvinit on servers but use systemd on desktops to gain more familiarity with it. I don't have any plans to switch to FreeBSD, and I'm upset that Debian dropped the kFreeBSD port from being official for Jessie. :-/ It would have been nice to have that as a fallback.
Re: Debian Testing -- the stability of Testing has been the issue of ongoing discussions at DebConfs so unfortunately this is a known issue. I can't say I know all of the reasons behind this problem, but I think one of them might be the automatic removal of source packages within 30 days that have RC bugs, and another being that transitions from Sid -> Testing can be such that source package versions in Testing can be out-of-sync compared to Sid. So the irony is that Sid / "Unstable" is actually more stable than Testing, almost all of the time. Sid doesn't get support from the security team though, so I don't consider it good for servers. So because of this I avoid Testing altogether, and run Stable for servers (and "customer" desktops) and Sid for my own desktops. That seems to work except of course that I run into some frustrations with packages for Stable being a bit old.
Anyway -- good post. Best of luck in whatever you choose to use for your free OS.
systemd is "optional" in Debian Jessie in that it's possible to uninstall, but systemd gets installed by deafult in Jessie, and it's also not easy to remove depending on what you're looking to run on the machine. Gnome depends on systemd heavily, so I'm not even sure if it's possible to remove systemd without removing Gnome. I've tried to run a Jessie system without systemd installed and it's ... difficult. You can have systemd installed without using it as the PID 1 init, but that too leads to unexpected behavior. Both Gnome and KDE have been built today with the assumption of systemd being PID 1, Gnome depends on logind to be able to log in, and so on.
The other init systems still work for now in Jessie but the GR [General Resolution] that Ian Jackson from the Debian Technical Committee started to declare that keeping the other init systems working was RC [Release Critical] was voted down, which means that systemd is now by default considered the only init system that has to continue to work. Because of this GR's defeat and the backlash on Ian for bringing it up, he's since resigned from the Debian-TC which I think is a great loss. :-( (My big thanks goes to Ian Jackson for his work within the Debian Technical Commttee.)
I haven't yet tried OpenRC outside of VM but IIRC in the VM it worked fine for me. Unfortunately the OpenRC packages (and documentation) in Debian were not in good shape at the time fo the Debian-TC discussion and decision on the default init system for the Jessie release.
Ian Jackson is a man of principle, and the way the final vote was done within the TC [Technical Committee] was certainly objectionable: he was in the middle of discussing what should be on the ballot when Bdale Garbee called for an immediate vote on the same subject but with a totally different ballot. Then when the vote came to a tie, Bdale used the "casting" vote, meaning he had two votes where all the other TC members had only one. Furthermore Bdale's friend and close business partner Keith Packard had just recently joined the TC.
Furthermore this GR [General Resolution] isn't about reversing the TC decision nor in changing the default init system for the Jessie release -- it's about giving the other init systems a fair chance by making them possible to use by making the bugs in packages causing them to break RC [Release Critical]. That's all.
And he did bring this GR up in March, but at that time the Debian community was more hopeful that support would continue for the other init systems, but instead support for everything else has waned -- Ubuntu immediately decided to switch to systemd and drop upstart, and there have been issues with support for other packages concerning the standard sysv-rc init -- all of which Ian had expected to happen.
The main objection from Debian developers concerns the timing of this GR only because the Jessie release is nearing, but ... Ian did bring this up in March...
You apparently never had to put your C64 power supply in the refrigerator.
The C64 power supply used a 5v linear regulator rated for 0.2A - 0.3A less current than the C64 itself drew through it, so the part would have premature failure because it was underrated. Apparently/supposedly the difference was expected to be dumped as heat, and the supply was potted which made it very difficult to get to the part that failed and replace it... but doing so was necessary because the replacement supplies had the same design flaw. I did that replacement and after doing so the power supply looked terrible (I left it ripped open), but with a linear regulator that had a sufficient current rating it never failed again (whereas the replacement supplies all did).
Putting the power supply in a refrigerator sounds terrible (but dedicated), but then, so was the "correct" fix. ;-)
I've heard of drilling through the potting material to remove and replace a fuse buried in there, but never that. What was the hope behind the refrigeration of the "brick"?
Yes, the C64 power supply was potted -- and after digging through it what had to be replaced wasn't a fuse, it was a 5v linear regulator. The problem with the C64 power supply was that the Linear regulator was designed for 1A, but Commodore was using it to pass 1.2A. This shortened the life of the part, and when it failed it required a huge effort to dig through it to find the part that was bad and replace it.
But I did exactly that. And unfortunately one generally had to do that if they wanted to end up with a reliable supply, because the replacement supplies had the same design flaw and would thus fail in the same way. Once I replaced the 5v regulator with one that was rated for 1.5A, it never failed again. :-)
I am the wrong person to get into the nitty gritty of it, but I believe this is handled by Side-by-Side dependencies (SxS) in windows. I have only very rarely seen dependency problems on Windows, even going back to the days when XP was new and 2000 still roamed the earth. Linux dependency problems are less common but theyre definitely a bigger issue than Windows ones.
Well, I was speaking of modularity in design terms, not about dependencies per se. Vista and above are known to be "more integrated" than previous Windows versions, and simultaneously nowhere near as modular for the base OS as most Linux distributions. [And as such I agree that dependencies are a bigger issue on Linux than Windows. ;-)] What I'm getting at is that on Linux a bug such as the OpenSSL problem can be quickly narrowed down to a particular package, whereby the code that needs looking at for a fix is much smaller that way. On a more integrated system the source of the error is likely harder to find, and once found more complicated to fix, than a modular system.
However this is speculation on my part, as I'm not familiar with nor involved in the design of Windows OSes, nor have I looked at any of the Windows source code, and I also don't otherwise have a way of making a "Linux vs Windows" side-by-side comparison.
The SSL flaw has been fixed and rolled out very quickly, it was not the first and will not be the last. How many known Security flaws for windows, IE and many other Microsoft products are out there, unfixed?
Could you explain why "Microsoft has a bigger problem with having to support old platforms" than anyone else? They seem to have vast resources and should actually be able to react quicker than others.
Best
-S
This is probably obvious, but the larger they get and the more "integrated" their system is (i.e. I'm thinking of the new level of system integration with Vista versions and above), the slower they're likely to be able to create correct fixes. I don't know this for a fact, but it seems as though the Windows system itself isn't terribly modular compared to other systems (Debian Gnu/Linux for instance) that have packages and dependencies. On a modular system focus can be placed on the "one package" that has a problem (if you can debug the issue down to the package level), but on a very integrated non-modular system where the source code itself is a guarded secret, that sounds like a difficult problem to deal with.
At least it fails gracefully with a clean error code. In Linux world it would show up as a dialog with corrupted text and a mysterious "Invalid argument" error message written in some log. ;)
I wouldn't call "erorr 800F0092" to be a "clean" error code -- more like a bizarre confusing unintelligible error code. The errors in Linux can sometimes be frustrating too, or might even be hidden in a log like you pointed out, but they're never designed to be as unintelligible as many of the Windows system error messages are. On Windows there seem to be two kinds of error messages: ones for developers and ones for users; "error 800F0092" vs "check the cable", and there doesn't seem to be a whole lot in-between. At least on Linux systems you get a full range of them. ;-)
Or linux.
I wish that were so... unfortunately Windows still has the Desktop userbase majority by a wide margin, and that doesn't seem to be changing despite Microsoft's many steps towards making computer owners' lives more difficult. "Windows Genuine Advantage" that limits your ability to change hardware in a computer running Windows, licensing confusion concerning running Windows in a Virtual Machine, version confusion ("home", "professional", "enterprise", "ultimate", etc), UI confusion with Metro and the Office "banner"... and so on.
I wish Linux were "the answer" to this, but I've been running it on the Desktop since 1998 and I know it's not. A user trying to switch first has to go through a painful process of figuring out what programs they can use to do their daily tasks -- because they're not going to be running Internet Explorer or Outlook anymore, and the new programs have a different menu layout and (for the most part) different shortcut keys. If you've been working with a Linux desktop you've probably forgotten just how painful this transition was -- and it's not trivial. For people that are "stuck in their ways" and get anxious when they feel lost, this in itself is sometimes an insurmountable challenge.
Also the Linux ecosystem is very different, mostly relying on volunteer efforts with a few paid developers on the side. Being that this ecosystem represents less than 5% of the market, it's not an ecosystem that would be able to cope with the other 95%+ of the market suddenly needing support. And because it's mostly volunteers that help, users first need to figure out where to report issues (which isn't always easy), then there are issues concerning user demads vs helper pushback, sometimes leading to rudeness and communication breakdown, occasional elitism or ignoring problems, etc. It's "a different world" than Windows users are used to in that respect too.
And when you say "Or Linux", if the users given that advice knew to they'd ask "which one?" (i.e. which distribution?) Yeah... that problem too. Which window manager / desktop environment? That too. Etc.
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...
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.
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 :-/
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.
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.
So tell me, why cant we have the parts we know are insecure issue a log each time they are run?
I understand what you're trying to get at; you'd like to have a log of the failure. However unfortunately that wouldn't tell you what you needed to know in this case; if you did have logging on this, the result you'd get would be "client authenticated" even though it was possible that the authentication actually didn't succeed. :-(
The unfortunate truth is that software bugs happen, and bugs that report success are harder to find than bugs that cause a failure.
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.
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.
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.
Another (non-issue) example is MTA (email) transfers; typically on Linux systems MTAs such as Exim use GnuTLS for TLS transfers, but purposely don't do certificate verification (but can be specifically configured to do so).
This is still a serious security issue for anything that does use GnuTLS for certificate verification of course, but off the top of my head I don't have a specific example of where this is done on the Linux platform. [There probably is an example to be found somewhere though.]
Damn, that doesn't sound like much fun. Sorry you had to go through that. :(
No, definitely wasn't.
Thankfully I'm okay and I don't think I'm worse for wear. For a time I was worried that I might have gotten brain damage from it (I know a couple of people that got brain damage from high fevers), but after this happened I went back to college and was able to complete a masters degree in electrical engineering with a high GPA, so I think I'm fine. ;-)
Thanks for the warning. I don't take it often enough to probably hit that. The ibuprofen dose is only 200mg, which is one OTC pill.
I pretty much take maybe 1 or 2 a week at most as needed, but they keep me out of the hospital or urgent care place so it's worth it.
(Annoys me that pain pills are hard to get for people who really need them because some people abuse them...)
I believe I was taking 2 200 mg pills every 6 hours for a full week straight. (Even if I had to get up in the middle of the night if necessary to take another 2 pills.) Unfortunately that's what it required to make the unbearable headache pain subside. I tried only taking 1 pill, that wouldn't cut it. I've never experienced a headache like that before or since.
Heat stroke also messes up your electrolytes too, so I had to eat bananas nuts and sports drinks for several days, during which everything tasted like metal until I got the electrolytes back. And during that time my face was still drooping from palsy, so drinking without spilling it out of my mouth onto my shirt was a challenge. I can look back on it now and laugh a bit, but at the time it was frightening. Also couldn't whistle, drinking from a straw was extremely difficult too because one side of my mouth couldn't close.
If you're only taking an Ibuprofin here and there I'm sure you won't run into what I did. ;-)