Cross-network software dependency self-consistent synchronization method and system for research and development tool chain

Abstract

The application provides a cross-network software dependency self-consistent synchronization method and system for a research and development tool chain, relates to the technical field of data processing, and analyzes a selected target object to generate a dependency list on a first network side, calls a dependency file according to the dependency list, and performs an encryption and encapsulation operation to obtain a synchronization data packet, performs a disassembly and error correction operation on the synchronization data packet to obtain a synchronization data slice and a check slice, and unidirectionally transmits the synchronization data slice and the check slice to a second network side. On the second network side, the received synchronization data slice and the check slice are used for data reorganization to obtain a reorganized data packet, the reorganized data packet is subjected to a security check, and the reorganized data packet that passes the check is deployed. The application realizes complete synchronization and safe transmission of software dependency under the condition of unidirectional transmission of physical isolation.

Description

Technical Field

[0001] This invention relates to data processing technology, and more particularly to a cross-network software dependency self-consistent synchronization method and system for R&D toolchains. Background Technology

[0002] With the rapid development of software factories and R&D toolchain systems, the efficiency and standardization of software development have continued to improve. In industries with high data security requirements, such as military and government enterprises, R&D environments are generally deployed on physically isolated internal networks. Cross-network synchronization of dependency packages is a crucial link in supporting the normal operation of offline R&D toolchains, and it is related to the delivery efficiency of internal R&D and the security of the supply chain.

[0003] Currently, software dependency synchronization in physically isolated networks primarily relies on manual transmission combined with physical media. Developers record missing dependencies on the intranet, which are then manually downloaded by external personnel and transferred to the intranet via CD-ROM or secure storage media. This method struggles to cover all dependency delivery levels, often resulting in multiple round trips for packet replenishment and long synchronization cycles. Furthermore, the lack of a reverse data channel in a unidirectional isolated environment prevents the use of conventional network protocol retransmission mechanisms to ensure transmission reliability.

[0004] Therefore, how to achieve complete synchronization and secure transmission of software-dependent data under physically isolated unidirectional transmission conditions has become a critical issue that urgently needs to be addressed. Summary of the Invention

[0005] This invention provides a cross-network software dependency self-consistent synchronization method and system for R&D toolchains, which can achieve complete synchronization and secure transmission of software dependencies under physically isolated unidirectional transmission conditions.

[0006] A first aspect of the present invention provides a cross-network software dependency self-consistent synchronization method for R&D toolchains, comprising: On the first network side, the selected target object is parsed to generate a dependency list; The corresponding dependency files are retrieved according to the dependency list, and the dependency files are encrypted and encapsulated to obtain a synchronization data packet; The synchronization data packet is disassembled and error-corrected to obtain multiple synchronization data slices and verification slices, and the synchronization data slices and verification slices are unidirectionally transmitted from the first network side to the second network side. On the second network side, data is reassembled based on the received synchronization data slices and verification slices to obtain reassembled data packets. Security verification is performed on the reassembled data packets, and the reassembled data packets that pass the verification are deployed.

[0007] Optionally, in one possible implementation of the first aspect, the step of parsing the selected target object and generating a dependency list includes: A dependency tree parsing operation is performed on the target object to obtain multiple dependent objects corresponding to the target object, and a dependency list is formed based on the dependent objects.

[0008] Optionally, in one possible implementation of the first aspect, the step of retrieving the corresponding dependency file according to the dependency list and encrypting and encapsulating the dependency file to obtain a synchronization data packet includes: Based on the dependency list, retrieve the dependency files of each dependent object; Calculate the hash value for each of the dependent files to obtain the leaf hash value of each dependent file; Construct a hash tree based on the leaf hash values, and calculate the root hash value of the hash tree; The root hash value is encrypted using a preset private key on the first network side to obtain a signature credential; The signature credential and dependent files are encapsulated to obtain a synchronization data packet.

[0009] Optionally, in one possible implementation of the first aspect, the step of performing an error correction operation on the synchronization data packet to obtain multiple synchronization data slices and verification slices includes: The synchronization data packet is divided based on a preset segmentation size to obtain multiple initial data slices; The forward error correction algorithm is invoked to perform redundancy calculations on the initial data slices, generating multiple initial check slices; A frame header is encapsulated at the beginning of each initial data slice and initial check slice to obtain encapsulated synchronization data slices and check slices. The frame header includes a session identifier, slice sequence number, and check code.

[0010] Optionally, in one possible implementation of the first aspect, the step of reassembling data based on the received synchronization data slice and check slice to obtain a reassembled data packet includes: Identify the frame header on the received synchronization data slice, and determine the missing synchronization data slice based on the frame header; When it is determined that there is a missing synchronization data slice, the missing synchronization data slice is restored based on the received verification slice to obtain the complete slice sequence; When it is determined that there are no missing synchronization data slices, a complete slice sequence is formed based on all synchronization data slices on the second network side; The synchronization data slices in the complete slice sequence are spliced ​​together to generate a recombined data packet.

[0011] Optionally, in one possible implementation of the first aspect, determining the missing synchronization data slice based on the frame header includes: Extract the session identifier, slice number, and checksum from the corresponding frame header; Based on the verification code, the received synchronous data slices are checked for consistency, and synchronous data slices that fail the consistency check are removed. The unreceived synchronization data slice is determined based on the session identifier and slice sequence number; The removed synchronization data slices and the unreceived synchronization data slices are treated as missing synchronization data slices.

[0012] Optionally, in one possible implementation of the first aspect, the security verification of the reassembled data packet includes: Obtain the dependent files in the reassembled data packet as reassembled dependent files, and extract the signature credentials from the reassembled data packet; Calculate the hash value for each of the reorganization dependency files, and determine the root hash value corresponding to the reorganized data packet based on the hash value of the reorganization dependency files; The signature credential is decrypted by retrieving the preset public key to obtain the root hash value corresponding to the synchronization data packet; The root hash values ​​of the reassembled data packet and the synchronization data packet are compared. If the root hash values ​​of the reassembled data packet and the synchronization data packet are different, a verification failure result is generated. If the root hash values ​​of the reassembled data packet and the synchronization data packet are the same, a verification pass result is generated.

[0013] A second aspect of the present invention provides a cross-network software dependency self-consistent synchronization system for R&D toolchains, comprising: The parsing module is used on the first network side to parse the selected target object and generate a dependency list; The encapsulation module is used to retrieve the corresponding dependency files according to the dependency list, and to perform encryption encapsulation operations on the dependency files to obtain a synchronization data packet; The disassembly module is used to disassemble and correct the synchronous data packets to obtain multiple synchronous data slices and verification slices, and to transmit the synchronous data slices and verification slices unidirectionally from the first network side to the second network side. The reassembly module is used on the second network side to reassemble data based on the received synchronization data slice and verification slice to obtain reassembled data packets, perform security verification on the reassembled data packets, and deploy the reassembled data packets that pass the verification.

[0014] A third aspect of the present invention provides an electronic device comprising: a memory, a processor, and a computer program, the computer program being stored in the memory, and the processor executing the computer program to perform the methods described in the first aspect of the present invention and various possible methods related to the first aspect.

[0015] A fourth aspect of the present invention provides a storage medium storing a computer program, which, when executed by a processor, is used to implement the first aspect of the present invention and various methods possibly involved in the first aspect.

[0016] The beneficial effects of this invention are as follows: 1. This invention parses the selected target object on the first network side to generate a dependency list, retrieves the dependency file according to the dependency list, and performs encryption and encapsulation operations to obtain a synchronization data packet. The synchronization data packet is then disassembled and error-corrected to obtain synchronization data slices and verification slices, which are then transmitted unidirectionally to the second network side. On the second network side, the received synchronization data slices and verification slices are used to reassemble the data into a reconstructed data packet, which undergoes security verification. The reconstructed data packet that passes verification is then deployed. This invention encapsulates software dependencies into synchronization data packets with verification information on the first network side and transmits them across the network in a unidirectional manner after slicing. On the second network side, the received synchronization data slices are used for reassembly, verification, and deployment. This avoids the dependency file incompleteness caused by manual recording and transmission via physical media in existing technologies, achieving synchronization of software dependencies from the first network side to the second network side under physically isolated unidirectional transmission conditions.

[0017] 2. This invention segments synchronization data packets to obtain initial data slices, calls a forward error correction algorithm to perform redundancy calculations on the initial data slices to generate initial check slices, and encapsulates a frame header including a session identifier, slice sequence number, and checksum in the header of each slice. On the second network side, the synchronization data slices are verified for consistency based on the checksum in the frame header. Synchronous data slices that fail verification are discarded. Unreceived synchronization data slices are determined based on the session identifier and slice sequence number. The discarded and unreceived synchronization data slices are considered as missing synchronization data slices, and the missing synchronization data slices are restored based on the check slices. This invention restores damaged and lost synchronization data slices during transmission by using check slices, realizing the completion and reassembly of synchronization data slices under unidirectional transmission conditions.

[0018] 3. This invention calculates leaf hash values ​​for each dependent file, constructs a hash tree based on the leaf hash values, calculates the root hash value, and encrypts the root hash value using a preset private key on the first network side to obtain a signature credential. On the second network side, the root hash value is calculated for the recombined dependent files, and the signature credential is decrypted using a preset public key to obtain the root hash value corresponding to the synchronization data packet. The two root hash values ​​are then compared to confirm whether the dependent files have been tampered with during cross-network transmission, thus achieving cross-network anti-tampering verification of dependent files in an intranet environment. Attached Figure Description

[0019] Figure 1A flowchart of a cross-network software dependency self-consistent synchronization method for R&D toolchains provided by the present invention; Figure 2 This is a schematic diagram of the structure of a cross-network software dependency self-consistent synchronization system for R&D toolchains provided by the present invention; Figure 3 This is a schematic diagram of the hardware structure of an electronic device provided by the present invention. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0021] The terms "first," "second," "third," "fourth," etc. (if present) in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein.

[0022] It should be understood that in the various embodiments of the present invention, the sequence number of each process does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0023] It should be understood that in this invention, "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion, for example, a process, method, system, product, or device that includes a series of steps or units is not necessarily limited to those steps or units that are explicitly listed, but may include other steps or units that are not explicitly listed or that are inherent to such process, method, product, or device.

[0024] It should be understood that in this invention, "multiple" refers to two or more. "And / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "Contains A, B, and C", "Contains A, B, and C" means that all three A, B, and C are contained; "Contains A, B, or C" means that one of A, B, and C is contained; "Contains A, B, and / or C" means that any one, two, or three of A, B, and C are contained.

[0025] It should be understood that in this invention, "B corresponding to A", "B corresponding to A", "A and B correspond", or "B and A correspond" means that B is associated with A, and B can be determined based on A. Determining B based on A does not mean determining B solely based on A; B can also be determined based on A and / or other information. Matching A and B is defined as a similarity between A and B that is greater than or equal to a preset threshold.

[0026] Depending on the context, "if" as used here can be interpreted as "when," "when," "in response to determination," or "in response to detection."

[0027] The technical solution of the present invention will be described in detail below with reference to specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0028] This invention provides a cross-network software dependency self-consistent synchronization method for R&D toolchains, such as... Figure 1 As shown, it includes: S1, on the first network side, parses the selected target object and generates a dependency list.

[0029] Here, the first network side refers to the external network environment that is physically isolated from the second network side; the target object refers to the synchronization object selected by the developer on the first network side, which can be a dependency identifier or a configuration file; the dependency list refers to the list of software dependencies at various levels referenced by the target object after parsing the target object.

[0030] It's important to note that when a development toolchain compiles and builds a software project, the project's own code typically cannot run independently and requires external software dependencies. These dependencies, in turn, have dependencies that reference other software dependencies. The target object initially selected by the developers on the first network side serves as a starting point. If only the software dependencies corresponding to this starting point are synchronized, the lower-level and deeper software dependencies it references will be missing, causing repeated missing dependencies to be reported during intranet compilation. This step parses the selected target object on the first network side, comprehensively identifying the software dependencies at each level of the target object, forming a complete dependency list that does not omit any lower-level references.

[0031] Understandably, the first network side receives the target object submitted by the developer, parses the target object, expands the software dependencies at each level referenced by the target object layer by layer, and summarizes the expanded software dependencies to form a dependency list.

[0032] In some embodiments, step S1 (on the first network side, parsing the selected target object and generating a dependency list) includes S11: S11, perform dependency tree parsing operation on the target object to obtain multiple dependent objects corresponding to the target object, and form a dependency list based on the dependent objects.

[0033] It's important to note that software dependencies are typically transitive, with a single top-level dependency referencing dozens or even hundreds of deeper dependencies. Therefore, this step involves extracting dependencies from all levels downwards.

[0034] Among them, dependency tree resolution operation refers to the resolution operation that starts from the target object and expands the software dependencies referenced at each level layer by layer; dependency object refers to the software dependency referenced by the target object at each level through dependency tree resolution operation.

[0035] Understandably, dependency resolution tools within the development toolchain, such as Maven, npm, and pnpm, can be used to resolve the target object. First, identify the software dependencies directly referenced by the target object. Then, using these referenced dependencies as new starting points, expand downwards layer by layer until you reach software dependencies that no longer reference other software dependencies, thus obtaining multiple dependency objects corresponding to the target object. These multiple dependency objects are then aggregated, and duplicate dependencies are removed to form a dependency list.

[0036] S2, retrieve the corresponding dependency files according to the dependency list, and perform encryption and encapsulation operations on the dependency files to obtain the synchronization data packet.

[0037] It should be noted that simply downloading the dependency files cannot guarantee their integrity after cross-network transmission, nor can it guarantee that the dependency files have not been tampered with during transmission. This step, after retrieving each dependency file, encrypts and encapsulates them, including verification information representing the overall content of the dependency file within the synchronization data packet. This allows the second network side to verify whether the dependency files have been tampered with, even without connecting to a public network, solely based on the verification information carried within the synchronization data packet itself.

[0038] Among them, dependency files refer to executable or deployable software component files corresponding to dependency objects; encryption and encapsulation operations refer to the operations of encrypting and encapsulating dependency files; and synchronization data packets refer to data packets obtained after encryption and encapsulation operations on dependency files, which are used for cross-network transmission.

[0039] In some embodiments, step S2 (retrieving the corresponding dependency file according to the dependency list and performing an encryption and encapsulation operation on the dependency file to obtain a synchronization data packet) includes S21-S25: S21, retrieve the dependency files of each dependent object based on the dependency list.

[0040] Understandably, the process involves obtaining each dependency object from the dependency list, and then retrieving the corresponding dependency file from the mirror source one by one, based on the storage location of each dependency object in the mirror source on the first network side.

[0041] S22, calculate the hash value for each of the dependent files to obtain the leaf hash value of each of the dependent files.

[0042] Understandably, the content of each dependent file, i.e. the complete binary content, is read one by one. Based on the read content, a hash operation is performed on each dependent file, and the calculated hash value is used as the leaf hash value of the corresponding dependent file.

[0043] S23, construct a hash tree based on the leaf hash values, and calculate the root hash value of the hash tree.

[0044] It should be noted that this step combines the leaf hash values ​​layer by layer upwards to calculate a root hash value. If any dependent file is modified, the root hash value obtained by combining the calculated values ​​will change.

[0045] A hash tree is a tree-like structure formed by combining the leaf hash values ​​of each dependent file as the bottom-level node, layer by layer upwards.

[0046] Understandably, the leaf hash values ​​of each dependent file are used as the bottom-level nodes of the hash tree. Adjacent leaf hash values ​​are combined, and the hash value of the combined content is calculated to obtain the node at the next higher level. This process is repeated, merging upwards layer by layer until only one node remains. The hash value corresponding to this node is then used as the root hash value of the hash tree. For example, when there are four leaf hash values, the first and second leaf hash values ​​are combined to obtain the first intermediate node, the third and fourth leaf hash values ​​are combined to obtain the second intermediate node, and the first and second intermediate nodes are combined to obtain the root hash value. Calculating the root hash value using a hash tree is existing technology and will not be elaborated upon here.

[0047] S24, the root hash value is encrypted based on the preset private key of the first network side to obtain a signature certificate.

[0048] It is understandable that the preset private key refers to the private key pre-configured on the first network side and used in the asymmetric key for encrypting the root hash value. The preset private key is only stored on the first network side. The preset private key is retrieved to perform asymmetric encryption on the root hash value, and the encrypted result is used as a signature credential. The signature credential is a digital credential generated based on the encryption of the preset private key.

[0049] S25, the signature credential and the dependency file are encapsulated to obtain a synchronization data packet.

[0050] Understandably, all dependent files and the generated signature credentials are compressed and packaged into a single compressed file, which is the synchronization data package.

[0051] S3, perform a decomposition and error correction operation on the synchronization data packet to obtain multiple synchronization data slices and verification slices, and transmit the synchronization data slices and verification slices unidirectionally from the first network side to the second network side.

[0052] It should be noted that the channel between the first and second network sides is a unidirectional transmission channel, which cannot provide reverse feedback; the second network side cannot send data reception status back to the first network side. In this situation, if synchronization data packets are transmitted directly, and some data is lost during transmission, the second network side cannot request the first network side to retransmit the lost portion, resulting in missing data synchronized to the second network side. This step performs a decomposition and error correction operation on the synchronization data packets. While decomposing the synchronization data packets into multiple slices, a check slice is also generated. When data loss occurs on the second network side, the lost data can be automatically reconstructed using the received slices and check slices, without needing to request retransmission from the first network side.

[0053] Among them, the disassembly and error correction operation refers to the process of data slicing and forward error correction coding; the synchronous data slice refers to the data slice obtained after splitting the synchronous data packet; the verification slice refers to the slice generated after redundancy calculation of multiple synchronous data slices, which is used to restore lost or damaged synchronous data slices; the second network side refers to the internal network environment in a physically isolated state.

[0054] It is understandable that the synchronization data packets are disassembled and error-corrected to obtain multiple synchronization data slices and check slices, which are then pushed unidirectionally from the first network side to the second network side through a one-way transmission channel.

[0055] In some embodiments, step S3 (performing a decomposition and error correction operation on the synchronization data packet to obtain multiple synchronization data slices and verification slices) includes S31-S33: S31, the synchronization data packet is divided based on a preset segmentation size to obtain multiple initial data slices.

[0056] It is understandable that the preset segmentation size refers to the pre-defined size of each slice when dividing the synchronization data packet. Starting from the beginning of the synchronization data packet, the synchronization data packet is sequentially split based on the preset segmentation size to obtain multiple initial data slices of the same size.

[0057] S32, the forward error correction algorithm is invoked to perform redundancy calculation on the initial data slice to generate multiple initial verification slices.

[0058] It is understandable that the initial data slice is used as the input of the forward error correction algorithm, i.e., the FEC algorithm, to perform redundancy calculation on the initial data slice. Based on the preset redundancy, multiple redundant data segments are generated. Each redundant data segment is an initial check slice, and the initial check slice contains redundancy information between multiple initial data slices.

[0059] It is worth mentioning that redundant calculation based on forward error correction algorithm is an existing technology and will not be elaborated here.

[0060] S33, a frame header is encapsulated in the header of each initial data slice and initial check slice to obtain the encapsulated synchronization data slice and check slice. The frame header includes a session identifier, a slice sequence number and a check code.

[0061] The frame header refers to the set of data information encapsulated in the slice header, including the session identifier, slice sequence number, and checksum; the session identifier refers to the identifier of the synchronous transmission task to which the slice belongs; the slice sequence number refers to the number that marks the position of the slice in the overall data; and the checksum refers to the verification data used to verify whether the content of a single slice is corrupted.

[0062] It is understandable that a frame header is encapsulated in the header of each initial data slice and initial check slice. The frame header includes the unique session identifier of this synchronization transmission task, the slice sequence number of the current slice, and the check code corresponding to the slice content.

[0063] It is worth mentioning that the check code can be calculated using the Cyclic Redundancy Check (CRC) algorithm, which is existing technology and will not be elaborated here.

[0064] S4, on the second network side, data is reassembled based on the received synchronization data slice and verification slice to obtain reassembled data packets, and the reassembled data packets are security verified. The reassembled data packets that pass the verification are then deployed.

[0065] It should be noted that after the synchronization data slices and check slices arrive at the second network side through the unidirectional transmission channel, some slices may be lost or damaged during transmission. This step first determines which synchronization data slices are missing on the second network side, restores the missing synchronization data slices using check slices, and then reassembles the complete synchronization data slices to restore them into data packets.

[0066] Among them, the reassembled data packet refers to the data packet obtained by splicing and restoring the complete synchronization data slice on the second network side.

[0067] Furthermore, although the reassembled data packet is restored to complete data on the second network side, it cannot be confirmed whether the dependent files within it have been tampered with during transmission. Therefore, a security verification of the reassembled data packet is still required. This can be done by verifying whether the dependent files have been tampered with based on the signature credentials. Deployment should only proceed after the verification passes.

[0068] In some embodiments, step S4 (reconstructing data based on the received synchronization data slice and check slice to obtain a reconstructed data packet) includes S41-S44: S41, Identify the frame header on the received synchronization data slice, and determine the missing synchronization data slice based on the frame header.

[0069] It should be noted that the synchronous data slices received by the second network side may contain slices whose content was corrupted during transmission, or slices that did not arrive. Both of these situations will result in incomplete data packets when finally spliced ​​together.

[0070] Therefore, this step identifies the frame header of the received synchronization data slice and determines the missing synchronization data slice based on the data information in the frame header.

[0071] In some embodiments, step S41 (determining the missing synchronization data slice based on the frame header) includes S411-S414: S411, extract the session identifier, slice number and checksum from the corresponding frame header.

[0072] Understandably, for each received synchronous data slice, the frame header encapsulated in the header is read, and the session identifier, slice sequence number, and checksum are extracted from the frame header.

[0073] S412, perform consistency verification on the received synchronous data slices based on the verification code, and discard synchronous data slices that fail the consistency verification.

[0074] It should be noted that when synchronous data slices pass through a one-way transmission channel, their content may be corrupted. If a corrupted synchronous data slice is used in the splicing process, it will lead to errors in the spliced ​​data packet. This step performs consistency verification on the received synchronous data slices based on the checksum in the frame header, identifies and removes synchronous data slices with corrupted content, and treats the corrupted synchronous data slices as missing synchronous data slices for restoration in subsequent processing.

[0075] Among them, consistency verification refers to the process of verifying whether the content of the synchronized data slice is consistent with the check code.

[0076] Understandably, a verification calculation is performed based on the content of the received synchronization data slice to obtain the actual verification value. This verification calculation can be referred to in step S33 and can be implemented using the Cyclic Redundancy Check (CRC) algorithm. The actual verification value is compared with the checksum in the corresponding frame header. If the actual verification value and the checksum in the corresponding frame header are consistent, that is, the consistency verification passes, then the content of the corresponding synchronization data slice is determined to be complete; if they are inconsistent, that is, the consistency verification fails, then the corresponding synchronization data slice is determined to be corrupted, and the corrupted synchronization data slice is discarded.

[0077] S413, determine the unreceived synchronization data slice based on the session identifier and slice sequence number.

[0078] Understandably, received synchronization data slices are grouped according to session identifiers, and synchronization data slices within the same group belong to the same synchronization transmission task. Within the same group, the missing slice number is determined based on the slice sequence number, and the synchronization data slice corresponding to the missing slice number is regarded as an unreceived synchronization data slice, that is, a synchronization data slice that did not reach the second network side within the same synchronization transmission task.

[0079] S414, treat the removed synchronization data slices and the unreceived synchronization data slices as missing synchronization data slices.

[0080] It is understandable that the synchronization data slices removed in step S412 and the synchronization data slices not received in step S413 are considered together as missing synchronization data slices.

[0081] S42, when it is determined that there is a missing synchronization data slice, the missing synchronization data slice is restored according to the received verification slice to obtain a complete slice sequence.

[0082] It should be noted that when missing synchronization data slices are identified, the missing parts need to be filled in. This step restores the missing synchronization data slices by verifying the redundancy information in the slices.

[0083] Among them, the complete slice sequence refers to the synchronous data slices arranged according to the slice number after the missing synchronous data slices are filled in.

[0084] Understandably, when determining the existence of missing synchronization data slices, the received synchronization data slices and the received check slices are used as inputs. Based on the redundancy information of the check slices, a forward error correction algorithm is used to calculate the missing synchronization data slices and restore them. The restored synchronization data slices are then arranged with the received synchronization data slices according to their slice sequence numbers to form a complete slice sequence.

[0085] S43, when it is determined that there are no missing synchronization data slices, a complete slice sequence is formed based on all synchronization data slices on the second network side.

[0086] It is understandable that when it is determined that there are no missing synchronization data slices, it means that the synchronization data slices received by the second network side have been complete and have all passed the consistency check. All the synchronization data slices received by the second network side are directly arranged according to the slice sequence number to form a complete slice sequence.

[0087] S44, the synchronization data slices in the complete slice sequence are spliced ​​together to generate a recombined data packet.

[0088] Understandably, the data content of each synchronization data slice in the complete slice sequence is read sequentially, the frame header of each slice is removed, and the data content with the frame header removed is concatenated in order to form a continuous complete data packet, thus obtaining the reconstructed data packet.

[0089] In some embodiments, step S4 (performing security verification on the reassembled data packet) includes S45-S49: S45, obtain the dependent file in the reconstructed data packet as the reconstructed dependent file, and extract the signature credential in the reconstructed data packet.

[0090] Understandably, the reassembled data packet is decompressed, all dependent files within the packet are extracted as reassembled dependent files, and the signature credential encapsulated on the first network side is extracted from the reassembled data packet.

[0091] S46, calculate the hash value for each of the reorganization dependency files, and determine the root hash value corresponding to the reorganized data packet based on the hash value of the reorganization dependency file.

[0092] It should be noted that to verify whether the dependency file has been tampered with, the root hash value corresponding to a reconstructed data packet can be recalculated based on the dependency file on the second network side, and then compared with the root hash value decrypted in the signature certificate.

[0093] It is understandable that the hash value of each reorganization dependency file is calculated separately. Referring to step S23, the hash values ​​of each reorganization dependency file are combined and calculated layer by layer until only one node remains. Then, the hash value corresponding to that node is used as the root hash value corresponding to the reorganized data packet.

[0094] S47, retrieve the preset public key to decrypt the signature credential and obtain the root hash value corresponding to the synchronization data packet.

[0095] It is understood that the preset public key refers to the public key in the asymmetric key that is paired with the preset private key on the first network side and pre-configured on the second network side for decrypting the signature credential. The signature credential extracted in step S45 is decrypted based on the preset public key, and the decryption result is the root hash value corresponding to the synchronization data packet.

[0096] S48. The root hash values ​​of the reassembled data packet and the synchronization data packet are compared. If the root hash values ​​of the reassembled data packet and the synchronization data packet are different, a verification failure result is generated.

[0097] Understandably, the root hash value corresponding to the reconstructed data packet is compared with the root hash value corresponding to the synchronization data packet. If these two root hash values ​​are different, it is determined that the content of the reconstructed file is inconsistent with the content of the file sent by the first network side, indicating that it has been tampered with or damaged, and a verification failure result is generated.

[0098] S49. If the root hash values ​​of the reassembled data packet and the synchronization data packet are the same, a verification pass result is generated.

[0099] Understandably, referring to S48, if the root hash value corresponding to the reconstructed data packet is the same as the root hash value corresponding to the synchronization data packet, then it is determined that the content of the reconstructed file is consistent with the content of the file sent by the first network side, and there is no tampering or damage, generating a verification pass result. The verified reconstructed data packet is then deployed, and the dependent files in the reconstructed data packet are deployed to the development toolchain on the second network side.

[0100] See Figure 2 This is a schematic diagram of a cross-network software dependency self-consistent synchronization system for R&D toolchains provided in an embodiment of the present invention. The system includes: The parsing module is used on the first network side to parse the selected target object and generate a dependency list; The encapsulation module is used to retrieve the corresponding dependency files according to the dependency list, and to perform encryption encapsulation operations on the dependency files to obtain a synchronization data packet; The disassembly module is used to disassemble and correct the synchronous data packets to obtain multiple synchronous data slices and verification slices, and to transmit the synchronous data slices and verification slices unidirectionally from the first network side to the second network side. The reassembly module is used on the second network side to reassemble data based on the received synchronization data slice and verification slice to obtain reassembled data packets, perform security verification on the reassembled data packets, and deploy the reassembled data packets that pass the verification.

[0101] See Figure 3 This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of the present invention. The electronic device 30 includes: a processor 31, a memory 32, and a computer program; wherein... The memory 32 is used to store the computer program, and the memory may also be flash memory. The computer program is, for example, an application program or functional module that implements the above method.

[0102] Processor 31 is configured to execute the computer program stored in the memory to implement the various steps performed by the device in the above method. For details, please refer to the relevant descriptions in the preceding method embodiments.

[0103] Alternatively, the memory 32 can be either standalone or integrated with the processor 31.

[0104] When the memory 32 is a device independent of the processor 31, the device may further include: Bus 33 is used to connect the memory 32 and the processor 31.

[0105] The present invention also provides a readable storage medium storing a computer program, which, when executed by a processor, is used to implement the methods provided in the various embodiments described above.

[0106] The readable storage medium can be a computer storage medium or a communication medium. A communication medium includes any medium that facilitates the transfer of computer programs from one location to another. A computer storage medium can be any available medium accessible to a general-purpose or special-purpose computer. For example, a readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application-Specific Integrated Circuit (ASIC). Alternatively, the ASIC can be located in a user equipment. Of course, the processor and the readable storage medium can also exist as discrete components in a communication device. The readable storage medium can be a read-only memory (ROM), random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device, etc.

[0107] The present invention also provides a program product including executable instructions stored in a readable storage medium. At least one processor of the device can read the executable instructions from the readable storage medium, and the at least one processor executes the executable instructions to cause the device to implement the methods provided in the various embodiments described above.

[0108] In the embodiments of the above-described device, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly manifested as execution by a hardware processor, or execution by a combination of hardware and software modules within the processor.

[0109] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A cross-network software dependency self-consistent synchronization method for R&D toolchains, characterized in that, include: On the first network side, the selected target object is parsed to generate a dependency list; The corresponding dependency files are retrieved according to the dependency list, and the dependency files are encrypted and encapsulated to obtain a synchronization data packet; The synchronization data packet is disassembled and error-corrected to obtain multiple synchronization data slices and verification slices, and the synchronization data slices and verification slices are unidirectionally transmitted from the first network side to the second network side. On the second network side, data is reassembled based on the received synchronization data slices and verification slices to obtain reassembled data packets. Security verification is performed on the reassembled data packets, and the reassembled data packets that pass the verification are deployed.

2. The method according to claim 1, characterized in that, The step of parsing the selected target object and generating a dependency list includes: A dependency tree parsing operation is performed on the target object to obtain multiple dependent objects corresponding to the target object, and a dependency list is formed based on the dependent objects.

3. The method according to claim 1, characterized in that, The step of retrieving the corresponding dependency files according to the dependency list and encrypting and encapsulating the dependency files to obtain a synchronization data packet includes: Based on the dependency list, retrieve the dependency files of each dependent object; Calculate the hash value for each of the dependent files to obtain the leaf hash value of each dependent file; Construct a hash tree based on the leaf hash values, and calculate the root hash value of the hash tree; The root hash value is encrypted using a preset private key on the first network side to obtain a signature credential; The signature credential and dependent files are encapsulated to obtain a synchronization data packet.

4. The method according to claim 1, characterized in that, The step of disassembling and correcting the synchronization data packets yields multiple synchronization data slices and verification slices, including: The synchronization data packet is divided based on a preset segmentation size to obtain multiple initial data slices; The forward error correction algorithm is invoked to perform redundancy calculations on the initial data slices, generating multiple initial check slices; A frame header is encapsulated at the beginning of each initial data slice and initial check slice to obtain encapsulated synchronization data slices and check slices. The frame header includes a session identifier, slice sequence number, and check code.

5. The method according to claim 4, characterized in that, The process of reassembling data based on the received synchronization data slices and verification slices to obtain reassembled data packets includes: Identify the frame header on the received synchronization data slice, and determine the missing synchronization data slice based on the frame header; When it is determined that there is a missing synchronization data slice, the missing synchronization data slice is restored based on the received verification slice to obtain the complete slice sequence; When it is determined that there are no missing synchronization data slices, a complete slice sequence is formed based on all synchronization data slices on the second network side; The synchronization data slices in the complete slice sequence are spliced ​​together to generate a recombined data packet.

6. The method according to claim 5, characterized in that, The determination of missing synchronization data slices based on the frame header includes: Extract the session identifier, slice number, and checksum from the corresponding frame header; Based on the verification code, the received synchronous data slices are checked for consistency, and synchronous data slices that fail the consistency check are removed. The unreceived synchronization data slice is determined based on the session identifier and slice sequence number; The removed synchronization data slices and the unreceived synchronization data slices are treated as missing synchronization data slices.

7. The method according to claim 3, characterized in that, The security verification of the reassembled data packet includes: Obtain the dependent files in the reassembled data packet as reassembled dependent files, and extract the signature credentials from the reassembled data packet; Calculate the hash value for each of the reorganization dependency files, and determine the root hash value corresponding to the reorganized data packet based on the hash value of the reorganization dependency files; The signature credential is decrypted by retrieving the preset public key to obtain the root hash value corresponding to the synchronization data packet; The root hash values ​​of the reassembled data packet and the synchronization data packet are compared. If the root hash values ​​of the reassembled data packet and the synchronization data packet are different, a verification failure result is generated. If the root hash values ​​of the reassembled data packet and the synchronization data packet are the same, a verification pass result is generated.

8. A cross-network software dependency self-consistent synchronization system for R&D toolchains, characterized in that, include: The parsing module is used on the first network side to parse the selected target object and generate a dependency list; The encapsulation module is used to retrieve the corresponding dependency files according to the dependency list, and to perform encryption encapsulation operations on the dependency files to obtain a synchronization data packet; The disassembly module is used to disassemble and correct the synchronous data packets to obtain multiple synchronous data slices and verification slices, and to transmit the synchronous data slices and verification slices unidirectionally from the first network side to the second network side. The reassembly module is used on the second network side to reassemble data based on the received synchronization data slice and verification slice to obtain reassembled data packets, perform security verification on the reassembled data packets, and deploy the reassembled data packets that pass the verification.

9. An electronic device, characterized in that, include: The method comprises a memory, a processor, and a computer program, wherein the computer program is stored in the memory and the processor executes the computer program to perform the method according to any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium stores a computer program, which, when executed by a processor, is used to implement the method described in any one of claims 1 to 7.

Images