I installed Microsoft’s Security Essentials today.
Their security analysts have a rather direct way of receiving unknown files to analyse: shortly after the first scan, a dialogue popped up:
Neat. Presumably developers creating .exe files need to turn this off eventually…
Bash now (v4.1.5) does special parser trickery with the argument to =~. The easiest way to work with this is to put the regular expression into its own environment variable. e.g. to get the SMTP transaction ID from an exim log
line='2010-07-20 00:06:08 L5TE67-000BPA-56 <= nagios@nms2.example H=(mail.example) [10.10.10.10] P=esmtp S=22696 id=20100719170632.362CC12EDB7@nms2.example T="NMS Alert - Disk-D on Server2 is WARNING (111)" from <nagios@nms2.example> for admin@example'
re='^....-..-.. ..:..:.. (......-......-..) '
[[ $line =~ $re ]] && echo ${BASH_REMATCH[1]}
This is peculiar. If true, it indicates some surprisingly careless security engineering.
Decades ago I worked with Unisys EFTPOS terminals (the type you see at supermarket checkouts). These were of a type which had the PIN-entry keypad on the end of a cable, while the card slot was in the main body of the unit. A perceived risk was that someone could tamper with the unit and install sniffing hardware/software to learn the user’s PIN. To thwart this, the keypads included a DES key stored in supercap-backed-SRAM for encrypting the PIN before it ever left the keypad (the main body of the unit did not have this key; the computer inside it never had access to the plaintext PIN) and a tamper switch in the keypad which would short out the SRAM’s power pins the instant the keypad’s case was opened, thereby destroying its copy of the DES key and rendering the keypad permanently useless if opened.
It would seem that the same approach could readily be applied to terminals embedded in gasoline/petrol pumps; the card-scanner and/or PIN keypad should be in sealed units which are rendered permanently inoperative (by instantly losing/destroying a stored key) if opened.
Naturally, this is just one of dozens of vulnerabilities that such a device has; decisions about which counter-measures to employ are always about trade-offs. Nonetheless, this seems an odd choice.
Because I couldn’t find it in Microsoft’s online help, even after I knew the function name:
=mround(amount, 10)
(thanks)
A little piece of California, 2 hours from Manila
vfs objects = full_audit
full_audit:success = mkdir rename unlink rmdir
full_audit:failure = none
The instructions (libopensync-0.39/README) suggest:
mkdir build cd build cmake -DCMAKE_INSTALL_PREFIX=$prefix /path/to/opensync/source/ make make install
I have found the following to be more useful. Most importantly, the instructions above imply, incorrectly, that you can use them with an install directory of your choosing (as e.g. in ./configure –prefix in other projects). In fact, you need to use PKG_CONFIG_PATH to cause information about “installed” packages to be generated.
mkdir build cd build PKG_CONFIG_PATH=$(realpath ../../install)/lib/pkgconfig/ cmake -DCMAKE_INSTALL_PREFIX=$(realpath ../../install) $(realpath ..) make make install
I found some notes on this lying around; my recollection is that this process worked; I can’t recall whose notes they are :-(
+cgdcont=1,"ip","sunsurf"
UPDATE: The importance of this is that I’d like to take photos with my phone while travelling in The Philippines and Spain shortly and simply post them here, without messing about with logging in to anything. I did test this when the feature was announced and found that it didn’t work, it now does. (cue: Twilight Zone theme) I’ve just noticed that my two tests were separated by almost exactly a year…
Delicious/raz3