I have long version controlled my home directory. CVS. Git. Hg.
Unfortunately, they diverged. Divergence happens naturally with CVS. You have to work hard to get git and hg to diverge, but I did.
Now I want to merge the diverged home directories back together. Preserving the history if possible, from the different VCS. Sometimes just merging fikes.
==
Today: I want to start merging a diverged linux tree, from a flash drive, with my working tree (which started off on cygwin).
I created a new hg repo, created a branch on it, and then imported the tree to be merged.
I pulled/pushed this with my main home hg repo. Had to use -f, to force unrelated repos to be together.
Now I have a single repo, with my current working (cygwin derived, homedir, and a not working linux homedir, on different branches. The former n the default branch.
That's okay. Not so bad. A single history object(although I have kept separate working space trees.)
===
Now I want to merge, a file or a few files at a time.
E.g. copy the README from the linux branch to the default working derived from cygwin branch.
AAARGH!!!! Hg doesn't handle partials... neither merges, not copies, nor... Hg just plain really wants to lose track, not make doing this activity easy.
Monday, January 02, 2012
Missing X fonts
Like http://ubuntuforums.org/showthread.php?p=11544410, I was getting errors such as
(Except that I was getting the errors, not on a fresh Ubintu install, but when trying to use a fairly new machine at work, with what is probably a newer version of redHat.)
The post I quote fixed things by setting ~/.Xdefaultsto
And then doing xrdb -merge ~/.Xdefaults
Warning: Cannot convert string "-*-courier-medium-r-*-*-*-120-*-*-*-*-iso8859-*" to type FontStruct Warning: Cannot convert string "-*-helvetica-medium-r-*--*-120-*-*-*-*-iso8859-1" to type FontStruct
(Except that I was getting the errors, not on a fresh Ubintu install, but when trying to use a fairly new machine at work, with what is probably a newer version of redHat.)
The post I quote fixed things by setting ~/.Xdefaultsto
emacs*font: 7x14
And then doing xrdb -merge ~/.Xdefaults
On my end, I found that neither 7x14 nor courier worked. But font "fixed" did.
An Amusing and Frustrating Anecdote about Google 2-step Verification
I like Google 2-step verification - in which you normally log in with a password, but where, if you are logging in from a new machine, etc., you "verify" your login by entering a one time code sent to your cell phone by voice or text.
I liked the idea as soon as I heard of it, but was reluctant to sign up for it because I frequently use my laptop computer in places where cell phones don't work - e.g. at the coast in Oregon, and, most recently, at my new house in Portland's hills.
I was scared that I might end up unable to log into my gmail, lacking cell phone.
Nevertheless, after reading rave reviews, I finally gave in and signed up for 2-step verification. And have continued to use my laptop fairly successfully at the coast without cell phone coverage, since normally it has already been verified.
But over New Year's I finally tripped up:
Because of a bug with googlevoiceplugin.exe (a new copy was spawned every time I started Chrome: I had 52 copies when I realized what was happening) I uninstalled and reinstalled the plugin, and eventually Chrome itself 9since the plugin would not uninstall while Chrome was running).
So when I tried to log back into gmail on Chrome, 2-step verification was required. But my cell phone doesn't work at the coast.
Now, Google 2-step verification has a backup phone numbeer, which can be a land line using voice. But remember that I said the new house that I have just bought also lacks cell phone coverage? Guess what my backup phone was?
And Google 2-step verification does have a backup set of one time passwords. I know I printed them out for my wallet. Umm... got a new wallet, recently, smaller, and did not carry it over.
So now the fun begins: I don't have to drive too far to receive a text message. I'll try to login, get Google to send the verification code, drive to where I can receive a text message, drive back.
Try #1: got the message. Actually, got several verification code messages. Drive back, they don't work. Perhaps I got confused, and typed the wrong verification code into the wrong box.
Try #2: I realize that I may not need to drive the few miles to the next town. The mountain next to my house may have reception. Drive up it, yep, received the text message. Drive down... Nope, didn't work.
I'm beginning to think there is a timeout.
Try #3: Repeat. An hour or so later, since I had to charge my cell phone - the battery drains quickly in this area. But this time, I can't get any bars on top of the mountain. The fog has moved in and the sun has set, affecting signal strength.
So I drive to the next town. Signal, but no text message. I wait ten minutes, start driving back... and the message arrives while I am driving. Have I mentioned that AT&T Wireless has occasionally taken >4 hours to deliver text messages? 20 minutes is par for the course.
Doesn't work. I', getting pretty sure there is a timeout.
Try #4: This time I request the verification code, drive out, and call back to ask my wife to enter it.
However, my laptop has gone into power saving mode, and although I disabled the power-on password, by wife doesn't realize what has happened, and tries to use the second computer sitting next to the laptop that needs the verification code.
2 days later we try again: my wife drives to the next town with my cell phone. She calls me back when she gets a signal. I request the verification code. She waits a minute or so - fortunately, this morning AT&T is fast - and reads it back to me over the phone. I enter the code, and all is well.
I change my backup hone number to the landline at the coast. Realizing that this will needto be changed again when I get back to Portland.
And I write the backup passwords down by hand.
Monday, December 12, 2011
Powering up multiple displays on Windows 7 - lots of flashing :-(
I have 4 external 1920x1200 displays connected to my Lenovo Thinkpad X220 Tablet PC, via Diamond DisplayLink based USB adapters.
When I power the besat up, not just cold start, but also, most annoyingly, warm start, from Hibernate (Suspend to Disk) or Suspwend (to RAM) power down modes, it engages in excessive flashing.
The screen blanks and redisplays 15 times!!!
Quite annoying.
Continuing http://andyglew.blogspot.com/2011/12/multiple-displays-on-windows-7-good-but.html
When I power the besat up, not just cold start, but also, most annoyingly, warm start, from Hibernate (Suspend to Disk) or Suspwend (to RAM) power down modes, it engages in excessive flashing.
The screen blanks and redisplays 15 times!!!
Quite annoying.
Continuing http://andyglew.blogspot.com/2011/12/multiple-displays-on-windows-7-good-but.html
Sunday, December 11, 2011
Lifehack: Binder Clips help Debug Chistmas Lights
Fixing Christmas lights today.
Figured out the binary search approach - e.g. as described by http://www.squidoo.com/howto-fix-broken-christmas-lights#module12970984.
My own embellishment: I find it hard to track where I am in checking the Christmas lights, and/or strand continuity. Even leaving empty sockets behind doesn't help that much, since the empty sockets are hard to see. And since I have a small work space, so had to fold the string of lights back on itself 3 times.
So I marked my position with binder clips. I happened to have at least 4 colours of binder clip. I used four clips to dedfine the boundaries of the interval where I was searching for a duff lightbulb - two clibs at each boundary. Two clips at each boundary because, given the folding ofg the string of lights, it became hard to tell which direction was towards the end, and which inside the interval. So I used two colours of binder clip at each end.
Figured out the binary search approach - e.g. as described by http://www.squidoo.com/howto-fix-broken-christmas-lights#module12970984.
My own embellishment: I find it hard to track where I am in checking the Christmas lights, and/or strand continuity. Even leaving empty sockets behind doesn't help that much, since the empty sockets are hard to see. And since I have a small work space, so had to fold the string of lights back on itself 3 times.
So I marked my position with binder clips. I happened to have at least 4 colours of binder clip. I used four clips to dedfine the boundaries of the interval where I was searching for a duff lightbulb - two clibs at each boundary. Two clips at each boundary because, given the folding ofg the string of lights, it became hard to tell which direction was towards the end, and which inside the interval. So I used two colours of binder clip at each end.
Thursday, December 08, 2011
A Modest 1 bit Proposal about Quotification - making the Default Easy
Listening to an old "Security Now" podcast while doing my morning stretches.
Leo Laporte's TWIT website was hacked, and Steve Gibson, the Security Guy, says "Any time you are soliciting user input, there is a risk of malicious input somehow tricking the backend and executing that input, when it is meant to be, you know, benign [input data, like] user name and password.".
This is typical of the classic SQL injection hack, and, indeed, of any hack where the attacker is able to inject scripting code and fool the backend into executing it. Typically by embedding quotes or the like in the input string.
(For that matter, Steve's description also applies to binary injection via buffer overflow. But we won't go there; this page will talk only about non-buffer-overflow attacks, sijnce we have elsewhere described our agenda for preventing buffer overflow attacks.)
Say that you are talking user input like NAME, and are somehow using it to create an SQL or other language command, like "SELECT FIELDLIST FROM TABLE WHERE NAME = '$NAME' ". But now the attacker, instead of providing a nicely formed string like "John Doe", provides instead something like "anything' OR 'x' = 'x ". (I added spaces between the single and double quotes for readability.) I.e. the user provides a string that contains quotes in the target language - not the language where the query string is composed, but a language further along. So the query string becomes "SELECT FIELDLIST FROM TABLE WHERE NAME = 'anything' OR 'x' = 'x' ". And now the query matches any row in the table. (http://www.unixwiz.net/techtips/sql-injection.html provides examples, as does wikip[edia.).
The general solution to this is "quotification": take the user input, and either delete or quote anything that looks like a quote in the target language:. E.g. transform the attacker's string "anything' OR 'x' = 'x " into either "anything OR x = x " or "anything\' OR \'x\' = \'x ".
The problem with deleting stuff from the user string is that sometimes the user is supposed to have quotelike things. Consider names like "O'Toole". Or consider prioviding, e.g. via cut and paste, Chinese unicode names in an application whose original programmer was English, but where the system is otherwise capable of displaying Chinese. It is a pity if the barrier to internationalizaion is the "security" code scattered throughout your application that santizes user input. Worse, that is the sort of code that might get fixed by somebody who fixing internationalization problems who doesn't understand the security issues
The problem with quotifiying stuff is that it is hard. It is not just a case, for you Perl afficionadoes, of doing s/'/\/g - what about input strings that already have \\' inside them? And so on.
But the real problem, applicable to both deleting and quotification strategies, is that the code doing the user input sanitization does not necessarily know the syntax of all of the languages downstream. It may know that there is SQL along the way - but it may not know that somebody has just added a special filter that looks for French quotes, << and >>. Etc. Not just special symbols: I have defined sublanguages where QuOtE and EnDqUoTe were the quotes.
The security code may know the syntax at the time the sanitization code was written. But the downstream processing may have changed. The syntax of the language may have been extended, in a new revision of the SQL or Perl or ... . (I found a bug like that last year.)
The problem is that the user input santization code is trying to transform user input from strings that may be unsafe, to strings that are guaranteed to be safe forever and ever, no matter what revisions are made to the language, etc. The problem is that the default for character strings is that ANY CHARCATER MAY BE PART OF A COMMAND unless specially quoted.
We need to change this default. Here is my moldest proposal:
Let us define a character set whereby there is a special bit free in all characters. And whereby, if that special bit is set, it is guaranteed by ANY REASONABLE LANGUAGE that no character with that special bit set will be part of any command or language syntax like a quote symbol.
We should strongly suggest, that the visual display for the characters with and without the special bit set is the same. Or at least, the same in most situations - in others you may want to distinguish them, e.g., by shading.
.
If you are using something like BNF to describe your language, then it might be:
ORDINARY_CHARACTER ::== 'A' | 'B' | ...
TAINTED_CHARACTER ::== 1'A' | 1'B' | ...
POSSIBLY_TAINTED_CHARACTER ::= ORDINARY_CHARACTER | TAINTED_CHARACTER
where I am using the syntax 1'A' to describe a single character literal. with the special bit set.
STRING_LITERAL := QUOTED_STRING | TAINTED_STRING
TAINTED_STRING ::= TAINTED_CHARACTER+
QUOTED_STRING ::= " CHARACTER* "
(Actually, I am not sure whether a quoted string should be the abnove, or
QUOTED_STRING ::= " POSSIBLY_TAINTED_CHARACTER* "
)
Leo Laporte's TWIT website was hacked, and Steve Gibson, the Security Guy, says "Any time you are soliciting user input, there is a risk of malicious input somehow tricking the backend and executing that input, when it is meant to be, you know, benign [input data, like] user name and password.".
This is typical of the classic SQL injection hack, and, indeed, of any hack where the attacker is able to inject scripting code and fool the backend into executing it. Typically by embedding quotes or the like in the input string.
(For that matter, Steve's description also applies to binary injection via buffer overflow. But we won't go there; this page will talk only about non-buffer-overflow attacks, sijnce we have elsewhere described our agenda for preventing buffer overflow attacks.)
Say that you are talking user input like NAME, and are somehow using it to create an SQL or other language command, like "SELECT FIELDLIST FROM TABLE WHERE NAME = '$NAME' ". But now the attacker, instead of providing a nicely formed string like "John Doe", provides instead something like "anything' OR 'x' = 'x ". (I added spaces between the single and double quotes for readability.) I.e. the user provides a string that contains quotes in the target language - not the language where the query string is composed, but a language further along. So the query string becomes "SELECT FIELDLIST FROM TABLE WHERE NAME = 'anything' OR 'x' = 'x' ". And now the query matches any row in the table. (http://www.unixwiz.net/techtips/sql-injection.html provides examples, as does wikip[edia.).
The general solution to this is "quotification": take the user input, and either delete or quote anything that looks like a quote in the target language:. E.g. transform the attacker's string "anything' OR 'x' = 'x " into either "anything OR x = x " or "anything\' OR \'x\' = \'x ".
The problem with deleting stuff from the user string is that sometimes the user is supposed to have quotelike things. Consider names like "O'Toole". Or consider prioviding, e.g. via cut and paste, Chinese unicode names in an application whose original programmer was English, but where the system is otherwise capable of displaying Chinese. It is a pity if the barrier to internationalizaion is the "security" code scattered throughout your application that santizes user input. Worse, that is the sort of code that might get fixed by somebody who fixing internationalization problems who doesn't understand the security issues
The problem with quotifiying stuff is that it is hard. It is not just a case, for you Perl afficionadoes, of doing s/'/\/g - what about input strings that already have \\' inside them? And so on.
But the real problem, applicable to both deleting and quotification strategies, is that the code doing the user input sanitization does not necessarily know the syntax of all of the languages downstream. It may know that there is SQL along the way - but it may not know that somebody has just added a special filter that looks for French quotes, << and >>. Etc. Not just special symbols: I have defined sublanguages where QuOtE and EnDqUoTe were the quotes.
The security code may know the syntax at the time the sanitization code was written. But the downstream processing may have changed. The syntax of the language may have been extended, in a new revision of the SQL or Perl or ... . (I found a bug like that last year.)
The problem is that the user input santization code is trying to transform user input from strings that may be unsafe, to strings that are guaranteed to be safe forever and ever, no matter what revisions are made to the language, etc. The problem is that the default for character strings is that ANY CHARCATER MAY BE PART OF A COMMAND unless specially quoted.
We need to change this default. Here is my moldest proposal:
Let us define a character set whereby there is a special bit free in all characters. And whereby, if that special bit is set, it is guaranteed by ANY REASONABLE LANGUAGE that no character with that special bit set will be part of any command or language syntax like a quote symbol.
We should strongly suggest, that the visual display for the characters with and without the special bit set is the same. Or at least, the same in most situations - in others you may want to distinguish them, e.g., by shading.
.
If you are using something like BNF to describe your language, then it might be:
ORDINARY_CHARACTER ::== 'A' | 'B' | ...
TAINTED_CHARACTER ::== 1'A' | 1'B' | ...
POSSIBLY_TAINTED_CHARACTER ::= ORDINARY_CHARACTER | TAINTED_CHARACTER
where I am using the syntax 1'A' to describe a single character literal. with the special bit set.
STRING_LITERAL := QUOTED_STRING | TAINTED_STRING
TAINTED_STRING ::= TAINTED_CHARACTER+
QUOTED_STRING ::= " CHARACTER* "
(Actually, I am not sure whether a quoted string should be the abnove, or
QUOTED_STRING ::= " POSSIBLY_TAINTED_CHARACTER* "
)
And we require that the only place where the possibly tainted characters with the tainted bit set are ONLY permitted in strings. Nowhere else in the language. Not in keywords, symbols, operators....
Then we just have to ensure that all of our input routines set the special bit. If you really need to form operators, the programmer can untaint the data expliocitly. Btter to have to untaint explicitly in a few p[laces, than to have to quotify correctly in all places.
Perhaps better to make taintimg the default. To flip the polarity of the special bit. And to require that language syntax, keywords, etcv., be set only if the special bit is set.
This is just the well known taint or poison propagation strategy. Exposed to programming language syntax definitions.
I have elsewhere espoused taking advantage of extensible XML syntax for programming languages. This is similar, although orthogonal.
- wi8ki'ed at http://wiki.andy.glew.ca/wiki/A_Modest_1_bit_Proposal_about_Quotification_-_making_the_Default_Easy
- as well as posted on my blog
Wednesday, December 07, 2011
Multiple Displays on Windows 7... Good, but...
I love the DisplayLink USB display adapters that let my piddling little tablet PC drive 4 1920x1200 external monitors.
However, many, umm, irregularities happen with Windows 7 support and/or the display or device drivers.
Earlier today, and for weeks if not months, I have been able ti have 5 displays - my laptop/tablet PC's built in LCD, and my 4 external displays.
However, I went into hibernation while travelling from home to work (where I did not use the PC) and back to home again.
And when I woke up, I cannot get my laptop built in display to work, when the external displays are plugged. Sure, it works when they are not plugged in; but when they are plugged in, the laptop built in display gets "blackened" in the Orientation box.
Just yet another Windows 7 strangeness.
However, many, umm, irregularities happen with Windows 7 support and/or the display or device drivers.
Earlier today, and for weeks if not months, I have been able ti have 5 displays - my laptop/tablet PC's built in LCD, and my 4 external displays.
However, I went into hibernation while travelling from home to work (where I did not use the PC) and back to home again.
And when I woke up, I cannot get my laptop built in display to work, when the external displays are plugged. Sure, it works when they are not plugged in; but when they are plugged in, the laptop built in display gets "blackened" in the Orientation box.
Just yet another Windows 7 strangeness.
Subscribe to:
Posts (Atom)