ISO27001:2013 Certified Supplier

How Seriously Do We Take Information Security?

We’re an IT company: you’d expect us to say that we take information security seriously – and we do.

But We Would Say That, Wouldn’t We?

We don’t think you should have to take our word for it, so back in 2014 we embarked upon the journey to certification under ISO27001:2013, the Information Security standard. We examined, refined, documented and tested every aspect of Information Security, both within Tiger Computing and extending to how we manage and support our clients’ systems. In May 2015, we put ourselves to the test. We were independently audited and were assessed and certified as meeting the requirements of ISO27001:2013.

What Does This Mean For You?

It means that you can rest assured that we take Information Security seriously; that we will continue to refine and improve our Information Security policies; and that we will be independently audited annually to confirm that we are maintaining the required high standards of ISO27001:2013.

What’s Next?

We will continue to grow our support, management and monitoring infrastructure to ensure that our clients have the very best availability of your systems – and we’ll continue building our team of the best Linux experts in the UK.

NEWS & BLOG

Managing Debian’s package repositories

POSTED: 19th February 2019

Share this post:

Debian’s package manager, the Advanced Package Tool (APT) is also used by many derived distributions including Ubuntu. This means that managing package repositories on those systems is consistent and straightforward.

The repository list

Online package repositories for APT are listed in /etc/apt/sources.list and /etc/apt/sources.list.d. The latter is a directory of snippet files ending .list, for example /etc/apt/sources.list.d/nodejs.list. The snippet files have the same syntax as the main configuration file but they make it easier for other packages, configuration management systems and operators to add and remove repositories without disturbing any others.

Each (non-comment) line in this file represents either a binary or source package repository. Unless you particularly need the source to a package, binary repositories are usually sufficient. They look similar to this:

Shell

1

deb http://ftp.uk.debian.org/debian/stretch main

Debian repositories are divided into suites and components – in this example the suite is stretch and the component is main. A suite usually represents a Debian release by codename – stretch, jessie, etc – whereas a component divides the repository into logical chunks. For Debian’s official mirrors, valid components are main, contrib and non-free depending on how free the project considers those packages to be.

Validation

Most repositories are validated by cryptographic keys to protect users from malicious actors. For official Debian repositories, simply adding a repository entry is usually sufficient because the keys are already trusted (for example, to add a backports repository of packages which will be available in the next release, built for the current release).

But third-party repositories don’t have a trust chain already in place, so apt update results in an error like this:

Shell

1

2

3

4

Err:15http://repo.percona.com/apt stretch InRelease

The following signatures couldn'tbe verified because the public key isnotavailable:NO_PUBKEY9334A25F8507EFA5

As packages provided by a repository will have unrestricted root access to your system, strict verification of the key should always be done – that’s beyond the scope of this tip. To quote from the manual:

“It is critical that keys added manually via apt-key are verified to belong to the owner of the repositories they claim to be for otherwise the [package security] infrastructure is completely undermined.”

Adding a verified key to the trust list is a straightforward operation using the apt-key command, or by placing a keyring file into the /etc/apt/trusted.gpg.d directory.