I have for some time been unable to make changes to /etc/hosts stick; each time I reboot, the file is reverting to its previous state.
It appears that Cisco AnyConnect is at fault, it keeps private copy of the hosts file at /etc/hosts.ac and overwrites /etc/hosts each time it starts (which in my case is simply each time I reboot). The solution is simply to make any changes to both files at the same time.
(thanks)
From time to time friends who are planning visits to Sydney ask what’s worth seeing. Here is my incomplete, idiosyncratic, entirely unrepresentative list of places, and things worth seeing/doing:
At least 10 other places came to mind while writing this but the above should give you a flavour.
The good people at Salesforce appear to feel that disabling login autocomplete is a sensible default. They’re probably correct, but for those who use Firefox with a master password set, having Firefox keep the password encrypted is a better bet than storing it in a plain text file.
I’ve just uploaded a Greasemonkey script which reverts the behaviour to the browser’s default, which in turn allows the password manager to do its work. Per the warning on the page:
Use of this script is only sensible if your browser’s password manager has a master password set.
If it doesn’t, your password manager will store your password in an easy-to-recover form, which you probably don’t want.
There is a trick to using Greasemonkey for this purpose. The obvious approach:
document.getElementById('username').removeAttribute('value');
document.getElementById('password').removeAttribute('autocomplete');
will fail because Greasemonkey scripts usually run after the password manager has scanned the page, meaning that Salesforce’s code to prevent autocompletion will already have taken effect before the script gets involved. The way around this is to use “@run-at document-start” to run the script before the HTML parser runs and to then perform the relevant changes in a DOMContentLoaded event listener:
// @run-at document-start
document.addEventListener("DOMContentLoaded", function(e)
{
document.getElementById('username').removeAttribute('value');
document.getElementById('password').removeAttribute('autocomplete');
}, true);
It happens that an event listener added this way will complete its work before the password manager runs, meaning that it can do all of the things that it does (store credentials securely encrypted, store multiple credentials if you have multiple accounts, notice and remember password changes, delete no-longer-used credentials with a single keystroke, …) as designed.
My use of Greasemonkey for this purpose was inspired by Steve King‘s Auto-login to Salesforce. (Thank you!)
Put not-to-be-web-accessible static files under WEB-INF. If you need a real path – e.g. to pass outside Java – and your container unpacks to a filesystem then get it as:
request.getServletContext().getRealPath("/WEB-INF/file")
or, if stream access within Java is acceptable (this works even if the .war isn’t unpacked to a filesystem):
request.getServletContext().getResourceAsStream("/WEB-INF/file")
For temporary files, use:
File tempDir = (File) request.getServletContext().getAttribute(ServletContext.TEMPDIR);
File tempFile = File.createTempFile("prefix-", ".tmp", tempDir);
$ curl https://example.com/ curl: (35) error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert internal error $
This is apparently on openssl bug. Tomcat can be configured to work around this in /etc/tomcat7/server.xml by restricting the available cipher list:
<Connector protocol="HTTP/1.1" SSLEnabled="true" ... ciphers="SSL_RSA_WITH_RC4_128_SHA"/>
SECURITY NOTE: I’ve not researched the cause or workaround in any depth, explore the background before using this in a high-risk environment.
(thanks)
Astonishingly, JDK‘s keytool includes the ability to generate a private key, but not the ability to [directly] import one. A workaround is to use OpenSSL‘s PKCS12 tool to create a PKCS12 “keystore” for keytool to import:
openssl pkcs12 -export -passout pass:password -in example.com.crt -inkey example.com.key -out example.com.pkcs12 -name example.com -CAfile ca_chain.crt -caname root keytool -importkeystore -deststorepass password -destkeypass password -destkeystore example.com.keystore -srckeystore example.com.pkcs12 -srcstoretype PKCS12 -srcstorepass password -alias example.com rm example.com.pkcs12 keytool -import -alias ca_chain -keystore example.com.keystore -storepass password -trustcacerts -file ca_chain.crt
This requires:
This produces:
The latter can be used in Tomcat‘s server.xml as:
<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true" maxThreads="150" scheme="https" secure="true" clientAuth="false" sslProtocol="TLS" keystoreFile="example.com.keystore" keystorePass="password" keyAlias="example.com"/>
The issues dealt with along the way included:
java.io.IOException: SSL configuration is invalid due to No available certificate or key corresponds to the SSL cipher suites which are enabled.
because I had not specified keyAlias (I think) and:
java.io.IOException: Alias name example.com does not identify a key entry
because I had the no private key in the keystore, despite having the relevant certificate.
An old favourite, dug up for Gina to help explain to a steady stream of would-be sponsors her feelings on sponsorship for Business Rocks. This seems like a good problem to have!
A management consultant was on holiday in a small fishing village, he watched one afternoon as a small fishing boat docked at the quayside. Seeing the high quality of the fish, the consultant asked the fisherman how long he had spent out at sea that day.
“A few hours.” answered the fisherman.
“Then, why didn’t you stay out all day and catch more?” asked the consultant.
The fisherman told him that his small catch was enough to feed him and his family.
The business guru asked, “So what do you do the rest of the time?”
“I sleep late, make love to my wife, play with my kids and have an afternoon’s rest in my garden hammock. In the evenings, I go into the social club to see my friends, have a couple of beers, shoot some pool, and sing a few songs….. I have a full and happy life.” replied the fisherman.
The consultant ventured, “I have an MBA and work for a top management consultancy – I think, in fact I know I can help you…… You should start by fishing much longer every day and recruit some help. You can then sell the additional fish you catch and with the extra revenue, you can buy a bigger boat. A larger boat will allow you to catch more and expand your business to two or three boats until you have the largest fleet on the island. Instead of selling your fish at harbour, you can negotiate directly with the major fish distributors and perhaps open your own plant. You can then leave this village and move your entire operation to the mainland and build a huge company.
“How long would that take?” asked the fisherman.
“Done right, no more than ten years.” replied the consultant.
“And then what?” asked the fisherman.
“After that? You could acquire other companies, grow a massive organisation and finally float or sell your company and make millions!”
“Millions? Wow? And after that?” queried the fisherman.
“After that you’ll be able to retire, move to the islands, sleep late, make love to your wife, play with your grandkids and have an afternoon’s rest. In the evenings, you could shoot the breeze with friends and have a full and happy life”
The consultant looked at the fisherman, the fisherman stared back.
The consultant now works as a fisherman.
(thanks)
Accepting email over IPv6 risks providing spammers with an easy entrance point because IP-address blocklisting is not likely to be viable for an address space as large as IPv6’s. The need to continue to accept email over IPv4 for the indefinite future provides a useful safety valve in that a receiver can push messages offered over IPv6 whose validity is uncertain back to the existing IPv4 service, thereby reducing the dependence upon – or even eliminating the need for – IPv6-address blocklists.
To take advantage of this a receiver needs whitelists (manually maintained, automatically generated, user addressbooks, provided by a reputation data provider, …) and the ability to test and act on domain authentication (SPF, DKIM, DMARC, …) during the SMTP conversation. Any message failing authentication, or passing authentication but not matching a whitelist, need merely be given a temporary failure (4xx) response code. A well-behaved MTA (e.g. non-spammer) receiving 4xx responses will work through the receiver’s listed MXs until it finds one that gives an authoritative (2xx/5xx) response.
The argument that email receivers will need to accept email over IPv4 for the indefinite future is well-known and almost certainly correct, however organisations may find themselves wanting to accept email over IPv6 as well for at least two reasons:
The approach described here can be used in two different ways:
In either case the benefit is the same: a production-use-ready approach for accepting at least some email over IPv6 with a safe fallback to IPv4 for the rest.
Ideally all of the relevant authentication mechanisms (SPF, DKIM and DMARC) can be processed and acted on during the SMTP transaction, but this approach can be adopted even if this is only true for SPF; the result will simply be that some of the email that could have been accepted over IPv6 will instead be pushed to IPv4.
Most types of whitelist data can be applied:
In general, content-based anti-spam filters need not be used for messages which have passed any of the above. A particular exception is malware checking: clearly, it is not desirable to deliver malware even if it’s from a source that’s known to behave well, e.g. because someone’s PC has become infected and is emailing exploits or phish to each of the user’s contacts.
Weaker signals might also be used to decide to accept a message subject to content-based anti-spam filters not detecting a problem. These include:
These are all a little less robust than competent whitelisting, and may have to be tried on a “sacrificial lamb” basis, however as with the broad strategy of building on an IPv4 fallback, this is easier and safer to do than it was in an IPv4-only universe.
Astute readers will notice that what I am describing is an implementation of the Aspen Framework that Meng Wong described in his Sender Authentication Whitepaper 8 years (!) ago. I’d suggest that:
It is conceivable that this will eventually be the beginning of a migration strategy, that over time so much email will be able to be accepted on a “we know something good about this message” (rather than a “we know nothing bad about this message” basis) that it will become viable to reject outright any email about which nothing good is known. I don’t actually expect that this will be the case, but also suspect that so much will change during the parallel running of delivery-to-MX over IPv4 and IPv6 that it’s not practical to predict how delivery-to-MX over IPv4 might be phased out. The important observation would appear to be that this approach provides a production-use-ready way to start.
Additional thoughts:
Relevant disclosure: I work for TrustSphere which supplies software that can be used for whitelist automation (TrustVault) and reputation data that can be used as described above (TrustCloud). On re-reading it occurs to me that this post makes a case for using TrustSphere’s products. I’d like to clarify that it is not the case that I believe the above (or wrote it without believing it!) because I work for TrustSphere but, rather, than I work for TrustSphere because I believe the above. See also my comments on this from a few years ago.
Update 2012-12-17:
The rise of ‘cloud’ services and the rapid uptake of smartphones has created an unexplored – and perhaps quite large – niche for social software outside the control of advertiser-funded social network services (Facebook et al). While smartphone power and connectivity constraints make pure peer-to-peer social software on smartphones impractical, it is possible to construct a hybrid approach which moves much of the heavy lifting to undifferentiated/non-sticky services in the cloud while retaining owner/user control.
By contrast:
The options are:
| Will purchase, install, connect, maintain and physically secure device at residence. Will maintain server software. | Will maintain server software. | Won’t maintain server software. Willing to pay $/time/inconvenience for increased freedom. | Will only use phone. | ||
|---|---|---|---|---|---|
| Concerned about governmental/law enforcement interference. | FreedomBox | ||||
| Concerned about control of data by others. | FreedomBox on a virtual server. | P2P app with non-sticky service help. | |||
| Concerned about advertising-funded sites skewed incentives and/or constant unpleasant changing of the rules. | Diaspora on a friend’s server. App.net. |
||||
| Not concerned. | |||||
To understand where the additional niche exists, imagine that smartphones generally had:
In this environment, it would be possible to produce social network software that ran only on phones and talked only to peers on other phones. Unfortunately on current and likely future mobile phone networks, three of those things are always false and the fourth is usually false. It is possible, however, to use a certain class of network-hosted service as force-multipliers for an app running on a phone to give it capabilities [almost] as good as those four things, and to do so without giving control away:
This is not strictly ‘serverless’, but it introduces the use of hosted services in a way which (a) doesn’t cede control to an advertiser-funded social network service and (b) doesn’t require that the owner/user be willing/able to take on the administration of a virtual/real server.
An important objection in both cases is that identifiers in domains controlled by others are still required (host names for the storage-services’ web-servers in the first case, nicknames/usernames in the second case), however it is not necessary for any of these to take the traditional role of an email address as a personal identifier known to the user’s contacts, they are merely communication endpoints and if the means of stating which ones to use is automated, use of multiple endpoints of multiple types can be sustained. This does require a less obvious means of representing identity, but note for comparison that until recently Facebook users used nothing analogous to an email address, users were located by their name and their proximity to others in the social graph. Each user has a unique identification number, but in general only developers need to know this. The recent addition of email addresses doesn’t materially change the means of locating people, it simply happens that Facebook has added email support. The same identifier-independence is true for the scheme proposed here: the use and propagation of multiple communication endpoints can happen out of the sight of owners/users.
Another important concern is that if too many people start using this approach, IM networks are more likely to start blocking this kind of use. I’d suggest – as a hypothetical example – that FreedomBox-like projects may provide a way to address this: in many cases someone owning a FreedomBox is likely to be willing to have their friends use the device to deal with real-time notification needs. The FreedomBox XMPP/Jabber server could perhaps be enhanced to allow the option for certificate-based authentication by any of the owner’s friends without requiring registration formalities, meaning that this approach could extend non-advertiser-controlled social networking software to a much, much larger audience than those who are willing to run a [virtual] FreedomBox themselves. Not everyone knows someone who’s willing to run their own server, but the pool of people who do know such a person is dozens or hundreds of times as large as the pool of people who are able to do so themselves, meaning that if this approach is of interest to FreedomBox-like projects then there may be an opportunity here to reach a much larger audience much sooner.
This post is not yet a call to action, more a partial statement of vision, I intend to write several more posts over the next few weeks/months fleshing this idea out.
An interesting point from Tag Clouds That Manage Data in the Cloud:
Information may or may not want to be free, but services that manage free information want to be valuable.
This seems like a useful split to bear in mind.
Raz's Blog 