You may be able to "load the whole OS into memory", but that's missing the point, which is the data people work with once the OS is up and running. If that 4GB was enough to store all the data for the entirety of any conceivable session, on servers as well as desktops, why would anyone ever buy a hard drive larger than that? Hard drives would probably already be obsolete. I bet you own at least one hard drive larger than 4GB - and as the type of person who comments on slashdot, I bet more than 4GB of that hard drive is currently in use.
TFA is talking about replacing mass storage with PCM. The summary's usage of the phrase "storage networks" should also have been a hint.
"I trust Microsoft to pick the best software update scheme for me."
Gah! The entire point of this is that if you've installed an alternative browser, and set it as your default, it might be precisely because you *don't* trust everything coming out of Microsoft.
IE8 is probably better for more users than IE7 is.
Yes, IE8 is undoubtedly better than IE7, but what if IE7 wasn't your default browser beforehand? The update process doesn't account for whether or not your current default is a version of IE. The problem isn't forcing people to go from IE7 to IE8, it's about Microsoft "upgrading" people from (for example) Chrome to IE8.
FWIW, if IE was the default before the update, the process would simply not have to change the default, because IE8 *replaces* earlier versions. So the simplest thing to do from the very start would have been to make an installer that just leaves the current default alone.
Re:It's not just a windows issue
on
R.I.P. FTP
·
· Score: 1
a) In-transit packet sniffing. Plenty of places between your PC and the destination server for your unencrypted traffic to be sniffed.
Yes... as per the entire point of this article.:)
b) Local password caches: Plenty of users locally store their passwords for convenience. It's not impossible or even that difficult to pull them. The "wallets" may to some extent work to protect these, but an infected user account could still happily launch a background service that politely asks for the password at a convenient time
A semi-decent password wallet will prompt the user whenever a (new) application asks for a particular password. GNOME keyring does this, for example. I don't know how thoroughly it verifies that future requests come from the same program, though (e.g. authorise Evolution to read your mail account password, then replace the Evolution binary with something malicious). Regardless, you can't use this to *gain* access; such a "background service" would however be an interesting thing to put in place on a compromised box.
c) Config files: Local infected accounts can have local configuration files (firefox, etc) overwritten without the user knowing. Will you notice if your proxy is set to funky server for a few days?
How does the account become infected? Once you have control, you can do anything that user can do; but if you don't have write access to those configuration files, this point is moot.
d) Menu items, etc: When you click on the firefox icon, are you really running what you think? What if it's a wrapper with a 3rd-party app? OK, you run from commandline... is your $PATH set to run/usr/bin before "./.hiddenvirusdir/usr/bin" ?
An interesting one, but the whole menu item issue (I remember the furore a while back) isn't really any worse than the stuff you can do on the command line - which you already seem to be aware of.:) Again, though - if you don't have access to edit system-wide.desktop files/login scripts, or write access to a user's home area, this is just describing the ends without hinting at the means.
There are PLENTY of ways to compromise a 'nix desktop without root access.
Maybe, but you haven't detailed any yet. All the stuff you're talking about - with the exception of your point A - is stuff you can do *after you've already compromised the target account*.
Yes, windows has issues. For the experienced, so does Linux. If fact, short of writing actual trojans or binaries, I generally managed to more easily subvert my friend's 'nix machine more often than our other co-workers windows box.
I really do have to ask: how? Did you use common root passwords? Home areas on NFS without root-squash? Leaving logged-on boxes unattended for long periods of time without passworded screensavers? Booting each other's machines into single-user mode/with Knoppix in the drive/etc.? Without physical access (which I have to admit is *very* difficult to protect against - but not OS specific), the things you're describing ought to be incredibly difficult to accomplish on a properly set-up Linux desktop.
You may not share that netbook - I probably wouldn't either. Nor would I be likely to connect to it remotely and run graphical apps from it, as netbooks typically aren't very powerful. Connecting from it to other machines to run *their* apps - such as my office desktop over a VPN, for example - does, however, sound pretty plausible.
Admittedly the performance of raw X over the Internet leaves (in my experience) something to be desired, but throw in compression technologies such as NX and it is eminently usable. (I wish something like that would find its way into X proper.)
Also, it may not be obvious at first, but X actually has a lot of similarity to the concept of web apps and the use cases for Chrome OS. People are using browsers to host the user interfaces of applications in which most of the data storage & heavy lifting is done remotely - sound familiar? Compared to X, though, there are some key differences: browsers have very good caching and compression, especially if you consider the HTML required for a typical web app compared to the weight of the X commands necessary to render a comparable GUI; and responsiveness is improved by running a lot of the UI logic locally in JavaScript, something the X architecture can't really do.
If browsers had been *designed* from the ground-up for this job, instead of stiffing developers with a lacklustre widget set, massive cross-browser compatibility problems and no common rules for UI layout & design, I can actually imagine something like Chrome OS working very well. In reality, though, browsers *weren't* designed for this, and servers don't have perfect up-time. I think "Web 2.0" gives us a glimpse into what applications might look like if developers *did* sit down and split every graphical app into a client & server, and the concept isn't entirely without merit; I just don't think the tools that have been co-opted for the purpose are the right ones for the job.
Tell me, what kind of backwards logic makes the X server be the display and the X client be the application?
Logic that accounts for two facts; that computers can have multiple users, and that they can be networked. SSH lets you run arbitrary command-line applications on remote machines. To do that with arbitrary graphical applications - emphasis on "arbitrary", i.e. not re-writing every graphical app as a GUI client & back-end server - you need something on the local machine to which the remote machine can send display commands, and for proper integration with graphical apps running on the local machine, ideally that same something should be catering for both. So.. you run a display server, and anything that wants to display graphics - locally or otherwise - connects to it. Simple.
Like a lot of things in the *NIX world, it stops seeming backwards when you discard a few assumptions: that a computer is only used by one person (or that everyone who uses it is happy to share the same account), and that a keyboard, monitor and mouse will always be plugged in. These assumptions have kept Windows out of many a server room for years.
However, the difficulties of writing user-friendly software outside the "comfort zone" these assumptions provide have kept Linux out of many a living room for just as long. It's not impossible, though, and the situation is improving rapidly.
Yes, but to know whether or not the auditors were sufficiently diligent, you have to define precisely what their role is.
Is their role to certify that at the time of testing, the company being tested met the required standards?
Or, is their role to certify that the company met the required standards at time of testing, and continues to meet them for as long as the certification stands?
The two are significantly different. In reality, what they actually do is probably the former, and hence they probably only have the necessary records to demonstrate that they did their job for one point in time. The interesting thing here is that, seemingly, it is not yet obvious from a legal perspective which of the two the certifiers *should* be doing. If the court decides that they *should* have been doing the latter, but only did the former, then all hell breaks loose.
Yes, and it nowhere says my competitor is forced to redistribute the binaries to me.
Oh, for the love of... I never said it did. On that front, I was AGREEING with you.
While that is unlikely in the games market, this situation is common in the world of professional services where customers might actually pay a commercial rate for the man time required to modify a product to fit their needs.
Yes, but that's not really the situation that was under discussion, is it? In the scenario where a consultant or contractor is paid to add specific functionality to an existing product, the company paying them are probably only interested in using that product themselves, not selling or supporting it. In fact, depending on the nature of the product/changes, they may well desire not to redistribute it at all - which doesn't really make their version a competitor to the original, does it?
If someone wants to make a living making modified versions of GPL software as a consultant/contractor, good for them. In a scenario where the original author(s) of said software offer a similar service, people in the market for customized versions would be hard pressed to pick them over a third party not likely to know the code as well. (Admittedly there are many other factors that would influence such decisions, but being the original author is quite an advantage.)
I could buy a copy of his game, at which point he has now redistributed the code in binary form to me, so he must let me have the source code, but he can charge a fee. GPLv2 said the fee could only cover packaging and distribution costs but that restriction seems to have been lifted in v3. Note that my competitor may choose to refuse to sell me a copy of his game although I may be able to pick up a copy from elsewhere.
Have you actually read paragraph 6 from the GPLv3? The restriction is still very much in place (see point B, and fee restrictions on points C, D and E):
* a) Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by the Corresponding Source fixed on a durable physical medium customarily used for software interchange.
* b) Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by a written offer, valid for at least three years and valid for as long as you offer spare parts or customer support for that product model, to give anyone who possesses the object code either (1) a copy of the Corresponding Source for all the software in the product that is covered by this License, on a durable physical medium customarily used for software interchange, for a price no more than your reasonable cost of physically performing this conveying of source, or (2) access to copy the Corresponding Source from a network server at no charge.
* c) Convey individual copies of the object code with a copy of the written offer to provide the Corresponding Source. This alternative is allowed only occasionally and noncommercially, and only if you received the object code with such an offer, in accord with subsection 6b.
* d) Convey the object code by offering access from a designated place (gratis or for a charge), and offer equivalent access to the Corresponding Source in the same way through the same place at no further charge. You need not require recipients to copy the Corresponding Source along with the object code. If the place to copy the object code is a network server, the Corresponding Source may be on a different server (operated by you or a third party) that supports equivalent copying facilities, provided you maintain clear directions next to the object code saying where to find the Corresponding Source. Regardless of what server hosts the Corresponding Source, you remain obligated to ensure that it is available for as long as needed to satisfy these requirements.
* e) Convey the object code using peer-to-peer transmission, provided you inform other peers where the object code and Corresponding Source of the work are being offered to the general public at no charge under subsection 6d.
Still, AFAICT, you are correct that one must come into possession of a derivative work in object code form before one can request said work in source form. A competitor would have to have very high prices, incredibly loyal customers and no second-hand market for their product (at least, not that existed within the product's support lifetime or three years, whichever is longest) if they were to succeed in making that difficult. Note also that to sell successfully at such high prices, such a competitor must have made very high-value modifications and/or have very high marketing budgets in order to make a business of selling their derivative work, and funding such an operation would surely be viewed as a risky proposition.
This attack is made possible because the operating system on the computer loads and boots directly into Windows without first asking for a Pointsec âpreboot authenticationâ(TM) password. Normally, with whole disk encryption, a user is required to enter a password immediately upon turning the machine on. That password is what unlocks the decryption key and allows the rest of the operating system to load and execute. This FireWire attack would not be successful in that case, because the attack requires that Windows already be up and running. In the circumstance of a properly configured encrypted computer, a stolen system that is powered off would be well protected from unauthorized access and this type of attack.
From my previous post:
If software chained on to the user authentication process doesn't require valid credentials from that process in order to decrypt, that software is crap. By "require" I mean the data is required for the cryptography to function, not just a software check that it is present.
They are describing a gross misconfiguration here IMHO.
Your point 2: encrypted disks tend to be an issue with laptops, where they are stolen quite often. In this most common scenario, keyloggers don't enter into it.
Crypto is only as good as the weakest link.
Physical access != stealing. The OP stated that physical access means all bets are off - I may decide to insert a hardware keylogger into your laptop and come back later, rather than run off with it there and then. AFAICS, the OP's point still stands, you just have to think beyond naive assumptions.
Your point 1 is VERY wrong. Cracking an 8-character password when given access to the hash is much much much much easier than cracking a 20-character encryption passphrase or a smartcard-based encryption system.
Then the problem is that you have a sh*t user authentication system, which is something that should be fixed no matter what.
Furthermore, a crypto system which relies on Windows authentication to cough up the crypto key does not even require knowledge of the password. Just bypass the authentication and you get the key. I KNOW this is the case for Checkpoint WIL disk encryption.
Do you really? If I were to log into a Windows box as administrator and use this fact to run a shell impersonating another user, would this decrypt their stuff for me (i.e. no hacking or cracking involved), or by "bypassing" do you actually mean getting through the login process without entering the real password, e.g. replaying a previous handshake? Again, if the latter is the case, the problem is a sh*t user authentication system.
True, if you know a particular OS's authentication system uses weak hashes, or is vulnerable to replay attacks, or <insert vulnerability here> perhaps you shouldn't design crypto systems for that OS which integrate with it. But that's a problem with that OS, not with the very idea of integration.
Some disk encryption solutions, such as Checkpoint, rely on windows authentication to decrypt the disk. If this can be bypassed easily, it makes this disk encryption worthless.
To rephrase my initial point:
If software chained on to the user authentication process doesn't require valid credentials from that process in order to decrypt, that software is crap. By "require" I mean the data is required for the cryptography to function, not just a software check that it is present.
If the user authentication process can be subverted - i.e. you can "log in" without knowing the password in a way that still presents valid credentials to software further down the chain, or even strong passwords are easily cracked (e.g. weak hashing) - then the user authentication process is crap.
I don't know for definite that the Windows 7 authentication process satisfies these requirements, or that Checkpoint's decryption solution satisfies these requirements, because I don't have copies of them and am not a security researcher/cryptanalyst. But even if they don't, that doesn't make the whole concept bogus - it makes this particular implementation bogus. Can you provide concrete evidence that the two pieces of software in question don't satisfy these requirements?
1. There's nothing wrong with decryption being integrated with the user authentication system *provided it requires a correct password to succeed*, not just a shell claiming it is running as a given user.
Although it isn't targetted at disk encryption, gnome-keyring can be integrated with PAM to auto-unlock a user's encrypted password storage (their "default keyring") at login time. Going further, seahorse-agent provides auto-unlocking of SSH and GPG keys (by impersonating ssh-agent and gpg-agent respectively) in similar fashion, by storing the passphrases in the user's default keyring I believe. I may just not have looked hard enough, but I haven't heard anyone slating them for being "theoretically worthless" - unless you have no password on your default keyring, not even root su'ing to impersonate a particular user will grant access to their keys.
2. On the other hand, even "real" disk encryption (as opposed to "fake" disk encryption - ROT13?) DOES NOT protect against physical access if the attacker can get a keylogger (presumably a hardware one) in place to grab the password. Same for gnome-keyring and seahorse-agent. What these systems CAN do is prevent decryption of a stolen disk/keyring when no other data is available to the attacker.
They're... ok, but none of them particularly grab me. I really, really dislike the way that you have to stop and press an action button to pick up a weapon - it might be intentional, because in the small amount of time I played, it seemed like the inventory was very limited. What really killed that mechanic is the way that picking a weapon up also switches to it. Realistic, arguably, but incredibly awkward when you pick up a grenade, for example.
Not sure what to make of the flame thrower. Nice visual effect, but I found it difficult to determine whether or not I was actually *hitting* anything with it (apart from myself).
Not strictly weapon-related: I found the entire game very, very sluggish - movement, projectiles, reload times... far too slow IMO. I'm not saying you necessarily have to emulate Q3 for pacing - bunny-hopping at break-neck speeds isn't everything, UT2004 took a different approach with fixed-speed movement like yours, but configurable overall game speed. Currently, though, things take so long to accomplish that it somehow doesn't feel like you're actually in complete control of the game. Also I'm not entirely convinced by the HUD concept - it could grow on me, but the option of a more traditional HUD wouldn't go amiss. Remember, sometimes the reason things get copied time and time again is because they *work* - you don't have to change *everything* to be good!
Very good choice of engine, though, and nice to finally see ragdolls in an open-source FPS. For me personally, Nexuiz is by far and away the best FOSS FPS around in terms of gameplay, but the graphics are too garish (no real consistency in colour and texture usage) and the engine just doesn't perform.
I played for a small amount of time today, and couldn't shake the feeling that I was hobbling around with a pea shooter, whilst the bots ran around with real guns. Everything I did felt ineffectual, but the bots didn't seem to have any trouble killing me.
The theory behind using the Google-served copies of JavaScript libraries isn't to reduce load on the whitehouse.gov servers, but to improve caching.
This is true, but it doesn't change the fact that it still introduces security/privacy concerns. The fact remains that if the remote JavaScript changes, the behaviour of all websites referencing it will change. The method by which it changes doesn't have to involve hacking Google (DNS hijacking (site-local or otherwise), HTTP cache poisoning, etc.), and changes don't have to be outwardly malicious to have unintended side-effects (AVG's LinkScanner, anyone?).
On the face of it, though, referencing JQuery files directly from Google's servers is no worse than them referencing external resources from WebTrends Live, which I presume they have to do at some point in the tracking process.
I freely admit these comments are verging on paranoid, but the point is, intentions != reality, and just because there may be one good reason to do something doesn't mean there aren't also good reasons not to. Reality doesn't care which reason you picked.
It's totally unnecessary. It's a waste of time commuting. It's a waste of energy commuting. It's a waste of gas, office space, the expense of computers in the office, space on public transportation, business clothes. It goes on and on. We should all be working from home.
That may sound like a nice ideal, but there are many reasons that working from home isn't (yet?) a given.
I think you underestimate the importance of being able to walk up to a colleague and work with them face-to-face. The trouble with your ideal is that "work", in this context, rarely - if ever - just means writing code: it can mean giving someone a helping hand with a bit of debugging, going over design documents, giving feedback on a demo, performing knowledge transfer, or simply taking a break and having a chat. These things needn't be as formal as they sound: I quite often offer to help just because I can hear someone else's cries of anguish, or get asked to cast an eye over something for a minute or two simply because I'm there and my opinions are valued. A lot of this stuff just wouldn't happen if we weren't sat in the same building.
Coming back to that throwaway comment regarding opinions, how do you create an accurate picture of a person's abilities - especially those which may be of use, but are not part of their job description - without spending time with them?
There are also pure practical concerns. Being able to look over someone's shoulder at their monitor/piece of paper; body language; the ability to physically show someone what you mean during moments of confusion because they're *there*.
On the other side of the coin, there are also reasons why somebody may not want to work from home. I enjoy having the option to go to lunch with my co-workers; I like knowing who people are at meetings and release parties; I don't like my one year old daughter coming over to pester me and can't move my computer out of the living room because I can't afford anywhere bigger than this crappy two-bedroom flat; VMware over a VPN sucks. I have worked from home and I don't enjoy it.
If you could honestly do your job just as well as you do it now without physical contact with any of your colleagues, you aren't doing it right, you work for a "software factory", and/or your office environment is all wrong.
In closing, I'd like to offer up the idea that perhaps this thread isn't as off-topic as it may at first seem. The whole concept of part-time development work (which, if you're still holding down a full-time job, I assume means working from home) being somehow more satisfying than full-time work is slightly alien to me: unless you're writing cookie-cutter code, so well-defined as to be rather boring to churn out, it will take the majority of those 15 hours a week simply dealing with the practicalities of getting to know the code and other developers you're working with. You really think working this way could be more organised, more accountable and less political?
Even better: use NX (http://www.nomachine.com/ - includes a "free edition"). Basically heavily compressed X forwarding, but also includes niceties such as being able to disconnect and reconnect sessions without killing the X clients. I use it over a VPN on the rare occasions I work from home, on a standard ADSL connection. Typing on an NX forwarded xterm is almost as quick as when SSH-ing in directly (which may seem a somewhat pointless use-case, but is the closest I know how to get to the behaviour of "standard" SSH with X forwarding). I also find I get *much* better responsiveness if I run VMWare Server Client on my work box, forwarded over NX, instead of running the client at home and connecting to the work VMWare server from there.*
Also available as FreeNX (http://freenx.berlios.de), but harder to set up IME.
* Which may just be another way of saying "VMWare's protocol sucks", but regardless, turns it from near unusable to very useful.
However, their arguments seem to rely on the concept of linking - including static linking - being some sort of "magic" that results in a derived work. Not everyone agrees with this concept, provided that what you're linking with isn't modified. For example, see this LKML post by Linus Torvalds: http://lkml.org/lkml/2006/12/17/79. His views basically boil down to static linking being a form of aggregation, and dynamic linking of separate works having even less bearing since it doesn't necessarily require distribution of both works. Both, however, having bearing on whether or not two works are independent.
It seems to be a bit of a murky area, but here is my interpretation of the matter. Please note: IANAL. The quotes are taken from the GPLv3; as far as I can tell, the GPLv2 says much the same thing, albeit less explicitly.
From section 1, "Source code":
The "Corresponding Source" for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. For example, Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work.
I would say an application which makes use of the Havok SDK is "specifically designed" to require it. I don't think one could get away with saying it's a "System Library", either (a System Library being defined earlier as, in essence, something which interfaces with parts of an application's host OS, if any). Hence, the source code of the Havok SDK is Corresponding Source, IMHO.
So, what requirements does the GPLv3 place on Corresponding Source?
Sections 4 and 5, "Conveying Verbatim Copies" [of the program's source code] and "Conveying Modified Source Versions", do not mention Corresponding Source at all. From this, I would draw the conclusion that provided you are distributing your application in source code form, you do not have to re-distribute Corresponding Source.
However, from Section 6, "Conveying Non-source Forms":
You may convey a covered work in object code form under the terms of sections 4 and 5, provided that you also convey the machine-readable Corresponding Source under the terms of this License
So, if you are distributing binaries, you must distribute Corresponding Source, which obviously requires you to have access to it. In the case of the Havok SDK, this is clearly not the case.
This requirement is, in my opinion, linked in with the "anti-Tivoisation" measures incorporated into GPLv3; however it also has some importance when considering continued access to - and historical preservation of - useful software. It means that something licensed under the GPLv3 and distributed in binary form cannot be specifically designed (think "modified by Corporation X") to require closed-source components which do not qualify as System Libraries or Major Components of an OS. It also means that if a third-party library falls out of maintenance, it can still be fixed and updated as required to enable applications requiring it to keep working.
So, to summarise:
The Havok SDK qualifies as Corresponding Source of programs which require it.
Distribution of Corresponding Source is not required for works distributed in source code form.
This is important, as it means GPLv3 programs can use proprietary libraries provided they (the programs) are not distributed pre-compiled.*
However, Corresponding Source must be distributed with binaries.
Please note that I have not read the Havok SDK's license. It may or may not lay out requirements of its own for programs which prevent the scenario under discussion, but AFAICT, the GPLv3 itself doesn't prevent usage of closed-source libraries per se, provided you stick to only giving out source.
* Similar - but by no means identical - to the provisions in the Mozilla license which require distribution of binaries compiled by third parties to have all Mozilla-related trademarks removed. Debian et al. rebrand Firefox as a result; source-based distributions such as Gentoo don't innately prevent usage of official branding because they only distribute source code, but make doing so optional, and make it clear that doing so means you can't re-distribute your own binaries after compilation.
Slashdot Mirror
You may be able to "load the whole OS into memory", but that's missing the point, which is the data people work with once the OS is up and running. If that 4GB was enough to store all the data for the entirety of any conceivable session, on servers as well as desktops, why would anyone ever buy a hard drive larger than that? Hard drives would probably already be obsolete. I bet you own at least one hard drive larger than 4GB - and as the type of person who comments on slashdot, I bet more than 4GB of that hard drive is currently in use.
TFA is talking about replacing mass storage with PCM. The summary's usage of the phrase "storage networks" should also have been a hint.
LCDs still suffer from something very similar to the old CRT burn-in.
"I trust Microsoft to pick the best software update scheme for me."
Gah! The entire point of this is that if you've installed an alternative browser, and set it as your default, it might be precisely because you *don't* trust everything coming out of Microsoft.
IE8 is probably better for more users than IE7 is.
Yes, IE8 is undoubtedly better than IE7, but what if IE7 wasn't your default browser beforehand? The update process doesn't account for whether or not your current default is a version of IE. The problem isn't forcing people to go from IE7 to IE8, it's about Microsoft "upgrading" people from (for example) Chrome to IE8.
FWIW, if IE was the default before the update, the process would simply not have to change the default, because IE8 *replaces* earlier versions. So the simplest thing to do from the very start would have been to make an installer that just leaves the current default alone.
a) In-transit packet sniffing. Plenty of places between your PC and the destination server for your unencrypted traffic to be sniffed.
Yes... as per the entire point of this article. :)
b) Local password caches: Plenty of users locally store their passwords for convenience. It's not impossible or even that difficult to pull them. The "wallets" may to some extent work to protect these, but an infected user account could still happily launch a background service that politely asks for the password at a convenient time
A semi-decent password wallet will prompt the user whenever a (new) application asks for a particular password. GNOME keyring does this, for example. I don't know how thoroughly it verifies that future requests come from the same program, though (e.g. authorise Evolution to read your mail account password, then replace the Evolution binary with something malicious). Regardless, you can't use this to *gain* access; such a "background service" would however be an interesting thing to put in place on a compromised box.
c) Config files: Local infected accounts can have local configuration files (firefox, etc) overwritten without the user knowing. Will you notice if your proxy is set to funky server for a few days?
How does the account become infected? Once you have control, you can do anything that user can do; but if you don't have write access to those configuration files, this point is moot.
d) Menu items, etc: When you click on the firefox icon, are you really running what you think? What if it's a wrapper with a 3rd-party app? OK, you run from commandline... is your $PATH set to run /usr/bin before "./.hiddenvirusdir/usr/bin" ?
An interesting one, but the whole menu item issue (I remember the furore a while back) isn't really any worse than the stuff you can do on the command line - which you already seem to be aware of. :) Again, though - if you don't have access to edit system-wide .desktop files/login scripts, or write access to a user's home area, this is just describing the ends without hinting at the means.
There are PLENTY of ways to compromise a 'nix desktop without root access.
Maybe, but you haven't detailed any yet. All the stuff you're talking about - with the exception of your point A - is stuff you can do *after you've already compromised the target account*.
Yes, windows has issues. For the experienced, so does Linux. If fact, short of writing actual trojans or binaries, I generally managed to more easily subvert my friend's 'nix machine more often than our other co-workers windows box.
I really do have to ask: how? Did you use common root passwords? Home areas on NFS without root-squash? Leaving logged-on boxes unattended for long periods of time without passworded screensavers? Booting each other's machines into single-user mode/with Knoppix in the drive/etc.? Without physical access (which I have to admit is *very* difficult to protect against - but not OS specific), the things you're describing ought to be incredibly difficult to accomplish on a properly set-up Linux desktop.
You may not share that netbook - I probably wouldn't either. Nor would I be likely to connect to it remotely and run graphical apps from it, as netbooks typically aren't very powerful. Connecting from it to other machines to run *their* apps - such as my office desktop over a VPN, for example - does, however, sound pretty plausible.
Admittedly the performance of raw X over the Internet leaves (in my experience) something to be desired, but throw in compression technologies such as NX and it is eminently usable. (I wish something like that would find its way into X proper.)
Also, it may not be obvious at first, but X actually has a lot of similarity to the concept of web apps and the use cases for Chrome OS. People are using browsers to host the user interfaces of applications in which most of the data storage & heavy lifting is done remotely - sound familiar? Compared to X, though, there are some key differences: browsers have very good caching and compression, especially if you consider the HTML required for a typical web app compared to the weight of the X commands necessary to render a comparable GUI; and responsiveness is improved by running a lot of the UI logic locally in JavaScript, something the X architecture can't really do.
If browsers had been *designed* from the ground-up for this job, instead of stiffing developers with a lacklustre widget set, massive cross-browser compatibility problems and no common rules for UI layout & design, I can actually imagine something like Chrome OS working very well. In reality, though, browsers *weren't* designed for this, and servers don't have perfect up-time. I think "Web 2.0" gives us a glimpse into what applications might look like if developers *did* sit down and split every graphical app into a client & server, and the concept isn't entirely without merit; I just don't think the tools that have been co-opted for the purpose are the right ones for the job.
Tell me, what kind of backwards logic makes the X server be the display and the X client be the application?
Logic that accounts for two facts; that computers can have multiple users, and that they can be networked. SSH lets you run arbitrary command-line applications on remote machines. To do that with arbitrary graphical applications - emphasis on "arbitrary", i.e. not re-writing every graphical app as a GUI client & back-end server - you need something on the local machine to which the remote machine can send display commands, and for proper integration with graphical apps running on the local machine, ideally that same something should be catering for both. So.. you run a display server, and anything that wants to display graphics - locally or otherwise - connects to it. Simple.
Like a lot of things in the *NIX world, it stops seeming backwards when you discard a few assumptions: that a computer is only used by one person (or that everyone who uses it is happy to share the same account), and that a keyboard, monitor and mouse will always be plugged in. These assumptions have kept Windows out of many a server room for years.
However, the difficulties of writing user-friendly software outside the "comfort zone" these assumptions provide have kept Linux out of many a living room for just as long. It's not impossible, though, and the situation is improving rapidly.
Yes, but to know whether or not the auditors were sufficiently diligent, you have to define precisely what their role is.
Is their role to certify that at the time of testing, the company being tested met the required standards?
Or, is their role to certify that the company met the required standards at time of testing, and continues to meet them for as long as the certification stands?
The two are significantly different. In reality, what they actually do is probably the former, and hence they probably only have the necessary records to demonstrate that they did their job for one point in time. The interesting thing here is that, seemingly, it is not yet obvious from a legal perspective which of the two the certifiers *should* be doing. If the court decides that they *should* have been doing the latter, but only did the former, then all hell breaks loose.
Oh, balls.. forgot to log in. The above post was me.
... but that isn't the 300-line version GP is talking about. So what is your point exactly?
*I* didn't "bash" Cairo for being too immature, the Inkscape developers did.
Inkscape itself doesn't even use Cairo because they consider it too immature (and, IMHO, it is, at this point).
Just a quick reply to bash you for forgetting your own words so easily. Not that I'm bashing you, understand.
Yes, and it nowhere says my competitor is forced to redistribute the binaries to me.
Oh, for the love of... I never said it did. On that front, I was AGREEING with you.
While that is unlikely in the games market, this situation is common in the world of professional services where customers might actually pay a commercial rate for the man time required to modify a product to fit their needs.
Yes, but that's not really the situation that was under discussion, is it? In the scenario where a consultant or contractor is paid to add specific functionality to an existing product, the company paying them are probably only interested in using that product themselves, not selling or supporting it. In fact, depending on the nature of the product/changes, they may well desire not to redistribute it at all - which doesn't really make their version a competitor to the original, does it?
If someone wants to make a living making modified versions of GPL software as a consultant/contractor, good for them. In a scenario where the original author(s) of said software offer a similar service, people in the market for customized versions would be hard pressed to pick them over a third party not likely to know the code as well. (Admittedly there are many other factors that would influence such decisions, but being the original author is quite an advantage.)
GPLv3 FAQ regarding developing changes under NDAs.
I could buy a copy of his game, at which point he has now redistributed the code in binary form to me, so he must let me have the source code, but he can charge a fee. GPLv2 said the fee could only cover packaging and distribution costs but that restriction seems to have been lifted in v3. Note that my competitor may choose to refuse to sell me a copy of his game although I may be able to pick up a copy from elsewhere.
Have you actually read paragraph 6 from the GPLv3? The restriction is still very much in place (see point B, and fee restrictions on points C, D and E):
* a) Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by the Corresponding Source fixed on a durable physical medium customarily used for software interchange.
* b) Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by a written offer, valid for at least three years and valid for as long as you offer spare parts or customer support for that product model, to give anyone who possesses the object code either (1) a copy of the Corresponding Source for all the software in the product that is covered by this License, on a durable physical medium customarily used for software interchange, for a price no more than your reasonable cost of physically performing this conveying of source, or (2) access to copy the Corresponding Source from a network server at no charge.
* c) Convey individual copies of the object code with a copy of the written offer to provide the Corresponding Source. This alternative is allowed only occasionally and noncommercially, and only if you received the object code with such an offer, in accord with subsection 6b.
* d) Convey the object code by offering access from a designated place (gratis or for a charge), and offer equivalent access to the Corresponding Source in the same way through the same place at no further charge. You need not require recipients to copy the Corresponding Source along with the object code. If the place to copy the object code is a network server, the Corresponding Source may be on a different server (operated by you or a third party) that supports equivalent copying facilities, provided you maintain clear directions next to the object code saying where to find the Corresponding Source. Regardless of what server hosts the Corresponding Source, you remain obligated to ensure that it is available for as long as needed to satisfy these requirements.
* e) Convey the object code using peer-to-peer transmission, provided you inform other peers where the object code and Corresponding Source of the work are being offered to the general public at no charge under subsection 6d.
Still, AFAICT, you are correct that one must come into possession of a derivative work in object code form before one can request said work in source form. A competitor would have to have very high prices, incredibly loyal customers and no second-hand market for their product (at least, not that existed within the product's support lifetime or three years, whichever is longest) if they were to succeed in making that difficult. Note also that to sell successfully at such high prices, such a competitor must have made very high-value modifications and/or have very high marketing budgets in order to make a business of selling their derivative work, and funding such an operation would surely be viewed as a risky proposition.
From that link:
This attack is made possible because the operating system on the computer loads and boots directly into Windows without first asking for a Pointsec âpreboot authenticationâ(TM) password. Normally, with whole disk encryption, a user is required to enter a password immediately upon turning the machine on. That password is what unlocks the decryption key and allows the rest of the operating system to load and execute. This FireWire attack would not be successful in that case, because the attack requires that Windows already be up and running. In the circumstance of a properly configured encrypted computer, a stolen system that is powered off would be well protected from unauthorized access and this type of attack.
From my previous post:
If software chained on to the user authentication process doesn't require valid credentials from that process in order to decrypt, that software is crap. By "require" I mean the data is required for the cryptography to function, not just a software check that it is present.
They are describing a gross misconfiguration here IMHO.
>
Your point 2: encrypted disks tend to be an issue with laptops, where they are stolen quite often. In this most common scenario, keyloggers don't enter into it.
Crypto is only as good as the weakest link.
Physical access != stealing. The OP stated that physical access means all bets are off - I may decide to insert a hardware keylogger into your laptop and come back later, rather than run off with it there and then. AFAICS, the OP's point still stands, you just have to think beyond naive assumptions.
Your point 1 is VERY wrong. Cracking an 8-character password when given access to the hash is much much much much easier than cracking a 20-character encryption passphrase or a smartcard-based encryption system.
Then the problem is that you have a sh*t user authentication system, which is something that should be fixed no matter what.
Furthermore, a crypto system which relies on Windows authentication to cough up the crypto key does not even require knowledge of the password. Just bypass the authentication and you get the key. I KNOW this is the case for Checkpoint WIL disk encryption.
Do you really? If I were to log into a Windows box as administrator and use this fact to run a shell impersonating another user, would this decrypt their stuff for me (i.e. no hacking or cracking involved), or by "bypassing" do you actually mean getting through the login process without entering the real password, e.g. replaying a previous handshake? Again, if the latter is the case, the problem is a sh*t user authentication system.
True, if you know a particular OS's authentication system uses weak hashes, or is vulnerable to replay attacks, or <insert vulnerability here> perhaps you shouldn't design crypto systems for that OS which integrate with it. But that's a problem with that OS, not with the very idea of integration.
Some disk encryption solutions, such as Checkpoint, rely on windows authentication to decrypt the disk. If this can be bypassed easily, it makes this disk encryption worthless.
To rephrase my initial point:
I don't know for definite that the Windows 7 authentication process satisfies these requirements, or that Checkpoint's decryption solution satisfies these requirements, because I don't have copies of them and am not a security researcher/cryptanalyst. But even if they don't, that doesn't make the whole concept bogus - it makes this particular implementation bogus. Can you provide concrete evidence that the two pieces of software in question don't satisfy these requirements?
Two points of note:
1. There's nothing wrong with decryption being integrated with the user authentication system *provided it requires a correct password to succeed*, not just a shell claiming it is running as a given user.
Although it isn't targetted at disk encryption, gnome-keyring can be integrated with PAM to auto-unlock a user's encrypted password storage (their "default keyring") at login time. Going further, seahorse-agent provides auto-unlocking of SSH and GPG keys (by impersonating ssh-agent and gpg-agent respectively) in similar fashion, by storing the passphrases in the user's default keyring I believe. I may just not have looked hard enough, but I haven't heard anyone slating them for being "theoretically worthless" - unless you have no password on your default keyring, not even root su'ing to impersonate a particular user will grant access to their keys.
2. On the other hand, even "real" disk encryption (as opposed to "fake" disk encryption - ROT13?) DOES NOT protect against physical access if the attacker can get a keylogger (presumably a hardware one) in place to grab the password. Same for gnome-keyring and seahorse-agent. What these systems CAN do is prevent decryption of a stolen disk/keyring when no other data is available to the attacker.
They're... ok, but none of them particularly grab me. I really, really dislike the way that you have to stop and press an action button to pick up a weapon - it might be intentional, because in the small amount of time I played, it seemed like the inventory was very limited. What really killed that mechanic is the way that picking a weapon up also switches to it. Realistic, arguably, but incredibly awkward when you pick up a grenade, for example.
Not sure what to make of the flame thrower. Nice visual effect, but I found it difficult to determine whether or not I was actually *hitting* anything with it (apart from myself).
Not strictly weapon-related: I found the entire game very, very sluggish - movement, projectiles, reload times... far too slow IMO. I'm not saying you necessarily have to emulate Q3 for pacing - bunny-hopping at break-neck speeds isn't everything, UT2004 took a different approach with fixed-speed movement like yours, but configurable overall game speed. Currently, though, things take so long to accomplish that it somehow doesn't feel like you're actually in complete control of the game. Also I'm not entirely convinced by the HUD concept - it could grow on me, but the option of a more traditional HUD wouldn't go amiss. Remember, sometimes the reason things get copied time and time again is because they *work* - you don't have to change *everything* to be good!
Very good choice of engine, though, and nice to finally see ragdolls in an open-source FPS. For me personally, Nexuiz is by far and away the best FOSS FPS around in terms of gameplay, but the graphics are too garish (no real consistency in colour and texture usage) and the engine just doesn't perform.
I played for a small amount of time today, and couldn't shake the feeling that I was hobbling around with a pea shooter, whilst the bots ran around with real guns. Everything I did felt ineffectual, but the bots didn't seem to have any trouble killing me.
The theory behind using the Google-served copies of JavaScript libraries isn't to reduce load on the whitehouse.gov servers, but to improve caching.
This is true, but it doesn't change the fact that it still introduces security/privacy concerns. The fact remains that if the remote JavaScript changes, the behaviour of all websites referencing it will change. The method by which it changes doesn't have to involve hacking Google (DNS hijacking (site-local or otherwise), HTTP cache poisoning, etc.), and changes don't have to be outwardly malicious to have unintended side-effects (AVG's LinkScanner, anyone?).
On the face of it, though, referencing JQuery files directly from Google's servers is no worse than them referencing external resources from WebTrends Live, which I presume they have to do at some point in the tracking process.
I freely admit these comments are verging on paranoid, but the point is, intentions != reality, and just because there may be one good reason to do something doesn't mean there aren't also good reasons not to. Reality doesn't care which reason you picked.
It's totally unnecessary. It's a waste of time commuting. It's a waste of energy commuting. It's a waste of gas, office space, the expense of computers in the office, space on public transportation, business clothes. It goes on and on. We should all be working from home.
That may sound like a nice ideal, but there are many reasons that working from home isn't (yet?) a given.
I think you underestimate the importance of being able to walk up to a colleague and work with them face-to-face. The trouble with your ideal is that "work", in this context, rarely - if ever - just means writing code: it can mean giving someone a helping hand with a bit of debugging, going over design documents, giving feedback on a demo, performing knowledge transfer, or simply taking a break and having a chat. These things needn't be as formal as they sound: I quite often offer to help just because I can hear someone else's cries of anguish, or get asked to cast an eye over something for a minute or two simply because I'm there and my opinions are valued. A lot of this stuff just wouldn't happen if we weren't sat in the same building.
Coming back to that throwaway comment regarding opinions, how do you create an accurate picture of a person's abilities - especially those which may be of use, but are not part of their job description - without spending time with them?
There are also pure practical concerns. Being able to look over someone's shoulder at their monitor/piece of paper; body language; the ability to physically show someone what you mean during moments of confusion because they're *there*.
On the other side of the coin, there are also reasons why somebody may not want to work from home. I enjoy having the option to go to lunch with my co-workers; I like knowing who people are at meetings and release parties; I don't like my one year old daughter coming over to pester me and can't move my computer out of the living room because I can't afford anywhere bigger than this crappy two-bedroom flat; VMware over a VPN sucks. I have worked from home and I don't enjoy it.
If you could honestly do your job just as well as you do it now without physical contact with any of your colleagues, you aren't doing it right, you work for a "software factory", and/or your office environment is all wrong.
In closing, I'd like to offer up the idea that perhaps this thread isn't as off-topic as it may at first seem. The whole concept of part-time development work (which, if you're still holding down a full-time job, I assume means working from home) being somehow more satisfying than full-time work is slightly alien to me: unless you're writing cookie-cutter code, so well-defined as to be rather boring to churn out, it will take the majority of those 15 hours a week simply dealing with the practicalities of getting to know the code and other developers you're working with. You really think working this way could be more organised, more accountable and less political?
Even better: use NX (http://www.nomachine.com/ - includes a "free edition"). Basically heavily compressed X forwarding, but also includes niceties such as being able to disconnect and reconnect sessions without killing the X clients. I use it over a VPN on the rare occasions I work from home, on a standard ADSL connection. Typing on an NX forwarded xterm is almost as quick as when SSH-ing in directly (which may seem a somewhat pointless use-case, but is the closest I know how to get to the behaviour of "standard" SSH with X forwarding). I also find I get *much* better responsiveness if I run VMWare Server Client on my work box, forwarded over NX, instead of running the client at home and connecting to the work VMWare server from there.*
Also available as FreeNX (http://freenx.berlios.de), but harder to set up IME.
* Which may just be another way of saying "VMWare's protocol sucks", but regardless, turns it from near unusable to very useful.
Bit like Lemmings with physics. I'm not an affiliate of any sort, just someone who pre-ordered, played the beta of chaper 1 and loved it. :)
http://www.2dboy.com/
Unfortunately, though, having "gone gold" means "will be available in November", AFAICT. *sob*
I know it's incredibly bad form to keep replying to my own posts, but I think this is an important subject. :) Please see also http://www.fsf.org/licensing/licenses/gpl-faq.html#FSWithNFLibs and http://www.fsf.org/licensing/licenses/gpl-faq.html#GPLIncompatibleLibs. These seem to largely agree with my viewpoint that it isn't inherently prohibited, but there may be legal problems, and you should consider adding exceptions to your program's license to explicitly allow linking with required non-free libraries.
However, their arguments seem to rely on the concept of linking - including static linking - being some sort of "magic" that results in a derived work. Not everyone agrees with this concept, provided that what you're linking with isn't modified. For example, see this LKML post by Linus Torvalds: http://lkml.org/lkml/2006/12/17/79. His views basically boil down to static linking being a form of aggregation, and dynamic linking of separate works having even less bearing since it doesn't necessarily require distribution of both works. Both, however, having bearing on whether or not two works are independent.
A minor clarification:
a System Library being defined earlier as, in essence, something which interfaces with parts of an application's host OS, if anyUnder that wording, anything running on an OS is a System Library. This is not my intended meaning, nor that of the license; it should read:
a System Library being defined earlier as, in essence, something which exists purely to interface with parts of an application's host OS, if anyThink wrappers, language bindings to OS APIs, etc. :)
It seems to be a bit of a murky area, but here is my interpretation of the matter. Please note: IANAL. The quotes are taken from the GPLv3; as far as I can tell, the GPLv2 says much the same thing, albeit less explicitly.
From section 1, "Source code":
The "Corresponding Source" for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. For example, Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work.I would say an application which makes use of the Havok SDK is "specifically designed" to require it. I don't think one could get away with saying it's a "System Library", either (a System Library being defined earlier as, in essence, something which interfaces with parts of an application's host OS, if any). Hence, the source code of the Havok SDK is Corresponding Source, IMHO.
So, what requirements does the GPLv3 place on Corresponding Source?
Sections 4 and 5, "Conveying Verbatim Copies" [of the program's source code] and "Conveying Modified Source Versions", do not mention Corresponding Source at all. From this, I would draw the conclusion that provided you are distributing your application in source code form, you do not have to re-distribute Corresponding Source.
However, from Section 6, "Conveying Non-source Forms":
You may convey a covered work in object code form under the terms of sections 4 and 5, provided that you also convey the machine-readable Corresponding Source under the terms of this LicenseSo, if you are distributing binaries, you must distribute Corresponding Source, which obviously requires you to have access to it. In the case of the Havok SDK, this is clearly not the case.
This requirement is, in my opinion, linked in with the "anti-Tivoisation" measures incorporated into GPLv3; however it also has some importance when considering continued access to - and historical preservation of - useful software. It means that something licensed under the GPLv3 and distributed in binary form cannot be specifically designed (think "modified by Corporation X") to require closed-source components which do not qualify as System Libraries or Major Components of an OS. It also means that if a third-party library falls out of maintenance, it can still be fixed and updated as required to enable applications requiring it to keep working.
So, to summarise:
Please note that I have not read the Havok SDK's license. It may or may not lay out requirements of its own for programs which prevent the scenario under discussion, but AFAICT, the GPLv3 itself doesn't prevent usage of closed-source libraries per se, provided you stick to only giving out source.
* Similar - but by no means identical - to the provisions in the Mozilla license which require distribution of binaries compiled by third parties to have all Mozilla-related trademarks removed. Debian et al. rebrand Firefox as a result; source-based distributions such as Gentoo don't innately prevent usage of official branding because they only distribute source code, but make doing so optional, and make it clear that doing so means you can't re-distribute your own binaries after compilation.