Installation Package Upload Method, Installation Package Distribution Method, and Installation Package Verification Method

Abstract

The present application provides a method for uploading an installation package, a method for distributing an installation package, and a method for verifying an installation package, belonging to the field of cloud native technologies. The method includes: generating a signature file corresponding to a target application program based on a private key corresponding to the target application program and a first installation package, where the signature file includes signature information corresponding to each file in the first installation package; packaging the signature file and the first installation package to obtain a second installation package corresponding to the target application program; uploading the second installation package and a public key corresponding to the target application program to a second electronic device, so that the second electronic device distributes the second installation package and provides the public key to verify the second installation package after installation. Before uploading the first installation package of the target application program, the present application generates a signature file corresponding to the target application program, and uploads the second installation package obtained by adding the signature file to the first installation package. The signature file is uploaded along with the second installation package, which can reduce the maintenance difficulty of the second installation package after installation.

Description

Technical Field

[0001] This application relates to the field of cloud native technologies, and particularly to a method for uploading an installation package, a method for distributing an installation package, and a method for verifying an installation package. Background Art

[0002] With the development of cloud native technologies, containerization has become a trend in the development of application programs. In a containerized scenario, it is necessary to obtain an installation package of an application program, and then install the application program in a container based on the installation package, so as to achieve the containerized deployment of the application program.

[0003] Currently, the installation packages applicable to containers need to conform to the distribution format defined by the PyPA (Python Packaging Authority) specification, and the PyPA specification does not require digital signatures when uploading installation packages, resulting in greater difficulty in maintaining the installed installation packages. Therefore, it is necessary to provide a method for uploading an installation package to reduce the difficulty of maintaining the installed installation packages. Summary of the Invention

[0004] Embodiments of this application provide a method for uploading an installation package, a method for distributing an installation package, and a method for verifying an installation package. By adding a signature file to the installation package to be uploaded, after the installation package is installed, the installed installation package can be maintained based on the signature file, reducing the difficulty of maintaining the installed installation package. The technical solution is as follows:

[0005] In a first aspect, a method for uploading an installation package is provided. The method is applied to a first electronic device and includes:

[0006] Generating a public key and a private key corresponding to a target application program based on a preset signature algorithm;

[0007] Generating a signature file corresponding to the target application program based on the private key and a first installation package corresponding to the target application program, where the signature file includes signature information corresponding to each file in the first installation package;

[0008] Packaging the signature file and the first installation package to obtain a second installation package corresponding to the target application program;

[0009] Uploading the second installation package and the public key to a second electronic device, so that the second electronic device distributes the second installation package and provides the public key to verify the installed second installation package.

[0010] In a second aspect, a method for distributing an installation package is provided. The method is applied to a second electronic device and includes:

[0011] In response to a distribution request from a third electronic device for a second installation package corresponding to a target application, distribute the second installation package to the third electronic device. The second installation package is an installation package obtained by packaging a first installation package corresponding to the target application and a signature file. The signature file includes signature information corresponding to each file in the first installation package, and the signature information is generated based on a private key corresponding to the target application and the first installation package.

[0012] After the third electronic device installs the second installation package into a container, provide a public key corresponding to the target application to the third electronic device so that the third electronic device can verify the installed second installation package.

[0013] In a third aspect, an installation package verification method is provided. The method is applied to a third electronic device and includes:

[0014] After installing a second installation package corresponding to a target application into a container, obtain a signature file corresponding to the target application. The second installation package is an installation package obtained by packaging the signature file and a first installation package, and the signature file includes signature information corresponding to each file in the first installation package.

[0015] Obtain a public key corresponding to the target application.

[0016] Based on the public key and the signature file, verify the source of the installed second installation package.

[0017] In a fourth aspect, an installation package uploading device is provided. The device is set in a first electronic device and includes:

[0018] A first generation module for generating a public key and a private key corresponding to a target application based on a preset signature algorithm.

[0019] A second generation module for generating a signature file corresponding to the target application based on the private key and a first installation package corresponding to the target application. The signature file includes signature information corresponding to each file in the first installation package.

[0020] A packaging module for packaging the signature file and the first installation package to obtain a second installation package corresponding to the target application.

[0021] An uploading module for uploading the second installation package and the public key to a second electronic device so that the second electronic device distributes the second installation package and provides the public key to verify the installed second installation package.

[0022] Fifth aspect, there is provided an installation package distribution device, which is arranged in a second electronic device, and the device includes:

[0023] A distribution module, configured to respond to a distribution request of a third electronic device for a second installation package corresponding to a target application program, and distribute the second installation package to the third electronic device. The second installation package is an installation package obtained by packaging a first installation package corresponding to the target application program and a signature file. The signature file includes signature information corresponding to each file in the first installation package, and the signature information is generated according to a private key corresponding to the target application program and the first installation package;

[0024] A providing module, configured to provide a public key corresponding to the target application program to the third electronic device when the third electronic device installs the second installation package into a container, so that the third electronic device verifies the installed second installation package.

[0025] Sixth aspect, there is provided an installation package verification device, which is arranged in a third electronic device, and the device includes:

[0026] A first acquisition module, configured to acquire a signature file corresponding to the target application program after installing a second installation package corresponding to the target application program into a container. The second installation package is an installation package obtained by packaging the signature file and a first installation package, and the signature file includes signature information corresponding to each file in the first installation package;

[0027] A second acquisition module, configured to acquire a public key corresponding to the target application program;

[0028] A verification module, configured to verify the source of the installed second installation package based on the public key and the signature file.

[0029] Seventh aspect, there is provided an electronic device, including a processor and a memory; the memory stores at least one program code; the at least one program code is used to be called and executed by the processor to implement the installation package uploading method described in the first aspect, or the installation package distribution method described in the second aspect, or the installation package verification method described in the third aspect.

[0030] Eighth aspect, there is provided a computer-readable storage medium, in which at least one computer program is stored. When the at least one computer program is executed by a processor, it can implement the installation package uploading method described in the first aspect, or the installation package distribution method described in the second aspect, or the installation package verification method described in the third aspect.

[0031] In a ninth aspect, a computer program product is provided. The computer program product includes a computer program which, when executed by a processor, can implement the installation package uploading method described in the first aspect, or the installation package distribution method described in the second aspect, or the installation package verification method described in the third aspect.

[0032] The beneficial effects brought by the technical solutions provided in the embodiments of this application are as follows:

[0033] In the embodiments of this application, a first installation package is built for a target application program, and a public key and a private key corresponding to the target application program are generated based on a preset signature algorithm. Before uploading the first installation package, a signature file corresponding to the target application program is generated based on the private key and the first installation package corresponding to the target application program. Then, the signature file and the first installation package are packaged to obtain a second installation package, and then the second installation package and the public key are uploaded. Since the signature file is uploaded and distributed along with the second installation package, and the signature file includes the signature information corresponding to each file in the first installation package, based on the signature file and the public key, after the second installation package is installed, the installed second installation package can be verified. For example, the source of the installed second installation package can be verified, and it can also be verified whether the files in the installed second installation package are complete and unmodified, thereby reducing the maintenance difficulty of the installed second installation package. And the signature file exists throughout the life cycle of the second installation package, so the source of the second installation package can be traced throughout the life cycle of the second installation package, and the maintenance time is relatively long. Description of the Drawings

[0034] In order to more clearly illustrate the technical solutions in the embodiments of this application, the following will briefly introduce the drawings required for the description of the embodiments. Obviously, the drawings in the following description are only some embodiments of this application. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings.

[0035] Figure 1 It is a schematic diagram of the implementation environment involved in an installation package uploading, distribution and verification method provided by the embodiments of this application;

[0036] Figure 2 It is a flowchart of an installation package uploading method provided by the embodiments of this application;

[0037] Figure 3 It is a flowchart of another installation package uploading method provided by the embodiments of this application;

[0038] Figure 4 It is a flowchart of an installation package distribution method provided by the embodiments of this application;

[0039] Figure 5It is a flowchart of an installation package verification method provided by an embodiment of the present application;

[0040] Figure 6 It is a flowchart of another installation package verification method provided by an embodiment of the present application;

[0041] Figure 7 It is a schematic structural diagram of an installation package uploading device provided by an embodiment of the application;

[0042] Figure 8 It is a schematic structural diagram of an installation package distribution device provided by an embodiment of the present application;

[0043] Figure 9 It is a schematic structural diagram of an installation package verification device provided by an embodiment of the present application;

[0044] Figure 10 It is a structural block diagram of an electronic device provided by an embodiment of the present application. Detailed implementation manners

[0045] To make the objectives, technical solutions and advantages of the present application clearer, the following will further describe the embodiments of the present application in detail with reference to the accompanying drawings.

[0046] It can be understood that the terms "each", "multiple" and "any one" used in the embodiments of the present application, multiple includes two or more, each refers to each one in the corresponding multiple, and any one refers to any one in the corresponding multiple. For example, multiple words include 10 words, and each word refers to each of these 10 words, and any word refers to any one of the 10 words.

[0047] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data for analysis, stored data, displayed data, etc.) involved in the present application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data need to comply with the relevant laws, regulations and standards of relevant countries and regions, and provide corresponding operation entrances for users to choose to authorize or refuse.

[0048] Before executing the embodiments of the present application, first explain the nouns involved in the embodiments of the present application.

[0049] Wheel is the abbreviation of Python Wheel, which is a format of Python software packages and can simplify the installation and distribution of Python software packages. The Wheel software package is an installation package of a Python software package and is used to install Python software packages.

[0050] The WHL package is a pre-compiled binary package file mainly used for installing Python libraries. The WHL package contains pre-compiled bytecode, resource files, and metadata, etc., making the installation of Python packages faster and more convenient. The format of the WHL package conforms to the PyPA specification, aiming to simplify the installation and distribution process of Python packages.

[0051] PyPI (The Python Package Index) is a software repository for the Python programming language.

[0052] PIP (Package Installer for Python, the Python package management tool) is used to install Wheel packages.

[0053] PGP (Pretty Good Privacy) is an encryption communication protocol. By using encryption, digital signature, and compression technologies, it can ensure the confidentiality, integrity, and verifiability of data.

[0054] Digital signature is an identity authentication technology based on the public key authentication system. When sending a message, the sender uses a hash function to calculate the message to generate a message digest, and then uses the private key to encrypt the digest. Then, the encrypted digest is used as the digital signature of the message and sent to the receiver together with the message. The receiver uses the same hash function as the sender to calculate the digest of the received message, and then uses the public key to decrypt the digital signature of the message. If the two digests are the same, the receiver can confirm that the message is from the sender. Digital signatures have two functions: one is to determine that the message was indeed signed and sent by the sender; the other is to determine the integrity of the message. Based on the functions of digital signatures, in the embodiments of the present application, it can be used to verify the source and integrity of software packages.

[0055] The hash algorithm is an irreversible hashing algorithm used to generate the hash value of a file.

[0056] Packing refers to the process of packing files or directories into a compressed file of a certain format.

[0057] Unpacking refers to the process of decompressing a compressed file of a certain format.

[0058] The distribution format is the same as the packing format, mainly used for distributing and deploying applications. It can pack each file and necessary resources of the application into a single file or a group of files. The packed file is the installation package. The distribution format can include source code, library files, configuration files, etc. After the user downloads the installation package of the application, they can directly decompress and run it without going through a complex installation process.

[0059] Cloud native is a new software development and deployment approach that aims to build and run scalable, elastic, observable, and maintainable applications in a cloud computing environment. The core of cloud native is to design applications as elastic and scalable microservices and deploy applications in containers for easy management and rapid deployment. In cloud native scenarios, containerized applications are typically implemented using technologies such as Kubernetes, Docker, and Service Mesh, which can provide rich functionality and service support, such as container orchestration, service discovery, load balancing, and auto-scaling. By containerizing applications, the reliability, scalability, and flexibility of applications can be improved, and the development and deployment costs of applications can be reduced.

[0060] In cloud native scenarios, it is necessary to download the installation package of the application, namely the Wheel package, and install the application into the container based on the Wheel package. Currently, there are various sources of Wheel packages, such as the public PyPI source, the OS software source, etc. Although users can download Wheel packages from any source, since the Wheel packages applicable to containers need to conform to the distribution format defined by the PyPA specification, and the PyPA specification does not require digital signatures when Wheel packages are uploaded and distributed, the Wheel packages downloaded by users from any source do not carry signature information, making it difficult to maintain after installation. For example, the sources of Wheel packages installed in containers are relatively extensive. When users use containers, they can download Wheel packages by themselves. Due to the lack of a signature mechanism, they have no way of knowing the source of the Wheel packages. Another example is that after the Wheel package is installed, users can modify the source files. Some problems are caused after users modify the code of the Wheel package by themselves. However, due to the lack of a signature mechanism for the Wheel package, the integrity of the Wheel package cannot be guaranteed, so it is impossible to determine whether the problem is caused by the modified Wheel package.

[0061] To determine the source of the Wheel package, the solutions of related technologies, after the Wheel package is uploaded to the remote repository and in response to the distribution request of the Wheel package by the electronic device, before the remote repository distributes the Wheel package to the electronic device, generate a signature file for the Wheel package according to the stored Wheel package. This signature file can only ensure that the downloaded Wheel package has a reliable source. If the Wheel package stored in the remote repository has been tampered with, related technologies cannot verify that the Wheel package in the remote repository has been tampered with, and it is even more impossible to trace and track it after the electronic device installs the Wheel package.

[0062] To verify the consistency of the Wheel package before and after installation, the related technology obtains the Record file of the Wheel package before installation before obtaining the Wheel package and installing the Wheel package using PIP. This Record file includes the hash values of each file in the Wheel package before installation. After the Wheel package is installed, the Record file of the Wheel package after installation is obtained. This Record file includes the hash values of each file in the Wheel package after installation. Then, by comparing the Record file of the Wheel package before installation with the Record file of the Wheel package after installation, it is verified whether the Wheel package is consistent before and after installation. However, some files (such as.pyc) are generated during the installation of the Wheel package, and the hash values of these files are also appended to the Record file of the Wheel package after installation. Since the Record files before and after the installation of the Wheel package will change, it is impossible to verify the consistency of the Wheel package before and after installation based on the Record files before and after the installation of the Wheel package.

[0063] In order to determine the source of the distributed Wheel package and verify the consistency before and after the installation of the Wheel package, the embodiments of the present application provide a method for uploading an installation package, a method for distributing an installation package, and a method for verifying an installation package. This method is applicable to the upload, distribution, and verification of Wheel packages that comply with the PyPA specification. This method constructs a first Wheel package (i.e., the first installation package of the target application in the embodiments of the present application), generates a public key and a private key based on a preset signature algorithm (i.e., the public key and the private key corresponding to the target application in the embodiments of the present application). Then, an unpacking operation is performed on the first Wheel package to obtain the Record file corresponding to the first Wheel package (i.e., the target file in the embodiments of the present application). Then, the Record file is signed (i.e., the hash values of each file in the first Wheel package included in the Record file are encrypted using the private key corresponding to the target application), obtaining the signature file of the first Wheel package. Then, the signature file and the first Wheel package are packaged to obtain a second Wheel package (i.e., the second installation package of the target application in the embodiments of the present application). Furthermore, the public key corresponding to the target application and the second Wheel package are uploaded. Since the second Wheel package carries the signature file, therefore, subsequently, when a user obtains the second Wheel package and installs the target application into the container based on the second Wheel package, if the user wants to verify the source of the installed second Wheel package and the integrity of the second Wheel package before and after installation, the user can obtain the public key corresponding to the target application from the remote repository and obtain the Record file corresponding to the installed second Wheel package from the installation location of the target application. Then, based on the public key corresponding to the target application and the Record file corresponding to the installed second Wheel package, it is verified whether the second Wheel package is consistent before and after installation. The present application can verify the source and package integrity of the installed second Wheel package by adding a Record file to the first Wheel package. And the added signature file does not affect the upload, distribution, installation, and uninstallation of the second Wheel package, and has less invasiveness to the second Wheel package.

[0064] Please refer to Figure 1 , which shows the implementation environment involved in the method for uploading an installation package, the method for distributing an installation package, and the method for verifying an installation package provided by the embodiments of the present application. See Figure 1 This implementation environment includes: The implementation environment includes: a first electronic device 101, a second electronic device 102, and a third electronic device 103.

[0065] Among them, the first electronic device 101 can be an electronic device used by application developers. The application developers can use the first electronic device 101 to build the first installation package corresponding to the target application, generate the public key and private key corresponding to the target application, and generate the corresponding signature file for the target application based on the private key and the first installation package. Then, add the signature file to the first installation package to obtain the second installation package, and further upload the second installation package and the public key to the second electronic device 102.

[0066] The second electronic device 102 can be a remote repository, which is used to store the second installation package of the target application and its corresponding public key, and after receiving the distribution request from the third electronic device 103, distribute the second installation package of the target application to the third electronic device 103. After the third electronic device 103 installs the second installation package into the container, provide the public key corresponding to the target application to the third electronic device 103, so that the third electronic device 103 can verify the installed second installation package.

[0067] The third electronic device 103 can be an electronic device used by users or operation and maintenance personnel. After installing the target application into the container based on the second installation package, the users or operation and maintenance personnel can use the third electronic device 103 to obtain the public key corresponding to the target application from the second electronic device 102, and then verify the installed second installation package based on the public key.

[0068] The above-mentioned first electronic device 101 and the second electronic device 102 can communicate through a network. The second electronic device 102 and the third electronic device 103 can communicate through a network. This network can be a wired network or a wireless network.

[0069] The embodiment of the present application provides an installation package uploading method. Taking the first electronic device 101 in Figure 1 as an example of executing the embodiment of the present application, see Figure 2 , the method flow provided by the embodiment of the present application includes:

[0070] 201. Build the first installation package corresponding to the target application.

[0071] Among them, the target application is an application to be deployed in a container in a cloud-native scenario. The first installation package corresponding to the target application is used to install the target application into the container. The first installation package can be built using the source code of any assembly language. However, regardless of which assembly language's source code is used for building, the built first installation package needs to conform to the distribution format defined by the PyPA specification. Generally speaking, different assembly languages have different source code libraries, which include the original program code written by developers, version control information, developer information, modification history, etc. When building the first installation package corresponding to the target application, the developers of the application can first determine the type of assembly language to be used, then based on the type of assembly language, determine the corresponding source code library, and then according to the functions to be implemented by the target application, obtain the source code from the source code library to build the first installation package corresponding to the target application.

[0072] 202. Generate a public key and a private key corresponding to the target application based on a preset signature algorithm.

[0073] Among them, the preset signature algorithm can be a signature algorithm provided by PGP, etc. The public key and the private key are a pair of asymmetric keys. The public key can be used to encrypt data, and the private key can be used to decrypt the encrypted data; alternatively, the private key can be used to encrypt data, and the public key can be used to decrypt the encrypted data.

[0074] 203. Generate a signature file corresponding to the target application based on the private key and the first installation package corresponding to the target application.

[0075] Among them, the signature file includes the signature information corresponding to each file in the first installation package. This signature information cannot be tampered with and can be used to verify the source and integrity of the installation package during subsequent distribution and installation processes.

[0076] Specifically, when generating a signature file corresponding to the first installation package of the target application, the following method can be used:

[0077] 2031. Obtain the target file corresponding to the first installation package by unpacking the first installation package.

[0078] Among them, the target file can be a Record file. This target file includes the hash values of each file in the first installation package, and can also include the file path and file size of each file, and can also include the hash algorithm used for hash calculation of each file in the first installation package, etc. The first installation package is a compressed file. It is necessary to unpack the first installation package, and then obtain the target file corresponding to the first installation package from the multiple files obtained after decompression. When unpacking the first installation package, PIP, etc. can be used.

[0079] Generally, a digital signature includes the process of calculating the hash values (i.e., digests) of the files in the entire software package and the process of encrypting the digests of each file. Since the target file includes the hash values of the files in the first installation package, signing the first installation package is actually signing the target file.

[0080] 2032. Copy the target file to obtain a copy of the target file.

[0081] To reduce the intrusion into the first installation package, the target file can be copied to obtain a copy of the target file, and then the copy of the target file is signed to obtain a signature file. To facilitate the distinction between the target file and its copy, in the embodiments of the present application, the target file can be referred to as the Record file, and the copy of the target file can be referred to as the Record.asc file. In the embodiments of the present application, the target file is located in the target file directory, which is a file directory created for the first installation package to store the target file and its copy. The target file directory can be xxx.dist-info. The management of this target file directory is looser than that of other file directories obtained after unpacking the first installation package. Copying and storing the files in this target file directory has less impact on the first installation package. After unpacking the first installation package, the target file directory can be searched, and then the target file in the target file directory is copied and the copied target file is stored in the target file directory to obtain a copy of the target file. For example, copy the / Record file in the file directory xxx.dist-info, and then store the copied file in xxx.dist-info to obtain the RECORD.asc file.

[0082] 2033. Generate a signature file corresponding to the target application based on the private key and the copy of the target file.

[0083] Specifically, when generating a signature file corresponding to the target application based on the private key and the copy of the target file, the following method can be adopted:

[0084] 20331. Use the private key to encrypt the hash values of the files in the copy of the target file to obtain the signature information of the copy of the target file.

[0085] 20332. Add the signature information to the copy of the target file to obtain a signature file.

[0086] After obtaining the signature information, the signature information can be added to the copy of the target file in the target file directory, thereby obtaining a signature file. Since the management of the target file directory is looser than that of other file directories obtained after decompressing the first installation package, adding the signature file to this target directory will not affect the distribution, installation, and uninstallation of the installation package.

[0087] When adding signature information to a copy of the target file, the signature information can be directly added after the original content in the copy of the target file. At this time, the obtained signature file can be divided into two parts. The first half can include the copy of the target file, the adopted hash algorithm, etc. The copy of the target file includes the file paths, hash values, and file sizes of each file in the target file. The second half is the signature information of the copy of the target file, and this signature information is the encryption result obtained by encrypting the hash values of each file in the copy of the target file.

[0088] 204. Package the signature file and the first installation package to obtain the second installation package corresponding to the target application.

[0089] After obtaining the signature file, it is necessary to package the signature file with the first installation package to obtain the second installation package corresponding to the target application. When packaging the signature file and the first installation package, PIP can be used for packaging. By packaging the signature file with the first installation package, the signature file can be distributed along with the second installation package, so that the source of the second installation package can be traced throughout the entire life cycle of the second installation package.

[0090] 205. Upload the second installation package and the public key to the second electronic device.

[0091] After obtaining the second installation package, the second installation package and the public key can be uploaded to the second electronic device, so that the second electronic device distributes the second installation package and provides the public key to verify the second installation package after installation. The second electronic device can be a remote repository, and this remote repository is used to store the installation packages of containerized applications.

[0092] Taking the installation package as a Wheel software package as an example, generally, the construction of a Wheel software package includes the process of building a Wheel software package based on a source code library and the process of uploading the built Wheel software package to a remote repository. On this basis in the embodiments of the present application, before uploading the Wheel software package, a corresponding signature file is generated for the Wheel software package, and then the Wheel software package with the signature file added is uploaded. Figure 3 Shows the entire process of Wheel software package distribution, see Figure 3 , and this process includes the following steps:

[0093] step1. Based on the source code library, build a Wheel software package, that is, a Whl package, and generate a public key and a private key using a preset signature algorithm. Then, unpack the built Wheel software package using PIP.

[0094] Step 2: Copy the Record file under the xxx.dist-info directory of the software package, and store the copied Record file under the xxx.dist-info directory of the software package to obtain the Record.asc file under the xxx.dist-info directory of the software package.

[0095] Step 3: Encrypt the Record.asc file under the xxx.dist-info directory of the software package using the private key to obtain signature information, and add the signature to the Record.asc file under the xxx.dist-info directory of the software package.

[0096] Step 4: Repackage the Record.asc file under the xxx.dist-info directory of the software package with the Wheel software package to obtain a new Wheel software package, and then upload the new Wheel software package and the public key to the remote repository.

[0097] All of the above optional technical solutions can be combined arbitrarily to form optional embodiments of the present application, which will not be elaborated one by one here.

[0098] The embodiments of the present application provide a method for distributing installation packages. Taking the second electronic device 102 in Figure 1 executing the embodiments of the present application as an example, referring to Figure 4 , the method flow provided by the embodiments of the present application includes:

[0099] 401. Store the second installation package and the public key of the target application uploaded by the first electronic device.

[0100] When receiving the second installation package and the public key of the target application uploaded by the first electronic device, the second electronic device can store the second installation package and the public key of the target application to provide a source for the installation package of the target application.

[0101] 402. In response to the distribution request of the third electronic device for the second installation package corresponding to the target application, distribute the second installation package to the third electronic device.

[0102] When an operation and maintenance personnel or a user wants to install the target application into a container to implement containerized management of the target application, the third electronic device can be used to send a distribution request for the second installation package corresponding to the target application to the second electronic device. The distribution request may include the identifier of the target application, etc. In response to the distribution request, the second electronic device distributes the second installation package of the target application to the third electronic device, so that the third electronic device installs the second installation package into the container.

[0103] 403. After the third electronic device installs the second installation package into the container, provide the public key corresponding to the target application to the third electronic device so that the third electronic device can verify the installed second installation package.

[0104] In a possible implementation, after the third electronic device installs the second installation package into the container, if the operation and maintenance personnel or the user wants to verify the second installation package, the operation and maintenance personnel or the user can use the third electronic device to send a public key acquisition request for the target application to the second electronic device. When receiving the public key acquisition request, the second electronic device provides the public key corresponding to the target application to the third electronic device so that the third electronic device can verify the installed second installation package.

[0105] In another possible implementation, after the third electronic device installs the second installation package into the container, the third electronic device can send a notification message to the second electronic device. When receiving the notification message, the second electronic device can provide the public key corresponding to the target application to the third electronic device so that the third electronic device can verify the installed second installation package.

[0106] The embodiments of the present application provide an installation package verification method. Taking the third electronic device 103 in Figure 1 as an example of executing the embodiments of the present application, referring to Figure 5 , the method flow provided by the embodiments of the present application includes:

[0107] 501. After installing the second installation package corresponding to the target application into the container, obtain the signature file corresponding to the target application.

[0108] After installing the target application into the container based on the second installation package, if the operation and maintenance personnel or the user wants to verify the second installation package, the signature file corresponding to the target application can be obtained. The second installation package is an installation package obtained by packaging the signature file and the first installation package. The signature file includes signature information corresponding to each file in the first installation package, etc.

[0109] Specifically, when obtaining the signature file corresponding to the target application, the file directory at the installation location of the target application can be searched, and then the signature file can be obtained from the target file directory. The target file directory is the file directory obtained after unpacking the first installation package and used to store the target file and its signature file.

[0110] 502. Obtain the public key corresponding to the target application.

[0111] When the operation and maintenance personnel or the user wants to verify the second installation package, the third electronic device can also be used to send a public key acquisition request to the second electronic device to obtain the public key corresponding to the target application.

[0112] It should be noted that although the above takes obtaining the signature file corresponding to the target application as step 501 and obtaining the public key corresponding to the target application as step 502, in fact, it is also possible to first obtain the public key corresponding to the target application and then obtain the signature file corresponding to the target application. It is also possible to obtain the signature file corresponding to the target application and the public key corresponding to the target application simultaneously.

[0113] 503. Verify the installed second installation package based on the public key and the signature file.

[0114] Verifying the installed second installation package includes verifying its source and its integrity (i.e., whether it is the same as the files in the second installation package before installation). For different verification purposes, different verification methods can be adopted.

[0115] When it is necessary to verify the source of the second installation package, the public key can be used to decrypt the signature information in the signature file. If the signature information is successfully decrypted, it can be determined that the installed second installation package has the same source as the public key.

[0116] When it is necessary to verify the integrity of the second installation package, the public key can be used to decrypt the signature information in the signature file. When the signature information in the signature file is successfully decrypted using the public key, the hash values of each file in the first installation package obtained by decryption are acquired. Then, the hash values of each file in the second installation package after installation are obtained. Furthermore, the hash value of each file in the first installation package is compared with the hash value of the corresponding file in the second installation package after installation. If the hash value of each file in the first installation package is the same as the hash value of the corresponding file in the second installation package after installation, it is determined that the files in the second installation package after installation are complete and are consistent with the files in the second installation package before installation. It should be noted that although new files will be automatically generated after the second installation package is installed, the automatically generated files are not within the scope of verification. Just verify the existing files to ensure that the files during distribution are complete and unmodified. For example, the first installation package of the target application includes File 1, File 2, and File 3. During the process of installing the second installation package into the container, File 4 is generated. In the embodiment of the present application, when verifying the integrity of the second installation package after installation, the hash value of File 1 in the first installation package is compared with the hash value of File 1 in the second installation package after installation, the hash value of File 2 in the first installation package is compared with the hash value of File 2 in the second installation package after installation, and the hash value of File 3 in the first installation package is compared with the hash value of File 3 in the second installation package after installation. When the hash values of the three files in the first installation package are the same as the hash values of the three corresponding files in the second installation package after installation, it can be determined that the second installation package after installation is complete. Since the hash values of the three files in the first installation package are the hash values obtained when the target application is built, they are more accurate than the hash values generated based on the installation package during the subsequent distribution process. Moreover, File 4 in the second installation package after installation using the method of the present application is not within the scope of verification. Therefore, even if new files are generated during the installation process, it does not affect the verification result. However, in the related art, when verifying the integrity based on the hash values of each file in the target file before and after installation, the hash value of the target file before installation is generated based on the installation package after distribution, and it is necessary to ensure that the files included in the target file before and after installation are the same and the hash values of the files are the same. Therefore, the generation of new files during the installation process will affect the verification result.

[0117] In the embodiments of the present application, the signature file signs the original Record file. As long as the signature file passes the verification, it can prove that the Record file itself has not been modified. If the Record file has not been modified, it means that the hash values of all the files recorded in the Record file are valid. Furthermore, through the Record file, the hash verification of all the files in the Wheel software package can be performed in reverse. As long as the hash values recorded in the Record file are the same as the hash values of the installed Record file, it is considered that the Wheel software package is the same before and after installation and has not been modified. Generally speaking, the verification process includes two parts. The first part is to determine whether the Record file is valid, and the second part is to verify that all the files in the Wheel software package have not been tampered with based on the Record file.

[0118] Figure 6 shows the entire process of installation package verification provided by the embodiments of the present application. Refer to Figure 6 , and this process includes the following steps:

[0119] step1. Obtain the public key corresponding to the signature application from the remote repository.

[0120] Step2. Extract the Record.asc file, that is, the signature file, from the installation location of the Wheel software package.

[0121] Step3. Use the public key to verify whether the Record.asc file has a valid signature. If the public key can decrypt the signature information in the Record.asc file, it is determined that the Wheel software package comes from the remote repository of the corresponding public key.

[0122] After the signature verification is successful, the integrity verification of the Wheel software package can also be performed according to the Record.asc file and the installed Record file. If the hash value of each file in the Record.asc file is the same as the hash value of the corresponding file in the installed Record file, it is determined that the Wheel software package is complete and has not been tampered with.

[0123] In the embodiments of the present application, the installed Wheel software package is signed. Due to the uniqueness of this signature, any third party cannot perform effective verification. Subsequently, when performing verification, it only needs to verify whether the Record.asc can pass the signature verification. In addition, the signature file in the embodiments of the present application exists within the software package life cycle, which can maximize the guarantee of the consistency of software package distribution and can help the operation and maintenance personnel quickly trace the software package.

[0124] Please refer to Figure 7, which shows a schematic structural diagram of an installation package uploading device provided by an embodiment of the present application. The device is disposed in a first electronic device and can be implemented by software, hardware, or a combination of both, and becomes all or a part of the first electronic device. The device includes:

[0125] A first generation module 701, configured to generate a public key and a private key corresponding to a target application program based on a preset signature algorithm;

[0126] A second generation module 702, configured to generate a signature file corresponding to the target application program based on the private key and a first installation package corresponding to the target application program. The signature file includes signature information corresponding to each file in the first installation package;

[0127] A packaging module 703, configured to package the signature file and the first installation package to obtain a second installation package corresponding to the target application program;

[0128] An uploading module 704, configured to upload the second installation package and the public key to a second electronic device, so that the second electronic device distributes the second installation package and provides the public key to verify the second installation package after installation.

[0129] In another embodiment of the present application, the first generation module 701 is configured to unpack the first installation package to obtain a target file corresponding to the first installation package. The target file includes hash values of each file in the first installation package; copy the target file to obtain a copy of the target file; and generate a signature file corresponding to the target application program based on the private key and the copy of the target file.

[0130] In another embodiment of the present application, the first generation module 701 is configured to copy the target file in a target file directory and store the copied target file in the target file directory to obtain a copy of the target file. The target file directory is a file directory obtained after unpacking the first installation package and used to store the target file and its copy.

[0131] In another embodiment of the present application, the first generation module 701 is configured to use the private key to encrypt hash values of each file in the target file in the target file directory to obtain signature information of the target file; and add the signature information to the copy of the target file to obtain the signature file.

[0132] Those skilled in the art can clearly understand that for the convenience and brevity of description, the specific working processes of the above-described systems, devices, and units can refer to the corresponding processes in the foregoing method embodiments and will not be described herein again.

[0133] Please refer to Figure 8 , which shows a schematic structural diagram of an installation package distribution device provided by an embodiment of the present application. The device is arranged in a second electronic device and can be implemented by software, hardware, or a combination of both, and becomes all or part of the second electronic device. The device includes:

[0134] A distribution module 801, configured to, in response to a distribution request of a third electronic device for a second installation package corresponding to a target application program, distribute the second installation package to the third electronic device. The second installation package is an installation package obtained by packing a first installation package corresponding to the target application program and a signature file. The signature file includes signature information corresponding to each file in the first installation package, and the signature information is generated according to a private key corresponding to the target application program and the first installation package;

[0135] A providing module 802, configured to, when the third electronic device installs the second installation package into a container, provide a public key corresponding to the target application program to the third electronic device, so that the third electronic device verifies the installed second installation package.

[0136] Please refer to Figure 9 , which shows a schematic structural diagram of an installation package verification device provided by an embodiment of the present application. The device is arranged in a third electronic device and can be implemented by software, hardware, or a combination of both, and becomes all or part of the third electronic device. The device includes:

[0137] A first obtaining module 901, configured to, after installing a second installation package corresponding to a target application program into a container, obtain the signature file corresponding to the target application program. The second installation package is an installation package obtained by packing the signature file and a first installation package, and the signature file includes signature information corresponding to each file in the first installation package;

[0138] A second obtaining module 902, configured to obtain the public key corresponding to the target application program;

[0139] A verification module 903, configured to verify the source of the installed second installation package based on the public key and the signature file.

[0140] In another embodiment of the present application, the first obtaining module 901 is configured to find a file directory at the installation location of the target application program; obtain the signature file from the target file directory, where the target file directory is a file directory obtained after unpacking the first installation package and used to store the target file and its signature file.

[0141] In another embodiment of the present application, the verification module 903 is configured to decrypt the signature information in the signature file by using the public key; if the signature information is successfully decrypted, it is determined that the installed second installation package is from the same source as the public key.

[0142] In another embodiment of the present application, the verification module 903 is configured to, when the signature information in the signature file is successfully decrypted by using the public key, obtain the hash values of the files in the decrypted first installation package; obtain the hash values of the files in the installed second installation package; when the hash value of any file in the first installation package is the same as the hash value of the corresponding file in the installed second installation package, it is determined that the files in the installed second installation package are complete.

[0143] Those skilled in the art can clearly understand that for the convenience and brevity of description, the specific working processes of the systems, devices, and units described above can refer to the corresponding processes in the foregoing method embodiments and will not be elaborated herein.

[0144] Figure 10 The block diagram of an electronic device 1000 provided by an exemplary embodiment of the present application is shown. Generally, the electronic device 1000 includes a processor 1001 and a memory 1002.

[0145] The processor 1001 can be implemented in at least one hardware form of DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), and PLA (Programmable Logic Array). The processor 1001 can also include a main processor and a coprocessor. The main processor is a processor for processing data in the wake state; the coprocessor is a low-power processor for processing data in the standby state. In some embodiments, the processor 1001 can be integrated with a GPU (Graphics Processing Unit), and the GPU is responsible for rendering and drawing the content to be displayed on the display screen. In some embodiments, the processor 1001 can further include an artificial intelligence processor, and the artificial intelligence processor is used to process computational operations related to machine learning.

[0146] The memory 1002 may include one or more computer-readable storage media, which may be non-transitory computer-readable storage media. For example, the non-transitory computer-readable storage media may be CD-ROM (Compact Disc Read-Only Memory), ROM, RAM (Random Access Memory), magnetic tape, floppy disk, and optical data storage devices, etc. At least one computer program is stored in the computer-readable storage media, and when the at least one computer program is executed, it can implement the above-mentioned installation package distribution method or installation package verification method.

[0147] Of course, the above-mentioned electronic device may necessarily further include other components, such as an input / output interface, a communication component, etc. The input / output interface provides an interface between the processor and the peripheral interface module, and the above-mentioned peripheral interface module may be an output device, an input device, etc. The communication component is configured to facilitate communication between the electronic device and other devices in a wired or wireless manner, etc.

[0148] Those skilled in the art can understand that Figure 10 the structure shown in does not constitute a limitation on the electronic device 1000, and it may include more or fewer components than shown in the figure, or combine certain components, or adopt a different component arrangement.

[0149] An embodiment of the present application provides a computer-readable storage medium, in which at least one computer program is stored, and when the at least one computer program is executed by a processor, it can implement the above-mentioned installation package upload method, or the installation package upload method, or the installation package verification method.

[0150] An embodiment of the present application provides a computer program product, which includes a computer program, and when the computer program is executed by a processor, it can implement the above-mentioned installation package distribution method, or the installation package upload method, or the installation package verification method.

[0151] Those skilled in the art can clearly understand that for the convenience and simplicity of description, the specific working processes of the above-described systems, devices, and units can refer to the corresponding processes in the foregoing method embodiments, and will not be elaborated herein.

[0152] The above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them; although the present application has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that they can still modify the technical solutions recorded in the foregoing embodiments, or perform equivalent replacements for some of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A method for uploading an installation package, characterized in that, The method is applied to a first electronic device, and the method includes: Generating a public key and a private key corresponding to a target application based on a preset signature algorithm, where the target application is an application to be deployed in a container in a cloud native scenario; By unpacking a first installation package corresponding to the target application, obtaining target files corresponding to the first installation package, where the target files include hash values of each file in the first installation package, and the first installation package conforms to the distribution format defined by the PyPA specification; Copying the target files to obtain a copy of the target files; Generating a signature file corresponding to the target application based on the private key and the copy of the target files, where the signature file includes signature information corresponding to each file in the first installation package; Packing the signature file and the first installation package to obtain a second installation package corresponding to the target application; Uploading the second installation package and the public key to a second electronic device, so that the second electronic device distributes the second installation package and provides the public key to verify the second installation package after installation.

2. The method according to claim 1, wherein The copying the target files to obtain a copy of the target files includes: Copying the target files in the target file directory and storing the copied target files in the target file directory to obtain a copy of the target files, where the target file directory is the file directory obtained after unpacking the first installation package and is used to store the target files and their copies.

3. The method according to claim 1, wherein The generating the signature file corresponding to the target application based on the private key and the copy of the target files includes: Using the private key to encrypt the hash values of each file in the copy of the target files to obtain signature information of the copy of the target files; Adding the signature information to the copy of the target files to obtain the signature file.

4. A method for distributing installation packages, characterized in that, The method is applied to a second electronic device, and the method includes: In response to a distribution request from a third electronic device for a second installation package corresponding to a target application, distributing the second installation package to the third electronic device, where the second installation package is an installation package obtained by packing a first installation package corresponding to the target application and a signature file, the signature file includes signature information corresponding to each file in the first installation package, the signature information is generated according to the private key corresponding to the target application and the first installation package, the target application is an application to be deployed in a container in a cloud native scenario, the first installation package conforms to the distribution format defined by the PyPA specification, the signature file is generated by the first electronic device based on the private key corresponding to the target application and a copy of the target files, and the copy of the target files is obtained by copying the target files obtained by the first electronic device through an unpacking operation on the first installation package corresponding to the target application, and the target files include hash values of each file in the first installation package; After the third electronic device installs the second installation package into the container, provide the public key corresponding to the target application to the third electronic device, so that the third electronic device verifies the installed second installation package.

5. An installation package verification method, characterized in that The method is applied to a third electronic device, and the method includes: After installing the second installation package corresponding to the target application into the container, obtain the signature file corresponding to the target application. The second installation package is obtained by packaging the signature file with the first installation package. The signature file includes signature information corresponding to each file in the first installation package. The target application is an application to be deployed in the container in a cloud-native scenario. The first installation package conforms to the distribution format defined by the PyPA specification. The signature file is generated by the first electronic device based on the private key corresponding to the target application and a copy of the target file. The copy of the target file is obtained by the first electronic device copying the target file obtained by unpacking the first installation package corresponding to the target application. The target file includes the hash values of each file in the first installation package; Obtain the public key corresponding to the target application; Based on the public key and the signature file, verify the installed second installation package.

6. The method according to claim 5, wherein The obtaining the signature file corresponding to the target application includes: Search for the file directory at the installation location of the target application; Obtain the signature file from the target file directory. The target file directory is the file directory obtained after unpacking the first installation package and used to store the target file and its signature file.

7. The method according to claim 5, characterized in that, The verifying the installed second installation package based on the public key and the signature file includes: Use the public key to decrypt the signature information in the signature file; If the signature information is successfully decrypted, determine that the installed second installation package is from the same source as the public key.

8. The method according to claim 5, characterized in that, The verifying the installed second installation package based on the public key and the signature file includes: when the signature information in the signature file is successfully decrypted using the public key, obtain the hash values of each file in the decrypted first installation package; Obtain the hash values of each file in the installed second installation package; When the hash value of any file in the first installation package is the same as the hash value of the corresponding file in the installed second installation package, determine that the files in the installed second installation package are complete.

9. An electronic device, characterized in that, It includes a processor and a memory; the memory stores at least one piece of program code; the at least one piece of program code is used to be called and executed by the processor to implement the installation package uploading method according to any one of claims 1 to 3, or the installation package distribution method according to claim 4, or the installation package verification method according to any one of claims 5 to 8.

10. A computer-readable storage medium, characterized in that, At least one computer program is stored in the computer-readable storage medium, and when the at least one computer program is executed by a processor, it can implement the installation package uploading method described in any one of claims 1 to 3, or, the installation package distribution method described in claim 4, or, the installation package verification method described in any one of claims 5 to 8.

11. A computer program product, characterized in that, The computer program product includes a computer program, and when the computer program is executed by a processor, it can implement the installation package uploading method described in any one of claims 1 to 3, or, the installation package distribution method described in claim 4, or, the installation package verification method described in any one of claims 5 to 8.

Images