Returning to the Moon: Launchpad Security Penetration Exercise

There is an unexpected reward for moving source-code management of my Hexo-generated blogging to git and GitHub.  GitHub provides dependency analysis of node.js projects.  I receive an automated email about one dependency of my hexo-spanner code.

GitHub analysis of the hexo-spanner package.lock.json package reveals that UglifyJS2, depended on by Swig, has a known security vulnerability cured in a later version.

The uglify-js package is only depended on by Swig.  That places it in isolated use in confined ways under hexo.  I (will) do nothing to rely on Swig in any other manner.    I’ve dismissed the alert with explanation that the reported dependency is not exposed to the exploit.  I also created an issue on the hexo GitHub wondering if Swig can be deprecated from use in Hexo, since Swig is no longer maintained.

All in all, an amazing reward of my transposition of the Spanner Wingnut source-code management to GitHub.

Posted in Blog Development, blogs, Git, Hexo, Security Vulnerabilities, Spanner Wingnut, Toolcraft | Tagged , , , , | 21 Comments

Returning to the Moon: Tracking Network Modernization

John Stevenson has tips on bringing a hexo-authoring folder, and its themes, under Git for source control management.  I followed the first of those suggestions, although the GitHub Desktop client made the work much simpler than using Git command-line operations.

The GitHub Desktop client is used to put the local hexo-authoring folder, nfoCentrale/spanner/ under Git.   This works just fine for making local repositories that are not clones of repositories published on the internet anywhere (just yet).

When a new local repository is established, there is no association as the clone of any cloud-based repository at GitHub or elsewhere.  The first few commits establish configuration conditions on what is managed, with .gitignore and .gitattributes

First steps include adding .gitattributes and changing the .gitignore file already there, thanks to Hexo Install.   The .gitignore change has the spanner/themes sub-folder be ignored.

The landscape theme being used and customized is added into a separate local repository.

In bringing an existing folder under Git, its name must be used.  Later, the matching GitHub repository can be given a different name when the local one is published.

For each local repository, the existing material is checked-in, identifying different blocks in single commits.  Already-customized items are checked-in individually with messages that reflect their status.

When a git repository is initiated over an already-populated folder-tree, the contents show up as new uncommitted material.  These can be selectively committed to Git in a way that provides an useful initial history.

When all of the material to be tracked and change-managed is committed to one of the repositories, it is published.   Since there is no remote already, GitHub Desktop offers an opportunity to create a GitHub project. 

When the local repository has all of the pre-existing content committed, it can be published to GitHub.  The Publish action invites creation of a new GitHup repository.  The connection is automatic thereafter.

Once published, synchronization is used in the usual way for uploading the local commits to the GitHub repository.

Although the theme and the overall authoring folder are managed as separate GitHub repositories, there is no treatment as forks of any original sources.   Cherry-picking from updates to upstream sources will be reconciled when the time comes.  Similarly, if there is desire to contribute and push changes upstream, forks will be made for that purpose.

Posted in Blog Development, blogs, Golden Geek, Spanner Wingnut, Toolcraft | Tagged , , , , , | 2 Comments

Returning to the Moon: Instrumentation Coms Latency Bottlenecks

In the 2017-10-18 post, “So Close, Yet an FTP Too Far?”, Direct Publishing and then Backup and Source-Code Management are identified as critical for proof-of-concept and subsequent refinement into production practices.  

  • Direct publishing is now working smoothly, with some scale issues remaining to reconcile beyond Reducing Countdown Holds.  That’s a next-order problem.
  • Source-Code Management and Preservation is in dismal shape.  The first-choice solution impedes rapid maintenance and discourages easy authoring.

Blogging Collides with Web Deployment

There’s great appeal in the ancient Microsoft Site Server model for developing, deploying, and backing-up web sites.  The nfoCentrale Web Deployment Pillars are centered on that model.  It works well by virtue of integration between Microsoft Front Page, IIS with FrontPage extensions, and Visual Source Safe (VSS).  VSS also makes it painless to have a staging mirror that can be synchronized with hosted web sites via FTP.   In the nfoCentrale approach, the hosted-site carries static pages and all design-time operations happen with the FrontPage-IIS development server setup.

With node.js for static blog development and generation, the FTP synchronization has been made effortless.  The VSS integration is a terrible bottleneck.

The VSS client (top) distinguishes checked-out files but does not show files not ever checked-in.  The file explorer (lower image) does not indicate anything about source-control status, although checked-in and not checked-out files are set to read-only

There are several pain points.

  • The VSS client (top part of image) does not indicate whether the working folder has files that have not ever been checked in.
  • The checked-in files are set to read-only in the working folder.
  • That a file is checked out (red check mark in the top view) does not mean it has changed, only that it is checked out.
  • The File Explorer view (lower part of image) reveals nothing about the VSS status of the files.

The coordination between the file folders and VSS requires too much attention in this situation.  Also, it is annoying to start to edit a page and learn it is read-only and the VSS client must be opened and the page checked-out.  When inspired to spontaneously initiate and test new posts, diversions to check material in and out tend to be neglected, avoiding the distraction.

Superiority of Git Support

Even for solo development usage, Git support carries the day.

The GitHub client identifies changed and new material and provides check boxes for inclusion in a given commit message.  The file explorer (inset), supplemented by TortoiseGIT, shows where there are modified materials and indicates what other files are already committed.

There are several advantages from switching to Git for the hexo-authoring use case.

  • The GitHub desktop client for Windows supports any Git clone on the desktop, whether the origin is on GitHub or not.
  • The (clone) working-folder files are not locked and can be edited any time.
  • On checking for source-code changes to preserve, the GitHub client provides an easy identification of changed and new files, allowing them to be selectively committed with appropriate commit messages.
  • With TortoiseGit installed, the Windows file explorer (shown in the inset) identifies the committed, changed, and new status on each non-ignored file.  The change/current status is reflected up the file-folder hierarchy of the clone.

Make-Over Challenges

That Hexo and hexo-installable themes/plugins are all developed on GitHub creates a challenge.   That means parts of an authoring folder

  • will be cloned from forks of different GitHub repositories
  • will preserve any customizations in my own forks
  • will have changes to the originals cherry-picked into the customized code as appropriate
  • will be integrated into Git and GitHub in a manner that avoids update-collision/-conflict nightmares

There is some nervousness around this.  Inspiration will be taken from suggestions of John Stevenson’s account of his customization of a hexo-generated blog, including alignment of theme integration.

Steady As We Go

For this change, I will check everything out of VSS, then conduct the Git-integration ceremonies.  If all goes well, I can provide some precautionary VSS tracking by check-in with files kept checked out or (eventually) deleting the VSS project.

This contingency situation is precisely why I preserve version history in managed files themselves, so that change information outlives presence under a particular source-control system and survives when the files are encountered by other means.  The VSS history will not travel to Git, but the annotations in the files will.

Posted in Blog Development, blogs, Golden Geek, Spanner Wingnut, Toolcraft | Tagged , , , , , | Leave a comment

Returning to the Moon: Reducing Countdown Holds

The Hexo-generated Spanner Wingnut experimental blog is now much easier to author and to publish.   Essential features are operating and a series of “unit test” posts are now underway.   Customization is continuing based on unit test results and check-lists for feature adjustments.   Arrival at a complete, stabilized blog is in sight.  All of the customizations will be transposed into to restorations of additional blogs.

Significant improvement has been made for easy posting of new articles and content.  I finally found a one-click deploy that was a critical goal identified in Mercury Retro on 2017-10-21.   Now there’s near-effortless posting and maintenance, demonstrated by the level of activity at Spanner Wingnut.

The solution to one-click publishing is by one-way synchronization using the WS_FTP Pro ftpsync utility and a predefined control file.

The A2wingnut.ctlo file specifies settings for file syncrhonizaation between spanner/public and BlunderDome/wingnut.  Only new and changed files are uploaded to the site and nothing else on the site is touched.

I keep the A2wingnut.ctl file in the spanner/ authoring folder, along with a short-cut, A2wingSync,  that will automatically perform synchronization (a kind of push) of only new/changed files to the web server.

The synchronization is controlled by A2winnut.ctl using the A2wingSync shortcut in the spanner/ folder.  The A2wingnut.log is produced following a synchronization.

The shortcut has been edited to perform ftpsync with A2wingnut.ctl specified on the command line.  The operation is performed in the spanner/ folder.  

The shortcut is established by first creating it at the ftpsync.exe program location, copying it to spanner/, and then adjusting the properties for custom operation.

The A2wingSync shortcut in spanner/ is adjusted to take A2wingnut.ctl as a parameter and to start in the spanner/ folder

The hexo generate operation does not set any ERRORLEVEL when it encounters problems.  Instead of adding synchronization to my tidygen.bat script, I use a separate command line to initiate a desired synchronization.

When tidygen concludes successfully and the changes are OK to synchronize, a "start" command is used to initiate the ftpsync link.

The start command is needed in order to run ftpsync as a Windows application.  It is not a console application.  After the start, a separate window opens in which the ftpsync is performed and can be observed.  A log is also produced.

This part works just fine.  I am encouraged to create and post regularly now.

Posted in Blog Development, blogs, Golden Geek, Spanner Wingnut, Toolcraft | Tagged , , | Leave a comment

Returning to the Moon: Guidance Calibration

With images working on the Spanner Wingnut blog, there is now regular posting there.  I have begun adapting test pages from the hexo-theme-unit-test source.  I don’t use the recommended procedure though.  Instead, I have cloned the unit-test repository to its own location, and I cherry-pick the test pages from there.

Once I have transposed a test page into the spanner authoring folders, I first confirm that the test cases are all satisfied.  Then I make further adjustments that may be needed to satisfy my feature/formatting requirements.  That happened, for example, where I simplified formatting of block quotes.

I continue to find bread crumbs leading to where changes can be made by following the theme customization examples of John Stevenson.

In my case, I improved treatment of block quotes by removing features deep in themes/landscape/source/css/_partial/article.styl

Under the article.styl for blockquote CSS, the font-family, font-size, and text-align properties are commented out so that the prevailing formatting work.  Only the margin change is retained, introducing the indentation of margins

Test page adjustments reflect the successful change.

Additions to the blockquote paragraph confirm propler line wrap of the indented block and also that multiple block-indent levels are handled

I treat block “quote” and block-indentation as the same.  The simplified formatting allows for that and preserves multiple block indentation as well.  When the special case of quotation is intended, I will signal that by other means.

As the Spanner Wingnut blog generation improves, more about these customization will appear there, with no need for further attention on a separate blog.  It is not quite soup yet.

Posted in Blog Development, Golden Geek, Spanner Wingnut, Toolcraft | Tagged , , | Leave a comment

Returning to the Moon: Over-Tightened Wingnuts

The Spanner Wingnut blog is now being published with Hexo-generated content.  That version is the current default.  Technically, the Returning to the Moon topic could continue there.  that is the appropriate place for preservation of all the findings of my experimental efforts.

Of all the features and provisions that require more preparation, the one blocker against full use of Spanner Wingnut is incorporation of images

A benchmark case for this just fell into my lap.   It is, to my amazement, about wingnut.  In In the Ghost Recon Wildlands game, Orcmid's character just earned the "wingnut" helmet while playing solo at Tier solo play of the Tier One campaign level in Tom Clancy’s Ghost Recon Wildlands, I just earned the Wingnut Helmet.   No kidding.

My Orcmid character will not wear that helmet.  It reminds me of a haircut style ending in the early Beatles era.   One 1970s friend who sported it earned Hugh J. Rundle’s appellation as “Mrs. Morse’s son, Helmet.”

Acquiring that helmet brought reminiscence of all of that.

It also provides a test formatting for the screen-captured image.  I’ll endeavor to replicate something like these in my next round of updates to the Spanner Wingnut blog.

The Orcmid character in the standard campaign progression has different headgear and scarf.  Oddly, the hat is very similar to one that I own and wear.  The Ghost Recon naming of this hat is “Boonie.”  Hmm.  Mine was a gift, it has a great chin strap for windy Seattle weather, and it came pre-distressed, although I often roll it up and stuff it in a sleeve.

The floppier hat that orcmid prefers in the game is known as the Boonie.  It is favored because of one that the player wears regularly in real life

Here, Orcmid also sports his favorite assault rifle, with grenade launcher at the ready.  This definitely goes with the 100% tactical playing style that I have developed for near-close combat.  At other times, perhaps the most dangerous weaponry of this Ghost involves his explosive-equipped drone and precision sniping by his able team.

Standard for Orcmid is a sniper rifle and grey hair with poneytail.  In the Fallen Ghosts campaign, a Western hat similar to one the player also owns

In the Fallen Ghosts campaign feature of Ghost Recon Wildlands, it was necessary to design a new character.  I did what I could to have this Orcmid match the existing one, except for the Western hat.  I would enjoy serious gray hair, but this is the closest gray provided.  The pony tail helps though.

Posted in Blog Development, Golden Geek, Spanner Wingnut, Toolcraft, Uncategorized | Tagged , , , , | Leave a comment

Returning to the Moon: Viewport Glare Reduction

Continuing to mine advice by John Stevenson, I adapt his changing of banner images to have legible white-on-dark titles with no “white-out” glare.   The default banner (shown at Mapping Probe) also takes too much space.

File spanner/themes/landscape/source/css/images/banner.jpg  is the source for the banner image.  It is a 1920 by 1200 pixel image presented with 300 pixel height.  I cropped away the bottom, producing short-banner.jpg as a 1920 by 600 image of  starscape only.  Strangely, the only tool I had for accomplishing this change reliably is my screen-capture utility, HyperSnap 7.29, an unexpected bonus.

The short banner is the top half of the original banner image provided by the Hexo default theme, landscape

Theme processing will copy this image to spanner/public/css/images/short-banner.jpg.  Posts and pages will access it at the uploaded Spanner Wingnut css/images subfolder.

To use the new banner and size, the spanner/source/css/_variables.styl file is adjusted.

The theme source/css/ _variables.styl file banner change is by changing banner-height to 150px and banner-url to images/short-banner.jpg

This is sufficient to have a smaller banner with clear lettering.

The blog title "Spanner Wingnut's Muddleware Lab" and the subtitle are now clear with white type on a mostly-black background.

With this success, other adjustments come to mind, and they will be made in further adjustment of the banner, now that it is under control.

Posted in Blog Development, blogs, Golden Geek, Spanner Wingnut, Toolcraft | Tagged , , | Leave a comment