There is no such thing as "British English". There is either English, or any other variant of - American English, Australian English etc.
Well, I tend to agree actually; except that in the context of the discussion of variants, saying "British English" rather than solely "English" shows that you *mean* British English, and not instead a collection of all English variants.
Ha! I'm from the UK, so I use - of course - British English. However, occasionally there is a need to compromise. When I wrote colordiff I decided to use US-style 'color' in the project name (since colorgcc, colormake and other utilities already existed and I felt that made more sense) but to use UK-style 'colour' in all the documentation.
Do you not say anything in email that you wouldn't want the entire world to know, btw, in case your ISP publishes your email? Or not say anything to anyone at all, in case they might tell the newspapers?
Absolutely, you should certainly be aware of the fact that your ISP might 'publish' your email, perhaps by providing it to Certain Authorities. If this bothers you, use encryption, use it properly and be sure you trust your correspondents to do the same.
If you are so scared of trusting anyone such that you treat telling one person equivalent to telling everyone, you must either be a very secretive person, or you don't mind the whole world knowing about anything you do.
That's not what I said. I didn't say I was scared of trusting anyone. I implied that I don't trust Facebook not to either (a) make the information 'public' or (b) be forced to provide the information to Certain Authorities. Their recent fuss with their terms of service doesn't help install confidence in them.
I believe that treating "uploading content to Facebook" as "publishing to all" is a perfectly reasonable (and not necessarily paranoid) approach to take, in these circumstances.
Why don't you post your credit card numbers on Slashdot? After all, your credit company *might* do that, so it's naive to think there's any difference, right?
That's a ludicrous stretching of the argument. I trust my credit card company not to do that. Credit card companies are, generally speaking, good at keeping information secure. And it would not be in their interest to do as you suggest.
Facebook, on the other hand, have no such incentive to keep information on the site private.
Content on Facebook (and any other social networking site with privacy controls) isn't for public consumption - it's for consumption by those whom you've marked as friends.
I can't work out whether you're being serious, being naive or being a troll.
The act of posting anything to sites such as Facebook should be made on the assumption that it *might* become public. Assuming otherwise is just naive. If I post stuff, I only *expect* my friends to see it, but I tailor what I write on the assumption that it is completely public.
The login form might be located on an HTTP page, but as long as the form submits to an HTTPS page, your login credentials are still SSL-encrypted.
In general, yes, but one of the 'tricks' of sslstrip is that it changes the content of the HTTP-served page so that the (formerly) HTTPS submission page is no longer HTTPS, but HTTP.
There's nothing "grey" about the DVD solution. Using libdvdcss in the USA is a violation of the DMCA, and consequently is illegal at a federal level.
So why not release Debian with all the nice goodies included, but have the final stage of the installer ask "Are you in the US?"... and if you answer "Yes", then it removes anything that cannot be distributed there.
My 3 year old monkey(who obviously can't read/write) uses the computer all the time and I'm amazed at what she gets up to (ok she's not posting on slashdot, but give her time). She can switch on, start up the web browser, (her home page is the BBC kids page CBeebies) and she just looks around, finds the games to play, works out what to do and plays them. When she gets bored she goes back and chooses something else - painting a picture, watching a video etc. She only ever asks for help when she gets stuck in a dead end (like when she needs to download an add-on). I imagine the Monkey v4.5 is considerably more advanced.
Speaking as the parent process for an instance of Monkey v4.5, you're not wrong. She has the same setup as above, including CBeebies as the home page. The phrase "The Flash plugin has broken again, Dad" was part of her vocabulary for a while, until I sorted it out.
Just to throw what I use into the mix, on a network of ~100 WinXP desktops:
- Samba - acts as domain controller, triggers login scripts, maps drives etc. System Policy controlled using NTConfig.pol files in the 'netlogon' share, prepared using poledit.exe
- OpenLDAP - authentication backend for Samba, groups/users for the Samba server (plus many other tasks which are unrelated to desktop usage);
- WPKG - for software deployment, runs at each boot-up - really nice.
That's because the behaviour reported in the bug (the actual MITM attack) is *not* a problem with Firefox as suspected by the reporter: Firefox was behaving correctly by identifying the SSL certificates as invalid. It is however an interesting report of a MITM attack.
The most important part of the installer that has changed for the better is you can easily start the installation by selecting from gui and text options from a menu. The Etch installer you had to type something to start the installer.
Thank goodness for that. Now I can install Debian on all my systems which don't have a keyboard. Phew!
"There is a need for something, something to explain the license..."
Maybe, if you like. But there's no need for the user to be nagged (even once) about it. Other applications don't do it. The user doesn't need to know what the license is. The user's distribution gives them 1000s of applications and you certainly don't want to see a "This is $APP, its license is $LICENSE. Click [OK]" for every one.
There's no need for this. Put licensing/copyright information in Help/About, so that those who care can find it.
Please do some research before telling someone else to do research before posting.
DragonflyBSD is a fork of FreeBSD and not exactly mainstream so you can hardly accuse me of not being aware of what it said. Further, apart from that remark on the page you linked-to claiming that "OpenSSH contains a blacklist feature", there's nothing to suggest that OpenSSH itself actually contains any such blacklist management.
My research: There's nothing in the OpenSSH ChangeLog at ftp://ftp.plig.org/pub/OpenBSD/OpenSSH/portable/ChangeLog which mentions blacklisting and there's nothing in the source tarball either. I've looked (both the core distribution and the portable version).
It may be that DragonflyBSD includes blacklist management, but if so, they didn't get it from OpenSSH.
I raised the bug https://bugzilla.mindrot.org/show_bug.cgi?id=1469 because I thought that such a feature should be included. If the OpenSSH developers were interested in supporting this, I'm sure they'd have (a) commented on the bug and (b) written the code or used some of the contributed code. They may well have good reasons for not including this, but they haven't commented either way.
Remind me again, why in the world would I be running my OpenBSD server with the keys to it's SSH sever generated on a Debinin/Ubuntu machine?
That's not the problem. The problem is user keys (not server keys) generated on a Debian/Ubuntu machine which are then uploaded to a server. Any server. Running any distro/OS which is capable of running sshd.
This means that, since the compromise arose, Debian and Ubuntu distros are safe once patched with the blacklist code. However, for keys generated on Debian/Ubuntu but uploaded to non-Debian/Ubuntu servers, those non-Debian/Ubuntu servers will still be vulnerable unless manually checked. This means: OpenBSD servers, Fedora servers etc.
Have any distros apart from Debian/Ubuntu provided blacklist-like tools for this issue? Any of the *BSDs?
If you are running vista on a computer with 1GB ram, you are beyond help anyway.
You could also argue that the RAM remark is irrelevant too;-) Anyway, I was setting up this laptop for PHB: Lenovo ship Vista laptops with 1GB. I persuaded our supplier to upgrade it to 2GB on the grounds that 1GB/Vista "bordered on self harm". As he owed me a favour, he went along with that and sent the extra RAM:-)
Slashdot Mirror
Perhaps it's really OpenBSD, but just has a WinXP theme?!?
There is no such thing as "British English". There is either English, or any other variant of - American English, Australian English etc.
Well, I tend to agree actually; except that in the context of the discussion of variants, saying "British English" rather than solely "English" shows that you *mean* British English, and not instead a collection of all English variants.
American English or British English?
Ha! I'm from the UK, so I use - of course - British English. However, occasionally there is a need to compromise. When I wrote colordiff I decided to use US-style 'color' in the project name (since colorgcc, colormake and other utilities already existed and I felt that made more sense) but to use UK-style 'colour' in all the documentation.
Yes, almost certainly. You need to understand English to develop in programming languages where the syntax and reserved words are in English.
Next question?
Do you not say anything in email that you wouldn't want the entire world to know, btw, in case your ISP publishes your email? Or not say anything to anyone at all, in case they might tell the newspapers?
Absolutely, you should certainly be aware of the fact that your ISP might 'publish' your email, perhaps by providing it to Certain Authorities. If this bothers you, use encryption, use it properly and be sure you trust your correspondents to do the same.
If you are so scared of trusting anyone such that you treat telling one person equivalent to telling everyone, you must either be a very secretive person, or you don't mind the whole world knowing about anything you do.
That's not what I said. I didn't say I was scared of trusting anyone. I implied that I don't trust Facebook not to either (a) make the information 'public' or (b) be forced to provide the information to Certain Authorities. Their recent fuss with their terms of service doesn't help install confidence in them.
I believe that treating "uploading content to Facebook" as "publishing to all" is a perfectly reasonable (and not necessarily paranoid) approach to take, in these circumstances.
Why don't you post your credit card numbers on Slashdot? After all, your credit company *might* do that, so it's naive to think there's any difference, right?
That's a ludicrous stretching of the argument. I trust my credit card company not to do that. Credit card companies are, generally speaking, good at keeping information secure. And it would not be in their interest to do as you suggest.
Facebook, on the other hand, have no such incentive to keep information on the site private.
Content on Facebook (and any other social networking site with privacy controls) isn't for public consumption - it's for consumption by those whom you've marked as friends.
I can't work out whether you're being serious, being naive or being a troll.
The act of posting anything to sites such as Facebook should be made on the assumption that it *might* become public. Assuming otherwise is just naive. If I post stuff, I only *expect* my friends to see it, but I tailor what I write on the assumption that it is completely public.
Not '+1 Informative', this should be '+1 Misleading'. Disabling javascript is *not* sufficient to protect you against this exploit.
The login form might be located on an HTTP page, but as long as the form submits to an HTTPS page, your login credentials are still SSL-encrypted.
In general, yes, but one of the 'tricks' of sslstrip is that it changes the content of the HTTP-served page so that the (formerly) HTTPS submission page is no longer HTTPS, but HTTP.
There's nothing "grey" about the DVD solution. Using libdvdcss in the USA is a violation of the DMCA, and consequently is illegal at a federal level.
So why not release Debian with all the nice goodies included, but have the final stage of the installer ask "Are you in the US?" ... and if you answer "Yes", then it removes anything that cannot be distributed there.
My 3 year old monkey(who obviously can't read/write) uses the computer all the time and I'm amazed at what she gets up to (ok she's not posting on slashdot, but give her time). She can switch on, start up the web browser, (her home page is the BBC kids page CBeebies) and she just looks around, finds the games to play, works out what to do and plays them. When she gets bored she goes back and chooses something else - painting a picture, watching a video etc. She only ever asks for help when she gets stuck in a dead end (like when she needs to download an add-on). I imagine the Monkey v4.5 is considerably more advanced.
Speaking as the parent process for an instance of Monkey v4.5, you're not wrong. She has the same setup as above, including CBeebies as the home page. The phrase "The Flash plugin has broken again, Dad" was part of her vocabulary for a while, until I sorted it out.
Aw, no "Windows 7 DVD-Personally-Autographed-By-Bill-Gates and Thrown Across The Room By Steve Ballmer" Ultimate Edition, then?
Just to throw what I use into the mix, on a network of ~100 WinXP desktops:
- Samba - acts as domain controller, triggers login scripts, maps drives etc. System Policy controlled using NTConfig.pol files in the 'netlogon' share, prepared using poledit.exe
- OpenLDAP - authentication backend for Samba, groups/users for the Samba server (plus many other tasks which are unrelated to desktop usage);
- WPKG - for software deployment, runs at each boot-up - really nice.
The example cited is "RESOLVED INVALID"
That's because the behaviour reported in the bug (the actual MITM attack) is *not* a problem with Firefox as suspected by the reporter: Firefox was behaving correctly by identifying the SSL certificates as invalid. It is however an interesting report of a MITM attack.
Put me in a room with a bear, repeat a hundred times and see who comes out on top. Doesn't mean the bear is smarter.
I think it might mean that, actually. You just said "Put me in a room with a bear". Well, duh... you're clearly not that smart.
A review already? Nah, not possible. The book only was only published in September. That's nowhere near long enough to read A Neal Stephenson.
Article summary: use 'make -j', 'distcc' and 'ccache' or something combination of these. These utilities are well known and widely used already, no?
The most important part of the installer that has changed for the better is you can easily start the installation by selecting from gui and text options from a menu. The Etch installer you had to type something to start the installer.
Thank goodness for that. Now I can install Debian on all my systems which don't have a keyboard. Phew!
Read http://en.wikipedia.org/wiki/Chronology_of_Provisional_IRA_Actions - the numerous bombings by the IRA in the 1970s, 1980s and 1990s.
Then *one* incident in 2005 by "Actual Terrorists" and everyone goes ape.
Facebook now be havin' an "English (Pirate)" language option. Yarrr!
"There is a need for something, something to explain the license..."
Maybe, if you like. But there's no need for the user to be nagged (even once) about it. Other applications don't do it. The user doesn't need to know what the license is. The user's distribution gives them 1000s of applications and you certainly don't want to see a "This is $APP, its license is $LICENSE. Click [OK]" for every one.
There's no need for this. Put licensing/copyright information in Help/About, so that those who care can find it.
"OpenSSH now has a blacklist feature for weak Debian-generated ssh keys." From: http://www.dragonflybsd.org/community/release2_0.shtml Please do just a LITTLE bit of research before posting.
Please do some research before telling someone else to do research before posting.
DragonflyBSD is a fork of FreeBSD and not exactly mainstream so you can hardly accuse me of not being aware of what it said. Further, apart from that remark on the page you linked-to claiming that "OpenSSH contains a blacklist feature", there's nothing to suggest that OpenSSH itself actually contains any such blacklist management.
My research: There's nothing in the OpenSSH ChangeLog at ftp://ftp.plig.org/pub/OpenBSD/OpenSSH/portable/ChangeLog which mentions blacklisting and there's nothing in the source tarball either. I've looked (both the core distribution and the portable version).
It may be that DragonflyBSD includes blacklist management, but if so, they didn't get it from OpenSSH.
I raised the bug https://bugzilla.mindrot.org/show_bug.cgi?id=1469 because I thought that such a feature should be included. If the OpenSSH developers were interested in supporting this, I'm sure they'd have (a) commented on the bug and (b) written the code or used some of the contributed code. They may well have good reasons for not including this, but they haven't commented either way.
Remind me again, why in the world would I be running my OpenBSD server with the keys to it's SSH sever generated on a Debinin/Ubuntu machine?
That's not the problem. The problem is user keys (not server keys) generated on a Debian/Ubuntu machine which are then uploaded to a server. Any server. Running any distro/OS which is capable of running sshd.
Even the openssh guys don't seem interested in including blacklist support for probably-compromised keys: see https://bugzilla.mindrot.org/show_bug.cgi?id=1469
This means that, since the compromise arose, Debian and Ubuntu distros are safe once patched with the blacklist code. However, for keys generated on Debian/Ubuntu but uploaded to non-Debian/Ubuntu servers, those non-Debian/Ubuntu servers will still be vulnerable unless manually checked. This means: OpenBSD servers, Fedora servers etc.
Have any distros apart from Debian/Ubuntu provided blacklist-like tools for this issue? Any of the *BSDs?
If you are running vista on a computer with 1GB ram, you are beyond help anyway.
You could also argue that the RAM remark is irrelevant too ;-) Anyway, I was setting up this laptop for PHB: Lenovo ship Vista laptops with 1GB. I persuaded our supplier to upgrade it to 2GB on the grounds that 1GB/Vista "bordered on self harm". As he owed me a favour, he went along with that and sent the extra RAM :-)
> Bruce Schneier and gang aren't impressed by truecrypts product .
Their problem is relating to the deniability of the encryption. That's not an issue for many, I guess...