1. Release Notes for 3.6.3

GBS/VW version 8.5

GBS/VA version 5.4.6

For more details on supported GBS and client Smalltalk platforms and requirements, see the GemBuilder for Smalltalk Installation Guide for that version of GBS.

Locking

An AwsDataKey may be in a locked or unlocked state. A newly created key is unlocked. The key can be explicitly locked, and is automatically locked when the creating session logs out. If it is saved to disk, it is saved in the locked state.

If a key is locked, it cannot be used to encrypt or decrypt data. Before it can be used, it must be unlocked using an instance of AwsCredentials that can authenticate the CMK that is contained in the AwsDataKey.

The following methods are available:

AwsDataKey >> lock

AwsDataKey >> unlockWithAwsCredentials: anAwsCredentials

AwsDataKey >> isLocked

AwsDataKey >> isUnlocked

Encryption/decryption

Encryption and decryption done by sending a request to the (unlocked) AwsDataKey.

Encryption is performed using the AES-OCB authenticated encryption, which ensures data that has been successfully decrypted has not been modified in any way.

AwsDataKey >> encrypt: srcByteObj into: destByteObj
Uses the receiver to encrypt srcByteObj and stores the resulting encrypted bytes into destByteObj as a Base64 string. srcByteObj must be a non-empty byte object. destByteObj must be a mutable byte object; any contents will be overwritten.

AwsDataKey >> encryptAndErase: srcByteObj into: destByteObj
Encrypt srcByteObj, erasing all data in srcByteObj, and store the resulting encrypted bytes into destByteObj as a Base64 string. srcByteObj must be a non-empty byte object. destByteObj must be a mutable byte object; any contents will be overwritten.

AwsDataKey >> decrypt: srcByteObj into: destByteObj
Uses the receiver to decrypt srcByteObj and stores the resulting decrypted bytes into destByteObj. srcByteObj must be a non-empty byte object containing Base64 encrypted text. destByteObj must be an mutable byte object.; any contents will be overwritten.

Key rotation

AWS KMS provides the ability to do key rotation for improved security. You may update an instance of AwsDataKey with a new CMS using the following method. To ensure that the change will be committed if successful, this method write locks the receiver and commits the session, so this requires that there are no uncommitted changes.

AwsDataKey >> changeCmsKeyIdTo: newCmsKeyId usingNewCredentials: newCreds
Atomically update the receiver to use newCmsKeyId, which is accessed with newCreds in a single operation, and commit. The receiver must be unlocked, the session must not have uncommitted changes, and the session must be able to write lock the receiver.

Making a copy of a key

An AwsDataKey can be copied. The copy of an AwsDataKey has the same locked state as the original, and can be unlocked using the same credentials.

AwsDataKey >> copy
Answer a new object which is a deep copy of the receiver. The lock state of the receiver is preserved when copied, i.e.: if the receiver is unlocked the resulting copy will also be unlocked.

Key equality

AwsDataKey objects are considered equal (=) if they have the same CMK (Customer Managed Key) string and the same encrypted key string. Lock state does not affect equality.

System clock

AWS request signing uses the system clock to include a timestamp in the signature. For this reason, AWS methods may fail if the system clock time is incorrect.

Security Implications of this change

If your application contains sensitive data that should not be visible to unauthorized individuals, there are several administrative requirements that become more immediately visible with this feature. These requirements are not new; in previous releases plain text data may be visible within the bytes of a non-secured backups.

• All backups should be secured, using Repository>>secureFullBackup* methods; or access to/file permissions of backup files must be strictly controlled. Note that, while not officially supported, a backup from a previous release of GemStone can be restored into v3.6.3.
• Only GemStone userProfiles for users with full authorization to see all data in the repository should be granted FileControl privilege. This privilege allows you to make programmatic backups as well as restore and perform transaction log operations.

New Restore Methods

The following instance methods have been added to Repository, which are variants of existing methods with the additional keyword newSystemUserPassword:.

restoreFromBackup:newSystemUserPassword: 

restoreFromBackups:newSystemUserPassword: 

restoreFromSecureBackup:privateDecryptionKey:

passphrase:newSystemUserPassword:

restoreFromSecureBackup:privateDecryptionKey:passphraseFile:

newSystemUserPassword: 

restoreFromSecureBackups:privateDecryptionKey:passphrase:

newSystemUserPassword:

restoreFromSecureBackups:scavengePagesWithPercentFree:

privateDecryptionKey:passphrase:newSystemUserPassword:

Previously, the simple secure backup method accepting a passphrase file did not exist; this method, and the variation with the additional keyword, have also been added:

restoreFromSecureBackups:privateDecryptionKey:passphraseFile: 

restoreFromSecureBackups:privateDecryptionKey:passphraseFile:

newSystemUserPassword:

The argument to the newSystemUserPassword: keyword is a String meeting the same restrictions as to the password: method. Following the restore, login as SystemUser requires this password string.

Post-restore login as SystemUser

When restoring using the methods that allow you to specify a new SystemUser password, you must be logged in as SystemUser. This restores the objects in the backup; but the new SystemUser password is saved in encrypted form in the root page state of the repository. The restore itself does not update SystemUser’s UserProfile object.

It is strongly recommended to log in again as SystemUser after the commitRestore (if you are in full transaction logging mode), or after the restore is complete (in partial logging mode). This login will cause the SystemUser password to be updated in SystemUser’s UserProfile.

• If you make a programmatic backup before the SystemUser login (post-commitRestore), the backup will not contain the password defined by newSystemUserPassword:; since backup backs up the UserProfile data. If this second backup is restored (without using newSystemUserPassword:) the SystemUser password will be the one in the original backup, not the one specified by the first restore using newSystemUserPassword:.
• It is disallowed to explicitly set SystemUser’s password (using e.g. password:), when logged in as a user other than SystemUser, after a restore specifying a new SystemUser password but without any later (post-commitRestore) logins as SystemUser.

Shutting down the stone does not affect the SystemUser password state in the root page; after restart, the SystemUser password remains as set by newSystemUserPassword:.

GsTestResult did not distinguish errors and failures

GsTestResult treated errors and failures as the same, which led to miscounting of errors and of failures. SUnit supports defects, which includes both errors and failures.

GsTestResult now tracks defects, as well as supporting the superclass errors and failures. The instance variable defects has been added to GsTestResult.

Note that the TestCase >> defects returns results sorted with all errors followed by all failures, while GsTestCase >> defects returns both errors and failures in order of occurrence.

The methods for logging failures has been corrected; the methods:

GsTestResult >> logFailure: aTestCase

GsTestResult >> failureLogFile

have been removed, and are replaced by new methods:

GsTestResult >> logDefect: aTestCase

GsTestResult >> defectLogFile

And these methods now write to a log file named SUnitDefects.log, rather than SUnitFailures.log

GsTestResult stored printStrings rather than instances

GsTestResult stored printStrings of the GsTestCase instance run, rather than the instances themselves. This is more space efficient, but sending methods such as isError: to these objects returned incorrect results (always false).

The following methods, inherited from TestResult, are now disallowed for GsTestResult:

isError:

isFailure:

isPassed: