Installation package uploading method, installation package distribution method and installation package verification method

Abstract

The invention provides an installation package uploading method, an installation package distribution method and an installation package verification method, and belongs to the technical field of cloud native. The method comprises the steps that a signature file corresponding to a target application program is generated based on a private key corresponding to the target application program and a first installation package, and the signature file comprises signature information corresponding to all files 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; and uploading the second installation package and a public key corresponding to the target application program to the second electronic equipment, so that the second electronic equipment distributes the second installation package, and providing the public key to verify the installed second installation package. Before the first installation package of the target application program is uploaded, the signature file corresponding to the target application program is generated, the signature file is uploaded and added into the first installation package to obtain the second installation package, the signature file is uploaded along with the second installation package, and the maintenance difficulty of the installed second installation package can be reduced.

Description

Technical Field

[0001] The present application relates to the field of cloud native technology, and in particular to an installation package uploading method, an installation package distribution method, and an installation package verification method. Background Art

[0002] With the development of cloud-native technology, containerization has become a development trend of applications. In the containerization scenario, you need to obtain the installation package of the application, and then install the application in the container based on the installation package to achieve containerized deployment of the application.

[0003] Currently, the installation package used by the container must comply with the distribution format defined by the PyPA (Python Packaging Authority) specification. However, the PyPA specification does not require the installation package to be digitally signed when uploading, which makes it difficult to maintain the installation package after installation. Therefore, it is necessary to provide an installation package upload method to reduce the difficulty of maintaining the installation package after installation. Summary of the invention

[0004] The embodiment of the present application provides an installation package uploading method, an installation package distribution method and an installation package verification method, which adds a signature file to the installation package to be uploaded, so that after the installation package is installed, the installed installation package can be maintained based on the signature file, thereby reducing the maintenance difficulty of the installed installation package. The technical solution is as follows: In a first aspect, a method for uploading an installation package is provided, the method being applied to a first electronic device, the method comprising: Generate the public key and private key corresponding to the target application based on the preset signature algorithm; Based on the private key and a first installation package corresponding to the target application, generating a signature file corresponding to the target application, the signature file including 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; The second installation package and the public key are uploaded 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.

[0005] In a second aspect, a method for distributing an installation package is provided, the method being applied to a second electronic device, the method comprising: 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, wherein the second installation package is an installation package obtained by packaging a first installation package corresponding to the target application and a signature file, wherein 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 and the first installation package; After the third electronic device installs the second installation package into the container, the public key corresponding to the target application is provided to the third electronic device, so that the third electronic device verifies the installed second installation package.

[0006] In a third aspect, an installation package verification method is provided, the method being applied to a third electronic device, the method comprising: After installing a second installation package corresponding to the target application into the container, obtaining a signature file corresponding to the target application, wherein the second installation package is an installation package obtained by packaging the signature file with the first installation package, and the signature file includes signature information corresponding to each file in the first installation package; Obtaining a public key corresponding to the target application; Based on the public key and the signature file, the source of the installed second installation package is verified.

[0007] In a fourth aspect, a device for uploading an installation package is provided, the device being arranged in a first electronic device, the device comprising: A first generation module, used to generate a public key and a private key corresponding to a target application based on a preset signature algorithm; A second generating module, configured to generate a signature file corresponding to the target application based on the private key and the first installation package corresponding to the target application, wherein the signature file includes signature information corresponding to each file in the first installation package; A packaging module, used to package the signature file and the first installation package to obtain a second installation package corresponding to the target application; The uploading module is used to upload the second installation package and the public key to the 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.

[0008] In a fifth aspect, an installation package distribution device is provided, the device being arranged in a second electronic device, the device comprising: a distribution module, configured to distribute the second installation package corresponding to the target application to the third electronic device in response to a distribution request of the third electronic device for the second installation package, wherein the second installation package is an installation package obtained by packaging the first installation package corresponding to the target application and a signature file, wherein 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 and the first installation package; A module is provided, which is used to provide the public key corresponding to the target application to the third electronic device after the third electronic device installs the second installation package into the container, so that the third electronic device verifies the installed second installation package.

[0009] In a sixth aspect, an installation package verification device is provided, the device being arranged in a third electronic device, the device comprising: A first acquisition module, configured to acquire a signature file corresponding to the target application after installing a second installation package corresponding to the target application into a container, wherein the second installation package is an installation package obtained by packaging the signature file with the first installation package, and the signature file includes signature information corresponding to each file in the first installation package; A second acquisition module, used to acquire a public key corresponding to the target application; The verification module is used to verify the source of the installed second installation package based on the public key and the signature file.

[0010] In the seventh aspect, an electronic device is provided, comprising 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.

[0011] In an eighth aspect, a computer-readable storage medium is provided, wherein 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, 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 can be implemented.

[0012] In the ninth aspect, a computer program product is provided, which includes a computer program, and when the 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.

[0013] The beneficial effects of the technical solution provided by the embodiment of the present application are: The embodiment of the present application constructs a first installation package for the target application, and generates a public key and a private key corresponding to the target application based on a preset signature algorithm. Before uploading the first installation package, a signature file corresponding to the target application is generated based on the private key and the first installation package corresponding to the target application, and then the signature file is packaged with the first installation package 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 with the second installation package, and the signature file includes the signature information corresponding to each file in the first installation package, the second installation package after installation can be verified based on the signature file and the public key. For example, the source of the second installation package after installation can be verified, and whether the files in the second installation package after installation are complete and not tampered with can also be verified, thereby reducing the difficulty of maintaining the second installation package after installation. And the signature file exists in the entire life cycle of the second installation package, so the source of the second installation package can be traced back during the entire life cycle of the second installation package, and the maintenance time is relatively long. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0015] Figure 1 It is a schematic diagram of an implementation environment involved in a method for uploading, distributing and verifying an installation package provided in an embodiment of the present application; Figure 2 This is a flow chart of a method for uploading an installation package provided in an embodiment of the present application; Figure 3 is a flowchart of another installation package uploading method provided in an embodiment of the present application; Figure 4 is a flow chart of an installation package distribution method provided in an embodiment of the present application; Figure 5 is a flow chart of an installation package verification method provided by an embodiment of the present application; Figure 6 is a flowchart of another installation package verification method provided by an embodiment of the present application; Figure 7 It is a structural schematic diagram of an installation package uploading device provided in an application embodiment; Figure 8 It is a structural diagram of an installation package distribution device provided in an embodiment of the present application; Fig. 9 It is a structural diagram of an installation package verification device provided in an embodiment of the present application; Fig.10 It is a structural block diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0016] In order to make the objectives, technical solutions and advantages of the present application clearer, the implementation methods of the present application will be further described in detail below with reference to the accompanying drawings.

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

[0018] 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 used for analysis, stored data, displayed data, etc.) involved in this 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 must 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.

[0019] Before executing the embodiments of the present application, the terms involved in the embodiments of the present application are first explained.

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

[0021] The WHL package is a precompiled binary package file, mainly used to install Python libraries. The WHL package contains precompiled bytecode, resource files, and metadata, making the installation of Python packages faster and more convenient. The format of the WHL package complies with the PyPA specification and is designed to simplify the installation and distribution process of Python packages.

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

[0023] PIP (Package Installer for Python) is used to install the Wheel package.

[0024] PGP (Pretty Good Privacy) is an encrypted communication protocol that ensures the confidentiality, integrity, and verifiability of data by using encryption, digital signatures, and compression techniques.

[0025] A digital signature is an identity authentication technology based on a public key authentication system. When sending a message, the sender uses a hash function to calculate the message to generate a summary of the message, and then uses a private key to encrypt the summary, and then sends the encrypted summary as the digital signature of the message to the receiver together with the message. The receiver uses the same hash function as the sender to calculate the summary of the received message, and then uses the public key to decrypt the digital signature of the message. If the two summaries 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 is indeed signed and sent by the sender; the other is to determine the integrity of the message. Based on the role of digital signatures, in the embodiments of the present application, it can be used to verify the source and integrity of the software package.

[0026] A hash algorithm is an irreversible hash algorithm used to generate a hash value for a file.

[0027] Packing refers to the process of packaging files or directories into a compressed file in a certain format.

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

[0029] The distribution format is the packaging format, which is mainly used to distribute and deploy applications. It can package the various files and necessary resources of the application into a single file or a group of files. The packaged file is the installation package. The distribution format can contain source code, library files, configuration files, etc. After the user downloads the installation package of the application, he can directly decompress and run it without going through a complicated installation process.

[0030] 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 them in containers for easy management and rapid deployment. In cloud native scenarios, containerized applications are usually implemented using technologies such as Kubernetes, Docker, and Service Mesh, which can provide rich functions and service support, such as container orchestration, service discovery, load balancing, and automatic 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.

[0031] In the cloud-native scenario, you need to download the installation package of the application, that is, the Wheel package, and install the application into the container based on the Wheel package. Currently, there are several sources of Wheel packages, such as public PyPI sources, OS software sources, etc. Although users can download Wheel packages from any source, since the Wheel packages applicable to the container must comply with the distribution format defined by the PyPA specification, and the PyPA specification does not require the Wheel packages to be digitally signed when uploading and distributing, no matter which source the user downloads the Wheel package from, it does not carry signature information, making it difficult to maintain after installation. For example, the sources of the Wheel packages installed in the container are relatively wide. When using the container, users can download the Wheel packages by themselves. Since there is no signature mechanism, the source of the Wheel packages cannot be known. For another example, after the Wheel package is installed, users can modify the source files. Some problems are caused by users modifying the code of the Wheel package by themselves, but since the Wheel package has no signature mechanism, 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.

[0032] In order to determine the source of the Wheel software package, the solution of the related art is that after the Wheel software package is uploaded to the remote warehouse, in response to the electronic device's request to distribute the Wheel software package, before the remote warehouse distributes the Wheel software package to the electronic device, a signature file is generated for the Wheel software package based on the stored Wheel software package. The signature file can only ensure that the source of the downloaded Wheel software package is reliable. If the Wheel software package stored in the remote warehouse has been tampered with, the related art cannot verify that the Wheel software package in the remote warehouse has been tampered with, and cannot track and trace the Wheel software package after the electronic device installs it.

[0033] In order to verify the consistency of the Wheel software package before and after installation, the related technology obtains the Wheel software package and obtains the Record file of the Wheel software package before installation before using PIP to install the Wheel software package. The Record file includes the hash value of each file in the Wheel software package before installation. After the Wheel software package is installed, the Record file of the Wheel software package after installation is obtained. The Record file includes the hash value of each file in the Wheel software package after installation. Then, by comparing the Record file of the Wheel software package before installation with the Record file of the Wheel software package after installation, it is verified whether the Wheel software package is consistent before and after installation. However, some files (such as .pyc) will be generated during the installation of the Wheel software package, and the hash values ​​of these files will also be appended to the Record file of the Wheel software package after installation. Since the Record files before and after the installation of the Wheel software package will change, it is impossible to verify the consistency of the Wheel software package before and after installation based on the Record files before and after the installation of the Wheel software package.

[0034] In order to determine the source of the distributed Wheel software package and verify the consistency of the Wheel software package before and after installation, the embodiment of the present application provides an installation package uploading method, an installation package distribution method and an installation package verification method, which are applicable to the uploading, distribution and verification of Wheel software packages that comply with the PyPA specification. The method constructs a first Wheel software package (i.e., the first installation package of the target application in the embodiment of the present application), generates a public key and a private key (i.e., the public key and the private key corresponding to the target application in the embodiment of the present application) based on a preset signature algorithm, then unpacks the first Wheel software package to obtain a Record file corresponding to the first Wheel software package (i.e., the target file in the embodiment of the present application), then signs the Record file (i.e., using the private key corresponding to the target application to encrypt the hash value of each file in the first Wheel software package included in the Record file), obtains a signature file of the first Wheel software package, then packages the signature file with the first Wheel software package to obtain a second Wheel software package (i.e., the second installation package of the target application in the embodiment of the present application), and then uploads the public key corresponding to the target application and the second Wheel software package. Since the second wheel software package carries a signature file, when the user subsequently obtains the second wheel software package and installs the target application into the container based on the second wheel software package, if the user wants to verify the source of the installed second wheel software package and the integrity of the second wheel software package before and after installation, the user can obtain the public key corresponding to the target application from the remote warehouse, and obtain the Record file corresponding to the installed second wheel software package from the installation location of the target application, and then verify whether the second wheel software package is consistent before and after installation based on the public key corresponding to the target application and the Record file corresponding to the installed second wheel software package. This application can verify the source and package integrity of the installed second wheel software package by adding a Record file to the first wheel software package. And the added signature file does not affect the uploading, distribution, installation and uninstallation of the second wheel software package, and is less invasive to the second wheel software package.

[0035] Please refer to Figure 1 , which shows the implementation environment involved in the installation package uploading method, installation package distribution method and installation package verification method provided in the embodiment of the present application, see Figure 1 , the implementation environment includes: the implementation environment includes: a first electronic device 101, a second electronic device 102 and a third electronic device 103.

[0036] The first electronic device 101 may be an electronic device used by application developers. The application developers may use the first electronic device 101 to construct a first installation package corresponding to the target application, generate a public key and a private key corresponding to the target application, and generate a corresponding signature file for the target application based on the private key and the first installation package, and then add the signature file to the first installation package to obtain a second installation package, and then upload the second installation package and the public key to the second electronic device 102.

[0037] The second electronic device 102 can be a remote warehouse, used to store the second installation package of the target application and its corresponding public key, and after receiving a 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, the public key corresponding to the target application is provided to the third electronic device 103, so that the third electronic device 103 can verify the installed second installation package.

[0038] The third electronic device 103 may be an electronic device used by a user or an operation and maintenance personnel. After the target application is installed into the container based on the second installation package, the user or the operation and maintenance personnel may 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.

[0039] The first electronic device 101 and the second electronic device 102 can communicate with each other via a network, and the second electronic device 102 and the third electronic device 103 can communicate with each other via a network, which can be a wired network or a wireless network.

[0040] The present application embodiment provides a method for uploading an installation package. Figure 1 For example, the first electronic device 101 in the embodiment of the present application is executed. Figure 2 , the method flow provided in the embodiment of the present application includes: 201. Build a first installation package corresponding to a target application.

[0041] 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 constructed using source code of any assembly language, but no matter which assembly language source code is used to build it, the constructed first installation package must comply with 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 the developer, version control information, developer information, modification history, etc. When building the first installation package corresponding to the target application, the developer of the application can first determine the type of assembly language used, and then determine the corresponding source code library based on the type of assembly language, and then obtain the source code from the source code library according to the functions to be implemented by the target application to build the first installation package corresponding to the target application.

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

[0043] The preset signature algorithm may be a signature algorithm provided by PGP, etc. The public key and the private key are a pair of asymmetric keys. The public key may be used to encrypt data, and the private key may be used to decrypt the encrypted data; or the private key may be used to encrypt data, and the public key may be used to decrypt the encrypted data.

[0044] 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.

[0045] The signature file includes signature information corresponding to each file in the first installation package. The signature information cannot be tampered with, and the source and integrity of the installation package can be verified during the subsequent distribution and installation process.

[0046] Specifically, when generating a corresponding signature file for the first installation package of the target application, the following method may be used: 2031. Obtain a target file corresponding to the first installation package by unpacking the first installation package.

[0047] The target file may be a Record file, which includes the hash values ​​of each file in the first installation package, and may also include the file path and file size of each file, and may also include the hash algorithm used to perform hash calculations on each file in the first installation package. The first installation package is a compressed file, and the first installation package needs to be unpacked, and then the target file corresponding to the first installation package is obtained from the multiple files obtained by unpacking. When unpacking the first installation package, PIP, etc. may be used.

[0048] Generally, digital signature includes the process of performing hash calculation on the files in the entire software package to obtain the hash value of each file, i.e., the digest, and the process of encrypting the digest of each file. Since the target file includes the hash value of each file in the first installation package, signing the first installation package is actually signing the target file.

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

[0050] In order to reduce the intrusion of 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. In order to facilitate the distinction between the target file and the copy of the target file, the embodiment of the present application can refer to the target file as a Record file, and the copy of the target file as a Record.asc file. The target file of the embodiment of the present application is located in the target file directory, which is a file directory created by the first installation package for storing the target file and its copy. The target file directory can be xxx.dist-info. The target file directory is looser than other file directories obtained after the first installation package is unpacked. The files in the target file directory are copied and stored, and the impact on the first installation package is relatively small. After the first installation package is unpacked, the target file directory can be searched, and then the target file under 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, the / Record file under the file directory xxx.dist-info is copied, and then the copied file is stored under xxx.dist-info to obtain the RECORD.asc file.

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

[0052] Specifically, based on the private key and the copy of the target file, when generating the signature file corresponding to the target application, the following method can be used: 20331. Use the private key to encrypt the hash value of each file in the copy of the target file to obtain the signature information of the copy of the target file.

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

[0054] After the signature information is obtained, the signature information can be added to the copy of the target file in the target file directory to obtain the signature file. Since the target file directory is more loosely managed than other file directories obtained by decompressing the first installation package, adding the signature file to the target directory will not affect the distribution, installation and uninstallation of the installation package.

[0055] When adding signature information to a copy of a target file, the signature information can be directly added to the original content of the copy of the target file. The signature file obtained at this time can be divided into two parts. The first half may include a copy of the target file, the adopted hash algorithm, etc. The copy of the target file includes the file path, hash value and file size of each file of the target file; the second half is the signature information of the copy of the target file, and the signature information is the encryption result obtained by encrypting the hash value of each file in the copy of the target file.

[0056] 204. Pack the signature file and the first installation package to obtain a second installation package corresponding to the target application.

[0057] After obtaining the signature file, it is necessary to package the signature file with the first installation package to obtain a 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 with the second installation package, so that the source of the second installation package can be traced throughout the life cycle of the second installation package.

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

[0059] 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 installed second installation package. The second electronic device can be a remote warehouse, which is used to store the installation package of the containerized application.

[0060] Taking the installation package as a Wheel software package as an example, usually the construction of a Wheel software package includes a process of building the Wheel software package based on a source code library, and a process of uploading the constructed Wheel software package to a remote warehouse. On this basis, the embodiment of the present application generates a corresponding signature file for the Wheel software package before the Wheel software package is uploaded, and then uploads the Wheel software package with the added signature file. Figure 3 The entire process of Wheel package distribution is shown in Figure 3 , the process includes the following steps: Step 1: Based on the source code library, build the Wheel software package, namely the Whl package, and use the preset signature algorithm to generate the public key and private key. Then, use PIP to unpack the built Wheel software package.

[0061] step2. Copy the Record file under the software package directory xxx.dist-info, and store the copied Record file under the software package directory xxx.dist-info to obtain the Record.asc file under the software package directory xxx.dist-info.

[0062] step3. Use the private key to encrypt the Record.asc file under the software package directory xxx.dist-info, obtain the signature information, and add the signature to the Record.asc file under the software package directory xxx.dist-info.

[0063] step4. Repackage the Record.asc file in the software package directory xxx.dist-info with the Wheel software package to obtain a new Wheel software package, and then upload the new Wheel software package and public key to the remote repository.

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

[0065] The present application embodiment provides a method for distributing an installation package. Figure 1 For example, the second electronic device 102 in the embodiment of the present application is executed. Figure 4 , the method flow provided in the embodiment of the present application includes: 401. Store a second installation package and a public key of a target application uploaded by a first electronic device.

[0066] 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 the source of the installation package for the target application.

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

[0068] When the operation and maintenance personnel or the user want to install the target application into the container to realize the 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, and the distribution request may include the identification 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. 403. After the third electronic device installs the second installation package into the container, the public key corresponding to the target application is provided to the third electronic device, so that the third electronic device verifies the installed second installation package.

[0069] In one 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. Upon 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.

[0070] 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. After 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.

[0071] The present application embodiment provides an installation package verification method. Figure 1 For example, the third electronic device 103 in the embodiment of the present application is executed. Figure 5 , the method flow provided in the embodiment of the present application includes: 501. After installing the second installation package corresponding to the target application into the container, obtain a signature file corresponding to the target application.

[0072] After the target application is installed 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 the installation package obtained by packaging the signature file with the first installation package, and the signature file includes the signature information corresponding to each file in the first installation package.

[0073] Specifically, when obtaining the signature file corresponding to the target application, you can search the file directory at the installation location of the target application, and then obtain the signature file from the target file directory, which is the file directory obtained after the first installation package is unpacked and is used to store the target file and its signature file.

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

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

[0076] It should be noted that, although the above step 501 is to obtain the signature file corresponding to the target application, and the step 502 is to obtain the public key corresponding to the target application, 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, or to obtain the signature file corresponding to the target application and the public key corresponding to the target application at the same time.

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

[0078] Verification of the second installation package after installation includes verification of its source and verification of its integrity (ie, whether it is consistent with the files in the second installation package before installation). Different verification methods can be used for different verification purposes.

[0079] When the source of the second installation package needs to be verified, 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.

[0080] When the integrity of the second installation package needs to be verified, the signature information in the signature file can be decrypted using the public key. When the signature information in the signature file is successfully decrypted using the public key, the hash values ​​of each file in the decrypted first installation package are obtained, and then the hash values ​​of each file in the second installation package after installation are obtained. 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 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. It is sufficient to verify the existing files to ensure that the files are complete and not tampered with when distributed. For example, the first installation package of the target application includes file 1, file 2 and file 3. In the process of installing the second installation package into the container, file 4 is generated. When verifying the integrity of the second installation package after installation, the embodiment of the present application compares the hash value of file 1 in the first installation package with the hash value of file 1 in the second installation package after installation, compares the hash value of file 2 in the first installation package with the hash value of file 2 in the second installation package after installation, and compares the hash value of file 3 in the first installation package 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 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 constructed, they are more accurate than the hash values ​​generated based on the installation package in the subsequent distribution process, and file 4 in the second installation package after installation using the method of the present application is not within the verification range, even if new files are generated during the installation process, it does not affect the verification result. However, when the related technology performs integrity verification 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 new files generated during the installation process will affect the verification results.

[0081] In the embodiment of the present application, the signature file is used to sign the original Record file. As long as the signature file passes the verification, it can be proved that the Record file itself has not been modified. If the Record file has not been modified, it means that the hash values ​​of each file recorded in the Record file are valid. Then, the Record file can be used to reversely perform hash verification on all files in the Wheel software package. As long as the hash value recorded in the Record file is consistent with the hash value of the Record file after installation, it is considered that the Wheel software package is consistent before and after installation and has not been modified. In summary, the verification process includes two parts. The first part first determines whether the Record file is valid, and the second part verifies that all files in the Wheel software package have not been tampered with based on the Record file.

[0082] Figure 6 The entire process of installation package verification provided by the embodiment of the present application is shown in FIG. Figure 6 , the process includes the following steps: step1. Get the public key corresponding to the signed application from the remote repository.

[0083] Step 2. Extract the Record.asc file, which is the signature file, from the installation location of the Wheel software package.

[0084] Step 3. 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 public key.

[0085] Step 4. After the signature verification is successful, the integrity of the Wheel software package can also be verified based on 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.

[0086] The embodiment of the present application installs a signed Wheel software package. Since the signature is unique, no third party can perform effective verification. When performing subsequent verification, it is only necessary to verify whether Record.asc can pass the signature verification. In addition, the signature file of the embodiment of the present application exists in the life cycle of the software package, which can maximize the consistency of software package distribution and help operation and maintenance personnel to quickly trace the software package.

[0087] Please refer to Figure 7, which shows a schematic diagram of the structure of an installation package uploading device provided in an embodiment of the present application, the device is arranged in a first electronic device, the device can be implemented by software, hardware or a combination of both, and becomes the whole or part of the first electronic device, the device includes: The first generating module 701 is used to generate a public key and a private key corresponding to a target application based on a preset signature algorithm; A second generating module 702, configured to generate a signature file corresponding to the target application based on the private key and the first installation package corresponding to the target application, wherein the signature file includes signature information corresponding to each file in the first installation package; A packaging module 703 is used to package the signature file and the first installation package to obtain a second installation package corresponding to the target application; The uploading module 704 is used to upload the second installation package and the public key to the 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.

[0088] In another embodiment of the present application, the first generation module 701 is used to obtain a target file corresponding to the first installation package by unpacking the first installation package, the target file including 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 based on the private key and the copy of the target file.

[0089] In another embodiment of the present application, the first generation module 701 is used to copy the target file under the 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 is used to store the target file and its copy.

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

[0091] 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 aforementioned method embodiments and will not be repeated here.

[0092] Please refer to Figure 8, which shows a schematic diagram of the structure of an installation package distribution device provided in an embodiment of the present application, the device is arranged in a second electronic device, the device can be implemented by software, hardware or a combination of both, and becomes the whole or part of the second electronic device, the device includes: a distribution module 801, configured to distribute the second installation package corresponding to the target application to the third electronic device in response to a distribution request of the third electronic device for the second installation package corresponding to the target application, wherein the second installation package is an installation package obtained by packaging the first installation package corresponding to the target application and a signature file, wherein 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 and the first installation package; The providing module 802 is used to provide the public key corresponding to the target application to the third electronic device after the third electronic device installs the second installation package into the container, so that the third electronic device verifies the installed second installation package.

[0093] Please refer to Fig. 9 , which shows a schematic diagram of the structure of an installation package verification device provided in an embodiment of the present application, the device is arranged in a third electronic device, the device can be implemented by software, hardware or a combination of both, and becomes the whole or part of the third electronic device, the device includes: A first acquisition module 901 is used to acquire a signature file corresponding to the target application after installing a second installation package corresponding to the target application into a container, wherein the second installation package is an installation package obtained by packaging the signature file with the first installation package, and the signature file includes signature information corresponding to each file in the first installation package; A second acquisition module 902, used to acquire a public key corresponding to the target application; The verification module 903 is used to verify the source of the installed second installation package based on the public key and the signature file.

[0094] In another embodiment of the present application, the first acquisition module 901 is used to search for the file directory at the installation location of the target application; obtain the signature file from the target file directory, and the target file directory is the file directory obtained after the first installation package is unpacked and is used to store the target file and its signature file.

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

[0096] In another embodiment of the present application, the verification module 903 is used to obtain the hash value of each file in the first installation package obtained by decryption when the signature information in the signature file is successfully decrypted using the public key; obtain the hash value of each file in the second installation package after installation; 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 second installation package after installation, determine that the files in the second installation package after installation are complete.

[0097] 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 aforementioned method embodiments and will not be repeated here.

[0098] Fig.10 The structure 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 .

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

[0100] The memory 1002 may include one or more computer-readable storage media, which may be non-temporary computer-readable storage media, for example, the non-temporary 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 device, etc. The computer-readable storage medium stores at least one computer program, which can implement the above-mentioned installation package distribution method or installation package verification method when executed.

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

[0102] Those skilled in the art will understand that Fig.10 The structure shown in the figure does not constitute a limitation on the electronic device 1000, and the electronic device 1000 may include more or less components than those shown in the figure, or combine some components, or adopt a different component arrangement.

[0103] An embodiment of the present application provides 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, the above-mentioned installation package uploading method, or the installation package uploading method, or the installation package verification method can be implemented.

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

[0105] 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 aforementioned method embodiments and will not be repeated here.

[0106] 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 aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions 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: Generate the public key and private key corresponding to the target application based on the preset signature algorithm; Based on the private key and a first installation package corresponding to the target application, generating a signature file corresponding to the target application, the signature file including 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; The second installation package and the public key are uploaded 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.

2. The method according to claim 1, characterized in that The step of generating a signature file corresponding to the target application based on the private key and the first installation package of the target application comprises: Unpacking the first installation package to obtain a target file corresponding to the first installation package, where the target file includes a hash value of each file in the first installation package; Copying the target file to obtain a copy of the target file; A signature file corresponding to the target application is generated based on the private key and the copy of the target file.

3. The method according to claim 2, characterized in that The step of copying the target file to obtain a copy of the target file includes: The target file in the target file directory is copied and stored in the target file directory to obtain a copy of the target file. The target file directory is a file directory obtained after the first installation package is unpacked and is used to store the target file and its copy.

4. The method according to claim 2, characterized in that: The step of generating a signature file corresponding to the target application based on the private key and the copy of the target file includes: Using the private key, encrypting the hash value of each file in the copy of the target file to obtain signature information of the copy of the target file; The signature information is added to the copy of the target file to obtain the signature file.

5. A method for distributing an installation package, 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, wherein the second installation package is an installation package obtained by packaging a first installation package corresponding to the target application and a signature file, wherein 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 and the first installation package; After the third electronic device installs the second installation package into the container, the public key corresponding to the target application is provided to the third electronic device, so that the third electronic device verifies the installed second installation package.

6. A method for verifying an installation package, characterized in that: The method is applied to a third electronic device, and the method includes: After installing a second installation package corresponding to the target application into the container, obtaining a signature file corresponding to the target application, wherein the second installation package is an installation package obtained by packaging the signature file with the first installation package, and the signature file includes signature information corresponding to each file in the first installation package; Obtaining a public key corresponding to the target application; The installed second installation package is verified based on the public key and the signature file.

7. The method according to claim 6, characterized in that The step of obtaining the signature file corresponding to the target application comprises: Find the file directory at the installation location of the target application; The signature file is obtained from a target file directory, where the target file directory is a file directory obtained after the first installation package is unpacked and is used to store the target file and its signature file.

8. The method according to claim 6, characterized in that The verifying the installed second installation package based on the public key and the signature file includes: Using the public key, decrypting the signature information in the signature file; If the signature information is successfully decrypted, it is determined that the installed second installation package has the same source as the public key.

9. The method according to claim 6, 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, obtaining the hash value of each file in the first installation package obtained by decryption; Obtaining hash values ​​of various files in the second installation package after installation; 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 second installation package after installation, it is determined that the file in the second installation package after installation is complete.

10. An electronic device, characterized in that: It comprises 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 as described in any one of claims 1 to 4, or the installation package distribution method as described in claim 5, or the installation package verification method as described in any one of claims 6 to 9.

11. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores at least one computer program, and when the at least one computer program is executed by the processor, it can implement the installation package uploading method described in any one of claims 1 to 4, or the installation package distribution method described in claim 5, or the installation package verification method described in any one of claims 6 to 9.

12. A computer program product, characterized in that The computer program product includes a computer program, which, when executed by a processor, can implement the installation package uploading method described in any one of claims 1 to 4, or the installation package distribution method described in claim 5, or the installation package verification method described in any one of claims 6 to 9.

Images