• John Walker posted an update in the group Group logo of UpdatesUpdates 1 month, 1 week ago

    2019 May 10

    Committed the WordPress 5.2 update (Build 299) and published
    Builds 298 and 299 to GitHub.
    When I checked in Build 299 to GitHub, it reported:
        remote: GitHub found 1 vulnerability on
            Fourmilab/'s default branch (1 high).
    The URL they give you to view the alert does not work unless
    you're logged in to your GitHub account.  Tracking it down, this
    is the vulnerability detected:
    which turns out to be in a file belonging to the
    "twentynineteen" theme which we don't use.  The specific
    vulnerability is that in the list of dependencies for the theme
    they allow a version of NodeJS tar which has a remote file
    overwrite vulnerability.
    Well, after two attempts to patch the tar version in the file:
    (Builds 300 and 301), I just added the pile of crap to
    ~/.gitignore.  That did it (Build 302).
    Restored the original version of:
    backing out my earlier futile changes to patch the tar problem.
    Even though the file is in .gitignore, Git marked it as a change
    and wanted me to commit it (Build 303).  I published the change
    on GitHub.
    After two hours of wasted time, enormous frustration, and Builds
    304 through 306, all in vain, I finally figured out that adding
    a file to .gitignore isn't sufficient to keep Git from looking
    at it, and GitHub gigging it for a vulnerability.  After adding
    the file to .gitignore, you have to remove it from Git tracking
        git rm -r --cached wp-content/themes/twentynineteen/package-lock.json
    Note that this does not delete the local file; it just purges it
    from the Git repository.  It will now show up as a "deleted"
    item in "git status".  When you then commit the change (Build
    307), it will be gone from the local repository.  You can then
    "git sync" to publish on GitHub and the alert will go away.
    Now, I could finally restore the original:
    from the 5.2 distribution, replacing the version I futilely
    tried to hack to make the alert go away.  Since the theme isn't
    used, there's no functional reason to do this, but restoring the
    stock file will eliminate confusion as to where the changes came
    from when we next install an update to WordPress.  Since the
    file has now been removed from the repository and added to
    .gitignore, the change was not tracked by Git and generated no
    Build number.
    From this experience, it appears the Microsoftisation of GitHub
    is well underway.
    Updated the repository mirror on Juno through Build 307.
    Updated the Subscribe to Comments Reloaded plug-in to version
    190510.  This is a minor update which adds a new option to allow
    subscriptions on regular posts but not Pages and custom post
    types.  I left this at the default, which allows subscriptions
    on all kinds of what WordPress considers "posts", which is how
    it behaved before.  They also increased the compatibility claim
    up to 5.2.  We have no local code in this plug-in.  I looked at
    the configuration page and everything looks all right.  sThe
    Manage subscriptions page also looks as it should be. This is
    probably all right, but I'll let it run a few hours before
    committing the changes.
    Stopped the Ratburger Test instance.  We're done with
    pre-release testing of WordPress 5.2 and the production server
    has already begun to diverge from the state of this system, so
    there's no reason to keep it running and pay the CPU costs it
    incurs.  I'll detach and delete its /server volume in a day or
    two to economise on storage fees.
    Several hours later, there have been no apparent problems with
    the Subscribe to Comments Reloaded plug-in update so I committed
    the changes (Build 308) and published them on GitHub.