NTP users are strongly urged to take immediate action to ensure that their NTP daemons are not susceptible to being used in distributed denial-of-service (DDoS) attacks. Please also take this opportunity to defeat denial-of-service attacks by implementing Ingress and Egress filtering through BCP38.

ntp-4.2.8p15 was released on 23 June 2020. It addresses 1 medium-severity security issue in ntpd, and provides 13 non-security bugfixes over 4.2.8p13.

Please see the NTP Security Notice for vulnerability and mitigation details.

---

Are you using Autokey in production? If so, please contact Harlan - he's got some questions for you.

Most of what follows can also be found under bk helptool terms. I just wanted to restructure it slightly for the audience I'm writing it for but, yes, I shamelessly stole chunks of this straight from the helptool page. I've ordered these definitions so that it makes sense to read them top down. (If you think there are commands that would be useful to run in order to better understand any of these definitions, feel free to add them.)

package, repository: A package represents a logical collection of files, like the Linux 2.6.8 kernel package, or the gcc-3.3.4 package. A repository represents an instance of that package, so a single package might be represented by numerous repositories out there, each with its own developer making his own changes. A repository is also sometimes called a work space or a clone.

identity: There are two kinds of identities. Each BK package has a unique package identity that is the same across all copies or instances of that package, while each repository has its own repository identity, regardless of its underlying package. You can list each of these identities with:

 $ bk id           # package identity
 $ bk id -r        # repository identity

SCCS: Source Code Control System, the underlying source code management (SCM) system used to keep track of the actual files and directories and their revision history. When you first clone a repository, chances are none of the files will be visible in their regular locations, but their internal SCCS files will be in their respective SCCS/ directories. To work with a file, you'd normally check it out or edit it.

gfile, sfile: A gfile (or "gotten" file) is the regular file name that would be used by a developer, like foo.c, while the sfile (or sometimes s.file) is the underlying SCCS file representing that file and all of its revision history, which you would find in the corresponding file SCCS/s.foo.c. If you wanted to examine or do some work on a file, you'd first have to check out or edit that file, which would create the gfile from its corresponding sfile. If you really want to see a directory's sfiles without actually checking anything out, just run:

 $ ls SCCS

in that directory.

extras: This generally refers to files in your repository that aren't under any revision control; that is, perhaps temporary junk that you may have created but have no intention of checking in. You can see these files with the command:

 $ bk extras

check out, edit: When you want to either examine or make changes to a file, you would normally check out or edit the sfile to get the corresponding gfile. It seems traditional to say that, if you just want to examine a file in read-only mode, you'd "check it out", while if you want to get the file in writable form to make changes to it, you'd talk of "editing" the file, but this difference in terminology is not cast in stone.

diff: The word diff is generally used to describe the difference between a file's sfile, and its checked out gfile. If you edit a file, make some changes and just save those changes to your current gfile form of that file, that file now has a diff. Note that this is before you check any changes back in. If you pop back into the editor, make more changes and save the file again, the diff for that file will now be larger, but it will still be considered as one diff, not two smaller diffs.

To see all of the current diffs in a repo, just type:

 $ bk -r diffs

check in: Once you've decided that you like the changes you've made to a file and saved from the editor, you can check it in, which will update the corresponding sfile in the SCCS/ directory and increment its revision number. Once you do that, the file is no longer considered to have a "diff" since your edited version agrees with the sfile in the SCCS/ directory. (Note carefully that just checking in a file doesn't mean you're committing to it just yet. That comes later. Keep reading.)

revision, delta: When you check in an updated copy of a file, this increments its revision number. You might also refer to any given revision of a file as a delta of that file, but that depends on the context. The word "delta" might refer to a specific revision of a file, or it might be used to represent the difference between a version of a file and its previous version. Again, it's all based on the context.

If you want a quick summary of a file's revision history, just type something like:

 $ bk prs README

and see the helptool page for bk prs for more options.

pending: This term refers to files that have been checked out, edited and modified and saved, and checked in, but not yet committed to a changeset. If you want to see everything that's currently pending, just type:

 $ bk pending

commit: After you edit possibly multiple files, make changes and check those files back in, you can commit all of those changes, which generates a new changeset. As we've already mentioned, you can get a list of all of your currently-uncommitted but checked-in changes with:

 $ bk pending

cset, changeset, ChangeSet: A changeset (also abbreviated cset) is a collection of files and their revisions that are logically related, and that represent the unit of repository modification that is exchanged between repositories (well, that and patches). Normally, you'd group a collection of file revisions into a changeset because they represent a single, functional change or improvement to the repository, like "Upgraded USB support to 2.0".

Note that it's possible for a file to have more than one revision in a single changeset. If you edited file foo.c, figured you were done with it and checked it in, it might get a new revision number of, say, 1.11. If you realize you forgot something in that file, re-edited it, saved it and checked the newer version in, it would get the revision number 1.12. If you then committed that file as part of a new changeset, that changeset would contain both revisions of that file.

If you want some brief information on your repo's changesets, try any of the following:

 $ bk changes -r+ -nd:REV:              # latest changeset revision number
 $ bk changes -r+                       # general purpose of last changeset
 $ bk changes -r<rev number>            # general purpose of a given changeset

Finally, the changeset history of a repository is stored in the file named ChangeSet.

key: A key is a unique, unchanging identifier for a version of a file that can be used anywhere a regular version or revision number for that file can be used. You can extract the key for a particular file revision in one of two ways, depending on the key format that you want; for example:

 $ bk prs -hr<rev> -nd:KEY: Makefile         # human readable
 $ bk prs -hr<rev> -nd:MD5KEY: Makefile      # not so human readable

NOTE: The bk helptool terms page shows a different version of the above commands:

 $ bk -R prs -hr<rev> -nd:KEY: Makefile
 $ bk -R prs -hr<rev> -nd:MD5KEY: Makefile

The -R option means that the command will be run relative to the root of the repository, which is probably not what you want if you happen to be in a subdirectory somewhere.

tag, symbol: A tag or symbolic name can be given to any revision of your repository, so you can associate a meaningful name with some snapshot of the repo. You can get a list of all of the tags in your current repo with:

 $ bk tags

which is just a short form for bk changes -t, actually.