Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror

Comment: Re:Ian Jackson (Score 1) 522

by Sipper (#48174907) Attached to: Debian Talks About Systemd Once Again

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...

Comment: Re:Amiga Floppies (Score 2) 171

by Sipper (#46833367) Attached to: Previously Unknown Warhol Works Recovered From '80s Amiga Disks

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. ;-)

Comment: Re:Amiga Floppies (Score 2) 171

by Sipper (#46833305) Attached to: Previously Unknown Warhol Works Recovered From '80s Amiga Disks

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. :-)

Comment: Re:Slashdot is ridiculous (Score 1) 575

by Sipper (#46771447) Attached to: Microsoft Confirms It Is Dropping Windows 8.1 Support

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.

Comment: Re:Slashdot is ridiculous (Score 1) 575

by Sipper (#46756579) Attached to: Microsoft Confirms It Is Dropping Windows 8.1 Support

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.

Comment: Re:Wanna give up on these guys yet ? (Score 1) 575

by Sipper (#46756375) Attached to: Microsoft Confirms It Is Dropping Windows 8.1 Support

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. ;-)

Comment: Re:Bullet, meet foot (Score 2) 575

by Sipper (#46756323) Attached to: Microsoft Confirms It Is Dropping Windows 8.1 Support

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.

Comment: Re:If GNUTls is unneeded, then create a NO-OP libr (Score 1) 144

by Sipper (#46700535) Attached to: Not Just Apple: GnuTLS Bug Means Security Flaw For Major Linux Distros

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...

Comment: Re:If GNUTls is unneeded, then create a NO-OP libr (Score 1) 144

by Sipper (#46693199) Attached to: Not Just Apple: GnuTLS Bug Means Security Flaw For Major Linux Distros

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.

Comment: Re:If GNUTls is unneeded, then create a NO-OP libr (Score 1) 144

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 :-/

Comment: Re:If GNUTls is unneeded, then create a NO-OP libr (Score 1) 144

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.

Comment: Re:If GNUTls is unneeded, then create a NO-OP libr (Score 1) 144

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.

Comment: Re:Wow, that made it seem 10 times worse, thanks! (Score 1) 144

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.

Comment: Re:If GNUTls is unneeded, then create a NO-OP libr (Score 1) 144

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.

Comment: Re:If GNUTls is unneeded, then create a NO-OP libr (Score 5, Informative) 144

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.

To downgrade the human mind is bad theology. - C. K. Chesterton

Working...