Batch saving files in FrameMaker 11

I just wrote a Framemaker ExtendScript (Javascript dialect) to save all files in a Framemaker book as MIF.



Specifically, MIF7 in my case (hardwired, needs to be configurable).



Needed it because I use Frame 10-11-12, whereas the techwriter who cleans up my English uses Frame 7.   Frame 7 doesn't run on my PC, at least not reliably, whereas her Windows XP PC cannot run a modern FrameMaker.   And the company runs FrameMaker 7 on an old Sun box that is more than 100x slower than a modern PC for many common actions.



So we are stuck converting files between Framemaker binary .f, format and MIF7.



Doing this by hand for 315 files in just one of our architecture specs is a real pain.  I felt a weight lift off my chest when I ran this for the first time.



--



The script only saves .fm files in the .book.  It does not (yet) find all text inset files.



--



Next on the wishlist: batchify this fm2mif and mif2fm, so that Makefiles, etc., can use it.



I do not know how to invoke FrameMaker on a PC with useful command line arguments specifying, e.g. file or book, and command to run.



Can fake things by changing setup files.  That's fragile.



Perhaps can have ExtendScript parse a text file, and evaluate that.  Risky.

Byzantine Password Managers

Password managers like LastPass (https://lastpass.com/) - convenient. But risky. ISO a Byzantine password management system. No single password manager storing the actual passwords. Instead, if Byzantine-3, then any 2 have enough information to obtain stored passwords in plaintext - but no single password manager does. Probably requires a Javascript client that accesses each of the Byzantine set, and combines their responses. What does this protect against? => Having one (or a few) of the Byzantine set hacked. But not having a quorum hacked. => The bad guys hacked a sub-quorum do not have the ability to log in. => The bad guys cannot DOS you by giving you bogus data. What does it not protect against? X=> doesn't protect against the most likely security flaw: having the user computer, e.g. web browser, hacked. Wait... about that... ?=> Two+ factor. Clients running on two or more devices, e.g. PC and cell phone. No client knows the actual password? Unfortunately, this would require the folks who require passwords to get involved. Beyond 2 factor. "Dynamic two factor"? (But I guess this is what the security amulet idea is all about.)

goto fail - goto not the problem, lack of else was

ImperialViolet - Apple's SSL/TLS bug:

'via Blog this'
Apple's "goto fail" bug is notorious. Much discussion about how proper unit testing would have found it. Let alone code reviews. (I hope this bug is going into the pattern database for lint-like tools.)

While goto-less programming might have avoided the problem, I think it would have done so at the cost of readability.

I think it is more interesting that the problem might have been avoided if ELSE had been used.  The code in question is really a cascaded set of IFs, where each is only done if all earlier have succeeded - but it is expressed as independent statements.

The buggy code:

static OSStatus
SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams,
                                 uint8_t *signature, UInt16 signatureLen)
{
 OSStatus        err;
 ...

 if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
  goto fail;
 if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
  goto fail;
  goto fail;
 if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
  goto fail;
  ...

fail:
 SSLFreeBuffer(&signedHashes);
 SSLFreeBuffer(&hashCtx);
 return err;
}

Rewritten so that the relationship between the cascaded IFs is visible and automatically checked. Minor liberty in capitalizing the ELSEs.

if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0) 
  goto fail;
ELSE if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
  goto fail;
  goto fail;
ELSE if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
  goto fail;
  ...
ELSE
  ...
  return 0;

Plus, I am sure that somebody has pointed out that an assert would also have caught the error.

fail:
  assert(err != 0 );
  SSLFreeBuffer(&signedHashes);
  SSLFreeBuffer(&hashCtx);
  return err;