> Very true! If I meet a person face-to-face, they hand me their PGP/GPG public key, and they show me plausible-looking picture ID that matches the identity that their key claims to represent,
And I've stolen private GPG keys, stored in unsecured home directories or on backup tapes, precisely to demonstrate some of the current problems with the web of trust. It's particularly useful to steal poorly secured GPG keys that are part of an automated build process, since the build process must be able to unlock those keys.
What you've described is, I'm afraid, the technical approach to what is a workflow problem, not a technical problem.
Yes. I can clean up after the fact, with every single source file my team uses, re-indent all of them, and institute my particular site's arbitrary white space coding standard on every open source project or shared development project I work with, and mandate that they all use "vim" even in their Macintosh and Windows development environments. I can also completely break the revision history when I reset the history by general whitespace changes across every single file that uses a non-standard indentation format. I can also break, and manually resolve the problems with configuration tools that edited those files for deployment based on particular text, including the whitespace.
Now please pay my contracting rates or salary rates to resolve the disputes in every project I work with about whose coding standard we should follow, and which editor settings we'll enforce in every development environment, and the time getting such wholesale document changes through code review. I'm afraid it adds up very, very quickly to a lot of wasted resources.
It doesn't work as well as you might wish. X11 has, historically, not compressed well for remote graphical interactions. The problem is compounded when running X sessions over a VPN to a remote environment, and using the graphical environment hosted inside the GUI to the virtual machine manager.
I've found vim very useful when memory or resource squeezed. Emacs's tendency to leave temporary scattered copies of large edited files is particularly dangerous when trying to salvage database backups on a cramped partition. But the tendency of vi users to confuse their personal display settings for indentation with the actual text in the files they edit has caused enormous problems. This especially happens they submit code following indentations standards that exist only in the.vimrc somebody has been mailing around for the last six years, and which no other group in the world uses, and then they complain when the authors of the original software regularize the whitespace on submitted patches.
Merely speaking a language may not be interesting enough to rekindle your interest and encourage growth. But there hundreds of good open source and freeware projects that would benefit from your insight and experience. CPAN, github, GNU, and Apache all host projects that may interest you nad have relevance to your work, without being part of your daily grind. Perhaps you'd enjoy a chance to refine some familiar old project?
It can almost be done by rebasing and replacing a central master. But this deteriotes the history and interaction with _every single cloned repository_ and is generally noticed quite quickly. The validity of all the potentially independent, separate cloned repositories is one of the very useful, decentralized powers of git.
Such as https://www.bitbucket.com/ which has an interestingly different business model. Github represents, in technology, a great step forward from the older https://sourceforge.net/. But this sounds like they have some serious employee relationship and morale problems to deal with.
Unless a species can modify its own biology, or the evolution of _technology_ or of _societies_ can be included. And in practice, it is: evolution is not just DNA biology, it involves entire ecosystems and behavior that are effective, but contained nowhere within the biology of a species.
I was not referring to the insertion of false data: I was referring to its insistence on doing a local cache, appartnely not part of the system DNS, _after_ switching DNS servers and potentially needing new DNS answers due to being in a different DNS "view". This is common enough practice with various proxy and load balancer configurations, to have a different DNS record on the internal network than on the external network.
Inserting false DNS records is a whole _different_ security risk, one that is an ongoing problem that web browsers can do little about. In theory, it should be noticeable via SSL certificate failures. In practice, there are so many stolen "CA" or "Certificate Authority" records in the wild that can be used to sign arbitrary SSL certificates that we canot rely on a fake website not having a signed, apparently legitimate SSL certificate even for a corporate site like a bank. So poisoned DNS records, which is the problem you are referring to, are a much larger risk than one might expect. And the browsers can do _nothing_ about this. It's a failure of the SSL architecture.
Oh, my. No, I'm afraid it's "greatest common denominator". it's the standard mathematical "term of art" for the largest number that can that two, or more, numbers can be divided by, with no remainder. "Greatest common factor" may be more clear to you, but failure to use the correct label should be a troubling sign with anyone you expect to do mathematical work.
The tendency of Firefox to preserve its own DNS cach means I cannot use it when hopping from VPN to VPN with split DNS running. unless I configure and install my _own_ local DNS server to auto-reconfigure every time I activate a VPN. I'm afraid it's become unusable for me for real work and testing when switching from internal to external website access as I debug network and configuration issues: it's the only browser that fails this way.
As an older programmer, I'm fond of some very good quality, older tools such as "webmin". Not all the modules added to it are excellent, but its very clean and very flexible for many core system utilities such as BIND based DNS. It's also much more robust than any configuration tool that relies on a separate, manually configured back end database.
I'm afraid that this usually means two entirely different interfaces, with overlapping features and writing to the same configurations. That is more than twice the development cost, since they involve distinct styles and expertise to develop or manage and the _negotiation_ between the two styles is an added cost. And it makes debugging more than twice as expensive, since tests have to involve both sets of interfaces and switching between them.
This is prohibitively expensive: the result is usually that the "plain" interface lacks critical features that are only available in the more sophisticated tool.
That's a fascinating guess. It's not a feature I've personally used. Although yes, the Cisco configurations and the Cisco _clients_ do tend to have a horrible morass of undocumented options.
> since that puts an upper bound on human ingenuity
I'm saying to master the components you need before planning the project. Simply saying "human ingenuity will solve that" is like saying "we'll make the software secure when we're ready to publish". It is, itself, guaranteeing project failure.
> The stars will die out long before entropy becomes relevant here.
Do you understand what "entropy" is? Even using the purely thermodynamic definition, there is a very real energy cost for preserving complete coherence of the DNA sequence. Certainly, as a dynamic chemical system, the "entropy" present in the DNA molecule itself and its complex environment prohibit the likelihood of perfect sequence coherence over lengthy times. The result of such failures is degradation. One of the most unfortunate results of such losses is, frankly, cancer.
Frankly, for significant extension of human life, a general cancer cure is of critical importance. Or the accumulation of small risk factors is going to accumulate to a near certainty of dangerous cancers, of many different sorts. We already see this among our older citizens!
>> especially since scar tissue accumulates and regrowth of neural tissue has never been mastered.
> Neither which is a permanent problem.
Given the lack of progress for both issues, there's little concrete reason to assume they are _not_ permanent issues.
> I assure you that companies like Google, Facebook, Twitter, Microsoft and their relation ALL do the EXACT SAME THING.
Not from my direct experience with several of those companies. They install wldcard certificates, signed by one of the commercial root authorities, not their own root certificates.
Do you have any direct experience or instances to show that _any_ major software vendor or software service does this?
Clearly, not in IT or network security. A root CA is not for "filtering". A proxy or firewall is for filtering, and a root CA doesn't help with that other than to automatically authorize the certificates presented by the proxy. A root CA is for signing other certificates so that they are accepted without the manual intervention of the student or visitor using the "Bring-Your-Own-Device".
It may have conceivably been installed under a sealed warrant for "national security" reasons. Much like the Patriot Act in the USA demands silent cooperation with warrant free investigations of unconstitutional scope, I'm sure that UK governmental agencies have also demanded and received cooperation with dangerously excessive search orders.
A "private boarding school" implies that the school might well have international students, or students with parents are of economic and political power. Is it feasible to contact _those_ students and their families, to explain what the school has been doing without their knowledge? A similar scandal involving the use of webcams on student laptops to photograph them at home was reported on Slashdot, http://en.wikipedia.org/wiki/R....
Doing Main-In-The-Middle attacks with the root CA and SSL certificates signed by that root CA is only one of the risks. Once certificates signed by that CA are accepted, they're permanently usable for fake websites, for main-in-the-middle attacks with proxies using those faked SSL certificates for designated websites, and for replacing ordinary SSL signed software or update packages with fake, rootkitted packages. The list of subtler security issues is longer: those are only a few of the leading problems.
I'd be profoundly concerned that the school is not competent to protect their CA, or other certificates that have already been signed with it. Since they've already demonstrated ignorance among some personnel of their own security practices, and unwillingness to communicate truthfully with students, I'd assume that they've never properly secured the host or network on which they've stored their CA. Unless they have _erased_ the private CA and all copies of it, it can be misused at anytime in the future, especially on the school's own network.
Moreover, if possible before the CA is erased, _all_ of those certificates already signed with the CA need to be revoked, and replaced with a correctly signed one. That's quite expensive, at roughly $200 USD/certificate/year. You can buy get the certificates more cheaply, but that estimate includes the technical time to go replace the old certificates.
What you're describing is a sometimes hidden form of the "Not Invented Here" problem, where some deficit in a working software stack is discarded for theoretical, not production reasons. In this case, it can be guaranteed to be unstable because it would replace whatever production grade audio tool is already working with one written in house, requiring maintenance, and _likely vulnerable to the same SELinux problems_.
> Telomere breakdown, and cell deterioration is one of our biggest issues
And if we stopped entropy, cell detioration would not occur. It's about as likely, I'm afraid. Telomeres are a molecular _answer_ to DNA deterioration, preenting the connection of one DNA molecule to another at the end points. And some types of system damage are cumulative, especially since scar tissue accumulates and regrowth of neural tissue has never been mastered.
I remember these designs. They absolutely stripped the tread off the rear wheels within a few hundred miles of using them, and kept the local bike shops in serious business replacing wheels. Not tires: the wheels.
Federal offices are merely an example. I know businesses that absolutely refuse to put their mailing address or the location of their offices or their business office telephone number on their website or in local telephone listings, to avoid physical spam or having angry customers show up at their door. And in the business world, just try to find the street address of the ISP data centers near you.
Google Maps has been a reliable way for me to actually _find_ the data center I need to visit, when the staff of the company I'm dealing with don't know the street address, and the IT person is in the data center and their cell phone can't work from inside there.
I'm afraid that I was unclear. Worrying about how this will hide valid "NXDOMAIN" results is pointless, since thoe have already been hijacked by many ISP's DNS proxy servers and instead return the ISP's desired advertising page. They can also be redirected to far, far more dangerous services, sich as Phishing websites or mail servers to accept misaddressed email.
NXDOMAIN has not been a reliable response for invalid DNS queries for roughly 15 years. Look into the history of the "*.com" DNS entry in Verisign's root servers for the.com domain, which were returning valid Verisign owned hosts. And look carefully at the DNS proxy setups of major home network services, which often return their domain sales web pages instead of "NXDOMAIN" for invalid DNS entries.
Given that the data has _already_ been corrupted, this seems a reasonable attempt to broaden what is now done with "example.com". It also has the benefit that it's not auto-activated in default Kerberos configurations, a bit of behavior that genuinely alarms me in most default Kerberos setups and which few configuration tools have the ability to remove.
Slashdot Mirror
> Very true! If I meet a person face-to-face, they hand me their PGP/GPG public key, and they show me plausible-looking picture ID that matches the identity that their key claims to represent,
And I've stolen private GPG keys, stored in unsecured home directories or on backup tapes, precisely to demonstrate some of the current problems with the web of trust. It's particularly useful to steal poorly secured GPG keys that are part of an automated build process, since the build process must be able to unlock those keys.
What you've described is, I'm afraid, the technical approach to what is a workflow problem, not a technical problem.
Yes. I can clean up after the fact, with every single source file my team uses, re-indent all of them, and institute my particular site's arbitrary white space coding standard on every open source project or shared development project I work with, and mandate that they all use "vim" even in their Macintosh and Windows development environments. I can also completely break the revision history when I reset the history by general whitespace changes across every single file that uses a non-standard indentation format. I can also break, and manually resolve the problems with configuration tools that edited those files for deployment based on particular text, including the whitespace.
Now please pay my contracting rates or salary rates to resolve the disputes in every project I work with about whose coding standard we should follow, and which editor settings we'll enforce in every development environment, and the time getting such wholesale document changes through code review. I'm afraid it adds up very, very quickly to a lot of wasted resources.
It doesn't work as well as you might wish. X11 has, historically, not compressed well for remote graphical interactions. The problem is compounded when running X sessions over a VPN to a remote environment, and using the graphical environment hosted inside the GUI to the virtual machine manager.
I've found vim very useful when memory or resource squeezed. Emacs's tendency to leave temporary scattered copies of large edited files is particularly dangerous when trying to salvage database backups on a cramped partition. But the tendency of vi users to confuse their personal display settings for indentation with the actual text in the files they edit has caused enormous problems. This especially happens they submit code following indentations standards that exist only in the .vimrc somebody has been mailing around for the last six years, and which no other group in the world uses, and then they complain when the authors of the original software regularize the whitespace on submitted patches.
Merely speaking a language may not be interesting enough to rekindle your interest and encourage growth. But there hundreds of good open source and freeware projects that would benefit from your insight and experience. CPAN, github, GNU, and Apache all host projects that may interest you nad have relevance to your work, without being part of your daily grind. Perhaps you'd enjoy a chance to refine some familiar old project?
It can almost be done by rebasing and replacing a central master. But this deteriotes the history and interaction with _every single cloned repository_ and is generally noticed quite quickly. The validity of all the potentially independent, separate cloned repositories is one of the very useful, decentralized powers of git.
Such as https://www.bitbucket.com/ which has an interestingly different business model. Github represents, in technology, a great step forward from the older https://sourceforge.net/. But this sounds like they have some serious employee relationship and morale problems to deal with.
> Without death, there's no evolution possible
Unless a species can modify its own biology, or the evolution of _technology_ or of _societies_ can be included. And in practice, it is: evolution is not just DNA biology, it involves entire ecosystems and behavior that are effective, but contained nowhere within the biology of a species.
I was not referring to the insertion of false data: I was referring to its insistence on doing a local cache, appartnely not part of the system DNS, _after_ switching DNS servers and potentially needing new DNS answers due to being in a different DNS "view". This is common enough practice with various proxy and load balancer configurations, to have a different DNS record on the internal network than on the external network.
Inserting false DNS records is a whole _different_ security risk, one that is an ongoing problem that web browsers can do little about. In theory, it should be noticeable via SSL certificate failures. In practice, there are so many stolen "CA" or "Certificate Authority" records in the wild that can be used to sign arbitrary SSL certificates that we canot rely on a fake website not having a signed, apparently legitimate SSL certificate even for a corporate site like a bank. So poisoned DNS records, which is the problem you are referring to, are a much larger risk than one might expect. And the browsers can do _nothing_ about this. It's a failure of the SSL architecture.
Oh, my. No, I'm afraid it's "greatest common denominator". it's the standard mathematical "term of art" for the largest number that can that two, or more, numbers can be divided by, with no remainder. "Greatest common factor" may be more clear to you, but failure to use the correct label should be a troubling sign with anyone you expect to do mathematical work.
The tendency of Firefox to preserve its own DNS cach means I cannot use it when hopping from VPN to VPN with split DNS running. unless I configure and install my _own_ local DNS server to auto-reconfigure every time I activate a VPN. I'm afraid it's become unusable for me for real work and testing when switching from internal to external website access as I debug network and configuration issues: it's the only browser that fails this way.
As an older programmer, I'm fond of some very good quality, older tools such as "webmin". Not all the modules added to it are excellent, but its very clean and very flexible for many core system utilities such as BIND based DNS. It's also much more robust than any configuration tool that relies on a separate, manually configured back end database.
I'm afraid that this usually means two entirely different interfaces, with overlapping features and writing to the same configurations. That is more than twice the development cost, since they involve distinct styles and expertise to develop or manage and the _negotiation_ between the two styles is an added cost. And it makes debugging more than twice as expensive, since tests have to involve both sets of interfaces and switching between them.
This is prohibitively expensive: the result is usually that the "plain" interface lacks critical features that are only available in the more sophisticated tool.
That's a fascinating guess. It's not a feature I've personally used. Although yes, the Cisco configurations and the Cisco _clients_ do tend to have a horrible morass of undocumented options.
> since that puts an upper bound on human ingenuity
I'm saying to master the components you need before planning the project. Simply saying "human ingenuity will solve that" is like saying "we'll make the software secure when we're ready to publish". It is, itself, guaranteeing project failure.
> The stars will die out long before entropy becomes relevant here.
Do you understand what "entropy" is? Even using the purely thermodynamic definition, there is a very real energy cost for preserving complete coherence of the DNA sequence. Certainly, as a dynamic chemical system, the "entropy" present in the DNA molecule itself and its complex environment prohibit the likelihood of perfect sequence coherence over lengthy times. The result of such failures is degradation. One of the most unfortunate results of such losses is, frankly, cancer.
Frankly, for significant extension of human life, a general cancer cure is of critical importance. Or the accumulation of small risk factors is going to accumulate to a near certainty of dangerous cancers, of many different sorts. We already see this among our older citizens!
>> especially since scar tissue accumulates and regrowth of neural tissue has never been mastered.
> Neither which is a permanent problem.
Given the lack of progress for both issues, there's little concrete reason to assume they are _not_ permanent issues.
> I assure you that companies like Google, Facebook, Twitter, Microsoft and their relation ALL do the EXACT SAME THING.
Not from my direct experience with several of those companies. They install wldcard certificates, signed by one of the commercial root authorities, not their own root certificates.
Do you have any direct experience or instances to show that _any_ major software vendor or software service does this?
> I work at a school.
Clearly, not in IT or network security. A root CA is not for "filtering". A proxy or firewall is for filtering, and a root CA doesn't help with that other than to automatically authorize the certificates presented by the proxy. A root CA is for signing other certificates so that they are accepted without the manual intervention of the student or visitor using the "Bring-Your-Own-Device".
It may have conceivably been installed under a sealed warrant for "national security" reasons. Much like the Patriot Act in the USA demands silent cooperation with warrant free investigations of unconstitutional scope, I'm sure that UK governmental agencies have also demanded and received cooperation with dangerously excessive search orders.
A "private boarding school" implies that the school might well have international students, or students with parents are of economic and political power. Is it feasible to contact _those_ students and their families, to explain what the school has been doing without their knowledge? A similar scandal involving the use of webcams on student laptops to photograph them at home was reported on Slashdot, http://en.wikipedia.org/wiki/R....
Doing Main-In-The-Middle attacks with the root CA and SSL certificates signed by that root CA is only one of the risks. Once certificates signed by that CA are accepted, they're permanently usable for fake websites, for main-in-the-middle attacks with proxies using those faked SSL certificates for designated websites, and for replacing ordinary SSL signed software or update packages with fake, rootkitted packages. The list of subtler security issues is longer: those are only a few of the leading problems.
I'd be profoundly concerned that the school is not competent to protect their CA, or other certificates that have already been signed with it. Since they've already demonstrated ignorance among some personnel of their own security practices, and unwillingness to communicate truthfully with students, I'd assume that they've never properly secured the host or network on which they've stored their CA. Unless they have _erased_ the private CA and all copies of it, it can be misused at anytime in the future, especially on the school's own network.
Moreover, if possible before the CA is erased, _all_ of those certificates already signed with the CA need to be revoked, and replaced with a correctly signed one. That's quite expensive, at roughly $200 USD/certificate/year. You can buy get the certificates more cheaply, but that estimate includes the technical time to go replace the old certificates.
What you're describing is a sometimes hidden form of the "Not Invented Here" problem, where some deficit in a working software stack is discarded for theoretical, not production reasons. In this case, it can be guaranteed to be unstable because it would replace whatever production grade audio tool is already working with one written in house, requiring maintenance, and _likely vulnerable to the same SELinux problems_.
> Telomere breakdown, and cell deterioration is one of our biggest issues
And if we stopped entropy, cell detioration would not occur. It's about as likely, I'm afraid. Telomeres are a molecular _answer_ to DNA deterioration, preenting the connection of one DNA molecule to another at the end points. And some types of system damage are cumulative, especially since scar tissue accumulates and regrowth of neural tissue has never been mastered.
I remember these designs. They absolutely stripped the tread off the rear wheels within a few hundred miles of using them, and kept the local bike shops in serious business replacing wheels. Not tires: the wheels.
Federal offices are merely an example. I know businesses that absolutely refuse to put their mailing address or the location of their offices or their business office telephone number on their website or in local telephone listings, to avoid physical spam or having angry customers show up at their door. And in the business world, just try to find the street address of the ISP data centers near you.
Google Maps has been a reliable way for me to actually _find_ the data center I need to visit, when the staff of the company I'm dealing with don't know the street address, and the IT person is in the data center and their cell phone can't work from inside there.
I'm afraid that I was unclear. Worrying about how this will hide valid "NXDOMAIN" results is pointless, since thoe have already been hijacked by many ISP's DNS proxy servers and instead return the ISP's desired advertising page. They can also be redirected to far, far more dangerous services, sich as Phishing websites or mail servers to accept misaddressed email.
It's spelled NXDOMAIN, by the way.
NXDOMAIN has not been a reliable response for invalid DNS queries for roughly 15 years. Look into the history of the "*.com" DNS entry in Verisign's root servers for the .com domain, which were returning valid Verisign owned hosts. And look carefully at the DNS proxy setups of major home network services, which often return their domain sales web pages instead of "NXDOMAIN" for invalid DNS entries.
Given that the data has _already_ been corrupted, this seems a reasonable attempt to broaden what is now done with "example.com". It also has the benefit that it's not auto-activated in default Kerberos configurations, a bit of behavior that genuinely alarms me in most default Kerberos setups and which few configuration tools have the ability to remove.