OpenPGP is a non-proprietary format for authenticating or encrypting data, using public key cryptography. [opengpg]

It is based on the original PGP (Pretty Good Privacy) software.

Beginning in 1997, the OpenPGP Working Group was formed in the Internet Engineering Task Force (IETF) to define this standard that had formerly been a proprietary product since 1991.

Over the past decade, PGP, and later OpenPGP, has become the standard for nearly all of the world’s signed or encrypted email.

1. GNU Privacy Guard

GNU Privacy Guard (GnuPG or GPG) is a free-software replacement for Symantec’s PGP cryptographic software suite. The software is compliant with RFC 4880, the IETF standards-track specification of OpenPGP. Modern versions of PGP are interoperable with GnuPG and other OpenPGP-compliant systems.

GnuPG is part of the GNU Project and received major funding from the German government in 1999.

GnuPG is a hybrid-encryption software program because it uses a combination of conventional symmetric-key cryptography for speed, and public-key cryptography for ease of secure key exchange, typically by using the recipient’s public key to encrypt a session key which is used only once.

From Wikipedia, the free encyclopedia [sessionkey]

A session key is a single-use symmetric key used for encrypting all messages in one communication session. A closely related term is content encryption key (CEK), traffic encryption key (TEK), or multicast key which refers to any key used for encrypting messages.

GnuPG encrypts messages using asymmetric key pairs individually generated by GnuPG users. The resulting public keys may be exchanged with other users in a variety of ways, such as Internet key servers.

From Wikipedia, the free encyclopedia [keyserver]

In computer security, a key server is a computer that receives and then serves existing cryptographic keys to users or other programs. The users' programs can be running on the same network as the key server or on another networked computer.

The keys distributed by the key server are almost always provided as part of a cryptographically protected public key certificates containing not only the key but also 'entity' information about the owner of the key. The certificate is usually in a standard format, such as the OpenPGP public key format, the X.509 certificate format, or the PKCS format. Further, the key is almost always a public key for use with an asymmetric key encryption algorithm.

Key servers play an important role in public key cryptography. In public key cryptography an individual is able to generate a key pair, where one of the keys is kept private while the other is distributed publicly. Knowledge of the public key does not compromise the security of public key cryptography. An individual holding the public key of a key pair can use that key to carry out cryptographic operations that allow secret communications with strong authentication of the holder of the matching private key. The need to have the public key of a key pair in order to start communication or verify signatures is a bootstrapping problem. Locating keys on the web or writing to the individual asking them to transmit their public keys can be time consuming and unsecure. Key servers act as central repositories to alleviate the need to individually transmit public keys and can act as the root of a chain of trust.

These are some keyservers that are often used for looking up keys with gpg --recv-keys. These can be queried via https:// (HTTPS) or hkps:// (HKP over TLS) respectively.

  • keys.openpgp.org

  • keys.mailvelope.com/manage.html

  • pgp.mit.edu

  • keyring.debian.org

  • keyserver.ubuntu.com

  • pgp.surf.nl

2. Hands-on Guide on GPG Keys

To generate a key pair, first make sure you can run the following command.

$ gpg --version
gpg (GnuPG) 2.2.27
libgcrypt 1.8.8
Copyright (C) 2021 Free Software Foundation, Inc.
License GNU GPL-3.0-or-later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: /home/x/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
        CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2

If not, then you need to install it, the package is gnupg (for gpg) or gnupg2 (for gpg2).

$ sudo apt-get update
$ sudo apt-get install gnupg2

2.1. Generate a Key Pair

Simply run the following command and answer the prompt questions to generate a new key pair.

$ gpg --full-gen-key
gpg (GnuPG) 2.2.27; Copyright (C) 2021 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Please select what kind of key you want:
   (1) RSA and RSA (default)
   (2) DSA and Elgamal
   (3) DSA (sign only)
   (4) RSA (sign only)
  (14) Existing key from card
Your selection? 1
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (3072) 4096
Requested keysize is 4096 bits
Please specify how long the key should be valid.
         0 = key does not expire
      <n>  = key expires in n days
      <n>w = key expires in n weeks
      <n>m = key expires in n months
      <n>y = key expires in n years
Key is valid for? (0) 3y
Key expires at Fri 20 Mar 2026 10:58:15 AM CST
Is this correct? (y/N) y

GnuPG needs to construct a user ID to identify your key.

Real name: Your Name
Email address: your.name@example.com
Comment:
You selected this USER-ID:
    "Your Name <your.name@example.com>"

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
gpg: key E3347ECE4ECCD835 marked as ultimately trusted
gpg: revocation certificate stored as '/home/x/.gnupg/openpgp-revocs.d/BF743CF56A6EF9A4B0F94ACCE3347ECE4ECCD835.rev'
public and secret key created and signed.

pub   rsa4096 2023-03-21 [SC] [expires: 2026-03-20]
      BF743CF56A6EF9A4B0F94ACCE3347ECE4ECCD835
uid                      Your Name <your.name@example.com>
sub   rsa4096 2023-03-21 [E] [expires: 2026-03-20]

2.2. Generate an Authentication Subkey

An authentication subkey is used if you want to use your GPG key for SSH authentication. To generate this, just follow these steps:

$ gpg --expert --edit-key BF743CF56A6EF9A4B0F94ACCE3347ECE4ECCD835
gpg (GnuPG) 2.2.27; Copyright (C) 2021 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Secret key is available.

sec  rsa4096/E3347ECE4ECCD835
     created: 2023-03-21  expires: 2026-03-20  usage: SC
     trust: ultimate      validity: ultimate
ssb  rsa4096/DFAFCFC264DE8767
     created: 2023-03-21  expires: 2026-03-20  usage: E
[ultimate] (1). Your Name <your.name@example.com>

gpg> addkey
Please select what kind of key you want:
   (3) DSA (sign only)
   (4) RSA (sign only)
   (5) Elgamal (encrypt only)
   (6) RSA (encrypt only)
   (7) DSA (set your own capabilities)
   (8) RSA (set your own capabilities)
  (10) ECC (sign only)
  (11) ECC (set your own capabilities)
  (12) ECC (encrypt only)
  (13) Existing key
  (14) Existing key from card
Your selection? 8

Possible actions for a RSA key: Sign Encrypt Authenticate
Current allowed actions: Sign Encrypt

   (S) Toggle the sign capability
   (E) Toggle the encrypt capability
   (A) Toggle the authenticate capability
   (Q) Finished

Your selection? S

Possible actions for a RSA key: Sign Encrypt Authenticate
Current allowed actions: Encrypt

   (S) Toggle the sign capability
   (E) Toggle the encrypt capability
   (A) Toggle the authenticate capability
   (Q) Finished

Your selection? E

Possible actions for a RSA key: Sign Encrypt Authenticate
Current allowed actions:

   (S) Toggle the sign capability
   (E) Toggle the encrypt capability
   (A) Toggle the authenticate capability
   (Q) Finished

Your selection? A

Possible actions for a RSA key: Sign Encrypt Authenticate
Current allowed actions: Authenticate

   (S) Toggle the sign capability
   (E) Toggle the encrypt capability
   (A) Toggle the authenticate capability
   (Q) Finished

Your selection? Q
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (3072) 4096
Requested keysize is 4096 bits
Please specify how long the key should be valid.
         0 = key does not expire
      <n>  = key expires in n days
      <n>w = key expires in n weeks
      <n>m = key expires in n months
      <n>y = key expires in n years
Key is valid for? (0) 2y
Key expires at Thu 20 Mar 2025 12:01:37 PM CST
Is this correct? (y/N) y
Really create? (y/N) y
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.

sec  rsa4096/E3347ECE4ECCD835
     created: 2023-03-21  expires: 2026-03-20  usage: SC
     trust: ultimate      validity: ultimate
ssb  rsa4096/DFAFCFC264DE8767
     created: 2023-03-21  expires: 2026-03-20  usage: E
ssb  rsa4096/EF4D2528DEB8EB02
     created: 2023-03-21  expires: 2025-03-20  usage: A
[ultimate] (1). Your Name <your.name@example.com>

2.3. List Keys

To list all the public GPG keys. Give the following command.

$ gpg --list-keys

To obtain the key id in LONG (complete) format, use this flag “--keyid-format LONG”.

$ gpg --list-keys --keyid-format LONG

To list all the private GPG keys.

$ gpg --list-secret-keys

All these commands give you the following information about your GPG keys and subkeys.

  • Which algorithm your keys use, e.i rsa.

  • Key size, e.i 4096 bits.

  • Key IDs, e.i 123AB456 (this is the short key id of 8-bytes, in the long format you get the complete key id of 16-bytes).

  • Date of creation.

  • Their usage e.i

    ‘E’=encryption, ‘S’=signing, ‘C’=certification, ‘A’=authentication.

  • Their expiry date.

  • Their trust level, e.i Ultimate, unknown, etc.

  • Name and Email associated with them that’s also known as UID "User ID".

2.4. Exporting Keys

Exporting means, to bring out the keys from GPG database so that we may see or store them in files.

If you want to see your GPG key in ASCII characters, then you need to export it to a file by the following command.

$ gpg --output public.key --armor --export your.email@example.com

  • --output: specifies the output file.

  • --export: to instruct GPG to export your public key.

  • --armor: to export in ASCII characters.

Similarly, to export a private key directly on the terminal just change one flag.

$ gpg --armor --export-secret-keys your.email@example.com

This will ask for your passphrase. Here you may also add the --output flag to put its output in a file as done in the previous command.

Never give/share your private key anywhere. Keep it as secure as you can. The private key is required to decrypt the data encrypted just for you. So, compromising this key may result in security issues whose severity depends on the data you deal with.

2.5. Fingerprints

A key can be verified by a number of ways. One such way is to use its fingerprint. The fingerprint is a shorter number (usually expressed as a 40-hexadecimal-digit number) that contains a cryptographically strong hash of the public key.

To see the fingerprint of any GPG key associated with an email. Use this command.

$ gpg --fingerprint email@example.com

You can cross check this fingerprint with the person to verify if it is trustworthy.

2.6. Generating a Revocation Certificate

It is vital to have revocation certificate to declare your keys invalid in case your private key has been compromised or lost. It should be generated as soon as you generate your key pair, not when you need it. So, let’s generate it with the following command.

$ gpg --output ~/revocation.crt --gen-revoke your.email@example.com

In order to save this file from unauthorized access, you may immediately put restrictions (if not present by default).

$ chmod 600 ~/revocation.crt

In case you want to revoke your key, then you would have to upload this revocation certificate to a public keyserver (assuming that you have already sent your public key to a keyserver.)

2.7. Sending and Importing Keys

Sending:

  • Why are you using GPG keys in the first place?

    Because with GPG you can sign messages or other people can encrypt messages to you.

    Therefore, to make your key publicly available might be of great help. So that, anyone can take your public key to encrypt messages to you. For this, we can send our public key to a keyserver.

  • Would it be safe to upload your public key on keyservers?

    Absolutely yes, as I have already mentioned before that GPG works on asymmetric cryptography, therefore having your public key to someone doesn’t make a threat to your security. Because it is practically impossible to generate a private key from a public key.

    There are multiple keyservers available to hold public keys like, keys.fedoraproject.org, keyserver.ubuntu.com, etc. and they regularly synchronize among themselves. So if you send your key on keyserver.ubuntu.com, then after some time, it would also be available at keys.fedoraproject.org.

    To send your key to the keyserver use the following command.

    $ gpg --send-keys --keyserver keyserver_url key_id

    If you don’t want to upload your key to a keyserver (in case your communication is limited to a group of people) then you can also send your public key to them through email.

Importing:

Importing means to include the key in your GPG database, so that you may use them in future. For example, if you wanna send your friends an encrypted message, which can be done with their public keys. Therefore, first, you would need to import their keys into your GPG system and then only you may use them for encryption.

You can import the key of someone from a file, with the following command. For this, you must have their public key in a file say "their_gpg.key".

$ gpg --import their_gpg.key

Now when you would list-keys with “gpg --list-keys”, this imported key will also be listed.

But if the person’s key is available at a keyserver, then you can also directly pull their keys from there. Because keyservers distribute public keys to anyone who requests them. Once you have sent your key to a keyserver, others can request your key using the command.

$ gpg --keyserver keyserver_url --recv-keys key_id

To refresh all your keys from a keyserver, to obtain new signatures, new UIDs and new key revocations, use this.

$ gpg --refresh-keys

And to pull from specific servers, use this.

$ gpg --keyserver keyserver_url --refresh-keys

You should do this regularly. But you may receive error messages if any of your keys cannot be found on the key server.

2.8. Signing Keys

A major benefit of GPG is that you can sign a file to prove that it is genuinely coming form you. Because signs are created using private keys and only the person who owns the GPG keys, have its private key (if not compromised or lost).

Your key is already signed by you when it was created. That you may verify with.

$ gpg --list-sig your.email@example.com

In the output, the line after “sig” shows the UID of those people who have signed your key.

You can also sign keys of other people (assuming that you have already imported the key of that person). Signing a key means you verify that you trust the person, who they claim to be. If you sign a person’s key then sending the signed key back to him/her is a good idea, otherwise, they won’t be able to take advantage of your sign. For this, you have 2 methods.

  • Method 1:

    $ gpg --sign-key person.email@example.com
$ gpg --output ~/signed.key --sign-key person.email@example.com

    Then you can send this “signed.key” file to the person via mail.

    Once that person receives your signed key, then s//he can update their own GPG database to include your signature.

    $ gpg --import signed.key

  • Method 2:

    $ gpg --sign-key person.email@example.com
$ gpg --keyserver key_server --send-key person_keyid

    This will directly upload your sign to the keyserver (assuming that the person has sent his key to a keyserver). So when next time that person would refresh his/her GPG database, your sign would be included.

Why should you sign a person’s key?

Because this can help other people decide whether to trust that person too or not. If someone trusts you, and they see that you’ve signed this person’s key, they may be more likely to trust their identity too. There is a concept behind signing a key known as Web of Trust.

3. OpenPGP integration in APT

$ apt-key list
Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).
/etc/apt/trusted.gpg
...

3.1. DebianRepositoryUseThirdParty: Instructions to connect to a third-party repository

There are many different ways of configuring an unofficial APT repository on a machine. This document aims to standardize the procedure to add such a third-party repository to a Debian-based system so that the new repository can only ship a set of expected packages, and so that those packages will be securely delivered to the system. [usethirdparty]

3.1.1. OpenPGP certificate distribution

Repositories MUST be signed with an OpenPGP certificate. A binary export (gpg --export) of the certificate SHOULD be available at the root of the repository under the filename deriv-archive-keyring.pgp, where deriv is the a short name for the repository. The file SHOULD NOT be ASCII-Armored (gpg --export --armor) although a separate armored version MAY be available under deriv-archive-keyring.asc.

The certificate SHOULD be served over HTTPS if possible. A free X509 certificate MAY be obtained from Let’s Encrypt and automatically configured using the certbot package.

The certificate MAY also be made available on key servers. If so, operators SHOULD choose an appropriate keyserver or keyserver pool, such as keys.openpgp.org or keyserver.ubuntu.com, or implement a OpenPGP Web Key Directory. It should be noted that the previously recommended ad-hoc standard pool, sks-keyservers.net is out of service permanently. This certificate SHOULD be signed by other keys, preferably including some that are close to the strong set, in order to leverage the OpenPGP web of trust. The certificate MUST be downloaded over a secure mechanism like HTTPS to a location only writable by root. The certificate MUST NOT be placed in /etc/apt/trusted.gpg.d or loaded by apt-key add.

If future updates to the certificate will be managed by an apt/dpkg package as recommended below, then it SHOULD be downloaded into /usr/share/keyrings using the same filename that will be provided by the package. If it will be managed locally , it SHOULD be downloaded into /etc/apt/keyrings instead.

In releases older than Debian 12 and Ubuntu 22.04, /etc/apt/keyrings does not exist by default. It SHOULD be created with permissions 0755 if it is needed and does not already exist.

For example, users MAY be told to run a command to download the certificate, but because chances are the certificate being distributed is ASCII-Armored, it is best to unconditionally dearmor them. With Sequoia-PGP:

curl https://deriv.example.net/debian/deriv-archive-keyring.pgp | \
  sq -o /usr/share/keyrings/deriv-archive-keyring.pgp dearmor

or with GnuPG:

curl https://deriv.example.net/debian/deriv-archive-keyring.pgp | \
  gpg -o /usr/share/keyrings/deriv-archive-keyring.pgp --dearmor
The reason why we avoid ASCII-Armored files is that they can only be used by SecureApt in version 1.4 or later (which appeared in stretch). We also strongly recommend the use of HTTPS as it bypasses certain MITM attacks that would allow a hostile third party to inject OpenPGP certificate material in the repository setup.

3.1.2. Sources.list entry

A sources.list entry SHOULD have the signed-by option set. The signed-by entry MUST point to a file, and not a fingerprint.

The suite entry SHOULD correspond to the target Debian release if the binaries are built for a specific suite. In other cases, the suite SHOULD be the string "stable", or it MAY be a repository-specific string describing the suite concisely. If the suite does not correspond to a target Debian release, the suite naming convention MUST be clearly documented.

If the repository has no reason to be split into multiple components, then the component name SHOULD be main. If there is a reason for splitting the repo into multiple components, the reason for the split should be clearly documented (e.g. Debian’s documented split) and the component names should concisely reflect that split.

Entries MUST be added in the /etc/apt/sources.list.d directory using a shortened repository name (e.g. deriv.list). The "Deb822" file format MAY be used instead to improve clarity for complex entries (e.g. deriv.sources). (See sources.list(5))

For example, this would be the content of the /etc/apt/sources.list.d/deriv.list file:

deb [signed-by=/usr/share/keyrings/deriv-archive-keyring.pgp] https://deriv.example.net/debian/ stable main

The above is a sources.list line for a fictitious Deriv Debian derivative. The suite is stable and the component is the standard main component.

This is equivalent to the following Deb822 file format, under deriv.sources:

Types: deb
URIs: https://deriv.example.net/debian/
Suites: stable
Components: main
Signed-By: /usr/share/keyrings/deriv-archive-keyring.pgp
The reason we point to a file instead of a fingerprint is that the latter forces the user to add the certificate to the global SecureApt trust anchor in /etc/apt/trusted.gpg.d, which would cause the system to accept signatures from the third-party keyholder on all other repositories configured on the system that don’t have a signed-by option (including the official Debian repositories).
Serving the repository under HTTPS is OPTIONAL, as it may make running a round-robin network of untrusted mirrors more difficult, and the trust chain provided by SecureApt should suffice.

3.1.3. How to find and add a key

The debian-archive-keyring package is used to distribute keys to apt. Upgrades to this package can add (or remove) OpenPGP keys for the main Debian archive. [secureapt]

For other archives, there is not yet a standard location where you can find the key for a given apt repository. There’s a rough standard of putting the key up on the web page for the repository or as a file in the repository itself, but no real standard, so you might have to hunt for it.

The current and the retired Debian archive "signing" keys are available from https://ftp-master.debian.org/keys.html.

The OpenPGP ecosystem has a standard way to distribute keys, using a keyserver that OpenPGP implementation can use to download a key from and add it to a keyring. For example with Sequoia-PGP:

user@host:~> sq keyserver get --binary --output debian-archive-bullseye-stable.pgp 'A428 5295 FC7B 1A81 6000  62A9 605C 66F0 0D6C 9793'

Or with GnuPG:

user@host:~> gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys 'A428 5295 FC7B 1A81 6000  62A9 605C 66F0 0D6C 9793'
gpg: key 605C66F00D6C9793: public key "Debian Stable Release Key (11/bullseye) <debian-release@lists.debian.org>" imported
gpg: Total number processed: 1
gpg:               imported: 1
user@host:~> gpg --output debian-archive-bullseye-stable.pgp --export 'A428 5295 FC7B 1A81 6000  62A9 605C 66F0 0D6C 9793'

To install the keyring simply copy it to the apt trusted.gpg.d directory:

user@host:~> sudo cp -i debian-archive-bullseye-stable.pgp /etc/apt/trusted.gpg.d/

3.1.4. Complete example

This example may serve as a template for instructions provided at the root of the archive to help users configure the APT repository.

This is a Debian repository. To install packages from this repository, you should first download a trust anchor into your system using this command:

wget -O /usr/share/keyrings/deriv-archive-keyring.pgp https://deriv.example.net/debian/deriv-archive-keyring.pgp

Then you can add the repository to your sources.list by creating a text file in /etc/apt/sources.list.d/deriv.sources containing the following:

Types: deb deb-src
URIs: https://deriv.example.net/debian/
Suites: stable
Architectures: i386 amd64
Components: main
Signed-By: /usr/share/keyrings/deriv-archive-keyring.pgp

Finally, you should also add the following preferences file to restrict what this repository can install, by creating the following file in /etc/apt/preferences.d/deriv.pref:

Package: *
Pin: origin deriv.example.net
Pin-Priority: 100

Once this is done, you can run apt-get update for the changes to take effect and use apt-get install deriv-archive-keyring to make sure updates to the keyring are received in a timely manner.

3.1.5. Troubleshooting

$ sudo apt-get update
Hit:1 https://mirrors.ustc.edu.cn/debian bullseye InRelease
Hit:2 https://mirrors.ustc.edu.cn/debian bullseye-updates InRelease
Hit:3 https://mirrors.ustc.edu.cn/debian-security bullseye-security InRelease
Hit:4 https://mirrors.ustc.edu.cn/kubernetes/apt kubernetes-xenial InRelease
Hit:5 https://download.docker.com/linux/debian bullseye InRelease
Hit:6 https://packages.microsoft.com/debian/11/prod bullseye InRelease
Err:6 https://packages.microsoft.com/debian/11/prod bullseye InRelease
  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY EB3E94ADBE1229CF
Reading package lists... Done
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: https://packages.microsoft.com/debian/11/prod bullseye InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY EB3E94ADBE1229CF
W: Failed to fetch https://packages.microsoft.com/debian/11/prod/dists/bullseye/InRelease  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY EB3E94ADBE1229CF
W: Some index files failed to download. They have been ignored, or old ones used instead.
$ gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys EB3E94ADBE1229CF
gpg: key EB3E94ADBE1229CF: public key "Microsoft (Release signing) <gpgsecurity@microsoft.com>" imported
gpg: Total number processed: 1
gpg:               imported: 1
$ gpg --output microsoft-prod.gpg --export EB3E94ADBE1229CF
$ sudo chown root.root microsoft-prod.gpg
$ sudo mv microsoft-prod.gpg /etc/apt/trusted.gpg.d/
$ sudo apt-get update
Hit:1 https://download.docker.com/linux/debian bullseye InRelease
Hit:2 https://packages.microsoft.com/debian/11/prod bullseye InRelease
Hit:3 https://mirrors.ustc.edu.cn/debian bullseye InRelease
Hit:4 https://mirrors.ustc.edu.cn/debian bullseye-updates InRelease
Hit:5 https://mirrors.ustc.edu.cn/debian-security bullseye-security InRelease
Hit:6 https://mirrors.ustc.edu.cn/kubernetes/apt kubernetes-xenial InRelease
Reading package lists... Done

References