Introduction

In episode 2, Bill designed a database for his dependency manager to enable Go developers to have reproducible,durable and secure builds. This database will house the hash value for each of the dependencies stored. During runtime, these hash values are compared with the dependencies a user has locally. Bill’s tool makes this comparison to make sure the user has the right version of the dependency. Each team making use of Bill’s dependency manager will have access to its database, however, his database lacked any means to reliably perform audits.

In this video, Bill will update the database structure of the dependency manager. This update consists of adding a field to store the hash value of the previous record. This field will enable Bill’s database to chain (interlink) records together. With these new changes, teams can re-compute the hash values and detect a change in the database. This process can be described as the “cryptographic audit trail.” He does this to ensure that the database is auditable, and in turn, promote trust for his dependency manager.

Things you will learn in this video

• Storing the hash of a record’s previous entry chains the records together.
• By comparing the stored hash of a previous record with your computed hash of the previous record you can reliably determine if the database was changed.
• The genesis record will not store a “previous hash.”

Video